Схема бизнеса организации образец. Визуальное моделирование бизнес-процессов

Инструкция

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

Описать бизнес-процесс можно несколькими способами. Наиболее популярный из них - графический, с помощью , выполненных в различных нотациях (нотация - набор символов для обозначения чего-либо).
Самые распространенные виды нотаций для описания бизнес-процессов - это IDEF0, BPMN, EPC (ARIS) и др.
В качестве примера остановимся на диаграмме, выполненной в нотации BPMN (Business Process Modelling Notation) с помощью CASE-средства PowerDesigner (Рис.1). Главными элементами на диаграмме являются:
1. «Процесс» (функция) - скругленный по углам прямоугольник;
2. «Переход» - стрелка, соединяющая процессы;
3. «Решение» - ромб, содержащий вопрос, на который можно ответить только «Да» или «Нет»;
4. Условия - текстовые выражения, при которых осуществляется переход от функции к другой. Условия всегда заключаются в квадратные скобки. Иногда полезно разбить вашу на «Дорожки» - вертикальные или горизонтальные секции, обозначающие подразделения предприятия или сотрудников, ответственных за выполнение определенной функции. В таком случае этой функции должен находиться в пределах своей секции. Кроме перечисленных элементов, может содержать также перечень данных, которые являются входными или выходными для процесса, а также ссылки на правила или регламент, согласно которым выполняется та или иная функция. Пример описания бизнес-процесса «Контроль производства изделия» показан на рис.1. Нетрудно заметить, что эта диаграмма очень похожа на блок-схему алгоритма решения задачи.

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

Полезный совет

Всегда придерживайтесь правил выбранной графической нотации описания бизнес-процессов.

Источники:

• М.Рыбаков. Оптимизация бизнес-процессов.
• как составить бизнес процесс

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

Инструкция

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

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

Личная информация:

Консультировал в области регулярного менеджмента более 70-ти компаний: от 10 до 9.000 человек (включая: холдинги, сети магазинов, фабрики, сервисные компании, строителей, государственных служащих, веб-агентства, интернет-магазины). Ученик Александра Фридмана.

Один из соавторов книги "Социальные технологии Таллиннской школы менеджеров. Опыт успешного использования в бизнесе, менеджменте и частной жизни": http://www.ozon.ru/context/detail/id/140084653/

«Три пути ведут к знанию: путь размышления - это путь самый благородный, путь подражания - это путь самый легкий и путь опыта - это путь самый горький»

Конфуций

кому: собственникам, топ-менеджерам, руководителям

Управление процессами через регламенты приводит к управлению «рукой через ногу»

Я уже неоднократно рассказывал о пользе регламентов, которые решают такие важные задачи для собственников бизнеса и руководителей, как:

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

И редко встречал руководителя, который не считал бы регламенты полезными. Казалось бы, регламент это панацея от всех бед! Но... Попытки “управлять только по регламентам” зачастую терпят неудачу.

Почему? Сейчас попробую объяснить. Регламент - это описание какой-либо части рабочего процесса (последовательности действий), протекающего в компании: либо процесса целиком, либо нескольких процессов, либо части процесса.

Процесс (синоним “бизнес-процесс”) - это последовательность действий для решения какой-либо типовой задачи (нетиповые задачи относятся к проектам).

Процессами эффективно управлять напрямую, а для их формализации - чертить схемы

Процессы делятся на простые и составные. Составные - содержат в себе несколько простых процессов. Ещё бывают сквозные процессы . Так называют процессы, разные этапы которых проходят через несколько отделов компании. В этом обычно и заключается их сложность.

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

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

Почему регламентов недостаточно

• Далеко не все процессы линейные. Многие имеют множество условий “если…, то…”. Сложно быстро разобраться в “полотенце” текста регламента и понять, как этапы процесса связаны между собой . Например, регламент по подбору сотрудников изобилует подобными развилками почти на каждом этапе. В зависимости от должности соискателя собеседование может проходить удалённо или очно, с привлечением его непосредственного руководителя или без.
• Если процесс проходит через несколько звеньев, возникает проблема “кто ответственен за конечный результат”. В случае сбоев и косяков, сотрудники валят вину друг на друга и на обстоятельства, возникает круговая порука.
• Сотрудники не могут договориться между собой о том, кто выполняет какую работу.
• Из-за низкой наглядности (всё тот же гигантский объём текста регламента) крайне непросто заниматься оптимизацией и развитием процесса .
• Значительны затраты времени сотрудников на чтение, изучение, и понимание общей картины и всех взаимосвязей. Регламент редко описывает процесс целиком. Зачастую процессу, проходящему через несколько отделов, соответствуют разные регламенты.

Введение в управление процессами: в каком виде лучше описать процесс?

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

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

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

• Однозначная трактовка схемы участниками процесса.
• Наличие достаточного количества обучающего видео-материала по данной системе обозначений (нотации).
• Перспективы нотации: быстро ли она развивается, насколько используется, будет ли использоваться в дальнейшем или уже “отмирает”

Всем этим критериям, по моему мнению, отвечает нотация BPMN (версия 2.0) . Для отрисовки схем рекомендую использовать бесплатную программу Bizagi Modeler .

И ещё раз про упрощение. Начиная рисовать схемы, вам не обязательно соблюдать стандарт на все 100%, это только усложнит внедрение. На начальных этапах главное, чтобы схемы были понятны участникам и однозначно ими трактовались. Привести схемы в соответствие стандарту вы еще успеете.

Итого, схемы процессов решают следующие задачи:

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

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

Ключевая фишка процессного управления - ответственный за весь процесс

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

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

Ответственный за весь процесс (иногда его называют “владелец процесса”) - это руководитель (или сотрудник), который отвечает за доработки и развитие бизнес-процесса; решение глобальных возникающих коллизий и анализ сбоев; помощь и обучение ответственных за копию процесса.

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

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

За развитие процесса и выполнение всех его копий должен отвечать один человек

Таким образом, есть человек, который несёт ответственность за весь процесс (в том числе и за работу ответственных за копии), а есть люди, отвечающие за выполнение копий. В рамках процессного управления ответственные за копии процесса подчиняются “владельцу процесса”, а ответственным в свою очередь подчиняются участники процесса.

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

Алгоритм описания и развития бизнес-процесса с помощью схем и регламентов

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

Этап 1. Нарисовать и согласовать схему процесса

1. Начертите схему процесса совместно с ответственным за развитие процесса и экспертами из числа ответственных за исполнение конкретных копий процесса. Выделите наиболее критичные точки процесса. У каждого процесса и у каждого этапа на схеме есть “вход” и есть “выход”. При написании регламента учтите, что будет подаваться на вход, а что будет результатом работы.
2. Согласуйте схему со всеми участниками процесса или начальниками подразделений участников.

Пример №1. Схема процесса “Подбор сотрудников” в нотации BPMN

Пример №2. Часть схемы “Подбор сотрудников” в нотации BPMN

Этап 2. Написать регламент выполнения этапов процесса

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

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

Этап 3. Запустить управление процессом

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

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

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

Этап 4. Развивайте и оптимизируйте процесс с целью роста эффективности и качества

Как я уже упоминал, за развитие процесса должен отвечать его “владелец” (обращаю внимание, что это не из разряда “хочу/не хочу”, а почётная обязанность сотрудника).

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

Здесь важно вести перечень схем, для которых настроены автоматизированные бизнес-процессы, сделаны чек-листы и есть регламенты (возможно для этого пригодится отдельная таблица или специальная область в начале регламента). Это поможет “владельцу процесса” синхронизировать изменения на всех уровнях , а также выполнять их без избыточных действий.

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

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

Заключение, или Почему «всё и сразу» - это путь на кладбище проектов

Про процессы можно рассказывать много, хватит на целую книгу. Но… кладбища мёртвых проектов заполнены попытками внедрить “всё и сразу” и на самом дорогом и/или многофункциональном программном обеспечении. В лучшем случае сотрудники не использовали внедрённые технологии, или системы получались настолько громоздкими, что работать с ними было невозможно. В худшем - сложности при внедрении так и не позволили завершить работу до конца.

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

Читавшие эту статью, также читали

Время «Ч»: Когда внедрение регулярного менеджмента в вашей компании неизбежно, а оттягивание старта лишь принесёт дополнительные убытки

Сайт производителя товаров и оборудования: 10 типовых ошибок, которые препятствуют поиску новых дилеров и оптовиков

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

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

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

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

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

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

Такой подход дает возможность:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

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

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

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

Рис. 6. Примеры схемы процесса одной из компаний

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

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

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

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Ковалев Сергей Михайлович
Ковалев Валерий Михайлович
(Журнал "Консультант директора", № 12, Июнь, 2004 г.)

Семь "золотых" правил описания бизнес-процессов

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

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

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

Правило 1. Составляйте, уточняйте, подтверждайте схемы вместе с "владельцами"/"участниками" бизнес-процессов.

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

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

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

Правило 3. Используйте язык, понятный "владельцам"/"участникам" бизнес-процесса.

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

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

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

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

Правило 5. Избегайте излишней детализации бизнес-процессов, особенно на схеме "как есть".

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

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

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

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

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

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

Правило 7. Не смешивайте понятия "как есть", " как должно быть", "как будет".

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

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

Почему хорошая формализация бизнес-процесса важна?

1. Она позволяет сделать наши мысли предметом широкого обсуждения.
2. Она дает возможность донести новые правила работы до тех сотрудников, которые будут их выполнять.
3. Формализованные бизнес-процессы легче изменять и модернизировать.
4. Формализация бизнес-процессов является хорошей основой для последующей автоматизации бизнеса в компании: создания/настройки различных информационных систем и стандартных пакетов автоматизации.

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

Пример бизнес-процесса

В качестве примера я взял крупный магазин по торговле мебелью и его бизнес-процесс "Покупка клиентом товара". На рис. 9.1 представлена диаграмма этого бизнес-процесса в нотации BPMN , с комментариями по нотации.

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

Выделим следующие действия бизнес-процесса.

1. "Оформление заказа". Сначала клиент оформляет заказ. Предполагается, что перед этим он определился в главном - что ему нужно. Например, кухонный гарнитур. Тогда в отделе по торговле кухонной мебелью он, вместе с одним из менеджеров этого отдела, составляет дизайн-проект для своей покупки (в соответствии с размерами его кухни и своими пожеланиями), уточняет параметры своего заказа и точно определяется с комплектующими и материалами.
2. "Получение товаров". Клиент идет на склад и сам выбирает все составные части своего заказа, имея точный перечень того, что ему нужно. При этом ему помогают работники склада.
3. "Оплата товаров и оформление доставки". Клиент вместе со своими выбранными товарами (он везет их на тележке) следует к кассе и оплачивает то, что он выбрал. Далее, с оплаченными товарами, он переходит в отдел доставки, где оформляет и оплачивает доставку своей мебели, а также ее сборку (если ему это нужно); после этого он уезжает домой.
4. "Доставка". Оплаченные товары клиенту доставляют в течение трех дней.
5. "Сборка". После этого, если клиент оформил сборку, то к нему приезжает мастер-сборщик и собирает доставленную мебель.

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

Декомпозиция бизнес-процессов

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