Текстовое описание формализованным языком – это описание БП с помощью заранее определенных словесных конструкций и оборотов, подобно словесному описанию алгоритма программы (ЕСЛИ… ТО… ИНАЧЕ… и т. п.). Кроме того, при описании формализованным языком уже существует определенный глоссарий терминов предметной области, что немаловажно для правильного понимания процесса. Недостатки данного способа представления информации – сравнительно большой объем, что может затруднить понимание процесса.

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

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

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

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

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

• семейство стандартов IDEF (в частности, IDEFo, DFD, IDEF3);

• семейство стандартов ARIS (в частности, нотация eEPC);

• семейство стандартов UML (Usecase diagram, activity diagram).

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

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

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

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

• каковы «вход» и «выход» процесса в целом;

• из каких процедур состоит процесс;

• кто выполняет каждую процедуру;

• что получается в результате ее выполнения;

• кто получает результат и как он его использует;

• какие исключительные ситуации (разветвления) возникают в процессе?

Вот пример неинформативной схемы процесса (рис. 3.3):

Рис. 3.3. Пример неинформативной схемы бизнес-процесса

На этой схеме не видно:

• после какого события или факта процесс начинается;

• кто в нем участвует (является его исполнителем);

• что делает каждый исполнитель;

• что является результатом выполнения всего процесса и результатом работы каждого исполнителя;

• какие могут быть разветвления и в каких случаях.

А вот фрагмент схемы того же процесса, подготовленной в кросс-функциональной нотации (рис. 3.4).

Рис. 3.4. Фрагмент схемы бизнес-процесса в кроссфункциональной нотации

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

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

• продолжительность выполнения процедуры;

• нормы расхода материальных ресурсов на единичное выполнение процедуры;

• ставка оплаты труда исполнителя процедуры;

• иные характеристики, которые потребуются для анализа издержек, специфические для данного бизнес-процесса.

К анализу бизнес-процессов можно подходить двумя и даже тремя путями.

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

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

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

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

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

• удовлетворенность конечным результатом БП;