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

Для администраторов

Встроенные инструменты визуального моделирования

Процесс представляется как последовательность статусов и переходов между ними – в «Первой Форме» это называется маршрутом процесса. Для создания маршрута достаточно добавить нужные статусы и затем соединить из переходами (удобнее всего делать это методом drag-and-drop).

Визуальный редактор маршрута.

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

Маршрут согласования

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

Маршрут согласования с последовательным и параллельным запросом подписей.

Маршруты бизнес-процесса могут быть любыми, от самых простых до достаточно сложных.


Пример маршрута согласования договора

Для пользователей

Лента основного маршрута

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

To properly display this page you need a browser with JavaScript support.

Управление бизнес-процессами

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

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

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

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

Платформа ELMA BPM обладает огромным количеством возможностей для управления бизнес-процессами, однако все функции системы легко могут быть поделены на четыре группы в соответствии со стадиями жизненного цикла (цикл Деминга) процесса PDCA (Plan, Do, Check, Act):

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

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

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

Рис. 1. Пример графической модели процесса

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

Что бы избежать путаницы бизнес-процесс, создаваемый в Дизайнере ELMA, называется моделью бизнес-процесса, бизнес-процессом или просто процессом. Запущенный в веб-приложении бизнес-процесс называется экземпляром бизнес-процесса или просто экземпляром процесса.

Жизненный цикл процесса применительно к платформе ELMA BPM содержит следующие стадии:

Контроль и Мониторинг исполнения экземпляров бизнес-процессов в веб-приложении. Анализ затрат на процессы ;

Страница
2

Когда процессный подход начал завоевывать определенные позиции, многие находились в эйфории: найден универсальный инструмент управления! Многие противопоставляют функциональный и процессный подходы, считают их взаимоисключающими. Они говорят: "функции нужно забыть! А работать нужно только с процессами!". Но природа фирмы не изменилась от того, что мы смогли посмотреть на нее по-другому. Это механизм, который все равно выполняет определенный набор функций. И в зависимости от того, какой именно набор функций он выполняет, такие процессы и лежат в основе системы управления. Поэтому, с нашей точки зрения, нельзя просто откинуть один из подходов. Это не противопоставление, а два взгляда на управление, дополняющих друг друга. И сейчас, дорогие читатели, мы Вам это докажем.

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

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

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

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

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

Создание (дизайн) бизнес-процессов

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

Изменение бизнес-процессов

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

Анализ бизнес-процессов

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

Оптимизация бизнес-процессов

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

• Tutorial

Эту статью я написал в продолжение статьи о BPM-системах . И здесь я хочу рассказать о принципах работы BPMS на примере конкретной системы - Bizagi. Я постараюсь пояснить, как происходит процесс моделирования, разработки и исполнения бизнес-процесса в этой системе на практическом примере.

Bizagi: Model. Build. Run

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

• Modeler - полнофункциональная среда моделирования процессов в нотации BPMN;
• Studio - среда разработки бизнес-процессов;
• Engine - среда исполнения процессов, которая доступна пользователям в любом браузере с любого устройства.

Рассмотрим каждый из этих модулей подробнее.

Modeler

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

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

Вы можете использовать один из трех способов моделирования бизнес-процесса:

• New Process - создать свой новый бизнес-процесс;
• Import Process - импортировать бизнес-процесс;
• Process Xchange - выбрать готовую модель из базы бизнес-процессов, предложенной компанией Bizagi. Выбрав шаблон, вы можете доработать его под реалии своего бизнеса. Все представленные модели написаны на английском языке.

Созданный в Modeler бизнес-процесс вы можете редактировать, сохранить, экспортировать в различных форматах (pdf, html).

Моделирование бизнес-процесса производится в формате BPMN 2.0. Этот формат несколько отличается от известного многим BPMN 2.0, я с этим столкнулся на практике. Некоторых возможностей, которые подразумеваются в BPMN 2.0 и в некоторых других программах, созданных для работы исключительно с моделированием, в формате Bizagi вы не найдете. Например, здесь нет так называемой “внешней сущности”. Зато в Bizagi имеются собственные разработки, которых нет в других системах, например, Mailstone - промежуточный этап.

Созданные в Modeler карты бизнес-процессов можно как “расшаривать” на портале Bizagi, так и использовать коллаборатив, то есть несколько сотрудников могут выполнять совместную работу, что очень удобно.

Мodeler имеет русскоязычный вариант интерфейса, в отличие от двух других модулей.

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

Studio

Смоделированная карта бизнес-процесса должна заработать. Пользователь должен входить в систему и взаимодействовать с различными формами. Studio позволяет разработать интерфейс и формы, с которыми будет работать человек. Ниже мы подробнее рассмотрим все аспекты разработки бизнес-процесса в Bizagi Studio.

Хочу отметить, что Modeler и Studio бесплатны. В базовый пакет Studio включены до 20 тестовых пользователей.

Engine

Engine - это среда исполнения, которая позволяет пользователям заходить в систему и работать в ней, выполняя определенные бизнес-процессы.

Лицензии Engine платные. Бесплатен только тестовый режим.

В Engine предусмотрено два вида лицензии:

• постоянная лицензия;
• лицензия на год.

При этом компаниям, в которых работает до 50 пользователей, предоставляется скидка 50% - это так называемый Starter kit, направленный на поддержку малого и среднего бизнеса. Если на предприятии работает более 50 пользователей, придется оплачивать полную стоимость лицензий.

Engine предполагает пошаговое исполнение разработанного бизнес-процесса с учетом всех прописанных в Studio условий.

Без модуля Engine вы не сможете полноценно работать в системе и исполнять прописанные бизнес-процессы.

Как работает Bizagi

Что мы делаем в Bizagi, если нам необходимо автоматизировать какой-либо бизнес-процесс? Рассмотрим алгоритм действий на примере согласования заявки на расход денежных средств. В статье про BPM-системы мы видели, как этот бизнес-процесс был реализован на реальном проекте посредством учетной системы, сейчас мы посмотрим, как это правильно организовать в системе BPM.

1. Моделирование

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

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

Мы моделируем схему бизнес-процесса Payment Request: определяем начало процесса, события, оповещения, бизнес-правила и конец бизнес-процесса.

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

• Отказать;
• Одобрить.

3. При первом варианте Сотрудник получает уведомление об отказе руководителя. На этом бизнес-процесс заканчивается.
3. Во втором случае Руководитель должен Распечатать, подписать запрос и отправить его в бухгалтерию, на этом бизнес-процесс заканчивается.

Графическая карта бизнес-процесса выглядит так:

2. Разработка структуры данных

После того, как бизнес-процесс смоделирован, мы приступаем к разработке структуры данных. На данном этапе мы прописываем, в каких формах, каких полях хранятся те или иные данные и указываем их связи.

В нашем примере мы должны разработать три сущности (Entity):

• Запрос на оплату счета;
• Контрагент (поставщик, которому необходимо оплатить счет);
• Причина отказа.

Для каждой из этих сущностей необходимо прописать атрибуты (поля), которые будут доступны для заполнения. Атрибуты делятся на:

• Предустановленные (их очень много) - атрибуты, которые предлагает сама система;
• Пользовательские - те, которые пользователь создает вручную.

На скриншоте видно, какие атрибуты прописаны для каждой сущности.

Также необходимо указать связи между этими сущностями. Мы прописываем, что сущности Причины отказа и Контрагенты входят в сущность Запрос на оплату счета.

3. Создание форм (пользовательского интерфейса)

После того, как мы разработали структуру данных, нам необходимо решить, как пользователь заходит в систему, как взаимодействует с ней. И вот здесь нам необходимо создать пользовательский интерфейс.

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

Форма - это то, с чем впоследствии будет работать пользователь.

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

В нашем примере необходимо разработать 3 формы:

• Создания запроса на оплату;
• Проверка запроса на оплату;
• Формирования печатной формы.

Эти формы используют одни и те же данные. Основа в каждой из этих форм одна - запрос на оплату счета. Но каждая следующая форма имеет более расширенный функционал, чем предыдущая. Например, в форме Проверки запроса есть вся информация из формы создания запроса + статус заявки (Одобрено или нет). А следующая форма имеет по сравнению с предыдущей еще и возможность печати запроса. При необходимости ненужные поля из предыдущих форм можно скрыть.

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

Теперь рассмотрим сам процесс создания формы (например, Создания запроса на оплату).

Форма создается посредством выбора и перетаскивания в активное окно необходимых полей. Для выбора предлагаются поля (атрибуты), которые мы назначили конкретным формам на предыдущем этапе.

Форма создания запроса в итоге будет выглядеть так:

Здесь мы видим поля:

• Срок оплаты;
• Сумма счета;
• Номер счета;
• Контрагент;
• Присоединенный файл (возможно прикрепить счет на оплату).

Также для более удобного использования форм можно воспользоваться Layot (варианты расположения частей формы).

Макет формы можно разделить:

• на три равные части (33%-34%-33%);
• на две равные (50%-50%) части;
• на две неравные (70%-30%, 30%-70%) части;
• оставить макет неделимым (Full layout).

На этапе создания форм можно настроить видимость полей и функции редактирования для разных пользователей.
Например, у следующего этапа Проверки запроса есть своя форма, в которой руководителю видны поля, созданные сотрудником на предыдущем этапе, но руководитель эти поля редактировать не может. Зато ему доступны собственные поля, которые не видны сотруднику: поле Одобрено с вариантами Yes/No.

Поле Причина отказа становится видным для руководителя, только если в поле Одобрено он выбрал вариант No. То есть видимость полей можно настроить не только в формате Видно-Не видно, но и в зависимости от каких либо условий. Это условие выглядит так
PaymentRequestApproved is equal to false

Если Руководитель установил вариант Yes, становится доступной функция распечатать запрос на оплату. Для него уже никакие функции недоступны, кроме Generate template.

4. Определение бизнес-правил

В Bizagi предусмотрено три этапа установки бизнес-правил:

• Define Expressions - предполагает обработку условий
• Activity Actions (Events) - предполагает обработку событий
• Perfomance - предполагает обработку пользователей, работающих на том или ином этапе бизнес-процесса.

Define Expressions
На этапе Define Expressions идет определение вариантов поведения системы при тех или иных условиях. В нашем случае это результат проверки запроса, два варианта (две стрелки), которые ведут от Результата проверки. При нажатии на стрелку, ведущую к следующему этапу, открывается форма, в которых заполняются условия перехода на тот или иной этап.

Если по результатам проверки руководитель отказывает, то процесс переходит в стадию Оповестить о причине отказа.

Если по результатам проверки Руководитель одобрил запрос, процесс переходит на этап Распечатать счет.

Activity Actions
На этапе Activity Actions мы можем прописать предопределенные поля. Предопределенные поля могут заполняться в трех случаях (на выбор):

• при открытии формы;
• при сохранении;
• при выходе из формы.

Например, на этапе Создания запроса на оплату, мы можем указать, что при открытии формы у нас есть два предопределенных поля:

• Дата - здесь мы указываем, что дата запроса автоматически заполняется текущей датой DateTime.Today
• Автор (сотрудник) - здесь прописываем, что тот, кто инициировал документ, автоматически становится его автором Me.Case.Creator.Id

Perfomance
Следующий шаг - это Perfomance. Здесь мы прописываем, кто на каком этапе работает с бизнес-процессом, отвечает за его выполнение.

• На этапе Создания сделки работает сотрудник, создавший эту сделку. User Id Equal Case Creator
• На этапе Проверки запроса работает Руководитель того, кто создал документ. User Id Equals CurrentAssigneeBoss

5. Описание правил оповещения
После того, как мы прописали, как работают бизнес-правила, мы описываем правила оповещения.

Сотрудник не может постоянно находиться в одной системе, у него есть текущие дела и работа в других программах. Как он будет получать информацию об изменениях по бизнес-процессу, которые требуют его участия? Это настраивается с помощью Notification. В BPMN 2.0 есть такое понятие, как notification, и здесь мы можем оповещение привязать к системе.

Оповещения бывают двух видов:

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

Использовать можно оба вида оповещений одновременно.

В нашем бизнес-процессе при смене этапа (Одобрен или Не одобрен запрос на оплату), Сотруднику отправляется сообщение о том, что счет одобрен или требует уточнения.

6. Создание печатной формы

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

В системе можно создавать, так называемый, document templates. Для печатной формы запроса можно использовать word, excel или простой текст. Мы создали форму, которую должен распечатать тот, на ком заканчивается процесс, и поставить свою подпись. В этой печатной форме видна вся основная информация по запросу:

• Дата создания;
• Пользователь;
• Номер счета;
• Дата счета;
• Сумма счета;
• Основание;
• Подпись ответственного лица.

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

Исполнение бизнес-процесса

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

Рассмотрим, как происходит исполнение созданного нами бизнес-процесса:

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

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

2. Руководитель получает оповещение о том, что необходимо Проверить запрос.
3. Руководитель входит в форму запроса, где видит форму проверки запроса с доступными действиями - выбрать, одобрен или не одобрен запрос.

Если руководитель выбрал Yes:
4. Появляется кнопка Generate document для распечатки запроса. Руководитель выводит печатную форму и подписывает ее.
5. Сотрудник, инициировавший запрос, получает уведомление об одобрении счета

Если руководитель выбрал No:
4. Сотрудник, инициировавший запрос, получает уведомление об отказе в оплате счета.
Бизнес-процесс исполнен.

Еще несколько слов о Bizagi

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

В системе предусмотрена интеграция: возможно “снаружи” подключаться к Bizagi, либо из самой Bizagi подключаться к другим программам посредством API. Она использует web-сервисы и SOAP.

Необходимо также напомнить, что система имеет локализацию - варианты на разных языках. Есть в Bizagi Modeler и русский перевод. Сразу скажу, что этот перевод, к сожалению, не всегда правильный. К тому же, вся документация Bizagi представлена только на английском. Поэтому я предпочитаю работать с системой на английском языке.

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

Дизайнер Бизнес-Процессов - это инструмент для ручного или автоматического выполнения последовательно составленных Задач.

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

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

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

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

Возможно ваши старые бизнес-процессы в визуальном редакторе Дизайнера Бизнес-Процессов выглядят как-то так:

(нижняя картинка показывают как можно разделить путь выполнения Бизнес-Процесса)

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

Новый модуль Бизнес-Процессов позволяет связать последний РЕЗУЛЬТАТ с первыми ВХОДНЫМИ ДАННЫМИ. Таким образом вы можете создать бесконечно повторяющийся Бизнес-Процесс!