Backendtermék · Capability-portfólió
Válaszd le az ügyfélutat,ne az üzleti célt.
A Customer Data Platform teljes termékfelelőssége hozzám tartozott, valamennyi moduljával együtt. Röviden: leválasztottuk az ügyfélutakat a legacy backendekről, miközben érdemben felgyorsítottuk a profiladatok elérését.
- Szerepkör
- Backend Product Owner
- Időtartam
- 2022. máj. — 2023. okt.
- Mérföldkő
- A teljes termék leszállítva
Kövesd a capabilityt,
ne a legacy topológiát.
Az ügyféladatoknak összetett legacy backendekből gyorsan változó frontend use case-ekbe kellett eljutniuk. A közvetlen függőségek lassították a változtatást, növelték a komplexitást és nehezítették az egyenletes teljesítményt.
GET /profileStabil, use case-alapú szerződésCélérték <20 msOmnichannel kiszolgálás
Egy capability.
Három frontendcsatorna.
Ugyanaz az ügyfél-capability szolgálta ki a natív mobilalkalmazásokat, a webes ügyfélutakat és a Telekom üzletek belső platformjait. Minden csatorna stabil szerződést használt, miközben a CDP a termékhatár mögött kezelte a legacy backendek közötti különbségeket.
Minden első, legacy backendből kiszolgált profillekérdezés egyben migrációs lépés is volt. Miután az ügyfél adatai bekerültek a CDP-be, a további lekérdezéseket már a CDP szolgálta ki, a legacy backend újbóli meghívása nélkül.
A termékdöntés
Egy proxy továbbadja a komplexitást.
Egy capability layer a saját határain belül kezeli.
A program egy AWS-en futó, legacy szolgáltatásokhoz kapcsolódó API-gyűjteményből álló Customer Data Platformot vezetett be. A natív mobilalkalmazásoknak, webes ügyfélutaknak és a Telekom üzletek belső platformjainak úgy kellett stabilan és biztonságosan elérniük az ügyfél-capabilityket, hogy közben ne kelljen ismerniük vagy kezelniük a backendek összetettségét.
A réteget tartós üzleti capability-k köré szerveztük a legacy rendszerstruktúrák leképezése helyett.
A frontend use case-ekből indultunk ki az endpoint-portfólió kialakításakor, így az API-szerződések a tényleges felhasználási igényekhez igazodtak.
A válaszidőt, a napi kérésszámot és a titkosítást termékkövetelményként kezeltük, nem pedig utólag ellenőrzendő technikai szempontként.
A Customer Data Platformot és a REST API-kat használtuk határként a csatornák és az alaprendszerek között.
Az architektúrát is konkrét termékkövetelmények keretezték.
A legacy források eltérő struktúrákban és működési modellekben tették elérhetővé az ügyféladatokat.
A rétegnek naponta több millió kérést kellett kiszolgálnia.
A válaszidő-elvárásokat milliszekundumokban mértük.
A titkosításnak, a helyben futó komponenseknek és a felhőszolgáltatásoknak egységes end-to-end architektúrában kellett együttműködniük.
- A Telekom üzleteiben több mint 75%-kal csökkent az első ügyféladat megjelenéséig eltelt idő.
- A teljes profil betöltési ideje 60%-kal csökkent, felgyorsítva az ügyintéző által támogatott folyamatokat.
- A vezetékes szerződéssel rendelkező ügyfelek My Profile betöltési ideje appban és weben egyaránt 40%-kal javult.
- Lehetővé tettük a vezetékes és mobil szerződések, ügyfélprofilok és szerződő felek különböző domainek közötti összerendelését.
- A profilmigrációt a valós használathoz kötöttük: miután az első, legacy backendből kiszolgált lekérdezés feltöltötte a CDP-t, a további kéréseket már a CDP szolgálta ki a legacy backend újbóli meghívása nélkül.
- Naponta több millió kérést szolgáltunk ki 20 ms alatti válaszidő-céllal és vállalati szintű titkosítással.
A megfelelő leválasztási határ termékdöntés: a capability-k akkor maradnak értékesek, ha az ügyfél- és üzleti szándékot képviselik, nem a tegnapi rendszerek formáját.
Megjegyzés az eredményekhez · Az ügyféljourney- és teljesítményadatok a megadott projekteredményeket tükrözik; a saját szolgáltatástopológia absztrakt formában jelenik meg.
Kezdjünk beszélgetést
Találjuk meg, mit
érdemes megépíteni.
Szívesen beszélgetek összetett product ownershipről, üzleti elemzésről, beszállítóértékelésről és olyan kezdeményezésekről, ahol valódi együttműködésre van szükség az üzleti és a fejlesztői oldal között.