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

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

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

Цель

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

К этим рисункам (диаграммам) нужно предъявить следующие требования:

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

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

• Во-вторых, необходимо построить «модель» процессов, из которой можно получить не только рисунки, но и, например, текстовые отчёты о составе модели и т.п. Поэтому для описания процесса нужно используем не карандаш и бумагу или их компьютерный аналог: программу — «рисовалку» типа Adobe Photoshop, — а специальное «инструментальное средство моделирования». Традиционно под этим термином известны продукты ARISи BPWin, однако не следует ассоциировать способ описания процессов с конкретным продуктом. Более того, зависимость от конкретного продукта сегодня уже является минусом как самого способа описания бизнес-процессов, так и

что же конкретно мы хотим получить от модели бизнес-процессов?

• Модель должна позволять автоматически создавать отчёты о её составе (например, для оценки затрат на разработку Системы)

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

• Она должна обеспечивать возможность электронного обмена моделями и диаграммами (а не только «картинками») между различными инструментальными средствами моделирования (а, следовательно, и между людьми), а также передачу их в Систему.

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

• Иметь обратную связь с Системой: при внесении в Систему изменений (в т.ч. уточнений), они должны автоматически отражаться в модели. В результате, кардинально меняется назначение модели и жизненный цикл её использования: она продолжает «жить» и после завершения (активного этапа) разработки Системы.

Без обратной связи от Системы модель постепенно отстаёт от того, что работает в Системе на самом деле, и поэтому модель «умирает»: становится неактуальной, а потому — ненужной. На синхронное внесение в модель тех изменений, которые вносятся в работающую Систему по требованию Клиента (и, возможно, самим Клиентом), обычно нет ресурсов. И даже в том случае, если такие изменения вносятся, они могут содержать ошибки, быть неполными и т.п. как следствие любых ручных операций.

И наоборот: наличие обратной связи от Системы к её модели замыкает контур управления Системой, делает реальностью циклическую разработку (round — trip engineering), которая сейчас является необходимым элементом любой серьёзной среды разработки автоматизированных систем.

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