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