«В теории всё выглядит красиво, а на практике — совсем не так»
— старый инженерный афоризм, который почему-то каждый раз оказывается правдой
Летом 1956 года группа учёных собралась в Дартмутском колледже на семинар, который они гордо назвали Dartmouth Summer Research Project on Artificial Intelligence. Организатор Джон Маккарти писал в заявке, что «любой аспект обучения или интеллекта можно описать настолько точно, что машина сможет его сымитировать». Участники искренне верили, что за одно лето коллективного мозгового штурма они научат машину понимать язык, формировать абстракции и решать творческие задачи. Спойлер: не научили. От красивой концепции до массовой технологии прошло почти 70 лет, и только после 2022 года ИИ реально вошёл в повседневную жизнь.
Привёл этот пример не случайно 🙂 Каждое крупное технологическое обещание проходит один и тот же путь: сначала гениальная идея на бумаге, потом десятилетия разочарований, и только затем — тихое, часто незаметное для самих участников превращение в рабочий инструмент. Сейчас из нескольких мест подряд слышу про проекты реорганизации, орг. эффективности и то, как ИИ «заменит всех». Похоже, мы снова стоим на этом же перекрёстке — между вдохновляющей заявкой и реальной работой, которая всегда оказывается куда прозаичнее и сложнее, чем кажется в презентации.
В России это особенно понятный приоритет: компании задумались, не пора ли сбросить балласт и сократить людей, а бюджеты на трансформацию защищаются легче, если в презентации есть слово «ИИ». Параллельно консультанты поют, что ИИ захватит все рабочие места и резко повысит производительность — и на этом фоне идёт много дискуссий, что и как заменит ИИ, причём часто эти дискуссии оторваны от конкретной специфики бизнеса. Ну и про операционную модель разговор идёт отдельно, но по сути о том же самом: как организовать работу людей и систем так, чтобы она приносила деньги, а не только красивые метрики на слайде. Совокупность этих трёх вопросов сейчас так или иначе всплывает почти в каждом кабинете CEO, и часто одновременно — реорганизация как повод сократить штат, ИИ как повод оправдать сокращение, операционная модель как рамка, в которую всё это нужно упаковать.
В целом всё это верно и правильно, и я сам с удовольствием подключаюсь к таким инициативам. Но у этой медали есть и другая сторона — и именно она определяет, получится проект или закончится очередной серией красивых пилотов без результата. Разберём эту сторону подробно, по пунктам.
ИИ — это дорого, и самоокупаемость пока не близко
Начнём с экономики, потому что именно она чаще всего оказывается за скобками красивых презентаций. Если вы подписаны на Claude или любую другую модель по подписке и активно тратите все токены — сама компания-провайдер на этом не зарабатывает, а теряет деньги. Весь этот бизнес сейчас убыточен и растёт только на ожиданиях инвесторов, а не на реальной прибыли. Значит, происходит одно из двух: либо самоокупаемость ещё далеко, либо цена токенов должна вырасти в разы — и если вы крупный бизнес с промышленными объёмами использования, для вас это, скорее всего, уже так и есть, просто пока прикрыто скидками на этапе захвата рынка.
Это принципиально меняет логику планирования бюджета. Многие проекты сейчас закладывают экономику «как сегодня» — по текущим ценам на токены, по текущим лимитам подписок, по текущей скорости работы моделей. Но если ваш горизонт планирования — год-два, а не квартал, вы обязаны закладывать сценарий, в котором инфраструктурная часть станет заметно дороже, а не дешевле. Ирония в том, что более мощные модели часто оказываются экономически выгоднее, чем более дешёвые и слабые: если дорогая модель сокращает время на проверку результата с десяти минут до двух, экономия от этого перекрывает разницу в цене за токен. Но чтобы это увидеть, нужно считать не стоимость запроса, а полную стоимость завершённой задачи — включая время сотрудника на проверку, доработку и исправление ошибок. Большинство компаний этого просто не считает и поэтому принимает решения вслепую, ориентируясь на headline-цифру цены за токен, а не на реальную экономику конкретного процесса.
Планировать проект трансформации, исходя из сегодняшней «дешёвой» цены токена, — стратегическая ошибка. Закладывать нужно совсем другую экономику: с запасом на рост объёмов использования, на возможное повышение цен и на скрытые издержки — переработку промптов, повторные запуски, инфраструктуру мониторинга и контроль качества.
Навыки для поддержания системы: гибкость важнее модели
Чтобы ИИ реально заработал, нужны две вещи одновременно, и обе — про организационную скорость, а не про качество самой модели. Первая — очень гибкий и быстрый IT, который умеет внедрять продукты за недели, а не кварталы, способен быстро подключать новые API, тестировать новые модели и разворачивать пилоты без месяцев бюрократии. Вторая — пользователи, готовые быстро встраивать новые инструменты в свои процессы, причём «быстро» сейчас означает полугодия, а не месяцы: за это время инструментарий успевает кардинально измениться, появляются новые модели, новые возможности, новые способы решения той же задачи в разы эффективнее.
Если ваша компания — неповоротливый лайнер, где IT-бюджет одобряется раз в год и пересматривается раз в полгода, а любое решение согласуется с СБ по одной-две недели, вы получите очень немного реального эффекта и очень много хайпа. Причём это не гипотетический сценарий: именно такая архитектура согласований типична для крупных промышленных и финансовых организаций, где безопасность и регуляторика оправданно стоят на первом месте. Технология не виновата, виновата скорость организационных процессов вокруг неё — и здесь возникает неприятный парадокс: чем крупнее и «зрелее» организация с точки зрения процессов контроля, тем меньше у неё естественной скорости для того, чтобы реально извлекать пользу из быстро меняющегося инструментария.
Решение здесь не в том, чтобы отменить контроль — это было бы безответственно, особенно в регулируемых отраслях. Решение в том, чтобы выделить отдельный, более быстрый трек согласований именно для экспериментов с ИИ, с более лёгким уровнем риска и, соответственно, более лёгким уровнем бюрократии, оставив полный цикл контроля для того, что реально выходит в продакшен и касается клиентов или критической инфраструктуры.
Навыки использования: критическое мышление важнее промптов
От обычного сотрудника сейчас неожиданно требуется совсем не то, что раньше: навыки критического мышления, умение чётко структурировать задачу, способность быстро адаптироваться к тому, что инструмент, которым он пользовался вчера, сегодня работает уже немного иначе. Раньше типичная корпоративная компетенция строилась вокруг стабильного набора навыков и процедур — теперь она строится вокруг способности постоянно переучиваться и держать в голове несколько разных способов решения одной задачи одновременно.
В крупных компаниях с большим числом узкоспециализированных специалистов, бюрократией и укоренившимся принципом «лучше ничего не делать и не ошибиться, чем проявить инициативу и получить по голове», внедрение новых инструментов идёт медленно и долго, а обучение людей — ещё дольше. Это не вопрос одноразового тренинга, это вопрос культуры принятия решений. Можно провести идеальный курс по промпт-инжинирингу, но если корпоративная культура наказывает за инициативную ошибку сильнее, чем поощряет инициативный успех, люди рационально предпочтут не рисковать и продолжат делать всё по старинке — тихо, незаметно, но систематически.
Есть и более тонкий момент: критическое мышление и умение структурировать задачу — это навыки, которые годами не были приоритетом при найме и обучении в крупных иерархических организациях, где ценились скорее исполнительность и следование процедуре. Перестроить это за несколько месяцев корпоративного тренинга физически невозможно — это вопрос многолетней трансформации системы найма, оценки и развития персонала. И любой, кто обещает быстрый результат здесь, скорее всего, продаёт иллюзию.
Хайп и непрактичность: красивые цифры без результата
Довольно много инструментов дают красивые дашборды и впечатляющие цифры на демо, но так и не превращаются в реальное дело. Хороший тест на непрактичность — спросить себя: сколько компаний в вашей индустрии реально выиграли от «предиктивной аналитики ремонтов»? Этот инструмент существует уже, вероятно, десятилетия, но по-настоящему его использует горстка компаний — просто потому, что мало кто умеет быстро и практично его внедрять. То же самое, скорее всего, произойдёт и с генеративным ИИ, если подходить к нему так же: закупить платформу, провести пилот на витринном примере, показать красивую цифру совету директоров — и остановиться на этом, потому что дальше начинается настоящая, неблагодарная работа по встраиванию инструмента в реальный рабочий процесс сотен людей.
Отдельная и не менее важная проблема — данные. Сколько данных реально есть в вашей компании, насколько они хаотичны и неструктурированы? Это далеко не второстепенное препятствие, а часто основная причина, почему пилот так и остаётся пилотом. Любая модель, даже самая продвинутая, работает ровно настолько хорошо, насколько хороши данные, на которых она принимает решение. А в большинстве крупных организаций эти данные разбросаны по десяткам систем, ведутся в разных форматах, частично дублируются, частично противоречат друг другу и требуют месяцев работы просто для того, чтобы их привести в порядок, прежде чем к ним вообще можно будет подключить ИИ-инструмент.
Именно поэтому обещание «ИИ сам во всём разберётся» — это, по сути, маркетинговый ход, а не техническая реальность. Прежде чем ИИ начнёт приносить пользу в масштабе, придётся сделать много скучной, невидимой работы с данными и процессами — и именно эта работа обычно съедает большую часть бюджета проекта, а не сама модель.
Внедрение сверху вниз против нужной снизу свободы
Все крупные изменения в большом бизнесе традиционно идут сверху вниз — приказом, программой, каскадом целей, KPI, спущенными от совета директоров до линейного менеджера. Это логично: крупная организация не может позволить себе хаотичные, никем не согласованные изменения, особенно если речь о безопасности, финансовой отчётности или взаимодействии с клиентами.
Но инструментарий ИИ требует ровно обратного: инициативности и свободы на местах. Самые интересные и практичные применения ИИ обычно находят не топ-менеджеры на стратегической сессии, а линейные сотрудники, которые каждый день сталкиваются с рутинной, скучной, повторяющейся частью своей работы и понимают, где именно инструмент может сэкономить им реальное время. Но чтобы это применение появилось, у сотрудника должно быть время на эксперимент, право на ошибку и хотя бы минимальный доступ к инструментам без недельного согласования.
Организация таких «островков предпринимательства» внутри крупной иерархической структуры — задача совсем не типичная для корпоративного управления, но абсолютно необходимая, если вы хотите получить реальный эффект, а не только красивую презентацию для совета директоров. По сути, речь идёт о встроенном противоречии: топ-менеджмент должен одновременно держать жёсткий контроль над компанией и создавать внутри неё зоны, где этот контроль сознательно ослаблен ради экспериментов. Немногие организации умеют держать это противоречие в балансе — обычно оно решается либо в пользу полного контроля, и тогда ИИ остаётся хайпом, либо в пользу анархии, и тогда возникает бесконтрольный набор десятков не связанных друг с другом инициатив без единой архитектуры, которые потом невозможно ни измерить, ни поддерживать.
Почему нужны практики, а не визионеры
Из всего этого следует одна простая, но неудобная мысль: на встречу про реорганизацию, операционную модель и роль ИИ важно звать не тех, кто красиво рассказывает про будущее, а тех, кто понимает всю эту механику снизу — экономику токенов, скорость IT-процессов, культуру принятия решений, состояние данных, реальные барьеры внедрения на уровне конкретного отдела.
Визионер запустит вас в серию вдохновляющих пилотов, каждый из которых выглядит прорывом на слайде и умирает через полгода без единого измеримого результата. У визионера всегда красивая история про будущее труда, про агентов, которые заменят целые департаменты, про экспоненциальный рост производительности — и часто эта история даже отчасти правдива на горизонте нескольких лет. Проблема в том, что между этой историей и завтрашним понедельником лежит огромное количество скучной, неблагодарной работы, о которой визионер обычно не говорит, потому что это не его зона ответственности и не то, за что ему платят.
Практик действует иначе. Практик сначала спросит: где у вас данные и в каком они состоянии, кто в организации может принять решение за неделю, а не за месяц, во что вы на самом деле готовы вложиться — в инструмент или в изменение того, как люди работают, и что вы будете делать, если пилот покажет не 90%, а 60% успешности. Практик будет настаивать на измерении реальной ценности, а не факта использования инструмента, будет закладывать бюджет с запасом на рост стоимости, а не на сегодняшние скидочные цены, и будет требовать конкретного бизнес-владельца для каждой инициативы, а не размытой ответственности «между отделами».
Именно поэтому организационные изменения, операционная модель и вопрос про ИИ — это не три отдельных проекта, а одна системная задача. Решать её нужно не последовательно и не в изоляции друг от друга — сначала сократить штат, потом «внедрить ИИ», потом когда-нибудь обновить операционную модель, — а вместе, с самого начала, с людьми, которые одновременно видят картину сверху и понимают, где обычно ломается реализация снизу. Компании, которые пытаются решить эти три вопроса по отдельности, систематически проигрывают тем, кто с первого дня выстраивает их как единую перестройку того, как в организации создаётся ценность.
Если в вашей компании тема реорганизации, орг. эффективности или роли ИИ уже обсуждается — рад буду подключиться к дискуссии именно на этом, практическом уровне 🚀