Az alább található cikk egyike a BA KARAKTER Magazin első számában megjelent üzleti elemzők és projektszereplők által megosztott, izgalmasabbnál izgalmasabb témájú cikkeknek.
Olvassátok sok szeretettel Papp Gergely írását:
„A jól hangolt Business Analyst” könyvet olvasók kiváló összefoglalót kaphatnak azokról a feladatkörökről, amiben az Üzleti Elemzőnek meg kell nyilvánulnia a munkája során. Emellett olvasható benne az is, hogy milyen területekkel kell kapcsolatokat ápolnia. Jól bemutatásra kerül benne továbbá az is, hogy ehhez az Üzleti Elemzőnek be kell tudnia azonosítani a munkáját befolyásoló különböző stakeholdereket. Ebben a cikkben az Üzleti Elemzővel kapcsolatba kerülő különböző Architectek szerepet igyekszem röviden megvilágítani.
A projektekkel kapcsolatos szerepkörlistában említése kerültek a Solution és Enterprise Architect szerepek, amelyek vállalatban és projektekben betöltött szerepét igyekszem most a tradicionális felosztás bemutatásával egyértelműbbé tenni. Bár ezek a szerepkörök alapvetően jól lehatároltak és feladataik egyértelműen definiálhatók, manapság az ellátott funkciók már gyakran szóródnak szét szervezeten belül és esetenként teljességgel hiányoznak a betöltésükhöz szükséges képességek.
Az egyik hagyományos felosztás szerint az üzleti és az IT területek funkciói RUN, CHANGE és gyakran háttérbe szoruló GOVERN kategóriákba kerülnek besorolásra.
Ez segít abban, hogy a napi üzleti és informatikai működéshez szükséges feladatok (RUN) elkülöníthetőek legyenek az üzleti eredmények javítását célzó (CHANGE) változásoktól, továbbá a stratégiai irányok és a hosszútávú célok megvalósítását célzó tervezési és kontroll (GOVERN) tevékenységektől.
Ezzel az egyszerű felosztással viszonylag jól lehet priorizálni egy vállalat munkáját: a RUN jellegű tevékenységek kiesése jellemzően azonnal jelentkezik az eredményben, a CHANGE jellegű tevékenységek rövid-középtávon vannak kihatással egy cég nyereségre, míg a GOVERN jellegű feladatok hosszú távú fennmaradás és fejlődés céljait szolgálják.
Az üzleti és az IT oldali RUN tevékenységek akár teljesen elkülönülhetnek egymástól, mivel az üzlet elsősorban az üzleti folyamatok zökkenőmentes futásával, míg az IT oldal a technológiai képességek rendelkezésre állásának biztosításával foglalkozik.
Ha ilyen szempontból vizsgáljuk a munkáját, akkor az Üzleti Elemző amikor egy projekten dolgozik, akkor az üzlet oldalán levő CHANGE pillérből vizsgálja az aktuális üzleti folyamatot (RUN) és tervezi ennek átalakítását. Ennek keretében működik együtt a rendszerszervező szerepkörrel, aki pedig az IT RUN pillért változtatja.
Irányítási (GOVERN) szempontból az Üzleti Elemző munkáját projektvezető és az üzleti szponzor határozza meg és az Üzleti Architect felügyeli.
Az Üzleti Architect lenne elsősorban felelős a változás kezdeményezéséért, és figyelne oda a vállalati célok követésére és a kitűzött üzleti eredmények elérésére. A szervezeti szerepek összemosódása miatt, gyakran fordul elő, hogy az önálló pozícióként nem létező, Üzleti Architect szerepet is az Üzleti Elemző látja el. Ilyenkor okozhat nehézséget az, hogy a szerep hatékony betöltéséhez szükséges döntési hatáskör hiányzik, ami miatt azokat olyan nem szakmai, hanem szervezeti vezetői szerepek bevonásával lehet csak meghozni.
Ez nem lenne rossz megoldás, de egy szűk területért felelős szervezeti vezető gyakran nem ugyanazon az időtávon és szervezeti célokban gondolkodnak, mint azt egy Architect tenné.
Az IT oldali governance felelőseként a Solution Architect szintén elsősorban a change pillérben dolgozik. Feladata, hogy a változtatott üzleti tevékenységek a megfelelő informatikai rendszerben legyenek megvalósítva. Emellett gyakran ez a szerepkör hangolja össze a rendszerspecifikus ismerettel bíró rendszerszervezők munkáját is.
Kezében összpontosul az az informatikai területi ismeret, amely segít meghatározni, mely üzleti képesség mely informatikai rendszerben van megvalósítva és ő az, aki a projekt által indukált változásokat elhelyezi a jövőbeni térképen. A vállalati rendszerek komplexitása miatt ez a szerepkör szerencsére egye gyakrabban ténylegesen létezik, ahol viszont kisebb a rendszerek száma és komplexitása, ott akár egy jó rendszerszervező is el tudja látni a feladatot.
A szerepkörből jól látszik, hogy a változtatási projektek elején, még az üzleti scope-tisztázás során szükséges megtalálni a kapcsolatot a szervezetben a területért felelős Üzleti és Solution Architectekkel.
Ugyanis nem csupán az érintett rendszerek azonosításában fognak segíteni, de segítenek a megvalósítható és megvalósíthatatlan üzleti igények értékének komplexitásának és erőforrásigényének a meghatározásában.
A projekt végrehajtási fázisában architectek bevonása általában már csak akkor válik szükségessé, ha a nagyobb változások adódnak az eredeti tervekhez képest, hiszen nem feltétlenül rendelkeznek alacsony szintű ismeretekkel a megvalósításnál felmerülő kérdések megválaszolásához.
De hol vannak az Enterprise Architectek?
Hagyományos szerepkörökből felállított hierarchia esetén, Üzleti Elemzőként az Enterprise Architect szereppel, nem is kellene kapcsolatot tartani, hiszen a munkához kapcsolódó összes információ elérhető és döntés meghozható a projektbe bevont munkatársakon keresztül.
Az EA-k kicsit olyanok egy szervezeti hierarchiában, mint töltött tojás tetején a kaviár. A hivatalos receptkönyv szerint szükségesek lennének a minőségi megjelenéshez és ízprofilhoz, de kisebb éttermekben az ára miatt mással helyettesítik, vagy teljesen elhagyják az alkalmazását, ha pedig mégis odakerül, akkor sokan nem kérnek belőle csak lepiszkálják a tányér szélére.
Még azokban a cégek is, ahol létezik a szerepkör, a hatáskörük a szervezet aktuális vezetésének akaratától függően jelentősen eltérhet. Ez a szerep jellemzően nagyobb, nemzetközi szervezetek és erősebben kontrollált üzletágak esetén kap jelentőséget. Olyan helyeken, ahol több száz egymással integrált rendszer együttesét kell felügyelni és a szervezetet időről-időre auditálják is. Így ilyen szereplők főként banki és telekommunikációs cégekben, valamint az energiaszektorban jelennek meg.
Az Enterprise Architect szerepkörnek a vállalat érdekeit figyelembe véve, stratégiai szinten kell gondolkodnia.
A felelősségi körükbe tartoznak a következők:
- Nyilvántartások kezelése, úgymint: üzleti folyamatok, alkalmazások, integrációk, adatok, infrastruktúra és összefüggéseik
- Architektúra változásokat érintő folyamatok meghatározása, minőségbiztosítása
- Üzleti stratégiának megfelelő tervek kidolgozása
- Üzleti szintű stabil állapotok, platók meghatározása a teljes változási portfólió vonatkozásában
- Minőségi elvek meghatározása, például technológiai irányelvek, modellezési irányelvek, valamint azok minőségbiztosítása
- Végül pedig részvétel nagyobb transzformációk, tervezésében és stratégiai irányításában.
Mit mutat a gyakorlat?
Mint látszik, ideális esetben az EA nem kifejezetten, illetve kizárólagosan informatikai szereplő. A feladatköréből adódóan a teljes vállalati működésre rá kell lásson. Ideális esetben kezében futnak össze az üzleti folyamatokat nyilván tartó modellek is, aminek tekintetében ők határozzák meg annak mélységét és felügyelik annak minőségét. Mivel nem csupán tervezési, de üzleti és IT kontroll funkciókat is ellát, a szerep helye nem az informatikai, hanem az operatív vezető alatt lenne. Erre azonban nagyon kevés helyen van példa. Így amennyiben a szerepkör amúgy fel van hatalmazva arra, hogy valós kontrollt gyakoroljon az üzleti és az IT változások felett is, az a furcsa helyzet állhat elő, hogy az IT vezetőt megkerülve közvetlenül egyeztet az üzleti vezetőkkel, sőt beleszólhat az IT vezetői döntésekbe is.
Hagyományos, katonásan hierarchikus szervezetekben ebből adódhatnak civakodások, amelynek a kimenetele a terület szárnyainak megnyirbálása lehet.
A gyakorlatban azonban az EA-knak nem ilyen aktív a szerepük, hanem egy lényegesen szűkebb, reaktív működésre kényszerülnek, sőt szerepük különböző módon más szereplőkre ruházódhat át.
Így gyakran találkozni olyan szervezeti struktúrával, ahol Chief Architectként magas szintű tervezés és kontroll funkciót tölt be egy dedikált szakember. Ő közvetlenül irányítja a Solution Architecteket, de inkább reaktív módon foglalkozik a felmerülő problémákkal, hiszen nem fog egy tudni egy teljes vállalati portfolióval teljes mélységben foglalkozni.
Előfordulhat olyan felállás is, hogy az üzleti terület feldarabolásával néhány kiemelt Domain Architect felelős a teljes cég tervezéséért, akik EA és Solution Architect feladatokat egyszerre látnak el. Ilyen esetben többnyire az átfogó stratégiai távlati tervezés, valamint az egységesítés és minőségbiztosítási feladatok szokták megsínyleni a spórolást.
Talán a legkevésbé követendő az, a sok helyen megfigyelhető gyakorlat, hogy az alapvetően szervezeti vezetésért felelős CIO, akár egy szakmailag erős CTO-val karöltve, próbálja az Enterprise Architect feladatokat is ellátni. Ebben a felállásban az operatív vezetői fókusz és a stratégiai lencse közötti váltogatás miatt, nem biztos, hogy élesen fog kirajzolódni a követendő irány, a minőség még abban az esetben sem lesz optimális, ha a vezető történetesen tényleg ért az Enterprise Architect szakmához.
Mit csinálhat egy Üzleti Elemző?
Egy Üzleti Elemző bárhol is dolgozik, meg kell találnia, hogy kik azok, akik az adott üzleti projekt szkópjához kapcsolódó EA feladatokat ellátják. Mert ezek akár egy szervezeten belül is teljesen eltérhetnek.
Vegyünk példának egy fiktív űrrepülőgép-alkatrészt gyártó céget! Mivel működésük során számos minőségbiztosítási szabványt kell követnünk, és rendszeresen auditálják őket, a gyártáshoz, logisztikához, beszerzési folyamataikhoz kapcsolódóan minden jól dokumentált és rendezett. Egy új online értékesítési felület kialakítását célzó projektet indítanak, ami a cég az eredeti profiljából származó kókuszdió-habosító gépek forgalmazását hivatott a modern korba emelni.
Az üzleti elemző belekerülhet egy információs vákuumba, hiszen hiába termel az ágazat profitot, senkinek nem tűnt fel eddig, hogy az ezt működtető folyamatokra és nyilvántartó rendszerekre nem terjedt ki se az üzleti, sem az IT oldali nyilvántartás és figyelem. A cég a hagyományos termékei nyilvántartásához és telefonos értékesítéséhez egy teljesen független, már megszűnt cég által szállított rendszert használ, amihez évek óta nem nyúl senki.
Az amúgy létező governance folyamataik esetén egy ilyen projekt el sem indulhatott volna Üzleti és Enterprise Architectek bevonása nélkül, de ebben az esetben a Sales terület megkerülve a folyamatokat, saját költségvetésből indított kis zseb-projektként úgy gondolta, hogy nincs erre a felhajtásra szükség.
Mivel ezek a tevékenységek a cég governance radarja alatt folynak, ilyenkor akár az Üzleti Elemző is lehet az a szereplő, aki felhívja az érintettek figyelmet arra, hogy se a kapcsolt folyamatokhoz, se a rendszerhez megfelelő dokumentáció, illetve, hogy nem felel meg a változáskezelési folyamatnak.
Ezután abban is segíthet, hogy meghatározza, milyen módon tudja segíteni a szükséges folyamati leírások visszamenőleges elkészítését és azokat kinek és milyen formában fogja a projekt végén továbbadni.
Látszik, hogy az Üzleti Elemzők fontos szerepet töltenek be a vállalati governance fenntartásában. Munkájuk révén feltárják a problémás területeket, javítják a folyamatok hatékonyságát, ezáltal támogatják a szervezet eredményességét és versenyképességét. Ehhez viszont mindenképpen szükségük van arra, hogy megkapják a támogatást azoktól, akik ezeket a célokat meghatározzák, és biztosítsák összehangolt végrehajtásukat.
Köszönjük Papp Gergelynek az átfogó ismertetését az architectek és üzleti elemzők szerepéről a projektben.
Ha tetszett ez a cikk, hasonló szakmai tartalmakért töltsd le a teljes magazint ezen a linken!
