10 — Эволюция методологии — читательская версия

PDF — страница 156

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

10

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

PDF — страница 157

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

• Сделать организацию
• 1 машиночитаемой

• От второго мозга к Harness
• 2

• От архитектуры
• 3 к корпоративной способности

• Схема по тексту: § 10.1–10.3. Геометрия показывает связи и последовательность, а не количественные значения.

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

Три крупных серых круга с номерами: 1 сделать организацию машиночитаемой; 2 от второго мозга к Harness; 3 от архитектуры к корпоративной способности. Основание: §10.1–10.3, с. 158–163.

В исходном линейном извлечении второй круг/цифра 2 плохо отделён от заголовка, но визуально присутствует. Это история трёх потоков авторской образовательной программы. Она не доказывает, что все компании должны проходить те же три стадии, и не является второй лестницей зрелости.

PDF — страница 158

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

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

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

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

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

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

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

• как устроена конкретная компания;

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

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

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

• какие решения принимала раньше.

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

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

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

• проблемы;

• процесса;

• ограничения;

• внутренних знаний;

• человеческого контроля.

CORD связывает информацию с действием Появилась основная последовательность: Collect → Organize → Review → Do.

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

PDF — страница 159

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

• обучал систему;

• объяснял контекст;

• проверял результат.

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

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

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

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

• как система выбирает релевантный контекст;

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

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

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

• как знания распространяются между сотрудниками;

• как система изменяется после ошибки.

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

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

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

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

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

• правила;

• навыки;

• агентов;

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

• проверки;

• рабочие системы;

• человека.

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

PDF — страница 160

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

• какие правила действуют;

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

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

• какие источники подключены;

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

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

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

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

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

• хаотическим;

• замысленным;

• описанным;

• исполнимым;

• измеримым;

• оптимизируемым.

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

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

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

• стоимость запуска;

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

• риск;

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

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

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

• Rail — проверка соответствия процессу;

Meditate — перевод исправлений в правила.

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

PDF — страница 161

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

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

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

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

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

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

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

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

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

• сложные ситуации;

• хаотические состояния;

• случаи, в которых природа задачи ещё не определена.

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

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

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

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

• показать факторы;

• предложить альтернативы;

• проверить допущения;

• напомнить о рисках;

• помочь распознать исключение.

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

PDF — страница 162

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

• его ответственностью;

• методами;

• профессиональным языком;

• критериями качества;

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

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

• границами допустимой автономности.

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

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

Он получил:

• автора;

• владельца;

• версию;

• зависимости;

• проверки;

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

• историю применения;

• цифровой след изменений.

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

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

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

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

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

PDF — страница 163

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

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

• какие компетенции подтверждены;

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

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

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

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

10.4. Что мы пересмотрели

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

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

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

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

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

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

PDF — страница 164

«Если система сэкономила время, проект эффективен» Уточнение: Необходимо отдельно доказать:

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

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

• принятие;

• экономический эффект.

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

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

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

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

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

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

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

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

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

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

PDF — страница 165

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

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

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

• извлечение информации;

• подготовка черновиков;

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

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

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

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

• создание узких микросервисов;

• версионирование правил.

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

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

• оптимальный способ распределения ролей между человеком и ИИ;

• влияние scaffolding на развитие компетенций;

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

• экономический эффект корпоративного реестра;

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

• влияние автоматического распространения навыков на качество организации.

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

• автоматическое распространение корпоративных способностей;

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

• вознаграждение авторов навыков;

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

• управляемая самоэволюция корпоративной методологии.

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

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

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

PDF — страница 166

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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