Дмитрий Пинаев / Современные технологии управления

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

Описание системы управления

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

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

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

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

Модель бизнес-процессов компании

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

Организационная структура

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

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

На сегодняшний день большинство технологий бизнес-моделирования основаны на использовании графических диаграмм. Учитывая это, компания Microsoft включила в свою систему создания бизнес-диаграмм и схем Microsoft Visio 2003 специальные средства для описания бизнес-процессов и организационной структуры компании.

Для моделирования бизнес-процессов Visio 2003 предлагает бизнес-аналитику шаблоны для создания 7 видов диаграмм:

1. Basic Flowchart;
2. Cross-Functional Flowchart (с вертикальным или горизонтальным расположением дорожек);
3. EPC (Event-driven Process Chain);
4. IDEF0;
5. DFD (Data Flow Diagrams) в двух нотациях: Гейна-Сарсона и Йордана-Де Марко;
6. WFD (Work Flow Diagram)

Из перечисленных нотаций наиболее популярными являются IDEF0 и EPC.

Нотация моделирования IDEF0 базируется на методологии структурного анализа и проектирования SADT (Structured Analysis and Design Technique).

Диаграмма процесса «Закупка ТМЦ», изображенная с помощью нотации IDEF0

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

Типы стрелок нотации IDEF0

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

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

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

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

Диаграмма процесса "Обработка заказа", изображенная с помощью нотации EPC

Для описания бизнес-процессов нижнего (операционного) уровня можно использовать нотацию EPC, разработанную Институтом информационных систем Университета Саарланда (Германия) в сотрудничестве с компанией SAP AG. Ключевая особенность EPC диаграмм - описание бизнес-процесса как последовательности чередующихся событий и функций.

Основные графические элементы диаграммы EPC:

• функции,
• события,
• организационные единицы, ответственные за исполнение функций,
• информационные или материальные объекты, которые используются при выполнении функций,
• коннекторы (AND, OR, XOR).

В отличие от нотации IDEF0 нотация EPC позволяет удобно описать нелинейное выполнение бизнес-процесса. С помощью коннекторов можно обозначить некоторые функции процесса, выполняемые параллельно, а некоторые только при наступлении определенных условий.

Вторым шагом описания системы управления компании является построение модели организационной структуры. Для решения этой задачи Visio 2003 содержит шаблон Organization Chart, который позволяет быстро создать иерархическую диаграмму должностей и подразделений компании и определить их параметры.

Организационная структура

В шаблоне Organization Chart содержится набор графических элементов, обозначающих виды должностей:

• executive - руководитель высшего звена,
• manager - руководитель,
• position - должность,
• consultant - консультант,
• vacancy - свободная вакансия,
• assistant - помощник.

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

Владельцы процессов

После описания организационной структуры необходимо определить владельца процесса из числа руководителей и менеджеров компании. Владелец - это лицо, отвечающее за результат процесса и обладающее полномочиями для распоряжения ресурсами (материальными, трудовыми и пр.), необходимыми для его выполнения. Для того, чтобы назначить воадельца процесса на диаграммах IDEF0 необходимо завести пользовательский параметр «Process owner» у всех процессов и внести в него название должности из организационной структуры.

Заполнение свойств процесса

По разработанным моделям бизнес-процессов Microsoft Visio 2003 позволяет сформировать отчеты в формате:

• страницы Microsoft Excel,
• веб-страницы (HTML-файл),
• visio shape для внедрения отчета как таблицу Excel непосредственно в диаграмму Visio,
• файл XML.

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

Сформированный отчет по процессам в формате Microsoft Excel

Отличительной чертой Visio 2003 является простота и удобство создания диаграмм и интеграция с другими продуктами Microsoft Office. Благодаря этому, специалисты, увидевшие Visio в первый раз, уже через несколько часов начинают создавать диаграммы бизнес-процессов и организационных структур и использовать эти диаграммы в документах Microsoft Word.

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

Для целей моделирования в данном примере мы рассмотрим упрощенный процесс продажи некого самостоятельно производимого товара.

Непосредственное моделирование лучше всего начать с указания наименования и уточнения границ процесса. Границы можно зафиксировать сразу в виде событий на схеме. В нашем примере граничными событиями будут «Выявлена потребность клиента» и «Потребность подкреплена взаимными обязательствами» (см. рис. 3).

Рис. 3. Заголовок и границы процесса

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

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

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

Упрощенный пример описания процесса показан на рис. 5.

Рис. 5. Упрощенный пример описания процесса

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

Обучение проводится на персональных компьютерах.

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

В ходе тренинга рассматриваются наиболее распространённые методологии (нотации) моделирования бизнес-процессов, поддерживаемые Visio, и отрабатываются практические навыки построения графических диаграмм процессов в MS Visio.

Программа курса ориентирована на специалистов, занимающихся описанием, анализом и оптимизацией бизнес-процессов.

1. Базовые функции Microsoft Visio, необходимые для построения диаграмм бизнес-процессов.
   • Работа с листами диаграммы. Использование наборов фигур. Работа с образцами фигур. Добавление фигур на диаграмму. Проведение динамических соединительных линий между фигурами. Приклеивание соединительных линий к фигурам. Динамическое и статическое приклеивание. Установка параметров привязки и приклеивания. Использование функции автосоединения. Изменение размера и положения фигур. Изменение размера и положения текстового поля фигур. Маркеры фигуры: выделения, вращения, текстового поля, управления, точки соединения. Форматирование фигур. Копирование фигур и их формата. Автоматическое выравнивание и расстановка фигур. Группировка фигур и объединение их в контейнеры. Масштабирование, изменение размера и вида страницы диаграммы. Настройка параметров страницы диаграммы и её печати.
2. Основные правила построения диаграмм процессов.
   • Построение сети процессов верхнего уровня. Декомпозиция процессов. Определение целей описания процесса. Определение границ процесса: входов, выходов, поставщиков и потребителей. Построение диаграмм процессов верхнего и нижнего уровней. Правила отображения логики выполнения процесса. Правила использования событий и логических операторов. Отображение ответственных и исполнителей процессов.
3. Методологии и стандарты описания бизнес-процессов, поддерживаемых Microsoft Visio.
   • Наиболее часто применяемые на практике методологии и стандарты (нотации) описания бизнес-процессов, поддерживаемые программным продуктом Microsoft Visio. Схема процесса IDEF0. Обыкновенная блок-схема процесса. Блок-схема процесса с дорожками (Swimmer Lanes). Схема процесса ARIS VAC (Value Added Chain Diagram). Схема процесса ARIS EPC (Event driven Process Chain). Схема процесса BPMN (Business Process Model and Notation). Сравнительный анализ, преимущества, недостатки и области применения нотаций. Отображение на диаграмме ручных и автоматизированных процессов. Задание для процессов временных и стоимостных параметров, требований по срокам и качеству и других необходимых данных.
4. Сервисные функции MS Visio в приложении к задаче описания бизнес-процессов.
   • Декомпозиция и установка гиперссылок на вложенные диаграммы бизнес-процессов. Установка и редактирование защиты для фигур диаграммы. Установка для фигур диаграммы ссылок на различные внешние файлы, документы и ресурсы. Создание и редактирование атрибутов объектов диаграммы. Добавление и редактирование для фигур полей свойств (атрибутов). Создание и редактирование наборов фигур. Формирование отчётов на основе графической диаграммы. Формирование HTML-публикации графической диаграммы.

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

Хочу напомнить, что до начала описания бизнес процессов необходимо . компании – платформа, с которой необходимо начинать.

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

Схема бизнес процесса – инструкция для нетерпеливых

1 – Задайте границы процесса

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

2 – Нарисуйте основные блоки процесса

Расположите основные блоки (подпроцессы, операции) в том порядке, в котором они выполняются.

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

3 – Добавьте развилки и другие события

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

4 – Обозначьте роли участников процесса

В бизнес процессах нет должностей или конкретных сотрудников. Вместо этого используется понятие “роль”. Один сотрудник может выполнять множество ролей. Одну роль может выполнять множество сотрудников. Из набора ролей складывается должность.

По необходимости добавляйте недостающие операции.

5 – Разместите на схеме документы

Документ – это не обязательно официальная бумага с семью подписями. С точки зрения управления бизнес процессами документ – это информация на любом информационном носителе. Электронное письмо, доклад, презентация, СМС – все это документы.

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

6 – Добавьте используемые программы и базы данных

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

7 – Расположите инструменты и материалы

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

8 – Определите показатели эффективности в бизнес процессе

Расположите на схеме бизнес процесса показатели эффективности, которые тем или иным способом учитываются в системе.

9 – Свяжите полученную схему с другими процессами

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

Связь бизнес процесса с другими процессами

10 – Проверьте полученную модель бизнес процесса

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

• С чего начинается и чем заканчивается бизнес процесс?
• С какими процессами он связан? Чем обменивается?
• Какие операции выполняются? В каком порядке?
• Кто выполняет операции в процессе?
• Какие документы используются и появляются в процессе? В каких операциях эти документы используются/появляются?
• Какие инструменты, материалы, ПО и базы данных используются в процессе и в каких операциях?
• Какие показатели эффективности и где именно фиксируются в бизнес процессе?

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

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

Меня часто спрашивают - что почитать о бизнес-процессах?
Одним из лучших сайтов на просторах рунета является www.klubok.net . Я сам "вырос" на форуме и статьях этого сайта. Многие статьи не потеряли актуальности и сейчас. Начать учиться рекомендую именно с него.

А вот если говорить о книгах - то уверенно могу сказать лучшая книга о бизнес-процессах - это книга, написанная Репиным и Елиферовым: "Бизнес-процессы компании. Построение, анализ, регламентация".

Описание бизнес-процессов: стремление к простоте.

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие.

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

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»).

На схеме рис. 1. Последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов - при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы ни то, и не другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т.п. Но на схеме процесса нужно показывать реальные объекты - процессы, выполняемые людьми, документы, информационные системы и т.п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (рис. 1.) способа использования «ромбиков».

«Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)
«Плюсы»	«Минусы»
Наглядное отображение «логики» выбора тех или иных выходов процесса. Акцентирование внимания исполнителя на точку принятия решения/ветвление процесса в зависимости от условий.	Вынос логики принятия решения «наружу» операции процесса (некорректно с точки зрения формальной декомпозиции процессов). Неудобно документировать процесс (приходится дублировать «ромбики» текстом при формировании текстового описания операции). Схема процесса становится информационной перегруженной. «Ромбики» часто используются слишком формально, без реальной необходимости.

На рис. 2. показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме рис. 1. Схема рис. 2. выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности, эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»).

«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 2., показаны ниже.

В целом, применение схем в формате, подобном представленному на рис. 2, является удобным как для разработчиков, так и для сотрудников, работающих по этим схемам.

На рис. 3. представлена схема процесса, сформированная в нотации «Процедура» среды моделирования Business Studio. Схема имеет несколько особенностей. Во-первых, блоки «Решение» использованы не стандартным образом - не как графический элемент для отображения вопроса и ветвления, а как полноценная операция процесса, связанная с принятием решений. В Business Studio «ромбик» обладает почти всеми атрибутами полноценного процесса, но не может быть декомпозирован (возможно, разработчики системы со временем сделают такую возможность). Использование «ромбика» (вместо четырехугольника) делает схему нагляднее. При этом в атрибуты «ромбика» можно внести любую текстовую информацию: описание, начало, завершение, требование к срокам и т.п.

Второй особенностью схемы процесса, представленной на рис. 3., является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником - стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Но именно в Business Studio можно пользоваться только одним типом стрелок - стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности. Такой подход дает возможность:

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

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

«Плюсы» и «минусы» графического представления процесса в форме, представленной на рис. 3., показаны ниже.

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»).

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на рис. 3.

На рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на рис. 1-3. Трудоемкость формирования такой схемы так же существенно выше.

Схема процесса в нотации ARIS eEPC (построена в Business Studio)
«Плюсы»	«Минусы»
При формировании схемы выдерживается строгая, формальная логика процесса. Четко определены все события, возникающие по ходу процесса.	Сложность восприятия. Значительная трудоемкость формирования схемы. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем. Информационная избыточность. Занимает слишком много места, что неудобно для документирования.

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio).

Описание процесса для целей последующей автоматизации

Интересно посмотреть на рассматриваемую схему процесса в случае, если она описана в нотации BPMN 2.0. Это нотация предназначена для описания «исполняемых» процессов, т.е. процессов которые поддерживает система BPM.

Своим мнением об использовании BPMN 2.0. делится А.А. Белайчук - Генеральный директор компании «Бизнес-консоль»:

На рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на рис.1: в нотации BPMN задачи изображаются прямоугольниками, развилки - ромбами, данные - пиктограммой, похожей на документ. Потоки управления - сплошные линии, потоки данных - пунктирные. Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением - «движком» BPM-системы. В то же время, как показывает данный пример, при использовании ограниченного подмножества палитры BPMN оказывается не сложнее привычной блок-схемы. Ну а тем, кто хочет освоить BPMN профессионально, мы рекомендуем специализированные тренинг www.bpmntraining.ru .

Рис. 5. Схема процесса в нотации BPMN 2.0.

Практика жизни

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

При формировании схемы рис. 6, бизнес-аналитики очевидно, «боролись» за наглядность и максимальную понятность для рядового пользователя. Они стремились свести к минимуму, или вообще отказаться от текстового комментария к схемам процессов. Исполнителям просто печаталась схема формата А3, при чтении которой все сразу становилось понятно: что делать, как, какие документы использовать и т.п.

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

Выводы

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

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

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

В.В. Репин , к.т.н., доцент, Исполнительный директор ООО «BPM Консалтинг Групп », зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru

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