От ТЗ к диагностике: как меняется модель AI-разработки

Полтора года назад мы работали как большинство команд разработки: заказчик приходил с задачей, мы её оценивали, согласовывали ТЗ и делали. Стандартный цикл.

Сейчас мы работаем иначе. Сами инициируем диагностику, сами ищем где автоматизация принесёт наибольший эффект, сами считаем ROI — до того как написана первая строка кода. Только потом договариваемся о разработке.

В этой статье — конкретная методология: как мы выбираем что автоматизировать, как считаем эффект в штатных единицах, как структурируем взаимодействие с промышленным заказчиком. С числами из реального проекта.

Почему модель изменилась

Классическая заказная разработка предполагает, что заказчик знает что ему нужно. Он приходит с задачей, команда её решает.

На практике это работает плохо по двум причинам.

Первая: заказчик сразу называет что хочет сделать, не объясняя зачем. «Нам нужен чат-бот для ответов на вопросы по регламентам» — это уже готовое решение. Но правильная ли это задача? Может, проблема в том, что регламенты устаревшие и никто их не читает? Или что новые сотрудники задают одни и те же вопросы потому что онбординг не выстроен?

Вторая: заказчик не знает реального объёма рутины внизу. Директор по закупкам знает что «закупки работают медленно». Он не знает что конкретно 5 из 32 специалистов тратят 60–70% времени на сравнение цен по 55 000 позиций номенклатуры — и именно это узкое место.

Чтобы строить правильное решение, нужно сначала найти правильную задачу. Если этого не сделать — построишь не то. Система работает, эффекта нет. Заказчик решает, что AI — хайп, и больше не возвращается.

Структура нашей модели работы

Мы разделили работу на три зоны ответственности.

Владелец кейса — назначается со стороны заказчика. Он ведёт диагностику, согласовывает гипотезы, принимает результат. Именно он отвечает за то, что потенциал кейса посчитан честно.

Команда (Sandboxer) — вместе с Владельцем проверяет гипотезы, проектирует, строит, поддерживает и обучает. Мы сдаём результат одновременно Владельцу и Заказчику.

Заказчик — управляет изменениями на своей стороне, даёт команде доступ к данным и системам через Владельца, не меняет уже зафиксированный эффект.

Ключевой принцип: приёмка по потенциалу кейса, а не по факту внедрения. Владелец считает базовый эффект → Заказчик корректирует или принимает → фиксируем цифру. Немотивированный отказ невозможен — только встречный расчёт.

Это убирает главный риск таких проектов: заказчик принял систему, но эффект «не случился» потому что не было управления изменениями на его стороне.

Фаза 0: диагностика

До старта разработки мы проводим диагностику. Обычно это 2–3 недели. Результат — перечень кейсов с базовым расчётом эффекта и критериями приёмки по каждому.

Как ищем кейсы

Интервью проводим на двух уровнях. Руководители дают контекст — где болит стратегически, какие цели стоят по оптимизации штата или росту эффективности. Исполнители дают данные — что делается руками, как часто, сколько времени.

Параллельно смотрим на структуру процессов по шкале зрелости:

хаос → упорядочен → стандартизован → измеряем → автоматизируем

Автоматизировать можно начиная с уровня «упорядочен». Процесс в состоянии «хаос» нужно сначала описать — иначе мы автоматизируем беспорядок и сделаем его быстрее, а не лучше.

Не каждый процесс стоит автоматизировать. Наш порядок: сначала убираем лишнее (100% экономии), потом упрощаем избыточное (50–70%), только потом подключаем AI (60–95%).

Методология расчёта эффекта

Эффект считаем в штатных единицах (ставках). Одна ставка — объём работы одного сотрудника при полной занятости за год: 220 рабочих дней, 1760 часов.

Почему ставки, а не деньги? Потому что это единица, в которой ведётся штатное расписание. Директор понимает «0,6 ставки» лучше чем «экономия 1,2 млн рублей» — он видит конкретную роль в конкретном подразделении.

Формула

Базовые трудозатраты (ставок) = Годовой объём × Время на операцию ÷ 1760 ч
Высвобождение (ставок) = Базовые трудозатраты × Доля автоматизации

Доля автоматизации зависит от класса процесса:

• Процесс идёт автоматически, человек контролирует выборочно → 80–95%
• Машина готовит результат, человек утверждает каждый → 50–75%
• Машина помогает (подсказки, поиск), решение за человеком → 15–35%
  

  Тройная перекрёстная проверка

  Каждый кейс оцениваем тремя независимыми методами, итоговая цифра — их пересечение.

  Снизу вверх — основной путь. Берём годовой объём операций (в идеале — прямой замер заказчика), умножаем на время одной операции, получаем базовые трудозатраты. Умножаем на долю автоматизации — потенциал.

  Сверху вниз — проверка по численности. Смотрим на подразделение в целом, оцениваем какая доля времени уходит на автоматизируемые операции. Сумма по кейсам не должна превышать численность направления.

  Внешний ориентир — сравнение с бенчмарками. ОМК (Объединённая металлургическая компания, тяжёлое машиностроение): в среднем 1,13 ставки на один сценарий автоматизации; крупные нефтяные компании с программами роботизации: 200+ ставок суммарно. Если наша цифра сильно выходит за коридор — пересматриваем допущения.

  

  Кейс: машиностроительный завод (NDA)

  Крупный машиностроительный завод, производство сложного технологического оборудования. Более 1100 человек в штате, из них около 700 административных. Старт диагностики — июнь 2026 года.

  За две недели выявили пять кейсов.

  Кейс 1. Технологические паспорта контроля

  Процесс: бюро учёта документов заполняет паспорта ФЗ3 и паспорта сварных соединений по чертежам и данным контроля.

  Данные: прямой замер заказчика — 1458 часов в год на этот тип документов. Бюро отмечено как недозагруженное, диагностика предлагает сократить одного инженера.

  Класс автоматизации: «машина готовит — человек утверждает» → доля 70%.

  Расчёт:

  Базовые = 1458 ÷ 1760 = 0,83 ставки
  Высвобождение = 0,83 × 70% = 0,58 ставки

  Сверху вниз: диагностика заказчика сама предлагает сократить 1 инженера → ~1,0 ставки снимаемой работы. 0,58 укладывается в этот резерв. Ориентир OMК: 1,13 ставки на сценарий — наша цифра ниже из-за меньшего объёма в одном бюро.

  Итог: ~0,6 ставки. Одна из самых надёжных цифр в модели — держится на прямом замере.

  Кейс 2. Поиск аналогов техпроцессов

  Процесс: 18 технологов ищут аналоги техпроцессов и повторно применяемых деталей по чертёжному номеру. Работают вручную по бумажным тетрадям и внутренней справочной системе.

  Данные: ~15 000 техпроцессов в год, средняя норма ручного поиска — 0,1 ч на одну операцию (прямой замер 2025 года).

  Класс автоматизации: поиск по чертёжному номеру автоматизируется почти полностью — мгновенная выдача вместо ручного перебора. За технологом остаётся только решение о применимости → доля 60–80%.

  Расчёт (снизу вверх):

  Базовые = 15 000 × 0,1 ÷ 1760 = 0,85 ставки
  Высвобождение = 0,85 × (60–80%) = 0,51–0,68 ставки

  Проверка сверху вниз: 18 технологов × (5–15% времени на поиск) = 0,9–2,7 ставки занято поиском. Высвобождение = 0,5–2,2 ставки. Нижняя граница согласуется с прямым замером.

  Итог: ~0,6 ставки (надёжная оценка по прямому замеру; верхняя — до 1,5 ставки при доле времени 15%).

  Кейс 3. Технико-коммерческие предложения: актуализация цен и подбор аналогов

  Процесс: около 300 ТКП в год. Реестр цен в 1С — 55 423 позиции, 91% старше трёх месяцев. Специалисты закупок занимаются расценкой, анализом дефицита, выходом на электронные площадки, поиском поставщиков.

  Данные: по хронометражу — на расценке и работе с предложениями занято 5–8 ставок из ~32 в отделе закупок.

  Класс автоматизации: основной труд (поиск цен по 55 тыс. позиций, черновики запросов, подбор аналогов) машина забирает почти полностью; за человеком — утвердить цену и поставщика → доля 40–60%.

  Расчёт (сверху вниз — основной путь здесь):

  Высвобождение = (5–8 ставок) × (40–60%) = 2,0–4,8 ставки

  Проверка снизу вверх: 300 ТКП × (1–2 дня на расценку) ÷ 220 = 1,4–2,7 ставки только на предложениях. Плюс текущая актуализация цен — согласуется с диапазоном выше.

  Итог: 3,5 ставки (диапазон 2–5; держится на оценке доли рабочего времени — уточняется хронометражем закупок).

  Кейс 4. Патентный поиск

  Процесс: ~10 поисковых тем в год, 2–5 дней специалиста на тему. Хронометража у заказчика нет — норма экспертная.

  Расчёт:

  Базовые = 10 × (2–5 дней) ÷ 220 = 0,09–0,23 ставки
  Высвобождение = 0,09–0,23 × (50–75%) = 0,05–0,17 ставки

  Итог: ~0,1–0,2 ставки. Эффект в ставках мал — объём небольшой. Основная ценность кейса: скорость и охват поиска, а не экономия труда.

  Кейс 5. Обработка служебных расходов (подотчёт)

  Процесс: оформление командировочных расходов через бухгалтерию. Прямой замер заказчика: сейчас нагрузка — 1,2 ставки бухгалтера на эту роль.

  У кейса два пласта эффекта: концентрированный (бухгалтерия) и распределённый (сами сотрудники, которые сегодня итерируют из-за некомплекта документов и последовательных согласований).

  Расчёт:

  • Эффект на бухгалтерию: 1,2 → 0,4 ставки = ~1,0 ставки (прямой замер)
  • Эффект на сотрудников: 1000–2000 событий/год × 0,5–1,5 ч × (60–80%) ÷ 1760 = ~0,4 ставки (распределённый, не вырезается как отдельная ставка — возвращается в основную работу людей)

  Итог: ~1,4 ставки суммарно.

  Итог по пяти кейсам

  Кейс	Потенциал	На чём держится
  Паспорта контроля	0,6 ст.	Прямой замер 1458 ч/год × 70%
  Аналоги техпроцессов	0,6 ст.	Прямой замер 15 000 ТП × 0,1 ч × 60–80%
  Цены и аналоги (ТКП)	3,5 ст.	Занятость закупщиков × доля класса
  Патентный поиск	~0,1–0,2 ст.	Объём × экспертная норма
  Подотчёт	1,4 ст.	Прямой замер бухгалтерии + распределённый
  Итого	~6,3 ст.

  Это нижняя граница. Верхние оценки по диапазонам — до 8,4 ставки.

  От потенциала к реальному эффекту

  Потенциал — это при полном освоении на момент приёмки. Реальный эффект растёт по кривой освоения:

  Срок	Освоение	Реально от 6,3 ставок
  5 месяцев	~30%	1,0–1,3 ставки
  12 месяцев	~60%	1,9–2,7 ставки
  24 месяца	~80%	2,5–3,5 ставки

  

  По данным McKinsey (340 тыс. проектов изменений): в среднем достигается 67% максимального эффекта. Forrester: в среднем 48% от первоначального расчёта. Мы закладываем реалистичный коридор 48–67% от потенциала.

  Что это меняет в разработке

  Когда у вас есть цифра до старта, меняется всё.

  Архитектурные решения принимаются исходя из стоимости операции, а не из «лучших практик». Если кейс даёт 0,2 ставки, не нужна сложная инфраструктура — нужно быстрое и простое решение. Если кейс даёт 3,5 ставки — стоит инвестировать в качество и интеграции.

  Приёмка становится объективной. «Работает или не работает» заменяется на «доля автоматических сопоставлений не ниже согласованного порога», «95% строк закупки имеют однозначного конечного получателя», «снижение ручного труда разбора поставок на 30–50%».

  Управление изменениями планируется заранее. Мы знаем что эффект придёт через 5 месяцев и нарастёт за два года — и строим под это коммуникацию с командой заказчика, обучение, пилотные группы.

  Выводы

  Три вещи, которые изменила эта модель в нашей работе:

  1. Мы строим то что нужно, а не то что попросили. Диагностика часто показывает, что заказчик хочет автоматизировать следствие проблемы, а не причину. Мы видим это раньше, чем начинается разработка.

  2. Риск проекта распределяется честно. Заказчик принимает не «систему», а «потенциал». Если система работает, но эффект не реализовался — значит что-то не так на стороне внедрения. Это разговор про управление изменениями, а не про качество кода.

  3. Экспертиза в процессах защищает от коммодитизации. Написать код становится всё проще — AI-инструменты ускоряют разработку кратно. Но знать как работают закупки по 223-ФЗ, как устроена прослеживаемость МТО на промышленном предприятии, где реально теряется время — это строится годами и не автоматизируется.

  ---

Читать полностью на источнике