Kockázatkezelés agilis módszerek mellett

A szoftverfejlesztés területéről a 2000-es évek elején népszerűvé vált agilis megközelítés mára Magyarországon is elérte a vállalatok szervezetének egészét. Az ügyfélközpontúság, a gyorsaság, a rugalmasság igényeit szem előtt tartó szervezet- és vállalatvezetés sem nélkülözheti azonban az üzleti környezetének lényeges elemét adó jogszabályi és szabályozói kereteknek való megfelelő működés biztosítását. A compliance funkció hagyományosan konzervatív megközelítésű terület. Emiatt felmerül a kérdés, hogy milyen módon ötvözhető egymással az agilis módszerek alkalmazása és a compliance követelményeknek való egyidejű megfelelés biztosítása?

A vállalati compliance
Mielőtt megvizsgálnánk az agilitás módszereket vagy az agilis vállalati transzformáció jellemzőit, az „agilis compliance” koncepciójának vizsgálatához célszerű röviden meghatározni magát a compliance funkciót is, elhelyezni a vállalati működési funkciók között. Bár viszonylag fiatal a vállalati compliance, mégis egy relatíve konzervatív területről van szó, amelynek egyik fő feladata az adott szervezet vagy vállalat külső és belső jogszabályi, szabályozói követelményeknek való megfelelés biztosítása. Így megfelelési szempontból a compliance funkciónak kell azonosítania azon külső (pl. SOX, JSOX, CCPA stb.) és helyi, nemzeti (pl. ágazati) jogszabályi követelményeket, egyéb szabályozói követelményeket (pl. felügyeleti hatósági iránymutatások, állásfoglalások) vagy akár belső szabályzati előírásokat vagy szabványokat (pl. egy ISO szabványnak való megfelelés), amelyeket a vállalatnak teljesítenie kell a mindennapi működése során.

Másrészről a compliance funkció üzleti, működési kockázatkezelési tevékenységet is végez több alterületen, így a compliance funkció része a vállalatirányításnak. Emiatt a compliance az üzleti területeket támogató, döntéselőkészítő (pl. külföldi befektetések, egy-egy új termék megvalósíthatóságával, kockázatokkal kapcsolatban), és az általános védelmi vonalak részeként kontroll és kockázatkezelési területnek is tekinthető. A compliance funkciónak széles a tevékenységi spektruma, továbbá vállalatról-vállalatra változik, hogy ténylegesen milyen feladatokat lát el. Amit nagy magabiztossággal ki lehet jelenteni, hogy a vállalati compliance terület fontossága és szerepe folyamatosan, évről-évre növekszik. A hatékony compliance megvalósításának igénye elsősorban a jelenlegi, „hagyományosnak” mondott működési modellben is az egyes funkcionális területek közötti hatékony együttműködésben, kommunikációban, a vállalati kockázati kultúrában, kockázattudatosságban jelenik meg, amihez különösen fontos a felső vezetés kommunikációja, elvárásai, valamint a compliance funkció működésébe vetett bizalom, a terület aktív bevonása a vállalat életében, a vállalati kezdeményezésekbe. A nem hatékony módon megszervezet vállalati compliance terület, a nem megfelelően vagy kellő időben azonosított és kezelt compliance kockázatok a teljes vállalat, vagy akár vállalatcsoport számára is közvetlen jogi, pénzügyi, reputációs és operációs következményekkel járhatnak.

Agilis módszerek
Az agilis vállalati transzformáció megértéséhez szükséges röviden ismertetni magát az agilitást is, azaz, hogy mit nevezünk „agilis projektnek”, milyen agilis módszertanokat alkalmaztak, alkalmaznak. Az agilis módszerek a ’90-es évek korszellemének termékei és először az agilis szoftverfejlesztési módszertanok jelentek meg, párhuzamosan az akkori technológiai fejlődéssel, amely életre hívta azokat az igényeket, hogy minél rövidebb idő alatt, minél rugalmasabban, minél „ügyfél központúbb” szoftverek tervezését és elsősorban fejlesztését, szállítását lehessen elvégezni.

Az agilis módszereken alapuló megközelítés válasz volt a korábbi paradigmában gyakorlatilag egyeduralkodó ún. „vízesés” (waterfall) típusú szoftvertervezési- és fejlesztési modellre. Ennek a modellnek a lényege a lineáris, lépcsőzetesen egymásra épülő tevékenységek sorozata, mint pl. a követelmények előzetes meghatározása, dokumentálása, a tervezés, a fejlesztés és a tesztelés, ahol minden egyes főbb tevékenység lezárását egy-egy ellenőrzőpont előzte meg, mielőtt a következő tevékenységre lehetett volna továbblépni.

Az agilis szoftvertervezés lényege az iterativitás, priorizálás és rövid, jellemzően pár napos vagy hetes sprintekre bontani a teljes projektet. Agilis megközelítésben a sprinteken belül szükséges megtervezni, kialakítani és működő prototípusig vinni a szoftvert – gyors, egymásra épülő szoftver kiadásokban (release-kben). Az agilis módszereknél tehát a hangsúly a működő szoftver készítésén van; az agilis módszer az együttműködésre, kommunikációra, az ügyfélre és a kiadásokra fókuszál, nem pedig a folyamatokra vagy ezek, illetve a termék dokumentálásra (pl. jellemzően nem vagy alig készül specifikáció, ami szemben állhat bizonyos szabályozói követelményekkel). Az agilitást a szoftverfejlesztésben meglévő szabadsági fokok adták, és ma már egyáltalán nem jellemző, hogy egy projekt addig nem indul el, amíg nem definiáltak vagy terveztek meg minden tényezőt. Azonban a hibának, az esetleges nemmegfelelésnek ára van: kutatások szerint a szoftverekben a tervezési szakaszban 1 egység, az éles üzem során 100 egység egy-egy hiba utólagos javításának a költsége; ezen hibák adódhatnak a nem vagy nem jól felmért szabályozói, megfelelősségi követelményekből, jogszabályi nemmegfelelőségekből. Ezért fontos az agilis módszerek esetében is vizsgálni a compliance követelményeket és a compliance területek megfelelő bevonását.

Jellemző agilis módszerek az Extreme Programming (XP) 1996-ból, amelyben kizárólag a működő szoftver létrehozása a cél, minden más mellékes és ennek megfelelően kis, apró szoftver kiadásokban, release-ekben operál és a tesztelés része minden ciklusnak. A Crystal módszer és „színváltozatai” jellemzően a személyi interakciókra fókuszálnak, a hagyományos tervezés-fejlesztési fázisok helyett. A Dynamic Systems Development Method (DSDM) módszer jellemzője, hogy a 80/20-as szabály alapján történik a fejlesztés, valamint a középpontban az üzleti igény elsődlegessége áll. A Feature Driven Development (FDD), mint módszer pedig elsősorban a szoftver funkcióira koncentrál.

Ezen agilis módszerek térhódítását követően született meg 2001-ben az Agile manifesto, ami 12 elvet fogalmazott meg elsősorban az ügyfélre, az üzleti igényekre, a rugalmasságra, kommunikációra, interakcióra és a szoftver, mint termék leszállítására fókuszálva. Megjegyzendő, hogy compliance követelményekkel vagy compliance szempontokkal kapcsolatos elvet egyáltalán nem tartalmazott ez a kiáltvány.

Agilis vállalatok
Nem újkeletű igény a profitorientált vállalatoknál a folyamatos törekvés a minél gyorsabb, rugalmasabb, jobb minőségű termelésre, termék-fejlesztésre, szolgáltatás-nyújtásra és ügyfélkiszolgálásra. Jellemző mérőszámok a vállalati eredményességhez a Time-to-Market és a Time-to-Customer ezen a téren. Az agilis megközelítés egy eszköz lehet ezen célok elérése érdekében.

Agilis megközelítésről a vállalati működés több rétegében lehet beszélni: egyrészről projekt-szerű működés során átitatva a teljes vállalat mindennapi működését, másrészről felső vezetői szinten kommunikált szemléletmódról legyen szó. Az agilis vállalatvezetés a vállalat egészének szintjén azonban inkább már egy gyűjtőszó: többek szerint szemléletmód, működési modellek, eljárások, technikák és eszközök összessége, amelyek mégis iteratívan, inkrementális és egymással együttműködő módon működnek együtt. Emiatt fontos azt is hangsúlyozni, hogy a vállalati agilitás, az agilis transzformáció nem a költségek csökkentéséről szól, hanem sokkal inkább szemléletmód váltásról, munkamódszer váltásról, amely jelentősen érinti egy-egy vállalat mindennapi működését.

Az agilis területeken így jellemző a projekt szemlélet nem hierarchizált, több funkciót, vállalati területet lefedő agilis csapatok, ún. mag (core) csapatok kialakítása. Ezen projekt alapú és autonómon csoportok működését az egyes „squad”-ok, „tribe”-ok, „chapter”-ek és „guild”-ek biztosítják. Az egyes csapattagok kizárólag a sprintekben autonóm módon meghatározott tevékenységeken dolgoznak és az agilis vállalatoknál a középpontban a különböző funkcionális, szakértői területekről érkező egyének és ezen egyének napi interakciói állnak. Ez a projekt-szerű, autonóm csapatokba szervezett működés a hagyományos vállalati struktúrákat, területeket és funkciókat is fellazíthatja, feloldhatja.

Az üzleti igények a korábbi, hagyományos specifikációk, írásbeli dokumentumok helyett az agilis terminológiával élve „user story”-kban és a „user journey”-ben jelennek meg, amelyek megvalósításának helyzetét és a szükséges további feladatokat az erre a célra szolgáló felületeken, pl. kanban táblán lehet nyomon követni. Kulcsfontosságú, hogy a compliance-ért, jogszabályi, szabályozói megfelelőségért felelős munkatársakat hol és milyen ponton tudja bevonni az agilis szervezet, az egyes agilis csapatok, valamint hogyan tudja priorizálni a szervezet ezen compliance követelmények teljesítését az egyes sprineteken belül. Az agilis vállalatok nagyfokú autonómiát biztosítanak ezeknek a csoportoknak, ami bizonyos döntéseknek a szakértői szintre történő delegálását is jelenti, ami nagyfokú egyéni felelősséget is ró az egyes csapattagokra.

Felmerül a kérdés, hogy az agilis transzformáció során hol húzódjon a döntéseknek a határa, különösen compliance és kockázatkezelési szempontból? Másik mérlegelendő kérdés az erőforrás tervezéssel kapcsolatban merül fel, hogyan tud a szervezet minden egyes projekthez megfelelő számú és felkészültségű szakértőt biztosítani a compliance terület?

Jellemző különbségek
A hagyományos megközelítésben jellemzően a siló-szerű működést szokás kiemelni, azaz azt, hogy az egyes funkcionális területek a többi területtől elszigetelve, a másik terület tevékenységéről nem tudva végzik a mindennapi tevékenységeiket. Compliance szempontból a hagyományos struktúrákban is probléma lehet emiatt a terület vizibilitása, a compliance területtel szemben táplált bizalom és a terület bevonása a különböző kezdeményezésekbe, projektekbe. A hierarchikus irányítási viszonyok jobban láthatóak a „hagyományos” vállalatvezetési struktúrákban. Míg az agilis módon működő vállalatok inkább „laposak”, kevesebb hierarchia szinttel rendelkeznek.

Az egyik fő tétel az agilis működéssel kapcsolatban az ügyfelekkel való együttműködés előmozdítása, mintsem a hagyományos szerződések tárgyalása (“customer collaboration over contract negotiation”). Az agilis vállalatvezetési- és szervezési mód választ próbál adni a hagyományos, siló szerű működés jelentette problémákra, azonban az agilis működés sem kritika nélkül: a nagyfokú bizonytalanság miatt az egyes keresztfunkcionális csapattagok esetében előfordulhat a rövid távú (sprintekre korlátozott) szemléletre történő túlzott fókuszálás a vállalat közép- és hosszú távú érdekei helyett, és az egyes keresztfunkciós csapatok a mindennapi, sprint-beli feladatok „letudását” helyezik előtérbe. Kritika másrészről a teljesítményértékeléssel összefüggésben, hogy az egyes csapattagok a feladatot „megúszni” akarják, minél rövidebb hamarabb végrehajtott státuszúként feltüntetve és a feladatvégzést mennyiségi irányba eltolva a minőségi munkavégzés helyett. Harmadrészt, mivel az agilis módszer a csapattagok részéről is jár egyfajta szemléletváltással egy nem kellően jól koordinált csapat könnyen egy hibrid működési modellben találhatja magát, visszatérve a hagyományos modell szerinti, de agilis keretek közötti működési elvekhez.

Vállalati agilitás és compliance
Jellemzően nem lehet minden szervezeti egységet, vállalati funkciót vagy folyamatot agilis módszerűvé átalakítani, illetve működtetni. A vállalatok a compliance céljaikat a compliance stratégiájukban határozzák meg és a compliance programjukon keresztül érvényesítik, aminek az egyik célja az ellenőrizhetőség, auditálhatóság, valamint a mérhetőség biztosítása. Ezért szerintünk lehet élni azzal a feltevéssel, hogy a módszer változása nem érinti a compliance funkció céljainak elérését, az agilis transzformáció során is folyamatosan kezelni kell a compliance kockázatokat, összhangban a tervezett compliance programmal: az agilis transzformációs projekt reputációs, pénzügyi, operációs és jogi kockázatait is.

Jellemzőek a hibrid megoldások: azokat a területeket, amelyek tudnak hatékonyan működni agilis módszerek mellett, agilis formában és a hagyományos, például a támogató területeket, mint amilyen a compliance is, össze kell kapcsolni egymással. Ennek megfelelően a compliance kontroll és üzlettámogató funkciójának érvényesülnie kell mind az agilis csapatok, mind a hagyományos területek között és a compliance területnek egy agilis transzformáció vagy agilis működési modell esetében erre szükséges felkészülnie. Ez a vállalat sajátosságaihoz igazodó compliance keretrendszer kialakítását igényli, azaz eldöntendő, hogy az agilis transzformáció során a compliance működés támogató, döntéselőkészítő és belső ellenőrzési, kontroll szerepét milyen formában fogja tudni tovább érvényesíteni a szervezet, akárcsak agilisan működő folyamatok esetében?

A vállalat felsővezetése részéről mutatott hozzáállás, a befelé és kifelé kommunikált követelmények prioritása, a felső- és középvezetői kommunikáció mind az agilis szemlélet, agilis transzformáció, mind a compliance funkció hatékony működése érdekében kiemelten fontos, ami kihatással van a végrehajtói szintek működésére, viselkedésére is. Az agilis transzformáció, vagy a compliance működésével kapcsolatban sem szabad emiatt szem elől téveszteni az emberi tényező fontosságát, mivel a mindennapi működés során végső soron ez lesz a meghatározó. Az agilis vállalatok compliance funkciójával kapcsolatban is a legfontosabb, hogy a szervezeten belül a szükséges információk eljussanak a compliance területhez, a compliance funkcióra tartozó döntések meghozatalába kellő időben be legyenek vonva az érintettek. A kellő időt pedig szintén az agilis módszerekkel összhangban szükséges értelmezni, így jellemzően az egyes sprint elején, azok tervezési szakaszaiban szükséges meghatározni az alkalmazandó compliance követelményket. Az agilis transzformáció során is tud támaszkodni a compliance terület a már meglévő technológiai támogatásra, így pl. agilis projekt menedzsment szoftverekre, vagy az egyes kockázatok nyomon követéséhez a már meglévő GRC szoftverekre, illetve ezek integrációjára.

Kockázatkezelés agilis megközelítésben
A vállalat kockázatkezelés működését a különböző szinteken, rétegekben szükséges szétbontani. Az agilis működés során, elsősorban a projekt szemlélet érvényesül és így a compliance funkció kockázatkezelési tevékenységek nagy részének az egyes projektek lesznek a terepei. Az agilis működést a VUCA mozaikszóval szokták jellemezni, ami a folyamatos változás (Volatility), bizonytalanság (Uncertainty), komplexitás (Complexity) félreérthetőség (Ambiguity) leírására szolgál. Az agilis terminológiában emiatt a kockázat jellemzően a bizonytalanság (Uncertainty) részeként jelenik meg, illetve jeleníthető meg. Ennek megfelelően például az egyes kockázatok kezelését az Agile Project Management (AgilePM) projekt vezetési módszer a kockázatokat a bizonytalanság és tanulási lehetőségek mentén fogja meg. Az agilis működés során a különböző módszertanok biztosítják az egyes kockázatokat “láthatóvá” tételét, például külön színkódokkal jelölt feladatokkal ún. kockázat-módosított Kanban táblán („risk-modified Kanban board”), amin a zöld színnel jelölt feladatok lehetőségeket, míg a piros színűek fenyegetettségeket jelölnek; másik alkalmazott módszer az egyes kockázati anyagokkal való összekötésre és bemutatásra a „risk walling”.

Ennek megfelelően a projektek során így az egyes sprintekben a csapattagoknak nyomon kell követniük az egyes kockázati feladatok alakulását, a kockázatokért való felelősséget, illetve a kockázatokkal kapcsolatos szükséges döntéseket (pl. ki fogadhat el kockázatot? ki dönthet az egyes kockázatkezelési intézkedésekkel kapcsolatban?). Fontos kiemelni, hogy agilis projektek esetében a srcum master vagy az agile coach nem projektvezető; ezért hangsúlyos kérdés, hogy ki legyen a kockázat kezeléséért elsősorban dedikált személy. Jellemzően ezen személyről az egyes csapattagoknak szükséges megegyezniük egymással, csak úgy, mint az egyes kockázatkezelési feladatok kiosztásával kapcsolatban is (agilis kockázatkezelési terminológiában „risk tasking”). A szükséges kockázatkezelési feladatokat a napi egyeztetések, az egyes iterációk során a sprintek tervezési szakaszában lehetséges azonosítani és értékelni a lehetséges további kockázatokat. Az agilis megközelítésben a compliance és kockázatkezelési tevékenységek egyik célja, hogy a Minimális Életképes Termék („Minimum Viable Product – MVP”) megfelelő minőségben álljon elő és audit kész, ellenőrizhető legyen. Az egyes sprint-ek backlog-jaiban (tevékenység listájában) a nyitott kockázati tételeket a nyitott kockázati feladatok, compliance feladatok mentén kell priorizálni egészen addig, amíg ezen kockázati és compliance feladat nem állíthatók teljesített-re, majd ezzel a „tevéknyeség kisöpréssel” (burndown) kezelhető részben a kockázati étvágy is, hiszen az egyes kockázatcsökkentő intézkedéseket is ezeken a feladatokon keresztül hajtja végre a vállalat az egyes sprintekben.

Az agilis működés során is fontos a transzparencia biztosítása az egyes vállalati érintettek (stakeholder-ek) felé, hogy kommunikálni lehessen milyen területeken történt előrelépés, milyen feladatokat kell még elvégezni és milyen akadályokat (kockázatokat) szükséges még leküzdeni. Az ellenőrzés egyik eszköze a sprintek végére elkészülő prototípusok, demo termékek, amelyeket a projekt csapat egyes az érintett döntéshozóknak be tud bemutatni. Ezen bemutatók alkalmával is fontos visszajelzéseket kaphat a csapat a különféle compliance, szabályozói, jogszabályi követelményekkel kapcsolatban. Az agilis modell egyik előnyeként tartják emiatt ezt számon, hogy így legkésőbb az adott sprint végén kiderül, ha a prototípus nem teljesíti az egyes követelményeket, így legfeljebb az adott sprintre fordított idő és nem több erőforrás megy esetleg veszendőbe.

Kockázatkezelési, vagy akár szabályozói megfelelési szempontból problémás lehet viszont, hogy a dokumentáció jelentős része jellemzően az utolsó sprintekben készül el, válik véglegessé, ami tovább növeli a bizonytalanságot a támogató, kontroll területek képviselői számára is, és adott esetben növelheti a vállalat kockázati kitettségét. Folyamatosan nyomon kell követni az esetleges szabályozói elvárásokat és azok változásait is (különösen pl. a pénzintézeti szektorban). Jó gyakorlatnak az számít, ha a product owner rendszeres kapcsolatban áll a szabályozó, felügyeleti hatósággal és kommunikálja a követelmények változását a csapat vagy a compliance funkció felé.

Az egyes követelményeket a compliance területnek kell azonosítania és jól érthető módon kell kommunikálnia a csapattagok felé. Az agilis terminológia szerint a user story-k eredetileg funkcionalitást jelöltek a szoftverben, pl. „Mint product owner, szeretném, ha a webshopban bevásárlókocsi rendszerű vásárlás lenne”. Ez azt jelentette, hogy a szükséges funkcionalitást ki kellett alakítani az egyes sprintek során és el kellett készíteni a szükséges prototípust, majd élesbe állítani a funkcionalitást. Hasonlóan a compliance követelmények is így jelenhetnek meg, azzal, hogy a compliance követelmények jellemzően nem funkcionális követelmények, pl. adatvédelmi szempontból a privacy dashboard kialakítása, egy tájékoztató megjelenítése mobil alkalmazásokban, vagy az ügyfelek azonosításának követelménye.
Az egyes user story-kon jellemzően többen, közösen dolgoznak, míg a user task jellemzően egy személyhez rendelt feladat a csapaton belül. A compliance funkció így az egyes „user story”-kon keresztül jelenhet meg, amelyeket résztevékenységekre („task”-okra) lehet bontani és ennek megfelelően az egyes csapatokon belül személyekhez lehet rendelni. A compliance user story lehet így, pl. „Mint a compliance-ért felelős csapattag azért, hogy megfeleljünk az alkalmazandó MNB előírásoknak előzetesen értékelni kell a kiszervezés kockázatait.” Ennek megfelelően az agilis gyakorlatban az egyes compliance címkéket („tag”) és feladatokat a jó gyakorlat szerint a következőkre figyelemmel lehet meghatározni: (i) egy-egy önálló „tag” kialakítása az egyes compliance követelményekkel kapcsolatban; ahol a „tag” az adott követelmény lényegét jeleníti meg (pl. „Direkt marketing hozzájárulások kezelése”); (ii) a compliance „tag”-ek csoportosítása és véglegesítése az egyes követelmény-rendszerek mentén; (iii) a compliance „tag”-ek és a meglévő kontrollok egymáshoz rendelése; (iv) a compliance „task”-ok definiálása a kontrollokhoz nem rendelt „tag”-ekkel kapcsolatban; (v) a compliance követelmények és compliance „task”-ok összepárosítása. Az egyes compliance task-ok megfogalmazása, végrehajtása és követelményekkel való összerendelése miatt is fontos, hogy az agilis csapaton belül milyen formában jelenik meg a compliance funkció, mint szakértői, döntéselőkészítő terület.

Összegzés
Felmerül a kérdés, hogy szükséges-e és ha igen, akkor milyen módon tud a compliance funkció agilis módszerek mentén működni? Lehetséges-e a compliance terület többi funkcióját, a hagyományos megfelelési funkciókat, ahol bináris igen/nem válaszok szükségesek agilis módszerek mentén szervezni? Nincs egységesen alkalmazható varázsrecept arra, hogy tud-e és ha igen, akkor hogyan tud a compliance terület agilis módszerekkel működni. Minden vállalatnak magának kell testre szabni a saját agilis transzformációját és ennek során kialakítani az agilis, hibrid és hagyományos területek közötti kapcsolatokat és biztosítani mindegyik terület és vállalati funkció számára a megfelelő-szintű compliance támogatást. Az egyes projektekben a compliance funkció a projektek szerint tud agilisan működni, mint résztvevő funkció, azonban vállalat szinten továbbra is a compliance stratégiának és az adott compliance program végrehajtásának szükséges prioritást biztosítani. Látható, hogy a kockázatkezelési szempontokat is lehet érvényesíteni és magát a kockázatkezelési folyamatot agilis módszerek szerint szervezni, ahogy hasonlóan a kontroll, illetve ellenőrzési funkció is elvégezhető agilis módszerekkel. Az agilis működési modellben is működhetnek a jelenlegi, „klasszikus tevékenységek”, mint a tréningek, oktatások tartása az egyes keresztfunkcionális csapattagok, illetve a hagyományosan működő területeken dolgozó munkatársak számára. Az agilis módszerekkel történő működés során továbbra is kulcsfontosságú marad és hangsúlyozandó a kockázattudatos vállalati kultúra építése és fenntartása, amely elsősorban a vállalat felsővezetésén múlik, a megfelelő stratégiai szintű prioritások meghatározásával, amely kihatással van a vállalati irányítás és így a compliance funkció agilis módszerekkel történő megszervezésére is.