Iparág

Mesterséges intelligenciával generált szöveg

Hogyan alakítja a forward-deployed engineering a vállalati AI-termékeket

A cikk főszereplője Neej Gore, a Zeta Chief Data Officerje, aki a forward-deployed engineering (FDE) működését és szerepét elemzi a vállalati mesterséges intelligencia területén.

Hogyan alakítja a forward-deployed engineering a vállalati AI-termékeket

A forward-deployed engineering (FDE) olyan működési modell lett az vállalati mesterséges intelligencia területén, amelyben mérnökök a vásárló oldalára beágyazódva kötnek össze termékeket a valós üzemeltetési környezettel. A pitch-ek elején minden eladó hasonlót mond: egy mérnök a helyszínen, hetek alatt kicsomagolt munkafolyamat, és egy demó, ami működik az ügyfél adataival. Ami azonban valóban döntő, az a következő hónapokban történik: vajon az elvégzett munka beépül-e a termékbe, vagy csak szolgáltatási órákat gyűjtünk?

FDE jelensége egyszerre értékes és kockázatos: befektetők a FDE-létszámot növekedési jelként olvassák, a vásárlók a sebesség ígéretét látják benne. A fontos vizsgálati kérdés egyszerű: egy FDE-elköteleződés után a következő ügyfél több kész termékelemmel és kevesebb ismeretlennel kezd-e — vagy csak egy új szolgáltató csapatot kap?

Az FDE különböző arca

Az FDE nem egyetlen dolog. A leggyengébb formájában elfedi, hogy a termék önmagában még nem képes működni: a mérnök kézzel fordít le olyan logikákat, amit a szoftvernek egyszer automatizálnia kellene. A legerősebb formájában pedig fegyelmezett termék-tanulási funkcióként működik: a terepen előbukkanó kivételes eseteket azonosítja és újrahasználható képességekké alakítja.

A valódi érték abban rejlik, hogy az FDE révén létrejövő automatizáció egy „intelligencia-rendszert” táplál. Ez több, mint munkafolyamatokat végrehajtó szoftver: vállalati kontextust rögzít, minden telepítésből tanul, és javítja a jövőbeli döntések minőségét. A forward-deployed mérnökök hozzák be ezt a kontextust kezdetben személy formájában.

A mérnökök, mint a kontextusréteg

Bizonyos területeken a modellválasztás továbbra is számít. Sok vállalati munkafolyamatnál azonban nagyobb szűk keresztmetszet az, hogy maga a vállalat mit tud magáról: üzleti szabályokat, kivételeket, workflow-logikát és év alatt kialakult definíciókat. Az adat-hozzáférés nem ugyanaz, mint az üzlet megértése.

Egy nagy távközlési telepítés példájában az eredeti „magas szándékú” ügyfél definíció nem maradt életben, amikor összeütközött az üzemeltetési rendszerekkel. A modell jelzése mást mondott, mint amit a retention csapat tényleges megtartási kritériumai indokoltak — azok a kritériumok éveken át gyűjtött tapasztaton alapultak, régiók és lojalitási sávok szerint. Nem voltak sémák, amelyek dokumentálták volna ezt az ítélőképességet; ez a tudás az évtizede dolgozó emberek fejében élt. A mérnöknek le kellett ülnie velük, kinyerni ezt a tudást és kódolni, mielőtt az intelligencia-réteg biztonsággal aktiválhatott volna akciót a csupán pontszám helyett.

Miután ez a logika beépült az intelligenciarétegbe, az új beszerzési és megtartási use case-ek napok alatt mozdultak át az ötlettől a végrehajtásig. Ahelyett, hogy minden integrációt újraépítettek volna, a csapatok döntéseket adtak hozzá egy megosztott alaphoz.

Mit hagy maga után a tanulás: sandbox vagy sár?

Az ügyfélképviseleti beszélgetések hasznos kérdése nem az, hogy van-e FDE-je a szolgáltatónak, hanem hogy az a mérnök, aki az Ön környezetébe nyúl be, egy eszköz-sandboxban játszik-e, vagy megpróbál-e kirángatni a sárból.

  • Sandbox: az FDEk egy általános célú motort használnak speciális, bonyolult környezetekben. Feladatuk felfedezni, hogy hol kell egy új alkatrész, beszerelni azt, és a tanulságot visszajuttatni, hogy az alkatrész újra szállítható legyen.
  • Sár: a mérnök egy hiányzó képességet kézzel épít meg ügyfelenként, nincs alatta olyan motor, amely várja a komponens befogadását; ez gyakorlatilag egyedi megoldás.

A valóság gyakran a kettő között van: újrahasználható playbookok és connectorok a tipikus esetekre, egyedi ítélőképesség a többihez. Kívülről mindez hasonlóan néz ki: egy okos mérnök a helyszínen, kódol az ügyfél adataival. A döntő különbség az, hogy mi történik azzal, amit megtanul: a következő telepítés kevesebb ismeretlennel és kevesebb egyedi kóddal kezd-e, vagy visszatér minden nulláról.

A stratégiai FDE minden elköteleződést fegyelmezett tanulási ciklusként kezel: kivétel megfigyelése a terepen → újrahasználható artefaktummá kódolás → értékelés és biztonsági review → kiadás a termékbe → mérés, hogy a következő telepítés tényleg egyszerűbb lett-e. Sok cég az utolsó lépésnél megbukik: nem minden terepi felfedezés való a magtermékbe. Vannak ügyfél-specifikus, ideiglenes vagy túlságosan egyedi logikák.

Jó csapatok meg tudják különböztetni a következő három kategóriát:

  • termékintelligencia, ami minden ügyfélnél felhalmozódva növeli az értéket;
  • konfigurálható ügyféllogika, ami újrahasználható egy fiókon belül, de nem szabad széles körben szállítani;
  • egyszeri szolgáltatásmunka, ami pontosan amit látszik.

A testreszabás elvárt; a kudarc abban áll, ha nem címkézik a munkát vagy elveszítik a tanulást a komponensekből, amelyek általánosíthatóak.

Hogyan változik az FDE-szervezet optimálisan

A kényelmetlen következtetés: ahogy az FDE-funkció fejlődik, a humán-átfordításnak egységnyi értékenként csökkennie kell, még ha az abszolút létszám növekszik is. Egy gyorsan növekvő cég folyamatosan vehet fel FDE-ket, miközben minden telepítést könnyebbé tesz: több logika már a termékben létezik.

Minden telepítésnek kevesebb egyedi mérnöki munkát kell igényelnie, a mérnököknek pedig több időt kell tölteniük újrahasználható képességek kiterjesztésével, ahelyett hogy ugyanazokat az integrációkat és döntési logikákat építenék újra.

Kövesse négy mutatót:

  • mérnökök száma élő munkafolyamatonként
  • mérnöki órák száma telepítésenként
  • time-to-value iparáganként
  • és a megvalósítás részaránya, amely újrahasználható, nem pedig újraépített.

Kövesse még ezt is: a termékké alakítás késedelme (productization lag) — az az idő, amely a terepi felfedezés és a tesztelt, a következő ügyfél számára elérhető képesség között telik el. Idővel ez a késés csökkenjen, a testreszabott munka csökkenjen, és az újrahasználat növekedjen. Ha ezek nem javulnak, a szervezet teljesít ugyan, de nem tanul – bármilyen is a létszámtábla.

FDE csak állványzat, ha kívül marad az épületen. A cél nem a dolgozók eltörlése, hanem hogy amiatt, amit megtanulnak, egyre több legyen teherhordó termékképesség.

Három kérdés, amelyek túlmutatnak a pitch-en

  1. Hogyan árazzák az FDE-t?
  • Az árazás jelzés, nem ítélet. A külön professzionális szolgáltatási sor lehet őszinteség, a csomagolt FDE lehet veszteségvezető. A fontosabb kérdés, hogy a szerződés, a megújítás és a margin világosan elválasztja-e, mi ismételhető termékké alakítható és mi egyedi lesz.
  1. Hová kerül a terepi tanulás?
  • Ne következtessen csak önéletrajzokból. Kérdezze meg, ki felel az FDE és a termék közötti átadásért, milyen artefaktumok készülnek, és milyen gyorsan válnak tesztelt, támogatott képességgé. A szervezeti interfész mutatja meg, hogy a tanulás felhalmozódik-e.
  1. Mi gyorsult fel az utolsó ismételt telepítésnél?
  • Kérjen konkrét iparágat és konkrét delta-mutatót: kevesebb mérnöki óra, rövidebb hetek a haszonig, kevesebb egyedi integráció vagy magasabb újrahasználati arány. Egy hiteles szolgáltató meg tudja nevezni, mi változott és hogyan mérték.

Záró gondolat

A vállalati AI akkor teremt tartós előnyt, ha minden telepítés több marad a megelégedett ügyfélnél: több tudás az üzleti működésről, több újrahasználható képesség, ami idővel összegződik. A cél nem pusztán az AI bevezetése: a cél egy intelligencia-rendszer felépítése, amely begyűjti a vállalati kontextust, ügyfél-tanulságokat átalakít újrahasználható képességgé, és idővel összegződik.

Neej Gore a Zeta Chief Data Officer-e.

Ez a cikk a Zeta által bemutatott tartalom. Szponzorált cikkek olyan cégek által előállított tartalmak, amelyek fizetnek a közlésért vagy üzleti kapcsolatban állnak a kiadóval. További információ: sales@venturebeat.com.