Привет, Хабр! Меня зовут Игорь Кайбанов, я эксперт СЭД/BPMS компании Axenix.

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

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

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

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

 Также важно было обеспечить интеграцию с «1С». В «1С:ERP» уже были сосредоточены ключевые сущности: бюджеты, заказы, поставщики, движение средств. Но процессы согласования жили в «разрозненном состоянии»: часть шагов проходила внутри ERP, часть — в почте и мессенджерах. Регламенты интерпретировались по-разному в зависимости от страны и локального законодательства.

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

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

 Что именно пришлось автоматизировать

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

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

 Архитектурное решение: типовая система + кастомная оргмодель со сложной маршрутизацией

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

В качестве системы для решения задачи проекта было выбрано решение «1С:Документооборот 3.0». Практическая ценность платформы проявляется в трех вещах.

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

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

 Наконец, бесшовная интеграция. Связка с «1С:ERP» и внешними системами превращает документооборот в часть единого контура. Типичный сценарий выглядит так: операция в ERP — например, создание заявки на закупку — автоматически инициирует процесс в СЭД, формируя карточку документа и маршрут согласования. По мере прохождения этапов статусы возвращаются обратно, замыкая цикл.

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

 Рабочий процесс до автоматизации

 Перед тем как что-либо настраивать в системе, процессы приходится буквально «собирать с нуля», через As Is / To Be моделирование. В локальных сценариях это обычно одна диаграмма. В территориально распределенных — скорее многослойная карта, где накладываются сразу несколько измерений.

 С одной стороны, есть тип документа: финансовая заявка, договор, рекламация, каждый со своей логикой. С другой — так называемые target и disciplinary линии. Первая определяет, кто отвечает за бизнес-содержание и результат, вторая — кто формально утверждает документ с точки зрения юридической структуры. В реальности процесс проходит сразу через несколько контуров управления, что требует параллельного учета разных иерархий (см. рис. 1).

 К этому добавляются финансовый контур, а также точки интеграции с ERP и другими системами.

Рис. 1 - Функциональная и дисциплинарная иерархии в процессе согласования

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

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

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

Три контура управления в одном процессе

Пример того, как мы совместили три контура управления в одном процессе. Cправочник сотрудников, которым пользовались в организации, находился в информационной системе «материнской» компании и был составлен на английском языке. Более того, этот справочник был построен по двум разным принципам подчинения — target & disciplinary lines, т.е. подчинение по функциональному направлению и дисциплинарному.

Таким образом, структура подчинения выглядела непривычным образом — от людей, а не от подразделений. И вовсе не была похожа на типовой справочник «Структура предприятия» в «1С:Документообороте».

Архитектуру решили построить таким образом, чтобы вся информация по возможным в компании структурам подчинений — cost centers, target line, disciplinary line — хранилась в «Документообороте». Именно такая структура нам в дальнейшем и позволила создать матрицы согласования, базируясь на типовой иерархии подчинения справочника «Структуры предприятия» на стороне «Документооборота», доработанном регистре согласований, а также рабочих группах по уровням согласования.

Low Code — No Code: автоподстановки рулят, скрипты подруливают

Нужно отметить, что типовой функционал автоподстановок «1С:Документооборот» позволил значительно снизить объем разработки. За счет визуального конструктора и конфигурируемых справочников платформа хорошо подходит под low-code-подход: значительную часть маршрутов можно собрать без тяжелой разработки, что важно при быстрых изменениях регламентов.​

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

Одним из серьезных вызовов стала необходимость запуска комплексных процессов специалистами, работающими в «1С:ERP». Такие процессы используются для создания сложных и многошаговых маршрутов работы с документами или задачами и позволяют объединить несколько типовых действий (согласование, утверждение, ознакомление и т.п.) в единую логическую схему. В результате было найдено решение, позволяющее с незначительной доработкой формы в «1С:ERP» стартовать несколько разных маршрутов согласования в «1С:Документооборот».

В форме документа непосредственно из «1С:ERP» можно было выбрать не только маршрут, но и ответственного за документ (в данном случае — первого согласующего). В настройках использовались как реквизиты формы, так и общие реквизиты «1С:ERP».

В процессе работы мы столкнулись с очередным вызовом — если в «1С:ERP» имена физлиц и пользователей заведены на русском языке, то в «1С:Документооборот» — использовались имена и справочники на английском.

Типовой обмен не сопоставляет справочники на разных языках. Чтобы избежать значительных доработок системы, формирования мэппинговых таблиц, дополнительных реквизитов и транслитерации пользователей, мы сделали подмену на стороне документооборота, сформировав справочники сотрудников с дополнительными полями на разных языках. На стороне «1С:ДО» «Имя пользователя» оставлено на английском, а полное имя — на русском из «1С:ERP», правила обмена дополнили запросом для связи двух систем.

Если «ОбъектХDТО» содержит имя сотрудника на английском языке, то простой скрипт позволяет сопоставлять имя сотрудника на английском языке с его именем на русском и получать ссылку на соответствующего сотрудника в справочнике «Сотрудники».

Как результат — пользователь заходит в «1С: ERP», формирует документ (например, ЗРДС), отправляет на согласование. На стороне «1С:Документооборота» система определяет его англоязычное «альтер эго» и формирует рабочий процесс согласно его cost center и disciplinary line. В случае применения некоторых условий — цепочка могла уйти и на target line. Т.е. типовым функционалом с минимальными доработками мы смогли реализовать маршруты обработки документов по нескольким линиям подчинения одновременно и с учетом международного workflow.

Резюме: архитектура интеграции и почему она взлетела

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

Ключевую роль сыграл подход к настройке. Основная логика была собрана через low-code инструменты платформы: автоподстановки, визуальный конструктор процессов, правила обработки документов. Скрипты использовались точечно — в тех местах, где типовых средств уже не хватало. Например, при необходимости учитывать сразу несколько измерений — страну, валюту, тип документа и линию подчинения.

Интеграция с «1С:ERP» была выстроена как единый контур, а не набор точечных обменов. Из интерфейсов ERP с минимальными доработками запускались процессы в документообороте: передавались ключевые реквизиты документа, определялся первый согласующий, и дальше маршрут уже исполнялся внутри СЭД. При этом пользователь мог работать исключительно в ERP, не переключаясь между системами, а вся история согласования и статусы централизованно фиксировались в одном месте.

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

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

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