Skip to content

Hogyan gondolkozik egy Data Scientist, ha üzleti problémával találkozik?

Olvasási idő: 4 perc

Egy data scientist számára fontos, hogy megértse a tágabb üzleti kontextust, amibe az elemzése illeszkedik, és képes legyen a megfelelő kérdésre a megfelelő adatalapú választ adni. Az eredményének üzleti relevanciája és biztos módszertani háttere együttesen biztosítja azt, hogy egy projekt hosszútávon is üzleti értéket tudjon teremteni.

Analitikai projektjeink többségén nem ül data scientist a megrendelői oldalon, így ránk hárul annak a felelőssége, hogy az eredményeinket érthető formába öntsük. Ilyenkor az egyszeri elemzőnek kifejezetten nehéz dolga van, hiszen bele kell helyezkednie az üzleti oldal gondolkozásába. Ideális esetben az elemző és a megrendelő már a projekt kezdetén elkezd összecsiszolódni: az elemző megérti, hogy a projekt milyen értéket tud teremteni, a megrendelő pedig felismeri, hogy mik azok az információk, amire az elemzőnek szüksége van.

A megfelelő kommunikáció olyannyira fontos, hogy sokszor egy projektben erre külön embert is dedikálunk. Erről, “Analytics Translator – Egyfelől kocka, másfelől zseniális kommunikátor, az üzlet és az IT terapeutája” címmel egy Somos Eszterrel készült interjú olvasható blogunkon. Én, klasszikus elemzőként, egy kicsit más szemszögből közelítem meg a témát.

Ki gépen száll fölébe

Jellemző különbség üzleti és informatikai emberek között, hogy míg az előbbi inkább absztraktabb célokban gondolkozik, úgy az utóbbinak pontos definíciók szükségesek a munkájához. Ebből a szempontból egy data scientist valahol a kettő között helyezkedik el, de az üzleti oldaltól mindenképp elég távol ahhoz, hogy a kettejük közti kommunikáció kihívást jelentsen. Egyfelől az elemzőnek meg kell értenie a magas szintű üzleti célt is, másfelől viszont a részletekre is szüksége van.

Vegyünk egy egyszerű példát: az üzletfejlesztésért felelős megrendelő szeretné előre jelezni egy beruházás megtérülését. Ahhoz, hogy ezzel egy elemző el tudjon kezdeni dolgozni, tudnia kell, hogy mit jelent pontosan a megtérülés, hogyan számolható ki a korábbi projektek megtérülése, illetve mik azok az információk, amik felhasználhatók az előrejelzéshez. Ugyanakkor az nem várható el, hogy a megrendelő magától gondoljon mindenre, ami az elemzéshez szükséges. Ezért jó, ha az elemző is tisztában van az üzleti igénnyel, mivel így eszébe juthatnak további kérdések vagy buktatók, illetve teljes biztonsággal tud meghozni olyan elemzői döntéseket, amihez a tágabb kontextus hiányában üzleti segítség kellene.

Az igazat mondd, ne a valódit

Fő szabály szerint igyekszünk minél hamarabb minél értékesebb eredményeket szállítani. Ezek eleinte lehetnek egyszerű statisztikák, vagy egészen partikuláris eredmények (hé, Borsodban egészen kitűnő 2018-as eladásokat produkáltatok, tudjátok, hogy miért?). Ahogy halad előre az idő, egyre több és komplexebb elemzési eszközt vetünk be a mintázatok feltárására, és így lesz egyre nehezebb dolgunk azoknak az elmondásával. Ilyenkor egy szűk mezsgyén egyensúlyozunk, ahol az egyik oldalon a teljes érthetetlenség fenyeget minket, a másikon pedig az őszintétlenségnek az a kellemetlen érzése, amit a túlegyszerűsítés okoz. A teljes képhez mindig hozzátartozik egy csomó feltételezés, kiegészítés és megjegyzés, amik mind hozzáadnak az igazsághoz, de nyilván nincs értelme belefoglalni az egészet egy negyvenöt perces prezentációba.

Míg egyik oldalról cenzúrázni kell a technikai részleteket, a másik oldalról pedig hozzá kell rakni azokat az üzletileg fontos és hasznos mondásokat, amik módszertani szempontból mellékterméknek tűnnek. Így kerül a keresztvalidációs stratégia hosszas ismertetésének a helyére egy ábra az eladások országok közötti megoszlásáról. Ezért használjuk a modellezés minőségének mérésére az átlagos (abszolút) hibát, amit egy statisztikus magától biztosan nem használna. Ideális esetben egy záróprezentáció minden egyes száma és eredménye mögött több fontos módszertani döntés áll.

Az elemzői projekteknek mindig két végeredménye lesz: egy, amit az ügyfélnek mutatunk, és általunk hasznosnak vélt eredményeket jelenít meg, és egy másik, amelyik az eredményeket támasztja alá, és az ehhez szükséges technikai részleteket tartalmazza. A két eredmény együttesen biztosítja azt, hogy egy projekt hosszútávon is üzleti értéket tudjon teremteni. Ha az üzlet felé mutatott eredmények szépek, de a technikai részletek nincsenek rendben, akkor az elemzésre alapozott döntések nem lesznek optimálisak. Ha a módszertani háttér kerek, de hiányoznak az üzleti meglátások, akkor az eredményeket nem fogják átültetni a gyakorlatba.

Szerző:
Szokolics Dániel – Data Scientist

Other posts