Правильный порядок такой: сначала называется боль одной фразой, потом считается, сколько она стоит в месяц, и только потом подбирается класс системы. Заявки теряются — CRM. Склад не знает, где что лежит — WMS. Документы согласуются неделю — СЭД. Три системы дают три разные цифры — BI. Решения одного подразделения ломают планы другого — тогда и только тогда разговор про ERP. А если боль названа как «хотим порядок и чтобы всё было в одном месте», покупать пока нечего: это запрос на регламент и на чистые данные, и он закрывается в десять раз дешевле любой системы.
Так выбирают потому, что классы систем — это роли в контуре компании, а не наборы функций. У каждого класса есть модуль-сосед в чужой системе: в CRM бывает склад, в учётной системе бывает воронка продаж, в СЭД бывает регистрация счетов. Модуль-сосед закрывает верхнюю часть задачи и почти никогда — нижнюю, поэтому сравнение по спискам возможностей показывает, что подходит всё, и выбор в итоге делается по симпатии к менеджеру.
Все суммы ниже — порядок величин на сентябрь 2026 года: цены лицензий, часа внедрения и сопровождения меняются несколько раз в год и зависят от региона и подрядчика. Сверяйте на дату закупки. Бюро не является партнёром ни одного вендора.
Почему выбор по списку возможностей заканчивается одинаково
Сравнительные таблицы функций пишут вендоры, и они устроены так, чтобы строка «есть» стояла у продукта автора. В результате читатель получает ощущение, что системы отличаются деталями, и переносит решение на цену или на удобство интерфейса — то есть на два фактора, которые через полгода работы почти не имеют значения. Настоящая разница между классами проявляется в трёх местах, и ни одно из них в таблицу функций не попадает.
- Глубина, а не наличие. «Управление складом» есть и в CRM, и в учётной системе, и в WMS. Но задание на отбор с маршрутом по ячейкам, приёмка по нескольким штрихкодам и инвентаризация без остановки зоны есть только в третьей. Наличие пункта в списке не говорит ни о чём.
- Что система требует от компании. CRM требует описанных этапов сделки, WMS — размеченных адресов и терминалов, BI — согласованных справочников. Система, поставленная без этого, показывает данные, которых нет, и это дороже отсутствия системы.
- Цена владения, а не покупки. Лицензия — меньшая часть счёта. Основные деньги уходят на внедрение, поддержку, доработки после запуска и содержание обменов с соседними системами. Сравнивать классы и вендоров имеет смысл только по сумме за три года.
Чтобы перейти от ощущений к цифрам, боль формулируется тремя вопросами. Что именно теряется — деньги, время, клиент, товар. Сколько раз в месяц это происходит. Сколько стоит один случай. Три ответа дают месячную цену боли, и дальше выбор превращается в арифметику: класс, который закрывает эту боль, должен стоить в обслуживании заметно меньше, чем она.
Горизонтальная схема в чертёжном стиле из трёх зон слева направо. Зона 1 «боль»: три вопроса в рамках — «что теряется», «сколько раз в месяц», «сколько стоит один случай». Зона 2 «цена боли в месяц»: одна плашка со знаком ₽. Зона 3 «класс»: шесть подписанных блоков — CRM, WMS, СЭД, BI, ERP, «ничего», к ним ведут стрелки из зоны 2. Под схемой перечёркнутая стрелка в обратную сторону с подписью «от списка возможностей к боли — так не работает». Приглушённая палитра, подписи по-русски.
Пять точек боли и класс под каждую
- 1Заявки теряются, а решения по клиенту принимаются по памяти
Звонок был, договорённость была, а чем закончилось — помнит только менеджер, и то до отпуска. Повторные касания не делаются, причины отказов не собираются, руководитель видит выручку, но не видит, что происходит до неё. Это CRM: её работа — память о клиенте и дисциплина этапов. Она не приведёт лидов и не заставит звонить, но перестанет терять то, что уже пришло. Условие: этапы сделки должны быть описаны до внедрения, иначе воронка окажется декоративной. Что класс делает и чего от него ждать не стоит, разобрано в материале CRM-система: что это и что она не решит.
- 2Склад знает, где что лежит, только пока на смене нужный человек
Отбор занимает вдвое дольше, чем должен, приходит пересорт, инвентаризация останавливает работу на два дня, а новичок выходит на нормальную скорость месяц. Это WMS: адресное хранение, задания кладовщикам, маршрут отбора, приёмка и пересчёт без остановки зоны. Условие жёсткое: адреса ячеек, терминалы сбора данных и связь в зоне хранения должны появиться до системы, а не после. Порог по объёму и список того, что нужно на складе до внедрения, — в материале WMS-система: что это и когда складу без неё тяжело.
- 3Документ согласуют неделю, и никто не знает, у кого он сейчас
Договоры ходят по почте и чатам, версии множатся, поручения по итогам совещаний забываются, а найти прошлогодний акт можно только через человека, который его подписывал. Это СЭД — внутренний контур: маршруты согласования, регистрация, версии, архив. Главная путаница класса: СЭД работает внутри компании, а обмен документами с контрагентами — это ЭДО, отдельный контур с оператором и подписями. Где проходит граница между двумя контурами, разобрано в материале СЭД: система документооборота внутри компании.
- 4Три системы дают три разные цифры, а месяц закрывается неделю
Выручка в CRM не совпадает с выручкой в учётной системе, остатки в отчёте не совпадают с остатками на складе, а сводная таблица для собственника собирается руками и живёт один день. Это BI — слой отчётности поверх существующих систем, а не замена им. Условие, без которого получится красивый дашборд по неверным цифрам: согласованные справочники и одно определение каждой метрики на всю компанию. Что должно быть готово до первого дашборда, разобрано в материале BI-система: отчётность и дашборды.
- 5Решения одного подразделения регулярно ломают планы другого
Продажи подтвердили срок — переверстался график цеха. Цех сдвинул выпуск — поехала закупка. Поставщик отказал — срок клиенту меняется задним числом. Каждая такая связь называется узлом планирования, и когда их становится много, никакая связка отдельных систем не спасает. Это ERP и только она — но сначала узлы надо посчитать: до четырёх единый контур избыточен. Метод счёта и модельная смета — в материале ERP-система: что это и нужна ли она вашей компании.
Шестая боль встречается реже, но её ни с чем не спутать: цех живёт по бумажным сменным заданиям, а рейсы — в тетради у логиста. Факт по операциям вводится задним числом, простои и брак никто не считает, а срок перевозки известен только после звонка водителю. Здесь работают MES для цеха и TMS для перевозок — классы исполнения, а не планирования. Признаки, при которых MES не нужна и хватает учёта выработки, собраны в материале когда MES-система не нужна.
Сводная таблица: боль, класс, условие и ошибка
Четвёртая колонка здесь важнее первых трёх: в ней стоит признак, по которому видно, что класс выбран неверно. Именно на этих признаках проекты и разваливаются — не на функциях, а на несовпадении класса с задачей.
| Что болит | Класс | Что должно быть до покупки | Признак, что класс выбран неверно |
|---|---|---|---|
| Заявки теряются, решения по клиенту принимаются по памяти | CRM | Описанные этапы сделки и человек, отвечающий за воронку | От системы ждут расчёта прибыли по сделке — это учётный контур, а не CRM |
| Долгий отбор, пересорт, инвентаризация останавливает склад | WMS | Размеченные адреса ячеек, терминалы сбора данных, связь в зоне хранения | Позиций несколько сотен и один кладовщик — хватит адресного хранения в учётной системе |
| Согласования непредсказуемы, версии теряются, поручения забываются | СЭД | Маршруты согласования на бумаге и ответственные по ролям, а не по фамилиям | Задача на самом деле про обмен документами с контрагентами — это ЭДО, другой контур |
| Цифры не сходятся, сводный отчёт собирается руками | BI | Согласованные справочники и одно определение каждой метрики | Данные в источниках грязные — дашборд покажет ошибку быстрее, но не исправит её |
| Решения подразделений ломают планы друг друга | ERP | Пять и больше узлов планирования и люди на ведение нормативов | Болит один участок из пяти — точечная система дешевле в два-три раза |
| Цех по бумажным заданиям, рейсы в тетради | MES или TMS | Точки отметки факта в цехе или дисциплина оформления рейса | Факт вводится задним числом — система будет считать по тому, что вспомнили, а не по тому, что было |
Считаем боль в деньгах — иначе класс не выбрать
Класс без объёма ничего не говорит: одна и та же CRM на разных потоках заявок окупается за восемь месяцев или не окупается вовсе. Ниже — модельный расчёт по самому частому запросу. Вводные: 180 входящих заявок в месяц, шесть менеджеров, средний чек 45 000 ₽, маржа 25 %, конверсия в сделку 20 %, теряется без единой базы 12 % обращений.
Две вещи в этом расчёте принципиальны. Первая — коэффициент «возвращается половина»: система не возвращает все потерянные обращения, она возвращает те, что терялись по забывчивости, а не по отсутствию спроса. Любой расчёт, где потери возвращаются полностью, завышен вдвое, а деньги появляются только если по возвращённым заявкам действительно звонят. Вторая — экономия времени взята наполовину: освободившийся час менеджера превращается в деньги только если ему есть куда его деть. Как строить такие расчёты, чтобы они выдерживали проверку, разобрано в материале как посчитать окупаемость автоматизации.
График в чертёжном стиле. Горизонтальная ось — «входящих заявок в месяц» с отметками 40, 80, 120, 180. Вертикальная — «срок окупаемости, месяцев» от 0 до 24. Кривая падает от 17 месяцев при 40 заявках до 8,3 месяца при 180. Горизонтальная штриховая линия на отметке 12 месяцев подписана «граница, после которой проект обычно не защищают». Точки 40 и 180 подписаны суммами «14 100 ₽ в месяц» и «50 400 ₽ в месяц». Подписи по-русски, приглушённая палитра.
Если болит сразу всё: три очереди
У компании, которая дозрела до вопроса о системе, обычно болит не одно место, а четыре. Соблазн взять единый контур и закрыть всё разом понятен, и почти всегда он дороже и рискованнее, чем три очереди подряд. Порядок очередей обратный интуитивному: начинают не с самого шумного участка, а с того, где деньги теряются на входе.
- 1Деньги на входе. Заявки, звонки, клиенты. Это самая короткая очередь, самая дешёвая и с самым быстрым эффектом, который видно без отчётов: перестают теряться обращения. Она же приучает компанию работать в системе, а не рядом с ней, и это главный результат первой очереди, а не функции.
- 2Деньги в объёме. Склад, производство, закупка — там, где потери измеряются процентами от оборота. Очередь длиннее и дороже, требует подготовки на местах: адреса, терминалы, точки отметки факта. Запускать её до первой очереди нельзя: если компания не привыкла вносить данные, склад сгенерирует не порядок, а вторую реальность рядом с настоящей.
- 3Деньги в отчётности. BI поверх того, что уже собрано, или единый контур, если к этому моменту узлов планирования действительно много. Третья очередь честнее всего показывает результат первых двух — и часто выясняется, что ERP уже не нужна, потому что боль ушла вместе с порядком в данных.
Причина не в бюджете, а в людях: во время внедрения ключевые сотрудники заняты проектом — сверкой данных, приёмкой, обучением, двойным вводом. Двух проектов одновременно они не выдерживают, и оба заканчиваются формальной приёмкой без реальной работы. Разумный шаг между очередями — квартал: он нужен не подрядчику, а компании, чтобы система успела стать привычкой. Сроком между очередями жертвуют первым, и это самая частая причина, по которой вторая система остаётся пустой.
Горизонтальная лента времени в чертёжном стиле, разделённая на три блока с промежутками. Блок 1 «деньги на входе: заявки и клиенты» с подписью «CRM». Блок 2 «деньги в объёме: склад, производство, закупка» с подписью «WMS или производственный контур». Блок 3 «деньги в отчётности» с подписью «BI, а при пяти и более узлах планирования — ERP». Между блоками промежутки подписаны «квартал на привыкание». Под лентой перечёркнутая пара параллельных блоков с подписью «два проекта одновременно — оба формально приняты и не работают». Подписи по-русски.
Когда правильный ответ — ничего не покупать
Это не фигура речи и не скромность подрядчика. Заметная часть запросов на систему приходит из ситуации, где системе нечего автоматизировать: процесса нет, данные грязные, а ответственного за результат не существует. Система в такой компании фиксирует хаос и делает его дороже, потому что обойти его вручную теперь нельзя. Шесть признаков, при которых покупку стоит отложить.
- Процесс не описан, и два человека описывают его по-разному. До внедрения это разговор на час, после — переделка настроек за деньги.
- У процесса нет владельца. Если на вопрос «кто решает, как это должно работать» нет ответа фамилией, настройки будут меняться по кругу вслед за мнением последнего совещания. Владелец процесса — это фамилия и полномочия менять правила, а не строка в оргструктуре.
- Справочники грязные. Дубли клиентов, номенклатура в трёх написаниях, контрагенты без реквизитов. Всё это переезжает в новую систему вместе с вами и там дорожает. Чистить их всё равно придётся, вопрос только в том, до внедрения по своей ставке или во время него по ставке подрядчика.
- Объём ниже порога. Десять заявок в неделю, триста позиций на складе, два согласования в месяц. На таких числах любая система обслуживает сама себя.
- Боль разовая. Один провальный квартал или один скандальный заказ — это не основание для класса систем. Считайте частоту, а не яркость воспоминания.
- Компания в перестройке. Меняются ассортимент, направления, структура. Фиксировать в системе то, что изменится через квартал, — самый дорогой способ потратить бюджет.
Альтернатива покупке — не бездействие. Есть вполне конкретный набор работ, который снимает ту часть боли, которую система всё равно не снимет, и стоит на порядок дешевле. Он же делает будущее внедрение дешевле, потому что данные и процессы к тому моменту уже в порядке.
Проверяется результат просто: через два месяца после такой работы боль формулируется одной фразой с числом — «теряем 21 заявку в месяц» вместо «у нас бардак с заявками». Если фраза появилась, вы готовы покупать класс. Если не появилась, покупать было бы рано в любом случае. Почему этот шаг идёт первым, а не считается подготовительным, разобрано в материале порядок в процессах до автоматизации.
Схема-развилка в чертёжном стиле. Слева вход с подписью «запрос: нужна система». В центре ромб проверки с текстом «боль формулируется фразой с числом». Левая ветка «нет» ведёт к блоку «навести порядок: процессы, справочники, владелец, отчёты — 260 000 ₽, 6–8 недель», от него обратная стрелка к ромбу с подписью «через 2 месяца проверить снова». Правая ветка «да» ведёт к ряду из пяти блоков классов — CRM, WMS, СЭД, BI, ERP. Приглушённая палитра, подписи по-русски.
Порядок цены по классам
Вилки ниже — порядок величин на сентябрь 2026 года, первый год целиком: лицензии плюс внедрение плюс сопровождение. Разброс внутри класса больше, чем разница между соседними классами, и определяется он не системой, а числом доработок, числом связок и качеством исходных данных. Подробный разбор с коэффициентами сопровождения и моделями оплаты подрядчика — в материале сколько стоит внедрение системы.
| Класс | Лицензии в год | Внедрение разово | Первый год всего |
|---|---|---|---|
| CRM | 60 000 – 300 000 ₽ | 150 000 – 900 000 ₽ | 210 000 – 1 200 000 ₽ |
| СЭД | 80 000 – 400 000 ₽ | 200 000 – 900 000 ₽ | 280 000 – 1 300 000 ₽ |
| BI | 0 – 500 000 ₽ | 250 000 – 1 200 000 ₽ | 250 000 – 1 700 000 ₽ |
| TMS | 100 000 – 600 000 ₽ | 300 000 – 1 500 000 ₽ | 400 000 – 2 100 000 ₽ |
| WMS | 150 000 – 900 000 ₽ | 600 000 – 3 000 000 ₽ | 750 000 – 3 900 000 ₽ |
| MES | 200 000 – 1 200 000 ₽ | 800 000 – 4 000 000 ₽ | 1 000 000 – 5 200 000 ₽ |
| ERP | 300 000 – 1 500 000 ₽ | 1 200 000 – 6 000 000 ₽ | 1 500 000 – 7 500 000 ₽ |
Из таблицы видно главное: лицензия почти нигде не является основной статьёй. Между классами разница не столько в цене покупки, сколько в цене сопровождения и в том, сколько работы требуется от самой компании до старта. И есть ещё одна статья, которой в таблице нет: содержание обменов между системами — около 129 600 ₽ в год на одну связку. При трёх связках это почти 400 000 ₽ ежегодно, и именно из-за этой строки набор из пяти-шести систем внезапно догоняет по цене единый контур. Расчёт построчно и порог, после которого связка выгоднее единой платформы, — в материале одна система на всё или несколько связанных.
Как проверить решение до покупки
Пять проверок, каждая из которых делается до подписания договора и любая из которых дешевле, чем год работы в неподходящей системе.
- 1Свой сценарий на демонстрации, а не презентация вендора
Приносите свой случай: заказ с тремя позициями и частичной отгрузкой, договор с двумя согласующими и правкой на третьем круге, приёмку с пересортом. Презентация показывает систему в условиях, где она хороша; ваш сценарий показывает её там, где вам с ней жить.
- 2Пилот на одном участке с датой и критерием приёмки
Один склад, один отдел, один тип документа. Заранее записанный критерий: что должно получиться и к какому числу. Пилот без критерия всегда заканчивается фразой «в целом работает», и по ней решение не принимается.
- 3Выгрузка своих данных до внедрения, а не после
Возьмите настоящую номенклатуру и настоящих контрагентов и попробуйте загрузить. Это единственный способ узнать реальное состояние справочников до того, как за него придётся платить по часам подрядчика.
- 4Три пункта в договоре
Бесплатная выгрузка данных в открытом формате по требованию, потолок индексации стоимости в процентах и приёмка по очередям с оплатой следующей после сдачи предыдущей. Без первого пункта у вас не будет переговорной позиции через два года, без третьего — риск потерять весь бюджет на неудачной первой очереди.
- 5Счёт за три года, а не цена лицензии
Складывайте лицензии за три года, внедрение, сопровождение, планируемые доработки и содержание обменов. Сравнивайте классы и вендоров только по этой сумме. Разница между вариантами по цене покупки и по цене владения регулярно оказывается разнонаправленной.
Класс системы выбирается по тому, что болит, а вендор — по тому, кто это внедряет. Перепутать порядок дороже, чем ошибиться в обоих.
Сформулируйте боль фразой с числом и назовите, сколько стоит один случай и сколько раз в месяц он происходит. Если это получилось — идите выбирать класс и считать окупаемость. Если вместо фразы получается «хотим, чтобы всё было в одном месте», то первые 260 000 ₽ надо потратить не на лицензии, а на процессы, справочники и владельца. Это не отсрочка покупки, а её удешевление.
И последнее: выбор класса — самая дешёвая и самая результативная часть всего проекта. Он делается за один вечер, на листе бумаги, без подрядчика и без коммерческих предложений, и он определяет порядок цены на годы вперёд. Всё остальное — тендеры, сравнения вендоров, торг по скидке — влияет на итог в разы меньше, чем ответ на первый вопрос: что именно у вас болит и сколько это стоит в месяц.
