Методы визуального анализа графической схемы бизнес-процесса в нотации BPMN
Методы визуального анализа графической схемы бизнес-процесса в нотации BPMN
В статье Владимира Репина раскрываются методы визуального анализа графической схемы бизнес-процесса в нотации BPMN в Business Studio 5. Они могут быть использованы для выявления проблем, связанных с выполнением процесса, и разработки мероприятий по его оптимизации. Материал может быть полезен руководителям и специалистам, вовлеченным в проект описания и оптимизации бизнес-процессов компании.
Введение
В настоящее время для многих компаний является весьма актуальной задача анализа, оптимизации и цифровизации бизнес-процессов.
Метод визуального описания бизнес-процессов в нотации BPNM является одним из ключевых для решения этой задачи.
Какие проблемы, связанные с выполнением бизнес-процесса, могут быть выявлены путем визуального анализа графической схемы? В статье я привожу описание возможных методов и некоторые примеры их применения.
Требования к графической схеме бизнес-процесса
Прежде всего определимся с контекстом, точкой зрения и целью анализа.
Контекст – в компании создан Процессный офис, который использует программный продукт Business Studio для моделирования и анализа бизнес-процессов в нотации BPMN. Разработан и используется внутренний стандарт по описанию процессов («Соглашение по моделированию»).
Точка зрения – взгляд на выполняемую деятельность со стороны владельца бизнес-процесса.
Цель – выполнить описание и анализ бизнес-процесса «Как есть» для выявления возникающих проблем и разработки мероприятий по оптимизации/цифровизации бизнес-процесса, создания модели процесса «Как должно быть».
Важно отметить, что возможность визуального анализа определяется качеством и аналитической полнотой графической схемы. Логически некорректная модель с отсутствием какой-либо аналитики («Голый поток Work Flow») вряд ли подойдет для решения указанной выше задачи.
Можно сформулировать четыре группы критериев, которым должна удовлетворять графическая схема в нотации BPMN, которую предполагается использовать для анализа проблем:
- Отсутствие нотационных и логических ошибок.
- Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем.
- Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика).
- Визуальная наглядность и красота схемы (стиль).
Кратко пройдемся по этим критериям. Отсутствие нотационных и логических ошибок является базовым требованием. Схема, содержащая ошибки, тем более, логические, — непригодна для анализа. Для формального контроля качества схемы можно использовать чек-лист, который может содержать, например, следующие разделы:
• корректность формулировок названий объектов на схеме;
• корректность описания входов/выходов;
• корректность описания событий (стартовых, промежуточных, завершающих);
• логические ошибки;
• адекватное описание множества обрабатываемых в рамках процесса объектов;
• архитектурные ошибки (дублирование группы задач вместо использования «Типового процесса» и проч.);
• неоднородность по масштабу выполняемых задач;
• аккуратность исполнения схемы, наглядность.
Наличие на схеме потоков документов (информации), статусов документов, хранилищ данных (ресурсов), используемых информационных систем является ключевым для возможности выполнять анализ. Подробно о создании таких схем я написал в статье «Моделирование информационных потоков в нотации BPMN в Business Studio 5». Рекомендую обратить внимание на представленные там требования.
Содержательное соответствие реальному процессу (Модель «Как есть», адекватная семантика). Речь идет о том, что модель действительно соответствует процессу «Как есть», то есть содержит все реально выполняемые задачи без пропусков, упрощений и т.п.
На рис. 1 показан фрагмент схемы процесса. Слева – то, что было в созданной модели «Как есть». Справа – реальный процесс, в рамках которого осуществляется ручная передача документа от сотрудника к сотруднику. Такого рода ситуации, когда документ (информация) мгновенно и непонятно каким образом перемещаются от задачи к задачи, скорее могут служить иллюстрацией к фантастическому роману, чем для целей практического анализа бизнес-процесса.
Адекватная реальности семантика. Нотация BPMN является весьма сложной. Важно понимать, что она была разработана для проектирования исполняемых в BPM-системе процессов. Движок такой BPM-системы, если объяснять не уходят в технические детали, интерпретирует значки нотации BPMN определенным образом и генерирует исполняемый код без участия человека. При исполнении бизнес-процесса в BPM-системе семантика графической схемы реализуется через соответствующий функционал. Например, могут быть использованы такие решения, как: межпроцессное взаимодействие путем отправки/получения сообщений, граничные события различного типа, завершение процесса типа «Terminate», триггеры, сигналы, компенсации и прочее.
Но в реальном, неавтоматизированном бизнес-процессе (типичный пример: Outlook + функциональная система) ничего этого нет – передача информации, остановки, уведомления осуществляются вручную сотрудниками. Поэтому схема бизнес-процесса «Как есть», созданная бизнес-аналитиком с использованием сложной семантики BPMN, реализуемой только в BPM-системе, в действительности не соответствует реально выполняемому процессу. При чтении такой схемы совершенно непонятно, как выполняется процесс в действительности.
Некоторые бизнес-аналитики, «нахватавшись» красивых значков BPMN, начинают «лепить» их где и как попало, глубоко не анализируя процесс и не прописывая нюансы его практического выполнения.
Поэтому для описания неавтоматизированного бизнес-процесса «Как есть» настоятельно рекомендую использовать только самые простые конструкции нотации BPMN. Кроме того, важно подробно описать допустимые в моделях «Как есть» интерпретации значков BPMN в «Соглашении по моделированию».
Если цель – создание модели бизнес-процесса для исполнения в конкретной BPMS, то создавать эту модель «Как должно быть» нужно понимая, какой конкретно функционал имеет система, то есть какие возможности нотации BPMN она поддерживает.
Визуальная наглядность и красота схемы (стиль). Схемы могут сложными, но понятными, а могут быть содержательно простыми, но до крайности визуально запутанными (см. пример на рис. 2).
Например, в одной компании, в которой я проводил анализ качества схем в нотации BPMN, было жесткое требование размещать модели на листе формата А4. Это приводило к тому, что бизнес-аналитики делали на схеме «Змейку» и она становилась крайне сложной для восприятия. Это можно назвать плохим стилем моделирования.
Визуально наглядная, красивая схема гораздо больше подходит для целей анализа, чем запутанная и неряшливо нарисованная.
Какие проблемы можно выявить, анализируя схему бизнес-процесса?
Путем визуального анализа графической схемы бизнес-процесса можно выявить следующие проблемы:
• Технология выполнения процесса: некорректный состав, последовательность выполнения задач процесса, дублирование, отсутствие бизнес-правил.
• Дезинтеграция процесса по информационным системам (ручной перенос информации (документов) из системы в систему).
• Потеря важной информации (документов) при выполнении процесса.
• Отсутствие необходимой интеграции между процессами.
• Возвраты, излишние согласования.
• Узкие места.
• Задачи, не добавляющие ценность, потери.
Ниже рассмотрим каждую из указанных видов проблем.
Технология выполнения бизнес-процесса
Пример. Коллеги из довольной крупной компании разработали схему процесса «Создание, согласование и закрытие заявки на подбор» — см. рис. 3.
Проблемой является то, что проверка корректности заполнения заявки на подбор выполняется специалистом после того, когда руководитель подразделения и руководитель бизнес-единицы уже ее согласовали. То есть в случае выявления формальных замечаний, заявку придется возвращать в самое начало бизнес-процесса, что существенно увеличивает его длительность и приводит к дополнительным затратам.
Кроме того, процесс «Подбор персонала» включен в рассматриваемый процесс, как типовой. На мой взгляд, это несколько некорректно с точки зрения архитектуры бизнес-процессов HR в целом.
Анализ схемы может показать, например, что результат процесса не передается его инициатору, то есть «зависает». Инициатор вынужден сам как-то его добывать. Это означает, что границы процесса определены некорректно.
Анализ графической схемы позволяет выявить некорректную последовательность выполнения задач сотрудниками, отсутствие необходимых задач, лишние задачи и т.п.
На рис. 4 показан фрагмент схемы процесса, из которого видно, что в нужном месте отсутствует бизнес-правило. Менеджеры отправляют проекты предоплатных договоров одновременно клиентам и юристу. Некоторые – сначала юристу, потом клиентам. В случае, если у юриста есть замечания, то менеджерам по продажам приходится отзывать проекты договоров и отправлять клиентам вторые версии, что неэффективно и снижает удовлетворенность клиентов.
Еще один пример отсутствия бизнес-правила представлен на рис. 5. Менеджеры работают с заказчиками по-разному. Ряд заказчиков подписывает договор и присылает его скан, ряд – нет. Четко не определено, должны ли менеджеры требовать от заказчиков присылать подписанные сканы договоров или достаточно версии в формате MS Word и протокола разногласий и т.д.
Пример дублирования. На схеме рис. 6 показан фрагмент бизнес-процесса управления дебиторской задолженностью. Видно, что менеджер продаж и отдел управления просроченной дебиторской задолженностью дублируют контроль, пользуясь одними и теми же данными из автоматизированной системы управления компании.
Дезинтеграция процесса по информационным системам
На том же рис. 6 видно, что бизнес-процесс не интегрирован по информационным системам – наблюдается ручная передача информации в Outlook, ручная выгрузка из АСУ в MS Excel, потом в MS Word, сохранение в pdf-формат, звонки и e-mail-ы клиентам.
Ручной перенос данных между системами, как правило, является весьма трудоемким. Эта работа занимает значительную часть рабочего времени квалифицированных специалистов (например, ведущих менеджеров по продажам), лишая их возможности эффективно использовать это время для продаж, обслуживания клиентов, работы с поставщиками, аналитики, развития и проч. Кроме того, очевидно, что такой ручной перенос приводит к заметным задержкам при выполнении бизнес-процесса и сопряжен со значительными рисками некорректного ввода данных.
Потеря важной информации (документов) при выполнении процесса
Отсутствие интеграции между ИС, ручной перенос данных и отсутствие бизнес-правил часто сопряжены с проблемой потери важной информации (документов) при выполнении бизнес-процесса. Исполнитель либо не осознает важности этой информации для компании и не вносит ее в систему, либо бессистемно сохраняет документы на своем рабочем компьютере или, вообще, хранит их только в почте. Исполнитель может просто лениться сохранять информацию (документы) путем внесения, например, в CRM, сохранения в базе данных или на файл-сервере компании.
Отсутствие четких требований по работе с информацией, зафиксированных в регламенте, и контроля приводят к тому, что исполнители теряют важную для компании информацию.
Такая потеря информации (документов) в дальнейшем может привести к необходимости повторного сбора данных, запроса документов, к невозможности провести необходимый анализ для принятия решений и проч.
Отсутствие необходимой интеграции между процессами
На рис. 7 показан фрагмент бизнес-процесса приемки товара на склад гипермаркета торговой сети. В случае, если количество мест больше, чем указано в накладной, кладовщик «уведомляет менеджера по закупу» по яндекс-почте.
Но менеджер по закупку может: 1) случайно удалить письмо; 2) увидеть письмо со значительной задержкой; 3) отложить работу с поставщиков «на потом» без контроля сроков. Таким образом, проблема, возникшая в одном бизнес-процессе и нуждающаяся в решении, не связана с запуском на исполнение другого процесса. Кроме того, информации о проблеме не зафиксирована в системе и может быть потеряна.
Представленный выше пример весьма типичный. Очень часто можно увидеть на схемах ситуацию типа: «Уведомить менеджера…», «Переслать информацию в такой-то отдел» и т.п.
Плохо то, что при выполнении бизнес-процессов не запускаются другие процессы, а идет «уведомление» сотрудников, не контролируется сроки начала соответствующих действий, теряется непрерывность, возникают зоны безответственности.
Возвраты, излишние согласования
При выполнении бизнес-процессов часто возникают возвраты. Например, на рис. 8 показан возврат на повторное согласование договора.
Чем плохи возвраты? Они: 1) многократно увеличивают длительность выполнения процесса; 2) увеличивают затраты; 3) могут негативно влиять на качество результата процесса; 4) негативно сказываются на отношении сотрудников к работе (бесконечные переделки и уточнения, повторное выполнение одних и тех же задач мало кому понравится).
В свое время Филипп Кросби, известный специалист в области менеджмента качества, сформулировал принцип «Делать всё правильно с первого раза». Почему же сотрудникам сложно его придерживаться? В чем причины возвратов? Думаю, в следующем. К ним приводят:
• нечетко поставленные задачи;
• недостаток информации у исполнителя;
• некачественные входы (информация);
• отсутствие методик/бизнес-правил у исполнителя;
• недостаточная квалификация исполнителя;
• ошибки («человеческий фактор»).
Исполнитель получил задачу и выполнил ее. Но оказалось, что руководитель имел в виду немного другое. Приходится переделывать.
Например, исполнитель не смог выполнить задачу качественно из-за недостатка исходных данных или их несоответствия требованиям.
Методика выполнения задачи могла быть вообще не определена или описана поверхностно (плохой регламент), так что исполнителю пришлось самому решать, что значит правильный метод выполнения, полагаться на свой опыт или рекомендации коллег по работе. Но этот опыт и эти рекомендации не всегда адекватны ситуации и могут привести к проблемам, например, созданию аварийных ситуаций, возникновению потерь ресурсов, снижению техники безопасности и проч.
Если задача была поручена исполнителю, квалификация которого не соответствует уровню ее сложности, то сотрудник может допустить ошибку или выполнить работу некачественно.
Не стоит исключать и человеческий фактор: физическая усталость, моральное утомление (например, в случае выполнения рутинной, монотонной работы по разнесению УПД из «Контур.Диадок» в 1C-ERP при крайне медлительной работе программы), негативное отношение к выполняемой работе и, в целом, — к компании, отсутствие лояльности и т.д.
Но в чем коренные причины указанных выше проблем? Кто виноват? Сами сотрудники? Нет. Еще дедушка Эдвардс Деминг, специалист мирового масштаба и отец новой философии управления, говорил, что 95% проблем, возникающих у сотрудников при выполнении процессов, обусловлены не плохим отношением людей к работе, а теми бизнес-процессами, системой, которую создали сами менеджеры компании.
Поэтому наличие большого количество возвратов на схеме процесса красноречиво говорит о недостатках в работе руководителей.
Эту мысль ярко демонстрирует еще один пример, показанный на рис. 9. В рамках представленного бизнес-процесса исполнитель вносит изменения в некий важный и довольно сложный документ. Затем идет параллельное согласование его специалистами, а уже потом последовательное согласование руководителями.
На рис. 9 видно огромное количество согласующих лиц, причем после каждого руководителя процесс может вернуться к началу. Говорить о том, сколько времени занимает такое процесс, даже не хочется… В лучшем случае, в крупной компании – это месяцы.
Еще одним негативным аспектом такого рода бизнес-процессов является размытие ответственности за результат между руководителями. Э. Деминг указывал, что дублирование контроля в случае, если его выполняют люди, часто приводит к снижению качества результата именно из-за психологического фактора: каждое последующее согласующее лицо в той или иной степени надеется, что предыдущий руководитель уже проверил документ и не нужно особенно напрягаться для выявления проблем.
Очевидно, что такая практика организации бизнес-процесса, как показано на рис. 9, является порочной. Подобные процессы подлежат радикальному перепроектированию на основе разработки четких бизнес-правил и, конечно, цифровизации подготовки и принятия решений.
Узкие места
Еще одной проблемой, которую можно выявить путем визуального анализа схемы, являются узкие места в процессе. Они могут быть видны визуально, но чаще выявляются содержательно в том случае, если ресурс исполнителя ограничен, например: договора создают многие менеджеры, но в 1С-КА вводит данные только один сотрудник. Выполняемая им задача и он сам становятся узким местом.
На рис. 10 показ пример кадрового процесса одной из крупных компаний. По нему движется документ, который дополняют и согласуют множество руководителей. Несмотря на то, что процесс автоматизирован в СЭД, в нем возникло узкое место, обведенное овалом. Специалист подразделения кадров осуществляет ручной контроль после каждой задачи согласования и «проталкивание» процесса между его участниками.
Хотя все участники процесса используют СЭД, назвать этот процесс автоматизированным, а тем более цифровым, нельзя. Автоматизация, предполагающая постоянный ручной контроль и «проталкивание» документов, является неэффективной.
Сотрудник подразделения кадров явно является узким местом, ограничением в процессе. В случае его загрузки другими задачами, болезни, отпуска при выполнении процесса возникают проблемы, в первую очередь, значительное увеличение его длительности.
Кроме того, на практике многие руководители вынуждены связываться между собой вне процесса (телефон, личные встречи), чтобы ускорить выполнение процесса и получение важного для них результата.
В целом, двигать документ вдоль процесса тогда, когда можно двигать только данные (информацию) – неэффективно. Именно поэтому современные системы класса BPM, с точки зрения цифровизации, имеют значительные преимущества по сравнению с СЭД, тем более устаревших версий.
Задачи, не добавляющие ценность, потери
При выполнении бизнес-процесса часто можно выявить задачи, которые не создают ценность с точки зрения создания его результата и потребностей потребителя (внутреннего и/или внешнего). Выполнение многих задач связано с возникновением потерь различного вида.
Приведу несколько примеров действий, которые не создают ценность, но влияют на увеличение потерь:
• ручной перенос информации из одной информационной системы в другую (например, из pdf-файла в 1С);
• ожидание отклика информационной системы сотрудником при выполнении загрузки данных, сохранении, проведении проводок; зависания и «вылеты» системы; ожидание начала совещания у руководителя;
• неудобный интерфейс программы и, как следствие, много лишних действий исполнителя (движения мышкой от одного места экрана к другому, сложные многоуровневые меню и т.д.);
• ручное перемещение документов от одного рабочего места к другому в рамках, например, процесса согласования;
• выполнение расчетов и подготовка документов (отчетов), которые потом не используются;
• частые перемещения внутри офисного помещения (рабочее место – принтер – рабочее место), перемещения между разными этажами офиса, пешие перемещения сотрудников по территории крупного производственного предприятия и проч.;
• переделка документов из-за выявленных ошибок.
Выводы
Визуальный анализ графической схемы бизнес-процесса в нотации BPMN – мощный практический метод, позволяющий быстро получить информацию о возникающих проблемах и наметить пути оптимизации процесса.
В рамках деятельности Процессного офиса для описания и оптимизации бизнес-процессов целесообразно разработать:
- чек-лист формального анализа качества графической схемы бизнес-процесса;
- чек-лист содержательного анализа для выявления проблем и определения возможных мероприятий по оптимизации процесса.
Бизнес-аналитики Процессного офиса и участники временных рабочих групп из числа руководителей и специалистов могут взять на заметку рассмотренные в статье методы, детально проработать их и успешно применять на практике.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Февраль 2023 г.
Вы можете посмотреть видео по данной теме:
Фреймворк проекта оптимизации сквозного бизнес-процесса
Фреймворк проекта оптимизации сквозного бизнес-процесса
В статье Владимира Репина представлен Фреймворк проекта оптимизации сквозного бизнес-процесса компании. Схемы процессов и их описание разработаны с учетом опыта выполнения проектов командой BPM3.RU, а так же на основе анализа практики российских компаний. Материал может быть полезен для разработки внутреннего стандарта работы по анализу и оптимизации сквозных процессов, для сравнения с существующей практикой и определения направлений ее совершенствования.
Цели создания Фреймворка
Вашему вниманию предлагается процессный Фреймворк – комплексная модель процессов, которые необходимы для выполнения проекта оптимизации сквозного бизнес-процесса. Ранее в статье «Бизнес-процесс на ладони: простые методы анализа и оптимизации» были раскрыты методы выполнения анализа процесса и принципы его оптимизации. Рассматриваемый Фреймворк раскрывает вопрос организации такого проекта.
Процессы Фреймворка были спроектированы в результате анализа проектов оптимизации процессов, выполненных командой консультантов BPM3.RU, а так же с учетом опыта организаций, ведущих соответствующие проекты.
Условия применимости. Представленный Фреймворк может быть использован в случае, когда необходимо системно организовать работу по оптимизации сквозных бизнес-процессов масштаба компании, то есть значительных по сложности и длительности проектов межфункционального уровня. Использовать такой подход для оптимизации процессов внутри структурных подразделений, т.е. для относительно простых задач, не требуется.
Предполагается, что в компании созданы и активно функционируют Процессный комитет и Процессный офис, создана процессная архитектура и используется инструмент проектирования и анализа процессов (например, Business Studio), определен и используется метод назначения владельцев сквозных процессов, в достаточной степени развита культура проектного управления. Для организаций, только приступающих к внедрению процессного управления, представленный Фреймворк может быть упрощен в необходимой степени.
Контекст
Процессный Фреймворк был разработан в нотациях IDEF0 и BPMN в Business Studio 5. На рис. 1 представлена его контекстная диаграмма. Ключевыми входами в процесс являются: стратегия организации, мнения руководителей и специалистов, предложения сотрудников, результаты аудитов и, конечно, информация о выполнении процессов «Как есть». Ключевые выходы: внедренные изменения, информация об изменениях для сотрудников компании, информация о проекте («Резюме проекта») в базе знаний организации (на внутреннем портале).
Представленная ниже модель может быть переработана с учетом вашей архитектуры бизнес-процессов в целом и соответствующего контекста процесса.
Процессы оптимизации сквозного процесса
На рис.2 представлена общая модель процессов оптимизации сквозного процесса. Кратко рассмотрим назначение каждого из них в рамках Фреймворка.
Выбор процессов для оптимизации – в рамках данного процесса осуществляется анализ и выбор бизнес-процессов для оптимизации. Вообще говоря, этот процесс можно было бы вынести за пределы Фреймворка и показать в общей моделей процессов управления компанией, например, внутри процесса стратегического планирования или организационного развития. Но поскольку выбор процессов является весьма важным, я все-таки принял решение показать этот процесс, как часть рассматриваемого Фреймворка. В своей организации вы можете включить этот процесс в другую часть архитектуры.
Управление проектом оптимизации процесса – это, по сути, довольно формальная, но очень важная деятельность по администрированию проекта, в первую очередь, — контроль деятельности временной рабочей группы (групп) и обеспечение соблюдения сроков выполнения работ и качества ее результатов. Все содержательные работы, например, подготовка Отчетов по результатам анализа процессов или внедрения изменений, в которых участвует руководитель проекта, вынесены в другие процессы Фреймворка.
Содержательно проект оптимизации сквозного бизнес-процесса включает четыре фазы:
- Предварительный анализ.
- Углубленный анализ и разработка мероприятий по оптимизации.
- Внедрение изменений в процесс и управление изменениями (коммуникациями).
- Анализ эффекта от оптимизации процесса.
Предварительный анализ позволяет сформировать Проблемное поле и сформулировать гипотезы о причинах проблем, оценить потенциал оптимизации сквозного процесса, измерить показатели процесса «Как есть», установить цели и показатели для оптимизации.
Углубленный анализ и разработка мероприятий по оптимизации – ключевой этап проекта, в рамках которого проводится глубокий анализ процесса, подтверждаются (опровергаются) гипотезы о причинах проблем, разрабатываются мероприятия по оптимизации процесса, разрабатывается методика оценки эффекта, оценивается прогнозный эффект от оптимизации процесса, принимаются решения о внедрении соответствующих мероприятий (включая бюджет).
Внедрение изменений в процесс – довольно формально описанный процесс реализации намеченных мероприятий. Поскольку мероприятия могут быть разные, детально описать этот процесс невозможно. Управление изменениям в данном Фреймворке рассматривается довольно узко – как осуществление регулярных коммуникаций с сотрудниками по вопросам изменений, предупреждение и/или разрешение конфликтов.
Анализ эффекта от оптимизации процесса позволяет оценить реальный эффект, подвести итоги проекта и выполнить материальное стимулирование его участников, поместить информацию по проекту в базу знаний организации.
Выбор процессов для оптимизации
Рассмотрим процесс «Выбор процессов для оптимизации», представленный на рис. 3. Предлагается ежеквартально проводить анализ информации и определять бизнес-процессы, которые необходимо оптимизировать. Можно делать это, например, раз в полгода (в случае, если проекты выполнятся медленно). Кроме того, процесс может быть инициирован по мере необходимости, например, в случае внепланового изменения стратегии, рыночной ситуации и возникновения прочих факторов, которые могут существенно повлиять на процессы компании.
Руководитель Процессного офиса анализирует информацию из различных источников: стратегию, отчеты по аудиту процессов, предложения по улучшению процессов, поступившие от сотрудников, и прочее. На выходе получается перечень процессов для оптимизации со статусом «Проект». Количество процессов в нем, возможно, избыточное. В ходе дальнейшего анализа оно сокращается до того уровня, который приемлем для организации с точки зрения выделения ресурсов на работу по оптимизации этих процессов (не целесообразно иметь более 2-3 сложных проектов одновременно).
Процессный комитет (ПК) на своем очередном заседании рассматривает список и выбирает из него процессы для рейтинговой оценки. Возможно, какие-то процессы предлагает включить в список сам ПК или Генеральный директор (собственник).
После этого Бизнес-аналитик Процессного офиса проводит анкетирование сотрудников по соответствующим процессам, например, используя анкеты на Яндексе (для анонимности).
Руководитель Процессного офиса анализирует полученный результат, выполняя рейтинговый анализ процессов. В первую очередь, оцениваются результаты анкетирования руководителей и сотрудников. Например, может использоваться следующая таблица 1 расчета рейтинга процесса. В ней использовано пять критериев оценки и шкала из четырех делений.
Дополнительно к рейтингу Руководитель Процессного офиса готовит информацию о критических несоответствиях, выявленных в ходе аудитов, и потенциалу улучшений, основанному на предложениях сотрудников. В итоге, по каждому процессу из списка на ПК выносится следующая информация:
- Таблица рейтинговой оценки процесса.
- Справка о количестве критических несоответствий, выявленных по результатам аудита.
- Оценка потенциала оптимизации, основанная на предложениях сотрудников.
- Экспертное мнение Руководителя Процессного офиса и, возможно, Владельца процесса.
Процессный комитет рассматривает результаты оценки процессов и выбирает 1-3 сквозных процесса организации, по которым необходимо инициировать проекты оптимизации. На заседании ПК так же обсуждаются цели оптимизации сквозных процессов, ориентировочные сроки выполнения проектов, состав временных рабочих групп (ВРГ). Назначаются руководители соответствующих проектов.
Таблица 1. Рейтинг процесса.
Предварительный анализ
Первый этап проекта оптимизации – это выполнение предварительного анализа сквозного процесса.
Специально сформированная временная рабочая группа (ВРГ) из 3-5 человек проводит анализ документации по процессу: регламентов, положений, инструкций, результатов аудитов и проч. Это необходимо для того, чтобы узнать базовую информацию о процессе и не тратить лишнее время при проведении интервью.
Если модель процесса «Как есть» отсутствует в архитектуре процессов, то ВРГ может сформировать такую модель с участием 2-3 экспертов в предметной области (руководители, специалисты) путем проведения 1-2 моделирующих сессий и дальнейшего создания схем в Business Studio.
В любом случае, для процесса должны быть разработаны схемы «Как есть». Структура задач (подпроцессов) процесса используется для сбора и систематизации аналитической информации.
Далее ВРГ проводит анонимное анкетирование участников процесса, его внутренних поставщиков и потребителей. Одновременно проводится серия интервью с участниками процесса. Результаты интервью могут фиксироваться с виде кратких протоколов. Если встречи проводятся дистанционно (например, в Zoom), то сохраняются соответствующие видео-записи.
Затем ВРГ формирует Проблемное поле. Оно может иметь следующую структуру (таблица 2).
Таблица 2. Структура «Проблемного поля».
| № | Наименование процесса | Формулировка проблем по мнению сотрудников | Формулировка проблем по мнению ВРГ | Гипотезы о причинах проблем |
| 1 | Бизнес-процесс… | Проблема… | Проблема… | Гипотеза… |
Важно, что ВРГ не только структурирует проблемы, но и формулирует гипотезы о причинах этих проблем.
Вообще, какой-то факт (или чье-то мнение) могут рассматриваться в качестве проблемы только с определенной точки зрения. Например, «низкая скорость» выполнения процесса и «высокие затраты» могут (как бы дико это не прозвучало) «не быть проблемой», если покупателей и собственника все устраивает. В связи с этим, ВРГ должна четко определиться, с какой точки зрения оцениваются факты и мнения, идентифицируются в качестве проблем. Часто бывает весьма полезно привлекать внешних отраслевых экспертов, которые знают лучшую практику выполнения процессов и могут привнести другую точку зрения и свежий взгляд на ситуацию.
Но проблема – это только симптом. Причин может быть несколько. Они могут быть запрятаны довольно глубоко. Поэтому на предварительном этапе ВРГ формулирует гипотезы о причинах проблем, которые в дальнейшем должны быть проверены путем углубленного количественного анализа (на проверенных фактах).
На этапе предварительного анализа используются качественные методы анализа, позволяющие ВРГ структурировать субъективные мнения руководителей и специалистов о возникающих при выполнении процесса проблемах и возможных причинах.
После того, как проблемное поле сформировано, ВРГ выполняет анализ показателей, которые измеряются по процессу «Как есть». Если очевидно, что какие-то показатели необходимы для анализа, но не измеряются, то ВРГ их, по возможности, разрабатывает и измеряет. Важно количественно оценить текущее состояние процесса.
Кроме того, ВРГ оценивает возможный потенциал оптимизации процесса (в натуральных единицах и рублях), формулирует предложения по целям его оптимизации и соответствующим целевым значениям показателей.
Руководитель проекта (он тоже член ВРГ) подготавливает Отчет по анализу процесса «Как есть». В дальнейшем этот отчет может дополняться необходимыми разделами, либо могут делаться другие документы – по решению вашей организации.
В Отчете по анализу процесса «Как есть» должна быть представлена следующая информация:
- Модель процесса «Как есть».
- Проблемное поле с гипотезами о причинах проблем.
- Результаты измерения показателей процесса «Как есть».
- Оценка потенциала и цели оптимизации процесса.
Владелец процесса рассматривает Отчет и утверждает его, тем самым утверждая цели и показатели оптимизации. Если необходимо (при выполнении ряда критериев, например, — стратегически крайне важный сквозной бизнес-процесс), цели и показатели оптимизации процесса могут быть отправлены на согласование на Процессный комитет.
Углубленный анализ и разработка мероприятий по оптимизации
На рис. 5 показана схема процесса «Углубленный анализ и разработка мероприятий по оптимизации».
Второй этап проекта начинается с того, что ВРГ выполняет анализ процесса, используя ряд методов:
• уточняет контекст процесса;
• выполняет анализ графической схемы (технологии выполнения процесса);
• анализирует создаваемую ценность;
• анализирует потери;
• анализирует время выполнения;
• анализирует потенциал автоматизации;
• прочее.
Технически, для выполнения указанных видов анализа ВРГ может:
• выполнить визуальное наблюдение за процессом и фотографирование;
• получить и аналитически обработать данные учетных систем (например, 1С);
• построить графики и диаграммы;
• организовать сбор дополнительных необходимых данных в контрольных точках;
• провести мозговые штурмы;
• провести консультации с экспертами;
• выполнить бенчмаркинг;
• прочее.
ВРГ использует все адекватные контексту проекта методы анализа, которым предварительно были обучены участники рабочей группы. Вообще, формировать ВРГ по оптимизации сквозных процессов из необученных сотрудников весьма нерационально.
Следует отметить, что работа по анализу в достаточной степени творческая, но должна быть основана на определенных принципах и отработанных методах.
Полученная и обработанная аналитическая информация дает возможность подтвердить, либо опровергнуть гипотезы о причинах проблем. Таким образом, у ВРГ появляется глубокое понимание процесса и причин возникающих проблем. В свою очередь, это дает возможность перейти в задаче разработки мероприятий по оптимизации сквозного бизнес-процесса. Они могут включать в себя: изменение входов в процесс, изменение технологии выполнения процесса и его отдельных задач (в т.ч. устранение потерь), модернизацию оборудования, автоматизацию и роботизацию и т.д.
Участники ВРГ должны иметь представление о принципах и методах проектирования эффективных процессов, в том числе знать основы теории ограничений, методы TPS, понимать возможности современных BPM и RPA систем и проч.
Состав мероприятий может определяться причинами проблем, а так же видением перспективной модели процесса, сформированной участниками ВРГ и привлеченными экспертами.
В большинстве случаев, ВРГ необходимо разработать модель процесса «Как должно быть» с учетом предложенных мероприятий по оптимизации (например, в Business Studio).
Далее ВРГ анализирует каждое мероприятие по отдельности с точки зрения сроков, затрат (бюджет), эффекта и рисков. Затем делает сводный анализ «Затраты/Эффективность» для оценки пула мероприятий и выбора наиболее эффективных из них.
ВРГ разрабатывает (адаптирует на основе шаблона) Методику оценки эффекта от оптимизации процесса (производительность, затраты, время, качество, степень автоматизации и проч.), которая будет использована по факту реализации предлагаемых мероприятий. Проще говоря, ВРГ должна четко ответить на вопрос владельца процесса: «Как эффект проверять будем?».
Таким образом, ВРГ получает обоснованную прогнозную оценку эффекта от оптимизации сквозного бизнес-процесса, который должен быть получен за счет выполнения ряда предложенных ВРГ мероприятий.
При необходимости (и технической возможности), ВРГ проводит имитационное моделирование процесса «Как должно быть», чтобы на основе расчета подтвердить наличие эффекта от оптимизации. Например, в Business Studio можно выполнять имитационное моделирование одного или группы связанных (например, по ресурсам) процессов.
Руководитель проекта готовит Отчет по углубленному анализу процесса и мероприятиям. В Отчет включается следующая информация:
- Результаты анализа. Выявленные причины проблем (подтвержденные/опровергнутые гипотезы).
- Мероприятия по оптимизации процесса.
- Модель процесса «Как должно быть».
- Прогноз эффекта от оптимизации процесса, включая Методику оценки эффекта от оптимизации.
- Предложения по количеству и составу ВРГ для реализации мероприятий.
Владелец процесса утверждает Отчет, тем самым дает добро на выполнение запланированных мероприятий по оптимизации процесса.
При необходимости, Отчет по углубленному анализу и мероприятиям выносится на согласование на Процессный комитет.
Внедрение изменений в процесс
На рис. 6 показана схема процесса «Внедрение изменений в процесс». ВРГ выполняет утвержденные мероприятия по оптимизации процесса в соответствии с планом.
Для выполнения групп мероприятий по различным направлениям могут быть созданы дополнительные временные рабочие группы. В состав этих групп обязательно включаются участники основной ВРГ, которая проводила анализ процесса и разработку мероприятий. Кстати, за ВРГ на всех этапах проекта могут закрепляться бизнес-аналитики Процессного офиса. Они помогают ВРГ структурировать информацию, разрабатывать графические схемы, проводить анализ процессов, выполнять оценку эффекта и проч.
После внедрения всех запланированных мероприятий Руководитель проекта формирует Отчет по выполнению мероприятий. Этот Отчет носит скорее технический характер: что и как было сделано, сколько потратили времени и других ресурсов (денег, материалов).
Владелец процесса утверждает Отчет по выполнению мероприятий. Это важно с точки зрения контроля исполнения состава работ по проекту и сроков.
Далее, при необходимости, может быть инициирован процесс разработки регламента на основе модели процесса «Как должно быть». Процесс «Разработка/корректировка ВНМД» не входит в рассматриваемый Фреймворк. Этот процесс входит в группу процессов системы стандартизации бизнес-процессов компании. Так же, при необходимости, может быть инициировано обучение персонала.
Одновременно с выполнением мероприятий по оптимизации выполняется процесс «Управление изменениями (коммуникациями)».
Управление изменениями (коммуникациями)
На рис. 7 показана схема процесса «Управление изменениями (коммуникациями)».
Управление изменениями в данном Фреймворке рассматривается достаточно узко, а именно как:
- Составление плана коммуникаций.
- Периодическое (не реже одного раза в неделю) освещение хода и результатов проекта внутри организации (портал, стенд, газета, рассылки, совещания и проч.).
- Обработка вопросов, возражений, слухов.
- Предупреждение и разрешение конфликтных ситуаций.
ВРГ разрабатывает план по коммуникациям на основе общего плана проекта. Владелец процесса согласует этот план. Далее этот план корректируется (дополняется) по ходу проекта с учетом фактически полученных результатов проекта.
В еженедельном режиме ВРГ готовит и публикует материалы, а Руководитель проекта осуществляет мониторинг вопросов (через портал и «Горячую линию» проекта), мнений (совещания) и слухов (через курилку и другие неформальные места сбора агентурной информации).
При появлении возможности конфликтной ситуации к работе по ее предупреждению привлекается Владелец процесса. Он совместно с Руководителем проекта продумывает и реализует соответствующие корректирующие и предупреждающие действия, в т.ч. проводит необходимые встречи, совещания, презентации, публикует дополнительную информацию и прочее.
Анализ эффекта от оптимизации процесса
На рис. 8 показана схема процесса «Анализ эффекта от оптимизации процесса». Это четвертый этап проекта оптимизации сквозного бизнес-процесса.
После завершения всех мероприятий по оптимизации необходимо выполнить достаточное количество циклов (экземпляров) процесса, чтобы можно было собрать информацию и измерить показатели процесса.
ВРГ организует сбор информации и расчет необходимых показателей процесса.
Сравниваются показатели процесса до и после оптимизации. На основе утвержденной ранее Методики рассчитывается эффект от оптимизации сквозного бизнес-процесса. В зависимости от типа процесса эффект может выражаться по-разному (эта особенность должна учитываться в Методике).
В таблице 3 представлены показатели, по которым целесообразно оценивать эффект от оптимизации сквозных бизнес-процессов в зависимости от их характерных особенностей (типа). В таблице 3 показатели сгруппированы по двум шкалам (осям) и двум направлениям. Используются шкалы: «Степень риска» (Низкая/Высокая) и «Повторяемость» (Низкая/Высокая). Два направления: «Создание продукта (услуги) для внешнего (внутреннего) потребителя и «Создание управленческого решения». Показатели указаны в порядке важности для измерения процесса (1 – самый важный).
Таблица 3. Показатели для оценки эффекта от оптимизации бизнес-процессов.
Типы показателей, представленные в таблице 3, носят рекомендательный характер. Это означает, что не все указанные типы показателей обязательно должны измеряться для процессов соответствующего типа.
После того, как ВРГ рассчитает показатели процесса, Руководитель проекта готовит Итоговый Отчет по оптимизации сквозного бизнес-процесса, который включает в том числе оценку эффекта от оптимизации и предложения по премированию участников проекта (ВРГ, Руководителя проекта, Владельца процесса и проч.).
Далее Руководитель Процессного офиса получает Отчет и выполняет проверку эффекта от оптимизации процесса. Для этого он может выполнить контрольные расчеты, провести визуальный осмотр процесса, получить независимую обратную связь от участников процесса, организовать контрольный сбор данных и перерасчет показателей процесса. Рассматриваемая задача является контрольной и должна снизить риск некорректной оценки эффекта от проекта оптимизации сквозного бизнес-процесса.
После этого Отчет согласует Владелец процесса, а затем утверждает Процессный комитет. В рамках его проведения в том числе рассматривается и утверждается размер премий участникам ВРГ и другим сотрудникам.
Далее Руководитель проекта готовит Резюме проекта. Оно содержит ключевую информацию по проекту: Проблемное поле, результаты анализа, результаты внедрения мероприятий по оптимизации, оценку эффекта. Кроме того, в Резюме отдельно указываются найденные лучшие решения, которые можно использовать повторно в других проектах.
Руководитель Процессного офиса размещает резюме проекта в Базе знаний компании.
Управление проектом оптимизации процесса
На рис. 9 представлена схема процесса «Управление проектом оптимизации процесса».
После инициации проекта Руководитель проекта формирует, а Владелец процесса утверждает состав ВРГ по проекту. Целесообразно включать в состав этой группы 3-5 человек, включая Руководителя проекта.
За ВРГ может закрепляться бизнес-аналитик Процессного офиса для оказания организационной, методической и экспертной помощи.
Далее формируется и согласуется План проекта, который в дальнейшем уточняется ежемесячно (не реже) или по мере необходимости.
Еженедельно участники ВРГ предоставляют Руководителю проекта так называемые тайм-шиты – отчеты за неделю (обычно в формате MS Excel), где представлен перечень выполненных работ по проекту, затраченные человеко-часы и краткое описание полученных результатов.
Тайм-шиты нужны Руководителю проекта для анализа и понимания того, как работают участники ВРГ, насколько они продуктивны и вовлечены в проект.
На основе тайм-шитов и анализа результатов работы по проекту Руководитель проекта готовит и предоставляет Владельцу процесса статус-отчет за неделю. В этом коротком отчете представлена информация о результатах работы за неделю (план/факт), возникших трудностях и проблемах, необходимой помощи и решениях, которые целесообразно принять.
Не зависимо от текущего этапа проекта Руководитель проекта готовит и предоставляет Владельцу процесса и Процессному комитету отчет за месяц. По сути, этот отчет показывает использование ресурсов ВРГ и выполнение поставленных задач, возникшие трудности, содержит запрос ресурсов (решений) от Владельца процесса и Процессного комитета.
Таким образом, в рамках управления проектом представлены два контура управления: еженедельный и ежемесячный, в рамках которых контролируется ход работ по проекту, уточняется его план.
Оперативная постановка задач (поручений) участникам ВРГ выполняется Руководителем проекта в рамках содержательных совещаний ВРГ по обсуждению текущих рабочих вопросов по проекту.
Выводы
В статье представлен Фреймворк проекта оптимизации сквозного бизнес-процесса компании.
Для создания внутреннего стандарта выполнения такого проекта вам потребуется:
- Данный Фреймворк.
- Методика приоретизации и выбора процессов для оптимизации.
- Методика формирования Проблемного поля (включая гипотезы о причинах проблем).
- Методика разработки целей и показателей для процесса.
- Методика анализа процесса (может включать ряд методов).
- Методика оценки мероприятий по оптимизации процессов («Затраты/эффективность»).
- Методика оценки эффекта от оптимизации процесса (по итогам выполнения проекта).
- Методика управления изменениями (коммуникациями).
Указанные методики могут быть описаны в рамках одного стандарта (регламента) компании, либо выделены и утверждены в виде отдельных внутренних нормативно-методических документов. Не нужно создавать слишком сложные методы. Лучше сначала использовать простые и понятные решения, а затем, после практического использования, вносить в них необходимые изменения.
Можно, например, на основе представленного Фреймворка описать в Business Studio текстом все задачи процессов, разработать и приложить необходимые формы документов (таблицы, формулы, графики, шаблоны презентаций и проч.), сформировать и утвердить первую версию регламента процесса «Выполнение проекта оптимизации сквозного бизнес-процесса».
С учетом существующей в компании архитектуры процессов в области организационного развития и проектного управления Фреймворк может быть изменен, а необходимые методики прописаны в других документах компании. Главное, чтобы была сформирована простая и эффективная СИСТЕМА работы по оптимизации сквозных бизнес-процессов.
Успехов в оптимизации сквозных бизнес-процессов вашей организации!
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», член ABPMP Russian Chapter.
Январь 2022 г.
BPM-2021: вопросы и ответы
BPM-2021: вопросы и ответы
19 февраля 2021 года состоялась конференция «Системная практика управления бизнес-процессами». В конференции приняли участие более 500 руководителей и специалистов из России и других стран. По ходу конференции участники задали большое количество вопросов. Многие вопросы были сформулированы в чате конференции, поэтому во время ее проведения не всегда была возможность ответить на них развернуто. В статье мы восполняем этот недостаток. Наталья Косарева (НК) и Владимир Репин (ВР) подробнее ответили на многие вопросы участников. Презентации спикеров конференции и видео докладов можно посмотреть по ссылке выше.
Введение
18 февраля 2021 года состоялась конференция «Системная практика управления бизнес-процессами». В конференции приняли участие более 500 руководителей и специалистов из России и других стран.
Подводя итоги конференции, мы проанализировали состав участников, выбрали наиболее интересные вопросы и сформулировали на них ответы.
На рис. 1 представлена структура участников по половой принадлежности.
Интересно отметить, что женщины заметно больше мужчин интересуются темой процессного управления. Эта статистика подтверждается нашими личными наблюдениями за кадровым составом подразделений внутреннего орг. развития (это там, где работают бизнес-аналитики).
На следующем рис. 2 представлена диаграмма по уровням должностей участников конференции.
Любопытно отменить, что интерес к конференции был ярко выражен у руководителей подразделений (в первую очередь, в области орг. развития и СМК) и специалистов – бизнес-аналитиков, системных аналитиков и т.п. При этом главные и ведущие специалисты, вероятно, либо «уже в теме» (или считают, что «в теме»), либо настолько загружены текущей работой, что не смогли уделить время конференции. Впрочем, это только гипотезы.
На рис. 3 представлена структура участников конференции по типам организаций. Интересно отменить, что тема процессного управления оказалась важной для ВУЗов (6%) и органов государственной власти (4%).
Далее в статье представлены наиболее интересные вопросы участников конференции в соответствии со структурой BPM CBOK 3.0 и ответы на них. Часть вопросов была задана в чате конференции. Во время ее проведения не всегда была возможность ответить на них развернуто. Ниже мы восполняем этот недостаток.
Управление бизнес-процессами
Вопрос: Можно ли немного рассказать о связи процессов с финансовыми и бюджетными структурами. Например, для процесса управления «Бюджетирование», являются ли входами бюджеты ЦФО? Или бюджеты ЦФО — это интерфейсы между владельцем процесса бюджетирования и владельцами других процессов?
Ответ (НК): С моей точки зрения, бюджеты, которые не видоизменяются в других процессах, являются неким правилом, ориентиром. Если в бюджетной структуре происходит изменение бюджета, в связи с ее обязанностями по корректировке бюджета, то «бюджет» будет являться входом.
Ответ (ВР): Документы – это в любом случае не интерфейсы, ведь они пересекают границы ответственности. Границы процесса бюджетирования могут быть определены по-разному. Если формирование бюджетов ЦФО не входит в процесс «Бюджетирование», то очевидно, что бюджеты ЦФО (как результат другого процесса) могут являться входами для процесса «Бюджетирование». Так что это вопрос определения границ процесса.
Вопрос: «На примере последнего слайда Вы противопоставили развитие процессного управления и такие вещи, как развитие культуры, горизонтальных связей и т.п. Почему они противопоставлены? Нужно и то, и другое, как мне кажется».
Ответ (ВР): Нет, я не вкладывал такой смысл в слайды и не говорил этого. Как-раз наоборот, высокий уровень корпоративной культуры в части исполнительской дисциплины, коммуникаций, командной работы над проблемами, вовлеченности в улучшения будет только большим «плюсом» при внедрении технологий процессного управления. Наоборот, в бюрократической структуре с низкой исполнительской дисциплиной и слабыми горизонтальными связями процессное управление внедрять крайне тяжело.
Вопрос: «Зачем нужно уделять особое внимание управлению процессами, если можно решать задачи повышения прибыли другими способами?»
Ответ (НК): Прибыль = Выручка — Затраты. Следовательно, повышения прибыли можно достигать, либо увеличением выручки, либо уменьшением затрат. Процессное управление может способствовать изменению обеих составляющих. Например, для повышения выручки совершенствовать скрипты общения с клиентами, которые способствуют их притоку и доведения до покупки. Процессы, повышающие качество продукции, также способствуют увеличению количества клиентов и совершению существующими клиентами повторной покупки. Уменьшению затрат способствует стандартизация процессов, а для этого их необходимо увидеть, регламентировать и контролировать с помощью показателей с целью дальнейшего улучшения. Когда процессы выполняются по установленным стандартам, то люди не тратят время на раздумывания, как им лучше выполнить его. При стандартизации можно собирать статистические данные и смотреть статистическую устойчивость процесса. Улучшать можно только статистически устойчивые процессы.
Ответ (ВР): Каждая компания проходит разные этапы жизненного цикла. Область деятельности и масштаб компаний так же совершенно разные. Поэтому ответить на этот вопрос можно только применительно к конкретной компании, находящейся в конкретной ситуации. В целом, ответ – да. Можно эффективно решать задачи повышения прибыли другими способами. Но если компания достигла определенного размера и уровня зрелости, то внедрение процессного подхода становится неизбежным для того, чтобы уйти от практики «ручного управления» бизнесом, получить возможность делегировать полномочия и сделать процессы «прозрачными», контролируемыми, управляемыми.
Вопрос: «Можно ли в цифрах просчитать эффект для представления руководству?»
Ответ (НК): Все зависит от уровня зрелости учета на вашем предприятии. В продолжении ответа на предыдущий вопрос: эффект от внедрения может выражаться, либо в получении дополнительной прибыли от выпуска более качественной продукции, либо в уменьшении расходов в связи с устранением потерь.
Знание стоимости выполнения процесса помогает команде правильно назначить приоритет процессам, заслуживающим первоочередного рассмотрения. Организация может выбрать следующие критерии приоритетности:
• процессы, взаимодействующие с клиентом;
• процессы, оказывающие большое влияние на доходы;
• кросс-функциональные процессы, нуждающиеся в координации.
Каждому из этих факторов можно присвоить шкалу и определять приоритетность, исходя из суммы баллов.
Ответ (ВР): Можно. Но для этого нужно провести достаточно глубокую диагностику ситуации в компании и определить потенциал повышения эффективности. Для решения этой задачи целесообразно создать команду, включающую внутренних экспертов, внешних процессных методологов/аналитиков и отраслевых экспертов. Сравнение с практиками других успешных компаний особенно важно и позволяет сразу «высветить» проблемные места, оценить потенциал роста выручки, сокращения затрат и проч.
Вопрос: «Исходя из каких критериев можно рекомендовать выбор метода описания процессов (функциональные /сквозные)?»
Ответ (НК): Чтобы сложная современная организация оставалась конкурентоспособной, ВРМ и функциональное управление обязаны в ней уживаться и сотрудничать:
• функциональное управление гарантирует работоспособность несметного числа функциональных дисциплин, которые требуются организации для создания продукции и услуг;
• ВРМ гарантирует, что работа этого несметного числа функций координируется так, что продукция и услуги создаются с максимальной производительностью и эффективностью.
Ответ (ВР): Выбор зависит от целей и масштаба вашего проекта. Если вы хотите разобраться с процессами внутри отдела, то это будут «функциональные» процессы, которые могут не иметь законченной ценности в целом для компании и ее клиентов. Это не плохо и не хорошо. Это факт…. Если цель состоит в построении архитектуры бизнес-процессов компании, то нужно начинать с анализа деятельности всех подразделений, то есть с определения функциональных процессов. Если же цель проекта, например, быстро описать и автоматизировать конкретный бизнес-процесс на межфункциональном уровне, то нужно будет определять сквозной бизнес-процесс.
Вопрос: «Я правильно понимаю, что теперь на сквозной процесс не надо ломать голову и искать одного Владельца процесса. Так как это была та ещё задачка (невыполнимая), а исходя из теории так должно было бы быть. Сегодня Ваш слайд расставил все на свои места».
Ответ (НК): Э. Деминг в своей книге «Выход из кризиса» писал: «Разделенная ответственность означает, что не отвечает никто». Если цель ставится по всему сквозному процессу, то и ответственный должен быть один.
Ответ (ВР): Почему не надо? Надо! Если вы определяете сквозной процесс, то, очевидно, планируете его улучшать и потом оперативно управлять. Так что нужно будет выбрать и назначить ответственного за эту работу. А вот называть ли его «владельцем» и какие полномочия давать, это уже другой вопрос.
Вопрос: «Правильно ли понимаю, что рекомендуете с разной степенью глубины описывать разные процессы в рамках компании?»
Ответ (НК): В зависимости от уровня процессной зрелости организации управление эффективностью процессов различается углом зрения и глубиной. Один из первых шагов процессной команды – определение границ анализируемого процесса. Это ответственное решение, так как от него будет зависеть, как далеко зайдет проект, сколько бизнес-функций он затронет и какое воздействие на процессы и пользователей вверх и вниз по потоку работ окажут изменения. После того как рамки анализа заданы, аналитик должен выбрать глубину анализа: достаточно ли рассмотреть уровень действий или следует также проанализировать все входы и выходы?
Ответ (ВР): Глубина декомпозиции системы определяется целью ее разработки и квалификацией специалистов, которые потом будут с ней работать. Я рекомендую описывать процессы с той степенью глубины, которая нужна для принятия решений по улучшению процессов. Решения эти могут быть разного масштаба. Например, описание процессов в нотации IDEF0 на верхнем уровне помогло обосновать структурные изменения в организации – была создана новая, эффективная орг. структура, перераспределена ответственность за процессы на верхнем уровне. Другой пример: описание процесса в нотации BPMN помогло увидеть, насколько сложен, запутан реальный процесс, и принять решения по его реорганизации с последующим выходом на проект автоматизации в BPMS.
Вопрос: «Я правильно понимаю, что «сквозные» процессы собираются из отдельных уже описанных / стандартизованных процессов? Если да, то в чем ценность / смысл такой сборки? Или «выделены отдельные процессы» означает только то, что они названы / идентифицированы?»
Ответ (НК): Согласно определению АВРМР, «процесс» является кросс-организационным и включает в себя все работы, необходимые для создания и предоставления продукции или услуги. При этом процесс может быть разбит на подпроцессы, которые выполняются подразделениями как последовательность взаимосвязанных и последовательных действий – на потоки работ. После того, как эта структура определена, можно организовать мониторинг процесса путем объединения информации на уровне потоков работ, включая передачу ответственности между подразделениями.
Верхний уровень процессной иерархии составляет сквозной процесс. Затем он разбивается (декомпозируется) вплоть до отдельных действий, где и выполняется процессная работа. Процесс должен быть декомпозирован достаточно глубоко, чтобы показать, из каких действий он состоит и как эти действия дополняют друг друга в создании конечной продукции.
Ответ (ВР): Ценность — в непрерывности. Стыковка процессов в единый, непрерывный сквозной процесс, особенно при условии его автоматизации, дает очень хороший эффект для бизнеса: сроки выполнения, устранение потерь, удобство для клиентов.
Вопрос: «Как определить владельца процесса и разделить границы между внутренний заказчик/поставщик»?»
Ответ (НК): Самое главное – обеспечить непрерывность процесса и передачу ответственности. Лучше всего этого достигать при совместном обсуждении.
Ответ (ВР): Границы процессов – это всегда вопрос внутренних договоренностей. Не настолько важно, где граница. Гораздо важнее, что процессы стыкованы между собой непрерывным образом, что отсутствуют зоны безответственности (пересечения ответственности). При этом, конечно, важно понимать потребности каждого внутреннего заказчика. В разных частях организации (с учетом типа бизнеса) методы определения сквозных процессов могут быть разные. Простой критерий – «сквозной процесс проходит через несколько подразделений» — это не метод его определения. В целом, определение сквозных процессов – это инструмент менеджмента. Если просто спрашивать, «Что вы делаете для такого-то процесса?», можно получить большой объем плохо структурированной информации, которую почти невозможно будет использовать. Другими словами, описание процессов «снизу вверх» без архитектуры, как правило, не дает хорошего результата.
Вопрос: «Почему поиск и прием нового сотрудника — сквозной процесс. Этим же может заниматься одно подразделение».
Ответ (НК): В разных компаниях по разному: все зависит от размеров и организационной структуры компании.
Ответ (ВР): Может и один человек заниматься, если у вас небольшая компания. Но в средней и большой компании в процессе поиска и приема нового сотрудника участвует несколько разных подразделений: служба персонала, служба безопасности, бухгалтерия, внешнее мед. учреждение, руководитель подразделения-заказчика и проч. Процесс может быть достаточно сложным и, очевидно, сквозным.
Вопрос: «Правильно ли поняла по вашему слайду о функциях и процессах, что деятельность по бюджетированию является функцией? Если — да, то почему эта функция имеет все определяющие для процесса характеристики — повторяемость, регламентированность, наличие заказчика и показателей качества. Пример показателей — отклонение план\факт, своевременность подготовки бюджетов».
Ответ (НК): Модели потоков работ обычно описывают, что должно быть сделано для выполнения процесса. Это модели более детальные по сравнению с моделями процессов предприятия и моделями бизнес-процессов. Модели потоков работ разбиваются на действия (их также называют задачами или процедурами). Действия в модели потоков работ выполняются «функциями»: должностями, подразделениями, системами.
Ответ (ВР): А что такое вообще «Функция»? Если абстрактная способность что-то делать, то нам такое определение не нужно. А если функция имеет все нужные характеристики, то это уже процесс, но не сквозной, а локализованный в одном структурном подразделении. Это нормально.
Вопрос: «Какие принципы существуют при определении границ процесса. Как показывает моя практика — целостный результат коллеги понимают по-разному. Для кого-то это договор закупки подписан, для кого-то договор исполнен, для кого-то отсутствует возможность применить к нему исковую давность».
Ответ (НК): Все определяется целями компании, а также выбором приоритетов, о которых говорили выше: знание стоимости выполнения процесса помогает команде правильно назначить приоритет процессам, заслуживающим первоочередного рассмотрения, а также определению границ.
Ответ (ВР): Границы процесса определяются по входам/выходам и событиям. Но еще раз подчеркну: важно не просто определить границы отдельного процесса, а стыковать все процессы между собой по входам/выходам и событиям, добиваясь непрерывности и отсутствия зон безответственности.
Вопрос: «Обеспечение производства услугами подрядчиков куда помещаем: в операционную или обслуживающую систему?»
Ответ (НК): Компания сама определяет. Генри Минцберг в организационной структуре выделяет еще «Техноструктуру», которая как раз занимается обеспечением производства.
Ответ (ВР): Скорее, в обслуживающую.
Вопрос: «А управление, как процесс, Вы не выделяете?»
Ответ (НК): Управление – это самый важный процесс с точки зрения устранения потерь и повышения эффективности компании. Большинство организаций продолжает фокусироваться на небольших улучшениях структурированных процессов, в то время как возможности дифференциации процессов в большей степени кроются в деятельности работников умственного труда. Эта деятельность в значительной степени не структурирована – она не является рутинной, и для нее не характерно последовательное и предсказуемое выполнение. Ведущие мировые экономики зависят от успеха работников умственного труда. Успех в отраслях сферы услуг определяется использованием знаний.
Ответ (ВР): Да, конечно. При создании архитектуры бизнес-процессов для каждого процесса 1-3 уровня всегда определяем процесс «управления процессом». При его декомпозиции показываем процессы, связанные с целеполаганием, планированием, организацией, мониторингом и контролем, принятием решений, анализом, контролем исполнения регламентов и проч. Если не определять такие процессы в архитектуре, то как потом регламентировать и автоматизировать деятельность руководителей по управлению бизнес-процессами?
Вопрос: «Однако, а как же быть с процессами управления? Как быть с классическими схемами с управляющей и управляемой подсистемами и обратными связями?»
Ответ (НК): Работники умственного труда оказываются среди тех, кто больше всех сопротивляется улучшению процессов. Они видят в этом принижение значимости их опыта и уникальной интуиции. Однако такое отношение отражает давнее ошибочное восприятие улучшения процессов.
Ответ (ВР): При формировании моделей в нотации IDEF0 это можно легко показать. Мы так и делаем.
Моделирование процессов
Вопрос: «На верхнем уровне при моделировании не используете IDEF0? Комбинирование IDEF0 и BPMN на ваш взгляд не эффективно?»
Ответ (ВР): это зависит от используемого программного продукта для описания бизнес-процессов. Например, в Business Studio 5 мы активно используем нотацию IDEF0 для построения моделей процессов на верхнем уровне. Это модели так называемого структурного типа. Их основная задача – построение модели сложной системы – архитектуры процессов компании. Такую же задачу решает, например, нотация VAD в системе ARIS. Есть и другие нотации, которые можно применять для построения структурных моделей, например DFD (Data Flow Diagram). В свою очередь, нотация BPMN является отличным выбором для описания процессов Work Flow (поток работы) для целей анализа, регламентации и подготовки к автоматизации в BPMS. Например, комбинация нотаций IDEF0 (для верхнего уровня) и BPMN (для нижнего) в Business Studio 5 весьма эффективна.
Вопрос: «Какая «временная последовательность» может быть в диаграмме IDEF0 (верхний уровень 8-процессной модели)?»
Ответ (ВР): Никакая. IDEF0 – это модель структурного типа. Она принципиально не показывает «временную последовательность» выполнения процессов в отличии от нотаций типа Work Flow (CFFC, eEPC, BPMN).
Вопрос: «Выделяете ли Вы требования к моделируемым БП, до начала моделирования»?
Ответ (ВР): Да, конечно. Практически в каждом проекте создается (на основе типового) Соглашение по моделированию бизнес-процессов (Стандарт описания бизнес-процессов). В этом документе фиксируются все требования к моделям бизнес-процессов в используемых нотациях (например, IDEF0 и BPMN). Кроме того, всегда важно понимать цель моделирования процесса, метод и точку зрения.
Вопрос: «В «Бережливом производстве» есть инструмент картирование процесса. Рекомендуете ли его?».
Ответ (НК): Карта потока создания ценности (КПСЦ) входит в нотации, рекомендуемые BPM CBOK. Использование нотаций зависит от целей компании.
КПСЦ используется.
• Чтобы вовлечь в анализ процесса его исполнителей.
• Там, где не требуются полноценные средства моделирования.
• Там, где четко заданы требования по стоимости и продолжительности процесса.
Преимущества.
• Простота и легкость применения.
Недостатки.
• Плоские модели.
• Репозиторий не предусмотрен.
• Невозможно использовать для решения сложных задач.
Ответ (ВР): Если Вы имеете в виду Toyota Value Stream Map (VSM), то его можно рекомендовать для решения конкретного круга задач – анализа цепочки создания ценности в рамках существующей производственной модели и построении новой модели «вытягивающего» производства на основе принципов TPS. Если ваша задача – описать процессы для последующей автоматизации в BPMS, то метод VSM вам, конечно, не подойдет.
Анализ процессов
Вопрос: «Описание и анализ чем отличается от стандартизации?»
Ответ (НК): Одна из целей BPM СВОК – стимулировать читателей к использованию общей, согласованной терминологии в области ВРМ. Чтобы все друг друга понимали, определения должны быть согласованы с бизнес-руководителями, с IT и бизнес-партнерами. Но тут возникает культурно-политическая проблема: чье определение будет признано истинным и выбрано для всеобщего употребления? Пока термины и акронимы не согласованы, пользы от стандартов сбора информации будет немного в плане выработки общего понимания того, что представляют собой операции и как их следует совершенствовать.
Что такое описание и анализ по BPM CBOK?
Описание процесса должно соответствовать назначению и применению:
• Соответствие назначению подразумевает, что описание процесса содержит всю необходимую информацию для ответа на вопросы, кто, что, где, когда, зачем и как делает.
• Соответствие использованию подразумевает, что описание процесса структурировано таким образом, чтобы представлять эту информацию максимально эффективно, учитывая потребности целевой аудитории.
Анализ процессов дает представление о действиях процесса и измеряет результаты этих действий, сопоставляя их с целями организации.
Анализ процессов выполняется с помощью различных методов, в том числе составления диаграмм, интервьюирования, имитации действий и других. Он часто включает в себя изучение бизнес-среды, организационного контекста процесса, факторов, влияющих на операционную среду, отраслевых особенностей, правительственных и отраслевых нормативов, требований рынка и конкуренции.
Ключевые факторы, подлежащие рассмотрению при анализе процессов:
• стратегия бизнеса;
• цели процесса;
• ключевые проблемы на пути к достижению целей;
• вклад процесса в общую цепочку создания ценности;
• организация и бизнес-роли, обеспечивающие процесс.
Ответ (ВР): Да, конечно. Целью описания и анализа может быть, например, оптимизация процесса и/или подготовка к его автоматизации. Кроме того, создание регламента на основе описания процесса еще не означает его стандартизацию. Чтобы стандартизовать процесс нужно внедрить регламент и добиться того, чтобы соответствующие процессы выполнялись в соответствии с этим регламентом. Т.е. нужна Система стандартизации, а не просто отдельные регламенты.
Проектирование процессов
Вопрос: «На первый взгляд, проектирование процессов «снизу вверх» (путем выделения классов процессов и построения типовой модели объекта класса) всегда приводит к модели «as is». Или все-таки нет?»
Ответ (НК): Проектирование процесса включает изучение существующего процесса и его подпроцессов и анализ того, как он может быть усовершенствован или фундаментально пересмотрен для достижения желаемого результата.
Ответ (ВР): В этом вопросе несколько скрытых смыслов. Во-первых, проектирование «снизу вверх» редко приводит к нормальному архитектурному решению. Это как строить завод «хоз. способом» — построить можно, но потом будут постоянные проблемы: то не продумали, сё не продумали, там упало, тут развалилось и т.п. Во-вторых, что есть «as is»? Многие, когда делают описание «как есть», сильно отрываются от реальности. В итоге, считают, что делали «как есть», а по факту получили «как смогли изобразить свои представления о том, как есть, опираясь не неточные и непроверенные данные». Неумение моделировать, например, в нотации BPMN, комбинируется с недостоверными данными и их субъективной интерпретацией… Для получения действительно адекватной модели «как есть» нужно быть серьезным профессионалом и опираться на проверенные, достоверны данные. Чем точнее модель «как есть», тем она дороже. Но здесь возникает вопрос, а насколько такая модель нужна, если анализ процесса в целом показывает, что он никуда не годный? Речь идет о том, что степень приближения модели «как есть» к реальности должна быть разумной, обусловленной целями и задачами конкретного проекта.
Вопрос: «Чем отличается описание процессов «для автоматизации» от описания процессов «как есть» или «как будет»?»
Ответ (НК): Группа, отвечающая за проектирование бизнеса, должна иметь представление о технических аспектах проектирования, создания и внедрения бизнес-усовершенствований. Аналогично группа от IT должна иметь представление о подходах к трансформации бизнеса. Ограничения и доступные варианты будут сильно различаться в зависимости от того, опирается ли проектирование процесса на генерацию BPMS-приложений.
Существуют два основных подхода к проектированию новой модели. Первый заключается в проектировании такого усовершенствования, которое можно целиком реализовать одним изменением. Второй заключается в разработке модели, которая была бы оптимальной, но (пока) не реализуемой на практике из-за дороговизны, из-за радикальности, из-за недостижимых изменений IT и т.д. В этом случае разрабатываются одна или несколько промежуточных версий, приближающих нас к «оптимальной» модели «как будет».
Эффективность компании напрямую зависит от качества процессов и правил. Но сегодня к ним добавляется еще один элемент: способность компании воспринимать изменения и быстро к ним адаптироваться. И еще меньше тех, кто способен на быстрые изменения, и кто может контролировать большую часть происходящих в компании изменений. Одна из причин – неспособность IT-инфраструктуры и унаследованных IT-приложений компаний среднего и крупного масштаба поддерживать требуемый темп изменений. IT-подразделения завалены заявками на доработку информационных систем, с которыми не могут справиться. В большинстве операций возникают «белые пятна» — ручная работа, обусловленная ограниченными возможностями автоматизации и быстротой изменений.
Ответ (ВР): Всем. Начнем с того, что модели «Как есть» и «Как будет» могут делаться не для автоматизации. Модели «для автоматизации» тоже могут быть разными. Поэтому в этом вопросе вы пытаетесь сравнивать «круглое» и «теплое» — в чем разница?
Управление эффективностью процессов
Вопрос: «Максимальное кол-во KPI на одного человека, которые работают эффективно?»
Ответ (НК): Объем внимания у взрослого человека составляет 5-7 элементов, на это и стоит ориентироваться. У меня в компании у сотрудников был один верхний интегрированный показатель эффективности, который каскадировался на три составных.
Ответ (ВР): KPI не работают. Работают системы: целеполагания и планирования, управленческого учета, оперативного контроля и управления, материального стимулирования. Количество KPI само по себе ничего не значит. Важно, как они используются в рамках данных систем. С точки зрения конкретного человека, оценка больше, чем по 3-5 показателям становится сложной для восприятия. Это затрудняет понимание и снижает возможность концентрации.
Вопрос: «Для оценки бизнес-процессов, что предпочтительнее использовать KPI или OKR?»
Ответ (НК): ОKR применяется при управлении изменениями и инновациями (Change and Disrupt), а KPI — больше при управлении процессами (Run).
Ответ (ВР): KPI – показатели. Они используются не сами по себе, а в рамках определенной системы. В OKR тоже есть показатели.
Процессная трансформация
Вопрос: «Классификация типов управления… Чье авторство разработки? Или обще признанное с методологической точки зрения?»
Ответ (ВР): Авторство Владимира Репина. Подготовил специально для конференции. Меня давно волновал вопрос, может ли компания быть успешной без бизнес-процессов? Классики жанра, такие как М. Хаммер, устами своих последователей твердили нам, что «… компанию делают успешной и конкурентоспособной ее бизнес-процессы». После долгих размышлений над этим вопросом я все-таки понял: это не так! Компанию делают успешной множество факторов: личность собственника, текущий момент, коллектив, наследство в виде активов, медленная смерь конкурентов, гос. поддержка, удача и т.п. Когда мы говорим о процессах – есть они в компании или нет, — надо четко определить, что мы поднимаем под понятием «процесс». Если это «деятельность по преобразованию входов в выходы», то такую деятельность можно успешно выполнять безо всяких там процессов. Да, будут потери. Да, результат будет каждый раз немного разный. Но если на рынке нашелся клиент на такой результат, купил, и мы в прибыли, то обошлось без бизнес-процессов. Другое дело, как я писал выше, когда компания вырастает до определенного размера, ей становится выгодно заниматься определением реальных процессов (целенаправленная, повторяющаяся, стабильная последовательность действий, приводящая к получению заданного результата).
Вопрос: «А что если руководитель подразделения не берет на себя роль владельца сквозного БП? Как можно повлиять\замотивировать?»
Ответ (НК): Должна быть заинтересованность вышестоящего руководства, а уж у него есть административные ресурсы для вовлечения.
Ответ (ВР): Всяко-разно. Можно, например, утвердить положение о Владельце процесса, а потом назначить приказом.
Процессная организация
Вопрос: «Архитектура бизнес-процессов — это реестр сквозных процессов? Или организационная структура с функционалом подразделений — это тоже архитектура бизнес-процессов?»
Ответ (НК): Вариант 1-й архитектуры бизнес-процессов — реестр процессов в виде справочника, перечня процессов в Word. Вариант 2-й архитектуры бизнес процессов – это модель, в которой вы понимаете, как ваши процессы связаны с точки зрения информационных и материальных потоков, с точки зрения управленческих воздействий, обратных связей. Модель позволяет вам понять в каких границах работают процессы и точно определить для них показатели. Архитектура процессов –это основа для того, чтобы внедрять системную практику работы с процессами.
Ответ (ВР): В каком-то смысле – да. Недостаток Реестра может состоять в том, что непонятны, не уточнены границы процессов. Это означает, что сам Реестр довольно «сырой». При декомпозиции могут потребоваться существенные действия по его изменению. Если же при создании Реестра процессы были стыкованы по входам/выходам (т.е. определены границы), то такой Реестр можно рассматривать в качестве архитектуры бизнес-процессов организации.
Вопрос: «Архитектура процессов и карта основных бизнес-процессов — не одно и то же?»
Ответ (ВР): Нет, если речь идет об одной картинке, на которой представлены «рыбками» основные процессы.
Вопрос: «Как описывать архитектуру процессов? Самостоятельно или внешними специалистами?»
Ответ (НК): Зависит от целей и возможностей компании. Например, Вы захотели съесть борщ. Первый вариант: пойти в ресторан и там его заказать. Второй вариант: изучить книгу с рецептами, сходить на рынок, все закупить, приготовить, подождать, когда он настоится, потому что борщ лучше есть на второй день. Выбирайте сами.
Ответ (ВР): Все зависит от наличия в вашей компании процессного архитектора/методолога и бизнес-аналитиков. Если они есть, то можно разработать архитектуру самим. Если их нет, а нужно быстро, то целесообразно заказать эту работу у внешних консультантов.
Управление процессами организации
Вопрос: «10 атрибутов Системы управления бизнес-процессами — какие из них наиболее важно добавлять к 1-ому и 2-ому подходам (1. регламентация и 2. BPM-проект)».
Ответ (ВР): Не нужно их добавлять. Нужно выбрать ваш путь – будете или нет создавать Систему управления бизнес-процессами, как часть общей Системы управления компанией.
Вопрос: «Есть ли продуманный граф причинно-следственных связей 10-ти атрибутов? С чего начинать? Если мы поставили себе цель, по бизнес-процессам выйти на 5 уровень, это реально сделать за год? Если мы сейчас находимся на 2-ом уровне».
Ответ (НК): Можно все. Зависит лишь от желания руководства и финансовых ресурсов. За первые 4 месяца войны из-под удара агрессора были выведены 8 млн. человек, 2,5 тысячи промышленных предприятий, 1,5 тысячи колхозов и совхозов. По своим масштабам и эффективности этот проект не имеет аналогов в мировой истории. Нет ничего невозможного.
Ответ (ВР): Такого графа нет. Была попытка его нарисовать, но схема оказалась слишком сложной – не стал публиковать. А вот график Ганта по внедрению СУБП есть. Его можно посмотреть в моих статьях и видео на канале Youtube. Да, реально за год перейти со 2-ого на 5-й уровень (оценка 0,5, шкала 0-1), если вы имеете в виду шкалу, представленную на диаграмме в моей презентации.
Вопрос: «Вы показывали оценку зрелости компании по 10 факторам СУБП. Есть у вас методики оценки финансового эффекта (эффективности) при изменении уровня зрелости в целом и по каждому из показателей?»
Ответ (ВР): Нет, пока такую методику не разрабатывал, так как сделать это весьма сложно. У вас есть методики оценки финансового эффекта от совершенствования процесса конструирования изделий, управления персоналом или развития корпоративной культуры? Вряд ли. Но, тем не менее, многие собственники компаний убеждены, что это делать нужно.
Вопрос: «В своей практике консультанта и продавца консалтинговых услуг я давно чувствовал нехватку методики оценки зрелости организации с точки зрения ее готовности к тем или иным работам в области бизнес-анализа. Мог бы я надеяться, что Вы или другой выдающийся профессионал однажды подготовит такую методику, которая позволит нам, специалистам, качественно оценивать организацию с точки зрения ее способности успешно внедрить конкретные наши работы / предложения?»
Ответ (ВР): Вопрос интересный. Такая методика, правда не в формализованном виде, у меня есть. Приходится оценивать возможность внедрения системы на этапе принятия решения – работать с конкретным клиентом или нет. Думаю, мы ее подготовим и опубликуем в ближайшее время.
Наталья Косарева,
эксперт-практик в области развития производственных систем, руководитель группы сервисных компаний по всей территории России, организатор кубка Гастева А.К. в 2019 году.
Владимир Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент»
Март 2021 г.
Проект внедрения системы управления бизнес-процессами (СУБП). Часть I. «Концепция»
Проект внедрения системы управления бизнес-процессами (СУБП). Часть I. «Концепция»
В серии статей Владимира Репина подробно раскрывается план внедрения Системы управления бизнес-процессами (СУБП), как части общей системы управления. Ключевой результат внедрения СУБП – это бизнес-процессы с лучшим мировым уровнем эффективности и качества, основанные на инновационных, цифровых технологиях. План внедрения может быть адаптирован с учетом специфики вашей компании.
Что такое СУБП и зачем она нужна вашей компании?
Начнем с определения:
Система управления бизнес-процессами (СУБП) — совокупность методов, инструментов, ресурсов и внедренных бизнес-процессов, направленная на эффективное развитие Компании на основе управления каждым значимым бизнес-процессом в рамках его жизненного цикла.
СУБП – это часть системы управления компанией, как например система управления финансами или система управления персоналом. Наличие СУБП означает, что в организации ведется практическая работа с процессами: оперативное управление, анализ, улучшение, стандартизация и автоматизация.
Ключевой результат СУБП – это бизнес-процессы с лучшим мировым уровнем эффективности и качества, основанные на инновационных, цифровых технологиях.
Главное условие успешного внедрения СУБП – наличие твердого желания собственников и руководителей верхнего уровня системно организовать работу с процессами.
В данной серии статей я предлагаю вашему вниманию подробный план внедрения СУБП «C нуля». Этот план вы можете адаптировать с учетом особенностей и конкретной ситуации в вашей организации.
Уровень развития процессной практики может быть различным. Его можно оценить, используя методику оценки зрелости системы управления бизнес-процессами, а потом сформировать план совершенствования (внедрения) СУБП в вашей компании.
План внедрения СУБП
План внедрения СУБП включает следующие этапы:
- Подготовка к выполнению проекта.
- Разработка документа «Концепция внедрения СУБП в компании».
- Разработка Методологии и регламентация процессов СУБП.
- Разработка Архитектуры бизнес-процессов.
- Внедрение программного обеспечения СУБП.
- Разработка системы развития компетенций по процессному управлению.
- Разработка системы вовлечения персонала в деятельность по улучшению процессов.
- Выполнение «пилотного» проекта по оптимизации сквозного процесса компании.
На рис. 1 показан ориентировочный график выполнения проекта внедрения СУБП.
Срок внедрения СУБП, то есть построения Системы работы с процессами около 6 месяцев. При желании, можно быстрее. Но есть определенные ограничения, связанные, в первую очередь, с недостатком ресурса времени руководителей и их мотивации выполнить проект. Крайне нежелательно растягивать проект на 1,5-2 года. За это время многие решения потеряют актуальность, результаты обучения будут забыты, регламенты устареют. То есть систему нужно строить достаточно быстро.
Руководство компании может принять решение об определении КПЭ по результатам проекта, которые будут стимулировать руководителей подразделений выполнять проектные задачи в срок и с высоким качеством. Это – один из ключевых факторов успеха проекта
1. Подготовка к выполнению проекта
Подготовка к выполнению проекта включает следующие группы работ.
1.1. Проведение 1-дневного семинара-совещания с руководством компании по внедрению СУБП.
Перед тем, как инициировать проект, руководство должно убедиться, что СУБП действительно необходима компании. Нужно познакомиться с методологией и возможными результатами внедрения, рассмотреть примеры других компаний, оценить уровень развития практики работы с процессами, обосновать необходимость внедрения СУБП. Для этого целесообразно провести однодневный семинар-совещание или, другими словами, стратегическую сессию с руководством верхнего уровня.
1.2. Обсуждение видения и целей внедрения СУБП.
Обсуждение видения СУБП компании и конкретизация целей ее внедрения могут выполняться в рамках совещаний руководителей верхнего уровня с привлечением собственников. Результатом совещаний является предварительная формулировка видения и целей внедрения СУБП в компании. Координирует работу один из руководителей, либо внешний консультант. На данном этапе важно определиться с основными аспектами будущей системы, причем широкими мазками, эскизно, без детализации.
1.3.Поиск и подбор Руководителя Процессного офиса, Главного методолога и бизнес-аналитиков.
В рамках подготовки к проекту необходимо выбрать из своих сотрудников или привлечь со стороны специалистов, от которых во многом зависит успех внедрения СУБП. Необходимо подобрать Руководителя Процессного офиса, Главного методолога и одного-двух бизнес-аналитиков (на первое время).
Для подбора можно использовать проф. стандарт «Специалист по процессному управлению» и соответствующий тест, доступный на сайте ассоциации ABPMP Russian Chapter. Так же можно обратиться к лучшим экспертам в области процессного управления за помощью в подборе и тестировании кандидатов.
Было бы весьма недальновидно запускать такой важный проект, как внедрение СУБП без ресурсов, опираясь только силы сотрудников подразделений, которые не имеют нужных компетенций в области процессного управления (в лучшем случае, они рисуют алгоритмы с ромбиками, как на уроках информатики).
1.4. Назначение куратора проекта внедрения СУБП по стороны Руководства компании.
Одновременно с п. 1.3. выполняется выбор и назначение куратора проекта со стороны топ-менеджмента компании. Это может быть первый заместитель директора, директор, руководитель крупного департамента, представитель собственника.
1.5. Выполнение бенчмаркинга.
Куратор с сотрудниками Процессного офиса и ключевыми руководителями могут совершить 2-3 бенчмаркинговых поездки для ознакомления с опытом внедрения СУБП и практикой работы с бизнес-процессами в передовых компаниях. Если таких средств нет, то необходимо, как минимум, ознакомиться с опытом других компаний, доступным из открытых источников: сайта www.bpmaward.ru, www.finexpert.ru, www.tadviser.ru и др. Так же можно посетить специализированные конференции для обмена опытом с коллегами.
1.6. Разработка Плана проекта внедрения СУБП.
Процессный офис разрабатывает План внедрения СУБП. Если в компании развита культура проектного управления, то по всем правилам может быть создан Устав проекта.
При подготовке плана важно четко определить, какое время (в человеко-часах) потребуется о руководителей и специалистов компании. Это время обязательно должно быть выделено. По ходу проекта стимулом для предоставления ресурсов могут является соответствующие КПЭ.
План внедрения презентуется руководству компании (Совет директоров, Правление и т.п.), дорабатывается и утверждается. Руководителем проекта внедрения СУБП может быть назначен кто-то из топ-менеджеров, либо руководитель Процессного офиса. В некоторых случаях может быть привлечен внешний специалист на время проекта.
Далее выделяются необходимые ресурсы: время руководителей и специалистов, инфраструктура, технические и финансовые средства, программное обеспечение. Сделать это нужно быстро, не затягивая на несколько месяцев.
2. Разработка документа «Концепция внедрения СУБП в компании»
2.1. Формирование Глоссария.
Система терминов в области процессного управления является важнейшим элементом СУБП. Процессный офис разрабатывает Глоссарий, используя общепринятые отраслевые практики, книги специалистов по BPM, доступные системы терминов, рекомендации BPM CBOK, опыт экспертов. Крайне нежелательно использовать сложные, запутанные термины.
По ходу проекта Глоссарий будет дополняться терминами с учетом используемых решений в области автоматизации СУБП.
Глоссарий должен быть доступен всем сотрудникам компании на внутреннем корпоративном web-портале.
2.2. Определение видения, целей и принципов СУБП.
Процессный офис формализует видение, цели и принципы СУБП в рамках проекта документа «Концепция внедрения СУБП в компании». В некоторых компаниях этот документ называют «Стандарт управления бизнес-процессами» и т.п. Это концептуальный, руководящий документ, скорее политика, чем регламент.
Руководитель проекта организует согласование видения, целей и принципов СУБП с руководством компании.
2.3. Архитектура бизнес-процессов компании
Процессный офис прописывает в проекте «Концепции» понятие архитектуры, как она должна формироваться, для чего и как будет использоваться.
Включать саму архитектуру в виде реестра или модели процессов в «Концепцию» нецелесообразно, так как она будет изменяться по ходу проекта. Необходимо определиться с базовыми аспектами построения и использования архитектуры процессов компании.
2.4. Определение структуры процессов для управления ЖЦ бизнес-процесса.
Процессный офис прорабатывает структуру процессов СУБП, которые необходимо спроектировать и внедрить для управления всеми значимыми бизнес-процессами в рамках их жизненного цикла.
Жизненный цикл любого процесса (см. рис 2) включает целеполагание, планирование и проектирование, внедрение изменений, выполнение процесса и оперативное управление, анализ.
Например, необходимо включить в структуру процессов СУБП «Процесс описания процессов». Это необходимо для четкой организации работы по проектированию бизнес-процессов с высоким качеством. Если пустить работу на самотек, то будут получены результаты весьма низкого качества, которые нельзя использовать. Данный процесс СУБП будет использоваться в рамках этапа ЖЦ «Проектирование процесса и планирование изменений».
Другой пример – «Разработка Технического задания на автоматизацию процесса» — то есть соответствующий бизнес-процесс и т.п.
В идеальной ситуации должны быть разработана общая модель процессов СУБП. Такая модель наглядно показывает взаимодействие процессов СУБП между собой и с другими процессами организации.
Удобно представлять модель процессов СУБП в виде матрицы, где в столбцах показаны фазы жизненного цикла процесса, а в строках – процессы СУБП, которые должны быть развернуты в организации.
Важно не забыть про процессы управления самой СУБП: целеполагание, планирование работ по описанию, анализу, регламентации и автоматизации процессов, планирование проектов по совершенствованию СУБП, анализ ее эффективности и проч.
2.5. Определение методологии СУБП
Многие процессы СУБП должны базироваться на четко определенных методиках, в том числе:
- Методика проектирования процессов.
- Методика анализа процессов.
- Методика автоматизации процессов.
- Методика внедрения изменений.
- Методика разработки целей и показателей для управления процессами.
- Методика оперативного управления процессами.
- Методика оценки уровня зрелости СУБП и проч.
Процессный офис включает в проект «Концепции» перечень соответствующих методик, которые будут использоваться. Не все они могут быть разработаны сразу, но необходимо понимание, что они нужны для организации практики работы с бизнес-процессами в компании.
2.6. Определение участников СУБП.
Процессный офис проектирует структуру будущей СУБП в части субъектов. Определяются органы управления и участники СУБП: Процессный комитет, Процессный офис, Процессный Методолог, владельцы процессов, менеджеры процессов, участники временных рабочих групп по проектированию процессов и проч. С учетом определенных процессов СУБП определяются функции, полномочия и ответственность субъектов СУБП. Готовый раздел включается в проект «Концепции».
2.7. Определение архитектуры информационных систем СУБП
В рамках «Концепции» целесообразно описать архитектуру информационных систем, которые будут использоваться в СУБП (см. рис. 3): состав, назначение и основные информационные потоки между ними. Для управления бизнес-процессами в рамках СУБП используются:
- Среда проектирования и анализа процессов (например, Business Studio, ARIS и др.)
- Система автоматизации процессов – BPMS (например, Bizagi, Elma и др.).
- Внутренний web-портал.
- BI-система.
Возможны различные комбинации систем. Например, модуль BI может быть реализован в рамках единого web-портала компании. Другой пример – использование среды проектирования и портала BPMS без отдельного программного обеспечения для проектирования процессов (Business Studio, ARIS).
Выбор архитектуры информационных систем СУБП определяется многими факторами:
• ИТ-стратегией компании;
• функциональными возможностями уже используемых в компании систем, в т.ч. web-портала;
• наличием средств для приобретения и внедрения ИТ-систем;
• ограничениями в области безопасности и проч.
Тем не менее, в «Концепции» принципиально важно сформулировать, что будут использоваться: обязательно web-портал для управления ЖЦ бизнес-процессов (формируется на основе архитектуры процессов компании), средство проектирования и автоматизации процессов, средство для автоматического формирования регламентирующих документов на основе схем процессов, средство для оперативного управления процессами (может использоваться web-портал компании или доработанный портал BPMS).
2.8. Определение системы оценки зрелости и этапов развития СУБП компании.
В рамках «Концепции» желательно указать, что компания будет регулярно проводить оценку зрелости СУБП по соответствующим разделам.
Целесообразно показать перспективу развития СУБП на как, например, показано на рис. 4.
2.9. Презентация и утверждение Концепции внедрения СУБП.
После того, как проект «Концепции внедрения СУБП в компании» подготовлен, Процессный офис организует презентацию документа для руководства компании. Проводится обсуждение «Концепции» на совещаниях с руководством компании. «Концепция» утверждается и доводится до персонала.
В следующих статьях серии я подробно рассмотрю оставшиеся этапы проекта внедрения Системы управления бизнес-процессами компании.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Директора АО «СО-ЕЭС», руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы.
Июль 2020 г.
Нотация BPMN как внутренний стандарт компании для проектирования бизнес-процессов: «за» и «против»
Нотация BPMN как внутренний стандарт компании для проектирования бизнес-процессов: «за» и «против»
В статье Владимира Репина обсуждаются вопросы использования нотации BPMN в качестве корпоративного стандарта проектирования бизнес-процессов компании. Рассматриваются аргументы «За» и «Против» применения. Представлены предложения по организации обучения сотрудников. Приводится практический пример внедрения нотации на крупном предприятии. Обсуждаются «подводные камни» использования нотации BPMN на первых этапах проекта.
Какие нотации используют компании для описания процессов сегодня?
Многие успешные компании, внедряющие технологии автоматизации бизнес-процессов, используют нотацию BPMN. Многие, но не все… Более того, в РФ существует огромное количество средних и крупных предприятий, на которых вообще отсутствует принятый корпоративный стандарт проектирования бизнес-процессов. Какими средствами они «рисуют» процессы? Чаще всего в MS Visio используют набор объектов для «Простой блок-схемы». Бывают ситуации хуже, когда в компании одновременно применяют 3-4 разных подхода к описанию процессов, причем все они нестандартные и реализованы в различных «нотациях» и программных продуктах, включая MS Excel и Power Point.
Интересно, почему, когда речь заходит о необходимости описать процессы, все (кроме узкого круга профи) хватаются за эту «Простую блок-схему» с ромбиками? Возможный ответ – этому учили в школе на уроках информатики. Вдолбили, так сказать. Если бы в школе учили описывать исполняемые процессы в BPMN, то вряд ли чья-то рука потянулась к блок-схеме родом из 70-х. Но пока этого, увы, нет.
К чему приводит такая практика проектирования бизнес-процессов? Во-первых, схемы процессов понятны весьма узкому кругу лиц, а не всем сотрудникам компании. Во-вторых, такие схемы, чаще всего, носят аналитический характер. Это означает, что процесс описан весьма укрупненно, без деталей. Таки схемы нельзя «исполнить». Если попытаться выполнить работу как указано на схеме, то сразу возникнут вопросы, ответов на которые схема не дает. Это звучит странно – как схема, предназначенная для описания алгоритмов, дает сбои при описании процессов для бизнеса? Конечно, ответ заключен не в наборе используемых значков нотации. Причина — в идеологии формирования схемы.
Сегодня тренд цифровизации бизнеса явно набирает обороты. Но может ли компания, которая даже не имеет внутреннего стандарта моделирования и обученных сотрудников, быть успешной в цифровой трансформации? Сомнительно. Для начала, придется научиться быстро и эффективно проектировать процессы своими силами (создать внутренние компетенции), либо заплатить большие деньги внешним провайдерам.
Ситуацию с использованием устаревших подходов частично усугубляет наличие в крупных компаниях действующих систем электронного документооборота. То, что в них творится, назвать автоматизацией бизнес-процессов можно весьма условно. Большинство руководителей это понимает, но не знает возможностей современной BPMS (Business Process Management System) в части автоматизации процессов и, особенно, применения концепции «Документ без документа». Вообще, относительно недавно вступил в стадию умирания бумажный документооборот, а теперь и электронный документооборот должен умереть, оставив вместо себя автоматизированные процессы с нужным набором данных. В BPMS, если потребуются, документы можно формировать автоматически, так сказать, «налету».
Использование нотации BPMN в качестве корпоративного стандарта дает возможность не только проектировать процессы, но и внедрять в массы идеологию исполняемых процессов в купе с новыми ИТ-технологиями, такими как PM (Process Mining), RPA (Robotic Process Automation) и проч. Рассмотрим аргументы «За» и «Против» использования нотации BPMN в качестве корпоративного стандарта.
Почему нотация BPMN: «За» и «Против»
Руководителям компании нужно объяснить, что BPMN – это не просто значки другого, незнакомого вида и цвета. Это – инженерный стандарт проектирования исполняемых бизнес-процессов, обладающий следующими преимуществами (плюсами):
• наглядность, понятность и красота схем;
• после базового обучения можно начинать с использования ограниченного набора объектов;
• BPMN — стандарт ISO с 2013 года;
• BPMN де-факто использует большинство разработчиков BPMS.
Да, BPMN – сложный стандарт. Однако, даже начинающие при использовании ограниченного набора объектов и понимания сути метода (исполняемый процесс, токен, экземпляр) могут проектировать вполне качественные схемы. Более того, применение сложных семантических конструкций без действительной практической необходимости может только осложнить работу, привести к созданию неоправданно сложных схем или вообще исказить смысл процесса до неузнаваемости. С чем бы сравнить? Это как неопытный спортсмен, не освоивший базовую технику бросков, начинает пытаться применять сложные и опасные приемы. Я уверен, что можно обучить сотрудников, так сказать, использовать верхушку айсберга. Этого на первых порах будет достаточно. Крайне важно, чтобы сотрудники компании научились формировать наглядные, понятные и красивые схемы. Много раз на практике наблюдал ситуацию, когда запутанная, уродливая схема после соответствующей доработки становится красивой, а главное, понятной участникам процесса и внутреннему заказчику – руководителю.
Что важно донести до руководителей?
В первую очередь, нужно довести до сведения руководителя компании, что нотация BPMN – это лучший инженерный стандарт для проектирования процессов. Вряд ли в ближайшее время появится какой-то другой стандарт. Если поставлена цель цифровизации компании, то навык проектирования исполняемых процессов с использованием нотации BPMN будет одним из ключевых.
Далее важно объяснить руководителю разницу между общей, аналитической схемой и схемой исполняемого процесса. Для этого потребуется раскрыть понятие токена и экземпляра процесса. Более сложные аспекты, связанные с межпроцессным взаимодействием, можно будет объяснить на примерах компании несколько позже (чтобы поначалу не вызвать отторжения к подходу в целом из-за сложности этого конкретного метода).
BPMN – сложный стандарт. Но в рамках первичного ознакомления достаточно дать руководителям минимально необходимые знания семантики и метода моделирования бизнес-процессов. Это сделать вполне реально, например, в рамках проведения моделирующих (рабочих) сессий по описанию и анализу бизнес-процессов компании.
По ходу вовлечения, руководителям обязательно нужно показывать возможности, ограничения и условия эффективного использования современных решений класса BPMS, PM, RPA, AI и проч. Но надо четко понимать, что передаваемая и, можно сказать, культивируемая в умах менеджеров идеология исполняемых бизнес-процессов является базой для пропаганды новых информационных технологий.
Как обучать сотрудников нотации BPMN?
Это не так уж и сложно. Нужно:
- найти хорошего специалиста, который умеет преподавать тему, и обсудить с ним учебную программу;
- подготовить учебные и методические материалы;
- выбрать инструмент моделирования;
- разработать внутренний стандарт применения нотации BPMN для проектирования бизнес-процессов;
- организовать обучение;
- организовать работу по практическому закреплению навыков моделирования процессов.
В настоящее время специалистов, хорошо знающих BPMN, на рынке уже достаточно много. Но важно, чтобы такой специалист мог научить использовать нотацию на простых и понятных примерах, без использования «птичьего языка» (сленга ИТ-специалистов – профессиональных внедренцев BPMS). Кстати, я категорически против так называемого «каскадного» обучения, когда одного сотрудника отправляют на тренинг, а он потом пытается учить всех остальных. Результат – множество ошибок, а главное, — искаженное понимание темы.
Обучение проектированию процессов в нотации BPMN я провожу по книге «Моделирование бизнес-процессов в нотации BPMN. Пособие для начинающих. Часть I». Как правило, в течение 4-6 часов слушатели делают практические задания, осваивая элементы нотации от простого к сложному. Затем, они выполняют комплексное практическое задание по проектированию трех связанных между собой процессов. Проводится презентация результатов, анализ схем по чек-листу и разбор ошибок. Для такого обучения достаточно одного дня.
Далее выдаются практические задания, которые слушатели делают в течение недели. Затем проводится рабочая сессия по представлению и разбору схем процессов («домашние задания» я проверяю заранее). После 2-3 сессий участники приобретают навык формирования вполне адекватных схем в нотации BPMN.
На следующем этапе развития можно использовать книгу Игоря Федоров «Нотация BPMN 2.0. Стандарт ISO/IEC 19510:2013 для создания исполняемых моделей бизнес-процессов», сам стандарт и множество практически полезных материалов в сети Интернет.
Идеальным вариантом освоения BPMN является практикум с использованием, собственно, BPMS (например, такой практикум проводит А.А. Белайчук, Президент ABPMP Russian Chapter, с использованием системы BizAgi). Однако, в ряде случаев это сделать технически и организационно сложно. Приходится начинать с простого. Но, как минимум, демонстрацию движения токенов вдоль схемы исполняемого процесса сделать крайне полезно.
Внедрение нотации BPMN как корпоративного стандарта проектирования процессов в Иркутской нефтяной компании
В качестве примера рассмотрим кейс внедрения нотации BPMN в «Иркутской нефтяной компании» («ИНК»), в которой я уже более 1,5 лет сопровождаю проект создания и развития Системы управления бизнес-процессами. Информацию любезно предоставил Юрий Андреевич Федосеев, начальник отдела оптимизации бизнес-процессов и стандартизации ООО «ИНК» (ОБПиС).
За время проекта в «ИНК» удалось сделать многое:
• разработан и внедрен стандарт «Моделирование бизнес-процессов»;
• установлен и настроен инструмент проектирования и анализа процессов (Business Studio 4.2);
• обучено 259 руководителей и специалистов;
• сформировано более 226 схем в BPMN;
• внешние подрядчики (в т.ч. крупные консалтинговые компании) обязаны представлять результаты работы в виде схем BPMN с учетом требований стандарта компании;
• внедрены регламенты сквозных процессов, разработанные на основе схем процессов в нотации BPMN;
• внедряется система оценки процессной зрелости компании;
• проект на стадии выбора BPMS.
Самое главное, что в «ИНК» активно формируется процессное мышление у руководителей и специалистов. Высокая практическая оценка используемых методов и инструментов подтверждается большим количеством запросов от подразделений в ОБПиС с просьбой провести анализ и оптимизацию их процессов. Юрий Федосеев отмечает: «В проектах оптимизации мы преимущественно используем базовый набор элементов нотации (стартовые и конечные события, события отправки и приема сообщения, таймеры, шлюзы и/или… Несмотря на сложность, базовые элементы и логика нотации хорошо воспринимается сотрудниками на обучении. Освоение происходит быстро. Все бизнес-аналитики отдела прошли подготовку по программе Внутренних тренеров, что позволило организовывать качественное обучение для небольших групп на постоянной основе. Мы не ставим перед собой цель описать все процессы Компании. Ценность нашей работы – в помощи, внутреннем консалтинге. Наши клиенты – подразделения, которые хотят разобраться в своей работе и в том, как лучше взаимодействовать с другими в рамках сквозных процессов. И моделирование – это наш основной инструмент в этом деле…».
«Оптимизация процессов Электроснабжения» — так назывался один из проектов «ИНК», в рамках которого использовалась технология описания и анализа процессов в нотации BPMN. По ходу проекта было сформировано 59 процессов в нотации BPMN. Описание и анализ процессов позволил выявить 10 критичных зон безответственности и последствия, к которым наличие этих зон может привести. Прогнозный экономический эффект от устранения зон безответственности составляет около 78,6 млн. рублей в год.
Второй проект с использованием BPMN, как корпоративного стандарта проектирования процессов «ИНК», — это «Оптимизация процессов Капитального строительства». В рамках данного проекта в условиях жестких ограничений удалось выстроить слаженную и эффективную работу подразделений. Основные результаты моделирования процессов на текущей фазе проекта: прозрачный процесс капитального строительства, оперативный доступ сотрудников к схемам процессов и регламентам через корпоративный портал.
Подводные камни внедрения нотации BPMN в качестве корпоративного стандарта
В некоторых компаниях при использовании нотации BPMN для проектирования процессов возникают определенные трудности. Работа организована неэффективно. На выходе получаются поверхностные схемы аналитического характера, которые невозможно использовать для анализа и принятия решений. Некоторые причины такой ситуации:
• плохое обучение – как следствие, непонимание исполняемых процессов и формирование аналитических схем;
• архитектурные решения низкого качества – проектирование процессов нижнего уровня без понимания системы процессов в целом;
• попытка формально «перерисовать» в BPMN старые схемы с сохранением их недостатков;
• схемы огромного размера с ошибками (семантика, логика);
• низкая степень мотивации участников процесса (или обратная мотивация – желание скрыть реальную картину);
• моделирование ради моделирования.
Резюме
Хочу отметить, что навык проектирования процессов в нотации BPMN – это только один из многих навыков второй группы компетенций («Операционные») модели Gartner 2013 года, которые необходимы для успешного выполнения BPM-проекта в компании. Это означает, что руководители не должны ожидать «процессно-цифрового чуда» только от того, что они заставили необученных сотрудников с низким уровнем внутренней мотивации «рисовать» схемы процессов. Другими словами, внедрение Системы управления бизнес-процессами компании – это не только проектирование процессов, но их активное улучшение и внедрение изменений, создание методов и инструментов управления бизнес-процессами.
Если руководство компании поставило цель трансформировать систему управления с использованием современных процессных технологий, то навык проектирования и анализа исполняемых процессов является одним из ключевых. Нотация BPMN в этом случае может и должна быть выбрана в качестве внутреннего корпоративного стандарта проектирования бизнес-процессов.
В.В. Репин,
к.т.н., доцент, консультант по управлению, Генеральный директор ООО «Владимир Репин Менеджмент», Советник Зам. Председателя Правления АО «СО-ЕЭС».
Ноябрь 2019 г.
Деловая игра «Процессный пазл»
Деловая игра «Процессный пазл»
В статье Владимира Репина рассматривается деловая игра «Процессный пазл», предназначенная для наглядной иллюстрации разницы между функциональным и процессным подходом к управлению, мотивирования руководителей компании на внедрение системы процессного управления.
Введение
Многие руководители и специалисты в области орг. развития сталкиваются с задачей, как быстро и наглядно объяснить собственникам и топ-менеджерам разницу между функциональным и процессным управлением, показать преимущества процессного управления и обсудить ключевые решения, которые нужно принять для его внедрения в компании.
Игровой способ подачи информации является одним из наиболее эффективных, особенно для людей, перегруженных работой. Они могут на время отвлечься от проблем и заняться принятием решений в легкой игровой манере, пробуя различные возможные варианты.
Автором статьи была разработана и опробована на практике игра для руководителей под названием «Процессный пазл». Цель игры – наглядная практическая иллюстрация преимуществ процессного управления и обсуждение ключевых управленческих решений, которые необходимо принять в случае его внедрения в компании.
Исходные условия
Для игры используются заранее заготовленные карточки с бизнес-процессами некоторой компании. По условиям задачи эта организация производит и продает оптом чайники. По заявкам клиентов в конструкцию чайников могут вноситься изменения. Необходимо изменение технологии производства, поиск новых поставщиков сырья и т.п.
Организационная структура компании представлена на рис. 1.
В каждом структурном подразделении и для руководителей верхнего уровня определены «функциональные процессы». Это процессы, которые от начала до конца выполняются в рамках структурного подразделения под полным контролем его руководителя. И это не абстрактно сформулированные функции, например, «Маркетинг» или «Производить продукцию», а вполне четкие процессы с реальными входами и выходами. Но они локализованы внутри подразделений и не являются сквозными или, другим словами, – межфункциональными.
Большинство процессов на схеме рис. 2 приблизительного одного масштаба. Но некоторые из них явно являются процессами следующего уровня декомпозиции (предупреждать игроков об этом не нужно).
Есть один процесс, который явно не вписывается в традиционный функционал подразделения. Этот процесс основан на реальном примере из практики и включен специально, чтобы проиллюстрировать тот факт, что «функциональные процессы» могут быть довольно странными и находиться в явно неподходящих для них структурных подразделениях. Уверен, что читатель сам легко найдет этот процесс среди прочих.
Еще есть некоторые процессы, которые начинаются со слова «Участие…». В ряде случаев, эти процессы просто некорректно выделены со слов сотрудников, для которых они по каким-то причинам субъективно важны.
Кстати, для зарегистрированных пользователей портала FineXpert.ru доступен файл MS Visio со всеми представленными в статье схемами.
На рис. 3 показан пример оформления карточек с функциональными процессами. Карточки нужно распечатать и вырезать – для этого служит пунктирная линия. Так же нужно распечатать несколько пустых карточек, которые понадобятся во время игры.
Порядок игры
Количество участников игры – от 3 до 6-8 человек (если участников больше, то целесообразно подготовить два комплекта карточек). Целесообразно сдвинуть 4 стола, чтобы удобно было раскладывать карточки. Если в компании есть плоттер, то можно заранее распечатать схему, представленную рис. 2. Если нет, то достаточно просто распечатать схему орг. структуры (3-4 шт.).
Сценарий деловой игры «Процессный пазл»:
- Подготовить карточки, схемы и рабочие столы.
- Создать рабочие группы по 6-8 руководителей.
- Кратко рассказать кейс («компания производит чайники», функциональные процессы), раздать карточки (предварительно перемешав их, как карты). Если играют топ-менеджеры крупной компании, то карточки можно предварительно разложить по функциональным подразделениям для экономии времени. Но это делать нежелательно. Первичное раскладывание карточек нужно для первого знакомства с компанией. Обязательно нужно сказать, что реструктуризация компании не предполагается, т.е. нельзя менять схему орг. структуры.
- Задание № 1. Необходимо разложить карточки с процессами по функциональной принадлежности, в т.ч. для руководителей верхнего уровня (10-12 минут).
- Задание № 2. В группе создать две подгруппы по 3-4 человека.
a. Задание для подгруппы № 1 – собрать пазл – сквозной процесс «Подготовка технико-коммерческого предложения для клиента». Можно слегка намекнуть на возможные границы этого процесса, но не делать всю работу за участников.
b. Задание для подгруппы № 2 — собрать пазл – сквозной процесс «Разработка нового изделия (от идеи до постановки на производство»).
c. Объявить для всех, что если кому-то потребуется карточка, но она уже занята другой группой, то можно взять пустую карточку и написать на ней необходимое название (такое же, как на существующей карточке!). - По факту готовности сквозных процессов:
a. сфотографировать выложенные группами «пазлы»;
b. вывести фото с пазлами на большой экран (через проектор); если группа одна, то можно обсуждать результаты работы прямо на рабочем столе;
c. группы докладывают результаты сборки сквозных процессов из функциональных процессов;
d. ведущий находит несоответствия в сквозных процессах, удаляя ненужные или добавляя нужные процессы, объясняет допущенные ошибки. - Подведение итогов игры.
Ниже на фото показано, как это всё выглядит «в живую» во время игры.
Кроме указанных выше двух сквозных процессов с использованием карточек можно выложить еще несколько сквозных процессов, например, «Согласование договора».
На следующем фото представлен результат сборки сквозного процесса «Подготовка технико-коммерческого предложения для клиента». Это один из возможных вариантов. Участники должны увидеть, что процесс выполняется в нескольких функциональных подразделениях компании.
Для тех топ-менеджеров, которые много читали западных авторов и полагают, что в компании легко определить единый сквозной процесс от «Заказа до оплаты отгруженного товара», можно поставить задачу собрать этот сквозной процесс. В случае удачной выкладки (можно дать группе 15 минут) целесообразно задать вопрос о том, кто и каким образом будет управлять таким длинным процессом, и как исполнители процесса будут распределены по функциональным подразделениям. Возможно, кто-то предложит плоскую «бирюзовую» орг. структуру. Впрочем, данная игра, на мой взгляд, не имеет целью убедить руководителей в необходимости радикально изменять структуру, и уж тем более, создавать супер-мега сквозные бизнес-процессы.
В качестве опции, после выкладки сквозных процессов можно предложить участникам игры сделать еще следующее:
- выложить еще несколько ключевых сквозных бизнес-процессов компании;
- определить, какие процессы являются чисто функциональными, и не вошли ни в один сквозной процесс (можно пометить карточки с такими процессами красными стикерами);
- определить, какие процессы не соответствуют по уровню остальным (слишком детальные);
- определить, какие процессы (даже функциональные!) вовсе не являются процессами и выделены вследствие субъективного видения руководителей компании;
- предложить разработать систему целей и показателей для управления сквозными процессами;
- предложить продумать возможные направления изменения организационной структуры компании.
По итогам проведения игры важно, на мой взгляд, обсудить с участниками следующие ключевые моменты:
- обсудить понятие границ процесса (по входам/выходам и условиям старта и завершения процесса (необходимо объяснить понятие событий разного типа);
- обсудить понятие уровня декомпозиции; затронуть наличие в пазле неадекватных процессов (типа «Участие в ….» и т.п.).
- отметить момент, что некоторые функциональные процессы могут быть многократно использованы в нескольких сквозных процессах в связи с чем возможен конфликт по ресурсам;
- обсудить, кто из руководителей в этом учебном примере может стать владельцем сквозного процесса; отметить подробно проблемы в определении ответственности и полномочий владельцев процессов;
- обсудить ключевые решения, которые должны принять топ-менеджеры для практического внедрения процессного управления в организации:
a. определение ключевых сквозных бизнес-процессов;
b. определение владельцев процессов и наделение их реальными полномочиями и ответственностью.
Заключение
Вы можете использовать игру в том виде, как она разработана с существующим набором карточек (см. файл MS Visio). Либо — провести анализ деятельности структурных подразделений вашей компании, выявить функциональные процессы, подготовить новые карточки и организовать игру с учетом вашей специфики. Но делать это нужно аккуратно, четко понимая, какие именно функциональные процессы вы определили (соответствие по уровням), какие «ошибочные» пазлы специально включили в состав карточек.
Сделать всё это вы можете сами силами внутреннего подразделения орг. развития (Процессный офис, отдел СМК) или пригласить автора статьи с его коллегами-консультантами. Мы проводим необходимое количество встреч с руководителями верхнего уровня, определяем функциональные процессы, готовим сценарий и модерируем игру.
Так же можно провести игру в рамках 1-дневного тренинга по процессному управлению для топ-менеджмента.
Автор будет признателен за отзывы по результатам игр, которые вы проведете, а так же за проверенные практикой предложения по дополнению (возможно, изменению) сценария игры.
Успехов при внедрении системы процессного управления!
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ноябрь 2018 г.
Базовые понятия процессного управления
Базовые понятия процессного управления
Что понимается под процессным управлением? Чем оно является, а чем – нет? В статье Владимира Репина рассмотрены базовые понятия процессного управления, необходимые для практической работы, а так же семь критериев, которые помогут быстро оценить уровень развития процессного управления в вашей компании.
Введение
Статья написана для тех руководителей, которые сомневаются в необходимости использования практики процессного управления (Business Process Management) в своем функциональном подразделении и компании в целом. Для тех, кто уже использует эти методы, материал может быть полезным с точки зрения систематизации знаний.
В статье я буду использовать рабочее определение процесса, как целенаправленной деятельности, по определенной технологии преобразующей входы в выходы (результаты), представляющие ценность для клиента.
Можно найти множество различных определений процесса. Ряд определений вполне обоснованно можно критиковать. Но я буду использовать именно это определение.
Если в вашей компании никто еще не говорит о процессном управлении, то вы можете начать его использовать в рамках своего функционального подразделения, независимо от каких-то глобальных инициатив или проектов руководства. Для этого нужно просто определить процессы, которые на 100% находятся в зоне вашего контроля, и начать ими управлять.
Большего эффекта можно достигнуть от изменения сквозных (межфункциональных) процессов организации. Для того, чтобы начать с ними работать, нужно желание топ-менеджеров компании и более сложный методический поход.
Начнем с простых вопросов и рассмотрим более подробно, что же представляет собой процесс, как объект управления.
Процесс, как объект управления
На рисунке 1 схематично представлен процесс, как объект управления.
Прежде всего, необходимо установить границы процесса. Для этого нужно определить входы и выходы, а так же условия начала и завершения процесса.
Входы и выходы — это информационные или материальные объекты: файлы с информацией, документы на бумажном носителе, материалы для производства и т.п. Требования к каждому входу/выходу должны быть четко определены (специфицированы) в документах и согласованы со всеми заинтересованными сторонами (с поставщиками и потребителями процесса, руководством вышестоящего уровня и, в некоторых случаях, с государством).
Кроме входов/выходов важно определить условия начала и завершения процесса. Процесс может «запускаться» в определенное время («по таймеру») или при получении управляющего сообщения (например, устного распоряжения руководителя). Наличие готовых (например, сложенных горкой) входов еще не означает, что процесс нужно запускать. Так же необходимо четко определить условия завершения процесса, т.е. в каких случаях можно считать, что процесс завершен. Например, документы переданы, товар упакован и помещен на место хранения, клиент подтвердил получение документа и т.п. Опять же, условия завершения не являются выходами процесса. Не надо путать.
На рис. 1. показано, что процесс выполняется по определенной технологии. По сути, это продуманный алгоритм выполнения последовательности действий, приводящий к получению результата с заданными, повторяющимися характеристиками. Для практического выполнения этого алгоритма нужны ресурсы – люди, оборудование, информационные системы и проч. Они связаны между собой в том смысле, что отсутствие необходимого оборудования или людей повлечет за собой изменение алгоритма работы. Наоборот, цель изменения (оптимизации) процесса может повлечь за собой изменения в требованиях к ресурсам.
Технология выполнения процесса хранится, как минимум, в виде знаний и навыков в головах сотрудников, которые его выполняют. Как правило, знания о технологии выполнения процесса фиксируют в регламентах (положениях, инструкциях). Кроме того, требования к выполнению процесса могут быть «зашиты» в информационные системы, которые используются для автоматизации процесса.
Слева на рис. 1. Слева показан график нагрузки на процесс. Входы, которые нужно обрабатывать, поступают в процесс с определенной интенсивностью в течение определенного времени. Например, необходимо обрабатывать партию из 5 деталей каждые 2 минуты. В этом случае график нагрузки будет дискретным – с равномерным интервалом. Другой пример – суточный график количества посетителей для супермаркета. Поскольку посетителей много, то график будет практически непрерывным и на нем будут видны периоды пиковой нагрузки.
Итак, нагрузка на процесс – это количество входов, которое нужно обработать за единицу времени. Однако, возможности процесса ограничены, в первую очередь, по ресурсам. Используемая технология выполнения процесса и ресурсы (оборудование, люди) определяют производительность процесса – возможность преобразовывать определенное количество входов в выходы за единицу времени. На рис. 1 снизу показан график производительности процесса. На нем видны ступеньки. Это может быть, например, из-за того, что вводилось/выводилось из эксплуатации оборудование, добавляли людей в рабочие смены и т.п.
Что будет со входами, которые процесс не в состоянии пропустить через себя из-за ограничений по производительности? Они встанут в очередь – см. соответствующий график на рис. 1. (если, конечно, им не расхочется быть преобразованными в этом процессе – например, когда вы стоите в очереди на кассу и вдруг решаете, что не будете больше стоять).
С учетом нагрузки на процесс и его производительности мы получаем график выходов (результатов) процесса. На рис. 2 показан пример, показывающий, как связаны входы, производительность, очередь и выходы процесса (при условии, что нет брака). По горизонтальной шкале показы часы суток. По вертикальной – количество единиц (входы и т.п.).
На рис. 1 над процессом показаны цели и показатели, а так же владелец процесса. Цели и показатели нужны для управления процессом. Производительность является одним из ключевых показателей. Кроме нее, важно измерять план/факт по количеству выходов процесса, эффективность (отношение результата к затраченным на его получение ресурсам), показатели качества (например, уровень дефектов в выходах процесса). Для организации, как системы ориентированной на достижение целей во внешней среде, важно не просто преобразовывать входы в выходы, а делать это эффективно, т.е. с прибылью для себя. Это означает, что крайне важно измерять и улучшать показатели эффективности процесса.
Владелец процесса – это руководитель, который полностью отвечает за весь процесс – от начала до конца. Ему подчиняются все ресурсы процесса. Но вот цели процесса и показатели, по которым он управляется, владелец процесса сам себе ставить не может. Это должны делать руководители вышестоящего уровня, которые понимают роль этого процесса в общей системе работы организации и в состоянии правильно установить цели и выбрать показатели для измерения степени их достижения (на практике с этим всем часто бывают проблемы).
Если процесс целиком проходит внутри функционального подразделения, то проблем с выбором владельца процесса нет – это руководитель подразделения, либо сотрудник, которому делегированы соответствующие полномочия (заместитель, ведущий специалист).
Если процесс сквозной, то задача существенно усложняется. Нужно формулировать правила определения владельца процесса, определять его ответственность и полномочия.
Важно отметить, что если руководителя назвали владельцем процесса, но при этом он ничем не рискует (премией, зарплатой, должностью), то это вовсе не владелец, а просто его имитация.
Управление процессами в масштабах организации начинается тогда, когда ключевые сквозные процессы получили своих владельцев и эти владельцы начали что-то реально изменять, сокращая затраты, повышая производительность и качество работы, удовлетворенность клиентов сквозных процессов. В противном случае говорить, что в компании «внедрено процессное управление» нельзя. Никто никакими процессами не управляет. В лучшем случае, внедрено «описание процессов» в какой-то там среде моделирования (на сегодня, большая часть такого софта – «рисовалки», по большому счету).
Отдельная история – это автоматизация сквозных процессов. Условно говоря, она может быть функциональная и процессная. При функциональной автоматизации «процессное управление» не наступает, т.к. мы имеем те же раздробленные по подразделениям небольшие функциональные процессы, только автоматизированные в какой-то системе.
При процессной автоматизации (в BPMS или СЭД) процессное управление так же может не наступить в случае, если за администрирование процесса в информационной системе отвечает технический специалист, но владелец сквозного процесса не назначен (или ничего реально не делает с точки зрения управления и развития процесса).
Еще раз, я утверждаю, что ключевым критерием внедрения «процессного управления» является наличие системы управления и развития сквозными процессами. Как минимум, это означает, что в организации есть реально работающие владельцы процессов. Причем они могут это делать без автоматизации в BPMS или СЭД, хотя «на коленках» управлять процессами гораздо сложнее.
Работа с локальным процессами функциональных подразделений имеет смысл и может принести положительные практические результаты. Но значительные системные эффекты возможны только при оптимизации сквозных процессов, так как большая часть проблем возникает из-за раздробленности процесса на небольшие функциональные кусочки и потери синергии от взаимодействия участников. Проще говоря, функциональные колодцы «рвут» процессы по живому, что приводит к росту затрат, увеличению длительность выполнения и снижению качества результатов работы в масштабах компании.
Как же можно понять, в какой степени в вашей организации используется практика управления процессами на межфункциональном уровне? Можно предложить ряд простых критериев для оценки.
Семь критериев оценки уровни развития процессного управления
Существует большое количество методов оценки уровня процессной зрелости организации. Часть из них даже утверждены как стандарты. Однако, все они достаточно сложны и весьма теоретичны, что делает невозможным их быстрое практическое применение.
Ниже представлена таблица с семью критериями, по которым можно быстро и достаточно легко оценить уровень развития существующей в вашей организации практики управления бизнес-процессами. Данные критерии сформулированы на основании моего практического опыта внедрения процессного подхода к управлению.
По каждому критерию сформулированы характеристики «левой» и «правой» части шкалы оценки. Если таблица будет понятна, то вы сможете сформулировать характеристики для промежуточных «делений шкалы» и оценить «уровень зрелости процессного управления» в вашей компании.
Таблица. Критерии оценки уровня развития процессного управления
| № | Критерий | Левый край шкалы | Правый край шкалы |
| 1 | Бизнес-процесс, как объект управления | Сквозные процессы не определены. Руководители подразделений управляют своими локальными, функциональными процессами. | Определены ключевые сквозные процессы организации. Для каждого процесса назначен владелец процесса. Ответственность и полномочия владельца процесса четко определены. |
| 2 | Цели и показатели для управления бизнес-процессом | Показателей для процессов практически нет. Считаются только показатели структурных единиц (подразделения, сотрудники). | Полный набор показателей для комплексной оценки сквозных процессов. Ряд показателей используется в качестве KPI для стимулирования владельца процесса и участников процесса. |
| 3 | Технология выполнения бизнес-процесса | В основном, в головах участников. Частично – в регламентах (положениях, инструкциях). | Полностью актуальная информация о технологии в регламентах сквозных процессов (в т.ч. в гипертекстовом виде), многие требования «зашиты» в BPMS, СЭД |
| 4 | Внедрение изменений в бизнес-процессе | Не системно, время от времени | Системное, целенаправленное развитие на основе понимания жизненного цикла процесса |
| 5 | Вовлеченность руководителей в управление процессами | Практически отсутствует. | Руководители активно участвует в управлении и развитии сквозных процессов. |
| 6 | Процессная интеграция в компании | В разных частях системы управления практикуются различные походы к работе с процессами. Единой архитектуры процессов нет. | Есть архитектура бизнес-процессов компании. Все инициативы и проекты (в т.ч. автоматизация) синхронизируются на единой процессной платформе организации. |
| 7 | Цифровой образ бизнес-процесса | Отсутствует. | Ключевые сквозные процессы имеют цифровые образы в информационной системе. |
Заключение
Методы процессного управления можно применять в рамках функционального подразделения, но наибольший эффект можно получить при управлении сквозными бизнес-процессами.
Степень развития методов процессного управления может быть разной. Существует множество методик оценки. Можно быстро оценить степень развития процессного управления по семи критериям, предложенным в данной статье.
Вовлечение руководителей в практику работы с процессами является первым важным шагом на пути изменения системы управления компании с ориентацией ее на сквозные бизнес-процессы и клиентов.
Обучение руководителей путем проведения различного рода деловых игр, например, игры на определение границ и структуры сквозных бизнес-процессов компании «Процессный пазл», может стать хорошей отправной точкой для внедрения процессного управления в организации.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ноябрь 2018 г.
Добавить комментарий Отменить ответ
И снова о SADT: в чем были неправы Марка и МакГоуэн?
И снова о SADT: в чем были неправы Марка и МакГоуэн?
В статье Владимира Репина рассмотрены недостатки методологии 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-7 уровнях (по «горизонтали» и «вертикали»);
- все бизнес-процессы имеют реальные связи (не абстрактно-обобщенные) со всеми другими бизнес-процессами, с которыми они взаимодействуют;
- все связи должны базироваться на потоках реальных объектов (информация, документы, материальные ресурсы), используемых в организации;
- бизнес-процессы должны быть стыкованы по входам/выходам в соответствии со своим уровнем иерархии (процесс нижнего уровня не может быть поставщиком, например, процесса уровня +3);
- бизнес-процессы, описанные в нотации 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-БП2.В1 (исходящая стрелка 1 Бизнес-процесса 1 поступает как входящая стрелка 1 в Бизнес-процесс 2);
- на каждом уровне модели (до уровня BPMN) определяются процессы управления;
- по каждой стрелке должны двигаться реальные объекты из справочников (информация, документы, материальные ресурсы);
- внешние ссылки разрешены только на диаграмме А0;
- использование междиаграммных ссылок (МДС) запрещено на всех диаграммах (исключение может быть только одно – когда создано две отдельных модели в IDEF0 (у каждой своя контекстная диаграмма) и их нужно связать между собой. Но в этом случае допускаются только МДС на диаграмме А0).
На рисунке 2 представлена модель компании (промышленное производство), сформированная на основе представленных выше правил (кроме «правила двух стрелок» — пока выбрано некоторое промежуточное решение).
Использованы разные цвета для стрелок, по которым движутся объекты разного типа:
• красные стрелки — управляющие воздействия (ограничения, планы, приказы и т.п.);
• серые стрелки – отчетность всех видов, проекты планов и т.п.;
• синие стрелки – информационные и материальные потоки;
• розовые стрелки – запросы на предоставление сервисов (входы в обеспечивающие процессы);
• зеленые – ресурсы для выполнения процессов и результаты сервисов (оборудование, ИТ-сервисы, персонал и т.п.).
Стрелки одного типа частично наложены друг на друга для сохранения визуальной наглядности диаграммы.
Вверху рисунка 2 показана процессная категория «Управление бизнесом». Из этого четырехугольника выходят стрелки красного цвета – стрелки управления, которые входят сверху во все остальные категории процессов.
Ниже показаны так называемые основные процессы, которые участвуют в создании продукта (оказании услуг). Процессные категории данного типа связаны между собой стрелками синего цвета. При построении диаграммы была сделана попытка минимизировать количество стрелок между объектами.
Еще ниже представлен четырехугольник категории «Инженерно-техническое обеспечение». Из него выходят стрелки зеленого цвета – ресурсы, необходимые для выполнения остальных процессов (оборудование, ЗИП и проч.). На диаграмме видно, что эти зеленые стрелки заходят во все остальные процессы снизу в соответствии с методологией SADT.
Справа внизу показана категория «Обеспечение операционной деятельности» — внутри все процессы обеспечения, такие как «Управление персоналом», «Административно-хозяйственное обеспечение» и другие. Видно, что выходом категории также являются зеленые стрелки, передающие ресурсы (например, персонал).
Важно, что все реально взаимодействующие бизнес-процессы связаны между собой реальными потоками объектов.
Если бы в Business Studio была возможность включать/выключать отображение различных типов стрелок (например, показать только управление и отчетность), то модель можно было разрабатывать и смотреть по слоям. Такое решение было бы намного удобнее.
Представленная на рисунке 2 модель может показаться сложной. Но она имеет то преимущество, что все взаимодействующие процессы связаны стрелками, по которым движутся реальные объекты (информация, документы, материальные объекты). Это означает, что:
• можно четко определить входы/выходы процессов и зоны ответственности руководителей;
• для каждого процесса можно определить цели и показатели;
• процессы можно синхронизовать между собой.
Выводы
По итогам анализа недостатков методологии SADT можно сделать следующие выводы:
• методология SADT в классическом варианте содержит ряд допущений, которые не позволяют использовать ее для создания инженерной модели бизнеса (ИМБ);
• за счет отмены тоннельных стрелок и введения новых правил моделирования можно скорректировать методологию SADT и сделать ее применимой для создания ИМБ;
• существующие системы бизнес-моделирования (такие, как ARIS или Business Studio) крайне неудобны для создания сложной ИМБ;
• есть основания полагать, что ИМБ может служить платформой для создания полной цифровой модели бизнеса путем интеграции подсистем управления и ряда функциональных приложений на единой процессной платформе.
В.В. Репин,
к.т.н., доцент, консультант по управлению, тренер,
Генеральный директор ООО «Владимир Репин Менеджмент»
Ноябрь 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 месяцев и более). На выходе команда проекта получает толстые тома схем, с которыми дальше сложно работать. Потом делается попытка выполнить анализ процессов и обоснование необходимых изменений. Потом еще много месяцев рисуют модели «как должно быть». За это время процессы уже успевают поменяться… Считаю более правильным подход, когда сначала создается процессная архитектура бизнеса, а затем выполняется работа по описанию, анализу и оптимизации процессов, причем последовательно – начиная с наиболее важных к менее важным процессам. По каждому процессу должен быть достигнут практический эффект от оптимизации.
Но если все-таки без тотального описания бизнес-процессов не обойтись? Как быть в этом случае? В следующем разделе представлен методический подход к выполнению такого проекта.
Возможный методический подход
Для тотального описания бизнес-процессов компании необходимо:
- убедить команду топ-менеджеров в необходимости изменений и найти лидеров;
- разработать архитектуру процессов компании;
- установить и настроить систему бизнес-моделирования;
- создать необходимые компетенции у команды проекта;
- разработать методики (описания и анализа процессов, в т.ч. загрузки исполнителей);
- выполнить описание, анализ и оптимизацию процессов, в т.ч. разработку моделей «как должно быть», анализ загрузки исполнителей, расчет изменения численности сотрудников и исключения ненужных должностей;
- разработать перспективную организационную структуру и штатное расписание;
- выполнить организационные изменения, в т.ч. орг. структуры и штатного расписания.
Создание и убеждение команды топ-менеджеров и поиск лидера (лидеров) проекта – задача во многом «политическая» и в данной статье не обсуждается.
Для разработки архитектуры процессов нужна команда экспертов, члены которой смогут по-новому взглянуть на бизнес компании и построить модель на основе видения перспективных цепочек создания ценности или, говоря шире, — перспективной бизнес-модели. При этом акцент должен делаться на сквозные процессы и эффективность управления инвестируемым капиталом собственников по всей цепочке процессов, по всему жизненному циклу продуктов компании. Наличие адекватной архитектуры процессов – это залог успешного выполнения проекта тотального описания процессов. Запутанная, сложная архитектура или архитектура, имеющая мало общего с реальностью, приведут к построению рыхлой и запутанной процессной модели бизнеса.
Создание компетенций у команды проекта. Прежде чем решать этот вопрос, нужно найти людей в эту команду. Кто может в нее войти? Можно попытаться провести кастинг среди крупных консалтинговых компаний, но вряд ли даже крупные компании способны выставить 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 г., Москва