В статье авторы раскрывают опыт компании ООО ОКП «АРС» по проектированию бизнес-процессов в нотации BPMN в Business Studio 6 для целей автоматизации в 1С-ДО. Рассматриваются особенности использованного методического подхода. Представлен опыт работы проектной команды. Приводятся примеры конкретных бизнес-процессов. Статья может быть полезной компаниям, выполняющим проект автоматизации бизнес-процессов с использованием 1С-ДО.

Введение

Компания Особое конструкторское подразделение «АРС» занимается проектированием и строительством крупных инфраструктурных научных объектов по заданию Института солнечной и земной физики Сибирского отделения РАН.

Весной 2024 года в компании был создан «Процессный офис» в рамках Управления персоналом и организационного развития. На сегодняшний день в организации работают: процессный архитектор, процессный методолог и два бизнес-аналитика. В качестве платформы для внедрения системы управления бизнес-процессами используется программный продукт Business Studio 6.

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

Методический подход к выполнению проекта

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

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

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

Поэтому в компании был принят следующий подход к проектированию и автоматизации бизнес-процессов в 1С – см. рис. 2.

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

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

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

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

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

«Документ для процесса» или «Процесс для документа»?

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

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

Еще один аспект, который приходится учитывать – это, что одна задача на схеме процесса в BPMN в 1С-ДО состоит из нескольких последовательных действий пользователя в различных экранных формах 1С. Очевидно, что было бы излишне описывать все элементарные действия пользователя в виде задач на схеме в BPMN.

Наоборот, можно для одной задачи в BPMN сделать текстовое описание с экранными формами из 1С-ДО, то есть, фактически создать инструкцию по работе пользователя в системе. В этом случае, модель бизнес-процесса в нотации BPMN дает общее четкое представление о процессе, а описание задачи – инструкцию по действиям пользователя в системе.

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

Моделирование статусов документов

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

На рис. 4 показаны примеры статусов документов. Четкое понимание статусов важно, в первую очередь, для бизнеса. Например, на каждой стадии взаимодействия с контрагентом должно быть понятно, в каком статусе находится договор: «Подписан контрагентом» и предоставлен в виде скана, «Подписан АРС» и отправлен контрагенту в виде скана подписанной скан-копии и т.п.

Но, с точки зрения 1С-ДО и задачи ее настройки, такие статусы могут показаться лишними. Здесь возникает, в определенном смысле, конфликт интересов бизнес-пользователя и программиста 1С-ДО, который стремиться выполнить настройку процесса быстрее и с минимальным количество доработок штатного функционала, в том числе маршрутов.

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

Приведем пример статусов, настроенных в 1С-ДО: «Утвержден, Подписание договора: Подписан, Ознакомление с подписанием: Ознакомление завершено, Прикрепить оригинал: Исполнен, Подписание сторонами: Подписан».

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

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

Главное – создать удобное для пользователя решение. Но после настройки и ввода в эксплуатацию процесса в 1С-ДО, в Business Studio необходимо приводить модель процесса (включая названия документов и формулировки статусов) в соответствие с реализованным программным решением. Кстати, это требование сформулировано приказом по компании.

Автоматизация не равна регламентации

В качестве примера рассмотрим процесс согласования и подписания договора. В 1С-ДО – это один маршрут для конкретного типа договора, включающий в себя как согласование, так и подписание документа.
Этап подписания договора в 1С-ДО включает в себя всего три шага:

1. «Подписание договора».
2. «Ознакомление с подписанием».
3. «Прикрепить оригинал».

Но в реальности процесс гораздо сложнее. На рис. 6 показано четыре разных сценария подписания договора в виде схем в нотации BPNN:

1. подписание на бумаге, первой подписывает организация;
2. подписание на бумаге, первым подписывает контрагент, работа со сканами документов;
3. подписание по ЭДО, первой подписывает организация;
4. подписание по ЭДО, первым подписывает контрагент.

Нужны ли эти сценарии, если уже есть автоматизированный маршрут в 1С-ДО? Да, нужны. Они показывают задачи, которые должны выполнить участники бизнес-процесса, в том числе «оффлайн».

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

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

Выводы

Наш опыт в ОКП «АРС» говорит о том, что выполнение проекта автоматизации процессов в 1С-ДО с использованием моделей бизнес-процессов в нотации BPMN в Business Studio помогает:
• вовлечь руководителей и специалистов компании в работу по проектированию и внедрению перспективных бизнес-процессов;
• получить автоматизированные процессы для бизнеса, четкие регламенты и инструкции для сотрудников;
• создать корпоративную базу знаний по бизнес-процессам в целом и по работе с системой 1С-ДО (это наш важный нематериальный актив);
• в целом, существенно продвинутся по пути создания культуры работы с бизнес-процессами в компании.

Закончить статью хотим слоганом, которые придумал Владимир Репин:

«Если хочешь перемен, изучай BPMN!».

А.Ю. Добровольский,
1-й заместитель Генерального директора ООО Особое конструкторское подразделение «АРС».

В.В. Репин,
к.т.н., доцент, консультант по управлению, член ABPMP Russian Chapter, Процессный методолог ООО ОКП «АРС».

Ноябрь 2024 г.

www.bpm3.ru

Внедрение Business Studio 6: создание системных справочников. Часть II

В своей статье ВладимирРепин рассматривает системный подход к моделированию организации в Business Studio 6. Представлено краткое сравнение нотаций VAD и IDEF0 (Часть I). Рассматриваются практические аспекты создания основных справочников Business Studio 6: организационной и ролевой структуры, документов и статусов, программного обеспечения и хранилищ данных. Статья будет полезна для читателей, перед которыми поставлена задача создания и использования процессной модели организации на основе современных подходов.

Прочитать Часть I статьи

Справочник организационной и ролевой структуры

На рис. 1 показан справочник организационной и ролевой структуры (в Business Studio 6 он называется «Оргединицы»).  Почему этот справочник должен быть частично заполнен в первую очередь? При создании архитектуры бизнес-процессов на схемах верхнего уровня желательно показывать должности владельцев процессов и наименование подразделений – исполнителей.  Руководители верхнего уровня при работе с архитектурными схемами всегда хотят видеть эту информацию.

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

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

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

Роли в процессах и информационных системах (например, в 1С-ДО) могутсоздаваться по ходу проектирования бизнес-процессов компании. Заранее неизвестно, какие именно роли потребуются. Но папки для группировки ролей можно и нужно создать заранее. Правильный подход – создавать папки по названию процессных категорий компании. Но можно и по названию крупных структурных подразделений. Обычно мы используем 2 уровня группировки ролей в виде папок. Натретьем уровне можно создавать сами роли. Кстати, Business Studio позволяет создавать дочерние роли, например, у роли «ИТ-администратор» может быть дочерняя роль «Администратор 1С-ДО» и т.п.

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

Кроме ролей и должностей, Business Studio 6 позволяет создавать так называемые «Группы оргединиц». В такого рода объекты можно включать любые должности и роли из основного справочника с использованием типа связи «Агрегация». Это очень удобно для моделирования различных коллегиальных органов управления, например: «Процессный комитет», «Правление», «Временная рабочая группа по проекту оптимизации бизнес-процесса» и т.п.

Справочники документов и статусов

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

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

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

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

Елена Захарова, Директор департамента управления бизнес-процессами КОМПАНИИ «ДАИЧИ»: «Кроме предложенного подхода, есть альтернативный, который используется в некоторых компаниях, группировка документов по видам, например, Акты, Запросы, Договоры, Счета, Отчеты и пр. Данный подход помогает быстро находить нужный документ с структуре и переиспользовать его для разных бизнес-процессов».

Вторая часть справочника «Документы» — это папка «Утвержденные ВНМД». ВНДМ – внутренние нормативно-методические документы – политики, стандарты, регламенты, положения, инструкции и т.д. Частично  эти документы могут быть сформированы на основе моделей бизнес-процессов, выгружены из Business Studio, согласованы, утверждены, отсканированы. Все утвержденные и отсканированные ВНМД помещаются в справочник Business Studio.

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

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

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

Отмечу, что в Business Studio 6 можно создавать иерархическую структуру документов без использования папок. Это может быть удобно, например, для моделирования пакетов документов, которые состоят из нескольких частей.

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

Business Studio 6 позволяет создавать новые типы связей для удобной вам группировки объектов. Но для этого уже требуется высокая квалификация администратора системы.

Отмечу, что документы в справочнике мы рассматриваем в широком смысле, например «Карточка контрагента» в 1С или «Запрос клиента через форму сайта» — это тоже документы.

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

Для создания статусов используется раздел «Термины» в справочнике «Функциональные объекты». Создавать статусы должен Процессный методолог. Более того, желательно запретить остальным участникам проекта создавать свои статусы. Иначе через какое-то время в справочнике будет много мусора – неадекватно определенных, ненужных для моделирования статусов.    

            Приведу несколько примеров использования статусов документов:

1. «Договор с клиентом», статусы: «Согласован» и «Word»;
2. «Бюджет закупки», статусы: «Утвержден» и «Excel»;
3. «Приказ», статусы: «Утвержден» и «Бум.»;
4. «Контрагент», статусы: «1С-ДО» и «Помечен на удаление»;
5. «Заявление на отпуск», статусы: «Шаблон» и «Word».

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

Справочники программных продуктов и хранилищ данных

            На рис. 4 показан пример заполнения справочника «Программные продукты».

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

Елена Захарова, Директор департамента управления бизнес-процессами КОМПАНИИ «ДАИЧИ»:  «Кроме структурирования программных продуктов в справочнике, мы, как правило, расширяем количество атрибутов в карточке программного продукта, дополняя его необходимыми, например, размещая в ней ссылку на паспорт программного продукта, если паспорта, ведутся ИТ-службой на другом ресурсе. Отдельного внимания требует справочник «Категория программного продукта», который определяет классы информационных систем, например, Системы электронного документооборота (СЭД), Планирование ресурсов предприятия (ERP), Управления взаимоотношениями с клиентами (CRM), Системы автоматизированного проектирования (CAD). Заполняя этот атрибут в карточке программного продукта, в дальнейшем можно проанализировать «парк» используемых программных продуктов по нему и спланировать его оптимизацию или развитие.»

На рис. 5 показан справочник «Базы данных». На схемах в нотации BPMN объект из такого справочника выглядит как бочонок. Для описания процессов удобно интерпретировать эти «базы данных» в широком смысле – как хранилища для документов. Пример:

1. Договор в формате MS Word разработан и хранится на компьютере – используется объект «ПК работника».
2. Далее договор отправляется по e-mail другому сотруднику – используется объект «Outlook», т.е. файл с договором некоторое время «живет» в Outlook.
3. Затем сотрудник загружает договор с 1С-ДО – используется объект «1С-ДО».
4. После согласования договор распечатывается, подписывается и потом попадает в архив – используется объект «Бум.архив».

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

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

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

Что касается справочника «Материальные объекты», то он используется весьма редко. Для моделей процессов в нотации BPMN вполне достаточно объектов из справочника «Документы».

Елена Захарова, Директор департамента управления бизнес-процессами КОМПАНИИ «ДАИЧИ»: «Использование справочника Материальные объекты целесообразно, если на моделях процесса вы хотите выделить такие объекты как Товар, Грузовое место и др. в т.ч. с присвоением им статусов, отражающих стадию жизненного цикла такого объекта. В торговых компаниях мы его используем».

Выводы

В статье рассмотрены основные справочники, которые используются на старте проекта внедрения системы управления бизнес-процессами на платформе Business Studio 6.

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

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

Подвести итог можно следующей фразой:

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

В.В. Репин,

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

Сентябрь 2024 г.

www.bpm3.ru

В своей статье Владимир Репин рассматривает системный подход к моделированию организации в Business Studio 6. Представлено краткое сравнение нотаций VAD и IDEF0. Рассматриваются практические аспекты создания основных справочников Business Studio 6: организационной и ролевой структуры, документов и статусов, программного обеспечения и хранилищ данных. Статья будет полезна для читателей, перед которыми поставлена задача создания и использования процессной модели организации на основе современных подходов.

Клиповый метод моделирования бизнес-процессов

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

В последнее время некоторые клиенты в качестве одного из ключевых критериев выбора системы рассматривают «возможность быстро начать моделировать процессы» — открыл систему и «нарисовал», что нужно. Изучать нотации и методы построения архитектуры не обязательно, ошибки система должна выявлять сама, «токены должны красиво бегать по схеме» и т.п. Не хочется говорить о плохом, но это очень похоже на следствие фрагментированного, клипового мышления. В Интернете нашел такое определение: «Клиповое мышление — это вид сознания, при котором человек воспринимает информацию через короткие форматы и яркие образы и способен быстро переключаться с одной информации на другую из-за поверхностного погружения в её суть. Принято считать, что при клиповом мышлении мозг воспринимает информацию фрагментарно и небольшими порциями. Этому виду сознания приписывают самые разные симптомы и свойства — рассеянность внимания и концентрации, неспособность строить логические связи, неумение воспринимать большие объёмы данных…».  Если у наших молодых процессных аналитиков будет преобладать такой тип мышления, то потребность в сложных, системных решениях постепенно будет сходить на нет.

Как проявляется такой подход при создании корпоративной процессной архитектуры? В справочнике процессов (в BS6 – это «Деятельность…») возникает куча папок по фамилиям сотрудников, в которых они создают модели процессов, например, в нотации BPMN. При этом единые справочники документов, событий и другие наполняются хаотично, бессистемно, как попало. Различные, ненормированные названия, множество дублирующих друг друга объектов. При этом, никакая архитектура бизнес-процессов (в нотации IDEF0 или VAD) не создается.

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

Есть ли альтернатива клиповому моделированию бизнес-процессов? Да, конечно. Во-первых, в организации должны быть процессный архитектор и процессный методолог – специалисты с опытом работы (если их нет, то нужно учить того, кто есть). Во-вторых, нужно разработать внутренний стандарт — «Соглашение по моделированию» и строго ему следовать. В-третьих, нужно обучить сотрудников нотациям моделирования, методам построения архитектуры и знанию функциональных возможностей Business Studio 6 (или любой другой выбранной системы класса Enterprise Architecture).

Ниже в статье я рассматриваю вопросы построения системных справочников для организации работы по моделированию в Business Studio 6. Частично будут затронуты вопросы использования нотаций VAD (Value Added Chain) и IDEF0. Что касается, применения нотации BPMN, то на сайте www.bpm3.ru много статей по этой теме, на основе которых вы можете даже разработать свое «Соглашение по моделированию».

Создание справочника бизнес-процессов

В Business Studio 6 справочник «Деятельность» («Деятельность Visio» — при одновременном использовании двух редакторов, «Деятельность» — при использовании только редактора MS Visio или только встроенного редактора) является основным – в нем создается процессная архитектура организации. Для создания моделей процессов верхнего уровня -, так называемых структурных моделей, — используются нотации VAD и IDEF0. Речь идет о разработке корпоративной процессной архитектуры. Для этого нужен определенный, четкий метод.  Можно создавать архитектуру, основываясь на разных принципах:

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

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

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

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

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

VAD или IDEF0?

В версии 6 Business Studio представлены две нотации для проектирования процессов на верхнем уровне: VAD и IDEF0. Моделировать в VAD можно с использованием встроенного в систему редактора, в IDEF0 – при помощи MS Visio (подробно о методике моделирования в нотации IDEF0 можно прочитать в моей книге «Разработка архитектуры бизнес-процессов компании в Business Studio»).

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

На самом верхнем уровне архитектурная модель в нотации VAD выглядит как плитка (реестр в графической форме), состоящая из категорий процессов («рыбок») без каких-либо визуальных связей в виде стрелок между ними (в самой же модели Business Studio 6 создается связь типа «Композиция» через вложение в родительскую фигуру). Если визуальная связь между объектами в виде стрелок есть (в Business Studio можно выбрать для этого связь «предшествует»), то она может рассматриваться в качестве «декоративной». Никакой осмысленной нагрузки, с точки зрения системной модели, связи такого типа на диаграмме верхнего уровня не несут, так как никакого потока работы (Work Flow), непосредственно запускающего один процесс строго после завершения другого, на верхнем уровне не бывает. Это диаграммы структурного типа, а не алгоритмов.ё

В Business Studio 6 можно создавать несколько представлений архитектуры, в том числе можно:

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

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

Замечу, что при моделировании в нотации VAD на среднем уровне, на диаграмме можно показывать движение документов, исполнителей, информационные системы и прочие объекты, как показано на рис. 5.

Если при работе в Business Studio 6 выбран редактор MS Visio, то можно моделировать бизнес-процессы верхнего уровня в нотации IDEF0. При этом функциональные возможности по настройке визуального вида модели (вывод на показ параметров, визуальные стили) будут работать так же, как было в версии 5. Нужно понимать, что при использовании встроенного редактора и нотации VAD визуальная настройка модели может быть выполнена с использованием совершенно других, новых функциональных возможностей Business Studio 6  – через стили, которые дают широкие и гибкие возможности по «кастомизации» визуального вида диаграмм.

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

            С появлением в 6-й версии Business Studio нотации VAD многие задаются вопросом: «А какую нотацию лучше использовать для моделирования архитектуры бизнес-процессов компании?». С точки зрения профессионального процессного архитектора – разницы нет. Главное – иметь правильный методический подход к созданию архитектуры. Но, тем не менее, я приведу здесь таблицу сравнительного анализа этих двух нотаций.

Таблица 1. Сравнение нотаций VAD и IDEF0 в Business Studio 6

Чем нотация VAD привлекает многих руководителей и бизнес-аналитиков? Схемы можно «нарисовать» быстро. Это, очевидно, ключевое преимущество. Но какой ценой достигается эта быстрота? «Плитку» из «рыбок» в VAD можно сделать, но обоснование структуры бизнес-процессов на каждом уровне остается, как бы, за кадром. Процессный архитектор обязан использовать четкую методику построения архитектуры, определить границы каждого процесса и увязать их между собой по входам и выходам. Эта информация может быть структурирована в виде таблицы MS Excel, например. Но также она может остаться только в голове архитектора модели, что крайне плохо. Кроме того, отсутствие информации о границах процессов на схеме в нотации VAD может привести к ненужным дискуссиям руководителей при обсуждении архитектурных моделей компании.

Использование нотации VAD на среднем уровне (см. рис. 5) также вызывает вопросы. Дело в том, что это почти BPMN, только без четкой логики – нет движения токенов, нет событий и шлюзов. Но зачем нужна такая «недонотация» — ни структурная, ни исполняемая?

Интересно разобраться, как вообще возникла нотация VAD? Концепция выявления и анализа цепочек создания ценности организации принадлежит Майклу Портеру. Это продуманная и практически полезная методология. Но вот нотация VAD, насколько я понимаю, — это детище профессора А.В. Шеера. Когда-то давно Шееру с его фирмой IDS Scheer нужно было (с маркетинговой точки зрения) отмежеваться от якобы «устаревшего метода функциональной декомпозиции IDEF0» и прикрыться красивой методологией цепочек создания ценности Майкла Портера. Только и всего… Какой-то глубокой методологии рисования «зеленых рыбок» у Шеера не было.

В следующей, II-ой части статьи я расскажу как заполнить другие важнейшие справочники Business Studio 6 на этапе внедрения этой системы.

В.В. Репин,

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

Сентябрь 2024 г.

www.bpm3.ru

Статья Хазал Симсек с комментариями Владимира Репина

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

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

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

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

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

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

• Программное обеспечение.
• Методы.
• Диаграммы.

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

Что такое анализ процессов?

Анализ бизнес-процессов оценивает процессы для выявления характера и первопричины неэффективности. Анализ процессов может помочь:

• улучшить процессы;
• автоматизировать избыточные задачи и действия;
• обеспечить стандартизацию и соответствие требованиям.

Владимир Репин. Автор статьи использует для определенных процессов термин «Redundant tasks and activities», предлагая их автоматизировать. Скорее всего, она имеет в виду процессы и задачи, выполнение которых человеком избыточно с точки зрения создания ценности. Речь, очевидно, идет об автоматизации (роботизации) рутинных задач, которая позволяет сотрудникам сосредоточиться на более сложных и интересных задачах, что повышает их удовлетворённость и мотивацию, ведет к развитию профессиональных навыков.

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

Process analysis software (программное обеспечение для анализа процессов)

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

Что такое Process Intelligence?

Платформы Process Intelligence позволяют собирать и анализировать данные о процессах для получения информации о производительности процессов.

Владимир Репин. В Интернете можно найти разные определения термина Process Intelligence, например такое: «Это практика сбора и анализа данных по процессу для выявления узких мест и повышения операционной эффективности. Process Intelligence позволяет бизнес-аналитикам выявлять каждый этап рабочего процесса, ответственный персонал, продолжительность всего процесса, среднее время ожидания и проблемы с процессом». Tadviser.ru приводит следующее определение: «Process Intelligence (PI) — это комбинация технологий управления бизнес-процессами (BPM) и бизнес-аналитики (BI). PI выводит стратегическое и операционное управление на новый уровень. Если измерение степени успешности бизнеса с помощью Business Intelligence дает его результаты, но не показывает различные пути их достижения, то PI помогает получить лучшие бизнес-результаты лучшими из возможных способов».

1. Process mining

Process mining — это аналитическая дисциплина и технология для сбора, анализа и моделирования бизнес-процессов на основе технологических данных, записанных в ИТ-системах.

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

2. Task mining

Анализ задач или Task Intelligence — это технология для отслеживания взаимодействия пользователей на рабочих местах, например выполнения задач в электронных таблицах.

Владимир Репин. Task Mining — это технология, позволяющая полно и достоверно воссоздать последовательность действий в рамках бизнес-операций. Она фиксирует и исследует элементарные действия в рамках каждого шага процесса (заполнение полей, переходы между вкладками и окнами и другие взаимодействия с интерфейсами рабочих приложений), восстанавливает их последовательность и оценивает эффективность. Основные цели Task Mining: 1) определить, чем именно и когда заняты сотрудники; 2)     посчитать количество выполняемых операций и трудозатраты на них; 3)     идентифицировать и проанализировать повторяющиеся паттерны, чтобы найти способы их оптимизации и/или роботизации. Полученные данные помогают улучшить эффективность рабочих процессов и уменьшить время, затрачиваемое на рутинные задачи. Если основная задача Process Mining – это восстановление  фактического хода бизнес-процесса в компании, то Task Mining, в свою  очередь, — это оцифровка деятельности сотрудников и подсчёт трудозатрат, определение нагрузки и эффективности работы. То есть Process Mining выполняется для отдельных задач (https://rb.ru). Мнение еще одного эксперта: «Важен анализ пользовательской активности, то есть исследование активностей сотрудников в течение их рабочего дня: сколько времени человек провел за рабочим компьютером, какие приложения использовал, с кем внутри сети взаимодействовал и др. Для этого используются решения класса Task Mining/Process Discovery».

3. Process modeling (моделирование процессов)

Программное обеспечение для моделирования процессов моделирует процессы и выполняет эти модели.

Владимир Репин. Здесь автор немного лукавит – ПО для моделирования, как правило, не исполняет процессы, то есть это не BPM-система. Хотя, например, в Business Studio можно не только моделировать процессы в различных нотациях, но и запускать их на имитацию. Эту имитацию можно рассматривать как выполнение, цель которого состоит в получении данных о средней длительности и стоимости выполнения процессов. Например, вы сделали модель «Как есть», путем имитации рассчитали ее характеристики, а потом повторили эти действия для модели «Как должно быть». Сравнив результаты можно сделать выводы о потенциальном эффекте от оптимизации бизнес-процесса… В данном контексте речь идет о системах класса CA (Corporate Architecture), в которых можно разрабатывать архитектуру бизнес-процессов (и не только) организации, моделировать процессы в различных нотациях и проч.

4. A digital twin of an organization (цифровой двойник организации)

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

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

5. Process mapping (составление карт процессов)

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

Владимир Репин. Возникает вполне закономерный вопрос, чем, собственно Process mapping отличается от Process modeling? Картирование (мапинг) могут делать обычные сотрудники, используя примитивные, но интуитивно понятные нотации (за редким исключением, например – Toyota Value Stream Map). Например, всем известная крупнейшая промышленная организация в РФ в рамках своей «Производственной системы» картирует процессы, но не моделирует их, например, в BPMN. Надо сказать, что для ряда задач картирование при помощи примитивных, укрупненных представлений вполне решает свои задачи (например, в рамках проектов в области бережливого производства). Но для автоматизации и цифровизации такое картирование не годится. Примерно так же видят разницу между Process mapping и Process modeling  коллеги из Bizagi: «Process mapping — это процесс создания визуальной диаграммы шагов в потоке деятельности, которая создаёт бизнес-процесс. Он фокусируется на диаграммах существующих процессов в качестве точки отсчёта. Process modeling — это графическое представление бизнес-процессов или рабочих процессов в деталях и в контексте бизнес-операций. Модель процесса включает элементы документации процесса и учитывает всю информацию, необходимую для правильного выполнения процесса и его интеграции в более широкую организацию.  Process modeling — это более динамичный и гибкий подход, который ставит процессы в контекст всей организации. Он поддерживает процессы жизненного цикла и непрерывное улучшение». В общем, отмежевались они маркетингово от устаревшего термина «маппинг».

6. Business Process Management  (программное обеспечение для управления бизнес-процессами)

Программное обеспечение для управления бизнес-процессами (BPM) автоматически анализирует процессы и управляет ими.

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

7. Workflow Аnalysis Software  (программное обеспечение для анализа рабочих процессов)

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

Владимир Репин. В том, что автор статьи выделил такой метод анализа, есть некоторое лукавство, если не сказать неточность. Исторически, подход Work Flow появился довольно давно (более 30 лет назад). На тот момент фактически не было стандартов для моделирования исполняемых процессов. Вендоры Workflow-систем (прадедушки и прабабушки современных BPMS) создавали свои визуальные конструкторы процессов «кто во что горазд» (хотя потом, в 1993 году была создана  Workflow Management Coalition (WfMC)). В целом, стандартизации не было. Теперь у нас есть BPMN и мощные системы класса BPМ, которые, помимо своей основной функции автоматизации исполнения бизнес-процессов, предоставляют замечательные возможности для сбора и анализа аналитической информации по процессам. Имея современные методы и инструменты для моделирования бизнес-процессов и их последующей автоматизации в BPMS я бы не стал вообще выделять Work Flow в качестве какого-то отдельного метода анализа (если конечно нет цели пустить пыль в глаза клиентов умными терминами). Тем не менее, наши западные коллеги до сих пор пишут про Work Flow так: «…это системный подход, который используется для оценки, анализа и оптимизации потока задач, процессов и информации в организации. Он включает в себя изучение того, как выполняется работа, выявление узких мест, неэффективности и областей улучшения для повышения производительности, эффективности и производительности (itexus.com)…». Общие слова. Даром что уже давно есть ABPMP и BPM CBOK. Найдите три отличия от Process Modeling и Business Process Management…

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

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

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

8. Gap analysis (анализ пробелов)

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

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

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

9. Value-added analysis (анализ добавленной стоимости)

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

• определения процессов, повышающие ценность бизнеса;
• определения процессов создания реальной добавленной стоимости (RVA);
• выявления процессов, не связанных с добавленной стоимостью (NVA)

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

Владимир Репин. Что касается Value-added analysis, то его использование сопряжено с некоторыми трудностями. Дело в том, что с разных точек зрения один и тот же процесс может добавлять ценность для бизнеса, а для клиента – нет. Что с ним тогда делать? Многие, так называемые, «вспомогательные» процессы жизненно необходимы компании, в то время как для клиента они совершенно не нужны.

10. Root cause analysis  (анализ корневых причин)

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

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

Владимир Репин. Данный метод очень старый и относится к важнейшим методам менеджмента качества: «… Анализ корневой причины берет свое начало в атомном военно-морском флоте США, где адмирал Хайман Риковер установил высокие стандарты операционной эффективности для систем и персонала. Большинство ранних методов анализа корневой причины были разработаны в сотрудничестве специалистов атомного флота и сотрудников Комиссии по атомной энергии США (Atomic Energy’ Commission – AEC, ныне Nuclear Regulatory Commission – NRC), занимавшихся проектированием, эксплуатацией, обслуживанием и заправкой топливом морских ядерных реакторов… Анализ корневой причины – это структурированный исследовательский процесс, который позволяет распознавать и обсуждать глубинные убеждения и практики, приводящие к низкому уровню качества. Корневая причина — это основной причинный фактор, который, если его исправить или устранить, предотвращает повторение ситуации. Существуют разногласия относительно того, следует ли относить сбой к одной корневой причине (что-то, что действует как электрический выключатель) или к группе корневых причин. Это может зависеть от принятой в организации таксономии корневых причин. Методы анализа корневой причины могут быть полезны как для диагностики, так и для предотвращения проблем с качеством, защитой окружающей среды и техники безопасности. Некоторые специалисты не хотят признавать, что корневые причины кроются в ценностях и культуре организации, но пока анализ не доходит до этого уровня, организация не начинает бороться с корневыми причинами….»

11. Observational analysis  (анализ наблюдений)

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

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

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

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

12. Experience examination analysis  (анализ опыта сотрудников)

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

• неэффективность процессов и потенциальные причины, которые ее предопределяют;
• выявить хорошо функционирующие процессы  и happy path.

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

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

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

 13. Predictive analysis (прогнозный анализ)

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

• определить области, которые могут дать наибольшую выгоду из автоматизации;
• выбрать тип изменений, например стандартизацию.

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

14. Impact analysis  (анализ взаимного воздействия)

Анализ воздействия — это важный показатель для оценки воздействия взаимодействий между процессами, системами и приложениями.

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

Владимир Репин. «Impact Analysis (импакт анализ) — это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты. Затронутые области требуют большего внимания во время проведения регрессионного тестирования…». Думаю, этот метод уже ближе к методам бизнес-анализа (см. BABOK), чем к классическим методам анализа бизнес-процессов. Не совсем понятно, зачем автор статьи включил его в список.

15. Failure mode effects analysis (FMEA)  (анализ последствий отказов):

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

Владимир Репин. Метод довольно старый и многим, особенно менеджерам по качеству, хорошо известный. «FMEA (failure modes and effects analysis) – анализ причин и последствий отказов. Метод анализа, применяемый в менеджменте качества для определения потенциальных дефектов (несоответствий) и причин их возникновения в изделии, процессе или услуге. Он применяется для выявления проблем до того, как они проявятся и окажут воздействие на потребителя….»

Диаграммы и графики

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

16. Flowchart mapping (построение блок-схем)

Блок-схемы процессов отображают простые процессы в виде отдельных этапов в последовательном порядке. Диаграмма иллюстрирует:

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

Владимир Репин. Представленная автором статьи диаграмма довольно примитивна (странно, почему не был приведен пример в нотации BPMN): знакомая всем «схема с ромбиками» (ANSI, 1974 год). Совершено очевидно, что такой формат представления устарел, хотя в некоторых компаниях его до сих пор используют. Но большинство организаций перешли или переходят на нотацию BPMN (с нотаций CFFC, eEPC и других «доморощенных» нотаций).  

17. Spaghetti diagram (диаграмма-спагетти)

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

Владимир Репин. Еще раз о несистемности подачи материала автором статьи. Спагетти-диаграмму невозможно построить без программного продукта класса Process Mining, но этот класс уже был рассмотрен под номером 1. Возможно, что эту статью вообще писал ИИ, а автор только немного ее правил.

18. Fishbone diagram (диаграмма рыбьей кости)

Диаграммы «Рыбья кость» показывают причинно-следственные связи проблемы в данном процессе. Они сочетаются с анализом первопричин. Диаграммы «Рыбья кость» учитывают:

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

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

Заключение

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

 Успехов при внедрении технологий BPM!

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

«Классический» взгляд на бизнес-процесс

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

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

Собственник компании внедрил в организации процессный подход и гордо рассказывает руководителю другой, дружественной компании о том, что у него любой сотрудник знает, что такое процесс. Тот спрашивает: «А как ты это докажешь?». В ответ собственник говорит: «Идем в любой отдел и спросим любого сотрудника». Так и они и сделали. Зашли в первый попавшийся кабинет и собственник спросил одного из сотрудников: «Скажи-ка, любезный, что такое «Процесс»?». Сотрудник вскочил со своего места и выпалил: «Это то, что имеет вход и выход!».

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

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

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

«Полная» модель бизнес-процесса

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

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

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

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

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

Таблица 1. Процесс «Продажи». Пример.

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

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

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

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

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

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

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

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

Выводы

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

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

Май 2024 г.

www.bpm3.ru

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

Проблема «рисования» бизнес-процессов

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

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

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

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

Так что это такое «управление бизнес-процессами»? Может это совершенно искусственный термин, не имеющий никакого отношения к реальности? Давайте разберемся с этим вопросом.

Что такое управление бизнес-процессами?

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

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

Что же, всё-таки, такое управление бизнес-процессами? В Глоссарии Ассоциации профессионалов по процессному управлению (ABPMP Russian Chapter, https://abpmp.org.ru/resource/bpm-glossary/) дается следующее определение:

«BPM (Управление бизнес-процессами, УБП)

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

    а) анализа, проектирования, внедрения, управления и непрерывного совершенствования сквозных процессов и

    б) регулирования отношений в области процессного управления (Governance).

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

Красиво сказано, спору нет. Но смущает две вещи: 1) взгляд через «модели процессов», то есть опять «рисование»; 2) ну совершенно не понятно, кто и что должен делать…. И вряд ли кто-то из руководителей реальной компании процитирует такое определение из Глоссария в ответ на вопрос: «Как Вы управляете бизнес-процессами»?

Если свести весь BPM к изменению схем и последующей маршрутизации экземпляров процессов в BPMS руководителем, то это как-то совсем слабо и совершенно «не тянет» на управление бизнес-процессами с Большой буквы… Хотя, может это оно и есть? С точки зрения поставщика BPM-системы, наверное…

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

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

Кейс. На одной из сессий по описанию бизнес-процессов собственник весьма успешной компании из сектора телекоммуникаций сказал: «…то, что мы сейчас делаем (схемы) хорошо, но как-то механистично… Да, видно, кто и что должен делать. Да, видны документы… Но КАК именно делать? Как создавать ценность для клиентов? Какие принципы закладывать в эту работу? Что должно мотивировать сотрудников ориентироваться на ключевые, базовые принципы создания ценности? Какие ограничения при этом существуют? Схемы ответа на этот вопрос не дают…». То есть в понимании собственника разработка бизнес-процесса – это не столько рисование схем в BPMN, сколько создание системы работы, которая способна «непрерывно поставлять ценность для клиентов». А это уже серьезная задача для владельца процесса… Для ее решения была создана модель целей, ценностей, принципов и ограничений на языке Archimate в Business Studio 6.

Владелец бизнес-процесса: кто он?

Начнем с определения владельца бизнес-процесса. В Глоссарии ABPMP приводится следующая формулировка (обратите внимание, что определение дается через понятие «роль»):

«Лицо, исполняющее эту роль, несет постоянную ответственность и отчитывается за успешное проектирование, разработку, исполнение и эффективность всего сквозного (кросс-функционального) бизнес-процесса».

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

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

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

Обратите внимание, что владелец должен управлять ходом процесса. Иначе – это вовсе не владелец.  

Можно составить следующее более полное определение владельца процесса:

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

Используя данную формулировку, можно четко определить, чем может и должен управлять владелец бизнес-процесса. Это:

1. Цели, показатели, планы/отчеты, контрольные процедуры по процессу.
2. Методы и инструменты оперативного управления процессом.
3. Контекст процесса: входы/выходы (включая требования, методы и инструменты контроля), интеграция с поставщиками/потребителями.
4. Технология выполнения процесса (модели/схемы в нотациях – только инструмент проектирования алгоритма выполнения).
5. Оборудование.
6. Средства измерения процесса.
7. Среда выполнения процесса.
8. Персонал (количество, компетенции, система стимулирования).
9. ИТ-системы, поддерживающие выполнение процесса (включая экземпляры процесса в случае их наличия в автоматизированной системе).
10. Риски процесса.

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

Теперь понятно, почему при наличии «рисования» управление бизнес-процессами НЕ наступает. Причина проста – руководители не работают как владельцы бизнес-процессов, не осознают себя таковыми. В лучшем случае, 60-70% их времени уходит на «управление персоналом».

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

Этапы развития (уровни зрелости) владельца бизнес-процесса по Майклу Хаммеру

Майкл Хаммер определил четыре этапа развития (уровня зрелости) организации при внедрении управления бизнес-процессами. В частности, для владельца процесса он предложил рассматривать три раздела: «Личность», «Деятельность» и «Полномочия».

На первом уровне зрелости «портрет» владельца процесса (ВП) выглядит следующим образом (Таблица 1):

Таблица 1. Уровень 1

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

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

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

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

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

Таблица 2. Уровень 2

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

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

На Уровне 3 (Таблица 3) ВП занимается только бизнес-процессом, то есть не совмещает функциональное управление подразделениями и «процессный менеджмент». 

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

Таблица 3. Уровень 3

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

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

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

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

Таблица 4. Уровень 4

Как мы видим, в концепции Майкла Хаммера роль владельца бизнес-процесса меняется от локального «регламентатора» и «уговаривателя», до титанической фигуры масштаба собственников бизнеса, реально воздействующего на бизнес-модель компании, ее архитектуру, цепочку создания ценности, интеграцию с поставщиками и потребителями…

Наверное, для наших компаний такая фигура ВП – это просто космос. При концентрации таких людей в количестве 3-5 человек в одной организации, ее бизнес должен взлететь, как ракета. Можете представить себе в вашей компании одновременно 5-7 работающих Илонов Масков? Думаю, к такому уровню совершенства в менеджменте очень долго нужно идти, если это вообще нужно ставить в качестве реальной цели.

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

«Портрет» реального владельца бизнес-процесса

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

Таблица 5. Виды бизнес-процессов.

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

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

В таблице 6 представлено описание владельцев в зависимости от масштаба процессов.

Таблица 6. Владельцы процессов различного масштаба.

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

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

Таблица 7. Модель функций, ответственности и полномочий владельца процесса.

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

При реальном создании института владельцев процессов нужно четко определить/создать:

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

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

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

Кейс. Захарова Елена, руководитель процессного офиса/эксперт в области управления бизнес-процессами, о практике принятия на себя роли владельца процесса в крупных российских компаниях: «Как правило, в компаниях нет руководителей, готовых взять на себя ответственность за кросс-функциональный процесс, проходящий более чем через одну бизнес-функцию, а тем более за сквозной процесс. Управление процессом воспринимается как управление группой функциональных процессов одной бизнес-функции, за которую отвечает руководитель, и управление теми, кто ему подчиняется. 

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

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

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

Из реального примера, попытки в нескольких компаниях назначить владельца процесса Поставка товара с центрального склада в розничный магазин, с установлением понятного показателя OTIF (on time in full) – показывающего своевременность и полноту объема поставки, проваливались из-за нежелания потенциального владельца процесса брать на себя ответственность за этапы процесса после того, как товар был передан ответственным за доставку получателю. Основное обоснование: «… дальнейшую приемку и разбирательства при недопоставке или перепоставке товара делают сотрудники не моей бизнес-функции…». Желания влиять на сотрудников других бизнес-функций у владельца не было, как и желания брать ответственность за достижение целевых показателей процесса в целом.

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

Выводы

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

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

В.В. Репин,

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

Февраль 2024 г.

www.bpm3.ru

В статье Владимира Репина и Андрея Манюхина рассматривается вопрос выбора единой методологической базы при создании (развитии) системы повышения операционной эффективности бизнеса. Представлены результаты исследования зарубежной практики. Обсуждаются «плюсы» и «минусы» ключевых подходов и возможность объединения разных методов в рамках единой Системы управления бизнес-процессами компании на основе идеологии Business Process Management.

Введение. Что понимается под операционной эффективностью?

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

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

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

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

На каждый процесс тратятся ресурсы. Но вот насколько бизнес-результат таких процессов покрывает эти затраты? Например, бизнес-процесс формирования претензии поставщику в крупной организации требует значительных ресурсов (в первую очередь, — это рабочее время специалистов и руководителей), но вот окупается ли он? Например, выполнение одного экземпляра такого процесса обходится компании в 50-60 тысяч рублей, а убыток (неустойка) по претензии составляет всего 30 тыс. рублей. Насколько это рентабельно или эффективно? Ответ очевиден, но что с этим делать? Варианта три: 1) отказаться от выставления претензий, начиная с определенной суммы (при этом, вносить соответствующих поставщиков в «черный список»); 2) радикально изменить процесс работы с претензиями, повысив его эффективность; 3) сознательно смириться с возникающими потерями (худший вариант). Но, сначала необходимо научиться считать стоимость процессов, как минимум. А чтобы считать их стоимость, процессы надо научиться ранжировать по их ресурсоёмкости и влиянию на результат, конечный продукт, потому что одновременно описать и смоделировать все процессы невозможно.

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

Некоторые тренды

Какие методы используют компании для повышения операционной эффективности? Обратимся к результатам исследования, которое ежегодно проводит The Process Excellence (PEX) Network — глобальное сообщество, включающее более 190,000 BPM-профессионалов и руководителей, которые хотят улучшить свой бизнес благодаря реализации процессного подхода к управлению и совершенствованию операционной деятельности компании. Исследование за 2023 год было переведено российской компанией Comindware в рамках сотрудничества с PEX Network. В статье мы приведем лишь несколько ключевых графиков.

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

Согласно исследования PEX, 39% респондентов применяют методы бережливого производства (3-е место). На втором месте — методы бизнес-анализа и анализа данных (41%). На первом (47%) — методы управления изменениями. Что интересно, BPM (Business Process Management) используют только 32% опрошенных компаний.

На рис. 2 представлена информация о том, в какие решения компании планируют инвестировать деньги. На первом месте (41%) – Бизнес-анализ и анализ данных. Вполне очевидно, что именно эти методы могут позволить быстрее осуществлять цифровую трансформацию, создавая новые программно-аппаратные решения для повышения операционной эффективности. На втором месте (35%) – Искусственный интеллект, использование которого однозначно является ключевой составляющей цифровой трансформации. На третьем месте (33%) – собственно сама цифровая трансформация. На четвертом (31%) – просто автоматизация процессов. Моделирование процессов и Business Process Management почти делят 4-ое место.

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

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

Хайп-лин, бережливый BPMN и прочие «диковинные звери»

Практика российских компаний, судя по многим известным нам проектам, запущенным в крупных и средних компаниях, а так же результатам ежегодного конкурса «BPM-проект года» (проводится ABPMP Russian Chapter), подтверждает рейтинг методов повышения операционной эффективности, представленный на рис. 1. Сегодня стало модно использовать термин «Бережливое управление», особенно в гос. компаниях. Этот подход рассматривается некоторыми как главная методология повышения операционной эффективности.
Когда говорят «Бережливое», то подразумевается группа методов Lean, хотя, перевод «Бережливое» не передаёт заложенных оттенков смысла и многими руководителями воспринимается дословно. Методы Lean, все-таки, относятся к 70-80-ым годам 20 века. У кого-то они работают, но для современной компании цифровая трансформация бизнеса может дать намного больше преимуществ.

Но что мы наблюдаем сейчас в российской практике? У нас много компаний и профессионалов, которые системно внедряют TPS (Toyota Production System), преимущественно на производствах. Авторам приходилось видеть практически идеально внедренную TPS на российских машиностроительном производстве, заводе металлоконструкций и проч. Но при этом бизнес-процессы в области оперативного управления, маркетинга, продаж и закупок, управления финансами и персоналом оставляли желать лучшего.

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

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

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

Нас не удивит, если в ближайшее время на рынке появятся «новые» концепции, обещающие руководителям компаний очередные быстрые и легкие победы, например: «Бережливый BPM, включая бережливый BPMN», «Бережливая цифровизация», «Цифровой Lean», «Тощий CRM» и тому подобные диковатые монстры – плоды некорректных маркетинговых «генетических» экспериментов.

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

BPM – как ключевой метод повышения операционной эффективности бизнеса

BPM – Business Process Management, как совокупность принципов, методов, инструментов и компетенций в настоящему времени уже стал вполне сложившимся, зрелым. Для первичного знакомства с ним можно обратиться к русскому переводу книги «BPM CBOK 4.0: Свод знаний по управлению бизнес-процессами». Как же BPM помогает развивать организацию?

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

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

1. Архитектура бизнес-процессов.
2. Управление бизнес-процессами по целям и показателям.
3. Система стимулирования руководителей на улучшение бизнес-процессов по КПЭ (KPI).
4. Практика описания и анализа бизнес-процессов.
5. Практика оптимизации бизнес-процессов и внедрения изменений.
6. Автоматизация бизнес-процессов (в BPMS).
7. Стандартизация бизнес-процессов.
8. Контроль и аудит бизнес-процессов.
9. Корпоративная система обучения персонала методам процессного управления.
10. Процессный офис.

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

Ключевым элементом, базой СУБП является Архитектура бизнес-процессов компании. Очевидно, что она является важнейшей частью общей корпоративной Архитектуры, для построения которой можно применять методологию ArchiMate и, например, современный российский программный продукт Business Studio 6, моделируя все необходимые аспекты: от заинтересованных сторон и их целей, цепочки создания ценности и компетенций бизнеса, до операционных процессов в нотации BPMN, технологической платформы и структуры используемых данных.

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

• научные методы (в т.ч. основанные на теории очередей и систем массового обслуживания);
• методы регулярного менеджмента (четкие зоны ответственности исполнителей, стыковка по входам/выходам, идентификация и прослеживаемость и др.);
• методы оптимизации технологии выполнения процесса (устранение узких мест, устранение избыточного контроля и ненужных согласований, распараллеливание работ и прочие);
• методы поиска и устранения потерь (Lean);
• методы анализа рисков и проектирования робастных процессов;
• методы автоматизации (в СЭДО, BPMS);
• методы цифровизации (BI, RPA, «нейронка» и другие).

Проектируя исполняемый процесс в современной нотации BPMN (стандарт ИСО с 2013 года) вы можете использовать любые доступные и понятные команде проекта методы анализа и разработки эффективных бизнес-процессов. При этом именно BPM, как платформа, объединяет, интегрирует различные подходы и методы. Возникает необходимость в тесном сотрудничестве специалистов различных направлений: менеджеров по трансформации, бизнес-аналитиков, специалистов по Lean, профессионалов в области цифровизации и прочих. Это дает синергетический эффект. Другим словами, когда вы оптимизируете бизнес-процесс, вы не просто устраняете потери, которые лежат на поверхности («Хайп-Lean»), но проектируете новый, совершенный процесс, обладающий высокой операционной эффективностью. Фрагментарные улучшения не позволяют оценить процесс в целом, систему (архитектуру) процессов, — тем более. Они «перегоняют» узкие с одного места в процессе в другое, подобно, как воздушные пузыри при наклеивании плёнки на стекло.

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

Но главное, несмотря на ряд автоматизированных в Axapta функций, сквозной процесс в целом сопровождался значительным по объему бумажным документооборотом. Было очевидно, что прямой перенос задач, выполняемых в Axapta, в 1С-ERP нерационален. Нужно создавать новый, эффективный бизнес-процесс без бумажного документооборота, с минимумом ручных задач и максимальной степенью интеграции между системами. В рассматриваемой ситуации устранение потерь за счет исключения задач, выполняемых «ногами» (передача документов с одного рабочего места на другое), было невозможно без радикального перепроектирования и цифровизации бизнес-процесса в целом.

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

Выводы

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

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

Если у вас еще не создан Процессный офис и СУБП, то целесообразно обратить внимание на концепцию и методы BPM, заняться системным внедрением методов проектирования и управления бизнес-процессами. Это приведет к заметному, а главное, — постоянному росту операционной эффективности вашей компании.

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

А.Е. Манюхин,
консультант по управлению, партнер BPM3.RU

Январь 2024 г.

www.bpm3.ru

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

Введение. Ключевая проблема применения BPMN для процессов «Как есть»

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

1. создать модель процесса «Как есть», адекватную реальной выполняемой деятельности, с целью анализа и обоснования мероприятий по оптимизации;
2. разработать регламент выполнения бизнес-процесса (конкретный, понятный руководящий документ для исполнителей, а не обще-руководящий, водянистый, «исотизированный» документ);
3. подготовить техническое задание для автоматизации бизнес-процесса в 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 неприменима (плохо применима) для реального «эксельно-аутлукового» процесса «Как есть».
В качестве выводов хочу еще раз напомнить читателю, что очень важно всегда:

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

Удачи в описании бизнес-процессов «Как есть» с использованием нотации BPMN!

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

Октябрь 2023 года.

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

Компания «Фронтсайд»

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

Начало проекта

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

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

Целями проекта являлись:

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

Спонсором проекта выступил генеральный директор Дмитриев А.В., руководителем проекта была назначена Котик Н.П., были выбраны эксперты Теплова Е.Б., Дворецкий С.А, а также приглашены консультанты Репин В.В. и Калошина Л.Н.

Разработка архитектуры и моделирование бизнес-процессов

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

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

На рис.1 представлена контекстная диаграмма компании «Фронтсайд».
Входами для осуществления деятельности компании были определены:

1. Рыночная информация (поступающая с Рынка).
2. Потребность в товарах и услугах (поступающая от Клиентов).
3. Сырье и сервисы (от Поставщиков).
4. Человеческие ресурсы (поступающие из Общества).
5. Финансовые ресурсы (от Собственников).

В результате осуществления деятельности определены следующие выходы:

1. Информация для рынка (передается на Рынок).
2. Товары и услуги (для Клиентов).
3. Потребность в сырье и сервисах (передаются Поставщикам).
4. Специалисты (возвращаются в Общество).
5. Возврат инвестиций (Собственникам).

Управляющее воздействие на осуществление деятельности компании оказывают:

1. Видение и цели Собственников.
2. Эстетические нормы Общества.
3. Законы, нормы и правила Государства.

Далее архитектура бизнес-процессов «Фронтсайд» была декомпозирована на 7 подпроцессов (рис.2):

1. Управление бизнесом компании «Фронтсайд».
2. Маркетинг.
3. Продажи.
4. Исполнение заказов.
5. Обеспечение операционной деятельности.
6. Обслуживание производственной инфраструктуры предприятия.
7. Управление техническим развитием и обеспечение качества.

Бизнес-процесс «Исполнение заказов» состоит из пяти ключевых для бизнеса блоков:

1. Управление исполнением заказов.
2. Снабжение.
3. Производство.
4. Складская логистика.
5. Транспортная логистика.

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

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

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

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

Оптимизация бизнес-процессов «На ходу»

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

При таком подходе важно сразу оценить, как предложенные изменения повлияют на другие бизнес-процессы. Поэтому руководитель проекта принимал решения по каждому конкретному предложенному случаю и направлению. Где-то было принято решение моделировать процессы «as is», где-то «to be», а если были выявлены процессы, которых нет, но в разработке которых нуждается компания, то они были включены в план моделирования.

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

Моделирование бизнес-процессов в нотации BPMN

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

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

Пример бизнес-процесса

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

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

Особенности выполнения проекта

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

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

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

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

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

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

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

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

Достигнутые результаты

Проект внедрения Системы управления бизнес-процессами в компании «Фронтсайд» продолжается. Но уже можно говорить, что были достигнуты следующие ключевые результаты:
• Построена архитектура бизнес-процессов компании в нотации 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 г.

www.bpm3.ru