FDE трансформирует развертывание корпоративного ИИ

При поддержке Zeta

Любая презентация передового инженера по внедрению (FDE) первые десять минут звучит одинаково: инженер на месте у клиента, рабочий процесс, закодированный за несколько недель, и демоверсия, которая наконец-то работает на реальных данных заказчика. Разница кроется в том, что происходит в последующие месяцы, и большинство вендоров не скажут вам об этом, пока вы не спросите напрямик.

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

Проверка проста: начинается ли после завершения проекта FDE работа с новым клиентом с большего количества готового продукта и меньшего числа неизвестных — или просто с новой команды услуг?

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

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

Инженеры как контекстный слой

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

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

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

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

Песочница, грязь и судьба полученных знаний

Полезный вопрос во время звонка по due diligence или обсуждения продления контракта заключается вовсе не в том, есть ли у вендора специалисты FDE. Вопрос в том, работает ли инженер в вашей среде в песочнице с инструментами или пытается вытащить вас из грязи.

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

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

Стратегический подход к FDE рассматривает каждое взаимодействие как дисциплинированный цикл обучения. Он начинается с наблюдения за исключениями в полевых условиях, кодификации их в повторно используемый артефакт, проверки с помощью оценки и аудита безопасности, выпуска в продукт и последующей оценки того, действительно ли следующее развертывание стало проще. Именно на этом последнем этапе большинство компаний тихо терпят неудачу. Не каждое открытие из полевых условий принадлежит ядро продукта. Часть клиентской логики является проприетарной, временной или слишком специфичной для обобщения. Хорошие команды видят разницу между тремя вещами, которые часто сваливают в кучу под вывеской «FDE»: продуктовую аналитику, которая накапливается у каждого клиента; настраиваемую клиентскую логику, которая пригодна для одного аккаунта, но не должна тиражироваться широко; и разовые услуги, которые являются именно тем, чем кажутся.

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

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

Лучшая организация FDE меняет свою форму

Неприятный вывод для команд, создающих функции FDE, заключается в том, что объем человеческого участия должен сокращаться на единицу поставляемой ценности, даже если общая численность персонала растет. Быстро растущая компания может продолжать нанимать инженеров FDE, делая каждый запуск существенно проще, поскольку большая часть необходимой логики уже заложена в продукте. Каждое развертывание должно требовать меньше кастомного инжиниринга, чем предыдущее, а инженеры должны тратить больше времени на расширение возможностей повторного использования, чем на переделку одних и тех же интеграций, рабочих процессов и логики принятия решений.

Отслеживайте четыре параметра:

• количество инженеров на один работающий процесс;

• часы инженерной работы на одно развертывание;

• время до получения ценности (time-to-value) в разрезе вертикалей;

• долю внедрений, которые используются повторно, а не пересоздаются с нуля.

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

FDE — это лишь временные леса, пока они остаются снаружи здания. Цель состоит не в том, чтобы избавиться от людей, выполняющих работу, а в том, чтобы как можно больше из того, чему они учатся, превращалось в несущие конструктивные возможности продукта.

Три вопроса, позволяющие заглянуть за маркетинговую презентацию

1. Как оценивается FDE?

Ценообразование — это скорее сигнал, чем окончательный вердикт. Отдельная строка профессиональных услуг может отражать честную прозрачность, а включенные в пакет услуги FDE могут быть убыточным продуктом, оплачиваемым за счет утилизации. Более полезный вопрос заключается в том, дают ли контракт, продление и маржинальность четкое понимание того, какая работа является повторяемой продуктификацией, а какая — заказной разработкой.

2. Куда уходят знания, полученные в полях?

Не делайте выводы только на основе резюме. Спросите, кто отвечает за передачу дел от FDE к продуктовой команде, какие артефакты при этом создаются и как быстро они превращаются в протестированные, поддерживаемые функции. Именно организационный интерфейс показывает, накапливаются ли знания, а не название должности.

3. Что ускорилось при последнем повторном развертывании?

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

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

Нидж Гор (Neej Gore) — директор по данным (Chief Data Officer) в компании Zeta.

Спонсорские статьи — это контент, созданный компанией, которая либо платит за публикацию, либо имеет деловые отношения с VentureBeat, и они всегда четко маркируются. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.