Описание нотации IDEF3

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

Что важно понимать при работе с IDEF3:

1. Нотация является частью семейства IDEF.
2. Нотацию IDEF3 можно взаимоувязать с IDEF0.
3. Пользователи читают графические модели в IDEF3 без подготовки, достаточно комментариев специалиста.

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

Зачем нужна нотация IDEF3

Нотация IDEF3 была создана для описания одновременно технологических и бизнес-процессов. Чтобы понять, чем отличаются бизнес-процессы от технологических, вы можете ознакомиться с моей статьей «Что такое бизнес-процесс». Здесь же я кратко напомню, что в бизнес-процессе может быть несколько вариантов финала. Технологический представляет собой алгоритм, где результат всегда один: создание продукта (услуги). Кроме того, в бизнес-процессах всегда задействованы не только технологии, но и люди. Технологический процесс может быть автоматизирован полностью.

Нотация IDEF3 может быть использована:

1. Как инструкция для сотрудников, которые будут работать в рамках бизнес-процесса.
2. Как иллюстрация предлагаемых решений для заказчика (если есть возможность работать с компьютером, то можно также пользоваться декомпозицией, что особенно удобно).
3. Как алгоритм для настройки IT-системы.

Основные преимущества IDEF3

1. Простота. Элементов не так много, как в некоторых аналогичных решениях. В процессном моделировании используется всего 5 основных объектов. 
2. Ограничение нотации определенными рамками (формат А4). При моделировании важно, чтобы диаграмма не «расползалась» на огромный лист, не была перегружена слишком большим количеством элементов, но при этом она должна быть информативной.

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

Как выглядит нотация IDEF3

Внешне нотация IDEF3 представляет собой набор из прямоугольников и стрелок внутри какого-то элемента. Это может быть:

• основной процесс,
• UOB (один из элементов основного процесса, для которого выполнена декомпозиция),
• нотация IDEF0.

Важные параметры диаграммы IDEF3:

1. Графическая нотация всегда выполняется в черно-белом формате, цветовые решения IDEF3 не использует.
2. Нотация (основная или декомпозиция элемента) должна читаться при распечатке в формате А4.
3. Элементы диаграммы выполняются в соответствии с правилами, которые определяют возможности взаимодействия между ними.

Взаимодействие с 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 включает в себя:

1. UOB Label.  Метка -Название элемента.
2. Node Ref #. Уникальный номер элемента. 
3. IDEF Ref #. Номер IDEF0.

Каждый объект UOB имеет свой уникальный номер. Но при этом для UOB первого уровня (на основной диаграмме) это может быть простая нумерация «1, 2, 3, 4…». В случае декомпозиции объекты диаграммы получают номер основного элемента, который дополняется внутренней нумерацией диаграммы, т.е. декомпозиция UOB 1 будет выглядеть так: «1.1, 1.2, 1.3, 1.4 …».

Узлы (01ctions)

Английский термин «01ction» переводят в русскоязычных учебниках двумя способами – Узел или Соединение.  Но я считаю, что Узел – понятие более точное, так как «стрелки», т.е. процессы, которые входят в узел и выходят из него, могут не только соединяться, но и разъединяться.

Узел – это точка, в которую могут сходиться несколько веток, после чего снова расходиться.

В Узел может вести одна стрелка, а на выходе быть несколько, а может быть и наоборот, на входе – несколько стрелок, на выходе – одна. Потому термин «Соединение» не совсем корректен и вносит некоторую путаницу.

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

Но что делать, если на определенном этапе процесса действия зависят от того, выполнено ли определенное условие?

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

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

Для реализации вариантов действий в зависимости от выполнения определенных условий и были созданы Узлы. Ниже кратко описаны варианты классификации Узлов.

Схождение и расхождение

По количеству входящих и исходящих стрелок узлы в IDEF3 делятся на два вида:

1. Узлы схождения, в которых сходятся ветки разных подпроцессов.
2. узлы расхождения, которые делят один процесс на несколько «веток».

Параллельные и альтернативные

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

Обозначаются такие узлы символом @ (логическое «И»). Все, что исходит из узла с этим символом, запускается параллельно.

Например, у нас есть процесс 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 всегда будут действиями процесса, но одновременно их можно декомпозировать на более простые действия.