Тема внедрения изменений в бизнес-процессы дошла и до Российского отделения международной Ассоциации BPM-профессионалов (ABPMP Russian Chapter) в виде статьи президента этой ассоциации г-на Белайчука под названием "С чего начинается управление изменениями". Точнее г-н Белайчук поделился с читателями своего блога переводом статьи с англоязычного ресурса.
В статье речь идёт об управлении изменениями в бизнес-процессах. Основная мысль заключается в том, что "начинать управлять изменениями надо намного раньше — уже на первом этапе проекта BPI, когда разрабатывается устав, проводится выявление процесса и его моделирование". Автор статьи даёт понять, что управление изменениями должно носить систематический характер, и необходимо принимать во внимание, что в работе любой организации постоянными могут быть только изменения.
Далее в статье описываются трудности, которые непременно возникнут в организации при каждом витке итерации вносимых изменений в "устоявшуюся" работу процессов организации, и как с ними бороться на уровне психики?! "людей, сталкивающихся с изменениями".
Не уверен, какими именно способами члены международной Ассоциации BPM-психологов, извините, BPM-профессионалов решают поставленные задачи, так как кроме психологических методов решения вопросов по внедрению изменений других предложено, увы, так и не было.
Поэтому предлагаю вместо утешения сотрудников организаций, которым волей или неволей приходится сталкиваться с изменениями в структуре бизнес-процессов, дабы не расстраивать их понапрасну, рассмотреть более технический подход к этой ситуации.
Суть подхода заключается в следующем:
Запущенные экземпляры подстраиваются под изменения модели процесса автоматически.
То есть достаточно внести изменение в модель бизнес-процесса, а далее можно расслабиться и не думать, как встроить новые изменения в уже запущенные экземпляры, которые, к примеру, будут активны ещё несколько лет. Ведь ждать окончания их жизненного цикла, чтобы полностью забыть о них, нет ни желания, ни возможности.
Просьба не путать этот подход с adaptive case management (ACM).
ACM — это самый гибкий подход на сегодняшний день, который даёт возможность настраивать каждый запускаемый экземпляр индивидуально.
Рассматриваемый подход, в данной статье, описывает полу-структурированные процессы (semi-structured), которые обладают заранее определённым набором правил, но могут изменяться в ходе выполнения процесса.
Эти изменения автоматически применяются также к запущенным экземплярам до момента внесения изменений, тем самым обеспечивая наличие глобальной модели бизнес-процесса в данный момент времени.
Другими словами, изменения применимы не только к новым экземплярам (т.е. отсроченные изменения), а также ко всем запущенным экземплярам данной модели бизнес-процесса, используя метод миграции (т.е. экстренные изменения).
Рассмотрим пример из жизни, взяв процесс возврата командировочных, и примем допущение, что жизненный цикл этого процесса равен 10 годам (чтобы наглядней понимать преимущество экстренных изменений в запущенных экземплярах).
Модель процесса "Возврат командировочных" в версии 1.0:
Заполняется заявка на возврат командировочных, далее заявка обрабатывается менеджером, который может немедленно её одобрить, отклонить или запросить дополнительную информацию.
Согласно принятому решению происходит оповещение инициатора процесса. И после возврата командировочных или отказа возврата процесс завершается.
Процесс был запущен и спокойно себе отрабатывает заявки, пока в определённый момент времени не приходит уведомление от руководства, что заявки свыше €200 должны задним числом утверждаться ещё и начальником отдела. То есть это изменение также применимо к ранее запущенным заявкам, которые были проапрувлены менеджером, но у бухгалтерии, как обычно, не дошли до этого руки и командировочные ещё не были возвращены.
Для этого создаётся новая версия процесса с учётом необходимых изменений, в данном случае можно добавить ещё один UserTask и один ExclusiveGateway.
И следующая версия процесса будет выглядеть подобным образом:
Появилось новое разветвление после утверждения заявки менеджером; и если сумма превышает €200, то требуется утверждение ещё от одного лица с другим уровнем доступа.
Всё вроде хорошо, новые заявки будут запускаться по новой модели процесса, но остаётся вопрос, как быть с уже запущенными экземплярами, особенно с теми, где сумма возврата превышает €200? Здесь мы также вспоминаем о сделанном допущении, что окончание жизненного цикла запущенных экземпляров в ближайшие 10 лет не предвидится, а изменения нужно внести сейчас в не одну тысячу запущенных экземпляров, с разбросанными этапами выполнения по всей модели.
В этом случае, как было уже описано в первой части, последующая версия процесса соединяется с предыдущей посредством так называемой "Migration Map", в которой указываются "переходы" токенов между соседними версиями процесса.
Для данного примера "Migration Map" может выглядеть следующим образом, при котором заявки, которые были одобрены к выплате в версии процесса 1.0, но ещё не были обработаны бухгалтерией, будут перенаправлены к новому разветвлению "more than €200". В случае, если сумма превышает €200, то необходимо будет дополнительное одобрение начальством. Заявки с суммой до €200 будут, как и в первой версии, проходить к UserTask "Refund expenses" сразу без дополнительного одобрения.
Миграция активируется в момент перехода токена между тасками любого типа или в момент обращения пользователя к одному из UserTask.
В данном случае новые требования, которые необходимо применить к запущенным экземплярам, будут реализованы при попытке пользователя открыть UserTask "Refund expenses". Система управления процессами (СУП) определяет, что появилась новая версия процесса и заглядывает в "Migration Map". СУП по названию процесса, названию исходного UserTask, и зная в какой версии был запущен текущий экземпляр процесса, определяет версию процесса для миграции и название элемента в новой версии процесса.
По этим параметрам и проходит "скачок" между версиями. Для пользователя это происходит незаметно. Если после миграции в новой версии процесса у данного пользователя нет прав доступа к новому элементу, то появляется соответствующее сообщение о том, что версия процесса была изменена и запрашиваемый UserTask не доступен.
Миграция для остальных тасков происходит без структурных изменений, т.е. в тот же самый таск, но уже в обновлённой версии процесса.
Подводя итог, можно сказать, что с увеличением количества используемых BPNM элементов ухудшается гибкость самих процессов.
Для решения этой проблемы и обеспечения достаточной гибкости и адаптивности процесса моделирование происходит на двух абстрактных уровнях (Часть 2). На верхнем уровне описывается предметный процесс. Нижний уровень — технический, на нём описываются подпроцессы для верхнего уровня.
Золотое правило моделирования процессов: упрощайте предметный уровень и всё сложное переносите на технический.
Желаю всем простого, понятного и лёгкого моделирования!
Автор: asushko
