МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ «СТАНКИН»
ЛАБОРАТОРНЫЕ РАБОТЫ
ПО
ДИСЦИПЛИНЕ «ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА CALS-ТЕХНОЛОГИЙ»
Москва 2009 г.
ЛАБОРАТОРНАЯ РАБОТА №1
Цель работы: Формирование навыков разработки модели бизнес-процесса с использованием EPC-диаграммы.
Задачи работы:
1. Изучение правил построения EPC-диаграммы;
2. Разработка EPC-диаграммы бизнес-процесса в соответствии с заданием.
Правила построения EPC-диаграммы
Объекты диаграммы:
| Объект | Описание |
| Функции представляют собой элементарные действия, направленные на осуществление бизнес-процесса | |
| Департамент или отдельное штатное подразделение, выполняющий функцию | |
| Должность (в т.ч. множественная) в организационной структуре, выполняющая функцию | |
| Информационные носители, как материальной формы (бумажные документы и т.д.), так и электронного представления информации: файлы, электронные письма, ресурсы Интернет и т.д. | |
| Товар или услуга, являющаяся результатом выполнения бизнес-функции или необходимые для выполнения функции | |
| Информационные потоки, обеспечивающие входные и выходные данные процесса | |
| Качественная или количественная ситуация (состояние), достижение которой важно для компании | |
| Нормативные документы |
Отношения объектов диаграммы:
|
1. Для построения диаграммы событийно-управляемого процесса используются объекты, указанные в разделе «Объекты» и связи между ними, указанные в разделе «Отношения объектов».
2. Диаграмма определяется последовательность действий и событий, необходимых для выполнения процесса. Каждая EPC-модель должна начинаться как минимум одним стартовым инициирующим событием (состоянием) и завершаться как минимум одним результирующим событием (состоянием). События и функции по ходу выполнения процесса должны чередоваться (сменять друг друга) (рис.1).
Рис. 1. Функционально-событийная последовательность бизнес-процесса
- Все функции должны идти в правильной последовательность. Необходимо учитывать параллельны они или последовательны.
- События и функции должны иметь только по одному входящему и одному исходящему отношению, показывающему ход выполнения бизнес-процесса.
В случае если есть разветвления, то необходимо использовать оператор ветвления , при этом показывать все возможные варианты течения процесса и результаты выполнения функций. Разветвление всегда начинается после функции.
На eEPC - диаграмме допустимы следующие варианты использования правил ветвления/слияния:
1) Условное ветвление процесса с помощью оператора «исключающее ИЛИ» (при выполнении функции наступает только одно из возможных событий) (Рис.2).
Рис. 2. Разветвление с оператором «исключающее ИЛИ»
2) Условное ветвление процесса с помощью оператора «ИЛИ» (при выполнении функции наступают либо одно событие, либо другое, либо оба сразу) (Рис.3).
Рис. 3. Разветвление с оператором «ИЛИ»
3) Условное ветвление процесса с помощью оператора «И» (при выполнении функции наступают оба события) (Рис.4).
Рис. 4. Разветвление с оператором «И»
4)Функция выполнится, если наступили оба события (Рис.5).
Рис. 5. Соединение с оператором «И»
5) Функция выполнится, если наступило, либо одно событие, либо другое, но не оба сразу (Рис.6).
Рис. 6. Соединение с оператором «исключающее ИЛИ»
6) Функция выполнится, когда наступило хотя бы одно из событий (Рис.7).
Рис. 7. Соединение с оператором «ИЛИ»
- На входе и выходе разветвления обязательно должны использоваться одинаковые операторы (Рис. 8).
Рис. 8. Использование операторов на входе и выходе
- Определяются предшествующие и последующие процессы и отображаются в интерфейсах (рис.9). Если нет предшествующих и последующих процессов в рамках компании, то используется объект «Границы процесса» («Начало процесса», «Завершение процесса»).
Рис. 9. Функционально-событийная последовательность бизнес-процесса с интерфейсами, указанием границы процесса
- Определяется и отображается вся необходимая информация и ресурсы, необходимые для выполнения функции, а также результаты выполнения функции. Необходимо максимально точно отображать входящую и исходящую информацию. Для таких документов таких как: Приказ, Служебная записка, Заявление и т.д., необходимо указывать их назначение. Информация, которая передается в устном виде, а также неструктурированная информация на любых носителях отображается информационным значком (рис.10).
Рис. 10. Функционально-событийная последовательность бизнес-процесса с интерфейсами, входящей и исходящей информацией
- Определяется и отображается исполнитель каждой функции (рис.11).
Рис. 11. Функционально-событийная последовательность бизнес-процесса с интерфейсами, входящей и исходящей информацией, регламентирующими документами и исполнителями
- Определяется возможность и необходимость декомпозиции функции. Если нужно, расписываются функции более детально на ЕРС диаграмме и делается ссылка на нее.
EPC-метод был разработан Августом-Вильгельмом Шеером (August-Wilhelm Scheer) в рамках работ над созданием методологии ARIS (Architecture of Integrated Information Systems - Архитектура интегрированных информационных систем) в начале 1990-х годов.
Диаграмма процесса (функции) в нотации EPC представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и информационные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни.
1. Диаграмма процесса EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).
2. События и функции по ходу выполнения процесса должны чередоваться.
3. Рекомендуемое количество функций на диаграмме - не более 20. Если количество функций диаграммы значительно превышает 20, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.
4. События и функции должны содержать строго по одной входящей и одной исходящей связи (потоку управления), отражающей ход выполнения процесса.
5. На диаграмме не должны присутствовать элементы без единой связи. Исключение может составлять элемент «цель» всего процесса (диаграммы).
6. События и логические операторы, окружавшие функцию на вышележащей (родительской) диаграмме, должны быть начальными/результирующими событиями и операторами на диаграмме декомпозиции функции.
7. Каждый оператор слияния должен обладать минимум двумя входящими связями и только одной исходящей, оператор ветвления - только одной входящей связью и минимум двумя исходящими. Операторы не могут обладать одновременно несколькими входящими и исходящими связями.
8. Логические операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ветвление функции и события невозможно.
9. Логический оператор, разветвляющий ветви, и оператор, объединяющий эти ветви, должны совпадать. Допускается также ситуация, когда оператор ветвления «И», оператор объединения – «ИЛИ».
Примеры допустимых и недопустимых ситуаций приведены на следующем рисунке.
а) допустимые ситуации
 |
 |
 |
 |
б) недопустимые ситуации
 |
 |
Рис. 8.7. Примеры допустимого и недопустимого использования логических операторов
10. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами, потоки в местах пересечений не меняют своего направления.
8.7. Пример построения EPC-диаграммы
На следующем рисунке приведен пример диаграммы EPC процесса «Предпроектное обследование» из обучающих материалов к программному продукту Business Studio .
Рис. 8.8. Диаграмма EPC для процесса «Предпроектное обследование»
Одной из отличительных особенностей нотации, применяемой в Business Studio, является использование обобщенного символа исполнителя («Субъект»). Несмотря на отображение его в виде организационной единицы, под ним может пониматься также должность или персона.
Специализация ГК Абажур — выполнение разноплановых проектов строительства на основе ЕРС/ЕРСМ контрактов… Но для тех, кто в поиске и еще не знает что такое ЕРС и ЕРСМ, предлагаем сборник материалов, которые, как мы надеемся, послужат подспорьем для наших Партнеров и клиентов при работе с такими сравнительно новыми для отечественной практики инструментами, как ЕРС-, ЕРС(М)-контракты.
Структурирование, заключение и исполнение ЕРС и ЕРС(М) контрактов
ГК Абажур специализируется на выполнении разноплановых проектов строительства на основе ЕРС/ЕРСМ контрактов , а также других строительных контрактов с индивидуальными условиями. , применяет системные решения в строительстве с использованием BIM моделирования, создает проекты зданий, при которых достигается низкая капиталоемкость.
Контракты EPC/EPCM – это наиболее распространенный вид договоров в строительной сфере
При выборе той или иной формы важно помнить, что вид договора подряда может привести к существенному изменению уровня издержек и рисков, которые связаны с возведением больших и крупных сооружений. Уровень затрат на пропорционален рискам, которые принимает на себя заказчик. С уменьшением коммерческих рисков, принятых владельцем, увеличиваются издержки на возведение объекта и его управление. В любом бизнесе это логически подтверждается связкой «риск-вознаграждение».
Принятые генеральным подрядчиком обязательства чаще всего включают в себя предоставление четырех видов услуг:
- Инжиниринг (Engineering) – изыскательные работы, создание проекта, согласование документации;
- Снабжение (Procurement) – выбор, закупка и поставка оборудования и материалов, необходимых для выполнения всех работ;
- Возведение объекта (Construction) – строительство, выполнение сборочных и пусконаладочных работ;
- Управление всеми строительными процессами (Construction Management) .
Контрактная стратегия при реализации крупных строительных проектов
Сокращение сроков строительства часто бывает возможным за счет того, что ЕРС-подрядчик, будучи единственным ответственным перед заказчиком лицом, может осуществлять разработку и выдачу проектной и рабочей документации параллельно с закупками материалов и оборудования, а также выполнением СМР.
Например , ЕРС-подрядчик может не дожидаться разработки и утверждения всей проектной документации для того, чтобы начать контрактование оборудования длительного цикла изготовления.
Эффективное применение параллельного проектирования позволяет в ряде случаев серьезно сократить общие сроки строительства. Это особенно актуально для некоторых газовых проектов, в особенности проектов по переработке/подготовке попутного нефтяного газа, где может быть пик добычи, к моменту которого обязательно нужно построить установку по подготовке газа, в противном случае общая рентабельность проекта серьезно ухудшается. В таких случаях оправдано использование ЕРС-модели реализации проекта, которая, несмотря на более высокую стоимость позволяет завершить строительство в более сжатые сроки.
Каждая контрактная стратегия - «традиционная» модель управления силами заказчика и ЕРС-модель обладает сильными и слабыми своими сторонами. Для сравнения приводим таблицы, систематизирующие негативные и позитивные стороны каждой стратегии.
ЕРС(М)-контракт
ЕРС(М) - структура является контрактным решением, которое, с точки зрения распределения рисков, лежит посередине между моделями мультилот и договора ЕРС. Следует сразу оговориться, что единого и однозначного понимания, что считать ЕРС(М)-контрактом не существует. Под таким договором могут понимать, например, ситуацию, когда EPCM-подрядчик выступаем исключительно как консультант, не заключающий никаких договоров субподряда от своего имени.
Равным образом EPC(M)-контрактом может называться договор генерального подряда полного цикла, но в котором цена определена по принципу «открытой книги» (open book) или «возмещения» (cost + fee, reimbursable)*. Сложность в терминологию привносит также то обстоятельство, что ни одна из ведущих международных организаций (FIDIC, ICC Orgalime) не выпустила проформы договора ЕРС(М).
* На наш взгляд, более правильно называть такие контракты
EPC open book и EPC reimbursable либо cost plus fee соответственно
ЕРС(М) представляет собой английскую аббревиатуру Engineering Procurement Construction Management. При этом корректным переводом данной аббревиатуры на русский язык является «Проектирование, Поставки, Управление Строительством». В ЕРС(М) модели слово management (управление) чаще всего относится именно к строительству в узком смысле слова, т.е. к выполнению строительно-монтажных и иных работ на площадке.
С учетом ранее сделанных оговорок о неопределенности в терминологии:
Под ЕРСМ-контрактом чаще всего понимается такая структура, когда EPC(M)-подрядчик собственными силами или силами дочерней компании осуществляет проектирование, самостоятельно осуществляет контрактование оборудования и материалов, но в части строительно-монтажных работ осуществляет лишь управление, т.е. не нанимает от собственного имени строительно-монтажных подрядчиков, а лишь от имени заказчика управляет нанятыми заказчиком подрядчиками.
Принципиальным отличием договора ЕРС(М) от EPC-контракта является то, что ЕРС-контракт является соглашением о «принятии ответственности и рисков»
Заключая ЕРС-контракт, заказчик в значительной степени перекладывает риски и ответственность на ЕРС-подрядчика , который должен эту ответственность обеспечивать ликвидным имуществом. ЕРС(М)-контракт - это соглашение о профессиональных услугах, заказчик «покупает» компетенции , ответственность ЕРС(М)-подрядчика за сроки и бюджет проекта отсутствует либо ничтожно мала в сравнении со стоимостью проекта и носит, таким образом, исключительно стимулирующий характер.
Возможны различные варианты структурирования цены в ЕРС(М)-контракте, однако она никогда не является твердой. Часто цена представляет собой сочетание повременных ставок (в отношении тех функций, которые ЕРСМ-подрядчик выполняет лично – проектирование, управление закупками, управление строительством) и принципа «открытой книги».
Данный принцип означает, что
- субконтрактование осуществляется прозрачным для заказчика способом и с участием его представителей;
- подрядчик раскрывает структуру собственных накладных расходов, а также размер предполагаемой прибыли и такие накладные расходы/прибыль либо фиксируются в определенной сумме либо добавляются в виде процентной надбавки к стоимости каждого договора поставки.
Как уже отмечалось, ответственность ЕРС(М) – подрядчика сильно ограничена и больше напоминает ответственность инженера-консультанта (который отвечает лишь за недобросовестное или некомпетентное оказание собственных услуг), нежели чем ответственность генерального подрядчика.
Вместе с тем довольно часто в договорах ЕРС(М) встречаются механизмы стимулирования подрядчика с использованием принципов бонуса/малуса (т.н. gain sharing / pain sharing) .
Например , договор может предусматривать, что вводе объекта в эксплуатацию в более ранний срок подрядчик получает дополнительное вознаграждение, при задержке подрядчик, наоборот, лишается части прибыли.
Аналогичным образом может строиться стимулирование в отношении общей : стороны могут установить некий целевой бюджет и если, эффективно управляя строительством, подрядчик добьется экономии, то такая экономия делится между сторонами в согласованной пропорции. Тем не менее, ЕРС(М) – подрядчик при согласовании бонуса/малуса обычно не готов рисковать всем вознаграждением и поэтому данный механизм не дает заказчику полного комфорта в отношении стоимости и сроков строительства, а лишь направлен на создание у подрядчика материальной заинтересованности в успешном реализации проекта.
Одним из преимуществ ЕРСМ-контракта по сравнению с моделью EPC является то немаловажное обстоятельство, что тендер по выбору ЕРСМ-подрядчика может быть подготовлен и проведен существенно быстрее, чем тендер на присуждение договора ЕРС lumpsum. Дело в том, что в первом случае от заказчика требуется меньший уровень определенности в отношении объема работ, границ поставки и рисков; и подрядчику необходимо подготовить лишь ценовое предложение в отношении повременных ставок, накладных расходов и собственной прибыли - от него не требуется подготовки твердого ценового предложения, касающегося общей стоимости проекта.
При тендере по модели ЕРС lumpsum, наоборот, заказчику необходимо подготовить детальным образом проработанные техническое задание и требования (при недостаточном уровне проработки подрядчики могут либо вообще отказаться подавать предложения с твердой ценой либо оценить риски в очень большую величину); равным образом, подрядчику требуется на порядок больше времени для подготовки предложения с твердой ценой, учитывающей все риски.
Современные методы строительства, высококлассные материалы и технологии, функции строительного контроля и генерального подрядчика, промышленные и коммерческие здания, монтаж быстровозводимых конструкций. Строительство объектов любой сложности!
Термины:
EPC-подрядчик - это , выполняющий за твердую цену основной объем работ инвестиционного проекта и принимающий на себя все риски его осуществления с момента проектирования и до момента передачи готового объекта заказчику (включая выполнение гарантийных обязательств), по которым он несет финансовую ответственность перед Заказчиком.
Используется, как правило, в тех проектах, где может с достаточной степенью точности оценить размер своих расходов, а также степень рисков.
ЕРС-контракт предполагает , что основной объем работы ЕРС-подрядчик выполняет собственными силами, поэтому не предусматривается специальное вознаграждение за организацию и управление работами привлекаемых контрагентов нижнего уровня.
ЕРСМ-подрядчик может заключать договоры с субподрядчиками от своего имени или же управлять договорами, заключенными заказчиком с конкретными исполнителями работ.
ЕРСМ-контракт предусматривает и общую стоимость проекта с учетом вознаграждения ЕРСМ-подрядчика, и фиксированный срок сдачи объекта в эксплуатацию, достижение основных технических параметров объекта. Способ (подход) ЕРСМ позволяет управлять именно проектом, а не конкретными работами. Специфические работы выполняют профессионалы. Задача ЕРСМ - оценивать потребные свойства (возможности, профессионализм, ресурсы и пр.) выбираемых подрядчиков/поставщиков, распределять правильно между ними работы и зоны ответственности. Далее - координировать их действия, решать спорные вопросы, планировать общую схему проекта, менять планы в случае критических изменений с минимальными последствиями и далее со всеми остановками.
Мировая практика реализации инвестиционных проектов выделяет ЕРС- и ЕРСМ-контракты как наиболее перспективные стратегии реализации сложных промышленных проектов, на которые приходится около 80% реализуемых проектов.
Более подробно читаем публикацию, подготовленную .
В случае возникновения вопросов или комментариев Вы можете — все они будут с благодарностью рассмотрены.
«Чем нагляднее передана информация, тем быстрее и точнее ее воспримет тот, кому она адресована». Эту истину давно и активно используют маркетологи, педагоги и исследователи. Не остались в стороне и менеджеры. В этой статье рассмотрена нотация EPC как один их наиболее популярных современных методов, который позволяет сделать описание сложной работы не только удобным, но и гораздо более точным и понятным всем участникам проекта или процесса.
История возникновения графических стандартов моделирования
Сейчас, когда темпы развития всех процессов в обществе растут и системы усложняются, управление как искусство воздействия на людей вынуждено приобретать еще и способности к системному управлению, схожему с управлением инженерными системами. В начале 90-х годов прошлого века в бизнес-лексикон вошло слово «реинжинирингМайкл Хаммер и Джеймс Чампи впервые ввели это определение в своей книге «Реинжиниринг корпорации» ». А вслед за ним появилось и понятие «инжиниринг» бизнеса. Если первое – это перепроектирование бизнес-процессов, то второе – проектирование эффективной организационной системы с нуля.
Эта тенденция свидетельствует о том, что давно и достаточно успешно ведется поиск методов описания и даже конструирования организации как системы. Если мы будем рассматривать менеджмент не только как искусство, но и как науку, то ему, как и любой другой научной дисциплине, нужны свои специфические системы обозначений для фиксации формул и законов. Такие системные решения с успехом используют инженеры во многих областях деятельности, химики, физики, математики и др.
Социально-экономическая система, коей является организация, гораздо более разнообразна, чем естественные науки, и единой формы записи «аксиом», управленческих формул так пока и не найдено. Но дорожка проложена. А начинается она со всем нам известных блок-схем, которые позволяют описать порядок действий для достижения заданного результата. Но, к сожалению, изобразительные возможности блок-схемы очень ограниченны, и она не позволяет отобразить всего многообразия элементов процесса управления бизнесом.
На сегодня вариантов блок-схем, с помощью которых можно изобразить взаимодействие людей и систем в процессе созидательной деятельности, разработано достаточно много. Они объединены в комплексы инструментов для того, чтобы более полно описать все аспекты деятельности предприятия. Такие инструментальные средства называют методологиями моделирования. Наиболее полными и известными являются три из них:
- ARIS (Architecture of Integrated Information Systems);
- SADT (Structured Analysis and Design Technique);
- UML (Unified Modeling Language).
(нажмите для увеличения)
Для полного и всестороннего описания деятельности предприятия приходится использовать разные графические стандарты, которые заложены в методологию и называются нотациями. Но для решения узких задач достаточно выбрать ту нотацию, которая и придумана для соответствующего описания. Выше вашему вниманию представлен один из графических видов нотаций, о которой речь пойдет в настоящей статье.
Особенности нотации EPC
Нотация моделирования EPC (Event-driven Process Chain) ориентирована на построение алгоритмов взаимодействия в процессе выполнения конкретной работы. Её главными элементами являются:
- события, которые запускают или завершают работу;
- действия (работа), которая переводит систему из одного состояния в другое;
- исполнители работы;
- ресурсы и результаты работы (входы и выходы).
Эта нотация является составной частью методологии ARIS, автор Вильгельм-Август Шеер, разработана в начале 1990-х гг. В конце предыдущего раздела на рисунке продемонстрирован общий вид процесса стандартизации работы с использованием нотации EPC. Рассмотрим особенности описания бизнес-процессов организации с помощью этой нотации. Даже не вникая в суть схемы, сразу бросается в глаза чередование красных и зелёных элементов – это и есть цепочка событий и процессов, заложенная в названии нотации. Состав элементов модели определяется четырьмя основными позициями.
Вполне вероятно, что в ходе описания модели процесса мы соберемся применить информационную систему. Тогда сможем её отобразить с помощью специальных трехуровневых наборов элементов (оранжевого цвета ).
- ИС – информационная система.
- Модуль ИС.
- Функция ИС.
У баз данных традиционно есть свое изображение – в виде цилиндра. Хотя использование их без информационной системы и системы без базы данных на сегодня мне представляется невозможным. Для отображения логики переходов между функциями используются логические операторы, которые помогают конкретизировать условия выполнения параллельных работ или возникновения событий. Они показывают варианты слияния или ветвления как функций, так и событий. Логических операторов всего три: «И», «ИЛИ» и «Исключающее ИЛИ». В разных системах могут использоваться их разные графические обозначения.
Обозначение и использование логических операторов в нотации EPC
Алгоритм построения диаграммы EPC
Как мы видим, несомненным преимуществом данной нотации является интуитивно понятный набор элементов и правил построения диаграмм. Для создания диаграмм процессов рекомендуется использовать специальные программы для моделирования процессов. Для EPC это, в первую очередь, система ARIS. Но она дорогая и достаточно сложная, и для небольших периодических проектов по упорядочиванию деятельности подразделений не используется.
Простота и популярность нотации стимулировало создание других инструментов для рисования бизнес-процессов, в том числе в нотации EPC. Самым простым из них является Visio – один из шаблонов в нем так и называется – «Схема EPC». Наиболее полезным инструментом для меня является система Бизнес Студио. В ней, кроме возможности нарисовать процесс, можно автоматически сгенерировать документ (Регламент процесса) и рабочие инструкции для его участников, что заметно облегчает рутинную часть процесса разработки стандартов деятельности.
Цвета и обозначения вторичных элементов в разных программах могут немного отличаться, но общие правила всегда выдержаны. На представленном в первом разделе статьи примере нотации EPC отражен упрощенный алгоритм работы с данной нотацией. Давайте разберем его по шагам.
После выполнения всех шагов мы получаем детальный план выполнения процесса, понятный его исполнителям. А четко обозначенные события и результаты позволяют настроить точки контроля для всех значимых этапов процесса. И я вновь отсылаю вас к примеру визуальной модели, размещенной в начале статьи.
Преимущества и недостатки нотации EPC
Использование EPC помимо простоты и доступности имеет следующие преимущества.
- Позволяет отразить все значимые организационные элементы на одной схеме (в отличие от простой блок-схемы).
- Может использоваться на разных уровнях модели – описывать как глобальные процессы, так и делать детальные инструкции за счет того, что каждый функциональный блок может стать подпроцессом.
- Легко делать сложные распараллеливания процесса, так как можно ввести любое количество событий в один ряд.
В то же время эта нотация не стала единственной и неповторимой в силу следующих недостатков.
- Необходимость придумывать события на каждые даже незначительные действия сильно усложняет схему.
- Вероятны организационные разрывы из-за неудобного отслеживания назначений.
- Качественное прописывание входов и выходов приводит к перегрузке схемы прямоугольниками, стрелками, которые начинают пересекаться и тем самым еще сильнее усложняют восприятие схемы.
- При распараллеливании работ очень сложно отразить исполнителей. Если один человек выполнят группу функций, картинка усложняется стрелками. Если присутствуют несколько исполнителей или мы не хотим рисовать длинные стрелки, приходится дублировать «овальчики» с исполнителями. Все это очень скоро может привести к полной неразберихе на схеме.
По своему опыту, я могу сказать, что локальные рабочие процедуры, нарисованные в данной нотации, вполне удобны как для разработчика, так и для пользователя инструкции. Нотация подойдет и для проект-менеджеров, поскольку позволяет им наглядно планировать распределение работ в проекте на интуитивно понятном для разных участников проекта языке. А для разработки более сложной многоуровневой модели деятельности предприятия больше подходят другие нотации моделирования, которые мы рассмотрим в следующих статьях.
Нотация EPC (Event-Driven Process Chain – событийная цепочка процессов) используется для описания процессов нижнего уровня. Диаграмма, описанная в нотации EPC, представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальные и конечные события, участники, исполнители, материальные и документальные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни. Диаграмма декомпозируемой функции EPC может быть описана только в нотации EPC.
Используемые графические символы
| Символ | Изображение | Описание |
| Функция | Блок представляет собой функцию – действие или набор действий, выполняемых над исходным объектом (документом, материалом и проч.) с целью получения заданного результата. Внутри блока помещается наименование функции. Временная последовательность выполнения функций задается расположением функций на диаграмме процесса сверху вниз. | |
| Событие | Событие – состояние, которое является существенным для целей управления бизнесом и оказывает влияние или контролирует дальнейшее развитие одного или более бизнес-процессов. Отображает события, активизирующие функции или порождаемые функциями. Внутри блока помещается наименование события. | |
| Стрелка |  | Стрелка отображает связи элементов диаграммы EPC между собой. Связь может быть направленной и ненаправленной в зависимости от соединяемых элементов и типа связи. |
| Оператор AND («И») | 
Рис.18
Рис.19
Рис.20
Рис.21
| Оператор «И» используется для обозначения слияния/ разветвления как функций, так и событий. Если завершение выполнения функции должно инициировать одновременно несколько событий, то это обозначается с помощью оператора «И», следующего после функции и перед событиями. На рисунке (Рис.18) Рис.20завершение выполнения Функции одновременно инициирует события: Событие 1 и Событие 2. Если событие происходит только после обязательного завершения выполнения нескольких функций, то это обозначается с помощью оператора «И», следующего после функций и перед одиночным событием. На рисунке (Рис.19) Событие произойдет только после обязательного завершения Функции 1 и Функции 2. Если функция может начать выполняться только после того, как произойдут несколько событий, то это обозначается с помощью оператора «И», следующего после нескольких событий и перед функцией. На рисунке (Рис.20) Функция начнет выполняться только после того, как произойдут Событие 1 и Событие 2. Если одно событие может инициировать выполнение нескольких функций, то это обозначается с помощью оператора «И», следующего после события и перед функциями. На рисунке (Рис.21 ) Событие одновременно инициирует выполнение Функции 1 и Функции 2. |
| Оператор OR («ИЛИ») | 
Рис.22
Рис.23
Рис.24
| Оператор «ИЛИ» используется для обозначения слияния/ разветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «ИЛИ». Если завершение выполнения функции может инициировать одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после функции и перед событиями. На рисунке (Рис.22) Рис.20завершение выполнения Функции 1 может инициировать только Событие 1, только Событие 2, одновременно и Событие 1, и Событие 2. Если событие происходит после завершения выполнения одной или нескольких функций, то это обозначается с помощью оператора «ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.23) Событие может произойти либо после завершения выполнения Функции 1, либо после завершения Функции 2, либо после завершения выполнения и Функции 1, и Функции 2. Если функция может начать выполняться после того, как произойдет одно или несколько событий, то это обозначается с помощью оператора «ИЛИ», следующего после нескольких событий и перед функцией. На рисунке (Рис.24) Функция может начать выполняться либо после того, как произойдет Событие 1, либо после того, как произойдет Событие 2, либо после того, как произойдут и Событие 1, и Событие 2. |
| Оператор XOR («Исключающее ИЛИ») | 
Рис.25
Рис.26
Рис.27
| Оператор «Исключающее ИЛИ» используется для обозначения слияния/ разветвления функций и для слияния событий. По правилам нотации EPC после одиночного события не может следовать разветвляющий оператор «Исключающее ИЛИ». Если завершение выполнения функции инициирует только одно из событий в зависимости от условия, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего за функцией и перед событиями. На рисунке (Рис.25) Функция инициирует либо только Событие 1 либо только Событие 2. Если событие происходит сразу после завершения выполнения либо одной функции, либо другой, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после функций и перед одиночным событием. На рисунке (Рис.26) Событие может произойти либо сразу после завершения выполнения Функции 1, либо сразу после завершения выполнения Функции 2. Если функция может начать выполняться после того, как произойдет либо только одно событие, либо только другое, то это обозначается с помощью оператора «Исключающее ИЛИ», следующего после нескольких событий и перед функцией. На рисунке (Рис.27) Функция может начать выполняться сразу после того, как произойдет либо Событие 1, либо Событие 2. |
| Интерфейс процесса |  
Рис.28
Рис.29 Диаграмма Процесса 1
Рис.30 Диаграмма Процесса 2
| Элемент, обозначающий внешний (по отношению к текущей диаграмме) процесс или функцию. Используется для указания связи процессов между собой: - обозначает предыдущий или следующий процесс; - обозначает процесс, откуда поступил или куда передается объект. Внутри блока помещается наименование внешнего процесса. На рисунке (Рис.28 ) показано, что договор является результатом выполнения процесса «Заключение договоров». На рисунке (Рис.29 ) показано, что после окончания процесса «Процесс 1» (и наступления события «Событие 1») начинает выполняться «Процесс 2». На диаграмме «Процесс 2» (Рис.30 ) показано, что перед началом «Процесса 2» был завершен «Процесс 1», инициировавший «Событие 1». |
| Бумажный документ | Используется для отображения на диаграмме бумажных документов, сопровождающих выполнение функции. Внутри блока помещается наименование бумажного документа. | |
| Электронный документ | Используется для отображения на диаграмме электронных документов, сопровождающих выполнение функции. Внутри блока помещается наименование электронного документа. | |
| ТМЦ | Используется для отображения на диаграмме товарно-материальных ценностей (ТМЦ), сопровождающих выполнение функции. Внутри блока помещается наименование ТМЦ. | |
| Информация | Используется для отображения на диаграмме информационных потоков, сопровождающих выполнение функции. Внутри блока помещается наименование информационного потока. | |
| Информационная система |  | Используется для отображения на диаграмме информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование информационной системы. |
| Модуль информационной системы |  | Используется для отображения на диаграмме модуля информационной системы, поддерживающего выполнение функции. Внутри блока помещается наименование модуля информационной системы. |
| Функция информационной системы | Используется для отображения на диаграмме функции информационной системы, поддерживающей выполнение функции. Внутри блока помещается наименование функции информационной системы. | |
| База данных | Используется для отображения на диаграмме базы данных, сопровождающей выполнение функции. Внутри блока помещается наименование базы данных. | |
| Термин |  
Рис.31
| Используется для отображения на диаграмме терминов, сопровождающих выполнение функции. Внутри блока помещается наименование термина. Может быть также использован для обозначения статусов бумажных/электронных документов и других элементов справочника «Объекты деятельности». На рисунке (Рис.31) статус документа «Акт выполненных работ» устанавливается с помощью термина «Подписанный». |
| Набор объектов |  | Используется для отображения на диаграмме наборов объектов, сопровождающих выполнение функции. Внутри блока помещается наименование набора объектов. |
| Прочее | Используется для отображения на диаграмме потоков объектов, которые нельзя отнести ни к одной из предопределенных групп справочника «Объекты деятельности». Внутри блока помещается наименование прочего объекта. |
Команды панели инструментов для диаграммы EPC
Палитра элементов диаграммы EPC
Вертикальная палитра элементов, предназначенная для добавления элементов на диаграмму EPC, разделена на 3 части.
В верхней части палитры представлены элементы: Стрелка, Процесс, Событие и три типа операторов (И, ИЛИ, Исключающее ИЛИ). Добавление Процесса или События на диаграмму создает новый элемент в соответствующем справочнике.
Средняя часть палитры предназначена для добавления Сноски и Рамки на диаграмму.
Нижняя часть палитры предназначена для добавления на диаграмму элементов, уже существующих в подгруппах справочника «Объекты деятельности», справочниках «Процессы» и «Субъекты». При нажатии на любую кнопку нижней части палитры откроется окно соответствующего справочника, и будет предложено выбрать элемент, который необходимо добавить на диаграмму. Элементы вышеперечисленных классов могут быть также добавлены на диаграмму из Навигатора.
Типы связей, которые могут быть наведены между элементами на диаграмме EPC, перечислены в справочнике «Типы связей». Дополнительно к возможности показывать/убирать наименования типов связей на диаграмме с помощью кнопки в справочнике «Типы связей» существует возможность установить показ наименования того или иного типа связи на всех диаграммах, где эта связь установлена. Для этого необходимо проставить галочку у параметра «Видимость типа связи» для данной связи (Рис.32):
Рис.32 Управление показом наименования типа связи на всех диаграммах
Правила моделирования нотации EPC
1. Диаграмма функции EPC должна начинаться как минимум одним стартовым событием (стартовое событие может следовать за интерфейсом процесса) и завершаться как минимум одним конечным событием (конечное событие может предшествовать интерфейсу процесса).
2. События и функции по ходу выполнения процесса должны чередоваться. Решения о дальнейшем ходе выполнения процесса принимаются функциями.
3. На диаграмме функции располагаются сверху вниз в соответствии с временной последовательностью их выполнения.
4. Рекомендуемое количество функций на диаграмме – не более 20. Если количество функций получается значительно выше, то существует вероятность, что неправильно выделены процессы на верхнем уровне и необходимо произвести корректировку модели.
5. События и функции должны содержать строго по одной входящей и одной исходящей связи, отражающей ход выполнения процесса.
6. События и операторы, окружавшие функцию на вышележащей диаграмме (Рис.33 ), должны быть начальными/ результирующими событиями и операторами на диаграмме декомпозиции функции (Рис.34 ). Стартовые события могут следовать за интерфейсами процесса, конечные события могут предшествовать интерфейсам процесса.
Рис.33 – Диаграмма процесса, на которой встречается Функция 1
Рис.34 – Диаграмма декомпозиции Функции 1
7. На диаграмме не должны присутствовать объекты без единой связи.
8. Каждый оператор слияния должен обладать хотя бы двумя входящими связями и только одной исходящей, оператор разветвления – только одной входящей связью и хотя бы двумя исходящими. Операторы не могут располагать одновременно несколькими входящими и исходящими связями.
9. Если оператор обладает входящей связью от элемента «событие», то он должен обладать исходящей связью к элементу «функция» и наоборот.
10. За одиночным событием не должны следовать операторы «OR (И)» и «XOR (ИЛИ)».
11. Операторы могут объединять или разветвлять только функции или только события. Одновременное объединение/ разветвление функции и события невозможно.
12. Оператор, разветвляющий ветки, и оператор, объединяющий эти ветки, должны совпадать. Допускается также ситуация, когда оператор начала «И», оператор конца – «ИЛИ».
Примеры допустимых ситуаций (Рис.35 , Рис.36 , Рис.37 , Рис.38 ):
Рис.35
Рис.36
Рис.37
Рис.38
Пример недопустимой ситуации (
