Сборник методических рекомендаций Тольятти, 2008 - umotnas.ru o_O
Главная
Поиск по ключевым словам:
Похожие работы
Название работы Кол-во страниц Размер
Методические указания и рекомендации 1 42.93kb.
Сборник методических материалов по курсу «Правовые основы журналистики» 1 290.06kb.
Сборник методических материалов 1 129.39kb.
Литература № п/п Наименование дисциплины 1 246.22kb.
Программа курса соответствует требованиям Государственного образовательного... 2 654.99kb.
Сборник методических материалов по курсу «международное право» для... 1 618.1kb.
Практикум по немецкому языку Сборник текстов, контрольно-тренировочных... 8 644.41kb.
Сборник методических материалов, Москва: Флинта: Наука: Эколого-просветительский... 1 86.43kb.
Сборник методических материалов для проведения еженедельных гайдовских... 3 712.65kb.
Роект постановления мэрии городского округа тольятти 1 53.03kb.
2. Основные понятия Социологический опрос в системе обязательного... 1 111.89kb.
Лабораторная работа № Разработка моделей idef0 Порядок выполнения... 1 63.77kb.
Викторина для любознательных: «Занимательная биология» 1 9.92kb.

Сборник методических рекомендаций Тольятти, 2008 - страница №4/4

2.2.2 Построение моделей IDEF0


В этом подразделе мы рассмотрим методику построения моделей IDEF0 более подробно.

2.2.2.1 Диаграммы


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


Рисунок 2.10 - IDEF0-диаграмма со служебной информацией на полях

Все элементы заголовка диаграммы перечислены в таблице 2.1.


Таблица 2.1 - Элементы заголовка диаграммы IDEF0

Поле

Назначение

USED AT

Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную)

Author, date, project

Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась

Notes 1…10

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

Status

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

Working

Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы

Draft

Диаграмма достигла некоторого приемлемого для читателей уровня и готова для предоставления на утверждение

Recommended

Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся

Publication

Диаграмма готова для окончательной печати и публикации

Reader

ФИО читателя

Date

Дата знакомства читателя с диаграммой

Context

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

Все элементы "подвала" диаграммы перечислены в таблице 2.2.


Таблица 2.2 - Элементы "подвала" диаграммы IDEF0




Поле

Назначение

Node

Номер диаграммы, совпадающий с номером родительского функционального блока

Title

Имя родительского функционального блока

Number (еще называют C-Number)

Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия диаграммы будет иметь новое значение в этом поле. Как правило, C-Number состоит из инициалов автора (которые предполагаются уникальными среди всех аналитиков проекта) и последовательного уникального идентификатора, например, SDO005. При публикации эти номера могут быть заменены стандартными номерами страниц. Если диаграмма замещает другую диаграмму, номер заменяемой диаграммы может быть заключен в скобки – SDJ005 (SDO004). Это обеспечивает хранение истории изменений всех диаграмм модели.

2.2.2.2 Построение моделей


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

  • Почему моделируется данный процесс?

  • Что выявит данная модель?

  • Как ознакомившиеся с этой моделью смогут ее применить?

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

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



  • Каковы задачи менеджера?

  • Каковы задачи клерка?

  • Кто контролирует работу?

  • Какая технология нужна для выполнения каждого шага? и т.п.

2.2.2.3 Точка зрения


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

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


2.2.2.4 Границы моделирования


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

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

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

Когда границы моделирования понятны, становятся ясными и причины, по которым некоторые объекты системы не вошли в модель.


2.2.2.5 Выбор наименования контекстного блока


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

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


2.2.2.6 Определение стрелок на контекстной диаграмме


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

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

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

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

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

Когда контекстная диаграмма представляется завершенной, попробуйте задать следующие вопросы:



  • Обобщает ли диаграмма моделируемый бизнес-процесс?

  • Согласуется ли диаграмма с границами моделирования, точкой зрения и целью моделирования?

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

2.2.2.7 Нумерация блоков и диаграмм


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

Префикс повторяется для каждого блока модели. Номера используются для отражения уровня декомпозиции, на котором находится блок. Блок АО декомпозируется в блоки А1, А2, A3 и т.д. А1 декомпозируется в А11, А12, А13 и т.д. А11 декомпозируется в A1l1, A112, А113 и т.д. Для каждого уровня декомпозиции в конец номера добавляется одна цифра.

Номер блока можно изменить. Для этого необходимо щелнуть правой кнопкой мыши по пустому полю, выбрать Model Propetions – Nambering и установить необходимые параметры.

2.2.2.8 Связь между диаграммой и ее родительским функциональным блоком


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

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

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


Рисунок 2.12 - ICOM-коды на граничных стрелках

2.2.2.9 Два подхода к началу моделирования ("в ширину" и "в глубину")


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

2.2.2.10 Когда остановиться?


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

При необходимости дальнейшей детализации отдельных процессов могут быть использованы диаграммы IDEF3.


2.2.2.11 Другие диаграммы IDEF0


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

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

Рисунок 2.13 - Фрагмент дерева модели

Рисунок 2.14 – Фрагмент дерева модели


Презентационные диаграммы. Презентационные диаграммы (For Exposition Only diagrams -FEO diagrams) часто включают в модели, чтобы проиллюстрировать другие точки зрения или детали, выходящие за рамки традиционного синтаксиса IDEF0 (рисунок 2.15). Диаграммы FEO допускают нарушение любых правил построения диаграмм IDEF0 в целях выделения важных с точки зрения аналитика частей модели. Естественно, если диаграмма FEO включена в модель исключительно для отображения другой точки зрения на систему, она скорее всего будет выглядеть как обыкновенная диаграмма IDEF0, удовлетворяя всем ограничениям IDEF0.

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

Кроме того, встречаются следующие виды презентационных диаграмм;


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

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

  • различные точки зрения, как правило, на глубину одного уровня декомпозиции.



Рисунок 2.15 - Диаграмма FEO для выделения функционального блока и его стрелок

2.2.2.12 Удаление диаграмм

Для того чтобы удалить диаграмму, щелкните на панели инструментов на кнопке «Diagram Dictionary Editor» , в появившемся окне выберите тип (Diagram Type) и название диаграммы, которую необходимо удалить, и нажмите Delete (рисунок 2.16).



Рисунок 2.16 – Удаление диаграмм

3 ПРАКТИЧЕСКИЕ ЗАНЯТИЯ

В качестве примера рассмотрим деятельность вымышленной компании Quill, которая существует 5 лет и занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Годовой оборот компании составляет примерно 20 млн. долл. Компания закупает компоненты для компьютеров от трех независимых поставщиков, а не производит компоненты самостоятельно. Она только собирает и тестирует компьютеры. Компания реализует продукцию через магазины и специализируется на покупателях, для которых главный критерий при покупке - стоимость компьютера. Предполагаемый объем рынка для компании Quill в последующие 2 года - 50 млн. долл.

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


  • продавцы принимают заказы клиентов;

  • операторы группируют заказы по типам компьютеров;

  • операторы собирают и тестируют компьютеры;

  • операторы упаковывают компьютеры согласно заказам;

  • кладовщик отгружает клиентам заказы.

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

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



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


3.1 Создание контекстной диаграммы


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

  1. Запустите BPWin. (Кнопка Пуск – Все программы –AllFusion Process Modeler или ярлык на рабочем столе ).

  2. Появляется диалоговое окно I would like to. Внесите имя модели {Деятельность компании Quill} и выберите Туре - IDEF0. Нажмите кнопку ОК.

  3. В появившемся окне на вкладке General можно добавить разработчика диаграммы (Auhtor) и его инициалы (Auhtor initials). Нажмите кнопку ОК.

  4. Автоматически создается контекстная диаграмма.

  5. Перед тем как приступить к работе, необходимо настроить язык модели – кириллический. Для этого, выберите Model – Defaul Fonts – выберите из списка любую вкладку и щелкните по ней – в ячейке с названием Script установите «Кириллический», далее в левом нижнем углу экрана установите галочки напротив необходимых опций: All activities in this diagram (только для данной диаграммы); All activities in this model или Change all occurrences (для всей модели).

  6. Обратите внимание на кнопку на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации - Model Explorer (появляется слева). Кнопка Activities /Diagrams переключает режим Model Explorer. В режиме Activities щелчок правой кнопкой по объекту в Model Explorer позволяет редактировать его свойства.

  7. Если Вам непонятно, как выполнить то или иное действие, Вы можете вызвать помощь - клавиша F1 или меню Help.

  8. Перейдите в меню Model / Model Properties. В закладке General диалогового окна Model Properties следует внести имя модели {Деятельность компании Quill}, имя проекта Project {Модель деятельности Quill}, имя автора и тип модели - Time Frame {AS-IS} – «как есть»).

  9. В закладке Definition внесите определение {Это учебная модель, описывающая деятельность компании Quill} и Scope {Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов}.

  10. В закладке Status установите WORKING и нажмите кнопку ОК.

  11. Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по работе. В контекстном меню выберите Name Editor. В закладке Name внесите имя {Деятельность компании Quill}.

  12. В закладке Definition внесите определение {Текущие бизнес-процессы компании Quill}.

  13. В закладке Status установите WORKING и щелкните по кнопке ОК.

  14. Создайте стрелки на контекстной диаграмме (таблица 3.1). Для этого выберите кнопку на панели инструментов.

Таблица 3.1 – Данные для построения стрелок



Наименование стрелки

Описание

Тип

Бухгалтерская система

Оформление счетов, оплата счетов, работа с заказами

Mechanism (механизм  )

Звонки клиентов

Запросы информации, заказы, техническая поддержка и т.д.

Input

(вход )


Правила и процедуры

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

Control (контроль  )

Проданные продукты

Настольные и портативные компьютеры

Output

(выход )





3.2 Создание диаграммы декомпозиции


1. Для того чтобы декомпозировать процесс (на процессы нижнего уровня), выделите блок, выберите кнопку перехода на нижний уровень в палитре инструментов , в диалоговом окне Activity Box Count выберите вид диаграммы IDEF0, установите необходимое число работ, для данного примера – 3, на диаграмме нижнего уровня и нажмите кнопку ОК (рисунок 3.1)


Рисунок 3.1 – Создание диаграммы декомпозиции
Автоматически будет создана диаграмма декомпозиции. Правой кнопкой мыши щелкните по работе, выберите Name Editor и внесите имя работы. Повторите операцию для всех трех работ. Затем внесите определение и статус для каждой работы согласно таблица 3.2.
Таблица 3.2 - Описание работ дли диаграммы декомпозиции

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

Описание

Статус

Продажи, маркетинг

Телемаркетинг, презентации, выставки

WORKING

Сборка, тестирование компьютеров

Сборка и тестирование настольных и портативных компьютеров

WORKING

Отгрузка, получение

Отгрузка заказов клиентам и получение компонентов от поставщиков

WORKING

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

Рисунок 3.2 – Диаграмма декомпозиции


3. Правой кнопкой мыши щелкните по ветви стрелки управления работы "Сборка и тестирование компьютеров" и переименуйте ее в "Правила сборки и тестирования" (рисунок 3.3).

Внесите определение (Definision) для новой ветви: "Инструкции по сборке, процедуры тестирования, критерии производительности и т.д."




Рисунок 3.3 – Диаграмма декомпозиции
Правой кнопкой мыши щелкните по ветви стрелки механизма работы "Продажи и маркетинг" и переименуйте ее в "Систему оформления заказов".

4. Создайте новые внутренние стрелки так, как показано на рисунке 3.4.



Рисунок 3.4 – Создание внутренних стрелок

5. Создайте стрелку обратной связи (по управлению) "Результаты сборки и тестирования" (рисунок 3.5), идущую от работы "Сборка и тестирование компьютеров" к работе "Продажи и маркетинг". Для большей наглядности, измените стиль стрелки, для этого щелкните правой кнопкой мыши по стрелке, из контекстного меню выберите Style, в Thickness измените толщину линии. Если необходимо, установите опцию Extra Arrowhead и Squiggle (из контекстного меню).



Рисунок 3.5 – Создание стрелки обратной связи
6. Создайте новую граничную стрелку выхода "Маркетинговые материалы" из работы "Продажи и маркетинг". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике . Если вы хотите, чтобы данная стрелка отражалась на всех диаграммах (в том числе и 0-го уровня), щелкните правой кнопкой мыши по концу стрелки и из контекстного меню выберите Arrow Tunnel, в появившемся окне (рисунок 3.6) отметьте Resolve it to border arrow и нажмите кнопку ОК.

Рисунок 3.6 – Туннелирование стрелки



Задание. Декомпозируется работа "Сборка и тестирование компьютеров". В результате проведения экспертизы получена следующая информация:

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

  • диспетчер координирует работу сборщиков, сортирует заказы, группирует их и дает указание на отгрузку компьютеров, когда они готовы;

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

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

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

На основе этой информации внесите новые работы и стрелки (таблицы 3.3 и 3.4).
Таблица 3.3 – Декомпозиция процесса «Сборка и тестирование компьютеров»

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

Описание

Статус

Отслеживание расписания и управление сборкой и тестированием

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

WORKING

Сборка настольных компьютеров

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

WORKING

Сборка ноутбуков

Сборка ноутбуков в соответсвии с инструкциями и указаниями диспетчера

WORKING

Тестирование компьютеров

Тестирование компьютера и компонент. Замена неработающих компонент.

WORKING

Таблица 3.4 – Описание стрелок для декомпозиции процесса «Сборка и тестирование компьютеров»



Стрелка

Источник

Тип

Назначение

Тип назначения

1

2

3

4

5

Диспетчер

Персонал производственного отдела

Mechanism 

Отслеживание расписания и управление сборкой и тестированием

Mechanism 

Заказы клиентов

{Border}

Control 

Отслеживание расписания и управление сборкой и тестированием

Control 

Заказы на настольные компьютеры

Отслеживание расписания и управление сборкой и тестированием

Output 

Сборка настольных компьютеров

Control 

Заказы на ноутбуки

Отслеживание расписания и управление сборкой и тестированием

Output 

Сборка ноутбуков

Control 

Компоненты

{Tunnel}

Input 

Сборка настольных компьютеров

Input 

Сборка ноутбуков

Input 

Тестирование компьютеров

Input 

Настольные компьютеры

Сборка настольных компьютеров

Output 

Тестирование компьютеров

Input 

Ноутбуки

Сборка ноутбуков

Output 

Тестирование компьютеров

Input 

Продолжение таблицы 3.4



1

2

3

4

5

Персонал производственного отдела

{Tunnel}

Mechanism 

Сборка настольных компьютеров

Mechanism 

Сборка ноутбуков

Mechanism 

Правила сборки и тестирования

Правила и процедуры

Control 

Сборка настольных компьютеров

Control 

Сборка ноутбуков

Control 

Тестирование компьютеров

Control 

Результаты сборки и тестирования

Сборка настольных компьютеров

Output 

{Border}

Output 

Сборка ноутбуков

Output 

Тестирование компьютеров

Output 

Результаты тестирования

Тестирование компьютеров

Output 

Отслеживание расписания и управление сборкой и тестированием

Input 

Собранные компьютеры

Тестирование компьютеров

Output 

{Border}

Output 

Тестировщик

Персонал производственного отдела

Mechanism 

Тестирование компьютеров

Mechanism 

Указание передать компьютеры на отгрузку

Отслеживание расписания и управление сборкой и тестированием

Output 

Тестирование компьютеров

Control 


Рисунок 3.7 – Декомпозиция процесса «Сборка и тестирование компьютеров»


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

3.3 Создание диаграммы узлов


1. Для создания диаграммы узлов выберите меню Diagram/Add Node Tree. Установите опции диалогового окна Node Tree Wizard, как показано на рисунок 3.8.

а) б)


Рисунок 3.8 – Построение диаграммы узлов: а) – шаг 1, б) – шаг 2

2. Щелкните по кнопке ОК. Создается диаграмма дерева узлов (рисунок 3.9).



Рисунок 3.9 – Диаграмма узлов «Деятельность компании Quill» (вид 1)

3. Для того чтобы создать диаграмму дерева узлов, подобную рисунку 3.10, выберите меню Diagram/Add Node Tree, в диалоговом окне Node Tree Wizard (рисунок 3.8б) отключите опцию Bullet Last Level и щелкните по кнопке ОК.

Рисунок 3.10 - Диаграмма узлов «Деятельность компании Quill» (вид 2)


3.4 Создание FEO-диаграммы


При обсуждении бизнес-процессов возникла необходимость детально рассмотреть взаимодействие работы "Сборка и тестирование компьютеров" с другими работами. Чтобы не модифицировать диаграмму декомпозиции, создайте FEO-диаграмму, на которой будут только стрелки работы "Сборка и тестирование компьютеров" (рисунок 3.11):

  1. Выберите пункт меню Diagram / Add FEO Diagram.

  2. В диалоговом окне Add New FEO Diagram выберите тип и внесите имя диаграммы FEO. Щелкните по кнопке ОК.

  3. Для определения диаграммы перейдите в Diagram / Diagram Properties и в закладке Diagram Text внесите определение.

  4. Удалите лишние стрелки на диаграмме FEO.

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



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

Постройте FEO на основе диаграммы А0 («Деятельность компании Quill») и добавьте стрелку "Неисправные компоненты". Стрелка должна идти с выхода "Сборка и тестирование компьютеров" на вход "Отгрузка и получение" (рисунок 3.12).



Рисунок 3.12 – FEO-диаграмма «Деятельность компании Quill»

3.5 Декомпозиция процесса "Продажа и маркетинг"


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

На основе этой информации декомпозируйте работу "Продажи и маркетинг" (IDEF0).

Создайте следующие работы:


  • предоставление информации о ценах;

  • оформление заказов;

  • исследование рынка.

Результат декомпозиции представлен на рисунок 3.13.

Рисунок 3.13 – Декомпозиция процесса «Продажи и маркетинг»


ГЛОССАРИЙ


Границы моделирования (Scope) — ширина охвата и глубина детализации при описании моделируемого набора объектов.

Действие (Activity) — описание набора мероприятий, имеющего целью обработку или передачу данных или ресурсов (например, "Обработать заказ" или "Провести технический контроль"). Модели IDEF0 выделяют неэффективные действия (у которых отсутствует управление или выход) и, таким образом, способствуют работе по проведению реинжиниринга бизнес-процессов. Действие в модели 1DEF3, называемое также единицей работы, описывает обработку, мероприятие, принятие решения или другую процедуру, выполняемую системой или организацией. Действия в диаграммах DFD отображают обработку или передачу данных.

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

Стрелка (Arrow) — стрелка на диаграмме IDEF0 представляет вход, управление, выход или механизм выполнения действия. На диаграммах IDEF3 стрелки обозначают порядок выполнения действий (стрелки, нарисованные сплошной линией), отношения (стрелки, нарисованные прерывистой линией) или поток (двухконечные стрелки, нарисованные сплошной линией). В DFD стрелка обозначает поток данных между действиями, хранилищами данных и внешними ссылками.

Управление (Control arrow) — ограничение для блока диаграммы IDEF0, определяющее как, когда и при каких условиях выполняется действие, обозначенное этим блоком. Это правила, стандарты, законы, должностные инструкции и т.п. Стрелки, обозначающие управление, входят в блоки диаграммы IDEF0 сверху.

<< предыдущая страница