БиблиотекаПриложение
Дополнительный материал
10 — Эволюция методологии
Постраничное техническое извлечение. Текст источника сохранён в блоках; это не редакционный пересказ. Таблицы, порядок чтения схем и изображения требуют сверки с PDF.
PDF — страница 156
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
10. Эволюция
методологии:
что изменилось
и что осталось
неизменным
10
Компания, способная работать с ИИ
Методология, представленная в этом документе, не
была сформулирована заранее в законченном виде.
156
PDF — страница 157
§ 10.1–10.3 Paper Planes
Эволюция методологии
Сделать организацию
1 машиночитаемой
От второго мозга к Harness
2
От архитектуры
3 к корпоративной способности
Схема по тексту: § 10.1–10.3. Геометрия показывает связи и последовательность, а не количественные значения.
Компания, способная работать с ИИ 157
PDF — страница 158
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Она развивалась в течение трёх потоков образовательной программы, параллельно с внутренним
внедрением ИИ и работой над клиентскими задачами. Между потоками менялись инструменты,
архитектура и представления о допустимой автономности.
Некоторые ранние идеи получили подтверждение и стали основой подхода. Другие оказались
слишком узкими. Третьи пришлось существенно ограничить.
Эта эволюция важна не только как история появления методологии. Она показывает
фундаментальное свойство самой области: устойчивый подход к искусственному интеллекту нельзя
построить как раз и навсегда установленный стандарт.
Модели, интерфейсы и способы взаимодействия будут меняться. Поэтому методология должна уметь
пересматривать собственные положения, сохраняя при этом устойчивое ядро.
10.1. Первая версия: сделать организацию
машиночитаемой
Первый поток был сосредоточен вокруг нескольких базовых идей.
Искусственный интеллект требует корпоративного контекста
Стало понятно, что универсальная модель не знает:
как устроена конкретная компания;
какие методы она применяет;
какой понятийный аппарат использует;
что считает качественным результатом;
какие решения принимала раньше.
Поэтому возникла идея корпоративного «второго мозга» — среды, в которой документы, записи,
правила и проекты становятся доступными искусственному интеллекту.
В центре находится ограничение
ИИ следует применять не вообще в компании, а в конкретном месте, где он
способен изменить результат системы.
Работа начинается с:
проблемы;
процесса;
ограничения;
внутренних знаний;
человеческого контроля.
CORD связывает информацию с действием
Появилась основная последовательность:
Collect → Organize → Review → Do.
Она позволяла рассматривать базу знаний не как архив, а как систему движения от нового сигнала к результату.
Компания, способная работать с ИИ 158
PDF — страница 159
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Человек остаётся внутри контура
Уже в первой версии человек выполнял три основные функции:
обучал систему;
объяснял контекст;
проверял результат.
Ограничение первой версии
Главным риском было чрезмерное внимание к форме хранения.
Конкретный инструмент — в частности, Obsidian и файловая база в Markdown — мог выглядеть
центром решения. Это создавало впечатление, что правильно организованная база знаний почти
автоматически превращается в ИИ-систему.
Но хранение и навигация решают лишь часть проблемы.
Необходимо было понять:
как система выбирает релевантный контекст;
как применяет методы;
как выполняет действия;
как проверяет ограничения;
как знания распространяются между сотрудниками;
как система изменяется после ошибки.
10.2. Вторая версия: от второго мозга
к Harness
Во втором потоке центр методологии переместился от хранилища знаний к управляющей оболочке.
Инструмент перестал быть архитектурой
Obsidian сохранил полезность как интерфейс просмотра и простой способ навигации. Но перестал
рассматриваться как обязательная основа системы.
Главным стал Harness — среда, связывающая:
корпоративный контекст;
правила;
навыки;
агентов;
инструменты;
проверки;
рабочие системы;
человека.
Это был переход от вопроса «где хранить знания?» к вопросу «как знания участвуют в выполнении работы?»
Компания, способная работать с ИИ 159
PDF — страница 160
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Промпт уступил место контексту
Качество результата стало рассматриваться не как следствие одной удачной формулировки,
а как продукт архитектуры:
какие правила действуют;
какой проектный контекст доступен;
какие навыки установлены;
какие источники подключены;
какие проверки обязательны;
какие термины понимает система.
Удачный запрос остаётся полезным, но перестаёт быть основной корпоративной компетенцией.
Появилась зрелость процесса
Стало очевидно, что готовность процесса к ИИ зависит не только от его важности.
Процесс может быть:
хаотическим;
замысленным;
описанным;
исполнимым;
измеримым;
оптимизируемым.
ИИ должен не перепрыгивать через уровни, а помогать процессу перейти к следующему состоянию.
Монолит уступил место узким микросервисам
Вместо попытки переделать основную корпоративную систему возникла идея создавать
ограниченные сервисы вокруг неё.
Это уменьшало:
стоимость запуска;
время разработки;
риск;
зависимость от большого проекта автоматизации.
Обратная связь получила архитектурные компоненты
Появились:
QA — контроль качества;
Rail — проверка соответствия процессу;
Meditate — перевод исправлений в правила.
CORD стал дополняться полноценным контуром PDCA.
Компания, способная работать с ИИ 160
PDF — страница 161
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Ограничение второй версии
Несмотря на декомпозицию, агенты и рабочие процессы всё ещё могли восприниматься
как основной ответ на широкий класс задач.
Оставался недостаточно проработанным вопрос:
Всегда ли задачу вообще следует превращать
в исполнимый процесс?
Описание деятельности ещё не означает, что причинно-следственные связи достаточно
устойчивы для автоматизации.
10.3. Третья версия: от архитектуры
к корпоративной способности
Третий поток добавил новый диагностический и организационный уровень.
Перед автоматизацией появилась классификация задачи
Стало необходимо различать:
воспроизводимые операции;
экспертно-аналитические задачи;
сложные ситуации;
хаотические состояния;
случаи, в которых природа задачи ещё не определена.
Это ограничило область применения агентов.
Агент оказался не универсальным цифровым сотрудником, а инструментом для выполнения
ограниченных функций внутри подходящего режима.
Появился scaffolding
Вторая важная идея — различие между инструкцией и когнитивной опорой.
Не всякую экспертную работу нужно превращать в правило. Иногда необходимо сохранить
человеческое решение, но усилить качество рассуждения:
показать факторы;
предложить альтернативы;
проверить допущения;
напомнить о рисках;
помочь распознать исключение.
ИИ стал рассматриваться не только как исполнитель, но и как когнитивный экзоскелет.
Компания, способная работать с ИИ 161
PDF — страница 162
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Модель себя стала основанием персонального Harness
Корпоративный контекст был дополнен моделью пользователя:
его ответственностью;
методами;
профессиональным языком;
критериями качества;
полномочиями;
характерными корректировками;
границами допустимой автономности.
Это позволило перейти от абстрактного корпоративного помощника к рабочей системе конкретного
руководителя или специалиста.
Навыки стали цифровыми активами
Навык перестал быть только локальной инструкцией.
Он получил:
автора;
владельца;
версию;
зависимости;
проверки;
область распространения;
историю применения;
цифровой след изменений.
Так возникла идея корпоративной операционной системы навыков.
Распространение экспертизы стало частью архитектуры
Новая версия навыка может становиться доступной другим сотрудникам. Исправление одного
эксперта способно изменить работу множества пользователей.
Организация начинает распространять не только документы и учебные материалы,
но и исполняемые способы работы.
Rail и Meditate стали операционными механизмами
Rail превратился в конкретную инспекцию проекта по библиотеке процессов, а Meditate —
в механизм извлечения правил из исправлений и инцидентов.
Самообучение перестало быть общей метафорой. Оно было представлено как управляемый цикл:
инцидент → анализ → предлагаемое изменение → проверка → новая версия → распространение.
Компания, способная работать с ИИ 162
PDF — страница 163
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Машиночитаемость распространилась на полномочия
Машиночитаемой должна быть не только информация, но и организационная допустимость действия:
кто имеет право выполнить задачу;
какие компетенции подтверждены;
какие данные доступны;
когда требуется согласование;
при каких условиях право должно быть временно ограничено.
Так машиночитаемость стала основой не только знаний, но и управления.
10.4. Что мы пересмотрели
«Компании нужен второй мозг»
Уточнение:
Компании недостаточно второго мозга как хранилища. Ей нужна система, связывающая память,
методы, исполнение, контроль и обучение.
«Нужно собрать все знания»
Уточнение:
Не вся информация полезна. Необходимо собирать минимально достаточный контекст, определять
статус, применимость, приоритет и связь с решением.
«Нужно научиться писать хорошие промпты»
Уточнение:
Качество запроса важно, но корпоративный результат определяется прежде всего контекстом,
методом, правилами, инструментами и проверками.
«Нужно создавать агентов»
Уточнение:
Сначала нужно определить природу задачи. Агент оправдан в ограниченной функции с понятными
действиями и проверяемым результатом.
«Человек должен проверять финальный ответ»
Уточнение:
Человек должен владеть целью, методом, границами, неоднозначным решением и изменением
системы. Финальная проверка — только одна из ролей.
«Нужно максимально автоматизировать процесс»
Уточнение:
Необходимо выбрать правильную степень автоматизации. Иногда достаточно подсказки, scaffold,
проверки или проекта решения.
Компания, способная работать с ИИ 163
PDF — страница 164
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
«Если система сэкономила время, проект эффективен»
Уточнение:
Необходимо отдельно доказать:
технический результат;
процессный эффект;
принятие;
экономический эффект.
«Самообучающаяся система изменяет себя»
Уточнение:
Система обнаруживает повторяемые корректировки и предлагает изменения. Значимые правила
меняются управляемо, с участием владельца и версионированием.
10.5. Что осталось устойчивым
Несмотря на изменения, несколько положений сохранялись во всех трёх версиях.
Метод важнее инструмента
Модель не должна придумывать способ управления вместо компании.
Контекст является частью системы
ИИ должен знать не всё, а то, что необходимо для правильного действия в конкретной организации.
Начинать нужно с ограничения
Проект имеет смысл, если изменяет значимый результат, а не только демонстрирует техническую возможность.
Функции необходимо декомпозировать
Узкая, проверяемая и обратимая функция является более надёжной единицей внедрения,
чем должность или подразделение.
Человек сохраняет ответственность
Полномочие, смысл, неоднозначный выбор и изменение метода не исчезают с ростом автоматизации.
Ошибка должна улучшать систему
Если исправление не изменило правило, навык или процесс, организация не научилась.
Архитектура должна быть переносимой
Корпоративная способность не должна исчезать при замене модели, интерфейса или поставщика.
Компания, способная работать с ИИ 164
PDF — страница 165
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
10.6. Уровни доказанности
В развивающейся области особенно важно отделять наблюдение от вывода, а рабочую гипотезу —
от подтверждённого эффекта.
Практически подтверждённые механизмы
К этой категории относятся функции, которые могут быть непосредственно продемонстрированы и проверены:
извлечение информации;
подготовка черновиков;
проверка документов;
применение навыков;
поиск отклонений;
работа с корпоративным контекстом;
создание узких микросервисов;
версионирование правил.
Их техническая работоспособность не означает автоматически доказанного экономического
эффекта, но сам механизм наблюдаем.
Рабочие управленческие гипотезы
Требуют дополнительной проверки:
оптимальный способ распределения ролей между человеком и ИИ;
влияние scaffolding на развитие компетенций;
переносимость экспертных навыков;
экономический эффект корпоративного реестра;
связь машиночитаемости со скоростью управления;
влияние автоматического распространения навыков на качество организации.
Целевая архитектура
Некоторые элементы описывают направление развития:
автоматическое распространение корпоративных способностей;
сквозная связь стратегии, полномочий, задач и обучения;
вознаграждение авторов навыков;
регулярная автоматическая диагностика всей организации;
управляемая самоэволюция корпоративной методологии.
Эти идеи не следует представлять как универсально доказанные практики. Они являются
проектируемой моделью, которую необходимо проверять на масштабе и длительном горизонте.
10.7. Открытые вопросы
Методология продолжает развиваться. Несколько вопросов пока не имеют окончательного ответа.
Компания, способная работать с ИИ 165
PDF — страница 166
10. Эволюция методологии: что изменилось и что осталось неизменным Paper Planes
Как измерять экономику общих компонентов?
Один навык или элемент инфраструктуры может использоваться в десятках процессов. Не всегда
понятно, как распределять стоимость и эффект.
Как избежать чрезмерной стандартизации?
Система навыков способна быстро распространять сильный метод, но так же быстро закрепить
слабую или устаревшую практику.
Как сохранить человеческую компетенцию?
Снижение ручной нагрузки может сопровождаться потерей способности понимать и выполнять
работу без системы.
Как управлять конфликтом правил?
Чем больше процессов и подразделений подключено, тем выше вероятность противоречий
между локальными требованиями.
Как доказать переносимость?
Навык, созданный в одном контексте, может давать другой результат в новом подразделении, стране
или клиентской ситуации.
Где проходит граница допустимого наблюдения?
Машиночитаемость создаёт новые возможности управления, но одновременно повышает
риск тотального контроля сотрудников.
Как часто пересматривать архитектуру?
Слишком частые изменения разрушают стабильность. Слишком редкие приводят к накоплению
устаревших правил и зависимостей.
Эти вопросы не являются дефектом подхода. Они определяют программу его дальнейшего развития.
Компания, способная работать с ИИ 166