Организация бизнес-процессов. Организация бизнеспроцессов

• Название: Организация бизнеспроцессов
• Дата: 06.03.2023
• Размер: 1.34 Mb.
• Имя файла: Организация бизнес-процессов.docx
• Тип: Лекции; #971698

Тема лекции: Организация бизнес-процессов

1. Введение

Существует несколько определений понятия бизнес-процесса (в русской транскрипции операционный процесс фирмы) приведём наиболее часто встречающиеся. Итак, бизнес-процесс это:

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

Таким образом, эти определения дают нам понимание о 3-х характеристиках бизнес-процесса: 1. Стоимость - она стремится к минимальной величине.

2. Длительность - она стремится к максимальной скорости реализации процесса.

3. Степень удовлетворённости клиента (качество продукта).

Теперь немного истории. Послевоенная разруха в Японии, борьба за рынки сбыта методом повышения качества товаров способствовала появлению термина Total Quality Management (TQM). Типичная оценка операций до 80-х гг.: "Все операционные процессы, используемые японской автомобильной промышленностью нам хорошо известны - их успех зиждется на экономике масштабов, на развитом внутреннем рынке, особом отношении рабочих к своему труду, а также на способности эффективнее контролировать инфляцию" (Форд, август 1978г.). 80-90-ые успехи японцев, особенно автомобильной промышленности, не дают покоя американцам. Этому противостоянию обязано появление методики IDEF, позволяющей анализировать бизнес с точки зрения функциональности системы и представляющей в виде набора элементов-работ, которые взаимодействуют между собой. На базе этой методики создаются стандарты серии ISO 9000, 9001 и вот здесь появляется Business Process Reengineering (BPR). Новый взгляд на японское чудо: "Многие объясняют успехи японцев в снижении себестоимости производства и достижении высочайшего уровня качества высокой степенью автоматизации, политикой государственной поддержки, а также особенностями национальной культуры. Вне сомнения, указанные факторы сыграли важную роль, однако первичным источником мирового лидерства стала эффективная реализация глубоко продуманной стратегии, основанной на высочайшей культуре производства, включающей низкую себестоимость и высокое качество, стали результатом успехов в стратегическом управлении людьми, материалами и о борудованием." (Форд, октябрь 1993г.). Как видно, появилось ещё одно понятия бизнес-процесса.

2. Жизненный цикл бизнес-процесса

Бизнес-процессы – это основа любой успешной компании. Эти процессы объединяют системы, партнеров и сотрудников для достижения ключевых стратегических и тактических целей. Возрастающее число компаний присматриваются к Web-сервисам и сервис-ориентированной архитектуре (Service Oriented Architecture, SOA) для решения проблем интеграции, возникающих при соединении приложений. BPEL и другие стандарты в области Web-сервисов предлагают открытый, переносимый и стандартизованный способ решения типичных проблем развития приложений. Они позволяют создавать решения на базе SOA, которые обеспечивают гибкость бизнеса при максимальном использовании уже задействованных ресурсов и минимизации стоимости развертывания новых приложений.

Жизненный цикл процесса (см. рис. 2.1) состоит из следующих шагов или задач:



Рис. 2.1 BPM-решение полного цикла

• 
  Моделирование процесса (Model the process) – во время этого шага владельцы бизнес-процессов создают высокоуровневую модель, состоящую из задач, которые должны выполняться, и нужных для этого ресурсов. Кроме того, делаются некоторые предположения о времени выполнения и стоимости каждой задачи.
  
• 
  Имитация и анализ (Simulate and Analyze) — полученная высокоуровневая модель используется для “прогона” некоторых гипотетических сценариев с целью обнаружения критических участков (paths) и “узких горлышек” (bottlenecks). Полученная информация применяется для тонкой настройки процесса перед его развертыванием.
  
• 
  Внедрение и документирование (Implement and document) — во время этого шага высокоуровневый бизнес-процесс, точнее его описание высокого уровня, преобразуется в модель исполняемого процесса. Сам же процесс документируется для того, чтобы он мог использоваться для обучения и сопровождения в будущем.
  
• 
  Развертывание и исполнение (Deploy and Execute) – этот шаг включает развертывание процесса для BPM-“движка” (BPM-engine) и его исполнение для реализации сквозных (end to end) потоков [управления и данных] между системами и людьми.
  
• 
  Мониторинг (Monitor) – во время этого шага происходит мониторинг бизнес-процессов с целью получения ключевых индикаторов эффективности и других метрик. Это шаг выполняется, как правило, с применением средства мониторинга бизнес-активности (Business Activity monitoring tool) совместно с BPM-“движком”.
  
• 
  Оптимизация и перепроектирование (Optimize and Redesign) – после того, как над системой в течение некоторого времени проведен мониторинг, полученные за это время метрики (historical metrics) могут быть использованы для дальнейшей оптимизации процесса. Реальная пропускная способность процесса и метрики использования могут быть введены в инструмент имитации, чтобы получить оптимальную исполнительную модель.
  

Рассмотрим теперь каждый шаг более подробно.

2.1 Моделирование процессов с применением bpmn

В качестве стандарта для моделирования бизнес-процессов получает признание BPMN (Business Process Modeling Notation - нотация моделирования бизнес-процессов), разработанная организацией Business Process Modeling Initiative (BPME.org).

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

BPMN напрямую отображается на языки исполнения бизнес-процессов, такие как BPEL и BPML. BPMN предоставляет нотацию для моделирования, а BPEL является языком описания исполнения процессов.

К ключевым особенностям BPMN относятся:

• 
  Пулы и лейны (Pools and lanes - бассейны и дорожки) — эти сущности используются для демаркации процессов и систем. (Демаркация – выяснение, какие из процессов и систем используются, а какие нет). Пул используется, чтобы разделить различные бизнес-сущности или участников. Действия (activities) внутри пулов – это модульные (self-contained) процессы. Лейны (Lanes) используются для описания и разделения действий в пулах по функциям или ролям.
  
• 
  События и действия (Events and activities) — События используются для представления того, что происходит в процессе бизнес-деятельности. У этих событий обычно есть причины/эффекты (следствия), и они могут влиять на сам поток данных. Действия ссылаются на работу, которая исполняется, либо как единая задача, либо как набор задач.
  
• 
  Соединенные объекты (Connect objects) — различные сущности BPMN могут быть соединены через последовательность операций; поток операций (sequence flow), чтобы отметить порядок, в котором выполняются действия; поток сообщений, чтобы отметить сообщения между сущностями или через ассоциацию, используемую для ассоциирования текста с объектами потока данных (flow objects).
  
• 
  Проектирование сложного процесса (Complex process design) - BPMN может использоваться, как для высокоуровневого описания процессов, так и для описания сложных процессов со многими уровнями детализации. Процессы могут включать детализирующие представления (drill down views) для описания деталей более низкого уровня (lower levels of detail) внутри отдельных диаграмм.
  
• 
  Моделирование и контроль сообщений (Model message and control) — в дополнение к спецификации порядка операций в потоке BPMN обеспечивает представление об объектах данных для моделирования того, как документы, данные и другие объекты используются и изменяются во время процессного потока.
  

2.2 Имитация и анализ

Для выполнения имитации во время этого этапа жизненного цикла процесса должны быть сделаны следующие оценки:

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

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

• 
  Вычислить среднее (average elapsed) время транзакции, полную, от начала до конца (end-to-end) пропускную способность и стандартные отклонения (deviation) для определения того, насколько эти отклонения соответствуют допустимым по соглашениям об уровне обслуживания SLA (Service Level Agreements);
  
• 
  Идентифицировать “узкие места” при использовании процесса и ресурсов;
  
• 
  Определить количественно человеческие и другие ресурсы, необходимые для завершения задач, чтобы соответствовать заданным SLA;
  
• 
  Вычислить ожидаемые оценки ошибок и рейтинги уровней обслуживания;
  

Определение оптимизации, необходимой для перехода процесса на уровень “как должно быть”.

2.3 Документирование и внедрение

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

Следующий после документирования шаг – это внедрение бизнес-процессов.

Наиболее распространенным инструментом для этого является BPEL (Business Process Execution Language) - язык выполнения бизнес-процессов. С одной стороны, BPEL - это язык на основе ХМL для формального описания бизнес-процессов и протоколов взаимодействия бизнес-процессов. Но с другой, BPEL - это стандартизированная технология реализации бизнес-процессов через интеграцию информационных систем в рамках SOA и Web-сервисов. Она включает в себя язык наглядного описания бизнес-процессов, интерпретатор этого языка, средства взаимодействия с системами (адаптеры), средства мониторинга, отладки и сбора статистики. Технология имеет важную особенность - только автоматизированные, то есть происходящие в рамках информационных систем, процессы могут быть адекватно реализованы, и это отличает ее от средств проектирования бизнес-процессов общего назначения.

Реализации BPEL

Коммерческие реализации:

• 
  Oracle
  
• 
  IBM
  
• 
  Microsoft
  

OpenSource реализации:

• 
  Active BPEL www.activebpel.com
  
• 
  Apache Agila http://wiki.apache.org/agila/
  

2.4 Развертывание и исполнение

Наиболее критичным этапом в жизненном цикле процесса является его развертывание на платформе, которая может управлять потоком данных и выполнять различные задачи этого процесса. Объединение набора сервисов в сквозной поток процесса требует выполнения множества технических требований, включая соединение (binding) с разнородными системами, шаблоны для синхронного и асинхронного обмена сообщениями, манипулирование данными, координация в потоке, управление исключительными ситуациями, недетерминированные события, компенсирующие транзакции (compensating transactions), управление версиями, и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. Продукт Oracle BPEL Process Manager обеспечивает наиболее зрелую, масштабируемую и полную реализацию механизма исполнения BPEL, доступную сегодня. Архитектура данного продукта представлена на рис. 2.2.



Рис 2.2 Архитектура Oracle BPEL Process Manager и сопутствующих компонентов.

Некоторые из ключевых функций этого сервера:

• 
  Поддержка стандартов — механизм включает непосредственную поддержку стандартов BPEL и web-сервисов;
  
• 
  Производительность и масштабируемость – высокопроизводительный BPEL-механизм исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” ("dehydration"), так что состояние долгоживущих потоков автоматически поддерживается в базе данных;
  
• 
  Множество платформ развертывания - BPEL Server использует как базовый J2EE-сервер приложений с поддержкой большинства основных коммерческих серверов приложений;
  
• 
  Встроенные сервисы интеграции — они позволяют использовать возможности соединений и трансформаций из стандартного BPEL-процесса.
  
• 
  Сервис пользовательской задачи (User task service), предоставляется как встроенный BPEL-сервис для обеспечения интеграции людей и выполняемых ими вручную задач в BPEL-потоки.
  
• 
  BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console и Java API.
  

2.5 Мониторинг

Измерение ключевых метрик процессов в реальном времени исполнения процессов критичны для оценки производительности развернутых бизнес-процессов. BPEL-процессы могут быть инструментированы с датчиками (sensors), чтобы осуществлять мониторинг критических действий и переменных. Oracle Business Activity Monitoring (BAM) позволяет соединять эти индивидуальные метрики в составные события. Панель BAM (см. рис 2.3) позволяет реализовать мониторинг, анализировать и своевременно отвечать на события или исключительные ситуации, которые происходят внутри предприятия.



Рис 2.3 Панель Oracle BAM

Ключевые концепции Oracle BAM таковы:

• 
  Бизнес-события (Business Events) – перехват таких интересных событий как изменение информации о клиентах, изменения в описи товаров, заказах на покупку из друших информационных систем предприятия.
  
• 
  Составные события (Composite events) – определение, агрегирование, соотнесение и фильтрация событий от различных конечных систем.
  
• 
  Сигналы (Alerts) – уведомление пользователей через различные каналы (электронная почта, голосовая почта, пейджеры и т.д.) на основе превышения пороговых значений и/или порогов рисков для некоторых ключевых метрик.
  
• 
  Визуализация в масштабе реального времени - широкий набор средств визуализации в масштабе реального времени на BAM-панели для показа данных самых последних событий и детализации при анализе основных факторов.
  

2.6 Оптимизация и перепроектирование

BAM закрывает отсутствующее звено между исполнением процесса и перепроектированием. Традиционно имитация процессов основана на предположениях и догадках. Проблема такого подхода в том, что надежны только результаты, а предположения делались на этапе моделирования. При применении BAM, как данные реального времени, так и исторические данные, накопленные за период времени, могут быть использованы, чтобы промоделировать процесс “как есть” (“as-is”) и создать оптимальный процесс “как должно быть” ("to-be"). Благодаря таким успешным итерациям процесс может быть тонко настроен, что приведет к значительной экономии ресурсов и средств.

3. Автоматизация бизнес-процессов на примере системы "1с:Предприятие 8.0"

При создании многочисленных новшеств в 1С8 по сравнению с предыдущей версией – 1С7.7 и другими аналогичными программными системами, разработчики решали три основные взаимосвязанные задачи:

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

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

3.1 Основные сведения о механизме бизнес-процессов

Бизнес-процессы в 1СП8 нужны для того, чтобы объединять отдельные операции (выписка счета, прием наличной оплаты, отпуск товара со склада и т.д.) в цепочки взаимосвязанных действий, приводящих к достижению конкретной цели (например, продажа товара за наличный расчет). Участие сотрудников в жизненном цикле бизнес-процесса обеспечивается при помощи ролевой маршрутизации, например, по ролям, рабочим группам, подразделениям, помещениям, филиалам и т.д. Два основных объекта МБП — бизнес-процессы и задачи. Они используют друг друга, а также три вспомогательных — параметр сеанса, регистр сведений и справочники. Вспомогательные объекты не используют друг друга и основные объекты (рис. 3.1).



Рис. 3.1 Схема взаимодействия объектов механизма управления бизнес-процессами

• 
  Задача предназначена для учета заданий и описывает способ их распределения по исполнителям, с учетом организационной структуры предприятия.
  
• 
  Объект "Бизнес-процесс" описывает логику выполнения операция для достижения той или иной цели и управляет жизненным циклом созданных бизнес-процессов (экземпляров) от момента старта до момента завершения. Логика бизнес-процесса (взаимосвязь и последовательность обхода точек маршрута, условные переходы и пр.) наглядно описывается в виде карты маршрута, которая позволяет визуально описывать маршрут бизнес-процесса в виде связного графа и позволяет легко описывать алгоритмы условных переходов, и реакцию бизнес-процесса на различные события (рис. 3.2).
  

Рис. 3.2 Карта маршрута

При создании карты маршрута бизнес-процесса используются справочники с предопределенными данными (ролями, подразделениями и пр.) для установки их значений в атрибуты адресации точек маршрута. Бизнес-процессы создают задачи при переходе на точки маршрута и используют регистр сведений для обработки групповых точек. Параметр сеанса используется бизнес-процессами для интерактивной активации невыполненных задач для текущего исполнителя. Задачи сообщают бизнес-процессам о своем выполнении, чем вызывают их продвижение дальше по маршруту. Ключевым понятием в механизме бизнес-процессов и задач в 1С8 является система адресации, которая обеспечивает возможность не только персональной, но и ролевой адресации задач участникам бизнес-процессов. Ролевая маршрутизация позволяет назначать задания не только конкретным исполнителям, но и ролям, группам, подразделениям и т.д.

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

• 
  Многомерная система адресации задач исполнителям (роли, отделы, организации, группы и т.д.)
  
• 
  Визуальное проектирование карты бизнес-процесса
  
• 
  Генерация задач по исполнителям
  
• 
  Ролевая маршрутизация
  
• 
  Переход по точкам маршрута в соответствии с картой бизнес-процесса
  

3.2 Практическая реализация бизнес-процессов в системе "1с:Предприятие 8.0"

Разработка БП ведется в приложении "Конфигуратор" (рис. 3.3), исполнение — в среде прикладных решений (рис. 3.4)



Рис. 3.3 Разработка бизнес-процесса в среде "Конфигуратор"



Рис. 3.4 Исполнение бизнес-процесса в среде прикладных решений

Конфигуратор системы 1С:Предприятие предоставляет широкие возможности по созданию бизнес-процессов, логика которых задается с помощью маршрутных карт. Сказав это, нужно сделать еще одно важное замечание. Вообще говоря, программирование бизнес-процессов можно было делать и ранее в "1С:Предприятии", но только на уровне языка программирования. Новый механизм автоматизирует эту процедуру, предлагая визуальные средства проектирования, настройку программы с помощью методов параметризации и сводя к минимуму (или вовсе исключая) объем кодирования. Все это теперь реализовано на уровне платформы, которая содержит объекты метаданных и механизмы, делающие возможным единообразную реализацию бизнес-процессов в прикладных решениях. Механизм бизнес-процессов, реализованный в 1СП8 не претендует на универсальность аналогичную программам, написанным на языке BPEL(они могут исполняться в любой системе, поддерживающей необходимые стандарты), а ориентирован на реализации только в среде 1СП8 и оптимизирован для этих целей. Это частности выражается и в том, что в результате визуального проектирования БП разработчик не получает некоторую программу на исходном коде внутреннего языка 1СП8.

Пример проектирования бизнес-процесса в "1с:Предприятие 8.0"

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

Шаг 1. Словесное описание бизнес-процесса:

• 
  всем линейным руководителям — написать предложения;
  
• 
  линейный руководитель заполняет документ "предложение по графику отпусков";
  
• 
  менеджер по персоналу рассматривает — отклоняет, просит уточнить, просит пересмотреть или принимает;
  
• 
  в какой-то момент (например, когда большинство сотрудников в график попали) менеджер направляет директору;
  
• 
  если принимается, то бизнес-процесс завершен.
  

Шаг. 2. Определение адресации

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

Шаг 3. Формирование задачи

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

Шаг 4. Проектирование бизнес-процесса:

Создаем наш первый бизнес-процесс и соединяем его с только что созданной задачей. Затем приступаем к рисованию карты маршрута (рис. 3.5):



Рис. 3.5 Карта маршрута бизнес-процесса "Планирование отпусков"

• 
  точка Старт;
  
• 
  точки действия в порядке следования;
  
• 
  добавляем условные переходы;
  
• 
  точка Завершение;
  
• 
  оформляем карту.
  

Шаг 5. Добавляем формы

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

• 
  Форма предложения по графику отпусков (использует документ «Планирование Отпуска»)
  
• 
  Форма для рассмотрения всех графиков – «Форма для согласования с руководством»
  

Шаг 6. Программируем.

Для настройки условных переходов необходимо написать обработчик проверки условия на встроенном языке (рис. 3.6).



Рис. 3.6 Программная реализация отдельных блоков бизнес-процесса

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

Шаг 7. Проверка работоспособности:

• 
  создаем новый экземпляр бизнес-процесса;
  
• 
  все руководители получают задачу "Подготовить график отпусков";
  
• 
  после составления всех планов они все вместе поступают на рассмотрение кадровику в виде задачи "Рассмотреть графики";
  
• 
  по результатам рассмотрения часть из них отправляется на доработку;
  
• 
  после доработки и успешного повторного рассмотрения перед менеджером по персоналу ставится задача согласовать с директором;
  
• 
  после успешного согласования бизнес-процесс завершается.
  
• 
  Для дальнейшего улучшения этого бизнес-процесса и более тесной его интеграции с прикладным решением можно добавить к нему дополнительные возможности (потом, после разработки, т.е. уже в ходе эксплуатации)
  

Заключение

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

• 
  Обратная связь с документами. Например, чтобы при заполнении документа "График отпусков" автоматически инициировался бизнес-процесс согласования графика и соответствующая задача появлялась у менеджера по кадрам.
  
• 
  Проверка выполнения. Проверка актуальности и правильности составления графика линейными руководителями до передачи на согласование менеджеру по кадрам, например, не разрешать выполнение других задач при незаполненном графике.
  
• 
  Автоматическая сборка отдельных графиков в обобщенный. Можно предусмотреть в карте маршрута точку автоматической обработки, на которой система сама соберет все графики в общий и отправит его на согласование менеджеру по кадрам.
  
• 
  Согласование как вложенный бизнес-процесс. Сам процесс согласования можно выделить во вложенный бизнес-процесс и использовать его в дальнейшем не только в БП "Согласование отпусков", но и в других БП — например заключение договоров, выписка счетов и т.д.