Корпоративные системы: управляю процессами, а не позволяю им управлять мной
При интеграции различных информационных решений особенно заметно, насколько по-разному компании организуют согласование документов, обработку заявок и выполнение внутренних поручений. Одни платформы ограничиваются уведомлениями: сотруднику приходит сообщение о новом документе. Другие создают отдельный тип задания для каждого сценария. Где-то сразу используют BPMN-движок, а где-то процесс вообще не формализован.
На ранних этапах разработки легко сделать жизнь пользователей сложнее. Например, согласование сметы приходится выполнять в одном разделе, чертежа - в другом, а служебной записки - в третьем. Пользователь вынужден помнить, куда заходить и какую кнопку нажимать в каждом конкретном случае. Такой подход встречается чаще, чем хотелось бы, и обычно становится следствием попытки быстро закрыть частную задачу без общей модели.
Если платформа уже содержит встроенный механизм задач, ситуация проще. ELMA365, 1С, Enovia и другие продукты предоставляют готовые инструменты, на которых можно выстроить надежную работу. Однако при разработке самостоятельного решения команда нередко создает собственный модуль без единой архитектуры. В результате он оказывается жестко привязанным к конкретному документу, плохо расширяется и требует значительных затрат при каждом новом сценарии. Еще одна крайность - преждевременное внедрение BPMN-процессора вроде Camunda там, где достаточно более простой модели.
Для большинства внутренних задач подходят корпоративные системы управления, построенные на трех базовых сущностях: маршруте, шаге и задаче с возможностью оставить замечание. Такая схема не претендует на замену полноценной BPMN-платформы, но позволяет закрыть значительную часть типовых процессов. Дополнительные сценарии появляются благодаря комбинации маршрутов, их последовательному или параллельному запуску и корректной обработке результатов.
Из чего состоит модель процесса
Маршрут представляет собой набор шагов, распределенных между конкретными сотрудниками или ролями. Каждый шаг включает одну или несколько задач. Маршрут считается выполненным только после завершения всех шагов, а шаг - после выполнения входящих в него задач.
Предположим, необходимо согласовать комплект конструкторской документации. Тогда маршрут может включать такие шаги:
- конструктор;
- технолог;
- специалист по нормоконтролю;
- главный инженер.
На каждом этапе задания можно назначить конкретному сотруднику, группе или роли. Например, конструктор получает одну задачу, технолог - другую, а на этапе нормоконтроля несколько исполнителей работают параллельно. Это позволяет описывать как простые последовательные цепочки, так и более сложные схемы с ветвлением.
После запуска активируется первый шаг. Следующий становится доступным только после завершения предыдущего. При этом число шагов и задач не ограничивается технически, однако крупный процесс лучше разделять на несколько логически самостоятельных маршрутов. Их можно запускать один за другим или одновременно, в зависимости от особенностей бизнеса.
Именно здесь появляется эффективная система управления бизнес-процессами: отдельный маршрут отвечает за исполнение заданий, а бизнес-объект - за собственное состояние и дальнейшую логику.
Разделение ответственности
Ключевой принцип архитектуры заключается в том, что маршрут не должен знать внутреннюю структуру объекта, с которым работает. Он не обязан проверять заполнение реквизитов, анализировать статус документа или решать, разрешено ли его согласование. Такие проверки выполняются на стороне самого объекта до запуска маршрута.
Маршрут лучше рассматривать как изолированный сервис. На вход он получает инструкции: кто должен выполнить действие, в каком порядке и с какими условиями. На выходе возвращается результат - успешное завершение, отклонение с замечаниями либо иной предусмотренный итог.
После этого объект принимает результат и меняет собственное состояние в рамках жизненного цикла. Например, после положительного завершения согласования документ может перейти в статус "Утвержден", а после отказа - вернуться автору на доработку. Если требуется следующий этап, объект запускает новый маршрут.
Такое разделение делает автоматизацию бизнес-процессов устойчивой. Изменение правил конкретного документа не требует переписывать механизм маршрутов, а добавление нового типа объекта не заставляет создавать отдельную систему задач.
Жизненный цикл маршрута
Для управления состояниями маршрута достаточно ограниченного набора статусов:
- Черновик - маршрут создан, в него добавлены шаги и задачи, но исполнение еще не началось.
- Запущен - первый шаг активирован, пользователи получили задания.
- Согласовано или завершено - все необходимые действия выполнены положительно.
- Отклонено с замечаниями - один из участников отказал в согласовании и указал причины.
- Проигнорировано или не является предметом согласования - сценарий не требует фактического исполнения, но результат должен быть зафиксирован.
Набор статусов может расширяться, однако важно не превращать его в сложную систему, где пользователю трудно понять текущее состояние. Каждое состояние должно иметь четкий смысл, допустимые переходы и понятный набор действий.
Замечания особенно важны при отклонении. Простого статуса "отказано" недостаточно: автору необходимо видеть, что именно нужно исправить. При повторном запуске можно сформировать новый маршрут или вернуть текущий в работу - выбор зависит от требований к аудиту и истории изменений.
Удаление объекта и изменение его статуса
Отдельного внимания требуют ситуации, когда рассматриваемый документ удален, архивирован или переведен в состояние, несовместимое с активным согласованием. Маршрут не должен продолжать работу вслепую.
При попытке открыть задачу система обязана проверить доступность объекта и его актуальный статус. Если документ удален, задания можно автоматически закрыть с техническим результатом. Если он перешел в другой статус, система должна определить, сохраняется ли необходимость согласования. В некоторых случаях маршрут следует завершить как утративший актуальность, в других - запустить заново по новым правилам.
Такая проверка необходима для интеграции корпоративных информационных систем. Несогласованные состояния между задачами и объектами приводят к "зависшим" поручениям, неверной отчетности и конфликтам между подразделениями.
Практические правила внедрения
Перед запуском стоит определить единый справочник ролей, правила назначения исполнителей и порядок обработки просроченных задач. Назначение на конкретного человека удобно для уникальных поручений, но для устойчивости процессов лучше использовать роли, если обязанности могут переходить между сотрудниками.
Полезно также предусмотреть делегирование, замещение на период отпуска, уведомления о приближении срока и журнал событий. При этом уведомление не должно подменять задачу: письмо сообщает о необходимости действия, но само действие выполняется в едином интерфейсе.
Еще один важный аспект - измеримость. Система должна сохранять время запуска и завершения шагов, длительность ожидания, количество возвратов на доработку и причины отклонений. Эти данные помогают обнаружить узкие места и понять, где автоматизация действительно ускоряет работу, а где лишь переносит ручные операции в цифровую форму.
Внедрение корпоративной информационной системы лучше начинать с нескольких понятных процессов: согласования документов, заявок на закупку, служебных записок или технических изменений. После проверки модели на практике можно добавлять параллельные маршруты, дополнительные роли и интеграции. Такой постепенный подход снижает риски и дает пользователям время привыкнуть к единой логике.
Итог
Универсальный механизм процессов не обязательно должен быть сложным. Во многих корпоративных сценариях достаточно трех сущностей - маршрута, шага и задачи - при условии, что между ними четко определены связи и ответственность.
Маршрут исполняет последовательность поручений, объект управляет собственным жизненным циклом, а результат маршрута становится входом для следующего действия. Благодаря этому корпоративные системы управления остаются расширяемыми, а бизнес-логика не смешивается с механизмом задач.
Главный принцип можно сформулировать просто: система должна помогать сотруднику понимать, что делать дальше, а не заставлять его изучать внутреннее устройство нескольких разрозненных модулей. Когда процессы стандартизированы, прозрачны и независимы от конкретного документа, компания получает не набор отдельных автоматизаций, а устойчивую среду для развития.
