Метод IDEF3 предназначен для моделирования последовательности выполнения действий и взаимозависимости между ними в рамках процессов. Модели IDEF3 могут использоваться для детализации функциональных блоков IDEF0, не имеющих диаграмм декомпозиции.
Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются, как и в IDEF0, с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер (номер действия обычно предваряется номером его родителя, например, 1.1.). Все связи в IDEF3 являются однонаправленными и организуются слева направо.
Типы связей IDEF3:
Временное предшествование (Temporal precedence), простая стрелка.
Исходное действие должно завершиться, прежде чем конечное действие сможет начаться.
Объектный поток (Object flow), стрелка с двойным наконечником. Выход исходного действия является входом конечного действия. Исходное действие должно завершиться, прежде чем конечное действие сможет начаться. Наименования потоковых связей должны чѐтко идентифицировать объект, который передается с их помощью.
Нечеткое отношение (Relationship), пунктирная стрелка.
Завершение одного действия может инициировать начало выполнения сразу нескольких других действий, или наоборот, определенное действие может требовать завершения нескольких других действий до начала своего выполнения (ветвление процесса). Ветвление процесса отражается с помощью специальных блоков (операторов):
-«И» – блок со знаком &.
-«Исключающее ИЛИ» («одно из») – блок со знаком Х.
-«ИЛИ» – блок со знаком О.
Если действия «И», «ИЛИ» должны выполняться синхронно, это обозначается двумя двойными вертикальными линиями внутри блока, асинхронно – одной.
Метод IDEF3 позволяет декомпозировать действие несколько раз, что обеспечивает документирование альтернативных потоков процесса в одной модели.
21
Цель DFD (моделирование потоков данных) – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные. Может отражать не только информационные, но и материальные потоки.
Основными компонентами диаграмм потоков данных являются:
–внешние сущности (материальный объект или физическое лицо, являющееся источником или приѐмником информации (заказчики, персонал, поставщики, клиенты, склад));
–системы и подсистемы (подсистема по работе с физическими лицами и др.);
–процессы (преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом; физически это может быть, например, подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т. д.);
–накопители данных (абстрактные устройства для хранения информации);
–потоки данных (на диаграмме стрелки).
Необходимо размещать на каждой диаграмме от трех (меньше нет смысла) до семи (больше не воспринимаемо) процессов, не загромождая диаграммы несущественными на данном уровне деталями.
Первым шагом при построении иерархии процессов является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации. Для сложных систем (десять и более внешних сущностей, распределенная природа и многофункциональность системы) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных.
Каждый процесс на DFD может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификации представляют собой описания алгоритмов задач, выполняемых процессами.
При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей «AS–IS» и «AS–TO–BE», отражая существующую или предлагаемую структуру бизнес-процессов организации.
Студенту необходимо построить модель AS–IS выбранного бизнеспроцесса, используя стандартные методологии: IDEF0 (функциональное мо-
22
делирование), DFD (моделирование потоков данных) и IDEF3 (моделирование потоков работ) в рамках программного пакета All Fusion Process Modeler r7 (BPwin).
Моделирование может быть начато с контекстной диаграммы деятельности организации или рассматриваемого бизнес-процесса.
Все диаграммы декомпозиции представить виде отсканированных доку-
ментов из программного пакета AllFusion Process Modeler r7 (BPwin), разме-
щая их как в основной части курсовой работы, так и в приложениях к ней, делая соответствующие ссылки по ходу описания выполняемых процедур моделирования процесса.
2.5. Построение новой (усовершенствованной) модели процесса «AS–TO–BE» («как должно быть»)
Всоответствии с требованиями и рекомендациями международных и отечественных стандартов [5] управление процессами заключается в непрерывном их измерении, контроле и улучшении в соответствии с циклом Деминга (PDCA), который всегда имеет несколько оборотов. Реализация этого цикла обеспечит повышение качества процесса.
На основе анализа процессов организации и проверки результатов измерений (мониторинга) процессы можно оценить по степени их действенности, эффективности и существующего потенциала для улучшения. Вместе с расстановкой приоритетов процессов (ключевые, управленческие и поддерживающие) такая оценка потенциала для улучшения помогает разрабатывать стратегию их улучшения. При этом можно применять широкий спектр возможностей улучшения процессов – от непрерывного их улучшения до реинжиниринга, т. е. радикальной перестройки бизнес-процесса (Business Process
Reengineering).
Вобщей системе управления бизнес-процессами реинжиниринг занимает место тактического управления (рис. 6).
По сути дела обоснование выбора того или иного бизнес-процесса в качестве объекта описания и дальнейшего моделирования (раздел 2.3 курсовой работы) должно базироваться на основе данных анализа соответствия самого процесса, показателей его результативности и показателей качества управления процессом требованиям потребителей результатов этого процесса. Тем самым и интересен выбор данного процесса, так как он требует улучшения (совершенствования) действующей модели процесса «AS–IS».
23
Управление бизнес-процессами
Управление парамет- |
Управление структурой |
Управление |
рами бизнес-процессов |
бизнес-процессов |
набором бизнес- |
(оперативное |
(совершенствование и |
процессов |
управление) |
реинжиниринг) |
(стратегическое |
|
|
управление) |
Объем, цена, издержки, |
Состав и логическая взаимо- |
Конкурентоспо- |
затраты времени, трудо- |
связь выполняемых работ. |
собность бизнес- |
емкость, частота, перио- |
Порядок документооборота. |
процессов |
дичность и др. |
Порядок движения |
|
|
материальных потоков. |
|
|
Используемые механизмы и |
|
|
технологии |
|
Рис. 6. Схема уровней управления бизнес-процессами
В этом разделе курсовой работы необходимо указать выявленные несоответствия действующей модели процесса «AS–IS» или проблемы, препятствующие его нормальному функционированию, которые возможно устранить или минимизировать их влияние на качественные показатели и результаты процесса.
После чего требуется построить новую модель процесса «AS–TO–BE» («как должно быть») с использованием того же программного пакета All
Fusion Process Modeler r7.
2.6. Разработка спецификации усовершенствованного бизнес-процесса
Параллельно с разработкой и построением усовершенствованной модели рассматриваемого бизнес-процесса необходимо представить его новую спецификацию (информационную карту) в соответствии с требованиями, которые предъявляются к содержанию и оформлению ее разделов (прил. 3).
Особое внимание следует уделить показателям результативности усовершенствованного бизнес-процесса.
На завершающем этапе необходимо провести сопоставление действующей и вновь разработанной карты процесса с указанием выявленных различий по каждому разделу карты процесса.
24
2.7.Заключение курсовой работы
Взаключительной части курсовой работы должны быть отражены полученные результаты и уровень выполнения поставленных перед студентом задач.
Следует предложить план мероприятий по внедрению новой (усовершенствованной) модели бизнес-процесса.
25