Внедрение ИИ в компании: почему команда не может оценить результат

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

01Дилемма атрибуции

В основе того, на чём буксует внедрение ИИ, лежит одна операция, которая изнутри не выполняется. Чтобы понять своё положение, команде нужно атрибутировать — отделить ограничение объекта от ограничения собственной позиции. И именно этого она сделать не может, потому что у неё нет внешней шкалы, относительно которой такое разделение проводится. Мы называем это дилеммой атрибуции. В классическом обучении и в зрелых ИТ-категориях у любого процесса есть знаемая верхняя граница, относительно которой можно понять, достигли мы запланированного результата или нет. В ИИ верхней границы изнутри не видно, она быстро меняется и известна узкому кругу практиков.

У дилеммы два проявления — по двум типичным стадиям внедрения, — и различаются они тем, насколько конкретен объект, ограничение которого надо отделить от собственного.

На стадии теста инструмента (платформа уже выбрана, команда несколько месяцев с ней работает) объект конкретный — вот этот инструмент. Команда получает какой-то результат и не может ответить на два связанных вопроса. Исчерпывает ли этот результат возможности инструмента, или мы видим малую часть? И если результат не устраивает — это потолок инструмента или мой потолок, я просто не дожал? На конкретный объект и сомнение проецировать легче.

На стадии выбора платформы объекта ещё нет — есть «ИИ вообще», классы платформ, траектория сферы. Здесь та же невозможность развести объект и себя, но проецировать вовне не на что, и сомнение возвращается к себе: знаю ли я свой запрос, достаточно ли я его сформулировал, правильная ли у меня оптика — понимаю ли я, как сегодня вообще мыслят процессы через ИИ. Это та же дилемма, просто чем абстрактнее объект, тем больше сомнения летит в самого спрашивающего.

В обоих проявлениях внешней шкалы у клиента нет, и без неё запрос не формулируется. «Предложите, а мы посмотрим» — не уклонение, а закономерный ход в этой ситуации. И — забегая вперёд — у дилеммы есть способ ослабления, к которому мы вернёмся на установочной сессии: зайти не от инструмента (чьи границы не видны), а от боли (которая известна, причем известна лучше всего самому сотруднику, и не требует внешней шкалы).

Дилемма работает в две стороны. С одной — подталкивает к внешнему эксперту. С другой — блокирует его: а вдруг мы и так всё сделали правильно, и эксперт окажется тратой денег. Клиент сомневается не в том, чем эксперт будет полезен, а в том, будет ли полезен в принципе. Здесь же — менее очевидный полюс с другой стороны: даже опытный эксперт извне, без погружения в работу людей, не всегда может сходу сформулировать, чем он будет полезен. На снятии запроса наш собственный эксперт честно сказал «надо подумать».

Это нормально и важно — и важно ровно потому, что описывает структуру задачи, а не недостаток эксперта. В ИИ-внедрении знание, нужное для пользы, физически распределено между двумя сторонами: эксперт по ИИ знает, какие есть инструменты, что они могут и как из их возможностей создавать комплексные инструменты; профильный специалист в команде клиента знает, что в его работе на самом деле делается, как, с какими ограничениями и где болит. Сборка пользы происходит во встрече, не до неё. Никто не может сказать маркетологу или геологу, как ему лучше внедрить ИИ в свою работу, лучше, чем он сам — но он не может это сформулировать без второй половины знания, той, что у эксперта по ИИ. Из этой структуры следует и форма контракта, и почему классические форматы продажи экспертизы здесь не работают.

02Как дилемма проявилась в описанном кейсе

Январь 2026 года. Тренинг-менеджер представительства международной энергетической компании в России знакомится с нами на онлайн-встрече, описывает план: ждёт корпоративный ИИ-инструмент от IT, на старте нужно базовое обучение, которое хотели проводить через доступ к нашему курсу “Нейросети для бизнеса”. Через неделю — вежливый отказ: дополнительные платформы внутри не одобрили, политика партии. Этот отказ — не про нас и не про дилемму: у клиента в этой точке есть понятный план и корпоративные ограничения.

С февраля по май IT-департамент клиента запускает собственный пилот: восемь человек из семи функций — HR, юристы, IT, финансы, коммуникации, геология, транспорт — еженедельно тестируют семь модулей Яндекс 360. К концу марта у группы — большой документ с пробами; в конце мая запланирована презентация для всех сотрудников. Снаружи — образцовая работа.

Клиент попадает на нашу конференцию. Через несколько дней приходит письмо: «Хотели бы обсудить привлечение эксперта для оценки применимости и внедрения ИИ». На встрече по снятию запроса IT-руководитель за двадцать минут подробно описывает, что делают: модули, сценарии, критерии оценки. Позиция отчётливая — «личная эффективность, не процессы», «категорически против чат-ботов – нельзя закрываться ими от коллег», «облако вместо своих серверов». И ровно в этой ясности — провал: к концу встречи клиент так и не сказал, чего хочет от нас. Финальная реплика:

«Готовьте ваше предложение. Какие ваши ожидания, с какой суммы вы готовы стартовать?»

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

03Форма контракта как ответ на структуру проблемы

В крупном B2B у клиента, оказавшегося в дилемме атрибуции, есть типовые способы снизить риск входа: бесплатная диагностика, пробный доступ, гарантия возврата. В этом сегменте они работают плохо по разным структурным причинам. Бесплатное в восприятии корпоративного отдела закупок попадает в категорию «несерьёзное», при этом бюрократия по NDA и инфобезу остаётся той же. Гарантия возврата возмещает деньги, но не время людей внутри клиента, а в крупном B2B время людей и есть основная статья затрат. Поэтому же и пробный доступ работает только когда ценность очевидна заранее, хотя всё равно пугает перспективой допродажи.

Поэтому мы предложили клиенту другой формат входа — короткую живую сессию с практиком, в которой за полтора-два часа становится видимым диапазон возможностей, который изнутри не виден. Мы называем этот формат ИИ-разговор: это не пробник, не диагностика и не вступительный модуль обучения, а формат со своим артефактом. Команда выходит из сессии с пересобранным пониманием того, где она находится; и здесь же точку получает сам эксперт — он впервые “материально” (прикоснувшись к процессам), а не “идеально” (гипотетически) видит, где компания. Из этой точки трек дальнейшего движения разворачивает не эксперт в одиночку — над ним уже сразу могут работать все участники; эксперт дальше помогает двигаться по нему увереннее. Сборка двусторонняя: понимание появляется у обеих сторон одновременно, а не транслируется от эксперта к клиенту. Дальше, если этого достаточно, команда работает самостоятельно. Если нужна более глубокая сборка — переходит в следующий формат, со-внедрение, в котором мы и сделали с клиентом основную работу. В этой конструкции три принципиальных свойства, и каждое работает не как механика упаковки, а как ответ на конкретный фрагмент дилеммы.

Первое: каждый формат оставляет у клиента артефакт, который можно масштабировать нашими руками, силами другого подрядчика или внутренними ресурсами. Клиент платит не за «попробовать оценить» и даже не просто за «получить нечто в собственность», а за встроенную диспозицию мыслить свою работу через ИИ — то, что остаётся в команде, когда конкретный инструмент и конкретный артефакт давно сменились.

Второе: лестница расширения видна заранее. Клиент покупает не только конкретную сессию с её непосредственным результатом, но и знание о пути и следующих шагах — без привязки к исполнителю, инструменту и подрядчику. Это не снимает блокировку «а вдруг эксперт окажется тратой денег», но ослабляет её - клиент овладевает картой, по которой может выйти из одной истории и войти в другую.

Третье и главное: формат даёт клиенту точку, из которой он может пересобрать свой собственный запрос. До первой сессии клиент не знает, нужен ли ему эксперт и для чего, после — знает. У клиента появляется внешняя точка, из которой становятся различимы два разных способа смотреть на инструмент — «инструмент → применение» и «боль → инструмент». Эксперт не транслирует «правильный» способ — он показывает, что способов больше одного, и с командой определяется, какой для какой задачи подходит. Почему второй способ открывает то, чего не видно из первого, разворачивается дальше, на установочной сессии.

Здесь же замыкается ход про распределённую экспертизу, о которой шла речь выше. Раз знание, нужное для пользы, распределено между двумя сторонами и собирается во встрече, лестничный формат — не маркетинговый ход, а одна из немногих адекватных форм ответа: обе стороны входят ровно настолько, насколько готовы, и расширяются по мере того, как польза становится видимой. Эксперт, который приходит и говорит «я точно знаю, чем буду полезен», в категории ИИ-внедрения либо продаёт стандартизированный продукт (который в этой категории, по крайней мере пока, не работает), либо лукавит. Эксперт, который говорит «надо подумать», ведёт себя профессионально — он не претендует на знание контекста, которое во многом появляется только во встрече с командой.

В нынешнем моменте сферы это распределение становится императивом. Немного ранее «знание ИИ-инструмента» ненадолго было статической компетенцией: надо было либо уметь писать промпты — инструкции, заставляющие модель выдать качественный результат, либо подсмотреть их у кого-то. Промпты тиражировались как ноу-хау, на какие-то даже заявлялись права интеллектуальной собственности, продавались сборники. Сейчас, с распространением агентских режимов внутри платформ типа ChatGPT и Claude (codex, claude code), многие автоматизации, для которых ещё недавно нужна была отдельная платформа для сборки без программирования (часто всё же с примесью кода), делаются прямо в чате — нужно только корректно изложить процесс и образ результата; дело доходит до создания приложений под себя прямо на ходу. Ключевая компетенция сместилась из промптов в рефлексивный взгляд на собственную работу. То, что делает агента возможным, — это не знание агента или программирования, а знание того, как устроено то, что мы хотим автоматизировать. Это знание физически лежит в команде клиента. Поэтому лестничная форма структурно соответствует тому, где сейчас находится ключевая компетенция.

Клиент согласовал ИИ-разговор.

04Сцена первая: ИИ-разговор в действии

Установочная живая сессия с пилотной группой. Восемь человек инициативной группы, наш эксперт — Елена.

Дошли до модуля нейросапорта. IT-руководитель пропустил: «Не видим смысла дальше углубляться, у нас просто нет задач». Елена задумалась: «А внутреннюю поддержку вы не рассматривали? Сотрудник хочет взять отпуск, спрашивает по каким правилам — вместо того чтобы дёргать HR». В кадре подняла руку HR-менеджер: «Прошу прощения, расскажите больше про этот продукт. Это прекрасный продукт, зачем нам чат-бот крутить, если такой продукт уже сделан? У меня мозги уже набекрень от этого, от чат-бота».

Выяснилось, что HR-менеджер два месяца руками прописывала вопросы и ответы для будущего внутреннего чат-бота. Елена за две минуты показала, что нейросапорт умеет работать с базой документов напрямую — заливаешь политику отпусков, и он отвечает по ней.

Этот эпизод нельзя прочитать как «глупый клиент, умный эксперт». HR-менеджер делала качественную работу с измеримым прогрессом. IT-руководитель в той же команде в это же время уверенно говорил, что передавать работу чат-ботам не желательно, чтобы не закрываться от коллег безжизненными программами. Они в одной комнате — и у них нет общей картины применимости инструмента. Это разворот дилеммы между командой и внешней шкалой возможностей: команда не видит, что платформенный инструмент уже умеет делать ровно то, что HR-менеджер пытается в другом месте заставить его сделать . Здесь внешний практик работает прямо: даёт ту шкалу, которой у команды нет. В конце сессии тренинг-менеджер сказала: «У меня вообще мир разделился на до и после».

05Когда клиент сам пересобирает запрос

Через несколько дней после установочной сессии клиент написал нам — с желанием расширить программу до следующего формата, со-внедрения. Из старой точки переход в следующий формат выглядел бы как «потратить ещё деньги на непонятную услугу». Из новой — «совместно сделать следующий шаг по уже начатой и видимой траектории». Дилемма тут не снимается совсем — как структурное свойство она остаётся, — но перестаёт блокировать: клиента приводят в точку, из которой он сам отвечает на свой собственный вопрос.

И — что важно для конструкции пакета — переход ИИ-разговор → со-внедрение здесь не появляется как необходимость продолжения обучения. ИИ-разговор сделал свою работу полностью: для команды, у которой запрос за одну сессию закрылся, на нём всё и закончилось бы — и это нормальный итог формата. Лестница работает в обе стороны: она открывает следующий шаг, но не делает его обязательным.

06Сцена вторая: со-внедрение в действии

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

В разговор вмешалась коллега из соседнего отдела: «Слушай, а мне кажется, зря ты так. У нас тоже есть документ, который мы каждый год обновляем — база прошлогодняя, и нам нужно вычитывать и менять её руками. А что если просто накидать список изменений, и ИИ бы сам по логике нашёл, куда вставить, и вставил — а мы только вычитываем? Почему нет?»

Финансовый менеджер согласилась: «Спасибо, что сформулировала. Я думала: вот боль есть, а как её решить с помощью машины — не знаю».

И только после этого Елена достала заранее заготовленную цитату Валерия Бабушкина: «Если у вас в руках есть молоток, всё вокруг внезапно превращается в гвозди». Когда команда идёт от инструмента, она видит свои задачи только сквозь призму того, что инструмент уже умеет в её представлении. Возможности, выходящие за это представление, остаются трудно различимы — не от халатности, а потому что можно не найти вопроса, который их откроет, можно побояться его задать, можно не понимать, как его отработать. Финансовый менеджер сама заранее списала свою боль как «не для ИИ» — это и есть точка, в которой структурный дефект инструменто-центричной методики проявляется наружу. Афоризм Бабушкина здесь сработал постфактум, как имя для уже произошедшего, не как методическая рамка, которую эксперт принёс с собой.

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

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

Здесь же эксперт работает не как носитель шкалы — он работает как медиатор. И в двух смыслах сразу: тот, кто помогает людям внутри команды говорить друг с другом (медиация в коммуникации - Елена настояла, чтобы менеджер развернула боль, даже когда та сама её отбросила), и тот, кто помогает говорить не об инструментах и их применении, а о приложении инструментов к болям (медиация между технологией и профильной практикой). Активный жест переходит к команде: задачу разворачивает не Елена, а коллега из соседнего отдела. Елена создаёт сцену, на которой может состояться сдвиг способа мышления в перспективе ИИ.

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

07Формат в трёх тактах и два входа в систему

Если назвать такты по именам, видно, что обе сцены выше — это они в работе. Оптика — живая сессия, на которой снимается разворот между командой и внешним миром (установочная сессия с нейросапортом). Матрица — структура, в которую оптика перекладывается (задача → процесс и его этапы → метрика → инструмент): здесь снимается разворот внутри команды, потому что в матрицу попадают и задачи, заранее списанные отдельными людьми как «не для ИИ». У матрицы есть отдельное свойство, ради которого стоит остановиться: она фиксирована не на уровне ИИ-инструмента, а на уровне функциональных болей и способа работы с ними. Колонка «инструмент» переписывается, когда выходит новый инструмент; колонки «задача», «процесс и его этапы», «метрика» остаются. В сфере, где каждый квартал выходит что-то, переписывающее карту применимости, это и даёт артефакту устойчивость: он не «решение» (которое со временем устаревает), а способ заново задавать вопрос.

Менторы — методика работы с матрицей интериоризируется участниками пилотной группы. Внутренние менторы — это не люди, которые знают ответ, — это люди, которые сумеют задать пересборку матрицы под новые инструменты, когда они выходят. Важно, что этот навык не усвоить отдельно от того материала, на котором пересборка происходит: внутренние менторы могут это делать потому, что работают со своими собственными процессами, и внешний эксперт не может занять их место не из-за некомпетентности, а потому что у него нет их материала.

Та же логика лежит на уровне сферы в целом и объясняет, в частности, как существуют сами внешние ИИ-эксперты — те, кто приходит к клиенту в роли практика. Материалы (реальные функциональные задачи команд) и инструменты (чат-боты, ИИ-агенты и платформы) ещё не сложились в устойчивые сети ассоциаций — пара «вот этот инструмент для вот этого класса материала» не закрепилась за конкретными задачами так, как это происходит в зрелых категориях. Из этого следует, что в нынешнем моменте «ИИ-экспертиза» ещё нечасто существует в отрыве от какой-то профильной экспертизы: многие сильные внешние ИИ-практики выросли через свою предметную область, проходя на ней рефлексивный путь (маркетолог — через маркетинг, аналитик — через аналитику). Это исторически наблюдаемая картина, и она постепенно меняется по мере того, как сети сцепляются; но пока она работает в ту сторону, что носитель функциональной экспертизы из команды клиента — это потенциально такой же эксперт по приложению ИИ к своему материалу, как и внешний практик. Разница в том, кто прошёл рефлексивный путь раньше и кто видел больше разных контекстов.

Артефакт каждого такта — собственность клиента.

В конце стратсессии Елена сказала группе: «Это не истина в последней инстанции. Это важно, чтобы это была ваша таблица, а не какая-то спущенная откуда-то сверху». Это и есть третий такт в его сути — передача внутрь, а не утверждение методологии сверху.

Описанный кейс — это вход B: клиент пришёл с уже выбранной платформой и несколькими месяцами собственного опыта. Но та же структура работает и на стадию раньше — на входе A, когда платформа ещё не выбрана. Меняется только то, какое поле сканирует оптика в первом такте: на входе B — конкретный инструмент, на входе A — какая инфраструктура вообще ложится на картину болей команды. В ситуации B оптика отвечает «где мы относительно этого инструмента», в A — «какой класс инструментов нам вообще нужен». На входе A в матрице колонка «инструмент» остаётся открытой и становится собственным выбором команды на основании ее же видения.

Это усиливает позицию формата против классического консалтинга. Большой консультант, приходя к команде на стадии до выбора платформы, оставляет отчёт «рекомендуем платформу Z с обоснованием на 60 слайдов». Со-внедрение оставляет матрицу применимости и команду, которая может это решение пересобрать и защитить сама, без зависимости от подрядчика.

08Со-внедрение в системе форматов

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

ИИ-разговор — лёгкая точка входа, та самая живая сессия с практиком, через которую клиент в описанном кейсе и зашёл. Она ослабляет дилемму в её ранней острой форме, когда клиент ещё не готов даже к лестничному контракту: команда выходит из сессии либо с собранным пониманием, которого ей достаточно, либо с переоформленным запросом, готовым стать со-внедрением.

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

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

Эти три формата не лестница в смысле «дороже-ещё-дороже». Это карта, по которой клиент может зайти в любую точку и двигаться в любую сторону, исходя из того, на какой стадии дилеммы он сейчас. Со-внедрение — стержневой формат, в котором происходит основная сборка. ИИ-разговор и ИИ-синхронизация — точки касания с другими стадиями жизни команды внутри ИИ-сферы.

09Категория, у которой пока нет имени

Если шагнуть от пакета на уровень индустрии: российский рынок корпоративного ИИ-обучения в 2026 году в моменте перехода. Первая волна — массовые курсы «что такое нейросеть» — насыщена. Вторая волна устроена иначе: клиент уже работал с ИИ и застрял в дилемме атрибуции — не может развести, где ограничение ИИ для его задач, а где ограничение собственной оптики. На рынке это проявляется как один запрос с несколькими входами. Например, команда ещё выбирает платформу — и тогда осмысленный выбор невозможен без того, чтобы сперва переформатировать взгляд на свои процессы (выбор от инструмента — это и есть дилемма; выбор от боли требует другой оптики). Или платформа уже есть, и переформатирование стоит как самостоятельная задача — научиться видеть свои процессы так, чтобы на них «ложился» ИИ: какой пилот завайбкодить, какие входные и выходные данные для него нужны, какая нужна архитектура, а какой достаточно. Часто к этому добавляется и вопрос — оправданна ли вообще глубокая интеграция (историй про негативную отдачу от поспешной оптимизации уже хватает). В примерах общее одно: переформатирование оптики первично, выбор и внедрение инструмента — вторичны. Между «курсом для всех» и «стратегическим консалтингом» образовался разрыв, в котором находится запрос большинства команд. Школы продают курсы. Большие консультанты — миллионные проекты. А посередине — мы постарались описать, что посередине.

Мы используем два имени, разнесённых по уровням. На уровне продукта — ИИ-сопровождение: то, что описывается клиенту, попадает в коммерческое предложение и в LMS-карточку. Это понятное в T&D-словаре слово, не требующее объяснения, и оно охватывает весь пакет — ИИ-разговор, со-внедрение, ИИ-синхронизация. На уровне индустрии — со-внедрение: это название категории между курсом и консалтингом, и приставка «со-» делает в нём всю работу. Не курс — потому что содержание складывается внутри сессии под конкретную команду, а не зафиксировано заранее. Не консалтинг — потому что консалтинг приходит сверху со своей методологией и оставляет отчёт, а со-внедрение работает изнутри команды и оставляет рабочий артефакт. Это дешевле — потому что не требует длинных контрактов на разработку. Это устойчивее — потому что не устаревает в момент внедрения, как может устаревать сложное ИИ-решение в нынешних темпах сферы. Со-внедрение — это работа, в которой методика складывается совместно с командой клиента и сразу становится её собственностью, и в которой польза собирается двумя экспертами в комнате — экспертом по ИИ и носителем функциональной экспертизы изнутри команды. Возможно, через год индустрия найдёт для этой категории другое слово; форма от этого не изменится.

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

«Мы всё думаем, как назвать у себя в компании то, что у нас сейчас идёт. Это не обучение. Не консалтинг. Это что-то другое».

Форма, которая лежит за этим «другим», уже работает.