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

Методология структурно-функционального моделирования

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

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

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

Модель — это совокупность символов (математических, графических и т. п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.

Нотации — система условных обозначений, принятая в конкретной модели.

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

С целями структурного анализа могут быть построены модели для отображения:

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

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

• 1) выделение множества объектов, оказывающих существенное влияние на деятельность структурного элемента;
• 2) спецификацию входных и выходных потоков (информации, материалов, продуктов, услуг, финансов и т. д.);
• 3) выявление основных процессов, определяющих деятельность структурного элемента и обеспечивающих реализацию его целевых функций;
• 4) спецификацию потоков между основными процессами деятельности, уточнение связей между процессами и внешними объектами;
• 5) оценку объемов, интенсивности и других необходимых характеристик потоков;
• 6) разработку функциональной модели деятельности структурного элемента;
• 7) объединение моделей структурных элементов в единую модель деятельности организации.

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

Наиболее популярный стандарт IDEF0 можно считать следующим этапом развития хорошо известного графического языка структурного функционального моделирования систем SADT. Исторически IDEF0 как стандарт был разработан в 1981 г. в рамках обширной программы автоматизации промышленных предприятий США, которая носила обозначение /САМ (Integrated Computer Aided Manufacturing). Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF = ICAM • DEFinition). В процессе практической реализации участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик — специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.

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

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

Первым из них является понятие функционального блока (.Activity Box), который представляет собой конкретную функцию в рамках рассматриваемой системы. Графическое изображение функционального блока имеет вид прямоугольника (рис. 4.1) и обладает своим уникальным идентификационным номером. В соответствии с требованиями стандарта название каждого функционального блока должно быть сформулировано, по возможности, в глагольном наклонении (например, «производить продукцию», а не «производство продукции»).

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

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

• • верхняя сторона имеет значение «Управление» (Control');
• • левая сторона — «Вход» (Input);
• • правая сторона — «Выход» (Output);
• • нижняя сторона — «Механизм» (Mechanism).

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

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

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

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

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

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

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

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

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

Рис. 4.2. Представление функции «Обеспечить защиту информации».

Рис. 4.3. Представление функции технолога

Необходимость использования управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других стандартов (например, DFD (Data Flow Diagram) или IDEF3)).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition).

Операция декомпозиции применяется при разбиении функции на составляющие се подфункции. Количество уровней детализации процесса определяется непосредственно разработчиком модели.

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

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

В пояснении к контекстной диаграмме должна быть указана цель (Pwpose) построения диаграммы в виде краткого описания и определена точка зрения (Viewpoint).

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

В процессе построении модели точка зрения указывает основное направление развития модели и определяет количество уровней необходимой детализации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как правило, процесс разработки модели является итеративным и содержит следующие этапы:

• 1) создание черновика модели (Model Draft). На этом этапе в создании модели участвует группа специалистов, называемых авторами (Authors) и относящихся к различным сферам деятельности предприятия. Авторы опрашивают компетентных лиц о структуре различных процессов, после чего на основе имеющихся положений, документов и результатов опросов создается черновик модели;
• 2) распространение черновика для рассмотрения, согласований и коммен тариев. На этом этапе происходит обсуждение черновика модели с широким спектром компетентных лиц (читателей) на предприятии. В процессе реализации этого этапа каждая из диаграмм черновой модели письменно критикуется и комментируется, а затем передается автору. Авторы, со своей стороны, также письменно соглашаются с критикой или отвергает ее с изложением логики принятия решения и вновь возвращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению;
• 3) официальное утверждение модели. Согласованная модель утверждается руководителем рабочей группы при условии отсутствия разногласий по поводу ее адекватности у авторов модели и читателей. Окончательная модель представляет собой согласованное представление о предприятии (системе) с заданной точки зрения и для заданной цели.

Построенная модель системы может служить основой для ее дальнейшего совершенствования.

Моделирование с использованием метода IDEF0 включает:

• 1) концептуальный этап (определение объекта и цели моделирования, обоснование точки зрения, подбор субъектов и установление сроков моделирования);
• 2) этап разработки модели (построение IDEFO-диаграмм, проведение циклов «автор — читатель»);
• 3) проведение экспериментов с моделью (изучение модели AS IS, получение ответов на вопросы типа «что будет, если…»);
• 4) интерпретация результатов (построение модели ТО BE, документирование результатов).