Всем привет!
Вы работаете с системами мониторинга транспорта, отрабатываете и согласуете заявки или являетесь частью команды разработки таких продуктов? Тогда этот материал будет вам интересен.
В статье на примере продукта Monitor3S мы расскажем, как оптимальным образом организовать работу с заявками на транспорт, если компании трудно подобрать коробочное решение мониторинга с использованием GPS и ГЛОНАСС. Кому интересно – добро пожаловать под кат.
А в чем проблема?
До технического описания мы обязательно дойдем, но сначала расскажем о трудностях заказчиков, которые и побудили нас искать оптимальные решения при помощи автоматизации.
У заказчика есть собственная система электронного документооборота (СЭД), где оформляются заявки на транспорт. Далее заявки проходят цепочку согласований, по результатам которых инициатору назначается транспортное средство и водитель. Затем водитель получает путевой лист, распечатанный из программы бухгалтерского учета (1С), самостоятельно разрабатывает маршрут движения через все точки погрузки/разгрузки и в конце смены сдаёт путевой лист с информацией по горюче-смазочным материалам (ГСМ), пробегу и прочим атрибутам стандартного путевого листа.
Схема кажется понятной, однако даже при использовании системы мониторинга транспорта с использованием ГЛОНАСС/GPS, если у вас возникает необходимость соотнести состояние выполнения заявки с планом на смену (например, есть сомнения по поводу потраченных ГСМ или пришел штраф), это можно сделать, только проверив данные из нескольких информационных систем: посмотреть заявку в СЭД, посмотреть трек перемещения в системе мониторинга транспорта, а затем в 1С проверить нормы расхода и сверить всё это с путевым листом.
Если отобразить схематически, то выглядит это примерно так:
Как мы видим на рисунке, в центре движения информационных потоков находится диспетчер, который по целому ряду причин не всегда может обеспечить своевременное обновление информации, выгрузку данных и не застрахован от банальных ошибок.
Чтобы упростить эту работу, весь процесс необходимо автоматизировать.
Если в организации много транспорта и характер его использования различен (перевозка пассажиров, перевозка грузов, спецтехника, строительная техника), то планирование и бюджетирование ее работы на большие периоды – это трудоёмкая задача. Особенно сложно она решается при наличии обширной филиальной сети и большом количестве участников процесса, в том числе подрядчиков.
В таком случае, кроме оперативного формирования необходимого количества заявок на технику, нужно отслеживать класс транспорта, сверяться с плановыми показателями производственной программы, по каждой выполненной заявке осуществлять проверку фактически оказанных услуг, а по итогам отчетного периода сводить итоговые данные и формировать отчёты для руководства. На рисунке схематически отображён процесс взаимодействия всех участников процесса:
Прохождение заявки на оказание транспортной услуги по какому-то одному статическому workflow с участием основных элементов рабочего процесса можно проиллюстрировать так, как представлено на схеме ниже:
На схеме все выглядит просто, но на практике эти манипуляции требуют очень много времени, а автоматизация рабочего процесса с необходимой гибкостью использования его элементов оказывается непростым делом.
При первом подходе к решению описанных выше проблем мы расширили API в Monitor3S. Можно было бы доработать решение в 1С и «затащить» туда все, что ожидали пользователи, дополнить показателями из системы мониторинга транспорта, но мы пошли по пути интеграции между программами, усилив функциональность программного комплекса.
Сделав специальный интеграционный модуль внутри Monitor3S, который самостоятельно инициировал запросы к СЭД, актуализировал статус заданий внутри системы мониторинга транспорта и точки маршрута, формировал итоговый «путевой лист» с фактическими показателями (топливо, пробег, моточасы и пр.), в итоге мы получили схему работы, представленную на рисунке ниже.
Эта схема оказалась рабочей, однако при эксплуатации выявила ряд недостатков:
Нам хотелось добиться большей гибкости получившегося решения и чем больше мы детализировали процессы, тем больше понимали, насколько сложной будет поддержка этих схем и возможных изменений функциональности. Даже версионность самого процесса может стать проблемой, так как часть заявок может уже быть инициирована и сопровождается по одному workflow, а новые заявки должны начинать движение по другому workflow из-за вступивших в действие обновленных правил со строго определённой даты.
Стало очевидно, что необходимо минимизировать искажения реальных рабочих процессов и предоставить аналитикам гибкий механизм для моделирования бизнес-процессов, автоматического формирования их описаний в стандартизованном формате с возможностью легкого корректирования и дальнейшей автоматизации.
Для решения всех этих задач мы начали использовать в работе BPMN, так как эта система позволяет хранить условные обозначения и их описание в XML-формате для отображения бизнес-процессов в виде диаграмм. Она ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN позволяет трансформировать диаграммы, описывающие бизнес-процесс, в исполняемые модули. Спецификация BPMN является исполняемой и переносимой (то есть процесс, нарисованный в одном редакторе от одного производителя, может быть исполнен на движке бизнес-процессов другого производителя при условии, если они оба поддерживают BPMN).
Немаловажным требованием являлось то, что формат описания должен быть открытым стандартом, бесплатным и не принадлежащим к области проприетарных разработок, ограничивающих выбор реализаций «движков».
После ряда исследований мы решили, что продукт Activiti, являясь одной из реализаций «движка» для выполнения BPMN-схем, вполне подходит для автоматизации самих процессов при условии декомпозиции операций до нужного уровня.
После макетирования и оценки важных для архитектуры деталей мы поняли, что это действительно хороший вариант по целому ряду причин:
Общая схема компонентов Activiti и взаимодействия между ними представлена на рисунке ниже:
Activiti не виден конечным пользователям, но выполняет значительную роль в бэкенде и логике приложения.
Аналитики «прорисовывают» процессы в любом удобном инструменте с поддержкой выгрузки workflow в стандарте BPMN. Для создания BPMN-описания можно использовать разные редакторы, но мы выбрали интуитивно понятный BPMN-редактор, реализованный на базе Eclipse c помощью плагина eclipse bpmn2 modeler, который поддерживает в полном объеме стандарт BPMN 2.0 и позволяет сформировать файл с BPMN-описанием (схемой) для дальнейшей загрузки в Activiti.
После загрузки BPMN-схемы в Activiti приложение создает на ее основе описание процесса (process definition). Затем, используя запрос REST-API от внешней системы или Java-API (для приложений, написанных на Java) или интерфейс веб-приложения (Activiti Explorer), Activiti создаёт на базе описания процесса инстанс (поток), который начинает выполняться как по волшебству, передвигаясь шаг за шагом по элементам схемы, следуя по направлениям, указанным стрелками, тем самым реализуя логику схемы:
Таким образом, BPMN-схема, представляющая собой xml-файл, начинает выполняться, как будто это программа, написанная на одном из языков программирования.
Уже импортированные workflow (часть) выглядят следующим образом:
При реализации разработчики в основном использовали минимум кода для проверки граничных условий выполнения того или иного элемента схемы, а также расширяли возможности в самом Activiti, реализуя “custom extension” или добавляя кастомную логику в BPMN-процесс, например, реализуя т.н. “service task” или “event listener” и расширяя api-приложения Monitor3S.
Внутри Activiti “custom extension” и “custom logic” реализуется на Java или Groovy, но разность стеков между Monitor3S и Activiti здесь не имеет значения, так как системы взаимодействуют через REST-API по https.
В итоге в разрезе состава оборудования типовой комплекс Monitor3S можно представить так:
Что касается отказоустойчивости, то, конечно, и она, и высокая доступность служебной БД самого Activiti реализуется отдельными средствами БД (у нас для этого есть специальные утилиты в СУБД Jatoba), но в итоге несколько инстансов Activiti могут корректно работать с единой базой данных.
Таким образом, внедрение в бэкенде Activiti позволило гибко и быстро подстраивать под разные потребности рабочие процессы, связанные с движением заявок на автотранспорт в Monitor3S, оптимизировав целый ряд функций:
В настоящее время у Activiti уже есть вполне зрелые форки, и нам было бы интересно узнать о вашем опыте их использования. Напишите в комментариях об опыте работы BPMN и движков автоматизации бизнес-процессов.
Материал подготовил коллектив авторов: Горячев Алексей, Карпенко Андрей, Рожков Денис.
Вы работаете с системами мониторинга транспорта, отрабатываете и согласуете заявки или являетесь частью команды разработки таких продуктов? Тогда этот материал будет вам интересен.
В статье на примере продукта Monitor3S мы расскажем, как оптимальным образом организовать работу с заявками на транспорт, если компании трудно подобрать коробочное решение мониторинга с использованием GPS и ГЛОНАСС. Кому интересно – добро пожаловать под кат.
А в чем проблема?
До технического описания мы обязательно дойдем, но сначала расскажем о трудностях заказчиков, которые и побудили нас искать оптимальные решения при помощи автоматизации.
Ситуация № 1 СЭД – программа мониторинга – 1С – путевой листок
У заказчика есть собственная система электронного документооборота (СЭД), где оформляются заявки на транспорт. Далее заявки проходят цепочку согласований, по результатам которых инициатору назначается транспортное средство и водитель. Затем водитель получает путевой лист, распечатанный из программы бухгалтерского учета (1С), самостоятельно разрабатывает маршрут движения через все точки погрузки/разгрузки и в конце смены сдаёт путевой лист с информацией по горюче-смазочным материалам (ГСМ), пробегу и прочим атрибутам стандартного путевого листа.
Схема кажется понятной, однако даже при использовании системы мониторинга транспорта с использованием ГЛОНАСС/GPS, если у вас возникает необходимость соотнести состояние выполнения заявки с планом на смену (например, есть сомнения по поводу потраченных ГСМ или пришел штраф), это можно сделать, только проверив данные из нескольких информационных систем: посмотреть заявку в СЭД, посмотреть трек перемещения в системе мониторинга транспорта, а затем в 1С проверить нормы расхода и сверить всё это с путевым листом.
Если отобразить схематически, то выглядит это примерно так:
Как мы видим на рисунке, в центре движения информационных потоков находится диспетчер, который по целому ряду причин не всегда может обеспечить своевременное обновление информации, выгрузку данных и не застрахован от банальных ошибок.
Чтобы упростить эту работу, весь процесс необходимо автоматизировать.
Ситуация № 2 План – факт
Если в организации много транспорта и характер его использования различен (перевозка пассажиров, перевозка грузов, спецтехника, строительная техника), то планирование и бюджетирование ее работы на большие периоды – это трудоёмкая задача. Особенно сложно она решается при наличии обширной филиальной сети и большом количестве участников процесса, в том числе подрядчиков.
В таком случае, кроме оперативного формирования необходимого количества заявок на технику, нужно отслеживать класс транспорта, сверяться с плановыми показателями производственной программы, по каждой выполненной заявке осуществлять проверку фактически оказанных услуг, а по итогам отчетного периода сводить итоговые данные и формировать отчёты для руководства. На рисунке схематически отображён процесс взаимодействия всех участников процесса:
Прохождение заявки на оказание транспортной услуги по какому-то одному статическому workflow с участием основных элементов рабочего процесса можно проиллюстрировать так, как представлено на схеме ниже:
На схеме все выглядит просто, но на практике эти манипуляции требуют очень много времени, а автоматизация рабочего процесса с необходимой гибкостью использования его элементов оказывается непростым делом.
Попытка №1
При первом подходе к решению описанных выше проблем мы расширили API в Monitor3S. Можно было бы доработать решение в 1С и «затащить» туда все, что ожидали пользователи, дополнить показателями из системы мониторинга транспорта, но мы пошли по пути интеграции между программами, усилив функциональность программного комплекса.
Сделав специальный интеграционный модуль внутри Monitor3S, который самостоятельно инициировал запросы к СЭД, актуализировал статус заданий внутри системы мониторинга транспорта и точки маршрута, формировал итоговый «путевой лист» с фактическими показателями (топливо, пробег, моточасы и пр.), в итоге мы получили схему работы, представленную на рисунке ниже.
Эта схема оказалась рабочей, однако при эксплуатации выявила ряд недостатков:
- если обновляется версия ПО одной из систем, то иногда меняются и механизмы интеграции;
- состав данных в разных системах меняется. Иногда это выясняется, когда уже что-то сломалось;
- к любым изменениям автоматизированного рабочего процесса надо привлекать кроме аналитика ещё и разработчиков, штатно выпускать коробочную версию продукта с обновлениями, а это дополнительные существенные трудозатраты.
Попытка №2. BPMN + Activiti
Нам хотелось добиться большей гибкости получившегося решения и чем больше мы детализировали процессы, тем больше понимали, насколько сложной будет поддержка этих схем и возможных изменений функциональности. Даже версионность самого процесса может стать проблемой, так как часть заявок может уже быть инициирована и сопровождается по одному workflow, а новые заявки должны начинать движение по другому workflow из-за вступивших в действие обновленных правил со строго определённой даты.
Стало очевидно, что необходимо минимизировать искажения реальных рабочих процессов и предоставить аналитикам гибкий механизм для моделирования бизнес-процессов, автоматического формирования их описаний в стандартизованном формате с возможностью легкого корректирования и дальнейшей автоматизации.
Для решения всех этих задач мы начали использовать в работе BPMN, так как эта система позволяет хранить условные обозначения и их описание в XML-формате для отображения бизнес-процессов в виде диаграмм. Она ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN позволяет трансформировать диаграммы, описывающие бизнес-процесс, в исполняемые модули. Спецификация BPMN является исполняемой и переносимой (то есть процесс, нарисованный в одном редакторе от одного производителя, может быть исполнен на движке бизнес-процессов другого производителя при условии, если они оба поддерживают BPMN).
Немаловажным требованием являлось то, что формат описания должен быть открытым стандартом, бесплатным и не принадлежащим к области проприетарных разработок, ограничивающих выбор реализаций «движков».
После ряда исследований мы решили, что продукт Activiti, являясь одной из реализаций «движка» для выполнения BPMN-схем, вполне подходит для автоматизации самих процессов при условии декомпозиции операций до нужного уровня.
После макетирования и оценки важных для архитектуры деталей мы поняли, что это действительно хороший вариант по целому ряду причин:
- в Activiti, помимо самого движка, также реализует REST-API для взаимодействия с внешними системами. Это позволяет взаимодействовать с Activiti системам, развернутым на различных платформах (Windows, Linux и т.д.);
- в Activiti реализован веб-интерфейс, позволяющий управлять загрузкой BPMN-схем, запуском процессов на основе загруженных схем, и осуществлять множество других операций по управлению и контролю за процессами;
- Реализована поддержка работы в кластере. Мы были рады увидеть такую возможность, т.к. для корпоративных заказчиков отказоустойчивость очень важна.
Общая схема компонентов Activiti и взаимодействия между ними представлена на рисунке ниже:
Activiti не виден конечным пользователям, но выполняет значительную роль в бэкенде и логике приложения.
Аналитики «прорисовывают» процессы в любом удобном инструменте с поддержкой выгрузки workflow в стандарте BPMN. Для создания BPMN-описания можно использовать разные редакторы, но мы выбрали интуитивно понятный BPMN-редактор, реализованный на базе Eclipse c помощью плагина eclipse bpmn2 modeler, который поддерживает в полном объеме стандарт BPMN 2.0 и позволяет сформировать файл с BPMN-описанием (схемой) для дальнейшей загрузки в Activiti.
После загрузки BPMN-схемы в Activiti приложение создает на ее основе описание процесса (process definition). Затем, используя запрос REST-API от внешней системы или Java-API (для приложений, написанных на Java) или интерфейс веб-приложения (Activiti Explorer), Activiti создаёт на базе описания процесса инстанс (поток), который начинает выполняться как по волшебству, передвигаясь шаг за шагом по элементам схемы, следуя по направлениям, указанным стрелками, тем самым реализуя логику схемы:
Таким образом, BPMN-схема, представляющая собой xml-файл, начинает выполняться, как будто это программа, написанная на одном из языков программирования.
Уже импортированные workflow (часть) выглядят следующим образом:
При реализации разработчики в основном использовали минимум кода для проверки граничных условий выполнения того или иного элемента схемы, а также расширяли возможности в самом Activiti, реализуя “custom extension” или добавляя кастомную логику в BPMN-процесс, например, реализуя т.н. “service task” или “event listener” и расширяя api-приложения Monitor3S.
Внутри Activiti “custom extension” и “custom logic” реализуется на Java или Groovy, но разность стеков между Monitor3S и Activiti здесь не имеет значения, так как системы взаимодействуют через REST-API по https.
В итоге в разрезе состава оборудования типовой комплекс Monitor3S можно представить так:
Что касается отказоустойчивости, то, конечно, и она, и высокая доступность служебной БД самого Activiti реализуется отдельными средствами БД (у нас для этого есть специальные утилиты в СУБД Jatoba), но в итоге несколько инстансов Activiti могут корректно работать с единой базой данных.
Таким образом, внедрение в бэкенде Activiti позволило гибко и быстро подстраивать под разные потребности рабочие процессы, связанные с движением заявок на автотранспорт в Monitor3S, оптимизировав целый ряд функций:
- Оперативное управление транспортом.
- Автоматическое формирование справки для сверки фактических показателей уровня топлива в баках и пробега, чтобы оперативно проверить заполнение водителем путевого листа.
- Оперативное информирование о занятости транспорта.
- Улучшение системы отчетности, так как сводные отчеты по план/факту пробегов и ГСМ формируются с учетом классов транспорта, водителей и филиалов.
В настоящее время у Activiti уже есть вполне зрелые форки, и нам было бы интересно узнать о вашем опыте их использования. Напишите в комментариях об опыте работы BPMN и движков автоматизации бизнес-процессов.
Материал подготовил коллектив авторов: Горячев Алексей, Карпенко Андрей, Рожков Денис.
