IDEF0 как инструмент моделирования процессов

Андрей Дворников

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

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

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

При этом времени и денег затрачено много, а результат...

А результат в лучшем случае равен нулю.

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

Вопрос первый и самый главный: какую методику выбрать из спектра предлагаемых на современном рынке?

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

Вопрос второй, логически вытекающий из первого: какой из программных продуктов выбрать, да так, чтобы по обычаю, было дешево и сердито?

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

При определении собственного выбора методик моделирования, через мои руки прошли разные программные продукты, реализующие множество нотаций: от экзотического для российского пользователя System Architect ( британской компании со смешным именем Popkin Software & System Inc .) до популярного, в настоящий момент, ARIS Toolset немецкой компании IDS Scheer AG .

На мой взгляд, для решения описания средних по сложности задач в рамках проекта, наиболее простой и эффективной является методика функционального моделирования IDEF 0, реализованная в программном продукте BPWin компании Computer Associates International , Inc . (наряду с IDEF 3, DFD )

Среди преимуществ этого выбора следует отметить следующее:

Во-первых, методология использует очень простые элементы (символы) – блоки и стрелки

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

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

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

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

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

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

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

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

Символы

Язык методики прост и лаконичен. Для моделирования выделено всего два графических символа, один из которых, отражает какое либо действие или работу (Activity в BPWin или Функциональный блок в IDEF0), второй служит для отображения взаимодействия работ с внешним миром и между собой (Arrow в BPWin или Интерфейсная дуга в IDEF0).

Любая работа отображается в виде прямоугольника, любое взаимодействие с внешней средой в виде стрелки (см. рис. 1).

Рисунок 1. Основные элементы методологии моделирования процессов IDEF 0: функциональный блок и интерфейсные дуги

Значения символа Arrow (стрелка или интерфейсная дуга).

Стрелки (Arrow) в IDEF0 имеют четыре основных значения:

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

Всегда присоединяется к работе (функциональному блоку) слева.

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

Всегда присоединяется к работе (функциональному блоку) сверху.

Значение 3. Выход процесса (Output). Отображают отходы производства, отчетность, продукцию или услугу, преобразованные данные (в том числе информационные).

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

Значение 4. Механизмы процесса (Mechanism): Символизируют сотрудников, программное обеспечение, оборудование, средства связи, то есть все то, что участвует в процессе.

Всегда присоединяются к процессу снизу.

Декомпозиция. (Decomposition)

Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его части. (см. Рис. 2, где бизнес-процесс декомпозирован на операции).

Рисунок 2. Декомпозиция бизнес-процесса на составляющие его операции в стандарте IDEF 0

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

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

При этом следует отметить, что лучшее – это враг хорошего.

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

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

Объем процессного регламента, в таком случае, будет равен от сорока семи до пятидесяти страниц.

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

• "Связь по входу" (Output - Input) - выход вышестоящей работы является входом для нижестоящей.
• "Связь по управлению" (Output - Control) - выход вышестоящей работы является контролем (управлением) для нижестоящей работы.
• Обратная "связь по входу" (Output – Input Feedback) - выход нижестоящей работы является входом вышестоящей работы (Применяется при описании циклических работ)
• Обратная "связь по управлению" (Output – Control Feedback) - выход нижестоящей работы является контролем (управлением) вышестоящей
• Связь "выход-механизм" (Output – Mechanism) - выход одной работы является механизмом другой, т.е. одна работа готовит ресурс для другой. Данный тип связи разрешен стандартом, но применять его нужно очень осторожно, только после разбора ситуации совместно с менеджером по качеству.

Рисунок 3. Типы связей между операциями процесса, используемые в стандарте IDEF 0

Моделирование. От модели "Как есть" к модели "Как надо"

Перед началом моделирования, разработчику стоит определиться с двумя важными вещами:

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

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

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

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

Далее, собранный материал переводится в символы IDEF0, в соответствии с правилами методики.

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

В результате получается модель "Как есть", которая и описывается в процессном регламенте.

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

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

Как уже упоминалось ранее, BPWin поддерживает три методики моделирования: IDEF0, IDEF3, DFD.

Моделируя последовательно один и тот же процесс в трех нотациях, разработчик обязательно определит узкое место процесса, причем, не одно. При использовании полученных моделей, новая модель в нотации IDEF0 уж точно будет в формате "Как надо". (Рис. 4).

Рисунок 4. Методологии моделирования IDEF0, IDEF3 и DFD

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

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

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

Но это уже совсем другая история... .

Версия для печати	Вернуться на сайт