Egész éves nyaralás BI riasztással

Képzeljen el olyan üzleti intelligencia rendszert, amely tapintatosan jelzi, ha rendellenességet észlel a vállalat valamely folyamatában. Önnek nincs más dolga, mint időnként ránéznie az okostelefonjára, és átnézni az üzeneteket. Ha minden rendben akkor folytathatja a Mount Everest megmászását vagy tölthet egy újabb koktélt a tengerparton azzal a megnyugtató érzéssel, hogy otthon minden rendben van. Ha pedig baj lesz, akkor arról úgyis kap majd egy értesítést és - függetlenül attól, hogy éppen hol van - be tud avatkozni.

Ugye milyen jól hangzik? Hát még ha hozzáteszem hogy az SQL Server 2012-ben megjelent egy olyan riasztó (Alert) rendszer, amely pont ezt a célt szolgálja. Felcsigáztam?

Nos. Mielőtt felmenne a Wizz Air oldalára foglalni 2 főre egy tengerparti utat (csak oda), hagy meséljek el egy történetet.

Úgy jó 10-12 évvel ezelőtt kísérleteztünk egy ilyen megoldással. A feladat az volt, hogy készítsünk egy olyan rendszert, amely figyelmeztetést küld akkor, ha valami nagyon elmarad a tervtől. A cél pedig az volt, hogy minél hamarabb észrevegyük, ha egy folyamat letért a tervezett pályáról

A kezdeti peremfeltétel valahogy így szólhatott: Ha a terv/tény eltérés > 30% akkor riasztás. Mivel ez a rendszer szól mindenért, ezért módosítottuk a szabályt és belefoglaltuk azt is, hogy csak a nagyobb összegű eltéréseknél küldjön riasztást. Aztán egyes termékcsoportoknál figyelnünk kellett a szezonalítást és csak akkor kellett riasztást küldeni, ha a tervhez képesti eltérést nem a szezonális hatás eredményezte, Aztán külön szabályt kellett kidolgozni olyan termékekre, amelyekre nem volt terv, és még sorolhatnám.

Ugye ismerős az a történet, ahol egy kisfiú sokszor hazudta azt, hogy farkasok támadták meg a nyáját. Aztán amikor tényleg jött a farkas, már senki sem figyelt rá...

Hát valahogy így működött a kísérleti rendszerünk is. Olyan sokszor kiáltott farkast, hogy a végén már senki sem hitt neki. Nem beszélve arról, hogy a végén egy olyan szabályrendszert kaptunk, amely áttekinthetetlen volt már egy informatikus számára is, nemhogy egy üzleti felhasználó számára.

Végül maradtunk az egyszerű színkódolásnál és a vállalat megszokott folyamatainál: Az az üzleti felhasználó, aki legközelebb áll a szakterülethez (aki legjobban ismeri a szakterületet) az monitorozza annak teljesítményét és ő jelenti, ha baj van. Ő ugyanis ritkán kiált farkast, míg a gép sajnos sokszor...

Mi volt a kísérleti megoldással a probléma? 1) a teljes adatbázisban 2) és magasan aggregált szinteken (is) kereste az eltéréseket, és ennek következtében túl sok riasztást generált. Ugyanakkor észrevettük azt is, hogy elemi adatokon, egyszerű mutatószámokra remekül működik. Csak hát akkor nem erre volt igény :-)

Konklúzió

A riasztás egy hasznos BI szolgáltatás. De csak operatív szinten. Ott ahol még egyszerűek a folyamatok, egyszerűek a mérőszámok és egyszerűek a szabályok és a mutatók aggregálatlanok. És ahol a riasztási küszöbértékeket a szakterülethez értő üzleti felhasználó saját maga állítja be, tartja karban csak magának küldve riasztásokat. Mert bár az operatív döntések egyre nagyobb százaléka automatizálható, a stratégiai, vagy az összetettebb döntéshez még ember szükségeltetik.

Úgyhogy sajnos ki kell ábrándítanom: Az egész éves szabadság BI riasztással még várat magára. Viszont ahogy a főnökét ismerem, ő majd felhívja nyaralás alatt, úgyhogy a tengerparton dolgozásból mégis lesz valami...