Сетевое издание

Международный студенческий научный вестник

ISSN 2409-529X

Впервые появившись в Германии, термин «Индустрия 4.0» постепенно становится повсеместно используемым синонимом «четвертой промышленной революции» [3], означающей активное применение информационных технологий с целью тотальной автоматизации производственных процессов. Одним из принципов создания таких «умных» предприятий является использование информационных систем поддержки принятия решений, которые собирают, визуализируют информацию, автоматизируя рутинные операции [3]. В России применение концепции «Индустрия 4.0» может стать решающим фактором повышения глобальной конкурентоспособности [2], поэтому правительством ведутся работы по развитию отечественной цифровой экономики. Так, распоряжением от 28 июля 2017 года была утверждена программа, рассчитанная до 2024 года и определяющая задачи, выполнение которых приведет к развитию цифровой экономики, определяющей данные в цифровом виде ключевым фактором производства [4].

Одним из направлений развития цифровизации было утверждено создание информационной инфраструктуры, в рамках которой планируется внедрение «цифровых платформ работы с данными для обеспечения потребностей власти, бизнеса и граждан» [4]. Примером такой платформы может быть RUNA WFE – платформа, позволяющая разрабатывать BPM системы для бизнес-процессов организаций. Были проведены исследования по внедрению BPMS в отечественных вузах, в результате которых было заключено, что BPM?системы незаменимы при интеграции разноплатформенных ИС, автоматизации бизнес?процессов, «отставания» настроек ПО от изменений в бизнес-процессах [1]. Однако, в отчете о тенденциях в управлении бизнес-процессами, построенного на основании ежегодных опросов различных компаний, было выявлено, что треть опрошенных организаций используют BPMS лишь в ознакомительных целях [5]. Возникает противоречие между очевидной необходимостью использования BPM?систем в управлении современной организацией и незавершенностью перехода этих организаций к процессному подходу в управлении. Постепенно все больше компаний осознают необходимость этого перехода в условиях цифровой революции, но при этом техническая сторона вопроса не развита, исполняемые модели, интерпретируемые бизнес-сервером, имеются в недостаточном количестве. Возникает закономерный вопрос: что затрудняет управление бизнес-процессами через BPMS? Проблема заключается не только в трудоемкости анализа многочисленных регламентов и построения моделей, но и во внедрении BPM?системы, которое включает в себя такие сложности, как настройка сервера и микросервисов.

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

Система RUNA WFE в результате сравнения с аналогами (ELMA BPM, Activity) была определена как наиболее подходящая, поскольку она представляет собой свободно распространяемую систему с открытым кодом, ориентированную на конечного пользователя и имеющую богатый веб?интерфейс, графический дизайнер бизнес?процессов, ботов для автоматического выполнения задач, достаточную документацию [7]. Кроме того, сервер RUNA позволяет выполнять бизнес-процессы в условиях, максимально приближенных к реальным условиям организации.

Система, разработанная на платформе RUNA WFE, имеет микросервисную архитектуру. Микросервисная архитектура – это современное представление и частный случай сервис?ориентированной архитектуры (SOA). Обе архитектурные парадигмы рассматривают приложение как набор модулей – сервисов, отличие заключается в их размере. В микросервисной архитектуре каждый модуль состоит из небольшого количества строк кода. Основным достоинством небольших сервисов является модульность. В функциональном подходе при разработке монолитного приложения после внесения изменений в небольшую его часть, требуется пересобрать приложение и заново развернуть его. Это ведет к увеличению цикла обновления системы и повышает расходы на сопровождение продукта. Микросервисы позволяют избежать этого. Кроме того, небольшие модули легче тестировать. Масштабируемость позволяет любым способом распределить создание микросервисов между разработчиками. При этом нет риска возникновения конфликтов или сложных логических ошибок, которые было бы трудно отследить при разработке монолитного приложения разными людьми.

Создание системы с микросервисной архитектурой начинается с выполнения оркестровки. В терминологии BPMN оркестровкой называется детальное явное описание бизнес-процесса в виде потока взаимодействия между веб-сервисами. Бизнес-процесс может быть вручную описан на языке оркестровки, но чаще всего описание генерируется автоматически из workflow?диаграмм. Оркестровка рассматриваемого бизнес-процесса была выполнена с помощью инструмента BizAgi Modeler. Полученная модель выглядит как направленный граф, по которому перемещается точка управления, и состоит из элементов нотации BPMN. В модель было добавлено два пула: «Перевод студента» и «Передача данных». Выделение процесса «Передача данных» в отдельный пул обосновано тем, что он объединяет действия, выполняемые сотрудниками образовательной программы, с которой переводится студент. Пул «Перевод студента» включает в себя действия, выполняемые сотрудниками программы, на которую переводится студент. Благодаря этому удалось отобразить взаимодействие процессов в одной организации. На рисунке 1.1. изображен фрагмент созданной модели. Для каждой из задач процесса были указаны время выполнения, стоимость и исполнитель. Настройка ресурсов заключалась в указании количества доступных в организации сотрудников и их почасовой заработной платы. В BizAgi Modeler было создано 14 сценариев, различающихся количеством задействованных сотрудников и поступающих заявок, и был запущен «What If» анализ. Основными показателями сравнения сценариев стали: процент загруженности сотрудников, расходы на заработную плату, общее время выполнения процесса, а также общее время ожидания ресурсов. Анализ собранной статистики позволил сравнить различные сценарии между собой и сделать выводы о том, что количество сотрудников в учебном офисе на данный момент оптимально при текущем количестве поступающих заявок.

Рисунок 1.1. Вид симуляции

Результаты проектирования системы позволили перейти к ключевому этапу ? реализации исполняемой модели бизнес?процесса на сервере RUNA. Исполняемая модель определяется настройкой четырех перспектив: уровня управления, уровня ресурсов, уровней данных и операций. Аналогично построению модели в BizAgi Modeler, реализация перспективы потока управления для запуска модели на RUNA WFE сервере начинается с выполнения оркестровки. Модель была построена в соответствии с моделью, спроектированной ранее, но в нее было добавлено множество задач сценариев и несколько заданий, исполнителями которых были назначены боты. Задача сценария ? это элемент BPMN, при прохождении через который точки управления выполняется заранее определенный алгоритм действий. Потребовалось использование более 50 задач сценария («выполнить формулу», «выполнить код Groovy», «загрузить файл из файловой системы» и др.). Ботами в терминологии RUNA называются микросервисами. Бот — это компьютерное приложение, программная сущность, способная автоматизировать выполнение задачи.

Реализация уровня ресурсов исполняемой модели заключалась в создании ролей и привязке их к задачам в среде Process Designer, создании исполнителей, групп, отношений на RUNA WFE сервере, определении полномочий исполнителей. Во время выполнения экземпляра процесса на каждую роль в процессе назначается конкретный исполнитель на сервере. Так, в соответствии с выявленными на этапе анализа участниками бизнес-процесса были добавлены роли студента и сотрудников университета. При этом роль «Студент» связана со стартовым событием модели «Перевод студентов», и исполнитель, запустивший процесс, автоматически назначается на роль «Студент» в экземпляре запущенного процесса. Для того, чтобы задать инициализатор остальным ролям процесса, потребовалось создать конкретных исполнителей на RUNA WFE сервере (например, Иванов И.И.) и определить отношения, с помощью которых будут инициализироваться роли.

На этапе анализа было определено, что в учебном офисе каждой из образовательных программ есть сотрудник учебного офиса, менеджер программы и академический руководитель, аттестационные комиссии формируются для каждой образовательной программы. Образовательные программы разделяются на две группы по принадлежности к факультету, у каждого из которых свой руководитель. Проректор координирует работу всех факультетов всех кампусов НИУ ВШЭ. Во главе одного кампуса стоит директор, курирующий работу всех факультетов, а у директора есть заместитель. Исходя из этого, на Runa WFE сервере был создан 41 исполнитель. Каждый студент в соответствии с принадлежностью к одной из образовательных программ был добавлен в одну из семи групп «Студенты образовательной программы * », где * - название соответствующей образовательной программы. Также были настроены другие группы пользователей.

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

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

В качестве инициализатора ролей «Аттестационная комиссия», «Академический руководитель» и «Руководитель факультета» использованы одноименные отношения, примененные к роли «Менеджер программы». Роль «Проректор/директор» не имеет инициализатора. Она будет инициализироваться с помощью задачи сценария отношением «Координирующий проректор», если перевод осуществляется между образовательными программами разных кампусов, или отношением «Директор», если студент переводится в рамках одного кампуса. Следует обратить внимание, что роль менеджера программы, на которую переводится студент, не имеет инициализатора. Поскольку на роль «Менеджер программы» назначается менеджер образовательной программы, на которую переводится студент, эта роль не может быть проинициализирована отношением, в правой части которого ? студент образовательной программы. Выбранная студентом целевая образовательная программа будет храниться в переменной процесса, и только она может быть использована для инициализации роли. С помощью исключающего шлюза в зависимости от выбранной образовательной программы на роль назначается определенная группа менеджеров, при этом первое задание будет назначено всем членам группы, а первый исполнитель, взявший его на выполнение, будет выполнять роль на протяжении всего процесса в дальнейшем.

С целью автоматизации отдельных задач процесса были созданы боты, в терминологии RUNA ботами называемые микросервисами, периодически опрашивающими RUNA WFE?сервер. Если экземпляры процессов, запущенные на сервере, имеют активные задачи, исполнителями которых назначены боты, микросервисы выполняют эти задачи, а результат возвращают на сервер. В рассматриваемых процессах задействованы четыре задачи ботов. В таблице 1.1 описывается, в каких ситуациях они использовались.

Таблица 1.1. Задачи ботов

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

Реализация перспективы данных заключается в определении набора внутренних переменных процесса, используемых для настройки конфигурации исключающих шлюзов, обмена данными, заполнения шаблонов документов. В процессе используются 9 документов: заявление студента, выписка из зачетной книжки, протокол аттестации, индивидуальный учебный план, договор об оказании платных образовательных услуг, чек, подтверждающий оплату, приказ о переводе, личное дело студента, акт о передаче личного дела. Всего было создано 42 переменных – строковых, целочисленных, списочных, файловых и пользовательских типов данных. Это позволило задать конфигурацию шести исключающим шлюзам, а также выполнить хореографию созданных моделей, то есть настроить взаимодействие между ними с помощью передачи сообщений. Документы, используемые в процессе, формируются на основе заранее подготовленных шаблонов с помощью задачи сценария «Формирование документа DOCX используя шаблон».

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

На этом создание исполняемой модели бизнес-процесса «Перевод студентов внутри НИУ ВШЭ» было завершено. Созданные модели были загружены на RUNA WFE сервер. Для определения работоспособности системы были запущены и выполнены до конца экземпляры процесса, подтвердившие работоспособность модели и успешный переход точки управления по всем возможным путям схемы. Количество проведенных тестов достаточно, чтобы сделать вывод о том, что загруженная на сервер исполняемая модель бизнес-процесса интерпретируется без ошибок и позволяет осуществлять процесс перевода студентов на практике.

В работе возникли осложнения с использованием внешнего хранилища данных в RUNA WFE. Существует ограничение: в используемый в качестве внешнего хранилища данных файл Excel нельзя вручную добавлять данные во избежание проблем с их форматом. Так, для использования заранее заполненного хранилища необходимо создавать отдельный процесс, в котором бот будет добавлять данные в файл. Кроме того, очень важно реализовать простейший аналог транзакций системы управления БД, включив опцию «последовательного выполнения задач» бота.

Результатом выполнения поставленных задач стало успешное создание исполняемой модели бизнес-процесса «Перевод студентов внутри НИУ ВШЭ», реализация четырех перспектив интерпретируемой сервером модели, загрузка ее на сервер RUNA WFE и запуск экземпляров процесса. Несмотря на возникшие трудности, поставленная цель была достигнута в полной мере: полученная система позволила осуществить перевод студента на практике. В организации появляется аналог производственного конвейера: сотрудники не тратят время на поиск информации, передачу своих трудов, изучение должностных инструкций, выполнение рутинных операций, все задачи разбиты на равные по трудоемкости действия. Такой подход к управлению бизнес-процессами позволяет сократить цикл обновления бизнес-процесса в соответствии с изменениями в организации. Система позволяет исполнять экземпляры бизнес-процесса и контролировать их состояния, распределять задачи между сотрудниками, просматривать историю, выполнять администрирование пользователей.