«Процессный подхо I к управлению Моделирование бизнес-процессов Издательство Манн, Иванов и Фербер Москва, 2013 УДК 658.512 ЫЖ 65.291.216 Р41 Репин В. В., Елиферов В. Г. Р41 Процессный подход к управлению. Моделирование ...»

— отсутствие «лидерства руководителя», прямо прописанного в восьми принципах менеджмента качества ИСО 9000:2005;

— отсутствие команды управленцев верхнего уровня, заинтере­ сованности и участия руководства;

— некорректная постановка целей проекта, непонимание сути и реальных возможностей процессного подхода;

— попытки решить проблемы управления силами рабочей груп­ пы без участия руководителей и менеджеров организации;

— отсутствие внутренних стандартов на описание и регламен­ тацию бизнес-процессов;

— неэффективное применение инструмента моделирования бизнес-процессов;

— оторванность от проекта среднего звена управления;

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

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

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

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

Вторая важнейшая проблема — некорректная постановка целей проекта. Очень часто вследствие искаженного понимания основ процессного подхода от рабочей группы требуют таких результатов, для достижения которых не хватает либо времени, либо ресурсов, либо заинтересованности руководства. Например, часто требуется подробное описание бизнес-процессов и их оптимизация. При этом мало кто из руководителей представляет, с каким объемом форма­ лизованной информации (модели бизнес-процессов) придется иметь дело через три-четыре месяца после начала работ и как эту инфор­ мацию реально использовать. Начиная работу по описанию биз­ нес-процессов, сотрудники часто очень смутно представляют, как дальше эти модели будут использованы для реальной работы. Как показывает практика, попытки детально описать и реорганизовать процессы организации редко оказываются успешными. Кроме того, если в работу по реорганизации процессов не вовлечены руководи­ тели и сотрудники, которые их выполняют, то она обречена на неуда­ чу на 80-90%.

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

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

В одной из западных работ, анализирующих опыт применения технологий реинжиниринга бизнес-процессов [4], приводится при­ мерно следующая схема (рис. 1.18).

По нашим оценкам, большинство проектов по реорганизации бизнес-процессов в российских организациях не выходит за пределы третьего этапа, показанного на рис. 1.18. Типовой сценарий развития событий в общих чертах следующий: ставятся «правильные» цели, инициируется проект (этап 1 на схеме), создается описание бизнеспроцессов (этап 2), осуществляются попытки провести их анализ и приступить к реорганизации (этап 3). Большинство организаций испытывает значительные трудности именно на третьем этапе, ког­ да необходимо получить определенные результаты. Не получив бы­ стрых, измеримых результатов, ощущая необходимость длитель­ ной, кропотливой работы, руководство организаций сворачивает работы по проекту. Начинается поиск очередных «модных подходов к управлению», способных «повысить» конкурентоспособность ор­ ганизации (например, системы CRM или BPMS). Обратим внимание, Глава l. Процессный подход к управлению что последний, шестой уровень соответствует процессной системе управления, наличию системы непрерывного улучшения процессов, ориентации на клиента, а главное — новой культуре и философии управления.

Рис. 1.18. Уровни развития проекта реинжиниринга бизнес-процессов 6. Непрерывное улучшение процессов ' Барьер информационных (Continuous Process Improvement — CPI) технологий 1.8. Состав этапов типового проекта моделирования и реорганизации бизнес-процессов организации В заключение главы кратко остановимся на составе этапов типового проекта реорганизации бизнес-процессов организации, поскольку такой подход получил достаточно широкую известность.

Типовой проект реорганизации бизнес-процессов включает сле­ дующие этапы:

Этап 1. Подготовительный.

Этап 2. Моделирование и анализ бизнес-процессов «как есть».

Этап 3. Моделирование бизнес-процессов «как должно быть».

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

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

— диагностику проблем организации;

— определение основных бизнес-процессов (сети процессов);

— определение и ранжирование целей проекта;

— выбор (разработку) и утверждение методики ведения про­ екта, включая методику моделирования бизнес-процессов, структуру регламента выполнения бизнес-процесса и другие — подготовку программного и аппаратного обеспечения;

— формирование рабочих групп;

— методическую подготовку — обучение руководителей и спе­ циалистов организации;

— информирование персонала о задачах проекта;

— детальное планирование работ.

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

На втором этапе проекта выполняются моделирование и анализ бизнес-процессов. Этап 2 включает следующие работы:

— создание моделей организационной структуры;

— создание вспомогательных моделей (деревьев функций, доку­ ментов, материальных ресурсов и т. д.);

— разработку моделей бизнес-процессов верхнего уровня;

— проверку адекватности моделей верхнего уровня;

Глава 1. Процессный подход к управлению — разработку моделей детальных бизнес-процессов (несколько уровней декомпозиции);

— проверку адекватности детальных моделей;

— создание моделей документов, данных и т. д.;

— проведение анализа моделей;

— формирование отчетов.

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

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

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

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

В то же время следует отметить, что если мы рассматриваем от­ дельно взятый простейший бизнес-процесс, то создавать для него модель «как должно быть» вполне допустимо. Например, процесс за­ грузки автомобиля клиента на складе готовой продукции, процесс * Методика расчета стоимости изделий путем анализа стоимости операций.

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

— выбор приоритетных направлений реорганизации процесса;

— разработка критериев оценки эффективности перспективно­ — обсуждение конкретных мер повышения эффективности про­ — формирование нескольких вариантов моделей бизнеспроцесса «как должно быть»;

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

С другой стороны, если мы рассмотрим деятельность организа­ ции на очень высоком уровне (когда в модели всего 6-8 объектов, обозначающих различные работы), то такая модель становится обо­ зримой. В этом случае можно говорить о реорганизации данной мо­ дели и ее экономическом обосновании. К сожалению, осмысленных изменений на верхнем уровне может не оказаться. Например, на ме­ таллургическом комбинате сначала нужно выплавить сталь, а уже потом изготовить прокат, но не наоборот. Складывается следующая ситуация. Пока мы находимся на высоком уровне рассмотрения, все изменения кажутся нам тривиальными и ненужными. Как только мы переходим к детальным бизнес-процессам, резко возрастает объем информации, снижается эффективность ее анализа, становится Глава 1. Процессный подход к управлению невозможным корректное обоснование решений по реорганизации бизнес-процессов организации. Что делать в этой ситуации? Созда­ вать в организации такую систему управления, которая сама приве­ ла бы к постоянному улучшению процессов (см. главы 3 и 4), то есть внедрять систему управления, основанную на процессном подходе.

Очевидно, что в случае построения процессной системы управ­ ления этап 3 не должен отдельно выделяться — он объединяется с этапом 4.

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

Затем совершается собственно реорганизация бизнес-процессов, при этом могут выполняться следующие работы:

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

процессной системы управления;

— оперативный контроль выполнения плана;

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

— корректировка моделей бизнес-процессов на основе практи­ — изменения организационной структуры, должностных обя­ занностей исполнителей;

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

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

Методика внедрения в организации процессного подхода к управ­ лению подробно рассмотрена в главе 4. Для тех организаций, которые не готовы использовать комплексный подход к изменению системы управления, но хотят описать и реорганизовать отдельные процессы, методика выполнения работ подробно изложена в главе 3.

Подведем итоги главы 1. Что же необходимо для успешного вне­ дрения процессного подхода к управлению в вашей организации?

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

— проникнуться философией процессного управления;

— освоить основные положения стандартов ИСО серии 9000;

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

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

Глава 1. Процессный подход к управлению 1.9. Список литературы 1. Процессный подход // Серия «Все о качестве. Зарубежный опыт». — М.:

НТК «Трек», 2000.

2. Р 50.1.028-2001 Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования.

3. Лоуренс II. Принцип Питера, или Почему дела идут вкривь и вкось. — М.: Зксмо-Пресс, 2002.

4. Mayer R., deWitte Р. Delivering Results: Evolving BPR from Art to Engineering.

URE: www.idef.com 5. PIPS 183 США Integration definition for function modeling (IDET0).

6. Хаммер M., Чампи Д. Реинжиниринг корпорации. Манифест революции в бизнесе. — М.: Мани, Иванов и Фербер, 2007.

7. Хаммер М., Хершман Л. Быстрее, лучше, дешевле. Девять методов реин­ жиниринга бизнес-процессов. — М.: Альпина Паблишер, 2012.

8. Деминг О. Выход из кризиса. Новая парадигма управления людьми, си­ стемами и процессам. — М. : Альпина Бизнес Букс ; Альпина Паблишерз, 2009.

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

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

Подробная структура любого метода, используемого для создания моделей процессов, представлена на рис. 2.1 [1].

Каждый метод предоставляет пользователю определенный язык описания объектов реального мира при помощи специально раз­ работанного синтаксиса, использующего ряд графических симво­ лов. Эти графические символы отражают реальные объекты и связи между ними. Каждый метод предлагает свой способ описания дея­ тельности организации. Поскольку любая организация представляет собой сложную, многогранную систему, то не существует какого-то одного выделенного метода, при помощи которого можно было бы полно описать организацию. Поэтому часто споры о том, какой метод Глава 2. Выбор методологии описания бизнес-процессов лучше, лишены смысла. Выбор подходящего метода описания зави­ сит от целей, поставленных перед аналитиком, создающим модель организации. Например, для описания управления деятельностью организации на верхнем уровне было бы неправильно использовать метод Work Flow или Data Flow и, наоборот, для описания рабочих процессов нецелесообразно применять стандарт IDEF0.

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

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

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

2.2. Понятие объекта и связи «Система — набор объектов, имеющих данные свойства, и на­ бор связей между объектами и их свойствами» [16].

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

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

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

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

При помощи объектов модели и связей реальная деятель­ ность организации представляется в виде описания, как показано на рис. 2.2.

Рис. 2.2. Представление деятельности организации в виде модели Бывают и более сложные ситуации (стандарт IОЕБО), когда объект одновременно служит для описания некоторой сущности реального 74 Процессный подход к управлению. Моделирование бизнес-процессов мира и в то же время указывает на использование его другим объ­ ектом, то есть, по сути, отражает связь объектов.

Каждый объект и связь обладают рядом параметров, или, как принято говорить, атрибутов, отражающих определенные характе­ ристики реального объекта (рис. 2.3).

Рис. 2.3. Атрибуты объекта модели Состав атрибутов зависит от типа объекта модели, точнее от типа отображаемого при помощи модели реального объекта организации.

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

На практике при создании моделей организации описание атри­ бутов объектов модели осуществляется при помощи специальных опций инструментальных средств моделирования бизнес-процессов, что дает возможность сделать из простейшего описания бизнеспроцесса более сложную модель для проведения определенных вы­ числений, анализа, оценки процесса. На рис. 2.4 показан пример Глава 2. Выбор методологии описания бизнес-процессов атрибутов объекта типа «процесс» («2.1. Приемка») в среде модели­ рования Business Studio.

Рис. 2.4. Атрибуты процесса в среде моделирования Business Studio Содержание деяте пьнсстн; установление факт ичвекопо количества, качества н комплектности Нага выполнения Назначение регламенте ПрОЦвН Паспорт регламенте:

Периодичность выполнения:

Субъекты Формы документов | Цвлл по процессу | Те Субъект t Тип связи Начальник смены Связи, используемые в моделях процессов, также играют важ­ нейшую роль. С их помощью удается описать взаимодействие между объектами модели. Связи, выраженные специальными условными обозначениями (стрелками), делают схему процесса информативной.

Следует отметить, что в зависимости от смысла связи одна и та же мо­ дель может описывать совершенно разные практические ситуации.

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

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

2.3. Основные методологии описания процессов В настоящее время для описания бизнес-процессов используется не­ сколько методологий. К числу наиболее распространенных относят­ ся методологии создания моделей структурного типа, методологии описания потоков работ (Work Flow*) и методологии описания по­ токов данных (Data Flow Modeling).

Давно известная и широко используемая методология струк­ турного описания бизнес-процессов — стандарт США 1DEF0. Под­ ход IDEF0 разработан на основе методологии структурного анализа и проектирования SADT в 1963 году. С момента разработки стандарт не претерпел существенных изменений. В настоящее время разви­ тие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов — программных продуктов для моделирования бизнес-процессов (например, Casewise, Business Studio** и т. д.). Мето­ дология IDEF0 предоставляет аналитику прекрасные возможности ** Далее по тексту Casewise - CW, Business Studio - BS.

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

Вторая важнейшая методология описания процессов — Work Flow Modeling*. Существует несколько методологий, в которых можно фор­ мировать модели типа Work Flow. Одна из первых методологий тако­ го типа — IDEF3 — предназначена для описания рабочих процессов, или, иными словами, потоков работ. Методология описания IDEF очень близка к алгоритмическим методам построения схем процес­ сов и стандартным средствам построения блок-схем (см., например, построение блок-схемы в программе MS Word). Следует отметить, что спецификация 1DEF3 включает два существенно различающихся метода описания процессов. В данной книге мы рассмотрим получив­ ший наибольшее распространение метод. Основа методологии IDEF состоит в построении моделей процессов по принципу последова­ тельно выполняемых во времени работ (функций, операций). Можно обоснованно утверждать, что принципы, заложенные в IDEF3, лежат в основе многих современных подходов к созданию моделей типа Work Flow, в том числе методологий ARIS еЕРС и BPMN (Business Process Model and Notation — нотация и модель бизнес-процессов).

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

Еще одна группа методологий, активно используемых на прак­ тике, — нотация DFD (Data Flow Diagramming). Эта нотация * Моделирование потоков работ.

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

Одна из современных методологий описания процессов — ARIS (Architecture of Integrated Information Systems — архитектура интегри­ рованных информационных систем). Методология была разработа­ на немецкой компанией IDS Scheer AG. Основа методологии состоит в том, что любая организация рассматривается как сложная систе­ ма, описание которой строится из четырех основных групп моделей:

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

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

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

По сути, данная нотация действительно является расширением ме­ тодологии IDEF3 за счет использования понятия «событие» (Event).

Кроме нотации еЕРС, ARIS предоставляет аналитику и другие сред­ ства описания процессов организации. Сегодня аналогичными воз­ можностями обладают программные продукты Casewise и Business Studio. Даже в MS Visio достаточно много возможностей для созда­ ния моделей бизнес-процессов.

Глава 2. Выбор методологии описания бизнес-процессов Отметим, что в последние годы существенное развитие получила методология ВРМЫ. Есть все основания полагать, что со временем она вытеснит нотацию АШЭ еЕРС с рынка, так как все больше про­ граммных продуктов позволяют не только автоматизировать про­ цессы с использованием нотации ВР1УШ, но и разрабатывать ком­ плексную систему процессов организации.

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

В заключение краткого описания существующих методологий следует отметить, что бизнес-процессы предприятия могут быть описаны при помощи стандартных блок-схем. По сути, блок-схемы основаны на методологии нотации ШЕИЗ, но при этом они содер­ жат некоторые дополнительные специальные графические объекты.

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

Сводная информация по основным существующим методологи­ ям представлена на рис. 2.5.

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

2.4. Методология IDEF В разделе 2.4 будут рассмотрены основные практически важные аспекты использования нотации IDEF0 для описания бизнеспроцессов предприятия. Более полная информация содержится в стандарте IDEF0, а также в SADT [2; 3; 5].

Некоторые специалисты считают, что стандарт IDEF0 устарел.

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

2.4.1. Объекты и связи в IDEF Основной объект диаграммы процессов в нотации IDEF0 — объект Activity. Графически он представляет собой четырехугольник.

Объект служит для описания функций, выполняемых в организа­ ции (рис. 2.6). Напомним, что каждую функцию (процедуру, работу) можно рассматривать в качестве некоторого процесса. На верхнем уровне каждый процесс может быть представлен как «черный ящик», преобразующий входящие ресурсы в исходящие. Такое определение фактически совпадает с определением процесса, заложенным в стан­ дарте ИСО 9000:2005.

Вторая основная составляющая стандарта IDEF0 — связи, ото­ бражаемые стрелками (рис. 2.6). На диаграмме процесса в IDEF стрелки, входящие в левую сторону функции, служат для описа­ ния потоков материальных ресурсов или потоков информации, до­ кументов.

Глава 2. Выбор методологии описания бизнес-процессов Рис. 2.6. Формирование модели бизнес-процесса. Шаг Материальные ресурсы (вход) Информация Входящие ресурсы преобразуются функцией (работой, процес­ сом). Результатом этого преобразования являются материальные выходы или информация, которые показываются в виде стрелок, вы­ ходящих из правой стороны четырехугольника.

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

Что еще необходимо показать на диаграмме, чтобы можно было описать реальный процесс организации? Следует отобразить управ­ ляющие воздействия, которые определяют порядок выполнения работы, управляют ею. К ним относятся, например, распоряжения руководителя, нормативные документы, ГОСТы, ОСТы, ТУ и т. д.

Управляющие воздействия показываются на диаграмме стрелками сверху. Любое управляющее воздействие существует в виде опреде­ ленной информации, поэтому стрелки сверху в нотации ШЕИО озна­ чают управляющие информационные потоки.

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

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

Отметим, что не во всех современных программных продуктах стандарт ЮЕРО реализован со стопроцентным соответствием. Од­ нако это не препятствует его практическому применению.

Итак, рис. 2.6 показывает основные принципы построения диа­ граммы в ЮЕРО. На первый взгляд все очень просто. Однако с мо­ мента появления нотации (в виде методологии БАОТ) в начале 70-х годов XX века более удачных способов описания процессов органи­ зации на верхнем уровне предложено не было. В чем же сила этого представления? Важнейшая особенность ЮЕРО — возможность ото­ бражения управляющих воздействий, или, если обобщить, возмож­ ность описания управления процессами организации. Заметим, что в соответствии с требованиями этого стандарта для каждой функ­ ции на диаграмме должно быть показано хотя бы одно управляющее воздействие. Это означает, что никакая функция без управления вы­ полняться не может.

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

Для понимания принципов моделирования в ЮЕРО рассмотрим пример построения простейшей диаграммы процесса.

2.4.2.Обратные связи по управлению и информации возможность отражения реального процесса Начнем описание процесса с того, что поместим на диаграмму три функции, как показано на рис. 2.7. Первую назовем «Планировать деятельность», вторую — «Осуществлять деятельность и вести Глава 2. Выбор методологии описания бизнес-процессов регистрацию фактической информации», третью — «Анализиро­ вать, контролировать и управлять деятельностью». Обратите внима­ ние, что для наименования функций могут быть использованы толь­ ко глаголы или отглагольные существительные. Это одно из базовых требований нотации. Было бы, например, неправильно называть объект «Начальник коммерческого отдела» или «Отдел закупок».

Рис. 2.7. Формирование модели бизнес-процесса. Шаг

ДСЯТОЛЬНОСТЬ

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

Объекты на диаграмме расположены в шахматном порядке, или в так называемом порядке доминирования [3]. Важно отметить, что 84 Процессный подход к управлению. Моделирование бизнес-процессов этот порядок удобен на практике и не следует по возможности от него отступать. Следует также подчеркнуть, что расположение объектов на диаграмме может не соответствовать реальной последовательно­ сти выполнения функций. Дело в том, что модели IDEF0 предназна­ чены именно для описания процессов с точки зрения управления, а любые процессы управления системами цикличны.

Рассмотрим рис. 2.8. Представим себе, что функцию планирова­ ния выполняет коммерческий отдел (КО), который использует при этом средство автоматизации MS Excel. Для планирования КО при­ меняет информацию о рынке (прайс-листы и т. д.) и заявки клиентов.

Регламентируется деятельность КО «Регламентом планирования», «Планом организации на год». Результат работы КО — «План отгруз­ ки ГП» (готовой продукции). Посмотрим, как эта информация будет отображена на диаграмме.

Рис. 2.8. Формирование модели бизнес-процесса. ШагЗ Инфоруация полняют производственный отдел (ПрО) и цех. Для выполнения Глава 2. Выбор методологии описания бизнес-процессов работ требуются сырье и материалы. Работы регламентируются нор­ мативами на расход сырья, ГОСТами, ОСТами, ТУ, требованиями клиента. Для работы оборудования в цехе требуется АСУ ТП, для производства продукции — станки и прочее оборудование, то есть основные средства.

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

Рис. 2.9. Формирование модели бизнес-процесса. Шаг Нам осталось показать входы и выходы функции «Анализиро­ вать, контролировать и управлять деятельностью». Кто должен ее выполнять? Для нашего примера будем считать, что контролирует работу тот, кто ее планирует, то есть КО. Подчеркнем еще раз, что мы 86 Процессный подход к управлению. Моделирование бизнес-процессов рассматриваем условный пример. Более сложные и реальные приме­ ры приведены в главе 3.

В своей работе по анализу и контролю КО руководствуется ре­ гламентом анализа и контроля. Не стоит забывать и о годовом плане работы организации в целом. Для работы КО использует MS Excel.

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

Результат работы КО — отчет для руководства организации «План/факт», как показано на рис. 2.10.

Рис. 2.10. Формирование модели бизнес-процесса. Шаг Глава 2. Выбор методологии описания бизнес-процессов Вы заметили, что стрелка, изображающая КО (как и Excel), не по­ вторяется на диаграмме дважды? Она ветвится. Ветвление стрелок — прекрасный инструмент, позволяющий сделать диаграмму процесса более наглядной.

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

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

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

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

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

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

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

На рис. 2.11 представлены обе рассмотренные нами обратные связи — по информации и управлению.

Рис. 2.11. Формирование модели бизнес-процесса. Шаг На рис. 2.10 мы добавили еще одно ветвление стрелки «План отгрузки ГП». Дело в том, что данная стрелка может являться одновременно и информационным входом, и входом по управ­ Рассмотренный пример показывает, что при формировании мо­ делей процессов в ШЕРО можно (и нужно!) эффективно использо­ вать стрелки, отображающие обратные связи по управлению и ин­ формации.

Глава 2. Выбор методологии описания бизнес-процессов 2.4.3. Некоторые правила ветвления и слияния стрелок В предыдущем примере несколько раз нам приходилось иметь дело с ветвлением стрелок. Стрелки могут также сливаться. Подробно правила ветвления и слияния стрелок описаны в стандарте ШЕЕО.

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

На рис. 2.12 показаны ситуации правильного и неправильного наименования стрелок при ветвлении и слиянии.

Рис. 2.12. Правила ветвления и слияния стрелок Ветвление стрелок в ситуации 1 означает, что поток ресурсов А содержит в себе потоки Б и С. Например план продаж может вклю­ чать в себя план по отгрузке в натуральном выражении и план от­ грузки в стоимостном выражении.

Ветвление стрелок в ситуации 2 недопустимо, так как оно озна­ чало бы, что поток А содержит в себе одновременно и А, и Б, что некорректно.

Аналогично можно рассмотреть ситуации слияния стрелок 3 и 4.

90 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 2.13 показывает, как можно пользоваться механизмом вет­ вления и слияния стрелок при построении диаграммы процессов в ЮЕЕО. Стрелка, входящая на диаграмму процесса, ветвится на не­ сколько других, отражающих более детально поток ресурсов или информации. Исходящие стрелки сливаются, показывая, как фор­ мируется результат выполнения процесса в целом. Сказанное спра­ ведливо также для стрелок сверху — управляющих воздействий, и стрелок снизу — механизмов (персонал, инфраструктура).

Таким образом, ветвление и слияние стрелок позволяет показы­ вать потоки ресурсов и информации сначала укрупненно, что важно для описания процессов на верхнем уровне, а затем более детально — для диаграмм процессов нижнего уровня. Указанный механизм эф­ фективно используется при построении диаграмм ШЕРО при деком­ позиции моделей бизнес-процессов.

Рис. 2.13. Пример ветвления и слияния стрелок Ветвление и слияние стрелок — важнейший инструмент для соз­ дания моделей в ШЕЕО. Особенно наглядным этот факт становится Глава 2. Выбор методологии описания бизнес-процессов при осуществлении декомпозиции моделей процессов с верхнего уровня на нижний.

2.4.4. Миграция и туннелирование стрелок, принципы декомпозиции в ГОЕРО Важнейшее понятие нотации ШЕЕО — «туннелирование стрелок».

Выполним декомпозицию функции «Осуществлять деятельность»

(см. рис. 2.14). На более детальном уровне она включает в себя сле­ дующие функции (работы):

— «Разрабатывать график производства».

— «Выполнять подготовку производства».

— «Изготавливать продукцию».

— «Хранить готовую продукцию на складе».

— «Отгружать готовую продукцию клиенту».

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

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

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

Теперь необходимо подвязать каждую из показанных на рис. 2. стрелок к соответствующему объекту — функции.

«План отгрузки ГП» подвязываем к функции «Разрабатывать гра­ фик производства». К ней же сверху подводим «Требования клиента»

и «План отгрузки ГП», но уже в виде управляющего воздействия. Вы­ ходом первой функции являются управляющее воздействие «График производства» и информационный поток «Данные графика произ­ водства».

Входящая стрелка «Сырье и материалы» ветвится на две стрелки:

«Вспомогательное сырье» и «Основное сырье и материалы».

92 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 2.14. Формирование модели бизнес-процесса. Шаг отгрузки ГП Выходом второй функции процесса («Выполнять подготовку про­ изводства») являются «Данные по готовности оборудования».

Третья функция процесса «Изготавливать продукцию» исполь­ зует входящие материальные ресурсы — «Основное сырье и матери­ алы» и информацию — «Данные графика производства» и «Данные по готовности оборудования». Выходами третьей функции являются «Данные по производству ГП», «ГП на склад» (готовая продукция, от­ гружаемая на склад) и «Брак». Обратите внимание, что выход «Брак»

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

цию на складе» формирует выходы «Данные по запасам ГП»

Глава 2. Выбор методологии описания бизнес-процессов и «ГП на складе». При ее описании, однако, пришлось дополнительно ввести в рассмотрение и отобразить в виде стрелок исполнителя — «Склад ГП» и управляющий вход «Условия хранения ГП на складе».

Все четыре новых входа, которые отсутствовали на диаграмме верхнего уровня и появились на рис. 2.15, выделены жирным шриф­ том. Начало стрелки «Условия хранения ГП на складе» заключено в квадратные скобки. Это условное обозначение появляется, когда мы показываем новую стрелку, которой нет на диаграмме верхнего уровня. Для стрелок, входящих в диаграмму процесса, квадратные скобки указываются в начале стрелки. Для новых стрелок, являю­ щихся исходящими, квадратные скобки указываются в конце, как, например, для стрелки «Отчет по состоянию склада».

Рис. 2.15. Формирование модели бизнес-процесса. Шаг План отгрузки ГП Разрабатывать Граоик произ юдства Производственный отдел Квадратные скобки означают, что нарушена нотация описания процесса. Чтобы устранить возникшее противоречие с нотацией, необходимо либо сделать стрелку туннельной, либо разрешить ее миграцию на диаграмму верхнего уровня. Так, например, стрелка 94 Процессный подход к управлению. Моделирование бизнес-процессов «Брак» туннельная. Она не отображается на диаграмме верхнего уровня, а будет видна только на текущей диаграмме. Туннельные стрелки обозначены круглыми скобками.

В случае со стрелкой «Склад ГП» ситуация другая — мы разре­ шили противоречие с нотацией, устранив квадратные скобки и обе­ спечив миграцию этой стрелки на диаграмму верхнего уровня.

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

Следует отметить, что туннелирование стрелок обычно исполь­ зуют одновременно с ветвлением, что обеспечивает связность и про­ зрачность диаграмм процессов без излишнего усложнения. Вместе с тем механизмом туннелирования стрелок следует пользоваться очень аккуратно, так как при туннелировании поток возникает ни­ откуда или уходит в никуда, то есть легко потерять или забыть зна­ чимую для всей модели информацию. Более подробно ознакомиться с правилами туннелирования стрелок можно в книге [3].

2.4.5. Нумерация объектов на диаграммах Каждый объект (функция, работа) на диаграмме процесса в нотации ШЕБО может быть пронумерован. Существует несколько способов нумерации. Мы рассмотрим наиболее простой и часто применяе­ мый. На рис. 2.16 представлено дерево функций процесса, разрабо­ танного нами выше (рис. 2.11, 2.15).

Как видно на рис. 2.16, нумерация диаграмм идет сверху вниз — от диаграммы верхнего уровня к диаграммам нижнего уровня. Каж­ дая диаграмма нижнего уровня получает свой номер на основе номе­ ра родительской диаграммы верхнего уровня. Например, функция «Осуществлять деятельность...» имеет номер А2, а функции процес­ са более низкого уровня имеют номера А21-А25. Если мы декомпози­ руем функцию А22, то функции более детального процесса получат Глава 2. Выбор методологии onucaiiun бизнес-процессов номера А221-А22К Буквенный индекс «А» вводится условно. (Более детальную информацию о правилах нумерации функций в моделях см. [3; 5].) Использование рассмотренного механизма нумерации делает отслеживание функций процессов достаточно наглядным.

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

Рис. 2.16. Диаграмма дерева узлов 2.4.6. Оформление схем моделей в IDEF0, рамка IDEF На рис. 2.17 представлена диаграмма процесса, заключенная в так называемую рамку IDEF0. Вверху и внизу чертежа расположено не­ сколько полей для отображения информации о диаграмме процесса.

Рассмотрим сначала верхние поля диаграммы.

Поле USED АТ используется для указания ссылок на другие места модели (другие диаграммы), в которых идет ссылка на данную диа­ грамму.

Группа полей Author, Project, Date, Rev служит для указания ав­ тора диаграммы, наименования проекта, по ходу которого она была создана, дат создания и даты последнего пересмотра.

Рис. 2.17. Рамка ШЕРО Глава 2. Выбор методологии описания бизнес-процессов Поле Notes используется при проверке модели экспертом. Поря­ док работы в этом случае следующий. Автор диаграммы передает ее эксперту, со слов которого построено описание процесса. Эксперт читает диаграмму и в случае несогласия со схемой процесса делает свои замечания письменно, непосредственно на диаграмме. Каждое замечание должно быть пронумеровано. При указании замечания эксперт обводит его порядковый номер в поле Notes. Такой порядок разработан для того, чтобы автор модели — аналитик мог устранить все замечания, четко контролируя их количество. Количество ис­ правлений должно соответствовать количеству замечаний.

Далее идут поля статуса диаграммы: Working, Draft и т. д. Для каждого такого поля указывается дата и ставится подпись лица, уполномоченного менять статус диаграммы. Диаграммы, находящи­ еся в работе, получают статус Working. Диаграммы, утвержденные и являющиеся обязательными для исполнения, могут получить, на­ пример, статус Publication.

В поле Context указывается номер диаграммы верхнего уровня, содержащей рассматриваемый на данной диаграмме процесс в виде одной функции. Кроме того, в этом поле графически показано по­ ложение данного процесса среди функций диаграммы верхнего уровня.

Рассмотрим теперь поля, находящиеся в нижней части рамки диаграммы IDEF0.

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

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

Последние поля — Number и поле без названия. Первое поле слу­ жит для присвоения диаграмме уникального номера, второе — для указания номера ее листа с диаграммой в подшивке документов (то есть для формирования отчета, содержащего несколько диаграмм).

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

Приводимые в ней данные однозначно определяют положение 98 Процессный подход к управлению. Моделирование бизнес-процессов диаграммы среди прочих, ее текущий статус, дату последнего пере­ смотра и т. д. Подчеркнем, что наличие стандартной проработанной рамки делает методологию ЮЕЕО еще более удобным инструментом для описания бизнес-процессов. Во многих современных системах моделирования процессов, поддерживающих ШЕБО, большинство важнейших полей рамки заполняется автоматически. Таким обра­ зом, процесс документирования моделей становится достаточно про­ стым и прозрачным. Это существенно облегчает работу аналитиков при создании комплекта моделей бизнес-процессов организации.

2.4.7. Преимущества и недостатки использования \DEF для описания бизнес-процессов Методология моделирования бизнес-процессов ШЕБО, на наш взгляд, предназначена для описания процессов верхнего уровня.

Описывая такие процессы, аналитик уделяет огромное внимание управлению процессами, обратным связям по управлению и инфор­ мации. В табл. 2.1 приводятся основные преимущества и недостатки методологии ШЕБО.

Табл. 2.1. Преимущества и недостатки методологии ЮЕН) - Полнота описания бизнес-процесса (управле­ ние, информационные и материальные потоки, стрелок).

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

- Соответствие подхода к описанию процессов в ЮЕБО стандартам ИСО 9000: Важнейшая характерная черта ЮЕБО — это полнота описания бизнес-процесса, которая достигается за счет наличия средств, ото­ бражающих управляющие воздействия, обратные связи по управле­ нию и информации. Методология ШЕБО предоставляет аналитику Глава 2. Выбор методологии описания бизнес-процессов возможность не заботиться о комплексности декомпозиции за счет использования механизмов мигрирования и туннелирования стре­ лок. Такой механизм обеспечивает связность создаваемых диаграмм между собой. Кроме того, он делает модель процесса наглядной. Ис­ пользование возможности разделения и слияния стрелок также спо­ собствует созданию более наглядных и проработанных моделей. Ре­ зюмируя, можно сказать, что жесткие требования по формированию моделей в IDEF0 в сочетании с гибкими средствами представления потоков информации и ресурсов обеспечивают создание IDEF0моделей стандартного вида.

Второе важнейшее преимущество IDEF0 — это соответствие формата представления процесса его определению в ИСО 9000:2005, что позволяет выбирать IDEF0 в качестве внутреннего стандарта ор­ ганизации, регламентирующего описание бизнес-процессов.

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

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

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

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

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

2.5. Методология IDEF Нотация IDEF3 — важнейшая после IDEF0 и предназначена для опи­ сания потоков работ (Work Flow Modeling). В течение длительного 100 Процессный подход к управлению. Моделирование бизнес-процессов времени IDEF3 широко использовалась для создания моделей биз­ нес-процессов организации на нижнем уровне — при описании ра­ бот, выполняемых в подразделениях и на рабочих местах. Следует от­ метить, что эта нотация была взята за основу при создании методики описания процессов ARIS еЕРС — «расширенной цепочки процесса, управляемого событиями». Предлагаем читателю ознакомиться с но­ тацией IDEF3 как классическим вариантом Work Flow, а затем перей­ ти к рассмотрению более новых схем моделирования процессов.

Основные графические объекты модели, используемые в IDEF3, — четырехугольники и стрелки. Первые служат для описания функций (работ, процессов), вторые — для отражения в модели последователь­ ности выполнения функций во времени либо последовательности выполнения функций, обусловленной потоком материальных ресур­ сов. Прежде чем перейти к нотации IDEF3, рассмотрим следующий пример. На рис. 2.18 представлено два варианта возможного описа­ ния потока работ.

Вариант 1 на рис. 2.18 показывает, что вначале выполняется функ­ ция 1. После ее завершения одновременно осуществляются функ­ ции 2 и 3. Стрелки в этом случае показывают, как завершение одной функции влияет на начало выполнения другой.

Вариант 2 построен по-другому. Начало выполнения функций здесь обусловлено поступлением на вход материальных ресурсов (вход функции 1), окончание — выходом материальных ресурсов (выход функции 1). Потоки ресурсов определяют начало выполне­ ния следующих функций процесса (функций 2 и 3).

В чем недостатки способов описания процессов, представленных на рис. 2.18? В том, что построенные таким образом схемы процес­ сов невозможно прочитать однозначно. Функции 2 и 3 могут выпол­ няться не одновременно, например, в ситуации, когда потребуется осуществить одну из двух. В этом случае выбранный способ описа­ ния процесса не позволит понять, какой вариант развития событий реализуется на самом деле. Если на структурных моделях верхнего уровня (IDEF0) синхронность и условные переходы не важны, то на уровне Work Flow эти данные весьма существенны для реальной работы и должны отражаться в модели. Вернемся к нотации IDEF3.

лава 2. Выбор методологии описания бизнес-процессов Рис. 2.18. Описание потоков работ Длительность выполнения функций (график Ганта) Стрелки отражают последовательность выполнения функций, обусловленную потоком материальных объектов Чтобы избежать неоднозначности описания, в нотации ЮБЕЗ определены дополнительные объекты, служащие для отображения возможных вариантов ветвления и слияния потоков работ, реализу­ ющихся при определенных условиях. Указанные объекты являются логическими символами трех видов:

— логического «И»;

— логического «ИЛИ»;

— исключающего логического «ИЛИ».

Виды объектов нотации ШЕРЗ и их назначение представлены в табл. 2.2.

102 Процессный подход к управлению. Моделирование бизнес-процессов Табл. 2.2. Виды объектов нотации IDEF3 и их назначение Модель работы Объект служит для описания функций 2 Объект ссылки Объект, используемый для описания ссылок (Referent) на другие диаграммы модели, циклические переходы Логический Оператор, позволяющий описать ветвление оператор «И» и слияние процесса. Оператор показывает, что Логический Оператор, позволяющий описать ветвление оператор «ИЛИ» и слияние процесса. Оператор показывает, что Логический опе­ Оператор, позволяющий описать ветвление ратор исключаю­ и слияние процесса. Оператор показывает, что после 8 Стрелка потока Показывает поток объектов от одной функции ---------------------------------------------- В отличие от нотации ШЕБО, в нотации ШЕИЗ стороны четырех­ угольника, изображающего функцию (работу, процесс), не используют­ ся для привязки входов различного типа. Более того, в четырехугольник может входить и выходить только одна стрелка. В противном случае правила построения диаграмм в ШЕБЗ будут нарушены.

На рис. 2.19 показан пример применения логического оператора «И».

Процесс начинается с функции, после которой стоит знак этого опера­ тора, — перекресток. За перекрестком процесс разветвляется и одновре­ менно начинает выполнять следующие две функции. Когда они выпол­ нены, происходит слияние стрелок процесса при помощи значка «И».

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

На рис. 2.20 представлена модель с логическим оператором «ИЛИ».

Такой оператор означает, что после выполнения первой функции про­ цесса могут произойти три события: 1) выполняется функция 2; 2) вы­ полняется функция 3; 3) выполняются функции 2 и 3 одновременно.

Глава 2. Выбор методологии описания бизнес-процессов Рис. 2.19. Модель процесса с оператором «И»

Рис. 2.20. Модель с оператором «ИЛИ»

Рис. 2.21 иллюстрирует применение логического символа исклю­ чающего «ИЛИ». В данном случае после выполнения функции 1 мо­ жет начаться выполнение либо функции 2, либо функции 3. Далее после выполнения какой-либо из этих функций мы снова попадаем на перекресток исключающего «ИЛИ». Функция 4 будет выполнена либо после окончания функции 2, либо функции 3.

104 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 2.21. Модель с оператором исключающего «ИЛИ»

В нотации ШЕРЗ логические операторы могут быть синхронны­ ми и асинхронными. На рис. 2.22 показана разница между синхрон­ ным и асинхронным «И».

Рис. 2.22. Модель с оператором логического «И»

При декомпозиции процессов в ЮЕРЗ не происходит мигриро­ вания и туннелирования стрелок. Аналитик должен сам заботиться о связности моделирования процесса, корректности декомпозиции Глава 2. Выбор методологии описания бизнес-процессов (если данная функция не предусмотрена программным продуктом, в котором он работает). Возможный пример декомпозиции процесса из нотации IDEF0 (рис. 2.15) на процесс в нотации IDEF3 показан на рис. 2.23. Обратим внимание, что функция «Получить вспомога­ тельное сырье на складе» инициируется поступлением утвержден­ ного графика производства. Этот факт отражен входящей стрелкой «График производства». Также на диаграмме процесса показана стрелка «Вспомогательное сырье». Такое ее представление — нару­ шение нотации описания. Но, вообще говоря, таким приемом можно пользоваться, не забывая при этом менять тип стрелки на стрелку с двумя наконечниками, отображающую поток объектов (матери­ альных ресурсов или информации).

На рис. 2.24 приведен пример бизнес-процесса в нотации IDEF под названием «Обработать заявку клиента». Рассматриваемый про­ цесс — часть более общего процесса «Сбыт готовой продукции». Про­ цесс начинается с поступления заявки клиента, которую обрабатыва­ ет функция «Выполнить учет заказа в системе». По ходу ее реализации данные заказа клиента регистрируются в системе автоматизации (на­ пример, в файле Excel). Затем менеджер отдела сбыта осуществляет проверку на соответствие номенклатуре (функция «Выполнить ана­ лиз на соответствие номенклатуре»). Результатом этого могут быть два события: «Заказ соответствует номенклатуре изделий, произво­ димых организацией» или «Заказ не соответствует номенклатуре из­ делий». Для отражения этих событий в модели процесса используется логический оператор исключающего «ИЛИ». После этого логического оператора процесс ветвится. В случае несоответствия заказа номен­ клатуре выполняется нижняя ветка процесса, а именно функции «Уведомить клиента о невозможности выполнения заказа» и «Внести заказ клиента в статистику неудовлетворенного спроса».

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

Планово-экономический отдел организации (ПЭО) анализирует за­ каз и делает вывод о его реализуемости.

Рис. 2.23. Пример модели процесса в стандарте ЮЕРЗ Рис. 2.24. Модель бизнес-процесса «Обработать заявку клиента» в нотации ЮЕРЗ 108 Процессный подход к управлению. Моделирование бизнес-процессов Например, может сложиться ситуация нехватки производствен­ ных мощностей из-за ремонтов, несоответствия величины заказа эко­ номически обоснованным размерам партии и т. п. В этом случае мы снова попадаем на нижнюю ветку процесса, при этом используется ло­ гический оператор «ИЛИ». Он служит для объединения возможных входов в функцию «Уведомить клиента о невозможности заказа».

Если ПЭО считает заказ выполнимым, то проводится детальный расчет себестоимости выполнения — определяется его цена и воз­ можные сроки выполнения (функция «Рассчитать себестоимость, цену и возможные сроки выполнения заказа»). Далее указанные выше расчетные цифры согласовываются с клиентом — выполняет­ ся функция «Согласовать условия поставки с клиентом».

Снова возможны два варианта — используется оператор логиче­ ского исключающего «ИЛИ». Если клиента не устраивают финансовые условия, он отказывается от заказа, который мы вносим в статистику неудовлетворенного спроса (нижняя ветка процесса). Если клиент го­ тов работать на наших условиях, то процесс заканчивается. Выходом процесса служат «Согласованная заявка клиента» и данные по рас­ считанным параметрам заказа (на схеме процесса не показаны).

Обратите внимание, что описанный выше процесс приводится далее в виде модели в нотации А1Ш еЕРС, так что читатель может сравнить возможности двух нотаций по описанию одного и того же Анализ процесса, представленного на рис. 2.24, наводит на мысль о том, что нотацию IОЕГЗ целесообразно применять в случае относи­ тельно простых процессов на нижнем уровне декомпозиции, то есть на уровне рабочих мест. В этом случае схема процесса может слу­ жить основой для создания документов, регламентирующих работу исполнителей. Очевидно, что процесс в нотации ШЕРЗ «плоский».

При помощи этой нотации достаточно сложно создавать комбини­ рованные модели, в которых бы сочетались описания потоков работ и процессы управления ими. Этот факт становится в особенности очевидным при сравнении описаний процессов в нотации ШЕРЗ и ШЕРО. Более подробную информацию о правилах создания моде­ лей в нотации ШЕРЗ можно найти в [3].

Глава 2. Выбор методологии описания бизнес-процессов 2.6. Моделирование процессов в нотации DFD Важнейшим способом описания процесса являются диаграммы по­ токов данных (информации) DFD (Data Flow Diagram). Диаграммы этого типа содержат, как правило, два типа графических объектов:

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

Рис. 2.25. Пример простейшей модели потоков данных На диаграмме DFD функции обычно располагаются слева напра­ во в порядке, соответствующем последовательности их выполнения во времени, хотя это не обязательно. Если придерживаться указанного требования, то полученная схема — это описание процесса, схожее с его описанием в нотации IDEF3. Процесс, представленный на рис. 2.25, имеет два входящих потока данных и три исходящих. На верхнем уровне рассмотрения этот процесс выглядел бы в виде одной функции с двумя входами и тремя выходами. Таким образом, к описанию про­ цессов в DFD применимы типовые правила декомпозиции. Что касает­ ся сторон четырехугольников, то в нотации DFD они не имеют того же значения, что и в IDEF0. Следует отметить, что существует несколько подходов к формированию моделей потоков данных.

Часто нотацию DFD путают с простым описанием потоков ин­ формации между подразделениями. Это далеко не одно и то же.

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

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

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

Рис. 2.27. Модель процесса в нотации DFD Данный заказа клионта заказа клионта Для чего служит нотация DFD? В первую очередь она нужна для описания реально существующих в организации потоков данных.

Описания могут создаваться как по процессному, так и по функцио­ нальному признаку В первом случае мы получаем модели бизнеспроцессов в формате DFD, во втором — схему обмена данными между подразделениями. Созданные модели потоков данных организации могут быть использованы при решении таких задач, как:

— определение существующих хранилищ данных (текстовых — определение и анализ данных, необходимых для выполнения — подготовка к созданию модели структуры данных организа­ ции (так называемой ERD-модели);

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

Рис. 2.28. Различные варианты использования нотации DFD графический символ хранилища данных) графический символ хранилища данных) Более того, нотация DFD может быть несколько модернизиро­ вана таким образом, чтобы на одной диаграмме показывались как потоки данных, так и потоки материальных ресурсов, как видно При создании моделей процессов на практике часто бывает полез­ но использовать несколько способов описания. Сначала, например, мы создаем модель в нотации IDEF0, выявляем функции, входящие в процесс. Затем проводим декомпозицию процесса. При достижении определенного уровня детализации (третьего-четвертого) становит­ ся целесообразным сформировать для каждого детального процесса несколько схем в различных форматах: управление — в IDEF0, а по­ токи данных и материалов — в DFD.

Глава 2. Выбор методологии описания бизнес-процессов Более подробную информацию о принципах построения моде­ лей бизнес-процессов в DFD можно получить в [3].

Рис. 2.29. Совмещение различных типов стрелок на одной модели DFD В данном разделе мы рассмотрим методологию ARIS. В настоящее время на рынке инструментальных средств моделирования бизнеспроцессов представлено одноименное ПО ARIS [6].

Методология ARIS включает в себя несколько различных но­ таций для описания деятельности организации с различных точек зрения. В методологию интегрированы существующие стандарты и спецификации описания процессов и данных, например IDEF3, ERD, DFD, UML и т. д. Основная концепция ARIS по описанию орга­ низации показана на рис. 2.30.

Изображение на рис. 2.30 часто называют «домик ARIS». Подход методологии ARIS к описанию процессов основы вается на рассмотре­ нии деятельности организации с четырех точек зрения: взгляд на ор­ ганизационную структуру, взгляд на данные (потоки и структуру), взгляд на функции (функциональные иерархии), взгляд на контроль и управление (сводные модели бизнес-процессов).

Методология ARIS включает в себя большое количество различ­ ных нотаций, допускающих гибкое создание различных моделей 1U Процессный подход к управлению. Моделирование бизнес-процессов организации. К числу наиболее значимых и практически используе­ мых нотаций ARIS относятся:

— нотация Value-added Chain Diagram (диаграмма цепочки про­ цесса, добавляющего стоимость);

— нотации еЕРС, Extended Event-driven Process Chain (расши­ ренная нотация цепочки процесса, управляемого событиями) и PCD (диаграмма цепочки процесса);

— нотация Organizational Chart (организационная диаграмма);

— нотация Function Tree (дерево функций);

— нотация Product Tree (дерево продуктов).

Рис. 2.30. Основные виды моделей в методологии ARIS Сила методологии ARIS (с формальной точки зрения) заключает­ ся в ее комплексности, которая проявляется во взаимосвязи моделей, построенных в различных нотациях. Методология ARIS позволяет описывать деятельность организации с разных точек зрения, при этом полученные модели в определенной степени связаны между со­ бой. Следует, однако, подчеркнуть, что основные преимущества та­ кого комплексного подхода:

— требуют для своей реализации наличия инструментальной среды ARIS, дорогостоящей и достаточно сложной в исполь­ зовании, хотя существует и бесплатная, упрощенная версия этого продукта под названием ARIS Express;

Глава 2. Выбор методологии описания бизнес-процессов — трудно реализуемы на практике, так как влекут большой рас­ ход ресурсов (человеческих, материальных и финансовых) в течение длительного времени.

2.7.1. Нотация Value-added Chain Diagram (VAD) На рис. 2.31 представлена одна из важнейших нотаций ARIS — нота­ ция Value-added Chain Diagram. Диаграмма цепочки процесса, добав­ ляющего стоимость, используется при описании бизнес-процессов организации на верхнем уровне. Как правило, консультанты, ис­ пользующие ARIS, рекомендуют выделять шесть-восемь бизнеспроцессов верхнего уровня и описывать их в нотации VAD. Затем проводится декомпозиция полученных процессов верхнего уровня, при этом используется либо нотация VAD, либо еЕРС. Рассмотрим основные объекты нотации VAD, представленные на рис. 2.31.

Основной объект нотации VAD — это Value Added Chain. Факти­ чески это процесс или группа функций организации, которые служат для получения добавленной стоимости. Объекты соединяются между собой пунктирной стрелкой, имеющей тип is predecessor of («является предшественником»). Этот тип связи показывает, что один процесс — предшественник другого. Очевидно, однако, что на практике все основные процессы цикличны. Кроме того, они имеют обратные свя­ зи. Поэтому термин is predecessor of, на наш взгляд, неудачный.

Между процессами, приведенными на рис. 2.31, могут быть ото­ бражены потоки материальных ресурсов и информации. Для их опи­ сания можно воспользоваться объектами типа Cluster (для описания информации) и Technical Term (для описания материальных пото­ ков). Для описания инфраструктуры, необходимой для выполнения процесса, в данном примере выбраны типы объектов Product/Service и Information Service. Выбор типов объектов для отображения реаль­ ных потоков в достаточной степени условный. Очень важно в начале работ по моделированию процессов определить, какие именно типы объектов будут использованы и какие объекты реального мира они будут отображать. Так, в примере на рис. 2.31 можно было бы по­ казать все потоки (информационные и материальные) при помощи объектов типа Technical Term.

116 Процеса i ы й п од ход к у правлены ю. Мо делировапие бизпес-процес со в Рис. 2.31. Модель в нотации Value-added Chain Diagram На рис. 2.31 показаны также объекты Organizational Unit, отобра­ жающие организационные подразделения, выполняющие соответ­ ствующие процессы.

Объекты связываются между собой при помощи связей опреде­ ленного типа (рис. 2.31). Например, информационный поток, отобра­ жаемый объектом Cluster, является входящим для первого процесса, и он связан с ним при помощи стрелки типа is input for («является входом для»). Другой пример — тип связи executes («исполняет») между объектами Value-added Chain и Organizational Unit. Тип свя­ зи is used by показывает, что Product/Service используется процессом и т. д. Таким образом, в методологии ARIS важнейшие требования — это корректный выбор и дальнейшее использование связей и объек­ тов определенного типа.

На рис. 2.32 представлен пример модели верхнего уровня, вы­ полненный в нотации ARIS VAD. Вы уже знакомы с этим процессом.

На рис. 2.17 он приведен в нотации IDEF0.

Принципы построения диаграммы процесса верхнего уровня в VAD существенно отличаются от IDEF0: в VAD стрелки могут входить в лю­ бую сторону объекта Value-added Chain. (Напомним, что в IDEF0 каж­ дая сторона объекта Activity (функция) имеет глубокий смысл.) Оперативное управляющее воздействие Требования клиента отгрузки ГП 118 Процессный подход к управлению. Моделирование бизнес-процессов На рис. 2.33 представлена ситуация, возможная в нотации УАО, когда на диаграмме процесса приводится множество обратных свя­ зей, смысл которых понятен только создавшему модель аналитику.

Указанный недостаток УАЭ можно обойти, заранее оговорив возможность специального использования обратных связей, как, на­ пример, на рис. 2.34.

Рис. 2.33. Обратные связи в нотации Value-added Chain Diagram Рис. 2.34. Пример реализации обратных связей в нотации Value added Chain Diagram Отметим, что у специалистов по АШБ такой подход может вызвать критику, так как противоречит нотации. Но мы придерживаемся Глава 2. Выбор методологии описания бизнес-процессов той точки зрения, что это вполне допустимо, так как модели верх­ него уровня в нотации VAD ARIS реально могут быть использованы лишь в качестве простейшего способа графического изображения цепочки процесса.

Заканчивая обзор нотации ARIS VAD, еще раз акцентируем вни­ мание на том, что указанная нотация в большей степени носит иллю­ стративный характер и не предназначена для создания комплексных моделей процессов верхнего уровня организации.

2.7.2. Нотация ARIS еЕРС - расширение нотации IDEF Нотация ARIS еЕРС (еЕРС — Extended Event Driven Process Chain — расширенная цепочка процесса, управляемого событиями) разрабо­ тана специалистами немецкой компании IDS Scheer AG (Германия), в частности профессором Шеером. В табл. 2.3 приводятся основные используемые в рамках нотации объекты.

Помимо указанных в табл. 2.3 основных объектов, при постро­ ении диаграммы еЕРС могут быть использованы и многие другие.

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

Для понимания смысла нотации еЕРС рассмотрим основные используемые типы объектов и связей. На рис. 2.35 представлена простейшая модель еЕРС, описывающая фрагмент бизнес-процесса предприятия.

На рис. 2.35 видно, что связи между объектами имеют определен­ ный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая событие 1 и функцию 1, активирует (activates) или инициирует выполнение функции 1. Функ­ ция 1 создает (creates) событие 2, за которым следует символ логиче­ ского «И», запускающий выполнение функций 2 и 3.

Внимательный анализ нотации еЕРС показывает, что она прак­ тически не отличается от IDEF3. Важнейшее отличие еЕРС — на­ личие объекта «Событие» (Event). Этот объект служит для ото­ бражения в модели возможных результатов реализации функций, в зависимости от которых выполняется та или иная последующая 120 Процессный подход к управлению. Моделирование бизнес-процессов ветка процесса. Нотация еЕРС называется расширенной, очевидно, именно вследствие наличия в ней объекта «Событие» (в ШЕИЗ тако­ го объекта нет). На рис. 2.36 приводятся примеры применения сим­ волов логики и событий при построении моделей в нотации еЕРС.

Табл. 2.3. Основные объекты, используемые в рамках нотации ARIS еЕРС Организаци­ Объект, отражающий различные организацион­ онная еди­ ные звенья предприятия (например, управление между объек­ ми объектами, например активацию выполне­ исключающее между событиями и функциями в рамках про­ Глава 2. Выбор методологии описания бизнес-процессов Рис. 2.35. Нотация АШБ еЕРС Рис. 2.36. Применение логических операторов при построении моделей в еЕРС Функция При построении модели в А1Ш еЕРС должны соблюдаться сле­ дующие правила:

— каждая функция инициируется и завершается событием;

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

Кроме этих, существуют и другие важные правила формирова­ ния моделей в АШБ.

На рис. 2.37 показано применение различных объектов нотации АШБ еЕРС при создании модели бизнес-процесса.

122 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 2.37. Окружение функции в нотации ARIS еЕРС На рис. 2.36 и 2.37 видно, что бизнес-процесс в нотации еЕРС представляет собой последовательность процедур, расположенных в порядке их выполнения. Следует отметить, что реальная длитель­ ность осуществления процедур в еЕРС не может быть отражена ви­ зуально. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя возлагается выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса.

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

Глава 2. Выбор методологии описания бизнес-процессов На рис. 2.38 представлен процесс обработки заказа клиента (он же изображен в нотации IDEF3 на рис. 2.24).

Процесс начинается с события «Поступил заказ клиента». Оно инициирует функцию «Выполнить учет заказа в системе», которую осуществляет менеджер отдела сбыта. Для работы он использует «Систему учета заказов». Результат выполнения функции отобража­ ется событием «Учет заказа выполнен».

После этого менеджер по сбыту реализует функцию «Выполнить анализ на соответствие номенклатуре». Результат — два альтернатив­ ных события: «Заказ соответствует номенклатуре» и «Заказ не соот­ ветствует номенклатуре». Процесс ветвится. Для отображения вет­ вления процесса используется символ логического исключающего «ИЛИ».

Функция «Уведомить клиента о невозможности выполнения за­ каза» может выполняться в двух случаях: если заказ не соответству­ ет номенклатуре либо производство невозможно. Для отображения на схеме процесса этих вариантов используется символ логического «ИЛИ» и т. д.

Как видно из рис. 2.38, схема процесса в ARIS еЕРС отличается от схемы в IDEF3 наличием объектов: событий, документов, при­ кладных систем и должностей. Схема в ARIS визуально представля­ ется более информативной и воспринимается лучше, однако ее раз­ мер существенно превышает схему в нотации IDEF3.

Рассмотренный выше процесс может быть представлен также в нотации ARIS PCD (Process Chain Diagram) — разновидности еЕРС.

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

Рис. 2.38. Пример модели Глава 2. Выбор методологии описания бизнес-процессов Однако нотация РСО обладает существенным недостатком — ее можно эффективно применять для простых (не более пяти-восьми функций), желательно линейных процессов. Сложные же процессы, с разветвленной логикой, отображать при помощи РСО неудобно, что наглядно отображено на рис. 2.39.

126 Процессный подход к управлению. Моделирование бизнес-процессов 2.7.3. Нотация ARIS Organizational Chart Нотация Organizational Chart — одна из основных нотаций ARIS и предназначена для построения схем организационной структу­ ры предприятия. Как правило, эта модель строится в начале про­ екта по моделированию бизнес-процессов. В модели отражаются существующие подразделения предприятия в виде иерархической структуры, как показано на рис. 2.40.

Рис. 2.40. Модель организационной структуры предприятия Модель строится из объектов Organizational Unit, Position, Internal Person и т. д. Заложенные в нотацию виды связей позволя­ ют отразить различные типы отношений между объектами орга­ низационной структуры. В представленном на рис. 2.40 примере «Предприятие» управляется «Директором», при этом используется тип связи is Organization Manager for. Иерархия подразделений стро­ ится при помощи связей is composed of. Также могут быть указаны должности — Position, фамилии занимающих их сотрудников — Internal person, тип связи — occupies. Кроме моделей иерархии под­ разделений, могут быть построены модели иерархии подчиненности в проектных командах, группах и т. д. Все отраженные в моделях объекты могут быть использованы в дальнейшем при построении моделей бизнес-процессов. При построении сложных иерархических Iлава 2. Выбор методологии описания бизнес-процессов структур может быть использована декомпозиция, например струк­ туру подразделения отражают на более детальной схеме.

2.7.4. Нотация ARIS Function Tree Эта нотация предназначена для формирования моделей дерева функций. Пример такой модели представлен на рис. 2.41. Все функ­ ции на этой диаграмме соединены связями. Чаще всего использу­ ются типы связей is execution-oriented superior и is process-oriented superior. Первый тип связи служит для построения дерева по функ­ циональному признаку (описания функций подразделения). Второй тип связи используется при создании дерева функций, входящих в некоторый бизнес-процесс.

Рис. 2.41. Модель Function Tree (дерева функций) Дерево функций может строиться по функциональному, про­ цессному и продуктовому принципам. На практике часто использу­ ется первый принцип — создаются модели иерархии функций под­ разделения.

2.7.5. Нотация ARIS Product Tree На рис. 2.42 представлена нотация ARIS Product Tree. Она предна­ значена для создания моделей дерева продуктов. Модели такого типа могут использоваться для описания материальных входов и выходов процесса.

128 Процессный подход к управлению. Моделирование бизнес-процессов Рис. 2.42. Модель Product Tree (дерева продуктов) Нотация Information Flow — аналог DFD и применяется при постро­ ении схем потоков данных или документов между функциями биз­ нес-процессов предприятия. Простота нотации ограничивает области ее полезного применения. Ее основные объекты — Function (использу­ ется также при построении моделей бизнес-процессов) и Information Flow — информационный поток, как показано на рис. 2.43.

Рис. 2.43. Нотация ARIS Information Flow (информационного потока) При построении моделей бизнес-процессов сначала может быть построена модель еЕРС, а затем, с использованием определенных в процессе функций, — модель информационных потоков.

2.7.7. Использование нескольких нотаций при соз моделей процессов в АШБ При формировании моделей бизнес-процессов в АКК, как правило, используется несколько типов нотаций. На рис. 2.44 представлена схема применения моделей, созданных в различных нотациях.

Глава 2. Выбор методологии описания бизнес-процессов Рис. 2.44. Использование нотаций АШБ при создании моделей Как правило, работа по описанию бизнес-процессов компании в АИБ начинается с создания модели организационной структуры.

Одновременно (или позже) могут разрабатываться модели, описыва­ ющие структуру основных материальных и информационных вхо­ дов и выходов. С использованием данных моделей создаются моде­ ли бизнес-процессов верхнего уровня в нотации УАЭ. После этого разрабатываются модели функций подразделений и другие вспомо­ гательные модели (например, описание прикладных программных систем). Затем формируются модели процессов в нотации еЕРС.

Модели еЕРС строятся на основе уже имеющихся описаний органи­ зационной структуры, функций подразделений, материалов, систем и т. д. Итог работы — комплект моделей, описывающих деятельность организации с различных точек зрения.

Особенность работы в полноценных программных продуктах для моделирования бизнес-процессов состоит в том, что программный продукт создает базу данных по объектам и их атрибутам. С одной 130 Процессный подход к управлению. Моделирование бизнес-процессов стороны, это позволяет рассматривать различные аспекты взаи­ модействия объектов модели, выбирая одну из нотаций (рис. 2.44).

С другой стороны, «несущественная» ошибка при создании связей между объектами в одной нотации может существенно исказить вид диаграммы в другой нотации.

2.8. Описание процессов при помощи блок-схем Простейший, но практически важный способ описания бизнеспроцессов — методика составления блок-схем. Данный подход имеет много общего с графическими языками описания алгоритмов про­ граммного обеспечения. С точки зрения методологии формирование блок-схем проводится так же, как в нотации IDEF3, хотя для упро­ щения символы логики могут опускаться. Для разработки блок-схем могут быть использованы стандартные офисные программные про­ дукты, например MS Word или Visio. Основные графические объек­ ты языка описания процессов при помощи блок-схем представлены Табл. 2.4. Графические объекты блок-схемы процесса «Процесс«. Объект отображает функцию или процесс, выпол­ 2 «Ручное управление«. Объект отображает функцию или процесс.