Lean-Agile Компания

Как управленческий харнесс противостоит усталости от изменений Добрый день, на связи Алексей Ионов. Принято считать, что изменения – это всегда хорошо, и чем их больше, тем лучше. Я с этим не согласен. Изменения не бесплатны, и когда их слишком много, они начинают вредить. Человек приходит в организацию с негласным контрактом: я делаю работу, по понятным правилам, в понятной системе – и получаю за это результат, самореализацию и оплату. Когда структура, роли, подчинение, отчётность и ритуалы постоянно перестраиваются, контракт рушится. Энергия уходит не на создание ценности, а на адаптацию к очередной трансформации. Сопротивление бывает открытым – люди спорят и не соглашаются. Но хуже другое: пассивное ожидание. Внешне всё нормально – люди на местах, встречи идут, задачи закрываются. А внутри человек уже отключился и ждёт, когда «и это пройдёт». Организация этого не замечает, а цели трансформации не достигаются. Первая мысль – заменить уставших: «возьмём других с рынка». Но на рынке – люди из таких же организаций, уставшие от таких же изменений. В итоге нанимается не мотивация, а её демонстрация. Что делать? Сделать изменения управляемыми. Остановить их нельзя – мир ускоряется. Настоящая гибкость возникает не из отсутствия ограничений, а из небольшого набора правил, которые не нарушаются. Построить их можно на основе Lean-Agile подходов: потоки ценности, ключевые роли, короткие циклы, способы постановки задач и принятия решений. Набор таких правил я бы назвал управленческим харнессом. Внутри него могут меняться продукты, клиенты, приоритеты и цели – а управленческая логика остаётся понятной. Перед следующей реорганизацией задайте три вопроса: – Где происходят изменения: в создаваемой ценности или оргструктуре? – Есть ли экономический смысл в этих изменениях? – Как через один цикл работы мы поймём по данным, а не по декларациям, что цели изменения достигнуты? Если ответов нет – реорганизацию стоит пересмотреть. Изменения должны быть частью бизнеса, а не непроходящим стрессом.

Когда AI-инициативу нужно остановить – и почему это не провал Добрый день, на связи Алексей Ионов. В AI-Native организации много инициатив останавливаются. И это нормально. ИИ расширяет возможности экспериментов. Но не каждая гипотеза должна стать продуктом, а пилот – дойти до масштабирования. Эксперимент нужен, чтобы понять: где есть ценность, а где её нет. В Lean-Agile мы давно говорим об обучающейся организации. В AI-Native это условие жизнеспособности. Если за неподтверждённую гипотезу ищут виноватых – организация перестаёт учиться. Реальный провал – не остановить инициативу, а продолжать тратить деньги, внимание лидеров и энергию команд на неподтверждённую гипотезу: потому что «мы уже начали», сделали красивое демо или кто-то пообещал результат. Пилот должен начинаться не с вопроса «что мы можем сделать с технологией?», а с вопроса: какой экономический эффект хотим получить для клиента, бизнеса и процесса? До старта важно договориться о метриках и возможных решениях: масштабировать, дорабатывать или останавливать. На разборе пилота я бы задал четыре вопроса: – Есть ли измеримый эффект, а не просто красивое демо? – Понятна ли экономика следующего этапа: интеграция, контроль, поддержка, риски? – Ограничение устраняется доработкой – или лежит в данных, процессе, ответственности, организационной модели? – Какие знания, данные и компоненты мы уже получили и зафиксировали? Не стоит путать технологические и организационные ограничения. Часто проблема не в качестве модели: данные не подготовлены, процесс не определён, владелец не назначен, метрика не связана с потоком ценности. Закрытая инициатива – не потеря, если мы отработали гипотезу, получили знания, а людей направили на возможность, развивающую полученные компетенции. Задача лидера – сделать такую остановку безопасной: не искать виноватых, а помогать компании быстрее получать знания. Зрелость AI-портфеля измеряется не количеством пилотов, а качеством решений: что масштабировать, что дорабатывать и что вовремя прекращать.

Работающая LLM ещё не означает результат для бизнеса Добрый день, на связи Алексей Ионов. Представьте B2B-компанию. Менеджер готовит коммерческое предложение около 2 часов. Техническая команда показывает демо: подключаем LLM – и черновик готов за 15 минут. Руководство выделяет бюджет, решение внедряют. Но менеджеры по-прежнему тратят на предложение 2-3 часа. Почему? Предложение – не только текст: нужно проверить наличие оборудования, данные клиента, цены и сроки, согласовать условия. Мы ускорили написание текста, но не изменили путь от запроса клиента до корректного предложения. Поэтому до внедрения важно спросить: что должно измениться в работе, чтобы клиент получил предложение быстрее? Например: получать нужные сведения в начале, пересмотреть согласования и определить, где ИИ готовит черновик, какие решения менеджер принимает сам, а какие требуют подтверждения – особенно если ошибка в цене, сроках или комплектации слишком дорога. Метрика – время от запроса клиента до отправки корректного предложения, а не скорость подготовки черновика. Сокращение этого срока – не обещание LLM, а гипотеза для проверки. ИИ повышает требования к данным, полномочиям, контролю и ответственности. Именно здесь возникает отдельная ответственность: связать бизнес-цель, изменения в процессе, роль ИИ и измеримый результат. Эту ответственность в AI-Native подходе берёт AI Value Architect – Архитектор ИИ-ценности. В небольшой инициативе эту ответственность может взять на себя один из лидеров. Но когда задействованы продажи, закупки, склад, финансы, ИТ и безопасность, нужна отдельная работа по согласованию изменений в сквозном потоке. Перед запуском AI-инициативы задайте три вопроса: – Какой результат должен измениться? – Что должно измениться в работе и правилах принятия решений? – Кто отвечает за связь этих изменений? Подробнее о роли AI Value Architect: ionovpartners.ru/...afe

Как выбрать точку входа в AI-Native трансформацию Добрый день, на связи Алексей Ионов. На прошлой неделе я писал о дорожной карте внедрения AI-Native SAFe. Она показывает путь изменений, но оставляет вопрос: с чего начать? Lean-Agile и SAFe ускоряют изменения, но не определяют точку входа. Она зависит от того, какую ценность организация хочет создать или какую проблему решить. Распространённый сценарий – купить инструмент, открыть доступ сотрудникам, провести обучение и запустить несколько «модных» кейсов. Всё это необходимо. Но само по себе не гарантирует бизнес-результат. Инструменты, обучение и новые роли должны поддерживать трансформацию, а не заменять её смысл. Точкой входа должен стать заметный бизнес-эффект, создаваемый конкретным потоком ценности. Я бы искал такую точку на пересечении пяти признаков: 1. Есть заметная проблема или возможность. Например: потери в процессе, слабый клиентский опыт, длительный вывод продукта на рынок или недостаточное качество стратегических решений. 2. Понятен ожидаемый бизнес-результат. Не «внедрить AI-ассистента», а повысить удержание клиентов, выручку или маржинальность продукта, сократить стоимость операций или ускорить вывод продукта на рынок. 3. Есть владелец результата. Лидер, который может менять процесс и отвечает за бизнес-результат, а не только за запуск технологии. 4. Можно зафиксировать исходную точку. Иначе эффект изменений не оценить. 5. Доступны данные и контекст. Без курированных корпоративных знаний даже сильная модель даст лишь усреднённый результат. Если эти условия сходятся в одной области бизнеса – вероятно, вы нашли правильную точку входа. На старте особенно важно не распыляться: один правильно выбранный бизнес-эффект в конкретном потоке ценности полезнее десяти несвязанных экспериментов. AI-Native трансформация начинается не с инструмента и не с фреймворка. Она начинается с работы, которую нужно улучшить, и результата, который можно измерить. #AINativeSAFe #AINative #ionovpartners