И_И_ by paperplanes

Экспертные продажи как система данных Экспертные продажи держатся на когнитивной стратегии сильного менеджера: он держит в голове карту клиента - структуру холдинга от головной организации до объектов, ЛПР на каждом объекте, проектные институты, которые формируют требования к закупке. С ИИ можно собрать систему поверх этой методологии, помогающий работать эффективнее. Покажу два примера • PowerMap. Помогает ответить на вопрос: как дотянуться до ЛПР-а такой-то компании, если мы не знакомы? На базе внутренних данных CRM и данных, которые парсятся в ходе АБМ-активностей собирается единый граф связей и становиться видно, сколько касаний надо совершить до компании X. • Скоринг потенциала региона/бизнеса/отрасли. Отвечает на вопрос, у кого при тех же усилиях команды потенциал выше. Лиды в воронке ранжированы по динамике роста, выручке, отрасли и географии. Менеджер остаётся владельцем смысла (в логике HITL). Условие одно - корректная работа с данными. Отсюда задача. Собрать верное озеро данных(писали об этом в прошлых постах) и сделать экспертную продажу воспроизводимой у всей команды.

⚡️⚡️⚡️В Mooove появилась новая подборка «Искусственный интеллект в бизнесе» Внутри наши вебинары по ИИ для тех, кто пропустил или хочет пересмотреть и подкрепить это полезными материалами, а также платные фрагменты интенсива и лонгриды для подписчиков: о том, как встроить ИИ в работу компании, выбрать подходящий процесс, настроить проверку человеком и превратить ИИ из разового развлечения в управленский инструмент. В материалах вы узнаете, что такое машиночитаемый процесс, как встроены в работу ИИ циклы PDCA и CORD, как устроена система И_И_ Paper Planes и многое другое:) Ссылка на подборку - https://mooove.ru/collections/iskusstvennyy-intellekt-v-biznese Будет интересно!

Виды collect: как ловить разные сигналы В цикле PDCA мы уже разбирали review и organise, теперь вернёмся к отправной точке контура «думай» — к collect. Collect — это фиксация всех значимых для меня данных внутри системы. Главный принцип: у разных типов информации разные носители, и под каждый у меня заведён свой инструмент сбора информации. Встречи и переговоры. Все созвоны трансрибируются, после через MCP передаются в Codex. Дальше Codex проходится по нему и сам помечает, что это было: встреча, лекция или просто идея. Лекции, выступления и спонтанные мысли. Ловлю через умные очки и приложение Voice Notes. Чтение книг. Использую Readwise. Все мои хайлайты система забирает, размечает, тэгирует, формирует новые связи в графе obsidian после. Рукописные заметки. Пишу от руки в Remarkable. Проходчик забирает написанное раз в шесть часов, все картинки и наброски падают в Obsidian, а в конце дня из этого мне собирается отчёт за день. Доп источники. Календарь: каждое новое событие падает в коллект автоматически. Метрики из CRM по разным источникам. Материалы коллег. Отдельный важный канал. То, что делает команда, течёт ко мне через туннель: один-два раза в день всё, что появилось на её диске, оценивают мои проходчики и поднимают мне только то, что помечено как важное. И ещё про то, как коллект устроен. Его дело - поймать и рассортировать, в содержание не вникать: вот двадцать писем, из них три важных, семнадцать нет. Главная задача Collect - не пропустить сигнал. У любой вашей задачи должно быть множество каналов коллекта, помыслить их значит начать работать над вашей системой:) Для тех, кто пропустил или хочет углубиться в тему, мы будем продолжать показывать и рассказывать, как построить свою систему на нашем следующем интенсиве по ИИ, записывайтесь или пишите в лс @ilia_balahnin:) https://xn----itbbmgpihhfjo1e9bbj.xn--p1ai/programs/ai-v-biznese

Решение устаревает раньше, чем его внедрили Компании вкладываются в ИИ ради скорости - быстрее считать, быстрее реагировать. И почти никто не замечает, что сама скорость превращается в управленческий риск. Механизм этого риска описал ещё в шестидесятых Дональд Шон. Чем быстрее меняется среда, тем сложнее становятся проблемы, которые она перед нами ставит. Чем сложнее проблема, тем больше времени уходит на её решение. А чем дольше мы решаем, тем сильнее за это время успевает измениться сама проблема. В итоге к моменту, когда решение готово, оно относится к ситуации, которой уже нет. Шон называл такие решения мертворождёнными - они корректны для мира, который успел исчезнуть, пока их собирали. Представьте компанию, которая год выстраивает коммерческую стратегию под конкретный рынок. Через год стратегия готова, но рынок за этот год изменился, конкурент выпустил новый продукт, клиент поменял привычку. в итоге ресурсы потрачены на решение задачи, которой больше не существует в прежнем виде. ИИ эту проблему не снимает, а возводит в степень. Он ускоряет цикл у всех сразу - у вас, у конкурента, у клиента. Среда начинает меняться ещё быстрее, проблемы сменяют друг друга ещё чаще, окно для принятия решения сжимается. Теперь машина должна каждый день сверять вошедшие в нее новые факты с стратегией и подсвечивать, что изменилось, где возникли риски/возможности/вопросы. Что нужно, чтобы система работала именно так. 1. Машиночитаемость процессов компании, где ключевые объекты и связи заданы заранее: откуда брать итоги встреч, где создаются артефакты всеми участниками компании, какие возникают инциденты, отклонения и тп. 2. Контрольная вышка как набор людей и процессов, отвечающих за доклад собственнику о всех отклонениях, наблюдениях, изменениях. 3. Цикл PDCA, по которому каждое отклонение превращалось в сверку/пересмотр правил. Так меняется и сам предмет управления: вместо статичного плана он управляет скоростью, с которой компания замечает изменение рынка и подстраивается под него. Как такую систему создать будем показывать и рассказывать на нашем следующем интенсиве по ИИ, записывайтесь или пишите в лс @ilia_balahnin:) https://xn----itbbmgpihhfjo1e9bbj.xn--p1ai/programs/ai-v-biznese

Проходчики В словаре был термин «проходчик». Раскрываю его подробнее. Это один из самых полезных и при этом малозаметных классов артефактов в моей ИИ-системе. Проходчик — автоматический крон-оператор внутри Codex. Он не ждёт, пока я что-то спрошу. Включается сам по расписанию, проходит по Vault, выполняет конкретные правила и возвращает мне сводку только тогда, когда нашёл нечто требующее моего внимания. У меня три типа проходчиков. Архетипический проходчик Сканирует новые проекты и сопоставляет их с прошлыми. У меня в Notion 16 лет архива, и за это время сформировались устойчивые архетипы клиентских ситуаций. Условно — архетип А, Б, С. Каждый со своим набором ранних сигналов, ловушек, рабочих манёвров. Проходчик берёт активный проект и говорит: «На него больше всего похожи архетип А и Б. Чтобы понять, какой именно, на ближайшей встрече задай вот такой вопрос. Если ответ такой — это А, если такой — это Б». QA-агенты Работает по жёстким правилам. У меня есть набор стандартов проекта: на третий день должен быть собран паспорт проекта, на седьмой — оценка консистентности базы и тп. Если стандарт не выполнен, проходчик это ловит. Дальше он не делает работу сам. Он сообщает мне: «На проекте X отсутствует паспорт. Запросить разрешение на сбор?» Если разрешаю — запускается следующий проходчик, который собирает паспорт по шаблону и подкладывает мне на проверку. Коммуникатор Передаёт данные другим сотрудникам по правилам сопоставления. У каждого человека в команде есть свой профиль интересов и ответственности. Проходчик-коммуникатор знает: такие данные имеют ценность для такого человека. Обмен идёт через проходчиков с версионированием. Они берут актуальное состояние нужных файлов, упаковывают как пакет для конкретного адресата, отдают(настройка через Oath гугла). Что важно понять про класс проходчиков в целом. Они работают как автоматические уборщики системы. Содержательную работу за вас они не делают - их задача в том, чтобы в системе оставался порядок без вашего постоянного участия. Стандарты соблюдены. Ничего не потерялось. Каждый новый проект приземлился в правильный архетип. Дальше в канале разберём один из классов проходчиков - QA-агентов.

Где рвётся цикл PDCA Цикл PDCA знают все: Plan, Do, Check, Act — планируй, делай, проверяй, улучшай. На бумаге круг замкнут. На практике он рвётся на последнем шаге, на Act. Ошибку нашли, обсудили, а в системе ничего не поменялось. Через месяц она возвращается на том же месте. Act случается тогда, когда после разбора в системе реально меняется правило, ответственный, точка проверки, показатель или обучение. Разобрали на планёрке и разошлись — этого мало. Простой признак. Ошибка случилась второй раз - дело уже не в исполнителе, а в том, что после первого раза систему не обучили. 4 признака пройденного Act. • Правило. Переписали норматив, по которому работают дальше. • Ответственный. У изменения есть человек, который за него отвечает. • Предупредительный сигнал. Появился маркер, который поймает ошибку раньше. • Обучение. Обновление дошло и до команды. Признак разомкнутого круга. «Мы регулярно проводим ретроспективы». Если после разбора в системе ничего не меняется, это Check без Act. Что делать. На каждый разобранный случай - одно конкретное изменение: правило, ответственный, показатель и тп. Собрать эту рутину можно скиллом, который проверяет и сверяет с вами, что стоит занести в правила.

Озеро данных и метафайлы Залить данные в общую базу для ИИ это только первый и самый поверхностный шаг. Модель отвечает на запросы, но видит набор разрозненных фактов без связи между ними. Знанием это становится, когда поверх озера появляются метафайлы, которые учат машину видеть цепочки причинно-следственных связей. Озеро это хранилище под единой моделью данных. Метафайл это срез поверх него: он описывает, как одно связано с другим. По сути метафайл это обычный текстовый файл рядом с данными. В нём человеческими словами записано, из каких частей состоит озеро, что с чем связано и какая цепочка ведёт от вопроса к выводу. Лежит он в той же папке, что и данные, и читается так же, как все остальные файлы системы. Покажу на озере данных процесса опросов (мы их часто проводим на проектах). В нём лежат сотни проведённых исследований. Сами по себе они отвечают на вопрос «что люди сказали». Поверх них мы кладём метафайл, который строит цепочку: какой вопрос анкеты, каким способом его визуализируют, какое наблюдение из ответов вытекает, какой вывод за ним стоит. Теперь система отвечает не «вот данные». Она показывает, к чему это приводит. Как собрать метафайл, по шагам. • Опиши сущности. Перечисли, из чего состоит озеро. Для опросов это: анкета, вопрос, тип вопроса, способ визуализации, ответ, сегмент аудитории, вывод. • Пропиши связи. Укажи, что с чем сцеплено. Например: «вопрос про цену строится гистограммой, частое наблюдение — чувствительность к цене у сегмента Б». • Собери цепочки. Свяжи связи в маршрут от входа к решению: вопрос, визуализация, наблюдение, вывод, какое управленческое решение можно принять. • Обеспечь HITL. Дальше система сама замечает новое: прошла новая волна опросов, появилась устойчивая закономерность. Но в метафайл она её не вписывает без подтверждения: «вижу вот такую связь, добавляем?». Строка попадает в файл только после твоего «да». Это HITL: машина видит закономерность, человек решает, становится ли она правилом. Выглядит запись обычным текстом: оценка NPS → разрез по сегментам → низкая оценка в сегменте Б → проседает только один сегмент → решение: частная это практика или системная проблема Признак сырого озера. «Мы загрузили все наши данные в ИИ». Загрузить мало: без метафайлов это поиск по всем данным, который выдаёт ближайший похожий кусок без причинной связи. Для работы в логике И_И_ нужны и данные, и связи между ними :)

Маршрутизация внимания Собственник часто формулирует запрос так: хочу контролировать все свои проекты. У меня их под сто. Контролировать столько проектов нельзя, это самообман: внимание не масштабируется. Размазанный контроль - это уже не контроль. ИИ здесь не расширяет внимание. Он его маршрутизирует. И отвечает на другой вопрос: какие проекты держать в фокусе сегодня и почему. Маршрутизация внимания это модель ротации. Из всего портфеля система каждый день выводит ограниченный набор, остальное держит в фоне. Покажу на своем примере. Раз в день система проходит портфель и поднимает мне примерно четверть проектов, по правилам триажа. Что-то поднимается, потому что подошёл срок гейтов. Что-то — потому что появилось отклонение от плана. Что-то — потому что давно не открывалось и копится риск. Остальное намеренно не показывается. Как выбираются приоритеты. • Триаж. Что вообще достойно фокуса сегодня, а что ждёт. • Буферы и лимиты. Сколько проектов можно держать в работе разом, без перегруза. • Срок и отклонение. Подошли ворота или появилось расхождение с планом — проект всплывает. • Когнитивная сложность Legacy. Цена возвращения в проект, который не трогали две недели, кратно выше: на перевключение уходит больше, чем на саму работу. Система это учитывает. Признак фейкового контроля. Дашборд, где видны все двести проектов разом. Это иллюзия охвата: решения не принимаются, а ощущение «я всё вижу» мешает заметить, что не видишь ничего. Как решить эту проблему. Определить, по каким сигналам проект достоин фокуса: срок, отклонение, риск простоя, давность касания. Задать лимит на число проектов в работе. Завести крон, который раз в день поднимает только то, что прошло по правилам. Остальное держать в фоне до срока. Без машины необходимость фокусироваться и большой портфель проектов/клиентов конфликтуют: чем больше проектов, тем тоньше размазано внимание. С маршрутизацией портфель растёт, а фокус остаётся.

Что значит внедрить ИИ «Мы внедрили ИИ» обычно означает «поставили бота». На самом деле внедрить ИИ это не про инструмент вовсе. Это про то, что вы сначала разобрали свою работу: какого класса перед вами задача и на каком она уровне. Инструмент подбирается в конце и оказывается мелким техническим вопросом. Большинство же идёт с конца - берёт модную модель и ищет, куда её приткнуть. Внедрить ИИ значит перенести задачу на карту: три уровня ценности и восемь классов задач. Три уровня ценности. • Экономика. Ворота, через которые проходит любая затея: это окупится? • Операции. Главный уровень. Здесь ИИ меняет, как компания принимает решения и ведёт процессы(машиночитаемые). • Рутина. Вымещение ручного труда. Полезно, но глубокой проработки не требует и большого эффекта не даёт. Восемь классов задач. • Формализация. Собрать из разрозненных входов машиночитаемое ТЗ. База, с которой начинается всё остальное. • Выравнивание. Состыковать процессы, которые рассинхронились: продажи с производством, план продаж с закупками. • Ускорение. Сжать цикл: сделку, вывод продукта, время до первой ценности для клиента. • Экспертиза и рынок. Столкнуть экспертизу компании с внешними данными: новые продукты, оценка рынка. • Контроль качества. Проверка артефактов и ранние сигналы об отклонении, пока оно не стало убытком. • Знания и люди. Обучение, адаптация, передача знаний, найм как отдельный процесс. • Клиентский сервис. Работа до продажи и после: квалификация, сопровождение, удержание. • Смысловая работа. Контент, аналитика, тексты — там, где нужен смысл, а форма вторична. Признак мнимого внедрения. «Давайте внедрим ИИ в продажи». Продажи это функция, а никакая не задача. Пока не назван класс — формализация, ускорение или контроль качества — и уровень ценности, внедрять нечего. Получится ИИ ради ИИ.

Обратная связь как данные Обратную связь в командах обычно дают голосом и забывают половину через неделю. У нас годами был ритуал: вечером по четвергам каждый каждому говорил, что нужно скорректировать за неделю. Хвалить нельзя, прогресс отмечать нельзя — только зоны роста. Записывали на стикеры, через неделю сверялись. И тут вскрылась дыра: через пять недель уже не вспомнить, что говорили на первой, и выводов из этого не сделать. Обратная связь была, данных не было. Машиночитаемая обратная связь это та же оценка, но в форме, которую читает не только человек. У каждого пункта есть поля: кто, что за событие, какой это сигнал, что с ним делать дальше. Мы переделали сам формуляр обратной связи. Теперь оценка попадает в систему как структурированная запись, и машина понимает её семантику. Простой случай: «Влад впервые сам провёл презентацию клиенту». Для системы это ключ допуска: она знает, что первая самостоятельная презентация разблокирует следующий уровень, ставит пометку в карточке и пишет: «рассмотреть повышение через три месяца». Никто не держит это в голове, и сигнал никуда не пропадает. Что обратная связь содержит в себе, когда становится данными. • Событие. Что именно произошло, привязано к человеку и дате. • Тип сигнала. Допуск, риск, прогресс, нарушение — машина различает их по семантике. • Следующий шаг. Куда сигнал отправляется: в карьерную карту, в кадровое решение, в план развития. • След. Запись остаётся, и через пять недель видно всю траекторию, а не обрывок. Зачем это собственнику. Кадровые решения перестают зависеть от того, кто что вспомнил на совещании. Траектория сотрудника собирается из сигналов сама, и повышение или разговор о проблеме опирается на запись. Не на впечатление последней недели. Признак фейковой обратной связи. «Мы регулярно даём друг другу фидбэк». Если она живёт в устных разговорах и стикерах, через месяц от неё остаётся ощущение. Проверка простая: можете ли вы поднять, что именно говорили конкретному человеку пять недель назад, и что с этим стало. Без обратной связи система всегда сползает вниз. Плато не бывает: сотрудник, команда, процесс либо растут, либо деградируют. Машиночитаемая обратная связь ловит сползание раньше, чем оно стало проблемой.

⚡️⚡️Собрали саммари по первому дню интенсива В карточках: — CORD целиком: сбор, разбор, просмотр, действие; — двенадцать источников, откуда вообще приходит материал; — устройство рабочей папки — куда всё складывается после разбора; — Readwise как вход для чтения и исследований; — и первый запуск, с которого всё начинается. Листайте. Если хочется глубже — пост с разбором CORD выше в ленте.

Сегодня провели первый день интенсива по управляемой ИИзации. Собрали очень разный бизнес: производство мебели, продажа электромобилей, медицинский B2B, B2B SaaS, стройка, билетный оператор, ресторанный консалтинг, интеграторы умного дома. Большинство приходит за ИИ с вопросом «какой инструмент взять». А разобраться надо до этого: куда вообще ставить, что описывать, что считать управленческим эффектом. Сегодня про это и говорили. Сразу оговорюсь. Дальше я буду расписывать конкретно свою систему - со своим набором инструментов и привычек. У вас будет другой набор, и это нормально. Обсуждали много чего: • 12 классов бизнес-процессов - куда вообще ставить ИИ. • Цикл «думай» (CORD) - четыре процесса работы с информацией, без которых ИИ остаётся генератором красивых ответов. • Машиночитаемый формат - почему отчёты надо собирать под модель данных. • Human in the Loop - почему без человека машина деградирует. • Выравнивание стыков процессов - где у ИИ самый недооценённый эффект. • Туннелирование между коллабораторами - как обмениваться материалами внутри команды, не ломая друг другу контекст. Каждая из этих тем заслуживает внимания. Сейчас подробнее про CORD: это базовая конструкция, без которой остальное не складывается. Чтобы думать с ИИ, нужны четыре класса процессов работы с информацией: Collect, Organize, Review, Do. Collect - как сигнал вообще попадает в систему. Голосовые заметки, заметки от руки, выделения в читалке, RSS-сводки, расшифровки встреч, прямая подгрузка статей и документов. У меня этим занимается отдельный класс агентов-проходчиков: они забирают сигнал из источников по своему расписанию, размечают и кладут в систему. Organize — куда сигнал ложится. Работает через модель PARA Тиаго Форте. • Projects - то, что начинается и кончается. • Areas - зоны ответственности: маркетинг, продажи, HR. У этих нет даты окончания. • Resources - инструменты, базы, библиотеки. У каждого свои метрики качества использования. • Archive - всё прошлое. Это не свалка: на основе архива у меня живёт «довод-менеджер», который классифицирует новые проекты по двенадцати архетипам и присылает прогноз из архива: «на седьмой день вы упрётесь в стену — на похожих проектах вот тут стало больно, исправляй сейчас». Review - когда возвращаемся к данным. Проекты - ежедневно, области - раз в три дня, ресурсы - раз в неделю. У меня каждый вечер идёт «закрывашка»: проверка проектов с разной степенью детализации. Скиллы и агентов отдельно раз в неделю прогоняю с вопросом «что уже можно улучшить на основе того, что мы делали». Do - когда сигнал становится действием. Машина пишет задачи в базу. Команда делает, машина читает статусы и сигналит, если давно ничего не двигалось. Закрывашку я записываю на аудио, машина закрывает выполненное и ставит новые задачи. Петля замыкается на действии. Если хотя бы один из четырёх процессов не заведён, всё ломается. Без Collect нечего обрабатывать. Без Organize всё сваливается в кучу. Без Review данные устаревают. Без Do всё остаётся разговором. Это рамка, в которую дальше встраиваются и машиночитаемый формат, и HITL, и выравнивание стыков, и туннелирование. В ближайшие недели буду разбирать по одной теме. А если пропустили наш интенсив, тут можно купить запись: https://xn----itbbmgpihhfjo1e9bbj.xn--p1ai/programs/ai-v-biznese#price

Координационное трение Эффект ИИ обычно считают в сэкономленных часах: задача делалась за три часа, теперь за один. Это видимая и небольшая часть. Куда больше времени уходит между задачами — на их стыковку. Это и есть координационное трение: пока работа переходит с этапа на этап и из рук в руки, время утекает на склейку. Координационное трение почти не видно в отчётах: оно размазано по стыкам. Каждый человек занят делом, а время утекает в промежутках между делами. Простой пример. Раз в неделю у меня совещание по контрольной вышке. Codex сам собирает к нему повестку: проходит реестры, вылавливает отклонения и противоречия, ставит встречу в календарь, присылает приоритеты. Я прихожу готовым и за час принимаю 17 решений. Сами решения — это минуты. Без машины день ушёл бы на то, чтобы собрать повестку руками: вспомнить, кто что писал, найти, где это лежит, свести, что изменилось. На что уходит время между задачами. • Поиск. Где лежит нужный файл, в каком чате это обсуждали, какая версия свежая. • Повторное вникание. Каждый, кто берётся за задачу, заново поднимает её историю. • Передача из рук в руки. Передал работу другому — и контекст пересказываешь заново. • Сверка. Что изменилось со вчера, кто теперь владелец, какое правило тут действует. Что тут делает машина. Она не просто пишет быстрее. Она убирает саму склейку: находит файл, сверяет правило, обновляет запись, показывает, что изменилось. Поиск, сверка и пересказ уходят из дня. Старшие и партнёр перестают руками собирать контекст и занимаются проверкой и решениями. Признак, что трение осталось. «ИИ внедрили, а легче не стало». Если ИИ воткнули в готовый процесс точечно, он сел поверх трения: отдельные задачи ускорились, а встреч, пересылок и вопросов «где это лежит» меньше не стало. Как это измерить. Перестать мерить сэкономленные часы на задаче. Посчитать, сколько на маршруте передач, согласований и повторных вниканий, и снять это число до и после ИИ. Его падение и есть настоящий эффект. Поэтому обычный бот трение не убирает: он встаёт на один стык, а склейка на всех остальных остаётся. Трение уходит, когда весь процесс собран машиночитаемым: контекст лежит в общей памяти (это озеро), а работа идёт по заранее проложенному маршруту (это рельса), и машина ведёт её сама, без ручного сведения на стыках. Тогда стыки исчезают как класс. Это и есть техническая аугментация операционной модели: трение снято по всей системе, и от этого растёт её пропускная способность. Ускорение одной задачи такого не даёт.

Скафолдинг без когнитивной стратегии Скафолдинг(от scaffold - строительные леса) — это подпорки, которыми обкладывают работу сотрудника, чтобы он выдавал больше: ИИ-ассистент, шаблоны, готовые пайплайны. Сам по себе он полезен. Опасен скафолдинг, когда даётся без когнитивной стратегии — без алгоритма рассуждения, который человек понимает и может проверить. Тогда подпорки заменяют мышление вместо того, чтобы его усиливать. Когнитивная стратегия — это как именно специалист приходит к выводу: какие данные берёт, в каком порядке думает, где себя проверяет. ИИ должен её копировать и ускорять. Подменить её скафолдингом нельзя. Самый известный разбор этой ошибки — один из крупнейших мировых консалтингов, годами вкладывавший в собственного ИИ-ассистента. Замысел понятный: ИИ как скафолд для младших, средние меньше времени на проверку, старшие больше продают. Вышло ровно наоборот, и по шагам. Как рушится пирамида. • Младшие работают бездумно. Со скафолдом они перестают думать и начинают впихивать в ИИ ворох сырых данных. Когнитивная стратегия не нарабатывается. • Результат нельзя интерпретировать. Младший не может интерпретировать то, что выдала машина: он не строил цепочку рассуждения и не видит, где она поехала. • Средние уходят в бесконечный QA. Проверять приходится парсоновский чёрный ящик — чтобы понять, верно или нет, надо ломом вскрыть чужую цепочку. Тяжёлые стратегии, скопированные в скафолд, даже среднему неинтерпретируемы. • Партнёры начинают заниматься не своей работой. В QA уходят и старшие — работа, от которой когда-то отошли. Пирамида seniority схлопывается. Дальше парадокс. Средний с ИИ делает работу в десять раз быстрее младшего без ИИ. Возникает соблазн разогнать младших. Но младшие — это будущие старшие. Убрав их, компания теряет преемственность на 20–30 лет и стреляет себе в ногу. Признак скафолдинга без стратегии. «Стали быстрее, но проверять стали дольше». Если старшие вычитывают всё дольше вместе со скоростью младших, значит выдаётся выход, который никто не может прочитать. Скорость купили QA-долгом, и он всплывёт. Как правильно. Сначала вынуть когнитивную стратегию специалиста: как рассуждает, где проверяет, где останавливается. Отдать её ИИ как алгоритм рассуждения. Просьба «сделай красиво» этого не заменит. Нужно научить младшего оценивать результат и держать semantic ownership. Скафолд усиливает того, у кого когнитивная стратегия есть. У кого её нет — отнимает и остатки. Ну а мы напоминаем про интенсив по ИИ, который стартует уже завтра. Регистрация ➡️ https://скрытые-чемпионы.рф/programs/ai-v-biznese

Процессы, собранные под ИИ Почти все встраивают ИИ в существующие процессы: тут бот, там агент. Процесс остаётся прежним, вставки работают каждая сама по себе, между ними те же ручные стыки. Так процесс не умнеет, он становится дырявым. Правильный маршрут - собрать процесс машиночитаемым с самого начала: каждый вход, артефакт и сущность сразу в единой модели данных. Машиночитаемость — это когда у каждой единицы работы есть структура, статус и место, и система читает их без человека-посредника. Держится это на двух опорах. Озеро - нормативная память: реестры, правила, параметры. Рельса - производственный маршрут со входом, гейтами. Между ними замкнута петля: выход рельсы возвращается в озеро, озеро задаёт норматив следующему прогону. Самое тонкое место - вход в озеро. Свободный текст превращает его в свалку. Поэтому инжест нормируется через шаблон под модель данных: на входе данные уже структурированы(она просто не пропустит вброс от вас в формате "не нравится", так как это не положить в правило). А если модель описана машиночитаемо, шаблон собирает сама машина. Тогда и нового человека/проект/задачу система заводит иначе: сразу собирает карточку под модель данных - роль, связи, проекты, доступы. Дальше задачи, права и передачи по нему складываются сами, ведь его данные с первого дня читают все рельсы. Это и есть техническая аугментация операционной модели. Это пересборка самой работы под машину, инструменты поверх неизменного процесса так не работают. Условие одно - усилить можно только описанный процесс: поверх хаоса озеро станет свалкой. Строить нужно процессы, заранее собранные под ИИ. Тогда встраивать его никуда не придётся:)

«Хотим ИИ» это ещё не потребность Рынок устроен так: все хотят ИИ, и всем говорят, что они хотят ИИ (все как в меме). Подрядчики, вендоры, статьи, конкуренты повторяют одно и то же. Собственник слышит это со всех сторон и приходит с запросом «нам тоже нужен ИИ». Управленческой потребности за ним пока нет. Если на таком запросе сразу начать внедрять, получается то, что мы регулярно видим на старте проектов: дашборд поверх хаоса, пилот на неготовых данных, бот, про который через неделю забывают. Между «хотим ИИ» и работающим ИИ лежит долгий процесс. Большинство пытается взять её одним прыжком от моды к внедрению. Сессия по применению ИИ нужна, чтобы пройти этот путь. Ступени, которые мы проходим на сессии. • От «хотим ИИ» к «где именно его внедрить». Раскладываем бизнес по цепочке создания ценности на 11 категорий процессов. ИИ не появляется «в компании». Он появляется в конкретном процессе. • Оценка пригодности. По каждому кандидату считаем AI-ready: эффект (где влияет на деньги, скорость, качество), готовность (есть процесс, данные, владелец), внедряемость (можно запустить пилот без расползания IT-контура). • Пять уровней зрелости. Процесс ставится на лестницу L1-L5: хаотичный, повторяемый, описанный, управляемый, оптимизирующий. ИИ подключается с L4. На L1-L2 модель учит на шуме. Перепрыгнуть нельзя: процесс на L2 сначала описывают и измеряют, потом подключают ИИ. • Класс решения. Под пригодный процесс подбираем один из пяти классов: автоматизация по правилам, предиктивная аналитика, распознавание, генеративные модели, поддержка решений. Половине запросов «хотим ИИ» на деле нужен low-code или workflow, модель там лишняя. На выходе сессии конкретные артефакты: карта зрелости процессов, матрица «процесс × класс решения», прототип на одном готовом процессе и дорожная карта на 90 дней, которую можно защищать перед советом директоров. «Хотим ИИ» можно закрыть за неделю красивым внедрением, которое создаст проблемы. Нормальные работающие прототипы можно собрать за две, но с предварительной проработкой

Путь задачи Задача не существует, пока не прошла полный маршрут: от встречи через файл проекта до базы задач с отметкой приёмки. До этого момента это формулировка в чьей-то голове. Маршрут универсальный. У меня это Markdown + Airtable. У вас может быть Notion + Jira, Google Doc + Asana, любая пара «черновик — исполнительный контур». Вчера разбирали проект. На встрече прозвучало 11 задач. Транскрипт через MCP ушёл в Codex, тот разнёс пункты по файлу проекта. К утру я открыл Airtable: доехало 5, застряло 6. Codex прошёлся по списку разрывов — задач из файла, у которых нет кросс-записи в базе. За одним пунктом стояло 5 отдельных задач — разнёс их по одной. Другой совпал с задачей из вчерашнего разбора, снял как дубль. Три отложил с конкретной датой возврата. Маршрут задачи: пять обязательных шагов. • Сборка смысла. Задача отделена от обсуждения, переформулирована в действие. • Атрибуция. У задачи есть владелец, срок и тип выхода: документ, решение, артефакт. • Запись в файл проекта. Первичная фиксация: статус «открыта», ссылка на источник. • Мост в базу задач. Кросс-запись с отметкой приёмки: доехала, в разрыве или дубль. • Контроль исполнения. Цикл проверки: кто что сделал, что зависло, что переоткрыто. Под капотом это BPMN-поток с пятью гейтами. Между шагом 03 и 04 стоит человеческий шлюз(HITL): машина не пишет в базу без явного «да». Разрывы между файлом и базой каждый час сканирует проходчик-исправитель ошибок, который не делает работу сам, а подсвечивает то, что не доехало. Признак фейкового исполнения. «У нас 200 задач в Notion». Это формулировки, а не задачи. Реальное число это то, что доехало до базы задач с подтверждением приёмки. Разница обычно в 2-3 раза. Алгоритм проверки маршрута. Открыть случайный проект. Взять последние 10 задач из файла проекта. Найти в базе. Нет в базе — разрыв на шаге 04. Нет владельца / срока / типа — разрыв на шаге 02. Дубль — закрыть, без действия. Если AI ведёт длинный список задач в одном месте, это свалка. Если проводит каждую через маршрут с гейтом приёмки, это операционная управляемость по логике Adaptive Case Management: задача это не строчка в таблице, а кейс со шлюзом приёмки.

AI должен сокращать не людей, а ручной труд старших сотрудников Вокруг AI часто возникает простой вопрос: можно ли с его помощью сократить людей? (Особенно в ПСФ - профессиональные сервисные фирмы - консультанты/юристы/аудиторы). Но главная проблема часто не в том, что в компании слишком много людей, а в том, что слишком большая часть функций держится на ручном труде сильных старших. Здесь AI становится интересен не как замена сотрудника, а как способ снизить зависимость выдачи продукта от ручного старшего труда. Правильный объект управления — не «сколько людей после внедрения», а senior review load. Senior review load — измеряемая величина. Часы в неделе старшего на правки чужих текстов, повторную сборку, ответы на однотипные вопросы, поиск в архиве. Признак фейковой AI-автоматизации — старший продолжает править всё, что выходит из системы. Что сделать прямо сейчас: Замерить senior review load. Найти(с помошью вашего "друга" - Кодекса или Клода) повторяемую операцию. Описать стандарт качества, который работает без автора. Перенести в скилл с человеческой проверкой. Через месяц замерить снова.

Обещали на первом вебинаре второй — делаем второй :) На прошлой неделе мы в основном говорили про то, как устроена ИИ-система в управлении компанией. Теперь спускаемся на уровень конкретных бизнес-процессов. Тема: «Как внедрять ИИ в бизнес-процессы: реальные кейсы, ошибки и первые управляемые сценарии» Регистрация Разберем способы внедрения ИИ: от бизнес-процесса к сценарию, от сценария к пилоту, от пилота к управляемому контуру. Поговорим о том: • как выбирать процессы для внедрения ИИ; • как понять, готов ли процесс к автоматизации; • где ИИ и low-code дают эффект в деньгах, скорости, качестве или клиентском опыте; • почему незрелый процесс с ИИ масштабирует беспорядок; • какие ошибки чаще всего ломают пилоты; • как запускать первые сценарии так, чтобы они не умерли через два недели: • как реальные инструменты внедрения работают на примерах наших проектов. Второй вебинар будет уже дискуссионным. Можно приходить со своими наработками, процессами и вопросами. Также покажем реальные кейсы Paper Planes: закупки, продажи, маркетинг, сервис, HR, финансы и управленческие процессы. Разберём не абстрактные «нейросети вообще», а конкретные инструменты и сценарии, которые уже применялись в проектах. Регистрация Подробнее о вебинаре

Машина должна уметь ошибаться правильно Зрелый AI-помощник ценен тем, что превращает ошибку в управляемое событие: видит её, называет, исправляет, записывает в правило. Вчера вечером Codex должен был дописать строки в базу задач по итогам утреннего обсуждения. К утру я заметил, что таблица пустая, запись не дошла до базы. Раньше бы я полез править руками или просить машину поправить конкретную строку. На тезис «вот тут пусто, проверь» Codex развернулся и пошёл по своему маршруту с конца в начало. 01. Самопроверка. Зашёл в базу, прошёл по последним запускам и локализовал причину отказа: запись оборвалась на последнем шаге, данные были подготовлены, но в базу не ушли. 02. Обходной путь. Починил ошибку ручно. Параллельно отметил факт сбоя в журнале инцидентов. 03. Проверка «источника правды» (single source of truth). Прошёл по диску, убедился, что исходные данные на месте. Сбой ограничился слоем обратной записи. 04. Обновление локального канона. Записал правило: если запись в базу падает, в первую очередь проверить доступ, дописать недостающие строки через входящий буфер руками, отметить инцидент в журнале и обновить статусы. Положил правило в файл, который Codex читает перед запуском. Единичная правка сразу закрепилась как правило в локальном каноне Codex. Сам сбой Codex зафиксировал в реестре недостатков системы, и на ближайшей контрольной вышке мы пройдёмся по нему руками: разберём, что ещё в маршруте могло привести к этой остановке и стоит ли пересобирать архитектуру обратной записи. Также у меня есть регулярные процедуры проверки "здоровья" системы и оценки всего, что должно стать правилом. Об этом расскажу на вебинаре и интенсиве.