Процессный офис: как организовать работу

За каждой ВРГ закрепляется бизнес-аналитик процессного офиса, который в дальнейшем помогает организовать работу группы, выступает в качестве модератора на моделирующих сессиях (специальный тип совещаний по описанию процессов), обучает участников методам и инструментам процессного управления («обучение практикой») и т. д.

Состав рабочей группы должен быть согласован владельцем процесса и руководителем процессного офиса.

В зависимости от задач участники ВРГ должны проходить соответствующие внутренние учебные курсы, чтобы овладеть минимально необходимыми знаниями и компетенциями. Например, если поставлена задача описать процесс «Как есть» в нотации BPMN, то Процессный офис организует обучение (8—16 человек) по методам описания бизнес-процессов в нотации BPMN. Как правило, если работу по описанию начинают сотрудники, совершенно не обученные методам моделирования, то они:

• не могут корректно определить границы и структуру процессов;

• пытаются нарисовать длинный сквозной процесс, состоящий из задач разного масштаба, при этом часто пропускают важные шаги или, наоборот, дробят работу на слишком мелкие фрагменты;

• забывают про описание входов/выходов;

• нарушают многие правила создания моделей типа work flow, в том числе некорректно используют значки BPMN;

• не фиксируют проблемы;

• прочее.

Фактически такие «модели» приходится потом переделывать «с нуля».

2. Описание и анализ бизнес-процессов (в рамках деятельности рабочих групп по бизнес-процессам или по заданию непосредственного руководителя) в нотациях IDEF0 (VAD) и BPMN (eEPC)

Это одна из ключевых функций процессного офиса. Как я писал выше, процессный офис не может и не должен заниматься описанием всех процессов компании своими силами. Важно отметить, что сама постановка задачи – «Описать все процессы» – является некорректной. Описание всего и вся никому не нужно. Тем более что по мере этой работы процессы успевают измениться. Нужно моделировать только те процессы, которые критически важны в настоящее время или необходимы для развития компании в стратегической перспективе. Модель бизнес-процесса (графическая схема плюс другая важная информация) должна использоваться как инструмент для анализа, улучшения, регламентации, автоматизации. Сами по себе схемы ценности не имеют. Если процессный офис слишком долго занимается описанием ради описания, то судьба его печальна – рано или поздно собственник его ликвидирует или заменит в нем ключевых сотрудников.

Описание бизнес-процессов целесообразно выполнять в специализированном программном продукте (например, Business Studio) в обоснованно, сознательно выбранных нотациях, подходящих для решения поставленных задач. В целом и чаще всего это нотации IDEF0 (VAD) – на верхнем уровне и BPMN – на нижнем.

Создание диаграммы в нотации IDEF0 может выполняться в следующей последовательности:

1. Декомпозировать диаграмму на следующий, нижний уровень. В случае, если на нижнем уровне невозможно однозначно определить и привязать к подпроцессам стрелки управления, то это означает, что необходимо декомпозировать процесс, используя нотацию BPMN. В этом случае декомпозиция в нотации IDEF0 не выполняется.

2. Включить сетку, используя функцию программного обеспечения. Если в системе нет функции автосохранения, необходимо сохранять диаграмму после каждого значимого действия (добавление процессов на схему, добавление и привязка стрелок, ввод данных, настройка визуализации).

3. Определить и создать на диаграмме процессы (от 2 до 12). Обязательно указать процесс «Управление…» вверху диаграммы. Наличие готовой диаграммы с одним процессом (кроме контекстной диаграммы) не допускается. В случае наличия двух процессов на диаграмме рекомендуется пересмотреть диаграмму вышестоящего уровня, уточнить границы и состав процессов.

4. Привязать к процессам стрелки, входящие с диаграммы вышестоящего уровня. При необходимости разветвить входящие стрелки с учетом информации (документов, материальных потоков), которые по ним могут передаваться.

5. Определить и показать на диаграмме стрелки, связывающие процессы между собой (взаимодействие по входам/выходам), в том числе стрелки обратной связи и управления.

6. Агрегировать стрелки, выходящие из процессов на диаграмме, путем привязки к стрелкам, исходящим с диаграммы на диаграмму вышестоящего уровня. В случае появления на диаграмме новых стрелок, которые должны передаваться на диаграмму вышестоящего уровня, но не могут быть привязаны к существующим стрелкам, обратиться к процессному методологу для согласования изменений на диаграммах вышестоящего уровня.

7. Зафиксировать проблемы и предложения по процессам (при наличии) визуально.

8. Зафиксировать функциональные требования (при наличии) визуально.

9. Показать для каждого блока владельца процесса и исполнителей (подразделения) путем использования настроек визуализации.

10. Обновить номера процессов на диаграмме. При этом процесс «Управление…» должен иметь номер 1.

11. Проверить диаграмму на визуальную наглядность, в том числе разместить фигуры процессов равноудаленно, путем выравнивания по сетке. Скорректировать положение стрелок и названий. При необходимости изменить размеры диаграммы.

12. Отключить сетку.

13. Выполнить проверку корректности модели с использованием штатного отчета. Устранить ошибки в случае их наличия.

14. Отправить диаграмму на проверку качества процессному методологу (уведомить о готовности диаграммы).

Создание диаграммы в нотации BPMN выполняется в следующей последовательности:

1. Декомпозировать диаграмму на следующий, нижний уровень.

2. Включить режим «Сетка».

3. Создать нужное количество дорожек, используя объекты из справочников. Дорожки на схеме располагаются горизонтально. Увеличить и выровнять размер дорожек по вертикали. Изменить размер дорожек по горизонтали с учетом возможной сложности схемы процесса.

4. Создать стартовое событие (события) процесса.

5. Выполнить моделирование процесса, последовательно используя объекты модели:

• задачи;

• шлюзы;

• события;

• информационные системы;

• документы;

• базы данных;

6. Указать статус для каждого документа, использованного в модели.

7. Проверить наличие взаимодействия процесса по входам/выходам с другими процессами / внешними субъектами. При наличии такого взаимодействия создать на модели необходимое количество свернутых пулов. Показать потоки информации (документов) между процессами и соответствующие базы данных (места хранения информации).

8. При необходимости заполнить атрибут «Требования к срокам» для каждой задачи. Вывести на показ.

9. При наличии информации сформулировать проблемы визуально.

10. При наличии информации сформулировать функциональные требования к ИС визуально.

11. Проверить качество схемы по чек-листу. При необходимости отредактировать визуальный вид схемы для повышения ее компактности и наглядности.

12. Отключить режим «Сетка».

13. Передать схему процесса на согласование процессному методологу (уведомить о готовности схемы).

Работа по описанию (моделированию) бизнес-процессов должна планироваться на основе нормативов трудоемкости (об этом подробно будет сказано ниже). Время, которое требуется от участников ВРГ, должно быть четко определено (сформирован бюджет рабочего времени). Также доступный ресурс сотрудников процессного офиса должен соответствовать планируемой трудоемкости работ.

Бизнес-аналитики процессного офиса могут сопровождать ВРГ (проводить моделирующие сессии и совещания) и заниматься описанием наиболее сложных и важных бизнес-процессов самостоятельно по заданию руководителя процессного офиса.

Ознакомиться с нотацией BPMN и моделированием бизнес-процессов с ее использованием можно в моей книге «Моделирование бизнес-процессов в нотации BPMN в Business Studio 5»11:

Пример графической схемы в нотации BPMN, разработанной для целей анализа и проектирования автоматизированного процесса в 1С: ДО, показан на рис. 20.

Обратите внимание на использование статусов документов. Такое решение, с одной стороны, дает полное представление об информационных потоках, но с другой делает схему визуально нагруженной. Если вы хотите оставить на графической схеме только логику, то придется всю остальную, важную для понимания процесса информацию фиксировать вне модели, например в таблицах MS Excel и пр.

Отмечу, что на схеме рис. 20 задачи, выполняемые вручную, я обычно помечаю маркером «ладошки» и закрашиваю оранжевым цветом, чтобы неэффективность сразу бросалась в глаза руководителям.

3. Проведение моделирующих сессий/совещаний с руководителями и специалистами компании по описанию и анализу бизнес-процессов

Моделирующая сессия – это специальный вид совещания. МС проводится по определенной методике или, другими словами, сценарию.

МС – это очень хороший способ вовлечь сотрудников в работу по описанию и анализу бизнес-процессов. По ходу сессии сотрудники учатся определять контекст процесса, его структуру, описывать процесс в определенной нотации, определять взаимодействие между процессами, выявлять и фиксировать проблемы, продумывать возможные подходы к реорганизации, улучшению бизнес-процесса.

Бизнес-аналитики процессного офиса должны уметь профессионально организовывать и проводить моделирующие сессии. Этот навык очень важен для успеха проекта.

4. Инициация проектов оптимизации бизнес-процессов

Данная функция выделена специально, чтобы подчеркнуть ее важность. По ходу описания процессов аналитики фиксируют множество проблем. Как правило, сразу видны возможности улучшения процесса. Некоторые из них являются достаточно простыми и не требуют значительных ресурсов при внедрении. Их можно отнести к группе так называемых БРИ – «Быстро реализуемых инициатив».

Бизнес-аналитики процессного офиса должны фиксировать проблемы и предложения (лучше – прямо в Business Studio, потом можно выгружать в MS Excel), классифицировать их. С определенной периодичностью предложения должны рассматриваться детальнее.

После оценки возможных затрат и эффективности их можно брать в работу – назначать ответственных из сотрудников подразделений. Результаты внедрения БРИ нужно фиксировать и проверять. Для процессного офиса такая база реализованных улучшений – один из важных способов показать результаты своей работы руководству компании. К сожалению, довольно часто рассмотрение и внедрение предложений сотрудников откладываются на потом «до лучших времен… вот когда всё соберем… через месяц…» и т. п.

Второй тип предложений по улучшению бизнес-процессов – это сложные, довольно затратные мероприятия, связанные с изменениями кросс-функционального бизнес-процесса или группы связанных процессов (бизнес-функции), внедрением новых ИТ-решений, структурными изменениями и пр. Такие инициативы нужно тоже фиксировать, но оценивать более системно, тщательно, с учетом стратегии развития компании в целом. По ряду предложений могут быть инициированы проекты оптимизации бизнес-процессов масштаба компании. Процессный офис может выступать инициатором таких проектов – выносить на обсуждение пул проектов (мероприятий), которые могут быть реализованы в следующем квартале, полугодии и т. д.

Процессный офис (в случае отсутствия в компании проектного офиса) может взять на себя ведение базы знаний реализованных проектов улучшений. Информация по таким проектам может быть также выгружена в общую базу знаний по бизнес-процессам в гипертекстовом виде при помощи HTML-публикации или внутреннего портала, например на основе технологии BS Portal.

5. Валидация моделей бизнес-процессов (в том числе с использованием метода имитационного моделирования бизнес-процессов)

Используются два понятия: верификация и валидация моделей. Верификация – это проверка модели по чек-листу на формальное соответствие требованиям «Соглашения по моделированию», в первую очередь – используемой нотации. Валидация подразумевает проверку, что в соответствии со схемой можно реально выполнить процесс и получить заданный результат при приемлемых (установленных) показателях времени, стоимости и качества. Валидацию бизнес-процесса можно проводить двумя путями:

1) организовать и выполнить пробную эксплуатацию процесса;

2) выполнить имитационное моделирование.

Процессный офис может освоить метод имитационного моделирования процессов в Business Studio и выполнять имитацию для наиболее важных бизнес-процессов. Это довольно трудоемко, зато можно понять, как реально будет работать процесс до его внедрения.

6. Разработка/корректировка шаблонов отчетов для автоматической выгрузки документов из среды моделирования бизнес-процессов

Шаблоны отчетов – это понятие среды моделирования Business Studio. С их помощью можно выгружать из базы информацию о бизнес-процессах (и других объектах) в структурированном виде: регламенты, инструкции, положения, технические задания на автоматизацию и др.

Несколько специалистов процессного офиса могут научиться разрабатывать шаблоны отчетов для решения задачи частичной автоматизации формирования регламентирующих документов из Business Studio.

В других программных продуктах также можно разрабатывать специальные отчеты для выгрузки документов из среды моделирования, например путем написания соответствующих скриптов или используя встроенные в инструмент возможности low-code.

4.5. Планирование и внедрение изменений в процессах

1. Разработка уставов и планов проектов оптимизации бизнес-процессов

Если деятельность процессного офиса ограничивается только описанием процессов (созданием графических схем), то это означает, что цель его создания не достигнута. В первую очередь собственнику и руководителям компании нужны реальные изменения, улучшения в бизнес-процессах, результативная деятельность владельцев процессов. Поэтому процессный офис просто обязан внедрять изменения различного вида, оценивая и документируя их результат и эффективность. Для этого можно выполнять БРИ и проекты оптимизации (улучшения) бизнес-процессов.

Для проектов (мероприятий) масштаба структурного подразделения целесообразно делать план (паспорт или карточку проекта). Для проектов межфункционального масштаба, например оптимизации кросс-функционального бизнес-процесса разработки нового продукта, проектов трансформации, цифровизации и пр., необходимо разрабатывать уставы. При отсутствии в компании проектного офиса эту работу должен делать процессный офис.

Желательно разработать и утвердить методику (регламент) выполнения проектов оптимизации (улучшения) бизнес-процессов, в приложения к которому включить формы соответствующих документов: карточка БРИ, карточка (паспорт) проекта, устав проекта и пр.

2. Управление проектами оптимизации бизнес-процессов

Руководитель процессного офиса, процессный методолог и бизнес-аналитик процессного офиса могут играть роль руководителей проектов оптимизации бизнес-процессов. По каждому проекту формируются соответствующие планы. По крупным проектам необходимо готовить еженедельные статус-отчеты для владельцев процессов и кураторов. Также важно формировать ежемесячные отчеты и отчеты по результатам выполнения ключевых этапов проектов. Результативность проектов обязательно должна контролироваться, накопленные знания помещаться в общую базу знаний компании (база Business Studio и выгрузка на внутренний портал при помощи HTML-публикации).

Сотрудники процессного офиса должны обладать необходимыми компетенциями по управлению проектами и, крайне желательно, по управлению изменениями.

Состав этапов проекта оптимизации кросс-функционального бизнес-процесса

В качестве объекта оптимизации (трансформации) может рассматривается кросс-функциональный бизнес-процесс компании, который может включать ряд подпроцессов. Это означает, что руководство компании определило границы процесса так, что он проходит через несколько структурных подразделений организации.

Проектом оптимизации процесса можно считать такой проект, в рамках выполнения которого была подготовлена и использована хотя бы одна схема процесса в нотации BPMN. Это означает, что «проекты улучшений» типа «Замена ламината в офисе» или «Приобретение и монтаж агрегата „А“ в 3-м цеху» к проектам оптимизации административных кросс-функциональных бизнес-процессов компании не относятся (хотя и могут привести к повышению эффективности и пр.). Предлагаемые далее методы и инструменты для проектов такого типа неприменимы или применимы частично.

Собственно, в проект оптимизации кросс-функционального бизнес-процесса (далее для простоты – просто «проект» и «процесс») можно включать следующие этапы:

1. Инициация проекта и подготовка к его выполнению.

2. Предварительный анализ.

3. Углубленный анализ и разработка мероприятий по оптимизации.

4. Внедрение изменений.

5. Анализ эффекта от оптимизации процесса.

6. Подведение итогов проекта.

На рис. 21 показан фреймворк (комплекс типовых процессов) рассматриваемого проекта.

В некоторых компаниях (например, в рамках ПСР12 «Росатома») уже сформирован определенный методический подход и определены этапы выполнения типового проекта. Но каждая организация определяет внутренние методики и регламенты с учетом своей специфики и доступных ресурсов, в первую очередь квалифицированных и вовлеченных сотрудников. Поэтому состав этапов проекта и их названия могут отличаться. Но с точки зрения сути вопроса все указанные на рис. 21 действия должны быть выполнены.

На каждом этапе проекта используются конкретные методики и инструменты. В зависимости от масштабов проекта и доступных ресурсов они могут отличаться по составу, сложности и трудоемкости. Например, можно использовать методы из BABOK, методы управления изменениями, картирование процессов по методу Toyota (для производственных процессов), FMEA-анализ и пр.

Далее я предлагаю минимально необходимый набор методик и инструментов для выполнения проекта оптимизации административного процесса.

Рис. 21. Фреймворк проекта оптимизации

кросс-функционального бизнес-процесса

Для выполнения проекта удобно использовать так называемый «Органайзер» – файл в MS Excel. Найти его можно на моем сайте www.bpm3.ru. При дальнейшем чтении рекомендую открыть этот документ и, читая книгу, просматривать соответствующие разделы «Органайзера». Представленный ниже материал может быть использован для разработки методики (регламента) выполнения проекта оптимизации кросс-функционального бизнес-процесса в вашей организации.

Методы, инструменты и соответствующие страницы «Органайзера» представлены в таблице 10.

Хотел бы отметить следующее. Заполнение большого количество аналитических таблиц не ведет автоматически к глубокому пониманию причин проблем и проектированию оптимального процесса (то же самое можно сказать и о разработке стратегии компании). Это только инструмент систематизации, упорядочения аналитической работы. Чаще всего проблемы в бизнесе сложные, нестандартные и требуют креативного, даже дерзкого мышления и разработки новых, инновационных подходов. Можно привести примеры предприятий, которые внедрили Lean на производстве, но успешно обанкротились из-за неправильно выбранной стратегии и политики ценообразования. Предлагаемые мной подходы и сам «Органайзер» – это не панацея, а только рабочий инструмент, в дополнение к которому рабочая группа может выбирать и использовать подходящие к контексту методы и инструменты.

Инициация проекта и подготовка к его выполнению

Откройте лист «1. Карточка проекта» «Органайзера». Предполагается, что бизнес-процесс для оптимизации был выбран в рамках стратегического планирования в качестве приоритетного. Также инициатором проекта может выступать бизнес-заказчик (например, собственник) или владелец кросс-функционального процесса. В любом случае в компании должен быть определен и закреплен в регламентах четкий порядок выбора приоритетных бизнес-процессов для оптимизации (реорганизации).

В рамках первого этапа проекта формируется ВРГ – временная рабочая группа по проекту. В ее состав включают 3—5 человек – руководителей среднего звена и специалистов из подразделений, через которые проходит кросс-функциональный процесс. Делать ВРГ слишком большой (более 6 человек) нерационально. За ВРГ желательно закрепить бизнес-аналитика из процессного офиса компании. Также нужно назначить кого-то из участников ВРГ руководителем проекта (но не бизнес-аналитика).

Если участники рабочей группы не владеют необходимыми методами и инструментами (описание процессов в BPMN, аналитические методы, Lean), то для них проводится соответствующее обучение с использованием разработанных в компании программ. Описание и оптимизация бизнес-процессов «на основе здравого смысла и опыта» возможны, но, как показывает опыт, недостаточно эффективны.

Рабочей группой совместно с владельцем процесса определяются следующие ключевые аспекты процесса:

1) Бизнес-контекст, заинтересованные стороны и их потребности.

2) Бизнес-проблема, текущие значения показателей процесса.

3) Цели проекта.

4) Возможный результат проекта, целевые значения показателей процесса.

Для понимания бизнес-процесса как объекта управления рекомендую прочитать мою статью «Типовая модель бизнес-процесса» на сайте www.bpm3.ru.

Возможно, что-то из указанного выше сложно сформулировать или быстро измерить. Этот факт не должен быть проблемой при запуске проекта, если владелец процесса (и тем более собственник компании) убежден, что улучшение процесса крайне важно для бизнеса.

На этапе подготовки важно определить положение процесса в общей архитектуре процессов компании и его границы. Это можно сделать с использованием контекстной диаграммы (в любом удобном инструменте, включая MS Visio). В западной практике этот метод называют SIPOC13. Некорректное, неточное определение контекста в дальнейшем приводит к переделкам и увеличению сроков выполнения проекта.

После определения бизнес-контекста, проблем, целей и возможных результатов проекта рабочая группа формирует укрупненный план по этапам с привязкой к календарным срокам, готовит планово-отчетные документы по проекту.

Дополнительно к указанному выше целесообразно определить принципы и ограничения при выполнении текущего и перспективного процесса и риски, которые могут возникнуть при выполнении проекта. Проще говоря, рабочей группе нужно понимать, что можно делать, а что нельзя, какие есть ограничения по возможным методам, инструментам и выделенным на проект ресурсам (в том числе по рабочему времени руководителей компании).

После заполнения листа «1. Карточка проекта» «Органайзера» и согласования с владельцем процесса издается приказ (распоряжение) по компании об инициации проекта. Наименование процесса, цели проекта оптимизации, состав ВРГ, сроки берутся в приказ из «1. Карточки проекта» «Органайзера».

Предварительный анализ

ВРГ приступает к анализу кросс-функционального бизнес-процесса. Прежде всего, необходимо выполнить анализ документов по процессу: регламентов, положений, инструкций и рабочих документов. Это важно для получения первичной информации о процессе. Кроме того, многие руководители в начале проведения интервью спрашивают, ознакомились ли участники ВРГ с документами по процессу, – нужно быть готовыми, владеть информацией.

Как правило, извлечь всю необходимую информацию из документов невозможно. Поэтому участники рабочей группы проводят интервью с руководителями и специалистами – исполнителями процесса, а также с внутренними поставщиками и потребителями. Количество интервью, которые нужно провести, зависит от сложности процесса и наличия ресурса времени у ВРГ. Результаты проведения интервью фиксируются в виде кратких протоколов, доступных всем участникам ВРГ. Нет необходимости делать дословную расшифровку. Важно зафиксировать содержательно факты и мнения участников. Руководитель ВРГ ведет архив проекта в специально отведенной для этого папке на сервере компании.