6.4.Описание бизнес-процессов

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

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

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

• Business Flow Chart – функциональные блок-схемы (бизнес-схемы). Адаптация использования блок-схем описания программных алгоритмов для бизнес-схем. Детальное описание блок-схем приведено в ГОСТ 19.701-90 (ИСО 5807-85) «Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения».
• UML (Unified Modeling Language) – унифицированный язык моделирования. Семейство нескольких нотаций для описания любых систем, включая описание бизнес-процессов. Позволяет перейти от описаний системы непосредственно к написанию компьютерных программ. Большинство нотаций посвящено именно архитектуре программ, нотации для бизнес-процессов довольно ограниченны по возможностям и визуализации.
• IDEF (Integrated DEFinition) – семейство нотаций для решения задач моделирования сложных систем. Для задачи описания бизнес-процессов интерес представляют IDEF0 и IDEF3:

-IDEF0 (Function Modeling) – методология функционального моделирования. С помощью схем IDEF0 изучаемая система (предприятие) предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков). Моделирование средствами IDEF0 обычно является первым этапом изучения и высокоуровневого описания любой системы (предприятия);

-IDEF3 (Process Description Capture) – методология документирования процессов, происходящих в системе (предприятии), описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с IDEF0 – каждая функция (функциональный блок) может быть представлена в виде отдельного процесса схемой IDEF3.

• DFD (Data Flow Diagrams) – диаграммы потоков данных. Инструмент структурного анализа и проектирования информационных систем. Является структурной нотацией, используемой в бизнес-анализе и в анализе информационных систем. Схемы DFD хорошо сочетаются с IDEF0 и IDEF3. Смысл DFD-блока, отображающего функцию, совпадает со смыслом блоков IDEF0 и IDEF3, заключается в преобразовании входов в выходы. DFD-блоки также имеют входы и выходы, но не поддерживают управление и исполнителей. DFD может быть высокоуровневой схемой, которая далее раскрывается в IDEF0.
• EPC (Event-Driven Process Chain) – событийная цепочка процессов, ключевыми элементами которой являются «События» и «Функции». Очень распространенная нотация для моделирования и описания бизнес-процессов, хорошо сочетается с IDEF0, как более наглядная замена нотации IDEF3. Имеет расширенный вариант – eEPC:

-eEPC (extended Event-Driven Process Chain) – нестрогий вариант EPC, когда можно использовать дополнительные элементы схем для большей наглядности – например, «база данных» символом цилиндра.

• BPMN (Business Process Model and Notation) – нотация для моделирования бизнес-процессов. Имеет простой и понятный конечному пользователю набор элементов. Нотация современная (появилась в 2004 году, стабилизировалась в 2008–2013 г.) и сегодня активно используется для описания бизнес-процессов, для чего она и была изначально предназначена, а не адаптирована из описания IT-систем.

Приведенный список не конечен, читатель может самостоятельно изучить иные средства моделирования, но приведены основные используемые инструменты, с которыми предстоит столкнуться в проектах внедрения ERP-систем.

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

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

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

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

Важно учитывать, что со схемами предстоит работать не только на экране в инструменте проектирования (где может быть удобная навигация между подчиненными и родительскими схемами), но и на бумаге (как часть отчета).

Цветная схема требует цветной печати, либо нужно подбирать цвета текста и фона графических элементов для читабельности и возможности различения полутонов при черно-белой печати. Также важным является расположение элементов: не всегда простой задачей будет вписаться в лист А4 для сохранения приемлемого масштаба и размера шрифтов текста. Нужно следовать правилу минимизации элементов функций (действий) на одной схеме до 5–8 штук. Иначе за счет элементов других типов схема превратится в паутину соединительных линий с потерей наглядности. Минимизация элементов облегчает восприятие, нужно выносить группируемые элементы в подпроцессы, использовать переходы между схемами. Такое требование актуально для схем любых нотаций.

Далее рассмотрим некоторые из приведенных выше нотаций.

Отправить