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

СТАНДАРТ IDEF3

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

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

• анализировать существующие процессы и разрабатывать новые;

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

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

• содействовать принятию оптимальных решений при реорганизации процессов;

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

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

IDEF3-ДИАГРАММА

IDEF3-ДИАГРАММА (диаграмма потока, process flow diagram, IDEF3-diagram, workflow) - основная единица описания в IDEF3, являющаяся графическим представлением назначения системы или процесса и применяются для анализа завершенности процесса обработки информации (проверка модели ИС на целостность). Обычно IDEF3-диаграммы являются дополнением к IDEFO-диаграммам, т.к. содержат все необходимые сведения для построения моделей, которые в дальнейшем могут быть использованы для имитационного анализа. С помощью диаграмм IDEF3 можно анализировать сценарии из реальной жизни, например, как закрывать магазин в экстренных случаях или какие действия должны выполнить менеджер и продавец при закрытии. Каждый такой сценарий содержит в себе описание процесса и может быть использован, что бы наглядно показать или лучше задокументировать бизнес-функции организации.

СЦЕНАРИЙ

СЦЕНАРИЙ (Scenario) - описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Метод IDEF3 использует сценарии для упрощения структуры описаний сложного многоэтапного процесса. Сценарии определяют граничные условия описания и представляют собой повторяющуюся по-следовательность ситуаций или действий, которые описывают типичный класс проблем, при-сутствующих в организации или системе, описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности обработки менеджером заявки). Использование сценариев упрощает структуру описаний сложного многоэтапного процесса. На основе IDEF3-диаграмм создаются сценарии действий сотрудников предприятия/организации, например последовательность этапов конструкторско-технологической подготовки производства машиностроительного изделия или иного события, которые необходимо обработать за конечное время. Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. Исполнение каждого сценария сопровождается соответствующим документооборотом, который состоит из двух основных потоков: документов, определяющих структуру и последовательность процесса (технологических указаний, описаний стандартов и т.д.), и документов, отображающих ход его выполнения (ре-зультатов тестов и экспертиз, отчетов о браке, и т.д.).

IDEF3-ДИАГРАММА СЦЕНАРИЯ

IDEF3-ДИАГРАММА СЦЕНАРИЯ (scenario diagram) -- это специфический вид диаграммы, которая создается для иллюстрации сценария типа what if – «что будет, если» для декомпози-ционных IDEF3-диаграмм. Для сценария номер декомпозиции всегда больше единицы. При создании сценария, как и при создании описания, требование, что при декомпозиции может существовать только одна точка входа, за которой обязательно следует функция или перекресток, дополняется разрешением, что сценарий, который не является декомпозицией, может иметь несколько точек выхода. Создание сценариев путем декомпозиции IDEF3-диаграммы должно производиться при непосредственном участии автора и экспертов в предметной области. Алгоритм совместной работы имеет вид:

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

2. При отсутствии личного контакта между автором и экспертом необходимо приготовить список вопросов для проведения интервью.

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

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

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

Диаграммы Workflow могут быть использованы в моделировании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, каждый из которых сопровождается описанием процесса и может быть использован для документирования каждой функции. IDEF3 предполагает построение двух типов моделей. Для описания процесса в IDEF3 определены две стратегии и, соответственно, два типа диаграмм, представляющие описание одного и того же сценария технологического процесса в разных ракурсах - модель может отражать некоторые процессы в их логической последовательности, позволяя увидеть, как функционирует организация, или же модель может показывать “сеть переходных состояний объекта”, предлагая вниманию аналитика последовательность состояний, в которых может оказаться объект при прохождении через определенный процесс:

• process-centered strategy – стратегия описания процесса как последовательности выпол--няемых действий. Диаграммы этого типа получили название Process Flow Description Dia-grams (PFDD) – диаграммы потокового описания последовательности выполнения этапов процесса "с точки зрения наблюдателя". Поток процессов содержит знания о том, «как это происходит» в организации, т.е. описание того, что происходит с изделием, когда оно проходит через этапы производственного процесса. Диаграммы PFDD описывают процесс, фиксируют весь временный, старшинство, и информация отношений причинно-следственной связи относительно набора процессов в технологическом маршруте. Ключевыми понятиями диаграммы Описания Последовательности Действий являются понятия, процесс и логика процесса;

• object-centered strategy - стратегия описания процесса как последовательности изменений состояний объекта, над которым выполняются действия. Диаграммы такого типа получили название Object State Transition Network (OSTN) – диаграммы последовательности измене-ний состояний объекта и его трансформаций процессом. OSTN позволяет рассматривать процесс "с точки зрения объекта" и используются для иллюстрации трансформаций объекта, которые происходят на каждой стадии выполнения соответствующих UOW. Объектные сети изменений состояния фиксируют центрированные объектом представления процессов, суммируя допустимые изменения состояния, которым объекты могут подвергнуться повсюду специфического технологического маршрута. Сеть описания изменений состояния объектов рассматривает возможные изменения, которые происходят с объектами в ходе отдельного процесса, поэтому ключевыми понятиями OSTN диаграммы являются состояние объекта и изменение состояния.

Описание процесса в IDEF3 может содержать диаграммы PFDD и OSTN или диаграммы какого-либо одного типа.

В качестве базовой структурной единицы описания процесса для диаграмм PFDD в IDEF3 используется понятие сценария. Описание процесса может состоять из одного или нескольких сценариев. Сценарий определяется как повторяющаяся ситуация, некий набор ситуаций, описывающих типичный класс проблем в системе или организации, обстановка или среда, в которой происходит рассматриваемый процесс. Основным назначением сценария является определение контекста описания через присвоение сценарию имени. Именем сценария может быть глагол с поясняющими словами («Оформить заказ на товары», «Проверить пригодность товара») или название совокупности характерных действий («Выполнение последовательности проверок»). Таким образом, сценарий устанавливает ориентацию и границы описания. Описание потока процессов в IDEF3 содержит определение процессов и их связей в общем контексте деятельности предприятия. Его цель – показать, что происходит в данной организации при решении отдельной проблемы или в повторяющихся ситуациях. Создание модели IDEF3 подразумевает наличие фактов, полученных от экспертов, и их отображении в виде пяти базовых блоков описания. Потоковые диаграммы последовательности действий являются наиболее известными и широко используемыми. Графические элементы, используемые в этой методологии описания процессов, включают модули единицы поведения, связи старшинства, узлы или перекрестки, модули ссылок и примечаний.

ССЫЛКА (Referents, ссылка, объект ссылки). Ссылка на диаграмме IDEF3 является особым объектом, предназначенным для отображения некоей идеи, концепции или данных, которые не могут быть непосредственно связаны с функцией, стрелкой, перекрестком или UOW (рис. 1). Ссылки расширяют границы понимания диаграммы и упрощают конструкцию описания (тем самым исключают неоднозначность). Ссылкой могут быть дополнительные факты, ограничения или какие-то логические построения, которые позволяют произвести дополнительное описание действия функции. Ссылки расширяют границы понимания диаграммы и упрощают конструкцию описания (тем самым исключают неоднозначность).

Ссылки предназначены для:

• обращения к предварительно определенному функциональному элементу UOW, без дублирования его определения;

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

• организации связи между диаграммами описания процесса PFDD и OSTN объектными диа-граммами.

Согласно нотации IDEF3 могут применяться ссылки трех видов: unconditional - безусловные, synchronous - синхронные, asynchronous - асинхронные. Графически объект ссылки изображается в виде прямоугольника, похожего на прямо-угольник UOW. В качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами UOW или перекрестками пунктирными линиями. На рисунке 2 представлены условные обозначения двух видов базовых ссылок стандарта IDEF3. Каждый из представленных видов ссылки может быть типа «UOB», «SCENARIO», «TS» или «GO TO». Очевидно, что ссылки типа UOB ссылаются на функциональный модуль «UOB», типа «SCENARIO» ссылаются на соответствующий сценарий, типа «TS» (Transition Schematic) – на соответствующую схему, типа «GO TO» - на любой из структурных элементов IDEF3: функциональный модуль, сценарий или узел. При этом, в основном поле символа ссылки указывается её тип и через дробь уникальное наименование блока, сценария, схемы или функции узла. В поле «Locator» указывается уникальный номер идентификатор элемента, указанного в ссылке. Пример использования ссылок показан на рисунке 2.

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

• UOB (unit of behaviour, элементы поведения) - функциональные элементы применятся, когда необходимо подчеркнуть множественное использование какой-либо UOW, но без цикла. Например, UOB "Контроль качества" может быть использован в процессе "Изготовления редуктора" несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся UOW. Номер идентификатора процесса назначается последовательно. В правом нижнем углу UOB располагается ссылка (IDEF0/USER или другие) и используется для указания ссылок либо на элементы из функциональной модели IDEF0, либо для указания на отделы или конкретных исполнителей, которые будут выполнять указанную UOW;

• SCENARIO - название сценария;

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

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

• Примечания могут использоваться для обеспечения дополнительной информации в процессе моделирования, для присоединения к диаграммам иллюстраций, текста, экранных форм, комментариев и т.д. Примечания предоставляют возможность выразить идеи или концепции вместо использования относительных связей. Поле примечания разделено в два раздела. Верхняя часть элемента используется для идентификации примечания и содержит идентификатор примечания, составленный из номера элемента, для которого делается примечание, и номера примечания с префиксом N (например, J1/N1). Нижний часть примечания, называется поле примечания, и предназначена непосредственно для текста, рисунка и т.п. примечания. Стандартом IDEF3 не определены какие-либо ограничения на форму и состав содержания поля примечания, хотя группой разработчиков модели могут быть определены некоторые соглашения для решения каких-либо целей.

• ELAB (elaboration) - используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках.

Помимо деления на виды, методология IDEF3 определяет два вида ссылок по способу запуска. На Рис 2 представлены их условные обозначения. Использование ссылки «Вызвать и продолжить» (Call and Continue Referent) указывает, что элемент, указанный в ссылке, должен быть активизирован до завершения выполнения действия модулем, к которому относится ссылка. Использование ссылки «Вызвать и ждать» (Call and Wait Referent), указывает, что элемент, указанный в ссылке, должен начать и закончить выполнение действия до завершения действия модулем, к которому относится ссылка.

Разделение на ссылку "Запустить и продолжить" и "Запустить и ждать" позволяет описать временные границы выполнения ссылки. Так использование ссылки "Запустить и продолжить" указывает, что упомянутый элемент ссылки должен лишь инициализироваться (активизироваться) раньше, чем выполнение элемента IDEF3, вызывающего элемент ссылку, будет завершено. Для такой ситуации возможно развитие событий представлено на Рис 3. Использование ссылки "Запустить и ждать" указывает, что упомянутая ссылка должна и активизироваться и завершиться прежде, чем элемент его вызвавший завершит свое выполнение. Если используется ссылка "Запустить и продолжить", которая имеет тип UOW, SCENARIO или GO-TO, то на выходе такого элемента не может использоваться стрелка старшинства. Это утверждение становиться очевидным, если изучить график запуска на Рис. 5. 23. При использовании после Ссылки "Запустить и продолжить" стрелки старшинства получаем неопределенную, непоследовательную и противоречивую ситуацию. Существует противоречие в совместном использовании ссылки "Запустить и продолжить" и стрелки старшинства. Если тип ссылки UOB, то наименование этого ссылки должно быть идентично наименованию элемента UOW, который предварительно определен. Если ссылка UOB используется в диаграмме описания процесса и приложена к элементу диаграммы, то во время выполнения вызывающего UOW элемента осуществляется активизация соответствующего UOW элемента (причем временных ограничений по завершению вызываемого UOW элемента нет). Если UOB ссылка приложен к стрелке, которая связывает элементы состояния объекта в диаграмме обекта, то выполнение упомянутого в ссылке UOW должно начаться прежде, чем начнет изменяться состояние объекта. Если UOB ссылку приложен к элементу состояния объекта в объектной диаграмме OSTN, то это указывает, что упомянутый UOW содержит объект в соответствующем состоянии. Если используется ссылку типа Scenario, то соответственно его название должно совпа-дать с названием сценария, на который ссылается вышеуказанный ссылку. При использовании Scenario ссылки в диаграмме описания процесса во время выполнения вызывающего UOW элемента осуществляется активизация вызванного сценария (причем временных ограничений по завершению вызываемого сценария нет). Вызываемый сценарий же выполняется на всю "глубину" декомпозиции. Если Scenario ссылку приложен к стрелке, которая связывает элементы состояния объекта в диаграмме объекта, то выполнение упомянутого в ссылке Scenario должно начаться прежде, чем начнет изменяться состояние объекта. Если тип ссылки UOW или SCENARIO, то такой элемент может являться источником для связи старшинства. Другой особенностью ссылки "Запустить и Ждать" является невозможность использования GO-TO ссылки. На рисунке 5 приведена PFDD диаграмма, описывающая с помощью графических средств IDEF3 документирование производственного процесса окраски детали. В целом, этот процесс состоит непосредственно из самой окраски, производимой на специальном оборудовании и этапа контроля ее качества, который определяет, нужно ли деталь окрасить заново (в случае несоответствия стандартам и выявления брака) или отправить ее в дальнейшую обработку.

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

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