Како изградити процес развоја усмерен на усклађеност

Kada se uvodi novi sistem, usklađenost se često razmatra tek nakon što je prva verzija završena, a pravna ili informatička bezbednosna provera otkrije nedostatke. Tada dolazi do kasnih izmena, ponovnog testiranja, nejasnih odgovornosti i kašnjenja u pokretanju. Pitanje nije samo kako izgraditi proces razvoja fokusiran na usklađenost, već i kako učiniti usklađenost proverljivim delom svakodnevnog poslovanja bez nepotrebnog usporavanja razvoja.

Usklađenost nije odvojena gomila dokumenata. U sistemu skladišta to može značiti da se kretanje zaliha može pratiti i da se ne može retroaktivno menjati bez traga. U procesu e-trgovine to znači da je obrada ličnih podataka ciljno orijentisana i evidentirana. U proizvodnji to znači da se odstupanje u kvalitetu, odobrenje ili promena recepture može jasno povezati sa odgovornom ulogom. Zajednička tačka u svim slučajevima je kontrolabilnost.

Usklađenost nije poslednja kapija razvoja

U mnogim kompanijama proces razvoja počinje jednostavnom formulom: poslovanje izražava potrebu, razvojni tim kreira funkciju, a neko proverava da li je upotrebljiva. Ovo funkcioniše prihvatljivo kada je proces povezan sa malo sistema, obrađuje malo podataka i kada greška ne izaziva ozbiljne operativne ili ugovorne posledice.

Međutim, u rastućim kompanijama promena retko ostaje unutar granica jedne aplikacije. Novi status narudžbine može uticati na webshop, ERP, fakturisanje, integraciju kurira i izveštaje menadžmenta. Ako nema jasnog pravila ko može menjati podatke, koji sistem je vlasnik podataka, šta se smatra odobrenom promenom i kako se može vratiti pogrešno izdanje, tada rizik usklađenosti zapravo postaje operativni rizik.

Cilj nije da se za svaki razvojni zadatak pripremi nesrazmerna administracija. Cilj je da odluke, kritične kontrole i dokazi o proveri budu prisutni u procesu tamo gde su zaista potrebni.

Kako izgraditi proces razvoja fokusiran na usklađenost počevši od poslovnog procesa?

Prava polazna tačka nije pravilnik, niti lanac razvojnih alata. Prvo treba razumeti koji poslovni događaj sistem obrađuje, ko donosi odluku, na osnovu kojih podataka i šta se dešava ako korak nije ispravan ili je izostavljen.

Uzmimo jednostavan primer: radnik korisničke službe menja adresu isporuke narudžbine. Na prvi pogled ovo izgleda kao mala funkcija. Ipak, operativna pitanja su važna: do kada je dozvoljena promena, da li je potrebna obrazloženje, ko odobrava za narudžbine velike vrednosti, da li se promena prenosi na prevoznika i da li je kasnije vidljivo ko je izvršio promenu? Ako na ova pitanja nema odgovora, programer može samo kreirati polje za unos podataka i dugme za čuvanje. Kontrolisani proces ne može.

Tokom istraživanja, važno je razjasniti tri stvari za svaku značajnu promenu: koja obaveza ili interni pravilnik je povezan sa njom, koja greška ili zloupotreba se može sprečiti kontrolom i šta će biti proverljiv dokaz da je kontrola funkcionisala. To može biti dnevnik ovlašćenja, zapis o odobrenju, verzionisani dokument, rezultat testa ili zapisnik o vraćanju. Nije uvek potrebno sve, ali odluka mora biti svesna.

Zahtevi moraju biti testabilni

Izjave poput „neka bude bezbedno“ ili „neka bude u skladu sa propisima“ nisu pogodne kao razvojni zahtevi. Ne otkrivaju šta treba izgraditi, ko proverava i kada se očekivanje smatra ispunjenim.

Upotrebljiv zahtev je konkretan. Na primer: korisnik može videti samo kretanje robe povezano sa sopstvenom lokacijom; količina odobrene narudžbine ne može se menjati bez novog odobrenja; izvoz finansijskih podataka je evidentiran; izmene kritičnih postavki sistema zahtevaju dve odvojene uloge. Iz ovih zahteva mogu se kreirati dizajnerske odluke, test slučajevi i kasnije provere.

Važno je razlikovati obavezne kontrole od očekivanja pogodnosti. Ako unutrašnje odobrenje zavisi od jednog prodajnog administratora koji ne može biti zamenjen tokom odsustva, sistem može biti u skladu sa dokumentovanim pravilom, ali poslovanje može stati. Dobra usklađenost nije samo stroga, već i operativna.

Disciplina razvoja treba da varira u zavisnosti od rizika

Nije opravdano primeniti isti nivo provere na promenu rasporeda unutrašnjeg izveštaja i na prepravku prenosa podataka za fakturisanje. Previše ujednačen proces usporava manje popravke, pa zaposlenici vremenom traže zaobilazne puteve. Previše labav proces ostavlja otvorene rupe upravo kod kritičnih promena.

Korisno je proceniti promene prema najmanje tri kriterijuma: da li uključuju lične, finansijske ili poslovno osetljive podatke; da li menjaju ovlašćenja, odobrenja ili evidentiranje; i da li mogu izazvati prekid rada u više povezanih sistema. Za promenu prikaza niskog rizika može biti dovoljna uobičajena provera od strane programera i poslovno preuzimanje. Za veći rizik može biti potrebna dodatna stručna odobrenja, integracioni test, plan vraćanja i dokumentovana odluka o puštanju u rad.

Ovo nije birokratija, već zaštita kapaciteta. Pažnja tima je usmerena tamo gde loša odluka kasnije može dovesti do ispravke podataka, žalbe klijenta, pogrešne fakture ili zastoja u proizvodnji.

Kontrole moraju postati funkcija sistema tokom planiranja

Očekivanje usklađenosti se ne ispunjava time što je navedeno u projektnoj mapi. Kritično pravilo mora biti ugrađeno u proces. Ako korak zahteva odobrenje, sistem mora upravljati stanjem, ulogom odobravaoca, vremenskim pečatom i izuzetnim slučajevima. Ako je potrebna mogućnost praćenja, dnevnik mora zabeležiti šta se promenilo, a ne samo da je neko pristupio.

Upravljanje ovlašćenjima je posebno česta slaba tačka. U mnogim sistemima korisnici vremenom dobijaju „privremeno“ širi pristup, koji zatim ostaje trajno. Prilikom planiranja, korisno je razmišljati u terminima uloga umesto pojedinaca i razdvojiti pokretanje, proveru i odobrenje tamo gde to ima poslovni značaj. U malim kompanijama nije uvek moguće potpuno razdvojiti zadatke. U takvim slučajevima može biti potrebna kompenzaciona kontrola, kao što je naknadna provera od strane menadžera ili redovna revizija dnevnika.

Upravljanje izuzecima je podjednako važno. U stvarnom poslovanju dolazi do grešaka u uvozu, hitnih narudžbina, prekida u radu eksternih usluga ili pogrešno zatvorenih radnih naloga. Sistem podržava usklađenost kada izuzetak ne predstavlja skriveno zaobilaženje, već označen, evidentiran i naknadno pregledan proces.

Testiranje mora proveriti i dokaze

Funkcionalni test proverava da li sistem obavlja ono što treba. U razvoju fokusiranom na usklađenost, takođe treba proveriti da li sprečava ono što ne sme i beleži ono što kasnije treba dokazati.

Test procesa odobravanja ne sme stati na tome da dugme za odobrenje radi. Treba proveriti da li neovlašćeni korisnik može pokrenuti korak, da li se sadržaj može menjati nakon odobrenja, da li je dnevnik ispravno prikazan i u kom stanju ostaje transakcija u slučaju greške u integraciji. Negativni testovi često govore više o kvalitetu kontrola nego uobičajeni, uspešni procesi.

Poslovno preuzimanje ne treba tretirati kao formalni potpis. Zadatak procesnog menadžera nije da opšte izjavi: „sve je u redu“. Potrebno je potvrditi da sistem podržava određena pravila u stvarnim operativnim situacijama, uključujući izuzetke. Test podaci moraju odražavati verodostojne scenarije.

Puštanje u rad i operativno upravljanje su deo istog procesa

Razvoj se ne završava puštanjem u rad. Najbolje planiranje i testiranje je beskorisno ako nije jasno ko odlučuje o izdavanju, kako se proveravaju prve operativne obrade i šta se dešava u slučaju greške.

Za svako značajnije izdanje treba biti određen odgovoran za poslovno prihvatanje promene, tehničku realizaciju i naknadnu proveru. Plan vraćanja ne sme biti teoretski dokument. Treba znati koji se pokreti podataka mogu dogoditi tokom izdavanja, šta se može automatski vratiti i nakon koje tačke je potrebna i poslovna korekcija podataka.

Operativne kontrole mogu uključivati redovnu reviziju ovlašćenja, obradu grešaka ili ponovljenih integracionih poruka, čuvanje dnevnika i naknadni pregled izvanrednih izmena. Učestalost ovih aktivnosti zavisi od značaja sistema. Sistem koji direktno podržava proizvodnju ili isporuku zahteva drugačiju pažnju od retko korišćenog internog registra.

Održiva usklađenost nije očigledna po broju pravila. Ona se vidi kada novi zaposleni razume svoju ulogu, kada menadžer može pregledati kritične odluke i kada pogrešna promena ne primorava tim na ručno pretraživanje podataka. Ako se za sledeći razvojni zahtev prvo razjasne proces, odgovornosti i proverljive kontrole, usklađenost neće biti prepreka, već osnova za predvidivo poslovanje.