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

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

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

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

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

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

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

Кратко опишу разделы, по которым может проводиться оценка уровня зрелости СУБП[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 г.

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

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

Введение

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

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

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

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

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

Постановка задачи

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

Первое. Точка зрения – руководитель 1-2 уровня компании, заинтересованный в оптимизации и цифровизации бизнес-процесса в целом. Обратите внимание, что точка зрения, например, ИТ-специалиста, ответственного за внедрение какой-либо информационной системы (ERP, ЭДО, CRM и проч.) может существенно отличаться от точки зрения руководителя, то есть от «бизнесовой» точки зрения.

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

Итак, схема бизнес-процесса в нотации BPMN в Business Studio 5 должна содержать:

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

Посмотрим, как можно решить указанную задачу средствами Business Studio 5. Разбирать метод будем на простом и наглядном примере.

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

На рис. 1 представлена простейшая схема подготовки, согласования и утверждения некоторого документа «Х». Это, можно сказать, «голый» поток работы (Work Flow). Есть ли компании, которые ТАК моделируют процессы? Как это ни странно, да, есть. Наблюдал в нескольких организациях. Отсутствие возвратов (после согласования/утверждения) и полное отсутствие информации/документов объясняют желанием «упростить» схему и сделать ее «наглядной» для бизнес-пользователей. При этом информацию «о действиях в случае отклонений» выносят в приложения к нормативному документу, а входы/выходы прописывают вручную прямо в самом проекте регламента, а не выгружают автоматически из Business Studio. Использование такого «ручного» труда, на мой взгляд, сродни покупке профессионального перфоратора, который потом не включают в розетку, а долбят дырки в стене вручную.

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

Что можно сделать с такой схемой? Прежде всего, отобразить реальный поток работы – возвраты после согласований.

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

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

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

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

Моделирование информационных потоков на схемах в нотации BPMN в Business Studio

На рис. 3 показана схема с потоком документов, точнее, с движением одного документа (частный случай в рамках нашего учебного примера).
Для того, чтобы показать это движение, использована пунктирная стрелка типа «Association» (термин BPMN).

Если смотреть на схему непредвзято, с точки зрения здравого смысла, то можно задаться вопросом: «Дает ли наличие таких стрелок и значков «Документ “Х”» какую-то дополнительную аналитическую информацию?». Скорее «Нет», чем «Да». Но лишней работы по моделированию это добавляет точно. Возникает вопрос: «А может тогда лучше вообще не показывать эти документы»? Бизнес-аналитики некоторых компаний, которые моделируют движение документов на таком абстрактном уровне, постепенно вообще отказываются от визуализации документов на схемах.

Отмечу, что в проектах мы принципиально не используем справочник «Бумажные документы», только – «Электронные документы», чтобы не дублировать сущности. Так же не используем справочник «Информация». Почему? Любая информация в бизнесе, даже неструктурированное письмо по e-mail или сообщение по WhatsApp, может рассматриваться в качестве документа. Если в Business Studio одновременно использовать справочник «Электронные документы» и «Информация», то может возникнуть ненужная путаница.

С точки зрения анализа реального процесса «Как есть» схема рис. 3 опять неполна и не может быть эффективно использована. Что можно сделать?

На рис. 4 показаны статусы документов. Например, после задачи «Подготовить проект документа» Документ «Х» имеет статусы «Проект» и «Word». Они указывают на то, что документ создан в формате MS Word (статус – «Word») и готов для согласования (статус – «Проект»).

После задачи «Согласовать проект документа», Документ «Х» приобретает статусы «Несогласован» и «Word» или «Согласован» и 1С-ДО, то есть статусы определяются контекстно.

Как технически настроены статусы в Business Studio? Через свойства документа («Свойства объекта» по правой кнопке) можно найти «Статусы» и создать новый термин в справочнике «Термины», означающий нужный статус документа (информации). После этого можно вывести статус на показ, используя функционал Business Studio «Настроить показ параметров».

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

В справочнике «Термины» мы используем следующую группировку статусов (показаны примеры статусов):

1. По жизненному циклу документов:
   1.1. Проект
   1.2. Согласован
   1.3. Утвержден
   1.4. Подписан компанией
   1.5. Подписан клиентом
   1.6. …
2. По форме:
   2.1. Устно
   2.2. Бум.
   2.3. Excel
   2.4. Word
   2.5. e-mail
   2.6. Скан в pdf
   2.7. Скан скан-копии в pdf
3. Внутри ИС:
   3.1. 1C-ERP
   3.2. CRM
   3.3. Business Studio
   3.4. Контур.Диадок
   3.5. …
4. Формализован/неформализован:
   4.1. Неформ.
   4.2. Форма
   4.3. Шаблон

Использование статусов документов (информации) дает важную информацию для анализа бизнес-процесса. Однако, мы не получаем ответа на вопрос: «Как именно передается документ от задачи к задаче?», то есть посредством каких ресурсов, собственно, осуществляется перемещение документа.

Моделирование ресурсов (хранилищ данных) на схемах в нотации BPMN в Business Studio

На рис. 5 показаны объекты типа «База данных» для того, чтобы показать, посредством какого ресурса (среды, хранилища) осуществляется переда документа от задачи к задаче.

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

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

1. Корпоративные ресурсы:
   1.1. 1С
   1.1.1. 1С-ERP
   1.1.2. 1С-ERP-CRM
   1.1.3. 1C-ДО
   1.2. Архивы электронные
   1.2.1. Архив Бухгалтерии
   1.2.2. Архив Юр.службы
   1.2.3. …
   1.3. Архивы бумажные
   1.3.1. Архив Бухгалтерии
   1.3.2. Архив Юр.службы
   1.3.3. …
   1.4. Outlook
   1.5. Сервер
   1.6. WhatsApp
   1.7. ..
2. Персональные ресурсы:
   2.1. РМ сотрудника
   2.2. РС
3. Внешние ресурсы:
   3.1. ЭТП поставщика
   3.2. ЭДО
   3.3. …

На рис. 5 показано, что Документ «Х» передается от задачи «Подготовить проект документа» к задаче «Согласовать проект документа» посредством MS Outlook, то есть «временным прибежищем» для этого документа служит Outlook. Некоторые компании, кстати, умудряются до 80% всех рабочих документов хранить в Outlook, что является проблемой (путаница в версиях документов, долгий поиск, перегрузка сервера, риск потери важной информации и проч.).

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

Моделирование информационных систем на схемах в нотации BPMN в Business Studio

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

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

Информационные системы берутся из справочника Business Studio «Программные продукты», который может быть структурирован, например: так:

1. Офисное ПО:
   1.1. MS Office
   1.1.1. MS Word
   1.1.2. MS Excel
   1.1.3. MS Outlook
   1.1.4. …
2. Корпоративное ПО:
   2.1. 1C-ERP
   2.1.1. 1C-ERP-CRM
   2.1.2. 1C-ДО
   2.1.3. …
   2.2. Business Studio
   2.3. BI
   2.4. …
3. Специальное ПО:
   3.1. Контур.Диадок
   3.2. Контур.Фокус
   3.3. Telegram.Чат-бот
   3.4. ЭТП поставщика…
4. Сетевое и серверное ПО:
   4.1. …

В версии Business Studio 5 нельзя настроить визуальный размер и цвет значков выбранного типа один раз для всей рабочей базы. Это приходится делать вручную на каждой схеме. Мы делаем значок программного обеспечения в виде небольшого четырехугольника и закрашиваем его в «фирменный цвет» соответствующий информационной системы, например, 1С – в желтый.

Информационные системы (программные продукты) связываются с задачами двумя различными видами входящих связей:

• «Поддерживает» — в случае, если ИС используется сотрудником при выполнении задачи;
• «Выполняет» — в случае, если задача выполняется целиком автоматически.

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

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

Зачем одновременно показывать на схеме информационные системы и статусы документов? Ведь и так «всё понятно»? Не всё так просто… Например, документ может быть подготовлен в 1С, выгружен в MS Word и доработан вручную, а потом в виде скана в pdf отправлен клиенту через WhatsApp. В данном примере для выполнения задачи использовалось три программных продукта, но ресурсом (хранилищем), использованным для отправки документа, был WhatsApp. Ресурсами, используемыми для хранения файлов MS Word и pdf, могли быть «РС» (т.е. жесткий диск компьютера сотрудника) или сервер компании.

Моделирование межпроцессного взаимодействия по входам/выходам на схемах в нотации BPMN в Business Studio

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

В нотации BPMN в Business Studio 5 для решения этой задачи можно использовать следующую конструкцию – см. рис. 7. Мы связываем бизнес-процесс «Подготовить данные для проекта документа “Х”» (показан на схеме как свернутый пул) стрелкой типа «Message Flow» с задачей бизнес-процесса «Подготовить проект документа». Такая связь в нотации BPMN означает отправку и получение сообщения. По сути, это управляющее воздействие одного экземпляра процесса на другой экземпляр. Но в Business Studio мы сознательно идем на нарушение стандарта и интерпретируем такую связь просто – один бизнес-процесс поставляет на вход другого бизнес-процесса документы (информацию).

Далее к стрелке «Message Flow» привязывается конкретный документ. На рис. 7 – это «Данные для подготовки документа “Х”». Статус показывает, что это документ в формате MS Excel, а привязанная «База данных» показывает, что ресурсом (хранилищем) для этого документа служит файл-сервер компании.

Таким образом, рассматриваемый контекст нужно читать так: «Бизнес-процесс «Подготовить данные для проекта документа “Х”» когда-то (вполне возможно, что намного раньше, чем стартовал процесс «Подготовить, согласовать и утвердить документ») в процессе своего выполнения создал файл MS Excel и положил его на файл-сервер. Через какое-то время процесс «Подготовить, согласовать и утвердить документ» при выполнении задачи «Подготовить проект документа» обратился к файл-серверу и взял оттуда этот документ.

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

На рис. 8 представлен пример схемы бизнес-процесса, разработанной с использованием представленного в статье метода.

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

Выводы

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

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

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

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

Удачи в проектировании подробных и практически полезных моделей бизнес-процессов в нотации BPMN в Business Studio!

В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член 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 г.

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

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

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

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

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

Создание подпроцессов

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

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

Начнем с группы задач, выполняемых Исполнителем Б. Они обведены красным овалом № 1. Вместо этой группы задач оставим одну – «Выполнить расчет и подготовить презентацию».
Далее декомпозируем эту задачу на нижний уровень, используя так же нотацию BPMN.

На рис. 2 видно, что у этой задачи появился маркер «+» внутри квадрата, а схема в целом стала выглядеть значительно проще.

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

В BPMN используется два понятия: Collapsed Sub Process («Свернутый») и Extended Sub Process («Раскрытый»). Первый показывается в виде задачи с маркером «+» внутри квадрата, второй – в виде схемы процесса. На рис. 3 показан пример: схема без Sub Process (вверху), Collapsed Sub Process (в середине) и Extended Sub Process (внизу).

В Business Studio в силу архитектуры этой системы невозможно показать на схеме процесса Extended Sub Process, только Collapsed Sub Process.

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

На рис. 4 показана схема подпроцесса «Выполнить расчет и подготовить презентацию». В данном случае исполнитель тот же самый, что и на верхнем уровне, так что все корректно (с точки зрения регламентации в Business Studio).

Обратите внимание, что подпроцесс начинается с неопределенного события. Как правильно его называть в Business Studio? Часто я просто указываю «Нужно сделать что-то…» и т.п. в зависимости от сути выполняемых действий. Завершающее событие так же именовано по смыслу.

Рассмотрим далее группу задач 2 (см. рис. 1) и обсудим, как можно поступить в этом случае.

Запуск других процессов путем отправки сообщений

Обратите внимание на группу задач на рис. 1, обведенных овалом под номером 2. Его выполняют «Другие исполнители». Можно было бы создать несколько дорожек, но я специально не стал усложнять схему.
Создадим отдельный процесс под названием «Подготовить данные». Теперь этот процесс можно запустить на исполнение из Процесса А, организовав межпроцессное взаимодействие.

Измененная модель показана на рис. 5. Исполнитель А выполняет задачу «Запросить данные». После нее показано промежуточное событие «Запрос на предоставление данных», которое инициирует на выполнение процесс «Подготовить данные». Он показан в виде свернутого пула над схемой. От события к нему проведена стрелка типа Message Flow.

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

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

На рис. 7 показаны возможные варианты моделирования межпроцессного взаимодействия путем отправки и получения сообщений. Поскольку в Business Studio такие примеры технически сделать нельзя, я использовал моделер Camunda.

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

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

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

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

Схема подпроцесса «Получить данные» показана на рис. 9. Она достаточно проста и не требует комментариев.

Использование типовых процессов

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

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

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

В Business Studio создадим новую модель процесса в нотации BPNM под названием «Согласовать документ». Она показана на рис. 10.

На схеме Процесса А удалим группу задач согласования (овал № 3) и соответствующие дорожки, закроем схему, скопируем в навигаторе процесс «Согласовать документ» и вставим его как задачу в Процесс А, обязательно используя опцию «Вставить как ссылку», откроем схему Процесса А на редактирование и внесем необходимые изменения. На рис. 11 показана готовая схема Процесса А.

Задача «Согласовать документ» на дорожке Руководителя – это типовой (повторно выполняемый) процесс. В терминах Business Studio – это процесс-ссылка.

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

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

Как вы видите на рис. 11, схема процесса стала существенно проще и понятнее.

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

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

На рис. 12 показан фрагмент модели, которая решает поставленные задачи. После выполнения шага «Задача N» одновременно запускается типовой процесс и еще два потока работ.

Внизу схемы показано, что типовой процесс выполняется и затем данный поток работ завершается.
Средний поток («Задача N+1» и далее) продолжается своим чередом.

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

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

На рис. 13 показан фрагмент типового процесса, который отправляет нужное сообщение в рассматриваемый нами процесс.

Сравнение трех методов «декомпозиции» процессов

Сравнение трех рассмотренных нами методов представлено в таблице 1.

Таблица 1. Сравнение методов

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

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

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

Сентябрь 2021 г.

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

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

Из практики известно, что один и тот же процесс любой бизнес-аналитик может смоделировать десятками разных вариантов. И каждый вариант процесса может иметь свою «правду жизни». Какую “правду” выбрать? Ту, которая нужна владельцу процесса. На примере процесса обработки заявки попытаюсь рассмотреть влияние идеологии на моделирование процесса (носитель идеологии – владелец процесса, остается скрытым, но незримо присутствует в данной статье). Обработка заявки – это типовой бизнес-процесс, который «живет» внутри любой организации, – обработки заявки на закупку, заявки на подбор персонала или заявки на какой-либо иной сервис внутри организации. Ниже будут рассмотрены варианты ролевых моделей этого процесса. Процесс описан в максимально простой нотации «процедура», поддерживаемой Business Studio, где постараюсь проиллюстрировать влияние идеологии на описание процесса. Также представлен вариант процесса в нотации BPMN (рис.2).

Для простоты я определяю идеологию как совокупность требований/ценностей/принципов, которые владелец процесса транслирует в процесс всем своим образом действий, стилем управления, способом коммуникаций и т.д. Требования к централизации приемки заявок, требования к контролю качества исполнения заявок (внутренняя оценка, т.е. оценка в компании и/или внешняя оценка качества исполнения заявки), требования к разделению ответственности между исполнителями заявок, требования к фиксации факта/срока выполнения заявки и другие требования – все вместе и в совокупности составляет идеологию, составляющую базу для моделирования целевого процесса «to be». Чаще бывает так, что владелец процесса именно в диалоге с бизнес-аналитиком оттачивает свои мысли, глубже осознает свои требования к настройке “своего” бизнес-процесса в контексте конкретной организации.

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

Свободное текстовое описание бизнес-процесса обработки заявки:
Стартовое событие: регистратор зафиксировал получение заявки от заказчика.

1 шаг: регистрация, квалификация заявки.
Регистратор (сотрудник подразделения, куда поступают заявки по телефону, и-мейл) регистрирует заявку, присваивает ей атрибуты (квалифицирует заявку), и на основе атрибутов заявки определяется состав исполнителей заявки, дальнейший маршрут ее обработки.

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

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

4 шаг: приемка выполнения заявки.
На 4 шаге руководитель принимает заявку и закрывает ее как исполненную или отправляет ее на доработку.

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

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

2 вариант описания процесса:

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

3 вариант описания процесса:

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

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

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

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

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

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

Сергей Третьяк, Эксперт по стратегическому менеджменту, разработке BSC, OKR. Руководитель проектов орг. развития, руководитель отдела организационного развития, руководитель проектного офиса.

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

Четыре метода анализа бизнес-процесса

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

В данной статье я хотел бы рассмотреть четыре метода анализа процессов, которые вполне может использовать любой сотрудник организации, хотя бы в начальной степени овладевший навыками создания графических схем процессов в нотации BPMN (или, шире, — Work Flow). К числу этих методов относятся:
1. визуальный анализ графической схемы процесса;
2. анализ времени выполнения процесса;
3. анализ потерь, возникающих при выполнении процесса;
4. анализ потенциала автоматизации процесса

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

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

На данном учебном примере разберем указанные выше методы анализа и принципы оптимизации.

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

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

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

Далее в статье рассмотрены методы анализа бизнес-процесса на примере разбора представленной схемы (разработана в Business Studio 5).

Анализ графической схемы бизнес-процесса

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

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

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

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

На рис. 2 показан результат визуального анализа графической схемы процесса.

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

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

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

На схеме так же видно, что потребитель процесса (в данном случае – это Роль А, инициатор) не получает результат выполнения процесса – «Расчет». Ему нужно писать и звонить руководителю (Роль Д), выяснять статус и потом «ногами» забирать нужный ему документ. Это плохо.

По результатам содержательного визуального анализа графической схемы процесса выявлены следующие проблемы:
• результат выполнения процесса не передается его потребителю;
• 18% задач не создают ценность, 36% задач – создание ценности под вопросом;
• три возврата, которые увеличивают длительность процесса;
• дублирование задач;
• чрезмерный контроль;
• узкие места (задачи, выполняемые руководителями).

Далее необходимо выполнить анализ времени выполнения бизнес-процесса.

Анализ времени выполнения бизнес-процесса

На рис. 3 показан анализ времени выполнения процесса. Для каждой задачи определяют три показателя:

1. нормативное время выполнения, минут;
2. фактическая трудоемкость, минут;
3. календарное время выполнения, минут.

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

Фактическая трудоемкость – это реальное время, которое сотрудник, в среднем, тратит на выполнение задачи. Она может быть определена экспертным путем или при помощи хронометража.

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

Почему фактическая трудоемкость и календарная длительность могут отличаться? Все просто – процесс может простаивать по различным причинам. Например, руководителю поступил документ на согласование. Реальная фактическая трудоемкость его работы надо документом, например, — 5 минут. Фактическая календарная длительность, в среднем, — 6 часов (с учетом повторного выполнения). То есть большую часть времени документ просто ждет в очереди на обработку. Очевидно, что необходимо организовать выполнения бизнес-процессов так, чтобы нормативное время и календарное время отличались как можно меньше.

Обратите внимание, что нормативное выполнения процесса в целом – около 2,8 часов, а фактическая календарная длительность – 32 часа, то есть почти в одиннадцать раз больше!

На рис. 4 показано время выполнения процесса в виде диаграммы. Видны следующие ограничения, устранение которых позволит существенно сократить длительность процесса. Бизнес-процесс дольше всего простаивает на следующих задачах:

• Проверить расчет.
• Проверить и согласовать расчет.
• Распечатать и передать расчет на согласование.
• Передать расчет на согласование.
• Выполнить расчет количества.
• Выполнить расчет стоимости.

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

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

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

Анализ потерь при выполнении бизнес-процесса

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

1. потери, связанные с перепроизводством;
2. потери, связанные с ожиданием;
3. потери, связанные с транспортировкой;
4. потери, связанные самой обработкой;
5. потери, связанные с ненужными запасами;
6. потери, связанные с ненужными движениями;
7. потери, связанные с производством дефектной продукции.

На рис. 5 показаны потери, которые были выявлены при проведении анализа процесса. Условные обозначения для потерь выбраны произвольно (без использования какой-либо нотации).

Более подробно потери и риски, возникающие при выполнении задач процесса показаны в Таблице 1. Так же в таблице показаны возможные последствия.

Таблица 1. Потери и риски при выполнении процесса.

После анализа потерь целесообразно выполнить анализ потенциала автоматизации бизнес-процесса.

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

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

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

Разработка мероприятий по оптимизации бизнес-процессов

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

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

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

Таблица 2. Мероприятия по оптимизации бизнес-процесса.

Схема бизнес-процесса, полученного по результатам оптимизации, представлена на рис. 7.

Диаграмма по времени выполнения задач бизнес-процесса «Как должно быть» (прогноз) показана на рис. 8.
Нормативное время выполнения процесса – 0,8 часа (сокращение в 3,4 раза).
Прогнозируемое календарное время выполнения процесса (с учетом установленных SLA – максимальное время реагирования на поступившую на выполнение задачу) – 4,3 часа (сокращение в 7,4 раза).
Оценить повышение качества расчета можно будет только набрав определенную статистику выполнения бизнес-процесса после внедрения всех мероприятий по его оптимизации и автоматизации.

Резюме

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

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

Апрель 2021 г.

Зачем нужны версии моделей в Business Studio?

На рис. 1 представлена актуальная архитектура бизнес-процессов некоторой компании (учебный пример). Обратите внимание на категорию процессов «Продажа», группу процессов «Управление заказами» и бизнес-процесс «Обработка заявок и выставление счетов» (А3.4.1.). Видно, что все объекты в группе «Управление заказами» показаны серым цветом. Это значит, что эти модели получили статус «Опубликована» и их нельзя изменить.

До выхода 5-й версии Business Studio эта задача довольно часто решалась следующим образом. Создавалась папка «Модели в работе», а в ней соответствующие папки по процессам, а уже в них путем простого копирования создавались различные версии моделей бизнес-процессов. Я встречал ситуации, когда таких версий было около тридцати для каждого процесса. На рис. 1, например, показаны три версии модели бизнес-процесса «Обработка заявок и выставление счетов».

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

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

С выходом 5-ой версии Business Studio ситуация радикально изменилась. Теперь не нужно создавать бесконечное количество копий моделей «копи-пастом» в актуальной базе, а можно использовать инструмент «Ветки». Как это сделать? Рассмотрим ниже, но для начала обратите внимание на актуальную версию модели процесса, который мы хотим изменить. Она представлена на рис. 2.

Далее вы можете повторять представленные ниже действия на своей базе (для тренировки лучше создать отдельную базу Business Studio).

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

Создание ветки

Для того, чтобы создать новую версию модели процесса на основе уже существующей нужно создать новую ветку. На рис. 4 показан первый шаг. Нужно выйти из Business Studio, запустить его заново. Далее в окне выбора баз данных выбрать нужную базу (в нашем примере – это база «Версии моделей») и войти в режим создания веток. Для этого навести мышь на строку «Actual model», нажать правую кнопку мыши и выбрать «Управление ветками».

В открывшемся окне нужно создать новую ветку, нажав на кнопку «+» слева. На рис. 5 показано, что создана новая ветка под названием «Оптимизация процесса продаж». Затем нужно сохранить изменения.

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

После того, как ветка будет создана, нужно открыть ее, выбрав в списке баз данных, как показано на рис. 6.

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

Создадим новый проект. Для этого в меню «Управление моделью» нужно выбрать «Проекты» и в открывшемся окне создать новый проект. На рис. 7 показано, как заполнены данные для нового проекта под названием «Оптимизация процессов продаж».

Обратите внимание, что выбраны участники проекта – пользователь vvrepin и Ivanov Ivan. В данную базу я захожу как vvrepin. Физическое лицо, ассоциированное с этим пользователем Windows, – Репин Владимир Владимирович. Кроме того я являюсь пользователем BS Portal.

Обратите внимание, что задана проектная роль – «Эксперт проекта». Это означает, что пользователь будет получать уведомления на портале, например, при запуске опроса типа «Согласование». (Описание проектных ролей выходит за рамки этой статьи).

На вкладке «Ветки» нужно выбрать ветку, которую мы создали, как показано на Рис. 8. , а затем сохранить проект.

Далее в меню «Управление моделью» выберите пункт «Выбрать текущие проекты» и поставьте галочку напротив только что созданного проекта.

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

Далее нужно выделить мышкой процесс «Обработка заявок и выставление счетов» и все его операции и нажать Ctrl-Shift-V. В открывшемся окне нужно присвоить статус «В работе», как показано на Рис. 10. Затем открыть схему процесса на редактирование.

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

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

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

Для этого выделите процесс «Обработка заявок и выставление счетов» и все его операции в справочнике «Процессы». Нажмите Ctrl-Shift-V и выберите статус «Проект», как показано на Рис.12.

Теперь можно отправить опрос на портал (предварительно убедитесь, что портал «Портал Компании «Ветки» (условное название – у вас будет свой портал) запущен). В меню «Управление моделью» выберите «Запуск опроса». В открывшемся окне выберите тип опроса «Согласование» и соответствующий (ваш) портал (см. рис 13). Нажмите кнопку «ОК».

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

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

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

Применение ветки

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

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

Далее в меню «Управление моделью» выберите «Применить ветку». Business Studio будет закрыто. В открывшемся окне нажмите «ОК» (комментарий можно не писать). После того, как ветка применится (появится окно «Применение ветки успешно завершено»), зайди в основную, актуальную модель (Actual Model – это название, кстати, можно изменить) и найдите в справочнике процесс, для которого была создана новая версия, как показано на рис. 17.

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

Резюме

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

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

Если вы еще не перешли с версии Business Studio 4 на версию 5, то рекомендую это сделать. И прекратите мучить себя и заказчиков создавая бесконечное количество копий в папке «Модели в работе»!

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

Февраль 2021 г.

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

Зачем моделировать программные продукты в Business Studio?

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

Для чего нужна информация о программных продуктах на схемах типа Work Flow (eEPC, BPMN)? Конечно, в модели такого типа нас интересует, прежде всего, корректный (без логических ошибок) алгоритм выполнения процесса. Движение документов на схеме, взаимодействие по входам-выходам с другими процессами, описание используемого программного обеспечения, рисков и прочих объектов делают из графической схемы модель бизнес-процесса. Это дает нам возможность выполнять анализ процесса «как есть», находить проблемы и выявлять их причины, определять потенциал повышения эффективности процесса за счет реализации ряда мероприятий.

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

Формирование структуры программных продуктов в справочнике

В Business Studio 5 можно создать структуру используемых в компании программных продуктов в справочнике «Объекты деятельности/Программные продукты». На рис. 1 показан пример структуры программных продуктов компании.

В начале создается объект справочника «Информационная система», например «1С». Затем для нее может быть добавлен «Модуль ИС», например «1С: Бухгалтерия». Далее, при необходимости, внутри модуля можно создать «Функцию ИС». В целом, группировка по модулям и функциям может быть многоуровневая.

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

Три способа использования программах продуктов на схеме процесса в нотации BPMN

Способ № 1. Привязка через интерфейс

Рассмотрим три основных способа использования программных продуктов в моделях бизнес-процессов в нотации BPMN. На рис. 2 показана схема процесса (учебный пример). По правой кнопке открыты «Свойства» операции «Собрать информацию». Из справочника программных продуктов в список «Программные продукты» перетянут мышкой продукт «MS Word».

Далее нужно выбрать тип связи программного продукта и операции процесса. Можно использовать два типа связей: «поддерживает» и «выполняет» (вы можете создать любой новый тип связи при необходимости). Какой из них выбрать?

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

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

1. операция выполняется сотрудником, и при этом:
2. какие-то действия выполняются сотрудником в соответствующей информационной системе.

Тип связи «выполняет» можно интерпретировать следующим образом:

1. операция выполняется полностью автоматически в соответствующей информационной системе.

Действительно, что значит, что программное обеспечение что-то «выполняет»? Может ли MS Word что-то «выполнять» сам без участия человека? С моей точки зрения, нет. А вот например, антивирусная система может приступить к проверке автоматически, по расписанию, без участия человека. В этом случае операция «Проверить РС на вирусы» будет полностью автоматический и будет «выполняться» соответствующей информационной системой.

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

Способ № 2. Визуализация на схеме

Программные продукты можно просто перетаскивать мышкой на схему процесса в виде фигуры. Но чтобы это сделать, в Business Studio 5 сначала нужно выбрать тип фигуры. При открытой схеме процесса надо выбрать мышкой программные продукты в палитре элементов и нажать правую кнопку. Далее поставить галочку напротив «Фигура», как показано на рис. 3. После этого можно перетаскивать программные продукты из справочника на диаграмму.

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

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

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

Более глубокий анализ указанных проблем дает возможность обосновать мероприятия по улучшению процесса и внедрению новых информационных систем, например iBPMS+RPA вместо тяжеловесной, неудобной и устаревшей СЭД.

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

Как быть в случае, если операция выполняется полностью автоматически? На рис. 6 показан один из допустимых вариантов. Можно одновременно использовать маркер автоматического выполнения («вызов внешней функции или сервиса») и тип связи «выполняет». По типу связи вы всегда сможете отфильтровать все операции процессов, выполняемые автоматически. Кстати, в Business Studio 5 можно настраивать визуализацию параметров для стрелок, используемых в модели. Это удобно.

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

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

Способ № 3. Представление в виде отдельной дорожки

В Business Studio 5 появилась возможность использовать программное обеспечение в качестве дорожки на схеме в нотации BPNN. На рис. 7 показана измененная схема процесса, на которой модуль «FI-CO» показан в виде дорожки. Дополнительно для наглядности использован маркер автоматического выполнения операции.
Обратите внимание, что тип связи программного обеспечения с операцией процесса – «выполняет». Таким образом, можно визуально показывать программное обеспечение в качестве полноценного участника процесса.

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

Хотя, возможно, это будет удобно для описания алгоритмов выполнения процессов, полностью автоматизированных в различных системах: веб-сервисы, BPMS, RPA, ERP.

Преимущества и недостатки методов представления программных продуктов в моделях процессов в нотации BPMN

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

Мы рассмотрели различные подходы к моделированию программных продуктов на схемах бизнес-процессов в нотации BPMN в Business Studio 5.

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

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

Январь 2021 г.