Tokovi odobravanja kojima revizori veruju

Tok odobravanja dokumenata u SharePoint-⁠u i Power Automate-⁠u može da se napravi za jedno popodne. Tok koji će revizor prihvatiti kao dokaz zahteva više razmišljanja. Razlika retko leži u situaciji kada sve ide po planu. Leži u onome što se dešava kada neko izmeni fajl posle odobrenja, ode na godišnji odmor ili odobri sopstveni zahtev.

U ovom tekstu prolazimo kroz odluke koje čine da tok odobravanja izdrži kada neko izvan tima počne da postavlja pitanja.

Šta revizor želi da vidi

Revizora ne zanima koliko je vaš flow elegantan. On želi da za svaki dokument, i posle više meseci ili godina, dobije odgovor na nekoliko jednostavnih pitanja:

Koja tačno verzija dokumenta je odobrena?
Ko ju je odobrio, kada i u kojoj ulozi?
Da li je ta osoba imala pravo da je odobri?
Da li je iko kasnije mogao da izmeni dokument ili zapis o odobrenju?
Da li se zapis čuva onoliko dugo koliko pravila zahtevaju?

Svaka odluka opisana u nastavku služi nekom od ovih pitanja. Sve što slabi odgovor na bilo koje od njih je problem.

Život dokumenta u toku odobravanja koji je spreman za reviziju.

Odobrenje vežite za konkretnu verziju

Najčešća slabost na koju nailazimo je odobrenje koje se odnosi na dokument, a ne na njegovu verziju. Fajl se odobri u ponedeljak, izmeni u utorak, a biblioteka i dalje pokazuje „Odobreno“.

Počnite od podešavanja biblioteke:

Uključite glavne i sporedne verzije, tako da su radne verzije sporedne, a odobreni dokumenti postaju glavne verzije.
U bibliotekama sa formalnim odobravanjem zahtevajte check-⁠out pre izmene.
Koristite content approval ili kolonu statusa koja se automatski vraća na početno stanje kada se fajl promeni.

U samom flow-⁠u, u trenutku pokretanja zahteva zabeležite oznaku verzije i ETag ili hash fajla. Kada se odobrenje završi, uporedite ih ponovo. Ako se dokument u međuvremenu promenio, odobrenje treba odbiti ili pokrenuti ispočetka, a ne tiho primeniti na novi sadržaj.

Zaključajte ono što je odobreno

Posle odobrenja dokument treba prebaciti u stanje u kom ne može da se menja bez novog ciklusa. Možete ga objaviti kao glavnu verziju uz ograničena prava izmene, premestiti u biblioteku samo za čitanje ili mu dodeliti retention label koji ga označava kao zapis. Izaberite jedan pristup i primenjujte ga dosledno.

Audit trag koji ne može da se menja

Komentar u koloni SharePoint liste nije audit trag. Svako ko ima pravo izmene nad listom može da ga promeni, a istorija verzija stavki liste može da se skrati.

Upotrebljiv audit trag ima sledeće osobine:

Samo se dopisuje. Zapisi se dodaju, a ni flow ni obični korisnici ih ne menjaju i ne brišu.
Čuva se odvojeno od dokumenata, sa pravima pristupa koja poslovni korisnici nemaju.
Potpun je. Beleži se svaki zahtev, odluka, preusmeravanje, podsetnik, istek roka i otkazivanje.

U praksi događaje odobravanja upisujemo u poseban log: Dataverse tabelu sa uključenim auditingom, zaključanu SharePoint listu u koju upisuje samo servisni nalog ili Azure storage tabelu. Microsoft Purview audit log daje dodatni zapis na nivou platforme, ali period čuvanja zavisi od licence, pa proverite šta vaš tenant zaista čuva pre nego što se na to oslonite.

Šta beležiti za svaki događaj

Za svaki korak zabeležite najmanje:

ID dokumenta, biblioteku i oznaku verzije
hash ili ETag fajla u trenutku odluke
ID zahteva i verziju toka odobravanja
identitet osobe koja je postupila (user principal name i object ID, a ne samo ime za prikaz)
ulogu u kojoj je postupila, na primer odobravalac, zamenik ili administrator
odluku i komentar
vreme u UTC-⁠u
kod zamene, u čije ime je radnja izvršena

Beležite identitet osobe koja je kliknula, a ne identitet konekcije pod kojom flow radi. Flow-⁠ovi često rade pod servisnim nalogom, a taj nalog nikada ne sme da se pojavi kao odobravalac.

Podela dužnosti mora da se sprovodi

Pravilo je jednostavno: osoba koja priprema ili podnosi dokument ne treba da ga odobri. U manjoj firmi to pravilo se prekrši čim jedini drugi odobravalac nije dostupan.

Zato ga sprovedite u samom toku, a ne samo u pravilniku:

Pre dodele zadatka proverite da odobravalac nije autor, podnosilac ili poslednja osoba koja je menjala dokument.
Odobravaoce određujte na osnovu uloga ili grupa koje se održavaju izvan flow-⁠a, kako niko ne bi mogao sam sebe da doda.
Ako ne postoji nijedan odgovarajući odobravalac, zaustavite tok i eskalirajte. Nemojte prelaziti na varijantu „bilo ko iz grupe“.

Za rizičnije dokumente razmislite o dva nivoa odobravanja, gde drugi odobravalac dolazi iz drugog sektora.

Zamene i odsustva rešite eksplicitno

Ljudi idu na odmor, menjaju radna mesta i odlaze iz firme. Tok odobravanja koji to ne predviđa ili stoji u mestu ili podstiče prečice.

Zamenu projektujte kao funkciju sa sopstvenim pravilima:

Zamene se vode u posebnoj listi, sa datumom početka, datumom završetka i osobom koja ih je potvrdila.
Tok pri dodeli zadatka proverava aktivne zamene i beleži i prvobitnog odobravaoca i zamenika.
Zamenik ne može da odobri dokument čiji je autor, čak ni kada radi u nečije ime.
Zadaci na čekanju se posle definisanog vremena eskaliraju na unapred određenu rezervnu ulogu, a eskalacija se beleži.

Ne oslanjajte se na automatske odgovore o odsustvu niti na prosleđivanje mejlova za odobrenje. I jedno i drugo prekida vezu između odluke i osobe koja je bila ovlašćena da je donese.

O čuvanju zapisa mislite od prvog dana

Zapisi o odobrenjima moraju da nadžive ljude koji su ih napravili, a ponekad i sam sistem. Rokovi čuvanja zavise od vrste dokumenta, delatnosti i propisa, pa ih pre razvoja dogovorite sa osobom koja je u vašoj organizaciji zadužena za usklađenost.

Zatim ih primenite u platformi:

Koristite Microsoft Purview retention labele na odobrenim dokumentima i na audit logu.
Ne dozvolite da istorija pokretanja flow-⁠a bude vaš jedini zapis, jer se ona čuva ograničeno vreme.
Opišite kako biste izvezli kompletan trag za jedan dokument, i taj izvoz zaista isprobajte.

Testirajte tok onako kako bi to uradio revizor

Većina timova proveri da odobrenje prolazi. Manje njih proveri šta se dešava kada nešto krene naopako. Pre puštanja u rad prođite kroz slučajeve poput ovih:

Autor pokušava da odobri sopstveni dokument.
Dokument se menja dok je odobrenje na čekanju.
Odobravalac se usred ciklusa uklanja iz grupe.
Zamena ističe dok je zadatak otvoren.
Dva odobravaoca odgovore skoro u istom trenutku.
Flow pukne na pola i zahtev se podnese ponovo.
Administrator otkaže zahtev.

Za svaki slučaj proverite i ishod i log. Ispravan ishod bez zapisa u logu i dalje pada na reviziji.

Ako odluku ne možete da rekonstruišete samo na osnovu loga, bez pitanja bilo koga, log nije gotov.

Česte greške

Status odobrenja se čuva u koloni koja može da se menja i nema istoriju.
Odobrava se link ka dokumentu, a ne konkretna verzija.
Akcija odobravanja radi pod servisnim nalogom, pa se taj nalog beleži kao odobravalac.
Podnosilac u formi zahteva slobodno bira odobravaoca.
Istorija pokretanja flow-⁠a se koristi kao trajni zapis.
Tok se menja u produkciji bez verzionisanja, pa stara odobrenja više ne odgovaraju trenutnoj logici.
Zamena se tretira kao prosleđen mejl, a ne kao zabeleženo i vremenski ograničeno ovlašćenje.

Odakle početi

Ako već imate tokove odobravanja, izaberite proces koji je najosetljiviji na reviziju i postavite mu pet pitanja sa početka ovog teksta. Gde god je odgovor „moraćemo da proverimo sa nekim“, postoji rupa u dizajnu.

Zatvaranje tih rupa je obično manje posla nego što deluje. Verzionisanje, pravi log i podela dužnosti koja se zaista sprovodi pokrivaju veći deo onoga što revizori traže.