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

Как правило, высокозначимые бизнес-процессы, специфические для организации, исполняют люди с использованием передовых технологий автоматизации. Внедрение таких процессов требует соответствующего управления изменениями. В большинстве случаев внедрение также требует разработки конкретных прикладных программных модулей. Модели процессов с KPI, соответствующими факторам роста ценности, являются отправной точкой для более детального моделирования обеспечивающего программного обеспечения. Они обеспечивают последовательный, управляемый подход от стратегии к внедрению и автоматизации процессов. Способ моделирования на этом этапе может измениться. Например, для моделирования структуры программного обеспечения, обеспечивающего высокозначимые процессы, может использоваться UML. Также с помощью моделей можно запрограммировать процессный движок BPMS. В зависимости от используемого репозитория и движка это может даже делаться автоматически или полуавтоматически. Чрезвычайно полезной здесь может быть интеграция средств моделирования и исполнения процессов, в первую очередь благодаря тому, что она позволяет гибко подстраивать процессы исходя из факторов роста ценности.

Для автоматизации процессов часто используется сервис-ориентированная архитектура (SOA), в которой функциональное программное обеспечение и логика процесса (потока работ) отделены друг от друга [Kirchmer 2017; Slama and Nelius 2011]. Таким образом, модели процессов могут использоваться, с одной стороны, для программирования потоков работ, а с другой – для разработки программных сервисов, для которых нет готовых библиотек. Программное обеспечение может поставляться вместе с референтными моделями, которые можно использовать для проектирования процессов.

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

Модели стандартных процессов используются для выбора или, как минимум, для оценки предварительно отобранных пакетов программного обеспечения, таких как ERP, SCM или CRM. Эти системы могут стать компонентами единой архитектуры следующего поколения. Затем модели, разработанные в ходе проектирования процессов, становятся движущей силой внедрения программных пакетов во всех подразделениях, участвующих в соответствующих бизнес-процессах [Kirchmer 1999]. В идеале входящие в состав программного обеспечения отраслевые референтные модели используются в качестве начального приближения в ходе проектирования процессов. Это означает, что вы приобретаете у поставщика программного обеспечения референтные процессные модели. Если такая возможность имеется, вы извлекаете выгоду из отраслевых настроек программного обеспечения и минимизируете усилия по проектированию и моделированию. Использование других отраслевых референтных моделей (не входящих в состав программного обеспечения) может привести к необходимости корректировок и обширных переделок.

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

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

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

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