Při práci business analytika ve vysoce regulovaném prostředí se setkáváme s opakujícími se problémy a výzvami. Níže je několik z nich, včetně typických chyb a doporučení, jak se jim vyhnout:
Podcenění komplexnosti regulací
Někdy převládá dojem, že regulace je jen “další požadavek navíc”. Chybou je nedostatečně prostudovat hloubku požadavků a jejich vzájemné vazby. Například GDPR není jen o získání souhlasu od uživatele, ale zahrnuje i požadavky na bezpečnost, správu životního cyklu dat atd.
Prevence: Analytik by měl detailně nastudovat relevantní regulace, ideálně i s komentáři či výklady od právníků. Pomáhá vytvořit si checklist všech oblastí, které daná regulace pokrývá, a kontrolovat proti němu kompletnost požadavků. Je také užitečné konzultovat zkušenější kolegy nebo externí odborníky na danou problematiku, zvlášť pokud jde o novou regulaci.
Nezapojení správných stakeholderů včas
Častou chybou je, že se některá důležitá zainteresovaná strana přizve do projektu pozdě, až když se odhalí problém. Například opomenout zapojit oddělení compliance při návrhu produktu může vést k dodatečným změnám na poslední chvíli.
Prevence: Mapujte stakeholdery už při startu projektu – kdo má legislativní znalost? Kdo bude řešení provozovat? Kdo za něj ponese odpovědnost? Poté je proaktivně oslovte. Jak radí praxe, vyplatí se “zalepit si” čas u vytížených expertů (právníků, bezpečáků) dopředu. Pravidelné status schůzky, kde jsou přítomni zástupci compliance/legál, pomohou včas odhalit sporné body. Pokud stakeholder nemá čas, je dobré získat aspoň jeho review dokumentace písemně. Důležité je také školit stakeholdery z byznysu o významu regulací, aby sami chápali, proč je zapojujete – pak budou spolupracovat ochotněji.
Nedostatečná dohledatelnost a dokumentace
V zápalu vývoje někdy týmy rezignují na podrobnou dokumentaci s tím, že “to si přece pamatujeme”. V regulovaném prostředí se to může vymstít – při auditu po vás budou chtít doložit, jak a proč byla určitá funkčnost navržena.
Prevence: Zavést disciplínu v dokumentování – každý požadavek by měl mít jasný popis, autora, datum, a hlavně odkaz na zdroj (zákon, interní směrnici). Používejte šablony, které obsahují sekci “Regulatorní kontext” pro každý požadavek. Implementujte traceability matici a udržujte ji aktuální po celou dobu projektu. Před uzavřením fáze analýzy proveďte interní review dokumentace se zástupci kvality či auditu, kteří zkontrolují, že nechybí žádné náležitosti. Moderní nástroje (Jama, Polarion, Enterprise Architect apod.) umožňují vkládat traceability vztahy přímo při psaní požadavků – využijte toho.
Zlaté pravidlo: Co není zdokumentováno, jako by neexistovalo – v regulaci dvojnásob platí.
Příliš technický nebo příliš byznysový pohled (nevyváženost)
Někteří analytici se zaměří jen na právní text regulace a sepíší požadavky, které ale nejsou realizovatelné nebo nedávají smysl uživatelům. Jiní naopak poslouchají jen byznys a ignorují “nudné” paragrafy, což vede k nesouladu.
Prevence: Najděte rovnováhu. Každý regulační požadavek převeďte do byznysové potřeby (“abychom zůstali na trhu, musíme…”) a zároveň každou byznysovou funkci ověřte vůči regulacím (“neodporuje tento plánovaný krok něčemu?”). Pomáhá technika dvojí kontroly: nechte právníka ověřit, že navržené řešení splňuje zákon, a zároveň nechte koncové uživatele nebo business ownera posoudit, že navržené kontrolní mechanismy jsou akceptovatelné v praxi. Pokud najdete konflikt, hledejte kompromis – často existuje více cest ke splnění regulace, vyberte tu nejpřívětivější pro uživatele. Překlenujte komunikační propast – využívejte vizuální modely (procesy, diagramy), které si vyloží jak vývojář, tak právník.
Reaktivní přístup místo proaktivního
Někdy organizace řeší regulaci až ve chvíli, kdy musí hasit problém (např. hrozící pokutu). Analytici pak pracují ve stresu a časové tísni, což zvyšuje chybovost.
Prevence: Snažte se o proaktivní monitoring regulatorních změn. Sledujte novinky z regulačních orgánů, účastněte se školení k novým směrnicím. Pokud víte, že za půl roku vstoupí v platnost DORA, iniciujte předběžnou analýzu už nyní. Organizace, které mají vyspělé GRC, často sestavují interní “regulatory roadmap” – seznam očekávaných regulací a odhad dopadu. Business analytik by měl být do takového procesu zapojen. Tím pádem se pak nestane, že by požadavky přišly narychlo na poslední chvíli. Také se vyplatí poučit se z minulých projektů – udělat si interní retrospektivu, co se při implementaci minulé regulace zanedbalo a jak to příště udělat lépe.