Коротко для руководителя ИТ-компании
Вход ИТ-компании в сделку часто экономически незащищён. Обычный пресейл должен квалифицировать запрос, показать релевантность и довести клиента до следующего шага. Но в сложных проектах внутрь пресейла всё чаще проваливается работа другого класса – управленческая диагностика.
Команда начинает выяснять, почему заказчику нужна CRM, ERP, BI, BPM, AI или заказная разработка; где нарушены процессы, ответственность, показатели, данные и управленческие решения. Если этот слой не оформлен как отдельный продукт, он остаётся неоплаченным и позже возвращается в проект как изменение требований, спор об эффекте, дополнительные встречи, доработки и просадка маржи.
ИТ-компания оценивает разработку, хотя сначала нужно проверить, правильно ли поставлена управленческая задача.
Вынести управленческую диагностику из обычного пресейла в отдельный предпроект перед автоматизацией.
Рынок стал жёстче. Экономически незащищённый вход стал опасным
Пока рынок быстро рос, многие проектные потери можно было не замечать. Бесплатные встречи, расширенное обследование, несколько дополнительных созвонов с заказчиком, неучтённые уточнения, небольшие доработки, повторная аналитика – всё это выглядело как нормальная цена сложного проекта.
Но в более жёстком рынке такая логика начинает бить по экономике ИТ-компании. Заказчик осторожнее входит в проекты, дольше согласует бюджет, сильнее давит по цене, хочет этапность, переносит решения, просит отсрочки и требует доказуемого эффекта. У подрядчика остаётся меньше пространства для того, чтобы собственным ресурсом компенсировать всё, что не было выявлено до старта.
По оценке Т1, опубликованной «Коммерсантом», оборот российского ИТ-рынка в 2025 году должен был вырасти всего на 3% год к году после 20% в 2024 году. TAdviser фиксировал, что жёсткая денежно-кредитная политика вынуждала заказчиков откладывать, приостанавливать или отказываться от части ИТ-проектов. В заказной разработке усилился запрос на снижение затрат при сохранении качества.
Для ИТ-компании это означает одно: прежняя модель «глубже разберёмся на входе, а потом заработаем на разработке» становится менее устойчивой. Чем хуже условия по цене, авансу и срокам оплаты, тем дороже обходится управленческая работа, которая не выделена в продукт и не оплачена отдельно.
Что на самом деле проваливается в пресейл
Заказчик редко приходит с точной управленческой задачей. Он приходит с названием системы, с накопленной болью или с желанием «что-то автоматизировать». В запросе звучит: «нужна CRM», «нужен дашборд», «надо внедрить ERP», «автоматизируйте согласования», «хотим AI-ассистента», «нужен личный кабинет».
ИТ-компания начинает профессионально делать свою работу: уточняет роли, процессы, сценарии, интеграции, поля, статусы, отчёты, права доступа, документы, события, интерфейсы. Всё это необходимо. Без этого система не будет разработана.
Но в этот момент часто происходит подмена. Формально команда собирает требования к будущему инструменту. Фактически она уже заходит в управленческую диагностику: проверяет, правильно ли определён сам предмет автоматизации.
ИТ-компания принимает симптом за задачу, а потом внутри проекта расплачивается за то, что настоящая управленческая причина не была выявлена на входе в сделку.
Если проблема не в CRM, а в системе продаж, CRM не создаст управляемость сама по себе. Если проблема не в BI, а в отсутствии дерева управленческих решений, дашборд не сделает компанию умнее. Если проблема не в маршруте согласования, а в размытых полномочиях, workflow только быстрее проведёт по системе прежнюю неопределённость.
Заказчик приносит не ИТ-задачу, а управленческую неопределённость
На входе в проект есть два слоя. Первый виден сразу: система, модуль, интеграция, отчёт, интерфейс, автоматизация процесса. Второй почти всегда сложнее: управленческая задача, которую заказчик не умеет сформулировать в ИТ-языке.
«Нужна CRM, чтобы менеджеры лучше работали с клиентами».
Кто владеет воронкой, как устроены этапы продажи, какие действия влияют на конверсию, какие показатели контролируются, кто принимает решение при отклонении.
«Нужен BI-дэшборд для руководства».
Какие решения принимает руководство, какие показатели являются ранними сигналами, кто отвечает за изменение потока, что должно произойти после просмотра отчёта.
«Автоматизируйте согласования».
Где проходят полномочия, кто владелец процесса, какие критерии принятия решений, какие исключения допустимы, где теряется скорость и ответственность.
Если второй слой не разобран, ИТ-команда всё равно столкнётся с ним позже: в изменении требований, сопротивлении пользователей, споре функциональных блоков, бесконечном уточнении отчётов, запросах на новые роли и попытках заказчика получить тот эффект, который никто не спроектировал.
Где ИТ-компания теряет маржу
Потеря маржи редко выглядит как одна большая ошибка. Чаще она распределена по проекту тонким слоем: лишние встречи, расширенные интервью, повторная аналитика, уточнение логики, правка процессов, дополнительное обучение, новые отчёты, дополнительные согласования, конфликтные обсуждения, поддержка переходного периода.
Формально всё это можно назвать клиентоориентированностью. Экономически это часто означает другое: подрядчик компенсирует невыявленную управленческую задачу собственным ресурсом и проектной маржой.
В мягком рынке это можно было закрывать будущими контрактами и ростом объёма работ. В сжимающемся рынке эта модель становится прямым риском: денег меньше, переговоры жёстче, а ожидания заказчика по эффекту выше.
Почему ИТ-компания обычно не вынесет этот слой сама
Важно сказать точно: не потому, что ИТ-команды слабые. Наоборот, сильные ИТ-команды часто первыми чувствуют, что проблема находится выше требований. Но производственная логика ИТ-компании настроена на другое: быстро понять запрос, оценить работу, продать проект, собрать требования, разработать, внедрить, поддержать.
Управленческая диагностика устроена иначе. Она не начинается с вопроса «какие функции нужны?». Она начинается с вопроса «какая система управления не работает и какой экономический или организационный результат должен измениться?»
Поэтому решение не в том, чтобы просто назвать расширенный бизнес-анализ консалтингом. Решение в том, чтобы добавить к ИТ-проекту профессиональный управленческий слой – до технической оценки, до фиксации ТЗ и до обещания эффекта заказчику.
Что нужно вынести в отдельный продукт
У ИТ-компании должен появиться отдельный управленческий предпроект перед автоматизацией. Не «расширенное уточнение требований». Не «ещё одна встреча до КП». Не «подумаем вместе». А самостоятельная стадия с предметом, результатом, сроком и ценой.
Его задача – отделить симптом от причины и перевести управленческую неопределённость заказчика в архитектуру будущего ИТ-проекта.
Что должно быть результатом такого предпроекта
- формулировка настоящей управленческой задачи, а не только названия системы;
- карта процесса, потока или управленческого контура, который должен измениться;
- дерево показателей и решений: кто, на основании каких данных, что должен менять;
- границы ответственности заказчика и ИТ-подрядчика;
- риски внедрения: где система может быть создана, но эффект не наступит;
- требования к данным, ролям, регламентам, контрольным точкам и организационным изменениям;
- обоснование этапности, аванса, цены и границ разработки.
Тогда ИТ-компания перестаёт продавать только часы, функции и релизы. Она начинает продавать более сильную логику: сначала подтверждаем управленческую задачу, затем проектируем контур результата, затем переводим его в систему.
Что меняется для ИТ-компании
Отдельный управленческий слой меняет не только качество проекта, но и коммерческую модель подрядчика.
Заказчику проще понять, почему нельзя сразу оценить систему, если показан риск автоматизации симптома.
Первая оплачиваемая стадия нужна не «на подумать», а для снижения риска бюджета, срока и результата.
То, что относится к оргпроектированию, данным, ответственности и управленческим решениям, не растворяется внутри разработки.
Часть глубины, которая раньше проваливалась в обычный пресейл, превращается в оплачиваемый предпроект.
Реальные ограничения выявляются до старта, а не после запуска системы.
ИТ-компания говорит не только про функции и интеграции, а про управляемость, экономику, ответственность и эффект.
В текущем рынке это не косметическое улучшение пресейла. Это способ защитить экономику ИТ-компании в условиях, когда заказчик стал требовательнее, бюджет осторожнее, а ошибка на входе дороже.
Что делать руководителю ИТ-компании
Если входящие сделки стали длиннее, заказчики сильнее торгуются, а команда всё чаще тратит ресурс до договора, нужно не углублять обычный пресейл за свой счёт, а перестроить границу между продажей, диагностикой и разработкой.
Что проверить перед следующей оценкой проекта
Перед тем как оценивать CRM, ERP, BI, BPM, AI или заказную разработку, ИТ-компании стоит задать себе несколько вопросов.
Если этих ответов нет, ИТ-компания уже не просто уточняет запрос. Она вошла в управленческую диагностику, которую пора оформлять как отдельный продукт.
Следующий разумный шаг
Взять один реальный входящий запрос заказчика и разобрать его не как список функций, а как управленческую задачу: где симптом, где причина, какие вопросы нужно задать до оценки, что вынести в предпроект и как защитить цену, аванс и границы разработки.
Разобрать пресейл-запросИсточники и связанные материалы
- Борисенко Татьяна. Почему автоматизация бизнеса не дает управленческого эффекта
- Savv.tech: стратегический консалтинг, бизнес-архитектура и цифровизация
- Форма контакта для разбора пресейл-запроса
- Коммерсантъ / Т1. Рост ИТ-рынка России замедлится до 3% в 2025 году
- TAdviser. Тенденции ИТ-рынка России
- TAdviser. Время экономии: тренды рынка заказной разработки в 2025 году
- CNews. Заказная разработка 2025
