Срок внедрения AI, названный на первой встрече, почти всегда потом сдвигается, и сдвигает его не технология, а данные, доступы и согласования на стороне заказчика — каждая такая неделя стоит компании денег, которые проект должен был начать возвращать. Сроки внедрения AI определяются тремя вещами, которых подрядчик до разбора не видит: в каком состоянии данные, кто принимает решения и готова ли компания менять процесс. Ниже — что можно назвать заранее, что растягивает проект, как сократить срок без потери результата и как выглядит честный ответ на вопрос «за сколько внедрите».
Срок, названный до разбора, — обещание вместо оценки
«За сколько внедрите?» — первый вопрос почти на каждой встрече. Подрядчик в этот момент не знает ни того, в каком состоянии данные, ни того, сколько согласований внутри компании, ни того, есть ли человек, который будет вести изменение. Все три вещи влияют на срок сильнее, чем сложность самой задачи.
Что это значит: названная цифра берётся из прошлых проектов и служит не планированию, а продаже. Дальше происходит одно из двух: в срок не укладываются и объясняют это обстоятельствами, либо укладываются, урезав объём до того, что помещается.
«От чего эта цифра изменится в большую сторону?» Подрядчик, который считал, назовёт три-четыре условия. Подрядчик, который вспомнил похожий проект, скажет, что всё под контролем.
Вердикт: быстрый ответ о сроке говорит о готовности продавать, а не о готовности делать.
Сроки внедрения AI зависят от данных и людей сильнее, чем от технологии
Четыре фактора, и только один из них про технологию.
| Фактор | Что происходит | Влияние |
|---|---|---|
| Состояние данных | Записи есть, но не выгружаются; выгружаются, но без привязки к сделке; привязаны, но половина полей пустая | Самое сильное. Может удвоить срок |
| Скорость решений | Каждый вопрос уходит в согласование и возвращается через неделю | Сильное. Календарь идёт, работа стоит |
| Готовность менять процесс | Инструмент внедряют, а регламент оставляют прежним | Сильное, но проявляется поздно |
| Сложность задачи | Один сценарий или связка из нескольких систем | Умеренное. Обычно предсказуемо |
Порядок в таблице не случаен. Технологическая часть внедрения прогнозируется лучше всего: похожие задачи занимают похожее время. Всё, что связано с данными и людьми, разбросано в разы — и именно поэтому срок нельзя назвать, не посмотрев. Какой минимальный набор данных нужен для старта и как быстро проверить его качество, разобрано в статье о том, какие данные нужны для AI.
Вердикт: если подрядчик на первой встрече спрашивает только о задаче и ни разу — о выгрузках и о том, кто решает, срок он оценивает по технологии, то есть по самой предсказуемой части.
Заранее можно назвать только срок технической части
Есть случаи, когда цифру честно называют до разбора: задача закрывается готовым продуктом, и его запуск повторялся много раз. У 404ai сроки опубликованы на страницах продуктов. Эхолитикс подключается к CRM и телефонии за 3 дня, пилот идёт 14 дней. Базовый сценарий AI-агента Дирижёр — квалификация, запись, ответы на частые вопросы — запускается за 3–5 рабочих дней, сложные конфигурации с несколькими каналами и своими навыками — от 2 недель. Стандартный проект Фонекса занимает около 3 недель: неделя на сценарии, неделя на интеграцию с CRM и тестирование, неделя на пилотный запуск и калибровку.
Когда готового продукта нет, сроки другие: рабочий прототип при разработке под задачу — 2–6 недель, а если непонятно, с какого процесса начинать, диагностика занимает 2–4 недели, и её разброс объясняется не размером компании, а тем, как быстро приходят доступы и данные.
Что это значит: все эти цифры описывают работу, которая начинается в тот момент, когда данные выгружены, доступы работают и есть человек, способный сказать «делаем так». Время до этого момента в них не входит и целиком зависит от заказчика.
Вердикт: опубликованный срок продукта — это скорость подрядчика, а не дата, к которой процесс заработает у вас.
Проект растягивают четыре вещи, и все на стороне заказчика
- Доступы. Между «дадим доступ» и «доступ работает» проходят недели: нужен админ системы, у него отпуск, у безопасности вопросы, у интегратора нет прав на нужный раздел.
- Отсутствие владельца. Когда решение принимает «мы посоветуемся», каждая развилка стоит несколько дней. За проект таких развилок десятки.
- Расширение по ходу. «Раз уж вы это делаете, добавьте ещё». Каждое такое добавление кажется мелким, а вместе они дают второй проект внутри первого.
- Отложенная проверка. Результат готов, но его некому посмотреть три недели. Работа при этом считается идущей.
Общее у всех четырёх в том, что они лежат на стороне заказчика и подрядчиком не управляются. Это не перекладывание ответственности, а причина, по которой честный план всегда содержит колонку «что нужно от вас» и сроки по ней. Доступы — самый частый из четырёх пунктов; как пройти согласование с ИТ без недель переписки, разобрано в статье о том, как договориться с ИТ-отделом.
Вердикт: план без колонки «что нужно от вас» не короче честного плана — он просто ещё не знает, насколько длиннее.
Сократить срок можно тремя приёмами, и параллельный запуск в их число не входит
Три приёма, которые действительно работают, в отличие от «давайте параллельно».
- Сузить первый шаг. Один процесс, один канал, одни часы. Узкий кусок доходит до результата быстрее, чем широкий, и даёт понимание, которого не даст никакое планирование.
- Назначить одного решающего. Не согласующего, а решающего: человека, чьё «да» окончательно. Это сокращает календарь сильнее любой технической оптимизации.
- Подготовить данные заранее. Выгрузку, доступы и список систем можно собрать до начала работ. Это единственная часть, которую заказчик может ускорить в одиночку.
Параллельный запуск нескольких сценариев. Он не ускоряет проект, а лишает возможности понять, что сработало: при одновременном изменении трёх вещей причина результата неизвестна, и следующий шаг выбирается наугад.
Вердикт: срок сокращает не скорость подрядчика, а ширина первого шага и число людей, чьё «да» нужно ждать.
План по проверяемым состояниям показывает отставание на первой же точке
План из двух пунктов — «начали» и «сдали» — не позволяет заметить отставание раньше срока сдачи. К этому моменту исправлять уже поздно, и разговор сводится к переносу даты.
Полезная детализация — не по неделям, а по проверяемым состояниям. Данные выгружены и проверены. Первая версия отвечает на десять контрольных вопросов. Подключена интеграция и прошёл тестовый обмен. Проведён прогон на реальной выборке. Каждое состояние либо достигнуто, либо нет — без промежуточных «почти».
У каждого состояния своя дата, и отставание видно на первом же пропуске. Практическое правило: если пропущены две контрольные точки подряд, дата сдачи уже недостижима, и обсуждать это лучше сразу, а не за неделю до срока. Те же состояния потом служат критериями приёмки — как их формулировать, разобрано в статье о приёмке AI-проекта.
Вердикт: «почти готово» — не состояние, а настроение.
Этапы связаны по содержанию, поэтому параллельная работа их не сжимает
Предложение «давайте делать параллельно» звучит на каждом обсуждении сроков и почти никогда не даёт обещанного эффекта. Причина в том, что этапы связаны не организационно, а содержательно.
Настроить обработку нельзя, пока не понятно, какие данные приходят. Проверить качество нельзя, пока не собрана размеченная выборка. Обучить людей нельзя, пока поведение системы не устоялось — иначе учить придётся дважды. Попытка идти параллельно приводит к переделке, и суммарное время растёт. Та же история, что со стройкой: отделку можно заказать заранее, но класть её до того, как высохла стяжка, значит класть дважды.
Что действительно параллелится: сбор материалов и согласование доступов идут одновременно с разбором процесса, потому что не зависят от его результата. Всё остальное лучше выстраивать последовательно и экономить на другом — на сужении первого шага.
Вердикт: параллельно можно готовиться, но не делать.
Ожидание решений на вашей стороне сопоставимо со сроком самой работы
Подрядчик отвечает за свою часть, и обычно она предсказуема. Растягивают проект решения, которые принимаются на стороне заказчика, и это стоит осознать до подписания.
Типичный набор: согласование содержания ответов, утверждение формулировок, решение по спорным случаям, приёмка. Каждый из этих шагов занимает минуты работы и недели ожидания, если у него нет владельца с полномочиями.
Практический приём — посчитать заранее. Выпишите все точки, где нужно ваше решение, и по каждой укажите, кто решает и за какой срок. Сумма ожиданий обычно оказывается сопоставимой со сроком самой работы, и это самое дешёвое место для сокращения.
Мы в 404ai считаем отсутствие такого человека причиной не начинать проект, а не поводом начать и надеяться: без владельца процесса внедрение упирается в согласования и не доходит до результата. Это одно из условий, записанных на странице «Как мы работаем».
Срок пилота задаёт метрика, а не календарь
Пилот часто планируют как отрезок времени: две недели — и решение. Но истёкший срок сам по себе ничего не доказывает. Пилот заканчивается, когда получен ответ на вопрос, ради которого его запускали, а вопрос этот формулируется до старта: какой показатель должен измениться, как его считать и при каком результате работа останавливается.
Отсюда два правила, которые экономят месяцы. Первое: расширять пилот на весь поток имеет смысл, когда за день сплошного чтения результатов не нашлось ни одной неверной отработки, а не когда закончилось отведённое время. Второе: если показатель за срок пилота не сдвинулся, это тоже результат — выводы фиксируются, и решение принимается по ним, а не продлением «ещё на пару недель посмотреть».
По этой логике устроен наш метод «Цель → метрика»: цель и способ замера записываются до запуска, пилот идёт на данных компании, у каждого шага есть точка, где можно остановиться. Что делать, если пилот не дал результата, разобрано в статье «Пилот провалился: что делать дальше».
Вердикт: пилот без условия остановки не заканчивается — он превращается в эксплуатацию, за которую никто не принимал решения.
Быстрое внедрение не нужно, если его результат нечем измерить
Гонка за сроком имеет смысл, когда каждая неделя без решения стоит понятных денег. Бывает иначе, и тогда честнее не торопиться или не начинать вовсе.
Первый случай — метрику назвать не удаётся. Если неизвестно, в каком показателе должен проявиться результат, быстрый запуск даст работающий инструмент при неизменившейся отчётности, и через квартал никто не сможет сказать, окупился ли он. Второй — поток слишком мал: при паре обращений в день автоматизация не вернёт вложенного, как бы быстро её ни внедрили. Третий — внедрение попадает на пик сезона: запуск в момент, когда у отдела нет времени читать результаты пилота, откладывает настоящий срок, а не приближает его. Четвёртый — задача решается регламентом: если заявки теряются потому, что за них никто не отвечает, назначить ответственного можно за один день.
Я бы в любом из этих случаев сначала закрыл причину, а уже потом обсуждал сроки. Остальные признаки того, что ИИ сейчас не нужен, собраны в статье «Когда AI не нужен».
Вердикт: быстрый запуск ненужного проекта — это просто быстрый расход.
Сорванный срок не лечится новой датой, названной в тот же день
Первое, чего делать не нужно, — назначать новую дату немедленно. Дата, названная в тот же день, обычно оказывается такой же оптимистичной, как первая, и её срыв обходится дороже: доверие к оценкам исчезает.
Порядок разумнее такой. Понять, что именно не сделано и почему — по контрольным состояниям, а не по общему ощущению. Разделить причины на устранимые и нет: отсутствие данных устранимо, недооценка сложности задачи — не всегда. Пересобрать оставшийся объём и назвать дату по нему, а не по остатку от прежнего плана.
И честно решить вопрос объёма. Часто правильный ответ — не двигать дату, а сократить содержание: выпустить меньше, но в срок, и добавить остальное следующим этапом. Для большинства процессов это лучше, чем ждать полного решения ещё квартал.
Вердикт: вторая дата должна быть посчитана, а не названа.
Честный ответ о сроке состоит из трёх чисел
Он почти никогда не помещается в одну цифру. Первое число — срок разбора: сколько нужно, чтобы посмотреть процесс и данные. Второе — срок до первого измеримого результата на самом дорогом узком месте. Третье — горизонт всей работы с оговоркой, от чего он сдвинется.
Такой ответ хуже продаётся и лучше исполняется. Если подрядчик даёт его сразу и без вопросов, у него либо очень похожий опыт, либо готовность назвать любую цифру. Срок и стоимость обычно обсуждают вместе, и логика у них одна — как читать смету, разобрано в статье о том, сколько стоит внедрение ИИ.
Что изменить в разговоре, где прозвучит «за сколько внедрите»
Главное следствие для решения: сравнивать подрядчиков по названному сроку бессмысленно, пока не известны три вещи с вашей стороны — в каком виде данные, кто принимает решения по процессу и какой показатель будет считаться результатом. Срок подрядчика — только технологическая часть; остальное календарь проекта берёт из вашей компании.
Проверить это можно до первой встречи. Попросите IT выгрузить за месяц записи разговоров или переписки вместе с данными сделок и засеките, сколько дней это заняло. Назовите одного человека, чьё решение по процессу окончательно. Запишите одной строкой, какая цифра должна измениться. Если на всё ушла неделя, ваш проект длиннее опубликованных сроков примерно на эту неделю; если выгрузку сделать не удалось, начинать нужно с неё, а не со сравнения подрядчиков.
