В статье Андрея Манюхина приводятся примеры визуализации процессных моделей как в общепризнанных нотациях в среде  Business Studio, так и в свободных нотациях. Разбираются плюсы и минусы, условия применения тех или иных способов визуализации процессных моделей.  Статья адресована как бизнес-аналитикам, так и менеджерам, которые интересуются процессным управлением.

Введение

Современные условия характеризуются слабым представлением бизнес-заказчиков о профессиональных стандартах для специалистов в области описания и оптимизации бизнес-процессов. В этой связи хочется напомнить о существовании такого стандарта (https://abpmp.org.ru/resource/profstandard/). Много «около-процессных» специалистов заявляют об оптимизации бизнес-процессов: в последнее время набирают популярность, так называемые, «подразделения операционных улучшений», которые обычно занимаются точечными фрагментарными улучшениями на уровне операций, но преподносят это как бизнес-процессы. В результате, бизнес-заказчик теряется в многообразии методов, часто разочаровывается, появляется предвзятое негативное отношение к описанию и оптимизации бизнес-процессов, в их настоящем понимании.

Команда консультантов BPM3.RU имеет обширную практику построения процессных архитектур и в данной статье автор делает попытку систематизировать подходы и предоставить читателю наиболее оптимальные для каждой конкретной ситуации.

Правильный подход, ставший классикой

Рассмотрим построение процессной архитектуры на примере процессной модели закупок для операционной деятельности. Данная модель создана мной на основе практик российских и зарубежных производственных компаний в учебных целях. Модель создана с точки зрения директора по закупкам. На рис.1 представлена контекстная диаграмма (А-0).

Понимая окружение (контекст) процесса операционных закупок, декомпозируем процесс на 6 процессных категорий (групп процессов), как показано на рис.2.

Часто приходится слышать такое мнение, что процессная архитектура – вещь умозрительная и не существует никаких критериев группировки процессов в категории, и, вообще, архитектура не нужна и можно просто описывать процессы нижнего уровня. Хотел бы поделиться критериями группировки процессов. По результатам своего опыта я выделяю два основных критерия группировки процессов:

• Единый владелец группы процессов,
• Единый результат (выход) группы процессов.

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

Процессная модель операционных закупок в виде реестра представлена на рис. 3.

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

В реестре расписаны варианты проведения аварийной закупки, их восемь, далее я указал количество вариантов по каждому типу закупочной процедуры. В итоге, по закупке товаров получается 44 сценария, плюс – столько же по услугам. Итого, получается 88 (!) сценариев и, соответственно, процессов. Очевидно, что ряд подпроцессов будет дублирован n количество раз. Хорошо, что я семантически верно обозначил эти процессы, на практике бывает, что так чётко названия не обозначают, и появляется сотня процессов, найти нужный из которых можно только путём последовательного перебора… Такие решения часто понятны только их создателям. А бизнес-заказчик всегда одной из важных целей ставит порядок и прозрачность процессов и зон ответственности…

Конечно же, для связи процессов существуют методы отражения в виде межпроцессных взаимодействий в виде свёрнутых пулов и стрелок типа message flow. Но, опять же, чтобы эти взаимодействия увидеть, необходимо последовательно открывать все процессы. Часто бывает нужно показать наиболее важные сценарии и сделать это можно при помощи процессов-ссылок, как показано на рис. 5. На примере закупки стандартных товаров у единственного поставщика по импорту.

Тот же самый процесс с помощью ссылок можно сделать в нотации BPMN, как показано на рис.6.

В реестре обычно для таких процессов завожу папку «Типовые цепочки процессов (on-demand chains of models)», как показано на рис.7.

Таким образом, типовые процессы (сценарии) являют собой третье измерение процессной модели не нарушая, при этом, логики процессной архитектуры.

Несомненными плюсами такого подхода являются: 1) возможность представления архитектуры процессов, сгруппированной в логике цепочки создания ценности с отражением владельцев групп процессов, 2) возможность представления архитектуры процессов в виде сценариев, последовательности запуска тех или иных процессов. Оба представления, как показывает практика, востребованы бизнес-заказчиками.

Свободные нотации для презентационных целей

Часто аудитория слабо ориентируется в нотациях. Более того, менеджменту обычно нравятся простые красочные картинки. Ту же самую модель закупок можно изобразить вот в таком виде, как показано на рис.8.

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

Сценарий закупки у единственного поставщика представлен на рис.9.

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

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

Выводы

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

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

В презентационных целях бывает полезно для общего понимания отойти от нотации, «оживить» картинку, но, — не более того. Далее необходима кропотливая работа по описанию и оптимизации процессов.

А.Е. Манюхин,

МВА, консультант по управлению

Май 2023 г.

www.bpm3.ru

В статье Владимира Репина приводятся примеры моделей бизнес-процессов «As is» («Как есть»), «To be Medium» («Как должно быть, переходная»), «To be Max» («Как должно быть, целевая») в нотации BPMN в Business Studio. Представленный методический подход к описанию процессов позволяет визуально увидеть переход от существующей ситуации к перспективной. Это важно для собственников и руководителей организации для решения задачи обоснования изменений и планирования автоматизации и цифровизации бизнес-процессов организации.  

Введение

Описание бизнес-процессов «As is» («Как есть») является отправной точкой для оптимизации и автоматизации бизнес-процессов организации.

Важно отметить, что эту работу нужно делать с точки зрения бизнес-заказчика, а не программиста. Процесс должен быть описан целиком со всеми его нюансами, а не только действия, выполняемые сотрудниками, например, в 1C-ERP или СЭД. Ограниченная точка зрения на процесс может привести к тому, что не будут выявлены значимые проблемы и выработаны адекватные решения по его изменению.

Для решения указанной задачи должен использоваться адекватный метод, позволяющий четко определять на схемах процессов:

• границы процессов и зоны ответственности сотрудников;
• интеграцию – взаимодействие процессов между собой (прямое и/или через данные);
• сроки выполнения задач;
• возможные риски;
• возникающие потери;
• потенциал автоматизации и цифровизации.

Команда консультантов BPM3.RU выработала свой методический подход к разработке моделей в нотации BPMN в Business Studio. BPMN используется  как единый язык, понятный всем заинтересованным сторонам в организации.

Ознакомиться в нашим подходом можно в статьях «Моделирование информационных потоков в нотации BPMN в Business Studio 5» и «Методы визуального анализа графической схемы бизнес-процесса в нотации BPMN».

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

Примеры моделей бизнес-процессов в нотации BPMN в Business Studio

На рис. 1 представлена модель бизнес-процесса заключения договора с клиентом «Как есть». Ключевые особенности этого процесса:

• много ручной работы;
• дезинтеграция по информационным системам (ручной перенос информации из одной системы в другую);
• отсутствие четкого бизнес-правила по отправке проекта договора клиенту (что сначала: проверка у юриста или отправка документа клиенту).

Видно, что процесс выполняется с использованием MS Outlook и вручную.

Одним из подпроцессов является процесс «Согласование договора с клиентом». Он является типовым (повторно выполняемым). Модель «Как есть» этого процесса представлена на рис. 2. Процесс практически весь «ручной». По ходу его выполнения от задачи к задаче передается бумажный комплект документов.

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

Далее рабочая группа из специалистов продаж, юристов и консультантов команды BPM3.RU разработала несколько моделей нового процесса. Модель «To be Medium» (переходная) представлена на рис. 3.

Новый процесс целиком выполняется в информационной системе: 1C-ДО или BPMS. На схеме представлены комментарии, отражающие ключевые нюансы процесса.

Данная схема была использована в качестве Технического задания для подготовки прототипа исполняемого бизнес-процесса на платформе Elma-365.

Если сравнить рисунки 2 и 3, то изменения процесса очевидны. Руководители и специалисты, обученные нотации BPMN, сразу видят различия. Схема является удобным инструментом формирования ТЗ на автоматизацию – можно обойтись без длинного текстового описания требований, особенно в случае автоматизации процесса с использованием No-code/Low-code системы.

На рис. 4 показана модель бизнес-процесса «Согласование договора с клиентом» в версии «To be Max».

Особенностями модели «To be Max» (перспектива на 1,5-2 года) являются:

• использование Личного кабинета клиента для автоматического взаимодействия с организацией;
• полная автоматизация ряда задач в 1C-ERP;
• использование RPA-модуля (возможно, нейронной сети) для распознавания и сравнения версий договоров, получения/отправки договоров через «Контур.Диадок» и проч.

Интересно отметить, что после создания этой модели стало очевидно, что дорожку «Менеджер по работе с клиентами» можно полностью исключить из процесса – все задачи могут быть выполнены автоматически. Это означает, что сотрудники, находящиеся на рассматриваемой должности, смогут потратить сэкономленное  время на привлечение новых клиентов, что положительно скажется на выручке компании.

Если сравнить схемы рис. 1 и рис 4, то различия видны явно. Это важно для наглядного представления возможных изменений руководителям и специалистам организации.

Сравнение моделей «As is», «To be Medium», «To be Max»: свет в окне

В таблице 1 приводится содержательное сравнение моделей «As is», «To be Medium», «To be Max», которое показывает, как изменяются бизнес-процессы при их трансформации из текущего состояния в перспективное.

Таблица 1.

Выводы

Моделирование бизнес-процессов от «As is» к «To be Medium» и «To be Max» в нотации BPMN в Business Studio дает руководителям компании такие преимущества, как:

• наглядное представление и понимание пути перехода от текущего к целевому состоянию;
• оценка возможной цены «светлого цифрового будущего» (трудоемкость и стоимость проектов автоматизации и цифровизации);
• понимание возможности устранения узкого места в лице ИТ-подразделения компании путем передачи значительного объема работ по автоматизации процессов с использованием технологии No-code/Low-code в Процессный офис;
• понимание приоритета цифровой трансформации;
• радикальное сокращение сроков, повышение производительности процессов, «прозрачность» всей системы работы организации для собственников и топ-менеджмента.

Один из главных эффектов от описания процессов «As is», «To be Medium», «To be Max», во многом, психологический. Руководители смотрят на схемы и говорят: «А что, так можно будет?». Они видят, насколько изменится бизнес-процесс, станет меньше ручной, бумажной работы, возрастет скорость выполнения процессов, повысится эффективность.

Удачи в оптимизации и цифровой трансформации ваших бизнес-процессов!

В.В. Репин,

к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Май 2023 г.

www.bpm3.ru

Введение. Что такое СУБП?

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

В рамках этих систем исполняются соответствующие бизнес-процессы. Для того, чтобы ими эффективно управлять и целенаправленно развивать, нужна еще одна система – Система управления бизнес-процессами — СУБП. Приведем ее рабочее определение:

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

Можно сказать по-другому. Наличие СУБП означает, что в организации внедрена системная практика работы с бизнес-процессами.

Как понять, есть ли в вашей компании такая система и оценить ее текущий уровень развития? Есть довольно много различных методик оценки. Я предлагаю оценивать СУБП по десяти основным направлениям.

Структура СУБП компании и оценка уровня ее зрелости

Кратко опишу разделы, по которым может проводиться оценка уровня зрелости СУБП[1]:

Таблица 1. Структура СУБП.

На рис. 1 показан пример оценки уровня зрелости СУБП некоторой организации. Видно, что в 2022 году оценка была весьма невысокая. На 2023 года руководство компании запланировало существенное развитие системы, например разработку архитектуры бизнес-процессов, развитие практики описания, анализа и внедрения изменений и проч.

Роль СУБП в развитии бизнеса

Собственникам и руководителям важно понимать роль СУБП в развитии компании. На рис. 2 показано текущее состояние бизнеса и перспективное состояние, характеризующееся кратным ростом масштабов.

Как перейти от текущего состояния к перспективному? Необходимо стратегическое видение возможностей: новые, инновационные продукты и сервисы, перспективные сегменты рынка, изменения в бизнес-модели, поддержка государства, источники финансирования для активного развития и т.д.

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

Какова же роль СУБП в трансформации, развитии бизнеса? Система помогает достигать целей бизнеса при сохранении/улучшении его управляемости и снижении операционных рисков. Дает возможность целенаправленно развивать процессы, сокращая время их выполнения, снижая затраты и устраняя потери, переходить на новые модели работы с клиентами, особенно в части цифровизации. 

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

Проект внедрения СУБП: видение и цели

С учетом приведенных выше соображений, ключевые цели проекта внедрения СУБП можно определить следующим образом:

1. Создать систему работы с бизнес-процессами.
2. Достичь целей развития бизнеса с минимальными затратами ресурсов и минимальными рисками.

Созданная в рамках проекта Система работы с бизнес-процессами даст возможность:

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

Для формализации видения и целей внедрения СУБП целесообразно разработать документ типа политики, например, под названием «Концепция внедрения СУБП в … компании». В этом документе нужно зафиксировать ключевые термины, принципы, видение структуры СУБП, описать органы управления с их функциями, полномочиями и ответственностью: Процессный комитет, Процессный офис, Процессный архитектор и другие. Данный документ в некоторых компаниях называют «Стандарт внедрения процессного управления»…. В любом случае, руководителям нужно договориться между собой, что они понимают под СУБП, согласовать видение и цели создания системы работы с бизнес-процессами.

Во время или перед формализацией видения СУБП руководителям полезно ознакомиться с опытом других компаний, провести бенчмаркинг. Найти партнеров для бенчмаркинга можно на сайте https://bpmaward.ru – там размещается информация (доклады, видео) о компаниях-финалистах конкурса «BPM-проект года», который проводит Ассоциация профессионалов управления бизнес-процессами (ABPMP Russian Chapter), https://abpmp.org.ru.

Ролевая структура проекта внедрения СУБП

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

Таблица. 2. Ролевая структура проекта

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

Основные этапы проекта внедрения СУБП

Типовой проект внедрения СУБП включает следующие группы работ (этапы):

0. Определение видения и целей внедрения СУБП.

1. Организация деятельности Процессного офиса.

2. Разработка методик СУБП.

3. Внедрение Business Studio.

4. Проектирование архитектуры бизнес-процессов (IDEF0).

5. Описание и анализ бизнес-процессов «Как есть» (BPMN).

6. Описание бизнес-процессов «Как должно быть» (BPMN).

7. Оптимизация и регламентация бизнес-процессов.

8. Разработка системы обучения и аттестации персонала.

9. Проведение внутренних аудитов.

10. Проведение оценки зрелости СУБП.

11. Планирование развития СУБП и бизнес-процессов компании на 20__ год.

На рис. 3 показан График Ганта такого проекта. Нужно отметить, что на сроки выполнения проекта сильно влияют такие факторы, как: 1) размер компании; 2) сложность ее бизнес-процессов; 3) количество и качество выделенных ресурсов; 4) доступный ресурс времени руководителей и их вовлеченность в проект.

Этап 0 «Определение видения и целей внедрения СУБП» может довольно долго, например, 2-3 месяца (на рис. 3 – меньше). Руководителям компании нужно разработать и согласовать видение и цели внедрения. В этом могут помочь учебно-практические сессии, на которых внешний эксперт расскажет о целях внедрения, методах и инструментах СУБП, возможных этапах проекта, роли руководителей, рисках и проч.

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

Этап 2 включает разработку ключевых методик СУБП. Должны быть созданы: 

1. Глоссарий СУБП.
2. Концепция СУБП («Стандарт внедрения СУБП» или «Стандарт внедрения процессного управления»).
3. «Соглашение по моделированию бизнес-процессов» (нотации IDEF0 и BPMN).
4. Регламент моделирования и анализа бизнес-процесса.
5. Регламент выполнения проекта оптимизации сквозного бизнес-процесса.
6. Методика разработки целей и показателей для управления процессами.
7. Методика выбора процессов для оптимизации.
8. Стандарт управления ВНМД, включая формы регламентов (на платформе Business Studio)
9. Регламент автоматизации процесса (в BPMS).
10. Методика оценки зрелости СУБП.
11. Прочие.

Для ускорения разработки примеры методик и регламентов могут быть получены (на различных условиях) от внешнего эксперта (консультанта) и адаптированы к условиям компании (холдинг, гос. структура и т.п.).  Ключевыми документами в начале Этапа 2 являются Глоссарий и «Соглашение по моделированию бизнес-процессов». Когда они готовы, можно приступать к Этапу 4.

Этап 3 – внедрение инструмента Business Studio. Он довольно длинный, так как после покупки и инсталляции системы нужно будет:

• создать пользователей и определить для них права доступа;
• настроить структуру системных справочников, в том числе ввести в базу орг.структуру компании;
• разработать шаблоны отчетов для автоматической выгрузки из Business Studio регламентов и других документов;
• настроить и сформировать html-публикацию (BS Portal);
• прочее.

Выполнение Этапа 4 «Проектирование архитектуры бизнес-процессов» может занять от 1 до 2,5 месяцев в зависимости от сложности структуры и бизнес-процессов компании. В Business Studio разрабатываются архитектурные модели бизнес-процессов в нотации IDEF0 на 1-3 уровнях (контекст, архитектура, модели категорий и групп). В зависимости от масштаба компании и сложности бизнес-процессов может потребоваться создать от 8-12 моделей (уровни 0, 1, 2) до 60-80 (уровень 3) в нотации IDEF0. На следующем уровне декомпозиции уже, как правило, используется нотация BPMN.

В рамках Этапа 5 «Описание и анализ бизнес-процессов «Как есть»» выполняется описание бизнес-процессов в нотации BPMN с фиксацией проблем и предложений по улучшению процессов, функциональных требований к информационным системам.  Важно отметить, что цель «описать все процессы» не ставится. Выбирается 1-2, максимум, 3 категории бизнес-процессов, которые являются наиболее важными для компании в текущем контексте. Например, это могут быть категории «Продажи», «Закупки» и «Логистика» или «R&D», «Управление ассортиментом и запасами» и т.п. Руководителям компании нужно определиться с выбором ключевых, наиболее важных для развития бизнеса категорий процессов и начинать детальное описание и анализ именно с них. То есть выбираются «пилотные» категории (группы) процессов, которые нужно оптимизировать в первую очередь.

Далее выполняется Этап 6 «Описание бизнес-процессов «Как должно быть»». Перед описанием бизнес-процессов «Как должно быть» целесообразно разработать Концепцию трансформации, которая может включать элементы новой бизнес-модели: изменения в организационной и ролевой структуре, новые/измененные методики и бизнес-правила, видение перспектив развития ИТ-архитектуры и возможности по цифровизации.  После этого запускается работа по созданию моделей бизнес-процессов «Как должно быть». Фиксируют предложения по оптимизации процессов, уточняются требования к информационным системам и прочее.

На Этапе 7 «Оптимизация и регламентация бизнес-процессов» инициируются проекты (мероприятия) по оптимизации. После внедрения изменений и подтверждения эффекта, для измененных бизнес-процессов формируются регламентирующие документы. Business Studio помогает автоматизировать этот процесс: на основе разработанных моделей процессов и специально спроектированных шаблонов, регламенты выгружаются из Business Studio автоматически.

Если позволяет ресурс, то Этап 8 «Разработка системы обучения и аттестации персонала» запускается одновременно с описанием бизнес-процессов «Как есть». Разрабатывается модель компетенций в области процессного управления, создаются учебные курсы (в т.ч. дистанционные), вопросы для аттестации и проч.

Ближе к концу года, при наличии внедренных регламентов выполнения бизнес-процессов, выполняется Этап 9 «Проведение внутренних аудитов». Далее аудиты бизнес-процессов проводятся регулярно в соответствии с Программой аудитов.

Этап 10 «Проведение оценки зрелости СУБП» выполняется с использованием соответствующей методики в конце года (начало декабря). Его результатом является Отчет по оценке уровня зрелости СУБП. Для получения объективной картины оценка может проводиться внешними экспертами.

Результаты оценки уровня зрелости СУБП используются при выполнении Этапа 11 «Планирование развития СУБП и бизнес-процессов компании на 202_ год», в рамках которого обсуждаются полученные результаты, разрабатывается и утверждается План развития СУБП на следующий год.

На рис. 3 видно, что с момента завершения Этапа 7 «Оптимизация и регламентация бизнес-процессов» СУБП организации начинается работать в постоянном, штатном режиме. Выбираются следующие категории (группы) бизнес-процессов для анализа и оптимизации и проч.

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

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

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

Процессный офис

Ключевую роль в проекте внедрения СУБП играет Процессный офис. С учетом опыта организации деятельности таких подразделений во многих компаниях, я могу выделить следующие ключевые функции Процессного офиса:

1. Управление функционированием и развитием СУБП Компании.
2. Развитие Методологии управления бизнес-процессами в Компании.
3. Управление архитектурой бизнес-процессов Компании.
4. Описание и анализ бизнес-процессов Компании.
5. Планирование и внедрение изменений в процессах.
6. Регламентация и стандартизация процессов.
7. Автоматизация (роботизация) бизнес-процессов (совместно с ИТ-подразделениями Компании).
8. Поддержка базы знаний по бизнес-процессам.
9. Развитие процессных компетенций (совместно с Департаментом по персоналу Компании).
10. Проведение внутреннего аудита бизнес-процессов Компании.
11. Управление подачей предложений сотрудников по улучшению бизнес-процессов.
12. Разработка и внедрение системы целей и показателей для управления бизнес-процессами (в т.ч. KPI).

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

Кроме того, Процессный офис может использовать, например, ПО Jira для управления задачами и проектами, а также BPMS (Elma, Comindeware и другие) для их автоматизации.

В своей работе Процессный офис может использовать несколько различных планов. В первую очередь, это План развития СУБП компании. Он формируется один раз в год после проведения оценки уровня зрелости СУБП, которая помогает выявить проблемы и наметить пути совершенствования СУБП в следующем году. Далее план может уточняться/корректироваться ежеквартально в зависимости от достигнутых результатов.

Следующий важный и основной документ – это План/отчет Процессного офиса. В него включаются следующие задачи:

1. описание и анализ бизнес-процессов «Как есть»;
2. разработка мероприятий по оптимизации бизнес-процессов, в том числе проектирование бизнес-процессов «Как должно быть» (промежуточный и перспективный варианты);
3. разработка/актуализация регламентов и других внутренних нормативно-методических документов (ВНМД);
4. отмена ВНМД;
5. автоматизация бизнес-процессов в BPMS;
6. проведение обучения и аттестации сотрудников (в области процессного управления);
7. другие задачи.

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

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

Для моделей в нотации BPMN можно привести следующее определение:

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

Нормативное время создания модели в нотации BPMN для одного нормо-процесса «Как есть» может быть определено в пределах от 4 до 8 часов работы бизнес-аналитика. В этот время входят:

• подготовка к проведению моделирующей сессии (МС), в том числе анализ регламентирующих и рабочих документов по процессу;
• организация проведения МС;
• проведение МС длительностью около 1,5-2 часов;
• доработка модели бизнес-процесса после проведения МС и отправка на согласование участникам МС и заинтересованным руководителям;
• внесение изменений в модель процесса по результатам согласования.

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

Кроме норматива для описания одного нормо-процесса могут быть определены еще нормативы для разработки и актуализации регламента, контроля качества проекта регламента и некоторые другие.

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

Вовлечение руководителей и специалистов

Одним из ключевых факторов успеха проекта внедрения СУБП является вовлечение руководителей и специалистов в «процессную работу».  К числу эффективных методов вовлечения можно отнести:

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

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

Риски проекта внедрения СУБП и компенсационные мероприятия

Проект внедрения СУБП, как части новой системы управления организацией, подвержен вполне типовым рискам, к числу которых можно отнести:

• неясное видение целей и целевого состояния и роли СУБП;
• отсутствие общего понимания целей у разных групп заинтересованных сторон;
• отсутствие у руководителей знаний и опыта в области процессного управления;
• отсутствие навыков процессного лидерства (процессное мышление, понимание технологий процессного управления, открытость, сотрудничество);
• недостаточная вовлеченность и мотивация сотрудников;
• сопротивление сотрудников изменениям.

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

Таблица 3. Риски проекта внедрения СУБП и компенсационные мероприятия

Чтобы избежать указанных выше рисков нужно, в первую очередь, сформулировать видение и цели внедрения СУБП в документе «Концепция внедрения…». Далее необходимо понять, какие бизнес-процессы для компании являются ключевыми в текущем контексте и зачем их нужно трансформировать. Проект внедрения СУБП должен помочь решить ключевые проблемы бизнеса (Business Challenge). Кроме этого, нужно выделить на проект адекватные ресурсы и привлечь экспертов (в штат или в качестве внешних консультантов) – носителей методологии и опыта внедрения в других компаниях.

Выводы

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

Проект внедрения СУБП вполне реально выполнить за 8-10 месяцев. К этому сроку будут созданы основы системной практики управления бизнес-процессами, которую потом нужно будет развивать и совершенствовать.

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

Удачи во внедрении Системы управления  бизнес-процессами на платформе Business Studio!

В.В. Репин,

к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Март 2023 г.

www.bpm3.ru

[1] В рамках авторской Методики Владимира Репина.

[2] BI — Business Intelligence.

[3] OKR — Objectives and Key Results, «цели и ключевые результаты».

[4] Моделирующая сессия (МС) – специальный тип совещания, которое проводится по определенной методике с целью описания и анализа бизнес-процесса.

[5] BPMS – Business Process Management System.

[6] СЭД – Система электронного документооборота.

[7] КиПД – Корректирующие и предупреждающие действия.

[8] Нормо-процесс – схема в нотации BPMN, содержащая до 12 задач, шлюзы, документы, ресурсы и информационные системы. Авторское определение Владимира Репина.

[9] ИПР – Индивидуальный план развития.

В статье Владимира Репина раскрываются методы визуального анализа графической схемы бизнес-процесса в нотации BPMN в Business Studio 5. Они могут быть использованы для выявления проблем, связанных с выполнением процесса, и разработки мероприятий по его оптимизации. Материал может быть полезен руководителям и специалистам, вовлеченным в проект описания и оптимизации бизнес-процессов компании.

Введение

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

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

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

Требования к графической схеме бизнес-процесса

Прежде всего определимся с контекстом, точкой зрения и целью анализа.

Контекст – в компании создан Процессный офис, который использует программный продукт Business Studio для моделирования и анализа бизнес-процессов в нотации BPMN. Разработан и используется внутренний стандарт по описанию процессов («Соглашение по моделированию»).

Точка зрения – взгляд на выполняемую деятельность со стороны владельца бизнес-процесса.

Цель – выполнить описание и анализ бизнес-процесса «Как есть» для выявления возникающих проблем и разработки мероприятий по оптимизации/цифровизации бизнес-процесса, создания модели процесса «Как должно быть».

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

Можно сформулировать четыре группы критериев, которым должна удовлетворять графическая схема в нотации BPMN, которую предполагается использовать для анализа проблем:

1. Отсутствие нотационных и логических ошибок.
2. Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем.
3. Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика).
4. Визуальная наглядность и красота схемы (стиль).

Кратко пройдемся по этим критериям. Отсутствие нотационных и логических ошибок является базовым требованием. Схема, содержащая ошибки, тем более, логические, — непригодна для анализа. Для формального контроля качества схемы можно использовать чек-лист, который может содержать, например, следующие разделы:
• корректность формулировок названий объектов на схеме;
• корректность описания входов/выходов;
• корректность описания событий (стартовых, промежуточных, завершающих);
• логические ошибки;
• адекватное описание множества обрабатываемых в рамках процесса объектов;
• архитектурные ошибки (дублирование группы задач вместо использования «Типового процесса» и проч.);
• неоднородность по масштабу выполняемых задач;
• аккуратность исполнения схемы, наглядность.

Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем является ключевым для возможности выполнять анализ. Подробно о создании таких схем я написал в статье «Моделирование информационных потоков в нотации BPMN в Business Studio 5». Рекомендую обратить внимание на представленные там требования.

Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика). Речь идет о том, что модель действительно соответствует процессу «Как есть», то есть содержит все реально выполняемые задачи без пропусков, упрощений и т.п.

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

Адекватная реальности семантика. Нотация BPMN является весьма сложной. Важно понимать, что она была разработана для проектирования исполняемых в BPM-системе процессов. Движок такой BPM-системы, если объяснять не уходят в технические детали, интерпретирует значки нотации BPMN определенным образом и генерирует исполняемый код без участия человека. При исполнении бизнес-процесса в BPM-системе семантика графической схемы реализуется через соответствующий функционал. Например, могут быть использованы такие решения, как: межпроцессное взаимодействие путем отправки/получения сообщений, граничные события различного типа, завершение процесса типа «Terminate», триггеры, сигналы, компенсации и прочее.

Но в реальном, неавтоматизированном бизнес-процессе (типичный пример: Outlook + функциональная система) ничего этого нет – передача информации, остановки, уведомления осуществляются вручную сотрудниками. Поэтому схема бизнес-процесса «Как есть», созданная бизнес-аналитиком с использованием сложной семантики BPMN, реализуемой только в BPM-системе, в действительности не соответствует реально выполняемому процессу. При чтении такой схемы совершенно непонятно, как выполняется процесс в действительности.

Некоторые бизнес-аналитики, «нахватавшись» красивых значков BPMN, начинают «лепить» их где и как попало, глубоко не анализируя процесс и не прописывая нюансы его практического выполнения.
Поэтому для описания неавтоматизированного бизнес-процесса «Как есть» настоятельно рекомендую использовать только самые простые конструкции нотации BPMN. Кроме того, важно подробно описать допустимые в моделях «Как есть» интерпретации значков BPMN в «Соглашении по моделированию».

Если цель – создание модели бизнес-процесса для исполнения в конкретной BPMS, то создавать эту модель «Как должно быть» нужно понимая, какой конкретно функционал имеет система, то есть какие возможности нотации BPMN она поддерживает.

Визуальная наглядность и красота схемы (стиль). Схемы могут сложными, но понятными, а могут быть содержательно простыми, но до крайности визуально запутанными (см. пример на рис. 2).
Например, в одной компании, в которой я проводил анализ качества схем в нотации BPMN, было жесткое требование размещать модели на листе формата А4. Это приводило к тому, что бизнес-аналитики делали на схеме «Змейку» и она становилась крайне сложной для восприятия. Это можно назвать плохим стилем моделирования.

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

Какие проблемы можно выявить, анализируя схему бизнес-процесса?

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

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

Ниже рассмотрим каждую из указанных видов проблем.

Технология выполнения бизнес-процесса

Пример. Коллеги из довольной крупной компании разработали схему процесса «Создание, согласование и закрытие заявки на подбор» — см. рис. 3.

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

Кроме того, процесс «Подбор персонала» включен в рассматриваемый процесс, как типовой. На мой взгляд, это несколько некорректно с точки зрения архитектуры бизнес-процессов HR в целом.

Анализ схемы может показать, например, что результат процесса не передается его инициатору, то есть «зависает». Инициатор вынужден сам как-то его добывать. Это означает, что границы процесса определены некорректно.

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

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

Еще один пример отсутствия бизнес-правила представлен на рис. 5. Менеджеры работают с заказчиками по-разному. Ряд заказчиков подписывает договор и присылает его скан, ряд – нет. Четко не определено, должны ли менеджеры требовать от заказчиков присылать подписанные сканы договоров или достаточно версии в формате MS Word и протокола разногласий и т.д.

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

Дезинтеграция процесса по информационным системам

На том же рис. 6 видно, что бизнес-процесс не интегрирован по информационным системам – наблюдается ручная передача информации в Outlook, ручная выгрузка из АСУ в MS Excel, потом в MS Word, сохранение в pdf-формат, звонки и e-mail-ы клиентам.

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

Потеря важной информации (документов) при выполнении процесса

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

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

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

Отсутствие необходимой интеграции между процессами

На рис. 7 показан фрагмент бизнес-процесса приемки товара на склад гипермаркета торговой сети. В случае, если количество мест больше, чем указано в накладной, кладовщик «уведомляет менеджера по закупу» по яндекс-почте.

Но менеджер по закупку может: 1) случайно удалить письмо; 2) увидеть письмо со значительной задержкой; 3) отложить работу с поставщиков «на потом» без контроля сроков. Таким образом, проблема, возникшая в одном бизнес-процессе и нуждающаяся в решении, не связана с запуском на исполнение другого процесса. Кроме того, информации о проблеме не зафиксирована в системе и может быть потеряна.
Представленный выше пример весьма типичный. Очень часто можно увидеть на схемах ситуацию типа: «Уведомить менеджера…», «Переслать информацию в такой-то отдел» и т.п.

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

Возвраты, излишние согласования

При выполнении бизнес-процессов часто возникают возвраты. Например, на рис. 8 показан возврат на повторное согласование договора.

Чем плохи возвраты? Они: 1) многократно увеличивают длительность выполнения процесса; 2) увеличивают затраты; 3) могут негативно влиять на качество результата процесса; 4) негативно сказываются на отношении сотрудников к работе (бесконечные переделки и уточнения, повторное выполнение одних и тех же задач мало кому понравится).

В свое время Филипп Кросби, известный специалист в области менеджмента качества, сформулировал принцип «Делать всё правильно с первого раза». Почему же сотрудникам сложно его придерживаться? В чем причины возвратов? Думаю, в следующем. К ним приводят:
• нечетко поставленные задачи;
• недостаток информации у исполнителя;
• некачественные входы (информация);
• отсутствие методик/бизнес-правил у исполнителя;
• недостаточная квалификация исполнителя;
• ошибки («человеческий фактор»).

Исполнитель получил задачу и выполнил ее. Но оказалось, что руководитель имел в виду немного другое. Приходится переделывать.

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

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

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

Не стоит исключать и человеческий фактор: физическая усталость, моральное утомление (например, в случае выполнения рутинной, монотонной работы по разнесению УПД из «Контур.Диадок» в 1C-ERP при крайне медлительной работе программы), негативное отношение к выполняемой работе и, в целом, — к компании, отсутствие лояльности и т.д.

Но в чем коренные причины указанных выше проблем? Кто виноват? Сами сотрудники? Нет. Еще дедушка Эдвардс Деминг, специалист мирового масштаба и отец новой философии управления, говорил, что 95% проблем, возникающих у сотрудников при выполнении процессов, обусловлены не плохим отношением людей к работе, а теми бизнес-процессами, системой, которую создали сами менеджеры компании.

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

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

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

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

Узкие места

Еще одной проблемой, которую можно выявить путем визуального анализа схемы, являются узкие места в процессе. Они могут быть видны визуально, но чаще выявляются содержательно в том случае, если ресурс исполнителя ограничен, например: договора создают многие менеджеры, но в 1С-КА вводит данные только один сотрудник. Выполняемая им задача и он сам становятся узким местом.

На рис. 10 показ пример кадрового процесса одной из крупных компаний. По нему движется документ, который дополняют и согласуют множество руководителей. Несмотря на то, что процесс автоматизирован в СЭД, в нем возникло узкое место, обведенное овалом. Специалист подразделения кадров осуществляет ручной контроль после каждой задачи согласования и «проталкивание» процесса между его участниками.
Хотя все участники процесса используют СЭД, назвать этот процесс автоматизированным, а тем более цифровым, нельзя. Автоматизация, предполагающая постоянный ручной контроль и «проталкивание» документов, является неэффективной.

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

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

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

Задачи, не добавляющие ценность, потери

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

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

Выводы

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

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

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Февраль 2023 г.

Вы можете посмотреть видео по данной теме:

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

Цели создания Фреймворка

Вашему вниманию предлагается Фреймворк Системы стандартизации бизнес-процессов компании. В 2015 году я издал книгу «Бизнес по правилам: регламенты должны работать». Она и сейчас продается в издательстве «Инфра-М». В рамках данной книги была предложена архитектура Системы стандартизации бизнес-процессов и разработана методика оценки зрелости такой системы. Информация, представленная в книге, продолжает, на мой взгляд, оставаться достаточно актуальной и полезной. Тем не менее, настало время несколько обновить процессный Фреймворк. C одной стороны, целесообразно было упростить некоторые процессы, с другой – сделать модели процессов в нотации BPMN в большей степени ориентированными на автоматизацию. В данной статье представлен результат переработки Фреймворка с учетом указанных аспектов.

Общая модель Системы стандартизации бизнес-процессов (ССБП)

На рис. 1 представлена общая модель (Фреймворк) Системы стандартизации бизнес-процессов (ССБП) компании.

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

Процесс «Контроль исполнения ВНМД руководителями» можно было бы показать как типовой в другой части архитектуры процессов организации. Но я принял решение представить его как часть системы стандартизации бизнес-процессов, поскольку это очень важно с содержательной точки зрения – линейные руководители должны обязательно и регулярно контролировать исполнение требований регламентов.

Качественные модели процессов являются основой для регламентации. Деятельность по описанию и анализу бизнес-процессов вынесена за рамки рассматриваемого Фреймворка (будет подготовлена отдельная модель).

Принцип построения Фреймворка ССБП – жизненный цикл внутренних нормативно-методических документов компании (регламенты, положения, инструкции): от разработки и ввода в действие, до анализа использования и отмены ВНМД. Не нужно путать ВНМД с планово-отчетными и организационно-распорядительными документами. Для управления документами указанных типов нужны другие бизнес-процессы. Они не входят в рассматриваемый Фреймворк.

1. Управление регламентацией процессов

На рис. 2 представлена схема процесса «Управление регламентацией процессов». На ней представлен контур управления ССБП: ежегодный и ежемесячный.

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

На схеме процесса используется документ «План/отчет РАО ВНМД». Это сокращение. Полное название документа может, например, звучать так: «План/Отчет по разработке, актуализации, отмене и обучению по внутренним нормативно-методическим документам организации». Это рабочий документ Процессного офиса. В нем представлена информация о том, какие ВНМД нужно будет разработать, актуализировать, отменить и прочее.

План может создаваться на год по месяцам с последующей ежемесячной корректировкой. Форма плана – файл в MS Excel. Документ может включать в себя одновременно плановую и фактическую информацию.

Для корректной работы по планированию Процессному офису нужны соответствующие нормативы. Например, работа по созданию одноуровневого регламента бизнес-процесса на основе уже готовой и согласованной графической схемы в нотации BPMN может занять от 8 до 32 часов в зависимости от структуры регламента (простая или сложная). Например, создание регламента, включающего схему, текстовое описание, цели и показатели, требования к ресурсам, описание действий в случае отклонений, риски, контрольные процедуры может занять 24-32 часа рабочего времени Бизнес-аналитика Процессного офиса (без учета времени сотрудников подразделений, принимающих в этом участие).

Если у вас есть возможность, то целесообразно автоматизировать планирование и отчетность в специализированной системе.

Ежеквартально, 25 декабря (это условная дата) Руководитель Процессного офиса проводит анализ исполнения Плана РАО. Кроме того, он обязательно использует такие документы, как: «Отчет по оценке использования ВНМД» и «Отчет по аттестации по ВНМД». Информация из этих документов необходима для определения бизнес-процессов, по которым срочно нужна актуализация, обучение, аттестация и другие мероприятия. Формируется План РАО на следующий год по месяцам.

Проект Плана рассматривается и утверждается на Процессном комитете. Если у вас нет Процессного комитета, то его роль могут играть Комитет по ИСМ, Совет директоров или просто ЕИО (Генеральный директор).

Далее ежемесячно, например, 20 числа каждого месяца, Бизнес-аналитик Процессного офиса выполняет анализ исполнения Плана РАО на месяц и готовит соответствующий Отчет.

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

В случае необходимости он выполняет корректировку Плана РАО. В этом случае проект Плана РАО с корректировками передается на рассмотрение и утверждение на Процессом комитете. Далее цикл продолжается.

2. Разработка/корректировка ВНМД

На рис. 3 представлена схема процесса «Разработка/корректировка ВНМД». Участники процесса показаны при помощи ролей: «Разработчик ВНМД», «Руководители, согласующие ВНМД», «Бизнес-аналитик».

Разработчик ВНМД приступает к разработке в соответствии с Планом. В зависимости от ситуации, могут использоваться следующие документы: 1) модель (модели) бизнес-процесса в нотации BPMN (согласованная); 2) текущая версия ВНМД; 3) предложения по корректировке/дополнению ВНМД, накопленные в базе знаний, в том числе – предложения сотрудников.

В рамках рассматриваемого Фреймворка формирование проекта ВНМД осуществляется в Business Studio путем заполнения необходимых атрибутов модели: текстового описания задач процесса, привязки целей и показателей, определения методов контроля, привязки форм рабочих документов и т.п. После подготовки проекта ВНМД, разработчик, в качестве самоконтроля, проверяет документ с использованием чек-листа. Если по ходу работы выясняется, что необходимо изменить схему процесса, инициируется процесс «Описание процесса в нотации BPMN».

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

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

Процесс согласования может быть разработан для компании в целом и использован на схеме в качестве типового (процесс-ссылка в Business Studio).

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

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

3. Ввод ВНМД в действие

На рис. 4 показана схема процесса «Ввод ВНМД в действие». Разработчик ВНМД запрашивает у Бизнес-аналитика код ВНМД. Бизнес-аналитик присваивает ВНМД код в соответствии с утвержденными правилами и вносит проект ВНМД в Реестр ВНМД.

Разработчик ВНМД готовит проект приказа о вводе ВНМД в действие и, в качестве приложения к нему, — План внедрения ВНМД.

Здесь нужно сделать небольшое отступление. Как вы думаете, когда руководитель ставит свою подпись «Утверждаю» на проекте регламента, это магическое действие? Любое магическое действие должно приводить к мгновенному исполнению задуманного (это – шутка). Когда новый ВНМД утверждается, означает ли это, что его требования начинают мгновенно и правильно выполнять сотрудники организации? Конечно, нет. Прежде всего, они должны узнать о том, что новый документ введен в действие. Затем ознакомиться с ним. Понять требования и научиться их исполнять. Это даже вопрос не одного дня, а целого переходного периода. Не говоря уже о том, что необходим контроль исполнения требований нового регламента со стороны руководителей. Именно поэтому внедрение ВНМД – это не только утверждение соответствующего документа, это – целый процесс, который должен быть запланирован и выполнен в организации. Для этого создается План внедрения ВНМД.

Этот документ может содержать следующую информацию: 1) перечень лиц для ознакомления с ВНМД; 2) план по обучения/инструктажу сотрудников по ВНМД; 3) контрольные действия на переходном этапе (кто, когда и как будет контролировать исполнение требований нового регламента); 4) создание «горячей линии» для ответа на вопросы сотрудников по новому документу; 5) сбор обратной связи (оценку) по новому ВНМД от руководителей и сотрудников и прочее.

Внутренние НДМ организации можно условно разбить на две большие группы: процессные (регламенты, инструкции) и структурные (положения, должностные и рабочие инструкции). За их внедрение отвечают различные руководители. За процессные – владельцы процессов. За структурные – руководители подразделений. Это разделение показано на рис. 4. Если у руководителей есть замечания, то проект приказа и план внедрения ВНМД могут быть скорректированы.

Если замечаний нет, то комплект документов передается на утверждение. Комплект включает: 1) согласованный проект ВНМД; 2) проект приказа в вводе ВНМД в действие; 3) План ввода ВНМД в действие.

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

Далее владелец процесса/руководитель подразделения организует выполнение плана внедрения ВНМД.

4. Размещение ВНМД в архиве, на портале и уведомление о статусе

На рис. 5 представлена схема процесса «Размещение ВНМД в архиве, на портале и уведомление о статусе». Выполняет процесс Бизнес-аналитик Процессного офиса.
На схеме показаны два стартовые события: «ВНМД утвержден» и «ВНМД отменен». Далее представлены два разных потока работы.

В случае, когда ВНМД утвержден, Бизнес-аналитик:

1. изменяет статус ВНМД в Реестре ВНМД;
2. сканирует ВНМД и помещает оригинал ВНМД в архив документов компании;
3. размещает ВНМД в базе Business Studio (публикация на портале BS Portal выполняется автоматически по расписанию);
4. выполняет рассылку уведомлений в вводе ВНМД в действие (например, по e-mail).

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

В случае, когда ВНМД отменен, Бизнес-аналитик:

1. изменяет статус ВНМД в Реестре ВНМД;
2. удаляет ВНМД из Business Studio;
3. помещает оригинал ВНМД в архив отмененных документов;
4. утилизирует оригинал ВНМД (при необходимости);
5. выполняет рассылку уведомлений об отмене ВНМД (например, по e-mail).

Особенностью рассматриваемого процесса является использование:
• Реестра ВНМД;
• внутреннего портала (базы знаний компании по бизнес-процессам);
• бумажного архива ВНМД.

Ответственность за ведение бумажного архива ВНМД может быть возложена на Процессный офис компании (на практике часто так и делают).

Уведомление сотрудников в вводе ВНМД в действие (или отмене) является весьма важной задачей. Этот процесс доведения информации должен быть четко проработан. В идеальном варианте, сотрудники должны подтверждать свое ознакомление с этой информацией.

Отмена ВНМД так же является важной для того, чтобы исключить использование сотрудниками устаревших версий документов, что ведет к рискам некорректных действий, потерь, неудовлетворенности внутренних и внешних потребителей и проч.

5. Выдача учтенных копий ВНМД

На рис. 6 показана схема процесса «Выдача учтенных копий ВНМД». В настоящее время одной из целей цифровизации компаний является снижение доли бумажных документов. Тем не менее, в некоторых случаях бумажные копии утвержденных ВНМД могут понадобиться в практической работе.

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

В случае, если ВНМД отменен, Бизнес-аналитик делает отметку об отмене ВНМД в Реестре и уведомляет сотрудников, использующих копии данного документа. Сотрудники обязаны изъять и утилизировать копии ВНМД (данная задача не включена в рассматриваемый процесс).

6. Контроль необходимости актуализации ВНМД

На рис. 7 представлена схема процесса «Контроль необходимости актуализации ВНМД». Как правило, ответственного за актуализацию ВНМД и плановую дату актуализации фиксируют в Реестре и/или в карточке ВНМД в Business Studio. Но наличие ответственного сотрудника и плановой даты совершенно не означает, что этот сотрудник инициирует процесс в установленный срок. Практика показывает, что таким сотрудникам весьма нужны напоминания и, так сказать, еще некоторые сопутствующие действия. Поэтому рассматриваемый процесс необходим в общей системе процессов ССБП компании.

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

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

Бизнес-аналитик фиксирует полученную информацию в Реестре для возможности последующего контроля. Если ответственный не ответил в течение 3-х рабочих дней, Бизнес-аналитик уведомляет соответствующего руководителя. Тот, в свою очередь, на ручном управлении предпринимает определенные действия. Далее процесс повторяется с задачи 3.

7. Отмена ВНМД

Следующий процесс Фреймворка (рис. 8) – это «Отмена ВНМД». В случае, если необходимо отменить ВНМД, Бизнес-аналитик подготавливает проект приказа об отмене действия ВНМД. Руководитель, утверждающий ВНМД, утверждает приказ. Бизнес-аналитик помещает приказ об от мене ВНМД на сервер.

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

8. Анализ использования ВНМД

На рис. 9 показана схема процесса «Анализ использования ВНМД». К сожалению, системно анализ использования ВНМД в компаниях, как правило, не ведется. Поэтому обратите на рассматриваемый процесс особенное внимание.

Один раз в полгода (или ежегодно) Бизнес-аналитик последовательно выполняет следующие задачи:

• проводит анкетирование сотрудников по ВНМД для выявления их актуальности и практической полезности;
• анализирует статистику использования ВНМД на внутреннем web-портале (сколько раз смотрели документы, как долго и т.п.);
• выполняет анализ результатов аудитов в части несоответствий по ВНМД;
• выполняет анализ предложений сотрудников по улучшениям ВНМД (поданных, внедренных).

После этого Бизнес-аналитик формирует Отчет по использованию ВНМД и предоставляет его руководителю Процессного офиса. После того, как Руководитель согласует Отчет, Бизнес-аналитик помещает его в базу знаний компании.

Отчет используется для планирования работы с ВНМД в рамках процесса «Управление регламентацией процессов».

9. Обучение и аттестация по ВНМД

На рис. 10 показана схема процесса «Обучение и аттестация по ВНМД». Обучение и аттестация сотрудников компании – это штатная функция подразделения по работе с персоналом (HR). Но в данном случае речь идет о довольно специфической аттестации – проверки знаний сотрудниками требований ВНМД. Готовить вопросы к аттестации и контролировать ее проведение должны специалисты, профессионально занимающиеся разработкой, контролем качества, вводом в действие и аудитом исполнения требований регламентов. Но это и есть сотрудники Процессного офиса – Бизнес-аналитики. Поэтому организацию и проведение аттестации на знание ВНМД должны, на мой взгляд, делать именно они.

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

Далее он готовит/корректирует вопросы для аттестации. Для этого используется Методика подготовки вопросов и действующие ВНМД.

Технически вопросы для аттестации могут быть занесены в соответствующие атрибуты процессов (и других объектов) в базе данных Business Studio.

Затем Бизнес-аналитик готовит формы для аттестации, например, на внутреннем портале компании или с использованием сервиса Яндекс-формы.

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

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

Информация по итогам аттестации предоставляется сотрудникам и руководителям подразделений
Бизнес-аналитик помещает результаты аттестации в архив (базу знаний). В случае, если необходимо дополнительное обучение, то Бизнес-аналитик ставит задачу разработчикам ВНМД на проведение обучения.

После проведения соответствующего обучения разработчики ВНМД уведомляют Бизнес-аналитика и руководителей подразделений о проведенном обучении.

10. Контроль исполнения ВНМД руководителями

Процесс «Контроль исполнения ВНМД руководителями» представлен на рис. 11. Как я говорил выше, это типовой процесс, который должен регулярно выполнять каждый руководитель организации в зоне своей ответственности.
Процесс запускается периодически – еженедельно, раз в 2 недели (для простоты на схеме показан старт неопределенного типа). Руководитель определяет дату и время контроля исполнения требований. Важно, что сотрудники об этом не уведомляются.

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

По итогам проведения контроля его результаты (факт, причины, предложения) фиксируются в журнале контроля ВНМД (в электронном виде).

Далее, при необходимости, руководитель принимает решения и проводит работу с сотрудниками, допустившими нарушения требований регламентов.

На рис. 12 представлена схема, показывающая отличия между двумя типами контрольных процедур, которые можно использовать в процессе:

1. контроль, встроенный в процесс;
2. контроль «над процессом». Контроль, встроенный в процесс, обладает следующими особенностями:
   • он сплошной (то есть выполняется в каждом экземпляре процесса);
   • возникают риски увеличения сроков выполнения процесса, роста потерь, снижения качества (при неправильно организованном контроле).

Контроль «над процессом»:
• выборочный (выполняется только для некоторых экземпляров процесса);
• не создает узкое место в процессе;
• не приводит к росту затрат (незначительные затраты);
• положительно влияет на снижение рисков при выполнении процесса и повышение качества его результатов.

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

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

Таблица сравнительного анализа

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

Андрей Краснобаев, Директор по качеству СТД «Петрович», практик в области организационного развития.

Вячеслав Гончаров, Начальник управления технологического сопровождения АО «Концерн «Уралвагонзавод».

Наталья Косарева, Руководитель компании. Эксперт в области организационного развития. Эксперт в области аудита производственных систем. Организатор Кубка Гастева. Член ABPMP Russian Chapter

Юрий Федосеев, Начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК».

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

«Если посмотреть в общем, то данный Фреймворк действительно имеет практическое применение. Многие методологические аспекты нашего процесса были взяты из первой книги В.В. Репина «Бизнес по правилам…». И сейчас, спустя годы, они продолжают успешно работать. Если уходить в детали, то в каждой компании тот или иной представленный процесс может работать несколько иначе. На это оказывают влияние применяемые информационные системы, сложившиеся практики работы с документами, этап развития, территориальная разрозненность подразделений и даже особенности корпоративной культуры организации».
Юрий Федосеев

«В связи с тем, что компания сервисная, с разъездным персоналом по всей территории России, старались автоматизировать процессы, а стандартизацию контролировать через систему показателей и уведомлений о сбоях в процессах».
Наталья Косарева

Выводы

В статье представлен Фреймворк Системы стандартизации бизнес-процессов компании (ССБП). Это часть общей Системы управления бизнес-процессами (СУБП).
Использовать представленный в статье материал вы можете следующим образом:

1. сравнить существующие у вас процессы и решения с представленными во Фреймворке;
2. найти отличия (то есть провести так называемый «маппинг»);
3. дополнить/скорректировать вашу модель работы с ВНМД;

Главное – необходимо рассматривать управление ВНМД в рамках всего жизненного цикла регламентирующих документов. Тогда ваша модель будет полной.
Еще одним важнейшим требованием является регулярный анализ актуальности, практической полезности ВНМД, оценка эффекта от их внедрения и использования.
Успехов в стандартизации бизнес-процессов вашей компании!

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Апрель 2022 г.

В статье Владимира Репина представлен Фреймворк проекта оптимизации сквозного бизнес-процесса компании. Схемы процессов и их описание разработаны с учетом опыта выполнения проектов командой BPM3.RU, а так же на основе анализа практики российских компаний. Материал может быть полезен для разработки внутреннего стандарта работы по анализу и оптимизации сквозных процессов, для сравнения с существующей практикой и определения направлений ее совершенствования.

Цели создания Фреймворка

Вашему вниманию предлагается процессный Фреймворк – комплексная модель процессов, которые необходимы для выполнения проекта оптимизации сквозного бизнес-процесса. Ранее в статье «Бизнес-процесс на ладони: простые методы анализа и оптимизации» были раскрыты методы выполнения анализа процесса и принципы его оптимизации. Рассматриваемый Фреймворк раскрывает вопрос организации такого проекта.

Процессы Фреймворка были спроектированы в результате анализа проектов оптимизации процессов, выполненных командой консультантов BPM3.RU, а так же с учетом опыта организаций, ведущих соответствующие проекты.

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

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

Контекст

Процессный Фреймворк был разработан в нотациях IDEF0 и BPMN в Business Studio 5. На рис. 1 представлена его контекстная диаграмма. Ключевыми входами в процесс являются: стратегия организации, мнения руководителей и специалистов, предложения сотрудников, результаты аудитов и, конечно, информация о выполнении процессов «Как есть». Ключевые выходы: внедренные изменения, информация об изменениях для сотрудников компании, информация о проекте («Резюме проекта») в базе знаний организации (на внутреннем портале).

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

Процессы оптимизации сквозного процесса

На рис.2 представлена общая модель процессов оптимизации сквозного процесса. Кратко рассмотрим назначение каждого из них в рамках Фреймворка.

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

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

Содержательно проект оптимизации сквозного бизнес-процесса включает четыре фазы:

1. Предварительный анализ.
2. Углубленный анализ и разработка мероприятий по оптимизации.
3. Внедрение изменений в процесс и управление изменениями (коммуникациями).
4. Анализ эффекта от оптимизации процесса.

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

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

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

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

Выбор процессов для оптимизации

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

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

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

После этого Бизнес-аналитик Процессного офиса проводит анкетирование сотрудников по соответствующим процессам, например, используя анкеты на Яндексе (для анонимности).

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

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

1. Таблица рейтинговой оценки процесса.
2. Справка о количестве критических несоответствий, выявленных по результатам аудита.
3. Оценка потенциала оптимизации, основанная на предложениях сотрудников.
4. Экспертное мнение Руководителя Процессного офиса и, возможно, Владельца процесса.

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

Таблица 1. Рейтинг процесса.

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

Первый этап проекта оптимизации – это выполнение предварительного анализа сквозного процесса.

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

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

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

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

Затем ВРГ формирует Проблемное поле. Оно может иметь следующую структуру (таблица 2).

Таблица 2. Структура «Проблемного поля».

Важно, что ВРГ не только структурирует проблемы, но и формулирует гипотезы о причинах этих проблем.

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

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

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

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

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

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

В Отчете по анализу процесса «Как есть» должна быть представлена следующая информация:

1. Модель процесса «Как есть».
2. Проблемное поле с гипотезами о причинах проблем.
3. Результаты измерения показателей процесса «Как есть».
4. Оценка потенциала и цели оптимизации процесса.

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

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

На рис. 5 показана схема процесса «Углубленный анализ и разработка мероприятий по оптимизации».

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

Технически, для выполнения указанных видов анализа ВРГ может:
• выполнить визуальное наблюдение за процессом и фотографирование;
• получить и аналитически обработать данные учетных систем (например, 1С);
• построить графики и диаграммы;
• организовать сбор дополнительных необходимых данных в контрольных точках;
• провести мозговые штурмы;
• провести консультации с экспертами;
• выполнить бенчмаркинг;
• прочее.

ВРГ использует все адекватные контексту проекта методы анализа, которым предварительно были обучены участники рабочей группы. Вообще, формировать ВРГ по оптимизации сквозных процессов из необученных сотрудников весьма нерационально.

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

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

Участники ВРГ должны иметь представление о принципах и методах проектирования эффективных процессов, в том числе знать основы теории ограничений, методы TPS, понимать возможности современных BPM и RPA систем и проч.

Состав мероприятий может определяться причинами проблем, а так же видением перспективной модели процесса, сформированной участниками ВРГ и привлеченными экспертами.

В большинстве случаев, ВРГ необходимо разработать модель процесса «Как должно быть» с учетом предложенных мероприятий по оптимизации (например, в Business Studio).

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

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

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

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

Руководитель проекта готовит Отчет по углубленному анализу процесса и мероприятиям. В Отчет включается следующая информация:

1. Результаты анализа. Выявленные причины проблем (подтвержденные/опровергнутые гипотезы).
2. Мероприятия по оптимизации процесса.
3. Модель процесса «Как должно быть».
4. Прогноз эффекта от оптимизации процесса, включая Методику оценки эффекта от оптимизации.
5. Предложения по количеству и составу ВРГ для реализации мероприятий.

Владелец процесса утверждает Отчет, тем самым дает добро на выполнение запланированных мероприятий по оптимизации процесса.

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

Внедрение изменений в процесс

На рис. 6 показана схема процесса «Внедрение изменений в процесс». ВРГ выполняет утвержденные мероприятия по оптимизации процесса в соответствии с планом.

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

После внедрения всех запланированных мероприятий Руководитель проекта формирует Отчет по выполнению мероприятий. Этот Отчет носит скорее технический характер: что и как было сделано, сколько потратили времени и других ресурсов (денег, материалов).

Владелец процесса утверждает Отчет по выполнению мероприятий. Это важно с точки зрения контроля исполнения состава работ по проекту и сроков.

Далее, при необходимости, может быть инициирован процесс разработки регламента на основе модели процесса «Как должно быть». Процесс «Разработка/корректировка ВНМД» не входит в рассматриваемый Фреймворк. Этот процесс входит в группу процессов системы стандартизации бизнес-процессов компании. Так же, при необходимости, может быть инициировано обучение персонала.

Одновременно с выполнением мероприятий по оптимизации выполняется процесс «Управление изменениями (коммуникациями)».

Управление изменениями (коммуникациями)

На рис. 7 показана схема процесса «Управление изменениями (коммуникациями)».
Управление изменениями в данном Фреймворке рассматривается достаточно узко, а именно как:

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

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

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

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

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

На рис. 8 показана схема процесса «Анализ эффекта от оптимизации процесса». Это четвертый этап проекта оптимизации сквозного бизнес-процесса.

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

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

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

Таблица 3. Показатели для оценки эффекта от оптимизации бизнес-процессов.

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

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

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

После этого Отчет согласует Владелец процесса, а затем утверждает Процессный комитет. В рамках его проведения в том числе рассматривается и утверждается размер премий участникам ВРГ и другим сотрудникам.

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

Руководитель Процессного офиса размещает резюме проекта в Базе знаний компании.

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

На рис. 9 представлена схема процесса «Управление проектом оптимизации процесса».

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

За ВРГ может закрепляться бизнес-аналитик Процессного офиса для оказания организационной, методической и экспертной помощи.

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

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

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

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

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

Таким образом, в рамках управления проектом представлены два контура управления: еженедельный и ежемесячный, в рамках которых контролируется ход работ по проекту, уточняется его план.

Оперативная постановка задач (поручений) участникам ВРГ выполняется Руководителем проекта в рамках содержательных совещаний ВРГ по обсуждению текущих рабочих вопросов по проекту.

Выводы

В статье представлен Фреймворк проекта оптимизации сквозного бизнес-процесса компании.

Для создания внутреннего стандарта выполнения такого проекта вам потребуется:

1. Данный Фреймворк.
2. Методика приоретизации и выбора процессов для оптимизации.
3. Методика формирования Проблемного поля (включая гипотезы о причинах проблем).
4. Методика разработки целей и показателей для процесса.
5. Методика анализа процесса (может включать ряд методов).
6. Методика оценки мероприятий по оптимизации процессов («Затраты/эффективность»).
7. Методика оценки эффекта от оптимизации процесса (по итогам выполнения проекта).
8. Методика управления изменениями (коммуникациями).

Указанные методики могут быть описаны в рамках одного стандарта (регламента) компании, либо выделены и утверждены в виде отдельных внутренних нормативно-методических документов. Не нужно создавать слишком сложные методы. Лучше сначала использовать простые и понятные решения, а затем, после практического использования, вносить в них необходимые изменения.

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

С учетом существующей в компании архитектуры процессов в области организационного развития и проектного управления Фреймворк может быть изменен, а необходимые методики прописаны в других документах компании. Главное, чтобы была сформирована простая и эффективная СИСТЕМА работы по оптимизации сквозных бизнес-процессов.

Успехов в оптимизации сквозных бизнес-процессов вашей организации!

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.

Январь 2022 г.

19 февраля 2021 года состоялась конференция «Системная практика управления бизнес-процессами». В конференции приняли участие более 500 руководителей и специалистов из России и других стран. По ходу конференции участники задали большое количество вопросов. Многие вопросы были сформулированы в чате конференции, поэтому во время ее проведения не всегда была возможность ответить на них развернуто. В статье мы восполняем этот недостаток. Наталья Косарева (НК) и Владимир Репин (ВР) подробнее ответили на многие вопросы участников. Презентации спикеров конференции и видео докладов можно посмотреть по ссылке выше.

Введение

18 февраля 2021 года состоялась конференция «Системная практика управления бизнес-процессами». В конференции приняли участие более 500 руководителей и специалистов из России и других стран.

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

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

На следующем рис. 2 представлена диаграмма по уровням должностей участников конференции.

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

На рис. 3 представлена структура участников конференции по типам организаций. Интересно отменить, что тема процессного управления оказалась важной для ВУЗов (6%) и органов государственной власти (4%).

Далее в статье представлены наиболее интересные вопросы участников конференции в соответствии со структурой BPM CBOK 3.0 и ответы на них. Часть вопросов была задана в чате конференции. Во время ее проведения не всегда была возможность ответить на них развернуто. Ниже мы восполняем этот недостаток.

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

Вопрос: Можно ли немного рассказать о связи процессов с финансовыми и бюджетными структурами. Например, для процесса управления «Бюджетирование», являются ли входами бюджеты ЦФО? Или бюджеты ЦФО — это интерфейсы между владельцем процесса бюджетирования и владельцами других процессов?
Ответ (НК): С моей точки зрения, бюджеты, которые не видоизменяются в других процессах, являются неким правилом, ориентиром. Если в бюджетной структуре происходит изменение бюджета, в связи с ее обязанностями по корректировке бюджета, то «бюджет» будет являться входом.
Ответ (ВР): Документы – это в любом случае не интерфейсы, ведь они пересекают границы ответственности. Границы процесса бюджетирования могут быть определены по-разному. Если формирование бюджетов ЦФО не входит в процесс «Бюджетирование», то очевидно, что бюджеты ЦФО (как результат другого процесса) могут являться входами для процесса «Бюджетирование». Так что это вопрос определения границ процесса.

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

Вопрос: «Зачем нужно уделять особое внимание управлению процессами, если можно решать задачи повышения прибыли другими способами?»
Ответ (НК): Прибыль = Выручка — Затраты. Следовательно, повышения прибыли можно достигать, либо увеличением выручки, либо уменьшением затрат. Процессное управление может способствовать изменению обеих составляющих. Например, для повышения выручки совершенствовать скрипты общения с клиентами, которые способствуют их притоку и доведения до покупки. Процессы, повышающие качество продукции, также способствуют увеличению количества клиентов и совершению существующими клиентами повторной покупки. Уменьшению затрат способствует стандартизация процессов, а для этого их необходимо увидеть, регламентировать и контролировать с помощью показателей с целью дальнейшего улучшения. Когда процессы выполняются по установленным стандартам, то люди не тратят время на раздумывания, как им лучше выполнить его. При стандартизации можно собирать статистические данные и смотреть статистическую устойчивость процесса. Улучшать можно только статистически устойчивые процессы.
Ответ (ВР): Каждая компания проходит разные этапы жизненного цикла. Область деятельности и масштаб компаний так же совершенно разные. Поэтому ответить на этот вопрос можно только применительно к конкретной компании, находящейся в конкретной ситуации. В целом, ответ – да. Можно эффективно решать задачи повышения прибыли другими способами. Но если компания достигла определенного размера и уровня зрелости, то внедрение процессного подхода становится неизбежным для того, чтобы уйти от практики «ручного управления» бизнесом, получить возможность делегировать полномочия и сделать процессы «прозрачными», контролируемыми, управляемыми.

Вопрос: «Можно ли в цифрах просчитать эффект для представления руководству?»
Ответ (НК): Все зависит от уровня зрелости учета на вашем предприятии. В продолжении ответа на предыдущий вопрос: эффект от внедрения может выражаться, либо в получении дополнительной прибыли от выпуска более качественной продукции, либо в уменьшении расходов в связи с устранением потерь.
Знание стоимости выполнения процесса помогает команде правильно назначить приоритет процессам, заслуживающим первоочередного рассмотрения. Организация может выбрать следующие критерии приоритетности:
• процессы, взаимодействующие с клиентом;
• процессы, оказывающие большое влияние на доходы;
• кросс-функциональные процессы, нуждающиеся в координации.
Каждому из этих факторов можно присвоить шкалу и определять приоритетность, исходя из суммы баллов.
Ответ (ВР): Можно. Но для этого нужно провести достаточно глубокую диагностику ситуации в компании и определить потенциал повышения эффективности. Для решения этой задачи целесообразно создать команду, включающую внутренних экспертов, внешних процессных методологов/аналитиков и отраслевых экспертов. Сравнение с практиками других успешных компаний особенно важно и позволяет сразу «высветить» проблемные места, оценить потенциал роста выручки, сокращения затрат и проч.

Вопрос: «Исходя из каких критериев можно рекомендовать выбор метода описания процессов (функциональные /сквозные)?»
Ответ (НК): Чтобы сложная современная организация оставалась конкурентоспособной, ВРМ и функциональное управление обязаны в ней уживаться и сотрудничать:
• функциональное управление гарантирует работоспособность несметного числа функциональных дисциплин, которые требуются организации для создания продукции и услуг;
• ВРМ гарантирует, что работа этого несметного числа функций координируется так, что продукция и услуги создаются с максимальной производительностью и эффективностью.
Ответ (ВР): Выбор зависит от целей и масштаба вашего проекта. Если вы хотите разобраться с процессами внутри отдела, то это будут «функциональные» процессы, которые могут не иметь законченной ценности в целом для компании и ее клиентов. Это не плохо и не хорошо. Это факт…. Если цель состоит в построении архитектуры бизнес-процессов компании, то нужно начинать с анализа деятельности всех подразделений, то есть с определения функциональных процессов. Если же цель проекта, например, быстро описать и автоматизировать конкретный бизнес-процесс на межфункциональном уровне, то нужно будет определять сквозной бизнес-процесс.

Вопрос: «Я правильно понимаю, что теперь на сквозной процесс не надо ломать голову и искать одного Владельца процесса. Так как это была та ещё задачка (невыполнимая), а исходя из теории так должно было бы быть. Сегодня Ваш слайд расставил все на свои места».
Ответ (НК): Э. Деминг в своей книге «Выход из кризиса» писал: «Разделенная ответственность означает, что не отвечает никто». Если цель ставится по всему сквозному процессу, то и ответственный должен быть один.
Ответ (ВР): Почему не надо? Надо! Если вы определяете сквозной процесс, то, очевидно, планируете его улучшать и потом оперативно управлять. Так что нужно будет выбрать и назначить ответственного за эту работу. А вот называть ли его «владельцем» и какие полномочия давать, это уже другой вопрос.

Вопрос: «Правильно ли понимаю, что рекомендуете с разной степенью глубины описывать разные процессы в рамках компании?»
Ответ (НК): В зависимости от уровня процессной зрелости организации управление эффективностью процессов различается углом зрения и глубиной. Один из первых шагов процессной команды – определение границ анализируемого процесса. Это ответственное решение, так как от него будет зависеть, как далеко зайдет проект, сколько бизнес-функций он затронет и какое воздействие на процессы и пользователей вверх и вниз по потоку работ окажут изменения. После того как рамки анализа заданы, аналитик должен выбрать глубину анализа: достаточно ли рассмотреть уровень действий или следует также проанализировать все входы и выходы?
Ответ (ВР): Глубина декомпозиции системы определяется целью ее разработки и квалификацией специалистов, которые потом будут с ней работать. Я рекомендую описывать процессы с той степенью глубины, которая нужна для принятия решений по улучшению процессов. Решения эти могут быть разного масштаба. Например, описание процессов в нотации IDEF0 на верхнем уровне помогло обосновать структурные изменения в организации – была создана новая, эффективная орг. структура, перераспределена ответственность за процессы на верхнем уровне. Другой пример: описание процесса в нотации BPMN помогло увидеть, насколько сложен, запутан реальный процесс, и принять решения по его реорганизации с последующим выходом на проект автоматизации в BPMS.

Вопрос: «Я правильно понимаю, что «сквозные» процессы собираются из отдельных уже описанных / стандартизованных процессов? Если да, то в чем ценность / смысл такой сборки? Или «выделены отдельные процессы» означает только то, что они названы / идентифицированы?»
Ответ (НК): Согласно определению АВРМР, «процесс» является кросс-организационным и включает в себя все работы, необходимые для создания и предоставления продукции или услуги. При этом процесс может быть разбит на подпроцессы, которые выполняются подразделениями как последовательность взаимосвязанных и последовательных действий – на потоки работ. После того, как эта структура определена, можно организовать мониторинг процесса путем объединения информации на уровне потоков работ, включая передачу ответственности между подразделениями.
Верхний уровень процессной иерархии составляет сквозной процесс. Затем он разбивается (декомпозируется) вплоть до отдельных действий, где и выполняется процессная работа. Процесс должен быть декомпозирован достаточно глубоко, чтобы показать, из каких действий он состоит и как эти действия дополняют друг друга в создании конечной продукции.
Ответ (ВР): Ценность — в непрерывности. Стыковка процессов в единый, непрерывный сквозной процесс, особенно при условии его автоматизации, дает очень хороший эффект для бизнеса: сроки выполнения, устранение потерь, удобство для клиентов.

Вопрос: «Как определить владельца процесса и разделить границы между внутренний заказчик/поставщик»?»
Ответ (НК): Самое главное – обеспечить непрерывность процесса и передачу ответственности. Лучше всего этого достигать при совместном обсуждении.
Ответ (ВР): Границы процессов – это всегда вопрос внутренних договоренностей. Не настолько важно, где граница. Гораздо важнее, что процессы стыкованы между собой непрерывным образом, что отсутствуют зоны безответственности (пересечения ответственности). При этом, конечно, важно понимать потребности каждого внутреннего заказчика. В разных частях организации (с учетом типа бизнеса) методы определения сквозных процессов могут быть разные. Простой критерий – «сквозной процесс проходит через несколько подразделений» — это не метод его определения. В целом, определение сквозных процессов – это инструмент менеджмента. Если просто спрашивать, «Что вы делаете для такого-то процесса?», можно получить большой объем плохо структурированной информации, которую почти невозможно будет использовать. Другими словами, описание процессов «снизу вверх» без архитектуры, как правило, не дает хорошего результата.

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

Вопрос: «Правильно ли поняла по вашему слайду о функциях и процессах, что деятельность по бюджетированию является функцией? Если — да, то почему эта функция имеет все определяющие для процесса характеристики — повторяемость, регламентированность, наличие заказчика и показателей качества. Пример показателей — отклонение план\факт, своевременность подготовки бюджетов».
Ответ (НК): Модели потоков работ обычно описывают, что должно быть сделано для выполнения процесса. Это модели более детальные по сравнению с моделями процессов предприятия и моделями бизнес-процессов. Модели потоков работ разбиваются на действия (их также называют задачами или процедурами). Действия в модели потоков работ выполняются «функциями»: должностями, подразделениями, системами.
Ответ (ВР): А что такое вообще «Функция»? Если абстрактная способность что-то делать, то нам такое определение не нужно. А если функция имеет все нужные характеристики, то это уже процесс, но не сквозной, а локализованный в одном структурном подразделении. Это нормально.

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

Вопрос: «Обеспечение производства услугами подрядчиков куда помещаем: в операционную или обслуживающую систему?»
Ответ (НК): Компания сама определяет. Генри Минцберг в организационной структуре выделяет еще «Техноструктуру», которая как раз занимается обеспечением производства.
Ответ (ВР): Скорее, в обслуживающую.

Вопрос: «А управление, как процесс, Вы не выделяете?»
Ответ (НК): Управление – это самый важный процесс с точки зрения устранения потерь и повышения эффективности компании. Большинство организаций продолжает фокусироваться на небольших улучшениях структурированных процессов, в то время как возможности дифференциации процессов в большей степени кроются в деятельности работников умственного труда. Эта деятельность в значительной степени не структурирована – она не является рутинной, и для нее не характерно последовательное и предсказуемое выполнение. Ведущие мировые экономики зависят от успеха работников умственного труда. Успех в отраслях сферы услуг определяется использованием знаний.
Ответ (ВР): Да, конечно. При создании архитектуры бизнес-процессов для каждого процесса 1-3 уровня всегда определяем процесс «управления процессом». При его декомпозиции показываем процессы, связанные с целеполаганием, планированием, организацией, мониторингом и контролем, принятием решений, анализом, контролем исполнения регламентов и проч. Если не определять такие процессы в архитектуре, то как потом регламентировать и автоматизировать деятельность руководителей по управлению бизнес-процессами?

Вопрос: «Однако, а как же быть с процессами управления? Как быть с классическими схемами с управляющей и управляемой подсистемами и обратными связями?»
Ответ (НК): Работники умственного труда оказываются среди тех, кто больше всех сопротивляется улучшению процессов. Они видят в этом принижение значимости их опыта и уникальной интуиции. Однако такое отношение отражает давнее ошибочное восприятие улучшения процессов.
Ответ (ВР): При формировании моделей в нотации IDEF0 это можно легко показать. Мы так и делаем.

Моделирование процессов

Вопрос: «На верхнем уровне при моделировании не используете IDEF0? Комбинирование IDEF0 и BPMN на ваш взгляд не эффективно?»
Ответ (ВР): это зависит от используемого программного продукта для описания бизнес-процессов. Например, в Business Studio 5 мы активно используем нотацию IDEF0 для построения моделей процессов на верхнем уровне. Это модели так называемого структурного типа. Их основная задача – построение модели сложной системы – архитектуры процессов компании. Такую же задачу решает, например, нотация VAD в системе ARIS. Есть и другие нотации, которые можно применять для построения структурных моделей, например DFD (Data Flow Diagram). В свою очередь, нотация BPMN является отличным выбором для описания процессов Work Flow (поток работы) для целей анализа, регламентации и подготовки к автоматизации в BPMS. Например, комбинация нотаций IDEF0 (для верхнего уровня) и BPMN (для нижнего) в Business Studio 5 весьма эффективна.

Вопрос: «Какая «временная последовательность» может быть в диаграмме IDEF0 (верхний уровень 8-процессной модели)?»
Ответ (ВР): Никакая. IDEF0 – это модель структурного типа. Она принципиально не показывает «временную последовательность» выполнения процессов в отличии от нотаций типа Work Flow (CFFC, eEPC, BPMN).

Вопрос: «Выделяете ли Вы требования к моделируемым БП, до начала моделирования»?
Ответ (ВР): Да, конечно. Практически в каждом проекте создается (на основе типового) Соглашение по моделированию бизнес-процессов (Стандарт описания бизнес-процессов). В этом документе фиксируются все требования к моделям бизнес-процессов в используемых нотациях (например, IDEF0 и BPMN). Кроме того, всегда важно понимать цель моделирования процесса, метод и точку зрения.

Вопрос: «В «Бережливом производстве» есть инструмент картирование процесса. Рекомендуете ли его?».
Ответ (НК): Карта потока создания ценности (КПСЦ) входит в нотации, рекомендуемые BPM CBOK. Использование нотаций зависит от целей компании.
КПСЦ используется.
• Чтобы вовлечь в анализ процесса его исполнителей.
• Там, где не требуются полноценные средства моделирования.
• Там, где четко заданы требования по стоимости и продолжительности процесса.
Преимущества.
• Простота и легкость применения.
Недостатки.
• Плоские модели.
• Репозиторий не предусмотрен.
• Невозможно использовать для решения сложных задач.
Ответ (ВР): Если Вы имеете в виду Toyota Value Stream Map (VSM), то его можно рекомендовать для решения конкретного круга задач – анализа цепочки создания ценности в рамках существующей производственной модели и построении новой модели «вытягивающего» производства на основе принципов TPS. Если ваша задача – описать процессы для последующей автоматизации в BPMS, то метод VSM вам, конечно, не подойдет.

Анализ процессов

Вопрос: «Описание и анализ чем отличается от стандартизации?»
Ответ (НК): Одна из целей BPM СВОК – стимулировать читателей к использованию общей, согласованной терминологии в области ВРМ. Чтобы все друг друга понимали, определения должны быть согласованы с бизнес-руководителями, с IT и бизнес-партнерами. Но тут возникает культурно-политическая проблема: чье определение будет признано истинным и выбрано для всеобщего употребления? Пока термины и акронимы не согласованы, пользы от стандартов сбора информации будет немного в плане выработки общего понимания того, что представляют собой операции и как их следует совершенствовать.
Что такое описание и анализ по BPM CBOK?
Описание процесса должно соответствовать назначению и применению:
• Соответствие назначению подразумевает, что описание процесса содержит всю необходимую информацию для ответа на вопросы, кто, что, где, когда, зачем и как делает.
• Соответствие использованию подразумевает, что описание процесса структурировано таким образом, чтобы представлять эту информацию максимально эффективно, учитывая потребности целевой аудитории.
Анализ процессов дает представление о действиях процесса и измеряет результаты этих действий, сопоставляя их с целями организации.
Анализ процессов выполняется с помощью различных методов, в том числе составления диаграмм, интервьюирования, имитации действий и других. Он часто включает в себя изучение бизнес-среды, организационного контекста процесса, факторов, влияющих на операционную среду, отраслевых особенностей, правительственных и отраслевых нормативов, требований рынка и конкуренции.
Ключевые факторы, подлежащие рассмотрению при анализе процессов:
• стратегия бизнеса;
• цели процесса;
• ключевые проблемы на пути к достижению целей;
• вклад процесса в общую цепочку создания ценности;
• организация и бизнес-роли, обеспечивающие процесс.
Ответ (ВР): Да, конечно. Целью описания и анализа может быть, например, оптимизация процесса и/или подготовка к его автоматизации. Кроме того, создание регламента на основе описания процесса еще не означает его стандартизацию. Чтобы стандартизовать процесс нужно внедрить регламент и добиться того, чтобы соответствующие процессы выполнялись в соответствии с этим регламентом. Т.е. нужна Система стандартизации, а не просто отдельные регламенты.

Проектирование процессов

Вопрос: «На первый взгляд, проектирование процессов «снизу вверх» (путем выделения классов процессов и построения типовой модели объекта класса) всегда приводит к модели «as is». Или все-таки нет?»
Ответ (НК): Проектирование процесса включает изучение существующего процесса и его подпроцессов и анализ того, как он может быть усовершенствован или фундаментально пересмотрен для достижения желаемого результата.
Ответ (ВР): В этом вопросе несколько скрытых смыслов. Во-первых, проектирование «снизу вверх» редко приводит к нормальному архитектурному решению. Это как строить завод «хоз. способом» — построить можно, но потом будут постоянные проблемы: то не продумали, сё не продумали, там упало, тут развалилось и т.п. Во-вторых, что есть «as is»? Многие, когда делают описание «как есть», сильно отрываются от реальности. В итоге, считают, что делали «как есть», а по факту получили «как смогли изобразить свои представления о том, как есть, опираясь не неточные и непроверенные данные». Неумение моделировать, например, в нотации BPMN, комбинируется с недостоверными данными и их субъективной интерпретацией… Для получения действительно адекватной модели «как есть» нужно быть серьезным профессионалом и опираться на проверенные, достоверны данные. Чем точнее модель «как есть», тем она дороже. Но здесь возникает вопрос, а насколько такая модель нужна, если анализ процесса в целом показывает, что он никуда не годный? Речь идет о том, что степень приближения модели «как есть» к реальности должна быть разумной, обусловленной целями и задачами конкретного проекта.

Вопрос: «Чем отличается описание процессов «для автоматизации» от описания процессов «как есть» или «как будет»?»
Ответ (НК): Группа, отвечающая за проектирование бизнеса, должна иметь представление о технических аспектах проектирования, создания и внедрения бизнес-усовершенствований. Аналогично группа от IT должна иметь представление о подходах к трансформации бизнеса. Ограничения и доступные варианты будут сильно различаться в зависимости от того, опирается ли проектирование процесса на генерацию BPMS-приложений.
Существуют два основных подхода к проектированию новой модели. Первый заключается в проектировании такого усовершенствования, которое можно целиком реализовать одним изменением. Второй заключается в разработке модели, которая была бы оптимальной, но (пока) не реализуемой на практике из-за дороговизны, из-за радикальности, из-за недостижимых изменений IT и т.д. В этом случае разрабатываются одна или несколько промежуточных версий, приближающих нас к «оптимальной» модели «как будет».
Эффективность компании напрямую зависит от качества процессов и правил. Но сегодня к ним добавляется еще один элемент: способность компании воспринимать изменения и быстро к ним адаптироваться. И еще меньше тех, кто способен на быстрые изменения, и кто может контролировать большую часть происходящих в компании изменений. Одна из причин – неспособность IT-инфраструктуры и унаследованных IT-приложений компаний среднего и крупного масштаба поддерживать требуемый темп изменений. IT-подразделения завалены заявками на доработку информационных систем, с которыми не могут справиться. В большинстве операций возникают «белые пятна» — ручная работа, обусловленная ограниченными возможностями автоматизации и быстротой изменений.
Ответ (ВР): Всем. Начнем с того, что модели «Как есть» и «Как будет» могут делаться не для автоматизации. Модели «для автоматизации» тоже могут быть разными. Поэтому в этом вопросе вы пытаетесь сравнивать «круглое» и «теплое» — в чем разница?

Управление эффективностью процессов

Вопрос: «Максимальное кол-во KPI на одного человека, которые работают эффективно?»
Ответ (НК): Объем внимания у взрослого человека составляет 5-7 элементов, на это и стоит ориентироваться. У меня в компании у сотрудников был один верхний интегрированный показатель эффективности, который каскадировался на три составных.
Ответ (ВР): KPI не работают. Работают системы: целеполагания и планирования, управленческого учета, оперативного контроля и управления, материального стимулирования. Количество KPI само по себе ничего не значит. Важно, как они используются в рамках данных систем. С точки зрения конкретного человека, оценка больше, чем по 3-5 показателям становится сложной для восприятия. Это затрудняет понимание и снижает возможность концентрации.

Вопрос: «Для оценки бизнес-процессов, что предпочтительнее использовать KPI или OKR?»
Ответ (НК): ОKR применяется при управлении изменениями и инновациями (Change and Disrupt), а KPI — больше при управлении процессами (Run).
Ответ (ВР): KPI – показатели. Они используются не сами по себе, а в рамках определенной системы. В OKR тоже есть показатели.

Процессная трансформация

Вопрос: «Классификация типов управления… Чье авторство разработки? Или обще признанное с методологической точки зрения?»
Ответ (ВР): Авторство Владимира Репина. Подготовил специально для конференции. Меня давно волновал вопрос, может ли компания быть успешной без бизнес-процессов? Классики жанра, такие как М. Хаммер, устами своих последователей твердили нам, что «… компанию делают успешной и конкурентоспособной ее бизнес-процессы». После долгих размышлений над этим вопросом я все-таки понял: это не так! Компанию делают успешной множество факторов: личность собственника, текущий момент, коллектив, наследство в виде активов, медленная смерь конкурентов, гос. поддержка, удача и т.п. Когда мы говорим о процессах – есть они в компании или нет, — надо четко определить, что мы поднимаем под понятием «процесс». Если это «деятельность по преобразованию входов в выходы», то такую деятельность можно успешно выполнять безо всяких там процессов. Да, будут потери. Да, результат будет каждый раз немного разный. Но если на рынке нашелся клиент на такой результат, купил, и мы в прибыли, то обошлось без бизнес-процессов. Другое дело, как я писал выше, когда компания вырастает до определенного размера, ей становится выгодно заниматься определением реальных процессов (целенаправленная, повторяющаяся, стабильная последовательность действий, приводящая к получению заданного результата).

Вопрос: «А что если руководитель подразделения не берет на себя роль владельца сквозного БП? Как можно повлиять\замотивировать?»
Ответ (НК): Должна быть заинтересованность вышестоящего руководства, а уж у него есть административные ресурсы для вовлечения.
Ответ (ВР): Всяко-разно. Можно, например, утвердить положение о Владельце процесса, а потом назначить приказом.

Процессная организация

Вопрос: «Архитектура бизнес-процессов — это реестр сквозных процессов? Или организационная структура с функционалом подразделений — это тоже архитектура бизнес-процессов?»
Ответ (НК): Вариант 1-й архитектуры бизнес-процессов — реестр процессов в виде справочника, перечня процессов в Word. Вариант 2-й архитектуры бизнес процессов – это модель, в которой вы понимаете, как ваши процессы связаны с точки зрения информационных и материальных потоков, с точки зрения управленческих воздействий, обратных связей. Модель позволяет вам понять в каких границах работают процессы и точно определить для них показатели. Архитектура процессов –это основа для того, чтобы внедрять системную практику работы с процессами.
Ответ (ВР): В каком-то смысле – да. Недостаток Реестра может состоять в том, что непонятны, не уточнены границы процессов. Это означает, что сам Реестр довольно «сырой». При декомпозиции могут потребоваться существенные действия по его изменению. Если же при создании Реестра процессы были стыкованы по входам/выходам (т.е. определены границы), то такой Реестр можно рассматривать в качестве архитектуры бизнес-процессов организации.

Вопрос: «Архитектура процессов и карта основных бизнес-процессов — не одно и то же?»
Ответ (ВР): Нет, если речь идет об одной картинке, на которой представлены «рыбками» основные процессы.

Вопрос: «Как описывать архитектуру процессов? Самостоятельно или внешними специалистами?»
Ответ (НК): Зависит от целей и возможностей компании. Например, Вы захотели съесть борщ. Первый вариант: пойти в ресторан и там его заказать. Второй вариант: изучить книгу с рецептами, сходить на рынок, все закупить, приготовить, подождать, когда он настоится, потому что борщ лучше есть на второй день. Выбирайте сами.
Ответ (ВР): Все зависит от наличия в вашей компании процессного архитектора/методолога и бизнес-аналитиков. Если они есть, то можно разработать архитектуру самим. Если их нет, а нужно быстро, то целесообразно заказать эту работу у внешних консультантов.
Управление процессами организации

Вопрос: «10 атрибутов Системы управления бизнес-процессами — какие из них наиболее важно добавлять к 1-ому и 2-ому подходам (1. регламентация и 2. BPM-проект)».
Ответ (ВР): Не нужно их добавлять. Нужно выбрать ваш путь – будете или нет создавать Систему управления бизнес-процессами, как часть общей Системы управления компанией.

Вопрос: «Есть ли продуманный граф причинно-следственных связей 10-ти атрибутов? С чего начинать? Если мы поставили себе цель, по бизнес-процессам выйти на 5 уровень, это реально сделать за год? Если мы сейчас находимся на 2-ом уровне».
Ответ (НК): Можно все. Зависит лишь от желания руководства и финансовых ресурсов. За первые 4 месяца войны из-под удара агрессора были выведены 8 млн. человек, 2,5 тысячи промышленных предприятий, 1,5 тысячи колхозов и совхозов. По своим масштабам и эффективности этот проект не имеет аналогов в мировой истории. Нет ничего невозможного.
Ответ (ВР): Такого графа нет. Была попытка его нарисовать, но схема оказалась слишком сложной – не стал публиковать. А вот график Ганта по внедрению СУБП есть. Его можно посмотреть в моих статьях и видео на канале Youtube. Да, реально за год перейти со 2-ого на 5-й уровень (оценка 0,5, шкала 0-1), если вы имеете в виду шкалу, представленную на диаграмме в моей презентации.

Вопрос: «Вы показывали оценку зрелости компании по 10 факторам СУБП. Есть у вас методики оценки финансового эффекта (эффективности) при изменении уровня зрелости в целом и по каждому из показателей?»
Ответ (ВР): Нет, пока такую методику не разрабатывал, так как сделать это весьма сложно. У вас есть методики оценки финансового эффекта от совершенствования процесса конструирования изделий, управления персоналом или развития корпоративной культуры? Вряд ли. Но, тем не менее, многие собственники компаний убеждены, что это делать нужно.

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

Наталья Косарева,
эксперт-практик в области развития производственных систем, руководитель группы сервисных компаний по всей территории России, организатор кубка Гастева А.К. в 2019 году.

Владимир Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»

Март 2021 г.

Компетенции для BPM-проекта

В 2013 году компания Gartner предложила модель компетенций, которые необходимы для успешного выполнения BPM-проекта в компании (BPM – Business Process Management). Для внедрения процессного управления, согласно этой модели, проектной команде необходимы компетенции по трем направлениям: трансформационные, операционные и технические. Рассмотрим их подробнее (см. таблицу 1).

Трансформационные компетенции

Успех проекта оптимизации бизнес-процесса во многом зависит от… выбора этого процесса. Выбрав процесс, эффект от оптимизации которого минимален, мы никогда не окупим потраченные ресурсы. Но как сделать выбор? Почему конкретный процесс должен быть выбран? Как такой выбор повлияет на достижение стратегических целей? Опыт и чутьё полезны, но кроме них необходимы четкие критерии выбора и подходящая методика. Процесс – узкое место. Процесс – ключевой фактор для цифровой трансформации. Процесс многократно повторяется и может быть тиражирован в регионы, филиалы и т.п. «Умение готовить бизнес-обоснование и наличие видения» — первая необходимая компетенция для руководителя.

Вторая трансформационная компетенция – это управление проектами. Можно просто описывать процессы, а можно описывать в срок с конкретным результатом и внедрением изменений. Это вполне очевидно. Но, к сожалению, довольно часто BPM-проект начинается и идет полупартизанским методом, потому что «… у нас очень сложно оформить что-то как проект…».

Третья компетенция «Знание организационной структуры и корпоративной культуры» является одной из ключевых, на мой взгляд. Понятно, что знание орг. структуры – это не столько знание схемы, сколько реальных людей с их возможностями и связями. Без этих знаний и умений в подборе союзников для проекта и нейтрализации оппонентов, определения реальных возможностей и скорости изменений, BPM-проект вряд ли состоится.

Еще две трансформационные компетенции тесно связаны с третьей. Это – коммуникации и методы управления изменениями. Если вы сформулировали проблему и выявили ее причины, собрали совещание, обсудили проблему, протоколом распределили задачи исполнителям, то можно сказать, что уровень коммуникаций и управления изменениями в компании… низкий. Дело в том, что наличие протокола и закрепления задач по отдельным исполнителям совершенно не означает, что:
• протокол содержит обдуманный план действий;
• задачи будут выполнены и проконтролированы (зависит от культуры исполнения);
• исполнители будут работать как единая команда;
• другие сотрудники компании будут уведомлены о планируемых изменениях;
• четко сформулированы и практически использованы критерии оценки результативности изменений.

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

Операционные компетенции

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

Вторая компетенция – это «Моделирование, анализ и проектирование бизнес-процессов». Одна довольная обширна. Нужно уметь моделировать процессы «как есть» в современных нотациях (например, eEPC или BPMN) с использованием различных программных продуктов (например, BizAgi или Camunda Modeler, ARIS, Business Studio и проч.). Нужно владеть методами анализа процессов, например: анализ ограничений, времени выполнения, потерь. Нужно знать принципы и методы оптимизации процессов, например: вертикальное и горизонтальное сжатие процесса, устранение узких мест и др. Рассматриваемая компетенция является ключевой.

«Регулирование и организация процессной работы» — эти умения необходимы для эффективной организации команды проекта. Например, нужно уметь организовывать и проводить моделирующие сессии, выполнять анализ процесса, готовить и проводить презентации предлагаемых изменений бизнес-заказчику и т.п.

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

Последняя компетенция в группе операционных компетенций – «Подбор инструментов, поддерживающих методологию BPM». Выбор адекватного инструмента важен для успешного выполнения проекта. Например, нецелесообразно долго выбирать и настраивать сложный инструмент, если проект короткий, а решение по масштабному внедрению в компании не принято. Есть риск, что «весь пар проектной команды уйдет в свисток». Можно полгода обосновывать покупку системы ARIS, а можно взять бесплатный Camunda Modeler и быстро решить поставленную задачу, показав хороший результат.

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

Технические компетенции

Допустим, вы описали процессы. Что дальше? Как проектировать новые, эффективные и цифровые процессы? С практикой 70-х годов далеко не уедешь. Проектная команда должна, как минимум, четко представлять себе возможности современных средств автоматизации и тенденции их развития. Первая техническая компетенция – это «Архитектура и дизайн решения». Сотрудники должны знать, как устроена типичная BPMS (возможно, даже Low-code система), что она может делать, а что — нет.

Вторая техническая компетенция – «Знание программного обеспечения BPM». Процессы можно проектировать по-разному. Для регламентов верхнего и среднего уровня будет достаточно довольно общего, аналитического описания. Но для настройки BPMS такие модели не годятся. Нужно проектировать исполняемые процессы, а для этого надо знать, как работает BPM-система.

Конечная цель почти любого BPM-проекта – это автоматизация процессов, поэтому компетенция «Разработка приложений от модели и по аджайлу» является крайне важной. Хотя бы кто-то из участников проектной группы должен ей владеть.

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

Для создания результата, который нужен потребителю, умение «Проектирование взаимодействия с пользователями» является весьма важным. Кроме того, команда проекта может использовать методы CJM (Customer Journey Mapping).

Структура компетенций по ролям

Как отмечал Ицхак Адизес, в природе не бывает людей, обладающих всеми компетенциями одновременно. Но эту проблему можно решить, формируя команду проекта из сотрудников, компетенции которых взаимно дополняют друг друга. С учетом опыта реальных проектов можно рассмотреть следующую ролевую структуру BPM-проекта:

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

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

Рассмотрим необходимые уровни «прокачки» компетенций по каждой роли BPM-проекта. Ниже представлено экспертное мнение автора статьи. Еще раз хочу подчеркнуть, что нерационально требовать, например, от бизнес-аналитика уровня понимания бизнес-видения и знания организации, как от топ-менеджера. С другой стороны, странно было бы требовать от топ-менеджера детального знания нотации BPMN и т.п.

В статье я часто употребляю термин «компетенция». В Википедии приводится следующее определение: «Профессиональная компетенция — способность успешно действовать на основе практического опыта, умения и знаний при решении профессиональных задач». В Трудовом кодексе РФ термина «компетенция» нет, но определяется «квалификация», которая понимается как совокупность «знаний-умений-навыков».

В чем разница между «умением» и «навыком»? Рассмотрим определения:
• умение – реализация способности осмысленно выполнять какую-либо работу, требующую теоретических знаний и практических навыков;
• навык – это сочетание стереотипных физических действий и мыслительных операций, которые выполняются в необходимой последовательности как часть определенного вида работы.

Структура трансформационных компетенций представлена в следующей Таблице 1 и на Диаграмме 1. Уровни «прокачки» каждой компетенции показаны по шкале от 1 до 5 баллов и определены следующим образом:
• Уровень 1: Достаточный. Компетенции приближаются к базовым требованиям стандарта.
• Уровень 2: Удовлетворительный. Компетенции полностью удовлетворяют стандарту.
• Уровень 3: Хороший. Компетенции полностью удовлетворяют и по ряду аспектов превышают требования стандарта, четко выражены.
• Уровень 4: Очень хороший. Компетенции по многим аспектам превышают требования стандарта, четко выражены, сохраняются в течение длительного периода.
• Уровень 5: Отличный. Компетенции на уровне лучших отраслевых практик, существенно превышают требования стандарта, четко выражены, сохраняются в течение длительного периода.

Под стандартами в данном случае подразумеваются внутренние стандарты компании, полностью или частично основанные на внешних стандартах.

Структура операционных компетенций представлена в следующей Таблице 3 и на Диаграмме 2.

Структура технических компетенций представлена в следующей Таблице 4 и на Диаграмме 3.

Если коротко, то можно предложить для обсуждения следующее видение:
• у бизнес-заказчика (владельца процесса) должны быть очень хорошие (хорошие) трансформационные компетенции. При этом операционные могут быть удовлетворительные (достаточные), а технические – достаточные (ну не должен Зам. ГД уметь писать скрипты на C#);
• руководитель проекта должен обладать очень хорошими (хорошими) трансформационными, хорошими операционными и очень хорошими техническими компетенциями (особенно для проектов, ориентированных исключительно на автоматизацию бизнес-процессов);
• эксперту в предметной области (специалисту структурного подразделения) требуется удовлетворительные трансформационные, достаточные (удовлетворительные) операционные и технические компетенции (т.е. не обязательно его детально учить настройкам BPMS, если только он потом не будет лично настраивать систему в своем подразделении);
• процессный методолог должен обладать очень хорошими трансформационными компетенциями (местами хорошими), отличными и очень хорошими операционными компетенциями, очень хорошими и хорошими техническими компетенциями. Это самый сложный случай. Найти такого методолога весьма сложно, но он стоит своих денег;
• бизнес-аналитик должен обладать удовлетворительными (местами, хорошими) трансформационными компетенциям. Операционными компетенции должны быть очень хорошие. Технические – хорошие (удовлетворительные).

Из представленных выше таблиц видно, что набор компетенций и необходимая глубина их освоения разные. Как их оценить? Для решения этой задачи можно использовать шкалы оценки.

Шкалы для оценки компетенций

Рассмотрим шкалы оценки трансформационных компетенций (разработаны автором статьи). Шкала для первой компетенции «Умение готовить бизнес-обоснование и наличие видения» представлена на рис.1. Шкалу следует читать так: требования к компетенциям суммируются слева направо. Например, на втором уровне сотрудник не только «Умеет оценивать ROI, привлекательность для бизнеса», но и «Может определять и оценивать риски для бизнеса».

Шкала оценки по компетенции «Управление проектами» представлена на рис.2.

Шкала оценки по компетенции «Знание организационной структуры и корпоративной культуры» представлена на рис.3.

Шкала оценки по компетенции «Коммуникации» представлена на рис.4.

Шкала оценки по компетенции «Методы управления изменениями» представлена на рис.5.

Теперь перейдем к шкалам оценки операционных компетенций. На рис. 6 представлена шкала оценки по компетенции «Выявление бизнес-процессов».

На следующем рисунке 7 представлена шкала оценки по компетенции «Моделирование, анализ и проектирование бизнес-процессов».

Шкала для компетенции «Регулирование и организация процессной работы» представлена на рис. 8.

На следующем рисунке 9 представлена шкала оценки по компетенции «Управление эффективностью процессов».

На следующем рис. 10 представлена шкала оценки для компетенции «Подбор инструментов, поддерживающих методологию BPM».

Шкала для компетенции «Архитектура и дизайн решения» представлена на рис. 11.

На следующем рис. 12 представлена шкала оценки для компетенции «Знание программного обеспечения BPM».

На следующем рис. 13 преставлена шкала оценки для компетенции «Разработка приложений от модели и по аджайлу».

Шкала для компетенции «Имитационное моделирование и оптимизация процессов» представлена на рис. 14.

Шкала для компетенции «Проектирование взаимодействия с пользователями» представлена на рис. 15.

Для каждого уровня каждой шкалы должны быть разработаны контрольные вопросы (как минимум, 2-3), ответы на которые позволят подтвердить достижение соответствующего уровня сотрудником. Создание таких вопросов (критериев) сопряжено, как минимум, с рядом проблем:
• возможность неоднозначной интерпретации вопроса;
• субъективность оценивающего субъекта;
• недостаточная квалификация оценивающего субъекта (например, оценивать знание нотации BPMN не может человек, который никогда не видел ни одной модели в этой нотации);
• недостаточно четкие (противоречивые) стандарты, на основании которых могут быть сформулированы вопросы;
• неоднозначная и противоречивая «лучшая» отраслевая практика.

Тем не менее, работать в этом направлении нужно, иначе от идеи оценивать и развивать компетенции участников команды по внедрению BPM-проекта придется отказаться.
Приведу пример контрольных вопросов (система критериев оценки с весами) для первого и второго уровня шкалы «Моделирование, анализ и проектирование бизнес-процессов».

Чтобы перейти на соответствующий уровень по шкале оценки нужно набрать от 75% до 100% по текущему уровню и не менее 50% по следующему уровню.
Например, по Уровню 2 получено 78%, по Уровню 3 – 42%, а по Уровню 4 – 80% (см. Таблицу 7). В этом случае, в качестве подтвержденного может быть выбран только Уровень 2, так как хорошее знание принципов и/или лучших практик не является основанием для высокой оценки конкретных практических навыков базового уровня.

При разработке шкал и критериев целесообразно использовать доступные источники по этой теме.

Учебные программы и материалы для развития компетенций

Для развития требуемых BPM-компетенций внутри компании нужны учебные программы и материалы, но какие именно? Целесообразно рассмотреть следующие базовые учебные программы (см. таблицу 8).

Очевидно, что некоторые из указанных программ уже могут использоваться в компании (проводилось обучение). Необходимо выяснить несколько вопросов:
• кто и когда был обучен?
• каковы реальные полученные сотрудниками знания, навыки, умения?
• планируется ли включать этих сотрудников в команды по BPM-проектам?

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

Глядя на количество курсов, представленных в таблице 7, можно подумать, что получилась программа MBA. Чтобы не измучить людей теорией, каждый курс должен быть максимально практическим – обязательно нужно в него включать:
• конкретные документированные методики;
• примеры;
• сложные и полезные практические задания (а не просто рефлексию после вопроса типа: «Посмотрите на лампочку – что вы чувствуете?»).

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

Для развития компетенций руководителей и сотрудников я провожу для компаний семинары и тренинги по различным программам, в том числе:

1. «Внедрение системы управления бизнес-процессами», 2 дня.
2. «Стандартизация бизнес-процессов», 2 дня.
3. «Моделирование бизнес-процессов в нотации BPMN», 2 дня.
4. «Описание, анализ и регламентация процессов в Business Studio», 2 дня.
5. «Имитационное моделирование и анализ процессов в Business Studio», 2 дня.
6. Прочие специальные программы, составленные по запросам заказчиков.

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

Одновременно с разработкой учебных программ необходимо создать систему подтверждения компетенций. Она может включать систему тестов для каждого уровня и роли в проекте. Частично можно подтверждать компетенции с использованием внешних сервисов. Рассмотрим два из них.

Подтверждение компетенций

Организация ABPMP Russian Chapter разработала профессиональный стандарт «Специалист по процессному управлению», который утвержден приказом Министерства труда и социальной защиты Российской Федерации от «17» апреля 2018 г. № 248н. Так называемая «Функциональная карта вида профессиональной деятельности», представленная в Стандарте, включает следующие «Обобщенные трудовые функции»:
• A. Регламентация процессов подразделений организации или разработка административных регламентов подразделений организации, уровень квалификации 6.
• B. Проектирование и внедрение кросс-функциональных процессов организации или административных регламентов организации, уровень квалификации 6.
• C. Проектирование и внедрение системы процессного управления организации, уровень квалификации 7.
• D. Проектирование и трансформация процессной архитектуры организации, уровень квалификации 7.

Для подтверждения компетенции Процессного методолога и бизнес-аналитика можно использовать тест, разработанный ABPMP Russian Chapter в соответствии с требованиями профессионального Стандарта. Пройти тест «на здравом смысле» не получится – для правильных ответов на многие вопросы нужно не просто знать теорию, но иметь опыт практического использования соответствующих методик и инструментов.

Рассмотрим другой сложный, но полезный путь развития и подтверждения компетенций в области BPM – это прохождение сертификации OMG CERTIFIED EXPERT IN BPM™ 2 (OCEB™ 2). Структура тестов представлена на следующем рисунке 16.

К числу участников BPM-проектов относятся и представители бизнеса, и технические специалисты. Очевидно, что они используют на практике различные наборы методов и инструментов, поэтому программа OCEB 2 разделена на два направления после базового. Это сделано для того, чтобы была возможность проходить сертификацию среднего и продвинутого уровня в зависимости от вашей профессиональной ориентации. Сертификация на каждом уровне требует сертификации на нижестоящих уровнях.

Базовый уровень OCEB 2 требует от участника BPM-проекта определенных знаний и умений. Экзамен этого уровня, в первую очередь, охватывает базовые концепции и термины бизнеса в целом, целеполагания и планирования, управления бизнес-процессами. Далее тест включает область моделирования бизнес-процессов с использованием нотации BPMN 2 (40% теста). Экзамен завершается темами качества процессов, организации процессной работы, разработки системы показателей для управления процессами.

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

Для чего проходить тесты OCEB 2? Для меня лично важны следующие возможности:
• получить признание профессионализма в области BPM;
• систематизировать свои знания в области BPM и узнать что-то новое;
• понять и использовать структуру вопросов для построения внутрикорпоративной системы тестирования;
• ознакомиться с лучшей литературой по теме (на английском языке);
• подтянуть свой английский.

Кроме сертификации по проф.стандарту и OCEB 2, можно пройти учебные курсы и сертификацию у поставщиков различных BPM-систем. Конечно, желательно изучать ту систему, которую предполагается использовать в компании. Но если решение пока не принято, то можно использовать свободно (бесплатно) распространяемые BPM-системы и методические материалы к ним (например, российская RUNA WFE и др.). К сожалению, пока в книжных сетях практически нет учебных курсов (методических пособий) для самостоятельного изучения современных BPM-систем.

Итак, можно отметить следующие возможности по подтверждению компетенций для BPM-проекта:
• внутрикорпоративная система сертификации;
• сертификация по специальности «Специалист по процессному управлению»;
• сертификация OMG OCEB 2;
• сертификация у поставщиков программного обеспечения для BPM;
• сертификация специализированных тренинговых компаний.

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».

Декабрь 2019 г.

В статье Владимира Репина обсуждаются вопросы использования нотации BPMN в качестве корпоративного стандарта проектирования бизнес-процессов компании. Рассматриваются аргументы «За» и «Против» применения. Представлены предложения по организации обучения сотрудников. Приводится практический пример внедрения нотации на крупном предприятии. Обсуждаются «подводные камни» использования нотации BPMN на первых этапах проекта.

Какие нотации используют компании для описания процессов сегодня?

Многие успешные компании, внедряющие технологии автоматизации бизнес-процессов, используют нотацию BPMN. Многие, но не все… Более того, в РФ существует огромное количество средних и крупных предприятий, на которых вообще отсутствует принятый корпоративный стандарт проектирования бизнес-процессов. Какими средствами они «рисуют» процессы? Чаще всего в MS Visio используют набор объектов для «Простой блок-схемы». Бывают ситуации хуже, когда в компании одновременно применяют 3-4 разных подхода к описанию процессов, причем все они нестандартные и реализованы в различных «нотациях» и программных продуктах, включая MS Excel и Power Point.

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

К чему приводит такая практика проектирования бизнес-процессов? Во-первых, схемы процессов понятны весьма узкому кругу лиц, а не всем сотрудникам компании. Во-вторых, такие схемы, чаще всего, носят аналитический характер. Это означает, что процесс описан весьма укрупненно, без деталей. Таки схемы нельзя «исполнить». Если попытаться выполнить работу как указано на схеме, то сразу возникнут вопросы, ответов на которые схема не дает. Это звучит странно – как схема, предназначенная для описания алгоритмов, дает сбои при описании процессов для бизнеса? Конечно, ответ заключен не в наборе используемых значков нотации. Причина — в идеологии формирования схемы.

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

Ситуацию с использованием устаревших подходов частично усугубляет наличие в крупных компаниях действующих систем электронного документооборота. То, что в них творится, назвать автоматизацией бизнес-процессов можно весьма условно. Большинство руководителей это понимает, но не знает возможностей современной BPMS (Business Process Management System) в части автоматизации процессов и, особенно, применения концепции «Документ без документа». Вообще, относительно недавно вступил в стадию умирания бумажный документооборот, а теперь и электронный документооборот должен умереть, оставив вместо себя автоматизированные процессы с нужным набором данных. В BPMS, если потребуются, документы можно формировать автоматически, так сказать, «налету».

Использование нотации BPMN в качестве корпоративного стандарта дает возможность не только проектировать процессы, но и внедрять в массы идеологию исполняемых процессов в купе с новыми ИТ-технологиями, такими как PM (Process Mining), RPA (Robotic Process Automation) и проч. Рассмотрим аргументы «За» и «Против» использования нотации BPMN в качестве корпоративного стандарта.

Почему нотация BPMN: «За» и «Против»

Руководителям компании нужно объяснить, что BPMN – это не просто значки другого, незнакомого вида и цвета. Это – инженерный стандарт проектирования исполняемых бизнес-процессов, обладающий следующими преимуществами (плюсами):
• наглядность, понятность и красота схем;
• после базового обучения можно начинать с использования ограниченного набора объектов;
• BPMN — стандарт ISO с 2013 года;
• BPMN де-факто использует большинство разработчиков BPMS.

Да, BPMN – сложный стандарт. Однако, даже начинающие при использовании ограниченного набора объектов и понимания сути метода (исполняемый процесс, токен, экземпляр) могут проектировать вполне качественные схемы. Более того, применение сложных семантических конструкций без действительной практической необходимости может только осложнить работу, привести к созданию неоправданно сложных схем или вообще исказить смысл процесса до неузнаваемости. С чем бы сравнить? Это как неопытный спортсмен, не освоивший базовую технику бросков, начинает пытаться применять сложные и опасные приемы. Я уверен, что можно обучить сотрудников, так сказать, использовать верхушку айсберга. Этого на первых порах будет достаточно. Крайне важно, чтобы сотрудники компании научились формировать наглядные, понятные и красивые схемы. Много раз на практике наблюдал ситуацию, когда запутанная, уродливая схема после соответствующей доработки становится красивой, а главное, понятной участникам процесса и внутреннему заказчику – руководителю.

Что важно донести до руководителей?

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

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

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

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

Как обучать сотрудников нотации BPMN?

Это не так уж и сложно. Нужно:

1. найти хорошего специалиста, который умеет преподавать тему, и обсудить с ним учебную программу;
2. подготовить учебные и методические материалы;
3. выбрать инструмент моделирования;
4. разработать внутренний стандарт применения нотации BPMN для проектирования бизнес-процессов;
5. организовать обучение;
6. организовать работу по практическому закреплению навыков моделирования процессов.

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

Обучение проектированию процессов в нотации BPMN я провожу по книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I». Как правило, в течение 4-6 часов слушатели делают практические задания, осваивая элементы нотации от простого к сложному. Затем, они выполняют комплексное практическое задание по проектированию трех связанных между собой процессов. Проводится презентация результатов, анализ схем по чек-листу и разбор ошибок. Для такого обучения достаточно одного дня.

Далее выдаются практические задания, которые слушатели делают в течение недели. Затем проводится рабочая сессия по представлению и разбору схем процессов («домашние задания» я проверяю заранее). После 2-3 сессий участники приобретают навык формирования вполне адекватных схем в нотации BPMN.

На следующем этапе развития можно использовать книгу Игоря Федоров «Нотация BPMN 2.0. Стандарт ISO/IEC 19510:2013 для создания исполняемых моделей бизнес-процессов», сам стандарт и множество практически полезных материалов в сети Интернет.

Идеальным вариантом освоения BPMN является практикум с использованием, собственно, BPMS (например, такой практикум проводит А.А. Белайчук, Президент ABPMP Russian Chapter, с использованием системы BizAgi). Однако, в ряде случаев это сделать технически и организационно сложно. Приходится начинать с простого. Но, как минимум, демонстрацию движения токенов вдоль схемы исполняемого процесса сделать крайне полезно.

Внедрение нотации BPMN как корпоративного стандарта проектирования процессов в Иркутской нефтяной компании

В качестве примера рассмотрим кейс внедрения нотации BPMN в «Иркутской нефтяной компании» («ИНК»), в которой я уже более 1,5 лет сопровождаю проект создания и развития Системы управления бизнес-процессами. Информацию любезно предоставил Юрий Андреевич Федосеев, начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК» (ОБПиС).

За время проекта в «ИНК» удалось сделать многое:
• разработан и внедрен стандарт «Моделирование бизнес-процессов»;
• установлен и настроен инструмент проектирования и анализа процессов (Business Studio 4.2);
• обучено 259 руководителей и специалистов;
• сформировано более 226 схем в BPMN;
• внешние подрядчики (в т.ч. крупные консалтинговые компании) обязаны представлять результаты работы в виде схем BPMN с учетом требований стандарта компании;
• внедрены регламенты сквозных процессов, разработанные на основе схем процессов в нотации BPMN;
• внедряется система оценки процессной зрелости компании;
• проект на стадии выбора BPMS.

Самое главное, что в «ИНК» активно формируется процессное мышление у руководителей и специалистов. Высокая практическая оценка используемых методов и инструментов подтверждается большим количеством запросов от подразделений в ОБПиС с просьбой провести анализ и оптимизацию их процессов. Юрий Федосеев отмечает: «В проектах оптимизации мы преимущественно используем базовый набор элементов нотации (стартовые и конечные события, события отправки и приема сообщения, таймеры, шлюзы и/или… Несмотря на сложность, базовые элементы и логика нотации хорошо воспринимается сотрудниками на обучении. Освоение происходит быстро. Все бизнес-аналитики отдела прошли подготовку по программе Внутренних тренеров, что позволило организовывать качественное обучение для небольших групп на постоянной основе. Мы не ставим перед собой цель описать все процессы Компании. Ценность нашей работы – в помощи, внутреннем консалтинге. Наши клиенты – подразделения, которые хотят разобраться в своей работе и в том, как лучше взаимодействовать с другими в рамках сквозных процессов. И моделирование – это наш основной инструмент в этом деле…».

«Оптимизация процессов Электроснабжения» — так назывался один из проектов «ИНК», в рамках которого использовалась технология описания и анализа процессов в нотации BPMN. По ходу проекта было сформировано 59 процессов в нотации BPMN. Описание и анализ процессов позволил выявить 10 критичных зон безответственности и последствия, к которым наличие этих зон может привести. Прогнозный экономический эффект от устранения зон безответственности составляет около 78,6 млн. рублей в год.

Второй проект с использованием BPMN, как корпоративного стандарта проектирования процессов «ИНК», — это «Оптимизация процессов Капитального строительства». В рамках данного проекта в условиях жестких ограничений удалось выстроить слаженную и эффективную работу подразделений. Основные результаты моделирования процессов на текущей фазе проекта: прозрачный процесс капитального строительства, оперативный доступ сотрудников к схемам процессов и регламентам через корпоративный портал.

Подводные камни внедрения нотации BPMN в качестве корпоративного стандарта

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

Резюме

Хочу отметить, что навык проектирования процессов в нотации BPMN – это только один из многих навыков второй группы компетенций («Операционные») модели Gartner 2013 года, которые необходимы для успешного выполнения BPM-проекта в компании. Это означает, что руководители не должны ожидать «процессно-цифрового чуда» только от того, что они заставили необученных сотрудников с низким уровнем внутренней мотивации «рисовать» схемы процессов. Другими словами, внедрение Системы управления бизнес-процессами компании – это не только проектирование процессов, но их активное улучшение и внедрение изменений, создание методов и инструментов управления бизнес-процессами.

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

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».

Ноябрь 2019 г.

В статье Владимира Репина рассмотрены три нотации моделирования бизнес-процессов, при помощи которых можно создавать графические диаграммы с использованием продукта Business Studio: «Процедура», eEPC, BPMN. Обсуждаются преимущества и недостатки каждой нотации. Приводится сравнительный анализ и рекомендации по выбору нотации для описания бизнес-процессов компании.

Введение

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

В Business Studio представлено три нотации, которые можно для этого использовать: «Процедура», eEPC, BPMN.

Цель статьи – кратко рассмотреть ключевые преимущества и недостатки каждой нотации, а также сравнить их между собой при помощи ряда критериев.

Такой анализ и сравнение может быть полезен при выборе нотации моделирования бизнес-процессов для использования в проекте построения системы управления бизнес-процессами компании.

Нотация «Процедура»

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

Рассмотрим ключевые преимущества и недостатки нотации «Процедура».

Преимущества:
• внешняя простота;
• интеграция с IDEF0 по потокам объектов;
• возможность использования междиаграммных ссылок для интеграции моделей в архитектуре.
Недостатки:
• морально устарела;
• примитивная семантика, в т.ч. отсутствие нормального аппарата шлюзов и событий;
• отсутствие визуальных значков для моделирования движения документов и статусов;
• нельзя использовать промежуточные события;
• некорректная работа имитации;
• невозможность экспорта моделей в BPMS для автоматизации.

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

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

Нотация eEPC

На рис. 2. представлен пример диаграммы процесса в нотации eEPC. Это тот же процесс, который был описан в «Процедуре» выше.

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

Преимущества:
• простота и понятность для исполнителей;
• возможность отображения потока объектов (документов) со статусами;
• адекватное межпроцессное взаимодействие (процессные интерфейсы);
• возможность корректной имитации.
Недостатки:
• ресурсоемка при моделировании + размер диаграммы;
• ограниченная семантика;
• отсутствуют дорожки;
• устарела с точки зрения автоматизации.

Диаграммы в нотации eEPC всегда занимают намного больше места, чем диаграммы в нотациях «Процедура» и BPMN. Кроме того, моделирование в eEPC занимает в несколько раз больше времени, чем в других нотациях.

Нотация eEPC имеет весьма ограниченную семантику. Это приводит к тому, что для сложных практических случаев приходится искать обходные пути для того, чтобы показать нужные аспекты на диаграмме.

В тоже время диаграмма в нотации eEPC является вполне понятной большинству сотрудников. На ней можно отобразить потоки документов, причем со статусами. Можно использовать значок процессного интерфейса для интеграции с другими диаграммами в рамках общей модели компании.

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

В целом, конечно, нотация eEPC, как и «Процедура», безнадежно устарела. Особенно с точки зрения использования моделей процессов для настройки BPM-систем.

Нотация BPMN

На рис. 3. представлена схема процесса в нотации BPMN.
Это тот же самый процесс, который был представлен выше в нотациях «Процедура» и eEPC.

Рассмотрим преимущества и недостатки нотации BPMN вообще, и с точки зрения моделирования процессов в Business Studio, в частности.

Преимущества:
• международный стандарт ISO с 2013 года;
• «де факто» принята всеми разработчиками BPMS;
• семантика, позволяющая описывать сложные практические ситуации;
• возможность отображения потока объектов (документов) со статусами;
• возможность импорта диаграмм из MS Visio;
• возможность экспорта для автоматизации в BPMS.
Недостатки:
• сложная семантика;
• неадекватное межпроцессное взаимодействие в части информационных потоков (задача решается);
• не вся семантика BPMN поддерживается при имитационном моделировании.

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

На схеме в нотации BPMN можно использовать события и логические операторы (в т.ч. весьма сложные). С точки зрения использования человеком, схему можно сделать нагляднее за счет визуализации движения документов со статусами.

В Business Studio можно импортировать схемы процессов в нотации BPMN, разработанные в MS Visio. Из Business Studio возможен экспорт моделей для настройки исполняемых процессов в BPMS.

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

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

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

Попробуем сравнить рассматриваемые нотации по набору критериев.

Сравнительный анализ нотаций

Сравнение нотаций можно сделать по трем группам критериев:

1. Внешний вид диаграмм.
2. Интеграция.
3. Семантика и имитация.

В следующей таблице 1 представлено сравнение по группе критериев «Внешний вид диаграмм». Максимальный балл -10.

В таблице 2 представлена оценка нотаций по критерию «Интеграция».

В таблице 3 представлено сравнение нотаций по группе критериев «Семантика и интеграция».

Выводы

Итоговая оценка нотаций в баллах представлена на следующей диаграмме:

Диаграмма. Итоговая оценка нотаций в баллах.

По совокупности критериев, я рекомендую использовать нотацию BPMN для описания, анализа и регламентации бизнес-процессов на операционном уровне. На сегодня — BPMN – лучшая нотация!

Если, всё-таки, по каким-то причинам вам придется делать выбор между «Процедурой» и eEPC, и если не нужна имитация, то лучшим выбором станет нотация «Процедура». Но если предполагается серьезно заниматься имитацией процессов, то лучше выбрать нотацию eEPC, чем «Процедуру».

Успехов вам при описании и оптимизации бизнес-процессов!

В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»

Январь 2019 г.