Описание idef0 модели. В чем трудность применения IDEF0. Что такое IDEF0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще статьи по данной теме.

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

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

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

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

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

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

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

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

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

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

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

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

В общем, нотации можно назвать языком программирования при бизнес-анализе

Что такое IDEF0?

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

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

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

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

Стрелки могут быть:

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

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

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

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

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

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

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

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

Основной блок – «Написать статью».

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

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

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

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

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

В нашем случае работа делится на 4 основных этапа:

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

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

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

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

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

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

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

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

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

Я лично считаю, что на первом этапе нет ничего лучше, чем обычная бумага, простой карандаш и ластик, чтобы вносить корректировки в случае ошибок.

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

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

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

Требования стандарта IDEF0

Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

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

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

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

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

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

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

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

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

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

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

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

Основные элементы диаграммы IDEF0.

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

Основными элементами диаграммы в нотации IDEF0 являются:

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

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

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

Рис . 5.2.

Стрелки в стандарте IDEF0 не показывают движение данных или последовательность событий, как на DFD- или WFD- диаграммах. Здесь они предназначены для указания данных и объектов, необходимых для осуществления данной функции, и что в результате ее реализации получается. Стрелки могут быть прямыми или ломаными. В последнем случае угол сгиба должен равняться 90°. На схеме они должны располагаться вертикально или горизонтально, но диагонали - не допускается. Концы стрелок должны касаться внешней границы блока, но не заходить за нее. Также недопустимо присоединять стрелку к углу блока, поскольку в зависимости от того, с какой стороны к блоку подходит стрелка, можно определить назначение объекта, который она представляет. В рамках данного стандарта выделяют четыре типа стрелок: входящие (вход, Input), выходящие (выход, Output), стрелки управления (управление, Control), стрелки механизма (механизм, Mechanism).

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

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

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

Важно запомнить

Часто при описании бизнес-процессов с помощью методологии IDEF0 начинающие аналитики допускают ошибку, заключающуюся в несоблюдении правила: "Сущности входящего и выходящего объекта одинаковы".

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

Рис. 5.3. IDEF0-диаграмма процесса "Прием сотрудника на работу"

Стрелка управления, которая входит в блок сверху, показывает условия и элементы управления, необходимые для выполнения функции, напри

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

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

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

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

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

Контекстная диаграмма представляет собой один блок со стрелками, которые отражают связи описываемого процесса с внешней средой. Таким образом, можно говорить о том, что контекстная диаграмма показывает область моделирования и ее границы. Название блока соответствует названию описываемой функции (процесса). Номер контекстной диаграммы всегда нулевой. Его принято обозначать "АО". Когда речь идет об описании деятельности организации или подразделения, то при создании контекстной диаграммы в качестве названия указывается название проекта или краткая формулировка описываемой деятельности. Например, "Оформить дебетовую банковскую карту" или "Управлять персоналом". Такой же подход применяется и при названии стрелок, входящих и исходящих от единственного блока контекстной диаграммы. На рис. 5.4 приведен пример контекстной диаграммы процесса "Управление претензиями клиентов". Кроме того, контекстная диаграмма должна содержать описание цели построения модели и сведения о точке зрения, в соответствии с которой строится модель IDEF0.

Диаграмма верхнего уровня является первой дочерней диаграммой по отношению к контекстной. На рис. 5.5 приведена диаграмма верхнего уровня процесса "Управление претензиями клиентов". Она является дочерней диаграммой по отношению к контекстной, приведенной на рис. 5.4. Функция, показанная на контекстной диаграмме (АО), раскладывается на подфункции посредством создания данной дочерней диаграммы верхнего уровня. Затем каждая из представленных подфункций раскрывается в виде дочерних диаграмм более низкого уровня. Степень декомпозиции в данном случае определяется целью моделирования, т.е. разбиение функции на подфункции, операции и т.д. происходит до тех пор, пока не будут достигнуты цели и задачи моделирования.

Рис. 5.4. Контекстная диаграмма процесса "Управление претензиями клиентов"

В рамках данной методологии моделирования различают родительскую и дочернюю диаграммы. Их иерархические отношения иллюстрирует рис. 5.1.

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

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

Функциональные блоки на диаграмме 1DEF0 должны размещаться последовательно и в порядке степени их важности. Их принято располагать по диагонали (см. рис. 5.5).

Каждая дочерняя диаграмма состоит из дочерних блоков и стрелок, которые обеспечивают необходимую на данном уровне детализацию родительского блока. Таким образом, дочерняя диаграмма описывает ту же предметную область, что и ее родительский блок. Примером может служить диаграмма декомпозиции подпроцесса "Зарегистрировать претензию", которая представлена на рис. 5.6. Она является дочерней диаграммой для диаграммы верхнего уровня процесса "Управление претензиями клиентов" (см. рис. 5.5), поскольку она представляет собой более детальное описание одного функционального блока (первого) родительской диаграммы. Аналогичным образом могут быть подробно описаны и другие функциональные блоки данной родительской диаграммы.

Рис. 5.5. Диаграмма верхнего уровня процесса "Управление претензиями клиентов"

Рис. 5.6. Диаграмма подпроцесса "Зарегистрировать претензию"

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

О методологии IDEF0

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

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

Элементы, используемые для IDEF0

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

Возможности использования IDEF0

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

Типы связей между процессами IDEF0

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

1. Иерархическая («часть» - «целое») связь.

2. Управляющая (регламентирующая, подчинённая):

2) обратная связь управления.

3. Функциональная или технологическая:

2) обратная входная.

3) потребительская;

4) логическая;

5) методическая или коллегиальная;

6) ресурсная;

7) информационная;

8) временная;

9) случайная.

Построение блоков и связей в диаграммах

Методология IDEF0 предоставляет целый ряд правил и рекомендаций по своему использованию и улучшению качества использования. Так, в диаграмме отображается один блок, на котором можно задать название системы, её назначение. К блоку или от блока ведёт 2-5 стрелок. Можно больше или меньше, но как минимум две стрелки необходимы для входа/выхода, а остальные для дополнительных работ и их указания на диаграмме. Если стрелок больше 5, следует задуматься об оптимальности построения модели, и нельзя ли сделать её ещё более детализированной.

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

Количество блоков, которое будет на одной диаграмме, рекомендовано в численности 3-6. Если их меньше, то такие диаграммы вряд ли будут нести смысловую нагрузку. Если количество блоков будет огромным, то прочитать такую диаграмму будет весьма сложно, учитывая наличие ещё и дополнительных стрелок. Для улучшения восприятия информации размещать блоки рекомендуется сверху вниз и слева направо. Такое расположение позволит отразить логику исполнения последовательности процессов. А также стрелки будут создавать меньшую путаницу, обладая минимальным количеством пересечений друг с другом.

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

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

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

Именование

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

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

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

Информация о стрелках

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

Пример реализации методологии IDEF0 на конкретной модели

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

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

Исходной информацией выступают:

данные про линию путей;
паспорт всей дистанции;
план пути.

Управляющие данные:

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

Результатом модели является:

Ограничение допустимых скоростей с указанием причины ограничения.
Допустимые скорости при движении на раздельных пунктах и во время перегона составов.

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

Заключение

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

Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

· Стрелки входа (входят в левую грань работы) - изображают данные или объекты, изменяемые в ходе выполнения работы.

· Стрелки управления (входят в верхнюю грань работы) - изображают правила и ограничения, согласно которым выполняется работа.

· Стрелки выхода (выходят из правой грани работы) - изображают данные или объекты, появляющиеся в результате выполнения работы.

· Стрелки механизма (входят в нижнюю грань работы) - изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…)

· Стрелки вызова (выходят из нижней грани работы) - изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.

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

Рисунок 7.1. Функциональный блок и интерфейсные дуги

Работы на диаграммах изображаются в виде прямоугольников (функциональные блоки). Каждая работа изображает какую-либо функцию или задачу и именуется глаголом или глагольной фразой, обозначающей действие, например «Изготовление изделия», «Обслуживание клиента» и т.д. Стрелки помечаются существительным и обозначают объекты или информацию, связывающую работы между собой и с внешним миром.

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

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.7.2 и Рис.7.4. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).

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

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

Рисунок 7.2 - Пример контекстной диаграммы

Как видно на Рис.7.2, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.

Рисунок 7.3 - Пример диаграммы декомпозиции

Рисунок 7.4 - Пример контекстной диаграммы

Рисунок 7.5 - Пример диаграммы декомпозиции

Иерархия диаграмм

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

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

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

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

Рисунк 7.6 - Структура SADT-модели. Декомпозиция диаграмм

Рисунок 7.7 - Соответствие должно быть полным и непротиворечивым

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

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

Рис. 7.8. Пример механизма

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7.9 показано типичное дерево диаграмм.

Рисунок 7.9 - Иерархия диаграмм