Почему мы не стали делать еще одну большую СЭД

Российский рынок систем электронного документооборота сформировался давно и сегодня остается одним из наиболее зрелых сегментов корпоративного ПО. Крупные решения закрывают десятки сценариев – от регистрации и согласования документов до специализированных процессов, которые отличаются в зависимости от отрасли, масштаба бизнеса и внутренних регламентов компании.

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

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

СЭД как еще одна система в ИТ-ландшафте

Главная боль – не сама работа с документами, а появление еще одной сложной системы рядом с ERP, CRM или отраслевой платформой. Для крупной компании внедрение СЭД редко ограничивается установкой программного продукта. На предприятии уже работают учетные, производственные, кадровые и управленческие системы, каждая из которых содержит собственные справочники, бизнес-логику и данные.

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

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

Для бизнеса такая модель означает, что компании приходится поддерживать интеграционные связи между системами и учитывать их при каждом изменении ИТ-ландшафта.

Документооборот как сервис

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

Именно на такой архитектуре «Диасофт» строит свое решение для электронного документооборота - Digital Q.EDMS. Его базовые функции реализованы в виде набора микросервисов, которые закрывают наиболее распространенные операции с документами (работа с типами документов, с каталогом документов, конструктор маршрутов согласования и выполнение маршрутов согласования, электронно-цифровая подпись трех видов, работа с шаблонами документов).

Микросервисы интегрируются с другими системами через доступные интерфейсы (в том числе REST API и Kafka). Для межсервисного взаимодействия лучше использовать Kafka. но если в основной системе по каким-то причинам нельзя использовать брокер сообщений, то на помощь приходит REST API. Чтобы обеспечить консистентность, если одна из систем временно недоступна, как раз предпочтительнее при межсервисном взаимодействии брокер сообщений чем REST API: если вы используете брокер сообщений, вам гораздо проще обрабатывать недоступность сервисов и обеспечивать надежность основных бизнес-процессов.

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

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

Почему универсальность перестает быть главным преимуществом СЭД

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

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

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

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

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

А что с монолитами?

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

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

«Меньше функций» – это баг или фича?

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

Пользователю производственной системы не обязательно нужен весь интерфейс СЭД. Ему может быть достаточно нажать «Отправить на согласование» непосредственно в ERP и затем получить там же результат. В таком случае отсутствие десятков других возможностей перестает быть недостатком.

Вместо вывода

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

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