Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

МОДЕЛИРОВАНИЕ БИЗНЕСА

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

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

 информация об объекте проектирования - ИС предприятия (черный ящик);

 знания о предметной области, в которой работает предприятие (они могут быть получены путем предварительного изучения объекта и /или на основании опыта);

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

 знания о методах и средствах моделирования и анализа систем.

 программные средства (инструменты) для моделирования и анализа;

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

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

В процессе разработки ИСУП выполняются три уровня анализа, каждый из которых соответствует трем основным стадиям создания ИСУП:

 определение требований;

 формирование спецификаций;

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

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

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

 локальные, поддерживающие один-два типа моделей и методов (Design/IDEF, ProCap, S-Designor, CASE-Аналитик);

 малые интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin);

 средние интегрированные средства моделирования, поддерживающие от 4 до 10-15 типов моделей и методов (Rational Rose, Paradigm Plus, Designer/2000);

 крупные интегрированные средства моделирования, поддерживающие более 15 типов моделей и методов (ARIS Toolset).

При разработке ИСУП локальные средства моделирования могут быть использованы только на концептуальном уровне для предварительного анализа или как средство демонстрации заказчику общих предложений по будущему проекту. Задача комплексного анализа системы локальными средствами не может быть решена. Малые интегрированные средства моделирования, как правило, исторически выросли из локальных. Так же, как и последние, они изначально не были ориентированы на комплексный анализ систем. Возможности по интеграции различных моделей в рамках общей модели появились в процессе совершенствования и развития этих программных средств. Характерными особенностями этой категории является наличие в инструментальном средстве независимых компонентов и интеграция моделей путем экспорта и импорта данных (рис. 31).

Рис. 31. Применение локальных, малых и средних интегрируемых средств моделирования на различных этапах создания ИСУП

Типичный представитель малых интегрированных средств моделирования - комплект программных продуктов Platinum Technology (CA/ Platinum/Logic Works), основанный на популярных пакетах BPwin и Erwin. BPwin. Поддерживает три методологии моделирования: IDEF0 (диаграммы функций), IDEF3 (только диаграммы процессов), DFD (диаграммы потоков данных) и обеспечивает интеграцию моделей трех типов без экспорта или импорта данных. Интеграция выполняется как путем слияния нескольких моделей, так и посредством переключения на различные методологии в процессе разработки отдельных диаграмм модели. Предусмотрено расширение возможностей анализа систем как в самом пакете BPwin (функционально-стоимостный анализ), так и с помощью экспорта данных в другие пакеты. ERwin. Поддерживает несколько разновидностей методологии информационного моделирования, основанной на ER-диаграммах (сущность - связь). Интеграция моделей BPwin с моделями ERwin выполняется путем обмена данными через функции экспорта/импорта. Малые интегрированные системы, так же как и локальные, практически не позволяют выполнить комплексный анализ систем, который в большей или меньшей степени необходим для создания малых, средних и крупных ИСУП. С их помощью можно разрабатывать локальные ИСУП или небольшие подсистемы, предназначенные для автоматизации отдельных бизнес-цепочек, т.е. когда нет необходимости в комплексном анализе предприятия. Типичная сфера использования малых интегрированных средств - решение задач так называемой кусочной автоматизации предприятия. Средние интегрированные средства моделирования. Эта категория представлена программными продуктами, при создании которых изначально были заложены требования комплексного использования различных методов и типов моделей. Продукты средней категории имеют единую среду для разработки всех поддерживаемых типов моделей, что позволяет применять одни и те же объекты в разных моделях.

К средним интегрированным средствам можно отнести такие известные продукты, как Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), Designer/2000 (Oracle).

Rational Rose и Paradigm Plus основаны на объектно-ориентированном подходе к моделированию и ориентированы на метод UML (Unified Modeling Language).

Помимо UML поддерживаются и другие методы. Отличия между Rational Rose и Paradigm Plus состоят в основном в доступных пользователю типах диаграмм и методов.

Последние версии Rational Rose позволяют строить восемь типов диаграмм UML: диаграммы прецедентов (Use Cases Diagrams), диаграммы классов (Class Diagrams), диаграммы последовательности (Sequence Diagrams), диаграммы сотрудничества (Collaboration Diagrams), диаграммы состояний (State Diagrams), диаграммы действий (Activity Diagrams), компонентные диаграммы (Component Diagrams), диаграммы развертывания (Deployment Diagram). UML диаграммы в Rational Rose. Rational Rose - мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного продукта будет возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

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

 Use case diagram (диаграммы прецедентов);

 Deployment diagram (диаграммы топологии);

 Statechart diagram (диаграммы состояний);

 Activity diagram (диаграммы активности);

 Interaction diagram (диаграммы взаимодействия);

 Sequence diagram (диаграммы последовательностей действий);

 Collaboration diagram (диаграммы сотрудничества);

 Class diagram (диаграммы классов);

 Component diagram (диаграммы компонент). Диаграммы прецедентов (Use case diagram). Этот вид диаграмм позволяет создать список операций, которые выполняет система.

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case - это описание сценария поведения, которому следуют действующие лица (Actors).

Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определении требований к будущей программной системе. Отражает объекты, как системы, так и предметной области и задачи, ими выполняемые. Диаграммы топологии (Deployment diagram). Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм.

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

Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться. Диаграммы состояний (State Maсhine diagram). Каждый объект системы, обладающий определенным поведением, может находиться в определенных состояниях, переходить из состояния в состояние, совершая определенные действия в процессе реализации сценария поведения объекта. Поведение большинства объектов реальных систем можно представить с точки зрения теории конечных автоматов, то есть поведение объекта отражается в его состояниях, и данный тип диаграмм позволяет отразить это графически. Для этого используется два вида диаграмм: Statechart diagram (диаграмма состояний) и Activity diagram (диаграмма активности).

Диаграмма состояний (Statechart diagram) предназначена для отображения состояний объектов системы, имеющих сложную модель поведения. Это одна из двух диаграмм State Machine, доступ к которой осуществляется из одного пункта меню. Диаграммы активности (Activity diagram). Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип диаграмм позволяет показать не только последовательность процессов, но и ветвление и даже синхронизацию процессов.

Этот тип диаграмм позволяет проектировать алгоритмы поведения объектов любой сложности, в том числе может использоваться для составления блок-схем. Диаграммы взаимодействия (Interaction diagram). Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе. Диаграммы последовательностей действий (Sequence diagram). Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов.

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

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм. Диаграммы классов (Class diagram). Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов.

Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диаграмм противоположен по содержанию диаграмме Collaboration, на котором отображаются объекты системы. Rational Rose позволяет создавать классы при помощи данного типа диаграмм в различных нотациях, похожего на облако. Таким образом, Г. Буч пытается показать, что класс - это лишь шаблон, по которому в дальнейшем будет создан конкретный объект.

Нотация OMT более строга.

И, конечно же, Rational Rose позволяет создавать диаграмму классов в унифицированной нотации.Диаграммы компонентов (Component diagram). Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

Основным типом диаграмм, своеобразным ядром моделирования в UML являются диаграммы классов. Диаграммы классов - ключевой тип диаграмм Rational Rose. Кроме UML предусмотрено использование и других методов (Booch, OMT). Пакет применим на всех стадиях и циклах создания ИСУП.

Пакет Paradigm Plus ориентирован на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки. Он поддерживает диаграммы различных методов (UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/ Mellor, Coad/Yourdon). Пакет может быть использован на всех циклах создания ИСУП (рис. 32).

Рис. 32. Циклическое использование моделей Paradigm Plus при создании ИСУП

В состав Designer/2000 входят Process Modeller и System Modeller. Process Modeller предназначен для разработки моделей процессов, а System Modeller - для моделей иерархии функций (Function Hierarchy Diagrammer), моделей потоков данных (Dataflow Diagrammer) и моделей типа сущность - отношение (Entity Relationship Diagrammer) (рис. 33).

Process Modeller позволяет повысить наглядность представления процессов за счет анимации и использования мультимедийных файлов, он пригоден для всех стадий разработки ИСУП.

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

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

Рис. 33. Модели Designer/2000Крупные интегрированные средства моделирования. К этой категории относится инструментальное средство, специально предназначенное для проектирования крупных ИСУП, таких, например, как системы управления предприятием класса ERP.

Это семейство ARIS (ARIS Toolset, ARIS Easy Design) компании IDS Sheer AG.

В ARIS воплощен практический опыт множества аналитиков, работающих в области проектирования ИСУП, а также учтены недостатки существующих инструментальных средств. Отличительная особенность ARIS - особое внимание к первому уровню анализа (анализ требований).

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

Рис. 34. Оценка применимости инструментальных средств для анализа ИСУП

Из рассмотренных выше инструментальных средств к категории ERP можно отнести только ARIS. ARIS обеспечивает четыре различных «взгляда» на моделирование и анализ. Для каждого «взгляда» поддерживаются три уровня анализа (требования, спецификации, внедрение).

Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет (рис. 35) множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т.д. «Взгляды» ARIS: Процессы, Функции (с Целями), Данные, Организация - являются «комнатами», из которых состоит так называемый домик ARIS. Главная «комната» домика ARIS (основной «взгляд») -
Процессы, для моделирования которых предназначено 57 типов моделей из 85. Процессный «взгляд» является характерной особенностью и для ERP-систем, предназначенных для автоматизации процессов, пронизывающих организационную структуру предприятия.

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

Рис. 35. Количество типов моделей ARIS для разных «взглядов» и уровней моделирования

Резюме. Рассмотренные выше инструментальные средства широко используются для моделирования и анализа систем, в том числе и при создании ИСУП. Среди локальных и малых инструментальных средств весьма популярными остаются программы, основанные на реализации структурного подхода к анализу и проектированию систем и методологий IDEF. Среди малых инструментальных средств доминируют пакеты BPwin и ERwin компании Platinum. Локальные и малые инструментальные средства могут быть использованы при разработке соответственно локальных и малых ИСУП. Для средних и крупных ИСУП использование этих средств имеет смысл в качестве дополнения к более универсальному инструментальному средству средней категории.

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

По данным исследовательской компании International Data Corporation, среди инструментальных средств, которые можно отнести к этой категории, лидирующее положение занимает пакет Rational Rose.

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

Система ARIS как крупное интегрированное средство моделирования имеет уникальные возможности для моделирования и анализа систем. Моделирование в ARIS может выполняться как «сверху вниз», так и «снизу вверх». Для конкретных разработок количество используемых типов моделей и методик может быть ограничено с помощью специальных фильтров. Система позволяет контролировать процесс моделирования и выполнять расширенный анализ системы: определение целей и критических факторов, оценку рисков и конкурентов и др. Система ARIS предоставляет аналитикам возможность интегрированного управления ресурсами, необходимыми для использования на всех уровнях анализа при разработке ИСУП любой сложности. Основные методологии обследования организаций.
Стандарт IDEF0

Основные цели моделирования бизнес процессов

Система взаимодействия структуры организации имеет три основных аспекта:

 административный;

 финансовый;

 материальный (товарный).

С учетом новейших технологий можно добавить еще два:

 информационный;

 коммуникационный.

Наиболее существенными для бизнеса являются вопросы организации трех процессов финансового взаимодействия:

 финансового планирования (бюджетирования);

 финансирования (исполнения бюджетов);

 финансовой отчетности.

Взаимодействие между элементами системы не обходится без документооборота. Для его отображения приходится применять средства, одним из которых являются «диаграммы потоков данных» (DFD).

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

В большинстве случаев имеет место значительно более сложная ситуация: интуитивно все понятно, но при попытках формализовать взаимоотношения возникают трудности. В данной ситуации может помочь семейство методологий IDEF. Данное семейство состоит из методологии функционального моделирования IDEF0 и методологии информационного моделирования IDEF1X. IDEF-методологии создавались в рамках программы компьютеризации промышленности - ICAM (Integrated Computer Aided Manufacturing), в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальное требование при разработке рассматриваемого семейства методологий - это возможность эффективного обмена информацией между ВСЕМИ специалистами - участниками программы ICAM (Icam DEFinition - IDEF). С широким применением IDEF (и предшествующей методологии - SADT) связано возникновение основных идей BPR (бизнес-процесс реинжиниринг).

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

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

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

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

 IDEF1X-методология (IDEF1 Extended) построения реляционных структур. IDEF1X относится к типу методологий «Сущность-Связь» (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

 IDEF2-методология динамического моделирования развития систем;

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

 IDEF4-методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым, позволяя анализировать и оптимизировать сложные объектно-ориентированные системы;

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

Рассмотрим часто используемую методологию функционального моделирования IDEF0. История возникновения стандарта IDEF0. Методологию IDEF0 можно считать следующим этапом развития известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST). Основные элементы и понятия IDEF0. В основе методологии графического языка IDEF0 лежат четыре основных понятия. Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (рис. 36) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы.

Рис. 36. Функциональный блок

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

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

 верхняя сторона имеет значение «Управление» (Control);

 левая сторона имеет значение «Вход» (Input);

 правая сторона имеет значение «Выход» (Output);

 нижняя сторона имеет значение «Механизм» (Mechanism).

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

Рис. 37. Функциональный блок

Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения (рис. 38).

Рис. 38. Функциональный блок

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram). Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

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

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

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

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

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

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

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

Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования.

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

Рис. 39. Декомпозиция функциональных блоков

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

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

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

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

 создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели;

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

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

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

Использование IDEF0 для описания и классификации процессов в рамках системы качества МС ИСО семейства 9000 версии 2000

Рассмотрим применение методологии функционального моделирования IDEF0 для описания и классификации процессов в рамках системы качества, создаваемой в соответствии с требованиями новой версии стандартов ИСО 9000:2000.

В 2000 году Международная Организация по Стандартизации (ISO) приняла новую версию стандартов серии 9000, содержащих перечень требований к системе качества (СК) организации.

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

Основную идею процессного подхода в новой версии стандартов можно свести к следующим положениям:

1. Деятельность организации необходимо представить в виде сети взаимодействующих между собой процессов;

2. Менеджмент деятельностью организации должен основываться на менеджменте сетью процессов.

Рассмотрим подход к описанию и классификации процессов в организации, основанный на применении методологии функционального моделирования IDEF0. Представление процессов. В МС ИСО 9000:2000 используется следующее определение процесса: Набор взаимосвязанных и взаимодействующих операций (действий), которые преобразуют входы в выходы.

Примечание 1. Входы процессов, как правило, являются выходами других процессов.

Примечание 2. Процессы в организации планируются и исполняются при управляемых условиях для добавления ценности.

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

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

 Какие процессы в деятельности организации относятся к системе качества?

 Какова структура этих процессов, включая выходы и потребителей процессов, входы и поставщиков и т.д.?

 Как процессы взаимодействуют друг с другом?

 Как в рамках процессов выполняются требования, определенные в МС ИСО семейства 9000 версии 2000 года?

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

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

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

2. Функциональная модель должна содержать процессы, определенные как обязательные в рамках требований МС ИСО семейства 9000 версии 2000 года. Перечень этих процессов приведен в МС ИСО 9001:2000.

3. Функциональная модель должна содержать элементы (объекты), регламентируемые в МС ИСО семейства 9000 версии 2000 года.

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

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

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

Таким образом, функциональная модель делового процесса будет охватывать процессы жизненного цикла, а также связанные с ними вспомогательные процессы и процессы менеджмента, входящие в состав деятельности организации. Это полностью согласуется с требованиями МС ИСО семейства 9000 версии 2000 года.

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

Рис. 40. Деловой процесс в ателье

Обязательные процессы и элементы. В МС ИСО 9001:2000 к обязательным процессам относятся:  реализация ответственности высшего руководства в рамках системы качества;

 менеджмент ресурсами (вспомогательными производственными процессами);

 менеджмент основными производственными процессами (процессами жизненного цикла продукции);

 процессы измерения, контроля и улучшения СК.

К обязательным элементам также относятся:

 документы, содержащие политику, цели организации в сфере менеджмента качества;

 документы, содержащие ответственность сотрудников организации (должностные инструкции);

 записи качества и т.д.;

 функциональная модель должна содержать все обязательные процессы и элементы в соответствии с требованиями МС ИСО семейства 9000 версии 2000 года.

Деловой процесс в швейном ателье будет иметь следующую структуру (рис. 41)

Рис. 41. Детализация делового процесса

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