13 — Приложение B — Первые 90 дней — читательская версия

PDF — страница 190

Приложение B. Первые 90 дней: от идеи до управляемого ИИ-контура

Девяносто дней недостаточно, чтобы «внедрить искусственный интеллект в компанию».

PDF — страница 191

За этот срок невозможно сделать машиночитаемой всю организацию, формализовать накопленную экспертизу, создать систему корпоративных навыков и перестроить все процессы.

Но за 90 дней можно решить более важную задачу: построить один полноценный рабочий контур и на его основании проверить способность компании системно работать с ИИ.

Результатом первых 90 дней должны стать:

• одна приоритетная функция;

• доказанная связь с ограничением;

• зафиксированное исходное состояние;

• утверждённый метод;

• машиночитаемый контекст;

• работающий навык или другой минимально достаточный механизм;

• установленная роль человека;

• контроль качества;

• реестр инцидентов;

• измеренный процессный эффект;

• решение о промышленной эксплуатации или остановке.

Главный критерий успеха — не зрелищность демонстрации, а воспроизводимость результата в реальной работе.

PDF — страница 192

B.1. Три параллельных трека

В течение 90 дней необходимо одновременно вести три трека.

Трек 1. Бизнес-результат

• выбор ограничения;

• описание процесса;

• базовые метрики;

• гипотеза эффекта;

• оценка результата.

Трек 2. Метод и организация

• формализация способа работы;

• роли;

• полномочия;

• человеческие шлюзы;

• обучение;

• разбор инцидентов.

Трек 3. Технологический контур

• Harness;

• данные;

• навыки;

• инструменты;

• проверки;

• журналирование;

• безопасность;

• версии.

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

PDF — страница 193

Первые 90 дней

• Выбрать правильную функцию
• 1–15

• Формализовать метод
• 16–30 и спроектировать контур

• Провести пилот
• 31–60 в контролируемом режиме

• Стабилизировать и принять
• 61–90 решение о масштабе

• Схема по тексту: Приложение B. Геометрия показывает связи и последовательность, а не количественные значения.

[!note] Редакторское пояснение схемы; визуальная сверка A1 Это пояснение редактора, не дополнительный текст авторов PDF. Текстовые подписи выше сохранены в порядке технического извлечения; связи описаны ниже.

Четыре вертикально соединённых круга с интервалами: 1–15 выбрать правильную функцию; 16–30 формализовать метод и спроектировать контур; 31–60 провести пилот в контролируемом режиме; 61–90 стабилизировать и принять решение о масштабе. Последний круг красный. Основание: приложение B, с. 196–207.

Перед началом отсчёта есть отдельный этап 0 (194–195), хотя его нет в этой схеме. Три параллельных трека на с. 192 также нельзя потерять: бизнес-результат, метод/организация, технология. 90 дней — рекомендация источника для одного контура, не обещание преобразования компании и не календарь AIN-T-005.

PDF — страница 194

Этап 0. До начала отсчёта

Перед запуском необходимо получить управленческое согласие по нескольким вопросам.

Спонсор

Должен существовать руководитель, который:

• заинтересован в бизнес-результате;

• обладает полномочиями менять процесс;

• предоставляет доступ к данным и людям;

• принимает решение о продолжении;

• защищает время участников.

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

Рабочая группа

Минимальный состав:

• владелец результата;

• владелец метода;

• представитель пользователей;

• методолог или аналитик;

• специалист по данным и интеграциям;

• контролёр качества;

• ответственный за безопасность.

В небольшой компании один человек может совмещать несколько ролей. Но ответственность каждого типа должна быть определена.

Границы

До старта фиксируются:

• процесс;

• подразделение;

• группа пользователей;

• допустимые данные;

• запрещённые действия;

• срок;

• бюджет;

• критерии остановки.

PDF — страница 195

Базовая политика

Даже для первого пилота необходимы минимальные правила:

• какие данные нельзя передавать внешним моделям;

• какие действия требуют подтверждения;

• где хранится результат;

• кто имеет доступ;

• как регистрируется инцидент;

• кто имеет право менять навык;

• как отключается решение.

Без этого пилот создаёт не только опыт, но и неконтролируемые риски.

PDF — страница 196

Дни 1–15. Выбрать правильную функцию

Цель первого этапа — не создать решение, а доказать, что выбрано правильное место применения.

Шаг 1. Определить стратегический результат

Рабочая группа фиксирует:

• стратегическую цель;

• дерево связанных показателей;

• процессный результат;

• горизонт ожидаемого эффекта.

Инициатива должна иметь понятную причинную связь с верхним уровнем, даже если её непосредственная метрика находится ниже.

Шаг 2. Найти ограничение

Используются:

• данные;

• интервью;

• наблюдение;

• карта процесса;

• анализ очередей;

• анализ переделок;

• оценка дефицитного ресурса.

Необходимо отличить симптом от ограничения.

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

PDF — страница 197

Шаг 3. Декомпозировать процесс

Процесс разбивается на:

• операции;

• решения;

• ожидания;

• передачи;

• проверки;

• исключения.

Для каждого элемента определяется:

• исполнитель;

• вход;

• выход;

• длительность;

• частота;

• ошибка;

• цена ошибки;

• возможность проверки.

Шаг 4. Классифицировать задачи

Рабочая группа отделяет:

• воспроизводимые операции;

• экспертно-аналитические задачи;

• сложные взаимодействия;

• кризисные или неопределённые ситуации.

Это предотвращает попытку автоматизировать весь процесс одним механизмом.

Шаг 5. Выбрать одну функцию

Предпочтение отдаётся функции, которая:

• связана с ограничением;

• повторяется;

• использует доступные данные;

• имеет наблюдаемый результат;

• потребляет дефицитный ресурс;

• допускает проверку;

• имеет ограниченный риск;

• может быть откатана за 90 дней.

PDF — страница 198

Шаг 6. Зафиксировать исходное состояние

На выборке реальных случаев измеряются:

• время;

• стоимость;

• количество участников;

• количество итераций;

• ошибки;

• пропускная способность;

• качество;

• объём ручной работы;

• итоговый процессный результат.

Результаты этапа

К 15-му дню должны быть готовы:

• паспорт инициативы;

• карта процесса;

• классификация функций;

• выбранный участок;

• исходные метрики;

• владелец результата;

• решение о продолжении.

Шлюз 1. Продолжать или остановить

Проект не переходит к следующему этапу, если:

• функция не влияет на ограничение;

• результат невозможно измерить;

• нет владельца;

• данные недоступны;

• риск неприемлем;

• существует очевидно более простое готовое решение.

PDF — страница 199

Дни 16–30. Формализовать метод и спроектировать контур

Цель этапа — сделать способ работы достаточно явным для пилота.

Шаг 1. Извлечь фактический метод

Проводится разбор нескольких реальных случаев:

• успешного;

• типового;

• сложного;

• ошибочного;

• пограничного.

У носителя метода уточняются:

• последовательность действий;

• необходимые данные;

• критерии;

• профессиональные эвристики;

• исключения;

• стоп-сигналы;

• допустимые варианты результата.

Шаг 2. Отделить правила от суждений

Создаётся карта:

Передаётся системе

• поиск;

• извлечение;

• расчёт;

• классификация;

• форматирование;

• проверка;

• применение устойчивого правила.

PDF — страница 200

Остаётся за человеком

• выбор между допустимыми вариантами;

• интерпретация противоречия;

• решение при высокой цене ошибки;

• внешнее обязательство;

• изменение метода;

• действие в исключении.

Шаг 3. Определить контекст

Фиксируется минимальный набор:

• корпоративных правил;

• процессных документов;

• проектных материалов;

• данных;

• моделей;

• примеров;

• терминов;

• источников.

Одновременно определяется, что не должно попадать в контекст.

Шаг 4. Спроектировать минимальный механизм

Выбирается наименее сложный вариант, достаточный для гипотезы:

• scaffold;

• проверка;

• навык;

• агент;

• микросервис.

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

PDF — страница 201

Шаг 5. Спроектировать QA и Rail

Определяются:

• обязательные проверки;

• независимая проверка источников;

• критерии полноты;

• процессные требования;

• точки остановки;

• формат сообщения об отклонении.

Шаг 6. Подготовить тестовый набор

Он включает:

• типовые случаи;

• сложные;

• пограничные;

• исторические ошибки;

• случаи, где система должна отказаться действовать;

• случаи с недостаточными данными.

Результаты этапа

К 30-му дню должны быть готовы:

• описание метода;

• первая версия навыка или scaffold;

• карта человеческих шлюзов;

• контекст;

• правила;

• тестовый набор;

• план пилота;

• политика безопасности для данного контура.

Шлюз 2. Готовность к реальной работе

Пилот не запускается, если:

• метод остаётся противоречивым;

• система не умеет останавливаться;

• невозможно проверить результат;

• не определено внешнее действие;

• отсутствует резервный ручной процесс;

• навык не прошёл тестовые случаи.

PDF — страница 202

Дни 31–60. Провести пилот в контролируемом режиме

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

Шаг 1. Запустить теневой или параллельный режим

Теневой режим

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

Подходит, если цена ошибки высока.

Параллельный режим

Человек и система выполняют функцию отдельно. Результаты сравниваются.

Подходит, если необходимо доказать качество и скорость.

Режим черновика

Система готовит результат первой, человек проверяет и исправляет.

Подходит для документов, аналитики и подготовки решений.

Шаг 2. Фиксировать каждое вмешательство

Необходимо регистрировать:

• что изменила система;

• что исправил человек;

• почему;

• к какому классу относится ошибка;

• была ли проблема в данных, методе, правиле или исполнении;

• повторялся ли дефект.

Исправления не должны оставаться только в диалоге.

PDF — страница 203

Шаг 3. Проводить короткие циклы Meditate

Не реже одного раза в неделю рабочая группа анализирует:

• повторяемые корректировки;

• конфликты;

• недостающие правила;

• лишние шаги;

• случаи недоверия;

• случаи необоснованного доверия;

• новые исключения.

Изменение навыка проводится управляемо:

• создаётся новая версия;

• повторяются тесты;

• фиксируется причина;

• ограниченной группе выпускается обновление.

Шаг 4. Наблюдать за поведением пользователей

Важно фиксировать не только качество результата, но и:

• используют ли люди систему;

• где обходят;

• что не понимают;

• какие этапы считают лишними;

• где копируют ответ без проверки;

• что вызывает опасение;

• какие новые способы работы возникают.

Шаг 5. Следить за защитными метриками

Ускорение не должно приводить к:

• росту дефектов;

• ухудшению клиентского опыта;

• увеличению переделок;

• потере понимания метода;

• росту риска утечки;

• снижению ответственности.

PDF — страница 204

Результаты этапа

К 60-му дню должны существовать:

• журнал применений;

• реестр инцидентов;

• несколько проверенных версий;

• фактические показатели скорости и качества;

• данные о принятии;

• список ограничений;

• решение о продолжении пилота, переработке или остановке.

Шлюз 3. Доказана ли работоспособность

Система не переходит к расширенной эксплуатации, если:

• качество нестабильно;

• результат зависит от автора решения;

• пользователи обходят контур;

• цена контроля поглощает экономию;

• ошибки невозможно быстро обнаружить;

• отсутствует воспроизводимость на разных случаях.

PDF — страница 205

Дни 61–90. Стабилизировать и принять решение о масштабе

Цель последнего этапа — превратить пилот в управляемую способность или осознанно отказаться от него.

Шаг 1. Расширить выборку

Решение проверяется:

• у нескольких пользователей;

• на новых данных;

• в разных типах случаев;

• без постоянного присутствия разработчика;

• при ограниченном доступе к эксперту.

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

Шаг 2. Провести контрольную оценку

Сравниваются:

• исходное состояние;

• технический результат;

• процессный эффект;

• принятие;

• предполагаемый экономический эффект.

Необходимо отделить наблюдаемый эффект от расчётного.

Например:

• сокращение времени измерено;

• возможность избежать найма является предположением;

• рост выручки пока не подтверждён;

• снижение риска оценено экспертно.

PDF — страница 206

Шаг 3. Подготовить промышленное владение

Назначаются:

• владелец навыка;

• владелец процесса;

• владелец данных;

• контролёр качества;

• владелец безопасности;

• служба или человек, отвечающий за поддержку.

Определяются:

• график Review;

• порядок обновлений;

• мониторинг;

• допустимый уровень ошибок;

• порядок отката;

• резервный процесс;

• обучение новых пользователей.

Шаг 4. Отделить общее от локального

Команда определяет, какие компоненты можно повторно использовать:

• правило;

• модель;

• базовый навык;

• проверку;

• коннектор к данным;

• шаблон;

• scaffold;

• микросервисный компонент.

И какие элементы должны остаться локальными:

• клиентский контекст;

• проектные исключения;

• персональные настройки;

• чувствительные данные;

• узкие правила подразделения.

PDF — страница 207

Шаг 5. Принять итоговый вердикт

Масштабировать

Если:

• эффект подтверждён;

• качество устойчиво;

• пользователи принимают контур;

• риск удерживается;

• владелец назначен;

• стоимость эксплуатации оправданна.

Продолжить ограниченную эксплуатацию

Если:

• польза наблюдается;

• но выборка недостаточна;

• экономический эффект ещё не доказан;

• требуются дополнительные версии.

Вернуть на доработку

Если:

• функция выбрана правильно;

• но метод, данные или контроль недостаточно зрелы.

Перевести в исследовательский режим

Если:

• задача оказалась сложнее;

• причинность нестабильна;

• алгоритмизация преждевременна.

Остановить

Если:

• эффект отсутствует;

• риск высок;

• пользователи не принимают решение;

• функция не влияет на ограничение;

• готовый рыночный продукт экономически сильнее;

• сопровождение превышает ценность.

PDF — страница 208

B.2. Что должно существовать через 90 дней

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

1. Паспорт инициативы.

2. Карта процесса и функции.

3. Классификация природы задачи.

4. Оценка зрелости.

5. Базовые метрики.

6. Утверждённый метод.

7. Минимально достаточный контекст.

8. Навык, scaffold или другой механизм.

9. Карта человеческих решений.

10. QA.

11. Rail.

12. Политика доступа и безопасности.

13. Журнал действий.

14. Реестр инцидентов.

15. История версий.

16. Результаты пилота.

17. Оценка принятия.

18. Расчёт экономической гипотезы.

19. Назначенные владельцы.

20. Итоговый управленческий вердикт.

B.3. Чего не следует ожидать через 90 дней

Не следует обещать:

• полную трансформацию компании;

• замену подразделения;

• полностью автономную работу;

• точную экономику всех будущих применений;

• завершённую корпоративную базу знаний;

• универсальный набор навыков;

• отсутствие ошибок;

• окончательную архитектуру.

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

PDF — страница 209

B.4. Главный принцип первых 90 дней

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

Такой контур даёт компании:

• метод внедрения;

• первую инфраструктуру;

• понимание рисков;

• опыт работы с инцидентами;

• владельцев;

• базовые правила;

• повторно используемые компоненты;

• основание для следующего решения.

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