TeachDocs

Материал из RunaWFE
Перейти к навигации Перейти к поиску

RunaWFE. Учебные материалы

Версия 4.5.0

© 2015-2023, ООО "Процессные технологии"

Основы разработки бизнес-процессов предприятия

Построение уровней описания бизнеса

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

Уровни описания бизнеса

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

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

Уровни бизнеса

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

  • Уровень предприятия
  • Уровень бизнеса
  • Уровень операций
  • Уровень шагов выполнения задачи
  • Уровень исполнителя

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

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

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

Уровень шагов выполнения задачи

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

  • решения задач, поставленных аналитику в рамках проекта
  • решения своих задач другими участниками на следующих фазах проекта

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

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


Проведение описания «снизу-вверх» и «сверху-вниз»

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

Методы сбора информации

Применяются следующие способы сбора информации:

  • Изучение имеющейся документации
  • Прямое наблюдение
  • Интервью
  • Опрос
  • Специальное совещание


Изучение имеющейся документации

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

Прямое наблюдение

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

Интервью

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

Опрос

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

Специальные совещания

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

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

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

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

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

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

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

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

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

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

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


Спецификация бизнес-процессов, как правило, состоит из следующих описаний

1) Описание исполнения бизнес-процессов (цепочек действий)

2) Описание декомпозиции бизнес-процессов на подпроцессы

3) Описание бизнес-функций

4) Описание сценариев операций.


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

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

Результат проектирования должен содержать, в том или ином виде, следующие уровни:

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятие парадигма рассматривается в данном случае в терминах концепции парадигм программирования Роберта Флойда (Флойд Р. О парадигмах программирования. В кн.: Лекции лауреатов премии Тьюринга. М: Мир, 1993) , которая является расширением концепции парадигм Томаса Куна, предложенной в работе «Структура научных революций» (Кун Т. Структура научных революций. М.: Прогресс, 1975).

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

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

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

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

  • изучение нотаций описания бизнес-процессов и обучение работе с конкретными СУБП (аналог обучения синтаксису языков программирования и работе с конкретными компиляторами)
  • изучение различных возможных вариантов реализации в виде исполнимых бизнес-процессов тех или иных типичных ситуаций в бизнесе предприятия (аналог обучения приемам программирования)

Существуют большое количество учебных курсов, посвященные первому подходу. Например, в работах [***] обобщен опыт обучения студентов разработке исполнимых бизнес-процессов в МЭСИ, НИТУ МИСиС и УГАТУ. На занятиях студенты изучают теорию исполнимых бизнес-процессов, графические нотации описания бизнес-процессов, основные компоненты типичных BPMS и получают практический опыт разработки и исполнения простейших бизнес-процессов.

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

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


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

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

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

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

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


Размер схемы бизнес-процесса

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

Направления движения точек управления по схеме бизнес-процесса

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

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

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

Tdc4 3 1.png
Рисунок 4.3.1. Схема с движением точек управления слева-направо - сверху-вниз.


Отказ от использования ролей в виде дорожек на схеме бизнес-процесса

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

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

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


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

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

Tdc4 3 2.png
Рисунок 4.3.2. «Интуитивная» реализация действия, выполняемого одновременно двумя лицами.


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

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

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

Tdc4 3 3.png
Рисунок 4.3.3. Правильная реализация действия, выполняемого одновременно двумя лицами


Вынесение второстепенных действий в параллельную ветку

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

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


Tdc4 3 4.png
Рисунок 4.3.4. Неправильная реализация бизнес-процесса с второстепенными действиями

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


Tdc4 3 5.png
Рисунок 4.3.5. Правильная реализация бизнес-процесса с второстепенными действиями


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

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


Tdc4 3 6.png
Рисунок 4.3.6. Другая реализация бизнес-процесса со второстепенными действиями

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

Tdc4 3 7.png
Рисунок 4.3.7. Пример схемы бизнес-процесса с тремя вложенными парами разделений - слияний


Расположение парных разделений-слияний и переходов, их соединяющих

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

Tdc4 3 8.png
Рисунок 4.3.8. Схема бизнес-процесса на которой линии расположения парные разделений – слияний, выделены желтым цветом


Желательно, чтобы линии переходов, соответствующих одновременно выполняющимся потокам действий, были параллельными. Это увеличивает понятность схемы, так как бизнес-аналитику проще представить параллельно расположенные на схеме последовательности действий как «параллельно» выполняющиеся. Примеры таких расположений также представлены на Рис. 4.3.5, 4.3.7, 4.3.8.


Решения с непарными разделениями - слияниями

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

Он состоит из следующих действий:

  • Заключить договор аренды помещения
  • Подготовить помещение к конференции
  • Подготовить пригласительные материалы
  • Впечатать в материалы конференции адрес
  • Разослать материалы конференции

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

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


Использование элемента «окончание бизнес-процесса»

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

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

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

Tdc4 3 9.png
Рисунок 4.3.9. Схема бизнес-процесса, реализующая согласование документа

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


Пример "компромиссного" решения по разделениям-слияниям и использованию элемента «завершение потока управления»

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

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

Описание бизнес-процесса:

Операционист вводит в стартовую форму данные заявки на кредит и запускает экземпляр бизнес-процесса. Далее задание «Верифицировать данные» выполняет Специалист-Верификатор. Он выбирает один из двух вариантов - Данные верифицированы / Данные не верифицированы.

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

В случае, если данные верифицированы, далее задание «Определить риски» выполняет Сотрудник скорингового центра. В форме задания он выбирает один из двух вариантов - Риски приемлемы / Риски не приемлемы. В случае, если риски не приемлемы, Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз выполняет задание «Уведомить об отказе», после этого бизнес-процесс завершается. В случае, если риски приемлемы, далее задание «Произвести проверку СБ» выполняет сотрудник службы безопасности. В форме задания он вводит результат проверки - один из четырех вариантов: "Отлично", "Хорошо", "Удовлетворительно", "Не удовлетворительно". В случае неудовлетворительного результата далее Операционист знакомится с информацией об отказе в оформлении данного кредита, SMS-шлюз выполняет задание «Уведомить об отказе».

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

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

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

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

Tdc4 3 10.png
Рисунок 4.3.10. Схема бизнес-процесса розничного кредитования банка


Использование алгоритмов в схеме бизнес-процесса

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

В качестве примера рассмотрим реализацию задачи об игре в камешки. Игра состоит в следующем: есть кучка в 100 камней. Игроки ходят по очереди. За один ход игрок должен взять из кучки не менее одного, но не более 9 камней. Тот, кто возьмет последний камень, является выигравшим. Надо разработать бизнес-процесс, реализующий игру в камешки. Также требуется придумать гарантированно выигрышную стратегию поведения игрока. В бизнес-процессе на форме задания каждому игроку должен находиться соответствующий стратегии совет от экземпляра бизнес-процесса, - какое количество камней игроку на данном ходе стоит взять из кучки. Если при данном количестве камней в кучке не существует "выигрышного" хода, то на форме должно содержаться сообщение "не могу дать совет". На Рис. 4.3.11 представлен пример бизнес-процесса, решающего данную задачу.

Tdc4 3 11.png
Рисунок 4.3.11. Схема бизнес-процесса, решающего задачу об игре в камешки


Опишем несколько алгоритмических задач

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

Tdc7.png
Рисунок 7. Получение справок в поликлинике (основной бизнес-процесс)
Tdc8.png
Рисунок 8. Получение справок в поликлинике (подпроцесс)


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


Классическая задача исследования операций - задача о дуэли.

Описание начальных условий дуэли:

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


Описание последовательностей действий в бизнес-процессе


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


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

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

Если дуэлянт дошел до барьера, то дальше он идти не может, он может только сделать выстрел.

Если выстрел не успешный и второй противник ранее тоже сделал неуспешный выстрел, то дуэль заканчивается с результатом "Ничья".

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

После окончания дуэли первому и второму дуэлянту направляются задания на ознакомление с результатом дуэли.


Задача М. Гарднера о разборчивой невесте

Описание предметной области:

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


Описание последовательностей действий в бизнес-процессе:

Ведущий запускает бизнес-процесс. В стартовой форме он выбирает невесту из списка (соответствует группе "Невесты").

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

В подпроцессе:

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

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

Если Невеста выбирает "Отказать", то текущему претенденту направляется задание "ознакомиться с отказом невесты", а Невеста рассматривает следующего претендента.

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

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


Пример решения:

Tdc9.png
Tdc10.png
Tdc11.png
Tdc12.png
Tdc13.png
Tdc14.png


Внедрение BPMS

Возможное сопротивление изменениям

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

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

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

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

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

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

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

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

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

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

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

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


Вовлечение персонала

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

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

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

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

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

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


Обучение пользователей

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

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

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

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


Внедрение бизнес-процессов в эксплуатацию

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

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

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

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

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


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

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

1. С целью проверки эффективности эксплуатирующихся бизнес-процессов (Для того, чтобы "Делать вещи правильно"),

2. Для последующего перепроектирования бизнес-процессов (Чтобы после этого "Делать правильные вещи")

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

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

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

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

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

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

  • Изучение документации
  • Интервью
  • Опрос
  • Совещание экспертов

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


Проверка эффективности эксплуатирующихся бизнес-процессов

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

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

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


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


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


Метрики эффективности

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


Анализ взаимодействия с заказчиком

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


Анализ точек передач ответственности

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


Анализ бизнес-правил

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


Анализ производительности

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


Анализ узких мест

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


Измерение эффективности бизнес-процессов

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

То есть, для каждого вида измерения надо сформулировать следующее:

  • Цель измерения
  • Что надо измерять
  • Где измерять
  • Как измерять
  • С чем сопоставлять результаты измерения
  • Ответственный за измерение

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

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


Отчет по результатам анализа

Завершающий этап анализа - подготовка отчета по его результатам.

Отчет может включать следующие пункты):

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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


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

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

  • Объединять бизнес-процессы в группы
  • Уменьшать число передач ответственности между подразделениями
  • Избегать дублирования ввода информации в бизнес-процесс (группу родственных бизнес-процессов)
  • При проектировании бизнес-процессов учитывать желаемые показатели эффективности


При перепроектировании бизнес-процессов производится следующее:

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


Имитационное моделирование

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

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

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

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

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


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

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

Ежедневный мониторинг:

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


Правильно проводимая трансформация должна:

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


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

Модель верхнего уровня задает систему координат для построения схем бизнес-процессов «как будет». С помощью имитационного моделирования проектная команда может проверить соответствие модели требованиям верхнего уровня и целям трансформации.

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

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

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

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

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


Литература

1 BPM CBOK 3.0. Свод знаний по управлению бизнес-процессами. Перевод с английского под редакцией Белайчука А.А., Елифёрова В.Г. М.: АПУБП, 2015

2 Михеев А. Г., Орлов М. В. Перспективы Workflow-систем // PC Week/RE, №№ 23 2004, 28 2004, 43 2004, 36 2005

3 Вагнер Ю.Б., Белайчук А.А. BPM в действии // Директор информационной службы, №2, 2007

4 Mikheev A.G., Pyatetskiy V.E. Designing executable business processes as a programming paradigm //Business Informatics. 2016. No. 1 (35). DOI: 10.17323/1998-0663.2016.1.45.56.