Эволюция подходов к моделированию и управлению бизнес-процессами. Понятие моделирования бизнес-процессов. Методология функционального моделирования IDEF0. Диаграмма потока данных DFD. Нотации Процесс и Процедура. Нотация EPC.
Первая волна: Фредерика Тейлора « Принципы научного управления». Используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Попытки автоматизации бизнес-процессов. Вторая волна: M. Хаммера и Д. Чампи «Реинжиниринг корпорации: манифест революции в бизнесе». Появление систем управления потоками работ WfMS ( Workflow Management Systems ) 2-го поколения. Третья волна: Г. Смит и П. Фингар «Управление бизнес-процессами: третья волна». Появление систем управления бизнес-процессами BPMS. Стремление к стандартизации.
Моделирование бизнес-процессов Совершенствование деятельности Использование ИТ Первая волна 1920–80-е гг. Анализ способов выполнения работ. Рационализация трудовых операций. Модели на бумаге. Низкая автоматизация 1980-е гг. Всеобщее управление качеством. Непрерывность изменений. Научный подход. Последовательное совершенствование 1970–90-е гг. Система управления базами данных. Совместное использование данных. Приложения, обращающиеся к базам данных Вторая волна 1990-е гг. ПО для построения диаграмм и анализа процессов в статике. Ручной реинжиниринг. Единовременное создание модели. Автоматизация: КИС с поддержкой потоков работ (WfMS, ERP) 1990-е гг. Реинжиниринг бизнес-процессов. Дискретность изменений. Ненаучный подход. Радикальное преобразование 1990-е гг. Распределенные вычисления. Совместное использование функций. Распределенные приложения Третья волна 2000-е гг. Ориентированное на бизнес-процессы ПО. Исполняемые модели. Итеративная оптимизация. Средства моделирования интегрированы в BPMS. Имитационное моделирование и анализ моделей в динамике. Конвертирование моделей. Стандартизация методологий 2000-е гг. Управление бизнес-процессами (BPM). Непрерывность изменений. Гибкость, адаптивность. Научный подход. Итеративное совершенствование 2000-е гг. Системы управления бизнес-процессами. Совместное исполнение бизнес-процессов. Распределенные бизнес-процессы
OASIS ( Organization for the Advancement of Structured Information Standards ): в спецификации ebXML и BPEL, стандарты для электронного бизнеса на базе XML и веб-сервисов ; OMG ( Object Management Group ): стандарты BPMN и UML, MDA и CORBA; W3C ( World Wide Web Consortium ): стандарты WS-CDL, WSCI, спецификации XML, технологии веб-сервисов; WfMC ( Workflow Management Coalition ): стандарты Wf -XML и XPDL. Изначально методологии BPML и BPMN были созданы консорциумом BPMI.org ( Business Process Management Initiative ), дальнейшее развитие BPML было прекращено в пользу BPEL, в 2005 г. произошло слияние BPMI.org с OMG, и в настоящее время работы над BPMN ведутся в рамках OMG.
Язык BPML дополняет язык реализации бизнес-процессов ( Business Process Execution Language, сокр. BPEL). BPML может использоваться для определения детальных бизнес-процессов, исполняемых при вызове каждого web -сервиса. BPML преобразует (« мэппирует ») бизнес-операции в обменные сообщения. Этот язык может использоваться для определения корпоративных бизнес-процессов, комплексных web -сервисов и многостороннего сотрудничества. В разработке BPML-спецификаций участвует целый ряд организаций: CSC, Intalio, SAP, Sun, SeeBeyond, Versata и др. UML ( Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. Концепция MDA ( Model Driven Architecture ) призвана обеспечить общую основу для описания и использования большинства существующих стандартов, не ограничивая разработчиков в выборе конкретных технологий. CORBA ( Common Object Request Broker Architecture — общая архитектура брокера объектных запросов; типовая архитектура опосредованных запросов к объектам) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология. Web Services Choreography Description Language (WS-CDL). Спецификация предназначена для создания сценариев взаимодействия Web -сервисов в рамках общего бизнес-протокола.
Технологии автоматизации межкорпоративного взаимодействия : бизнес-бизнес ( Business-to-Business, B2B ); ebXML ( Electronic Business using extensible Markup Language, ISO 15000 ). Наращивание функционала систем Workflow. Переход от задач описания процессов к задачам совершенствования по параметрам стоимости, качества и времени выполнения. Использование системы сбалансированных показателей (BSC — Balanced ScoreCard ) для обеспечения контроля результативности через наборы ключевых показателей результативности (KPI — Key Performance Indicators ).
М етод — это совокупность практических и теоретических приемов, позволяющих получить решение поставленной задачи. М етод предлагает свой способ описания деятельности организации. Н е существует одного выделенного метода, при помощи которого можно было бы полно описать организацию. Выбор соответствующего метода зависит от целей, поставленных перед аналитиком, создающим модель организации.
Термин «моделирование» имеет два основных значения: Процесс построения модели как некого представления, образа оригинала, отражающего наиболее важные его черты и свойства. Если же модель уже построена, то моделирование – это процесс исследования (анализа) функционирования системы (модели ).
Модель бизнес-процесса – формализованное (графическое, табличное, текстовое) описание БП, отражающее реально существующую или предполагаемую деятельность организации.
Модель, как правило, содержит следующие сведения о бизнес-процессе: набор составляющих процесс шагов – бизнес-функций; порядок выполнения бизнес-функций; механизмы контроля и управления в рамках бизнес-процесса; исполнителей каждой бизнес-функции; входящие документы/информацию, используемые каждой бизнес-функцией; исходящие документы/информацию, генерируемые каждой бизнес-функцией; ресурсы, необходимые для выполнения каждой бизнес-функции; документацию/условия, регламентирующие выполнение каждой бизнес-функции; параметры, характеризующие выполнение бизнес-функций и процесса в целом ( KPI).
Подходы к построению моделей БП Ф ункциональный Объектно-ориентированный Структурообразующий элемент бизнес-функция, действие, операция объект ( клиент, заказ, услуга)
Важным понятием любого метода моделирования бизнес-процессов являются связи (как правило, их изображают в виде стрелок в графических нотациях). Связи служат для описания взаимоотношений объектов и/или бизнес-функций друг с другом.
Каждый объект и связь обладают рядом параметров ( атрибутов ), отражающих определенные характеристики реального объекта.
Функциональный подход основан на трех принципах: Разбиение исследуемого процесса на функциональные блоки – подпроцессы, исходя из набора принципов, среди которых принцип «определенности» (выход каждого блока должен быть ясно понимаем независимо от сложности процесса), «единственности» и т. д. 2) Возможность детализации любых процессов путем иерархической декомпозиции. 3) Использование для описания процесса графических нотаций с возможностью текстового разъясняющего дополнения.
1960-х гг. Дуглас Росс (Массачусетский технологический институт, компания SoftTech ): методология структурного анализа и проектирования SADT ( Structured Analysis and Design Technique ). конец 1970-х гг. Министерство обороны США, программа интегрированной компьютерной поддержки производства ICAM ( Integrated Computer-Aided Manufacturing ): принята значительная часть SADT. в 1970-х гг. появился целый набор таких методов под общим названием IDEF (первоначально ICAМ DEFinition, затем Integrated DEFinition ). 1981 г. Технология SADT, переименованная в IDEF0, получила статус федерального стандарта США (последняя редакция выпущена Национальным Институтом По Стандартам и Технологиям США NIST – National Institute of Standards and Technology в 1993 г.,).
IDEF0 – методология функционального моделирования, снабженная наглядным графическим языком и позволяющая представить моделируемую систему в виде набора взаимосвязанных функций. Как правило, является первым этапом изучения системы ; IDEF1 – методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи ; IDEF1X (IDEF1 e Xtended ) – методология построения реляционных структур. О тносится к типу методологий «сущность-взаимосвязь» ( Entity-Relationship – ER) и, как правило, применяется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе ;
IDEF3 – методология описания процессов, происходящих в системе. Описывает сценарий и последовательность операций для каждого процесса. Близка к алгоритмическим методам построения схем процессов и стандартным средствам построения блок-схем (построение блок-схемы в программе MS Word ); IDEF4 – методология объектно-ориентированного проектирования. Р еализует объектно-ориентированный анализ больших систем, предоставляя пользователю графический язык для изображения классов, диаграмм наследования, таксономии методов ; IDEF5 – методология онтологического исследования сложных систем. Систему можно описать с помощью определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На базе этих утверждений формируются выводы о дальнейшем развитии системы и производится ее оптимизация.
Элемент – функциональный блок.
Элемент – стрелка (интерфейсная дуга). Стрелки могут быть: Входящие Input – вводные, которые ставят определенную задачу (вход). Исходящие Output – выводящие результат деятельности (выход) Управляющие (сверху вниз) Control – механизмы управления (положения, инструкции и д р.). Механизмы (снизу вверх) Mechanism – используется для того, чтобы произвести необходимую работу (обеспечение, ресурсы). Каждая сторона четырехугольника определяет тип стрелки. Каждая стрелка на дочерней диаграмме должна соответствовать стрелкам на родительской диаграмме.
Граничные стрелки помечаются с помощью ICOM -меток: Input, Control, Output, Mechanism.
Принципы моделирования: − функциональной декомпозиции; − ограничения сложности; − контекста.
Родительская диаграмма Дочерняя диаграмма
количество функциональных блоков на одной диаграмме должно быть не менее двух и не более шести; с каждой стороны в четырехугольник может входить не более шести стрелок одновременно. объекты на диаграмме расположены в шахматном порядке, или в так называемом порядке доминирования.
Моделирование бизнес-процесса начинается с построения контекстной диаграммы. На диаграмме отображается только один блок – главная бизнес-функция моделируемой системы. Планировать учебную нагрузку преподавателя А0 Нормативные документы Сотрудники кафедры Спланированная учебная нагрузка преподавателя Данные о преподавателе и учебных дисциплинах
Нумерация диаграмм: П роисходит сверху вниз — от диаграммы верхнего уровня к диаграммам нижнего уровня. Каждая диаграмма нижнего уровня получает свой номер на основе номера родительской диаграммы верхнего уровня.
Ветвление и слияние стрелок
Туннелирование
Рамка (каркас) диаграммы
Вспомогательный элемент – глоссарий ( Glossary ). Для каждого из элементов IDEF0 (диаграмм, функциональных блоков, интерфейсных дуг) создается набор соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом.
Построение модели: Шаг 1. Построение модели «как есть». Шаг 2. Определение бизнес-правил. Шаг 3. Построение модели «как должно быть». Шаг 4. Распределение ресурсов.
Определение бизнес-правил
Н аправлена на анализ функциональных аспектов и позволяет ответить на вопрос: «Что делает система ?». П одходит для описания бизнес-процессов верхнего уровня и позволяет отразить управление процессами, обратные связи и информационные потоки. Существует целый ряд программных инструментов, поддерживающих функциональное моделирование в стандарте IDEF0: BPwin и ERwin, ERwin Process Modeler ( Computer Associates ), IDEF0.EM Tool (ИП Ориентсофт ), Design /IDEF ( MetaSoftware ).
DFD ( Data Flow Diagram, 1979 г.) представляет иерархию функциональных процессов, связанных потоками данных. Цель — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Как и в IDEF0, основу методологии DFD составляет графический язык описания процессов. Используется при построении функциональной модели TO-BE. Распространенные графические нотации DFD: Йордана – Де Марко (Эд Йордан ( Yourdon ) и Том де Марко ( DeMarko )); Гейна Сарсона ( Gane Sarson ).
Где используется: при разработке программного обеспечения. для выявления проблем документооборота, дублирования документов или, наоборот, недостающей документации или электронных данных в системе. Не является исполнимой нотацией. Необходима для понимания особенностей документооборота, структуры и последующей работы с данными.
DFD должна наглядно ответить на вопросы: из чего состоит информационная система? что нужно, чтобы обработать информацию?
Элементы: Процесс (англ. Process ), т.е. функция или последовательность действий, которые нужно предпринять, чтобы данные были обработаны. Внешние сущности (англ. External Entity ). Л юбые объекты, которые не входят в систему, но являются для нее источником информации либо получателями какой-либо информации из системы после обработки данных. Хранилище данных (англ. Data store ). Внутреннее хранилище данных для процессов в системе. Поток данных (англ. Data flow ). В нотации отображается в виде стрелок, которые показывают, какая информация входит, а какая исходит из того или иного блока на диаграмме.
Графические эле м енты DFD
Нотация Гейна Сарсона
Требования к оформлению процесса: Каждая функция (процесс) должна иметь идентификатор; Название процесса нужно формулировать согласно формуле: Название процесса = Действие + Объект, над которым действие осуществляется Например, если эта работа связана с действием по продаже продукции, то ее нужно назвать <Продать продукцию>. Название работы должно быть по возможности кратким и состоять из 2-3 слов.
Требования к оформлению потока: Название потока нужно формулировать согласно формуле: Название потока = Объект, представляющий поток + Статус объекта Если речь идет о продукции, которую отгрузили клиенту, то поток можно назвать <Продукция, отгруженная> или <Продукция, отгруженная клиенту>. В данном случае <Продукция> это объект, представляющий поток, а <отгруженная клиенту> — статус объекта. Название должно быть по возможности кратким и состоять из 2-3 слов.
Требования нумерации: Внешние сущности ( External Entity ). Хранилище данных ( Data store ).
Требования к построению: Нет ограничения по количеству элементов, которые могут находиться на одной диаграмме. Чем больше элементов на диаграмме, тем сложнее ее читат ь. Рекомендация: количество процессов на диаграмме не должно быть больше семи. Имеет смысл строить DFD-диаграмму линейно, с выделением уровней функций, сущностей, хранилищ. Каждый процесс должен иметь хотя бы один вход и один выход. Процесс обработки данных должен иметь внешнюю входящую стрелку (данные от внешней сущности). Стрелки не могут связывать напрямую хранилища данных, все связи идут через процессы. Все процессы должны быть связаны либо с другими процессами, либо с другими хранилищами данных. Процессы не существуют сами по себе, а потому результат должен куда-то передаваться.
Основной принцип построения – принцип декомпозиции. DFD-модель включает в себя три документа, которые ссылаются друг на друга: Графические диаграммы. Миниспецификация. Словарь данных.
Шаг 1. Построение контекстной диаграммы. Уровень системы
Шаг 1. Построение контекстной диаграммы. В некоторых случаях стоит построить несколько контекстных диаграмм с иерархией: наличие большого количества внешних сущностей (десять и более); распределенная природа системы; многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы.
Шаг 2. Детализация подсистем на контекстной диаграмме. Правила : балансировки — при детализации процесса дочерняя диаграмма в качестве внешних источников/приемников данных может иметь только те компоненты (подсистемы, процессы, внешние сущности, накопители данных), с которыми имеет информационную связь соответствующий процесс на родительской диаграмме; нумерации — при детализации процессов должна поддерживаться их иерархическая нумерация. семи — для того, чтобы диаграмма легко читалась, количество функций на диаграмме не должно быть больше семи. Например, процессы, детализирующие процесс с номером 12, получают номера 12.1, 12.2, 12.3 и т.д.
Шаг 2. Детализация подсистем на контекстной диаграмме. Уровень подсистемы
Шаг 2. Детализация подсистем на контекстной диаграмме. Уровень процесса
Шаг 3. Миниспецификация. Документ, детально описывающий логику процесса. С одержит номер процесса, списки входных и выходных данных, тело процесса — подробный алгоритм функции, преобразующий входные потоки данных в выходные.
Шаг 3. Миниспецификация. Требования:
Шаг 4. Создание Словаря данных. Определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонент хранилищ. Определения элементов данных в словаре осуществляются: описанием значений потоков и хранилищ, изображенных на DFD; описанием композиции агрегатов данных, движущихся вдоль потоков, т.е. комплексных данных, которые могут расчленяться на элементарные символы (например, АДРЕС ПОКУПАТЕЛЯ содержит ПОЧТОВЫЙ ИНДЕКС, ГОРОД, УЛИЦУ и т.д.); описанием композиции групповых данных в хранилище; специфицированием значений и областей действия элементарных фрагментов информации в потоках данных и хранилищах; описанием деталей отношений между хранилищами.
Шаг 4. Создание Словаря данных. Определяются структура и содержание всех потоков данных и хранилищ данных, которые присутствуют на диаграммах. Для каждого потока в словаре хранятся: имя потока, тип, атрибуты. Например, при моделировании документооборота вводятся сведения о структуре и реквизитном составе документов.
Нотация Basic FlowChart ( BFC, Процесс, простая блок-схема) применяется для моделирования отдельных процессов компании, а также на нижнем уровне модели бизнес-процессов, например, совместно с IDEF0. Представляет алгоритм выполнения процесса и является нотацией класса workflow. Позволяют задать причинно-следственные связи и временную последовательность выполнения действий процесса. 1921 г. – американский инженер Франк Банкер Гилбрет представил первый структурированный метод для документирования потоков процесса ( flow process chart ) для членов Американского общества инженеров-механиков ( American Society ofMechanical Engineers, ASME).
Графические элементы нотации BFC : Начало процесса / Конец процесса Ручной процесс Автоматизированный процесс. Бумажный документ. В каждом блоке этого типа, помимо названия, должен быть обязательно указан код печатного документа. В отдельной таблице, прилагаемой к диаграмме, по коду должны восстанавливаться шаблон и процедуры заполнения печатной формы. Ручной (с клавиатуры, сканера) ввод данных в автоматизированную систему. Блок этого типа должен обязательно иметь связь с блоком типа 7 с указанием соответствующей подсистемы и т.д. Автоматизированная система, электронное хранилище данных. В тексте блока такого типа обязательно должно быть указано название Модуля, Подсистемы, Системы и т.д. Решение (выбор). Текст в этом блоке должен предполагать ответы «Да» или «Нет». Отступление допускается, если при этом вопрос и варианты ответов становятся более понятными (например, возможен вопрос: «Как клиент оплачивает заказ?»-и варианты ответа: «Наличными», «Через банк»). Архив. Значок размещается в том подразделении, где ведется архив. Соединитель страниц. Если символ находится в конце страницы, он должен содержать номер следующей страницы. Если значок расположен в начале – указывается номер предыдущей страницы. Соединитель с другим процессом. Должен содержать код процесса (указывается в заголовке диаграммы перед именем процесса ).
Описание элементов BFC : Процесс – компонент, обозначающий деятельность сотрудников организации, осуществляемую в рамках описываемого процесса и нацеленную на получение результата. Событие – некоторый факт, который может быть обнаружен и идентифицирован сотрудниками организации. Процессы выполняются как следствие произошедших событий, и, в свою очередь порождают новые события. Документ – специальным образом структурированная информация, размещенная на бумажном или электронном носителе.
Если две или более линий объединятся в одну, то место объединения должно быть смещено. Вместо одного символа с соответствующим текстом могут быть использованы несколько символов с перекрытием изображения. Выходящие из блоков документы не должны теряться. Рекомендуемое количество блоков на диаграмме ≤ 30. Требования к построению BFC :
Преимущества BFC Недостатки BFC Простота и наглядность описания Ограниченное число графических элементов Быстрое описание процесса Не требует специальных знаний
Нотация Cross Functional Flowchart ( CFC, Процедура, функциональная блок-схема, кросс-функциональная схема, перекрестно-функциональная диаграмма) отображает процесс на нижнем уровне бизнес-модели. Разработана в 1990-ых гг. на основе диаграмм, которые использовались для представления алгоритмов и описания логики компьютерных программ. Процедура отображает детальный алгоритм выполнения бизнес-процесса, участников бизнес-процесса и их взаимодействие в рамках Процедуры.
Дополнительно к графическим элементам BFC CFC используются дорожки ( Swim Lanes ), обозначающие организационные единицы – исполнителей действий процесса. Это повышает наглядность диаграммы. Дорожка означает должность, подразделение, роль. На дорожках размещают действия, за которые отвечает должность, подразделение, роль. Действия на дорожках связаны между собой информационными или материальными потоками. Дорожки могут быть как горизонтальные, так и вертикальные. Каждое действие может быть декомпозировано (разбито на более детальные бизнес-процессы).
Графические элементы CFC :
Преимущества CFC Недостатки CFC Простота и наглядность описания Ограниченное число графических элементов Быстрое описание процесса Отсутствие визуальных значков для моделирования движения документов и статусов Не требует специальных знаний Невозможность экспорта моделей в BPMS для автоматизации Интеграция с IDEF0 по потокам объектов
Нотация Event-Driven Process Chain ( EPC, событийная цепочка процессов) используется для описания процессов на разных уровнях. Представляет упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её. Может быть проведена декомпозиция (например, в нотациях EPC или BPMN). Нач. 1990-ых гг. – EPC-метод разработан Августом-Вильгельмом Шеером ( August-Wilhelm Scheer ) в рамках работ над созданием методологии ARIS ( Architecture of Integrated Information Systems, Архитектура интегрированных информационных систем). Методология EPC существует в разных интерпретациях (ARIS, Microsoft Visio, Business Studio, Bflow ).
Основные графические элементы EPC :
Основные графические элементы EPC :
Основные графические элементы EPC :
Основные графические элементы EPC :
Основные графические элементы EPC :
Основные графические элементы EPC :
Основные графические элементы EPC : https:// sites.google.com/site/anisimovkhv/learning/pris/lecture/tema8/tema8_3 http:// www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation
Типы связей между объектами на диаграмме процесса в нотации EPC (http://www.businessstudio.ru/wiki/docs/v4/doku.php/ru/csdesign/bpmodeling/epc_notation): процесса ; субъекта ; программного продукта; документа ; базы данных; информации ; товарно-материальных ценностей (ТМЦ); терминов ; операторов.
Правила моделирования: 1. Диаграмма функции должна начинаться как минимум одним стартовым событием) и завершаться как минимум одним конечным событием. 2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями. 3. Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели. 4. События и функции должны содержать строго по одной входящей и одной исходящей связи, отражающей ход выполнения процесса.
Правила моделирования: 5. События и операторы, окружавшие функцию на вышележащей диаграмме, должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции.
Правила моделирования: 6. На диаграмме не должны присутствовать объекты без единой связи. 7. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и хотя бы двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями. 8. Если оператор обладает входящей связью от элемента "событие", то он должен обладать исходящей связью к элементу "функция" и наоборот. 9. За одиночным событием не должны следовать операторы OR или XOR. 10. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно. 11. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор ветвления AND, оператор объединения OR.
Допустимые ситуации
Недопустимая ситуация
Алгоритм построения диаграммы: Шаг 1. Определить начальное и конечное события. Шаг 2. Добавить действия и соответствующие им промежуточные события. Шаг 3. Присоединить документы и (или) информацию, которая необходима для выполнения каждого этапа (входы) и документы, которые являются результатами работы на каждом этапе (выходы). Добавить связи с исполнителями и с обозначением ролей. Р аспространенная роль – «выполняет ». Другие : «утверждают результат», «отвечает за техническую часть», «должен быть уведомлен о нестандартном завершении» и т.п. Шаг 4. Оценить полноту и качество схемы. Проанализировать, все ли варианты исполнения процесса учтены в схеме.
Алгоритм построения диаграммы: Пример первого шага
Алгоритм построения диаграммы: Пример второго шага
Алгоритм построения диаграммы: Пример третьего шага
Преимущества EPC Недостатки EPC Отражает все значимые организационные элементы на одной схеме (в отличие от простой блок-схемы) Необходимость придумывать события на каждые даже незначительные действия Может использоваться на разных уровнях модели – описывать как глобальные процессы, так и делать детальные инструкции Вероятны организационные разрывы из-за неудобного отслеживания назначений Легко делать сложные распараллеливания процесса, так как можно ввести любое количество событий в один ряд Качественное прописывание входов и выходов приводит к перегрузке схемы прямоугольниками, стрелками, которые начинают пересекаться и тем самым еще сильнее усложняют восприятие схемы При распараллеливании работ очень сложно отразить исполнителей
