Если вы хотя бы раз сталкивались с документооборотом в компании, то знаете, что это огромная и неповоротливая махина, наладить которую сложно, пустить на самотек нельзя, а выстроить идеально практически невозможно. Или все-таки возможно? Какие проблемы возникают при работе с системами электронного документооборота и как их избежать еще на этапе внедрения, попробуем разобраться в этой статье.
Привет! Меня зовут Любовь Черкасова. Я больше 13 лет работаю в ИТ и занимаюсь цифровизацией бизнес-процессов в крупных компаниях. За это время я руководила командами аналитиков и отделом внедрения, участвовала в проектах по запуску и развитию корпоративных систем, а также выводила на рынок собственный продукт — LDM.КЭДО.
Последние годы я занимаюсь развитием CSP-платформы и регулярно вижу и исправляю последствия архитектурных решений, принятых на этапе внедрения. Поэтому многие из наших проектов – устранение этих последствий и замена существующих систем. Я ни раз наблюдала проекты, в которых система формально внедрялась успешно, но уже в процессе реализации становилась неактуальной для бизнеса: требования менялись быстрее, чем шёл проект. Именно этот опыт и выводы из него легли в основу статьи. Я расскажу о том, как наша команда изменила подход к реализации систем электронного документооборота (СЭД), и что из этого получилось. Надеюсь, наш опыт будет полезен кому-то еще.
Все кейсы, описанные в статье, реальные, они действительно из жизни наших клиентов.
Небольшая вводная. За последние несколько лет рынок корпоративных систем претерпел сразу несколько масштабных изменений. После ухода западных вендоров российский крупный и средний бизнес перешел на отечественные системы: 1С, Directum, LDM, ELMA, ЭОС, Авандок, Docsvision, TESSA. А сами СЭДы из простых решений для маршрутизации документов внутри компании превратились в полноценные платформы для управления корпоративным контентом, на которые заказчики возлагают решение многих задач. Сегодня СЭД интегрируется с ERP, CRM, ИИ-агентами. Нагрузка на них постоянно возрастает. Следовательно, СЭД превращается в огромную ИТ-инфраструктуру, на которую заказчики возлагают очень много надежд и от которой ждут решения многих задач. Причем пул этих задач постоянно растет.
Вдогонку за бизнесом
Внедрение СЭД традиционно рассматривается как сложный и достаточно продолжительный проект. А чем сложный проект отличается от доработки? — Прежде всего подходом. Корпоративные ИТ-системы по-прежнему создаются как проекты с фиксированной логикой: инициация и ТЗ, выбор, настройка, интеграции, запуск, сопровождение и поддержка. Как это выглядит на практике мы все прекрасно знаем. Сначала аналитики долго пишут ТЗ, потом разработчики на базе существующей платформы делают доработки и адаптируют имеющуюся платформу под конкретный бизнес клиента, затем проводятся различные испытания и тесты, и наконец, система сдается в опытно-промышленную эксплуатацию. По моему опыту, в крупных компаниях такой полноценный процесс внедрения системы электронного документооборота (ECM, CSP) занимает до 1,5 лет. Казалось бы, не так и много. Но бизнес сегодня живет в совершенно другой реальности, в которой изменения происходят непрерывно, минимум раз в месяц. И заказчик хочет получить свою систему через два месяца, ну, ладно, через полгода. И не из прихоти, а потому что за полтора года в компании заказчика не единожды обновляются бизнес-процессы, меняется состав и количество сотрудников. Это одна сторона процесса. С другой стороны, государство постоянно меняет требования к электронному документообороту. Например, делает обязательным машиночитаемые доверенности, или изменяет формат УПД, или вводит новый формат кадровых электронных документов, или…. Одним словом, за год может произойти непредсказуемое количество изменений в документообороте. Это касается абсолютно всех компаний, но острее всего дела обстоят в банковской сфере. Здесь изменения происходят еще быстрее, как правило на выполнение указаний ЦБ, основного регулятора банковской сферы, дается три месяца. Если же система внедряется полтора года, то она по определению не может соответствовать такой динамике изменений.
В результате проект успешно завершен — система формально сдана и запущена, но она уже не соответствует текущим процессам и ожиданиям бизнеса. Система уже устарела.
«Устаревание» проявляется не во внешнем виде или версии ПО, а в том, что любые изменения становятся дорогими, медленными и рискованными. Получается, что ИТ-технологии «бегут» за бизнесом, хотя должны были бы его опережать. Как преодолеть этот диссонанс? Либо изменить процесс внедрения, либо архитектуру системы и сделать ее адаптируемой.
Какие проблемы возникают во время внедрения:
-
Интеграции превращаются в отдельную программу работ
Каждый новый контур требует уникальной доработки и усложняет архитектуру системы. А теперь еще нужно интегрироваться с ИИ. -
Безопасность и модели доступа догоняют проект в конце
Доступы, аудит и требования ИБ начинают ограничивать развитие системы уже после запуска. Непонятно, что мешает оговорить это на старте. -
Масштабирование и производительность проверяются слишком поздно
Нагрузочные ограничения появляются тогда, когда архитектурные решения уже зафиксированы. Это происходит всегда, а не только когда бизнес реально вырос за время внедрения. -
Кастомизация формирует технический долг на годы вперёд
Быстрые доработки на этапе внедрения увеличивают TCO и замедляют time-to-market в дальнейшем. А как сделать так, чтобы доработки не приводили к росту технического долга?
Блочный ремонт
Конечно, доработки в крупных монолитных системах типа OpenText, Documentum, 1С возможны. Но любое изменение — это «вермишель» в коде и риск «уронить» всё здание. Но и не вносить изменения невозможно. Следовательно, нужен новый подход для лечения этих старых проблем. Что предлагает наша команда? Если коротко — заменить монолитные системы на микросервисные платформы, такие как платформа LDM, с большим количеством независимых блоков. Сейчас расскажу, как именно такой подход реализуется и что дает на практике.
Low-code/no-code
Первое условие для быстрых изменений — использование инструментов low-code/no-code. Те, кто работал с монолитными СЭД, сразу же скажут, что там этот инструмент тоже используется. И будут правы. Но там low-code может быть использован в очень ограниченном объеме, предусмотренном самим вендором. Новый подход в доработке микросервисной CSP-платформы состоит в том, что инструмент low-code становится расширяемым. Не хватило существующего процесса или сервиса — напиши свой рядом. Это позволяет, во-первых, сократить время на реализацию новых фич за счет готовых блоков, а во-вторых, снять ограничения, поскольку заказчик может самостоятельно написать то, что ему нужно в данный момент.
Из жизни наших клиентов
### 1. Кейс: Радикальное сокращение Time-to-Market в промышленности
Проблема: В крупном промышленном холдинге внедрение новых функций в монолитной системе на базе OpenText занимало более полугода из-за сложности связей и «вермишели» в коде.
Решение: Переход на микросервисную платформу и использование Low-code инструментов («Конструктор микрофронтов»), позволяющих аналитикам настраивать интерфейсы и логику без привлечения программистов.
Эффект: Средний показатель Time-to-Market снизился до 12 рабочих дней (с потенциалом сокращения до 5 дней). Это позволило бизнесу ежемесячно подключать новые подразделения и быстро реагировать на изменения процессов.
Time-to-market
Возможность изменения и развития отдельных блоков платформы. Если платформа микросервисная, то каждый сервис может иметь свой релизный цикл, может обновляться отдельно от всей платформы. Что это дает? Такой подход позволяет быстрее вносить доработки, снижает риски обновлений и напрямую сокращает time-to-market — время от появления бизнес-запроса до его вывода в промышленную эксплуатацию. Это в корне отличается от обновления монолитной системы, поскольку ее можно обновить только всю целиком, каждый раз рискуя — улучшить одно и сломать что-то другое.
Из жизни наших клиентов
### 2. Кейс: Преодоление инфраструктурного и финансового «потолка» — миграция с SharePoint.
Проблема: Крупная лизинговая компания использовала западное решение (SharePoint) в качестве основного хранилища. При объеме данных в 26–28 ТБ система перестала быть масштабируемой. Облачный провайдер не мог расширять дисковое пространство под SQL-базу данных Microsoft.
Финансовый барьер: Лицензии на СУБД для построения кластера стоили около 4 млн рублей за 2 ядра, что делало дальнейшее расширение экономически невыгодным.
Решение: Переход на отечественную платформу с поддержкой S3-хранилищ, а также дедубликацией и тирингом.
Эффект: Сняты ограничения на объем хранимых данных, обеспечена технологическая независимость и значительная экономия на лицензиях по сравнению с западным ПО.
Изменение правил доступа
Когда мы работаем с корпоративным контентом, огромную роль играют правила доступа. То есть сотрудник должен иметь доступ к документам, необходимым в работе, и не иметь доступ ко всем другим документам, например, коммерческим тайнам компании, персональным данным сотрудников и т.п. Как правило, в крупных организациях очень сложные модели доступа, они зависят от роли, должности, конкретного подразделения или проекта, времени суток, устройства подключения и т.д. Критериев может быть с десяток, кроме того, они постоянно меняются, потому что люди переходят из одного подразделения в другое, увольняются или наоборот получают повышение. И чем быстрее сотрудник получит доступ к нужному контенту, тем быстрее он включится в работу. Ну, а если сотрудник увольняется его тем более нужно срочно лишить всех прав доступа — это уже вопрос безопасности компании. Монолитные системы с этим справляются с большим трудом. У меня есть пример, когда в одной крупной компании новый сотрудник получал нужные доступы только спустя два дня, после того, как сервис монолитной системы пересчитывал ролевые модели. Два дня на проекте, особенно на критическом этапе, это очень много. На микросервисной платформе LDM этот вопрос решен с помощью атрибутивной модели доступа, которая позволяет за несколько часов перестроить ролевые модели. Ее отличие в том, что доступы не хранятся в базе данных, а пересчитываются на ходу.
Из жизни наших клиентов
### 3. Кейс: Мгновенное управление доступом в госсекторе
Проблема: В одной из крупных организаций при добавлении сотрудника в команду проекта пересчет прав доступа в монолитной системе занимал двое суток. На критических этапах (например, закрытие года) это парализовало работу новых участников.
Решение: Внедрение платформы LDM c атрибутивной моделью доступа (ABAC) на базе библиотеки Casbin, где права рассчитываются «на лету» в момент запроса на основе атрибутов (должность, проект, время суток).
Эффект: Сотрудники получают доступ к нужным документам моментально после внесения записи в штатное расписание, что устранило двухдневные простои.
Нагрузка
Самое сложное при внесении изменений в СЭД — это не написать новую фичу, а обеспечить ее стабильную работу под промышленной нагрузкой. Мы все понимаем, что можно очень быстро и дешево написать нечто, работающие с пятью документами, но как это доработка поведет себя, когда документов будет миллион, предсказать практически невозможно. Наше исследование показало, что масштабирование новой фичи под большие нагрузки требует в пять раз больше трудозатрат, чем собственно ее написание. Микросервисная платформа LDM изначально спроектирована с расчетом на большие нагрузки, поэтому сборка приложения на нашей платформе, естественно, с учетом рекомендаций архитекторов платформы, позволяет собрать его быстро и сразу с учетом больших нагрузок.
Из жизни наших клиентов
### 4. Кейс: Снижение стоимости хранения документов в банке ТОП-5
Проблема: В одном из крупнейших банков России внедрение новой платформы потребовало решения задачи хранения огромного объёма документов (100+ млн объектов, сотни тысяч запросов в час) при высокой стоимости лицензий IBM FileNet и инфраструктуры.
Решение: Внедрение микросервисной CSP-платформы LDM с универсальными сервисами хранения и управления контентом, интеграцией с внутренними системами и автоматизацией обработки электронных документов.
Эффект: За счет оптимизации архитектуры и отказа от дорогостоящих лицензий банк снизил удельную стоимость хранения документов в 3–5 раз, сохранив управляемость и масштабируемость контента. А также приобрел возможности для разработки бизнес-приложений инсорс командой.
Быстрое формирование отчетности по всем правилам
Вернемся к формированию финансовой отчетности. На самом деле, это головная боль всех компаний, не только банков. Основная проблема здесь в том, что технологические решения не успевают за решениями регулятора. И даже если они уже есть, внедрить их в монолитную систему быстро нереально. Стандартный срок внесения изменений в монолит — 6 месяцев, которых как правило, у заказчика уже нет. Другое дело, если вы работаете на микросервисной платформе. Здесь замена нескольких блоков занимает не больше недели. А сам отчет по всем правилам формируется за минуты
Из жизни наших клиентов
### 5. Кейс: Централизованное управление клиентскими документами по запросам
Проблема: В крупном коммерческом банке документы клиентов хранились в разрозненных файловых хранилищах, что осложняло подготовку ответов на запросы, увеличивало трудозатраты и время обработки.
Решение: Перевод клиентских документов в LDM.Клиентское досье на базе микросервисной платформы: централизованное хранение, быстрый поиск, единая база и выгрузка в нужных форматах.
Эффект: Обработка клиентских документов стала в 2 раза быстрее, а система позволила централизовать и систематизировать досье розничных и корпоративных клиентов банка.
ИИ-помощники
Без искусственного интеллекта сегодня никуда. ИИ-помощник, безусловно, — вещь полезная, но это дополнительный контур интеграции. Поэтому микросервисная платформа LDM поддерживает MCP-протокол, что позволяет подключать к платформе любые нейронные сети. Сейчас их на рынке очень много, заказчик может работать с любой на свое усмотрение.
Несколько выводов
-
Корпоративная ИТ-система сегодня — это уже не монолитный замок с толстыми стенами, где любое изменение требует перестройки всего здания. Современная архитектура скорее напоминает модульный коттеджный посёлок: отдельные дома и коммуникации работают как единая среда, но каждый элемент можно развивать, перестраивать или заменять независимо от остальных.
-
В такой системе бизнес может добавлять новые «дома» — приложения и сервисы — под текущие задачи, расширять инфраструктуру по мере роста и обновлять отдельные модули без остановки всей экосистемы. Low-code-инструменты позволяют быстро подключать новые функциональные блоки, а микросервисная архитектура — изолировать изменения и управлять ими без риска для стабильности.
-
Микросервисный подход превращает корпоративную ИТ-систему из разового проекта в живую развивающуюся среду. Платформа не устаревает в момент запуска, а адаптируется вместе с бизнесом, сохраняя управляемость, масштабируемость и предсказуемость развития на годы вперёд.
Автор: Cherkasova_Lubov
