Внедрение инженерных решений на передовой — это способ обучения корпоративной системы искусственного интеллекта.

Нидж Гор, Зета

Представлено компанией Zeta

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

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

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

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

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

Инженеры представляют собой контекстный слой.

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

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

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

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

Песочница, грязь и что происходит с обучением?

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

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

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

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

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

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

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

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

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

• инженеров на каждый рабочий процесс в реальном времени

• инженерных часов на развертывание

• время получения выгоды по отраслям

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

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

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

Три вопроса, которые помогут пройти дальше.

1. Как формируется цена на FDE?

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

2. В каком направлении развивается полевое обучение?

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

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

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

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

Нидж Гор — директор по работе с данными в компании Zeta.

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

Источник: venturebeat.com