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

Методология «Партия компании»

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

Три функции одной модели

Модель «Гелиоса» должна одновременно быть:

1. Контекстом для AI-агентов — давать релевантные задачи, контракты, полномочия и инструменты. 2. Прибором для консалтинга — показывать неизвестность, узкие места, эффект и приоритет следующего изменения. 3. Картиной для человека — объяснять состояние компании и динамику трансформации без чтения всего реестра.

Ловушка — строить для этих функций три независимые модели. Правильный принцип: существует один реестр, а агентный контекст, аналитика и визуализация являются его проекциями. ^partiya-odnogo-vechera-2026-09-10

Оригинальная связка «Гелиоса»

Отдельные компоненты уже существуют в индустрии: C4, Architecture as Code, process mining, task taxonomies, policy/governance и agent runtimes. Отличительная гипотеза «Гелиоса» — их последовательная связка:

$$\text{Штатка L1} \rightarrow \text{градуированная разведка L2-L5} \rightarrow \text{реестр атомов} \rightarrow \text{слотовое замещение} \rightarrow \text{измеримый эффект}$$

Новизну этой комбинации следует считать рабочей гипотезой, пока не проведён отдельный prior-art и патентный поиск.

Единица модели: атом-задача

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

Минимальный контракт атома:

Тест атомарности

Атом проходит CI, если:

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

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

Шкала разведанности, а не мнимая объективность

Достоверность живёт на каждом атоме, а не на модели целиком:

• L1: гипотеза из штатного расписания и структуры.
• L2: внешняя нормативная гипотеза — вакансии, O*NET, APQC и отраслевые описания.
• L3: подтверждение речью и практикой — интервью, встречи, чаты, регламенты.
• L4: подтверждение цифровыми следами — CRM, DWH, event logs, статусы и таймстемпы.
• L5: подтверждение экономикой — P&L, ФОТ, стоимость операции и финансовый эффект.

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

Карта разведанности как первый продукт

Распределение атомов по уровням L1–L5 образует отдельный управленческий артефакт. Оно отвечает не «сколько процессов описано», а «какая доля компании подтверждена данными».

Возможные метрики:

$$Coverage_{Lk+}=\frac{\sum weight(atom_i),\ level_i\geq k}{\sum weight(atom_i)}$$

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

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

Тест воспроизводимости нарезки

Одну роль или процесс независимо разбирают два экстрактора. Совпадение наборов атомов служит численной оценкой устойчивости модели.

Базовые меры:

• Jaccard similarity для списков задач;
• совпадение входов/выходов;
• согласие по границам атомов;
• согласие по владельцам и SLA.

Низкое совпадение не доказывает ошибку, но повышает приоритет L3-разведки человеком.

Агент как ход

Агент не «занимает должность» целиком. Ход — изменение конкретного атома:

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

Субъектность агента ограничена allowed_actions, ролями доступа, финансовыми лимитами и необходимостью подтверждения. Свободная текстовая инструкция не заменяет governance.

Четыре судьбы атома

Для визуализации трансформации полезны четыре состояния:

1. Human — задача выполняется человеком. 2. Centaur — решение или ответственность у человека, часть работы у AI. 3. Neuro — задача исполняется агентом в допустимых границах. 4. Eliminated/Redesigned — задача устранена или перестала существовать после перестройки процесса.

Классификация на L1/L2 является гипотезой. Фактический статус должен подтверждаться логами исполнения и владельцем процесса.

Эффект как изменение потока

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

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

$$Effect(atom)=Metrics_{after}-Metrics_{before}$$

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

Счёт партии

Счёт территории показывает распределение выполнения между Human, Centaur и Neuro. Это обзорная, а не самодостаточная метрика.

Варианты взвешивания:

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

Кифу компании

Кифу — воспроизводимая последовательность ходов, из которой восстанавливается состояние реестра. Технически это Git-история манифестов плюс связанная телеметрия исполнения.

Каждый ход должен хранить:

• изменённые атомы и diff;
• автора предложения и ревьюеров;
• гипотезу эффекта;
• основания и уровень уверенности;
• версию агента, промпта, скилла и инструмента;
• дату применения и окно наблюдения;
• результат и решение: оставить, откатить или переработать.

Кифу как отчётность

Квартальный отчёт о трансформации можно строить не как перечень проектов, а как историю партии:

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

MCP-представление модели

Модель не должна целиком вставляться в каждый prompt. MCP-сервер предоставляет три логических класса интерфейсов:

1. Context: получить релевантный фрагмент онтологии, контракт и доказательства. 2. Queries: исследовать связи, уровни достоверности, drift и метрики. 3. Actions: предложить или выполнить разрешённый ход с governance и аудитом.

Эти «три порта» — логическая модель API, а не обязательное требование сделать три физических сервера.

Рёбра модели и междоменные SLA

Следующий уровень зрелости — перейти от сильного описания узлов к рёбрам:

• кто кому делегирует;
• какой артефакт передаётся;
• в каком формате;
• какой SLA действует;
• куда эскалировать исключение;
• кто принимает ответственность после передачи.

Именно event logs, переписка и транскрипты L3/L4 позволяют восстановить реальные траектории работы между доменами.

Двусторонний drift

Контроллер сравнивает манифест и наблюдаемое выполнение, но не считает манифест автоматически правым:

• если нарушена рабочая политика — предлагается изменение исполнения;
• если практика устойчиво превосходит устаревший регламент — формируется обратный MR к модели;
• если данных недостаточно — уровень уверенности понижается и назначается разведка.

Подробнее: Everything as Code для «Гелиоса».

Калибровка эталонов

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

1. лучшие сопоставимые подразделения самой компании; 2. исторический baseline; 3. внешний benchmark с явной применимостью; 4. экспертная гипотеза, помеченная как гипотеза.

Практический falsification test

Минимальный следующий эксперимент — взять выгрузку одного типа заявок из CRM с идентификатором случая и датами смены статусов.

Эксперимент должен:

1. выбрать один процесс и предполагаемый атом; 2. восстановить реальные переходы и время цикла; 3. сопоставить их с манифестом; 4. определить узкое место и ручные касания; 5. подтвердить или опровергнуть границу атома; 6. повысить его до L4 либо явно зафиксировать ошибку модели.

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

Позиционирование

Рабочая гипотеза позиционирования: «Гелиос» не заменяет Celonis, Palantir или UiPath, а создаёт дешёвый передний край — первичную карту компании из штатки и доступных текстовых источников за дни, затем постепенно подключает process mining, DWH и экономику.

Это требует проверки на реальных внедрениях. Основной риск — обещать достоверную модель бизнеса до появления L3/L4-доказательств.

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

• Выбрать стандарт идентификации: APQC PCF, собственная нумерация или гибрид.
• Формализовать CI-схему атома и операции split/merge.
• Определить формулу воспроизводимости независимых экстракторов.
• Разработать governance для порта Actions и staging «что если».
• Выбрать знаменатели для счёта партии и запретить их неявное смешивание.
• Проверить market/prior art гипотезу об уникальности связки.
• Провести первый L4-эксперимент на CRM event log.