Модуль p.4 · Урок 5
Урок 5: Адресное обоснование — на каком языке говорить с директором, CFO, ИБ, ИТ, HR
Содержание
- Чему вы научитесь
- Почему одинаковый питч почти гарантированно ломает проект
- Карта стейкхолдеров: кто что слышит
- Как переводить одну инициативу на восемь управленческих языков
- Директор завода
- Главный инженер
- Финансовый директор
- Начальник цеха
- Оператор / мастер
- ИБ / СБ
- ИТ-директор
- HR
- Что нести на встречу, кроме презентации
- Где чаще всего допускают ошибку
- Итоги
Чему вы научитесь
- Переводить один и тот же AI-проект на язык бизнеса, производства, финансов, ИБ, ИТ и HR
- За пять минут понимать, что именно считает успехом каждый ключевой стейкхолдер
- Разворачивать типовые возражения без общих слов про «инновации» и «цифровизацию»
- Готовить отдельные формулировки для директора завода, CFO, начальника цеха, оператора и службы ИБ
- Собирать карту влияния проекта так, чтобы он не умирал на стыке финансов, эксплуатации и комплаенса
Один и тот же AI-проект может быть одновременно хорошей идеей для директора завода, лишним риском для ИБ, источником расходов для CFO и угрозой для мастера смены. Поэтому адресное обоснование — не «мягкий навык», а часть защиты бюджета. Российские кейсы уже измеряют эффект AI не абстрактной «цифровизацией», а миллиардами рублей: ЕВРАЗ сообщил о 5,8 млрд ₽ эффекта за 2024 год, Северсталь — более 1 млрд ₽, Газпром нефть в прогнозах 2019–2020 годов оценивала эффект цифровых технологий, включая AI, около 6 млрд ₽ в год к 2025 году, а Минэнерго РФ оценивало потенциальный эффект AI для нефтегаза в 5,4 трлн ₽ к 2040 году (дата исследования: апрель 2026). На защите проекта это означает простую вещь: вас будут слушать не как evangelist AI, а как человека, который умеет перевести один и тот же проект в восемь разных логик принятия решения.
Почему одинаковый питч почти гарантированно ломает проект
Самая частая ошибка выглядит так: команда готовит один красивый слайд, на котором написано, что AI «ускорит процессы», «снизит издержки» и «повысит качество решений». Такой язык не цепляет никого.
Директор завода слышит общие слова и не понимает, как это связано с планом производства. Главный инженер не видит, станет ли меньше аварийных остановов. CFO не понимает, когда вернутся деньги. Начальник цеха предполагает, что ему навесят ещё одну систему без реальной пользы. Оператор думает, что систему внедряют для контроля или сокращения. ИБ видит новый внешний контур и новые риски. ИТ-директор — ещё одну интеграцию и ещё один сервис, который потом придётся сопровождать. HR — потенциальный конфликт с персоналом и потребность в обучении.
Карта стейкхолдеров: кто что слышит
| Стейкхолдер | Что волнует | На чём делать акцент | Типовое возражение | Как ответить | Контрольный вопрос к вам |
|---|---|---|---|---|---|
| Директор завода | EBITDA, выполнение плана, OEE, стабильность производства | Деньги, выпуск, производительность, влияние на план и репутацию площадки | «У нас уже много пилотов, а эффекта мало» | Покажите, какой KPI площадки изменится и как это связано с выпуском и маржой; опирайтесь на расчёт из урока 1 модуля p.4 | Можете ли вы назвать одну заводскую метрику, которая изменится в течение года? |
| Главный инженер | Надёжность, простои, безопасность, ремонтный цикл | Снижение аварийных остановов, предсказуемость обслуживания, ручной override | «Нельзя ставить ещё одну нестабильную систему в производственный контур» | Объясните, где система советует, а где не управляет; покажите fallback и режим ручного возврата | Понимаете ли вы, где заканчивается рекомендация AI и начинается решение инженера? |
| Финансовый директор | Payback, TCO, NPV, IRR, риск перерасхода | CapEx, OpEx, срок окупаемости, чувствительность сценария | «Вижу расходы сейчас, а эффект потом и без гарантий» | Защищайте проект консервативным сценарием и отделяйте разовые инвестиции от постоянных затрат; опирайтесь на TCO-логику из урока 6 модуля p.2 | Есть ли у вас консервативный сценарий, который переживёт вопрос «а если эффект будет вдвое ниже»? |
| Начальник цеха | KPI смены, план, дисциплина, лишняя нагрузка на людей | Упрощение рутины, меньше разборов брака, меньше ручных проверок | «Мне добавят систему, а отвечать за её ошибки буду я» | Покажите, что AI снимает ручную нагрузку и не забирает право последнего решения в критичном сценарии | Видит ли начальник цеха личную пользу для своей смены уже в пилоте? |
| Оператор / мастер | Стабильность работы, понятность интерфейса, сохранность роли | Удобство, скорость, меньше рутины, обучение до запуска | «Меня хотят заменить или начать тотально контролировать» | Сразу говорите, что цель — не сокращение человека, а снижение рутинных операций и помощь в принятии решений | Есть ли у вас честный ответ на вопрос «что изменится в моей смене завтра утром»? |
| ИБ / СБ | Контур данных, утечки, санкции, соответствие требованиям | Архитектура, сегментация, правовые границы, стандарты, аудит | «Вы принесли новый риск, который никто не сможет защитить» | Разговаривайте через допустимый контур, роли и меры контроля; здесь нужны связка с уроком 6 модуля p.3 и уроком 8 модуля p.3 | Можете ли вы показать, где живут данные, кто отвечает за риск и по какому стандарту проектируется система? |
| ИТ-директор | Поддержка, интеграция, SLA, совместимость со стеком | Эксплуатационная модель, интеграции, логирование, владение сервисом | «После пилота это останется на моей команде без ресурса и документации» | Покажите целевой контур эксплуатации, кто администрирует решение и какие системы уже затронуты | Понимаете ли вы, кто будет сопровождать решение через шесть месяцев после запуска? |
| HR | Обучение, сопротивление персонала, удержание, роль руководителей | Переобучение, новые роли, прозрачность изменений, не сокращение ради эффекта | «Персонал воспримет проект как скрытое сокращение или контроль» | Объясните, какие навыки появятся, как будет идти обучение и почему проект не стартует без людей | Есть ли у вас план коммуникации и обучения, а не только план внедрения технологии? |
Эта таблица нужна не для красивой презентации. Это ваш чек-лист перед любой встречей. Если вы не можете заполнить колонку «контрольный вопрос к вам», значит, вы ещё не готовы к разговору с конкретным человеком.
Как переводить одну инициативу на восемь управленческих языков
Представим один и тот же проект: AI-помощник для разбора причин брака и подготовки рекомендаций мастеру смены. Сам проект один, но язык обоснования будет разным.
Директор завода
Неправильный заход: «Мы хотим внедрить AI-ассистента для анализа производственных данных».
Правильный заход: «Мы сокращаем время разбора причин брака и быстрее возвращаем линию в стабильный режим. Для завода это проект про выпуск, качество и выполнение плана, а не про модную технологию».
Директор завода не покупает модель. Он покупает влияние на итог площадки. Поэтому разговор должен идти через OEE, выход годного, план и EBITDA. Если у вас нет прямой связи между системой и одной верхнеуровневой метрикой, для него это пока эксперимент, а не производственная инициатива.
Главный инженер
Неправильный заход: «Модель будет подсказывать лучшие действия оператору».
Правильный заход: «Система не забирает управление оборудованием. Она помогает быстрее увидеть комбинацию факторов, которые раньше искали вручную, и оставляет инженеру право окончательного решения».
Главного инженера интересуют надёжность, безопасность и предсказуемость. Его нужно успокоить не обещанием высокой точности, а границами применения. Покажите, где AI даёт рекомендацию, где стоит ручной override, как устроен fallback и что происходит при ошибке модели. Здесь особенно важно не путать аналитический помощник и автоматическое управление.
Финансовый директор
Неправильный заход: «Проект стратегически важен, потому что AI становится отраслевым стандартом».
Правильный заход: «Вот CapEx, вот TCO, вот консервативный payback, вот сценарий, при котором эффект вдвое ниже ожидаемого, и вот почему проект всё равно остаётся в зелёной зоне».
CFO не обязан верить в технологический энтузиазм. Он обязан отсекать проекты с неуправляемым расходом. Поэтому ваш язык здесь — сценарии, чувствительность, структура затрат и защита от оптимизма команды. Всё, что вы считаете в ROI, должно быть разложено на допущения и источники. Именно поэтому этот урок связан с уроком 1 модуля p.4 и уроком 6 модуля p.2: сначала экономика, потом обещания.
Начальник цеха
Неправильный заход: «Проект повысит прозрачность процессов и дисциплину исполнения».
Правильный заход: «Система снимет часть ручных проверок, быстрее соберёт фактуру по отклонениям и сократит число ситуаций, где смена остаётся один на один с разбором брака».
Начальник цеха смотрит на проект через свою смену и свои KPI. Если он чувствует, что внедрение усложнит жизнь людям и не даст быстрого локального выигрыша, он станет пассивным тормозом. В разговоре с ним важны не стратегия и не архитектура, а конкретный выигрыш для участка: меньше ручной рутины, меньше повторных разборов, меньше «висящих» решений на смене.
Оператор / мастер
Неправильный заход: «Новая система будет контролировать качество ваших действий и давать объективные рекомендации».
Правильный заход: «Система берёт на себя часть рутинного поиска по данным и журналам, чтобы мастер быстрее понимал ситуацию. Она не отменяет опыт человека и не вводится без обучения и параллельного режима».
Оператор слышит проект телом, а не презентацией. Его интересует, станет ли сложнее интерфейс, увеличится ли давление, исчезнет ли зона автономии. Поэтому важнее всего заранее проговорить две вещи: проект не стартует без обучения и у человека остаётся понятное право отклонить рекомендацию в установленном регламенте. Без этого change management превращается в сопротивление ещё до пилота.
ИБ / СБ
Неправильный заход: «Мы возьмём best practice-решение, оно enterprise-grade и у крупных компаний уже работает».
Правильный заход: «Вот контур данных, вот границы сети, вот роли, вот допустимость сервиса, вот стандартный пакет требований и вот кто несёт ответственность за риск».
Для ИБ бессмысленно говорить языком удобства. Нужен язык границ. Где живут данные? Есть ли внешний сервис? Допустим ли он для вашего контура? Какие меры вы берёте из урока 6 модуля p.3? Кто отвечает по ролям из урока 8 модуля p.3? Если на эти вопросы нет прямых ответов, служба ИБ правильно делает, что тормозит проект.
ИТ-директор
Неправильный заход: «Это маленький пилот, потом разберёмся, как встроить в стек».
Правильный заход: «Пилот малый, но эксплуатационная модель понятна уже сейчас: где будет жить сервис, кто его поддерживает, как устроены логирование, резервирование, доступы и интеграции».
ИТ-директор думает не про демо, а про хвост сопровождения. Любой пилот, который не отвечает на вопрос «кто это будет поддерживать после внедрения», воспринимается как технический долг в стадии рождения. Поэтому с ИТ нужен разговор про эксплуатацию, ownership, документацию, интеграции и отказоустойчивость. Даже если вы пока запускаете стенд, покажите, что понимаете конечную операционную модель.
HR
Неправильный заход: «Проект повысит производительность персонала».
Правильный заход: «Проект меняет профиль работы людей: убирает часть рутины, добавляет новые требования к навыкам и требует отдельной программы обучения руководителей и пользователей».
HR включается в AI-проект не из вежливости. Если система влияет на рабочие практики, интерфейсы, роли мастеров и ожидания от руководителей смен, без HR вы получите тихое сопротивление. Служба HR должна видеть не только технологию, но и маршрут адаптации: кого учим, кто первый пользователь, как объясняем изменения, какие страхи снимаем, какие навыки считаем обязательными.
Что нести на встречу, кроме презентации
Адресное обоснование — это не набор красивых тезисов. Это пакет ответов, который у каждого стейкхолдера собирается по-разному.
Зафиксируйте общий экономический каркас. До любой встречи у вас должны быть одна метрика эффекта, один консервативный сценарий и одно управленческое ограничение. Без этого каждый разговор начнётся заново.
Разложите карту интересов. Отдельно выпишите, чего боится человек, с которым вы идёте говорить, и чем он лично рискует, если проект пойдёт плохо.
Сформулируйте правильный и неправильный заход. Это дисциплинирует. Пока вы не можете своими словами показать, как не надо начинать разговор, вы, скорее всего, сами ещё говорите слишком общо.
Подготовьте один контрольный вопрос к себе. Не к собеседнику, а к себе. Если не можете на него ответить, встречу лучше перенести, чем импровизировать на ходу.
Разделите очередность встреч. Не ведите всех в одну комнату слишком рано. Сначала выравнивайте экономику, затем допустимость контура, потом эксплуатацию и только после этого идите в общий комитет.
Фиксируйте не согласие, а условия согласия. После разговора должно быть понятно, при каких условиях человек поддержит проект, а не просто «в целом не возражает».
Где чаще всего допускают ошибку
Первая ошибка — продавать всем технологию. Но стейкхолдерам не нужен AI как объект восхищения. Им нужна решённая проблема в их зоне ответственности.
Вторая ошибка — начинать с отраслевых трендов. Для директора завода и CFO фраза «так делают лидеры рынка» ничего не стоит, если вы не привязали её к их деньгам, рискам и срокам.
Третья ошибка — тащить ИБ и ИТ в разговор слишком поздно. Когда сервис уже выбран, а архитектура уже мысленно утверждена, служба ИБ и ИТ становятся не партнёрами, а функцией отказа. Это не их вина, а ваша последовательность.
Четвёртая ошибка — разговаривать с операторами в последнюю очередь. На производстве проект живёт или умирает не только на комитете, но и в смене. Если мастер и оператор не приняли новую логику работы, пилот формально существует, а операционно — нет.