Нельзя автоматизировать бардак

Навигатор: документ не обязательно читать целиком

Как я не старался, как не боролся над объемом, все равно документ получился большой, и это сделано намеренно: внутри не рассуждения, а инструменты - тест, чек-листы, шаблоны. Пользоваться ими можно выборочно.

Ниже - четыре маршрута под разные ситуации. Найдите свою и читайте только то, что нужно сейчас. Остальное останется на потом. Не забываем про глоссарий – он незримо присутствует и ждет прочтения.

Выберите свой маршрут

Маршрут 0. Зашел не в ту дверь – интересно, что здесь написано 5-7 минут

Прочитать, понять принцип, отложить документ до момента, когда пригодится

→ Раздел 5 - Закон, который не изменился: главный тезис в двух абзацах

→ Раздел 4.6 - Два контура зрелости: почему ИИ проваливается чаще, чем ERP

→ Раздел 11 – FAQ: 20 вопросов, которые задают чаще всего

Что в каждом разделе

Полная карта документа - на случай, если нужно найти что-то конкретное.

Три способа использовать документ

Прочитать - это только первый из них.

Первый. Пройти тест зрелости и понять, где вы находитесь. Двадцать минут, и картина становится честной. Результат можно показать руководству - это разговор с цифрами, а не с ощущениями.

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

Третий. Передать документ тому, кто будет вести проект внутри компании. Он получит и метод, и инструменты, и понимание, где обычно ломается.

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

Что происходит с ИИ-проектами

Прежде чем говорить о методе, посмотрим на цифры. Они одинаковы для всего мира, и российская промышленность не исключение.

• Мировая картина: четыре независимых исследования

В 2025 году сразу несколько исследовательских организаций измерили результативность корпоративных ИИ-проектов. Методики разные, вывод один.

График: провалы ИИ-проектов по данным пяти независимых исследований

Вот здесь я хочу сказать одну вещь, которую многие не говорят. Эти цифры - не приговор технологии. Это приговор подходу. Я видел проекты, где ИИ внедряли за три месяца и получали результат. И видел проекты, где два года шли к тому же результату - и не пришли. Разница не в модели. Разница в том, что было ДО модели.

В одном проекте мне сказали: «У нас всё готово, давайте ставить ИИ». Я спросил: «А покажите мне ваши регламенты». Мне показали. Я спросил: «А покажите, как вы ищете документ». Мне показали - 40 минут. Я сказал: «Ребята, вам не ИИ нужен. Вам порядок нужен». Они обиделись. Через год вернулись. Уже без обиды.

Поэтому когда вам говорят «95% провалов» - не пугайтесь. Пугайтесь, когда вам говорят «у вас всё готово, давайте ставить». Вот это действительно страшно.

Обратите внимание на разброс от 42 до 95 процентов. Это не противоречие - исследования измеряли разные точки жизненного цикла. MIT смотрел на финансовую отдачу, IDC - на выход в промышленную эксплуатацию, S&P - на решение свернуть проект. Вместе они описывают одну картину: подавляющее большинство ИИ-инициатив не доживает до результата.

Ещё одна цифра для масштаба. По оценке IDC на начало 2025 года, на каждые 33 запущенных пилота приходилось 4, дошедших до эксплуатации. Годом позже, в CIO Playbook 2026, доля дошедших выросла до 46% - рынок учится, и это подтверждает, что дело не в технологии, а в подготовке При этом те, что дошли, дают в среднем 171% возврата на вложения. То есть ИИ работает - когда проект доведён до конца правильно.

Почему проваливаются: причина одна

Здесь исследователи тоже сходятся. В опросе Gartner 38% руководителей назвали качество данных прямой причиной провала - столько же, сколько нехватку экспертизы. MIT в отчёте GenAI Divide формулирует ещё жёстче: 80% работы по переводу пилота в эксплуатацию - это не разработка модели, а инженерия данных, управление данными и интеграция.

«Вопрос не в том, какую модель купить. Вопрос в том, готовы ли ваши данные к промышленной эксплуатации.»

Gartner прогнозирует, что к концу 2026 года 60% ИИ-проектов, начатых без подготовленных данных, будут заброшены. И отдельно - более 40% проектов с ИИ-агентами будут отменены к концу 2027 из-за роста затрат и неясной ценности.

Инфографика: где именно ломаются ИИ-проекты

• Российская картина

В России ситуация та же, только с поправкой на стадию рынка.

• Около 80% попыток внедрения ИИ в бизнесе заканчиваются неудачей - оценка отраслевых экспертов, май 2026 года.

• В промышленную эксплуатацию выходит примерно 20% ИИ-продуктов.

• Более 70% российских компаний уже используют генеративный ИИ хотя бы в одном процессе.

• При этом только 26% компаний, закладывающих бюджет на ИИ, имеют стратегию его внедрения.

Я поясню, что значит «26 процентов имеют стратегию». Это значит, что три из четырёх компаний, которые сегодня тратят деньги на ИИ, не знают, зачем они это делают. У них нет ответа на вопрос «зачем», нет ответа на вопрос «как поймём, что получилось», и уж точно нет ответа «кто отвечает».

Я видел это своими глазами в двадцати с лишним организациях. Руководитель выходит и говорит: «Сорок процентов работы должен делать ИИ». И все расходятся по кабинетам. Один закупает подписки. Второй запускает пилот. Третий тихо саботирует. Четвёртый рисует отчёт с процентами, которые никто не проверит.

Через полгода проект закрывают. Тихо. Без разбора причин. А потом начинают заново.

Три четверти компаний тратят деньги на ИИ, не имея плана. Это и есть главная причина, по которой российская статистика провалов совпадает с мировой.

Проникновение ИИ по отраслям в России

График: проникновение ИИ по отраслям в России

Промышленность - на последнем месте по проникновению, но не по потенциалу. Классическое машинное обучение здесь давно доказало состоятельность: предиктивная аналитика оборудования, компьютерное зрение для контроля качества, цифровые двойники - решения с понятной экономикой и измеримым результатом.

Отставание промышленности объясняется просто. В телекоме и банках данные изначально цифровые и структурированные. На заводе значительная часть информации живёт в бумажных регламентах, головах мастеров и разрозненных таблицах. Именно поэтому в промышленности первый шаг - наведение порядка - критичнее, чем где-либо ещё.

Что из этого следует

Если данные названы причиной провала так же часто, как нехватка экспертизы. Первичен ответ на вопрос: в каком состоянии ваши процессы и данные прямо сейчас?

Именно на этот вопрос отвечает тест в части 4 этого документа. Пройдите его до того, как начнёте разговаривать с подрядчиками. Тогда вы либо сэкономите бюджет пилота, либо войдёте в проект с открытыми глазами.

• Тридцать лет до ИИ: что говорит статистика: почему 26% проектов заканчиваются успешно?

Мы говорили про ИИ. Теперь посмотрим, что происходило в ИТ всё это время - задолго до того, как появились большие языковые модели.

С 1994 года исследовательская группа Standish публикует отчёт CHAOS - самое цитируемое исследование результативности ИТ-проектов. База - более 50 тысяч проектов. Проект считается успешным только если завершён в срок, в рамках бюджета и с полным согласованным функционалом. Всё остальное - «проблемный» или «провальный».

Данные по открытым публикациям и вторичным источникам. Полные версии отчётов коммерческие. Методология менялась: в 2015 году в критерий успеха добавлена удовлетворённость пользователя, что снизило показатель примерно на 7 процентных пунктов. За 2006 и 2012 годы источники расходятся. CHAOS 2020 объявлен последним выпуском серии.

Я смотрю на эту таблицу и вижу себя. Я начинал в 1999 году с IBM Rational. Тогда успешных проектов было 26 процентов. Сейчас, спустя двадцать с лишним лет - 31 процент.

За эти годы сменилось всё. Методологии: от водопада к Agile, от Agile к DevOps. Архитектуры: от клиент-сервера к микросервисам. Инструменты: от ClearQuest до Jira. Появились облака, контейнеры, генеративный ИИ.

А линия успеха - вот она. 29–37 процентов. Четверть века. Не сдвинулась.

И каждый раз, когда приходит новая волна - а сейчас это ИИ - кто-то говорит: «Уж теперь-то всё изменится». Не изменится. Пока вы не начнёте с процессов.

График: плоская линия под волнами технологий

Что видно на этом графике

За двадцать шесть лет доля успешных проектов выросла с 16 до 31 процента и там застряла. Коридор 29-37% держится с 2002 года - почти четверть века.

А теперь посмотрите, что происходило в отрасли за эти же годы. Сменились методологии: от Waterfall к PMBOK, потом к Agile, потом к DevOps. Сменились архитектуры: клиент-сервер, SOA, микросервисы, облака. Сменились инструменты - от первых трекеров до Jira, Confluence, Azure DevOps. Появились контейнеры, машинное обучение, генеративный ИИ.

Каждая волна приходила с обещанием, что уж теперь-то всё изменится. Линия успеха не сдвинулась.

«Тридцать лет отрасль меняла инструменты. Результат остался прежним.»

Почему проваливаются: топ-10 факторов за 30 лет

Standish публикует не только проценты, но и факторы, влияющие на исход. Вот сводная картина по всем выпускам.

Главное наблюдение

Посмотрите на список ещё раз. Найдите там технологию.

Её нет. Ни языка программирования, ни платформы, ни базы данных, ни облака, ни методологии разработки. Ни Kubernetes, ни SAP, ни Python, ни GPT. За тридцать лет ни одна технология не вошла в топ-10 факторов успеха. Ни разу.

Все десять пунктов - про людей и решения. Поддержка руководства. Участие пользователей. Чёткие требования. Управление изменениями. Коммуникация. И еще: поддержка руководства, участие пользователей, чёткие требования, управление изменениями, коммуникация.

Ни языка программирования. Ни платформы. Ни базы данных. Ни облака. Ни Kubernetes. Ни SAP. Ни Python. Ни GPT.

Тридцать лет. Десять факторов. Ни одной технологии. Ни разу.

И вот что я хочу, чтобы вы запомнили: если вам продают ИИ как решение ваших проблем - вам продают не решение. Вам продают инструмент. А инструмент на хаосе не работает. Об этом следующий раздел.

«Проблемы возникают не потому, что компании не умеют писать код. А потому, что принимают слабые управленческие решения, плохо формулируют требования и не выстраивают взаимодействие между бизнесом и ИТ.»

Схема: 1994 против 2025 - те же причины

• Мостик к искусственному интеллекту

Вы думаете, за тридцать лет человечество изменило свою суть? Или на небесах переписали логику?

Люди те же. Организации те же. Причины провалов те же. Изменилась только скорость, с которой можно наделать ошибок - и цена этих ошибок.

Как выглядит «поддержка руководства» сегодня

Фактор номер один тридцать лет подряд. Все с ним согласны. Но что понимается под поддержкой на практике?

По наблюдениям на двадцати технологичных компаниях типичная картина такая. Руководитель выходит и объявляет: сорок процентов вашей работы должен выполнять ИИ.

Это не вовлечение. Это не поддержка. Это дань моде.

Дальше происходит предсказуемое. Каждый начинает делать так, как понял. Один закупает подписки на модели. Второй запускает пилот в своём отделе. Третий тихо саботирует, потому что боится за рабочие места подчинённых. Четвёртый рисует отчёт с процентами, которые никто не проверит.

Где здесь система? Где целевой результат? Кто отвечает за то, что получится?

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

Проверочный вопрос:

Если ваш руководитель сказал «нам нужен ИИ» - задайте ему три вопроса:

• Какую конкретную задачу это решает? Не «станем эффективнее», а какую.

• Как мы поймём, что получилось? Какое число, какой порог.

• Кто персонально отвечает за результат? Не «команда», а фамилия.

Если на все три есть внятный ответ - у вас есть поддержка. Если нет - у вас мода. И она стоит дороже, чем кажется. Двадцать проектов по пять миллионов - это сто миллионов на моду.

И это опаснее, чем полное отсутствие поддержки. Когда поддержки нет - проект просто не начинается, деньги остаются в компании. Когда есть имитация поддержки - начинается двадцать проектов одновременно, каждый со своим пониманием задачи, и все двадцать проваливаются параллельно.

Проверочный вопрос

Если ваш руководитель сказал «нам нужен ИИ» - задайте ему три вопроса. Какую конкретную задачу это решает? Как мы поймём, что получилось? Кто персонально отвечает за результат?

Если на все три есть внятный ответ - у вас есть поддержка. Если нет - у вас мода, и она стоит дороже, чем кажется.

«Поддержка руководства - это не лозунг с трибуны. Это ответ на три вопроса: зачем, как поймём что получилось, кто отвечает. Всё остальное - дань моде.»

Закон, который не изменился за 30 лет

Есть простое объяснение, почему провалов ИИ-проектов больше, чем провалов ERP-внедрений двадцать лет назад.

У любой организации есть два контура зрелости. Внешний - технологический: какие инструменты доступны, какие возможности открывает рынок. Он растёт стремительно, и за последние три года рванул как никогда. Внутренний - управленческий: умеете ли вы ставить задачи, договариваться, доводить до результата. Он растёт медленно, если растёт вообще.

Разрыв между контурами и есть зона провалов. Чем быстрее убегает технологический контур, тем шире разрыв, тем дороже ошибка.

Схема: два контура зрелости

«Не все освоили естественный интеллект, а хотят внедрить искусственный.»

Это не шутка, а точная формулировка проблемы. Прежде чем передавать решения машине, надо научиться принимать их самим - формулировать задачу, определять критерии, назначать ответственных. ИИ не заменит эту работу. Он её многократно усилит - в ту сторону, в которую вы её направите.

• Закон, который не изменился за 30 лет

«Меня всегда звали внедрить софт. Я всегда начинал с наведения порядка - даже когда за это не платили и об этом не просили. Потому что инструмент на хаосе не работает. С ИИ ровно то же самое, только счёт больше.»

Я работаю с этим с 1999 года. Тогда это был IBM Rational - ClearCase, ClearQuest, RequisitePro. Потом MS Project и Project Server, HP ALM, Jira и Confluence, TFS и Azure DevOps, отечественные трекеры после 2022 года. Инструменты менялись каждые несколько лет. Картина повторялась с точностью до деталей.

Компании покупали лицензии, ставили трекеры, запускали системы управления требованиями. Половина проектов давала нулевой эффект. Не потому что инструмент плохой - потому что под инструментом не было процессов. Разработчики сами на себя ставили задачи, поля были необязательными и свободными, никто не проверял связность данных.

Сейчас то же самое происходит с ИИ. Компании покупают доступ к моделям, нанимают интеграторов, запускают RAG-системы - и удивляются, что толку нет. Потому что RAG обучается на документах, которые никто не структурировал. Потому что агент отвечает на вопросы, которые никто не формализовал.

«Нельзя автоматизировать бардак. Умножишь бардак - получишь дорогой бардак.»

Иллюстрация: два цеха

• Почему об этом молчат

Вендор продаёт внедрение - ему невыгодно говорить «сначала наведите порядок в процессах». Интегратор продаёт часы - ему невыгодно говорить «вам это вообще не нужно». Стартап продаёт коробку - ему невыгодно говорить «коробка на вашем хаосе не взлетит».

Единственный, кто может сказать правду - тот, кому не платит ни один из них. Тот, кому платит только заказчик.

• Что даст этот документ

Этот документ не про меня. Он про то, как вам не потерять деньги. Внутри - тест зрелости, который покажет реальную готовность вашей компании; чек-лист вопросов, которые нужно задать подрядчику до подписания; шаблоны для сравнения предложений; и разбор провалов, чтобы вы узнали свою ситуацию заранее.

Пользуйтесь без меня. Если после теста станет ясно, что нужен внешний взгляд - контакты в конце.

Карта маршрутов: куда вы идёте

Я не веду всех по одному пути. После обследования наступает точка развилки - в каком состоянии ваши процессы. От ответа зависит весь дальнейший маршрут.

Карта маршрутов цифровизации (схема ИТ-ИИ-метро)

Общий ствол - для всех одинаковый

01 Обследование - что происходит с данными, процессами, инфраструктурой прямо сейчас.

02 Blueprint - целевая архитектура: что должно быть на выходе.

03 ТЗ и дорожная карта - требования, критерии приёмки, план этапов.

Развилка: четыре пути и один тупик

Ветка А. Процессы в хаосе

Исполнители сами на себя ставят задачи. Поля необязательны. Данные в свободном формате. Регламенты есть, но по ним не работают.

Комплексное обследование → Регламентация → Автоматизация → Выбор подрядчика ИИ

Срок ветки: 2-4 месяца. Пропустить нельзя - иначе автоматизируете хаос.

Ветка Б. Инструменты есть, но работают криво

Купили трекер, поставили систему - толку нет. Процессы не описаны, инструмент не настроен под реальную работу.

Регламентация → Донастройка купленного → Пилот → Выбор подрядчика ИИ

Срок ветки: 1-2 месяца. Часто новый софт вообще не нужен - хватает донастройки.

Ветка В. Порядок, готов к ИИ

Процессы описаны, данные структурированы, команда работает по регламентам. Прямо к выбору подрядчика.

Срок ветки: 0. Не навязываю то, что вам не нужно.

Ветка Г. Нужно импортозамещение

Иностранный стек нужно заменить, не потеряв данные и темп. Главный риск - перенести бардак на новый адрес.

Подбор инструментов → Миграция данных → Пилот → Выбор подрядчика ИИ

Срок ветки: 1-3 месяца. Момент миграции - лучший повод пересмотреть процессы.

Тупик. Когда проект нельзя спасти

Три типа ситуаций, когда ИИ только ухудшит положение:

1. Заказчик не готов менять процессы. Автоматизация хаоса - дорогой хаос.

2. Заказчик не готов следовать рекомендациям. Делает по-своему - рискует сам.

3. Уверен, что к ИИ всё готово, но данные не структурированы. Замеряем - цифры говорят сами.

В каждом тупике я фиксирую риск письменно и предлагаю пилот на живом участке вместо полного масштаба. Решение - за заказчиком. Моя задача - чтобы он принимал его зрячим.

• Станции маршрута

Каждый этап - это не «мы поработаем». Это конкретный артефакт на выходе, конкретные критерии, конкретная цена.

Примерная последовательность этапов сотрудничества. Важно!!! Это - идеальный график, когда есть поддержка руководства (см. выше) и нет большой бюрократии.

Артефакт каждого этапа остаётся у вас, даже если дальше вы не идёте. После обследования - карта процессов, которой уже можно пользоваться. После ТЗ - документ, который можно отдать любому другому исполнителю.

«Право уйти после каждого этапа - высшая форма честности в контракте.»

Тест зрелости: готовы ли вы к ИИ

28 вопросов по четырём осям. Отметьте один вариант в каждом вопросе, сложите баллы. В конце - интерпретация результата и рекомендации.

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

Ось 1. Процессы (7 вопросов, макс. 21 балл)

1. Описаны ли ваши ключевые бизнес-процессы?

☐ Нет, всё держится на людях и устных договорённостях (0 б.)

☐ Частично - есть регламенты, но устаревшие (1 б.)

☐ Да, описаны, но по ним не всегда работают (2 б.)

☐ Да, описаны и соблюдаются, есть контроль (3 б.)

2. Есть ли владелец у каждого ключевого процесса?

☐ Нет такой роли (0 б.)

☐ Формально назначены, фактически не отвечают (1 б.)

☐ У части процессов есть (2 б.)

☐ Да, у всех, и они реально принимают решения (3 б.)

3. Знаете ли вы, где у вас узкие места?

☐ На уровне ощущений (0 б.)

☐ Есть предположения, не проверенные (1 б.)

☐ Часть измерена (2 б.)

☐ Да, измерены и приоритизированы по влиянию (3 б.)

4. Как часто меняются процессы?

☐ Постоянно, каждый работает как привык (0 б.)

☐ Меняются стихийно, без фиксации (1 б.)

☐ Меняются по решению, но без анализа последствий (2 б.)

☐ Через управляемую процедуру изменений (3 б.)

5. Есть ли повторяющиеся операции, которые отнимают много времени?

☐ Не анализировали (0 б.)

☐ Есть, но не считали объём (1 б.)

☐ Есть, примерно оценили трудозатраты (2 б.)

☐ Да, измерены в часах и деньгах (3 б.)

6. Что происходит, когда ключевой сотрудник уходит в отпуск?

☐ Процесс встаёт (0 б.)

☐ Работает с большими сбоями (1 б.)

☐ Есть замена, но качество падает (2 б.)

☐ Процесс не зависит от конкретного человека (3 б.)

7. Есть ли формализованная процедура приёмки работ подрядчика?

☐ Нет, принимаем «на глаз» (0 б.)

☐ Есть акт, но без критериев (1 б.)

☐ Есть критерии, но нечёткие (2 б.)

☐ Да, измеримые критерии до начала работ (3 б.)

Ось 2. Данные (7 вопросов, макс. 21 балл)

8. В каком виде хранятся ваши документы?

☐ Бумага и файлы на локальных дисках (0 б.)

☐ Общая папка без структуры (1 б.)

☐ Структурированное хранилище, но без единых правил (2 б.)

☐ Единая система с классификацией и версионностью (3 б.)

9. Сколько времени занимает поиск нужного документа?

☐ Спрашиваем у коллег, кто помнит (0 б.)

☐ От получаса (1 б.)

☐ 5-15 минут (2 б.)

☐ Меньше 5 минут через поиск (3 б.)

10. Есть ли владелец данных - роль, отвечающая за их качество?

☐ Нет (0 б.)

☐ Формально ИТ, фактически никто (1 б.)

☐ Есть по отдельным системам (2 б.)

☐ Да, назначен и наделён полномочиями (3 б.)

11. Дублируются ли данные между системами?

☐ Постоянно, и они расходятся (0 б.)

☐ Часто, сверяем вручную (1 б.)

☐ Иногда, есть частичная интеграция (2 б.)

☐ Единый источник истины по каждой сущности (3 б.)

12. Есть ли у документов единый формат и шаблоны?

☐ Каждый пишет как хочет (0 б.)

☐ Шаблоны есть, но их игнорируют (1 б.)

☐ Большинство документов по шаблону (2 б.)

☐ Да, единые шаблоны с обязательными полями (3 б.)

13. Насколько актуальна ваша документация?

☐ Устарела, реальность другая (0 б.)

☐ Частично актуальна (1 б.)

☐ Актуальна по ключевым направлениям (2 б.)

☐ Обновляется по регламенту (3 б.)

14. Оценивали ли вы объём данных, пригодных для обучения ИИ?

☐ Нет (0 б.)

☐ Приблизительно, «у нас много документов» (1 б.)

☐ Посчитали объём, не оценивали качество (2 б.)

☐ Да, объём и качество оценены (3 б.)

Ось 3. Люди и изменения (7 вопросов, макс. 21 балл)

15. Как в компании обычно принимают новые инструменты?

☐ Сопротивляются, работают по-старому (0 б.)

☐ Формально принимают, фактически саботируют (1 б.)

☐ Принимают после долгого обучения (2 б.)

☐ Быстро осваивают, есть внутренние амбассадоры (3 б.)

16. Есть ли внутри компании человек, который будет вести ИИ-проект?

☐ Нет (0 б.)

☐ Есть, но у него нет времени (1 б.)

☐ Есть, частичная занятость (2 б.)

☐ Да, выделен и мотивирован (3 б.)

17. Как руководство относится к изменению процессов?

☐ Спустило цифру сверху («40% работы - на ИИ») без объяснения зачем (0 б.)

☐ Хочет инструмент, не трогая процессы (0 б.)

☐ Готово на словах, не на деле (1 б.)

☐ Готово к точечным изменениям (2 б.)

☐ Понимает, что процессы изменятся, и поддерживает (3 б.)

18. Был ли у вас опыт неудачного внедрения?

☐ Да, и причины не разбирали (0 б.)

☐ Да, причины обсудили устно (1 б.)

☐ Да, разобрали и зафиксировали выводы (2 б.)

☐ Нет, или все внедрения были успешными (3 б.)

19. Кто в компании принимает решение по ИТ-бюджету?

☐ Непонятно, решения затягиваются (0 б.)

☐ Коллегиально, долго (1 б.)

☐ Один человек, но нужно много согласований (2 б.)

☐ Понятный ЛПР с полномочиями (3 б.)

20. Готовы ли сотрудники тратить время на проект?

☐ Нет, все загружены (0 б.)

☐ Формально да, фактически нет (1 б.)

☐ Частично, по остаточному принципу (2 б.)

☐ Да, время выделено в графике (3 б.)

21. Есть ли практика обучения сотрудников новым инструментам?

☐ Нет, разбираются сами (0 б.)

☐ Разовые инструктажи (1 б.)

☐ Есть обучение при внедрении (2 б.)

☐ Системное обучение с проверкой усвоения (3 б.)

Ось 4. Управление и цели (7 вопросов, макс. 21 балл)

22. Сформулирована ли конкретная задача для ИИ?

☐ Нет, хотим «что-нибудь с ИИ» (0 б.)

☐ Общая идея без деталей (1 б.)

☐ Есть задача, но без метрик (2 б.)

☐ Да, с измеримым результатом (3 б.)

23. Как вы поймёте, что проект удался?

☐ По ощущениям (0 б.)

☐ «Станет удобнее» (1 б.)

☐ Есть качественные критерии (2 б.)

☐ Есть числовые критерии с порогами (3 б.)

24. Считали ли вы стоимость текущего ручного процесса?

☐ Нет (0 б.)

☐ Примерно (1 б.)

☐ Посчитали по одному направлению (2 б.)

☐ Да, в часах и деньгах (3 б.)

25. Есть ли бюджет на проект?

☐ Нет, ищем бесплатное решение (0 б.)

☐ Обсуждается (1 б.)

☐ Есть предварительный (2 б.)

☐ Утверждён с резервом на риски (3 б.)

26. Как вы выбираете подрядчиков?

☐ По рекомендации или кто первый написал (0 б.)

☐ Сравниваем цены (1 б.)

☐ Сравниваем по нескольким критериям (2 б.)

☐ Тендер по единому ТЗ с оценкой команды (3 б.)

27. Есть ли требования по защите данных?

☐ Не обсуждали (0 б.)

☐ Понимаем, что данные чувствительные (1 б.)

☐ Есть требования, не формализованы (2 б.)

☐ Формализованы, включая контур размещения (3 б.)

28. Что будет после запуска системы?

☐ Не думали (0 б.)

☐ Надеемся, что подрядчик поддержит (1 б.)

☐ Планируем поддержку (2 б.)

☐ Есть план развития и ответственный (3 б.)

Подсчёт и интерпретация результата

Сложите баллы по каждой оси отдельно, затем общую сумму. Максимум - 84 балла.

Радарная диаграмма для визуализации результата теста

Что означает ваш результат

0-25 баллов. ИИ подождёт

Внедрять ИИ сейчас - выбросить деньги. У вас нет ни процессов, ни данных, на которых система могла бы работать. Автоматизируете хаос - получите дорогой хаос.

Что делать: начать с обследования и регламентации процессов. Это 2-4 месяца работы, после которых можно вернуться к вопросу об ИИ. Хорошая новость - на этом этапе многие проблемы решаются без всякого ИИ, просто наведением порядка.

26-45 баллов. Точечный пилот

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

Что делать: выбрать один процесс с наибольшей зрелостью, сделать на нём пилот, параллельно подтягивать остальные. Не пытайтесь охватить всё сразу.

46-65 баллов. Готовы, но с подготовкой

Основа есть. Нужна адресная работа по слабым осям - обычно это данные или люди. При правильной последовательности проект взлетит.

Что делать: посмотрите, какая ось просела сильнее всего, и закройте её до старта. Если данные - структурировать. Если люди - назначить владельца проекта и снять сопротивление.

66-84 балла. Можно начинать

Вы готовы. Процессы описаны, данные структурированы, есть цели и метрики. Можно идти сразу к выбору подрядчика.

Что делать: сформировать ТЗ с измеримыми критериями, провести тендер, выбрать исполнителя. И следите за критериями здорового проекта из части 13.

«Заниженная оценка стоит дешевле, чем провалившийся проект. Если сомневаетесь между двумя вариантами - выбирайте меньший.»

• Прививка от введения в заблуждение: обещания подрядчиков, которые могут стоить вам проекта

Взаимодействие с подрядчиком всегда сложное, особенно когда необходимо разобраться в новом и неизвестном. Мы все понимаем игру: заказчику надо купить дешевле и качественно, подрядчику-исполнителю – дороже, и, желательно уже из готовых блоков. Хорошо это, или плохо – тема отдельного рассказа, а, возможно, и повести. Так есть. Мода на ИИ может спровоцировать заказчика на необдуманный шаг. Этот раздел, как работа «разрушителей легенд» - набор маркетинговых крючков подрядчиков.

Ни одна из этих фраз сама по себе не означает, что вас обманывают. Каждая может быть сказана честно и по делу. Но каждая - повод не кивнуть, а уточнить. Разница между хорошим подрядчиком и плохим часто не в том, что они говорят, а в том, что происходит после вашего уточняющего вопроса. Хороший - объясняет и приводит детали. Плохой - раздражается, обобщает или переводит тему.

Прочитали один раз - и на переговорах фраза сработает как сигнал: не спорить, не соглашаться, а уточнять.

Группа 1. Прячут отсутствие понимания задачи

Группа 2. Прячут технологическое лукавство

Группа 3. Прячут будущие доплаты

Группа 4. Прячут отсутствие людей

Группа 5. Прячут уход от ответственности

Как этим пользоваться:

• Услышали одну фразу - задайте уточняющий вопрос и посмотрите на реакцию. Это ещё ничего не значит. Хороший подрядчик может сказать любую из этих фраз честно.

• Услышали три - переходите к чек-листу из тридцати вопросов и идите по нему подряд, не пропуская блоки.

• Услышали пять и больше, а на уточнения получаете общие слова - экономьте своё время и деньги. Разговаривайте с кем-то ещё.

• Красный флаг - это не приговор подрядчику. Это сигнал, что следующий вопрос важнее предыдущего.

Отдельно: про демонстрации

Демо - самый неоднозначный инструмент переговоров, и дело не в честности подрядчика.

Когда вам показывают систему, вы подсознательно ищете зеркало - хотите увидеть свои процессы, свои документы, свою работу. Но на экране чужая компания: другая структура документов, другая терминология, другие исключения из правил. Мозг достраивает недостающее и подставляет ваш контекст. Кажется, что показали именно то, что нужно вам.

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

«На демо вы видите не будущее вашей системы. Вы видите прошлое чужой.»

Что с этим делать:

• Попросите показать демо на небольшой выборке ваших документов - хотя бы на десяти-двадцати. Это разумная просьба, и хороший подрядчик отнесётся к ней спокойно.

• Если подготовка такого демо требует времени и оплаты - это нормально и даже честно. Ненормально, когда от просьбы уходят.

• Заранее подготовьте пять-семь реальных вопросов, ответы на которые вы знаете. Это ваша контрольная выборка в миниатюре.

• Спросите, что на демо работает хуже всего. Ответ «всё работает» менее информативен, чем честное перечисление ограничений.

Как этим пользоваться

Услышали одну фразу - задайте уточняющий вопрос и посмотрите на реакцию. Это ещё ничего не значит.

Услышали три - переходите к чек-листу из тридцати вопросов и идите по нему подряд, не пропуская блоки.

Услышали пять и больше, а на уточнения получаете общие слова - экономьте своё время и деньги, разговаривайте с кем-то ещё.

«Красный флаг - это не приговор подрядчику. Это сигнал, что следующий вопрос важнее предыдущего.»

Чек-лист: 30 вопросов подрядчику

Задайте эти вопросы на первой встрече. Хороший подрядчик ответит спокойно и конкретно. Плохой начнёт уходить в общие слова, показывать презентации и обещать «всё решим в процессе».

Отмечайте галочкой те вопросы, на которые получили внятный ответ. Если меньше 20 галочек - ищите другого.

Про команду (6 вопросов)

☐ Кто конкретно будет работать на проекте - имена, роли, опыт?

☐ Эти люди сейчас заняты на других проектах? На сколько процентов?

☐ Кто будет моей точкой контакта и как быстро он отвечает?

☐ Что произойдёт, если ключевой специалист уволится в середине проекта?

☐ Сколько похожих проектов ваша команда сделала за последний год?

☐ Могу ли я поговорить с вашим предыдущим заказчиком?

Про подход (6 вопросов)

☐ С чего вы начнёте - с обследования или сразу с разработки?

☐ Что вам нужно от нас, чтобы проект не встал? Конкретно, в часах.

☐ Как вы поймёте, что задача решена? Какие метрики?

☐ Что вы будете делать, если качество модели окажется ниже ожиданий?

☐ Как вы работаете с изменением требований по ходу проекта?

☐ Какие риски вы видите в нашем проекте прямо сейчас?

Про данные и безопасность (6 вопросов)

☐ Где будут храниться и обрабатываться наши данные?

☐ Данные уходят во внешние сервисы или всё остаётся в нашем контуре?

☐ Кто из вашей команды получит доступ к нашим данным?

☐ Что вы делаете с нашими данными после окончания проекта?

☐ Как вы оцените, достаточно ли наших данных для обучения?

☐ Что если данных не хватит - какой план Б?

Про результат и передачу (6 вопросов)

☐ Что останется у нас, если мы разойдёмся на середине?

☐ Исходный код будет в нашем репозитории или в вашем?

☐ Кому принадлежат права на созданное решение?

☐ Как вы будете обучать нашу команду?

☐ Сможем ли мы развивать систему без вас?

☐ Что входит в гарантийную поддержку и на какой срок?

Про деньги (6 вопросов)

☐ Из чего складывается эта цена? Покажите декомпозицию.

☐ Что не входит в стоимость и может появиться потом?

☐ Как оплачивается работа - по этапам или помесячно?

☐ Что происходит с оплатой, если этап не принят?

☐ Какой процент проектов у вас выходит за бюджет и на сколько?

☐ Готовы ли вы зафиксировать цену этапа или только Time&Materials?

Шаблон сравнения смет

Разброс цен на одну задачу бывает стократным - от 100 тысяч до 10 миллионов. Причина обычно не в жадности, а в том, что подрядчики по-разному поняли задачу и включили разный объём работ.

Заполните таблицу по каждому предложению. Пустые ячейки - это то, что подрядчик не учёл. Именно там прячутся будущие доплаты.

Покажу на примере. Допустим, вам нужно поставить RAG-ассистента на 10 тысяч документов. Вы запросили три предложения.

Первый подрядчик говорит: 2,5 миллиона. Второй - 6 миллионов. Третий - 12 миллионов. Разброс в пять раз.

Теперь смотрите в таблицу. Первый написал 2,5 миллиона, но в строке «Подготовка данных» у него пусто. В строке «Обучение команды» - пусто. В строке «Гарантийная поддержка» - пусто. Это значит, что эти работы он не учёл. И они всплывут потом. Как доплата.

Второй написал 6 миллионов и заполнил все строки. Третий написал 12 миллионов и тоже заполнил все строки, но заложил резерв на непонимание задачи.

Мораль: выбирайте не по цене. Выбирайте по полноте заполнения таблицы. Пустые ячейки - это будущие доплаты.

Правило: самое дешёвое предложение почти всегда означает, что подрядчик не понял объём. Самое дорогое - что он закладывает риск непонимания. Выбирайте не по цене, а по полноте заполненной таблицы.

Скелет ТЗ на ИИ-проект

Структура разделов с пояснением, что писать в каждом. Это не полное ТЗ, тем более это не ТЗ по 19, или 34 ГОСТу - это каркас, который защищает вас от размытых формулировок.

1. Цель и бизнес-задача

Что должно измениться в работе компании. Не «внедрить ИИ», а «сократить время поиска нормативного документа с 30 минут до 3». Если не можете сформулировать в таком виде - задача ещё не готова.

2. Текущее состояние (As-Is)

Как процесс работает сейчас: кто участвует, сколько времени занимает, где теряется. С цифрами. Этот раздел потом станет базой для расчёта эффекта.

3. Целевое состояние (To-Be)

Как процесс должен работать после внедрения. Кто что делает, где остаётся человек, что берёт на себя система.

4. Данные

Какие данные есть, в каком объёме, в каком формате, кто владелец, какого качества. Отдельно - что нужно подготовить до старта разработки и кто это делает.

5. Функциональные требования

Что система должна уметь. Каждое требование - проверяемое утверждение. Не «удобный интерфейс», а «пользователь находит документ не более чем за 3 клика».

6. Нефункциональные требования

Скорость ответа, нагрузка, доступность, требования к контуру размещения, защита данных, соответствие регуляторным требованиям.

7. Критерии приёмки

Ключевой раздел. Измеримые пороги, при достижении которых работа считается выполненной. Например: точность ответов на контрольной выборке из 100 вопросов - не ниже 85%; время ответа - не более 5 секунд; 80% сотрудников прошли обучение и работают самостоятельно.

Поясню на примере, почему этот пункт ключевой.

Плохой критерий: «Система должна работать корректно». Что значит «корректно»? Никто не знает. И когда подрядчик сдаст работу, вы будете спорить, что значит «корректно».

Хороший критерий: «Точность ответов на контрольной выборке из 100 вопросов - не ниже 85 процентов. Время ответа - не более 5 секунд. 80 процентов сотрудников прошли обучение и работают самостоятельно».

Видите разницу? В первом случае вы будете спорить. Во втором - вы будете принимать работу по факту. И подрядчик не сможет сказать: «Мы сделали как в ТЗ». Потому что в ТЗ написано конкретно.

8. Этапы и результаты

Разбивка на этапы, у каждого - свой артефакт и своя приёмка. Оплата привязана к принятым этапам, а не к календарю.

9. Зона ответственности заказчика

Что вы обязуетесь предоставить: доступ к данным, время специалистов в часах, сроки согласований. Без этого раздела подрядчик потом свалит срыв на вас - и будет прав.

10. Передача и поддержка

Что передаётся: код, документация, обученная команда. Формат обучения. Условия гарантии и последующей поддержки.

• Разбор провалов внедрения на

Разбор провалов: четыре истории

реальных проектах из моей практики: где именно сломалось

Четыре реальные истории. Названия компаний убраны, суть сохранена. Смотрите не на финал, а на точку, где всё ещё можно было исправить.

Схема: четыре точки невозврата

АнтиПровал 0. Когда сделали все правильно

Для баланса - один кейс, где сработало. Чтобы не казалось, что я тут только страшилки рассказываю.

Временная шкала

• Месяц 0: обследование. Три недели. Нашли 12 000 документов, из них актуальных - 7 400. Остальные - отменённые редакции, дубли, черновики.

• Месяц 1: чистка и разметка. Убрали мусор, проставили статусы, версионность, даты вступления в силу.

• Месяц 2: загрузка в RAG. 7 400 документов, а не 12 000.

• Месяц 3: тестирование на контрольной выборке. 100 вопросов, ответы известны заранее. Точность - 91%.

• Месяц 4: пилот на одном отделе. 40 человек.

• Месяц 6: раскатка на всю организацию. 4 500 пользователей.

Что сработало

Никто не торопился. Месяц на чистку данных - это скучно, неэффективно с точки зрения отчётности и бесит руководство, которое хочет «уже вчера». Но именно этот месяц сэкономил четыре месяца переделок.

Итого: 6 месяцев от старта до 4 500 пользователей. Поиск документа - 15 секунд вместо 40 минут. Точность 91% на контрольной выборке.

Разница с провалом 4 - один месяц на ревизию данных. Один месяц из шести.

Провал 1. Трекер работает, данные не импортируются

Крупный корпоративный заказчик. Все пользуются трекером, есть интеграция с системой управления проектами, но данные импортируются на 10-15%.

Временная шкала

• Месяц 0: закуплены лицензии, настроена интеграция. Все довольны.

• Месяц 3: руководитель проектного офиса замечает, что отчёты не сходятся.

• Месяц 6: выясняется, что импорт работает на 10%. Виноватым назначают интегратора.

• Месяц 8: приглашают меня. Смотрю настройки.

Что нашли

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

Где была точка невозврата

Месяц 0. Никто не описал процесс до настройки инструмента. Инструмент настроили под то, как «удобно» - то есть под отсутствие дисциплины.

«Инструмент был. Интеграция была. Данные - на 10%. Потому что под инструментом не было процесса.»

Провал 2. ТЗ на две страницы «по ГОСТу»

Заказчик на первой встрече сообщает, что работает строго по ГОСТам. Прошу показать ТЗ. Приносят документ на две страницы.

Временная шкала

• Месяц 0: ТЗ написано и согласовано. Подрядчик подписал.

• Месяц 2: подрядчик приносит первую версию. Заказчик: «это не то, что мы имели в виду».

• Месяц 4: третья переделка. Бюджет исчерпан наполовину, готового ничего.

• Месяц 5: конфликт. Обе стороны ссылаются на ТЗ - и обе правы, потому что там ничего конкретного не написано.

Что нашли

Спрашиваю: по какому ГОСТу писали? Называют номер. Это ГОСТ на оформление. Занавес.

Где была точка невозврата

Месяц 0. ТЗ на две страницы не может описать проект. Форма была соблюдена идеально, содержания не было.

««Мы работаем по стандарту» часто означает «мы правильно оформляем то, чего у нас нет».»

Провал 3. Мигрировали четыре месяца, стало хуже

Импортозамещение трекера. Четыре месяца работы, полный перенос данных.

Временная шкала

• Месяц 0: решение мигрировать. Ожидание руководства - «новый инструмент круче, станет лучше».

• Месяц 4: миграция завершена, данные перенесены полностью.

• Месяц 5: жалобы пользователей. Работать стало не удобнее, а в некоторых местах хуже.

• Месяц 6: приглашают разобраться.

Что нашли

Новый инструмент лёг поверх того же бардака в процессах, который был до этого. Технически миграция прошла безупречно. Только переехал беспорядок.

Где была точка невозврата

Месяц 0. Момент миграции - лучший повод пересмотреть процессы. Его использовали как повод ничего не менять.

«Переехать в новый офис с тем же беспорядком - это переезд беспорядка.»

Провал 3. «Провал 5 (мой). Я сказал «нет» - и проиграл тендер»

Единственная история здесь, где проиграл я. Оставляю её, потому что она честнее победных.

Один из крупнейших банков Москвы выбирал подрядчика на консалтинговый проект: обследование, оргизменения, внедрение инструментов. Конкурс собрал ведущих поставщиков процессного подхода и инструментов IBM - мою компанию (в партнёрстве с Carnegie Mellon) и ещё двух сильных игроков.

IT-директор собрал всех вместе и рассказал свежую боль. По-новому закону ИНН стал обязателен для юрлиц. Разработчики банка сделали поле ИНН обязательным - для всех, включая физлиц, у которых ИНН тогда ещё не было. В понедельник банк встал: платежи физлиц не проходили полтора дня. Прямые потери.

Вопрос ко всем был один: «Ваша волшебная система избавит нас от такого в будущем?» Конкуренты ответили: «Да, конечно, для этого она и нужна».

Я выступал последним и сказал: «Нет. Волшебных систем не бывает. Система не примет решение за вас - она даст информацию человеку. Как трактовать закон и что передать в разработку, решает бизнес-аналитик, а не инструмент. Система лишь не даёт упустить детали».

Дальше - то, за что мы и проиграли. Вместо предложения «под ключ» мы подали два договора: сначала обследование и рекомендации, а вторую часть - внедрение - только при письменном обязательстве заказчика менять оргструктуру. Без этого обязательства гарантировать результат нельзя, и мы честно закладывали этот риск в цену. Ценник вышел выше.

Конкуренты срезали цены на 40%, чтобы влезть. Выиграл не тот, кто назвал риск, а тот, кто пообещал волшебство подешевле.

Финал. Победитель сдавал проект не полгода, а полтора: год доработок. Компания оказалась ровно настолько незрелой, как мы и предупреждали. Под конец они аутстаффили специалистов -у меня же, - чтобы закрыть проект.

Мораль не в том, что я умнее. А в том, что риск можно назвать вслух или спрятать под красивое «да» и низкую цену. Я назвал - и проиграл тендер. Иногда выбор простой: либо честный, либо

богатый.

Провал 4. «Загрузим всё - ИИ разберётся»

Классика последних двух лет. Компания решает сделать корпоративного ассистента по внутренней документации.

Временная шкала

• Месяц 0: выгружают весь архив документов в систему. 40 тысяч файлов.

• Месяц 1: система запущена, показывает демо. Руководство впечатлено.

• Месяц 2: пользователи начинают работать. Ассистент отвечает уверенно и часто неправильно.

• Месяц 3: доверие потеряно, никто не пользуется. Проект тихо закрывают.

Что нашли

В архиве лежали документы разных лет, включая отменённые редакции регламентов. Система не отличала действующий документ от устаревшего и цитировала оба с одинаковой уверенностью.

Где была точка невозврата

Месяц 0. Никто не провёл ревизию данных перед загрузкой. Это работа на несколько недель, которую пропустили ради скорости.

«ИИ на сыром архиве не молчит - он галлюцинирует. Уверенно, красиво, неправильно. Это хуже, чем если бы он просто не работал.»

Бюджеты: сколько стоит и когда окупается

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

• Стоимость указана примерная, сильно зависит от квалификации специалистов, раскрученности интегратора-разработчика, параметров системы, количества обрабатываемых данных для обучения LLM и так далее.

Откуда эти цифры? Из проектов. Из реальных проектов, которые я вёл или в которых участвовал. Плюс статистика по рынку.

Но я сразу оговорюсь: это вилки. Не прайс-лист. Не фиксированные цены. Это диапазон, в который попадает большинство проектов данного типа. Ваш конкретный проект может быть дешевле. Может быть дороже. Зависит от состояния данных, от глубины интеграции, от требований к контуру.

И вот что я хочу сказать: если вам называют цену ниже нижней границы вилки - насторожитесь. Скорее всего, подрядчик не учёл половину работ. И они всплывут потом. Как доплата. Как всегда.

График: бюджеты и сроки типовых проектов

Формула расчёта эффекта

Считайте не «сколько стоит система», а «сколько стоит нынешний способ работы».

Шаг 1. Сколько человек выполняют операцию.

Шаг 2. Сколько часов в неделю уходит у каждого.

Шаг 3. Стоимость часа с учётом налогов и накладных.

Шаг 4. Годовые затраты = чел. × часы × 48 недель × стоимость часа.

Шаг 5. Реалистичная экономия - 40-60% от этой суммы, не 100%.

Пример: 30 инженеров тратят по 4 часа в неделю на поиск в документации. Час стоит 1500 рублей с накладными. Годовые затраты - 8,6 млн. Экономия 50% - 4,3 млн в год. Проект за 4 млн окупается меньше чем за год.

Инфографика: формула расчёта окупаемости

Пример. Не абстрактный, а с цифрами

30 инженеров тратят по 4 часа в неделю на поиск в документации. Час стоит 1 500 рублей с налогами и накладными.

• Шаг 1: 30 человек.

• Шаг 2: 4 часа в неделю.

• Шаг 3: 1 500 рублей в час.

• Шаг 4: 30 × 4 × 48 × 1 500 = 8 640 000 рублей в год.

• Шаг 5: Реалистичная экономия 50%, не 100%. Никто не перестаёт искать документы полностью.

Экономия: 4 320 000 рублей в год. Проект стоит 4 миллиона. Окупается за 11 месяцев.

Теперь тот же расчёт, но с экономией 30% (пессимистичный сценарий): 2 592 000 рублей в год. Окупаемость - 18 месяцев. Всё ещё меньше двух лет.

Если ваш подрядчик обещает экономию 100% - он либо не понимает, что говорит, либо пытается вам что-то продать. Скорее второе.

Покажу на живом примере. 30 инженеров тратят по 4 часа в неделю на поиск в документации. Час стоит 1500 рублей с накладными. Считаем: 30 умножить на 4 умножить на 48 недель умножить на 1500. Получаем 8 миллионов 640 тысяч в год.

Реалистичная экономия - 50 процентов. Не 100. Не 80. Пятьдесят. Потому что часть поиска останется. Часть документов всё равно будут искать вручную. Чудес не бывает.

Итого: экономия 4 миллиона 320 тысяч в год. Проект за 4 миллиона окупается меньше чем за год. Это не теория. Это расчёт. Возьмите свои цифры и посчитайте сами.

Где вылезают перерасходы

• Подготовка данных оказалась больше, чем думали. Самая частая причина.

• Интеграция с legacy-системами, про которую забыли на этапе оценки.

• Изменение требований после первого демо - «а давайте ещё вот так».

• Недооценка времени на приёмку и обучение.

• Отсутствие выделенного человека со стороны заказчика - проект простаивает.

План первых 30 дней

Что сделать самостоятельно, до привлечения кого бы то ни было. К концу месяца вы будете понимать своё положение точнее, чем большинство подрядчиков после первой встречи.

Неделя 1. Собрать факты

☐ Пройти тест зрелости из части 4 и записать результат по осям.

☐ Выписать 3-5 процессов, которые отнимают больше всего времени.

☐ Для каждого - посчитать: сколько людей, сколько часов в неделю.

☐ Собрать в одну папку все регламенты и инструкции по этим процессам.

☐ Отметить, какие из них актуальны, а какие устарели.

Неделя 2. Поговорить с людьми

☐ Провести по 30 минут с 5-7 исполнителями этих процессов.

☐ Спросить: что отнимает больше всего времени и что бесит больше всего.

☐ Спросить: где вы ищете информацию и сколько это занимает.

☐ Записать дословно 3-5 самых частых жалоб.

☐ Отдельно поговорить с тем, кто дольше всех в компании - он знает, где закопаны исключения.

Неделя 3. Оценить данные

☐ Посчитать объём документов по выбранному направлению.

☐ Проверить: есть ли дубли, устаревшие версии, документы без даты.

☐ Определить, кто отвечает за актуальность этих документов.

☐ Оценить, сколько времени займёт ревизия и чистка.

☐ Записать вывод: данные готовы, частично готовы или не готовы.

Неделя 4. Сформулировать задачу

☐ Написать одно предложение: что должно измениться и на сколько.

☐ Определить измеримый критерий успеха с конкретным числом.

☐ Посчитать стоимость текущего способа работы по формуле из части 9.

☐ Определить, кто внутри компании будет вести проект.

☐ Решить: идём в проект, делаем пилот или сначала наводим порядок.

После этих четырёх недель вы либо поймёте, что справитесь сами, либо будете готовы к разговору с подрядчиком на равных - с фактами, а не с общим желанием «внедрить ИИ».

Критерии здорового проекта

Чек-лист, который работает независимо от того, кого вы выбрали. Проверяйте на каждом этапе.

1. Роли и ответственность

Кто конкретно работает на проекте - имена, роли, опыт. Если вместо ответа показывают слайд с фотографиями офиса, это сигнал.

2. Артефакт на руки

Что остаётся у вас, если разойдётесь на середине. Хороший ответ: ТЗ, архитектурный документ, код в вашем репозитории.

3. Вклад заказчика назван заранее

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

4. Риски названы подрядчиком, а не вами

Хороший подрядчик говорит: «здесь мы обычно буксуем, если не будет доступа к данным». Плохой узнаёт о проблеме от вас через две недели после того, как она возникла.

5. Точка выхода без потерь

После каждого этапа вы можете остановиться, унеся ценность. Если привязывают намертво с самого начала - это не партнёрство.

6. Измеримые критерии успеха

«Система заработает» - не критерий. «Точность не ниже 85% на контрольной выборке из 100 вопросов, ответ не дольше 5 секунд, 80% сотрудников работают самостоятельно» - критерий.

Поясню, почему этот критерий самый важный.

Если подрядчик не может назвать измеримые критерии успеха - он не понимает задачу. Или не хочет брать на себя ответственность. И то, и другое - красный флаг.

«Система заработает» - это не критерий. Это обещание. Обещание нельзя проверить. Обещание нельзя принять. Обещание нельзя оспорить.

«Точность не ниже 85 процентов на контрольной выборке из 100 вопросов» - это критерий. Его можно проверить. Его можно принять. Его можно оспорить. И если подрядчик не согласен на такой критерий - значит, он не уверен в результате. А если он не уверен - почему вы должны быть уверены?

7. Прозрачная декомпозиция цены

Вы понимаете, из чего складывается сумма и что не входит. Единая цифра без разбивки означает, что внутри спрятан запас на непонимание задачи.

Об авторе

• Об авторе: Александр Новичков

Почему я имею право это писать.

Есть сцена: Паганини приходит на репетицию без скрипки, оркестр усмехается - «маэстро без инструмента?». А он, ещё не взяв смычок, называет, какие инструменты в оркестре расстроены.

Моя работа устроена так же. Я прихожу и первым делом говорю, где у вас фальшивит, - до того, как что-то внедрять. Инструмент вторичен. Первичен слух.

• Экспертными системами и объяснимым ИИ занимался ещё на Prolog и Lisp - базы знаний, правила вывода, проверяемость ответа. Тот же принцип, что сегодня в RAG: система отвечает по проверяемой базе, а не по наитию. Я в этой логике не два года, а десятилетия.

• 30 лет в ИТ-консалтинге и разработке. С 1999 года работаю с методологиями управления жизненным циклом: IBM Rational (ClearCase, ClearQuest, RequisitePro), MS Project и Project Server, HP ALM, Jira и Confluence, TFS и Azure DevOps, отечественные трекеры после 2022 года.

• 20 лет с авиационной промышленностью, банками, нефтянкой. Постановка процессов разработки в контуре ГОСТ и КТ-178, отделы тестирования с нуля, аутсорсинг проектов тестирования.

• Проекты в Татнефти, ВТБ, Русском Стандарте, Пенсионном фонде, ГНИВЦ ФНС, на предприятиях ОПК. Полный цикл ALM на 150+ пользователей, интеграция с SAP.

• Более 7000 обученных специалистов. Обучение команд до уровня самостоятельной сертификации, включая CMMI-3.

• Собственные программные продукты с международными клиентами: Германия, Бразилия, Аргентина. Признание IBM, Microsoft.

Я не пишу код и не продаю лицензии. Моя работа - разобраться в задаче раньше, чем вы потратите деньги, спроектировать решение, выбрать исполнителя без ангажемента и принять результат по жёстким критериям.

Мне платит только заказчик. Ни один подрядчик, вендор или интегратор не платит мне за то, чтобы я его рекомендовал. Поэтому я могу говорить то, что говорю в этом документе.

Моя линия жизни поверх графика CHAOS

Частые вопросы

Все вопросы и ответы

Термины из этого документа

Весь глоссарий