Схема бизнес-процесса (Business Process D iagram) - это представление пошаговых процессов, где схемы обычно создаются как блок-схемы, в которых фигуры представляют этапы процесса, а последовательность этапов обозначается стрелками.

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

Виды схем бизнес-процессов

Схемы разрабатываются с помощью целого ряда различных методик: без символов и диаграмм; с использованием символов и диаграмм; построения в зависимости от приоритетов; графически-описательное представление процессов.

Рисунок 1. Простая блок-схема бизнес-процесса изготовления электромотора.

Рисунок 2. Символы в схемах бизнес-процессов.

Рисунок 3. Простая блок-схема бизнес-процесса с использованием символов.

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

Рисунок 4. Схема построения бизнес-процесса с помощью графов приоритетов

Рисунок 5. Описание рабочего задания на примере одного графов

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

Пример. Схема графически-описательного представления «изготовление заказа 1000 единиц металлических уголков изделий из листовой стали»

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

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

Введение

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

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

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

«Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
«Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
«Процедура» системы Business Studio (один из возможных вариантов представления);
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. Трудоемкость формирования такой схемы так же существенно выше.

В целом, если Вы не собираетесь покупать 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 профессионально, мы рекомендуем специализированные тренинги .

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

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

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

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

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

Выводы

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

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

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

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

- среда общения профессионалов

размещено в разделе:

найти еще статьи

В Части 1 были описаны основные («Функция» и «Событие») и дополнительные элементы нотации eEPC. В этой статье я расскажу, как размещать все элементы на схеме бизнес-процесса. Для этого используются 2 типа линий:

1)Если есть движение ресурсов или информации к функции или от нее, то используется линия со стрелкой.
2)Если движения нет, то остальные элементы связываются между собой обычными линиями.

Посмотрите на рисунок 5. То, что на нем изображено, на реальном примере можно описать следующим образом: специалист отдела продаж по наступлению события «Поступила заявка от клиента» изучает данную заявку. Она подается от клиента на вход данной функции. Затем специалист отдела продаж, согласно «Инструкции по работе с 1С», делает запрос в программу 1С и получает необходимую выписку об остатках товара, указанного в заявке.

Рисунок 5. Использование различных элементов в нотации eEPC и отображение их связи

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

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

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

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

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

Важно. Входы и выходы не должны быть «подвисшими». То есть, входы на схеме должны «откуда-то» поступать, а выходы должны поступать «куда-то». Источниками и получателями входов и выходов могут быть:

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

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

Базы данных (программное обеспечение), в которые заносятся информация путем добавления или изменения записей. Например, функция «Добавить нового клиента в CRM» будет иметь на выходе новую запись в базе данных CRM, содержащую информацию о новом клиенте.

Работник или подразделение компании.

Внешние поставщики и получатели.

Рисунок 6. Примеры «передачи» выходов различным получателям

Оптимизация процесса и обозначение временных рамок

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

Итак, сразу по получении заявки (письма от робота сайта) рекомендуется создавать запись в программе для работы с заказами клиентов. Делать это можно при помощи специального ПО, документов Excel или Access и т.д. В ходе выполнения процесса можно работать с этой записью: добавлять информацию об остатках, уточненную информацию от клиента, возможное время доставки.

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

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

Чтобы увидеть процесс во времени, оценить его длительность и загрузку персонала я рекомендую использовать вот эти решения:
- немного отойти от нотации и, пользуясь возможностями MS Visio или другой программы, наносить надписи с обозначением времени на стрелки;
- в дополнение к блок-схеме в нотации eEPC разрабатывать диаграммы Ганта (это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту), используя программные продукты для управления проектам или делая это вручную в Excel;
- дополнять графическое описание процесса и функции текстовым - например, таблицей с полям. В них указываете такие данные, как наименование функции, описание функции, время ожидания перед выполнением, время выполнения, номер на схеме.

Элементы логики в схемах нотации eEPC

Как и сама нотация, элементы логики довольно просты, но при этом имеют определенные особенности :

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

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

Для каждого элемента возможны различные варианты использования.

Рисунок 7. Элементы логики

Логический элемент «И»

Последовательно разберем все варианты использования элемента «И»

Пример, когда после выполнения функции обязательно возникает несколько событий:

Рисунок 8. По окончании отгрузки товар размещен в кузове автомобиля, а накладные документы подписаны и переданы водителю

Вот ситуация, когда для выполнения функции необходимо наступление нескольких событий:

Рисунок 9. Печать накладных документов начинается тогда, когда счет оплачен и наступило плановое время отгрузки товара

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

Рисунок 10. После подготовки счет-фактуры и договора пакет документов для оформления купли-продажи товара готов

Вариант, когда после наступления события необходимо выполнить несколько функций:

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

Продолжение следует.

Александр Сагалович, www.probusiness.by

Построение блок-схемы (диаграммы) технологического процесса. Технологические схемы, этапы процессов и мероприятия по управлению

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

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

Таким образом, на диаграмме, планах или приложениях к ним должны быть приведены дополнительные сведения:

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

НАССР, здесь нет определенных ограничений и правил. Приведем несколько примеров построения диаграмм.

Рис. 7.4.

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

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

На рис. 7.4 и 7.5 представлены примеры диаграмм технологического процесса производства мороженого в виде блок-схем с использованием модульного подхода.

Рис. 7.5.

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

Ниже приведен перечень самых распространенных и наиболее общих стадий:

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

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

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

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

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