Нотация BPMN: ошибки применения для описания неавтоматизированных процессов «Как есть»
Нотация BPMN: ошибки применения для описания неавтоматизированных процессов «Как есть»
В статье Владимира Репина рассматривается вопрос возможности применения нотации BPMN для описания неавтоматизированных бизнес-процессов «Как есть». Обсуждаются элементы нотации BPMN, использование которых при описании процессов «Как есть» недопустимо, так как это приводит к искажению реальной картины деятельности организации и, как следствие, к невозможности проводить анализ и принимать решения по оптимизации бизнес-процессов. Статья будет полезна руководителям и бизнес-аналитикам, перед которыми поставлена задача описания процессов «Как есть» с целью проведения анализа и разработки мероприятий по оптимизации(в том числе автоматизации и цифровизации) процессов.
Введение. Ключевая проблема применения BPMN для процессов «Как есть»
Нотация BPMN, де-факто, является в настоящее время общепризнанной, основной и, практически, единственной нотацией для качественного, можно сказать, инженерного описания исполняемых процессов. Другими словами – процессов, которые можно выполнить. Такой взгляд на процесс нужен в случае, если поставлены цели:
- создать модель процесса «Как есть», адекватную реальной выполняемой деятельности, с целью анализа и обоснования мероприятий по оптимизации;
- разработать регламент выполнения бизнес-процесса (конкретный, понятный руководящий документ для исполнителей, а не обще-руководящий, водянистый, «исотизированный» документ);
- подготовить техническое задание для автоматизации бизнес-процесса в BPM-системе и/или СЭД.
На первый взгляд, BPMN идеально подходит для решения указанных задач. Но есть одна ключевая проблема. Нотация BPMN разработана и предназначена для проектирования бизнес-процессов в исполняемых системах – системах класса Business Process Management (BPMS). Это означает, что смысловые конструкции языка, заложенные в нотации BPMN, должны полностью поддерживаться функционалом конкретной BPM-системы при настройке и выполнении автоматизированного процесса. Если это не так, то вы имеете дело не с BPM-системой, но с продуктом, который только имитирует поддержку нотации BPMN.
Теперь представьте, что мы используем BPMN для описания реальных бизнес-процессов «Как есть». Они, чаще всего, являются «эксельно-аутлуковыми », не используют BPMS, хотя могут быть частично автоматизированы в различных функциональных системах, например, 1С («Функциональная автоматизация»).
Ключевая проблема применения нотации BPMN для описания таких процессов заключается в том, что элементы языка BPMN при создании модели искажают реальную картину, делая схему малопригодной для анализа.
Это утверждение может быть новостью для неопытных бизнес-аналитиков, но, вряд ли, — для профессионалов. Но, даже некоторые профессионалы иногда создают неадекватные реальности модели по различным причинам: недостаток времени, нежелание «заморачиваться» на создание сложной модели «Как есть», игнорирование последствий и проч.
Ниже в статье приводятся примеры часто встречающихся ситуаций, когда использование нотации BPMN приводит к искажению реальной картины деятельности.
Описательная модель и потерянные токены
Большинство аналитиков, которые переходят с создания «описательных» моделей (диаграмма с ромбиками в «доморощенной нотации «а-ля» 1974 год») на BPMN, часто упускают из вида понятие токена и его движение от задачи к задаче при выполнении процесса.
Рассмотрим текстовое описание некоторого кейса:
«Инициатор предоставления отчетов (роль) уведомляет по электронной почте руководителей структурных подразделений о необходимости предоставить Отчеты подразделений в установленный срок (одновременная рассылка нескольким адресатам). Руководители подразделений готовят отчеты и предоставляют Инициатору, который периодически, например, раз в 2 часа (после перекура и кофе), проверяет почту. В случае, если поступил отчет (корректировка отчета, пояснения), то Инициатор выполняет проверку информации. В случае, если в отчете чего-то не хватает или есть неточности, то Инициатор уведомляет об этом руководителя соответствующего подразделения. Когда собраны корректные отчеты по всем подразделениям, Инициатор готовит Сводный отчет и предоставляет его Большому начальнику по электронной почте. Начальник проверяет отчет. В случае наличия замечаний, направляет их Инициатору. Тот, в свою очередь, может внести изменения самостоятельно и/или запросить уточнения у руководителей подразделений».
Бизнес-аналитик, получив такой текстовый кейс, изобразил в нотации BPMN следующую схему – см.рис.1.
Представленный на рис.1 процесс, на первый взгляд, является простым, как две копейки. В начале процесса Инициатор (условная роль) уведомляет руководителей подразделений, каждый из которых должен подготовить отчет за период по своему подразделению. Инициатор получает все отчеты и анализирует их. Если есть замечания к конкретному отчету, Инициатор запрашивает у руководителя соответствующего подразделения уточнения. С точки зрения «описательной» схемы всё выглядит корректно. Но выполнить такой процесс в BPM-системе будет нельзя. Токен на схеме движется только один. Поэтому нельзя запустить несколько задач у нескольких руководителей.
Обратите внимание, бизнес-аналитик подразумевал (это важно – элемент абстракции!), что рассылка уведомлений и получение отчетов выполнятся по электронной почте. В случае несоответствий выполняются повторные запросы по e-mail. С описательной точки зрения схема, представленная на рис.1, вполне понятна. Но с точки зрения нотации BPMN в BPM-системе такой процесс можно будет выполнить только для одного токена и для одной пары «инициатор-руководитель подразделения», что не соответствует условиям кейса.
Специалист по нотации BPMN, искушенный в автоматизации процессов в BPM-системе, возможно, сразу предложил бы другой, корректный вариант – см. рис. 2.
На рис. 2 показано, что сразу после старта процесса запускается необходимое количество (множественный параллельный цикл) подпроцессов, в рамках каждого из которых Инициатор направляет уведомление, получает отчет, проверяет его, при необходимости запрашивает уточнения. После выполнения подпроцессов по всем подразделениям Инициатор готовит сводный отчет и направляет его Большому начальнику. Если у последнего есть замечания и требуются уточнения, то выполняется возврат и запуск подпроцессов, которые необходимы для уточнения информации. Представленная схема всем хороша, кроме одного: она, несколько, не соответствует реальному процессу «Как есть».
BPMN-у – BPMN-ово, регламенту – описательное?
Попытка разработать схему в нотации BPMN, соответствующую реальному процессу «Как есть», без использования семантики BPMN, неприменимой к неавтоматизированному «эксельно-аутлуковому» процессу, показана на рис. 3.
Схема, с точки зрения специалиста по автоматизации в BPM-системе, выглядит «страшненько». Но это, — именно, попытка описать языком нотации BPMN реальный «эксельно-аутлуковый» процесс «Как есть». Кстати, недопустимой крамолой является использование в качестве свернутых пулов руководителей подразделений (человек – это не процесс).
Вдумчивый читатель, определенно, уже понял основную идею – язык BPMN плохо подходит для описания реального, неавтоматизированного процесса «Как есть». Еще вдумчивый читатель, наверное, спросит: «А не нарисовать ли нам, для упрощения, обычную описательную модель процесса вообще без логических элементов — просто как набор последовательно выполняемых задач, а потом описать эту работу текстом?». Да, можно. Но это будет означать отказ от BPMN как инструмента и возврат к морально устаревшим описательным, примитивным схемам. С другой стороны, если схема и описание практически решают задачу, то почему бы и нет? Но есть риск, что использование двух разных подходов в одной организации будет путать неискушенных в методах моделирования руководителей и специалистов.
Возможно, когда-нибудь появятся более естественные, близкие к реальности языки описания того, как реально действует человек (сотрудник в офисе). Строгое следование алгоритму (путь токена), без прерываний и спонтанного (или по требованию) переключения с задачи на задачу – это модель для робота, но не для человека (хотя в BPMN есть спонтанный- Ad-Hoc подпроцесс, но его редко используют любители строгих алгоритмов). Описание «человеческого» процесса для языка BPMN, похоже, задача непосильная…
Конечно, с практической точки зрения, мы допускаем определенные абстракции, неточности, несоответствия реальному процессу. Главное, чтобы модель годилась для понимания и принятия решений. Но надо четко понимать возможности и границы применимости BPMN — языка исполняемых процессов.
Стартовые события процесса
Рассмотрим кейс. Исполнитель периодически смотрит почту. В случае, если поступило письмо клиента, он начинает что-то делать… На рис. 4 показана схема соответствующего процесса. Очень многие неопытные аналитики, увидев в BPMN маркер конверта тихо радуются и начинают его применять везде, где есть какие-либо «сообщения», запросы, письма и т.п. Но в BPMN стартовое событие-сообщение имеет четкий смысл – автоматический запуск экземпляра процесса на исполнение. В случае (см. выше), когда клиент присылает запрос по e-mail и сотрудник вручную смотрит почту, никакой экземпляр процесса автоматически не запускается. То есть так использовать язык BPMN некорректно – это несоответствие реальности. А как нужно? Да просто использовать стартовое событие неопределенного типа…
Следующий кейс. Исполнитель анализирует дебиторскую задолженность и, в случае превышения лимита, начинает что-то делать… Бизнес-аналитик рисует схему, представленную на рис. 5 и… опять ошибка несоответствия.
Событие-условие (триггер) в BPMN обозначает автоматический старт экземпляра процесса в случае, если в системе изменилось какое-то условие (например, А стало равно B). Но в рассматриваемом случае это не так – Исполнитель смотрит в базу и вручную запускает работу с ДЗ в случае, если видит превышение. Другое дело, когда автоматически в системе выполняется некоторый код и у исполнителя появляется соответствующее сообщение и новая задача…
Событие-сигнал – это очень специфический элемент нотации BPMN (см. рис. 6). В реальной жизни аналогом его может служить, пожалуй, только уведомление, переданное через систему оповещения, например, о пожарной тревоге. Да и то «с натяжкой», так как получают этот сигнал не экземпляры процессов, а люди (человек – это не процесс). Даже веерная рассылка по e-mail или через мессенджер не является аналогом, поскольку такие сообщения могут быть вообще не прочитаны, а если прочитаны, то совершенно необязательно повлекут за собой какие-либо действия. Поэтому использовать сигнал на схемах процессов «Как есть» не рекомендуется.
Завершающие события
Событие «Завершение» (в народе – «Терминатор») – очень специфическая конструкция BPMN, которая может использоваться только при описании процессов, предназначенных для исполнения в BPM-системе. Когда срабатывает завершающее событие такого типа, все токены в рамках экземпляра процесса будут остановлены и экземпляр процесса в целом будет завершен.
Рассмотрим пример, представленный на рис. 7. Это процесс согласования договора с поставщиком. В случае, если у представителя Службы безопасности (СБ) есть сомнения в надёжности контрагента и он отказывает в согласовании, то процесс переходит на задачу «Уведомить поставщика об отказе в заключении договора» и после нее срабатывает терминатор. По замыслу бизнес-аналитика это означает, что все задачи согласования, которые выполняются в это время, будут остановлены, а другие задачи не будут начаты… Но как в реальном процессе его участники (согласованты) узнают о том, что получен отказ от СБ? Только за счет веерной рассылки или сообщения в общем чате, через звонки. Сами по себе, выполняемые ими задачи не смогут быть остановлены «Терминатором». Таким образом, использование терминатора для описания процесса «Как есть» приводит к искажению реальной картины процесса.
Шлюзы
Эксклюзивный шлюз по событиям является еще одним элементом BPMN, который технически может быть реализован в BPM-системе, либо в ERP, но тогда программистами должен быть написан специальный код.
На рис. 8 слева показан пример использования эксклюзивного шлюза по событиям. Менеджер отправляет счет на оплату клиенту. Далее ПРОЦЕСС ждет на эксклюзивном шлюзе по событиям возникновения одного из двух альтернативных событий: либо счет оплачен, либо с момента его выставления прошло 2 рабочих дня. Если знаешь нотацию BPMN, то всё понятно… Только вот не понятно, как именно в реальном «эксельно-аутлуковом» процессе «Как есть» это реально будет выполняться.
Гораздо проще применить обычное решение – использовать простой эксклюзивный шлюз, как показано справа на рис. 8. Над задачей «Проверить поступление денежных средств» показан нормативный период, в течение которого менеджер обязан проверять поступление денежных средств по счету.
Вообще, промежуточное событие-условие («Триггер») можно использовать на модели «Как есть» только в случае, если в информационной системе (например, ERP) действительно срабатывает некоторый код и сотрудник получает соответствующую задачу на исполнение.
Передача информации между задачами процесса
На рис. 9 слева показано, что выходом «Задачи N» является «Документ», который поступает в «Задачу N+1». Но как именно? Что за документ, в какой форме, с каким статусом, посредством какого программного продукта передается? Схема не дает ответа на вопрос. Является ли это недостатком нотации BPMN? Только в том смысле, что нотация не требует жестко моделировать эти аспекты. При формировании схемы исполняемого процесса в BPM-системе их отражать визуально не нужно. Чего нельзя сказать об информации о структуре документа, его статусе и прочее (нужны для настройки структуры данных, проектирования экранных форм, действий с переменными).
Справа на рис. 9 показано, как мы моделируем в Business Studio. Для полноты картины показываем статус документа (например, в скобках после названия), посредством чего он передается (в данном примере – через MS Outlook), какое ПО используется при выполнении задач. Схема явно становится информативнее, хотя, это — уже не BPMN… Подробнее о нашем подходе к моделированию потоков информации в нотации BPMN именно в Business Studio можно прочитать в статье «Моделирование информационных потоков в нотации BPMN в Business Studio 5».
Выводы
Итак, я рассмотрел несколько примеров, когда семантика нотации BPMN неприменима (плохо применима) для реального «эксельно-аутлукового» процесса «Как есть».
В качестве выводов хочу еще раз напомнить читателю, что очень важно всегда:
- четко формулировать цель создания модели бизнес-процесса;
- понимать, что за процесс вы описываете (реальный «Как есть» или новый для исполнения в конкретной BPM-системе – используемые элементы нотации BPMN могут существенно отличаться; это нужно учитывать в «Соглашении по моделированию»);
- адекватно ситуации использовать семантику нотации BPMN, а в случае нестандартного ее использования, четко определить допустимую в конкретной компании интерпретацию (например, в «Соглашении по моделированию»).
Удачи в описании бизнес-процессов «Как есть» с использованием нотации BPMN!
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Октябрь 2023 года.
Внедрение процессного подхода в компании «Фронтсайд» с применением Business Studio
Внедрение процессного подхода в компании «Фронтсайд» с применением Business Studio
В статье описан реальный проектный опыт внедрения процессного подхода в компании «Фронтсайд» с применением программного продукта Business Studio, приведены примеры моделей бизнес-процессов, а также результаты проекта.
Компания «Фронтсайд»
Компания «Фронтсайд» занимается инжинирингом и производством фасадных систем для объектов с особыми требованиями к внешнему виду или процессам строительства и обслуживания. Компания работает на российском рынке с 2001 года. В ассортиментном портфеле представлены модульные фасадные, стеновые и кровельные системы на основе сэндвич-панелей, в том числе: уникальные решения для вертикального и горизонтального монтажа, конструктивные решения для углов зданий, а также эксклюзивные декоративные элементы. Уникальные для рынка продукты компании идеально подходят для реализации современных проектов для бизнеса и решения амбициозных задач.С более подробной информацией о компании и ее уникальных продуктах можно ознакомиться на сайте frontside.ru.
Начало проекта
В 2022 году при проведении анализа работы компании было выявлено, что большинство бизнес-процессов не формализованы, встречается дублирование функций, пересечение полномочий, а также зоны безответственности, отсутствует единый стандарт регламентации. Были выделены бизнес-процессы, которые необходимо изменить, оптимизировать или разработать и внедрить «С нуля». Также была выявлена необходимость определить и зафиксировать владельцев бизнес-процессов.
В ноябре 2022 года был запущен проект по внедрению процессного подхода с применением программного продукта Business Studio.
Целями проекта являлись:
- структурирование и визуализация, повышение прозрачности бизнеса с дальнейшей целью повышения эффективности компании;
- выявление процессов, создающих ценность для клиентов;
- освоение и использование инструмента для оптимизации и реорганизации бизнес-процессов.
Спонсором проекта выступил генеральный директор Дмитриев А.В., руководителем проекта была назначена Котик Н.П., были выбраны эксперты Теплова Е.Б., Дворецкий С.А, а также приглашены консультанты Репин В.В. и Калошина Л.Н.
Разработка архитектуры и моделирование бизнес-процессов
На первом этапе проекта руководство компании прошло тренинг Владимира Владимировича Репина «Внедрение системы управления бизнес-процессами» .
Для достижения целей проекта по визуализации, структурированию и повышению прозрачности бизнес-процессов была выбрана система для описания, оптимизации и регламентации бизнес-процессов предприятий, построения корпоративной архитектуры Business Studio. Основными критериями выбора были удобство и функциональность инструмента, а также наличие возможности регламентировать и анализировать бизнес-процессы.
Затем ключевые специалисты были обучены работе в Business Studio на популярном тренинге В.В. Репина «Business Studio 5: моделирование, анализ и регламентация бизнес-процессов».
Задачей ключевых сотрудников было непосредственное описание, моделирование и анализ бизнес-процессов компании в программном продукте Business Studio, а также дальнейшее обучение рядовых сотрудников.
Для моделирования бизнес-процессов верхнего уровня была выбрана нотация IDEF0. Данная нотация используется для создания функциональной модели, отображающей структуру и процессы системы, а также потоки информации и материальных объектов, связывающие эти процессы. На схеме, смоделированной в IDEF0, наиболее наглядно можно отобразить входы, выходы, управляющие воздействия и механизмы бизнес-процесса.
На рис.1 представлена контекстная диаграмма компании «Фронтсайд».
Входами для осуществления деятельности компании были определены:
- Рыночная информация (поступающая с Рынка).
- Потребность в товарах и услугах (поступающая от Клиентов).
- Сырье и сервисы (от Поставщиков).
- Человеческие ресурсы (поступающие из Общества).
- Финансовые ресурсы (от Собственников).
В результате осуществления деятельности определены следующие выходы:
- Информация для рынка (передается на Рынок).
- Товары и услуги (для Клиентов).
- Потребность в сырье и сервисах (передаются Поставщикам).
- Специалисты (возвращаются в Общество).
- Возврат инвестиций (Собственникам).
Управляющее воздействие на осуществление деятельности компании оказывают:
- Видение и цели Собственников.
- Эстетические нормы Общества.
- Законы, нормы и правила Государства.
Далее архитектура бизнес-процессов «Фронтсайд» была декомпозирована на 7 подпроцессов (рис.2):
- Управление бизнесом компании «Фронтсайд».
- Маркетинг.
- Продажи.
- Исполнение заказов.
- Обеспечение операционной деятельности.
- Обслуживание производственной инфраструктуры предприятия.
- Управление техническим развитием и обеспечение качества.
Бизнес-процесс «Исполнение заказов» состоит из пяти ключевых для бизнеса блоков:
- Управление исполнением заказов.
- Снабжение.
- Производство.
- Складская логистика.
- Транспортная логистика.
Вовлечение сотрудников в проект
Между ключевыми сотрудниками были разделены 7 основных направлений бизнеса. В задачи ключевых сотрудников входили как непосредственный сбор информации по процессам, анализ данных, моделирование бизнес-процессов в Business Studio, так и координация встреч по проекту, взаимоувязывание входов-выходов процессов между собой, обучение экспертов (владельцев) процессов, а также донесение до рядовых сотрудников основных принципов процессного подхода.
В данном проекте чувствовалась заинтересованность руководства, а также ключевых сотрудников в важном деле внедрения процессного подхода.
В ходе моделирования бизнес-процессов ключевые сотрудники (эксперты) были активны, вовлечены в проект и заинтересованы в описании, а затем и улучшении своих процессов.
Важнейшей задачей руководителя проекта было вовлечение в проект людей. До сотрудников в доступной форме доносилась информация для чего нужен проект по внедрению процессного подхода, проводились презентации, обучения. На стратегическом уровне была показана связь между достижением результата проекта и достижением стратегических целей. Проводилась индивидуальная работа с директорами. Были выявлены активные директора, которые поддерживают изменения и улучшения, подхватывают идеи и распространяют их в своих подразделениях. С директорами, которые сразу не включились в проект, проводились встречи, презентации с рекламой улучшений, показывали удачные примеры внедрения с участием активных директоров, проводился внутренний PR достижений.
Оптимизация бизнес-процессов «На ходу»
При активном включении владельцев процессов в проект внедрения процессного подхода, появлялась возможность оптимизировать процессы «На ходу». Например, на этапе анализа одного бизнес-процесса, эксперт компании увидел проблемные места процесса и сразу предложил внести улучшения в модель, а потом уже в реальную практику работы.
При таком подходе важно сразу оценить, как предложенные изменения повлияют на другие бизнес-процессы. Поэтому руководитель проекта принимал решения по каждому конкретному предложенному случаю и направлению. Где-то было принято решение моделировать процессы «as is», где-то «to be», а если были выявлены процессы, которых нет, но в разработке которых нуждается компания, то они были включены в план моделирования.
Например, в процессах группы «A6 Обеспечение операционной деятельности», в «HR сопровождении» были разработаны и внедрены несколько бизнес-процессов, которых ранее в компании не существовало.
Моделирование бизнес-процессов в нотации BPMN
Модели процессов 3-го и нижележащих уровней были разработаны в нотации BPMN. Данная нотация позволяет наиболее наглядно и информативно отобразить исполнение процесса, визуально показать входы, выходы, используемые программные продукты, базы данных, документы.
В ходе проекта эксперты бизнес-процессов проявляли активность. Например, эксперты бизнес-процесса «Снабжение» самостоятельно разработали таблицу, по которой готовились к встречам по моделированию в Business Studio (рис.3). Важно отметить, что такая таблица была размещена в общем доступе, заполняли её несколько экспертов. Таким образом достигалось единообразие и взаимоувязка процессов по входам-выходам, а также эксперты этого бизнес-процесса контролировали по информации из таблицы, чтобы не было дублирования функций. После заполнения таблицы, эксперты бизнес-процесса собирались на моделирующую сессию и достаточно быстро создавали модель процесса в нотации BPMN.
Пример бизнес-процесса
При моделировании бизнес-процесса «Контроль исполнения договора поставки» (рис. 4) эксперты отмечали, что все семь типов договоров контролируются совершенно по-разному, за них отвечают разные специалисты, поэтому будет семь совершенно разных бизнес-процессов Контроля исполнения Заказов поставщиков (по типам договоров).
При погружении в эти процессы оказалось, что общее все же можно выделить. Таким образом появились типовые бизнес-процессы «Организация доставки Заказов поставщиков», «Организация оплаты Заказов поставщику», «Анализ и устранение причин задержки поставки». Данные типовые процессы используются во всех семи процессах контроля исполнения заказов (рис.5).
Особенности выполнения проекта
После того, как завершится моделирование бизнес-процессов классификатора, проект будет продолжен уже в части оптимизации существующих описанных бизнес-процессов.
В апреле 2023 года активная фаза моделирования бизнес-процессов сменилась на анализ и тестирование изменений в нескольких пилотных процессах. Были выбраны несколько процессов:
- по одному процессу создана новая модель и сейчас ведется выбор программного продукта для его автоматизации;
- по одному процессу запущен проект реорганизации;
- также еще одному процессу открыт проект с целью оптимизации, снижения потерь и повышения удовлетворенности заказчика.
Было принято решение сфокусироваться на данных ключевых процессах, моделировать остальные процессы ради моделей, в архив, не стали.
В ходе выполнения проекта стало ясно, что некоторым процессам требуется реинжиниринг, даже не стали тратить время на моделирование «как есть», т.к. выявили очень вариативные процессы.
Также выявили процессы, которые совсем не стандартизированы, все работают по-разному, поэтому руководителем проекта было принято решение двигаться постепенно, разрабатывать маленькие улучшения по процессу и внедрять их. Сначала проводились интервью, опрашивали сотрудников, как выполняется процесс, собирались данные по процессу, после чего аналитики предполагали для обсуждения гипотезу по улучшению процесса.
Важно отметить, что внедрение процессного подхода неразрывно связано с методами бережливого производства. После завершения этапа моделирования, собираются аналитические данные, все отклонения. Каждое отклонение от модели процесса фиксируется как инцидент, разбираются, почему произошло отклонение. Возможно, исполнители забыли, что теперь процесс должен выполняться по-новому и продолжают работать по-старому. Тогда проводится дополнительное обучение, сотрудники детально разбираются в выполнении процесса. Возможно, требуется уточнение процесса, тогда снова проводится интервью с владельцами, формируется скорректированная модель.
Котик Н.П., Директор по развитию компании «Фронтсайд»: «…Без методов бережливого производства процессный подход, как мне кажется, работает не так эффективно. Модель без использования инструментов бережливого производства будет не оптимальной. Это очень кропотливая и длительная работа, которая позволяет увидеть каждую мелочь, каждое несовершенство процесса, зафиксировать инциденты. В общем виде процессный подход и бережливое производство – про то, как выстроить процесс и найти потери…»
В компании значительное внимание уделяется работе с идеями, применяются методы генерации идей для улучшения процессов.
Достигнутые результаты
Проект внедрения Системы управления бизнес-процессами в компании «Фронтсайд» продолжается. Но уже можно говорить, что были достигнуты следующие ключевые результаты:
• Построена архитектура бизнес-процессов компании в нотации IDEF0. Модели декомпозированы до процессов в нотации BPMN.
• Были внесены изменения в организационную структуру предприятия.
• Внутри компании сформировалась крепкая команда единомышленников, которые готовы внедрять улучшения в свои процессы. Те сотрудники, которые не поддерживают улучшения, не готовы меняться сами и менять свои процессы, покинули компанию. Из положительных моментов также можно отметить обновление персонала.
Трудности и рекомендации
В ходе моделирования бизнес-процессов команда проекта столкнулась с нечетким разграничением ответственности по процессам, исполнителям было сложно определить границы процессов, ответственных (зачастую люди не понимают цель тех или иных ежедневно выполняемых действий, не могут разделить задачи, пытаются решить все и сразу).
Это требует от команды проекта проведения масштабного анализа процессов, подготовки весомых аргументов для внедрения изменений.
Команда, которая приходит в проект, должна быть профессиональна, подготовлена, обучена, лично верить в вектор развития, поставленные цели, запланированный результат. Требуется вера и большой труд в разработке и внедрении изменений.
Котик Н.П.,
Директор по развитию компании «Фронтсайд»
Калошина Л.Н.,
Ведущий консультант по бизнес-процессам команды BPM3.RU
Репин В.В.,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Сентябрь 2023 года
Архитектура бизнес-процессов: многомерность, сценарии, способы визуализации
Архитектура бизнес-процессов: многомерность, сценарии, способы визуализации
В статье Андрея Манюхина приводятся примеры визуализации процессных моделей как в общепризнанных нотациях в среде Business Studio, так и в свободных нотациях. Разбираются плюсы и минусы, условия применения тех или иных способов визуализации процессных моделей. Статья адресована как бизнес-аналитикам, так и менеджерам, которые интересуются процессным управлением.
Введение
Современные условия характеризуются слабым представлением бизнес-заказчиков о профессиональных стандартах для специалистов в области описания и оптимизации бизнес-процессов. В этой связи хочется напомнить о существовании такого стандарта (https://abpmp.org.ru/resource/profstandard/). Много «около-процессных» специалистов заявляют об оптимизации бизнес-процессов: в последнее время набирают популярность, так называемые, «подразделения операционных улучшений», которые обычно занимаются точечными фрагментарными улучшениями на уровне операций, но преподносят это как бизнес-процессы. В результате, бизнес-заказчик теряется в многообразии методов, часто разочаровывается, появляется предвзятое негативное отношение к описанию и оптимизации бизнес-процессов, в их настоящем понимании.
Команда консультантов BPM3.RU имеет обширную практику построения процессных архитектур и в данной статье автор делает попытку систематизировать подходы и предоставить читателю наиболее оптимальные для каждой конкретной ситуации.
Правильный подход, ставший классикой
Рассмотрим построение процессной архитектуры на примере процессной модели закупок для операционной деятельности. Данная модель создана мной на основе практик российских и зарубежных производственных компаний в учебных целях. Модель создана с точки зрения директора по закупкам. На рис.1 представлена контекстная диаграмма (А-0).
Понимая окружение (контекст) процесса операционных закупок, декомпозируем процесс на 6 процессных категорий (групп процессов), как показано на рис.2.
Часто приходится слышать такое мнение, что процессная архитектура – вещь умозрительная и не существует никаких критериев группировки процессов в категории, и, вообще, архитектура не нужна и можно просто описывать процессы нижнего уровня. Хотел бы поделиться критериями группировки процессов. По результатам своего опыта я выделяю два основных критерия группировки процессов:
- Единый владелец группы процессов,
- Единый результат (выход) группы процессов.
Так, например, в представленной модели владельцами процессов инициирования закупок являются подразделения бизнес-заказчиков. В результате процессов инициирования появляется электронный документ – Заявка на закупку. Владельцем группы процессов проведения закупочных процедур является подразделение закупок, результат – решение о выборе поставщика.
Процессная модель операционных закупок в виде реестра представлена на рис. 3.
Как мы видим, реестр получился многоуровневый. Глядя на реестр, можно увидеть, что процесс закупки может осуществляться в отношении товаров и услуг, существует также шесть типов закупочных процедур, решение о выборе поставщика может принимать Закупочная комиссия либо уполномоченное лицо, поставщик и номенклатура могут быть уже известными или новыми, договор может быть типовым или нетиповым, таможенное оформление может потребоваться либо нет, то же самое – инспекции и экспедирование. Получается несколько десятков сценариев. Как будет выглядеть реестр процессов без архитектурного решения? А выглядеть он будет, как я начал показывать на рис.4, имея целью посчитать количество возможных вариантов (сценариев).
В реестре расписаны варианты проведения аварийной закупки, их восемь, далее я указал количество вариантов по каждому типу закупочной процедуры. В итоге, по закупке товаров получается 44 сценария, плюс – столько же по услугам. Итого, получается 88 (!) сценариев и, соответственно, процессов. Очевидно, что ряд подпроцессов будет дублирован n количество раз. Хорошо, что я семантически верно обозначил эти процессы, на практике бывает, что так чётко названия не обозначают, и появляется сотня процессов, найти нужный из которых можно только путём последовательного перебора… Такие решения часто понятны только их создателям. А бизнес-заказчик всегда одной из важных целей ставит порядок и прозрачность процессов и зон ответственности…
Конечно же, для связи процессов существуют методы отражения в виде межпроцессных взаимодействий в виде свёрнутых пулов и стрелок типа message flow. Но, опять же, чтобы эти взаимодействия увидеть, необходимо последовательно открывать все процессы. Часто бывает нужно показать наиболее важные сценарии и сделать это можно при помощи процессов-ссылок, как показано на рис. 5. На примере закупки стандартных товаров у единственного поставщика по импорту.
Тот же самый процесс с помощью ссылок можно сделать в нотации BPMN, как показано на рис.6.
В реестре обычно для таких процессов завожу папку «Типовые цепочки процессов (on-demand chains of models)», как показано на рис.7.
Таким образом, типовые процессы (сценарии) являют собой третье измерение процессной модели не нарушая, при этом, логики процессной архитектуры.
Несомненными плюсами такого подхода являются: 1) возможность представления архитектуры процессов, сгруппированной в логике цепочки создания ценности с отражением владельцев групп процессов, 2) возможность представления архитектуры процессов в виде сценариев, последовательности запуска тех или иных процессов. Оба представления, как показывает практика, востребованы бизнес-заказчиками.
Свободные нотации для презентационных целей
Часто аудитория слабо ориентируется в нотациях. Более того, менеджменту обычно нравятся простые красочные картинки. Ту же самую модель закупок можно изобразить вот в таком виде, как показано на рис.8.
По сути, это — графическое представление реестра процессов. Но, для презентационных целей смотрится гораздо интереснее.
Сценарий закупки у единственного поставщика представлен на рис.9.
Важно отметить, что подобные картинки хороши для понимания контекста и общего смысла, но они не предназначены для анализа процессов и формирования каких-либо выводов. Для анализа и оптимизации существуют другие нотации и методы, например, — BPMN.
Нередко приходится встречать совсем экзотические картинки с изображениями машинок, корабликов, домиков, фигурок человечков. Но, об этом, как об описании процессов даже не стоит говорить. Да, я бы и не говорил, если бы создатели таких схем не выдавали их за описания бизнес-процессов…
Выводы
Таким образом, хотелось бы подчеркнуть важность архитектурных моделей бизнес-процессов, как системной практики, позволяющей упорядочивать модели, разграничивать зоны ответственности.
Сценарии позволяют отобразить на верхнем уровне, как и в какой последовательности «включаются» процессы, что представляется важным для бизнес-заказчиков.
В презентационных целях бывает полезно для общего понимания отойти от нотации, «оживить» картинку, но, — не более того. Далее необходима кропотливая работа по описанию и оптимизации процессов.
А.Е. Манюхин,
МВА, консультант по управлению
Май 2023 г.
Бизнес-процессы: от визуализации к автоматизации
Бизнес-процессы: от визуализации к автоматизации
В статье Владимира Репина приводятся примеры моделей бизнес-процессов «As is» («Как есть»), «To be Medium» («Как должно быть, переходная»), «To be Max» («Как должно быть, целевая») в нотации BPMN в Business Studio. Представленный методический подход к описанию процессов позволяет визуально увидеть переход от существующей ситуации к перспективной. Это важно для собственников и руководителей организации для решения задачи обоснования изменений и планирования автоматизации и цифровизации бизнес-процессов организации.
Введение
Описание бизнес-процессов «As is» («Как есть») является отправной точкой для оптимизации и автоматизации бизнес-процессов организации.
Важно отметить, что эту работу нужно делать с точки зрения бизнес-заказчика, а не программиста. Процесс должен быть описан целиком со всеми его нюансами, а не только действия, выполняемые сотрудниками, например, в 1C-ERP или СЭД. Ограниченная точка зрения на процесс может привести к тому, что не будут выявлены значимые проблемы и выработаны адекватные решения по его изменению.
Для решения указанной задачи должен использоваться адекватный метод, позволяющий четко определять на схемах процессов:
- границы процессов и зоны ответственности сотрудников;
- интеграцию – взаимодействие процессов между собой (прямое и/или через данные);
- сроки выполнения задач;
- возможные риски;
- возникающие потери;
- потенциал автоматизации и цифровизации.
Команда консультантов BPM3.RU выработала свой методический подход к разработке моделей в нотации BPMN в Business Studio. BPMN используется как единый язык, понятный всем заинтересованным сторонам в организации.
Ознакомиться в нашим подходом можно в статьях «Моделирование информационных потоков в нотации BPMN в Business Studio 5» и «Методы визуального анализа графической схемы бизнес-процесса в нотации BPMN».
В данной статье я хотел бы поделиться примерами описания бизнес-процессов с использованием нашего метода и показать, как визуальное представление процессов дает возможность увидеть возможный переход от существующей к перспективной модели с использованием автоматизации и цифровизации.
Примеры моделей бизнес-процессов в нотации BPMN в Business Studio
На рис. 1 представлена модель бизнес-процесса заключения договора с клиентом «Как есть». Ключевые особенности этого процесса:
- много ручной работы;
- дезинтеграция по информационным системам (ручной перенос информации из одной системы в другую);
- отсутствие четкого бизнес-правила по отправке проекта договора клиенту (что сначала: проверка у юриста или отправка документа клиенту).
Видно, что процесс выполняется с использованием MS Outlook и вручную.
Одним из подпроцессов является процесс «Согласование договора с клиентом». Он является типовым (повторно выполняемым). Модель «Как есть» этого процесса представлена на рис. 2. Процесс практически весь «ручной». По ходу его выполнения от задачи к задаче передается бумажный комплект документов.
В Business Studio была подготовлена имитационная модель данного процесса. Специалисты продаж экспертно оценили среднюю длительность выполнения каждой задачи и среднее время ожидания из-за отсутствия ресурсов (загрузка исполнителей другими задачами, ожидание ответов от клиента). В итоге, среднее фактическое время выполнения одного экземпляра процесса превысило 20 рабочих дней. Конечно, это очень долгий срок для такого процесса, особенно в случае торговой компании.
Далее рабочая группа из специалистов продаж, юристов и консультантов команды BPM3.RU разработала несколько моделей нового процесса. Модель «To be Medium» (переходная) представлена на рис. 3.
Новый процесс целиком выполняется в информационной системе: 1C-ДО или BPMS. На схеме представлены комментарии, отражающие ключевые нюансы процесса.
Данная схема была использована в качестве Технического задания для подготовки прототипа исполняемого бизнес-процесса на платформе Elma-365.
Если сравнить рисунки 2 и 3, то изменения процесса очевидны. Руководители и специалисты, обученные нотации BPMN, сразу видят различия. Схема является удобным инструментом формирования ТЗ на автоматизацию – можно обойтись без длинного текстового описания требований, особенно в случае автоматизации процесса с использованием No-code/Low-code системы.
На рис. 4 показана модель бизнес-процесса «Согласование договора с клиентом» в версии «To be Max».
Особенностями модели «To be Max» (перспектива на 1,5-2 года) являются:
- использование Личного кабинета клиента для автоматического взаимодействия с организацией;
- полная автоматизация ряда задач в 1C-ERP;
- использование RPA-модуля (возможно, нейронной сети) для распознавания и сравнения версий договоров, получения/отправки договоров через «Контур.Диадок» и проч.
Интересно отметить, что после создания этой модели стало очевидно, что дорожку «Менеджер по работе с клиентами» можно полностью исключить из процесса – все задачи могут быть выполнены автоматически. Это означает, что сотрудники, находящиеся на рассматриваемой должности, смогут потратить сэкономленное время на привлечение новых клиентов, что положительно скажется на выручке компании.
Если сравнить схемы рис. 1 и рис 4, то различия видны явно. Это важно для наглядного представления возможных изменений руководителям и специалистам организации.
Сравнение моделей «As is», «To be Medium», «To be Max»: свет в окне
В таблице 1 приводится содержательное сравнение моделей «As is», «To be Medium», «To be Max», которое показывает, как изменяются бизнес-процессы при их трансформации из текущего состояния в перспективное.
Таблица 1.
«As is» | «To be Medium» | «To be Max» |
— Полностью бумажно-ручные и/или эксельно-аутлуковые процессы. — «Зоопарк» ИТ-систем. Слабая интеграция. — Значительные потери, низкая эффективность. — Потеря важной информации. — Интеграция: «Ручной процесс-Человек». — Отсутствие SLA (требований по длительности) для задач и процессов. — Отсутствие показателей для управления процессами. | — Процессы в BPMS/СЭД. — Интеграция SRM-CRM-ERP-BPMS. — Устранение потерь. Сокращение сроков. — Повышение эффективности. — Информация не теряется. — Интеграция: «Процесс-Процесс». — Прозрачность и наличие SLA (требований по длительности) для задач и процессов. — Измерение наиболее важных показателей процессов. | — Цифровые решения. Повышение скорости и эффективности. — ЛК клиента и поставщика. — Аналитика данных с применением BI/OLAP. — RPA, спец.решения, «Нейронка». — Интеграция с внешними системами. — Интеграция: «Процесс-Процесс». — Прозрачность и наличие SLA (требований по длительности) для задач и процессов. — Измерение всех необходимых показателей процессов. |
Выводы
Моделирование бизнес-процессов от «As is» к «To be Medium» и «To be Max» в нотации BPMN в Business Studio дает руководителям компании такие преимущества, как:
- наглядное представление и понимание пути перехода от текущего к целевому состоянию;
- оценка возможной цены «светлого цифрового будущего» (трудоемкость и стоимость проектов автоматизации и цифровизации);
- понимание возможности устранения узкого места в лице ИТ-подразделения компании путем передачи значительного объема работ по автоматизации процессов с использованием технологии No-code/Low-code в Процессный офис;
- понимание приоритета цифровой трансформации;
- радикальное сокращение сроков, повышение производительности процессов, «прозрачность» всей системы работы организации для собственников и топ-менеджмента.
Один из главных эффектов от описания процессов «As is», «To be Medium», «To be Max», во многом, психологический. Руководители смотрят на схемы и говорят: «А что, так можно будет?». Они видят, насколько изменится бизнес-процесс, станет меньше ручной, бумажной работы, возрастет скорость выполнения процессов, повысится эффективность.
Удачи в оптимизации и цифровой трансформации ваших бизнес-процессов!
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Май 2023 г.
План проекта внедрения Системы управления бизнес-процессами
План проекта внедрения Системы управления бизнес-процессами
Введение. Что такое СУБП?
Система управления любой организации включает в себя несколько подсистем, например: Система стратегического управления, Система оперативного управления, Система управления финансами, Система управления персоналом, Система управления качеством и другие.
В рамках этих систем исполняются соответствующие бизнес-процессы. Для того, чтобы ими эффективно управлять и целенаправленно развивать, нужна еще одна система – Система управления бизнес-процессами — СУБП. Приведем ее рабочее определение:
СУБП — совокупность методов, инструментов, ресурсов и внедренных бизнес-процессов, направленная на эффективное развитие компании на основе управления каждым значимым бизнес-процессом в рамках его жизненного цикла.
Можно сказать по-другому. Наличие СУБП означает, что в организации внедрена системная практика работы с бизнес-процессами.
Как понять, есть ли в вашей компании такая система и оценить ее текущий уровень развития? Есть довольно много различных методик оценки. Я предлагаю оценивать СУБП по десяти основным направлениям.
Структура СУБП компании и оценка уровня ее зрелости
Кратко опишу разделы, по которым может проводиться оценка уровня зрелости СУБП[1]:
Таблица 1. Структура СУБП.
1. Архитектура бизнес-процессов. | Архитектура бизнес-процессов компании может вообще отсутствовать, либо быть в форме Реестра в MS Excel или «ландшафтной карты» (картинка в MS Visio, MS Word или Power Point). Может использоваться специальное программное обеспечение для создания модели деятельности организации, в котором, как минимум, представлена модель верхнего уровня в виде «плитки» — набора четырехугольников или «рыбок», представляющих из себя процессы верхнего уровня. В более сложном, проработанном варианте – это комплексная модель, где показаны связи процессов верхнего уровня между собой (например, архитектура процессов в нотации IDEF0 в Business Studio). Для поддержания в актуальном состоянии и развития архитектуры в штате Процессного офиса должен быть опытный Процессный архитектор, использующий соответствующий регламент (стандарт) работы. Изменения (дополнения) должны вноситься в архитектуру регулярно. |
2. Управление бизнес-процессами по целям и показателям. | Очевидно, некоторые цели и показатели в компании используются, особенно финансовые. Часто — это цели и показатели структурных подразделений и КПЭ руководителей. Но для управления собственно бизнес-процессами показатели не определены или их очень мало. Должна быть создана система целей и показателей для управления бизнес-процессами, включая паспорта, формы планов/отчетов, панели управления (в BI[2]-системе, на портале Business Studio и проч.), регламенты оперативного управления процессами на основе показателей. Для бизнес-процессов различного типа набор показателей может существенно отличаться. |
3. Система стимулирования руководителей на улучшение бизнес-процессов по КПЭ. | Речь идет о KPI (или КПЭ) руководителей, стимулирующих их не только на выполнение своих функциональных обязанностей, а именно на целенаправленное развитие бизнес-процессов и повышение их производительности и эффективности, сокращение сроков выполнения, повышение качества продуктов/услуг и удовлетворенности клиентов, сокращение затрат и увеличение доходов за счет цифровизации и проч. Не все показатели для управления бизнес-процессами могут быть использованы в качестве КПЭ. Другими словами, для мониторинга и управления бизнес-процессом может использовать набор показателей, только часть которых подходит для КПЭ руководителя. В организации должно быть разработано (скорректировано) Положение о стимулировании персонала. Система KPI (КПЭ) руководителей по бизнес-процессам может быть построена с учетом метода OKR[3] и проч. |
4. Практика описания и анализа бизнес-процессов. | Некоторые компании используют для описания бизнес-процессов нестандартные (внутренние) нотации и плохо подходящие для этого инструменты: MS Excel, Power Point, бесплатные «рисовалки», MS Visio. Внутреннего стандарта по описанию процессов нет. Сотрудники не обучены. Контроля качества схем нет. Полярная ситуация – это когда есть внутренний стандарт описания процессов («Соглашение по моделированию»), применяются стандартные, международно-признанные нотации (IDEF0, VAD, BPMN) и современные инструменты (например, Business Studio), с использованием которых формируется единый Репозиторий бизнес-процессов компании. Руководители и специалисты обучены методам описания и анализа бизнес-процессов, вовлечены в проект и активно участвуют в моделирующих сессиях[4]. Работа по описанию и анализу планируется на основе нормативов трудоемкости. Качество графических схем контролируется. Проблемы и предложения по оптимизации бизнес-процессов документируются и берутся в работу. |
5. Практика оптимизации бизнес-процессов и внедрения изменений. | Самый худший вариант – улучшения выполняются хаотично, от случая к случаю, без плана. Эффект от проектов оптимизации, в том числе, экономический, оценивается формально или вообще не оценивается. Стандартов управления проектами и изменениями нет. Команды не формируются. Руководители и специалисты не обучены методам проектного управления, внедрению изменений… Ситуация в продвинутой компании – есть стандарты и инструменты для управления проектами и внедрения изменений. Формируются и обучаются временные рабочие группы (команды с ролевой структурой). Проекты оптимизации бизнес-процессов планируются и координируются. Ведется работа с персоналом по поддержке изменений. Результаты проектов оцениваются (в том числе по экономической эффективности) и документируются в базе знаний компании. Участники команд премируются в зависимости от достигнутых результатов проектов. |
6. Автоматизация бизнес-процессов (в BPMS). | В компании могут использоваться различные системы автоматизации. Как правило, это — функциональная автоматизация. В таких программных продуктах передача управления от одного сотрудника к другому (поток работы – Work Flow) не поддерживается (всё в ручную – звонки, e-mail-ы и проч.). Для автоматизации бизнес-процессов могут быть использованы как специальные системы класса BPMS[5] и/или СЭД[6], так и функциональные системы с интегрированным в них движком BPM. В компании должна быть налажена работа по выявлению бизнес-требований и функциональных требований по автоматизации процессов, организована работа команд, формирующих соответствующие технические задания. Настройку BPM-систем целесообразно выполнять с использованием технологии Agile. Оценка результативности и эффективности проектов автоматизации бизнес-процессов должна выполняться по определенной методике. Дополнительно могут быть использованы такие системы, как: RPA, Process Mining, AI и другие. |
7. Стандартизация бизнес-процессов. | Плохой вариант – структура и формы регламентов четко не определены. Регламенты пишутся текстом без наличия описания выполняемых бизнес-процессов. Качество документов не контролируется, регламенты своевременно не актуализируются. Жизненный цикл внутренних нормативно-методических документов (ВНМД) не определен. Процессы управления ВНМД фрагментарны и плохо регламентированы. Идеальная ситуация – наличие Стандарта управления ВНМД, включающего описание всех необходимых процессов в рамках жизненного цикла всех ВНМД. Структура и формы регламентов четко определены. Регламенты формируются на основе качественного описания бизнес-процессов в нотации BPMN, причем выгружаются автоматически из системы Business Studio. Деятельность по разработке и актуализации регламентов планируется. Качество документов контролируется. Проводится регулярная аттестация сотрудников на знание регламентирующих документов. В перспективе возможен отказ от регламента, как сущности, и переход к использованию гипертекстовой информационной базы знаний (например, на платформе BS Portal). |
8. Контроль и аудит бизнес-процессов. | Худший вариант – внутреннего аудита нет, или он выполняется слишком формально. Сертифицированных аудиторов нет. Результаты КиПД[7] не контролируются. Базы знаний по результатам аудитов нет. Хороший вариант – утвержден Стандарт внутреннего аудита. Регулярно, по плану выполняется внутренний аудит соответствия бизнес-процессов регламентам, выявляются проблемы и факторы, снижающие производительность и эффективность бизнес-процессов, качество их результатов. Результативность и эффективность КиПД контролируется. База знаний по результатам внутренний аудитов ведется. Штат укомплектован сертифицированными внутренними аудиторами. |
9. Корпоративная система обучения персонала методам процессного управления. | Во многих компаниях такая система отсутствует. Нет учебных курсов в области процессного управления, плана развития персонала. Обучение проводится фрагментарно, неглубоко и от случая к случаю. Идеальная ситуация – внедрена модель компетенций в области BPM (процессного управления) с учетом уровня должностей и ролевой структуры СУБП. Разработаны программы обучения и учебные курсы различных уровней сложности, в том числе дистанционные. Обучение сотрудников проводится регулярно по плану. Используется система аттестации на знание сотрудниками методов и инструментов управления бизнес-процессами. |
10. Процессный офис. | Исходная ситуация – в компании отсутствует функциональное подразделение по внутреннему организационному развитию, либо оно работает формально, загружено задачами, не связанными с процессным управлением. Идеальная ситуация – создан Процессный офис, включая Руководителя, Процессного архитектора, Процессного методолога, Бизнес-аналитиков. Сотрудники владеют необходимыми компетенциями. Утверждено Положение о Процессном офисе и должностные инструкции его сотрудников. Разработаны и утверждены регламенты работы Процессного офиса, например, «Соглашение по моделированию бизнес-процессов», «Регламент описания и анализа бизнес-процесса» и проч. Используется профессиональный инструмент для бизнес-моделирования (Business Studio). Планирование деятельности Процессного офиса выполняется на основе нормативов трудоемкости (с использованием понятия нормо-процесса[8]). Формируется план/отчет работы Процессного офиса (в т.ч. с использованием автоматизированных систем для планирования и контроля), ИПР[9] его сотрудников. Регулярно проводится обучение для повышения квалификации и аттестация бизнес-аналитиков. |
На рис. 1 показан пример оценки уровня зрелости СУБП некоторой организации. Видно, что в 2022 году оценка была весьма невысокая. На 2023 года руководство компании запланировало существенное развитие системы, например разработку архитектуры бизнес-процессов, развитие практики описания, анализа и внедрения изменений и проч.
Роль СУБП в развитии бизнеса
Собственникам и руководителям важно понимать роль СУБП в развитии компании. На рис. 2 показано текущее состояние бизнеса и перспективное состояние, характеризующееся кратным ростом масштабов.
Как перейти от текущего состояния к перспективному? Необходимо стратегическое видение возможностей: новые, инновационные продукты и сервисы, перспективные сегменты рынка, изменения в бизнес-модели, поддержка государства, источники финансирования для активного развития и т.д.
Собственники и руководители должны обладать стратегическим видением и понимать (предвидеть) отрывающиеся возможности для роста бизнеса с учетом быстро меняющегося внешнего контекста, который включает: внутреннею и внешнею экономическую ситуации, действия конкурентов, политические аспекты, инновационные технологии и продукты, новые бизнес-модели и проч.
Какова же роль СУБП в трансформации, развитии бизнеса? Система помогает достигать целей бизнеса при сохранении/улучшении его управляемости и снижении операционных рисков. Дает возможность целенаправленно развивать процессы, сокращая время их выполнения, снижая затраты и устраняя потери, переходить на новые модели работы с клиентами, особенно в части цифровизации.
Можно сказать, что СУБП обеспечивает организацию эффективными бизнес-процессами, которые соответствуют требованиям перспективной бизнес-модели. Но в тоже время, важно отметить, что СУБП не является панацеей, волшебной палочкой или красной кнопкой, нажав на которую можно решить сразу все проблемы компании. Она никогда не компенсирует отсутствие видения перспективной бизнес-модели, серьезные просчеты при принятии ключевых стратегических решений, конфликты на уровне топ-менеджмента и т.д. Но при наличии адекватной стратегии и бизнес-модели, СУБП может дать компании существенные рыночные преимущества, которые выражаются, прежде всего, в скорости трансформации существующих бизнес-процессов для соответствия быстро меняющемуся внешнему контексту, опережению конкурентов, особенно в области цифровой трансформации бизнеса.
Проект внедрения СУБП: видение и цели
С учетом приведенных выше соображений, ключевые цели проекта внедрения СУБП можно определить следующим образом:
- Создать систему работы с бизнес-процессами.
- Достичь целей развития бизнеса с минимальными затратами ресурсов и минимальными рисками.
Созданная в рамках проекта Система работы с бизнес-процессами даст возможность:
- четко определить зоны ответственности руководителей;
- оперативно управлять ключевыми бизнес-процессами, достигая поставленных целей по их результативности, эффективности, качеству;
- целенаправленно развивать (трансформировать) процессы в рамках их жизненного цикла, обеспечивая достижения поставленных стратегических целей;
- внедрять инновационные технологии;
- выполнять цифровую трансформацию бизнеса;
- вовлекать в работу по совершенствованию бизнес-процессов руководителей и специалистов, изменяя корпоративную культуру.
Для формализации видения и целей внедрения СУБП целесообразно разработать документ типа политики, например, под названием «Концепция внедрения СУБП в … компании». В этом документе нужно зафиксировать ключевые термины, принципы, видение структуры СУБП, описать органы управления с их функциями, полномочиями и ответственностью: Процессный комитет, Процессный офис, Процессный архитектор и другие. Данный документ в некоторых компаниях называют «Стандарт внедрения процессного управления»…. В любом случае, руководителям нужно договориться между собой, что они понимают под СУБП, согласовать видение и цели создания системы работы с бизнес-процессами.
Во время или перед формализацией видения СУБП руководителям полезно ознакомиться с опытом других компаний, провести бенчмаркинг. Найти партнеров для бенчмаркинга можно на сайте https://bpmaward.ru – там размещается информация (доклады, видео) о компаниях-финалистах конкурса «BPM-проект года», который проводит Ассоциация профессионалов управления бизнес-процессами (ABPMP Russian Chapter), https://abpmp.org.ru.
Ролевая структура проекта внедрения СУБП
В рамках проекта для крупной организации (холдинг) можно говорить о следующей ролевой структуре (см. Таблицу 2).
Таблица. 2. Ролевая структура проекта
Роль в проекте | Кто | Функции в проекте |
Бизнес-заказчик | Руководитель верхнего уровня (Собственник, ГД, Зам. ГД). | Выработка видения и целей внедрения СУБП, принятие ключевых решений в рамках проекта, выделение ресурсов, вовлечение топ-менеджеров |
Владелец процесса | Руководитель верхнего или среднего уровня. | Постановка целей оптимизации «Пилотных» бизнес-процессов, выделение ресурсов, активное участие в принятии ключевых решений по трансформации бизнес-процессов, оперативное управление бизнес-процессом. |
Руководитель проекта внедрения СУБП | Руководитель среднего уровня или нижнего уровня, отдельно выделенный руководитель. | Управление проектом внедрения СУБП, управление изменениями, организация коммуникаций с заинтересованными сторонами и персоналом компании, привлечение и контроль качества работы внешних экспертов. Организация и контроль качества деятельности Процессного офиса. |
Эксперт в предметной области | Руководитель, ведущий специалист, специалист, внешний привлеченный отраслевой эксперт | Активное участие в моделирующих сессиях, интервью. Передача знаний по бизнес-процессам. Участие в разработке и реализации мероприятий по оптимизации бизнес-процессов. |
Процессный архитектор | Руководитель в структуре Процессного офиса (компании в целом). | Разработка, развитие и актуализация архитектуры бизнес-процессов в Business Studio в нотации IDEF0. Разработка, развитие и актуализация организационной и ролевой структуры, целей и показателей, документов/информации, ресурсов, информационных систем и проч. Разработка нормативно-методических и организационно-распорядительных документов по работе с архитектурой бизнес-процессов. Контроль качества архитектурных моделей бизнес-процессов. Анализ эффективности использования архитектуры бизнес-процессов. Разработка предложений по развитию архитектуры бизнес-процессов (в том числе в рамках стратегического планирования). |
Руководитель процессного офиса | Руководитель среднего уровня. Может починяться Директору по развитию, Директор по управлению эффективностью бизнес-процессов и т.п. | Управление Процессным офисом. Ведение Плана/Отчета работы Процессного офиса. Постановка и контроль задач бизнес-аналитикам. Координация системной работы с бизнес-процессами. Управление коммуникациями и внутренний PR СУБП в компании. Управление проектами развития СУБП. Моделирование, анализ и регламентация бизнес-процессов в нотациях IDEF0 и BPMN в Business Studio. Контроль качества работы бизнес-аналитиков. Привлечение и контроль качества работы внешних подрядчиков в области СУБП и автоматизации бизнес-процессов. |
Процессный методолог | Руководитель или ведущий специалист в структуре Процессного офиса/другого функционального подразделения | Разработка внутренних нормативно-методических документов (ВНМД — методики, регламенты) по всем аспектам СУБП, в т.ч.: «Соглашение о моделировании бизнес-процессов», «Регламент описания и анализа бизнес-процесса», «Регламент выполнения проекта оптимизации бизнес-процесса» и др. Контроль исполнения требований ВНМД СУБП руководителями и специалистами. Разработка и актуализация процессных фреймворков («моделей работы») по ключевым аспектам СУБП. Разработка требований к шаблонам отчетов в Business Studio (паспорта процессов, регламенты, положения, инструкции, в т.ч. для html-публикации и BS Portal) и контроль их реализации в системе. Обучение руководителей и специалистов методам управления бизнес-процессами, в том числе нотациям IDEF0, BPMN и методам моделирования бизнес-процессов в Business Studio. Контроль качества моделей бизнес-процессов в нотациях IDEF0, BPMN в Business Studio. Выборочный контроль качества внутренних нормативно-методических документов. Разработка учебных и методических материалов, материалов для аттестации руководителей и специалистов в области управления бизнес-процессами. Проведение обучения руководителей и специалистов по используемым методам СУБП. Разработка методов вовлечения сотрудников в работу по улучшению бизнес-процессов. Анализ эффективности и развитие методик и ВНМД СУБП. Анализ эффективности использования и планирование развития внутренней базы знаний по бизнес-процессам (html-публикация или BS Portal). Организация и проведение ежегодной оценки уровня зрелости СУБП. Разработка плана развития СУБП на год. |
Бизнес-аналитик | Специалист Процессного офиса/специалист функционального подразделения бизнес-единицы | Моделирование, анализ и регламентация бизнес-процессов в нотациях IDEF0 и BPMN в Business Studio. Координация рабочих групп и проектов по оптимизации бизнес-процессов. Управление графиками и бюджетом проекта по оптимизации бизнес-процессов. Поддержание актуальности справочников объектов в Business Studio (организационная структура, документы, базы данных, программные продукты). Поддержание базы знаний компании по бизнес-процессам (публикация, портал). Разработка функциональных требований и ТЗ на автоматизацию бизнес-процессов (в BPMS, 1C-ERP, 1С-ДО). Проведение внутренних аудитов бизнес-процессов. Разработка целей и показателей для управления бизнес-процессами. Проведение оценки зрелости системы управления. Проведение обучения сотрудников методам управления бизнес-процессами. |
В небольшой организации (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 включает разработку ключевых методик СУБП. Должны быть созданы:
- Глоссарий СУБП.
- Концепция СУБП («Стандарт внедрения СУБП» или «Стандарт внедрения процессного управления»).
- «Соглашение по моделированию бизнес-процессов» (нотации IDEF0 и BPMN).
- Регламент моделирования и анализа бизнес-процесса.
- Регламент выполнения проекта оптимизации сквозного бизнес-процесса.
- Методика разработки целей и показателей для управления процессами.
- Методика выбора процессов для оптимизации.
- Стандарт управления ВНМД, включая формы регламентов (на платформе Business Studio)
- Регламент автоматизации процесса (в BPMS).
- Методика оценки зрелости СУБП.
- Прочие.
Для ускорения разработки примеры методик и регламентов могут быть получены (на различных условиях) от внешнего эксперта (консультанта) и адаптированы к условиям компании (холдинг, гос. структура и т.п.). Ключевыми документами в начале Этапа 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, не требующие сложной интеграции с другими системами. В случае необходимости интеграции подключаются специалисты ИТ-департамента. Такая схема работы позволяет реализовать конвейер по описанию, оптимизации и автоматизации бизнес-процессов компании.
Процессный офис
Ключевую роль в проекте внедрения СУБП играет Процессный офис. С учетом опыта организации деятельности таких подразделений во многих компаниях, я могу выделить следующие ключевые функции Процессного офиса:
- Управление функционированием и развитием СУБП Компании.
- Развитие Методологии управления бизнес-процессами в Компании.
- Управление архитектурой бизнес-процессов Компании.
- Описание и анализ бизнес-процессов Компании.
- Планирование и внедрение изменений в процессах.
- Регламентация и стандартизация процессов.
- Автоматизация (роботизация) бизнес-процессов (совместно с ИТ-подразделениями Компании).
- Поддержка базы знаний по бизнес-процессам.
- Развитие процессных компетенций (совместно с Департаментом по персоналу Компании).
- Проведение внутреннего аудита бизнес-процессов Компании.
- Управление подачей предложений сотрудников по улучшению бизнес-процессов.
- Разработка и внедрение системы целей и показателей для управления бизнес-процессами (в т.ч. KPI).
Платформой для реализации большинства функций Процессного офиса является среда моделирования, анализа и регламентации бизнес-процессов Business Studio.
Кроме того, Процессный офис может использовать, например, ПО Jira для управления задачами и проектами, а также BPMS (Elma, Comindeware и другие) для их автоматизации.
В своей работе Процессный офис может использовать несколько различных планов. В первую очередь, это План развития СУБП компании. Он формируется один раз в год после проведения оценки уровня зрелости СУБП, которая помогает выявить проблемы и наметить пути совершенствования СУБП в следующем году. Далее план может уточняться/корректироваться ежеквартально в зависимости от достигнутых результатов.
Следующий важный и основной документ – это План/отчет Процессного офиса. В него включаются следующие задачи:
- описание и анализ бизнес-процессов «Как есть»;
- разработка мероприятий по оптимизации бизнес-процессов, в том числе проектирование бизнес-процессов «Как должно быть» (промежуточный и перспективный варианты);
- разработка/актуализация регламентов и других внутренних нормативно-методических документов (ВНМД);
- отмена ВНМД;
- автоматизация бизнес-процессов в BPMS;
- проведение обучения и аттестации сотрудников (в области процессного управления);
- другие задачи.
При создании плана необходимо учитывать, что ресурсы сотрудников Процессного офиса ограничены. Целесообразно ввести нормативы трудоемкости выполнения соответствующих задач и планировать работу на их основе.
Поскольку фокус работы нацелен на бизнес-процессы, то ключевым понятием для создания нормативов Процессного офиса является понятие «Нормо-процесс» (термин введен автором статьи – Владимиром Репиным и активно используются в проектах командой BPM3.RU).
Для моделей в нотации BPMN можно привести следующее определение:
Нормо-процесс – это процесс, графическая схема которого содержит не более 12 задач, события, шлюзы, потоки информации/документов, информацию об используемых информационных системах и ресурсах.
Нормативное время создания модели в нотации BPMN для одного нормо-процесса «Как есть» может быть определено в пределах от 4 до 8 часов работы бизнес-аналитика. В этот время входят:
- подготовка к проведению моделирующей сессии (МС), в том числе анализ регламентирующих и рабочих документов по процессу;
- организация проведения МС;
- проведение МС длительностью около 1,5-2 часов;
- доработка модели бизнес-процесса после проведения МС и отправка на согласование участникам МС и заинтересованным руководителям;
- внесение изменений в модель процесса по результатам согласования.
Норматив зависит от нескольких факторов, в первую очередь, — от квалификации бизнес-аналитика. Так же на трудоемкость влияют: требования к модели процесса (степень подробности его описания – требуемая аналитика), функциональные возможности используемого инструмента, степень вовлеченности экспертов в предметной области – руководителей и специалистов, принимающих участие в МС.
Кроме норматива для описания одного нормо-процесса могут быть определены еще нормативы для разработки и актуализации регламента, контроля качества проекта регламента и некоторые другие.
Формирование плана работы Процессного офиса должно выполняться с учетом доступного рабочего времени его сотрудников с использованием разработанных и утвержденных нормативов. Это очень важно для того, чтобы не перегружать работой бизнес-аналитиков и обеспечить высокий уровень качества моделей бизнес-процессов, проектов регламентов, планов мероприятий по оптимизации процессов, паспортов целей и показателей, учебных программ и т.п.
Вовлечение руководителей и специалистов
Одним из ключевых факторов успеха проекта внедрения СУБП является вовлечение руководителей и специалистов в «процессную работу». К числу эффективных методов вовлечения можно отнести:
- проведение учебно-практических сессий с руководством;
- обучение руководителей и специалистов по процессному управлению;
- участие в моделирующих сессиях;
- участие в «пилотных» проектах описания, анализа и оптимизации бизнес-процессов;
- корпоративная wiki, «горячая линия» проекта;
- признание результатов (грамоты, денежные премии по результатам проектов и проч.).
- внедрение системы подачи предложений по улучшениям.
Процессный офис должен активно «продавать» внутри компании идеи, методы и результаты процессного управления, налаживать коммуникации с сотрудниками, информационно поддерживать изменения в процессах.
Риски проекта внедрения СУБП и компенсационные мероприятия
Проект внедрения СУБП, как части новой системы управления организацией, подвержен вполне типовым рискам, к числу которых можно отнести:
- неясное видение целей и целевого состояния и роли СУБП;
- отсутствие общего понимания целей у разных групп заинтересованных сторон;
- отсутствие у руководителей знаний и опыта в области процессного управления;
- отсутствие навыков процессного лидерства (процессное мышление, понимание технологий процессного управления, открытость, сотрудничество);
- недостаточная вовлеченность и мотивация сотрудников;
- сопротивление сотрудников изменениям.
В таблице 3 представлены риски, которые, на мой взгляд, являются ключевыми. Последствия реализации указанных рисков весьма печальны — увеличенные сроки проекта, формальное внедрение, охлаждения руководителей к методам процессного управления и, в итоге, тупик.
Таблица 3. Риски проекта внедрения СУБП и компенсационные мероприятия
Наименование риска | Последствия | Компенсационные мероприятия |
Отсутствие четких целей и видения системы | Сроки. Формальное внедрение. Тупик. | Концепция и план внедрения СУБП. |
Отсутствие вызова (Business Challenge) – важной для бизнеса стратегической задачи | Формальное внедрение. Охлаждение. | Стратегия, видение, бизнес-модель — «Пилотный» проект оптимизации с поддержкой Процессного офиса и применением методик СУБП. |
Недостаточный ресурс | Длительные сроки. Минимальный результат. Охлаждение. Тупик. | Выделение адекватного ресурса. |
Хождение по граблям | Сроки. Качество. Охлаждение. Тупик. | Привлечение экспертов |
Перфекционизм | Длительные сроки. Охлаждение. Тупик. | Работа с ЛПР. Применение Agile. |
Чтобы избежать указанных выше рисков нужно, в первую очередь, сформулировать видение и цели внедрения СУБП в документе «Концепция внедрения…». Далее необходимо понять, какие бизнес-процессы для компании являются ключевыми в текущем контексте и зачем их нужно трансформировать. Проект внедрения СУБП должен помочь решить ключевые проблемы бизнеса (Business Challenge). Кроме этого, нужно выделить на проект адекватные ресурсы и привлечь экспертов (в штат или в качестве внешних консультантов) – носителей методологии и опыта внедрения в других компаниях.
Выводы
Структура плана проекта внедрения СУБП и сроки выполнения его этапов зависят от нескольких аспектов, в первую очередь, от размера организации, ее корпоративной культуры, сложившейся практики работы с бизнес-процессами.
Проект внедрения СУБП вполне реально выполнить за 8-10 месяцев. К этому сроку будут созданы основы системной практики управления бизнес-процессами, которую потом нужно будет развивать и совершенствовать.
При активном участии руководителей и вовлечении сотрудников, выделении адекватного ресурса, проект будет выполнен в срок с высоким качеством результатов.
Удачи во внедрении Системы управления бизнес-процессами на платформе Business Studio!
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Март 2023 г.
[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
Методы визуального анализа графической схемы бизнес-процесса в нотации BPMN
В статье Владимира Репина раскрываются методы визуального анализа графической схемы бизнес-процесса в нотации BPMN в Business Studio 5. Они могут быть использованы для выявления проблем, связанных с выполнением процесса, и разработки мероприятий по его оптимизации. Материал может быть полезен руководителям и специалистам, вовлеченным в проект описания и оптимизации бизнес-процессов компании.
Введение
В настоящее время для многих компаний является весьма актуальной задача анализа, оптимизации и цифровизации бизнес-процессов.
Метод визуального описания бизнес-процессов в нотации BPNM является одним из ключевых для решения этой задачи.
Какие проблемы, связанные с выполнением бизнес-процесса, могут быть выявлены путем визуального анализа графической схемы? В статье я привожу описание возможных методов и некоторые примеры их применения.
Требования к графической схеме бизнес-процесса
Прежде всего определимся с контекстом, точкой зрения и целью анализа.
Контекст – в компании создан Процессный офис, который использует программный продукт Business Studio для моделирования и анализа бизнес-процессов в нотации BPMN. Разработан и используется внутренний стандарт по описанию процессов («Соглашение по моделированию»).
Точка зрения – взгляд на выполняемую деятельность со стороны владельца бизнес-процесса.
Цель – выполнить описание и анализ бизнес-процесса «Как есть» для выявления возникающих проблем и разработки мероприятий по оптимизации/цифровизации бизнес-процесса, создания модели процесса «Как должно быть».
Важно отметить, что возможность визуального анализа определяется качеством и аналитической полнотой графической схемы. Логически некорректная модель с отсутствием какой-либо аналитики («Голый поток Work Flow») вряд ли подойдет для решения указанной выше задачи.
Можно сформулировать четыре группы критериев, которым должна удовлетворять графическая схема в нотации BPMN, которую предполагается использовать для анализа проблем:
- Отсутствие нотационных и логических ошибок.
- Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем.
- Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика).
- Визуальная наглядность и красота схемы (стиль).
Кратко пройдемся по этим критериям. Отсутствие нотационных и логических ошибок является базовым требованием. Схема, содержащая ошибки, тем более, логические, — непригодна для анализа. Для формального контроля качества схемы можно использовать чек-лист, который может содержать, например, следующие разделы:
• корректность формулировок названий объектов на схеме;
• корректность описания входов/выходов;
• корректность описания событий (стартовых, промежуточных, завершающих);
• логические ошибки;
• адекватное описание множества обрабатываемых в рамках процесса объектов;
• архитектурные ошибки (дублирование группы задач вместо использования «Типового процесса» и проч.);
• неоднородность по масштабу выполняемых задач;
• аккуратность исполнения схемы, наглядность.
Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем является ключевым для возможности выполнять анализ. Подробно о создании таких схем я написал в статье «Моделирование информационных потоков в нотации 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 – мощный практический метод, позволяющий быстро получить информацию о возникающих проблемах и наметить пути оптимизации процесса.
В рамках деятельности Процессного офиса для описания и оптимизации бизнес-процессов целесообразно разработать:
- чек-лист формального анализа качества графической схемы бизнес-процесса;
- чек-лист содержательного анализа для выявления проблем и определения возможных мероприятий по оптимизации процесса.
Бизнес-аналитики Процессного офиса и участники временных рабочих групп из числа руководителей и специалистов могут взять на заметку рассмотренные в статье методы, детально проработать их и успешно применять на практике.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Февраль 2023 г.
Вы можете посмотреть видео по данной теме:
Моделирование информационных потоков в нотации BPMN в Business Studio 5
Моделирование информационных потоков в нотации BPMN в Business Studio 5
В статье Владимира Репина представлен метод моделирования информационных потоков, документов, информационных систем и ресурсов (хранилищ данных) на диаграммах в нотации BPMN в программном продукте Business Studio 5. Предлагаемый подход является крайне важным с точки зрения создания моделей «Как есть», позволяющих увидеть, как реально выполняется процесс, зафиксировать возникающие проблемы и предложить мероприятия по его оптимизации и цифровой трансформации.
Введение
В настоящее время моделирование бизнес-процессов в нотации BPMN является одним из инструментов, используемых в компаниях для понимания процессов «Как есть», разработки мероприятий по их оптимизации/цифровизации, формирования регламентирующих документов. Многие компании используют для описания процессов современный программный продукт Business Studio 5.
Участие в большом количестве проектов, в которых выполнялось моделирование бизнес-процессов в нотации BPMN в Business Studio, а так же проведение аудита качества (формального и содержательного анализа) схем бизнес-процессов различных организаций, позволило мне сделать следующие выводы:
- уровень знаний и компетенций по использованию нотации BPMN, к сожалению, всё еще довольно низкий — при моделировании сотрудники допускают много формальных (нотационных) и содержательных ошибок, что делает схемы непригодными для анализа и оптимизации бизнес-процессов;
- функциональные возможности программного продукта Business Studio используются не в полной мере;
- в организациях отсутствует подробная и качественная методика формирования моделей бизнес-процессов, например в виде «Соглашения по моделированию».
Важно отметить, что нотация BPMN в ее текущей версии не предназначена для адекватного моделирования потоков информации и межпроцессного взаимодействия с точки зрения отображения входов/выходов бизнес-процессов. Этот факт является существенным ограничением. Но проблема может быть решена с использованием функциональных возможностей Business Studio.
Представленный ниже метод моделирования в нотации BPMN предназначен именно для Business Studio. В случае применения других программных продуктов метод должен быть скорректирован с учетом функциональных возможностей соответствующей системы.
Постановка задачи
Перед тем, как заниматься моделированием бизнес-процессов «Как есть», очень важно определить точку зрения и цель этой работы.
Первое. Точка зрения – руководитель 1-2 уровня компании, заинтересованный в оптимизации и цифровизации бизнес-процесса в целом. Обратите внимание, что точка зрения, например, ИТ-специалиста, ответственного за внедрение какой-либо информационной системы (ERP, ЭДО, CRM и проч.) может существенно отличаться от точки зрения руководителя, то есть от «бизнесовой» точки зрения.
Второе. Цель – получение модели бизнес-процесса «Как есть», содержащей всю полноту информации о процессе (насколько это вообще возможно на графической схеме).
Итак, схема бизнес-процесса в нотации BPMN в Business Studio 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.2. Согласован
1.3. Утвержден
1.4. Подписан компанией
1.5. Подписан клиентом
1.6. … - По форме:
2.1. Устно
2.2. Бум.
2.3. Excel
2.4. Word
2.5. e-mail
2.6. Скан в pdf
2.7. Скан скан-копии в pdf - Внутри ИС:
3.1. 1C-ERP
3.2. CRM
3.3. Business Studio
3.4. Контур.Диадок
3.5. … - Формализован/неформализован:
4.1. Неформ.
4.2. Форма
4.3. Шаблон
Использование статусов документов (информации) дает важную информацию для анализа бизнес-процесса. Однако, мы не получаем ответа на вопрос: «Как именно передается документ от задачи к задаче?», то есть посредством каких ресурсов, собственно, осуществляется перемещение документа.
Моделирование ресурсов (хранилищ данных) на схемах в нотации BPMN в Business Studio
На рис. 5 показаны объекты типа «База данных» для того, чтобы показать, посредством какого ресурса (среды, хранилища) осуществляется переда документа от задачи к задаче.
Вообще, довольно часто бизнес-аналитики интерпретируют эти объекты как программное обеспечение (хотя для этого есть отдельный одноименный справочник в Business Studio). Это некорректно, на мой взгляд.
Что такое база данных в современных условиях? Можно ли использовать, например, SQL Server без необходимой для доступа к данным прикладной программной оболочки? Конечно, нет. Поэтому мы используем в проектах справочник «Базы данных» в широком смысле в качестве ресурсов – мест хранения документов (информации), например:
- Корпоративные ресурсы:
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.1. РМ сотрудника
2.2. РС - Внешние ресурсы:
3.1. ЭТП поставщика
3.2. ЭДО
3.3. …
На рис. 5 показано, что Документ «Х» передается от задачи «Подготовить проект документа» к задаче «Согласовать проект документа» посредством MS Outlook, то есть «временным прибежищем» для этого документа служит Outlook. Некоторые компании, кстати, умудряются до 80% всех рабочих документов хранить в Outlook, что является проблемой (путаница в версиях документов, долгий поиск, перегрузка сервера, риск потери важной информации и проч.).
Если схема бизнес-процесса предназначена для анализа, то я считаю крайне важным показывать на ней, как именно, посредством каких ресурсов осуществляется передача документов (информации) от задачи к задаче.
Моделирование информационных систем на схемах в нотации BPMN в Business Studio
Наличие ресурсов на схеме процесса не отвечает на вопрос, с использованием каких именно информационных систем выполняются задачи процесса.
В Business Studio есть два способа привязать используемую информационную систему к задаче процесса: через интерфейс или визуально на схеме. Если делать на схеме, то наименование соответствующей ИС попадает (после сохранения схемы) в список используемых ИС, которые можно посмотреть через свойства задачи. Если сделать в обратной последовательности (то есть сначала занести через интерфейс), то потом вывести на схему значок, символизирующий программное обеспечение, автоматически уже не получится.
Мы применяем визуальный способ представления информационных систем на схеме бизнес-процесса, как показано на рис. 6.
Информационные системы берутся из справочника Business Studio «Программные продукты», который может быть структурирован, например: так:
- Офисное ПО:
1.1. MS Office
1.1.1. MS Word
1.1.2. MS Excel
1.1.3. MS Outlook
1.1.4. … - Корпоративное ПО:
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.1. Контур.Диадок
3.2. Контур.Фокус
3.3. Telegram.Чат-бот
3.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 г.
Возможно, вам будет интересно посмотреть видео по этой теме: