Стандарт IDEF0

Стандарт IDEF0 Стандарт IDEF0 представляет совокупность методов, правил и процедур, предназначенных для построения функциональной модели, являющейся иерархически связанным структурным представлением действия (или множества действий) некоторого объекта, а также вещественных и информационных объектов (данных), необходимых для функционирования или являющихся результатом этого функционирования. Функциональная модель бизнес-процессов состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, которые отображают последовательности взаимосвязанных через общие объекты функций (операций, действий, работ — activity) бизнес-процесса. Достоинство функциональной модели заключается в простоте графического представления, которое использует всего два конструктивных элемента: - функциональный блок — описание функций, операций, действий, работ; - интерфейсная дуга — линия, связывающая функциональные блоки и описывающая объекты (потоки объектов). Функциональные блоки и интерфейсные дуги будут подробно рассмотрены позднее. Однако у вас может возникнуть вопрос: а почему, критикуя функциональный подход, мы должны рассматривать функциональное моделирование? Здесь под термином «функциональное моделирование» понимается моделирование процессов функционирования. А вот само функционирование должно строиться исходя из процессного подхода. Методология IDEF0 основана на следующих концептуальных положениях: Цели моделирования. Модель разрабатывается для понимания, анализа и принятия решений о реорганизации (реинжиниринге) или замене существующего либо проектировании нового БП. Модель описывает, что происходит в БП, как им управляют, какие сущности он преобразует, какие ресурсы использует и что производит, частями (элементами) БП могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). Блочное моделирование и его графическое представление. Изучаемый БП представляется в виде набора взаимодействующих и взаимосвязанных блоков, отображающих работы, операции, действия. В IDEF0 работы, операции, действия, происходящие в БП и его элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме, основном документе при анализе и проектировании БП, блок представляется прямоугольником. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешним по отношению к моделируемому БП окружению, представляются стрелками, входящими в блок или выходящими из него. Лаконичность и точность. Документация, описывающая БП, должна быть точной и лаконичной. Многословные характеристики, изложенные в форме традиционных текстов, неудобны. Графический язык позволяет лаконично, однозначно и точно показать все блоки БП и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи. Передача информации. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (разработчика или рабочей группы) к другому. К числу таких средств относятся:  диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые;  метки на естественном языке для описания блоков и стрелок, а также глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы;  последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем, на нижних уровнях, происходит их детализация и уточнение; 2  древовидные схемы иерархии диаграмм и блоков, обеспечивающие обозримость модели в целом и всех входящих в нее деталей. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила рассмотрим позднее. Здесь приводится только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться для того, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации. Итерационное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итерационную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов — экспертов в предметной области, к которой относится объект моделирования. Отделение «организации» от «функции». При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (организации, предприятия, фирмы, компании). Это помогает избежать субъективной точки зрения, навязанной организационной структурой и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, вопервых, оценить адекватность модели, а во-вторых, предложить решения, направленные на совершенствование этой структуры. Компонентами синтаксиса IDEF0 являются: блоки — представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование; стрелки — представляют данные или материальные объекты, связанные с функциями; диаграммы — обеспечивают формат графического и словесного описания моделей. Достоинство функциональной модели заключается в простоте графического представления, которое использует всего два конструктивных элемента: «блок» и «стрелки». Семантика языка IDEF0 устанавливает правила отображения при помощи блоков и стрелок моделируемых функций, работ, операций, действий, и их интерфейсов. Более подробно вопросы синтаксиса и семантики диаграмм IDEF0 будут рассмотрены в следующих темах (см. темы 7-9). Итоги по теме 1. Сущность функционального подхода к моделированию бизнес-процессов сводится к построению схемы процесса в виде последовательности работ, на входе и выходе которых отражаются объекты различной природы (материальные и информационные объекты, используемые ресурсы, организационные единицы...), необходимые для функционирования или являющиеся результатом функционирования. 2. Основными компонентами функционального моделирования являются диаграммы, содержащие графические элементы и текстовые описания. 3. Основными графическими компонентами функционального моделирования являются блоки, представляющие функции, и интерфейсные дуги, представляющие потоки объектов различной природы. 3 Описание функциональных блоков в стандарте IDEF0 Функциональный блок изображается в виде прямоугольника и представляет функцию или активную часть процесса, продуцирующую действие. Поэтому названиями блоков должны быть глаголы в неопределенной форме с последующим дополнением, например, «принять заказ», «определить потребность» и т.д. Название записывается внутри прямоугольника, поэтому должно быть кратким, но в то же время отражать суть процесса. Как правило, название дается по названию действия, обеспечивающего основной выходной результат процесса. Блоки на диаграмме нумеруются. Номер проставляется в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте. Пример графического изображения, обозначения и нумерации блока представлен на рис.11. Синтаксические правила для функциональных блоков: 1. Блоки должны быть прямоугольниками с прямыми углами. 2. Размеры блоков должны быть достаточными для того, чтобы включать имя блока. 3. Имя блока должно отражать сущность процесса. 4. Блоки должны быть нарисованы сплошными линиями. 5. Цвета линий различных блоков могут быть различными. Число блоков на одной диаграмме должно быть от двух до семи. Ограничение снизу выбрано из соображений здравого смысла для обеспечения информативности декомпозиции. Ограничение сверху определяется возможностями человеческого восприятия и поддерживает сложность диаграммы и модели на уровне, доступном для чтения, понимания и использования. Блоки размещают на диаграмме в определенном порядке — по степени важности или по порядку очередности выполнения. Этот порядок называется доминированием. Доминирование можно понимать как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком на диаграмме может быть либо первая из требуемой последовательности действий функция, либо планирующая или контролирующая функция. Более доминирующие блоки размещаются выше и левее относительно менее доминирующих. В результате получается ступенчатая схема, показывающая, какие функции оказывают большее влияние на остальные. Размещать блоки в произвольном порядке не рекомендуется. Тем более что и в жизни всегда можно выделить четкий порядок следования либо подчинения различных действий. Поэтому если блоки размещаются в порядке доминирования, то это один из критериев правильности их выделения. Рекомендованный принцип размещения блоков в порядке доминирования представлен в таблице (таблица 3). 4 Каждый блок при необходимости может подвергаться декомпозиции, т.е. разделяться на составляющие действия. Декомпозиция порождает очередную диаграмму модели, которая детализирует родительский блок. У порождающего блока может быть только одна диаграмма декомпозиции. Отметим, что в ходе разработки модели могут возникать различные альтернативные варианты декомпозиции. Такие варианты должны особым образом обозначаться (как правило, в виде префикса FEO (от первых букв английского выражения «For Exposition Only») к номеру диаграммы). Связи блоков и детализирующих их диаграмм можно проследить по соответствующим номерам. Для нумерации диаграмм применяется правило наращивания номера. Пример нумерации дерева диаграмм, изображенного ранее (см. рис. 10), представлен на рис. 12. Такой способ нумерации обеспечивает уникальность номеров блоков во всей модели. Допускается ставить точки между цифрами при наращивании номеров. Каждая сторона функционального блока имеет определенное назначение (см. рис. 13): - левая предназначена для входов; - верхняя - для управления; - правая - для выходов; - нижняя - для механизмов (исполнителей). 5 Рис. 13. Спецификация сторон функциональных блоков в стандарте IDEF0 Такая спецификация отражает определенные системные принципы, принятые при построении диаграмм модели в стандарте IDEF0: - входы преобразуются в выходы; - управление предписывает или ограничивает условия выполнения преобразований. Управление в ходе выполнения БП, как правило, остается неизменным; - механизмы (исполнители) показывают, кто или что выполняет преобразование. По завершении БП механизмы (исполнители) могут покидать (выводиться) из БП практически в неизменном состоянии. Эти принципы могут быть записаны следующим образом: в результате выполнения процесса, «вход» под воздействием «управления» преобразуется в «выход» посредством «механизма» (исполнителя). И вот для того, чтобы четко выделить такую спецификацию сторон функциональных блоков, углы прямоугольников не должны закругляться! Выходы одного блока могут быть входами, или управлениями, или механизмами (исполнителями) для других. Взаимосвязи блоков друг с Другом и с внешней средой отражаются интерфейсными дугами. Итоги по теме 1.Функция или активная часть процесса изображается в виде Прямоугольника (блока). 2.Стороны блока имеют определенное назначение: вход, управление, выход, механизм. 3.На диаграмме блоки размещаются в порядке доминирования. 4.На одной диаграмме помещаются не менее двух и не более семи блоков. 6 Описание интерфейсных дуг в стандарте IDEF0 Интерфейсные дуги изображаются в виде стрелок, ориентация которых отображает направление потоков объектов. Объекты могут быть различной природы: материальные, финансовые, информационные. Стрелка формируется из одного или более отрезков прямых (сегментов) и наконечника на одном конце. Если стрелки формируются из нескольких отрезков, то эти отрезки должны быть либо горизонтальными, либо вертикальными. Горизонтальные и вертикальные сегменты стрелок сопрягаются друг с другом закругленными линиями. Синтаксические правила для интерфейсных дуг: 1. Стрелки могут состоять только из вертикальных или горизонтальных отрезков. 2. Вертикальные и горизонтальные участки ломаных стрелок соединяются при помощи закруглений. 3. Концы стрелок должны присоединяться к внешним границам функционального блока и на его сторонах; присоединение в углах блока не допускается. 4. Стрелки должны быть нарисованы сплошными линиями. 5. Цвет и толщина линий для различных стрелок (или их фрагментов) могут быть различными. Стрелки не представляют последовательность событий, как в традиционных блоксхемах. Они лишь показывают потоки объектов. Потоки объектов однонаправленны, т.е. на интерфейсной дуге может быть только одна стрелка. Графические правила изображения стрелок представлены на рис. 14. Дуги помечаются текстовыми метками. Так как метки изображают объекты, то метки должны быть именами существительными или существительными с определениями. Рис.14. Интерфейсные дуги в стандарте IDEF0 Метки размещаются либо непосредственно на дугах, либо на свободных местах диаграммы и связываются с дугами при помощи выносных зигзагообразных линий рис. 15. Рис.15. Метки интерфейсных дуг в стандарте IDEF0 Подписи после разветвления или слияния уточняют объекты на соответствующих дугах. Особенности обозначения дуг после слияния или разветвления показаны в таблице (таблица 4). Варианты правильного и ошибочного обозначения дуг после разветвления или слияния показаны в таблице (таблица 5). По характеру использования в функциональных блоках объекты могут быть: 7 - входными; - выходными; - управляющими; - механизмами (исполнителями). Входные объекты преобразуются в функциональных блоках в выходные. При этом выходной объект — это вновь созданный объект или преобразованный старый объект. В последнем случае новое качество объекта, как правило, обозначается прилагательным, например «принятый заказ», «отложенный заказ», «удаленный заказ», «выполненный заказ» и т.д. Таблица 5 Варианты представления на диаграммы IDEF0 разветвлений и слияний дуг Управляющие объекты соответствуют нормативным актам (законодательным актам, инструкциям, планам, приказам), на основе которых выполняются процессы. Кроме того, управляющие объекты рассматриваются как ограничения, обстоятельства, условия выполнения процесса, например, «номенклатура — ценники», «списки клиентов и поставщиков», «состояние запасов», «состояние расчетного счета», «загруженность производственных мощностей» и пр. Управляющие объекты должны обязательно отражаться в функциональной модели, а входные объекты — не обязательно. В случае отсутствия входного объекта какой-либо управляющий объект одновременно является и входным, например, заказ, на основе которого выполняется работа, преобразуется внутри функционального блока в готовый продукт. 8 Механизмы — это объекты, которые исполняют процессы (исполнители). К механизмам относят структурные подразделения предприятия, персонал, автоматизированные рабочие места, оборудование. Интерфейсные дуги в соответствии со своим типом должны соединяться с соответствующими сторонами функциональных блоков (см. рис. 13, стр. 63):  входные дуги — с левой стороной блока;  выходные дуги — с правой стороной блока;  управляющие дуги — с верхней стороной блока;  дуги механизмов (исполнителей) — с нижней стороной блока. Объекты могут выступать в различных блоках в разных ролях, например, выходной объект одного блока является входным объектом, или управляющим объектом, или механизмом для другого функционального блока. Правила графического изображения взаимосвязей между блоками представлены в таблице (таблица 6). Объекты, связанные с границами диаграммы, выступают только в одной роли. Дуги этих объектов являются интерфейсами между диаграммой и остальной частью модели. Граничные дуги диаграммы должны быть согласованы с дугами родительского блока. Это означает, что интерфейсные дуги диаграммы должны иметь тот же тип и наименование, что и соответствующие им дуги у декомпозируемого блока. В SADT принята кодировка IСОМ, позволяющая точно идентифицировать и проверить связи по дугам между диаграммами. ICOM — это аббревиатура слов Input (вход), Control (управление), Output (выход), Mechanism (механизм). Принцип кодировки IСОМ иллюстрирует рис. 16. Таблица 6 Варианты графического изображения прямых и обратных взаимосвязей в стандарте IDEF0 Использование IСОМ-меток позволяет быстро проверять согласованность внешних дуг диаграммы с граничными дугами соответствующего родительского блока. IСОМ-метки формируются в соответствии с типом дуги (стороной функционального блока) по следующему правилу: - I1,I2, I3,... — последовательно обозначаются входные объекты; - О1,О2, ОЗ, ... — последовательно обозначаются выходные объекты; - С1,С2, СЗ, ... — последовательно обозначаются управляющие объекты; - М1, М2, МЗ, ... — последовательно обозначаются механизмы. 9 В ряде случаев нецелесообразно передавать объекты с одного уровня декомпозиции на другой. Например: - важные объекты системы, не показанные ранее на более высоких уровнях описания модели, могут появляться при описании новых деталей. В то же время эти новые объекты не всегда являются столь значимыми, чтобы их показывать на более высоких уровнях модели; - некоторые объекты могут быть необходимы лишь для описания верхних уровней модели. Их передача на более детальные уровни загромоздит диаграмму. Если дугу нецелесообразно передавать на другой уровень детализации, то ее помещают в «туннель». Помещение дуги в «туннель» является способом скрыть ее источник (приемник). Существуют два вида помещаемых в туннель дуг: 1. Со скрытым источником — дуга как бы появляется «из туннеля». 2. Со скрытым приемником — дуга как бы уходит «в туннель». Дуга со скрытым источником помечается круглыми скобками у своего начала. Дуга со скрытым приемником помечается круглыми скобками у своего конца (у стрелки). Результат «скрытия источника» представлен на рис. 17, а «скрытия приемника» — на рис. 18. Можно туннелирование трактовать и по-другому. Так, если круглые скобки стоят у «внешнего» края блока, то дуга не передается на следующий уровень детализации; а если у «внутреннего», то не появляется на предыдущем уровне детализации. Результаты такого туннелирования представлены на рис. 19 и рис. 20 соответственно. 10 Таким образом, туннельные изображения используют в двух случаях: 1. Для предотвращения заполнения нежелательными подробностями диаграмм высших уровней. 2. Для запрета передачи обобщенных описаний объектов в диаграммы нижних уровней. Помещение дуг в туннели — это важный инструмент регулирования сложности модели. Но пользоваться этим инструментом необходимо аккуратно. Важным инструментом регулирования сложности диаграммы являются сами названия дуг. Здесь необходимо активно использовать правило агрегирования, когда одно дуга может обозначать некоторую совокупность объектов, которые могут сходиться / расходиться. От одной стороны функционального блока не рекомендуется отводить/присоединять более 5-7 дуг. Итоги по теме 1.Все взаимодействия в функциональной модели происходят посредствам потоков объектов. 2.Потоки объектов в функциональной модели представляются в виде интерфейсных дуг. 3.Интерфейсные дуги изображаются в виде направленных стрелок и подписываются. 11 Учебный пример описания бизнес-процесса в стандарте IDEF0 Рассмотрим пример построения модели некоторого бизнес-процесса. Наш учебный пример будет настолько обобщенным, что мы даже не будем давать этому процессу названия. Не будем также уточнять и названия его элементов (объектов). Не будем рассматривать и итерации (уточнения) модели. Вместе с тем все основные элементы построения модели мы выполним. Итак, все начинается с построения диаграммы верхнего уровня рис.21. Рис. 21. Диаграмма верхнего уровня в стандарте IDEF0 — диаграмма А-0 На этой диаграмме должны быть обязательно представлены цель и точка зрения моделирования. Как видно из диаграммы верхнего уровня модели (см. рис.21), на ней представлен лишь один блок — это собственно и есть моделируемый БП. Интерфейсные дуги обозначают взаимосвязи моделируемого БП с внешним окружением. После того как построено графическое описание, строится вербальное (текстовое). Текстовое описание, как правило, включает общее описание и описание всех объектов. Общее описание должно включать краткую характеристику моделируемого процесса или общую логику взаимодействия процессов (для диаграмм-декомпозиций). Описания объектов содержат краткую характеристику (определение) и более подробное описание (комментарии) по каждому из блоков или интерфейсных дуг, помещенных на диаграмме. Затем для продолжения моделирования определяют состав декомпозиции моделируемого процесса. Результаты структурной декомпозиции, как правило, представляют в виде иерархического дерева рис. 22. Рис. 22. Структура декомпозиции бизнес-процесса в стандарте IDEF0 12 После того как определен состав системы, приступают к декомпозиции ее элементов. Декомпозицию проводят сверху вниз. В нашем случае первой необходимо провести декомпозицию блока А0. В начале декомпозиции производится «подготовительная работа»: - необходимо на новую диаграмму перенести все интерфейсные дуги декомпозируемого родительского блока (без учета туннельных); - поместить на новую диаграмму в порядке доминирования блоки с выделенными функциями, на которые предполагается декомпозировать родительский блок. Это достаточно простой и формальный этап составления новой диаграммы декомпозиции. Его результаты представлены на рис. 23. Получив такой «шаблон» (или «форму»), необходимо его заполнить — построить взаимосвязи блоков с внешним окружением, а также внутренние взаимосвязи. Может существовать множество различных вариантов и последовательностей выполнения этого построения даже для одной и той же диаграммы. В качестве одного из возможных вариантов предлагаем рассмотреть последовательное построение взаимосвязей для каждого блока в порядке их расположения на диаграмме. Этот вариант и последовательность его реализации представлены на рис. 24. Здесь (см. рис. 24) мы видим, что вначале были построены взаимосвязи для блока А1. Затем на диаграмму были добавлены взаимосвязи для блока А2. Затем — для блока А3. При построении взаимосвязей для очередного блока могут уточняться взаимосвязи остальных блоков. 13 14 Построив все взаимосвязи, нам необходимо привести диаграмму к читаемому виду. Для этого следует: o устранить, по возможности, пересечение дугами надписей; o максимально разнести параллельно идущие линии дуг; o изменяя топологию, снизить количество пересечений дуг; o выполнить другие графические преобразования, облегчающие визуальное восприятие диаграммы. Результаты построения диаграммы по нашему учебному примеру представлены на рис. 25. Теперь необходимо сформировать вербальное описание диаграммы — дать текстовые описание логики процесса и всех элементов (блоков и дуг). С дугами, которые идут от границы диаграммы, проще — их описание можно взять из вербального описания диаграммы А-0. Описание же по всем остальным вновь введенным объектам, а также по логике внутренних взаимодействий необходимо создать. Текстовое описание диаграммы и ее объектов помогает однозначному восприятию модели различными людьми, которые в той или иной степени могут использовать модель. После того как создано графическое и текстовое описание, необходимо решить, нужно ли дальше проводить декомпозицию или представленной детализации процессов достаточно. В нашем примере мы решили, что блок А2 должен иметь декомпозицию. Поэтому для этого блока необходимо продолжить процесс моделирования. Для того чтобы из самой диаграммы было видно, какие блоки подвергаются последующей декомпозиции, а какие — нет, левый верхний угол блоков, которые декомпозиции не подвергаются, перечеркивается чертой. Соответственно, если такой черты нет — блок имеет декомпозицию. В нашем примере блоки А1 и А3 имеют черту в верхнем левом углу, и значит, они в дальнейшем (или пока) декомпозироваться не будут. А если будут, то черта в левом верхнем углу этих блоков должна быть убрана Ну вот, декомпозиция и ее описание закончены! Но может найтись эксперт, который скажет, что он видит систему по-другому, или в ходе обсуждения варианта построения системы могут возникнуть альтернативные предложения, или может потребоваться выделить некоторые наиболее важные компоненты сложной диаграммы описания. Для того чтобы иметь возможность включать различные варианты в рассмотрение или представлять отдельные элементы системы, может быть использовано представление специального типа, так называемая FEO-диаграмма (For Exposition Only - только для изображения). Пример FЕО-диаграммы для построенной ранее диаграммы А0 учебного примера (см. рис. 25) представлен на рис. 26. 15 Рис. 26. Диаграмма FЕО, иллюстрирующая только внутренние взаимосвязи функциональных блоков Диаграмма на рис.26 сосредотачивает внимание на внутренних взаимодействиях и взаимодействиях по входам-выходам, что позволяет, например, оценивать необходимость и достаточность функциональных преобразований или проверять состав внутренних потоков, генерируемых процессом. Итоги по теме 1. Функциональная модель начинается с построения общего описания процесса и его взаимодействия с окружающим миром, которое представляется в диаграмме нулевого уровня или контекстной диаграмме. На контекстной диаграмме также должна отражаться цель моделирования (например, сокращение длительности выполнения процесса, или сокращение издержек при повышении качества обслуживания, или разработка нового процесса и т.д.) и точка зрения, с позиции которой рассматривается модель (директор организации, ITменеджер, отдел логистики и т.д.). 2. Диаграммы следующих уровней детализируют функции процесса каждого предыдущего уровня. Детализация продолжается до уровня элементарных действий, которые уже не нужно подвергать декомпозиции для получения ответов на поставленные перед моделью вопросы. 3. На каждом уровне рекомендуется размещать не менее двух и не более семи функциональных блоков. Число уровней декомпозиции не ограничено. Критерием окончания декомпозиции является достижение цели моделирования — получение ответов на поставленные вопросы с требуемой точностью. 4. Все объекты и логика диаграммы должны иметь текстовые описания. 5. Построение декомпозиции — процесс многовариантный и творческий. 6. Различные варианты декомпозиции могут быть представлены с помощью диаграмм специального вида — FЕО-диаграмм.