Model operacyjny
Model odpowiedzialności (RACI)
Standard językowy działa tylko wtedy, gdy ma właściciela, proces zmian i jasne role. RACI porządkuje odpowiedzialność: kto wykonuje pracę, kto za nią odpowiada, kogo trzeba skonsultować i kogo należy poinformować.
RACI, które działa w praktyce
RACI ma wartość tylko wtedy, gdy jest powiązany z decyzjami i artefaktami. Sam wykres ról niczego nie rozwiązuje, jeśli nie wiadomo: kto zatwierdza polityki, kto publikuje, kto prowadzi rejestry i kto odpowiada za regresje.
Minimalny zestaw ról w Luage
- Owner Standardu (A): odpowiada za wersje, publikację i wyjątki.
- Redakcja / Maintainer (R): utrzymuje treści i ich spójność.
- Security (C): konsultuje ryzyka, DLP, polityki dostępu, red teaming.
- Product / Ops (C): konsultuje skutki w procesie i integracjach.
- Wszyscy użytkownicy (I): są informowani o zmianach (release notes).
RACI a proces zmian
Zmiana standardu powinna przechodzić prostą ścieżkę: propozycja → recenzja → testy → publikacja → monitorowanie.
change_flow:
propose: R
review: C
approve: A
publish: R
monitor: R
audit: C
Antywzorzec: „wszyscy są odpowiedzialni”. W praktyce oznacza to, że nikt nie jest.
Lepiej mieć jednego A i dwóch C, niż pięciu A.
Co musi być w rejestrach
- Rejestr zmian (kto, co, dlaczego, policy_version).
- Rejestr wyjątków (czas obowiązywania, owner, ryzyko, kompensacja).
- Dowód testów regresji dla zmian wpływających na jakość/ryzyko.
Legenda
R = wykonuje • A = odpowiada • C = konsultowany • I = informowany
- Owner — właściciel standardu (jedna osoba / jedna funkcja).
- Domena — właściciel obszaru (produkt, support, marketing).
- Redakcja — utrzymuje styl, glosariusz i jakość treści.
- Inżynieria — integracje, automatyzacja, kontrola w pipeline.
- Security — ryzyka, dane, ograniczenia, incydenty.
- Compliance — wymagania prawne i regulacyjne.
Macierz (punkt wyjścia)
| Aktywność | Owner | Domena | Redakcja | Inżynieria | Security | Compliance |
|---|---|---|---|---|---|---|
| Definicja standardu (ton, styl, glosariusz) | A | C | R | I | C | C |
| Zmiana polityk/reguł (policy-as-code) | A | C | R | R | C | C |
| Publikacja matryc i szablonów | A | C | R | R | C | I |
| Wyjątek od standardu (jawny + termin ważności) | A | R | C | C | C | C |
| Ewaluacja jakości (testy, regresje, metryki) | A | C | C | R | I | I |
| Audyt zgodności i raport cykliczny | A | I | C | R | C | C |
| Incydent: prompt injection / ekspozycja danych | C | I | I | R | A | C |
| Onboarding zespołów i szkolenia | A | R | R | C | I | I |
To jest macierz „na start”. W praktyce dopasowuje się kolumny do struktury firmy, ale trzyma dwie zasady:
jedna aktywność ma jedną odpowiedzialność A, a wyjątki zawsze mają właściciela i termin.
Zasady wdrożeniowe
- Owner to funkcja, nie ozdoba. Jeśli Owner nie ma prawa powiedzieć „tak/nie”, RACI jest fikcją.
- Zmiany jak release. Wersja, opis zmiany, data wejścia, link do uzasadnienia.
- Wyjątek to dług. Dokumentujemy powód, ryzyko, plan spłaty i termin ważności.
- Audyt w rytmie. Stały cykl raportu (np. miesięczny/kwartalny) działa lepiej niż „akcje ratunkowe”.
Artefakty, które warto mieć
standard.md— definicje i zasady (wersjonowane).policy.yml— reguły „do egzekwowania” (tone, słownik, zakazy, format).templates/— matryce i szablony (z ownerem i statusem).exceptions.md— jawne wyjątki z terminem ważności.audit/— raporty zgodności i wyniki ewaluacji.