Uživatelské moduly

Problémy nikdo nechce, jsou ale neoddělitelnou součástí každého většího díla. Systémy řízení kvality jim proto věnují velkou pozornost, protože jejich řešení je klíčovým krokem nejenom v jejich odstranění, ale v celkovém zlepšování.

Kontrola a řešení problémů jsou součástí jak projektového řízení, tak běžného řízení procesní oblasti firmy. Samozřejmě je i součástí celkového řízení systému kvality.

Problémem označujeme širší skupinu událostí, které mají často v terminologii firmy samostatné pojmenování. Jednotlivé typy je možné odlišit pomocí číselníku definovaného v souladu s firemní metodikou:

Neshoda – Odchylka od standardu, typicky zjištěná interním auditem. Neshoda nemusí vyústit v závadu
Problém – Nejasnost ohledně řešení např. při vývoji, ale i např. i problém ve výrobě (vyskytující se závady)
Závada – Špatný výstup, který nesplňuje některý ze vstupních požadavků.
Podnět – Návrh, připomínka nebo upozornění od kohokoli z řešitelského týmu. Při další analýze se většinou zjistí, jak jej podrobněji klasifikovat – např. jako problém, ale např. také návrh na zlepšení.

Životní cyklus problému

Každý problém by měl být zaznamenán co nejdřív, když se objeví. Samozřejmě pouze v případě, že není ihned vyřešen (pak to pravděpodobně není problém)

Když je problém zaznamenán, zůstává „aktivní“, tedy vyřešený až do ukončení. Problém má v podstatě stejný životní cyklus, jako úkol neb o požadavek. Předpokládá se, že se odstranění problému někdo ujme, do té doby může zůstat jako otevřený bez řešitele.

Zaznamenání problému

Většina procesních metodik vyžaduje, aby byly zaznamenány všechny, nebo většina dále uvedených údajů. Ověřte si případně vlastní metodiku vaší organizace, co přesně vyžaduje.

Vznik problému

Dokumentace při založení záznamu o problému by měla zahrnovat:

Popis, jak se problém projevuje
Identifikace, kdo a kdy jej nahlásil (nemusí být nutně ten, kdo jej zaznamenal)
Kdy se začal projevovat, vznikl, nebo se na něj poprvé přišlo
Kdo dostává problém na starost

Řešení problému

V rámci další analýzy by měly vznikat záznamy:

Příčina problému – Její zjištění může vyžadovat podrobnější analýzu, např. „Root-Cause“, „Fishbone“, 8D report aj. Tyto analýzy by měly být zahrnuty v dokumentaci problému, protože jsou důležitou dokumentací postupu. Příčina je dokumentována na vlastní záložce v detailu.
Postup řešení – Jaké události a zjištění byly při řešení problému provedeny:
- Události: Dokumentovány formou události (záložka aktivity)
- Zjištění: Zaznamenány do postupu řešení (pod samotný popis problému). Pokud jde o domněnky, věci k diskuzi nebo návrhy, doporučujeme dokumentovat do diskuze u problému. Poznámka: diskuze je archivována stejně jako samotný objekt a je proto dokumentaci řešení, kterou je možné revidovat i následně auditovat.

Stavy řešení problému

Nový – po založení, probléme se dosud nikdo nevěnuje
Volný k řešení – Problém "správce" označil jako čekající na někoho, kdo se ho ujme
V řešení – Problém má někdo na starost
Vyřešen – Problém byl vyřešen a čeká na potvrzení správcem. Pokud problém přímo vyřeší správce, problém se do tohoto stavu vůbec nedostane
Dokončen – Problém byl kompletně vyřešen. Do stavu se dostane buď jeho vyřešením správcem, nebo potvrzením, že je problém vyřešen (správcem, když jej vyřešil někdo jiný)
Vyřazen – Problém přestalo mít smysl řešit. Do tohoto stavu jej řešitel může převést ručně příkazem. Problém je vyřazen např. v případě, že se týkal zakázky, která byla zrušena.

Dokumentace problému

Problémy mohou zůstat otevřené obecně jakkoli dlouhou. Systém nemá nástroj, jak vyhodnotit naléhavost problému a proto jeho řešení obecně neurguje. U problému by ale mělo být uvedeno, do kdy má být odstraněn a problémy, které toto datum překročí, jsou na pracovní ploše zvýrazněny.

Dokumentace problému má ale i další přínosy:

Zvýšení zastupitelnosti členů týmu, kteří si tak snadněji předají agendu, jež je třeba řešit
Předávání zkušenosti i do jiných a pozdějších projektů, které mohou získat zkušenost, na co si dát pozor a s čím počítat, že může nastat
Při kvalitní dokumentaci řešení problému je možné získat do jiných projektů nebo činností obecně i zkušenost, jak se s problémem vypořádat.
Splnění požadavků metodik, jako jsou PMBOK, ISO 9001, ASPICE, ISO 26262 a řady dalších, které dokumentaci problémů vnímají jako zásadní nástroj pro to, aby se problémy netratily a nezůstaly nevyřešeny.

Správný popis problému

Aby mohl být úkol řešen, musí být od začátku zdokumentován. Zejména pokud má problém řešit někdo jiný, než kdo problém zjistit a zapsal, nebo pokud je známo, že řešení se odkládá a nebude bezprostřední. Obsah popisu problémy většinou definují i metodiky kvality práce i interní systém jakosti. Metodiky se shodují na tom, že popis by měl obsahovat minimálně:

Přesnou identifikaci prostředí, ve kterém problém vznikl (např. zda jde o problém na interním zařízení, nebo u zákazníka a u kterého)
Za jakých okolností problém nastal
Co problém způsobil nebo způsobit může
Jak závažné má dopady
Jakými kroky se k němu dospělo (zejména pokud je možné jej stejnými kroky opět navodit)
Jaké by mělo být správné chování

Dále je vhodné uvést (pokud je známo a relevantní):

Odkaz na dokumentaci popisující správný stav (např. manuál špatně fungujícího přístroje)
Protokoly nebo jiné záznamy z chybného chování

Pro řadu problémů nemají samozřejmě některé výše uvedené hodnoty význam, nebo jej mají jenom v přeneseném smyslu (vzorovým příkladem pro dokumentaci problému je občas chybně se chovající zařízení. V takovém případě má dokumentace plnohodnotně smysl. V jiném příkladu – nedostatečná znalost u člena projektového týmu, bude pochopitelně většina bodu popisu nepoužitelných. Oba příklady jsou přitom problémem, který by měl být při vzniku zaznamenán.)

Dokumentace řešení

U problému by mělo být uvedeno, jak byl vyřešen. Popis je uveden do stejného popisu, jako popis podrobností o problému, protože v průběhu řešení, se často okolnosti upřesňují, a pracuje se s obojím společně.

Zejména při řešení složitějších problémů je běžné, že se problém dělí na dílčí problémy, nebo se další dílčí problémy projeví. Je proto možné k problému uvést dílčí podproblémy, nebo problém logickou vazbou spojit s jiným.

Uživatelské moduly

Technické moduly

Systémové moduly

Dejte nám kontakt, ozveme se

Chcete se rovnou zeptat?

Řízení incidentů, neshod v kvalitě

Smyslem řízení problémů je zajistit, aby byl každý problém vyhodnocen a úplně vyřešen. Řešení problémů zahrnuje agendu oddělení kvality i helpdesk pro zákazníky a uživatele.