Enterprise-системы: что это, как выбирать и где заканчивается готовое

Класс большой, и в разговоре его обычно сводят к ERP. Карта того, что бывает и когда потребность возникает:

Слово enterprise в названии не значит ничего. Значат три вещи, которые стоит проверять на демонстрации.

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

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

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

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

Порядок решений, который экономит основную часть бюджета.

Шаг 1. Описать процесс, который болит. Не «нам нужна ERP», а «заявка от клиента идёт четыре дня, потому что её трижды переносят руками между таблицами».

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

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

Шаг 4. Определить глубину. Одно и то же требование реализуется на разной глубине: отчёт по продажам может быть выгрузкой в Excel, набором готовых отчётов или BI-витриной с расписанием рассылок. Разница в трудозатратах — десятки раз.

Шаг 5. И только теперь смотреть на продукты. С описанным процессом, цифрами и понятной глубиной демонстрация превращается из презентации в проверку: попросите показать ваш сценарий, а не типовой.

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

Что просить на демонстрации

Презентации вендоров похожи друг на друга, поэтому приходить стоит со своим сценарием и пятью вопросами:

• Покажите мой процесс, а не типовой. Ваш неудобный случай: частичная отгрузка, возврат, пересчёт в занятой зоне, сделка с индивидуальной ценой.
• Как система отдаёт данные наружу. Документированный API, обмен по расписанию, вебхуки — или только выгрузка в Excel руками.
• Что будет с нашими доработками при обновлении платформы. Ответ «всё сохранится» без объяснения механизма — плохой знак.
• Как считается рост. Плюс пятьдесят пользователей, второй склад, филиал в другом регионе: покажите стоимость не старта, а третьего года.
• Дайте контакт клиента с похожим ландшафтом. Не логотип на слайде, а руководителя, которому можно позвонить и спросить про сроки внедрения.

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

Работающая архитектура почти всегда выглядит одинаково: ядро учёта, специализированные системы вокруг, единые справочники и обмен.

Ядро. Одна система — источник истины по финансам и материальным потокам. В России это чаще всего экосистема 1С: на неё приходится порядка 70–80% рынка ERP, а сам рынок оценивается примерно в 110 млрд ₽ с ростом около 20% в год.

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

Мастер-данные. Один справочник товаров, контрагентов и подразделений на весь контур, с правилами, кто создаёт и кто утверждает записи.

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

Принцип, который держит всю схему: у каждой сущности одна система-владелец. Заказ создаётся в одном месте, остаток считается в одном месте, карточка сотрудника ведётся в одном месте. Остальные читают. Как только право на запись появляется у двух систем, начинается расхождение, которое потом объясняют вручную на каждой сверке.

Люди. Рабочие места исполнителей — кладовщика, мастера, менеджера. Их обычно проектируют последними, хотя именно от них зависит качество данных во всём контуре: удобный экран даёт достоверные цифры, неудобный — «прочее» во всех полях.

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

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

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

Простая арифметика, которая объясняет, почему ландшафт становится дорогим. Прямых связей между n системами может быть до n(n−1)/2: при пяти системах — до десяти, при десяти — до сорока пяти. Каждая связь требует форматов, обработки ошибок, мониторинга и поддержки при обновлениях.

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

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

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

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

Практическая картина: базовые функции российские продукты закрыли, и рынок это подтверждает — тот же ERP-контур на 110 млрд ₽ с доминированием экосистемы 1С, рынок BPM-систем на 33–34 млрд ₽ со зрелой тройкой платформ. Но главный барьер, о котором говорят сами интеграторы, — не отсутствие модулей, а недостаточная глубина их реализации.

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

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

• 1. Инвентаризация. Какие системы стоят, какие процессы закрывают, где данные и какие обмены уже есть. Заодно выясняется, что часть купленной функциональности не используется.
• 2. Целевая модель процессов. Как должно работать: роли, шаги, точки принятия решений. Самый долгий по согласованиям этап и единственный, который нельзя делегировать подрядчику целиком.
• 3. Решение по каждому блоку. Готовое, платформа, надстройка или разработка — по глубине требований и цене владения.
• 4. Мастер-данные. Справочники, ведущие системы, правила сопоставления. До интеграций, а не после.
• 5. Пилот на одном процессе или подразделении. С измеримым результатом и сроком в недели.
• 6. Интеграции и обмен. С журналом, повторами и мониторингом.
• 7. Тиражирование и передача владельцу. Кто отвечает за систему, кто меняет правила, кто обучает новых сотрудников.

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

Причины повторяются от проекта к проекту, и все они организационные, а не технические.

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

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

Не назначили владельца. Без человека с полномочиями решения не принимаются, а спорные места остаются висеть до приёмки.

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

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

Оставили обмен без наблюдаемости. Обмен встал в пятницу, узнали в понедельник от клиента, разбирались до среды.

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

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

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