Ne veszítsünk irányt: saját döntéstámogató programunk elkészítése [1. rész]
1967. április 24-én, fedélzetén Vlagyimir Mihaljlovics Komarov űrhajós ezredessel, a Bajkonuri űrrepülőtér indítóállomásáról elstartolt az első Szojuz (szövetség) űrhajó, mely eszközök generációi ettől fogva csaknem 50 éven át biztosították, hogy közelebb kerüljön az emberiség a csillagokhoz. Az űrhajó döntéstámogató berendezései közül az egyik legmegragadóbb a Space Navigation Indicator, vagy röviden Glóbusz. Egy mechanikus számítógép amely Gagarin első űrrepülésétől egészen 2002-es(!) nyugdíjazásáig lényegében változatlan formában működött. Csak a kontextus miatt: Steve Jobs öt évvel később, 2007-ben mutatta be az Iphone első generációját.
A szerkezet a földgömb forgatásával mutatta az űrhajó helyzetét a fix célkeresztben, információt adott mikor kerül az űrhajó árnyékba, illetve napfénybe, ezzel segítve a dokkolás időzítését, valamint számolta a földkerülések számát. Egy további funkció pedig különösen érdekes: a módválasztó kapcsoló elforgatásával az űrhajósok egy adott hibahatáron belül képet kaphattak a landolás várható helyéről.
Ez a mérnöki alkotás volt egyike az első igazi döntéstámogató eszközöknek, melyek előrejelzést végeztek változtatható bemenő paraméterekkel, és történetével példát állít saját döntéstámogató rendszerünk elkészítéséhez.
Igényfelmérés és elemzés
Adatelemzői fogalomkörben hasonlóan a Glóbuszhoz a döntéstámogató eszköz olyan célszoftver, amely képes heterogén forrásokból származó adathalmazokat integrálni, azokat tisztítani, és valós időben elemzéseket végrehajtani változó bemeneti adatokkal és eltérő modellezési megközelítésekkel. Végül pedig az eredményt képes kontextusban megjeleníteni, és informálni a lehetséges “forgatókönyvek” várható hatásáról.
Ezek a használatot érintő fogalmak egészülnek ki nem funkcionális szempontokkal. Ilyen a gyors adatfeldolgozási képesség, adatbiztonság, karbantarthatóság, elérhetőség, kompatibilitás és dokumentálás.
Vegyünk ezen a ponton egy konkrét logisztikai problémát, aminek feloldását megkíséreljük egy ilyen eszköz üzembe helyezésével.
Kedves Adatcsapat!
Minőségbiztosítási és pénzügyi csapatunk visszajelzése alapján a szokásoshoz képest drasztikusan megemelkedett a frissáru túlkészletből fakadó hulladék mennyisége, mely a teljes értékláncon többletköltséget eredményez. Vizsgáljátok meg a “root cause”-t, és konzultáljunk a mielőbbi megoldásról.
Első lépésben határozzuk meg a megoldandó üzleti problémát, a jelenlegi helyzetet és a kívánt végállapotot, illetve a probléma megoldásához használni kívánt eszközt. Egyúttal érdemes az értékteremtés, mint transzformációs lépesek sorozatát is megvizsgálni, mivel ennek megértése sokszor elvezet az alapvető probléma meghatározásáig.
Ehhez jó alternatívát kínál a BPMN módszertan használata.A Business Process Model and Notation 2.0 egy szabványosított grafikus jelölési rendszer, amelyet üzleti folyamatok modellezésére és dokumentálására használnak. Célja, hogy áthidalja a szakadékot az üzleti folyamatok tervezése és azok technikai megvalósítása között, lehetővé téve a különböző érdekeltek számára, hogy könnyen megértsék és kommunikálják a folyamatokat.
Áttekintve a részfolyamatokat egyeztetve a területek felelőseivel, végül több lehetséges magyarázó tényezőt tudunk azonosítani:
- Manuális adatfeldolgozás több szinten.
- Egyedi, nem validált modellezési módszerek.
- A tervezők és adatspecialisták közötti kommunikáció nem elégséges.
- Lineáris folyamatok működése párhuzamosítás helyett.
- Adatok továbbítása csatolmányként. Redundancia, elavult adatok kockázata.
A lehetséges problémakeretet tanulmányozva képesek leszünk kiválasztani a valódi okot és meghatározni mennyire generális jelenségről van szó. Figyeljük meg a garbage in - garbage out elv érvényesülését: a hibás adatok miatt téves előrejelzés készül, eltérítjük a pénzügyi kalkulációt, és hibás döntésekkel rossz visszacsatolással reagálunk a piaci változásokra, tovább erősítve a problémát egy újabb logikai körben. Ezen fogunk most változtatni.
A root cause elemzés során feltártuk, hogy az akkut túlkészletezés oka két visszatérő eseményre vezethető vissza. Egyrészt, több esetben előfordult, hogy nem a legfrissebb adathalmaz került továbbításra a folyamat kezdeti szakaszában, illetve több esetben a feladat komplexitásához mérten kevésbé hatékony előrejelzési módszerek kerültek felhasználásra. Javaslatunk az üzleti folyamatok áttervezése, és egy, a részfolyamatokat integráló elemző alkalmazás bevezetése.
Az áttervezett üzleti folyamat egy döntéstámogató alkalmazással egészül ki, melyen keresztül a tervezők közvetlenül hozzáférnek a szabályok szerint tisztított és elemzésre felkészített adatokhoz. A szoftver lehetőséget teremt a skálázhatóságra, ezzel reagálva a piaci környezet gyors változására, ugyanakkor tervezők ezt validált módon lesznek képesek alkalmazni. A lineáris folyamatok helyett az elkészített előrejelzéshez azonnal hozzáfér a pénzügyi és operatív csapat, csökkentve a felesleges manuális adatátvitelt. Ezen túlmenően, az adatelemzői és tervező csapat szorosabb szervezeti egységben fog a továbbiakban működni, elősegítve a hatékony kommunikációt.
Foglaljuk össze hol tartunk: Definiáltunk egy gazdasági problémát, meghatároztuk annak okát, felmértük a jelenlegi működést, azonosítottuk az eredeti kiváltó problémát, és tettünk egy javaslatot annak megoldására.
Munkafolyamatok és a szakértői tudás felelőssége
A következő lépés, az üzleti folyamatok egészébe való beépíthetőség kérdése. Csak akkor érdemes továbbhaladni ha látjuk, munkánk eredménye nem csak helyettesít egy problémát egy másik, éppen megoldandóval.
Közelítsük meg a döntéstámogatást más szemszögből: készítünk egy applikációt, ami egy szakértő tudását, legyen az akár sajátunk, csomagolja be és adja át, hogy ez a tudásmag bármikor elérhető legyen. Beleértve későbbi önmagunkat is. Ennek belátásával a felelősség is sokszorozódik. Egy többek által, naponta használt eszközben rejlő hiba sokszorosan felülmúlja egy-egy önállóan működő Excel tábla hatósugarát. Ha nem csak magunk számára készítünk egy alkalmazást, gondoskodnunk kell arról hogy a szervezet működésébe való illesztés, a tudásátadás felelőssége, és a reziliens működés biztosítása valóban pozitív hatású legyen, és semmi esetre se okozzunk kárt. Egyik legfontosabb eszköz ennek kivitelezésére egy átfogó tesztelési politika végrehajtása, ennek tárgyalása túlmutat a bejegyzés keretein.
Váltsunk most fókuszt és közelítsünk rá a BPMN diagramon “ Forecast Oracle” egységére, és írjuk le annak működését.
A gazdaság változó hatásait az ábra szerint rögzítjük adatbázisunkban, ahhoz alkalmazásunk hozzáfér, mely rendelkezik olyan modellezési képességgel, ami kibővíti és támogatja a felhasználó tudását. A felhasználó/szakértő ennek alapján ellenőrzött módon adott körülmények között a optimalizálja döntését melyen keresztül visszahat a gazdasági folyamatokra. Ezt a logikai kört járjuk be akár percenként automatizálás esetén, vagy naponta egy klasszikus jelentési szituációban.
Következő lépésben definiálnunk kell a pontos igényeket és elvárásokat a bevezetésre kerülő szoftverünkkel kapcsolatban. Ehhez a klasszikus USE CASE diagram egy módosított formáját használom. Szürkével jelölöm az applikációt, eltérő színnel a kapcsolódó felhasználókat, illetve azonosítom az igényeket, melyeket a program egy-egy funkciója fog megválaszolni. Érdemes már itt priorizálni, mik azok a megoldandó problémák, amik elsődlegesek és határidőre teljesíthetők “Scope 01.” típusúak.
A tervezés utolsó szakaszában pedig érdemes kiemelt hangsúlyt helyezni a végfelhasználókkal való kommunikációra, megvizsgálva hogyan szeretnék ezeket a funkciókat használni a mindennapokban. Egyszerűen fogalmazva hogy nézzen ki az a kezelőfelület aminek használata minden érintett számár kényelmes és egyértelmű. Ehhez érdemes a program grafikus felületét (GUI) ábrázolni és akár egy-egy kávé mellett megvitatni az elvárásokat. Mivel a tervezés iteratív folyamat, fel kell készülni egy korábbi tervezési fázisba való visszalépésre is: ne feledjük a legdrágább az a szoftver amit nem használunk…
Kis programunk ebben a fázisban először kezd fizikálisan is alakot ölteni. Összhangban a felhasználói igényekkel, áttervezett üzleti folyamattal, és az infrastruktúra stabil lehetőségeivel meg tudjuk alkotni azt az interfészt mely napi szinten ki fogja szolgálni az értékteremtést. Helyet kaptak a beviteli mezők, melyek lehetővé teszik az adaptív működést, és skálázhatóságot. Gombnyomásra egy előre definiált függvény betölti az adatelemző csapat által tisztított adatokat, a változók elmentése után pedig a motorháztető alatt egy adatelemzők és tervezők által definiált matematikai modell elvégzi a számítást, majd pedig automatikusan megjelenik a grafikus és szöveges eredmény. A beviteli mezők rendelkeznek egy elfogadott standard értékkel, mellyel az elemzés az elfogadott szabályok mentén újra elvégezhetőek. Ezen kívül a program szerkezetét úgy tervezzük, hogy kis idő és költségráfordítással megoldja a “Scope 02.” elvárásokat is.
A terezőasztalon elvégeztük az üzleti elemzés területével rokon feladatokat. Készen állunk arra, hogy elkezdjük a valóságban is felépíteni a kódot, majd pedig tesztelés után megadjuk az engedélyt a repülésre. Erről fog szólni a sorozat második része: benézünk alaposan a motorháztető alá.
Addig is ajánlom az alábbi YouTube videót, ami részletesen bemutatja a Glóbuszt, és egy példányának restaurálását.
Utószó
A bejegyzés nem lenne teljes ha nem említeném meg Komarov ezredes teljes történetét. Tragikus, de az első Szojuz űrhajó visszatérésekor ejtőernyő hiba miatt Komarov életét vesztette, így ő lett az első űrfelfedező aki életét adta hogy az emberiség egy lépéssel majd később egy ugrással is előrébb kerüljön.
