6 иллюзий о внедрении российских ИТ‑систем, которые обходятся бизнесу слишком дорого

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

«Офлайн‑режим» с нюансами

Однако зачастую на этапе внедрения выясняется, что часть компонентов все же имеет сетевые зависимости. Например, авторизация опирается на облачные сервисы, видеосвязь работает через WebRTC, обновления загружаются по HTTPS, а электронная подпись использует SaaS‑модуль. Это не делает платформу «несоответствующей», но меняет исходные ожидания — для полноценной автономности требуется более тщательная проработка архитектуры.

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

Чтобы не столкнуться с неприятными открытиями уже после запуска, стоит заранее запросить у вендора схему развертывания с перечислением всех сетевых точек и зависимостей. Важно понимать, как работает авторизация и подписание в условиях полной изоляции, каким образом будут обновляться компоненты и вестись логи. Полезно потребовать IP‑план и описание режимов функционирования в закрытой среде. Иными словами, нужна прозрачная архитектурная модель, в которой каждое допущение можно проверить до старта проекта.

No‑code не заменяет архитектурный подход

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

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

Интеграции не всегда работают «из коробки»

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

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

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

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

Фоновая функция может оказаться критической

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

У большинства платформ на рынке собственных почтовых серверов нет: они работают как SMTP‑клиенты и используют стороннюю почтовую инфраструктуру — будь то корпоративный сервер компании или облачный сервис. Именно от этой инфраструктуры зависят корректность уведомлений, стабильность доставки, работа шаблонов и поддержка нескольких доменов. Здесь же важен и вопрос логирования: ведется ли журнал ошибок и доставки, кто отслеживает сбои и отвечает за их устранение.

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

Демо не отражает реальных условий

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

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

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

Как выбор сценариев и требований определяет результат внедрения

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

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