Chaos vo firemnom IT často nevzniká z dôvodu, že by ľudia nepracovali dostatočne. Vzniká preto, že rozhodnutia často nie sú jasné a stabilné, nie sú dohľadateľné a po pár týždňoch sa o tej istej veci vedie tá istá debata znova.
Inými slovami, firma nemá problém s execution, má problém s decision hygiene.
Poznáte to. Porada skončila, všetci prikývli. O mesiac neskôr sa však projekt zasekol, pretože:
- „Kto to vlastne schválil?“
- „Ja som si myslel, že prioritou je B, nie A.“
- „Audit chce dôkaz, že sme toto riziko vedome akceptovali, ale nemáme ho.“
Nepotrebujete drahý softvér ani nový procesný rámec. Často stačí Decision Log. Jednoduchý nástroj IT governance, ktorý zavedie poriadok do rozhodovania bez toho, aby ste zavádzali byrokraciu.
Čo je Decision Log a prečo to nie je len zápisnica
Decision Log je centralizovaný register kľúčových rozhodnutí. Na rozdiel od MoM (zápisu zo stretnutia), ktorá zachytáva diskusiu, Decision Log zachytáva to, čo platí.
Je to praktická governance kontrola, ktorá podporuje princípy bežných rámcov:
- COBIT: Pracuje s decision rights, accountability a transparentnosťou. Decision Log je mechanizmus, ktorý bráni tomu, aby sa riadenie zmenilo na sériu náhodných meetingov.
- ISO 38500: Stavia na responsibility a conformance. Log vytvára dohľadateľnú stopu o tom, kto prevzal zodpovednosť a aké riziko bolo vedome prijaté.
- ITIL 4: V rámci governance a continual improvement je dohľadateľnosť rozhodnutí nutnosť, nie administratíva.
Poznámka: V architektúre existuje príbuzná best practice ADR (Architecture Decision Record). Kým ADR rieši technické voľby, Decision Log rieši manažérske a strategické voľby. Tieto dva nástroje sa výborne dopĺňajú.
Čo riskujete, ak ho nemáte
Bez Decision Logu vznikajú opakovane náklady, ktoré nie sú na prvý pohľad viditeľné:
- Vracajúce sa rozhodnutia: Témy, ktoré boli uzavreté, sa otvárajú znova, pretože rozhodnutie nebolo nikde ukotvené.
- Spätné prepisovanie histórie: Rozhodnutia sa menia podľa toho, kto je v miestnosti práve najhlasnejší.
- Tichá akceptácia rizika: Keď nastane incident, zrazu nikto „nechcel“ to lacné, ale rizikové riešenie.
- Scope creep: Maskuje sa ako drobné zmeny, pretože neexistuje stopa, kedy a prečo sa scope zafixoval.
Ako postaviť Decision Log, ktorý reálne funguje
Ak to má byť funkčné, musí to byť minimum viable governance. Tu sú štyri pravidlá:
1. Definujte scope: Čo tam patrí a čo nie
Do Decision Logu nepatrí operatíva typu „kúpime 5 notebookov“. Patrí tam minimum rozhodnutí, ktoré majú priamy dopad na stratégiu, riziko, architektúru alebo peniaze:
- Priority a poradie veľkých iniciatív.
- Vedomá akceptácia rizika (Risk Acceptance) a výnimky.
- Výber strategického vendora alebo technológie.
- Zmeny SLA alebo service modelu.
2. Dáta: 10 stĺpcov a dosť
Neprekomplikujte to. Základný log má mať tieto stĺpce:
- ID (napr. D-2026-001)
- Dátum
- Rozhodnutie (jedna jasná veta)
- Owner (accountable)
- Kto schválil (napr. IT Steering)
- Dôvod / Kontext (2 až 3 vety)
- Dopad (čo to mení)
- Riziko (čo akceptujeme)
- Status (Active, Superseded, Retired)
- Review Date (kedy sa má rozhodnutie prehodnotiť)
Review Date je kľúčový údaj. Bez neho sa z logu stane mŕtvy archív.
3. Ownership: Kto velí
Ownerom Decision Logu nemôže byť abstraktné „IT“, „Projekt“, alebo „Sekurita“ . Musí to byť konkrétna rola, ktorá vedie governance cadence. Decision Log je povinný výstup z porady, nie dokument navyše.
- IT Director / CIO pre strategické rozhodnutia.
- PMO Lead pre projektové rozhodnutia.
- Security Manager pre bezpečnostné výnimky.
4. Kam s tým: Tam kde to žije
Technológia je druhoradá. Confluence, SharePoint, alebo zdieľaná tabuľka.
Podstatné je, aby to bolo dohľadateľné, verzované a aby sa to dalo použiť ako audit trail.
Ukážka: Takto môže vyzerať prvých 5 záznamov.
| ID | Dátum | Rozhodnutie | Owner | Schválil | Dôvod | Dopad | Riziko | Status | Review |
|---|---|---|---|---|---|---|---|---|---|
| D1 | 15.01.2026 | Prioritizácia stabilizácie Core služieb | IT Director | Steering Comm. | Nárast výpadkov v Q4 o 20%. Technický dlh brzdí prevádzku. | Stopka pre nové features na 3 mesiace. | Oneskorenie marketingovej kampane JAR 2026. | Active | 15.04.2026 |
| D2 | 20.01.2026 | Security fixy majú prednosť pred roadmapou | CISO | Board | Požiadavky NIS2 a rastúce hrozby ransomvéru. | Okamžité alokovanie kapacít pri kritických CVE. | Nespokojnosť produktových vlastníkov s termínmi. | Active | 20.07.2026 |
| D3 | 01.02.2026 | Single Intake iba cez Service Desk | SD Lead | Head of Ops | Strácanie požiadaviek v mailoch a „chodbové“ zadania. | E-mailové a telefonické požiadavky budú odmietnuté. | Dočasný odpor používateľov (Change Mgmt). | Active | 01.04.2026 |
| D4 | 10.02.2026 | Predschválenie Standard Changes | Change Mgr | CAB | CAB je preťažený rutinnými, nízko-rizikovými zmenami. | Zrýchlenie nasadzovania o 40%. | Riziko zneužitia kategórie pre zložitejšie zmeny. | Active | 10.05.2026 |
| D5 | 15.02.2026 | Cloud-first pre nové aplikácie | Chief Arch. | CTO | Potreba škálovateľnosti a zníženie on-premise nákladov. | Nutnosť rekvalifikácie adminov na Azure/AWS. | Vendor lock-in a variabilné OPEX náklady. | Review | 15.02.2027 |
Záver: Transparency kontrola, nie administratíva
Decision Log nie je o papieroch pre audítora. Je o disciplíne v rozhodovaní.
Keď sú rozhodnutia zapísané, prestávajú byť diskusiou, ktorá sa dá znova otvárať, alebo spochybňovať.
Čo spraviť zajtra ráno:
- Založte prázdny Decision Log, aj keby to mal byť jednoduchý spreadsheet.
- Spíšte doň prvých 5 rozhodnutí, ktoré sa u vás najčastejšie vracajú.
- Na najbližšom IT steeringu tento log otvorte a potvrďte, čo stále platí.
Efekt uvidíte rýchlo. Prestanete strácať čas riešením už vyriešeného.
