Rozdělení odpovědností podle RACI matice

Co je RACI a proč je důležitá pro projektové týmy

RACI matice je snadno čitelný model rozdělení odpovědností, který jasně stanovuje, kdo je zodpovědný za provedení (Responsible), kdo je konečně odpovědný (Accountable), kdo je konzultovaný (Consulted) a kdo je informovaný (Informed) u jednotlivých činností projektu. Jejím cílem je odstranit nejasnosti v rolích, předcházet duplicitě práce a zkrátit rozhodovací cyklus. V prostředí průřezových a hybridních týmů slouží RACI jako „provozní smlouva“, která doplňuje projektový plán a governance.

Definice a význam jednotlivých rolí R-A-C-I

Responsible (R): osoby nebo týmy, které práci vykonávají. Může jich být více, ale musí být jasná koordinace a prostor pro provedení úkolu.
Accountable (A): jeden finální vlastník výsledku a rozhodnutí. Předchází „ředění“ odpovědnosti a je spojkou na sponzora nebo steering committee.
Consulted (C): subjekty poskytující vstupy a odbornost. Interakce je obousměrná (diskuse), typicky odborní garanti, právníci, bezpečnost, zákaznický zástupce.
Informed (I): strany, které musí být transparentně a včas informovány o výsledku či změně, aby mohly sladit své aktivity. Interakce je jednosměrná (broadcast).

Kdy a kde RACI použít

Komplexní projekty s více funkcemi: vývoj produktu, IT implementace, regulační iniciativy, změny procesů.
Body zvýšeného rizika: rozhodnutí o rozpočtu, bezpečnostní výjimky, cut-over a go-live, právní a compliance schválení.
Opakované činnosti: release management, incident management, změnové řízení, zadávání zakázek, onboarding dodavatelů.

Postup zavedení RACI v projektu (krok za krokem)

Vymezení rozsahu: definujte, pro které procesy a milníky bude RACI vytvořena (nezahrnujte vše, pouze „kritickou cestu“ a rozhraní).
Mapování činností: z projektového WBS vyberte hlavní činnosti a rozhodovací body. Sdružujte příbuzné úkoly do logických bloků (např. „Testování a akceptace“).
Inventarizace rolí: použijte role, ne jména (např. „Product Owner“, „Právník“, „Bezpečnostní architekt“). Jména přiřaďte až po schválení matice.
Přiřazení R/A/C/I: pro každou činnost určete alespoň jedno R a přesně jedno A. C a I přidělujte střídmě podle skutečné potřeby.
Validace se stakeholdery: projděte matici na workshopu; hledejte kolize, duplicity A, nadměrný počet C a slepá místa bez I.
Publikování a propojení: matici uložte do „jediného zdroje pravdy“, propojte ji s projektovým plánem, decision logem a komunikačním plánem.
Údržba: revidujte při změnách rozsahu, organizačních přesunech a po retrospektivách.

Ukázková RACI matice (ilustrativní příklad)

Činnost	Projektový manažer	Product Owner	Vývojový tým	QA lead	Bezpečnost	Právo	Provoz (OPS)	Sponzor
Definice cílů a milníků	A	C	I	I	I	I	I	C
Specifikace požadavků	I	A	C	C	C	C	I	I
Implementace a build	I	C	R	C	I	I	I	I
Testování a akceptace	I	A	R	R	C	I	I	I
Bezpečnostní posouzení	I	C	I	C	A	I	I	I
Licenční a smluvní podmínky	I	C	I	I	I	A	I	I
Release a nasazení	A	C	R	C	C	I	R	I
Go-live rozhodnutí	C	A	C	C	C	C	I	I

Nejčastější chyby při práci s RACI

Dvě a více „A“ u jedné činnosti: oslabuje odpovědnost a prodlužuje rozhodování. Pravidlo „jeden A“ dodržujte striktně.
Příliš mnoho „C“: zahlcení konzultacemi vede k paralýze. Konzultujte pouze tam, kde vstup mění kvalitu nebo rizikový profil rozhodnutí.
Chybějící „I“: pokud informování selže, vznikají kolize plánů a nutnost přepracování. Nastavte jasné kanály a rytmus informování.
Přiřazení podle jmen, nikoli rolí: snižuje přenositelnost. V matici používejte role; jména uchovávejte v samostatné mapě RACI→lidé.
„Papírová“ RACI bez propojení na praxi: pokud není v decision logu, komunikačním plánu a kalendáři, nebude používána.

Rozšíření a alternativy: kdy sáhnout po RASCI, DACI, RAPID

RASCI (přidává „S“ – Support): vhodné, pokud jsou při výkonu odlišeny výkonné a podpůrné kapacity (např. platformový tým).
DACI: Driver, Approver, Contributors, Informed – používá se při produktových rozhodnutích s jasným „Driverem“.
RAPID: Recommend, Agree, Perform, Input, Decide – klade důraz na kroky rozhodování v složité governance.
CAIRO: RACI + „O“ (Out of the loop) – explicitně ukazuje, kdo nemá být zapojen, aby se chránila kapacita.

Propojení RACI s agilními rámci a DevOps

RACI není v rozporu s agilními principy. Ve Scrumu je např. Product Owner často „A“ za hodnotu produktu, Vývojový tým je „R“ za implementaci, Scrum Master může být „R“ za procesní zlepšení. V DevOps kontextu je OPS častěji „R“ při nasazení, ale „A“ může mít vlastnická produktová role při „go/no-go“. Důležité je, aby RACI odrážela reálný způsob práce týmu a rozhraní s okolními funkcemi.

Integrace RACI do projektové dokumentace a nástrojů

Projektová charta: shrnuje klíčové „A“ a rozhodovací pravomoci.
Plán komunikace: propojuje „I“ na kanály, periodicitu a vlastníky zpráv.
Decision log: pro rozhodnutí definujte „A“ a „C“; uveďte datum revize a kritéria pro změnu.
Nástroje: v nástrojích jako wiki, projektové portály či nástroje pro řízení práce udržujte RACI jako živý dokument s historií změn.

RACI v hybridních a externích týmech

Kontraktační vazby: u dodavatelů definujte, které body mají „A“ na straně klienta a které na straně dodavatele (např. bezpečnostní výjimky).
Časová pásma: sladěte „C“ a „I“ s dostupností; asynchronní Q&A a SLA na odpověď.
Escalation path: u sporných „A“ uveďte jasnou eskalační linii (projektový manažer → sponzor → steering committee).

Metodika správy změn v RACI (governance)

Práh změny: definujte, kdy je potřeba formální revize (změna rozsahu, rozpočtu, kritických závislostí).
Versioning: každá verze matice má číslo verze, datum a schvalujícího.
Transparentnost: změny jsou oznamovány v pravidelném reportu; historii udržujte auditovatelnou.

Měření přínosu: jak poznat, že RACI funguje

Zkrácení lead time rozhodnutí: méně nejasností, rychlejší „go/no-go“ na klíčových bodech.
Snížení reworku: méně kolizí a duplicitní práce mezi týmy.
Kvalita eskalací: méně ad hoc eskalací, více předvídatelných a podložených případů.
Spokojenost stakeholderů: vyšší skóre jasnosti rolí v pulzních průzkumech.

Praktická doporučení a „good practices“

Začněte od rozhodnutí, ne od hierarchie: identifikujte, kde se rozhoduje a jaký má dopad – podle toho přiřaďte „A“.
Minimalizujte „C“: konzultujte pouze hodnototvorně; zbytek řešte standardy nebo šablonami.
„A“ je přenosné, nikoli kolektivní: pokud je potřeba střídání, uveďte pravidla substituce a zastupování.
Vizualizujte: udělejte matici čitelnou a dostupnou (tabulka, barvy, legenda, odkazy na definice).
Propojte s kompetencemi: pokud „R“ nemá potřebné schopnosti, doplňte plán rozvoje nebo podporu (RASCI).

Checklist pro kvalitní RACI matici

Má každá činnost přesně jedno A a alespoň jedno R?
Je počet C odůvodněný a srozumitelný (co přesně dodávají a kdy)?
Jsou všechny klíčové sousední týmy zahrnuty alespoň jako I?
Je matice propojena s decision logem, plánem komunikace a kalendářem?
Je RACI napsaná jazykem rolí a ne jmen?
Existuje schválená verze a definovaný proces aktualizace?
Je matice reálně používána na schůzkách a v reportech (nejen v archivu)?

RACI jako akcelerátor odpovědnosti a rychlosti

RACI matice není byrokratická tabulka, ale praktický nástroj, který mění způsob, jakým týmy spolupracují a rozhodují. Pokud je vytvořena rozumně, udržována jako živý dokument a pevně propojena s řízením projektu, zkracuje cykly, snižuje rizika a zlepšuje kvalitu výsledků. Její síla spočívá v jednoduchosti: jeden jasný vlastník rozhodnutí, transparentní vykonavatelé a adekvátní zapojení zbytku organizace.