Реестр BPMN-процессов внутри 1С: зачем процессу два независимых статуса

Я много лет занимаюсь автоматизацией, и как Бизнес-аналитик нередко видел, что по документам 1С процесс может выглядеть законченным: есть заказ клиента, реализация, складские документы и закрывающие документы. Но во время предпроектного обследования выясняются скрытые детали, например: логисты регулярно вызывали курьера, чтобы отвезти бумажные накладные в Россельхознадзор и забрать их обратно! Операция влияла на сроки отгрузки, но существовала за пределами 1С и формального описания процесса.

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

Так возникла задача: хранить в 1С не только BPMN-схемы, но и минимальный реестр описанных процессов.

От редактора схем к реестру процессов

«Схемопоинт» — бесплатное расширение для моделирования BPMN-процессов внутри 1С. Оно работает в тонком клиенте, не требует изменения основной конфигурации и связывает данные в информационной базе.

В редакторе можно:

• создать BPMN-схему или импортировать файл .bpmn;

• сохранить процесс внутри 1С;

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

• повторно открыть схему из списка процессов.

Расширение для 1С  не исполняет BPMN, не создаёт задания и не заменяет полноценную BPMS-систему. Его область применения — описание процессов, тесно связанных с учётной системой: продаж, закупок, склада, логистики, производства и финансов.

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

1. Выполняется ли этот процесс в организации или отменен?

2. Соответствует ли BPMN-схема текущей работе?

3. Кто отвечает за процесс?

Первоначально хотелось объединить первые два вопроса в один статус. Но тогда возникали неоднозначные состояния.

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

Поэтому в реестре разделены:

• статус процесса — «Не определён», «Действует», «Не действует»;

• состояние описания схемы — «Не определено», «Черновик», «Актуально», «Требует актуализации»;

• владелец процесса — должность руководителя, отвечающего за процесс.

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

Как устроена связка 1С и bpmn-js

Для графического редактора используется открытая JavaScript-библиотека bpmn-js. Она отвечает за BPMN-полотно, добавление и изменение элементов и формирование канонического BPMN XML.

Архитектура разделена на три слоя:

При сохранении JavaScript формирует BPMN XML и JSON с составом элементов. 1С получает эти данные, сохраняет XML процесса и синхронизирует справочник BPMNЭлементы. Связи элементов с объектами конфигурации хранятся отдельно в регистре сведений.

Это разделение оказалось полезным при реализации реестра. Статус процесса и состояние его описания не являются частью BPMN-нотации. Если записать их только в XML или передавать в JavaScript, по ним будет неудобно строить списки и отборы средствами 1С.

Поэтому реквизиты реестра остались полностью на стороне 1С, а контракт между 1С и bpmn-js не пришлось расширять.

Как реализован реестр и какие нюансы пришлось учитывать

За основу взят уже существующий справочник BPMNПроцессы, в котором хранятся схема, автор и номер версии.

Доработана карточка процесса,  добавлены:

• два перечисления для статуса процесса и состояния описания;

• владелец процесса строка (пока);

• дата создания;

• дата последнего изменения статуса.

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

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

При записи учитываются несколько случаев:

Дата смены статуса обновляется только при реальном изменении. Повторная запись карточки со статусом «Действует» не должна создавать ложное событие.

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

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

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

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

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

Что это даёт бизнес аналитику или разработчику

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

Можно создать или импортировать схему в базы 1С, связать её шаги с объектами конкретной конфигурации, указать владельца и отметить состояние описания. Когда изменится схема продаж, документооборот или складской контур, процессы, требующие пересмотра, будут видны в общем реестре (состояние "Требует актуализации").

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

• планирование продаж;

• продажи по направлениям;

• отчётность по продажам;

После заполнения реестра можно задать уже не абстрактный вопрос «есть ли у нас описанные процессы?», а конкретные:

• какие действующие процессы имеют неактуальные схемы;

• какие описания остались черновиками;

• у каких процессов не определён владелец;

• какие схемы следует проверить перед следующим изменением 1С.

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

Бесплатный дистрибутив, описание возможностей, инструкция и расширения 1С для BPMN процессов доступны на сайте «Схемопоинт». Так же проект развивается на моем Гитхабе: https://github.com/a2gordeev/Schemopoint.BPMN_in_1C .