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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Трудности и рекомендации

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

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

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

Котик Н.П.,
Директор по развитию компании «Фронтсайд»

Калошина Л.Н.,
Ведущий консультант по бизнес-процессам команды BPM3.RU

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

Сентябрь 2023 года

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Май 2023 г.

www.bpm3.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Апрель 2022 г.

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

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

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

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

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

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

Контекст

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

Январь 2022 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сентябрь 2021 г.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Март 2021 г.

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

Введение

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

В качестве примера я выбрал процесс «Разработка нового изделия: от идеи до постановки на производство» и создал его модель в Business Studio.

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

Модель сквозного процесса в нотации IDEF0

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

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

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

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

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

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

Очевидно, что процесс такого уровня сложности невозможно представить в виде какой-то одной цепочки операций (Work Flow – поток работ, в нотации eEPC или BPMN), выполняемых конкретными сотрудниками. (Теоретически, это сделать можно, но модель будет включать несколько тысяч шагов и сотни шлюзов, что сделает ее абсолютно нечитаемой и практически неприменимой).

Если мы декомпозируем, например, «Выполнение НИОКР», то, скорее всего, на диаграмме увидим процессы, которые тоже нерационально представлять в виде диаграмм Work Flow.

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

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

Пример. Внутри блока «Разработка технологии производства нового продукта» находятся следующие подпроцессы:
• Управление разработкой технологии производства.
• Разработка НТД по продукту.
• Тестирование новых видов сырья и упаковки.
• Разработка нормативов по новому продукту.
• …

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

На рис. 3 показана диаграмма процесса «Разработка требований к новому продукту».

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

В реальности часть из них может работать одновременно, с разными задачами. Видно, что возможны возвраты и переделки, например, «Анализ возможности и необходимости создания нового продукта», «Разработка ТЗ на новый продукт» и «Принятие решения по новому продукту».

Если рассматривать блоки деятельности, представленные на схеме 3, как Work Flow (т.е. на следующем уровне), то для каждого такого процесса возможные различные условия:
• старта в части запуска предыдущими процессами;
• завершения в части запуска других процессов.

Сценарии выполнения сквозного процесса

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

Желтый сценарий – «идеальный», когда всё делается с первого раза и продукт получается удачный.

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

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

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

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

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

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

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

Таблица. Сценарии выполнения сквозного процесса. Пример.

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

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

Далее, если все процессы будут описаны в формате Work Flow, можно будет для каждого процесса рассчитать показатели выполнения одного экземпляра:
• минимальное, нормативное, максимальное время выполнения;
• затраты на выполнение.

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

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

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

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

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

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

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

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

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

Введение

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

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

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

Исходные условия

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

Организационная структура компании представлена на рис. 1.

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

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

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

Еще есть некоторые процессы, которые начинаются со слова «Участие…». В ряде случаев, эти процессы просто некорректно выделены со слов сотрудников, для которых они по каким-то причинам субъективно важны.

Кстати, для зарегистрированных пользователей портала FineXpert.ru доступен файл MS Visio со всеми представленными в статье схемами.

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

Порядок игры

Количество участников игры – от 3 до 6-8 человек (если участников больше, то целесообразно подготовить два комплекта карточек). Целесообразно сдвинуть 4 стола, чтобы удобно было раскладывать карточки. Если в компании есть плоттер, то можно заранее распечатать схему, представленную рис. 2. Если нет, то достаточно просто распечатать схему орг. структуры (3-4 шт.).

Сценарий деловой игры «Процессный пазл»:

1. Подготовить карточки, схемы и рабочие столы.
2. Создать рабочие группы по 6-8 руководителей.
3. Кратко рассказать кейс («компания производит чайники», функциональные процессы), раздать карточки (предварительно перемешав их, как карты). Если играют топ-менеджеры крупной компании, то карточки можно предварительно разложить по функциональным подразделениям для экономии времени. Но это делать нежелательно. Первичное раскладывание карточек нужно для первого знакомства с компанией. Обязательно нужно сказать, что реструктуризация компании не предполагается, т.е. нельзя менять схему орг. структуры.
4. Задание № 1. Необходимо разложить карточки с процессами по функциональной принадлежности, в т.ч. для руководителей верхнего уровня (10-12 минут).
5. Задание № 2. В группе создать две подгруппы по 3-4 человека.
   a. Задание для подгруппы № 1 – собрать пазл – сквозной процесс «Подготовка технико-коммерческого предложения для клиента». Можно слегка намекнуть на возможные границы этого процесса, но не делать всю работу за участников.
   b. Задание для подгруппы № 2 — собрать пазл – сквозной процесс «Разработка нового изделия (от идеи до постановки на производство»).
   c. Объявить для всех, что если кому-то потребуется карточка, но она уже занята другой группой, то можно взять пустую карточку и написать на ней необходимое название (такое же, как на существующей карточке!).
6. По факту готовности сквозных процессов:
   a. сфотографировать выложенные группами «пазлы»;
   b. вывести фото с пазлами на большой экран (через проектор); если группа одна, то можно обсуждать результаты работы прямо на рабочем столе;
   c. группы докладывают результаты сборки сквозных процессов из функциональных процессов;
   d. ведущий находит несоответствия в сквозных процессах, удаляя ненужные или добавляя нужные процессы, объясняет допущенные ошибки.
7. Подведение итогов игры.

Ниже на фото показано, как это всё выглядит «в живую» во время игры.

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

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

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

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

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

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

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

Заключение

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

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

Так же можно провести игру в рамках 1-дневного тренинга по процессному управлению для топ-менеджмента.

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

Успехов при внедрении системы процессного управления!

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

Ноябрь 2018 г.

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

Введение

Более 15 лет назад, когда IDS Sheer вывел на рынок методологию ARIS, для моделирования процессов верхнего уровня в ней использовалась нотация VAD (Value Added Chain – цепочка создания ценности). Маркетологи, продвигавшие ARIS, заявляли, что нотация IDEF0 (SADT) безнадежно устарела, т.к. представляла собой «функциональный взгляд на организацию», а VAD – «процессный взгляд»… Они были неправы. Сегодня становится очевидно, что скорее умрет VAD в том виде, как он реализован в ARIS. Это просто набор значков, по сути, представляющий собой субъективное видение реестра бизнес-процессов компании. Вокруг выбора состава этих значков много шаманства с бубном (типа разделения процессов на основные и вспомогательные и т.п.), но инженерного подхода там точно нет.

Практически единственной и, казалось бы, доступной (в силу своей кажущейся простоты) методологией построения моделей сложных систем является SADT (Structured Analysis & Design Technique), на основе которой в 1963 году был создан американский стандарт IDEF0 (разрешен в России в виде РД IDEF0 – 2000).

Классической книгой по SADT до сих пор считается книга Дэвида А. Марки и Клемента МакГоуэна с предисловием Дугласа Т. Росса «Методология структурного анализа и проектирования». Ниже в статье я буду цитировать авторов этого фундаментального труда (другого такого же на русском языке не издавалось).

Речь пойдет о моделировании сложных систем. И вот первая цитата (курсив автора статьи):

«Под словом «система» мы понимаем совокупность взаимодействующих компонент и взаимосвязей между ними… Под термином «моделирование» мы понимаем процесс создания точного описания системы. Особенно трудным оказывается описание систем средней сложности, таких, как система коммутаций в телефонных сетях, управление аэровоздушными перевозками или движением подводной лодки, сборка автомобилей, челночные космические рейсы, функционирование перерабатывающих предприятий. С точки зрения человека, эти системы описать достаточно трудно, потому что они настолько велики, что практически невозможно перечислить все их компоненты со своими взаимосвязями… Наша неспособность дать простое описание, а следовательно, и обеспечить понимание таких систем делает их проектирование и создание трудоемким и дорогостоящим процессом и повышает степень их ненадежности. С ростом технического прогресса адекватное описание систем становится все более актуальной проблемой. SADT (аббревиатура выражения Structured Analysis and Design Technique — методология структурного анализа и проектирования) — это методология, разработанная специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности».

Что можно сказать? Крупная организация (от 1000 человек, например) – это сложная система. Разработка комплексной модели бизнес-процессов организации – это создание модели сложной системы.

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

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

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

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

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

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

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

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

• иерархическая модель бизнес-процессов, включающая 5-6 уровней декомпозиции;
• уровни 1-3 (уровень 0 – контекстная диаграмма), местами до 4, описаны в нотации IDEF0;
• уровни 4-6 и ниже описаны в нотации BPMN;
• общее количество «процессов» (разного уровня) на диаграммах 1-6 уровней – 262 144 (если считать по 8 объектов на каждом уровне).

Последняя цифра не должна никого вводить в заблуждение или пугать. Это транзакции -элементарные действия, выполняемые отдельными сотрудниками или информационными системами. Много это или мало? По сравнению с численностью транзисторов на кристалле последней модификации Intel – это очень мало… По сравнению с численностью сотрудников… много? Не факт. Если в вашем холдинге работает 10 тыс. человек, то это всего лишь 26 транзакций на человека. Очевидно, что сотрудник выполняет гораздо больше элементарных действий во время повседневной работы (а значит для полного описания системы нужен еще уровень 7 или, даже 8).

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

Если же вы хотите создать полную цифровую модель бизнеса (что пока, конечно, утопия), то придется переходить на уровни 7-8. Но в ближайшем будущем, при использовании технологий Big Data, BPM, ERP, MES и искусственного интеллекта такая задача уже не будет казаться утопией…

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

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

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

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

Посмотрите на рис. 1. На нем представлена цифровая модель здания.

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

Кстати, если вы внимательно посмотрите на так называемое «программное обеспечение для моделирования бизнес-процессов» (даже импортное), то увидите там идеологическое отставание функционала, как минимум, на 15-20 лет. Например, ни в одной такой системе невозможно быстро отключить те или иные «слои», чтобы увидеть те аспекты модели, которые интересуют аналитика в данный момент. Или, например, автоматически сформировать диаграмму всех процессов одного уровня со всеми связями между ними, отследить движение конкретного документа через систему или увидеть в виде анимации последовательность запуска процессов в рамках конкретного сценария… (ограниченные возможности такого рода есть в некоторых системах для Process Mining). Создание моделей сложных организационных систем в современном софте для бизнес-моделирования исключительно неудобно и трудоемко!

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

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

Посмотрим, насколько методология SADT годится для построения архитектуры бизнес-процессов организации в виде инженерной модели бизнеса (ИМБ).

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

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

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

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

Количество объектов

Во-первых, хотел бы отметить требование по количеству процессов на одной диаграмме. Ограничение SADT – от 3 до 6 объектов. Цитата: «Диаграмма ограничивается 3-6 блоками для того, чтобы детализация осуществлялась постепенно. Вместо одной громоздкой модели используется несколько небольших взаимосвязанных моделей, значения которых взаимно дополняют друг друга, делая понятной структуризацию сложного объекта…».

Но практика создания моделей организации показывает, что 6 – это слишком мало (8-10 – нормально). Если жестко следовать ограничениям SADT, то появляются псевдо-уровни, усложняющие модель без практической необходимости (особенно при использовании в методологии цикла PDCA, рекомендованного РД РФ по IDEF0). Возможно, ограничение в 6 объектов было уместно, когда чертежи делали вручную на кульмане. Но сейчас это требование, на мой взгляд, устарело.

Смысл стрелок на диаграммах

Теперь рассмотрим интерпретацию стрелок на диаграммах SADT. Для начала приведу несколько цитат:
• «Дуги на SADT-диаграмме изображаются одинарными линиями со стрелками на концах. Для функциональных SADT-диаграмм дуга представляет множество объектов…»
• «Таким образом, SADT-диаграммы не являются ни блок-схемами, ни просто диаграммами потоков данных. Это предписывающие диаграммы, представляющие входные-выходные преобразования и указывающие правила этих преобразований . Дуги на них изображают интерфейсы между функциями системы, а также между системой и ее окружающей средой…»
• «Дуга в SADT редко изображает один объект. Обычно она символизирует набор объектов…»
• «…дуги SADT изображают иерархические наборы данных…».

Снимите крышку с системного блока своего компьютера. Что вы там видите? Набор функциональных блоков, связанных шлейфами. Их минимальное количество… Откройте капот вашего автомобиля. Так же картина – почти все провода, управляющие агрегатами, связаны в жгуты и убраны в защитные гофрированные трубки. Почему инженера так поступают? Почему не соединяют устройства напрямую кучей проводков? Потому, что такая система имела бы высокую сложность, крайне низкую надежность и ремонтопригодность. Внутри вашего компьютера был бы огромный, запутанный клубок проводов!

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

Итак, дуга SADT или стрелка на диаграмме IDEF0, например в Business Studio, — это труба по которой движется поток объектов: информация, документы, материальные ресурсы. Еще раз обращаю ваше внимание: «…кабели, соединяющие, разъединяющие и переносящие многообразие объектов..».

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

Количество стрелок

SADT ограничивает количество стрелок с каждой стороны процесса числом 6. Т.е. я могу провести шесть стрелок от одного процесса к другому. И здесь мы наблюдаем одно из самых методически плохо проработанных мест в SADT. Методом выбора стрелок и их именования является метод… пристального взгляда! Еще одна цитата:

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

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

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

Однонаправленность стрелок

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

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

Тоннельные стрелки

Крупнейшая провокация SADT – это тоннельные стрелки. Неопытные пользователи IDEF0 один раз вкусив «прелесть» тоннельных стрелок начинают их использовать даже… на диаграмме А0. В итоге разваливается вся модель.

Как же Марка и МакГоуэн обосновывают наличие тоннельных стрелок в методологии SADT? Вот некоторые цитаты (много, но по делу):

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

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

Создавать сначала модель объектов, а потом процессов

Приведу еще некоторые важные цитаты:

• «Чем лучше проанализированы объекты системы, тем полнее функциональные диаграммы будут описывать работу системы. Из этого следует, что декомпозиция данных должна начинаться раньше и проводиться согласованно с декомпозицией функций. Хорошая декомпозиция данных является ключом к хорошей декомпозиции функций..».
• «…Вот почему SADT предусматривает дополнительное описание полной иерархии объектов системы посредством формирования глоссария для каждой диаграммы модели и объединения этих глоссариев в Словарь данных. Таким образом, Словарь данных, важное дополнение модели, становится основным хранилищем полной иерархии объектов системы..».
• «Списки объектов системы, создаваемые в ходе моделирования, в SADT принято называть «списками данных»» Термин «данные» здесь употребляется как синоним слова «объект»… Составление списка данных является начальным этапом создания каждой диаграммы функциональной SADT-модели. Правило заключается в том, чтобы вначале составить список данных, а потом список функций…
• «В современных аналитических методах слишком часто уделяется повышенное внимание функциям в ущерб данным. Начиная с составления списка данных, вы сможете избежать перехода к немедленной функциональной декомпозиции. Списки данных помогут выполнить более глубокий анализ и при этом не концентрироваться на функциях системы, избегая пробелов, которые часто возникают из предвзятых представлений о функциональных декомпозициях».

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

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

Исключение составляет ситуация, когда сначала создают документ в справочнике «Объекты деятельности», а потом переносят его на диаграмму. Автоматически создается стрелка с тем же названием. По данной стрелке передается документ, на основе которого стрелка была создана. Но такой способ годится только на самом нижнем уровне описания в нотации IDEF0. Если применять его на А0, то вы получите лес стрелок и абсолютно нечитаемую диаграмму.

Кстати, в Business Studio 4.2. (текущая версия на момент написания статьи) сформировать иерархический справочник объектов деятельности невозможно – только линейный список. Либо приходится создавать псевдо-иерархию за счет использования папок.

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

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

Как можно доработать SADT для решения указанных проблем?

Сформулируем некоторые практические правила использования SADT для создания действительно инженерной архитектурной модели бизнеса (в Business Studio):

1. два процесса на схеме (в случае двустороннего взаимодействия между ними) могут соединяться только двумя стрелками («правило двух стрелок» — туда и обратно); стрелки (трубы) именуются, например, следующим образом: БП1.И1-БП2.В1 (исходящая стрелка 1 Бизнес-процесса 1 поступает как входящая стрелка 1 в Бизнес-процесс 2);
2. на каждом уровне модели (до уровня BPMN) определяются процессы управления;
3. по каждой стрелке должны двигаться реальные объекты из справочников (информация, документы, материальные ресурсы);
4. внешние ссылки разрешены только на диаграмме А0;
5. использование междиаграммных ссылок (МДС) запрещено на всех диаграммах (исключение может быть только одно – когда создано две отдельных модели в IDEF0 (у каждой своя контекстная диаграмма) и их нужно связать между собой. Но в этом случае допускаются только МДС на диаграмме А0).

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

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

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

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

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

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

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

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

Если бы в Business Studio была возможность включать/выключать отображение различных типов стрелок (например, показать только управление и отчетность), то модель можно было разрабатывать и смотреть по слоям. Такое решение было бы намного удобнее.

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

Выводы

По итогам анализа недостатков методологии SADT можно сделать следующие выводы:
• методология SADT в классическом варианте содержит ряд допущений, которые не позволяют использовать ее для создания инженерной модели бизнеса (ИМБ);
• за счет отмены тоннельных стрелок и введения новых правил моделирования можно скорректировать методологию SADT и сделать ее применимой для создания ИМБ;
• существующие системы бизнес-моделирования (такие, как ARIS или Business Studio) крайне неудобны для создания сложной ИМБ;
• есть основания полагать, что ИМБ может служить платформой для создания полной цифровой модели бизнеса путем интеграции подсистем управления и ряда функциональных приложений на единой процессной платформе.

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

Ноябрь 2018 г.

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

Краткое введение

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

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

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

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

Функционально-целевая модель ССБП

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

Как видно на рис. 1, основной результат или цель функционирования ССБП в целом – это «Возможность ведения прозрачного, управляемого и эффективного бизнеса» для собственников и топ-менеджмента. Не думаю, что для кого-то из собственников это не важно.
Надеюсь, вы обратили внимание на термин «Возможность» в формулировке результата. Честно говоря, я не люблю (на то имеются конкретные основания), когда используют термин «Обеспечение» при формулировке целей. Термин «возможность» — довольно близкий. Но в данном контексте понятные, корректные и актуальные регламенты – это действительно ВОЗМОЖНОСТЬ для руководителей — возможность эффективного контроля и управления процессами. А вот воспользуются ли они этой возможностью – это другой вопрос. Это другая часть системы управления, которую я в данной статье не рассматриваю.
Надеюсь, что представленная модель будет иметь для вас ценность. После осмысления схемы рис. 1, вы сможете четко обосновать для собственника компании ценность ССБП и суть каждого процесса в системе.

Рассмотрим кратко каждый процесс, представленный на схеме рис. 1.

1. Управление системой стандартизации бизнес-процессов

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

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

Основной результат: Глубокое и адекватное понимание процессов бизнеса. Понимание возможностей оптимизации процессов
Описание: Первый результат дает возможность регламентации процессов. Если мы глубоко и адекватно понимаем выполняемые процессы, знаем важные практически нюансы, мы способны создавать регламенты, основанные на 100% понимании процессов. Это – одно из важнейших условий эффективной работы по регламентам.
Второй результат заключается в возможности инициации и выполнения внутренних проектов организационного развития, которые изменяют процессы организации. Точки старта – это понимание проблем в процессах и путей их устранения.

3.Разработка НДМ

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

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

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

5. Поддержка базы знаний и web-портала

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

6. Хранение НМД и выдача копий НМД

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

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

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

8. Инвентаризация НМД

Основной результат: Соответствие стандартов требованиям бизнеса.
Описание: Цель процесса практически повторяет цель процесса № 7, но методы выполнения этих процессов разные. Инвентаризация НМД проводится раз в полгода (год) более сложным методом. Выявляется реальное состояние каждого НМД с точки зрения актуальности и практической полезности для бизнеса.

9. Отмена НМД

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

10. Анализ использования НМД и оценка эффекта для бизнеса

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

11. Внутренний аудит

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

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

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

Модель потоков

На рис. 2 так же показана модель ССБП, но вместо описания ценности (главного результата), создаваемой каждый процессом, представлены потоки документов (информации).

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

Вполне вероятно, что читателю данная схема будет более понятна. Она вполне подходит для дальнейшей декомпозиции каждого подпроцесса, например, в нотации CFFC, BPMN или eEPC.
Хотел бы привести небольшую практическую рекомендацию по выполнению такой работы. Прежде чем начать формировать модели подпроцессов ССБП (т.е. выполнять декомпозицию), рабочей группе проекта внедрения ССБП целесообразно заполнить таблицу, содержащую следующие столбцы:
• №.
• Наименование процесса.
• Главная цель процесса.
• Входы (информация, документы).
• Выходы (информация, документы).
• Участники.
• Ответственный.

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

Резюме

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

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

Февраль 2016 г.