6.4.3.EPC
Для описания бизнес-процессов нижнего (операционного) уровня можно использовать нотацию EPC (Event-Driven Process Chain). EPC-метод был разработан Августом-Вильгельмом Шеером в рамках работ над созданием ARIS в начале 1990-х годов.
ARIS (Architecture of Integrated Information Systems) – методология и тиражируемый программный продукт для моделирования бизнес-процессов организаций.
Нотация используется многими организациями для моделирования, анализа и реорганизации бизнес-процессов. Пришла на смену IDEF3 и хорошо сочетается с IDEF0, как раскрытие функциональных блоков. Ключевая особенность EPC-диаграмм – описание бизнес-процесса как последовательности чередующихся событий и функций.
Основные графические элементы диаграммы EPC:
- функции;
- события;
- роли или организационные единицы, ответственные за исполнение функций;
- информационные или материальные объекты, которые используются при выполнении функций;
- коннекторы (AND, OR, XOR).
Основные правила при моделировании просты, но между тем строги (дисциплинируют и вынуждают выяснять детали):
- каждая функция инициируется событием и завершается также событием;
- в каждую функцию не может входить более одной стрелки, «запускающей» выполнение функции;
- из каждой функции может выходить не более одной стрелки, описывающей завершение выполнение функций.
При моделировании процессов консультант очень часто сталкивается с ситуацией, когда одно событие в рамках процесса может инициировать выполнение одновременно нескольких функций, и наоборот – функция может быть результатом нескольких событий. Каким образом отразить это в диаграмме модели? Такие логические разветвления в потоке процесса отображаются при помощи операторов:
- логическое И (AND) – все ветки должны отработать;
- логическое ИЛИ (OR) – любая одна, несколько или все ветки;
- логическое взаимоисключающее ИЛИ (XOR) – только одна из веток отработает.
При моделировании процесса стоит придерживаться определенных правил расположения графических элементов на диаграмме:
- графические элементы процесса (события и функции) следует располагать сверху вниз;
- графические элементы, отображающие исполнителей функций (сотрудников и подразделений), следует располагать справа от функций;
- документы, используемые при выполнении функций, располагаются слева от функций, а формируемые в результате выполнения функций – располагаются справа от функций (вариант – тоже слева, чтобы не пересекаться с исполнителями, но тогда нужно рисовать у стрелки начало-конец).
Рис. 6.7. Элементы графической схемы в «1С»
Такие требования последовательности изображения элементов схемы затрудняют возможность уместить схему на печатном листе формата А4, схема EPC склона к «распуханию», нужно аккуратно ее декомпозировать на подпроцессы.
Правила построения схем EPC:
- если в рамках бизнес-процесса формируются или поступают какие-либо документы (учетные документы), они должны быть отражены на схеме в обязательном порядке;
- функции на схемах следует именовать отглагольными существительными, например «Регистрация заявки»;
- использование отглагольных существительных для других элементов, кроме функций и бизнес-процессов, запрещено;
- каждой функции и бизнес-процессу следует давать код – например, код функции может быть формата <Код бизнес-процесса>.<Код функции>;
- в схемах допускается использование меток на естественном языке. Метками можно пояснять соединительные линии (стрелки связи элементов модели). Стрелки показывают, как функции системы связаны между собой, как они обмениваются данными;
- объект схемы не может быть замкнут сам на себя;
- в модели разрешены циклы между несколькими объектами;
- разрешено только одно соединение между двумя объектами (все деления и слияния через коннекторы);
- одна функция (действие, работа) может иметь несколько последователей и несколько предшественников. Для отображения логических условий пересечения связей последовательности следует использовать специальные элементы И, ИЛИ, XOR;
- по возможности следует декомпозировать функции бизнес-процесса до такого уровня, чтобы у одной функции не было нескольких исполнителей – ролей;
- можно перечислять через запятую названия сущностей на схеме внутри одного элемента, например: «Движения по складу, расчеты по поставщику, проводки по БУ».

- 1. Обложка
- 2. Титульный лист
- 3. Выходные данные
- 4. Введение
- 5. Принятые термины и сокращения
- 6. Глава 1. Что такое ERP-система и зачем она компании
- 7. 1.2.Отличие ERP-системы от учетной бухгалтерской системы
- 8. 1.3.Зачем ERP-система компании
- 9. 1.4.Затраты на владение системой (стоимость эксплуатации)
- 10. 1.4.1.Облачные сервисы как путь снижения затрат
- 11. Глава 2. Как выбрать ERP-систему
- 12. 2.2.Тендер и участие в нем
- 13. 2.2.2.Со стороны исполнителя
- 14. 2.3.Fit-gap анализ разных систем
- 15. 2.4.ИТ-ландшафт текущий и перспективный
- 16. 2.5.Нагрузочные тесты и выбор «железа»
- 17. 2.6.Окупаемость и обоснование затрат на автоматизацию
- 18. Глава 3. Как внедрять ERP-систему
- 19. 3.1.1.Agile-методологии
- 20. 3.1.2.Серия стандартов ISO
- 21. 3.1.3.ГОСТ 34
- 22. 3.1.4.PMBOK
- 23. 3.1.5.Технологии управления проектами фирмы «1С»
- 24. 3.2.Введение в терминологию
- 25. 3.2.1.Проектный треугольник
- 26. 3.3.Реинжиниринг бизнес-процессов
- 27. 3.4.Какие подсистемы в какую очередь внедрять
- 28. Глава 4. Кто участвует в проекте внедрения
- 29. 4.1.1.Управляющий комитет
- 30. 4.1.2.Проектная команда исполнителя
- 31. 4.1.3.Рабочая группа со стороны заказчика
- 32. 4.2.Мотивация участников проекта внедрения
- 33. 4.2.2.Модели мотивации
- 34. 4.3.Коммуникация и конфликты
- 35. 4.3.1.Удаленное взаимодействие
- 36. 4.3.2.Командообразование
- 37. 4.3.3.Управление конфликтами
- 38. Глава 5. Этапы и документация проекта
- 39. 5.2.Документация проекта
- 40. 5.3.Фазы проекта
- 41. 5.3.2.Анализ и концептуальное проектирование
- 42. 5.3.3.Дизайн архитектуры системы
- 43. 5.3.4.Разработка
- 44. 5.3.5.Опытная эксплуатация
- 45. 5.3.6.Ввод в промышленную эксплуатацию
- 46. 5.3.7.Закрытие проекта
- 47. Глава 6. Что анализировать и как настроить прототип системы
- 48. 6.2.Готовим отчет
- 49. 6.3.Приоритизация требований
- 50. 6.4.Описание бизнес-процессов
- 51. 6.4.1.Функциональные блок-схемы
- 52. 6.4.2.IDEF0
- 53. 6.4.3.EPC
- 54. 6.4.4.BPMN
- 55. 6.4.5.Особенности описания бизнес-процессов
- 56. 6.5.Прототип и его демонстрация
- 57. Глава 7. Как оценить срок и бюджет проекта
- 58. 7.2.Методы оценки трудозатрат
- 59. 7.2.2.Анализ предложений исполнителей
- 60. 7.2.3.Оценка «снизу вверх»
- 61. 7.2.4.Оценка «сверху вниз»
- 62. 7.2.5.Экспертная оценка
- 63. 7.2.6.Параметрическая оценка
- 64. 7.2.7.Оценка по трем точкам (метод PERT)
- 65. 7.3.Мифический человеко-час
- 66. 7.4.Расчет себестоимости человеко-часа
- 67. 7.5.Как получить итоговый срок проекта
- 68. Глава 8. Риски проекта и управление ими
- 69. 8.2.Какие риски бывают в проекте внедрения ERP-системы
- 70. 8.3.Профилактика и как бороться с проявлениями рисков
- 71. 8.4.Когда риски можно игнорировать
- 72. 8.5.Процедура управления рисками в проекте внедрения ERP-системы
- 73. Глава 9. Как пережить фазы разработки и опытной эксплуатации
- 74. 9.2.Стандарты разработки
- 75. 9.3.Тестирование
- 76. 9.4.Готовимся к обучению пользователей
- 77. 9.5.Опытная эксплуатация
- 78. 9.6.Ведем список запросов на изменение
- 79. Глава 10. Запуск системы и что дальше
- 80. 10.2.Система продолжает работать – сопровождение корпоративной системы
- 81. Заключение
- 82. Список использованной литературы
Комментариев: 0