Kreativita, která přináší hodnotu

Od přesné otázky k ověřenému výsledku.

Propojuji analytické myšlení, vnímání souvislostí a srozumitelnou komunikaci.

Zlatá vizuální cesta od analýzy ke zlepšení

Můj způsob práce

Šest kroků, které se vzájemně propojují

Proces není přímka. Nové zjištění mě často vrací k otázce, zpřesnění nebo další variantě. Proto je cesta znázorněná jako živá, postupně se rozsvěcující linie.

⌕

Ujasnit účel

Pochopit, jaké rozhodnutí nebo potřebu má výstup podpořit.

Přesně se ptát

Ujasnit definice, očekávání a nejasnosti.

◎

Popsat souvislosti

Propojit požadavky, zdroje dat, procesní kroky a odpovědnosti.

✦

Předat zjištění

Oddělit doložená fakta, předpoklady, možné dopady a další postup.

✓

Ověřit skutečnost

Porovnat očekávaný a skutečný výsledek včetně výjimek a hraničních situací.

↗

Prověřit změnu

Vrátit se k původnímu požadavku a zkontrolovat výsledek.

V Quality Assurance

testovací scénáře mimo běžné „happy paths“
hledání skrytých vazeb a neobvyklých kombinací
odhalování příčin, nikoli pouze následků
srozumitelná komunikace chyb a rizik

DATA

V analýze a procesech

propojování potřeb uživatele a technického řešení
zjednodušování pracovních postupů
ověřování datové cesty a skutečného dopadu
hledání řešení i při omezených zdrojích

TEXT

V komunikaci

převod složitých témat do jasné struktury
přesné a přitom lidské formulace
vizuální uspořádání informací
texty, které pomáhají rozhodovat

Inspirace ověřenou praxí

Osm způsobů, jak posunout problém k řešení

Následující metody rozšiřují můj způsob uvažování o publikované zkušenosti IT týmů, bankovního dohledu a zlepšování procesů. U každého tématu odlišuji princip ze zdroje od návrhu praktického postupu. Cizí případy nejsou mými vlastními projekty.

Nejdřív porozumět situaci

Ověřit problém tam, kde vzniká

Rozhovor s uživatelem a pozorování skutečného postupu mohou změnit původní zadání. Design Council doporučuje nejprve porozumět lidem, kterých se problém týká; Toyota zdůrazňuje ověření situace přímo na místě. [5] [6]

Praktický postup: projít jednu konkrétní úlohu od zadání po výsledek. Zachytit čekání, ruční přepisy a obcházení systému. Oddělit potřebu „rychleji rozhodnout“ od předem zvoleného řešení „nový dashboard“.

Výstup: popis problému, dotčený uživatel a měřitelný cílový stav.

Od domněnky k ověření

Pracovat s více hypotézami

Google SRE popisuje diagnostiku jako opakované vytváření a ověřování hypotéz. Znalost očekávaného chování systému pomáhá zúžit hledání; samotná časová souvislost ještě neprokazuje příčinu. [1]

Praktický postup: pro nesprávný report prověřit alespoň vstup, transformaci a filtr. U každé varianty napsat, co ji potvrdí nebo vyvrátí. Začít levným, bezpečným testem a průběžně zapisovat výsledky.

Výstup: přehled hypotéz, důkazů a zbývající nejistoty.

Kreativita s kritérii

Navrhnout a porovnat varianty

Double Diamond propojuje rozšíření prostoru nápadů s následným výběrem a zkoušením řešení. Problém je vhodné nejprve vymezit a teprve potom rozhodovat, co změnit. [5]

Praktický postup: porovnat úpravu procesu, malou změnu systému a větší automatizaci. U každé zhodnotit dopad na uživatele, náročnost, riziko, závislosti a vratnost. Zachování stavu použít jako srovnávací základ.

Výstup: stručné zdůvodnění volby včetně nevýhod a podmínek úspěchu.

Celá datová cesta

Vyjasnit definice a odpovědnost

Zkušenosti sdílené s Basilejským výborem ukazují přetrvávající obtíže s datovou linií, roztříštěnými systémy a odpovědnostmi. Oprava jednoho reportu proto nemusí vyřešit širší problém dat. [4]

Praktický postup: sledovat konkrétní údaj od zdroje přes transformace až k použití. Sjednotit rozhodný okamžik, měnu a populaci. Určit odborného vlastníka definice i vlastníka technické opravy; ruční zásahy evidovat.

Výstup: mapa datové cesty, kontrolní body a jasný vlastník výjimky.

Když problém právě probíhá

Omezit dopad a koordinovat reakci

Google SRE doporučuje při vážném výpadku nejprve stabilizovat službu a současně uchovat důkazy pro pozdější analýzu. Hloubkové hledání příčiny nesmí bránit přiměřenému omezení škody. [1]

Praktický postup: pojmenovat dotčené služby a klienty, určit koordinátora a rytmus informování. Zvážit omezení funkce, zastavení změny nebo návrat podle předem ověřeného postupu. Zaznamenat rozhodnutí i důvod.

Výstup: sdílený stav incidentu, dočasné řešení a navazující plán nápravy.

Malý test před rozšířením

Ověřit změnu v reálných podmínkách

IHI pracuje s cyklem PDSA: změnu naplánovat, vyzkoušet, vyhodnotit a upravit. Malé testy se postupně rozšiřují a opakují v různých podmínkách. [7]

Praktický postup: předem napsat očekávaný přínos a způsob měření. Vyzkoušet změnu na omezeném rozsahu, který neohrozí službu. Vedle rychlosti sledovat chybovost, nároky na podporu a dopad na další tým.

Výstup: porovnání před a po, nežádoucí dopady a rozhodnutí rozšířit, upravit nebo zastavit.

Poučení bez obviňování

Z incidentu udělat konkrétní zlepšení

Autoři Google SRE popisují rozbory incidentů zaměřené na okolnosti a systémové podmínky. Hodnotu přináší sdílený záznam a provedená opatření, ne hledání člověka, který měl vše předvídat. [2]

Praktický postup: společně sestavit časovou osu, popsat dostupné informace a selhání kontrol. Ke každému opatření určit vlastníka, termín a důkaz účinnosti. Možnost otevřeně hlásit nejistotu spojit s jasnou odpovědností za další krok.

Výstup: krátký rozbor s ověřitelnými opatřeními a následnou kontrolou.

Aby změna vydržela

Předat řešení do běžného provozu

IHI rozlišuje zkoušení změny od jejího trvalého zavedení. Výsledek potřebuje podporu v každodenním fungování, jinak se původní postup může vrátit. [7]

Praktický postup: určit vlastníka procesu, aktualizovat návod a ověřit, že jej další člověk dokáže použít. Domluvit kontrolní termín a signál zhoršení. Zjistit od uživatelů, zda změna skutečně pomohla, nebo jen přesunula práci jinam.

Výstup: převzetí řešení, dostupný návod a měření udržitelného přínosu.

Publikované zkušenosti

Co ukazuje skutečná praxe

IT · zkušenost týmu Google

Automatizace potřebuje hranice

Google SRE popisuje incident, při němž prázdný seznam v automatizaci vedl k nečekaně širokému zásahu. Následná opatření při podobné pozdější události omezila rozsah dopadu. [2]

Poučení: ověřovat význam prázdného vstupu, bezpečnost opakování operace a omezení rozsahu zásahu.

Bankovnictví · případ TSB

Přenesená data nejsou funkční služba

Podle PRA se při migraci TSB v dubnu 2018 podařilo přenést data, nová platforma však následně trpěla technickými poruchami a klienti měli omezený přístup ke službám. [3]

Analytický závěr pro praxi: vedle správnosti dat ověřit celou klientskou cestu, závislosti na dodavatelích a připravenost obnovy.

Obecná praxe · přístup IHI

Nápad je začátek, zkouška přináší poznání

Model for Improvement propojuje jasný cíl, měření přínosu a malé opakované testy. Vznikl pro zlepšování procesů a IHI jej používá ve zdravotnictví. [7]

Možné využití v kancelářském procesu: nejprve ověřit novou podobu předání úkolu u malého počtu případů, sledovat vracení k doplnění a teprve potom postup rozšířit. Jde o modelovou aplikaci, nikoli popis konkrétního projektu.

Společný výchozí bod

Krátké zadání před výběrem řešení

Jedna společná stránka může udržet technický tým, odborného vlastníka a uživatele u stejného problému. Následující otázky jsou návrhem pracovní pomůcky.

Problém a dopad: Co se má stát, co se děje ve skutečnosti a koho to omezuje?
Důkazy a nejistota: Co je pozorované, co pouze předpokládáme a které informace chybí?
Varianty a kompromisy: Jaké jsou možnosti, jejich náklady, přínosy a rizika?
Zkouška a kritéria úspěchu: Jaký malý test varianty rozliší a podle čeho poznáme úspěch?
Rozhodnutí a odpovědnost: Kdo rozhodne, kdo provede změnu a kdy postup zastavíme nebo eskalujeme?
Následná kontrola: Kdy ověříme přínos, vedlejší dopady a předání do provozu?

Podklady a další čtení

Zdroje, ze kterých vycházím

Prostudováno 28. října 2026. Jde o publikované metody a zkušenosti, nikoli o tvrzení, že jsem uvedené projekty realizovala. Newsletter Basilejského výboru popisuje zkušenosti se zaváděním principů, nikoli nové dohledové požadavky.