Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Функционально-структурный анализ

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

• что поступает в подразделение “на входе”?

• какие функции, и в какой последовательности выполняются в рамках подразделения?

• кто является ответственным за выполнение каждой из функций?

• чем руководствуется исполнитель при выполнении каждой из функций?

• что является результатом работы подразделения (на выходе)?

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

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

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

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

Если в процессе моделирования выявляется несогласованность оценок экспертов, то такая несогласованность должна быть преодолена, чтобы получить модель, представляющую объект моделирования или какую-то его часть адекватно. Методология IDEF0 предусматривает необходимость сохранения записей о всех решениях и альтернативных подходах по мере того, как они возникают на протяжении проекта. Копии диаграмм, разработанные автором, критически (конструктивно) анализируются ком-петентными экспертами, которые заносят свои замечания и предложения непосредственно на копиях диаграмм. Авторы отвечают на каждое замечание письменно на тех же копиях. Предложения принимаются или отвергаются письменно с указанием причин. После внесения изменений и исправлений старые варианты диаграмм остаются в архиве проекта. В процессе чтения диаграмм ничто не должно предполагаться в модели по умолчанию, а также не должны делаться выводы, выходящие за пределы действия и утверждения модели. Это побуждает автора к тщательному комментированию и иллюстрированию каждого добавляемого к модели фрагмента, чтобы при чтении и интерпретации модели ее толкование было однозначным и соответствующим поставленной цели и установленной точке зрения без личного присутствия автора и его дополнительных пояснений. В коллектив, занимающийся моделированием ИС, обязательно должны входить следующие участники:

• руководитель проекта;

• авторы (разработчики) модели;

• технический совет;

• эксперты в предметной области;

• библиотекарь.

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

Это участник проектной группы, осуществляющий административное управление проектом. Ру-ководитель проекта должен выполнять при моделировании следующие основные функции:

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

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

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

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

• присваивать статус рассматриваемой советом части модели.

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

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

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

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

• оформление модели в виде IDEFO-диаграмм;

• установление необходимого контакта со всеми участниками проекта на основании предос-тавленного руководителем проекта списка источников информации и списка экспертов;

• оформление модели в виде набора IDEF0-диаграмм и оформление папки с диаграммами для рецензирования и передачи их в библиотеку проекта;

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

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

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

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

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

1. Изучение объекта моделирования и определение области действия модели.

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

3. Анализ и синтез системных объектов, записывая, как именно подверглись разбиению объекты, входящие в ограниченный объект. Список данных начинается со всех граничных стрелок и их ICOM-кодов, а заканчивается их составляющими.

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

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

6. Функциональные части объединяются в сбалансированные наборы из 3-6 блоков. Такое тре-бование стандарта вынуждает автора использовать абстракцию и декомпозицию для по-степенного представления деталей системы.

7. Создаются основные стрелки, представляющие ограничения, потом внешние и, наконец, внутренние стрелки.

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

9. Снова выполняются анализ и синтез, в результате чего формируются наборы объектов, ко-торые представляются стрелками, соединяющими блоки.

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

АВТОРСКАЯ ПРОВЕРКА - процесс критической оценки собственной работы, позволяющий определить качество диаграммы, которая декомпозирует блок и его стрелки. Авторская проверка позволяет аналитику объяснить объект самому себе. При критической оценке аналитик должен максимально абстрагироваться от своей работы, что позволяет ему взглянуть свежим взглядом на диаграмму с тем, чтобы информация, которую она несет, стала доступной не только ее автору, но и другим людям. Процесс критической оценки должен происходить по следующему алгоритму:

1. Выявление недостатков новой диаграммы.

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

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

4. Корректировка всех связанных с ней диаграмм.

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

• представляют ли блоки содержательную декомпозицию функции?

• не выглядит ли диаграмма запутанной?

• все ли блоки соответствуют точке зрения модели?

• несут ли блоки достаточный объем новой информации?

• все ли блоки имеют одинаковый уровень детализации?

• соразмерна ли сложность всех блоков?

• отражает ли каждый блок какой-либо аспект блока родительской диаграммы?

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

• все ли внешние стрелки имеют ICOM-коды?

• все ли ICOM-коды соединяют стрелки с одним и тем же значением?

• дополняют ли названия внешних стрелок информацию, сообщаемую диаграммой?

• не противоречит ли смысл анализируемой диаграммы смыслу родительской диаграммы?

Поиск ошибок в диаграмме обычно заканчивают вопросами о внутренних стрелках. Можно задать вопросы типа:

• не слишком ли много внутренних стрелок?

• нет ли блоков без стрелок управления?

• нет ли блоков без выходных стрелок?

• правильно ли отражают стрелки, представляющие ограничения, доминирование блоков?

• верно ли решение диаграммы?

• все ли важные обратные связи отражены?

• все ли ошибочные ситуации учтены?

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

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

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

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

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

Это элемент организации процесса создания моделей, предлагающий арбитражные решения по моделированию и рекомендации по установлению статуса диаграмм, части и/или модели в целом (статусы: «Рабочий проект», «Эскиз», «Рекомендовано» и «Публикация»). Технический совет выполняет роль комитета технического контроля и поэтому его главной обязанностью является контроль качества моделей, создаваемых авторами IDEF-проекта и, что создаваемая в процессе анализа, модель будет точна и используема в дальнейшем.

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

Основные функции комитета:

• на каждом этапе оценки применимости модели определять текущее направление развития проекта;

• вырабатывает предложения по корректировке модели и ее развития;

• направлять аналитику свои замечания и предложения по необходимой доработки в виде рецензий;

• после признания модели применимой для решения поставленной цели, давать разрешение на ее публикацию.

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