В момент покупки это выглядит логично.
На таблице сравнений всё красиво: у одних «CRM за 3 млн», у других — «то же самое за 1,8».
Проблема в том, что цена в коммерческом предложении — только видимая часть айсберга.
Настоящая стоимость вылезает позже — в виде доработок, поддержки, простоя и нервов.
Давайте разберём, из чего на самом деле складывается цена «дешёвого» IT‑решения и почему оно почти всегда оказывается дороже нормального.
Ошибка №1. Сравнивать только цену договора, а не стоимость владения
Когда сравнивают варианты, чаще всего смотрят на один параметр:
«Сколько стоит внедрение/разработка по договору».
Но у любого IT‑решения есть как минимум три слоя затрат:
- Запуск — лицензии, внедрение, настройка, обучение.
- Эксплуатация — поддержка, обновления, доработки «по ходу».
- Риски — стоимость сбоев, простоя, потери данных, зависимость от конкретного подрядчика или человека.
Дешёвое предложение почти всегда бьёт только по первому слою.
Остальное либо упоминается мельком, либо уходит в зону «там разберёмся».
В результате через год оказывается, что:
- поддержка стоит как половина первоначального внедрения;
- любые изменения тарифицируются по максимуму;
- за стабильность и безопасность вы платите отдельно.
В статье «Почему бизнес любит автоматизацию, но не любит менять процессы» я разбирал, как автоматизация закрепляет старый бардак. Здесь история другая: дешёвое внедрение закрепляет неправильную экономию.
Ошибка №2. Не задавать вопросов про поддержку и доработки
В коммерческом предложении всё выглядит аккуратно:
список работ, сроки, стоимость.
Но чаще всего между строк остаётся главное:
- что будет после запуска;
- кто и за какие деньги будет исправлять ошибки;
- как будут считаться доработки, которых точно будет много.
Типичный сценарий:
- в договоре заложено 1–2 месяца «гарантии»;
- по факту за это время вы только начинаете нормально пользоваться системой;
- всё, что дальше — оплачивается как новые работы по расценкам, которые вы не обсуждали.
«Дешёвый» подрядчик зарабатывает не на старте.
Он зарабатывает на том, что вы привязаны к его решению и вынуждены платить за каждую мелочь.
Несколько простых вопросов на старте сильно меняют картину:
- что именно входит в поддержку и на какой срок;
- какие работы оплачиваются отдельно;
- как считается час/день доработки.
Если ответы расплывчатые — это не экономия, а отсроченный чек.
Ошибка №3. Экономить на архитектуре и интеграциях
Чтобы сделать предложение дешевле, есть два простых приёма:
- Не трогать сложные интеграции — «пока давайте без этого, потом добавим».
- Упростить архитектуру — «сделаем попроще, а дальше посмотрим».
На бумаге вы «сэкономили»:
меньше часов, быстрее запуск, радостный ценник.
На практике:
- данные продолжают разъезжаться между системами;
- люди дублируют информацию вручную;
- при первой же попытке развивать решение всплывает фраза «под это архитектура не рассчитана, нужно переписывать».
Вы экономите на фундаменте, а потом платите за капитальный ремонт.
Это прямое продолжение той же логики, о которой я писал в статье «5 ошибок собственника, из‑за которых даже сильное IT не спасает бизнес»: попытка выиграть на короткой дистанции почти всегда делает проект дороже на длинной.
Ошибка №4. Не учитывать стоимость людей и времени
О цене IT любят говорить в рублях за лицензии и часы разработки.
Но почти никогда не считают стоимость:
- времени сотрудников, которые учатся обходным путям;
- ошибок, из‑за которых теряются сделки и клиенты;
- решений, которые руководство не может принять из‑за кривых отчётов.
Допустим, вы сэкономили 500 тысяч на внедрении.
Если из‑за неудобной системы:
- один менеджер теряет 1 сделку в месяц;
- руководитель отдела продаж тратит лишние 10 часов в месяц на сводку цифр;
- IT‑отдел держит одного человека «на костылях» вокруг этого решения,
эта «экономия» улетает за полгода.
Но в отчёте по проекту это не видно — там написано:
«Сэкономили на старте 30% от предложения конкурентов».
Ошибка №5. Смотреть только на первый проект, а не на горизонт 2–3 года
IT‑решения редко покупаются «один раз и навсегда».
Обычно это:
- шаг в сторону какой‑то платформы;
- связка с другими системами;
- долгосрочный выбор партнёров.
Дешёвое решение часто означает:
- закрытый стек, из которого сложно выехать;
- отсутствие документации — вы зависите от конкретной команды;
- ограниченные возможности расширения.
В какой‑то момент вы понимаете, что:
- систему невозможно развивать под новые задачи;
- её нельзя нормально интегрировать с остальным ландшафтом;
- проще начать заново, чем спасать то, что есть.
И тогда вы платите снова — уже за «нормальное» решение, плюс за миграцию с дешёвого.
Что спросить у себя и подрядчика до того, как выбирать «дешевле»
Несколько вопросов, которые стоит задать до подписания договора:
- Сколько будет стоить не только внедрение, но и поддержка/доработки за 2–3 года?
- Что произойдёт, если мы захотим уйти от этого решения: кому принадлежат код, данные, документация?
- Какие задачи мы точно не сможем решать на этой системе через год-два?
- Что именно подрядчик не включает в цену и за счёт чего он делает предложение «дешевле» конкурентов?
Если на эти вопросы нет конкретных ответов, перед вами не выгодное предложение, а просто красиво упакованная неопределённость.
Главное
Дешёвое IT‑решение редко бывает дешёвым.
Оно просто откладывает счёт на потом.
Вы платите меньше на старте — и почти всегда больше на дистанции:
в доработках, поддержке, потерянных возможностях и нервах команды.
Нормальный вопрос для собственника звучит не «где дешевле внедрить», а «какая будет реальная стоимость владения этим решением за 2–3 года и что я получу на выходе».
Если вы уже один раз «сэкономили» и теперь разгребаете последствия, посмотрите также статьи «5 ошибок собственника, из‑за которых даже сильное IT не спасает бизнес» и «Почему бизнес любит автоматизацию, но не любит менять процессы» — они помогают увидеть, где именно управленческие решения сделали ваш проект дороже, чем он должен был быть.