Декомпозиция бизнес процессов в нотации idef0

IDEF0 — нотация графического моделирования, используемая для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающих эти функции. Стандарт IDEF0 (Integration Definition for Function Modeling) утвержден в США в 1993 как Федеральный стандарт обработки информации. В России находится в статусе руководящего документа с 2000 года и в настоящее время в качестве стандарта не утвержден. Тем не менее методология IDEF0 является одним из популярных подходов для описания бизнес-процессов. К ее особенностям можно отнести:

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

  • поддержка декомпозиции;

  • доминирование;

  • выделение 4 типов стрелок.

Контекстная диаграмма. Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 приведен на Рис. 1.

Рисунок 1. Диаграмма A-0 в нотации IDEF0

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

Доминирование. Блоки модели IDEF0 на неконтекстной диаграмме должны располагаться по диагонали — от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева, «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные.

Выделение 4 типов стрелок. Выделяются следующие типы стрелок: «Вход», «Выход», «Механизм», «Управление». Входы преобразуются или расходуются процессом, чтобы создать то, что появится на его выходе. Управления определяют условия, необходимые процессу, чтобы произвести правильный выход. Выходы — данные или материальные объекты, произведенные процессом. Механизмы идентифицируют средства, поддерживающие выполнение процесса. Таким образом, блок IDEF0 показывает преобразование входа в выход с помощью механизмов с учетом управляющих воздействий.

Описание назначения графических символов, используемых в нотации IDEF0, приведено в Таблице 1.

Название Графический символ Описание
Процесс Процесс Процесс обозначается прямоугольным блоком. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом, глагольным оборотом или отглагольным существительным. Номер блока размещается в правом нижнем углу. Номера блоков используются для идентификации на диаграмме и в соответствующем тексте.
Стрелка Стрелка Стрелки обозначают входящие и исходящие из процесса объекты (данные).
Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок-стрелка. В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока — входы. Стрелки, входящие в блок сверху — управления. Стрелки, покидающие процесс справа — выходы, т.е. данные или материальные объекты, произведенные процессом. Стрелки, подключенные к нижней стороне блока, представляют механизмы.
Туннелированная стрелка Стрелка, туннелированная на конце, присоединенном к блоку процесса Стрелка, туннелированная на свободном конце Туннелированные стрелки означают, что данные, передаваемые с помощью этих стрелок, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме.
Стрелка, помещенная в туннель там, где она присоединяется к блоку, означает, что данные, выраженные этой стрелкой, не обязательны на следующем уровне декомпозиции.
Стрелка, помещаемая в туннель на свободном конце, означает, что выраженные ею данные отсутствуют на родительской диаграмме.
Туннелированные стрелки могут быть использованы на диаграммах процессов в нотациях IDEF0, «Процесс», «Процедура».
Внешняя ссылка Внешняя ссылка Элемент обозначает место, сущность или субъект, которые находятся за границами моделируемой системы. Внешние ссылки используются для обозначения источника или приемника стрелки вне модели. На диаграммах внешняя ссылка изображается в виде квадрата, рядом с которым показано наименование Внешней ссылки.
Внешние ссылки могут быть использованы на диаграммах процессов в любых нотациях.
Междиаграммная ссылка Междиаграммная ссылка Элемент, обозначающий другую диаграмму. Междиаграммная ссылка служит для обозначения перехода стрелки на диаграмму другого процесса без отображения стрелки на вышележащей диаграмме (при использовании иерархических моделей).
В качестве междиаграммной ссылки не может выступать диаграмма процесса в нотациях EPC и BPMN. Междиаграммные ссылки могут быть использованы на диаграммах процессов в нотациях IDEF0, «Процесс», «Процедура».
Процесс-ссылка Процесс-ссылка Элемент обозначает ссылку на типовую модель процесса.
Наиболее часто повторяющиеся процессы в рамках модели бизнес-процессов могут быть выделены в качестве типовых в отдельную папку в Навигаторе. Диаграмма типового процесса формируется один раз в одном месте Навигатора. Далее на любой диаграмме может быть использован процесс-ссылка на типовой процесс.
Параметры типового процесса заполняются непосредственно в Окне свойств типового процесса.
Постоянный список субъектов, принимающих участие в выполнении типового процесса, формируется также в Окне свойств типового процесса. Список субъектов, принимающих участие при выполнении типового процесса в рамках вышележащего процесса, формируется в Окне свойств процесса-ссылки на типовой процесс.
Процессы-ссылки могут быть использованы на диаграммах процессов в любых нотациях.
Сноска Сноска Выносной элемент, предназначенный для нанесения комментариев.
Элемент может быть использован на диаграммах процессов в любых нотациях.
Текст Текст Комментарий без сноски.
Элемент может быть использован на диаграммах процессов в любых нотациях.

Таблица 1. Графические символы, используемые в нотации IDEF0

Информация о способах добавления элементов на диаграмму содержится в главе Руководство пользователя → Создание модели деятельности организации.

Пример диаграммы процесса в нотации IDEF0 приведен на Рис. 2.

Рисунок 2. Диаграмма процесса в нотации IDEF0

Источник

Аннотация

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

Оглавление

Содержание

“Одна картинка стоит тысячи слов.“

Народная мудрость

Зачастую в моей работе возникает необходимость не просто изучить и решить определенную проблему, но выявить ее местонахождение в общей модели работы компании. Мало понимать, что определенное подразделение работает неправильно, важно понимать, каким образом оно взаимодействует с другими. Иначе невозможно выявить все существующие проблемы и выбрать оптимальный метод решения поставленной задачи. А для этого требуется изучить работу компании и составить ее функциональную модель.Конечно, в теории функциональная модель работы компании должна быть у руководителя, причем, не важно, идет речь об организации работы склада или об IT системе (от лида до заявки). Но в реальности практически никогда ее не оказывается, а потому в процессе изучения и поиска решения поставленной клиентом задачи я также создаю функциональную модель работы компании или определенного процесса (функции) самостоятельно.

Несколько слов о преимуществах графики

Как известно, функциональные модели IDEF0 — это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя — много-много слов. И понять в итоге, что же происходит, было очень сложно. А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы.

Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно. Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену — это и правда очень сложно. Этому клиенту я предложил альтернативный вариант — описать все, что можно, графически в виде нотаций. Показал ему примеры моделирования. В итоге они сейчас переосмысливают свои пожелания и оформление технического задания. Знаю я также много других примеров, когда графическое моделирование бизнес-процессов помогало в работе как моим коллегам, бизнес-консультантам и разработчикам, так и самим бизнесменам

Почему это важно для моей работы

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

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

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

Что такое нотация описания бизнес-процессов

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

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ). Википедия

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

Функциональная модель компании

Функциональная модель IDEF0 представляет собой набор блоков, каждый из которых представляет собой «черный ящик» со входами и выходами, управлением и механизмами, которые детализируются (декомпозируются) до необходимого уровня. Наиболее важная функция расположена в верхнем левом углу. А соединяются функции между собой при помощи стрелок и описаний функциональных блоков. При этом каждый вид стрелки или активности имеет собственное значение. Данная модель позволяет описать все основные виды процессов, как административные, так и организационные. Стрелки могут быть:

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

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

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

Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д. Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку.

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

Есть вопросы по моделированию в IDEF0? Напишите нам или позвоните по телефону +7(495)320-50-40 и мы Вас проконсультируем.

Написать нам

Пример создания функциональной модели IDEF0

Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи. Основной блок – «Написать статью».

пример описания модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы. Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

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

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

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

  1. Подготовить аудио.
  2. Подготовить текст
  3. Подготовить текст к публикации.
  4. Разместить статью в издании.

IDEF0 A0

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

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

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

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

А потому при необходимости я могу, скажем, за половину стоимости обязанности корректора предложить копирайтеру. Так я сэкономлю средства и время на взаимодействие разных специалистов. Конечно, я понимаю все заслуги корректоров и почему лучше работать с отдельным специалистам. Но напоминаю — у меня стоит задача: оптимизация затрат. Без такого наглядного инструмента было бы сложнее определить, какие из блоков можно удалить и, таким образом, оптимизировать работу.

Как создавать нотации IDEF0

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

IDEF0

Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок. Для того чтобы создать нотацию существующих бизнес-процессов, т.е. описать, как сейчас работает компания, необходимо принципы работы изучить. Сторонний специалист (консультант, разработчик) для этого проводит интервью. На первом этапе на вопросы отвечает руководитель компании, далее в процессе детализации нотации проводятся интервью сотрудников, отвечающих за различные этапы работы.

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

Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи. Требования стандарта IDEF0 Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

  1. В левом верхнем углу всегда – главный элемент.
  2. Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
  3. Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
  4. Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
  5. Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.

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

Точка зрения

2 основополагающих требования к модели.

В требованиях к диаграмме и построению модели в нотации IDEF0 есть требование, которое звучит так: любая диаграмма должна быть построена, исходя из точки зрения (Point of view) и цели (Scop). Именно этот вопрос, скажем так, один из основополагающих — точка зрения и цель. Соответственно, если мы хотим построить правильную диаграмму, нам необходимо выбирать правильно точку зрения. 

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

точка зрения — это краткое изложение перспектив и модель. 

Второе определение:

Точка зрения определяет, что можно «увидеть „в контексте модели, с какой точки зрения или “под каким углом». В зависимости от поставленной цели могут быть приняты точки зрения, учитывающие различные аспекты объекта. На модель существует только одна точка зрения. 

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

Выбор точки зрения.

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

Первое правило: выбор места в иерархии.

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

Точка зрения: работник склада.

Если я, допустим, выберу точку зрения работника склада, то, что я увижу? Я увижу товар, требования к товару, требования к документации, свое рабочее место. Если я отвечаю только за приемку, то увижу только зону приема. В этом случае сам склад, место хранения, я могу не увидеть и зону отгрузки тоже могу не увидеть. Соответственно, что мы здесь видим? Мы видим, что наша точка зрения обусловлена тем, где мы находимся в иерархии. Проще говоря, мы видим то, что нам разрешено увидеть. Значит, первое правило — мы должны понимать, кто мы в иерархии предприятия, то есть с какой точки зрения мы смотрим. 

Точка зрения: руководитель склада.

Чтобы наглядно продемонстрировать это, давайте посмотрим на точку зрения начальника, руководителя склада. Если мы посмотрим , то увидим, что он видит, как приемку, так и хранение, и отгрузку, и контролирует все эти вещи. То есть он видит больше. Он выше. Значит, с его точки зрения он видит больше. Но, в связи с этим, для него те вещи, которые важны для работника склада, и которые видит работник склада, уже не так важны. Можно сказать, что он видит больше, но видит в большей перспективе и меньшей детализации. 

Второе правило: выбор окружения

Отсюда же следует второй вопрос — что конкретно мы видим? Допустим, я работник склада, и я вижу то, что меня окружает: рабочее место, допустим, какой-то компьютер, доступ в какую-то систему учетную и ещё что-то в этом роде. И если я, описываю с точки зрения работника склада, работника приемки, назовём это так, то для меня эти все вещи будут важны.  

Но все ли они важны для меня, если я решил автоматизировать это рабочее место? Важна ли для меня с точки зрения автоматизации, например, чистота? Или важно для меня, какой у меня стол, наличие стула и тому подобные вещи? Нет, они не важны! Также не важны для меня и различные инструкции, потому что при автоматизации этот момент я опускаю.  

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

Третье правило: приоритет.

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

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

Цель создания модели.

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

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

Цель создания модели это другими словами то для чего эта модель будет использована.

Типичные ошибки

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

Использование различных цветов

Все элементы на диаграмме одинаково важны. При функциональном моделировании нет более или менее важных элементов. Исчезновение любого приведет к нарушению процесса и производственному браку.

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

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

Слишком большое количество блоков

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

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

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок. Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

  • Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
  • Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
  • Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
  • Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

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

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

Как правильно называются стрелки в IDEF0

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

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

Основные стрелки в IDEF0:

  • Input
  • Control
  • Output
  • Mechanism

Вместе этот тип элементов называют ICOM, т.е. это сокращение от названий всех типов стрелок. Именно так постоянно пишут в самом стандарте. Потому, когда вы видите упоминание ICOM, просто помните, что это значит — «Input, Control, Output, Mechanism».

Как это переводится?

  • Input — Ввод
  • Control — Контроль
  • Output — Вывод
  • Mechanism — Механизм

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

Input и Output

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

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

Но это неправильно. Input – это не Вход, а Ввод. И точно такая же ситуация со стрелкой Output, которую часто ошибочно переводят как «Выход».

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

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

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

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

Кроме того, перевод Input – Ввод, а Output – Вывод, наиболее точен. Именно так эти слова переводятся с английского языка.

Control и Mechanism

Далее, ошибки в переводе слова Control также постоянно повторяются, и они столь же некорректны. Часто Control переводят как «Управление». И это неправильно.

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

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

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

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

Если в качестве «Механизма» выступает компьютерная программа, то контроль уже заложен в ее коде. И при написании этого кода в том числе используются инструкции, правила и другие документы.

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

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

Как видите, все просто. Если вы правильно переводите термины, а именно:

  • Input — Ввод
  • Control — Контроль
  • Output — Вывод
  • Mechanism — Механизм

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

Модель работы швейного предприятия

В этом случае компания собиралась внедрять 1С. Управление производственным предприятием, и также нужно было навести порядок, чтобы каким-то образом стандартизировать и автоматизировать работу.

Цель

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

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

Описание

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

Также была задача уменьшить срок рассмотрения заявки на производство от клиента.

Я создал модель, разделил все этапы работы на функции. Далее каждую из них мы с клиентами рассматривали с точки зрения процессов и возможности автоматизации. Например, выбиралась функция «Проектирование производства», и для нее выполнялась автоматизация.

Описание работы швейной фабрики A-0
Описание работы швейной фабрики A0

Критика

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

  1. Мы видим 7 блоков. IDEF0 по стандарту требует максимум 6 блоков.
  2. В диаграмме используются такие фразы, как «исследование рынка», «проектирование». Это также ошибки. Если вы ознакомитесь с моим переводом стандарта IDEF0 на сайте Хабр, то там описывается, что функции должны называться глаголом в совершенной форме, т.е. давать ответ на вопрос «что необходимо сделать». В данном случае вместо «Исследование рынка» правильно написать «Исследовать рынок. Не «Проектирование продукции», а «Спроектировать продукцию». Не «Проектирование производства», а «Спроектировать производство» и т.д. Есть и другие ошибки в названиях. Например, при декомпозиции хорошо видно название «Производство и реализация швейных изделий». Здесь не должны объединяться два разных действия союзом «И». Должно быть либо производство, либо реализация, точнее – «произвести» или «реализовать», так как по правилам нотации не должно быть союза «и», каждый блок описывается фразой с одним глаголом, который выражает функцию.

С другой стороны, несмотря на ошибки, диаграмма – рабочая. Проект длился около 2,5 лет, все этапы были автоматизированы успешно. В результате ответ на запрос о возможности выпуска продукции стал приходить не через 2,5 месяца, а в течение 10 дней, что для этого вида бизнеса – очень короткий срок. Были достигнуты и другие цели, в частности, опираясь на эту диаграмму.

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

Ещё пример моделирования в IDEF0

В своей новой статье я привожу пример использования IDEF0 в торговом предприятии:

УФМТП. Универсальная функциональная модель торгового предприятия в нотации IDEF0

Бизнес-консультант с большим практическим опытом работы в России и ближайшем зарубежье. Автор
многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса. Живу и работаю в
Москве, руководитель компании Trinion. Делюсь опытом посредством блога на сайте trinion.org

Источник

Основу
методологии IDEFO составляет графический
язык описания бизнес-процессов. Модель
в нотации IDEFO представляет собой
совокупность иерархически упорядоченных
и взаимосвязанных диаграмм. Каждая
диаграмма является единицей описания
системы и располагается на отдельном
листе. IDEFO-модель предполагает наличие
четко сформулированной цели единственного
субъекта моделирования и одной точки
зрения. Модель может содержать четыре
типа диаграмм:

  • контекстную
    диаграмму (в каждой модели может быть
    только одна контекстная диаграмма);

  • диаграммы
    декомпозиции;

  • диаграммы
    дерева узлов;

  • диаграммы
    только для экспозиции (FEO).

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

  • верхняя
    сторона имеет значение «управления»;

  • левая
    — «входа»;

  • правая
    — «выхода»;

  • нижняя
    — «механизма».

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

Контекстная
диаграмма компании «EuroAuto»
в нотации IDEF0
(рис.5)

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

3.3 Принципы моделирования бизнес-процессов в нотации idef3

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

В
IDEF3 используются следующие типы объектов:

  • работа
    (Unit of Work, Activity)

  • стрелка
    (Arrow)

  • перекресток,
    или коннектор (Junction)

  • ссылочный
    объект (Referent)

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

Единицы
работы
— Unit
of
Work
(UOW).
UOW, также называемые работами (activity),
являются центральными компонентами
модели. В IDEF3 работы изображаются
прямоугольниками с прямыми углами и
имеют имя, выраженное отглагольным
существительным, обозначающим процесс
действия, одиночным или в составе фразы,
и номер (идентификатор).

Связи
показывают взаимоотношения работ. Все
связи в IDEF3 однонаправлены и могут быть
направлены куда угодно, но обычно
диаграммы IDEF3 стараются построить так,
чтобы связи были направлены слева
направо.

В
IDEF3 различают три типа стрелок, изображающих
связи:

  • Старшая
    (Precedence) — сплошная линия, связывающая
    единицы работ (UOW). Рисуется слева направо
    или сверху вниз.

  • Отношения
    (Relational Link) — пунктирная линия,
    использующаяся для изображения связей
    между единицами работ (UOW) и между
    единицами работ и объектами ссылок.

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

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

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

Средства
документирования и моделирования IDEF3
позволяют выполнять следующие задачи:

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

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

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

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

  • Разрабатывать
    имитационные модели технологических
    процессов, по принципу «КАК БУДЕТ,
    ЕСЛИ…»

Рис.6
Модель бизнес-процессов верхнего уровня
в нотации IDEF0

Рис.7
Модель бизнес-процессов верхнего уровня
в нотации IDEF0
(декомпозиция концептуальной схемы)

Рис.8
Модель бизнес-процессов нижнего уровня
в нотации IDEF3
(декомпозиция «Обработки запроса»)

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

Актуально ли на сегодня моделирование в IDEF0?

Актуально ли на сегодня моделирование в IDEF0?

Решетова Наталья Эвальтовна

Автор сайта Projectimo.ru

Свежие публикации автора:

Содержание

  • 1 Основные понятия и сокращения
  • 2 Функциональный блок
  • 3 Контекстная диаграмма
  • 4 Основные потоки
  • 5 Декомпозиция
  • 6 Выводы об актуальности нотации

Известная сегодня уже не только в узких кругах аббревиатура IDEF0 является первой методологией, стандартизирующей работу над бизнес-процессами. Она была разработана в середине прошлого века в рамках аэрокосмического проекта в США и, показав свою эффективность, стала федеральным стандартом. В нашей стране в 2000 году подготовлен документ «Методология функционального моделирования IDEF0. Руководящий документМетодология функционального моделирования IDEF0 Руководящий документ. Издание официальное. Госстандарт России РД IDEF0 – 2000. Разработан Научно-исследовательским Центром CALS – технологий «Прикладная Логистика». Принят и введен в действие Постановлением Госстандарта России 2000 г. Москва», но как стандарт он так и не был утвержден. Хотя это не помешало данной методологии стать в нашей стране одним из наиболее популярных инструментов графического моделирования бизнес-процессов. В данной статье я предлагаю вам рассмотреть модель IDEF0 и оценить актуальность этого подхода в настоящее время.

Основные понятия и сокращения

Разберемся немного с названиями ключевых элементов методологии. Графический стандарт IDEF0 является частью методологии SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования). IDEF – это сокращение от ICAM Definition, а ICAM образовано от Integrated Computer Aided Manufacturing, что переводится как интегрированная компьютеризация производства. Методология SADT – это целое семейство из 15 разных моделей, которые в комплексе должны были позволить исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.

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

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

Функциональный блок

Центральным элементом модели IDEF0 является функция, которая на схеме отображается в виде функционального блока – прямоугольника, внутри которого указано действие в форме отглагольного существительного. Действие может быть очень разным по масштабу – от деятельности компании вообще и до конкретной манипуляции в частности. Примеры: «Производство и продажа керамической посуды» и «Нанесение рисунка на изделие».

элементы функционального блока IDEF0

Обязательные элементы функционального блока в IDEF0

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

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

Такой подход позволяет немного сэкономить на пояснениях в схемах и добиться однозначности в отображении потоков, что придает стройности всей модели.

Для построения функциональной модели методология IDEF0 требует соблюдать следующие правила.

  1. Входы – это ресурсы, которые переносят свою стоимость в выходы полностью, то есть расходуются на создание результата полностью, а механизмы – это ресурсы, которые переносят свою стоимость только частично (оборудование – через амортизацию, а люди – через заработную плату).
  2. Управление – это необходимый элемент модели, так как он привязывает все действия к системе регламентов компании, четко обозначая, какие правила и требования должны быть соблюдены в процессе выполнения функции. Часто к этому потоку относятся формально, но при этом схема теряет строгость, а иногда даже смысл.
  3. У каждого функционального блока должна быть как минимум одна стрелка с каждой стороны (так как не может быть работы без ресурсов или результатов, а также неполной будет инструкция без исполнителя или инструкции).

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

Контекстная диаграмма

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

  1. Цель – конкретная формулировка назначения модели, по которой можно сверять в дальнейшем точность построения модели.
  2. Точка зрения – от чьего лица строится модель, так как модель зависима всегда от ее автора и фокуса внимания. Если мы строим общую модель предприятия, то обычно она представляется с точки зрения его директора.
  3. Тип модели – это указание на то, какая информация отображена на схемах. Здесь может быть 2 принципиальных варианта: AS IS («как есть») или TO BE («как будет»). Такое разделение необходимо, так как мы можем строить модели как для анализа деятельности, так и для ее трансформации. Мы должны четко отдавать себе отчет в том, что мы делаем, а также доносить эту информацию до окружающих.

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

Основные потоки

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

  1. Материальный: материалы и комплектующие на входе и готовая продукция на выходе.
  2. Клиентский: потенциальный клиент на входе и удовлетворенный на выходе.
  3. Финансовый: на входе это обычно инвестиции, платежи клиентов (выручка), кредиты и прочие доходы; на выходе – это платежи поставщикам, налоги, платежи по кредитам и прибыль.
  4. Информационный: на входе это все потоки информации о внешней среде (состояние рынка, поведение конкурентов, технологические инновации и пр.), а на выходе – это поток информации, которую компания сообщает о себе миру (вся рекламная информация, а так же все виды отчетности перед контролирующими органами).

Обратите внимание, что компания – это открытая система, и в ней ничего не возникает и не исчезает. Компания способна только преобразовывать входящие потоки в выходящие, и если она это делает хорошо, то появляется дополнительный денежный поток (прибыль), отражающий в каком-то смысле качество работы всей системы.

контекстная диаграмма

Пример контекстной диаграммы
(нажмите для увеличения)

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

Стрелки управления могут быть представлены только 1 видом потока – информационным, который можно разбить на 2 подвида. Первый – это документы, такие как:

  • законы и нормы;
  • приказы, распоряжения;
  • инструкции и регламенты;
  • планы;
  • конструкторская документация и пр.

Второй – это недокументированная информация, к которой чаше всего относятся требования собственников.

И, наконец, механизмы – здесь только 2 вида потоков: оборудование (материальный) и исполнители (подразделения и люди). Здесь не может быть документов, как и не может быть людей на стрелках управления!

Для навигации в модели предусмотрена сквозная нумерация. Контекстная диаграмма нумеруется «А-0». В дальнейшем каждый функциональный блок получает свой номер, какой бы глубокой ни была декомпозиция.

Декомпозиция

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

первый шаг декомпозиции

Первый шаг декомпозиции
(нажмите для увеличения)

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

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

  1. Создание продукта (результата).
  2. Продвижение и продажа – работа с клиентским потоком.
  3. Обеспечение деятельности по созданию продукта – вторичные процессы, которые необходимы для соблюдения государственных требований или удобства работы (кадровый и бухгалтерский учет, транспортное обслуживание, уборка помещений и прочее).
  4. Создание потоков управления – деятельность по разработке управленческих решений, которые будут определять требования ко всем процессам компании.

На рисунке ниже представлена диаграмма декомпозиции нашего примера.

первый уровень декомпозиции

Первый уровень декомпозиции
(нажмите для увеличения)

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

Дальнейшая работа над моделью аналогична первому шагу – проводится декомпозиция каждого функционального блока первого уровня. Нумерация блоков будет содержать при этом номер первого уровня: А1.1 … А1.n, A2.1 … A2.n и т.д.

Выводы об актуальности нотации

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

  1. Модель обладает хорошим визуализирующим потенциалом, но, на мой взгляд, большее ее значение – в дисциплинирующем эффекте. Заложенные в методологию правила и ограничения заставляют выработать системное и строгое отношение к моделям, что очень хорошо сказывается на качестве конечного результата.
  2. Модель позволяет выстроить потоки связи между внешне не сильно связанными вещами: связать подсистемы фронт и бэк-офисов с управлением, что гораздо хуже удается другим нотациям.
  3. Подход прост и понятен для большинства участников проекта. Построение и чтение диаграмм в данной нотации ограничивается только желанием вникать в хитросплетение потоков бизнеса.

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

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

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

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

Источник

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

Методология IDEF0 берет своё начало в 60-х годах. Разработана известным американским ученым Дуглас России в США. В настоящее время методология IDEF0 является фундаментальной, занимает ведущую позицию. Рассмотрим более подробно ее назначение и особенности.

Несколько слов о преимуществах графики

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

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

Изображение бизнес-процесса в графическом виде

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

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

Что такое нотация описания бизнес-процессов

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

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

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

По аналогии с языками программирования, нотации называют языками моделирования бизнес-процессов, являются общепризнанными и понятными для всех.
Сегодня в мире наиболее популярны 3 нотации:

  • IDEF0;
  • EPC;
  • BPMN.

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

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

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

Idef0 блоки

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

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

Назначение и состав методологии

Методология IDEF0 получила свою популярность и широкое применение благодаря простому графическому исполнению и простоте восприятия.

Методология IDEF0 описания бизнес-процессов заключается в описании действий с помощью диаграмм.

Описание бизнеса-процессов происходит быстро и очень понятно. Главные составляющие — диаграммы.

Выделяют четыре типа диаграмм:

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

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

Диаграммами декомпозиции — считаются второстепенными или дочерними. Описывают составные части основной функции.

Диаграмма дерева узлов — выражает зависимость функций между собой.

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

Элементы графической нотации

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

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

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

  • Деятельность;
  • Процесс;
  • Операция;
  • Действие.

Стрелочка в диаграмме обозначает взаимосвязь функций между собой и внешним миром. Подразделяются на:

  • Вход;
  • Управление;
  • Механизм;
  • Выход;
  • Вызов.

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

Типы связей между функциями

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

Маркетолог предприниматель

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

Выделяют несколько типов связей:

  • Иерархическая
  • Регламентирующая связь
  • Функциональная
  • Потребительская
  • Логическая
  • Коллегиальная
  • Ресурсная
  • Информационная
  • Временная
  • Случайная.

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

Плюсы и минусы

Преимущества IDEF0:

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

Недостатки IDEF0:

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

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

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

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

Облегчить чтение модели возможно, если придерживаться определенны правил создания диаграмм IDEF0. Вот некоторые из них:

  • Первостепенно определить для себя цель бизнес-процесса. Необходимо определить тип формируемой модели, а также позицию, с точки зрения которой будет строиться модель.
  • При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы).
  • На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
  • Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6.
  • Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз.
  • Отсутствие у функции одновременно стрелок управления и входа не допускается.
  • Обеспечить каждому блоку свой вход.
  • Постараться как можно меньше допустить поворотов в диаграмме и петель.
  • Используйте обратные дуги для изображения обратных связей.
  • Поименуйте каждый элемент диаграммы.
  • Использовать туннелирование стрелок.
  • Объединить стрелки, проходящие параллельно и дать им единое имя.
  • Нумерация блоков.

Типичные ошибки

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

Рассмотрим типичные ошибки:

  1. Использование различных цветов — не стоит пытать выделить отдельные элементы цветами, чтобы повысить наглядность. Все элементы одинаково важны.
  2. Слишком большое количество блоков — нельзя изобразить все нюансы процесса на одном листе. Для конкретизации деятельности необходимо применить детализацию каждого блока.
  3. Нарушение структуры при внесении корректировок — при внесении каких-либо изменений, например смены точки зрения, следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов.
  4. Правила названия управляющих элементов и блоков — называйте стрелки именами, а блоки глаголами.

Программное обеспечение для построения диаграмм IDEF0

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

К сегодняшнему дню создано не мало программ для создания диаграмм IDEF0. Вот некоторые из них:

  • ERWin 3.5.2;
  • Design/ IDEF;
  • Dia;
  • IDEF0/EMTool;
  • BPwin.

Пример создания функциональной модели IDEF0

Рассмотрим процесс написания статьи для наглядного описания создания функциональной модели IDEF0

Основной блок называется «Написать статью».Пример создания функциональной модели IDEF0

Взаимодействие с внешней средой обозначены на схеме входящими стрелками – «Знания в области написания статьи», «Опыт», «Информация из сторонних источников». Основы, которые необходимы для описания.

Управляющие в данном случае – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение.

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

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

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

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



Источник

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

IDEF0 — основные характеристики

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

Модель процесса в диаграмме IDF0

Модель процесса в диаграмме IDF0

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

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

Диаграммы IDEF0 читают сверху вниз и слева направо. Все базовые элементы основаны на простых символах:

  • прямоугольники изображают функции или процессы;
  • стрелки обозначают как функции взаимосвязаны через физические и информационные потоки.

Синтаксическая модель IDF0

Синтаксическая модель IDF0

Семантика языка описывает именно функции системы — что должно быть сделано для преобразования входящего потока, поэтому названия в прямоугольниках должны быть заданы глаголом или отглагольным существительным. Каждая сторона прямоугольника имеет свое значение и однозначно связана с одним из 4 видов стрелок:

Сторона прямоугольника Стрелка Значение

верхняя

стрелка управления

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

левая

стрелка входа

материал или данные

правая 

стрелка выхода

данные и материальные объекты, преобразованные функцией

нижняя

стрелка механизма

ресурсы (персонал, оборудование, производственные мощности и т.д.)

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

Другие правила синтаксиса

  • блок должен полностью вмещать название;

  • можно использовать только блоки прямоугольной формы;

  • блоки должны быть нарисованы сплошными линиями;

  • изгиб стрелок должен составлять 90°;

  • сегменты стрелок должны быть отрисованы сплошными линиями;

  • нельзя рисовать стрелки по диагонали;

  • стрелки не должны пересекать границы блока;

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

  • стрелки должны быть подписаны, для подписи используются только имена существительные.

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

Виды диаграмм

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

Пример диаграммы верхнего уровня A0 в нотации IDF0

Пример диаграммы верхнего уровня A0 в нотации IDF0

Иерархия типов функций

  • деятельность — совокупность всех процессов организации;
  • бизнес-процесс — совокупность логически связанных операций;
  • операция — совокупность последовательных или параллельных действий внутри определенного потока;
  • действие— преобразование свойств какого-либо объекта.

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

Основные характеристики IDF0

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

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

  • упор на иерархическое отображение элементов;

  • может быть воссоздана на программном уровне.

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

Для чего используется

Нотация универсальна и позволяет детально описывать достаточно сложные системы и процессы на любом уровне.

  • широко применяется в США при автоматизации машинного производства и до сих пор является частью стандарта FIPS (Federal Information Processing Standard);

  • применяется для имплементации методологий непрерывного улучшения, таких как Strategic Justification of Integrated Enterprise Technologies (SJET) и Perform Continuous Enterprise Improvement (PCEI);

  • в литературе можно найти пример описания процесса разработки стратегии на языке IDEF0.

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

Преимущества

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

  • возможность отобразить взаимосвязи между различными уровнями системы;

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

  • большое количество документации на английском языке;

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

  • аккуратно спроектированные схемы легко читаются.

Недостатки

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

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

  • низкий потенциал для автоматизации функциональных моделей;

  • требует определенных навыков для адекватного проектирования диаграмм;

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

BPMN vs IDEF0

Хотя IDEF0 иногда используют для моделирования бизнес-процессов, эта нотация задумывалась как средство моделирования взаимодействия бизнес-функций, не обязательно в процессном контексте. Стрелка в BPMN показывает точную последовательность выполнения шагов процесса, а в IDEF0 стрелки входов-выходов не обязаны отображать эту последовательность. Кроме того, BPMN содержит XML-описание элементов, что значительно упрощает имплементацию на программном уровне. В отличие от IDEF0, BPMN разрабатывалась с прицелом на автоматизацию бизнес-процессов, поэтому многие элементы нотации показывают именно машинные способы передачи и обработки данных. Нотация нашла широкое применение в BPMS, ERP, CRM, SRM и других информационных системах.

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

Верхнеуровневая диаграмма в Comindware Business Application Platform

Верхнеуровневая диаграмма в Comindware Business Application Platform

Comindware Business Application Platform исправляет этот недостаток BPMN за счет конструктора для проектирования исполняемой архитектуры предприятия. Конструктор визуализирует связи между бизнес-процессами, ресурсами и способностями предприятия, не уступая по точности IDEF0. Инструмент можно использовать для создания иерархических моделей с несколькими уровнями вложений.

Ознакомьтесь с возможностями по построению процессной архитектуры в Comindware Business Application Platform

Заказать демо

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Источник

Содержание:

1.      Простая блок-схема бизнес-процесса

2.      Моделирование IDEF0

3.      Моделирование BPMN

4.      Моделирование BPMN

5.      Графические нотации бизнес-процессов. Выводы.

Добрый день, коллеги.

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

·         Простая блок-схема;


·         IDEF0;


·         BPMN;


·         EPC.

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

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

1. Простая блок-схема бизнес-процесса

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

 

Упрощенная схема заваривания чая в нотации простой блок-схемы приведена Рисунке 1.

Преимущества данной схемы:

·         Простота элементов, наглядность;

Недостатки данной схемы:

·         Необходимость указания участника непосредственно внутри блока, что затрудняет восприятие. Данный недостаток может быть нивелирован при помощи вынесения операций, выполняемых разными участниками в отдельные подпроцессы, для примера на схеме приведен «Подпроцесс восполнения компонентов».

·         Сложность в описании временных задержек, ожиданий.

 

Рисунок 1. Схема заваривания чая в формате простой блок-схемы


2. Моделирование IDEF0

Нотация является федеральным стандартом обработки информации в США с 1993 года. К особенностям данного формата можно отнести следующие особенности:

·         Использование контекстной диаграммы:

Бизнес-процессы idef0 обязательно подразумевают использование диаграммы верхнего уровня, так называемой «диаграммы А-0», которая устанавливает область моделирования, ее границу и связи объекта моделирования с окружающей средой.

·         Поддержку декомпозиции:

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

·         Доминирование:

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

·         Выделение 4 типов стрелок:

В нотации выделяются такие типы стрелок: «Вход», «Выход», «Механизм», «Управление». Тип стрелки определяется стороной функционального блока, к которой она присоединена. «Входы» преобразуются или потребляются процессом. «Выходы» — данные или материальные объекты, производимые процессом. «Механизмы» описывают средства поддержания процесса. «Управления» показывают условия, необходимые процессу для производства правильного выхода.

Описание основных графических элементов:

 

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

Упрощенная схема заваривания чая в нотации IDEF0 приведена на Рисунке 2 (Контекстная диаграмма) и Рисунке 3 (Диаграмма первого уровня декомпозиции).

Преимущества данной схемы:

·         Неограниченная глубина детализации;

·         Жесткое регламентирование описания ресурсов процесса.

Недостатки данной схемы:

·         Сложность при глубоком уровне детализации;

·         В связи со сложностью хорошо подходит для верхнеуровневого и малоприменима для детального описания бизнес-процессов

 

Рисунок 2. Контекстная диаграмма 

 

Рисунок 3 Диаграмма первого уровня декомпозиции

3. Моделирование BPMN

Нотация используется для описания процессов нижнего уровня. Как и простая блок-схема, диаграмма BPMN отражает алгоритм выполнения процесса. Отображаются события, участники процесса, потоки данных и потоки ресурсов. По аналогии с нотацией IDEF0 каждый процесс может быть декомпозирован, при этом может использоваться как нотация BPMN, так и нотация EPC.

В нотации BPMN выделяют пять основных категорий элементов:

·         элементы потока (события, процессы и шлюзы);

·         данные (объекты данных и базы данных);

·         соединяющие элементы (потоки управления, потоки сообщений и ассоциации);

·         зоны ответственности (пулы и дорожки);

·         артефакты (сноски).

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

Описание основных графических элементов:

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

 Упрощенное BPMN описание заваривания чая приведено на Рисунке 4. 


Рисунок 4. Упрощенный процесс в нотации BPMN

Преимущества данной нотации:

·         Неограниченная глубина детализации;

·         Жесткое регламентирование использования элементов;

·         Автоматизация процессов моделирования и исполнения;

·         Гибкость и наглядность отображения сложных процессов.

Недостатки данной схемы:

·         Сложные регламенты моделирования.

4. Нотация EPC

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

Описание основных графических элементов:

Преимущества нотации EPC

·         При формировании схемы выдерживается строгая, формальная логика процесса.

·         Четко определены все события, возникающие по ходу процесса.

Недостатки нотации EPC

·         Сложность восприятия.

·         Значительная трудоемкость формирования схемы.

·         Информационная избыточность.

·         Занимает слишком много места, что неудобно для документирования.

Упрощенная схема заваривания чая в нотации EPC приведена на Рисунке 5.

 

Рисунок 5. Упрощенная схема заваривания чая в нотации EPC

5. Графические нотации бизнес-процессов. Выводы.

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

При работе в любой графической нотации необходимо придерживаться определенных общих правил:

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

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

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

Эксперт-консультант по производственному учету

Виктор Малиновский.

Источник

Понравилась статья? Поделить с друзьями:
  • Детский игровой центр бизнес план с расчетами
  • Декомпозиция целей компании по подразделениям
  • Делегирование полномочий в компании т питерса
  • Детский клуб в дербенте солнышко время работы
  • Деление бизнеса при разводе судебная практика