Mit várjunk egy ügyféloldalon dolgozó mérnöktől? Az FDE szerep határai

Amikor egy vállalkozás összekötné az ügyfélkezelőjét, a rendelési rendszerét és egy AI-eszközt, szüksége lehet olyan mérnökre, aki az üzleti folyamatot és a szoftvert egyaránt érti. Az angol Forward Deployed Engineer, röviden FDE elnevezés ilyen, ügyfélközelben dolgozó szakembert jelölhet. A munkakör neve azonban önmagában nem mondja meg, ki felel a megoldásért az átadás után.

Egy magyar KKV beszerzési döntésében ezért az a hasznos kérdés, hogy milyen problémát old meg a szakember, milyen hozzáférést kap, és mit hagy maga után. A szerep népszerűségének növekedését vagy csökkenését ez a cikk nem állítja: ehhez összehasonlítható munkaerőpiaci adatokra lenne szükség.

Mit dokumentál egy valódi szerepleírás?

A Palantir 2026. október 18-án ellenőrzött FDE-álláshirdetése ügyfélproblémák megértését, adatvezérelt megoldások tervezését és megvalósítását kapcsolja össze. A leírás közvetlen ügyfélmunkát és önálló mérnöki felelősséget is tartalmaz. Ez elsődleges példa arra, mit ért egy konkrét vállalat a szerep alatt; nem az összes FDE-pozíció szabványa és nem keresleti statisztika. Palantir: Forward Deployed Software Engineer.

A megnevezést érdemes munkatartalomra fordítani. A szakember feltárhatja a problémát, módosíthatja a terméket, készíthet ügyfélspecifikus összekötőt, vagy segíthet egy már meglévő rendszer bevezetésében. Ezek különböző eredmények. A vállalkozásnak azt kell megrendelnie, amire ténylegesen szüksége van.

Egy stúdió integrációs szolgáltatása, egy szoftvergyártó saját FDE-csapata és egy belső alkalmazott nem azonos szerződéses helyzet. A termékgyártó mérnöke például képes lehet közvetlenül jelezni egy termékhibát a saját fejlesztőinek, de ebből még nem következik, hogy a következő kiadás határidejét is ő dönti el.

Három szerep, eltérő felelősség

Az alábbi összehasonlítás javasolt feladatmegosztás egy beszerzés előkészítéséhez. Nem munkaköri szabvány: a tényleges szerződésben név szerint kell kijelölni a felelősöket. Kis csapatban ugyanaz a személy több feladatot is elláthat, de a döntések határa akkor is legyen látható.

Szempont	Termékfejlesztő	FDE	Bevezetési tanácsadó
Elsődleges cél	Több ügyfélnek használható termék	Működő megoldás a konkrét ügyfélhelyzetben	A rendszer beillesztése a szervezet működésébe
Jellemző eredmény	Verziózott termékképesség	Integráció, alkalmazás, műszaki visszajelzés	Folyamat, beállítás, oktatás, bevezetési terv
Kódmódosítás	A termék kódjában	A megállapodás szerinti rétegben	Nem feltétlenül része a munkának
Karbantartási felelős	Termékcsapat	Külön kijelölt integrációs gazda	Kijelölt üzemeltető vagy terméktámogatás
Átadási felelős	Kiadásért felelős személy	Műszaki átadást végző mérnök	Bevezetési projektvezető

Az ügyfél oldalán ettől függetlenül kell egy folyamatgazda, aki elfogadja az eredményt. Egy sikeres technikai próba nem jogosítja fel a beszállítót az árképzés vagy a vevői jogosultságok önálló megváltoztatására. A mérnök javaslatot tesz, az üzleti szabályról annak tulajdonosa dönt.

Mintaszituáció: ajánlatkérés egy nagykereskedőnél

Képzeljünk el egy magyar ipari nagykereskedőt, ahol az érdeklődők e-mailben küldenek cikkszámokat. Az értékesítő kézzel keresi meg a termékeket, ellenőrzi a készletet, majd ajánlattervezetet állít össze. Ez szemléltető helyzet, nem dokumentált ügyféleset és nem állítás a magyar vállalatok általános működéséről.

A megrendelt feladat legyen szűk: a beérkező kérésből készüljön ellenőrizhető ajánlattervezet. Az AI azonosíthatja a szövegben szereplő termékigényt, de az ár és a készlet a vállalat hiteles rendszeréből származzon. A bizonytalan egyezést jelölje, ne helyettesítse saját ötlettel. Az ajánlatot az értékesítő hagyja jóvá, a próba ne küldjön automatikusan levelet az ügyfélnek.

Az FDE feladata lehet az adatkapcsolat kialakítása, a hibák kezelése és az ellenőrző felület elkészítése. A folyamatgazda adja meg, mely árlista használható, mi történjen kifutott terméknél, és mikor kell telefonos egyeztetés. A bevezetési tanácsadó segíthet a munkatársak oktatásában, ha ezt külön megrendelték.

A tesztkészlet tartalmazzon ékezet nélküli megnevezést, elírt cikkszámot, többféle kiszerelést és hiányzó mennyiséget. A márkánként eltérő mértékegység különösen alkalmas a hibás egyezések feltárására. A cél nem az, hogy minden kérés automatikusan elkészüljön, hanem hogy a rendszer a bizonytalanságot is felismerhetően adja át.

A hozzáférés legyen a feladathoz kötve

A próba induljon mesterséges vagy megfelelően személytelenített adatokkal. Ha később valódi ügyféladat szükséges, előre rögzítsük, mely adatot mely szolgáltató kapja meg, milyen célból, és ki törli a próba végén. A személyes adatok kezelésének jogalapját a konkrét folyamatra kell meghatározni; az AI használata önmagában nem jogalap. Az EDPB kisvállalkozásoknak szóló útmutatója.

A fejlesztő ne a cégvezető közös rendszergazdai fiókját kapja meg. Saját, visszavonható hozzáféréssel dolgozzon, a kezdeti adatkapcsolat lehetőleg csak olvasást engedjen. Az ajánlattervezet készítése nem igényel automatikusan számlatörlési vagy árlista-módosítási jogot. A modellhez kerülő szöveget és az adatbázishoz hozzáférő programot külön bizalmi határként kezeljük.

A beérkező levél nem megbízható utasítás. Tartalmazhat olyan szöveget, amely az automatizmust jogosulatlan adatkiadásra próbálja rávenni. Az ügyfél által küldött tartalom ne bővíthesse a program jogosultságát, és ne határozhassa meg, hová küldhet adatot. A levélmellékletek feldolgozása és a naplóba kerülő tartalom is külön ellenőrzést igényel.

Mikor mondhatjuk, hogy kész?

A szerződéshez kapcsolt elfogadási jegyzőkönyv nevezze meg a vizsgált bemeneteket és az elvárt működést. A jó eredmény mellett a biztonságos elutasítás is legyen elfogadási eset. Hiányzó árnál ne szülessen kitalált összeg; elérhetetlen készletrendszernél ne jelenjen meg régi adat frissként.

A kézi folyamatról előzetesen mérjük meg a feldolgozási időt és az utólag szükséges javításokat. A próbánál a tervezet ellenőrzési idejét is számoljuk bele. Ha a generálás gyors, de az értékesítőnek minden sort újra kell keresnie, az időnyereség nem igazolt. Kevés mintából ne vezessünk le éves megtakarítást feltétel nélkül.

Az átadáshoz kell forráskód, telepítési leírás, adatmező-térkép, tesztkészlet, ismert hibák listája és visszaállási út. Külön pont legyen a titkok átadása vagy cseréje, a beszállítói hozzáférés visszavonása és a riasztások címzettje. A dokumentáció használhatóságát az bizonyítja, ha másik kijelölt szakember is végre tudja hajtani a szükséges műveleteket.

Tulajdonlás és fenntartás: még a kezdés előtt

Tisztázni kell, kinél van a kódtár, milyen felhasználási jogot kap az ügyfél, és átadhatja-e a munkát másik karbantartónak. A nyílt forrású függőségek, a beszállító meglévő komponensei és az egyedi fejlesztés eltérő feltételekkel érkezhetnek. Ezeket a szerződés rendezze; az „egyedi fejlesztés” kifejezés önmagában nem elég.

A fenntartási terv nevezze meg az API-változások, a modellcsere és a sérülékeny függőségek kezelését. Legyen világos, hogy a hibajavítás milyen időszakra és terjedelemre szól, mi új igény, és ki fizeti a külső szolgáltatásokat. A havi díj mögött tényleges feladatlista álljon.

A hosszú távú kockázat az egyetlen szakembernél összpontosuló tudás. Ennek csökkentésére nem feltétlenül új álláshely kell: dokumentált átadás, második hozzáértő és a működés rendszeres bemutatása is segíthet. Az FDE-szerep akkor hasznos, ha a projekt után a vállalkozás önállóbban tud működni, és nem marad tisztázatlan, kit kell hívnia a következő hibánál.