Содержание
Введение ............................................................................................. 3
1. Процесс создания IDEFO-модели.................................................. 4
2. Построение IDEF0-модели............................................................. 11
3. Принципы моделирования в IDEF0.............................................. 17
Заключение......................................................................................... 19
Список литературы ........................................................................... 20
Введение
IDEF0 - Function Modeling - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов.
Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому.
Исходная информация для IDEF0-модели поступает к разработчику из разных источников: от людей и от документов. Люди, являющиеся источниками информации, обладают конкретными знаниями о частных свойствах объекта моделирования, управлении или ходе бизнес–процесса и их участие в моделировании может быть ограничено несколькими минутами опроса.
Однако именно эти источники обеспечивают основу для моделирования.
Информация, предоставляемая ими, используется для создания модели, а восприятие этой информации обеспечивает разработчику понимание, необходимое для построения точной модели.
Целью работы является раскрыть процесс создания и построения IDEFO-модели.
Для достижения поставленной цели в работе определены следующие задачи:
- изучить процесс создания IDEFO-модели;
- охарактеризовать построение IDEF0-модели;
- рассмотреть основные принципы моделирования в IDEF0.
1. Процесс создания IDEFO-модели
Процесс моделирования в IDEF0 включает в себя:
- сбор информации об исследуемом объекте;
- документирование полученной информации и представление ее в виде модели;
- уточнение модели посредством итеративного рецензирования.
Сбор и изучение информации должны проводиться на всех этапах исследования объекта.
Можно назвать следующие способы получения сведений об изучаемой системе:
- чтение документации;
- наблюдение за работой системы;
- опрос с помощью анкет большой группы специалистов;
- беседа с экспертами, обладающими соответствующим опытом и необходимыми сведениями о системе;
- использование той информации, которой уже владеет автор;
- построение гипотетического описания с последующим обращением к экспертам с просьбой помочь приблизить полученное описание к действительности [7, c. 9].
Анкетирование является начальным этапом обследования. Анкеты позволяют составить поверхностное представление о деятельности предприятия, что помогает спланировать первоначальное распределение работ группы аналитиков.
Анкеты рассылаются руководителям структурных подразделений и должны содержать графы для фамилии и должности анкетируемого. Отдельно излагается просьба приложить шаблоны документов, с которыми работают сотрудники соответствующего подразделения. Список вопросов необходимо ограничить (не более 15 -20), а вся анкета не должна занимать более двух листов [6, c. 100].
Пример анкеты.
- Наименование подразделения.
- ФИО руководителя подразделения, номер его телефона.
- Координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться).
- Основные функции подразделения.
- Информация, поступающая из других подразделений (заявки, запросы, отчеты и т. п.).
- Информация, передаваемая в другие подразделения.
- Какая информация формируется ("рождается") в подразделении?
- С какими внешними предприятиями (банк, заказчик, поставщик и т. п.) взаимодействует подразделение и какой информацией обменивается?
- Физическое представление информационных потоков и хранилищ (документ, дискета, сеть, журнал, картотека и т. п.).
- Документы, поступающие от руководства, готовящиеся для руководства.
- Штатная структура и квалификация кадров.
- Техническое оснащение подразделения (компьютеры, сеть, модем)
- Подпись [3].
Просьба приложить:
1. Положение о подразделении.
2. Набор документальных форм (можно незаполненных), т. е. используемые формы, бланки и другие документы (например, карточка складского учета, отчет по форме N, наряд-задание, товарно-транспортная накладная).
Из всех путей сбора информации наиболее важный общение с экспертом, поскольку редко бывает так, чтобы вся необходимая информация была где-либо написана, а данные из анкет часто носят субъективный характер [2, c. 363].
Интервью это беседа с каким-либо лицом с целью сбора информации по рассматриваемому вопросу.
Интервьюирование является важнейшим и необходимым методом исследования, только с его помощью возможно разобраться во всех тонкостях применяемых на предприятии технологий. Современное предприятие, даже небольшого размера, является сложной системой. Конечно, руководство представляет ситуацию в целом, отдельные работники досконально знают свою деятельность, но полной картины протекания всех бизнес-процессов не имеет никто. Поэтому интервьюирование представителей всех звеньев организационно-штатной структуры позволяет понять и формализовать исследуемую систему [7, c. 11].
Имеются четыре типа интервью, которые могут проводиться на этапе получения знаний об исследуемом объекте:
- поиск фактов для понимания текущих операций (используется для того, чтобы установить содержание модели "как есть");
- выявление проблемы с целью установления будущих требований к системе (используется для проверки правильности модели "как есть" и формирования основы для модели "как должно быть");
- принятие решений относительно будущих возможностей системы (способствует определению содержания модели "как должно быть");
- разговор "автор читатель" (используется для того, чтобы решить проблемы, которые появляются в процессе построения IDEF0 модели) [2, c. 365].
Рекомендуется выделять три этапа при организации опроса: подготовка к опросу; проведение опроса; обработка результатов.
Подготовка к опросу. Процесс подготовки позволяет оптимизировать время, которое вы проведете, работая с источником информации. Это приобретает решающее значение, если вы ограничены в количестве встреч с экспертом (например, с руководителем организации).
Рекомендуются следующие шаги:
- выберите нужного собеседника;
- договоритесь о встрече;
- разработайте предварительную программу встречи;
- изучите доступную информацию о предмете разговора;
- согласуйте свои действия с группой проектировщиков.
Постарайтесь выбрать для встречи представителя соответствующей службы, в наибольшей степени обладающего нужными знаниями. После этого договоритесь с ним о скорой, насколько это возможно, встрече. Установите цель встречи и ограничьте беседу в пределах часа [5, c. 111].
Проведение опроса. Интервьюирование является наиболее сложной задачей: необходимо найти контакт с сотрудником и направить беседу в необходимое для аналитика русло. В начале разговора необходимо представиться и сформулировать цель встречи. Далее обговорите возможность ведения записей и согласуйте вопросы конфиденциальности. Затем сформулируйте первый вопрос, который задает тон всему разговору, поэтому хорошо продумайте его.
Записывайте IDEF0-функции и данные, попытайтесь набросать диаграмму. В ходе разговора задавайте вопросы, которые помогают уточнить или подтвердить полученную информацию, например:
- Можете ли вы привести пример
- Когда это произошло
- Есть ли у этого правила исключение
- Можете ли привести какие-нибудь цифры в подтверждение ваших слов? [7, c. 15]
Можно предложить несколько общих рекомендаций, касающихся линии поведения аналитика при интервьюировании:
- Тезис в начале беседы: "Я ничего (или почти ничего) не знаю о Вашей работе. Расскажите как можно подробнее, чем Вы занимаетесь". Даже если аналитик прекрасно знает предметную область, он не должен говорить много сам и учить интервьюируемого.
- Если специалист начал подробно рассказывать технологию работы, ни в коем случае нельзя его перебивать, необходимые уточнения можно сделать и в конце беседы.
- Если в беседе участвуют несколько аналитиков, вести беседу и задавать уточняющие вопросы должен один из них, неясные для других вопросы уточняются в конце беседы.
- Не стоит возражать. Нельзя задавать наводящих вопросов или вопросов с короткими ответами "да" или "нет". Следует дать эксперту возможность говорить то, что он хочет сказать, а не то, что от него хотят услышать.
- Задавая уточняющие вопросы, необходимо определить, является ли сообщаемая информация фактом или скорее мнением. Когда речь идет о времени, объеме или затратах, следует спрашивать о числах и количествах. Нужно уточнять источники и назначение данных, их формат, сроки сохранения, предполагаемое использование, требуемые изменения.
- Необходимо делать паузы, дать эксперту возможность подумать, что сказать дальше. Нельзя перебивать, подсказывая ответ или задавая другой вопрос [4, c. 123].
Интервьюируемые (90 %) предоставят всю необходимую информацию, если с ними вести беседу, соблюдая данные правила. Что касается остальных 10 %, то их можно типизировать следующим образом:
- "отказник" как правило, квалифицированный специалист, осознающий свою незаменимость и не желающий давать информацию. В данной ситуации возможны такие альтернативы: либо данная деятельность не будет включена в модель, либо она будет промоделирована на основании опыта и соображений здравого смысла;
- "говорун" обычно руководитель среднего звена, понимающий, что по-старому работать нельзя и хватающийся за любую возможность улучшить ситуацию. Очень полезный человек для поддержки проекта, но в беседе он готов бесконечно обсуждать свои трудности и проблемы. Получить от него необходимую информацию для построения модели практически невозможно. Единственный способ работы с ним обсуждение уже построенной (пусть примитивной и во многом ошибочной) модели с целью ее уточнения;
- "балласт" человек, давно работающий на предприятии и непонятно чем занимающийся. На вопросы типа: "Какие функции Вы выполняете?", "С какими документами Вы работаете?" агрессивно повторяет: "Я делаю все", "Со всеми документами", "Все документы ко мне приходят и все уходят". Какой-либо информации получить не удается по причине ее отсутствия. Естественно, никакого отражения подобной "деятельности" в модели не производится;
- человек, занимающий экзотическую и малопонятную должность типа "главный обогатитель". Представляет собой модификацию варианта "балласт" с той лишь разницей, что реально деятельность по обогащению (например, руды) существует и, следовательно, должна быть отражена в модели;
- "мелкая сошка" человек, не привыкший к проявлению интереса к себе и своей работе и занимающий низшую должность. При должном терпении реально получение того небольшого "куска" информации, которым он владеет [4, c. 124].
Беседу следует завершить плавно, договориться о времени следующей встречи (если она нужна), поставить эксперта в известность, как будет использована полученная информация и когда прислан материал на рецензирование.
Оформление результатов опроса. Ключевая информация, полученная в интервью, должна быть записана. Это можно сделать в виде: заметок, перечня функций и данных (объектов), эскизов диаграмм.
Оформляйте материалы сразу после встречи с экспертом. Посмотрите и закончите ваши заметки, а потом составьте IDEF0-глоссарий как средство определения новых понятий и терминологии. Затем набросайте диаграмму, определяя, какие еще вопросы следует задать и какие области исследовать [5, c. 113].
Результаты интервью оформляются в виде папки, копии которой распределяются среди участников проекта, а также среди других членов команды аналитиков (или даже интервьюируемых) с целью корректировки, добавления или исключения фактов, сведений и данных. Этот комплект (папка) должен содержать:
1. Титульный лист.
2. Интервью и последующую запись
- ФИО интевьюера (автора IDEF-модели);
- дата интервью;
- продолжительность интервью (начало и окончание);
- ФИО интервьюируемого
- должность и ответственность интервьюируемого
- номер телефона.
- дополнительные источники информации: документы, другие интервью (ФИО, должность, ответственность, адрес, номер телефона);
- существенные элементы информации - ключевые вопросы, рассмотренные в интервью;
- последующие вопросы или области, не охваченные в интервью;
- новые термины для проектного глоссария.
3. Список функций и данных (объектов).
4. Список основных интервьюируемых (разработанный при подготовке к интервью)
5. Примечания и эскизы диаграмм [6, c. 105].
2. Построение IDEF0-модели
Перед построением любой модели важно определить ориентацию модели, а именно: контекст, точку зрения и цель.
Контекст устанавливает содержание модели, как части окружающей среды. Это создает границу со средой путем описания внешних интерфейсов (дуг). Контекстная диаграмма устанавливает контекст модели.
Точка зрения определяет то, что может быть "видно" в пределах контекста с определенной "точки зрения" (или перспективы). В зависимости от цели могут быть приняты различные точки зрения, что подчеркивает разносторонность объекта, но в модели всегда имеется только одна точка зрения.
Цель определяет назначение модели и выявляет причину ее создания (функциональная спецификация, инструмент проектирования и т. д.).
Отпра
Моделирование начинается с создания диаграммы А-0. Затем рисуется одиночный блок, содержащий название функции, которая охватывает полные возможности (контекст) описываемой системы, с использованием входных, управляющих и выходных дуг для представления данных и объектов системы, реализующих интерфейс с окружающей ее средой. Эта одноблочная диаграмма ограничивает контекст для полной модели и формирует основание для дальнейшей декомпозиции. Цель и точка зрения записываются на А-0 контекстной диаграмме.
Некоторые авторы находят, что проще сначала сделать набросок диаграммы А0, а затем чертить одиночный блок и интерфейсные дуги уровня А-0. До начала декомпозиции может возникнуть необходимость сделать несколько переключений внимания между А-0 и А0.
Если диаграмма А-0 началась на слишком низком уровне детализации, А-0 блок необходимо сделать основанием для нового уровня АО диаграммы, продвинуться на один уровень к новой А-0-диаг-рамме, и повторно рассмотреть точку зрения и цель. Затем следует повторить этот процесс, пока А-0 не достигнет состояния, при котором охватываются все аспекты системы. Иногда более высокий уровень будет значительно шире, чем необходимо с выбранной точки зрения. Если такое случится, то нужно создать А-1 многоблочную контекстную диаграмму и привести диаграмму АО к первоначальному виду [7, c. 18].
Все системные функции лежат в пределах одиночного блока, показанного на диаграмме А-0. Диаграмма А0 декомпозирует функцию на диаграмме А-0 на три-шесть главных подфункций.
Реальная "вершина" модели - диаграмма А0. Ее структура раскрывает то, что диаграмма А-0 только наметила показать. Содержание и структура А0 также ограничивают каждый последующий уровень, потому что это законченное описание выбранного объекта. Нижние уровни только раскрывают (но не дополняют) функции А0. Диаграмма А0 вынуждает автора поддерживать выбранный уровень абстракции, одинаковую "глубину" моделирования и относить подробности к более низкому уровню [1].
Новая диаграмма формируется для каждого блока, который охватывает ту же самую тему, что и ее родительский блок, но более подробно. Сначала создается черновая диаграмма путем записи всех данных (объектов), связанных с анализируемой (декомпозируемой) функцией. Этот список должен охватывать всю тему родительского блока без потери какой-либо части при декомпозиции. Затем следует начертить блоки, которые являются кандидатами в качестве подфункций с соответствующими данными и объектами из списка, и изобразить дуги между блоками.
Чтобы получить четкую и ясную диаграмму, нужно изменять или перерисовывать диаграмму столько раз, сколько потребуется. Следует попробовать разбить блок на две (или более) части и синтезировать (объединить) две (или более) части в одиночный блок. В результате родительская диаграмма должна быть представлена тремя-шестью блоками.
При создании любой IDEF0-диаграммы необходимо учитывать следующие требования:
- цель диаграммы и точка зрения должны соответствовать заявленной цели и точке зрения полной модели;
- граничные дуги должны соответствовать дугам родительского блока;
- содержание блока должно точно соответствовать содержанию родительского блока.
Каждая диаграмма, как правило, будет сопровождаться страницей текста комментария, глоссария и, возможно, FEO. Текст, связанный с диаграммой А-0, должен завершать ориентацию модели, он пишется после создания диаграммы А-0 и дополняет контекст, описывая точку зрения и цель модели [7, c. 20]
Тексты для других диаграмм (включая А0) весьма разнообразны. Они сообщают сжатую, краткую историю, не дублируя того, что показано на диаграмме, просто описывают каждую функцию блока в словесной форме. Графическая диаграмма может иметь или не иметь связанную с ней текстовую диаграмму.
Имея законченную родительскую диаграмму, необходимо "укрепить" более высокие уровни, прежде чем переходить к дальнейшей детализации, т.е., имея А0, описать работу на уровне Al, A2, A3. Декомпозицию А1 в АН, АН 1 и т. д. следует сделать позже.
Можно дать две рекомендации, используемые в процессе выбора блока для детализации:
- начинать необходимо с "тяжелой части", являющейся наименее знакомой или ясной (понятной);
- выбирается блок, детализация которого даст больше информации относительно других блоков.
Более простые разделы могут быть декомпозированы позже с меньшим риском допустить ошибку.
Создание диаграмм - наиболее субъективный и творческий этап процесса моделирования. Можно предложить множество вариантов последовательности построения диаграмм, которые будут одинаково хорошо работать. Предлагаемые ниже шаги проверены опытом и разработаны для того, чтобы оказать помощь начинающему автору в построении IDEF0-диаграмм:
- Создайте список данных (объектов), относящийся к описываемому объекту в пределах контекста родительского блока.
- Дайте имена функциям, которые взаимодействуют (связаны) с перечисленными данными (объектами) и нарисуйте блоки вокруг этих имен.
- Начертите эскизно соответствующие дуги.
- Завершите диаграмму, которая представляет собой четкую структуру размещения блоков и дуг. Сгруппируйте дуги, если их структура слишком детализирована. Оставьте только существенные элементы.
- Создайте текстовую диаграмму, глоссарий и FEO-диаграммы (если необходимо), чтобы отразить важные аспекты.
- Определите, не нужно ли сделать изменения в родительской диаграмме [1].
Генерация функциональных блоков. Функциональные блоки генерируются с использованием главных подфункций родительской диаграммы. Поскольку имена подфункций уже написаны, блоки рисуют вокруг имен, чтобы формировать начало фактической диаграммы. На этой стадии число блоков несущественно. Они могут изменяться, соединяясь и разделяясь, чтобы соответствовать правилу "от трех до шести".
При соединении группируются два (или более) блока, чтобы формировать одиночный блок. Его цель состоит в том, чтобы объединить связанные функции в одну, более общую. Это устраняет преждевременную детализацию, которая размывает тему, представляемую на этом уровне.
Разбиение это процесс деления одиночного блока на две (или более) части (эта процедура является обратной по отношению к соединению). Цель разбиения состоит в том, чтобы обеспечить большее количество деталей для правильного представления анализируемой темы.
Далее анализируется получившееся множество функциональных блоков нельзя ли сделать имена более определенными. Специальные термины и сокращения следует использовать только в случае необходимости, чтобы способствовать связи с соответствующей аудиторией и только на нижних уровнях диаграмм, но не на самом высоком уровне (А-0 и АО). Все специальные термины следует детально описать в глоссарии.
Создание интерфейсных дуг. Соединение интерфейсных дуг с каждым индивидуальным блоком показывается эскизно. Нужно подсоединить концы дуг, чтобы показать, какие из них входные и управляющие, а какие выходные [6, c. 107].
Если дуга содержит и вход, и управление, то это показывается как управление. Часто тяжело определить, показывать дугу или нет. Самый простой способ решить этот вопрос заключается в следующем "когда есть сомнения, отбрасываем" (если это не управление). Если дуга действительно несущественна для главной "магистрали" диаграммы или имеются соответствующие сомнения, то правильнее будет не изображать ее. Неверно вычерченная сомнительная дуга будет вызывать постоянную угрозу ошибки.
Нужно группировать соответствующие дуги, если это возможно. Наиболее типичная ошибка при создании дуг состоит в том, что структура или имена дуги слишком детализированы. Уровень детализации дуг должен соответствовать уровню детализации блоков. На верхних уровнях названия блоков и дуг должны быть как можно более обобщенными.
В качестве последней проверки нужно сравнить все дуги со списком данных, чтобы убедиться, что присутствуют все необходимые элементы. Отсутствующие элементы либо не нужны для этого уровня детализации, либо их присутствие было пересмотрено при создании дуг.
Основное правило для размещения дуг "дуги управляют и ограничивают, а не устанавливают последовательность". Даже если для достижения некоторого желательного конечного результата какие-то действия должны выполняться последовательно от этапа к этапу, нужно пытаться выразить требуемые управления или ограничения так, чтобы они были истинны, независимо от последовательности шагов, приводящих к результату. Дело в том, что все блоки могут быть активны одновременно, поэтому последовательность не имеет никакого значения.
Не следует создавать хаос на диаграммах, используя большое количество информации и множество дуг. Не нужно тратить слишком много времени на один уровень. Не стоит стараться все выразить сразу. Нужно отнести подробности к подфункциям, для чего выполнить итерационные согласования между диаграммами высокого уровня и подфункциями для отображения подробностей [7, c. 22].
3. Принципы моделирования в IDEF0
В IDEF0 реализованы три базовых принципа моделирования процессов:
· принцип функциональной декомпозиции;
· принцип ограничения сложности;
· принцип контекста.
Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть ее структуру и состав (рисунок 1) [3].
Рисунок 1 – Принцип функциональной декомпозиции
Принцип ограничения сложности. При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу.
Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок - главная бизнес-функция моделируемой системы. Если речь идет о моделировании целого предприятия или даже крупного подразделения, главная бизнес-функция не может быть сформулирована как, например, "продавать продукцию". Главная бизнес-функция системы - это "миссия" системы, ее значение в окружающем мире. Нельзя правильно сформулировать главную функцию предприятия, не имея представления о его стратегии [3].
При определении главной бизнес-функции необходимо всегда иметь в виду цель моделирования и точку зрения на модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговой инспектор видят организацию совершенно по-разному.
Контекстная диаграмма играет еще одну роль в функциональной модели. Она "фиксирует" границы моделируемой бизнес-системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с блоком, представляющим главную бизнес-функцию [3].
Заключение
IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции.
Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.
IDEF0 - методология представляет собой четко формализованный подход к созданию функциональных моделей - структурных схем изучаемой системы. Схемы строятся по иерархическому принципу с необходимой степенью подробности и помогают разобраться в том, что происходит в изучаемой системе, какие функции в ней выполняются и в какие отношения вступают между собой и с окружающей средой ее функциональные блоки. Совокупность схем (IDEF0 - диаграмм) образует модель системы. Эта модель носит качественный, описательный, декларативный характер.
Методология функционального моделирования IDEF0 является достаточно простым инструментом, который позволяет разработчикам корпоративных информационных систем изучить сферу деятельности заказчика и решать задачи по повышению эффективности этой деятельности.
Применение функционального моделирования позволяет решать не только технические проблемы заказчика, связанные с информационными технологиями, но также проблемы, имеющие отношение к сфере деятельности заказчика.
Список литературы
1. Р50.1.028-2001. Методология функционального моделирования. М.: Госстандарт России, 2001.
2. Абдикеев Н.М. Реинжиниринг бизнес-процессов. Учебник - М.: ЭКСМО, 2005. – 578 с.
3. Дворников А. IDEF0 как инструмент моделирования процессов // Авант Партнер, 2005. - № 22 (79)
4. Методы и модели информационного менеджмента. Учебное пособие / Под ред. А.В. Кострова – М.: Финансы и статистика, 2007. – 336 с.
5. Окулесский В.А. Функциональное моделирование – методологическая основа реализации процессного подхода. М.: НИЦ CALS-технологий «Прикладная логистика», 2001. – 247 с.
6. Тельнов Ю.В. Реинжиниринг бизнес-процессов (Учебное пособие). / Московский международный институт эконометрики, информатики, финансов и права. - М., 2003. – 199с.
7. Функциональное моделирование на базе стандарта IDEF0. Учебный курс – Минск: 2002 – 35 с.