«Сделайте нам CRM, чтобы всё заработало». Проходит год, потрачены миллионы, система вроде стоит, отчётов море, а ощущения одно: деньги слили, люди раздражены, бизнесу легче не стало.
Знакомо?
В таких историях обычно ищут виноватых среди подрядчиков и айтишников. «Плохие настройки», «кривые руки», «нас не поняли». Это удобно — всегда есть внешний злодей.
Но правда в том, что большинство IT‑проектов ломаются не в коде и не в базе данных.
Они ломаются в управлении: в том, как собственник и топ‑команда ставят задачу, принимают решения и относятся к проекту.
Давайте разберёмся, где именно бизнес чаще всего сам превращает IT‑проект в «чёрную дыру» для денег.
Ошибка №1. Цель — «внедрить систему», а не заработать или сэкономить
Типичный старт звучит так:
«Нам нужна CRM»,
«Надо автоматизировать склад»,
«Пора переходить на нормальную ERP».
Это не цель.
Это список инструментов.
Когда цель проекта формулируется как «внедрить систему», вы заранее соглашаетесь на то, что любой результат можно назвать успехом. Серверы работают? Работают. Логи пишутся? Пишутся. Значит, формально всё хорошо.
Только вот бизнес этого «хорошо» не чувствует.
Как должно быть:
- Вместо «внедрить CRM» — «увеличить конверсию из заявки в сделку на 15% за счёт прозрачной воронки и контроля работы менеджеров».
Самый болезненный пример — CRM: её формально внедрили, а по факту ничего не поменялось. Почему так происходит, разбираю в статье «Почему внедрение CRM почти всегда не работает так, как обещали».
- Вместо «автоматизировать склад» — «сократить потери и пересортицу на 30% за счёт точного учёта и нормальной системы резервирования».
- Вместо «сделать отчёты» — «получать к 10:00 утром три ключевых показателя по продажам и дебиторке без ручного свода в Excel».
Чёткая бизнес‑цель — это не красивая фраза для презентации.
Это точка, по которой вы потом поймёте: проект дал результат или вы просто купили дорогой конструктор.
Ошибка №2. Экономия на предпроектной аналитике: «давайте быстрее начнём»
Вторая классика:
«Мы и так всё про свои процессы знаем, давайте не тратить время на бумажки, лучше сразу делайте».
Что в этот момент обычно не делают:
- не описывают, как компания работает сейчас — кто что делает, где теряются данные, где «ручники»;
- не договариваются, как должно быть после проекта — какая роль у кого, какие шаги автоматизируются, а какие нет;
- не фиксируют критерии успеха — по каким цифрам вы через 3–6 месяцев поймёте, что было не зря.
В результате всё, что «сэкономили» в начале, возвращается в середине и в конце проекта:
в виде бесконечных доработок, переделок, уточнений и скандалов.
Подрядчик крутит систему туда‑сюда.
Сотрудники уже устали.
Собственник злится, что сроки съехали, а бюджета нет.
Простой тест:
если вы не можете за 5–7 минут на одном листе описать «как живём сейчас» и «как хотим жить после проекта» — вы не готовы к внедрению. Вы готовы к долгому и дорогому эксперименту.
Ошибка №3. У бизнеса и IT разные цели, и никто не переводит
Для IT нормально думать так:
«Главное, чтобы система работала стабильно, не падала, данные не терялись, интеграции были корректными».
Для бизнеса нормально думать иначе:
«Главное, чтобы было больше денег, меньше хаоса, быстрее принимались решения и было понятно, что происходит».
Пока между этими двумя логиками нет переводчика, конфликт неизбежен.
IT говорит:
«Мы всё внедрили, система работает по ТЗ, вот акты».
Бизнес говорит:
«Мне всё равно неудобно, цифр нет, люди матерятся, деньги не растут».
Формально проект можно закрыть.
По ощущениям — это слив.
В зрелых компаниях есть человек, который связывает эти два мира — IT‑директор (подробно разбираю его роль в отдельной статье) или сильный руководитель со стороны бизнеса. Он переводит бизнес‑цели на язык требований к системе и обратно.
Если такого человека нет, IT‑проект превращается в спор «кто прав» вместо разговора «что полезно бизнесу».
Ошибка №4. Проект превращается в мешок хотелок
Почти любой проект начинается с простой мысли:
«Сделаем минимум, а потом потихоньку расширим».
Через месяц появляется первая фраза‑убийца:
«Раз уж делаем, давайте добавим ещё вот это».
Потом ещё это.
И вот это тоже.
Кажется, что компания просто повышает полезность проекта.
На практике она размывает результат.
Без жёстких приоритетов IT‑проект превращается в бездонный мешок задач:
- список требований растёт быстрее, чем команда успевает реализовывать;
- сроки тихо двигаются вправо;
- бюджет увеличивается «по чуть‑чуть», но постоянно;
- никто уже не помнит, ради чего вообще всё начинали.
Нужен простой, но неприятный шаг:
разделить хотелки на три корзины — «обязательный минимум для запуска», «следующий релиз» и «когда‑нибудь потом, если будет смысл».
И держать это разделение.
Даже если очень хочется «прямо сейчас добавить ещё одну маленькую формочку».
Ошибка №5. Некому сказать «нет» — слабый заказчик со стороны бизнеса
Ещё один частый сценарий:
формально за проект отвечает кто‑то из среднего уровня — руководитель отдела, «инициатор». У него нет полномочий спорить с собственником, коммерческим директором или подрядчиком.
В итоге:
- все тянут проект в свою сторону;
- каждый продавливает свои хотелки;
- никто не держит рамку, что важно бизнесу прямо сейчас.
Сильный заказчик со стороны бизнеса — это не человек, который «подписывает акты».
Это тот, кто умеет:
- сказать «нет, сейчас мы этого не делаем» даже самому собственнику;
- остановить расползание проекта;
- напомнить, ради какой цели всё начиналось.
Если такого человека нет, любые методологии и инструменты превращаются в декорации. Проект управляют эмоции, а не приоритеты.
Ошибка №6. У проекта нет понятного конца
Многие IT‑проекты живут годами в состоянии «ещё чуть‑чуть допилим, и будет идеально».
Каждая новая доработка вроде бы полезна.
Но бизнес не видит завершения, команда вечно в подвешенном состоянии, деньги уходят на поддержку бесконечного ремонта, а не на получение эффекта.
У любого нормального IT‑проекта должен быть чёткий момент «мы закончили первую фазу».
Это не значит, что дальше нельзя развивать систему.
Это значит, что:
- базовый функционал работает и даёт измеримый эффект;
- у владельца есть набор понятных цифр: что улучшилось в деньгах, сроках, прозрачности;
- всё остальное — это уже следующий этап, а не «немного доделаем».
Без такого финиша вы обречены жить в режиме «ещё немного потерпим» и платить за это каждый месяц.
Главное, что стоит вынести
IT‑проект — это не про софт.
Это про управленческое решение: что именно вы хотите изменить в бизнесе и готовы ли вы сами меняться вместе с системой.
Пока проект воспринимается как магическая кнопка «поставим CRM — будет порядок», деньги будут утекать в доработки, сдвинутые сроки и разочарование.
Хорошая новость в том, что большинство ошибок, о которых я писал выше, лежат на стороне управления, а не технологий.
А управленческие решения можно пересобирать.
Что сделать прямо сейчас
Если у вас уже идёт IT‑проект или вы только собираетесь его запускать, остановитесь на пять минут и честно ответьте себе:
- какую конкретную бизнес‑проблему вы решаете;
- кто отвечает за результат со стороны бизнеса, а не только со стороны IT;
- описаны ли текущие процессы и целевая модель «как должно быть»;
- знаете ли вы, какие цифры посмотрите через полгода, чтобы сказать: «Да, это было не зря».
Если хотя бы на часть этих вопросов ответа нет, проблема уже не в подрядчике и не в системе.
Проблема в том, как вы управляете проектом.
Напишите в комментариях, что вы сейчас внедряете — CRM, ERP, склад, производство или что‑то своё. В следующих материалах разберём, где именно в таких проектах чаще всего начинаются потери денег и что можно поправить ещё до того, как всё поедет не туда.
Что читать дальше:
– «Что на самом деле делает IT‑директор и почему без него вы теряете деньги» — если хотите понять, кому поручить управление всей этой конструкцией.
– «Почему внедрение CRM почти всегда не работает так, как обещали» — если у вас уже стоит или планируется CRM, и вы не хотите второй раз платить за одно и то же.