Что такое сценарии idef0

Аннотация

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

Оглавление

Несколько слов о преимуществах графики
Почему это важно для моей работы
Что такое нотация описания бизнес-процессов
Что такое IDEF0?
1. Функциональная модель компании
2. Пример создания функциональной модели IDEF0
Как создавать нотации IDEF0
Точка зрения
1. 2 основополагающих требования к модели.
2. Выбор точки зрения.
  1. Первое правило: выбор места в иерархии.
    1. Точка зрения: работник склада.
    2. Точка зрения: руководитель склада.
  2. Второе правило: выбор окружения
  3. Третье правило: приоритет.
Цель создания модели.
Типичные ошибки
1. Использование различных цветов
2. Слишком большое количество блоков
3. Нарушение структуры при внесении корректировок
4. Правила названия управляющих элементов и блоков
Выгоды использования IDEF0
В чем трудность применения IDEF0
1. Как правильно называются стрелки в IDEF0
2. Как это переводится?
  1. Input и Output
  2. Control и Mechanism
Модель работы швейного предприятия
1. Цель
2. Описание
3. Критика
Ещё пример моделирования в 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 основных этапа:

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

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

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

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

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

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

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

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

IDEF0

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

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

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

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

Сам стандарт 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С. Управление производственным предприятием, и также нужно было навести порядок, чтобы каким-то образом стандартизировать и автоматизировать работу.

Цель

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

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

Описание

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

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

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

Критика

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

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

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

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

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

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

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

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

Источник

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

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

Несколько слов о преимуществах графики
Что такое нотация описания бизнес-процессов
Что такое IDEF0?
- Назначение и состав методологии
- Элементы графической нотации
- Типы связей между функциями
- Плюсы и минусы
Правила и рекомендации построения диаграмм
- Типичные ошибки
Программное обеспечение для построения диаграмм IDEF0
Пример создания функциональной модели IDEF0
- Читать также:

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

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

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

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

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

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

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

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

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

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

IDEF0;
EPC;
BPMN.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основной блок называется «Написать статью».

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

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

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

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

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

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

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

Источник

Лекция
6. Стандарты моделирования IDEF

ПОНЯТИЕ
О СЕМЕЙСТВЕ СТАНДАРТОВ IDEF

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

IDEF-методология
создавалась в рамках проводимой в США
программы компьютеризации промышленности
ICAM (Integrated Computer Aided Manufacturing), в ходе
реализации которой выявилась потребность
в разработке методов анализа процессов
взаимодействия в производственных
системах. Отсюда и происходит название
данного семейства стандартов — Icam
DEFinition – IDEF.

В
настоящий момент к семейству IDEF можно
отнести следующие стандарты:

IDEF0
— методология функционального
моделирования. С помощью наглядного
графического языка IDEF0, изучаемая
система предстает перед разработчиками
и аналитиками в виде набора взаимосвязанных
функций (функциональных блоков — в
терминах IDEF0). Как правило, моделирование
средствами IDEF0 является первым этапом
изучения любой системы;
IDEF1
– методология моделирования информационных
потоков внутри системы, позволяющая
отображать и анализировать их структуру
и взаимосвязи;
IDEF1X
(IDEF1 Extended) – методология построения
реляционных структур. IDEF1X относится к
типу методологий “сущность-взаимосвязь”
(ER – Entity-Relationship) и, как правило, используется
для моделирования реляционных баз
данных, имеющих отношение к рассматриваемой
системе;
IDEF2
– методология динамического моделирования
развития систем. В связи с весьма
серьезными сложностями анализа
динамических систем от этого стандарта
практически отказались, и его развитие
приостановилось на самом начальном
этапе.
IDEF3
– методология документирования
процессов, происходящих в системе,
которая используется, например, при
исследовании технологических процессов
на предприятиях. С помощью IDEF3 описываются
сценарий и последовательность операций
для каждого процесса. IDEF3 имеет прямую
взаимосвязь с методологией IDEF0 – каждая
функция (функциональный блок) может
быть представлена в виде отдельного
процесса средствами IDEF3;
IDEF4
– методология построения
объектно-ориентированных систем.
Средства IDEF4 позволяют наглядно
отображать структуру объектов и
заложенные принципы их взаимодействия,
тем самым позволяя анализировать и
оптимизировать сложные объектно-ориентированные
системы;
IDEF5 – методология
онтологического исследования сложных
систем. С помощью методологии IDEF5
онтология системы может быть описана
при помощи определенного словаря
терминов и правил, на основании которых
могут быть сформированы достоверные
утверждения о состоянии рассматриваемой
системы в некоторый момент времени. На
основе этих утверждений формируются
выводы о дальнейшем развитии системы
и производится её оптимизация.

В рамках настоящей
лекции рассмотрим наиболее употребительные
и актуальные стандарты: IDEF0,
IDEF1/IDEF1X,
IDEF3, IDEF5.

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

Функциональный
блок графически
изображается в виде прямоугольника и
олицетворяет собой некоторую конкретную
функцию в рамках рассматриваемой
системы. По требованиям стандарта
название каждого функционального блока
должно быть сформулировано в глагольном
наклонении (например, “производить
услуги”, а не “производство услуг”).
Каждая из четырех сторон функционального
блока имеет своё определенное значение
(роль), при этом:

верхняя
сторона имеет значение «Управление»
(Control)
левая
сторона имеет значение «Вход» (Input)
правая
сторона имеет значение «Выход» (Output)
нижняя
сторона имеет значение «Механизм»
(Mechanism)

Каждый
функциональный блок в рамках единой
рассматриваемой системы должен иметь
свой уникальный идентификационный
номер.

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

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

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

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

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

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

Модель
IDEF0 всегда начинается с представления
системы как единого целого – одного
функционального блока с интерфейсными
дугами, простирающимися за пределы
рассматриваемой области. Такая диаграмма
с одним функциональным блоком называется
контекстной диаграммой, и обозначается
идентификатором “А-0”. В пояснительном
тексте к контекстной диаграмме должна
быть указана цель (Purpose) построения
диаграммы в виде краткого описания и
зафиксирована точка зрения (Viewpoint).
Определение и формализация цели
разработки IDEF0-модели является крайне
важным моментом. Фактически цель
определяет соответствующие области в
исследуемой системе, на которых необходимо
фокусироваться в первую очередь.
Например, если мы моделируем деятельность
предприятия с целью построения в
дальнейшем на базе этой модели
информационной системы, то эта модель
будет существенно отличаться от той,
которую бы мы разрабатывали для того
же самого предприятия, но уже с целью
оптимизации логистических цепочек.
Точка зрения определяет основное
направление развития модели и уровень
необходимой детализации. Четкое
фиксирование точки зрения позволяет
разгрузить модель, отказавшись от
детализации и исследования отдельных
элементов, не являющихся необходимыми,
исходя из выбранной точки зрения на
систему. Например, функциональные модели
одного и того же предприятия с точек
зрения главного технолога и финансового
директора будут существенно различаться
по направленности их детализации. Это
связано с тем, что в конечном итоге,
финансового директора не интересуют
аспекты обработки сырья на производственных
станках, а главному технологу ни к чему
прорисованные схемы финансовых потоков.

В
процессе декомпозиции, функциональный
блок, который в контекстной диаграмме
отображает систему как единое целое,
подвергается детализации на другой
диаграмме. Получившаяся диаграмма
второго уровня содержит функциональные
блоки, отображающие главные подфункции
функционального блока контекстной
диаграммы и называется дочерней (Child
diagram) по отношению к нему (каждый из
функциональных блоков, принадлежащих
дочерней диаграмме соответственно
называется дочерним блоком – Child Box). В
свою очередь, функциональный блок —
предок называется родительским блоком
по отношению к дочерней диаграмме
(Parent Box), а диаграмма, к которой он
принадлежит – родительской диаграммой
(Parent Diagram). Каждая из подфункций дочерней
диаграммы может быть далее детализирована
путем аналогичной декомпозиции
соответствующего ей функционального
блока. Важно отметить, что в каждом
случае декомпозиции функционального
блока все интерфейсные дуги, входящие
в данный блок, или исходящие из него
фиксируются на дочерней диаграмме. Этим
достигается структурная целостность
IDEF0 – модели.

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

Часто
бывают случаи, когда отдельные интерфейсные
дуги не имеет смысла продолжать
рассматривать в дочерних диаграммах
ниже какого-то определенного уровня в
иерархии, или наоборот — отдельные дуги
не имеют практического смысла выше
какого-то уровня. Например, интерфейсную
дугу, изображающую “деталь” на входе
в функциональный блок “Обработать на
токарном станке” не имеет смысла
отражать на диаграммах более высоких
уровней – это будет только перегружать
диаграммы и делать их сложными для
восприятия. С другой стороны, случается
необходимость избавиться от отдельных
“концептуальных” интерфейсных дуг и
не детализировать их глубже некоторого
уровня. Для решения подобных задач в
стандарте IDEF0 предусмотрено понятие
туннелирования. Обозначение “туннеля”
(Arrow Tunnel) в виде двух круглых скобок
вокруг начала интерфейсной дуги
обозначает, что эта дуга не была
унаследована от функционального
родительского блока и появилась (из
“туннеля”) только на этой диаграмме.
В свою очередь, такое же обозначение
вокруг конца (стрелки) интерфейсной
дуги в непосредственной близи от блока
– приёмника означает тот факт, что в
дочерней по отношению к этому блоку
диаграмме эта дуга отображаться и
рассматриваться не будет. Чаще всего
бывает, что отдельные объекты и
соответствующие им интерфейсные дуги
не рассматриваются на некоторых
промежуточных уровнях иерархии – в
таком случае, они сначала “погружаются
в туннель”, а затем, при необходимости
“возвращаются из туннеля”.

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

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

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

—
ограничение количества подходящих с
одной стороны к одному функциональному
блоку (выходящих из одного функционального
блока) интерфейсных дуг четырьмя

Соседние файлы в папке Лекции

#
#
#
13.04.2015445.12 Кб85Лекция 6 рис 1.pcx
#
13.04.2015457.82 Кб80Лекция 6 рис 2.pcx
#
13.04.201512.21 Кб80Лекция 6.bp1
#
#
#
#
#
#

Источник

From Wikipedia, the free encyclopedia

IDEF0, a compound acronym («Icam DEFinition for Function Modeling», where ICAM is an acronym for «Integrated Computer Aided Manufacturing»), is a function modeling methodology for describing manufacturing functions, which offers a functional modeling language for the analysis, development, reengineering and integration of information systems, business processes or software engineering analysis.^[1]

IDEF0 is part of the IDEF family of modeling languages in the field of software engineering, and is built on the functional modeling language Structured Analysis and Design Technique (SADT).

Overview[edit]

The IDEF0 Functional Modeling method is designed to model the decisions, actions, and activities of an organization or system.^[2] It was derived from the established graphic modeling language Structured Analysis and Design Technique (SADT) developed by Douglas T. Ross and SofTech, Inc. In its original form, IDEF0 includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models.^[3] The US Air Force commissioned the SADT developers «to develop a function model method for analyzing and communicating the functional perspective of a system. IDEF0 should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices».^[2]

Where the Functional flow block diagram is used to show the functional flow of a product, IDEF0 is used to show data flow, system control, and the functional flow of lifecycle processes. IDEF0 is capable of graphically representing a wide variety of business, manufacturing and other types of enterprise operations to any level of detail. It provides rigorous and precise description, and promotes consistency of usage and interpretation. It is well-tested and proven through many years of use by government and private industry. It can be generated by a variety of computer graphics tools. Numerous commercial products specifically support development and analysis of IDEF0 diagrams and models.^[1]

An associated technique, Integration Definition for Information Modeling (IDEF1x), is used to supplement IDEF0 for data-intensive systems. The IDEF0 standard, Federal Information Processing Standards Publication 183 (FIPS 183), and the IDEF1x standard (FIPS 184) are maintained by the National Institute of Standards and Technology (NIST).^[1]

FIPS PUB 183 «Integration Definition for Function Modeling (IDEF0),» was withdrawn as a Federal Standard (in favor of OPEN Specifications and Standards) September 2, 2008, as cited in «The Federal Register», Volume 73, page 51276 (73FR/51276). ^[4]

History[edit]

During the 1970s, the U.S. Air Force Program for Integrated Computer Aided Manufacturing (ICAM) sought to increase manufacturing productivity through systematic application of computer technology. The ICAM program identified the need for better analysis and communication techniques for people involved in improving manufacturing productivity. As a result, in 1981 the ICAM program developed a series of techniques known as the IDEF (ICAM Definition) techniques which included the following:^[3]

IDEF0, used to produce a «function model». A function model is a structured representation of the functions, activities or processes within the modeled system or subject area.^[5]
IDEF1, used to produce an «information model». An information model represents the structure and semantics of information within the modeled system or subject area.^[6]
IDEF2, used to produce a «dynamics model». A dynamics model represents the time-varying behavioral characteristics of the modeled system or subject area.^[7]

In 1983, the U.S. Air Force Integrated Information Support System program enhanced the IDEF1 information modeling technique to form IDEF1X (IDEF1 Extended), a semantic data modeling technique. By the 1990s, IDEF0 and IDEF1X techniques are widely used in the government, industrial and commercial sectors, supporting modeling efforts for a wide range of enterprises and application domains. In 1991 the National Institute of Standards and Technology (NIST) received support from the U.S. Department of Defense, Office of Corporate Information Management (DoD/CIM), to develop one or more Federal Information Processing Standard (FIPS) for modeling techniques. The techniques selected were IDEF0 for function modeling and IDEF1X for information modeling. These FIPS documents are based on the IDEF manuals published by the U.S. Air Force in the early 1980s.^[3]

IDEF0 topics[edit]

Top-Level Context Diagram

The IDEF0 approach[edit]

IDEF0 may be used to model a wide variety of automated and non-automated systems. For new systems, it may be used first to define the requirements and specify the functions, and then to design an implementation that meets the requirements and performs the functions. For existing systems, IDEF0 can be used to analyze the functions the system performs and to record the mechanisms (means) by which these are done. The result of applying IDEF0 to a system is a model that consists of a hierarchical series of diagrams, text, and glossary cross-referenced to each other. The two primary modeling components are functions (represented on a diagram by boxes) and the data and objects that inter-relate those functions (represented by arrows).^[3]

IDEF0 Building blocks[edit]

Integration Definition for Function Modeling (IDEF0) Box Format

The IDEF0 model displayed here on the left is based on a simple syntax. Each activity is described by a verb-based label placed in a box. Inputs are shown as arrows entering the left side of the activity box while output are shown as exiting arrows on the right side of the box. Controls are displayed as arrows entering the top of the box and mechanisms are displayed as arrows entering from the bottom of the box. Inputs, Controls, Outputs, and Mechanisms (ICOM) are all referred to as concepts.^[2]

Arrow : A directed line, composed of one or more arrow segments, that models an open channel or conduit conveying data or objects from source (no arrowhead) to use (with arrowhead). There are 4 arrow classes: Input Arrow, Output Arrow, Control Arrow, and Mechanism Arrow (includes Call Arrow). See Arrow Segment, Boundary Arrow, Internal Arrow.
Box : A rectangle, containing a name and number, used to represent a function.

Box Syntax
Arrow Syntax
Arrow Positions and Roles
Label and Name Semantics

Context : The immediate environment in which a function (or set of functions on a diagram) operates.
Decomposition : The partitioning of a modeled function into its component functions.

Example Top-level Diagram
Decomposition Structure
Detail Reference Expression Use
Arrow Fork and Join Structures

Fork : The junction at which an IDEF0 arrow segment (going from source to use) divides into two or more arrow segments. May denote unbundling of meaning.

Connections Between Boxes
Boundary and Internal Arrows
Typical Node Tree
Negative Node-Numbered Context

Function : An activity, process, or transformation (modeled by an IDEF0 box) identified by a verb or verb phrase that describes what must be accomplished.
Join : The junction at which an IDEF0 arrow segment (going from source to use) merges with one or more other arrow segments to form a single arrow segment. May denote bundling of arrow segment meanings
Node : A box from which child boxes originate; a parent box. See Node Index, Node Tree, Node Number, Node Reference, Diagram Node Number.

Graphical notation[edit]

IDEF0 is a model that consists of a hierarchical series of diagrams, text, and glossary cross referenced to each other. The two primary modeling components are:

functions (represented on a diagram by boxes), and
data and objects that interrelate those functions (represented by arrows).

As shown by Figure 3 the position at which the arrow attaches to a box conveys the specific role of the interface. The controls enter the top of the box. The inputs, the data or objects acted upon by the operation, enter the box from the left. The outputs of the operation leave the right-hand side of the box. Mechanism arrows that provide supporting means for performing the function join (point up to) the bottom of the box.^[1]

The IDEF0 process[edit]

The IDEF0 process starts with the identification of the prime function to be decomposed. This function
is identified on a “Top Level Context Diagram,” that defines the scope of the particular IDEF0 analysis. An example of a Top Level Context Diagram for an information system management process is shown in Figure 3. From this diagram lower-level diagrams are generated. An example of a derived diagram, called a “child” in IDEF0 terminology, for a life cycle function is shown in Figure 4.^[1]

Federal Information Processing Standards[edit]

In Dec 1993 the National Institute of Standards and Technology announcing the standard for Integration Definition for Function Modeling (IDEF0) in the category Software Standard, Modeling Techniques. This publication announces the adoption of the IDEF0 as a Federal Information Processing Standard (FIPS). This standard was based on the Air Force Wright Aeronautical Laboratories Integrated Computer-Aided Manufacturing (ICAM) Architecture from June 1981.^[3]

On September 2, 2008, the associated NIST standard, FIPS 183, has been withdrawn (decision on Federal Register vol. 73 / page 51276.^[4]

References[edit]

Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.

This article incorporates public domain material from the National Institute of Standards and Technology.

^ ^a ^b ^c ^d ^e Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.
^ ^a ^b ^c Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
^ ^a ^b ^c ^d ^e FIPS Publication 183 Archived 2009-02-27 at the Wayback Machine released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
^ ^a ^b Withdrawn FIPS Listed by Number, Updated 12/15/16)
^ ICAM Architecture Part II-Volume IV — Function Modeling Manual (IDEF0), AFWAL-TR-81-4023, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, June 1981.
^ ICAM Architecture Part II, Volume V — Information Modeling Manual (IDEF1), AFWAL-TR-81-4023, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, June 1981.
^ ICAM Architecture Part II, Volume VI — Dynamics Modeling Manual (IDEF2),
AFWAL-TR-81-4023, Materials Laboratory, Air Force Wright Aeronautical Laboratories, Air
Force Systems Command, Wright-Patterson Air Force Base, Ohio 45433, June 1981.

External links[edit]

Wikimedia Commons has media related to IDEF0.

FIPS Publication 183 released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST). (Withdrawn by NIST 08 Sep 02 see Withdrawn FIPS by Numerical Order Index)
Federal Register vol. 73 / page 51276 withdrawal decision
Overview of IDEF0 at www.idef.com

Источник

From Wikipedia, the free encyclopedia

IDEF0 is part of the IDEF family of modeling languages in the field of software engineering, and is built on the functional modeling language Structured Analysis and Design Technique (SADT).

Overview[edit]

History[edit]

IDEF0, used to produce a «function model». A function model is a structured representation of the functions, activities or processes within the modeled system or subject area.^[5]
IDEF1, used to produce an «information model». An information model represents the structure and semantics of information within the modeled system or subject area.^[6]
IDEF2, used to produce a «dynamics model». A dynamics model represents the time-varying behavioral characteristics of the modeled system or subject area.^[7]