Нужна ли ЭДО гибкость или как понять, что вашей компании действительно пора менять систему

Автор: Александр Виниковецкий, директор ЭДО Билайн

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

Именно поэтому первый вопрос, который я обычно задаю коллегам, звучит очень просто: а зачем вообще менять систему?

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

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

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

Я иногда привожу простой пример. В Москве когда-то было невозможно представить платные парковки или выделенные полосы для общественного транспорта. Пока город не столкнулся с постоянными многочасовыми пробками, такие решения воспринимались крайне болезненно. Когда проблема стала очевидной для всех, отношение постепенно изменилось. С корпоративными системами происходит примерно то же самое.

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

Архитектура — не цель

Еще один вопрос, который сегодня звучит особенно часто: что лучше — монолит или микросервисы? Честно говоря, сам по себе этот спор кажется мне несколько искусственным.

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

Какой уровень гибкости нужен именно вашей компании?

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

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

Выбирать нужно не между монолитом и микросервисами, а между разными моделями дальнейшего развития собственной ИТ-экосистемы.

С чего начинается выбор новой платформы

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

По сути, мы рассматривали три сценария:

1. продолжать развивать существующую систему;

2. полностью разрабатывать собственное решение;

3. искать платформу на рынке.

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

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

Почему список требований оказался важнее списка функций

Дальше мы постарались максимально абстрагироваться от конкретных продуктов.

Вместо этого команда сначала описала, что именно должна уметь будущая система.

Мы буквально прошли по всем подразделениям компании — финансам, юридическому блоку, HR, бизнес-направлениям, ИТ. Собрали процессы, которые так или иначе связаны с документооборотом, разложили их на отдельные функции и получили более 200 функциональных требований.

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

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

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

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

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

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

После выбора платформы начинается настоящая работа

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

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

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

Именно поэтому я бы назвал подобные проекты не миграцией ЭДО, а редизайном внутренних процессов компании.

Новая система очень быстро показывает проблемы старой

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

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

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

Сопротивляются не изменениям. Сопротивляются дополнительной работе

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

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

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

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

Гибкость проверяется уже после запуска

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

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

Однако, произошли существенные перемены. Если раньше серьезные изменения могли занимать месяцы, то сейчас мы выпускаем новые версии практически постоянно. В отдельные периоды количество релизов превышало количество рабочих дней в месяце. Это стало возможным благодаря современной архитектуре платформы и совместной работе нашей команды и специалистов ITFB Group. Часть изменений выполнялась силами интегратора, часть — уже собственной командой Билайна. Именно такая модель позволила быстро реагировать на замечания пользователей и постепенно развивать систему без длительных циклов ожидания. На мой взгляд, именно здесь проявляется реальная ценность гибкой архитектуры.

Следующий этап развития — искусственный интеллект

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

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

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

Что бы я сделал по-другому, если бы начинал проект сегодня

Если бы сегодня пришлось запускать этот проект заново, несколько вещей мы точно сделали бы иначе.

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

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

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

При этом есть вещь, которую мы точно не стали бы менять. Мы снова выбрали бы путь пересмотра процессов, а не их механического переноса в новую систему. Именно это решение оказалось самым сложным во всем проекте, но именно оно принесло наибольшую пользу бизнесу.

Какой из этого вывод?

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

1. Есть ли в компании собственная ИТ-команда, которая сможет развивать систему дальше?
2. Готов ли бизнес пересматривать процессы, а не переносить их "как есть"?
3. Готова ли организация инвестировать время в повышение качества данных?
4. Есть ли понимание, кто действительно владеет процессами, которые предстоит менять?
5. И наконец, готова ли компания воспринимать внедрение новой системы документооборота не как ИТ-проект, а как инструмент организационных изменений?

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