Adatokból üzleti értéket, kockázatok nélkül

Olvasási idő: 5 perc

Adat alapú megoldásokat szállító cégként ügyfeleinknél gyakran találkozunk egyfajta tanácstalansággal azzal kapcsolatban, hogy egy üzleti probléma Machine Learning (“ML”) alapú megoldásának (vagy akár egy egész cég vagy szakterület adat alapú támogatásának) hogyan is érdemes nekifutni. Az analitikai kezdeményezések egyik legfontosabb alaptulajdonsága ugyanis az, hogy ezek sokszor kísérleti jellegű projektek, sikerük és hozzáadott értékük előre nehezen megjósolható. Éppen ezért, amennyiben nem kellő figyelemmel és nem eléggé módszeresen fogunk hozzá, könnyen kudarcba fulladhat egy ilyen kezdeményezés, és negatív tapasztalatként, pénzkidobásként éghet be az üzleti döntéshozók fejébe. Analitikai projekteken olyan megközelítésre van tehát szükség, ami úgy darabolja fel a megoldás fejlesztési életciklusát, hogy a ráfordított energiát úgy tudjuk fokozatosan növelni, ahogyan egyre garantáltabb az ötlet megtérülése (ROI – return on investment). Tapasztalatunk alapján a legjobb megoldás egy Proof of Concept alapú megközelítés, amit gyakorlatilag adat-érettségtől függetlenül lehet és érdemes használni.

PoC, azaz Proof Of Concept

PoC alatt olyan “mini” projekteket értünk, amelyek gyorsan és olcsón feltárják egy (adat alapú) megoldás megvalósíthatóságát és nem utolsó sorban az üzleti hasznát.

Forrás: techopedia

Sokszor egy adat alapú ötlet nagyon jól hangzik az elméletben: alacsony költségeket és nagy hasznot ígér, így általában magas szinten átgondolva nincs is semmi akadálya a megvalósításnak. Amikor azonban a valóság beköszönt, és jellemzően a fejlesztés már elkezdődött, kiesnek a csontvázak a szekrényből, és a legkülönbözőbb okok miatt végül bedől a projekt (pl. nincs adat, nem jó a minősége, vagy az üzleti jelenség egyszerűen nem modellezhető jól, stb.). Vezetőként nagyon csábító ilyesfajta jó ötletekre a gyors megvalósítás ígérete mellett rábólintani, de sokkal kellemetlenebb azzal szembesülni, hogy a megálmodott ML alkalmazás mégsem hozza azt, amit várunk tőle, ráadásul kidobtunk egy kisebb (vagy akár nagyobb) összeget az ablakon. Az ilyen kockázatok minimalizálására megoldás a PoC alapú megközelítés, amelynek lényege, hogy csak arra fordítunk extra energiát (és ezáltal pénzt), amivel bizonyítottan érdemes is foglalkozni.

Az ML alapú megoldások életciklusa

Az alábbi ábra szemlélteti, ahogy egy ötletből üzleti folyamatokba integrált megoldás születik.

1. 1. Első lépésként képben kell lennünk azzal, hogy milyen adat alapon megoldható use case-ek, üzleti problémák vannak a szervezetben. Ha ezek nincsenek összegyűjtve, akkor érdemes visszalépni egyet, és átgondolni a cég működéséhez kapcsolódó főbb megoldandó problémákat (pl. költségek csökkentése, ügyfelek lemorzsolódásának megállítása, margin növelése, stb.). A problémáktól kiindulva tesztelhető ötleteket (hipotéziseket) gyűjthetünk, például ügyfél adatok és múltbeli viselkedési mintázatok felhasználásával meghatározható, hogy mely ügyfelek kockázatosak lemorzsolódás tekintetében.
   2. Szektortól függetlenül jellemző, hogy több olyan üzleti probléma is lesz, amelyre adat alapú megoldás elképzelhető, de az összes ötlet megvalósítására nincs kapacitás. Az ötleteket ezért priorizálni kell, azaz meg kell határozni, hogy mely ötlet(ek)re érdemes leginkább PoC projektet indítani. Tapasztalatunk alapján nincs gátja annak sem, hogy több PoC fusson párhuzamosan (ha megvan a kapacitás, vagy pl. több beszállító kipróbálása a cél), azonban számolni kell azzal, hogy ezek a szálak egymástól függetlenül futnak. Ennek nagy előnye, hogy egyszerre több csalit lógatunk a vízbe, így nagyobb eséllyel könyvelhetünk el sikert, ugyanakkor nyilvánvalóan a figyelem megoszlik, ezért a rendelkezésre álló kapacitások függvényében érdemes dönteni a párhuzamosításról. Érdemes a priorizálásba a gyorsaságot is szempontként beemelni, azaz azokra az üzleti esetekre PoC projektet definiálni, ahol viszonylag gyorsan validálhatjuk egy analitikus megoldásban rejlő lehetőségeket és buktatókat.
   3. Amennyiben a PoC sikeresnek bizonyul, azaz az ötlet ki lett próbálva és hozza a várt hasznot, érdemes tovább menni az implementáció irányába, és az eredményeket beépíteni a mindennapi működésbe. Abban az esetben, ha a PoC alapján az alapfeltevés nem igazolódik be, álljunk meg és vonjuk le a konklúziókat, ne öljünk több erőforrást az ötletbe.

   A kockázatmentességet tehát a szakaszolás biztosítja: csak azt az ötletet implementáljuk, amelynek a PoC alapján van értelme. 

   Mi a kockázatok csökkentésében sokszor ennél is tovább megyünk, és a PoC projekt harmadánál egy GO/NO-GO döntésre kerül sor. Az adat alapú megoldásokkal való próbálkozás folyamatát megkönnyíti, és a kockázatokat csökkenti, ha az alábbi döntési fán vezetjük végig ötlettől a megvalósításig a use case-t.

A metodológia alapelvei:

1. Tervezés – Egy ötlet PoC-ra való kiválasztásra ténylegesen fordítsunk időt, kimondottan az adatok elérhetősége és minősége szempontjából ellenőrizzük a megvalósíthatóságot.
2. Eszköztár – Nincs szükség felhőben levő adattárházra, sem homokozóra, viszont jó minőségű és kellő mennyiségű adatra igen.
3. Nyitottság – Kiemelten fontos, hogy a szervezet nyitott legyen egy ilyen megoldásra, és ne támadásnak vegye a szakértő, hogy egy “gép mondja meg” azt, amit eddig ő mondott.
4. Szakértelem – Érdemes az üzleti tudás felszívásakor a szakértőket bevonni, segítséget kérni és nem megversenyeztetni őket egy algoritmussal.
5. Tanulságok – Ha nem lesz sikeres egy PoC, vonjuk le a következtetéseket és építsük be a következő ötletbe.
6. Több próbálkozás – Ha tehetjük, próbáljunk ki többféle problémát is (pl. predikciót, optimalizálás, anomália detektálást, stb.)
7. Feszültségek – Legyünk felkészülve arra, hogy egy-egy új megoldás régi folyamatokat kiválthat, ezeknek a változásoknak a kezelésével számolni kell.
8. Egyszerűség – A motiváció fenntartása és az elvárások kezelése érdekében kezdjünk először egy könnyebb, várhatóan sikeres ötlettel, és a rizikósabb ötletekkel csak ezt követően foglalkozzunk.

PoC elleni érvek, nehézségek

Bár nagyon sok érv szól aa PoC megközelítés mellett, néhány ellenérvet is érdemes kiemelni:

1. Nem lehet örökké csak PoC-olni. Fontos, hogy az adatos “projekt-tölcsérünk” egészséges legyen, és integrált adat-alkalmazások is szülessenek, ne csak kísérletezzünk. 
2. Skálázhatóság. Nem mindig egyértelmű, hogy egy sikeres PoC projekt hogyan skálázható fel egy implementált megoldássá. Ezt a szempontot már a megvalósítás kezdeti szakaszától figyelembe kell venni.
3. Túlzó elvárások kezelése. Fontos, hogy a folyamatban résztvevő szakértők és üzleti döntéshozók tudják azt, hogy mit várhatnak. A PoC eredménye nem egy éles megoldás, nem egy klasszikus projekt, és a pénzügyi haszon realizálása tipikusan a PoC-ot követő projektre esik. A PoC-ot nem szabad automatikusan üzemi megoldásnak tartani.
4. Rá kell szánni az időt. Tény, hogy egyik előnye a PoC-olásnak, hogy gyors, de ez nem jelenti azt, hogy össze lehet csapni. A PoC komplexitásától függően az átfutása 2 héttől akár fél évig is tarthat, a tipikus átfutás a tapasztalatunk alapján 10 hét. 
5. Buy-in. A kapcsolódó üzleti terület elköteleződése és motivációja nélkül nem lehet egy adat alapú megoldást sikeresen kialakítani.
6. Hasznok számszerűsítése. Sokszor nem egyértelmű a lehetséges hasznok pontos kimutatása (pl. egy be nem következett esemény miatti megtakarítás). Az alapos és fair visszamérésre és kiértékelésre rendszerint jelentős energiákat kell allokálni. 

Szerzők:
Biró Szabolcs – Head of Advanced Analytics
Matzon Ákos – Advisory Team Leader