Методологии и методы бизнес-процессов созданы для оптимизации деятельности компании, повышения эффективности организации. То есть способ выполнения задач самым логичным образом, позволяющим снизить затраты и повысить качество производимых продуктов и услуг.
На сегодняшний день существует множество методологий моделирования бизнес-процессов. Среди них: IDEF, eEPC, BPMN и другие.
Зачем нужна данная нотация
IDEF это не одна нотация, а целый комплекс. Различаются порядковыми номерами: IDEF0, IDEF1, IDEF2, IDEF3 и так далее. В описании бизнес-процессов чаще всего используются IDEF0 и IDEF3.
Методология IDEF0 подразумевает использование диаграмм. С целью конкретизации бизнес-процессов используют функции, подразделяя их на более простые. IDEF3 — это метод моделирования бизнес-процессов, дополняющий IDEF0. Предназначен для описаний отдельных элементов бизнес-процессов. Сегодня речь пойдет про IDEF3.
IDEF3 — это «сценарий» бизнес-процесса. Представляет собой описание последовательности действий с детальным описанием происходящих событий.
Деятельность и успех любой организации во многом зависит от качества производимой продукции или услуг. Достичь высококачественной продукта можно только в случае тщательного изучения технологии его изготовления, а также соблюдения необходимых правил и нюансов при его создании. Нотация IDEF3 призвана описать процесс создания продукта и ответить на вопрос как это сделать.
Стандарт представляет собой диаграмму, состоящую из блоков, которые олицетворяют определенные действия. Верная последовательность этих действий обеспечивают достижение конечной цели.
Итак, IDEF3 — нотация позволяющая описывать технологические и бизнес-процессы. Стандарт представляет собой подробное описание действий, необходимых для достижения конечной цели, а также определение точной последовательности этих действий. Составляет так называемый сценарий процесса.
Сценарий — это подробное описание свойств объектов, документирование его изменения в процессе технологического процесса. Однако, нотацию IDEF3 можно отнести к универсальным методам моделирования. Поскольку используется как для описания технологических так и бизнес-процессов.
Основные характеристики нотации IDEF3:
- Основным вектором действия нотации является предоставление возможности описания модели, когда действия происходят (выполняются) в заданной последовательности, являются взаимозависимыми, а также детального описания объектов внутри этого процесса, влияющих на результат.
- Как правило, используется для моделирования процессов нижнего уровня.
- Является дополнением нотации IDEF0 — применяется для описания декомпозиии блоков процесса.
- Модель IDEF3 может подразделяться на отдельные блоки, для конкретизации отдельных элементов — возможность декомпозиции.
- IDEF3 не ограничивает жесткими рамками синтаксиса и семантики, что удобно для описания неполных или не целостных систем.
- Описание происходит с помощью диаграммы.
- Методика и рекомендации схожи с нотацией IDEF0.
- Нотация IDEF3 не имеет ограничений в количестве составных частей в рамках диаграммы.
- Все блоки диаграммы являются равноправными.
Нотация IDEF3 применяется для выполнения следующих задач:
- Документирование технологии процесса;
- Определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов.
- Определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта.
- Содействовать принятию оптимальных решений при реорганизации технологических процессов.
- Разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…»
Нотация IDEF3 призвана сделать бизнес-процесс как можно более логичным и информативным. Для этого при моделировании следует использовать декомпозиции. Именно этот инструмент позволит объединить технологические и бизнес-процессы.
Например, вы можете создать нотацию бизнес-процесса работы компании, где одним из элементов будет технологический процесс производства. Далее в рамках декомпозиции вы сможете развернуть технологический процесс в виде отдельного подпроцесса.
Основные преимущества и недостатки методологии
Основным отличием нотации IDEF3 от IDEF0 — это возможность описания логической цепочки действий. Таким образом, IDEF0 описывает «что» делает организация, нотация IDEF3 призвана описать «как» эти действия выполняются.
Преимущества нотации IDEF3:
- простота описания и восприятия — нотация содержит не большое количество элементов
- ограничение нотации определенными рамками (формат А4). При моделировании важно, учитывать размер диаграммы. Также она не должна быть перегружена слишком большим количеством элементов, но при этом она должна быть информативной.
Недостатки нотации IDEF3:
- малая информативность. Для наиболее детального описания процесса требуется использование нотации IDEF3 совместно с IDEF0.
Синтаксис и семантика моделей
Основной идеей нотации IDEF3 это описание сценария бизнес-процесса, то есть описание последовательности действий, ведущих к достижению цели, а также установление их границ. Одним из основополагающих аспектов верной работы созданного процесса, является верны подбор наименования производимый действий. По общему правилу, действия обозначают глаголами или отглагольными существительными.
Сценарий в большинстве случаев требует документирования, поскольку является источником информации для моделируемого процесса.
Первостепенным является верное определение цели моделирования. Проще говоря, правильная формулировка вопросов, ответами на которые будет служить созданный процесс. Чем точнее будет сформулирован вопрос, тем детальнее будет описан сценарий и процесс в целом.
Верное определение границ моделирования также является важным критерием создания процесса. Необходимо четко определить детали, которые войдут и буду играть определенную роль в бизнес-процессе.
Как для любой другой нотации, при моделировании с помощью IDEF3 необходимо верно определить целевую аудиторию процесса — учесть особенности категории людей, для которых создается процесс. Это поможет описать процесс доступным языком.
Основные элементы диаграмм
Основополагающей единицей нотации IDEF3 является диаграмма. В стандарте IDEF3 выделяют два вида диаграмм, описывающие один и тот же сценарий с разных точек зрения:
- Диаграммы, предназначенные для описания последовательности действий внутри процесса (Process Flow Description Diagrams, PFDD).
- Диаграммы, выражающие состояния объекта и изменение его свойств в процессе (Object State Transition Network, OSTN).
Нотация IDEF3 предлагает следующие элементы для моделирования:
- единицы работ;
- связи;
- перекрестки.
UOW (единица работы) — основополагающий элемент нотации. Используется для описания самого процесса. Представляет собой описание действий, производимых для достижения целей. Выражает последовательность этих действий в точном порядке друг за другом, является сценарием процесса.
UOW изображается в виде блоков — прямоугольников и имеют обязательные идентифицирующие атрибуты:
– название. Для формулировки имени UOW используют глаголы или отглагольные существительные, обозначающие процесс действия или события. Наименование блоков в процессе моделирования может меняться.
– порядковый номер блока. В связи с тем, что нотация представляет создание диаграмм, в рамках которых будет подробно описана последовательность действий для достижения цели или создания продукта, нумерация блоков крайне важна. Это позволит определить эту последовательность и расположить блоки в нужном порядке.
Связи — на диаграмме обозначаются в виде стрелок. Выражают порядок действий или очередность выполнения действий в рамках описываемого процесса. По общему правилу связи принято указывать слева направо.
JUNCTION (перекресток, узел). Нотация IDEF3 содержит такой элемент как «перекресток». Предназначен для описания логики взаимодействия между событиями и временной синхронизации активизации элементов диаграмм IDEF3. Элемент дает возможность отойти от четкой последовательности и создать ответвление. Перекрести позволяют создавать параллельность выполнения действий в рамках одного процесса.
Перекрестки подразделяют на два вида: предназначенные для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок.
Обязательным условием нотации IDEF3 является нумерация каждого перекрестка. Ввод перекрестка в диаграмму возможен только после определения и указания на диаграмме типа перекрестка.
Перекрести призваны выполнять логические функции, такие как: И, ИЛИ, ИСКЛЮЧАЮЩЕЕ ИЛИ, быть синхронным или асинхронным.
Диаграмма IDEF3 не имеет ограничений относительно количества использования перекрестков. При этом перекрестки могут быть как идентичными, так и разных видов. Это зависит от особенностей сценария процесса. Использования перекрестков разных видов может привести к ошибкам — логическим несоответствиям.
Правила, которых следует придерживаться, чтобы избежать логического несоответствия:
- Перекресток слияния можно использовать только, если перед ним стоит перекресток разветвления;
- перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ»;
- перекресток для слияния «И» не может следовать за перекрестком для разветвления типа исключающего «ИЛИ»;
- перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И»;
- перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой.
Нотация IDEF3 выдвигает определенные требования к описанию бизнес-процессов. Соблюдение этих условий сделает процесс наиболее информативным.
Перед созданием бизнес-процесса с помощью нотации IDEF3 необходимо:
- определить сценарий (описание действий необходимых для достижения результата);
- границы моделирования (область, за которую не стоит выходить для достижения удобства восприятия модели);
- определит точку зрения (угол мнения, со стороны которого будет производится процесс).
Указанные аспекты предварительно необходимо задокументировать. Это позволит учесть все нюансы при создании бизнес-процесса.
Необходимо верно определить действия и их количество, которые необходимо произвести для достижения конечной цели. Работа бизнес-процесса напрямую зависит от его полноты. Необходимо разобрать путь к достижению цели на определенные блоки, выражающие действия. Кроме того, следует определить объекты, которые будут участвовать в процессе.
Завершающим этапом подготовки к описанию бизнес-процесса с помощью нотации IDEF3 является определение последовательности и параллельности. Необходимо распределить действия в цепочку и обозначить их порядковыми номерами.
IDEF3 — это способ описания технологических и бизнес-процессов. Нотация позволяет составлять схемы даже очень сложных бизнес-процессов в понятной форме. Законченная схема демонстрирует логику процесса, его участников и последовательность их работы.
IDEF3 — способ описания процессов с использованием структурированного метода, позволяющего эксперту в предметной области представить положение вещей как упорядоченную последовательность событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу.
IDEF3 является технологией, хорошо приспособленной для сбора данных, требующихся для проведения структурного анализа системы.
В отличие от большинства технологий моделирования бизнес-процессов, IDEF3 не имеет жестких синтаксических или семантических ограничений, делающих неудобным описание неполных или нецелостных систем. Кроме того, автор модели (системный аналитик) избавлен от необходимости смешивать свои собственные предположения о функционировании системы с экспертными утверждениями в целях заполнения пробелов в описании предметной области. На рис. 3.1 изображен пример описания процесса с использованием методологии IDEF3.
IDEF3 также может быть использован как метод проектирования бизнес-процессов. IDEF3-моделирование органично дополняет традиционное моделирование с использованием стандарта методологии IDEF0. В настоящее время оно получает все большее распространение как вполне жизнеспособный путь построения моделей проектируемых систем для дальнейшего анализа имитационными методами. Имитационное тестирование часто используют для оценки эксплуатационных качеств разрабатываемой системы. Более подробно методы имитационного анализа будут рассмотрены ниже.
Рис.3.1 Описание процесса в методологии IDEF3
Синтаксис и семантика моделей IDEF3
Основой модели IDEF3 служит так называемый сценарий бизнес-процесса, который выделяет последовательность действий или подпроцессов анализируемой системы. Поскольку сценарий определяет назначение и границы модели, довольно важным является подбор подходящего наименования для обозначения действий. Для подбора необходимого имени применяются стандартные рекомендации по предпочтительному использованию глаголов и отглагольных существительных, например «обработать заказ клиента» или «применить новый дизайн».
Сценарий для большинства моделей должен быть документирован. Обычно это название набора должностных обязанностей человека, являющегося источником информации о моделируемом процессе.
Также важным для системного аналитика является понимание цели моделирования — набора вопросов, ответами на которые будет служить модель, границ моделирования — какие части системы войдут, а какие не будут отображены в модели, и целевой аудитории — для кого разрабатывается модель.
Диаграммы
Как и в любой рассматриваемой в этой книге технологии моделирования действий, главной организационной единицей модели IDEF3 является диаграмма. Взаимная организация диаграмм внутри модели IDEF3 особенно важна в случае, когда модель заведомо создается для последующего опубликования или рецензирования, что является вполне обычной практикой при проектировании новых систем. В этом случае системный аналитик должен позаботиться о таком информационном наполнении диаграмм, чтобы каждая из них была самодостаточной и в то же время понятной пользователю.
Единица работы. Действие
Аналогично другим технологиям моделирования действие, или в терминах IDEF3 «единица работы» (Unit of Work — UOW), — другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 3.2)
Рис. 3.2. Изображение и нумерация действия в диаграмме IDEF3
Связи
Связи выделяют существенные взаимоотношения между действиями. Все связи в IDEF3 являются однонаправленными, и хотя стрелка может начинаться или заканчиваться на любой стороне блока, обозначающего действие, диаграммы IDEF3обычно организуются слева направо таким образом, что стрелки начинаются на правой и заканчиваются на левой стороне блоков. В табл. 3.1 приведены три возможных типа связей.
Связь типа «временное предшествование». Как видно из названия, связи этого типа показывают, что исходное действие должно полностью завершиться, прежде чем начнется выполнение конечного действия. Связь должна быть поименована таким образом, чтобы человеку, просматривающему модель, была понятна причина ее появления. Во многих случаях завершение одного действия инициирует начало выполнения другого, как показано на рис. 3.3. В этом примере автор должен принять рекомендации рецензентов, прежде чем начать вносить соответствующие изменения в работу.
|
Изображение |
Название |
Назначение |
|
|
Временнбе предшествование (Temporal precedence) |
Исходное действие должно завершиться, прежде чем конечное действие сможет начаться |
|
|
Объектный поток (Object flow) |
Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться |
|
|
Нечеткое отношение (Relationship) |
Вид взаимодействия между исходным и конечным действиями задается аналитиком отдельно для каждого случая использования такого отношения |
Таблица 2.1
Рис. 3.3. Связь типа “временное предшествование” между действиями 1 и 2.
Связь типа «объектный поток». Одна из наиболее часто встречающихся причин использования связи типа «объектный поток» заключается в том, что некоторый объект, являющийся результатом выполнения исходного действия, необходим для выполнения конечного действия. Обозначение такой связи отличается от связи временного предшествования двойной стрелкой. Наименования потоковых связей должны четко идентифицировать объект, который передается с их помощью. Временная семантика объектных связей аналогична связям предшествования, это означает, что порождающее объектную связь исходное действие должно завершиться, прежде чем конечное действие может начать выполняться.
Связь типа «нечеткое отношение». Связи этого типа используются для выделения отношений между действиями, которые невозможно описать с использованием предшественных или объектных связей. Значение каждой такой связи должно быть определено, поскольку связи типа «нечеткое отношение» сами по себе не предполагают никаких ограничений. Одно из применений нечетких отношений — отображение взаимоотношений между параллельно выполняющимися действиями. Наиболее часто нечеткие отношения используются для описания специальных случаев связей предшествования, например для описания альтернативных вариантов временного предшествования.
Соединения
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий или, наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения. Соединения разбивают или соединяют внутренние потоки и используются для описания ветвления процесса:
- разворачивающие соединения используются для разбиения потока. Завершение одного действия вызывает начало выполнения нескольких других;
- сворачивающие соединения объединяют потоки. Завершение одного или нескольких действий вызывает начало выполнения другого действия.
В табл. 2.2 объединены три типа соединений.
|
Графическое обозначение |
Название |
Вид |
Правила инициации |
|
|
Соединение «и» |
Разворачивающее |
Каждое конечное действие обязательно инициируется |
|
Сворачивающее |
Каждое исходное действие обязательно должно завершиться |
||
|
|
Соединение «эксклюзивное «или»» |
Разворачивающее |
Одно и только одно конечное действие инициируется |
|
Сворачивающее |
Одно и только одно исходное действие должно завершиться |
||
|
|
Соединение «или» |
Разворачивающее |
Одно или несколько конечных действий инициируются |
|
Сворачивающее |
Одно или несколько исходных действий должны завершиться |
Таблица 3.2
Примеры разворачивающих и сворачивающих соединений приведены на рис. 3.4
Рис. 3.4 Два вида соединений
«И»-соединения. Соединения этого типа инициируют выполнение конечных действий. Все действия, присоединенные к сворачивающему «и»-соединению, должны завершиться, прежде чем начнется выполнение следующего действия. На рис. 3.5 после обнаружения
Рис. 3.5 “И” – cоединения
пожара инициируются включение пожарной сигнализации, вызов пожарной охраны, и начинается тушение пожара. Запись в журнал производится только тогда, когда все три перечисленных действия завершены.
Соединение «эксклюзивное «или «». Вне зависимости от количества действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное «или», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое действие, следующее за сворачивающим соединением «эксклюзивное «или», сможет начаться. Если правила активации соединения известны, они обязательно должны быть документированы либо в его описании, либо пометкой стрелок, исходящих из разворачивающего соединения, как показано на рис. 3.6
На рис. 3.6 соединение «эксклюзивное «или» используется для отображения того факта, что студент не может одновременно быть направлен на лекции по двум разным курсам.
Рис. 3.6 Соединение «эксклюзивное “или” »
Соединение «или» предназначено для описания ситуаций, которые не могут быть описаны двумя предыдущими типами соединений. Аналогично связи нечеткого отношения соединение «или» в основном определяется и описывается непосредственно системным аналитиком.
Указатели
Указатели — это специальные символы, которые ссылаются на другие разделы описания процесса. Они используются при построении диаграммы для привлечения внимания пользователя к каким-либо важным аспектам модели.
Указатель изображается на диаграмме в виде прямоугольника, похожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор (табл. 3.3).
|
Тип указателя |
Назначение |
|
ОБЪЕКТ (OBJECT) |
Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект |
|
ССЫЛКА (GOTO) |
Для реализации цикличности выполнения действий. Указатель ССЫЛКА может относиться и к соединению |
|
ЕДИНИЦА ДЕЙСТВИЯ (Unit of Behavior — UOB) |
Для многократного отображения на диаграмме одного и того же действия. Например, если действие «Подсчет наличных» выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB |
|
ЗАМЕТКА (NOTE) |
Для документирования любой важной информации общего характера, относящейся к изображенному на диаграммах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах |
|
УТОЧНЕНИЕ (Elaboration — ELAB) |
Для уточнения или более подробного описания изображенного на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соединений |
Таблица 3.3
Декомпозиция действий
Действия в IDEF3 могут быть декомпозированы или разложены на составляющие для более детального анализа. Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
Для корректной идентификации действий в модели с множественными декомпозициями схема нумерации действий расширяется и наряду с номерами действия и его родителя включает в себя порядковый номер декомпозиции. Например, в номере действия 1.2.5: 1 — номер родительского действия, 2 — номер декомпозиции, 5 — номер действия.
Требования IDEF3 к описанию бизнес-процессов
В этом разделе мы рассмотрим построение IDEF3-диаграммы на основании выраженного в текстовом виде описания процесса. Предполагается, что в построении диаграммы принимают участие ее автор (в основном как системный аналитик) и один или несколько экспертов предметной области, представляющие описание процесса.
Определение сценария, границ моделирования, точки зрения
Для экспертов предметной области, подготавливающих описание моделируемого процесса, должны быть документированы границы моделирования, чтобы им была понятна необходимая глубина и полнота требуемого от них описания. Кроме того, если точка зрения аналитика на процесс отличается от точки зрения эксперта, это должно быть ясно и подробно обосновано.
Вполне возможно, что эксперты не смогут сделать приемлемое описание без их формального опроса автором модели. В таком случае автор должен заранее подготовить перечень вопросов таким же образом, как журналист для интервью.
Определение действий и объектов
Результатом работы экспертов обычно является текстовый документ, описывающий интересующий аналитика круг вопросов. В дополнение к нему может прилагаться письменная документация, позволяющая определить природу изучаемого процесса. Вне зависимости от того, является ли информация текстовой или вербальной, она анализируется и разделяется частями речи для идентификации списка действий (глаголы и отглагольные существительные), составляющих процесс, и объектов (имена существительные), участвующих в процессе.
В некоторых случаях возможно создание графической модели процесса при участии экспертов. Такая модель может быть разработана после сбора всей необходимой информации, что позволяет не отнимать время экспертов на детали форматирования получающихся диаграмм.
Поскольку модели IDEF3 могут одновременно разрабатываться несколькими командами, IDEF3 поддерживает простую схему резервирования номеров действий в модели. Каждому аналитику выделяется уникальный диапазон номеров действий, что обеспечивает их независимость друг от друга. В табл. 3.4 номера действий выделяются каждому аналитику большими блоками. В этом примере аналитик 1 полностью использовал данный ему вначале диапазон номеров и дополнительно получил второй.
|
Аналитик |
Диапазон номеров IDEF3 |
|
1 |
1-99 |
|
2 |
100-199 |
|
3 |
200-299 |
|
1 |
300-399 |
Таблица 3.4
Последовательность и параллельность
Если модель создается после проведения интервью, аналитик должен принять решение по построению иерархии участвующих в модели диаграмм, например, насколько подробно будет детализироваться каждая отдельно взятая диаграмма. Если последовательность или параллельность выполнения действий окончательно не ясна, эксперты могут быть опрошены вторично (возможно, с использованием черновых вариантов незаконченных диаграмм) для получения недостающей информации. Важно, однако, различать предполагаемую (появляющуюся из-за недостатка информации о связях) и явную (указанную в описании эксперта) неясности.
Выводы. IDEF3 — это способ описания бизнес-процессов, который нужен для описания положения вещей как упорядоченной последовательности событий с одновременным описанием объектов, имеющих непосредственное отношение к процессу. IDEF3 хорошо приспособлен для сбора данных, требующихся для проведения структурного анализа системы. Кроме того, IDEF3 применяется при проведении стоимостного анализа поведения моделируемой системы.
IDEF3
— способ описания процессов, основной
целью которого является обеспечение
структурированного метода, используя
который эксперт в предметной области
может описать положение вещей как
упорядоченную последовательность
событий с одновременным описанием
объектов, имеющих непосредственное
отношение к процессу.
Технология
IDEF3 хорошо приспособлена для сбора
данных, требующихся для проведения
структурного анализа системы. В отличие
от большинства технологий моделирования
бизнес-процессов, IDEF3 не имеет жестких
синтаксических или семантических
офаничений, делающих неудобным описание
неполных или нецелостных систем. Кроме
того, автор модели (системный аналитик)
избавлен от необходимости смешивать
свои собственные предположения о
функционировании системы с экспертными
утверждениями в целях заполнения
пробелов в описании предметной области.
На рис. 1.1 изображен пример описания
процесса с использованием методологии
IDEF3.
Рис.
1.1. Описание процесса в методологии
IDEF3
Технология
IDEF3 также может быть использована как
метод проектирования бизнес-процессов.
ГОЕРЗ-моделирование органично дополняет
традиционное моделирование с использованием
стандарта IDEFO. В настоящее время оно
получает все большее распространение
как вполне жизнеспособный путь построения
моделей проектируемых систем для
дальнейшего анализа имитационными
методами. Имитационное тестирование
часто используют для оценки эксплуатационных
качеств разрабатываемой системы, более
подробно методы имитационного анализа
будут рассмотрены позднее.
Синтаксис
и семантика моделей IDEF3
Модели
IDEF3
Основой
модели IDEF3 служит так называемый сценарий
бизнес-процесса, который выделяет
последовательность действий или
подпроцессов анализируемой системы.
Поскольку сценарий определяет назначение
и границы модели, довольно важным
является подбор подходящего наименования
для обозначения действий. Для подбора
необходимого имени применяются
стандартные рекомендации по
предпочтительному использованию
глаголов и отглагольных существительных.
Например, «Обработать заказ клиента»
или «Применить новый дизайн» —
вполне подходящие названия сценариев.
Точка
зрения для большинства моделей должна
быть явным образом документирована.
Обычно это название набора должностных
обязанностей человека, являющегося
источником информации о моделируемом
процессе.
Для
системного аналитика также важно
понимание цели моделирования — набора
вопросов, ответами на которые будет
служить модель, границ моделирования
(какие части системы войдут в модель а
какие не будут в ней отображены) и целевой
аудитории (для кого разрабатывается
модель).
Диаграммы
Как
и в любой рассматриваемой в этой книге
технологии моделирования действий,
главной организационной единицей модели
IDEF3 является диаграмма. Взаимная
организация диаграмм внутри модели
IDEF3 особенно важна в случае, когда модель
заведомо создается для последующего
опубликования или рецензирования, что
является вполне обычной практикой при
проектировании новых систем. В этом
случае системный аналитик должен
позаботиться о таком информационном
наполнении диаграмм, чтобы каждая из
них была самодостаточной и в то же время
понятной читателю.
Единица
работы. Действие
Аналогично
другим технологиям моделрфования
действие, или в терминах IDEF3 «единица
работы» (Unit of Work — UOW) — другой важный
компонент модели. Диаграммы IDEF3 отображают
действие в виде прямоугольника. Как уже
отмечалось, действия именуются с
использованием глаголов или отглагольных
существительных, каждому из действий
присваивается уникальный идентификационный
номер. Этот номер не используется вновь
даже в том случае, если в процессе
построения модели действие удаляется.
В диаграммах IDEF3 номер действия обычно
предваряется номером его родителя (рис.
1.2).
Рис.
1.2. Изображение и нумерация действия в
диаграмме IDEF3
Связи
Связи
выделяют существенные взаимоотношения
между действиями. Все связи в IDEF3 являются
однонаправленными, и, хотя стрелка может
начинаться или заканчиваться на любой
стороне блока, обозначающего действие,
диаграммы IDEF3 обычно организовываются
слева направо таким образом, что стрелки
начинаются на правой и заканчиваются
на левой стороне блоков. В табл. 1.1
приведены три возможных типа связей.
Таблица
1.1. Типы связей в модели IDEF3
Связь
типа «Временное предшествование».
Как видно из названия, связи этого типа
отражают, что исходное действие должно
полностью завершиться, прежде чем
начнется выполнение конечного действия.
Связь должна быть поименована таким
образом, чтобы человеку, просматривающему
модель, была понятна причина ее появления.
Во многих случаях завершение одного
действия инициирует начало выполнения
другого, как показано на рис. 1.3. В этом
примере автор должен принять рекомендации
рецензентов, прежде чем начать вносить
соответствующие изменения в работу.
Рис.
1.3. Связь типа «Предшествование»
между действиями 1.1 и 1.2
Связь
типа «Объектный поток». Одной из
наиболее часто встречающихся причин
использования связи типа «объектный
поток» состоит в том, что некоторый
объект, являющийся результатом выполнения
исходного действия, необходим для
выполнения конечного действия. Такая
связь отличается от связи временного
предшествования двойным концом
обозначающей ее стрелки. Наименования
потоковых связей должны четко
идентифицировать объект, который
передается с их помощью. Временная
семантика объектных связей аналогична
связям предшествования. Это означает,
что порождающее объектную связь исходное
действие должно завершиться, прежде
чем конечное действие начнет выполняться,
как показано на рис. 1.4. В приведенном
примере счет на оплату услуг является
результатом выполнения действия 1.1.
Счет необходим для проведения оплаты
услуг.
Рис.
1.4. Объектная связь между действиями
1.1 и 1.2
Связь
типа »’Нечеткое отношение». Связи
этого типа используются для выделения
отношений между действиями, которые
невозможно описать с использованием
предшественных или объектных связей.
Значение каждой такой связи должно быть
определено, поскольку связи типа
«Нечеткое отношение» сами по себе
не предполагают никаких ограничений.
Одно из применений нечетких отношений
— отображение взаимоотношений между
параллельно выполняющимися действиями.
Рис. 1.5 иллюстрирует фрагмент процесса
запуска бензопилы с водяным охлаждением
и нечеткое отношение между действиями
«Запустить двигатель» и «Запустить
водяной насос». Название стрелки
может быть использовано для описания
природы отношения, более подробное
объяснение может быть приведено в виде
отдельной ссылки.
Рис.
1.5. Связь типа «Нечеткое отношение»
Наиболее
часто нечеткие отношения используются
для описания специальных случаев связей
предшествования, например для описания
альтернативных вариантов временного
предшествования. Обратимся еще раз к
рис. 1.3. На рис. 1.6 вертикальные линии
показывают начало и окончание действий
1.1 и 1.2, имеющих предшественную связь. В
соответствии с рисунком внесение
исправлений в работу начинается ПОСЛЕ
принятия всех замечаний от рецензентов.
Рис.
1.6. Временная шкала выполнения действия
для 2.3
Альтернативная
предшественной связи с рис. 1.3 связь
нечеткого отношения представлена на
рис. 1.7. В этом примере внесение исправлений
начинается по мере получения замечаний
от рецензентов, т.е. до непосредственного
окончания действия по принятию замечаний.
Рис.
1.7. Альтернатива связи предшествования
На
рис. 1.8 приведена соответствующая этой
ситуации временная шкала.
Рис.
1.8. Альтернативная временная шкала
Отметим
еще раз необходимость четкого
документирования временных ограничений
между действиями, соединенными нечетким
отношением. В качестве примера рассмотрим
еще одну временную шкалу (рис. 1.9) для
рис. 1.3.
Рис.
1.9. Другой вариант альтернативной
временной шкалы
в
случае, изображенном на рис. 1.9, внесение
исправлений будет начато после получения
первых замечаний, однако будет закончено
ПЕРЕД тем, как все замечания от рецензентов
будут получены и обработаны.
Оба
рассмотренных выше варианта временной
альтернативной шкалы могут иметь место
в реальности, поэтому корректная
интерпретация нечеткого отношения
должна быть документирована в модели.
Важно отметить, что корректность в этом
случае означает именно интерпретацию,
которая в точности отображает
документируемую ситуацию, а не
интерпретацию, более эффективную для
работы системы, с точки зрения аналитика.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Аннотация
Что из себя представляет нотация IDEF3. Из каких элементов состоит? Как используют эту нотацию и как она связана с IDEF0. О этом и многом другом вы узнаете из данной статьи.
Оглавление
Содержание
Внедрением IT-систем я занимаюсь уже много лет. И поначалу у меня постоянно возникали проблемы коммуникации с заказчиками, приходилось тратить много времени и сил на то, чтобы пояснить свои идеи и предложения. Решением вопроса оказалось использование графических нотаций. О том, как работать с IDEF0, я уже рассказывал в прошлых статьях. Сегодня предлагаю поговорить о нотации IDEF3.
Что важно понимать при работе с IDEF3:
- Нотация является частью семейства IDEF.
- Нотацию IDEF3 можно взаимоувязать с IDEF0.
- Пользователи читают графические модели в IDEF3 без подготовки, достаточно комментариев специалиста.
С точки зрения разработчика проектирование в IDEF3 требует определенных знаний и практических навыков. В представленном ниже обзоре мы обсудим сферы применения IDEF3, изучим основные элементы, разберемся, как ими правильно пользоваться.
Нотация IDEF3 была создана для описания одновременно технологических и бизнес-процессов. Чтобы понять, чем отличаются бизнес-процессы от технологических, вы можете ознакомиться с моей статьей «Что такое бизнес-процесс». Здесь же я кратко напомню, что в бизнес-процессе может быть несколько вариантов финала. Технологический представляет собой алгоритм, где результат всегда один: создание продукта (услуги). Кроме того, в бизнес-процессах всегда задействованы не только технологии, но и люди. Технологический процесс может быть автоматизирован полностью.
Нотация IDEF3 может быть использована:
- Как инструкция для сотрудников, которые будут работать в рамках бизнес-процесса.
- Как иллюстрация предлагаемых решений для заказчика (если есть возможность работать с компьютером, то можно также пользоваться декомпозицией, что особенно удобно).
- Как алгоритм для настройки IT-системы.
Основные преимущества IDEF3
- Простота. Элементов не так много, как в некоторых аналогичных решениях. В процессном моделировании используется всего 5 основных объектов.
- Ограничение нотации определенными рамками (формат А4). При моделировании важно, чтобы диаграмма не «расползалась» на огромный лист, не была перегружена слишком большим количеством элементов, но при этом она должна быть информативной.
Для реализации сочетания лаконичности и максимальной информативности в IDEF3 присутствует возможность использования декомпозиции. Именно через нее объединяют в общей системе бизнес-процессы и технологические. Например, вы можете создать нотацию бизнес-процесса работы компании, где одним из элементов будет технологический процесс производства. Далее в рамках декомпозиции вы сможете развернуть технологический процесс в виде отдельного подпроцесса.
Как выглядит нотация IDEF3
Внешне нотация IDEF3 представляет собой набор из прямоугольников и стрелок внутри какого-то элемента. Это может быть:
- основной процесс,
- UOB (один из элементов основного процесса, для которого выполнена декомпозиция),
- нотация IDEF0.
Важные параметры диаграммы IDEF3:
- Графическая нотация всегда выполняется в черно-белом формате, цветовые решения IDEF3 не использует.
- Нотация (основная или декомпозиция элемента) должна читаться при распечатке в формате А4.
- Элементы диаграммы выполняются в соответствии с правилами, которые определяют возможности взаимодействия между ними.
Cтоит задача по моделированию в IDEF3, напишите мне или позвоните по телефону +7(495)320-50-40, я помогу Вам разобраться!
Написать
Взаимодействие с IDEF0
IDEF3 можно использовать как самостоятельную нотацию или в качестве декомпозиции для IDEF0. Вы можете в IDEF0 описать любую функцию, после чего декомпозировать ее в IDEF3. Для этого в элементе IDEF0 нужно указать специальную метку под названием «IDEF REF», которая указывает на то, к какой IDEF выбранный процесс относится.
Т.е. вы создаете в IDEF0 функциональную модель работы компании или ее подразделения, где продумываете стратегически важные решения. После того, как функциональная модель проверена, изучена и утверждена, каждую функцию декомпозируете в IDEF3.
В функциональном моделировании функции — это «черные ящики», где описана только суть этапа без подробных действий. При декомпозиции в IDEF3 вы переходите к процессному моделированию каждого этапа отдельно. Это упрощает работу и позволяет переходить от общего к частностям и обратно.
Основные элементы IDEF3
Как и любая другая методология моделирования процессов, IDEF3 отличается особенностями синтаксиса, отображения графических объектов, имеет свою терминологию и т.д. Ниже мы разберемся с основными понятиями. Но важно понимать, что эта статья – ознакомительная, ее нельзя считать полноценным учебником по IDEF3. Потому многие объекты и возможности останутся за рамками публикации.
UOB (Units of behaviour)
Элементы UOB являются центральными компонентами любой графической нотации на IDEF3. Сам термин расшифровывается как «Units of behaviour», что в переводе с английского означает «Единицы поведения».
Иногда в учебниках или статьях можно встретить не совсем точную терминологию, которая звучит следующим образом: Units of Work (UOW), т.е. единицы работы. Такой вариант терминологии приводит к многочисленным ошибкам, так как сам термин оказывается неточным и охватывает не все возможные варианты использования элемента.
Элементы UOB – это любые виды действия, именно потому в точном переводе речь идет о поведении. Это может быть отдельный бизнес-процесс, задача, группа задач, технологический процесс и т.д.
Для лучшего понимания я предлагаю снова обратиться к сравнению с BPMN. В этой нотации основной элемент – это задача, т.е. конкретное действие. Ее невозможно декомпозировать и уточнить впоследствии. В IDEF3 UOB может быть, как конкретной задачей, так и «черным ящиком», объединившем в себе целую последовательность задач, увидеть которые можно при декомпозиции.
UOB включает в себя:
- UOB Label. Метка -Название элемента.
- Node Ref #. Уникальный номер элемента.
- IDEF Ref #. Номер IDEF0.
Каждый объект UOB имеет свой уникальный номер. Но при этом для UOB первого уровня (на основной диаграмме) это может быть простая нумерация «1, 2, 3, 4…». В случае декомпозиции объекты диаграммы получают номер основного элемента, который дополняется внутренней нумерацией диаграммы, т.е. декомпозиция UOB 1 будет выглядеть так: «1.1, 1.2, 1.3, 1.4 …».
Узлы (01ctions)
Английский термин «01ction» переводят в русскоязычных учебниках двумя способами – Узел или Соединение. Но я считаю, что Узел – понятие более точное, так как «стрелки», т.е. процессы, которые входят в узел и выходят из него, могут не только соединяться, но и разъединяться.
Узел – это точка, в которую могут сходиться несколько веток, после чего снова расходиться.
В Узел может вести одна стрелка, а на выходе быть несколько, а может быть и наоборот, на входе – несколько стрелок, на выходе – одна. Потому термин «Соединение» не совсем корректен и вносит некоторую путаницу.
Когда речь идет о процессе, мы обыкновенно предполагаем линейную последовательность действий. На входе у нас какие-то данные и поставленная задача, на выходе после выполнения определенной последовательности действий – решение.
Но что делать, если на определенном этапе процесса действия зависят от того, выполнено ли определенное условие?
Например, работник склада проверяет документ на наличие подписи ответственного лица. Если подпись присутствует, товар выдается. Если нет, документ возвращается владельцу и человек отправляется за нужной подписью. Ситуация очень распространенная.
К слову трудовые процессы без подобных «развилок» практически невозможно представить. Где-то надо проверить подпись или получение оплаты, в другом случае убедиться, что покупатель находится дома и готов принять товар с доставки. В процессе продажи развилок вообще очень много, ведь отказ покупателя от продолжения переговоров возможен практически на любом этапе.
Для реализации вариантов действий в зависимости от выполнения определенных условий и были созданы Узлы. Ниже кратко описаны варианты классификации Узлов.
Схождение и расхождение
По количеству входящих и исходящих стрелок узлы в IDEF3 делятся на два вида:
- Узлы схождения, в которых сходятся ветки разных подпроцессов.
- узлы расхождения, которые делят один процесс на несколько «веток».
Параллельные и альтернативные
Параллельный узел имеет обозначение – логическое И. Он указывает, что подпроцессы, которые запускаются после узла или, наоборот, были запущены перед узлом, выполняются одновременно.
Обозначаются такие узлы символом @ (логическое «И»). Все, что исходит из узла с этим символом, запускается параллельно.
Например, у нас есть процесс A, далее идет параллельный узел, из которого выходят стрелки к процессам В, С и D. Информация из процесса A отправляется в узел, после чего запускаются все исходящие процессы, т.е. те самые В, С и D.
По времени эти процессы могут запускаться в произвольном порядке. В некоторых случаях процесс В уже будет завершен, а процесс D только начнется. Эти нюансы обычно описываются дополнительно – текстом и при помощи специальных диаграмм.
Самое главное, что нужно понимать. Все процессы после параллельного узла обязательно будут запущены. И выполнены они будут параллельно, т.е. независимо друг от друга, каждый из них основан только на результатах процесса А.
В обозначении альтернативного узла присутствует буква «О» или «X». В Это первые буквы латинского написания ИЛИ:
- Не исключающее OR. В этом случае после узла могут запускаться один или несколько подпроцессов, в зависимости от условия, которое выполняется в узле. Т.е. ветки, которые удовлетворяют условию, выполняются, остальные – нет.
- Исключающее XOR. В таком типе узлов условие более жесткое, в результате исполняется только одна из веток, которая полностью соответствует условию.
Таким образом, для реализации различных вариантов проверки условий у нас есть:
- Логическое И – выполняются параллельно все ветки процессов.
- Логическое ИЛИ – выполняются только те ветки, которые удовлетворяют определенным условиям.
- Исключающее ИЛИ – выполняется только одна ветка, в точности подходящая под нужные условия.
Синхронные и асинхронные узлы
Здесь речь идет о параллельно запущенных процессах в результате узла И или не исключающего условного ИЛИ.
- Асинхронные узлы. Если процессы могут запускаться асинхронно, то есть в разное время, то узел имеет одну черту внутри прямоугольника. При этом, например, процесс B может быть запущен в 8 часов утра, а процесс C – в 2 часа дня или позже, в зависимости от каких-то условий.
- Синхронные узлы. Если нам важно, чтобы процессы после узла были запущены одновременно, необходимо использовать синхронный узел. Он обозначается двумя вертикальными линиями внутри прямоугольника – слева и справа.
Например, компания получает сложный производственный заказ. И очень важно, чтобы процессы расчета цены и технические возможности были рассчитаны как можно быстрее. Ответственный сотрудник передает информацию одновременно в отдел маркетинга для определения цены и в конструкторский отдел для решения технических вопросов. Такая синхронность гарантирует, что информация своевременно поступит в оба подразделения, а ответы будут получены в сжатые сроки.
Интересно, что синхронные узлы могут быть не только исходящими, но и входящими. В этом случае узел активируется только тогда, когда все параллельные процессы окончатся. Более того, очень важно, чтобы они окончились одновременно.
Само собой, что полная синхронизация возможна только в случае автоматических операций. В бизнес-процессах участвуют люди, потому кто-то может окончить работу раньше, а кто-то несколько затянет процесс. Но в случае синхронного узла, передать в него результаты работы можно будет только одновременно, когда все параллельные процессы будут завершены.
Референты (Referents) and примечания (Notes)
Референты (Referens) и примечания (Notes) необходимы для более глубокого понимания смысла и упрощения конструкций, т.е. для облегчения их восприятия и устранения любых вариантов невнятности или разночтений.
Существуют нескольких типов таких объектов:
- Call and Continue Referent (Вызови и продолжай). Используется для вызова ранее описанного UOB без дублирования. Указывает, что в процессе выполнения основного UOB необходимо будет обратиться к описанному ранее до момента завершения текущего UOB.
- Call and Wait Referent (Вызови и жди). Используется для передачи управления или определения цикла в процессе обработки. Показывает, что в процессе выполнения текущего UOB нужно обратиться к описанному ранее, после чего обязательно дождаться его завершения, и только потом можно будет завершить текущий UOB.
- Note (Примечание).
В описании референта обязательно указывают его тип, а также метку UOB или другого объекта, с которым будет проводиться работа. Для определения типа перехода используется локатор.
Связи (Links)
Связи – это связующее звено между функциональными элементами (UOB), отражающие порядок протекания процессов. В первую очередь, их использование обусловлено необходимостью обеспечения наиболее значимых по характеру взаимосвязей, имеющихся между функциональными элементами процесса. Поэтому их цель – привлечь внимание именно к ключевым аспектам взаимодействия между всеми элементами цепи. Все связи обязательно описываются в специальном документе Precedence Link Elaboration Document.
Связи необходимы для того, чтобы указывать последовательность движения по схеме процесса. Они помогают понять, какое действие совершается после какого, что необходимо для выполнения очередного действия, куда двигаться дальше, в зависимости от результата.
Связи бывают трех основных видов:
- Simple Precedence Link – простые связи предшествования;
- Constrained Precedence Links – ограниченные связи предшествования;
- Relational Link – связь отношения.
Связь простого предшествования может быть только одного вида (простая стрелка). Ограниченных связей существует 4 разных вида, о них мы поговорим немного позже. Связь отношения выглядит даже не стрелкой, а пунктирной линией, она также бывает только одного вида.
Простая связь (Simple Precedence Link)
Этот тип связи выглядит как обычная линия, на конце которой располагается стрелка, ведущая от одного объекта UOB к другому. Этот тип связей наиболее распространенный, такие стрелки вы увидите в любой модели.
Важно понимать, что простая связь указывает на то, что процесс B выполняется после процесса A. Но при этом для выполнения процесса B, процесс A не является обязательным.
Например, в процессе поставки товара от поставщика:
- A – заказ поставщику;
- B – приход товара (постановка на учет).
Обычная последовательность – сначала заказ товара поставщику, а потом его получение. Но в отдельных случаях товар может поступить без предварительного заказа, и его также можно оприходовать (процесс B выполняется, а процесс A оказался ненужным).
Ограниченные связи (Constrained Precedence Links)
Как уже было сказано ранее, этих связей существует 4 вида. Эти ограничения помогают указать, как система должна работать, что помогает не только описывать процессы, но и моделировать разные варианты.
1. Связь выглядит, как линия с двумя стрелками, имеющими одно направление.
Первая находится на конце линии, вторая – посредине. Этот вариант ограниченной связи указывает, что для выполнения пункта B работа по пункту A должна быть проведена в обязательном порядке.
Например, рассмотрим последовательность – создание (A) и согласование(B) рабочего табеля. В этом случае пункт B ни в коем случае не может быть выполнен без предварительного исполнения пункта A, так как чтобы согласовывать табель, его необходимо сначала создать.
2. Связь выглядит, как линия с двумя стрелками, но расположенная посредине направлена в обратную сторону.
Этот вариант ограничения указывает на то, что элемент B (второй по последовательности) может быть выполнен раньше элемента A (первый по порядку). Более того, для того, чтобы действия в элементе A были успешно завершены и можно было перейти к следующим этапам, элемент B должен выполняться в обязательном порядке.
Например, в идеале нет смысла создавать документ расчета табельного времени, если его после этого не утверждать и не пользоваться. Но в реальности бывает, что табель уже составлен, а сотрудник увольняется. В итоге, уже после отправки на утверждение табель приходится переделывать.
3. Связь выглядит, как линия со стрелкой на конце и многоугольником («звездочкой») посередине.
Означает, что элементы A и B взаимосвязаны, т.е. выполнение одного без другого невозможно и бессмысленно, причем, это правило работает в обе стороны.
4. Связь выглядит, как линия со стрелкой на конце и квадратом посредине.
Здесь наоборот, последовательность действий может быть любой, и взаимосвязь между элементами минимальна. Она будет зависеть от решения администратора и текущей ситуации.
Связь отношения (Relational Link)
Этот тип связей обозначается пунктирной линией и применяется, чтобы подчеркнуть возможную взаимосвязь между двумя элементами. Они не несут в себе никаких жестких ограничений и предопределенностей. Использование этого типа связей необходимо расшифровывать в сопроводительной документации.
Например, связь отношения, добавленная к нашему примеру с получением табеля, означает, что часть сотрудников могут самостоятельно создавать и отправлять на утверждение свои табеля, а часть не имеет такого права.
Маркировка и нумерация связей
Все связи, которые используются в схеме, в обязательном порядке маркируются и нумеруются. Для маркировки используются аббревиатуры от названий типов связей:
- СП или PL (от precedence links) – обозначения для связей предшествования;
- СО или DL (от dashed links) – связи отношений.
Таким образом, «СО1», «СО2», «СО3» будут обозначать разные связи предшествования, каждая из которых получила уникальное обозначение, что также отображается в сопроводительной документации.
Кроме того, важно понимать, что описанные выше типы связей – единственные существующие в нотации IDEF3. Иногда в публикациях встречаются какие-то другие обозначения и разновидности «стрелок». Некоторые из них могут показаться полезными, но к стандарту IDEF3 они не имеют никакого отношения.
Процессная и объектная семантика (Process Schematic Symbols и Object Schematic Symbols)
Все элементы IDEF3 делятся на два основных типа – процессный (Process Schematic Symbols) и объектный (Object Schematic Symbols). Как и следует из названий, в первом случае речь идет об описании процессов, во втором – о работе с объектами. Такое разделение позволяет IDEF3 объединять в себе различные подходы к моделированию.
Важно понимать, что при работе с процессной семантикой UOB – это обозначение определенного действия. Они могут выглядеть похожими на функции, более того, действие UOB можно декомпозировать, но на самом деле, при работе с процессами UOB остается действием, а не функцией.
Для сравнения, при работе с нотациями бизнес-процессов BPMN декомпозиция невозможна, здесь каждый элемент – всегда действие без вариантов. При работе с нотациями IDEF0 мы имеем дело с функциями и только с ними. Они могут декомпозироваться, но всегда остаются элементами функционального моделирования.
IDEF3 позволила объединить преимущества двух подходов. В результате мы можем работать с процесcным моделированием, в этом случае UOB всегда будут действиями процесса, но одновременно их можно декомпозировать на более простые действия.
Бизнес-консультант с большим практическим опытом работы в России и ближайшем зарубежье. Автор
многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса. Живу и работаю в
Москве, руководитель компании Trinion. Делюсь опытом посредством блога на сайте trinion.org
Юлия Лайши
Эксперт по предмету «Экономика»
преподавательский стаж — 5 лет
Задать вопрос автору статьи
Сущность методологии описания бизнес-процессов
Определение 1
Методология описания бизнес-процессов – это набор методов, объединенных единой концепцией и применяемых для описания хозяйственной деятельности системы с целью управления ею.
Работа предприятия в рыночных условиях сопряжена с постоянными рисками и борьбой за выживание. Управление и регулирование внутренними процессами компании с учетом вероятности воздействия различных факторов внешней и внутренней среды, позволяет снижать степень негативного воздействия рисков, а также максимально эффективно использовать потенциал компании. Моделирование бизнес-процессов является действенным инструментом структуризации многообразных внутренних связей и объектов предприятия.
Сделаем домашку
с вашим ребенком за 380 ₽
Уделите время себе, а мы сделаем всю домашку с вашим ребенком в режиме online
Для организации деятельности фирмы могут применяться различные методологии описания бизнес-процессов. Методология ведения проектов представляет собой реинжиниринг действующих процессов. Этот подход ведет к скачкообразному резкому изменению работы предприятия. Часто применяется для преобразований стоимости, производственных темпов или сервиса.
Для реализации методологий описаний бизнес-процессов применяются программные продукты, позволяющие создать единое информационное поле внутри предприятия, обеспечивающее доступ к необходимой информации лицам на различных должностях. Современные программы требуют адаптации под нужды каждого конкретного объекта хозяйствования.
Еще одна методология – это методология анализа и моделирования бизнес-процессов. Именно они помогают структурировать принимаемые управленческие решения, следовать стратегии и тактике предприятия. Моделирование бизнес-процессов позволяет не только разработать внутренние блоки взаимодействия, этапы производства, участие производственных факторов. Они так же помогают обозначить источники входных данных.
«Методология idef3» 👇
Существуют как государственные, так и частные корпоративные методологии описания бизнес-процессов. В основе их формирования лежат государственные стандарты, описывающие нормы осуществления тех или иных производственных действий. Возможность моделирования бизнес-процессов является мощным инструментом в руках руководителя компании. Она дает возможность не только структурировать все процессы, но также осуществлять качественный контроль над исполнением управленческих решений, отслеживать результат хозяйственной деятельности, устанавливать обратную связь.
Методология IDEF3
Моделирование бизнес-процессов стандартом IDEF0 не учитывает временную последовательностью и алгоритм планируемых работ. Для этих целей был усовершенствован стандарт IDEF0, и выпущен IDEF3. Последний применяется для разбивки работ на отдельные этапы. То есть, при планировании бизнес-процессов появляется возможность раскладывать производственный процесс на множество подзадач. Такой подход позволяет рассматривать альтернативные варианты. В этой модели особое внимание уделяется нумерации каждого подпроцесса. Он содержит в своем названии номер родительской работы, порядковый номер в декомпозиции и собственный номер в рамках рассматриваемой диаграммы.
Замечание 1
Особенностью стандарта IDEF3 можно назвать возможность связывать объект с другими работами. Это дает возможность сделать модель более наглядной, дополнив ее необходимой информацией.
С помощью IDEF3 строятся следующие модели:
- Модели работ с учетом логики их реализации, что дает возможность рассмотреть весь поток работ в рамках одного субъекта хозяйствования.
- Модель переходных состояний, то есть положения, в которых может существовать исследуемый объект в рамках производственного процесса.
Методология IDEF3 позволяет моделировать и анализировать сценарии, которые могут развернуться в практической деятельности экономического субъекта. Например, можно рассмотреть ситуацию экстренного закрытия магазина, последовательность действий в случае ее наступления. Методология позволяет проработать узкие места, разработать инструкции по осуществлению последовательности действий, прописать отдельные блоки бизнес-процессов предприятия.
Связи между работами в методологии IDEF3 делятся на три блока. Связь предшествования в модели выражает ситуацию, когда рассматриваемая работа может быть выполнена в строгом порядке. То есть, сначала выполняется первая работа, затем вторая. Связь отношения описывает ситуацию, когда вторая работа может начаться или закончится до того, как начнется или закончится первая работа. Связь потоков объектов описывает применение первой работы в последующих работах.
Блоки модели IDEF3 отражают следующие данные:
- Единица работы показывает конкретную задачу, выполняемую сотрудником или подразделением.
- Ссылки применяются для отображения взаимодействия блока с другими диаграммами.
- Связи в виде стрелок описывают взаимодействие работ. Например, связь предшествования изображается единой линией, отображает этап перехода от одной работы к другой. Пунктирной линией показывается связь отношения между объектами. Потом объектов указывает связь объекта с несколькими объектами сразу, обозначается линией с двумя и более стрелками. Перекресток слияния указывает на объект, объединяющий несколько видов работ. А перекресток ветвления наоборот показывает разбивку объекта на подзадачи.
Замечание 2
Методология IDEF3 показывает те места, где могут быть приняты альтернативные управленческие решения. Кроме того, она помогает отследить этапы перехода во времени от одного типа работ к следующим.
Диаграмма в стандарте IDEF3
В методологии IDEF3 существует два вида диаграмм. Они дают возможность рассматривать один и тот же бизнес-процесс с разных сторон. Существуют диаграммы описания последовательности процессов, а также диаграммы состояния объекта, его трансформации под влиянием бизнес-процесса. Например, при формировании диаграммы, описывающей создание блага, первый вид диаграмм опишет последовательность воздействия труда на ресурс, а вторая диаграмма покажет, как видоизменяется объект под влиянием труда.
С помощью графических инструментов IDEF3, руководители предприятий получают возможность документировать бизнес-процессы, создавать служебные инструкции. Кроме того, описанный процесс позволяет осуществлять эффективный контроль над его исполнением, а также отслеживать результаты труда.
Диаграмма, описывающая последовательность процессов, позволяет увидеть движение объекта в момент производства со стороны. Диаграмма состояния и изменения объекта показывает его преобразования с точки зрения самого объекта. Состояния объекта, как правило, показываются в кругах, изменения – направленными линиями.
Рассмотрим следующий рисунок:
Рисунок 1. Процесс предпродажной подготовки блага. Автор24 — интернет-биржа студенческих работ
На нем показан процесс предпродажной подготовки блага. Он показывает всю цепочку действии, которые необходимо произвести, чтобы выпустить новую единицу продукции. Сначала создается управляющее решение, и доводится до сотрудников соответствующим распорядительным документом. Далее процесс разбивается на три подзадачи, включающих в себя разработку и внедрение технической документации, сбора информации и формирования соответствующих материалов, закупку необходимых ресурсов, полуфабрикатов и расходных материалов. Важно осуществить мероприятия по подготовке персонала к работе над новым видом блага. Возможно потребуются новые знания, навыки, расходы на обучение в денежной и временной форме. Соединение новых материалов и навыков сотрудников позволит создать опытный образец, который в последующем будет тестироваться на рынке.
Замечание 3
Методология и диаграммы IDEF3 позволяют разбивать блоки на более мелкие составляющие. Такой инструмент дает возможность более детального описания каждой задачи.
Находи статьи и создавай свой список литературы по ГОСТу
Поиск по теме