Эволюция методологии: что изменилось и что осталось неизменным

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

Эволюция методологии

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

Текстовое описание схемы

Сделать организацию машиночитаемой
От второго мозга к Harness
От архитектуры к корпоративной способности

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

Это описание принадлежит самой методике и здесь не проверялось. Раздел излагает его как объяснение подхода: откуда взялись положения методики и какие из них пересматривались. Опыт этих потоков не приписывается проекту исследования.

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

Эта эволюция важна не только как история появления методологии. Она показывает фундаментальное свойство самой области: устойчивый подход к искусственному интеллекту нельзя построить как раз и навсегда установленный стандарт.

Модели, интерфейсы и способы взаимодействия будут меняться. Поэтому методология должна уметь пересматривать собственные положения, сохраняя при этом устойчивое ядро.

10.1. Первая версия: сделать организацию машиночитаемой

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

Искусственный интеллект требует корпоративного контекста

Стало понятно, что универсальная модель не знает:

как устроена конкретная компания;
какие методы она применяет;
какой понятийный аппарат использует;
что считает качественным результатом;
какие решения принимала раньше.

Поэтому возникла идея корпоративного «второго мозга» — среды, в которой документы, записи, правила и проекты становятся доступными искусственному интеллекту.

В центре находится ограничение

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

Работа начинается с:

проблемы;
процесса;
ограничения;
внутренних знаний;
человеческого контроля.

CORD связывает информацию с действием

Появилась основная последовательность: Collect → Organize → Review → Do.

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

Человек остаётся внутри контура

Уже в первой версии человек выполнял три основные функции:

обучал систему;
объяснял контекст;
проверял результат.

Ограничение первой версии

Главным риском было чрезмерное внимание к форме хранения.

Конкретный инструмент — в частности, Obsidian и файловая база в Markdown — мог выглядеть центром решения. Это создавало впечатление, что правильно организованная база знаний почти автоматически превращается в ИИ-систему.

Но хранение и навигация решают лишь часть проблемы.

Необходимо было понять:

как система выбирает релевантный контекст;
как применяет методы;
как выполняет действия;
как проверяет ограничения;
как знания распространяются между сотрудниками;
как система изменяется после ошибки.

10.2. Вторая версия: от второго мозга к Harness

Во втором потоке центр методологии переместился от хранилища знаний к управляющей оболочке.

Инструмент перестал быть архитектурой

Obsidian сохранил полезность как интерфейс просмотра и простой способ навигации. Но перестал рассматриваться как обязательная основа системы.

Главным стал Harness — среда, связывающая:

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

Это был переход от вопроса «где хранить знания?» к вопросу «как знания участвуют в выполнении работы?»

Промпт уступил место контексту

Качество результата стало рассматриваться не как следствие одной удачной формулировки, а как продукт архитектуры:

какие правила действуют;
какой проектный контекст доступен;
какие навыки установлены;
какие источники подключены;
какие проверки обязательны;
какие термины понимает система.

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

Появилась зрелость процесса

Стало очевидно, что готовность процесса к ИИ зависит не только от его важности.

Процесс может быть:

хаотическим;
замысленным;
описанным;
исполнимым;
измеримым;
оптимизируемым.

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

Монолит уступил место узким микросервисам

Вместо попытки переделать основную корпоративную систему возникла идея создавать ограниченные сервисы вокруг неё.

Это уменьшало:

стоимость запуска;
время разработки;
риск;
зависимость от большого проекта автоматизации.

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

Появились:

QA — контроль качества;
Rail — проверка соответствия процессу;
Meditate — перевод исправлений в правила.

CORD стал дополняться полноценным контуром PDCA.

Ограничение второй версии

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

Оставался недостаточно проработанным вопрос:

Всегда ли задачу вообще следует превращать в исполнимый процесс?

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

10.3. Третья версия: от архитектуры к корпоративной способности

Третий поток добавил новый диагностический и организационный уровень.

Перед автоматизацией появилась классификация задачи

Стало необходимо различать:

воспроизводимые операции;
экспертно-аналитические задачи;
сложные ситуации;
хаотические состояния;
случаи, в которых природа задачи ещё не определена.

Это ограничило область применения агентов.

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

Появился scaffolding

Вторая важная идея — различие между инструкцией и когнитивной опорой.

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

показать факторы;
предложить альтернативы;
проверить допущения;
напомнить о рисках;
помочь распознать исключение.

ИИ стал рассматриваться не только как исполнитель, но и как когнитивный экзоскелет.

Модель себя стала основанием персонального Harness

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

его ответственностью;
методами;
профессиональным языком;
критериями качества;
полномочиями;
характерными корректировками;
границами допустимой автономности.

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

Навыки стали цифровыми активами

Навык перестал быть только локальной инструкцией.

Он получил:

автора;
владельца;
версию;
зависимости;
проверки;
область распространения;
историю применения;
цифровой след изменений.

Так возникла идея корпоративной операционной системы навыков.

Распространение экспертизы стало частью архитектуры

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

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

Rail и Meditate стали операционными механизмами

Rail превратился в конкретную инспекцию проекта по библиотеке процессов, а Meditate — в механизм извлечения правил из исправлений и инцидентов.

Самообучение перестало быть общей метафорой. Оно было представлено как управляемый цикл: инцидент → анализ → предлагаемое изменение → проверка → новая версия → распространение.

Машиночитаемость распространилась на полномочия

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

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

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

10.4. Что пересмотрено в методике

«Компании нужен второй мозг»

Уточнение: Компании недостаточно второго мозга как хранилища. Ей нужна система, связывающая память, методы, исполнение, контроль и обучение.

«Нужно собрать все знания»

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

«Нужно научиться писать хорошие промпты»

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

«Нужно создавать агентов»

Уточнение: Сначала нужно определить природу задачи. Агент оправдан в ограниченной функции с понятными действиями и проверяемым результатом.

«Человек должен проверять финальный ответ»

Уточнение: Человек должен владеть целью, методом, границами, неоднозначным решением и изменением системы. Финальная проверка — только одна из ролей.

«Нужно максимально автоматизировать процесс»

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

«Если система сэкономила время, проект эффективен»

Уточнение: Необходимо отдельно доказать:

технический результат;
процессный эффект;
принятие;
экономический эффект.

«Самообучающаяся система изменяет себя»

Уточнение: Система обнаруживает повторяемые корректировки и предлагает изменения. Значимые правила меняются управляемо, с участием владельца и версионированием.

10.5. Что осталось устойчивым

Несмотря на изменения, несколько положений сохранялись во всех трёх версиях.

Метод важнее инструмента

Модель не должна придумывать способ управления вместо компании.

Контекст — часть системы

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

Начинать нужно с ограничения

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

Функции необходимо декомпозировать

Узкая, проверяемая и обратимая функция — более надёжная единица внедрения, чем должность или подразделение.

Человек сохраняет ответственность

Полномочие, смысл, неоднозначный выбор и изменение метода не исчезают с ростом автоматизации.

Ошибка должна улучшать систему

Если исправление не изменило правило, навык или процесс, организация не научилась.

Архитектура должна быть переносимой

Корпоративная способность не должна исчезать при замене модели, интерфейса или поставщика.

10.6. Уровни доказанности

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

Названия категорий ниже и отнесение к ним принадлежат методике; здесь они не проверялись.

Практически подтверждённые механизмы

К этой категории относятся функции, которые могут быть непосредственно продемонстрированы и проверены:

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

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

Рабочие управленческие гипотезы

Требуют дополнительной проверки:

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

Целевая архитектура

Некоторые элементы описывают направление развития:

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

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

10.7. Открытые вопросы

Методология продолжает развиваться. Несколько вопросов пока не имеют окончательного ответа.

Как измерять экономику общих компонентов?

Один навык или элемент инфраструктуры может использоваться в десятках процессов. Не всегда понятно, как распределять стоимость и эффект.

Как избежать чрезмерной стандартизации?

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

Как сохранить человеческую компетенцию?

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

Как управлять конфликтом правил?

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

Как доказать переносимость?

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

Где проходит граница допустимого наблюдения?

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

Как часто пересматривать архитектуру?

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

Эти вопросы — не дефект подхода. Они определяют программу его дальнейшего развития.