Что это такое
Конвейер фиксации решений — структурированный поток записей о моментах, в которых ваш сотрудник или система делает выбор. На вход — контекст и альтернативы. На выходе — выбор, его обоснование и результат. Каждая запись привязана к точному моменту времени и не редактируется задним числом. Это глубже, чем журнал событий или лог приложения: те фиксируют, что произошло, а конвейер — почему так выбрали.
В методике Oper8 это корень шестерни «Память» маховика данных. Без неё маховик не крутится: модели обучаться не на чем, метрики качества считать не из чего, переход на следующий уровень автономии обосновывать нечем.
Главное разграничение: лог действий ≠ лог решений. Лог действий отвечает на вопрос «что произошло». Лог решений отвечает на «почему выбрано это, а не одно из трёх других». В системе CRM фиксация «менеджер изменил статус заявки на "одобрено"» — это лог действия. Фиксация «менеджер выбрал "одобрено" из трёх вариантов (отказ / условное одобрение / полное одобрение), потому что соотношение долга к доходу в норме, история чистая, доход подтверждён» — это лог решения.
Лог решений работает в момент принятия решения и не редактируется задним числом. Это поток сырья для обучения агента, а не аудит, не дашборд метрик и не документооборот.
Из чего состоит
Полная запись о решении содержит восемь полей. Их удобно держать в голове как четыре блока: что дано (срез контекста), что выбрали (альтернативы, выбор, обоснование), кто и когда (уверенность, версия системы, время), что получилось (результат). Без любого из них лог теряет смысл для маховика данных.
Срез всех вводных, которые видел человек или система в момент выбора: цифры из CRM, статусы, история. Строго «как было в 14:32 12 апреля» — заморожено, не обновляется и не подтягивается из текущего состояния системы.
2. alternatives — рассмотренные варианты
Минимум два-три варианта, каждый с метками. Если в журнале стоит «выбран вариант А», но альтернативы не записаны — мы не понимаем, что отвергли. А без отвергнутых вариантов агенту не на чем учиться: он видит выбор, но не видит границ, по которым выбор сделан.
3. chosen — выбранный вариант
Тот из альтернатив, который пошёл в работу. Простое поле, ссылка на одну из меток в alternatives.
4. reasoning — обоснование одной-двумя фразами
Одна-две фразы, не больше: «соотношение долга к доходу стабильное, срок позволяет снизить платёж». Главное — зафиксировать критерий, по которому сделан выбор. Через год по этому полю строятся примеры для обучения агента.
5. confidence — уверенность принимающего
Субъективная оценка: high / medium / low или 0–100 %. Это поле — самое полезное для приоритизации. Низкая уверенность плюс плохой результат через 6 месяцев — кандидат в обучение. Высокая уверенность плюс плохой результат — кандидат в разбор причин.
6. model_version — кто принимал решение
Версия системы или роль человека (senior_underwriter, model_v3.1). Если решений несколько (человек + AI в советующем режиме) — фиксируются оба, и помечается, какое учли в действии. Без этого поля при изменении системы вы теряете способность сверять старые решения с новыми.
7. timestamp — точное время
Не просто дата, а время с точностью до секунды. Без этого нельзя восстановить порядок событий и сопоставить с другими системами.
8. outcome — результат через N дней или месяцев
Самое сложное и самое важное поле. Через сколько недель решение можно оценить? Что считать успехом? Это поле заполняется отложенно — через 30, 90, 180 дней, в зависимости от процесса. Без него вы записали факт, но не замкнули контур обучения.
Что даёт бизнесу
В банке федерального уровня для процесса кредитного андеррайтинга мы внедрили лог решений на год до запуска AI-агента. Андеррайтеры заполняли восемь полей в своей рабочей системе на каждой заявке — это добавляло 90 секунд к решению. За 11 месяцев накопилось 38 000 структурированных записей с результатом через 6 месяцев. Когда мы запустили AI-агента, ему дали обогащение примерами (few-shot) из лога — 200 типовых решений с обоснованиями. Агент вышел на уровень A3 за 4 недели вместо ожидаемых 4 месяцев: учиться было на чём.
В крупной телеком-компании мы начинали с обратного — диспетчеры техподдержки год работали без лога решений по маршрутизации обращений. Когда дошли до AI-агента, оказалось, что обучить не на чём: в системе тикетов есть факт «направлено в линию 2», но нет «направлено в линию 2, потому что три симптома совпали с типовой проблемой роутера, а не биллинга». Пришлось 10 недель сидеть с инженерами и разбирать решения задним числом — реконструировать обоснования по 800 закрытым кейсам. Это работа, которой можно было бы избежать.
Сроки разные по сегментам. В Mid-market на одном процессе лог решений собирается за 4–6 недель проектирования и работает с первого дня. В Enterprise проектирование одного лога занимает 2–3 месяца — нужно согласовать формат с compliance, привязать к единому источнику истины (Source of Truth), обеспечить защиту от редактирования и аудит. Зато потом на 3–5 соседних процессов формат тиражируется быстро.
С чего начать
Первый шаг — выбрать одно критическое решение в вашем процессе. Не пять и не три. Одно, которое часто принимается, имеет последствия и где сейчас «знание в голове». Типичные кандидаты: кредитный андеррайтинг, найм на ключевую позицию, выбор поставщика, маршрутизация заявки на инженера, оценка ремонта в страховании.
Спроектируйте формат записи под это решение. Не используйте универсальный шаблон — поле input_snapshot зависит от того, какие данные доступны в момент решения; alternatives — от того, какие варианты в принципе возможны. Универсальный шаблон даёт лог, в котором половина полей пустая, а другая — мусорная.
Внедрите форму в существующую систему. Не плодите отдельный инструмент — лучше расширить CRM/ERP/HRM полем «обоснование» и тремя альтернативами, чем создать параллельный лог, в который никто не будет писать. Заполнение записи должно занимать не больше 60–120 секунд — иначе сотрудники начнут саботировать.
Замкните контур через outcome. На старте определите, через сколько времени можно оценить результат (для кредита — 6 месяцев, для найма — 3 месяца, для маршрутизации тикета — 24 часа). Поставьте регулярный процесс заполнения этого поля — лог без outcome работает на половину мощности.
Если выбрать одно решение сложно. Это типичный сценарий в Enterprise: всё кажется критическим, владелец каждого процесса тянет на себя. Для такого случая мы делаем 30-минутную диагностику — берём 2–3 кандидата на лог, оцениваем по объёму, окупаемости и сложности проектирования и показываем, с какого начинать.
Где разваливается
Лог действий вместо лога решений. Самый частый режим отказа: команда говорит «у нас всё логируется в CRM», открываем — там даты и статусы, нет ни альтернатив, ни обоснования. Лечение: на каждое решение спрашивать «из чего выбирали?» Если ответ «варианта особо не было» — это либо лог не нужен (процесс детерминирован), либо человек не привык фиксировать альтернативы, и его этому надо учить.
Поле outcome пустое. Команда честно заполнила контекст и обоснование, но забыла замкнуть контур через результат. Через год у вас 40 000 решений, по которым невозможно отличить хорошие от плохих. Лечение: на старте определить срок ожидания результата и поставить регулярный (еженедельный или ежемесячный) процесс заполнения. Если процесс заполнения требует «зайти в три системы и сверить руками» — он не работает; нужна автоматическая интеграция.
Лог редактируется задним числом. Сотрудник идёт в запись от прошлого месяца и «уточняет» обоснование, потому что неловко за плохое решение. Через 6 месяцев в логе только успешные обоснования. Маховик учится на отредактированной истории, агент в боевом режиме видит совсем другую реальность. Лечение: технически — лог только пополняется, без редактирования прошлых записей; исправления оформляются как новые записи с пометкой «исправление». Культурно — отделить страх ответственности от анализа причин: ошибочное решение не повод для наказания, а сырьё для обучения.
