Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

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

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

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

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

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

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

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

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

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