Uloge i odgovornosti u IT-projektima: RACI-matrica kao brzo razjašnjenje za donosioce odluka

U mnogim IT-projektima usko grlo nije tehnologija, nego pitanje: ko zapravo odlučuje šta – i ko to provodi? Kada su uloge i odgovornosti u IT-projektu riješene samo „na osjećaj“, pojavljuju se tipični obrasci: zahtjevi se višestruko usklađuju, ticketi prave petlje, prihvatanja se odugovlače, i u slučaju incidenta nije jasno ko postavlja prioritete ili komunicira. Upravo ovdje je RACI-Matrix pragmatičan alat: prikazuje odgovornosti, smanjuje trenja na sučeljima i skraćuje puteve odlučivanja – bez teške governance-birokracije.

Korisnost je posebno velika u projektima sa više poslovnih odjela, operativnih jedinica, zahtjevima Security/Compliance ili vanjskim dobavljačima. Donosioci odluka dobiju jasan uvid gdje stvarno leži odgovornost, a vođenje projekta i IT-administracija mogu oblikovati procese tako da isporuka i operacije ne rade jedna protiv druge. Važno: RACI nije organigram i nije zamjena za rukovođenje. To je usklađivanje zadataka, odluka i obaveza informisanja – duž realnih radnih paketa, tokova podataka i predaja.

Zašto odgovornosti u IT-projektima tako često eskaliraju

Neprecizne odgovornosti rijetko se primijete prvog dana. Postaju vidljive kada poraste kompleksnost: više sistema, zavisnosti, sigurnosni zahtjevi, migracija podataka, paralelna izdanja. Tada „radimo to zajedno“ više nije dovoljno. Tri uzroka se u praksi pojavljuju posebno često:

• Sučelja između timova: poslovni odjel, IT, operacije, sigurnost, nabava i vanjski partneri prate različite ciljeve i imaju različite definicije „završeno“.
• Odluke bez jasnog vlasnika: Ako formalno niko nije zadužen, traži se konsenzus. To oduzima vrijeme i često vodi ka nedorečenim odlukama.
• Operativni pritisak: Najkasnije kod kvarova, prozora za promjene ili pripreme za puštanje u rad mora se brzo djelovati. Tada nedostajući put za eskalaciju odmah postane skup.

U posebno razvijenim korporativnim okruženjima odgovornosti su povijesno raspodijeljene: sistem je poslovno ukorijenjen u prodaji, tehnički u IT‑u, upravlja ga dobavljač, sučelja održava tim A, a kvaliteta podataka je „negdje“ smještena. Kada projekt modernizira ili proširuje takav pejzaž, praznine u odgovornostima ne nastaju samo organizacijski nego i konkretno tehnički: Ko odobrava Breaking Change na REST-sučelju? Ko snosi rizik pri čišćenju podataka? Ko odlučuje hoće li se sigurnosna zakrpa primijeniti izvan prozora održavanja?

RACI-matrica u praksi: značenje R, A, C i I

RACI je model uloga koji za svaki zadatak (ili Deliverable) razlikuje četiri vrste sudjelovanja. Važna je precizna definicija, jer bez nje se model brzo razvodni:

• R – Responsible (odgovornost za izvršenje): Ko praktično obavlja zadatak? To mogu biti više osoba ili timova.
• A – Accountable (odgovornost za rezultat): Ko nosi konačnu odgovornost i odlučuje u nedoumici? Za svaki zadatak treba postojati tačno jedna Accountable uloga, inače nastaju dvostruke odgovornosti.
• C – Consulted (konsultiran): Koga treba stručno/tehnički uključiti prije nego se odluči ili provede? Konsultacija je aktivna razmjena, nije informativni e‑mail.
• I – Informed (informiran): Koga treba obavijestiti o rezultatu, terminu ili riziku? To je jednostrano informisanje, ne učestvovanje u odlučivanju.

Za donosioce odluka razgraničenje između Responsible i Accountable obično predstavlja najveću polugu. U IT-projektima zadaci se često delegiraju, ali odgovornost nije jasno prenesena. Tada tim „radi“, ali niko ne donosi obavezujuću odluku pri konfliktima ciljeva (opseg vs. operativna sigurnost, vrijeme izlaska na tržište vs. kvaliteta podataka, zahtjev za funkcionalnost vs. sigurnosni zahtjev).

Za šta je RACI-matrica posebno pogodna – a za šta nije

RACI dobro funkcionira kada su zadaci ponavljajući ili se mogu opisati kao jasni isporučivi rezultati. Tipični primjeri:

• Procesi promjena i izdanja: odobrenje, prozor održavanja, odluka o rollbacku, komunikacija.
• Prihvaćanja: UAT (User Acceptance Test, funkcionalno prihvaćanje), tehničko prihvaćanje, odobrenje sigurnosti, odobrenje za rad.
• Integracija i sučelja: API-ugovori, verzioniranje, odgovornost za monitoring, eskalacija incidenata.
• Migracija podataka: mapiranje, čišćenje podataka, odobrenje pravila transformacije, izvještaji usklađivanja.
• Predaja u operativu: runbooks (upute za rad), monitoring, on-call pravila, odgovornost u dnevnom radu.

Nije idealno koristiti RACI kada su zadaci formulirani preširoko („isporučiti projekt“, „osigurati kvalitetu“) ili kada tim koristi matricu kao zamjenu za stvarnu komunikaciju. RACI ne zamjenjuje upravljanje dionicima niti rukovođenje, već ih strukturira. Također, RACI nije alat za mjerenje učinka pojedinaca; to je instrument upravljanja koji treba omogućiti protok rada.

Kako sastaviti RACI-matricu za 60 do 90 minuta

Dobra RACI-matrica ne nastaje za uredskim stolom, već u radionici s relevantnim ulogama. Cilj nije potpuna pokrivenost do posljednjeg specijalnog zadatka, već jasnoća za kritične puteve. Praktičan tijek:

1. Odrediti opseg: Za koju fazu vrijedi matrica (z. B. projekt do Go-live, Hypercare, redovni rad) i za koji procesni lanac (z. B. promjena do izdanja)?
2. Razraditi zadatke: Obično je dovoljno 10 do 25 zadataka. Formulišite zadatke kao rezultate: „odobriti ugovor o sučelju“, „definisati alarme za monitoring“, „dovršiti mapiranje podataka“.
3. Uloge umjesto imena: Koristite uloge (z. B. IT-operacije, vlasnik poslovne oblasti, Product Owner, Security, vanjski dobavljač). Imena se mijenjaju, uloge ostaju.
4. R i A prvo: Dodijelite za svaki zadatak tačno jedno A, zatim R. C i I dopunite tek kada su R/A stabilni.
5. Otvoreno rješavajte konflikte: Ako dvije uloge žele biti „A“, to je pitanje upravljanja. Razjasnite prava odlučivanja, ne samo sudjelovanje.

Za IT-upravu i projektne odgovorne posebno je važno da se matrica poveže s realnim rutinama upravljanja: Change Advisory Board (CAB, odbor za odobravanje promjena), tjedni Steering, pregled incidenata, sastanak za prihvat. Bez te ukotvljenosti RACI ostaje dokument koji nitko ne koristi.

RACI-matrica kao ubrzivač odluka za rukovodstvo i Steering

U upravljačkim krugovima i statusnim rundama često se raspravlja o sadržaju, iako je stvarno pitanje: tko smije odlučiti? Pažljivo održavana RACI-matrica omogućava tri pojednostavljenja:

• Putovi odlučivanja postanu eksplicitni: Ako je „A“ jasno definiran, tema se može pripremiti i potom odlučiti, umjesto kružnog ponavljanja.
• Eskalacije postaju faktualne: Eskalacija tada nije osobni neuspjeh, već definiran korak kada R i A ne dođu do zajedničkog stava ili kada rizici utječu na budžet/obim.
• Rizicima se dodjeljuju vlasnici: Evidencije rizika bez odgovornih su bezvrijedne. RACI prisiljava da se odluke o rizicima dodijelite odgovornom vlasniku.

Donosioci odluka posebno imaju korist ako se RACI kombinira s kratkim zapisnikom odluka: Što je odlučeno, tko je odlučio (A), s kakvim utjecajem na obim, operativu i rokove? To smanjuje kasnije rasprave pri prihvatu ili auditu, jer je moguće rekonstruirati zašto je odabrano određeno rješenje.

Tipične pogreške u RACI-matrici – i kako ih izbjeći

1) Previše „A“ po zadatku

Više odgovornih uloga često je refleks kako bi se izbjegli konflikti („odlučujemo zajedno“). U praksi to upravo stvara nejasnoću: ako su dvije instance konačno odgovorne, u neizvjesnosti se nitko ne osjeća nadležnim. Bolje: jedno A, jasna konsultacija (C) i definiran put eskalacije ako postoje prigovori od strane C.

2) „C“ se pretvara u suodluku

Konsultirane uloge su važne, npr. Security, zaštita podataka, arhitektura ili operativni pogon. Ali ako „C“ faktički vrši veto bez formalne odgovornosti, ravnoteža odlučivanja se pomjera. Zato razjasnite u istom koraku: Koji kriteriji dovode do zaustavljanja? Gdje je to samo preporuka? I tko odlučuje u slučaju konflikta ciljeva? To je upravljanje (governance), ne „politika“.

3) Zadaci su pregrubi ili se ne mogu operacionalizirati

„Testiranje“ nije dobar zadatak. Bolje: „odobriti opseg regression testova“, „osigurati testne podatke“, „označiti stavke u Go-live-čeklisti“. Što je zadatak konkretniji, to je jednostavnija dodjela – i to će više pomoći RACI-ju u svakodnevnom radu (Tickets, odobrenja, predaje).

4) RACI se ne prilagođava operativnoj realnosti

Mnogi projekti kreiraju matricu za fazu projekta, ali ne i za vrijeme nakon toga. Upravo tada nastaju poznate praznine: tko upravlja novim sučeljem? Tko ažurira certifikate? Tko održava korisničke role? Tko procjenjuje alert-e? Planirajte RACI barem za dvije faze: projekt do Go-live i Hypercare/redovni pogon.

RACI duž životnog ciklusa: od zahtjeva do operacija

Da RACI ne ostane samo kickoff-artefakt, vrijedi pogledati tipične projektne faze. Donosioci odluka tako mogu ciljano provjeriti da li je odgovornost zaista kontinuirano pokrivena.

Zahtjevi i opseg

Za individualni poslovni softver i procesno orijentirana softverska rješenja zahtjevi rijetko kada budu „gotovi“, već se iterativno konkretiziraju. To funkcionira ako je jasno tko je fachlich accountable za prioritizaciju i tko se mora konzultirati (npr. operacije zbog održivosti, Security zbog potrebe zaštite). Tipične zadatke: „Priorisierung des Backlogs“, „Abnahme der Akzeptanzkriterien“, „Freigabe von Prozessänderungen“. Ako ovdje ne postoji A, nastaju Scope Creep i kasnije žustre rasprave o prihvatanju.

Arhitektura, sučelja i tokovi podataka

U rastućim okruženjima tehnička arhitektura je često distribuirana. RACI-matrica pomaže razjasniti vlasništvo nad ugovorima o sučeljima i tokovima podataka: Ko je accountable za stabilnost jedne REST-API? Tko odgovara za pravila mapiranja između naslijeđenog sustava i novog rješenja? Tko odlučuje o verzioniranju i deprecaciji (planirano gašenje starih verzija sučelja)? Ove točke nisu samo tehničke: one odlučuju hoće li ostali sustavi raditi pouzdano i hoće li operacije i podrška u slučaju grešaka imati mogućnost djelovanja.

Testiranje, prihvatanje i odobrenja

U mnogim projektima vremenski planovi zapinju na prihvatima. Uzrok rijetko kada leži u „premalo testiranja“, nego u nejasnoj nadležnosti: Tko dostavlja testne podatke? Tko prioritizira nedostatke? Tko odlučuje je li Known Issue (poznata greška) prikladan za go-live? Jasna RACI-mapa čini procese prihvata predvidljivima, jer je tada jasno koja uloga kada mora donijeti odluku – i tko se samo informira.

Go-live, Hypercare i primopredaja u radu

Najkasnije pri Go-liveu upravljanje postaje operativno: monitoring mora biti aktivan, Runbooks moraju biti razumljivi, On-Call mora znati koga kontaktirati za stručna pitanja. RACI strukturira ovu primopredaju. Tipični zadaci: „Freigabe Go-live“, „Einrichtung Monitoring und Alarmrouting“, „Betriebsdokumentation abnehmen“, „Übergabe an Service Desk“. Posebno važno: definirajte tko je accountable za operativnu sposobnost (ne samo za isporuku).

RACI u mješovitim setupima: interno, eksterno, izvođači

Mnoge tvrtke rade s eksternim partnerima: za razvoj, operacije, infrastrukturu ili pojedinačne specijalne teme. U tom slučaju RACI je dvostruko važan, jer se granice ugovora često miješaju s granicama odgovornosti. Izvođač usluge može biti Responsible za provedbu, ali Accountable često ostaje interno, npr. kod System-Ownera ili IT‑uprave. To nije izjava nepovjerenja, već nužnost za upravljanje, budžet i rizik.

Praktične smjernice za vanjske sudionike:

• Accountable ostaje tamo gdje su rizik i odluka: budžet, prioritizacija, prihvatanje rizika, odobrenja.
• Responsible je tamo gdje se stvarno radi: implementacija, konfiguracija, podešavanje monitoringa – s jasnim kriterijima prihvatanja.
• C und I moraju odgovarati ugovoru i operativnim procesima: tko se mora konzultirati prije promjena? tko će biti informiran o incidentima? To treba biti u operativnom sporazumu, ne samo u prezentaciji projekta.

Posebno kod sučelja česta je zamka: dobavljač „pokreće“ komponentu, ali nitko nije accountable za end-to-end lanac. RACI bi stoga trebao sadržavati zadatke poput „definirati end-to-end monitoring“ ili „upravljati komunikacijom o incidentima prema stakeholderima“ – s jasno određenim Owners.

RACI susreće usklađenost, sigurnost i zaštitu podataka: jasna suradnja umjesto blokade

Sigurnost i zaštita podataka često se u projektima doživljavaju kao „stopperi“ kada su uključeni kasno ili kada zahtjevi nisu prevedeni u provedive kriterije. RACI može ovdje olakšati: sigurnost/zaštita podataka ciljano se uključuju kao Consulted u relevantne zadatke, a accountable uloga odlučuje na temelju definiranih kriterija.

Važno je razlikovati između:

• Zahtjevi politike (npr. minimalni standardi za autentikaciju, logiranje, čuvanje podataka): ovdje bi trebale postojati jasne točke provjere kako bi konzultacija bila planirana.
• Odluke o riziku (npr. privremeno izuzeće, preostali rizik): ovdje mora biti imenovana accountable uloga koja snosi rizik i dokumentira ga.

Na taj način sigurnost ostaje djelotvorna, bez da odluke zapadaju u razvodnjene koordinacijske petlje. Za operativu je to presudno: mogućnost audita ne nastaje većim brojem sastanaka, nego jasnom odgovornošću i provjerljivo dokumentiranim odlukama.

Minimalni predložak: koje zadatke treba uključiti u RACI matricu

Kao polazna točka pokazao se „minimalni set“ koji pokriva kritične tokove. Ovisno o projektu možete dopuniti, ali ovaj set sprječava tipične praznine:

• Prioritizacija backloga/opsega i kontrola promjena (postupanje s novim zahtjevima)
• Odobrenje arhitektonskih odluka (npr. integracija, pohrana podataka, autentikacija)
• Ugovor o sučeljima i verzioniranje (uključujući plan deprecacije)
• Migracija podataka: mapiranje, čišćenje, usklađivanje, odobrenje
• Priprema testnih podataka, planiranje UAT-a, klasifikacija nedostataka i odluka Go/No-Go
• Odobrenje za release i promjene (vremenski prozori održavanja, rollback, komunikacija)
• Monitoring/Alerting, pristupi logovima, odgovornost za usmjeravanje alarma
• Runbooks, operativna dokumentacija i predaja Service Desku / operaciji
• Eskalacija incidenata i odgovornost za komunikaciju

Ovaj predložak je namjerno proksiman procesu. Povezuje rad na projektu s operativnom stvarnošću: ko u IT-projektu samo „isporuči“, ali ne razjasni ko će nakon toga preuzeti operativno održavanje, stvara naknadne troškove – u podršci, stabilnosti i kasnijim rundama modernizacije.

Kako se RACI koristi u svakodnevnom radu: tiketi, sastanci, primopredaje

Presudan korak je operacionalizacija. Tri jednostavna mehanizma izvode RACI iz teorije u svakodnevicu:

Povezati RACI s procesima tiketa i promjena

Kada se kreira Change-ticket, trebalo bi biti jasno ko je accountable za davanje odobrenja i ko mora biti konsultovan. To se može prikazati u poljima obrasca, kontrolnim listama ili u Change-Workflowu. Tako RACI nije „usput“ vođen, već živi u procesu.

RACI kao standardni slajd za kritične odluke

Kod tema kao što su izmjena sučelja, čišćenje podataka ili odluka o puštanju u rad često je dovoljna kratka prezentacija: zadatak, predložena odluka, rizik i RACI-raspored. To disciplinuje diskusije: Ko odlučuje? Ko daje input? Ko se informiše? Tako sastanci ostaju kratki i usmjerenost na rezultat se povećava.

Uvrstiti RACI u dokumentaciju primopredaje i operativnu dokumentaciju

Runbooks i operativna dokumentacija efikasni su samo ako sadrže odjeljak o odgovornosti: System-Owner (A), operativni tim (R), sigurnost/zaštita podataka (C) i relevantni dionici (I). To sprječava da se pri promjeni osoblja ili pružatelja usluga ista diskusija o nadležnostima ponovno pokrene.

Zaključak: RACI-Matrix je mala, ali djeluje na pravim mjestima

RACI-matrica nije kompleksan okvir za upravljanje projektima, već brzo sredstvo za razjašnjenje uloga i odgovornosti u IT-projektu. Njen efekt nastaje tamo gdje projekti tipično gube vrijeme: kod odluka, sučelja, prihvata i primopredaja u radu. Ko prilagodi RACI stvarnim isporučivim rezultatima, za svaki zadatak jasno odredi tačno jednu accountable ulogu i poveže matricu s procesima promjena, tiketa i primopredaja, smanjuje krugove usaglašavanja i čini rizike upravljivim – za IT, poslovne jedinice i donosioce odluka podjednako.

Ako u tekućem projektu želite pragmatično izoštriti uloge, puteve donošenja odluka ili primopredaju u operacije, vrijedi kratki usklađujući workshop s relevantnim ulogama. Obratite nam se po tom pitanju:

Za ovu temu su također važni razjašnjenje nadležnosti i upravljanje u projektu. Članak jasno razvrstava ove aspekte i pokazuje na što se u svakodnevici treba fokusirati.

Razgovarajte o projektu ili modernizacijskom poduhvatu sa Net-Base.