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

Но нужно ли проводить мониторинг каждого процесса? Нужно ли устанавливать показатели для каждого процесса? В какие процессы вкладывать средства?
Нет и еще раз нет. Необходима избирательность. В первую очередь необходимо следить за себестоимостью и затратами на сбор данных. И в первую очередь мониторингу подвергать приоритетные процессы. Как выделить приоритетные процессы и как определить какие из процессов требуют улучшений, какие реинжиниринга и какие лишь только повышенного внимания?При выборе процессов требующих или улучшений, или реинжениринга, или только особого внимания нужно исходить из следующих критериев:
1. Важность процесса:
чем процесс важнее, тем более внимательно нужно следить за ним;
важность процесса определяется важностью его результатов.
–Показатели: и результативность, и эффективность.
2. Результативность процесса – способность процесса отвечать целям, измеряемым удовлетворенностью потребителя процесса.
3. Эффективность процесса – затраты и сроки выполнения.
Критерием выбора является определяющее значение показателейВ отношении важности лучшим судьей по определению является руководство организации. Однако хотя руководство и должно определять приоритетность различных областей деятельности и категорий потребителей или других заинтересованных лиц, в пределах каждого класса потребителей или иных заинтересованных лиц лучше всего судить об относительной важности того, что они получают от организации могут сами потребители или другие заинтересованные лица. Поэтому именно по ним следует измерять степень важности.
! Само собой разумеется, решение по окончательной оценке результатов, в частности, решение об относительной важности различных процессов среди основных процессов корпорации, должно принимать руководство.В отношении показателей судьей всегда должен быть пользователь результатов процесса.
Потребители лучше всего могут судить о пригодности к использованию – и вообще о соответствии ожиданиям – получаемых ими изделий и услуг.
Другие заинтересованные лица (акционеры, руководство, работники, деловые партнеры, общество) также лучше других могут судить о качестве того, что они получают.! Определение относительной важности различных категорий потребителей и других заинтересованных лиц – это вопрос стратегии, а следовательно, лежит на ответственности руководства.
После этого следует привлечь потребителей и других заинтересованных лиц к определению относительной важности каждого элемента ожидаемого качества.Поскольку процессы существуют для того, чтобы создавать качество для потребителей, естественным судьей о сравнительной ценности того, что процессы организации дают, является потребитель:
–внутренний потребитель для вспомогательных процессов;
–внешний потребитель для процессов, направленных на рынок;
–другие заинтересованные лица для процессов, направленных на них.
Другими словами, потребители и другие заинтересованные лица знают факторы, вызывающие удовлетворенность, и как определить их весомость.
! Высшее руководство принимает конечное решение об «утверждении» результатов процесса, в котором потребители и другие заинтересованные лица определяли важность (и дополняет ее тем, что относится к е

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• SIPOC
• Блок-схема процесса
• VSM (карта потока создания ценности)

В этой статье мы разберем особенности применения первых двух инструментов.

SIPOC

Аббревиатура SIPOC расшифровывается как Supplier (поставщик), Input (вход), Process (процесс), Output (выход), Customer (потребитель или заказчик). Уже из расшифровки становится ясным, о чем пойдет речь: этот инструмент дает возможность кратко описать ключевые особенности процесса, не вдаваясь в детали. Своего рода «взгляд с высоты птичьего полета». Поэтому именно с него полезно начать работу по описанию бизнес-процесса.

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

Пример заполнения таблицы SIPOC для процесса «Приемка сырья на склад»:

При заполнении таблицы необходимо обратить внимание на следующие моменты:

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

Блок-схема процесса

Блок-схема – инструмент для более подробного описания бизнес-процесса, чем SIPOC. Помимо входов и выходов, на блок-схеме уже находят отражение межоперационные потоки процесса. Также могут появиться дополнительные операции – при необходимости отразить процесс более подробно. Для создания блок-схемы понадобится собрать дополнительную информацию.

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

Обозначения, используемые на блок-схеме процесса:

Символ	Обозначаемое понятие
	Начало и конец процесса. Может использоваться как овал, так и круг.
	Прямоугольник с прямыми или скругленными углами – операция процесса.
	Ромб – оператор ветвления. Им обозначают операции, в ходе которых нужно сделать выбор, после которого возможно 2 сценария дальнейшего хода процесса.
	Треугольник – этап временного ожидания-складирования
	Стрелка указывает направление хода процесса. Также может использоваться для обозначения межоперационных потоков. В этом случае на стрелке помещают надпись – название объекта, передаваемого от одной операции к другой.
	Параллелограмм – обозначение любого объекта (материального или информационного).
	Прямоугольник с неровной стороной обозначает документ или информацию.

Возможно применение и других символов. Главное, чтобы все участники проекта понимали их содержание.

Блок-схему можно подготовить и в Word, и в Excel. В этих программах есть все необходимые инструменты. Но наиболее удобно рисовать блок-схемы в Microsoft Visio. Как правило, операции процесса располагают вертикально одна под другой. Входы процесса показывают слева (стрелки входов направлены к тем операциям, где эти объекты впервые используются), выходы – справа (стрелки направлены от тех операций, где эти объекты появляются). Поставщики и потребители процесса на блок-схемах, как правило, не отражаются.

Ниже приведены 2 варианта блок-схемы процесса – упрощенный и более подробный.

Упрощенная блок-схема процесса «Приемка сырья на склад»:

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

Подробная блок-схема процесса «Приемка сырья на склад»:

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

Блок-схема процесса «Приемка сырья на склад» со свимлейнами:

Свимлейны могут располагаться на листе как вертикально (см. пример выше), так и горизонтально.

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

Олешко Виктория, бизнес-тренер, консультант, главный редактор сайта сайт. Автор книги “ ” и блога “ ”. Хотите узнать больше об управлении знаниями? Присоединяйтесь к

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

Общая информация

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

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

Функциональный подход

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

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

Процессный подход

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

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

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

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

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

Порядок разработки

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

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

Чему следует уделить внимание?

Следует сконцентрироваться на следующих разделах:

1. Стандартные формы.
2. Карта.
3. Маршруты.
4. Матрицы.
5. Блок-схемы.
6. Описание стыков.
7. Вспомогательные описания.
8. Документирование.
9. Развернутое описание.
10. Определение индикаторов и показателей.
11. Регламент выполнения.

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

О картах замолвим слово

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

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

Матрицы

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

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

Меня часто спрашивают - что почитать о бизнес-процессах?
Одним из лучших сайтов на просторах рунета является 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 страниц регламентов.