Прямой ответ на вопрос заголовка: на простых процессах дешевле единая платформа, на сложных — набор специализированных систем, а разница между сценариями в обоих случаях укладывается в 7–16 % и почти никогда не оправдывает переезд ради неё. Расходы не исчезают при переходе от одного варианта к другому — они меняют место. В единой платформе вы платите за доработку слабых модулей, в наборе систем — за связки между ними и за их содержание.
Слово «зоопарк» в этом разговоре работает как аргумент, хотя аргументом не является. Пять систем, между которыми налажены обмены и у каждой есть хозяин, — это не зоопарк, а нормальная архитектура. Зоопарк — это когда никто не может сказать, где лежит первичная версия справочника контрагентов, и три отдела ведут его параллельно. Такая проблема не лечится покупкой шестой системы, в которую надо будет свести первые пять.
Ниже — две модельные сметы за 36 месяцев на одной и той же компании в 50 человек, честная годовая цена одной интеграционной связки, правило, по которому проводится граница между ядром и спутниками, и раздел про то, во что обходится ошибка в любую сторону.
Правило ядра: где проходит граница
Спор «одна система или несколько» решается не целиком, а по слоям. Есть слой, который обязан быть единым, и есть слой, где множественность безвредна. Граница проходит по деньгам: учёт, взаиморасчёты, себестоимость и отчётность живут в одной системе, потому что у денег не может быть двух версий истины. Всё, что вокруг — продажи, задачи, документы, поддержка, найм, аналитика, — может быть отдельным, если налажен обмен.
Система, в которой хранится единственная достоверная версия справочников контрагентов и номенклатуры, движения денег и складских остатков. В российской практике это почти всегда конкретная конфигурация 1С. Ядро не выбирают по удобству интерфейса — его выбирают по тому, откуда сдаётся отчётность и где сходится сверка.
Почему граница именно здесь. Расхождение в CRM обнаруживается на планёрке и стоит времени менеджера. Расхождение в учёте обнаруживается при закрытии месяца, стоит времени бухгалтера и главного бухгалтера и иногда стоит уточнённой декларации. Второй тип расхождений дороже первого на порядок, поэтому дублировать деньги в двух системах нельзя ни при какой экономии на лицензиях.
На практике правило раскладывается в четыре пункта. Первые два запрещают дублирование, вторые два его разрешают — и именно на этой границе стоит проверять любое предложение поставщика, который обещает «всё в одном окне».
- Справочник контрагентов рождается в ядре. В спутниках он только читается и дополняется своими полями — сегментом, ответственным, историей касаний. Обратная запись разрешена ровно для одного поля: идентификатора связи. Всё остальное создаёт вторую версию правды.
- Номенклатура, остатки и цены рождаются в ядре. Спутник может показывать их и резервировать, но не менять. Нарушение этого пункта — самая частая причина расхождений, которые потом разбирают по четыре часа за случай.
- Клиент, переписка, воронка и касания могут жить где угодно. Здесь дублирование безвредно: если два инструмента по-разному считают активных клиентов, ошибка стоит планёрки, а не декларации.
- Задачи, документы, знания и обращения тоже могут быть отдельными. Единственное требование — ссылка на сущность ядра: у задачи есть номер заказа, у обращения есть контрагент. Без этой ссылки любая аналитика по процессу собирается вручную.
Схема из центрального круга и четырёх спутников. Центр подписан «Ядро: учёт, деньги, склад — одна система», внутри перечислено «контрагенты, номенклатура, остатки, взаиморасчёты». Вокруг четыре блока: «Продажи и клиенты», «Задачи и документы», «Поддержка и обращения», «Аналитика». Каждый соединён с ядром двусторонней стрелкой с подписью «обмен, 129 600 ₽ в год на содержание». Пунктирная граница отделяет ядро от спутников и подписана «здесь дублирование запрещено». Чертёжный стиль, подписи по-русски.
Что на самом деле стоит одна связка
Главная ошибка обеих смет — считать интеграцию разовой покупкой. Разработка обмена действительно разовая: 150 000–220 000 ₽ за связку средней сложности. А дальше начинается содержание, и оно не заканчивается никогда, потому что обе стороны связки продолжают меняться. Ниже — годовая цена одной живой связки при ставке 1 200 ₽ за час работы инженера.
В смете подрядчика она отсутствует, потому что относится к эксплуатации, а не к проекту. В бюджете ИТ она растворяется в фонде оплаты труда. В итоге компания три года платит 388 800 ₽ в год за то, чего формально нет ни в одном документе, и удивляется, почему автоматизация не окупается по расчёту.
Это не аргумент против интеграций — без них не работает ни один сценарий, включая единую платформу: она тоже обменивается с 1С. Это аргумент за то, чтобы связок было ровно столько, сколько нужно, и чтобы у каждой был мониторинг. Как устроен такой мониторинг и какие четыре датчика ставятся на обмен, мы разбирали в материале мониторинг автоматизации. Полный перечень типовых связок и что в них передаётся — на странице интеграции систем.
Круговая диаграмма из четырёх секторов с подписями и суммами: «Мониторинг очереди ошибок — 62 400 ₽» (самый крупный сектор), «Расследование расхождений — 28 800 ₽», «Починка после обновлений — 19 200 ₽», «Правки при изменении полей — 19 200 ₽». В центре подпись «129 600 ₽ в год, одна связка». Сбоку приписка «три связки — 388 800 ₽ в год». Чертёжный стиль, подписи по-русски.
Две сметы за 36 месяцев: компания на 50 человек
Модельная компания: 50 сотрудников, из них 30 работают в системах — 12 в продажах, 8 на складе и в логистике, 6 в финансах, 4 в кадрах и администрировании. Учёт ведётся в 1С и остаётся там в обоих сценариях: это ядро, и оно не участвует в сравнении. Сравниваются надстройки над ядром.
Сценарий А — единая платформа: корпоративный портал, в котором есть CRM, задачи, документы, база знаний и обращения, плюс обмен с 1С. Сценарий Б — три специализированные системы: CRM для продаж на 12 пользователей, сервис задач и документов на 30 пользователей, система обращений на 6 пользователей, и три обмена между ними и ядром. Лицензии взяты как модельный ориентир на сентябрь 2026 года; тарифные линейки меняются, проверяйте прайс на день расчёта.
| Статья расходов за 36 месяцев | Единая платформа | Три системы + 1С |
|---|---|---|
| Лицензии | 504 000 ₽ | 1 382 400 ₽ |
| Внедрение и настройка | 850 000 ₽ | 620 000 ₽ |
| Доработка слабых модулей за три года | 1 200 000 ₽ | — |
| Разработка обменов | 220 000 ₽ (один с 1С) | 560 000 ₽ (три связки) |
| Содержание обменов | входит в администрирование | 1 166 400 ₽ |
| Администрирование и сопровождение | 1 260 000 ₽ | 1 008 000 ₽ |
| Обучение и сопровождение изменений | 180 000 ₽ | 150 000 ₽ |
| Итого | 4 214 000 ₽ | 4 886 800 ₽ |
Разрыв составляет 672 800 ₽ за три года, или 16 % — в пользу единой платформы. Но заметьте, чем он создан: не превосходством продукта, а лицензиями. Три отдельные подписки дают 1 382 400 ₽ против 504 000 ₽ у платформы, и одна эта строка перекрывает всю разницу с запасом. Всё остальное в таблице играет в обратную сторону: внедрение платформы дороже на 230 000 ₽, доработка модулей добавляет 1 200 000 ₽, а администрирование выше на 252 000 ₽.
Две составные колонки на общей оси в рублях. Левая подписана «Единая платформа — 4 214 000 ₽», сегменты снизу вверх: лицензии 504 000 ₽, внедрение 850 000 ₽, доработка модулей 1 200 000 ₽ (сегмент выделен штриховкой), обмен с 1С 220 000 ₽, администрирование 1 260 000 ₽, обучение 180 000 ₽. Правая подписана «Три системы + 1С — 4 886 800 ₽», сегменты: лицензии 1 382 400 ₽ (выделен штриховкой), внедрение 620 000 ₽, обмены 560 000 ₽, содержание обменов 1 166 400 ₽, администрирование 1 008 000 ₽, обучение 150 000 ₽. Между колонками скобка «разница 672 800 ₽, 16 %». Чертёжный стиль, подписи по-русски.
Чего в обеих сметах нет — стоит проговорить отдельно, потому что эти статьи всплывают на третьем месяце проекта. В них не учтено время ваших сотрудников на приёмку, обучение и наведение порядка в справочниках: по опыту это 80–160 часов руководителей и администратора за проект в любом из сценариев. Не учтена просадка производительности в первые недели после переключения — она посчитана отдельно в разделе про цену ошибки. Не учтены внешние расходы, одинаковые для обоих вариантов: телефония по минутам, рассылки, распознавание документов, хранение архива. И не учтён самый неприятный сценарий — оплата обоих вариантов одновременно, когда платформа уже куплена, а специализированные системы ещё не отключены.
Теперь усложним процессы, не трогая численность. Та же компания получает три склада вместо одного, продажи на двух площадках и небольшой производственный участок. Число людей не изменилось, изменилось количество исключений, которые система обязана уметь обрабатывать. В сценарии А это бьёт по одной строке — доработке модулей: она растёт с 1 200 000 до 3 100 000 ₽. В сценарии Б добавляется четвёртая система со своей связкой.
| Сценарий процессов | Единая платформа | Набор специализированных систем | Кто дешевле |
|---|---|---|---|
| Простые: один склад, одна площадка, оборот до ~500 млн ₽ в год | 4 214 000 ₽ | 4 886 800 ₽ | Платформа на 672 800 ₽, 16 % |
| Сложные: три склада, две площадки, производственный участок | 6 114 000 ₽ | 5 655 600 ₽ | Набор систем на 458 400 ₽, 7,5 % |
Оборот в первой строке — косвенный признак, а не критерий. Настоящий критерий — число процессов, в которых модуль платформы закрывает меньше двух третей задачи. Пока таких процессов один-два, доработка дешевле отдельной подписки. Когда их становится четыре и больше, каждый следующий обходится дороже предыдущего, потому что доработки начинают конфликтовать между собой и с обновлениями платформы. Оборот просто коррелирует с числом исключений, поэтому и попал в таблицу.
Правило 60 на 40: признак ложной экономии
Самая частая формулировка при выборе единой платформы звучит так: «модуль закрывает основное, остальное допишем». Проверим её на деньгах. Возьмём один процесс — обращения клиентов — и посчитаем два пути: дописать недостающие 40 % в модуле платформы или поставить отдельную систему на 6 пользователей вместе с полной ценой связки.
Вывод из расчёта прямой: дописывание последних 40 % не экономит ничего. Оно выглядит дешевле, потому что сравнивают разовую доработку в 620 000 ₽ с трёхлетней суммой подписки, а надо сравнивать одинаковые горизонты. Если модуль закрывает меньше двух третей задачи — ставьте отдельную систему и стройте связку; если больше — дописывайте.
Сравнение в две колонки на одной оси в рублях. Левая подписана «Дописать 40 % в модуле — 1 148 000 ₽», строки: разработка 620 000 ₽, сопровождение 288 000 ₽, правки после обновлений 240 000 ₽. Правая подписана «Отдельная система со связкой — 1 072 800 ₽», строки: лицензии 324 000 ₽, внедрение 180 000 ₽, разработка связки 180 000 ₽, содержание связки 388 800 ₽. Между колонками подпись «разница 75 200 ₽» и стрелка вниз с пометкой «чем меньше готовность модуля, тем шире разрыв». Чертёжный стиль, подписи по-русски.
Риск одного поставщика и что писать в договоре
У единой платформы есть расход, которого нет в смете: концентрация зависимости. Пока всё работает, он равен нулю. Он проявляется в трёх событиях, и все три случаются не по вашей воле: поставщик меняет тарифную политику, поставщик перестаёт развивать нужный вам модуль, поставщик меняет условия хранения или выгрузки данных. В наборе специализированных систем то же событие затрагивает один контур из четырёх, и переезд стоит одной подписки плюс одной связки.
Этот риск не устраняется, но ограничивается договором. Пять пунктов, которые имеет смысл вносить до подписания, а не после первого повышения тарифа.
- 1Выгрузка данных в открытом формате по требованию заказчика: перечень сущностей, формат, срок предоставления и то, что услуга бесплатна. Без этого пункта «вынести данные» превращается в отдельный проект на 200 000–400 000 ₽.
- 2Фиксация тарифа на срок договора и потолок ежегодной индексации в процентах. Формулировка «тариф может быть изменён поставщиком» означает, что смету владения за три года составить нельзя.
- 3Права на доработки: исключительные права на код, написанный за ваши деньги, принадлежат вам, исходники передаются с приёмкой этапа. Для коробочных решений — депонирование исходного кода.
- 4Отдельный SLA на обмены, а не только на доступность платформы. Обмен может стоять сутки при формально работающей системе, и без отдельного пункта это не является нарушением.
- 5Порядок действий при прекращении развития модуля: срок предупреждения, право на возврат части оплаченной подписки, обязанность передать данные модуля в структурированном виде.
Этот риск можно грубо оценить в деньгах и положить в смету третьей строкой. Возьмите долю процессов, которые в случае разрыва с поставщиком придётся переносить, и умножьте на стоимость их повторного внедрения. В модельной компании из этой статьи на платформе живут четыре процесса из пяти, повторное внедрение каждого — 190 000 ₽, вероятность неприятного события за три года оценим консервативно в 20 %. Получается 4 × 190 000 × 0,2 = 152 000 ₽ ожидаемых потерь — примерно четверть той разницы в 672 800 ₽, ради которой платформу и выбирали. В сценарии с набором систем то же событие затрагивает один процесс и даёт 38 000 ₽.
Перед подписанием задайте поставщику один вопрос: «Что именно мы получим на выходе, если через два года решим уйти?» Ответ должен быть перечнем файлов и сроков, а не обещанием «поможем с миграцией». Как формулировать это в договоре, разобрано в материале что должно быть в договоре на разработку.
Сколько стоит ошибка в любую сторону
Типичная ошибка выглядит так. Компания со сложными процессами переходит на единую платформу ради «единого окна». Через восемь месяцев склад начинает вести параллельную таблицу, потому что модуль не умеет частичные отгрузки. Через двенадцать поддержка заводит отдельный ящик, потому что в модуле обращений нет очередей и SLA. К четырнадцатому месяцу принимается решение вынести два процесса обратно в специализированные системы.
Обратная ошибка — набор систем там, где хватило бы платформы, — обходится дешевле и обнаруживается позже. Компания просто платит лишние 672 800 ₽ за три года и тратит время на обмены, которых могло не быть. Это неприятно, но не требует проекта по исправлению: лишнюю систему можно погасить по окончании подписки, а связку выключить. Асимметрия здесь та же, что и во всех сравнениях этого раздела: избыточная архитектура лечится деньгами, недостаточная — переездом.
Два столбца разной высоты на общей оси в рублях. Низкий подписан «разница между сценариями за 36 месяцев — 672 800 ₽». Высокий подписан «разбор платформы на 14-м месяце — 2 240 000 ₽» и разбит на сегменты: «списанная доработка 740 000 ₽», «внедрение двух систем 380 000 ₽», «перенос данных 260 000 ₽», «две связки 360 000 ₽», «параллельная работа 280 000 ₽», «просадка 220 000 ₽». Между столбцами подпись «в 3,3 раза». Чертёжный стиль, подписи по-русски.
Когда зоопарк трогать не надо
Есть ситуация, в которой правильный ответ — не делать ничего, и она встречается чаще двух рассмотренных. Признак простой: системы работают, обмены налажены, у каждой есть хозяин, а желание всё объединить возникло после презентации или после жалобы на то, что «приходится переключаться между окнами». Переключение между окнами стоит нисколько; переезд стоит 2 240 000 ₽.
- Обмены работают, расхождения разбираются в тот же день, и никто не ведёт параллельных таблиц. Это признак здоровой архитектуры, а не зоопарка. Единая платформа здесь решает задачу презентации, а не бизнеса.
- Проблема формулируется как «неудобно», но не переводится в часы или рубли. До того как считать смету, замерьте: сколько раз в неделю сотрудник переключается между системами и сколько минут на это уходит. Часто оказывается 6–10 минут в день, то есть около 30 000 ₽ в год на человека — против семизначного проекта.
- Настоящая боль — в одном процессе из восьми. Тогда это задача про один процесс, а не про архитектуру. Дешевле поставить одну систему или дописать один модуль, чем переносить семь работающих процессов ради восьмого.
- Нет владельца ни у одной из систем. Объединение в этом случае даст одну систему без владельца вместо пяти, и через год она превратится в зомби-систему: формально работает, фактически данные ведут в таблицах. Сначала люди и ответственность, потом платформа.
И последнее, что стоит проверить до любого решения. Обе сметы в этой статье считались на горизонте 36 месяцев, потому что на более коротком горизонте разница между сценариями всегда меньше стоимости перехода. Если вы не готовы планировать на три года, вопрос «одна система или несколько» для вас пока не стоит: методику полного счёта владения мы разбирали в материале стоимость владения автоматизацией.
Зоопарк — это не количество систем, а отсутствие ответа на вопрос, где лежит правда.
