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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 1.

Выводы

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

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

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

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

В.В. Репин,

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

Май 2023 г.

www.bpm3.ru

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Узкие места

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Февраль 2023 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

Апрель 2021 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Январь 2021 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме

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

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

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

Ноябрь 2019 г.

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

Возможная постановка задачи

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

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

Постановка задачи. Необходимо с использованием Business Studio:
а) перевести все подготовленные схемы в универсальный формат, при этом:
б) создать архитектуру бизнес-процессов компании;
с) сделать процессы исполняемыми;
д) подготовить ТЗ на автоматизацию процессов в BPMS.

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

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

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

Специалист по Business Studio Иван Глебов, считает, что «дополнительным положительным результатом использования среды моделирования Business Studio для формирования ТЗ является документирование функциональной архитектуры информационных систем, используемых для автоматизации бизнес-процессов. Архитектура информационных систем формируется в разделе «Программные продукты» среды моделирования Business Studio».

Перевод схемы в нотацию BPMN в Business Studio

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

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

Фрагмент схемы показан на рис. 3. Использованы маркеры операций, чтобы показать, какая операция будет выполняться пользователем в интерфейсе BPMS (Business process management system), а какая может быть выполнена скриптом (соответствующий маркер и серая заливка).

Не все операции процесса при переводе в исполняемый формат сохраняются в том виде, как на оригинальной схеме в MS Visio. При разработке модели процесса для BPMS многие действия рационально объединить в рамках одной операции.

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

Стоит упомянуть, что возможен импорт схем, созданных в MS Visio, в Business Studio. Но в данном случае было быстрее нарисовать «правильную» схему заново, чем редактировать схему, полученную после импорта. Но этот пример не говорит о том, что так поступать нужно всегда. Функция импорта полезна.

Настройка аналитики по бизнес-процессу и формирование ТЗ на автоматизацию

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

Кроме того, для настройки BPMS требуется дополнительная информация, которая не представлена на схеме. Необходимо определить, какие аналитические данные нужны автоматизации процесса в конкретной исполняемой системе. Затем настроить Business Studio путем расширения объектной модели с использованием модуля Meta Edit так, чтобы можно было удобно вносить данные через интерфейс системы. На рис. 4 показан пример возможной настройки. Для каждой операции процесса доступна закладка «ТЗ на автоматизацию», которая содержит ряд полей (атрибутов), которые необходимо заполнить.

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

После занесения информации по всем операциям процесса, можно автоматически сформировать готовое Техническое задание на автоматизацию бизнес-процесса. Для этого в Business Studio настраивается специальный шаблон отчета. Возможна выгрузка в MS Word или в MS Visio в зависимости от требований проекта. На рисунках 5 и 6 показаны фрагменты такого ТЗ. В данном случае, ТЗ сформировано в весьма упрощенной, демонстрационной форме.

Какая еще аналитика может и должна быть собрана при подготовке к автоматизации процесса в BPMS? В своей статье Андрей Чепакин предлагает следующую структуру:

1. Схема инициации процесса.
   1.1. Роль «Инициатор бизнес-процесса».
   1.2. Мотив инициации бизнес-процесса.
   1.3. Способы запуска бизнес-процесса.
2. Схема создания ценности.
   2.1. Типизация клиентов/заказчиков бизнес-процесса.
   2.2. Составляющие ценности, формируемой процессом, по типам клиентов.
   2.3. Сценарии использования процесса его клиентами.
3. Схема работы процесса.
   3.1. Спецификация входов процесса.
   3.2. Спецификация выходов процесса.
   3.3. Определение единицы потока и ее состояний.
   3.4. Ролевая модель процесса.
   3.5. Спецификация метрик и показателей процесса.
4. Схема данных процесса.
   4.1. Спецификация данных процесса.
   4.2. Определение источников данных для процесса.
5. Схема контроля процесса.
   5.1. Спецификация контролируемых метрик и показателей.
   5.2. Способы сбора и обработки данных.
   5.3. Способы доставки информации владельцам процесса.
6. Схема обратной связи процесса.
   6.1. Способы доставки обратной связи участникам процесса.
   6.2. Способы получения обратной связи от клиентов процесса.
   6.3. Способы доставки обратной связи высшему руководству.
7. Схема компетенций процесса.
   7.1. Требования к перечню участников процесса.
   7.2. Требования к компетенциям участников процесса.
   7.3. Реестр возможностей снижения требований к компетенциям.

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

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

Многие специалисты считают, что модель данных, кроме схемы, является ключевой для эффективного решения задачи автоматизации процесса в BPMS. В текущей версии Business Studio, к сожалению, нельзя создать графическую модель структуры данных, как это можно быть сделать, например, в ERWin (ER модель — entity-relationship model, модель «сущность — связь» — модель данных, позволяющая описывать концептуальные схемы предметной области). В Business Studio можно только описать атрибуты для всех документов, которые используются в моделях бизнес-процессов, как показано на рис. 7.

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

Кто будет настраивать BPMS?

Настройка любой BPMS включает, как минимум:

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

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

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

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

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

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

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

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

Сравнение двух подходов. Таблица.

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

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

В свою очередь ИТ специалистов не нужно специально учить методам анализа и оптимизации процессов (TOC, Lean, KPI).

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

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

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

Приведу пример. В моей книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» представлены модели трех процессов. Первый процесс называется «Подача заявки на оплату». В компании может быть одновременно инициировано несколько экземпляров этого процесса. Второй процесс – «Согласование графика платежей на неделю». Он запускается по таймеру и выполняется один раз в неделю. Третий процесс называется «Оплата счетов». Он инициируется процессом «Согласование графика платежей на неделю». Модели процессов были созданы в Business Studio в нотации BPMN. Используя семантику BPMN, я показал на схеме, что каждый экземпляр процесса «Подача заявки на оплату» должен получить сообщения из процессов «Согласование графика платежей на неделю» и «Оплата счетов». Далее эти три схемы были переданы в качестве ТЗ специалисту по Elma, который быстро настроил исполняемые процессы в этой системе (большое спасибо!). При настройке нужно было решить несколько задач, явно выходящих за пределы компетенций бизнес-пользователя, а именно: дополнение структуры данных, создание переменных процессов, создание скриптов на C#, управляющих отправкой сообщений, доработкой модели процесса с учетом технологических особенностей работы скриптов.

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

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

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

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

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

Введение

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

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

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

В данной статье рассматривается имитационная модель реального процесса «Рассмотрение и согласование оперативных заявок». крупной промышленной компании. Используемый инструмент имитационного моделировании – Business Studio 4.2.

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

Цель процесса – эффективное управление оборудованием за счет обоснованного, корректного и оперативного вывода в ремонт. Формально, результат процесса – это согласованная, утвержденная заявка, внесённая в сменное задание.

Автоматизация процесса практически отсутствует.

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

Исходная модель процесса для анализа «как есть» (80% заявок, поступающих в процесс, содержат ошибки).

Диаграмма процесса «как есть» представлена на рис.1. Участниками процесса являются:
• Инициатор подачи заявки.
• Оперативный персонал, в оперативном ведении у которого находится оборудование.
• Технический руководитель объекта.
• Оперативный персонал, в оперативном управлении у которого находится оборудование.

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

На рис. 2 показана интенсивность запуска процесса (нагрузка на процесс). В месяц поступает около 1200 оперативных заявок на обработку. Фактически, заявки могут готовиться в любое время, но процесс запускается только в период с 16 до 18-00 ежедневно. В другое время заявки просто не рассматриваются.

На схеме процесса показано время выполнения каждой операции. Например, для операции «Рассмотреть и согласовать заявку (совместимость)» сверху указано «Норм.Константа (0:05:00)». Это означает, что нормативное время выполнения данной операции составляет 5 минут. Там, где снизу операции написано «Ож.Константа…» это означает время ожидания выполнения из-за, например, отсутствия ресурса и проч.

Обратим внимание, что время выполнения первой операции процесса «Оформить оперативную заявку» не является константой. Около 64% всех заявок оформляется 5 минут. В 27% случаев необходимо собирать данные для заявки, а это занимает 15 минут. В 9% случаев сбор данных занимает 20 минут.

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

На схеме процесса (см. рис. 1) красным цветом показана вероятность перехода по соответствующим стрелкам после шлюзов. Так, например, переход по стрелке «да» после шлюза «Имеются критичные ошибки в заявке?» будет осуществляться с вероятностью 80% и т.п.

Имитация процесса проводилась для одного месяца – ноября 2018 г. По результатам имитации получены следующие данные:
• среднее время выполнения одного экземпляра процесса — 2 часа 40 минут;
• суммарная стоимость процесса за месяц – 128 тыс. рублей.

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

Измененная схема процесса — 10% заявок с ошибками.

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

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

По результатам имитации для случая с 10% ошибочных заявок получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 день и 6 часов (!);
• суммарная стоимость процесса за месяц – 320 тыс. рублей.

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

Оптимизация процесса

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

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

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

Полный список предложений следующий:
• заполнение заявок должно выполняться без ошибок и без ожидания данных (данные должны быть доступны в функциональной информационной системе);
• необходимо сокращение времени формирования заявок до 3 минут в 80% случаев;
• необходимо устранить операции типа «Передать» и «Получить»;
• необходима автоматизация самого процесса в системе класса BPM (Business Process Management);
• ряд операций необходимо сделать полностью автоматическими, например, «Сформировать/Внести заявку в сменное задание»;
• требуется создание единой базы данных в рамках функциональной ИС по управлению работой и обслуживанием оборудования;
• для всех операций необходимо сокращение времени выполнения операций за счет автоматизации.

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

По результатам имитации оптимизированного процесса получены следующие данные:
• среднее время выполнения одного экземпляра процесса – 1 час 34 минуты;
• суммарная стоимость процесса за месяц – 106 тыс. рублей.

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

Выводы по результатам имитационного моделирования процесса

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

Таблица. Сравнение процессов «как есть» и «как должно быть».

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

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

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

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

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

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

А.Э. Мельникова
Ведущий специалист по стандартизации отдела оптимизации бизнес-процессов и стандартизации
ООО «ИНК»

Декабрь 2018 г.

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

Введение

Цели деловой игры, предлагаемой вниманию читателя, следующие:

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

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

Сценарий игры

Организация

На группу участников (4-8 человек) распечатывается цветная схема процесса в формате А2.
Дополнительно распечатывается форма перечня предложений по оптимизации (2 листа на каждую группу, всего 6 листов).
Все участники делятся на 3 группы:

1. Команда «А» (выбирает себе название).
2. Команда «Б» (выбирает себе название).
3. Команда экспертов (желательно включить в нее несколько топ-менеджеров).
   Объявляются цели и правила игры. Цель игры – достижение лучших показателей за счет оптимизации бизнес-процесса. Используется два показателя: 1) длительность выполнения процесса; 2) стоимость результата процесса (в данном примере – это коммерческое предложение).

Демонстрация модели

Проводится демонстрация имитационной модели бизнес-процесса (с анимацией хода процесса в Business Studio).
Обсуждаются результаты имитации.
Обсуждаются целевые показатели процесса: 1) длительность выполнения; 2) стоимость результата процесса; 3) качество (количество ошибок и т.п.).

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

В процессе участвуют несколько сотрудников:
• Менеджер, ответственный за формирование КП клиенту (2 шт.);
• Начальник отдела продаж (1 шт.);
• Начальник Инженерно-технического отдела (1 шт.);
• Инженер Инженерно-технического отдела (1 шт.);
• Начальник ФЭО (1 шт.);
• Экономист ФЭО, ответственный за расчет стоимости изделия для КП (1 шт.);
• Коммерческий директор (1 шт.).

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

Процесс выполняется руководителями и специалистами. Практически после каждой операции процесса указаны шлюзы типа «Исключающее ИЛИ». Процесс ветвится – потоки работы разделяются с учетом вероятности. Например, после операции «Проверить расчет параметров изделия» в 20% случаев нужно переделать расчет, т.к. он содержит неточности (ошибки). Вероятности перехода показаны на схеме визуально в процентах красным шрифтом (это сделано вручную – в Business Studio нет возможности визуализировать вероятность перехода на схеме).

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

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

На рис. 2 показан фрагмент пошаговой имитации процесса в Business Studio. Пошаговая имитация используется для демонстрации понятия потока работ (Work Flow) и понятия «экземпляр» процесса.

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

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

1. средняя длительность процесса формирования коммерческого предложения – 9 дней 5 часов 24 минуты;
2. средняя стоимость подготовки коммерческого предложения — 3203,18 рублей.

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

Анализ процесса и формулирование предложений

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

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

Оценка предложений

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

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

Защита предложений

Команды представляют свои предложения по оптимизации процесса (3-5 минут).

Представили команды экспертов дают аргументированную оценку предложениям.
Затем группы могут потратить некоторое время на дискуссию.

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

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

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

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

Проводится имитация измененных моделей бизнес-процессов.
Определяются показатели процессов Команды «А» и Команды «Б».
Определяется победитель. Совместно обсуждаются итоги игры.

Примеры результатов выполнения игры

Приведу пример результатов изменения процесса двумя группами, участвовавшими в игре.

Одну группу можно условно назвать «Сдержанной», а другую «Радикальной».

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

По результатам имитации оптимизированного процесса получены следующие данные:

1. средняя длительность процесса формирования коммерческого предложения – 2 дня 12 часов 48 минут;
2. средняя стоимость подготовки коммерческого предложения — 1361,25 рублей.

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

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

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

По результатам имитации этого процесса получены следующие данные:

1. средняя длительность процесса формирования коммерческого предложения – 38 минут;
2. средняя стоимость подготовки коммерческого предложения — 47,98 рублей.

Таким образом, достигнуты следующие изменения после «оптимизации» процесса «Формирование КП клиенту»:

1. по длительности процесс улучшен в 350 раз;
2. по стоимости подготовки КП процесс улучшен в 67 раз.

Выводы

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

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

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

Кстати, при желании, можно организовать и провести такую деловую игру в вашей компании. Ее длительность около 4 часов. Буду рад сотрудничеству.

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

Апрель 2018 г.

Статья адресована читателям, которые используют или предполагают использовать программный продукт Business Studio, в частности BS Portal (web-портал). Рассматриваются возможности и ограничения Business Studio и BS Portal для поддержки оперативного управления бизнес-процессами компании.

Введение

Business Studio – хороший инструмент для моделирования и регламентации бизнес-процессов. При грамотном методическом подходе можно получать качественные графические схемы процессов и автоматически сформированные регламенты, основанные на 100% понимании этих процессов. Кроме того, все эти модели и регламенты можно просматривать в виде гипертекстовых страниц при помощи приложения BS Portal, что дает возможность сотруднику относительно быстро находить нужную ему информацию регламентирующего или справочного характера.

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

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

Предполагаю так же, что читатель уже имеет минимальный набор знаний об архитектуре Business Studio и видел в работе BS Portal (см. http://www.businessstudio.ru/load/portal/).

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

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

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

К регулярному оперативному управлению процессами я бы отнес, как минимум, следующее:

1. Оперативное планирование процесса (деятельности подразделения).
2. Мониторинг и контроль процессов по показателям;
3. Анализ причин отклонений в процессе и принятие решений (выбор — коррекция или корректирующее действие);
4. Оформление, выдача и контроль исполнения разовых задач по процессу (в т.ч. коррекций).
5. Планирование, организация и контроль исполнения корректирующих действий по процессу.
6. Оперативный контроль исполнения требований нормативно-методических документов (регламентов).
7. Анализ процесса в целом (в т.ч. на основе статистики), планирование, организация и контроль исполнения внутренних проектов развития (PDCA).
8. Оперативный контроль экземпляров бизнес-процессов.

Хотел бы обратить внимание, что автоматизация задач 1-3 во многих компаниях до сих пор отсутствует. Руководители используют подручные средства для хранения и анализа информации: свою голову, ежедневник, файлы MS Excel и т.п. В более продвинутых компаниях применяют BI-системы, автоматизируют работу с поручениями, внедряют документооборот, BPMS и проч.

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

Посмотрим, насколько Business Studio и, в особенности, BS Portal смогут помочь нам в поддержке указанных выше задач.

Персональная страница на портале

Итак, заходим на портал Business Studio. В рассматриваемой компании (демо-базе) я назначил себя на должность Коммерческого директора (на Генерального – скромность не позволила).

Для входа на портал нужно ввести свой логин и пароль. Кстати, я поменял логотип производителя на логотип моего портала www.bpm3.ru (там можно купить Business Studio и заказать консалтинг, извините за продакт плейсмент).

Далее открывается персональная страница пользователя – см. рис. 2. Хотел бы обратить внимание, что какие-либо индикаторы обновления данных, наличия новых сообщений пользователю, приглашений и т.п. на персональной странице отсутствуют. Хотя большинство из нас, будучи пользователями социальных сетей, уже привыкло к таким фишкам, как например на ФБ. К сожалению, даже мое фото на персональную страницу вывести невозможно, не говоря уже о других индивидуальных настройках.
Стоит отметить, что в системе есть возможность отправлять уведомления об изменениях на почту пользователей.

Для настройки пиктограмм разделов нужно разместить новые файлы в системной папке BS Portal. Через интерфейс Business Studio сделать это не получится. А уж если говорить о настройке стилей, то придется редактировать файл css.

Разделы «Показатели», «Цели» и «Документы» формируются по умолчанию, хотя их можно отключить. Но я оставил – их вполне можно использовать. Было создано несколько новых разделов, внутри которых используются так называемые разделители. Например, есть раздел «Мои процессы и НСД». В нем первый разделитель – «Управление процессами». Внутри некоторых разделов в виде гиперссылок показаны названия отчетов, в некоторых – «Коммерческий директор». Дело в том, что движок Business Studio работает следующим образом. Для отчетов, сформированных по классу физические лица, он выводит название самого отчета. Для отчетов по классу «Субъекты» — название должности. Если бы я занимал две должности в рамках данной модели (например, был бы еще Директором ООО «СбытПромЗакупка» — дочерней компании), то кроме «Коммерческого директора» была бы видна должность «Директор». Дело в том, что разработчики считаю, что в компаниях физические лица часто занимают несколько должностей.

Кстати, функционал настройки персональной страницы в Business Studio выполнен весьма сложно – нужно провалиться вниз на 9 уровней различных меню (если я не сбился со счета), чтобы сделать все необходимые настройки. Чтобы их проверить – снова на 7 уровней вниз и т.п. Понятие «Предпросмотр» web-страницы отсутствует и проч. Нужно запустить портал на формирование, и только потом смотреть результат.

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

Контроль процесса по показателям

Давайте зайдем в раздел «Мои показатели» на персональной странице, выберем один из показателей и посмотрим, что покажет система как результат работы стандартного отчета. Результаты представлены на рис. 4.

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

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

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

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

Мои процессы и НСД

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

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

Возможность создания такого рода отчетов – «плюс» как самой Business Studio, так и BS Portal. Легкость доступа к разработанным моделям процессов очень важна. Часто, причем даже в крупных компаниях, процессная модель остается «военной тайной» подразделения организационного развития и не доводится до линейных руководителей. Но ведь именно они являются потребителями этой информации! BS Portal в такой ситуации может оказаться реальным решением проблемы информирования широких масс сотрудников о процессных наработках.

Следующий отчет – «Процессы, в которых я участвую». Его задача – показать все операции, которые выполняет сотрудник, занимающий данную должность. Важно быстро находить требования к работе, которую нужно выполнить. Перелистывать десятки (если не сотник) бумажных регламентов невозможно. Поэтому BS Portal дает отличную возможность доступа к информации регламентирующего характера. Результат работы отчета представлен на рис. 6. Хочу заметить, что вид таблицы определяется пользователем – можно вывести всё, что необходимо руководителю (например, требования к срокам, периодичность выполнения, даты и т.п.).

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

Вернемся к разделу «Мои процессы и НСД». Последний отчет в данном разделе подготовлен для демонстрации возможности вывода фотографий. В данном случае я создал справочник оборудования, используемого в процессе. Добавил (через Meta Edit) поле для закачки фотографий и сделал соответствующий отчет – см. рис. 8.

Естественно, кроме названия и фото можно добавить всё, что угодно – описание, технические характеристики, порядок подготовки к работе и проч.

Мои страт. карты

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

Оперативный контроль

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

Первый отчет – «Оперативный контроль процессов». Результат его работы показан на рис. 10. Фактически, представленная таблица – это электронный ежедневник владельца процесса, в котором он осуществляет фиксацию отклонений процесса от нормального хода. Делается это на основании контроля значений показателей (через тот же BS Portal). Почему не хватает только отчетов с показателями? Попытайтесь ответить на простой вопрос: «Как убедиться в том, что руководитель регулярно мониторил процесс, фиксировал отклонения и разбирался с ними?!» Всё в голове или ежедневнике… Если вы сторонник неконтролируемого, субъективного ручного управления, то для вас этот вопрос покажется надуманным.

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

Теперь хотел бы обратить внимание читателя на простой, но ключевой аспект – все указанные выше данные можно внести только через интерфейс Business Studio. Через BS Portal это сделать невозможно (как, впрочем, и редактировать регламенты в гипертекстовом виде – это моя мечта). Напомню, что одна лицензия Business Studio стоит 76 800 рублей. Т.е. если владелец процесса хочет вести ежедневник контроля отклонений в BS, ему нужно будет потратит эту сумму. Хотя, стоит отметить, что сообщения о несоответствиях можно вводить через модуль Cockpit, который стоит 980 рублей.

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

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

Пример работы отчета представлен на рис. 11.

Как видно на рис. 11, в таблице есть такие столбцы, как: дата проверки, процесс, регламент (кстати по ссылке можно его открыть), пункт НМД (который проверялся), описание несоответствия и сообщение о несоответствии.

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

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

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

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

Другие разделы персональной страницы

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

Для прикола добавлен раздел «Мои фото», где сотрудник может что-то опубликовать. Однако механизм занесения фото в Business Studio таков – через текстовое поле формата rtf (тип атрибута «Изображение» хотя и есть в Meta Edit, но не поддерживается системой). Более правильный путь – создание специальных справочников через Meta Edit. В этом случае можно делать ссылки на файлы прямо из списка, доступного для каждой должности (процесса и т.п.).

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

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

Резюме

Итак, подведем итоги. Что может Business Studio Portal в части поддержки оперативного управления бизнес-процессами:

Итог – соответствие функционала BS Portal задачам оперативного управления бизнес-процессами – всего 14%. Понятно, что моя оценка субъективна.

Таким образом, можно сделать вывод, что система Business Studio и ее модуль BS Portal в данной версии 4.1 не могут быть эффективно использованы для оперативного управления бизнес-процессами организации. Этот вывод нисколько не умоляет замечательных функциональных возможностей системы Business Studio в части моделирования и регламентации бизнес-процессов компании. Возможно, разработчики системы примут к сведению указанные выше моменты и доработают функционал BS Portal в следующих релизах системы.
Буду рад вашим вопросам и примерам использования BS Portal для организации управления процессами.

В.В. Репин, к.т.н., доцент, тренер, консультант по управлению.

Октябрь 2016 г.