Ří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.

• Životní cyklus problému
  • Zaznamenání problému
  • Stavy řešení problému
  • Dokumentace problému
• Správný popis problému
• Dokumentace řešení
• Může vás zajímat

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.

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.

Může vás zajímat

• Problémy, incidenty, helpdesk tikety – terminologie
• Sdružování problémů a jejich společné řešení
• Předmět problému aneb propojení mezi problém a tím, čeho se týká