Rols i responsabilitats en projectes IT: matriu RACI com a aclariment ràpid per a decisors

En molts projectes de TI no és la tècnica la limitació, sinó la pregunta: qui decideix realment què — i qui ho implementa? Quan els rols i les responsabilitats en el projecte de TI només estan aclarits «per sensació», apareixen patrons típics: els requisits es revisen diverses vegades, els tickets donen voltes, les acceptacions s’allarguen i, en cas d’incident, no queda clar qui prioritza o qui comunica. Precisament aquí la matriu RACI és una eina pragmàtica: fa visibles les responsabilitats, redueix la fricció a les interfícies i acurta els camins de decisió — sense una pesada burocràcia de governança.

El benefici és especialment gran en projectes amb diversos departaments, unitats operatives, requisits de seguretat/compliance o proveïdors externs. Els decisors obtenen una visió clara d’on recau realment la responsabilitat, i la direcció del projecte així com l’administració TI poden dissenyar processos perquè el delivery i l’explotació no treballin l’un contra l’altre. Important: RACI no és un organigrama ni un substitut del lideratge. És una reconciliació sobre tasques, decisions i obligacions d’informació — alineada amb paquets de treball reals, fluxos de dades i entregues.

Per què les responsabilitats en projectes de TI sovint escalen

Les responsabilitats poc clares rarament es detecten el primer dia. Es tornen visibles quan augmenta la complexitat: múltiples sistemes, dependències, requisits de seguretat, migracions de dades, llançaments paral·lels. Aleshores, «ho fem conjuntament» ja no és suficient. A la pràctica apareixen especialment tres causes:

• Interfícies entre equips: el negoci, TI, explotació, seguretat, compres i socis externs persegueixen objectius diferents i tenen definicions diferents de «fet».
• Decisions sense un owner clar: si ningú és formalment responsable, es busca consens. Això consumeix temps i sovint resulta en acords formulats de manera ambigua.
• Pressió operativa: com a molt tard en cas d’incidències, finestres de canvi o preparació de go‑live cal actuar ràpid. Llavors l’absència d’un camí d’escalat esdevé immediatament costosa.

Precisament en paisatges empresarials evolucionats les responsabilitats estan distribuïdes històricament: un sistema està ancorat funcionalment a vendes, tècnicament a TI, operat per un proveïdor, les interfícies les manté l’equip A, la qualitat de dades està «en algun lloc». Quan un projecte modernitza o amplia aquest entorn, les llacunes de responsabilitat no només apareixen orgànicament, sinó també en termes tècnics concrets: Qui aprova un Breaking Change a una REST-Schnittstelle? Qui assumeix el risc en una neteja de dades? Qui decideix si s’aplica un fix de seguretat fora de la finestra de manteniment?

Matriu RACI a la pràctica: significat de R, A, C i I

RACI és un model de rols que per cada tasca (o deliverable) distingeix quatre tipus de participació. És fonamental la definició precisa, perquè sense ella el model es dilueix ràpidament:

• R – Responsible (Responsabilitat d’execució): Qui executa pràcticament la tasca? Poden ser diverses persones o equips.
• A – Accountable (Responsabilitat sobre el resultat): Qui assumeix la responsabilitat final i decideix en cas de dubte? Per tasca hauria d’haver-hi exactament una rol accountable, si no sorgeixen dobles responsabilitats.
• C – Consulted (Consultat): Qui cal involucrar funcional o tècnicament abans de decidir o executar? La consultació és un intercanvi actiu, no un correu d’informació.
• I – Informed (Informat): Qui ha de ser informat sobre el resultat, la data o el risc? Això és informació unidireccional, no decisió compartida.

Per als responsables de decisió, la línia divisòria entre Responsible i Accountable sovint és la palanca més important. En projectes IT sovint es deleguen tasques, però no es transfereix la responsabilitat de manera clara. Així, potser hi ha un equip que «treballa», però ningú pren decisions vinculants en conflictes d’objectius (Scope vs. seguretat operativa, Time-to-Market vs. qualitat de dades, petició de funcionalitat vs. requisit de seguretat).

Per a què la matriu RACI és especialment adequada – i per a què no

RACI funciona bé quan les tasques es repeteixen o es poden descriure com a entregables clars. Exemples típics:

• Processos de change i release: aprovació, finestres de manteniment, decisió de rollback, comunicació.
• Acceptacions: UAT (User Acceptance Test, acceptació funcional), acceptació tècnica, aprovació de seguretat, aprovació operativa.
• Integració i interfícies: contractes d’API, versionament, responsabilitat de monitorització, escalat d’incidents.
• Migració de dades: mapeig, neteja de dades, aprovació de regles de transformació, informes de conciliació.
• Lliurament a operacions: Runbooks (instruccions d’operació), monitorització, règim d’on-call, responsabilitat en l’operació diària.

RACI no és ideal quan les tasques estan formulades massa de forma general («entregar el projecte», «assegurar la qualitat») o quan l’equip utilitza la matriu com a substitut de la comunicació real. RACI no substitueix la gestió d’interessats ni el lideratge; n’estructura els processos. A més, RACI no és una eina per mesurar el rendiment de persones individuals; és un instrument de governança pensat per facilitar el flux de treball.

Com crear una matriu RACI en 60 a 90 minuts

Una bona matriu RACI no neix al despatx sinó en un taller amb els rols rellevants. L’objectiu no és la completitud fins a l’última tasca especialitzada, sinó la claredat en els camins crítics. Un procediment pràctic:

1. Definir l’abast (Scope): Per a quina fase s’aplica la matriu (p. ex. projecte fins a Go-live, Hypercare, explotació normal) i per a quina cadena de processos (p. ex. change fins a release)?
2. Desglossar les tasques: Sovint n’hi ha prou amb 10 a 25 tasques. Formuli les tasques com a resultat: «aprovar el contracte d’interfície», «definir les alarmes de monitorització», «finalitzar el mapeig de dades».
3. Rols en lloc de noms: Utilitzi rols (p. ex. operacions IT, responsable del departament funcional, Product Owner, Seguretat, proveïdor extern). Els noms canvien, els rols romanen.
4. R i A primer: Assigni exactament una A per tasca, després la R. Completi C i I només quan R/A siguin estables.
5. Resolució oberta de conflictes: Si dues rols volen ser «A», això és un tema de governança. Aclareixi els drets de decisió, no només la participació.

Per a la direcció de TI i els responsables de projecte és especialment important que la matriu estigui vinculada a rutines reals de govern: Change Advisory Board (CAB, comitè per a l’aprovació de canvis), Weekly Steering, Incident-Review, reunió d’acceptació. Sense aquesta vinculació la RACI esdevé un document que ningú fa servir.

RACI-Matrix com a accelerador de decisions per a l’alta direcció i el Steering

En comitès de direcció i reunions d’estat sovint es discuteixen continguts, tot i que la pregunta real és: Qui pot decidir? Una RACI-Matrix ben mantinguda permet tres simplificacions:

• Els camins de decisió queden explícits: Si „A“ és clar, un tema es pot preparar i després decidir, en lloc de donar voltes en cercle.
• Les escalades es tornen objectives: Una escalada deixa de ser un fracàs personal i es converteix en un pas definit quan R i A no coincideixen o quan els riscos afecten pressupost/abast.
• Els riscs tenen un owner: Els registres de risc sense responsables no tenen valor. RACI obliga a assignar les decisions sobre risc a un owner accountable.

Els decisors se’n beneficien especialment quan la RACI es combina amb un Decision-Log concís: Què es va decidir, per part de qui (A), i amb quines implicacions per a l’abast, l’operació i els terminis? Això redueix discussions posteriors en l’acceptació o en l’auditoria, perquè queda rastrejable per què es va triar un camí.

Errors típics en la RACI-Matrix — i com evitar-los

1) Massa „A“ per tasca

Varias funcions accountable són un reflex habitual per evitar conflictes („decidim conjuntament“). A la pràctica, però, això genera incertesa: si dues entitats són finalment responsables, en cas de dubte ningú se sent responsable. Millor: un únic A, consultes clares (C) i un camí d’escalada definit si hi ha objeccions de la C.

2) La „C“ esdevé co-decisió

Les funcions consultades són importants, com ara Security, protecció de dades, arquitectura o operació. Però si la „C“ exerceix de facto un dret de veto sense tenir responsabilitat formal, es desplaça l’equilibri de la decisió. Aclareixi per tant en el mateix pas: quins criteris condueixen a una aturada? On és només una recomanació? I qui decideix en cas de conflicte d’objectius? Això és governança, no „política“.

3) Les tasques són massa generals o no són operatives

„Provar“ no és una bona tasca. Millor: „aprovar l’abast del regression test“, „proporcionar dades de prova“, „marcar la llista de comprovacions de Go-live“. Com més concreta sigui la tasca, més fàcil és l’assignació — i més ajudarà la RACI en el dia a dia (tickets, aprovacions, traspasos).

4) La RACI no s’ajusta a la realitat operativa

Molt projectes creen una matriu per a la fase de projecte, però no per al període posterior. Precisament llavors sorgeixen les fissures conegudes: Qui opera la nova interfície? Qui actualitza els certificats? Qui manté els rols d’usuari? Qui avalua les alertes? Planifiqui la RACI almenys per a dues fases: projecte fins a Go-live i Hypercare/operació rutinària.

RACI al llarg del cicle de vida: des dels requisits fins a l’explotació

Perquè RACI no sigui només un artefacte de kick-off, val la pena analitzar les etapes típiques d’un projecte. D’aquesta manera, les persones decisòries poden comprovar de manera dirigida si la responsabilitat està coberta de manera contínua.

Requisits i abast

Per al programari empresarial a mida i les solucions pròximes als processos, els requisits rarament estan „acabats“, sinó que es concreten de manera iterativa. Això funciona si està clar qui és accountable des del punt de vista funcional per a la priorització i qui cal consultar (p. ex. operacions per a la mantenibilitat, Security pel requeriment de protecció). Tasques típiques: „priorització del backlog“, „aprovació dels criteris d’acceptació“, „aprovació dels canvis de procés“. Si aquí no existeix un A, apareixen derivacions de l’abast i, més endavant, discussions d’aprovació difícils.

Arquitectura, interfícies i fluxos de dades

En paisatges evolucionats, l’arquitectura tècnica sovint està distribuïda. Una matriu RACI ajuda a aclarir l’ownership dels contractes d’interfície i dels fluxos de dades: Qui és accountable per l’estabilitat d’una REST-API? Qui assumeix la responsabilitat de les regles de mapeig entre el sistema antic i la nova solució? Qui decideix sobre la versionització i la deprecació (apagat planificat de versions antigues d’interfícies)? Aquests punts no són només tècnics: determinen si altres sistemes continuen funcionant de manera fiable i si operacions i suport són capaços d’actuar en cas d’incidència.

Proves, aprovació i autoritzacions

En molts projectes la planificació temporal es trenca a causa d’aprovacions. La causa rarament és „manca de proves“, sinó responsabilitats poc clares: Qui proporciona dades de prova? Qui prioritza les incidències? Qui decideix si un Known Issue (error conegut) és apte per al go-live? Una RACI ben definida fa que els processos d’aprovació es puguin planificar, perquè queda clar quina funció ha de prendre una decisió i qui només ha d’estar informat.

Go-live, Hypercare i transferència a l’explotació

Com a molt tard en el Go-live la governança passa a ser operativa: el monitoratge ha d’estar actiu, els runbooks han de ser comprensibles, l’On-Call ha de saber a qui contactar per qüestions funcionals. RACI estructura aquesta transició. Tasques típiques: „aprovació del Go-live“, „configuració del monitoratge i l’enrutament d’alarma“, „aprovar la documentació d’explotació“, „transferència al Service Desk“. Especialment important: definiu qui és accountable per la capacitat operativa (no només per l’entrega).

RACI en entorns mixtes: intern, extern, proveïdors

Moltes empreses treballen amb socis externs: per al desenvolupament, operacions, infraestructura o temes especialitzats. En aquests casos RACI és doblement important, perquè els límits contractuals sovint es confonen amb límits de responsabilitat. Un proveïdor pot ser Responsible de la implementació, però el Accountable sovint continua sent intern, per exemple el propietari del sistema o la direcció de TI. Això no és una declaració de desconfiança, sinó necessari per al control, el pressupost i el risc.

Guies pràctiques per a la participació externa:

• Accountable queda on està el risc i la decisió: pressupost, priorització, acceptació de riscos, aprovacions.
• Responsible està on realment es treballa: implementació, configuració, configuració del monitoring – amb criteris d’acceptació clars.
• C i I han d’encaixar en el contracte i en els processos d’operació: Qui cal consultar abans de fer changes? Qui s’informa en cas d’incidents? Això ha d’estar en l’acord d’operació, no només en la presentació del projecte.

Precisament en les interfaces hi ha una trampa freqüent: el proveïdor pot «operar», però ningú és accountable per la cadena fi a fi. Per això la RACI hauria d’incloure tasques com «definir el monitoring fi a fi» o «gestionar la comunicació d’incidents als stakeholders» – amb owners clars.

RACI troba Compliance, Security i protecció de dades: participació clara en lloc d’obstrucció

La seguretat i la protecció de dades sovint es perceben als projectes com a «bloquejadores» quan s’involucren tard o quan els requisits no s’han traduït a criteris aplicables. La RACI pot alleujar-ho: Security/protecció de dades s’inclouen de manera dirigida com a Consulted en les tasques rellevants, i la rol accountable decideix sobre la base de criteris definits.

És important distingir entre:

• Requisits de política (p. ex. estàndards mínims per a autenticació, registre, conservació): aquí han d’existir punts de verificació clars perquè la consulta sigui planificable.
• Decisions sobre risc (p. ex. excepció temporal, risc residual): aquí cal designar un rol accountable que assumeixi i documenti el risc.

Així la seguretat es manté efectiva, sense que les decisions caiguin en cercles de coordinació difusos. Per a l’operació això és essencial: l’auditabilitat no s’aconsegueix amb més reunions, sinó amb responsabilitats clares i decisions rastrejables.

Plantilla mínima: quines tasques han d’anar en una matriu RACI

Com a punt de partida ha demostrat la seva validesa un «conjunt mínim» que cobreix els camins crítics. Segons el projecte en podeu afegir, però aquest conjunt evita les llosques típiques:

• Priorització de backlog/abast i Change-Control (tractament de noves demandes)
• Aprovació de decisions d’arquitectura (p. ex. integració, emmagatzematge de dades, autenticació)
• Contracte d’interfícies i versionat (inclòs el pla de deprecació)
• Migració de dades: mapeig, neteja, reconciliació, aprovació
• Provisió de dades de prova, planificació UAT, classificació de defects i decisió Go/No-Go
• Aprovació de release i changes (finestra de manteniment, rollback, comunicació)
• Monitoring/Alerting, accessos als logs, responsabilitat pel ruteig d’alarms
• Runbooks, documentació d’operació i lliurament al Service Desk / operació
• Escalada d’incidents i responsabilitat de comunicació

Aquesta plantilla és deliberadament propera als processos. Connecta el treball de projecte amb la realitat operativa: qui en un projecte de TI només „subministra“, però no aclareix qui s’encarregarà després de l’explotació, genera costos addicionals — en suport, estabilitat i en posteriors rondes de modernització.

Com s’utilitza RACI en el dia a dia: tiquets, reunions, lliuraments

El pas decisiu és l’operacionalització. Tres mecanismes senzills porten RACI de la teoria al dia a dia:

Enllaçar RACI amb els processos de tiquets i canvis

Quan es crea un ticket de canvi, hauria de quedar clar qui (A) té la responsabilitat final d’atorgar l’aprovació i qui ha de ser consultat. Això es pot reflectir en camps de formulari, llistes de comprovació o en un flux de treball de canvi. D’aquesta manera RACI no es gestiona „a banda“, sinó que forma part del procés.

RACI com a diapositiva estàndard per a decisions crítiques

En temes com canvi d’interfícies, neteja de dades o decisió de Go-live sovint n’hi ha prou amb una breu representació: tasca, decisió proposada, risc i assignació RACI. Això disciplina les discussions: Qui decideix? Qui aporta informació? Qui és informat? Així les reunions es mantenen breus i augmenta l’orientació als resultats.

Incorporar RACI en la documentació de lliuraments i d’explotació

Els runbooks i la documentació d’explotació només són efectius si inclouen una secció d’assignació de responsabilitats: propietari del sistema (A), equip d’explotació (R), seguretat/protecció de dades (C) i parts interessades rellevants (I). Això evita que, en cas de canvi de personal o de proveïdor, s’iniciï de nou la mateixa discussió sobre responsabilitats.

Conclusió final: la matriu RACI és petita, però té impacte als punts adequats

La matriu RACI no és un marc complex de gestió de projectes, sinó un instrument ràpid per aclarir rols i responsabilitats en un projecte TI. El seu efecte es produeix on els projectes típicament perden temps: en decisions, interfícies, aprovacions i lliuraments a explotació. Qui adapta RACI a entregables reals, assigna per tasca exactament un rol accountable i enllaça la matriu amb els processos de canvi, tiquets i lliuraments, redueix els cicles de coordinació i fa els riscos controlables — tant per a TI, com per a les unitats de negoci i els decisors.

Si, en un projecte en curs, voleu ajustar de manera pragmàtica rols, vies de decisió o el lliurament a explotació, val la pena fer un breu taller de posada en comú amb els rols rellevants. Contacteu-nos per això si ho desitgeu:

Per a aquest tema també són importants Aclarir responsabilitats i Governança al projecte. L’article situa aquests aspectes de manera comprensible i mostra què cal tenir en compte en el dia a dia.

Parlar del projecte o d’una iniciativa de modernització amb Net-Base.