Как только в системе управления заказами вы слышите «этого нет в модуле», незаметно начинает копиться счёт. В строке лицензии он никогда не появится. Он нарастает в побочных задачах, которые каждый месяц утекают в Excel, в обходных решениях, живущих в голове одного человека, и в доработках, которые заново ломаются при каждом обновлении версии. Эта статья — именно о таком скрытом счёте и об архитектуре, которая его устраняет: что на самом деле означает ERP/CRM на заказ, как ваши процессы превращаются в код и какую конкретную боль приносит попытка подогнать готовый продукт под себя.

Начнём с примера. Представьте производственную компанию среднего размера: свою продукцию она продаёт и напрямую крупным клиентам, и через сеть примерно из 40 дилеров по всей стране. Часть дилеров получает товар на консигнации (непроданный остаток можно вернуть), у каждой группы дилеров свой уровень цен, а особые правила скидок проходят через трёхуровневую иерархию согласований. Эта компания внедрила известную готовую ERP. Бухгалтерия, НДС и электронные счета-фактуры работали безупречно. Но консигнацию вести было негде. Цены для конкретных дилеров записывали в «пустую текстовую колонку». Согласования скидок в системе не было, поэтому они шли в групповых чатах. Через полгода реальные продажи компании жили уже вне ERP — в «теневой таблице» финансового менеджера. Счёт за лицензию оплачивался вовремя, а настоящую цену компания платила в другом месте.

Это история не о выборе плохой ERP. Это история о том, как правильный инструмент заставили делать не свою работу. Теперь разберём, как устроена эта ловушка.

«Этого нет в модуле, поменяйте процесс»: откуда берутся скрытые затраты

Самая дорогая фраза в любом проекте на готовой ERP или CRM: «Этого в модуле нет, вам нужно изменить процесс». Звучит разумно. В конце концов, такие продукты вобрали в себя «лучшие практики» тысяч компаний, и ваш процесс действительно может оказаться хуже. Но чаще всего эта фраза требует сточить именно тот процесс, который выделяет вас среди конкурентов.

Всё, что даёт вам конкурентное преимущество (модель консигнации, порядок работы дилерской сети, производственный поток под конкретный проект, цепочка согласования сервисных работ), обычно и есть та часть, которой в готовом продукте «нет». Потому что готовый продукт кодирует среднее, а ваше отличие средним не бывает. Меняя процесс, вы теряете не функцию программного обеспечения, а само конкурентное преимущество. Вот настоящие скрытые затраты: не лицензия, а компромисс в процессах.

У такого компромисса четыре классических симптома, и вы, скорее всего, узнаете все:

  • Теневая таблица: То, что система не может вместить, переезжает в «мастер-файл». Со временем этот файл становится настоящим мозгом компании, но его нельзя проверить, для него нет резервных копий, а когда сотрудник, который его ведёт, уходит в отпуск, работа останавливается.
  • Обходные решения, привязанные к людям: «Как это делается, знает только Ольга». Процесс живёт не в ПО, а в голове сотрудника. Это долг знаний, который нельзя ни масштабировать, ни передать.
  • Общение вне системы: Согласования, исключения и переговоры об особых ценах утекают в мессенджеры и электронную почту. Нет ни записи, ни следа, а на вопрос «кто это согласовал?» потом никто не ответит.
  • Доработки, которые ломаются при каждом обновлении: Каждая адаптация, зашитая в систему, ломается при следующем обновлении версии, её снова оплачивают и снова тестируют.

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

Как готовая ERP подминает вас под себя

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

Потолок кастомизации и давление fit-gap-анализа

Каждое внедрение готовой ERP начинается с fit-gap-анализа (анализа соответствий и разрывов). Ваши процессы сравнивают со стандартом продукта. Совпавшие («fit») оставляют как есть, а для несовпавших («gap») предлагают на выбор: подстроить процесс под продукт, закрыть разрыв кастомизацией или смириться. Большинство современных методологий внедрения теперь прямо опираются на подход fit-to-standard (подгонка под стандарт), поэтому рекомендация по умолчанию почти всегда одна: «измените процесс». Для регламентированных процессов это правильно. Но для процессов, которые вас отличают, это значит переименовать конкурентное преимущество в «разрыв» и удалить его.

Clean core и ловушка обновлений

Самое важное понятие корпоративных ERP последних лет — «clean core» («чистое ядро»): не трогайте ядро, расширения стройте вне его. Почему? Потому что каждая строка заказного кода, зашитая в ядро, — это технический долг. В таких системах, как S/4HANA, глубокие доработки, затрагивающие ядро, приходится заново тестировать и исправлять при каждом обновлении версии. В сильно кастомизированных корпоративных внедрениях этот долг по сопровождению может достигать примерно 10 000–50 000 $ в год. Хуже того, компании, которые не хотят его оплачивать, откладывают обновления, со временем отстают от поддерживаемой версии и сталкиваются с окончанием поддержки (EOL) и рисками безопасности. Иначе говоря, чем сильнее вы подгоняете готовый продукт под себя, тем меньше у вас свободы его обновлять. Эта ловушка обновлений — самая дорогая форма «кастомизации», потому что она сделана не на том слое.

Раздутый набор модулей и лицензии per-seat

Чтобы продаваться любому клиенту, готовые продукты несут в себе тысячи функций. Те из них, которыми вы не пользуетесь, и усложняют интерфейс, и попадают в счёт по модели лицензирования на каждого пользователя (per-seat). В корпоративных CRM стоимость одного пользователя в месяц составляет от 175 до 550 $ в зависимости от тарифа. Для команды из ста человек это шестизначная постоянная статья расходов в год, и она растёт вместе с командой. Вы платите за модули, которыми не пользуетесь, просто на случай, если они «когда-нибудь понадобятся».

Реальная TCO: подводная часть айсберга

Лицензия — лишь видимая часть совокупной стоимости владения (TCO). Реальная TCO обычно в 1,5–3 раза превышает стоимость лицензии. Разница складывается из консалтинга, интеграции, миграции данных, обучения и сопровождения. Ставки консультантов — от 100 до 400 $ в час. Стандартное внедрение занимает около 100 часов работы консультантов, а реальные заказные интеграции легко превышают 700 часов. Иными словами, допущение «готовое — значит дешёвое» обычно рушится на втором месяце внедрения.

Интеграционный долг

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

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

Техническая анатомия принципа «ПО подстраивается под вас»

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

  1. Карта процессов → модель данных. Сначала процесс фиксируется как есть: через какие шаги проходит заказ, как движется консигнационный товар, как открывается и закрывается заявка на обслуживание. Каждый объект на этих шагах (заказ, дилер, консигнационный запас, уровень цен, согласование) становится полноценной сущностью в модели данных. Консигнация, которую в готовом продукте пришлось втиснуть в «пустую текстовую колонку», здесь существует со своей таблицей и своими правилами.
  2. Иерархия согласований → машина состояний. Жизненный цикл заказа «черновик → ожидает согласования → согласован → отгружен → счёт выставлен» кодируется как явно определённая машина состояний (state machine). Для каждого перехода заданы правила: кто может его выполнить и при каких условиях. Сообщение «ок, согласовано» в мессенджере превращается в проверяемый переход между состояниями в системе.
  3. Бизнес-правило → движок правил. Такие бизнес-правила, как «скидки выше установленного порога согласует генеральный директор; отсрочка для дилеров на консигнации не может превышать 60 дней», не зашиваются в код, а задаются в движке правил. Отраслевой стандарт здесь — нотации BPMN 2.0 (моделирование процессов) и DMN (моделирование решений), а исполняют их движки класса Camunda или Flowable. Когда правило меняется, вы меняете правило, а не код.
  4. Оргструктура → детальная модель RBAC. Кто что может видеть, согласовывать и изменять, описывается детальной матрицей ролей и прав (RBAC), которая один в один соответствует реальной оргструктуре вашей компании. Региональный менеджер видит только дилеров своего региона, а финансовая служба обрабатывает согласования выше определённой суммы. Права соответствуют вашей иерархии, а не горстке фиксированных ролей, которые приблизительно предлагает готовый продукт.

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

Сделать по мерке не значит кастомизировать вслепую

Здесь важно развеять одно серьёзное заблуждение. «ПО на заказ» не значит «написать всё с нуля». Это слепая кастомизация: дорого, рискованно и не нужно. Правильная архитектура — подход «готовое ядро + заказной слой процессов».

Архитектура состоит из двух слоёв:

  • Готовое ядро (остаётся как есть): Всё, что у всех одинаково, привязано к законодательству и не создаёт отличий. Бухгалтерия, НДС, электронные счета-фактуры, электронный архив, обязательные учётные регистры, расчёт зарплаты. Изобретать здесь велосипед бессмысленно: используются проверенные продукты и существующая инфраструктура.
  • Заказной слой процессов (кодируется для вас): Всё, что отличает вас от конкурентов. Поток продаж и заказов, управление дилерами и консигнацией, особые уровни цен, производство под конкретные проекты, выездной сервис, многоуровневые согласования. Этот слой строится под ваши процессы по цепочке из предыдущего раздела (модель данных → машина состояний → движок правил → RBAC).

Мост между слоями — интеграции по принципу API-first. В реальном мире эти мосты не украшение, а фундамент: API-подключения к сервисам электронных счетов-фактур и электронного архива, банкам, службам доставки, маркетплейсам и готовым системам вроде SAP, Oracle или ERP, ставшей стандартом на вашем рынке. В такой архитектуре интеграции — не плагины, которые прикручивают потом, а полноправная часть проекта.

Для наглядности — карта модулей «оставить готовым / написать на заказ»:

  • Оставить готовым: Бухгалтерия, электронные счета-фактуры и электронный архив, обязательные учётные регистры, расчёт зарплаты, декларации по НДС, сверка с банком. Плюс API-мост к SAP, Oracle или стандартной ERP вашего рынка.
  • Написать на заказ: Управление продажами и заказами, модель работы с дилерами и консигнацией, особые уровни цен и скидок, попроектное производство, процесс выездного сервиса, многоуровневые согласования, отчётность под вашу специфику.

Шире, на уровне бизнес-модели, мы разобрали это разграничение в сравнении ПО на заказ и готового ПО. В отличие от общего решения «разрабатывать или покупать», здесь мы разбираем механику: как именно кодируется ERP/CRM на заказ.

До и после: сценарий из малого и среднего бизнеса

Вернёмся к производственной компании из начала статьи и сравним два мира.

С готовой ERP (до)

Движения консигнационного товара в модели данных продукта нет. Команда вводит его «как будто это обычная продажа» и вручную исправляет возвраты. Для уровня цен конкретного дилера продукт предлагает один стандартный прайс-лист, поэтому особые цены пишут в поле «примечания» строки заказа и вручную исправляют перед выставлением счёта. В системе нет шага согласования скидок, поэтому оно идёт в мессенджере. В итоге настоящая таблица продаж живёт в теневом файле на рабочем столе финансового менеджера. Закрытие месяца уходит на сверку этого файла с ERP. Стоит одному человеку заболеть — и цифры замирают.

С заказным слоем процессов (после)

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

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

Когда это правильно, а когда нет: честные границы

ERP/CRM на заказ — не ответ на любую ситуацию. Чтобы заслужить доверие, чётко обозначим границы.

  • Для регламентированных процессов правильный выбор — готовый продукт. Бухгалтерия, НДС, расчёт зарплаты и электронные счета-фактуры у всех одинаковы и определены государством. Никому не нужна «бухгалтерская программа на заказ»: здесь готовое ядро остаётся как есть. Писать всё это с нуля — пустая трата денег и времени.
  • Если бюджет очень ограничен или запуститься нужно за считаные недели, готовый продукт на старте быстрее и дешевле. Заказной слой — это инвестиция, и отдача от неё приходит по мере того, как он устраняет компромиссы в процессах. Если вам нужна скорость, чтобы выжить сегодня, начать с готового продукта и позже добавить слой с вашими отличиями — вполне законный путь.
  • Самая важная оговорка: кодировать плохой процесс как есть — ошибка. Принцип «процесс кодируется как есть» применим только к процессам, которые отличают вас и дают конкурентное преимущество. Если процесс уже сломан, неэффективен или разросся за годы латания одного сбоя поверх другого, закатать его в бетон как есть — значит закрепить ошибку навсегда. Такие процессы сначала улучшают (реинжиниринг бизнес-процессов, BPR), а потом кодируют. Хороший партнёр всегда спросит вас: «Почему вы делаете это именно так?»
  • Настоящий риск не в том, что решение «на заказ», а в качестве внедрения. Скажем без преувеличений: готовые ERP тоже проваливаются. По данным Panorama за 2025 год, доля неудачных ERP-проектов в целом составляет примерно 68%, а средний перерасход бюджета — 189%. Но вот что важно: более 75% этих неудач связаны с качеством внедрения, управлением изменениями и миграцией данных, а не с выбором «готовое или заказное». Поэтому правильный вопрос не «готовое или заказное», а «кто и как внедряет».

Дорого, рискованно, долго: честные ответы на возражения

У тех, кто принимает решения, есть три обоснованных возражения. Не будем от них отмахиваться — ответим прямо.

«ПО на заказ — это дорого»

На первый взгляд — да. Но сравнивайте правильно: реальная TCO готового продукта в 1,5–3 раза превышает стоимость лицензии, расходы на лицензии per-seat бесконечно растут вместе с командой, а сверху надо добавить невидимую цену теневой таблицы, обходных решений, привязанных к людям, и упущенных возможностей. Заказной слой — разовая инвестиция, которая устраняет ежегодный счёт за компромиссы в процессах. «Дорого» обычно не заказная разработка, а цена компромиссов, которую вы платите годами.

«ПО на заказ — это рискованно»

Риск реален, но его источник ищут не там. Приведённые выше данные показывают, что 75% неудач связаны с качеством внедрения. Риск снижает не выбор «готового», а дисциплина внедрения: чёткий объём работ, реалистичный план миграции данных, вовлечённость пользователей и управление изменениями. Архитектура, которая не трогает готовое ядро, и так передаёт основную часть риска (законодательство и бухгалтерию) проверенным продуктам. Риск остаётся только в слое, который действительно ваш.

«ПО на заказ — это долго»

Долго длится слепая кастомизация, а заказной слой с правильно очерченным объёмом работ — нет. Секрет в том, чтобы не писать всё с нуля: оставить готовое ядро готовым, кодировать только тот процесс, в котором вы отличаетесь, и начать работу с фиксированного, чёткого объёма. Расплывчатые, бессрочные проекты с почасовой оплатой затягиваются, а проекты с фиксированным объёмом работ и фиксированной ценой завершаются предсказуемо.

Оцените цену компромиссов в своей компании

Это самая практичная часть статьи. Чтобы измерить цену компромиссов в процессах своей компании, честно ответьте на четыре вопроса:

  • Есть ли теневая таблица? Живут ли реальные операционные данные вне основной системы, в «мастер-файле»? Сколько человек ведут этот файл и что будет, если он потеряется?
  • Где идёт работа вне системы? Проходят ли согласования, исключения и особые переговоры в мессенджерах и электронной почте? Есть ли в системе ответ на вопрос, кто это согласовал?
  • Какие обходные решения держатся на одном человеке? Сколько у вас процессов, о которых вы говорите «это умеет только один человек»? Это долг знаний, и счёт по нему однажды обязательно придёт.
  • Что сломалось при последнем обновлении версии? Какие ваши доработки перестали работать, были оплачены и протестированы заново? Сколько недель вы потеряли?

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

Для агентств-партнёров: готовое оставьте готовым, а своё отличие пишите на заказ

Если вы агентство или консалтинговая компания и клиенты ждут от вас решение на базе ERP/CRM, такое позиционирование создано для вас. Не нужно предлагать клиенту «давайте напишем всё с нуля»: это и невыгодно, и нереалистично. Но и втиснуть его в готовую коробку, обрекая на компромиссы в процессах, — значит ничем не выделиться среди конкурентов.

Правильный посыл прост: готовое оставьте готовым, а своё отличие пишите на заказ. Регламентированное ядро доверьте проверенным продуктам, а реальное конкурентное преимущество клиента (дилерскую сеть, консигнацию, особые процессы) закодируйте в заказном слое процессов. Делать это самим не обязательно. Partnerfy создаёт именно такой заказной слой под вашим брендом как ваш невидимый технологический партнёр. Экономику этой модели white-label и то, как она выстраивается, мы подробно разобрали в статье о white-label-партнёрстве по разработке ПО для агентств.

С чего начать: от карты процессов до запуска

Хорошая новость: эта работа начинается не с сюрприза, а с карты процессов. Современные проекты ERP/CRM на заказ делают ваши процессы видимыми с помощью стандартных нотаций вроде BPMN 2.0, выносят бизнес-правила из кода в движки правил и благодаря архитектуре API-first ставят интеграции (электронные счета-фактуры, банк, доставка, маркетплейсы) в центр проекта. Этот же подход можно дополнить автономными рабочими процессами, выйдя за рамки согласований людьми. Можно даже подключить поддержку клиентов к тому же ядру с помощью WhatsApp Business Cloud API и ИИ.

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

Как Partnerfy может помочь

Partnerfy — невидимый технологический партнёр для агентств и растущих компаний. Мы оставляем регламентированное ядро готовым, а процессы, которые отличают вас от конкурентов (продажи, работа с дилерами, консигнация, согласования, выездной сервис), кодируем один в один: от карты процессов к модели данных, машине состояний и матрице ролей и прав. Для агентств-партнёров мы делаем всё это полностью по модели white-label, под их собственным брендом. Наша цель одна: подстроить ПО под вас, а не вас под ПО.

Первый шаг прост. Мы проводим 30-минутную ознакомительную встречу, при необходимости подписываем NDA (соглашение о неразглашении) и готовим предложение с фиксированным объёмом работ и фиксированной ценой — в течение 5 рабочих дней. Никакой почасовой оплаты, бюджета без верхней границы и «посмотрим, как пойдёт»: вы с самого начала знаете, что получите и сколько заплатите. Чтобы оценить цену компромиссов в процессах и действительно подстроить ПО под себя, назначьте встречу.