Бенедикт Эванс: почему ИИ не сметёт тысячи корпоративных программ

Типичная крупная американская компания держит сотни, а то и тысячи разных программ: гигантские горизонтальные системы вроде SAP и Workday, сотни вертикальных SaaS-приложений и ещё сотни скриптов, автоматизаций и баз данных вплоть до 10-мегабайтной таблицы одного отдела, и часто сама не знает, сколько всего у неё есть, что реально используется и за что она платит. При этом компания полна скучной рутинной работы.

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

Главный аргумент: большинство людей, не строители инструментов и не думают инстинктивно, как переделать свою работу. Хороший семейный юрист весь день думает о своих делах и клиентах, а не о том, какой должна быть программа для юридического дискавери; хороший корпоративный продавец думает о продукте, клиентах и конкурентах, а не о софте для повышения своей продуктивности. Продукты вроде Excel пытаются закрыть этот разрыв обучающими сценариями и шаблонами, но каждый такой шаблон в итоге превращался в отдельную компанию, и то же самое автор видит в продуктах вида «Claude для X»: это помогает, но не решает задачу. Отсюда идея «forward-deployed engineer» (инженера прямого внедрения), человека, который знает, что умеет строить ИИ, и может просто походить по юридической фирме или архитектурному бюро и увидеть возможности, лежащие на поверхности, которых не видят сами юристы или архитекторы (автор сравнивает это с подростком на стажировке в офисе родителей, который вдруг замечает: «пап, а ты в курсе, что это можно делать вот так?»).

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

Но даже найдя решение, его нужно внедрить у всех остальных. Многие процессы и задачи, которые стоило бы автоматизировать, затрагивают 50 или 500 человек в пяти разных отделах, трёх разных системах учёта и четырёх разных регуляторных режимах; один человек не может в одиночку изменить, как весь этот процесс работает в компании, это должно стать покупкой, решением руководства и 18-месячным циклом продаж.

Автор описывает софт как спектр от «институционализированного» (компания централизованно покупает SAP, Carta или Rippling для задач, которые важно делать одинаково и у которых есть аудит, безопасность и ответственность) до «импровизированного» (пользователи сами собирают решения в свободной среде из Excel, почты, общих папок, Tableau, PowerPoint, CSV, скриншотов, PDF и созвонов), для разовых и пограничных случаев, которые не укладываются в готовые системы. Когда такая импровизированная задача становится регулярной, важной и обрастает выручкой и рисками, компания институционализирует её. Именно поэтому в компании в итоге оказываются сотни приложений: переход на SaaS был ровно таким же скачком на порядок в объёме софта, с новой операционной моделью и циклом обновлений, который убил часть неспособных перестроиться игроков, и это постоянный органический процесс «упаковки и распаковки» функциональности: любое SaaS-приложение делает то, что теоретически можно сделать в SAP, Excel или почте (например, Carta, компания с оценкой $4 млрд, которая по сути ведёт одну таблицу для финансового директора клиента), а иногда задачи возвращаются обратно в более простой инструмент. Один консультант рассказывал автору, что половина его работы, уговорить пользователей Excel перейти на базу данных, а другая половина, наоборот. Автор иллюстрирует это на PwC, которая нанимает 3, 4 тысячи выпускников в год и использует для этого специализированный институционализированный софт, тогда как небольшая фирма с наймом в 5, 10 человек обходится почтой, общей папкой и Google Sheets, и по мере роста такая фирма может перейти на Notion или отраслевой SaaS-HR, хотя даже внутри самой PwC отдельная команда может вести кандидатов в Google Sheets в обход неудобного Workday, и цикл распаковки начинается заново.

По мысли автора, ИИ проходит через тот же цикл: он расширит все существующие приложения, появится много новых вертикальных SaaS-продуктов, а Excel, Tableau, Google Sheets, почта и другие свободные среды получат новые возможности; при этом сам чат-бот становится ещё одной свободной средой рядом с Excel и почтой, которая забирает задачи у них и у специализированных приложений, и одновременно отдаёт им задачи обратно. Небольшая компания, которая нанимает десять выпускников, может дольше держаться на Google Sheets, потому что ИИ делает эту таблицу более масштабируемой, или начать использовать её как источник данных для Gemini, а затем обнаружить, что появилось новое SaaS-приложение, которое решает именно эту задачу и заодно ещё одну, о которой раньше не думали. ИИ не меняет сам вопрос, он создаёт новые варианты и сдвигает пороги, при которых имеет смысл переходить с одного решения на другое.

Это, по мнению автора, видно на опыте корпоративного внедрения ИИ за последние три года: каждая крупная компания выдала всем Copilot (или ChatGPT, или Claude), и небольшое число сотрудников пользуется этим очень активно (некоторые из них реально повысили продуктивность), более широкая группа, несколько раз в неделю, а значительная часть компании почти не пользуется инструментом вовсе. Автор считает, что это отчасти проблема обучения и управления изменениями, но в основном, та же самая проблема, что была бы при раздаче всем в компании персонального компьютера и Lotus 1-2-3 в 1983 году или доступа в интернет и браузера в 1997-м: сам факт раздачи инструмента не отвечает на вопрос, как именно он ложится на конкретные задачи людей на этой неделе. Компании действительно раздали всем ПК и Lotus, но не это перестроило обработку счетов; выдали браузер, но не это перестроило управление цепочкой поставок или электронную коммерцию ритейлера.

Узкий, привычный ответ компаний на такие структурные сдвиги, пилоты: пробные проекты (и купленных, и собственных продуктов), использующие новые возможности ИИ там, где раньше автоматизация была невозможна. По словам автора, сейчас накоплено много данных о том, сколько таких пилотов запускается, сколько из них срабатывает (примерно половина, и это нормально, ведь это и есть смысл пилота) и что может пойти не так. Но это, по мнению автора, всё тот же старомодный ИТ-директорский разговор про кейсы использования, «маяки», пилоты, героев и быстрые победы, тогда как гендиректор и совет директоров недоумевают: «У нас же сотни рабочих процессов, а мы сделали пять-десять пилотов, разве это должно так масштабироваться?» Раздать всем в компании ChatGPT масштабируется теоретически, но на практике большинство сотрудников просто не находит, как его применить.

Автор проводит аналогию с гипотетическим банком, раздавшим всем сотрудникам электронные таблицы в 1980-х, или ритейлером, раздавшим браузер в 1990-х: да, это стоило сделать, да, нужно думать об обучении и управлении изменениями, но это не способ продумать трансформацию работы компании вокруг новой технологии поколения. По мнению автора, с любой такой технологией компания должна ответить на три вопроса: во-первых, как её покупать, строить и внедрять (делать пилоты, брать продукт, встроенный вендором вроде Microsoft/Google/Oracle, строить самим, платить подрядчику или покупать готовое решение у стартапа); во-вторых, насколько сильно она меняет операции компании, ответ разный для страховой компании и юридической фирмы; в-третьих, создаёт ли она новые вызовы для экономики бизнеса, конкурентного давления или вовсе экзистенциальную угрозу. Раздача всем сотрудникам «Claude для X» не отвечает ни на один из этих вопросов, вместо этого, по наблюдению автора, растёт спрос на консалтинг по внедрению (иронично, учитывая, сколько вопросов ИИ ставит перед бизнес-моделью самого консалтинга): компания, которая хочет развернуть голосовую аналитику на базе LLM в колл-центре, скорее всего обратится к Accenture. Крупные ИИ-лаборатории уже заводят собственные подразделения по внедрению («deploycos»), автор проводит параллель со старой шуткой о том, что «специалист по машинному обучению, это статистик, который живёт в Сан-Франциско», предполагая, что «forward-deployed engineer», это, возможно, просто любой, кого наняла OpenAI. На этом месте захваченный текст обрывается на середине фразы.

Ключевые факты

Компании держат сотни, а то и тысячи разных программ, от SAP и Workday до 10-мегабайтной таблицы одного отдела, и часто сами не знают, что у них есть и за что они платят.
Полностью автоматизировать это мешает не техника: большинство сотрудников, не «строители инструментов» и не видят рутину, которую можно автоматизировать; для этого нужен «forward-deployed engineer», который ходит по офису и замечает то, чего не видят сами юристы или архитекторы.
Даже найденное решение нужно провести через организацию: задача может касаться 50, 500 человек в пяти отделах, трёх системах учёта и четырёх регуляторных режимах, и это занимает 18-месячный цикл продаж, а не пять минут на генерацию инструмента.
За последние три года компании раздали сотрудникам Copilot, ChatGPT или Claude, но активно пользуется ими меньшинство, автор сравнивает это с выдачей всем ПК и Lotus 1-2-3 в 1983 году или браузера в 1997-м: сама раздача инструмента не перестроила обработку счетов или цепочку поставок.
Примерно половина пилотных ИИ-проектов срабатывает, по словам автора, это нормально для пилотов, но пилотами не решить трансформацию сотен процессов сразу: компании отдельно нужно решить, как покупать, строить и внедрять ИИ, насколько сильно он меняет операции и создаёт ли новые угрозы для бизнеса.

Почему это важно

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

Кому это важно

ИТ- и продуктовым руководителям, которые решают, покупать ли готовый ИИ-продукт, встраивать вендорский или строить своё; командам, которые делают ИИ-инструменты «для X» и продукты вроде Copilot для целых компаний; консультантам по внедрению; руководителям, которые раздали сотрудникам доступ к чат-ботам и не понимают, почему это не изменило работу компании.

Как это применить

Автор предлагает не искать волшебную кнопку, а диагностировать задачу по спектру «институционализированное, импровизированное»: то, что сотрудники уже ведут в Excel, почте или общих папках, кандидат на институционализацию, как только вырастают масштаб, выручка и риск. Дальше, задать три вопроса из эссе: как покупать/строить/внедрять инструмент, насколько сильно он меняет именно ваши операции и создаёт ли он новые экономические или конкурентные угрозы. И отдельно, искать своих «forward-deployed engineer»: людей, способных пройтись по отделу и увидеть очевидную для стороннего взгляда, но незаметную изнутри рутину.

Можно ли доверять

Это авторская аналитическая колонка на личном блоге, а не репортаж с проверяемыми фактами о конкретном событии: центральный тезис подкреплён историческими аналогиями (SaaS-волна, ПК и Lotus 1-2-3 в 1983-м, браузеры в 1997-м) и примерами (Carta, PwC), а не внешними источниками. Ключевая цифра о пилотах, «примерно половина срабатывает», в тексте не привязана к конкретному исследованию или организации, автор лишь ссылается на некие общие данные. Иллюстративные реплики в тексте (подросток на стажировке, гендиректор с советом директоров), гипотетические, не цитаты реальных людей.

Риски и подводные камни

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

«Подождите, у нас же сотни рабочих процессов, а мы сделали пять-десять пилотов. Разве это должно так масштабироваться?»

— гипотетическая реплика гендиректора и совета директоров в иллюстрации автора