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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Декабрь 2018 г.

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

Введение

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

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

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

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

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

Организационная структура компании представлена на рис. 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 г.

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

Введение

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

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

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

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

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

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

Процесс, как объект управления

На рисунке 1 схематично представлен процесс, как объект управления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При процессной автоматизации (в BPMS или СЭД) процессное управление так же может не наступить в случае, если за администрирование процесса в информационной системе отвечает технический специалист, но владелец сквозного процесса не назначен (или ничего реально не делает с точки зрения управления и развития процесса).

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

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

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

Семь критериев оценки уровни развития процессного управления

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

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

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

Таблица. Критерии оценки уровня развития процессного управления

Заключение

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

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

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

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

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

Ноябрь 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 г.

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

Введение

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

Для выполнения этой задачи нужны: эффективная система управления проектом, методология, инструмент (система моделирования) и человеческие ресурсы, адекватные по численности и подготовке. Если инструмент можно легко купить, то с методологией и ресурсами всё не так просто. Качество управления проектом сильно зависит от конкретного руководителя.

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

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

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

Кроме того, рассматривается вопрос о принципиальной возможности обучения сотрудников (не специалистов по орг. развитию или ИТ) нотации BPMN для комплексного описания бизнес-процессов организации.

Исходные данные для анализа

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

Обучение проводилось в течение 2 дней на основе методического пособия «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I» (В.В. Репин, 2018 год). В первый день слушателей последовательно знакомили с основами нотации BPMN. Они выполняли ряд связанных между собой заданий, моделируя процесс в среде Business Studio и двигаясь от простого к сложному.

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

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

Требования и правила моделирования устанавливались в «Соглашении по моделированию» компании.

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

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

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

Типовые ошибки моделирования, допускаемы начинающими

Проблема мышки

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

Оборванные входы-выходы

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

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

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

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

Бывает обратная ситуация – на модели верхнего уровня входы/выходы есть, а при переходе на уровень вниз на процессы, описанные в нотации BPMN, эти входы/выходы теряются. Иногда на моделях нижнего уровня в нотации BPMN показывают информационные связи с процессами уровня + 2 выше. Как следствие – низкое качество модели компании в целом.

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

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

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

Некорректная логика процесса

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

Непонимание межпроцессного взаимодействия

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

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

Вторая проблема состоит в том, что отправку сообщений между разными процессами начинают показывать везде, где только можно, причем без всякого содержательного смысла:
• отправляют сообщение в другой процесс (свернутый пул на схеме в Business Studio), который не должен запускаться (инициироваться) – с ним просто есть взаимодействие по входам-выходам (причем, чаще всего, опосредованное – через базу данных или файл-сервер компании);
• отправляют сообщение в свернутый пул под названием «Все процессы», «Поставщик» или, что хуже всего, «Отдел такой-то…» (в Business Studio можно создать свернутый пул из так называемой «Внешней ссылки»);
• отправляют сообщение в процесс, который находится в дереве на 2-3 уровня выше описываемого и сформирован в нотации IDEF0 – отправка «на деревню дедушке»;
• показав отправку сообщения на схеме описываемого процесса, не открывают другой процесс и не дают себе труд продумать, куда попадает отправленное сообщение и как оно повлияет на выполнение другого процесса.

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

Использование таймеров

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

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

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

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

Процесс в процессе (рекурсия)

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

Красота схемы

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

Накопление опыта и исправление ошибок

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

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

Выводы

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

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

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

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

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

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

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

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

Сентябрь 2018 г.

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

Введение

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

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

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

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

Организация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Апрель 2018 г.

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

Введение

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

Что есть процессное управление сегодня?

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

• BPM CBOK – свод знаний в области управления бизнес-процессами — документ, на основании которого можно определить уровень зрелости организации в области процессного управления, сформировать план развития компании.
• Существует более 30 методик оценки уровня зрелости процессов.
• BPMN – стандарт ISO с 2013 года.
• Отраслевые процессные фреймворки (APQC, eTOM, ITIL, SCOR и др.).
• Эффективные средства автоматизации бизнес-процессов (BPMS, ERP в том числе включая элементы роботизации и искусственного интеллекта).
• Проф. стандарт «Специалист по управлению бизнес-процессами» готовится к утверждению.

Так же отмечу, что сегодня каждому руководителю доступны следующие практические методы и инструменты процессного управления:
• паспортизация процессов;
• оперативное управление процессами с использованием системы показателей (KPI), в т.ч. с использованием систем BPM;
• контроль процессов в BPMS и/или в СЭД;
• формирование графических схем процессов (в т.ч. с использованием специального программного обеспечения, например ARIS, iGrafx, MS Visio и др.);
• анализ процессов (в т.ч. графических схем).
• реорганизация процессов (с использованием технологий Lean, автоматизации, управления изменениями, а так же весь арсенал технологий 4-й индустриальной революции);
• регламентация и стандартизация процессов;
• контроль исполнения стандартов (в т.ч. с использованием современных информационных технологий).

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

Пример. Группа компаний «ЕВРАЗ». Проект автоматизации процессов Общего Центра Обслуживания для управления HR услугами. В рамках проекта была автоматизирована работа более 250 сотрудников HR ОЦО. В системе фиксируется 100% операций, происходящих в ОЦО. Автоматизировано более 80 бизнес-процессов HR-блока. Срок обработки обращений сотрудников в HR-службу сократился в 2 и более раза. Существенно снижено количество ошибок. Обеспечено соблюдение нормативных сроков (в начале проекта — для 70% обращений, после выполнения — 90%). Обеспечена прозрачность процессов. Снижение численности HR на 20%.

Пример. Крупный агрохолдинг. Выполнен проект трансформации процессов управления агропроизводством с использованием комплексного ИТ-решения. Проведение комплексной трансформации и автоматизации процессов позволило повысить рентабельность с гектара на 30%.

Пример. Строительная компания. Оптимизация и автоматизация процесса заказа ТМЦ и внедрение системы KPI позволило увеличить операционную рентабельность с 2 до 15%.

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

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

Методы «вовлечения» сотрудников в работу с процессами

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

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

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

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

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

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

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

Отдельно можно отметить инструменты наглядной агитации, а именно:
• плакаты и постеры;
• стенды;
• распечатки на стенах;
• памятки на рабочих местах;
• прочее.

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

Средства агитации могут создать атмосферу типа «У нас принято работать с процессами – посмотрите, как это здорово!». Но они, в большинстве случаев, будут порождать у сотрудников внешний статус мотивации.

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

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

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

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

Пример. Завод по производству ДСП. Рабочие группы за месяц описали и внедрили процессы в области ТОиР.
Пример. Холдинг по производству и реализации птицы. Харизматичный лидер компании поддерживал проект = успешное описание, анализ и внедрение изменений в процессах по методике SCRUM.

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

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

Постоянная практика работы с процессами как ключевой инструмент вовлечения

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

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

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

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

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

Пример. Коммерческий банк. Разработана архитектура процессов. Методикам описания и анализа процессов обучено до 30% персонала. За год работы описано и стандартизовано 1300 процессов. Создан внутренний портал для информирования сотрудников (регламенты, НСД, показатели). Некоторые результаты проекта: заявка на кредит физлица рассматривается за 1 час (ранее – за 2 дня), кредит физлицу выдается за 1 визит (ранее – за 3), уровень доступности банкоматов вырос до 99,97% (ранее – 90%), ускорение времени обработки зарплатного реестра с 4 часов до 0,5 часа, количество структурных подразделений уменьшено на 13%, сокращен ФОТ и на 20% уменьшена численность персонала.

Рекомендации для ООР при внедрении

В заключении сформулирую некоторые рекомендации для Отдела организационного развития компании, которому поручено внедрение процессного подхода. Эти рекомендации основаны на теории и практике внедрения процессного управления и управления изменениями:
• найдите свой локомотив (куратора проекта, лидера из числа руководителей верхнего уровня, собственников);
• определите ключевую проблему и преодолейте препятствия в умах (осознание проблемы руководителями);
• создайте команду изменений (найдите союзников из числа топ-менеджеров и просто уважаемых людей, определите роли, задайте правила);
• создайте видение целевого состояния компании (в т.ч. системы управления);
• сконцентрируйте ресурсы (на ключевых бизнес-процессах);
• создайте нужный статус мотивации у ключевых фигур влияния (топ-менеджеров и собственников);
• вовремя устраняйте политические препятствия;
• постоянно ведите пропаганду;
• СОЗДАВАЙТЕ ПОСТОЯННЫЕ ПРАКТИКИ РАБОТЫ С БИЗНЕС-ПРОЦЕССАМИ.

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

Ноябрь 2017 г., Москва

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

Введение

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

Для понимания масштаба такого тотального описания приведу пример. Компания численностью 2 тыс. человек. Общее количество процессов операционного уровня, которое необходимо описать, — около 1000. Это означает, что мы должны разработать тысячу схем формата А4 (8-15 шагов на каждой) для того, чтобы все действия (операции), выполняемые сотрудниками, попали в модель. Дальнейший анализ загрузки исполнителей позволит решить задачу оптимизации численности и исключения ненужных должностей из орг. структуры компании.

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

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

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

Возможный методический подход

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

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

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

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

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

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

МОЖНО СФОРМИРОВАТЬ КОМАНДУ ПРОЕКТА ИЗ РУКОВОДИТЕЛЕЙ ОТДЕЛОВ, ВКЛЮЧЕННЫХ В КАДРОВЫЙ РЕЗЕРВ. ПРАКТИКА ОПИСАНИЯ И АНАЛИЗА ПРОЦЕССОВ БУДЕТ ИМ ИСКЛЮЧИТЕЛЬНО ПОЛЕЗНА.

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

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

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

По ходу описания и анализа очень важно активно вовлекать руководителей в процесс поиска возможных улучшений. Целесообразно привлечь в команду специалистов по бережливому производству, ТРИЗ и, что особенно важно в наше время, по автоматизации в BPMS, цифровизации (знатоков методов «Индустрии 4.0»).

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

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

Шаг 2. Анализ загрузки должности.
В моделях процессов компании (напомню, что ВСЕ процессы описаны на уровне операций!) исполнителями являются должности и роли. Каждая роль в процессе связана с конкретной должностью. Должность может выполнять несколько ролей в разных процессах. Анализ процессов дает информацию о нормативной трудоемкости каждой операции и количестве операций, выполняющихся в процессах за месяц. Выполняется расчет общей трудоемкости выполнения операций в человеко-часах для должности. Пример: 10 процессов * 3 операции * 3 раза в день * 22 рабочих дня * 15 минут = 29 700 минут.

Шаг 3. Анализ структуры рабочего времени должности.
Выполняется анализ структуры рабочего времени для должности. Определяются: время подготовки к работе, время на постановку и выполнение разовых поручений, время на совещания и перерывы, опоздания, прогулы, больничные (последние три – можно брать как средние для компании по типу должности). Выполняется расчет рабочего времени, доступного для выполнения операций в процессах в течение месяца (общее календарное рабочее время минус сумма всех других времен). Если должность занимают несколько сотрудников, то доступное время умножается на их количество.

Шаг 4. Расчет нагрузки на одного исполнителя.
Общая трудоемкость выполнения операций в процессах сопоставляется с фондом рабочего времени сотрудников, занимающих должность. Пример: 22 рабочих дня * 6 часов * 60 минут = 7 920 минут (реальная формула более сложная). Расчетное количество необходимых сотрудников составляет 29 700 / 7 290 = 3,75, т.е. 4 человека. Допустим, фактически занимают должность – 10 человек. С учетом норматива численности, потенциально можно сократить 5 человек.

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

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

Шаг 7. Анализ возможности исключения должности.
В случае, если должность занимает один сотрудник и его загрузка в процессах недостаточная (например, менее 50%), то рассматривается возможность исключения должности из орг. структуры компании. При этом определяются должности, на которые может быть перераспределена нагрузка сотрудника в процессах.

ТОТАЛЬНОЕ ОПИСАНИЕ ПРОЦЕССОВ ПОЗВОЛЯЕТ НЕ ТОЛЬКО ВЫЯВИТЬ «ЛИШНИХ ЛЮДЕЙ», НО И ПЕРЕРАСПРЕДЕЛИТЬ ЗАДАЧИ ТАК, ЧТОБЫ ОНИ НЕ «ПОВИСЛИ» ПРИ УВОЛЬНЕНИИ СОТРУДНИКОВ.

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

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

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

Экономическое обоснование проекта тотального описания бизнес-процессов

Сделаем простой расчет – экономическое обоснование описания процессов для указанного в начале статьи случая – 2000 человек персонала и 1000 операционных процессов в компании.

Предположим, что средняя зарплата (с учетом налогов и взносов) – 30 тыс. рублей в месяц. Общий ФОТ составит 720 млн. рублей в год.

Трудоемкость описания 1000 процессов из расчета 40-а человеко-часов на 1 процесс – 40 тыс. часов (норматив, выработанный длительной практикой консалтинга по описанию и анализу бизнес-процессов). К этому времени добавим по 4 часа на анализ загрузки каждого исполнителя (с учетом использования полуавтоматизированной системы «скоринга»). В итоге получится трудоемкость проекта – 48 тыс. человеко-часов. Чтобы выполнить проект за год потребуется 25 экспертов. Предположим, что зарплата экспертов – 60 тыс. в месяц. Общий ФОТ на проект – 18 млн. рублей в год.

В случае, если по итогам проекта удается сократить только 10% численности персонала эффект составит 72 млн. рублей. Эффективность проекта будет равной 400%.

Выводы

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

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

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

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

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

Август 2017 г., Москва

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

Введение

По данным статистики 65% компаний занимаются описанием бизнес-процессов, из них в 41% компаний используют специальное программное обеспечение типа Business Studio. (The State of Business Process Management 2016, Paul Harmon, www.bptrends.com). Результатом описания процессов являются графические схемы, выполненные в различных нотациях. Схемы могут быть либо простые и читаемые, либо сложные и запутанные. Но в любом случае, это некоторый упорядоченный по определенным принципам набор шагов, который позволяет визуально представить себе, как выполняется процесс.

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

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

ПЕРВЫЙ ШАГ К ОПТИМИЗАЦИИ ПРОЦЕССА – ЭТО ПОНИМАНИЕ ПРОЦЕССА

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

Возможности и ограничения анализа графической схемы процесса

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

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

Схемы операционных процессов создают при помощи нотаций совершенного другого типа – Work Flow (eEPC, CFFC, BPMN, «Процедура» Business Studio). Базовый принцип создания таких схем – описание цепочки выполнения операций процесса в хронологическом порядке (строго одна за другой).

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

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

Операционный уровень (модель Work Flow):
• анализ технологии выполнения процесса (дублирование, узкие места, возвраты и проч.);
• value-анализ;
• анализ потерь;
• анализ времени выполнения;
• анализ рисков;
• имитационное моделирование (графическая схема – основа для создания имитационной модели).

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

Качество и верификация графической схемы процессы

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

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

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

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

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

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

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

Подробно каждый пункт чек-листа и методика работы с ним представлены в моей статье «Как проверить качество графической схемы процесса?», которая опубликована на портале FineXpert.ru (http://finexpert.ru/view/kak_proverit_kachestvo_graficheskoy_skhemy_protsessa/892).

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

ЧЕМ АДЕКВАТНЕЕ МОДЕЛЬ, ТЕМ БОЛЬШЕ ШАНСОВ ВЫЯВИТЬ РЕАЛЬНЫЕ ПРОБЛЕМЫ ПРОЦЕССА

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

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

При проведении визуального анализа достаточно очень небольшого времени, чтобы определить недостатки этого процесса. Обратите внимание, что на схеме процесса:
1 представлено 5 возвратов (перехода процесса на предыдущий этап);
2 количество повторяемых шагов при однократном возврате: 14;
3 количество информационных систем: 5 (MS Excel, 1С, АСУ «Транспорт», «Финансы», SAP).
4 доля контрольных операций: 57% (сверки, согласования, визирования);
5 доля операций по корректировке данных/документов (после возвратов): 19%.

Если сложить долю контрольных операций и операций по корректировке, то получится 76%. Но добавляют ли эти операции ценность для внутреннего клиента процесса? Ответ очевиден – нет. Таким образом из всего процесса только 24% операций добавляют хоты бы какую-то ценность.

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

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

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

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

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

I. Формальный визуальный анализ схемы

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

II. Визуальный анализ + содержательный анализ

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

Указанные пункты могут быть также оформлены в виде чек-листа.

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

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

III. Визуальный анализ + количественный анализ

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

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

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

Кроме указанных выше методов, для современных процессов можно ввести понятие «Цифровизация ready» и/или «Роботизация ready». Это означало бы, что процесс осмыслен и готов к тотальной цифровизации и роботизации – определены операции, которые необходимо цифровизовать (или цифровизировать) и т.п.

Резюме

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

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

Май 2017 г.

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

Эффект от оптимизации одного процесса

Довольно часто мне задают вопрос: «Как доказать руководству, что оптимизация процесса дает эффект?». Предлагаю простой пример. На рисунке 1 представлен несложный операционный процесс — всего три участника – два исполнителя и руководитель. Процесс включает пять операций и четыре точки ветвления. После каждой из них возможен возврат и переделка работы. После операции № 3 вероятность возврата – 20%, после операции 5 – 10%. Это экспертная оценка. Например, руководитель в среднем «заворачивает» на доработку 10% документов и т.п.

На рисунке показана стоимость каждой операции в рублях. Как ее определить? Самый простой способ: а) оценить нормативное время выполнения операции; б) определить стоимость 1 минуты рабочего времени исполнителя (хоты бы по его зарплате) – будет 5-10 рублей в минуту; в) умножить нормативное время на стоимость одной минуты. Легко рассчитать, что в идеальном варианте (при выполнении без возвратов) стоимость выполнения процесса в целом составит 120 рублей.

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

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

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

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

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

Видение процессной организации

Итак, руководитель решил вплотную заняться процессами организации. Как ему дальше поступить? Брать каждый процесс (из тысячи) и оптимизировать? Понятно, что это заведомо тупиковый путь. Бизнес должен постепенно измениться внутренне. Можно сказать, переродиться в Процессную организацию. Каковые ее ключевые черты? О Процессной организации писали многие. Один из наиболее комплексных подходов был сформулирован Майклом Хаммером в модели оценки зрелости процессной организации PEMM (Process and Enterprise Maturity Model). Еще одним документом, весьма полезным для осмысления возможностей, является BPM CBOK – свод знаний в области управления бизнес-процессами. Любому руководителю желательно его прочитать.

Обратимся к модели PEMM Майкла Хаммера. Она представлена в таблице 1.

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

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

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

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

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

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

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

Четвертый аспект в модели PEMM Майкла Хаммера – это Структура управления процессами. Для зрелой организации она характеризуется следующим образом:
• модель бизнес-процессов компании интегрирована с поставщиками и потребителями, используется для стратегического развития бизнеса;
• владельцы процессов;
• совет по бизнес-процессам;
• руководящий Комитет с участием представителей поставщиков и потребителей;
• совместная работа владельцев процессов с ВП поставщиков и потребителей.

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

1. Цели и принципы Процессной организации.
2. Архитектура, сквозные процессы, интеграция на межфункциональном и межорганизационном уровне.
3. Управление процессам (Процессный совет, владельцы процессов, менеджеры процессов, Процессный офис, Цели и показатели для управления процессами).
4. Методики (PDCA, оптимизация процессов, управление изменениями и проч.).
5. Компетенции (руководителей и специалистов).
6. Командная работа, вовлечение персонала.
7. Мотивация (руководителей и специалистов).
8. Культура организации.

Другой вариант – доработка вашей Стратегии с учетом указанных выше пунктов.

Для примера, в таблице 2 представлен результат мой субъективной экспертной оценки типичной российской торгово-производственной компании численностью до 500 человек («собирательный образ»). Зеленый цвет – утверждение полностью соответствует действительности, желтый – менее 50%, красный – менее 25%, черный – 0%.

Семь шагов процессной трансформации бизнеса

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

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

1. Самооценка.
2. Видение.
3. Архитектура и управление.
4. Организация.
5. Компетенции.
6. Анализ.
7. Внедрение.

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

Видение. Далее необходимо разработать видение (концепцию) Процессной организации. Основываться можно так же на указанных выше источниках (PEMM, BPM CBOK, CMMI, ISO 15504 и др.), информации о других компаниях, своем здравом смысле.

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Февраль 2017 г.