Диаграмма, описанная в нотации EPC, представляет собой упорядоченную комбинацию событий и функций. Для каждой функции могут быть определены начальное и конечное события, ответственные исполнители, материальные и документальные потоки, сопровождающие её, а также проведена декомпозиция на более низкие уровни.

На Рис. 4.7.1 показан пример диаграммы процесса в нотации ЕРС (Event-Driven Process Chain).

На диаграмме процесса в нотации EPC при нажатой кнопке на панели диаграммы процессы нумеруются автоматически сверху вниз. При этом изменение положения процесса на диаграмме изменяет порядок в Навигаторе. Если кнопка не нажата, номера процессов зависят от расположения процессов в Навигаторе и могут определяться пользователем с помощью кнопок « Переместить выше» и « Переместить ниже» контекстного меню Навигатора системы (см. п. «Панель инструментов и контекстное меню Навигатора»). В случае если подпроцессы текущего процесса EPC были созданы в дереве Навигатора, то при первом открытии диаграммы они будут расставлены системой сверху вниз.

В нотации EPC ветвление стрелок осуществляется с использованием Операторов.

Для всех элементов диаграммы можно выбрать другой элемент из справочника с помощью пункта контекстного меню «Сменить объект». Для функции в этом случае будет создан процесс-ссылка на выбранный типовой процесс.

При переименовании субъекта или объекта деятельности на диаграмме ЕРС новое название может совпасть с названием элемента, уже существующего в соответствующем справочнике. При этом дальнейшая работа программы аналогична ситуации, возникающей при переименовании субъекта на диаграмме Процедуры (см. п. 4.6.2 «Работа с диаграммой процесса в нотации «Процедура»).

Таблица 4.7.1 Панель инструментов диаграммы нотации EPC

Кнопка	Назначение
	Удалить тип связи по умолчанию. Открывает окно с перечнем заданных пользователем умолчаний типов связей для выбора типов, подлежащих удалению. Подробнее см. п. «Создание связей» ниже.
	Показать/убрать все типы связей на диаграмме. Управляет отображением названий типов связей на стрелках. Подробнее см. п. «Создание связей» ниже.
	Автоматическое обновление номеров процессов. Если кнопка нажата, то будет выполняться автообновление номеров процессов при изменении их расположения на диаграмме относительно других процессов. Если кнопка не нажата, номера процессов зависят от расположения процессов в Навигаторе и могут определяться пользователем с помощью кнопок « Переместить выше» и « Переместить ниже» контекстного меню Навигатора системы (см. п. «Панель инструментов и контекстное меню Навигатора»). По умолчанию кнопка нажата для всех новых диаграмм.
	Перенести контекст функции с вышележащей диаграммы. На диаграмме будут созданы все элементы, связанные с декомпозируемой функцией на вышележащей диаграмме. Подробнее см. п. «Контекст функции» ниже.
	Запуск имитации. Открывается окно статистики имитаций. Подробнее см. п. 7.3.

Модель процесса представляет собой взаимоувязанную интегрированную совокупность функциональной, поведенческой, информационной и организационной перспектив, однако многие модели, используемые сегодня в практике реинжиниринга, этому не удовлетворяют.

12.10.2011 Игорь Федоров

Модель процесса представляет собой взаимоувязанную интегрированную совокупность функциональной, поведенческой, информационной и организационной перспектив, однако многие модели, используемые сегодня в практике реинжиниринга, не удовлетворяют требованиям, предъявляемым к процессным моделям, и не могут называться процессными, поскольку дают неполное представление об объекте моделирования и не содержат всей информации, необходимой для создания исполняемой модели.

Cпоры о выборе нотации для моделирования бизнес-процессов по-прежнему не утихают. Анализу подвергаются возможности нотаций EPC (Event-driven Process Chains) и BPMN (Business Process Modeling Notation), синтаксис, набор примитивов языка описания и т. д. Однако сравнивать нотации и языки описания бизнес-процесса путем анализа их функциональности некорректно - является ли модель функциональной или процессной, определяет не только нотация, но и методология. Часто методология моделирования подменяется нотацией, что приводит к серьезным ошибкам в проектировании бизнес-процессов и появлению некачественных моделей.

Модели и перспективы

Модель - это материальное или мысленное представление объекта или явления, повторяющее одни свойства, существенные для целей конкретного моделирования, и опускающее другие, несущественные свойства, в которых модель может отличаться от прототипа. Сложный объект, например бизнес-процесс, описывается совокупностью моделей, каждая из которых отображает ограниченный набор свойств, а все вместе они описывают объект моделирования полностью. Каждая из частных моделей связана с главным вопросом, на который должна давать ответ соответствующая модель. Выделяются четыре перспективы модели бизнес-процесса (см. рисунок).

Функциональная: «Что делают участники?». Описывает состав выполняемых работ.

Поведенческая: «Как работают участники?». Описывает очередность, расписание выполнения, бизнес-правила.

Информационная: «Что обрабатывают участники?». Описывает бизнес-сущности предметной области процесса.

Организационная: «Кто выполняет работу?». Описывает состав и структуру исполнителей.

Модель, описывающая какую-то перспективу, отвечает на несколько вопросов, но среди них всегда есть главный, на который модель должна дать исчерпывающий ответ, а на дополнительные может полностью не отвечать. В последнем случае надо быть особенно внимательным, перспектива модели определяется именно главным вопросом, а не вспомогательным.

Функциональная перспектива

Функциональная модель описывает систему в статическом состоянии, помогает ответить на вопрос «что надо делать для достижения поставленной цели?». Ответом является перечень всех действий, которые необходимо выполнить, чтобы добиться запланированного результата. В управлении проектами широко применяется структурная декомпозиция работ (Work Breakdown Structure) - перечисленные в ней действия не связаны временной последовательностью. Аналогично, при моделировании процессов очень полезно создать структурную декомпозицию, которая поможет понять логику процесса и не забыть выполнить какую-либо важную функцию. Если две разные организации выполняют один и тот же процесс, то функциональная декомпозиция работ у них будет одинаковой, хотя очередность исполнения работ может меняться с учетом отличий их организационной структуры. Таким образом, функциональная модель слабо зависит от организационной структуры и может рассматриваться как справочная.

Часто функциональную модель ошибочно называют картой процессов; например, модели SCOR (The Supply-Chain Operations Reference-model) и ETOM (Enhanced Telecom Operations Map) содержат иерархии функций и цепочки создания ценности, но отнюдь не процессы . Даже руководящие документы TeleManagement Forum призывают различать процесс как последовательность выполняемых действий и процесс как направление деятельности компании.

Аспекты поведенческой перспективы

Поведенческая перспектива, описывающая динамику системы, отвечает на вопрос «как работают участники?». Для ее моделирования используется диаграмма потоков управления. Основной вопрос «как?» можно разделить на три: «В какой очередности выполняются операции, образующие процесс? В какое время выполняется операция? Почему операции исполняются в заданной очередности?».

Ответ на первый вопрос дает бизнес-логика, которая представляет процедурное описание очередности исполнения работ, для ее графического отображения используется диаграмма потоков работ. Ответ на второй дает расписание исполнения процесса, определяющее, когда производится та или иная работа, время, затрачиваемое не ее исполнение, действия, предпринимаемые в случае нарушения графика исполнения. Ответ на третий вопрос дают бизнес-правила, являющиеся декларативным описанием ограничений, накладываемых на процесс.

Бизнес-логика процесса

Очередность операций, образующих процесс, принято называть бизнес-логикой, и для ее описания применяются диаграммы потоков работ (UML, EPC, ABC Flowchart - описания на базе блок-схем). Бизнес-логика содержит явные, предписывающие сведения о маршруте исполнения процесса, но лишь косвенно учитывает критерии принятия соответствующих решений.

Схема процесса включает элемент «ветвление», позволяющий направить исполнение процесса по одному из предопределенных маршрутов в соответствии с заранее заданными условиями. Ветвление есть элемент бизнес-логики, а условие, по которому осуществляется ветвление, есть бизнес-правило. Часто бизнес-аналитики не разделяют логику и правила и размещают на диаграмме элемент «ветвление», но опускают связанное с ним правило ветвления.

Диаграммы, описывающие бизнес-логику, визуально кажутся простыми и понятными, поскольку не включают бизнес-правила, график исполнения, корректирующие действия, выполняемые, когда показатели процесса выходят за рамки допустимых диапазонов, поэтому многие аналитики используют их для согласования с представителями бизнеса. Однако простота обманчива - разработчикам ИТ-систем приходится повторно собирать пропущенные сведения, причем их представление о процессе может сильно отличаться от взглядов аналитика. В результате модель не в полной мере описывает процесс, детали явно не фиксируются, а существуют лишь в головах программистов. Как следствие, модель процесса на бумаге не соответствует логике работы ИТ-системы - именно эти неточности исходного описания бизнес-процесса приводят к многочисленным доработкам, которые возникают на этапе внедрения информационных систем.

Бизнес-правила

Под бизнес-правилом принято понимать утверждение, определяющее или ограничивающее некоторые аспекты бизнеса. В отличие от процедурного описания, правила постулируют ограничения на исполнение процесса, но не определяют, как именно предполагается достичь результата. Специалист в области бизнес-правил Рональд Росс дает следующую классификацию бизнес-правил :

• правила поведения определяют необходимость выполнить соответствующее действие и осуществить управляющее воздействие;
• правила определения устанавливают критерий применимости какого-либо бизнес-понятия, называемого фактом;
• правила вычисления помогают узнать значения искомых величин, называемых фактами; например, торговая скидка может определяться общим объемом закупок за определенный период, и т.д.;
• правила классификации помогают проверить истинность фактов; например, клиент считается VIP, если на его счете имеется определенная сумма и он не имел задолженности по платежам.

Ветвление процесса осуществляется на основе правила поведения, переключающего маршруты в соответствии со значением аргумента, принимающего значения «истинно» или «ложно», но что есть «истинно», а что есть «ложно», определяется правилом классификации, которое, в свою очередь, должно получить на вход некоторое значение, полученное с использованием правила вычисления. Например, представим такую последовательность действий: вычислить величину скидки как функцию от размера текущего заказа (правило вычисления); классифицировать размер скидки: большая, средняя, низкая (правило классификации); отправить сделку на одобрение руководителю с соответствующим уровнем полномочий (правило поведения). Однако получила распространение порочная практика размещения на схеме элемента «ветвление» с включением прямо в него и правила поведения, и правила определения, что делает схему негибкой, а описание неполным. Итак, следует явно выделять все правила в отдельные конструкции на диаграмме потоков работ, что поможет аналитику четко локализовать соответствующую логику.

Расписание исполнения

В области материального производства широко применяется график выполнения работ, используемый для расчета времени, затрачиваемого на производство изделия. Для бизнес-процессов расписание работ имеет более сложный вид, поскольку каждая операция может исполняться вовремя, а весь процесс - с опозданием, из-за возвратов назад на повторную обработку.

Онтология времени, используемая для описания бизнес-процессов, содержит два базовых понятия: события и интервалы . Под событием понимается точка на шкале времени, не имеющая длительности. События используются для координации исполнения разных процессов или ветвей одного процесса. Под интервалом понимается отрезок на шкале времени, заключенный между начальным и конечным событиями. Интервалы позволяют определить лимит времени, отводимый на исполнение отдельной операции или группы операций.

Сравнивая нотации моделирования бизнес-процессов, следует проанализировать, оперируют ли они базовыми понятиями «событие» и «интервал времени». Это помогает понять, позволяет ли нотация моделировать временные характеристики процесса, координировать исполнение процессов и их ветвей. Наши наблюдения показывают, что многие нотации моделирования бизнес-процессов не используют эти базовые понятия.

Степень детализации бизнес-логики

Чтобы ответить на вопрос «как?», диаграмма управления должна содержать максимально подробное описание действий, образующих процесс. Многие аналитики ограничиваются перечислением функций, без указания деталей их исполнения, предполагая, что исполнитель знает, как следует выполнить работу. Однако на практике сотрудники склонны выполнять работу с учетом своего индивидуального опыта, что приводит к высокой вариативности исполнения процесса. Нотации моделирования не определяют степени детализации описания, отдавая этот вопрос на откуп аналитику. Определим критерии детализации.

Руководящий документ Госстандарта России, «Методология функционального моделирования IDEF0» вводит понятия «действие» и «операция». Действие определяется как «преобразование какого-либо свойства материального или информационного объекта в другое свойство», а операция - как «совокупность последовательно или/и параллельно выполняемых действий».

Уточним эти определения для случая моделирования процессов. Действием будем называть работу, выполняемую участником над объектом процесса, изменяющую этот объект, но не приводящую к смене его состояния; например, участник ввел новые данные, но это не означает окончания обработки заявки. Операцией будем называть совокупность действий, приводящую к изменению состояния объекта; например, после выполнения всех проверок заявка может быть одобрена.

Диаграмма потоков работ обычно ограничивается уровнем операций. Считается, что излишняя детализация затрудняет понимание логики процесса. Диаграмма управления должна давать исчерпывающий ответ на вопрос о том, как исполняется процесс, иметь детализацию уровня действий. Как следствие, такие диаграммы оказываются излишне подробными, рискуют оказаться перегруженными деталями. Впрочем, это скорее вопрос стиля моделирования - многоуровневые структурированные модели могут сочетать в себе простоту бизнес-логики на верхнем уровне диаграммы и детальную подробность описания отдельных действий на нижнем.

Степень полноты бизнес-логики процесса

Большинство диаграмм потоков работ описывают ограниченный набор сценариев исполнения, определяя только наиболее очевидные маршруты. Они не включают редко исполняемые сценарии, оставляют вне внимания особые и исключительные ситуации. Такое неполное описание исполнения имеет право на существование, когда планируется разработать функциональную информационную систему, где человек определяет порядок исполнения операций. Однако при построении процессно-ориентированной системы порядок операций определяется самой системой, следовательно, модель должна покрывать все возможные сценарии исполнения, включая возвраты управления на предыдущий шаг или обгоняющие переходы, обходящие определенные шаги обработки, учитывать возможность эскалации проблемы, обработку исключительных ситуаций, иначе работа системы окажется невозможной.

Сравнительный анализ нотаций EPC и BPMN

Мы показали, что следует различать диаграммы потоков работ, потоков управления и модель процесса. Диаграмма потоков работ определяет бизнес-логику, очередность исполнения операций, имеет детализацию уровня операций, не включает расписание исполнения процесса и может не полностью определять бизнес-правила процесса. Диаграмма потоков управления уточняет диаграмму потоков работ в части расписания исполнения и бизнес-правил, имеет детализацию уровня действий, должна описывать все варианты исполнения, иначе говоря, она описывает технологию, гарантирующую достижение запланированного результата в случае точного выполнения заранее определенного набора действий. В отсутствие хотя бы одного компонента описание окажется неполным, технология не будет соблюдена. Модель процесса есть совокупность взаимоувязанных перспектив, каждая из которых описывает отдельные аспекты поведения процесса, а все вместе они образуют интегрированное, комплексное и полное представление о процессе и его исполнении. В том числе диаграмма потоков управления описывает поведенческую перспективу модели бизнес-процесса.

Нотация EPC является средством описания бизнес-логики процесса. Как показывает сравнение , нотация позволяет реализовывать основные паттерны бизнес-логики, не уступая остальным нотациям описания процессов. Диаграммы EPC часто не включают бизнес-правила, однако этот недостаток следует отнести не к нотации, как таковой, а к методологии применения. Что касается расписания исполнения, то тут надо отметить отсутствие средств моделирования временных характеристик исполнения. В нотации EPC присутствует конструкция «событие», однако она применяется для описания состояния объекта управления, а не для синхронизации исполнения. Методология EPC не акцентирует внимание на степени детальности и полноты получаемых диаграмм, оставляя этот вопрос на откуп аналитику. В отсутствие жесткой регламентации аналитики стремятся обеспечить простоту и читабельность диаграмм, поэтому ограничиваются описанием уровня операций и не стремятся выявить все маршруты исполнения. Нотация EPC часто используется для автоматизации с применением функционально-ориентированных систем, где человек играет ведущую, направляющую роль, так что отсутствие какого-либо сценария исполнения не является опасным. Все это позволяет классифицировать модели EPC как диаграмму потоков работ.

Нотации, включенные в ARIS, обладают чрезвычайно широкими возможностями по моделированию процессов, но не подкреплены открытыми и доступными для пользователей методологиями. Документ «Методология ARIS» описывает не методологию, а правила применения нотации, что допускает широкие возможности «интерпретации» способов моделирования.

Проблема EPC связана с попыткой приспособить этот инструмент для решения слишком широкого круга задач, без объяснения правил применения для конкретного случая. Как результат, аналитики применяют многие конструкции и механизмы интуитивно и неосознанно. Иногда их замысел удается понять из контекста задачи, но вряд ли современный компьютер сможет сам проанализировать контекст в ходе преобразования диаграммы в исполняемый формат.

Нотация BPMN описывает логику процесса. Немного лучшая поддержка паттернов бизнес-логики, по сравнению с EPC , не является решающим преимуществом. Нотация оперирует понятиями «событие» и «интервал времени», содержит средства синхронизации веток процесса между собой и процессов друг с другом. Сама нотация не содержит рекомендаций разделять логику и правила, но руководства по правильному стилю моделирования включают такую рекомендацию . Нотация BPMN применяется для создания процессно-ориентированных систем, где человек играет подчиненную, а система - ведущую роль, поэтому пропуск одного, даже самого редкого сценария не позволит выполнить работу и, следовательно, недопустим, соответственно модели BPMN покрывают все сценарии исполнения. Модели BPMN являются исполняемыми моделями, поэтому описывают все детали, вплоть до элементарных действий. Все вышесказанное позволяет классифицировать диаграмму BPMN как модель потоков управления.

Проблемы нотации BPMN связаны с тем, что схемы, как правило, оказываются перегруженными деталями и подробностями, потому трудночитаемыми. Выход видится в разработке методики построения иерархических многоуровневых моделей, где верхний уровень описывает контекст исполнения всего процесса, средний - логику исполнения, а нижний уровень - детали реализации отдельных операций.

Интерес к BPM и BPMS (Business Process Management Suite) достиг той степени зрелости, когда уже не приходится говорить о моде. Кроме этого, закончилась война стандартов и нотация BPMN получила признание всех крупных игроков, став стандартом де-факто. Это событие по значимости можно сравнить с появлением SQL, ставшего основой современных информационных систем.

BPMS окончательно сформировался как класс программного обеспечения для поддержки графического моделирования бизнес-процессов, исполнения модели бизнеспроцессов, мониторинга и анализа (Business Activity Monitoring, BAM). Однако разные продукты реализуют эту функциональность по-разному, и при выборе конкретной BPMS в первую очередь следует обращать внимание на следующее.

• Поддержка BPMN. Какая версия BPMN поддерживается (1.x или 2.0)? Насколько полна реализация: поддерживаются ли сообщения, сигналы, транзакционные подпроцессы?

• Тип процессного движка BPMN. Непосредственное исполнение предпочтительнее трансляции в какое-либо другое представление – только в этом случае удается на практике реализовать непрерывное усовершенствование бизнес-процессов.
• Связь между процессами и данными. Предпочтительнее хранение атрибутов про
цесса в максимально открытом виде – в таблицах и столбцах реляционной СУБД, что обеспечивает ссылочную целостность, высокие оперативные характеристики и свободу доступа к данным извне, в противоположность, например, хранению атрибутов в виде XML-строки.
• Пользовательский интерфейс. Интерфейс должен быть функциональным, эргономичными
и разрабатываться быстро, повозможности без программирования. Система должна позволять силами бизнес-аналитика создавать работающий пользовательский интерфейс, который при желании можно доработать уже с привлечением программиста.
• Системная платформа. В зависимости от технической политики компании выбор
может быть ограничен платформой Java или. Net – BPMS, поддерживающие обе платформы, являются редкостью.
• Схема лицензирования. Условно-бесплатные системы позволяют сэкономить на ли
цензии, но требуют больших ресурсов на разработку; некоторые коммерческие системы требуют значительных затрат даже в минимальной конфигурации.
• Наличие представительства или партнера в России.

Не следует забывать, что BPMS – это только одна из составляющих BPM, и для успеха проекта создания системы управления бизнес-процессами необходимы также компетенции в методологии и в управлении agile-проектами.

Анатолий Белайчук ([email protected]) – президент компании «Бизнес-Консоль» (Москва).

Проблемы трансляции диаграммы EPC в исполняемый формат

Результаты моделирования в нотации EPC не всегда приводят к созданию модели, которая без существенных переделок может быть конвертирована в исполняемый формат BPM.

Перечислим типовые ошибки моделирования.

У начинающих аналитиков модель EPC описывает наиболее вероятный вариант исполнения, опуская редко используемые альтернативные маршруты: на их схемах редко встретишь описания действий в нестандартных и исключительных ситуациях.

Очень часто модели не в полной мере фиксируют все критерии принятия решения. Как следствие, модель приходится повторно дорабатывать с целью уточнения бизнес-правил.

Аналитики не обращают внимание на изменение объекта управления процесса. Представим себе описание технологического процесса, включающего изготовление комплектующих. Если комплектующие производятся под заказ, то можно включить описание их изготовления в основной процесс, но если комплектующие производятся асинхронно к основной детали, то их производство должно быть отдельным процессом со своим объектом управления. Аналитик должен тщательно следить за объектом управления процессом, так как его смена является признаком возможного разделения сквозного процесса на цепочку взаимодействующих процессов.

Недостаточная степень детализации процесса приводит к необходимости повторного уточнения и описания упущенных деталей на этапе подготовки требований к разрабатываемой ИТ-системе.

Диаграммы EPC не описывают расписания исполнения, опускают вопросы синхронизации ветвей одного процесса между собой и с другими, внешним процессами.

Таким образом, можно сказать, что проблемы EPC лежат в области методологии ее применения, и при наличии соглашения о моделировании, которое бы определяло все детали разрабатываемой модели, большинства проблем, за исключением временных параметров исполнения, удалось бы избежать.

Не нотация, а методология определяет, является ли модель функциональной или процессной. Модель процесса есть многослойное описание, включающее взаимоувязанные описания функциональной, поведенческой, информационной и организационной перспектив. Для описания поведенческой перспективы следует использовать диаграмму потока управления, которая дает исчерпывающий ответ на вопрос «как исполняется процесс?», и в том числе определяет последовательность операций, бизнес-правила, расписание исполнения, имеет детализацию уровня действий и описывает все возможные сценарии исполнения. Диаграмма потоков работ, которую необоснованно называют моделью процесса, не описывает всех деталей поведения процесса и не является процессной диаграммой.

Многие модели, которые используются в практике реинжиниринга, не удовлетворяют всем перечисленным требованиям и потому не могут называться процессными. Возникает вопрос: может быть, именно в этом кроется неудача этих проектов реинжиниринга бизнес-процессов?

Литература

1. B. Curtis, M. Kellner, J. Over. Process Modeling, 1992.
2. eTOM, Representative process flows. ITU. s.l.: Telecommunication Standardization Sector Of ITU, 2004.
3. R. Ross. Principles of the Business Rule Approach. Addison-Wesley Professional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. A Core Ontology for Business Process Analysis, Proceedings of the 5th European semantic web conference on The semantic web: research and applications, Springer-Verlag Berlin, Heidelberg, 2008.
5. Методология функционального моделирования IDEF0. Москва: Госстандарт России, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Workflow control-flow patterns.
7. Methods ARIS 7.0. Saarbrucken: IDS Scheer AG, 2005.
8. B. Silver, BPMN Method & Style. Cody-Cassidy Press, 2009.

Игорь Федоров ([email protected]) – директор Центра компетенции процессного управления МЭСИ (Москва).

Моделирование бизнес-процессов, перспектива моделирования, функциональное и процессное моделирование

Event-driven process chain.

Цель EPC - это планирование и описание потоков работ, нижнего (операционного) уровня, бизнес-процессов. Основные элементы для построения диаграмм выступают события и функции. Бизнес-процессы, в диаграмме EPC, изображаются как последовательности чередующихся событий и функций.

Область применения EPC

Диаграмма EPC является стандартизированной графической диаграммой для моделирования бизнес-процессов, применима для:

• Составления моделей и документирование бизнес процессов как есть (as is)
• Описание возможных усовершенствований существующих бизнес процессов как будет (to be)
• Выявление всех участников процесса
• Выявление всех информационных систем, ресурсов и документов участвующих в процессе

Чтобы лучше получить представление о диаграмме EPC советуем посетить ссылки:

• Введение в EPC

  Ссылка ведет на введение в EPC. Советуем посетить ссылку в первую очередь.

• Элементы и структура построения диаграмм EPC

  Ссылка ведет на описание где представлены самые важные графические элементы диаграммы. Представление элементов и их использование отлично структурированно, Вам будет очень удобно ориентироваться.

• Примеры правил построения EPC диаграмм

  Ссылка ведет на документ где описаны примеры построения диаграмм. P.S. В данном случае нас интересует только информация, представленная в четвертой главе с 86 страницы.

Прочие полезные материалы:

• Ссылка ведет на сборник учебных материалов по методологии ARIS.

Стандарт EPC

EPC (Event-Driven Process Chain, событийная цепочка процессов) - нотация отображения хода выполнения процесса, ключевыми элементами которой являются События и Функции. Нотация EPC была разработана в 90х годах XX века. EPC придумал немецкий профессор Вильгельм-Август Шеер в рамках методологии ARIS.

Диаграмма бизнес-процесса в EPC должна начинаться и заканчиваться Событием. За Функцией всегда должно следовать Событие, т. е., выполнение Функции создает некоторое событие (состояние). Документы, организационные звенья, информационные и материальные потоки, элементы информационной системы (программное обеспечение, базы данных) имеют свое графическое обозначение. Для ветвления процесса используются операторы И, ИЛИ, исключающее ИЛИ.

EPC используется на низших уровнях описания бизнес-модели, когда стоит задача описать подробный ход выполнения бизнес-процесса. Функции EPC могут быть декомпозированы (разбиты на детальные бизнес-процессы только в нотации EPC).

К недостаткам EPC можно отнести то, что эта нотация обладает очень широким набором графических элементов, что может быть сложным для понимания, по сравнению с другими нотациями. Для разработки процессов в этой нотации и их чтения требуется предварительная подготовка сотрудников.

К преимуществам EPC относится возможность очень детально и точно описать выполнение бизнес-процесса, показать на диаграмме в графическом виде всех исполнителей, все используемые объекты. Также плюсом EPC-диаграмм является тот факт, что, как и на диаграммах IDEF0, на них можно указать входные и выходные данные каждой функции, проследить логику передвижения входных и выходных данных от блока к блоку. К тому же, в отличие от всё той же IDEF0, появилась возможность распараллеливать процесс, направляя его только по одной из альтернативных веток (в IDEF0 если и добавляем параллельность в выполнении, то все параллельные функции будут при этом выполняться одновременно). Достоинством также мне показалась возможность указать исполнителя по каждому этапу (читай: функции). Но, в IDEF0 исполнитель указан на каждом уровне декомпозиции единожды, и от его имени тянутся стрелки ко всем исполняемым им блокам. В EPC, чтобы подсчитать, какое количество действий выполняет исполнитель, нужно пробежаться по всем блокам действия и проверять, указан ли по нему нужный нам исполнитель.

Эта нотация оказалась очень привлекательной с позиций осуществления контроля выполнения процесса - каждая функция непременно переводит в систему в новое состояние, из чего следует, что после выполнения каждой функции систему можно проверить, действительно ли переход в нужное состояние был осуществлён.

В целом нотация EPC является признанной во всем мире как одна из лучших нотаций для построения бизнес-процессов и моделирования работы предприятия.

Выбор метода моделирования

Для моделирования необходимого бизнес-процесса была выбрана методология BPMN. Этот выбор обусловлен тем, что нотация BPMN позволяет наиболее точно отобразить логические процессы, происходящие при выполнении задач, требующих с высокой точностью описать последовательность действий, продемонстрировать взаимодействие сотрудников и клиента, а также позволяет показать временной разрыв между выполнением некоторых задач.

Специализация ГК Абажур — выполнение разноплановых проектов строительства на основе ЕРС/ЕРСМ контрактов… Но для тех, кто в поиске и еще не знает что такое ЕРС и ЕРСМ, предлагаем сборник материалов, которые, как мы надеемся, послужат подспорьем для наших Партнеров и клиентов при работе с такими сравнительно новыми для отечественной практики инструментами, как ЕРС-, ЕРС(М)-контракты.

Структурирование, заключение и исполнение ЕРС и ЕРС(М) контрактов

ГК Абажур специализируется на выполнении разноплановых проектов строительства на основе ЕРС/ЕРСМ контрактов , а также других строительных контрактов с индивидуальными условиями. , применяет системные решения в строительстве с использованием 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% реализуемых проектов.

Более подробно читаем публикацию, подготовленную .

В случае возникновения вопросов или комментариев Вы можете — все они будут с благодарностью рассмотрены.