Информационные технологии для менеджеров - Грабауров В. А.. Информационные
Скачать 18.31 Mb.
|
5.4. Понятие о стандарте моделирования бизнес-процессов IDEFПрограмма Integrated Computer-Aided Manufacturing (ICAM) выявила потребность в совершенных способах обмена информацией и методах анализа производственных и деловых систем для специалистов разных областей. В рамках программы ICAM для удовлетворения этих потребностей была разработана методология IDEF (ICAM Definition). Созданная методология, основанная на графическом представлении производственных систем, состоит из трех методологий.
Для решения наших задач - моделирования бизнес-процессов более всего подходит IDEF0-методология, поэтому рассмотрим именно ее. Методология IDEF0 (IntegratedDefinitionFunctionModeling) была впервые разработана для аэрокосмической промышленности США, а сейчас принята в качестве стандарта во многих странах. В основе методологии IDEF0лежит понятие блока, который отображает некоторую бизнес-функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение "входа", правая - "выхода", верхняя -"управления", нижняя - "механизма" (рис. 5.6). Блок выражает следующий факт: "функция" преобразует "вход" в "выход " под воздействием "управления ", используя "механизм ". Взаимодействие между функциями в IDEF0представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно "входным", "выходным", "управляющим". Согласно IDEF0модель бизнес-процесса описывается с помощью диаграмм, текста и глоссария, которые определяют взаимосвязи процесса с исполнителями (персоналом, автоматизированной информационной системой, автоматическим устройством) и объектами, выступающими в качестве входов (исходные материальные, информационные, финансовые или другие ресурсы), управлений (инструктивные материалы, нормативные документы, ограничения на выполнение) и выходов (результаты выполнения бизнес-процесса). Диаграммы состоят из блоков и дуг. Блоки представляют действия (функции), а дуги - объекты, обрабатываемые бизнес-системой. Функции показывают, что должно выполняться, не идентифицируя при этом какие-либо другие аспекты модели. Имена функций записываются внутри блоков. Они должны содержать активный глагольный оборот. Каждый блок на диаграмме имеет номер, записанный в нижнем правом углу. Рис. 5.6. Отображение бизнес-функции Дуги, соединенные с блоками, представляют материальные объекты или информацию, в которой нуждается или которую производит функция. Каждая дуга может иметь метку, которая должна быть выражена в виде оборота существительного. Сторона блока, в которую дуга входит или из которой выходит, показывает ее назначение: вход, управление, выход чин механизм. Входящие с левой и верхней стороны блока дуги представляют данные, необходимые для выполнения функции. Выходящие дуги (с правой стороны блока) обозначают данные, полученные в результате выполнения функции. Функция преобразует данные слева направо (от входа к выходу). К нижней части блока может присоединяться дуга "механизма", обозначающая либо человека, либо некоторое средство, выполняющее функцию. Вход и выход показывают, чтоделает функция, управление показывает, почему это делается, а механизм показывает, как именно это делается. На рис. 5.7 представлен фрагмент функциональной модели документооборота. При выполнении операции "сортировать документы" используется бизнес-правило: "Регистрации не подлежат: документы, присланные в копии для сведения, телеграммы и письма о разрешении командировок и отпусков...". Это правило зафиксировано в инструкции по документообороту. Функциональная модель позволяет не только идентифицировать существование этого правила, но также определить, при выполнении какой операции и на каком рабочем месте оно должно применяться. Рис. 5.7. Фрагмент функциональной модели документооборота В рамках функциональной модели бизнес-правило выглядит следующим образом: "Если в приемную поступил документ, предназначенный руководству, он подлежит сортировке, в результате которой на основании инструкции определяется, подлежит ли документ регистрации или нет". Принципы моделирования в IDEF0 В IDEF0 реализованы три базовых принципа моделирования процессов:
Принцип функциональной декомпозиции представляет собой способ моделирования типовой ситуации, когда любое действие, операция, функция могут быть разбиты (декомпозированы) на более простые действия, операции, функции. Другими словами, сложная бизнес-функция может быть представлена в виде совокупности элементарных функций. Представляя функции графически, в виде блоков, можно как бы заглянуть внутрь блока и детально рассмотреть его структуру и состав. Принцип ограничения сложности. При работе с IDEF0-диаграммами существенным является условие их разборчивости и удобочитаемости. Суть принципа ограничения сложности состоит в том, что количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде модели IDEF0, хорошо структурированы, понятны и легко поддаются анализу. Принцип контекстной диаграммы. Моделирование делового процесса начинается с построения контекстной диаграммы. На этой диаграмме отображается только один блок - главная функция моделируемой системы. Если речь идет о моделировании целого предприятия или крупного подразделения, главная функция может быть сформулирована как, например, "продавать продукцию". Главная функция системы - это предназначение системы в окружающем мире - ее стратегия. При определении главной функции необходимо всегда иметь в виду точку зрения на модель. Одно и то же предприятие может быть описано по-разному, в зависимости от того, с какой точки зрения его рассматривают: директор предприятия и налоговый инспектор видят организацию совершенно по-разному. Контекстная диаграмма играет еще одну роль в функциональной модели. Она "фиксирует" границы моделируемой системы, определяя то, как моделируемая система взаимодействует со своим окружением. Это достигается за счет описания дуг, соединенных с главной функцией системы. Модель IDEF0 является иерархически организованной совокупностью диаграмм. При этом каждый блок диаграммы может рассматриваться как отдельный тщательно определенный объект. Разделение такого объекта на его структурные части (блоки и дуги) называется декомпозицией. Каждая диаграмма в рамках модели, как и каждый функциональный блок, имеет свою уникальную идентификацию. Диаграмма верхнего уровня содержит единственный блок А0. Блоки на диаграмме А0 имеют нумерацию: Al, A2..., где буква А обозначает Activity (действие, функция). Предусматриваются пять типов взаимосвязей между блоками, которые имеют следующее значение: взаимосвязь по управлению - выход одного блока влияет на выполнение функции в другом блоке; Взаимосвязь по входу - выход одного блока является входом для другого; Обратная связь по управлению - выходы из одной функции влияют на выполнение других функций, выполнение которых, в свою очередь, влияет на выполнение исходной функции; Обратная связь по входу - выход из одной функции является входом для другой функции, выход которой является для него входом; Взаимосвязь "выход-механизм" - выход одной функции является механизмом для другой. Принятая в IDEF0 система обозначений для дуг позволяет точно определять и проверять связи по дугам между диаграммами за счет использования так называемых ICOM-кодов. Они получили свое название по первым буквам английских слов Input (Вход), Control (Управление), Output (Выход), Mechanism (Механизм). При построении диаграммы очередного уровня иерархии дуги, касающиеся декомпозируемого блока, переносятся на детализирующую его диаграмму в виде ICOM-кодов (II..., Cl..., Ol..., Ml...). После завершения работы над диаграммой ее внутренние дуги стыкуются с внешними, содержание которых может быть описано на более высоком уровне иерархии. На рис. 5.8 и 5.9 показаны модель Как-Есть до начала реинжиниринга и модель Как-Будет после его окончания на примере процесса транспортных перевозок. Результатом реинжиниринга является не только уменьшение числа операций за счет объединения процессов определения потребности в транспорте и заключения договора с транспортной организацией в один, но также и резкого сокращения времени выполнения каждого процесса. Рис. 5.8. Модель Как-Есть Рис. 5.9. Модель Как-Будет |