Problémy, incidenty, helpdesk tikety

Uživatelské moduly

Řízení úkolů, projektů a kvality
Kontakty, adresáře
Správa a automatizace webu
Modul Personalistika
Produkty, aktiva, nákup a prodej
Správa financí
Metriky a měření

Technické moduly

Modul Sabre
Konektor mezi AyMINE a Enterprise Architect

Systémové moduly

Framework – systémový základ
Správa systému

Dejte nám kontakt, ozveme se

Chcete se rovnou zeptat?

Volejte na tel. +420 605 203 938

nebo využijte další kontakty

Problémy, incidenty, helpdesk tikety

Oblast řešení problémů je široká a proto se k ná váže i mnoho pojmů.

Hlavní kapitolu o řešení problémů

Incident, neshoda – pohled kvalitáře

Pro oddělení kvality je incidentem resp. neshodou situace, kdy nebyly dodrženy závazné postupy a to i v případě, že reálně nevznikl problém v podobě nekvalitního výrobku.

Odchylka od postupů vytváří riziko, že výrobek, i když působní bezvadně, bezvadný být nemusí. Proto je třeba i zdánlivě "neškodný" incident zaznamenat a jeho dopady i příčiny řešit. Přesně k tomu záznam problému slouží. S incidentem se budou vázat:

  • Zařízení nebo postup, kterého se incident týká
  • Úkoly ověření dopadů incidentu
  • Úkoly pro odstranění následků
  • Úkoly pro preventivní opatření.

Tiket – pohled helpdesku

Problém je obecným označením pro jakýkoli typ incidentu z hlediska kvality nebo plnění procesů. Věcně je i záznamem problémů nahlášeného uživateli – interními i zákazníky. Evidence problémů je tak současně i evidenci hlášených závad, požadavků a stížností od zákazníků, které jsou často označovány jako helpdesk tikety.

S helpdesk tiketem se typicky budou vázat

  • Email nebo jiná forma zprávy, kterou hlášení o problému dorazilo
  • Objednávka nebo zařízení, ke kterému tiket vznikl
  • Úkol / interní objednávka, kterou bude problém odstraněn – např. zaslání vadného zboží
  • Úkol řešící příčinu problému – např. požadavek na refundaci nákladů dodavateli (dovozci)

Problém vs. úkol

Problémy nejsou úkoly a systém oba objekty důsledně rozlišuje, i když na první pohled mohou vypadat podobně. Problémy v systému mohou být sledovány a řešeny bez toho, aby pro jejich vyřešení vznikl úkol, ale pokud se ukáže, že je úkol potřeba, může být pro problém založen (dokonce i více než jeden). Založit pro řešení problému samostatný úkol může být užitečné zejména, pokud je třeba pro řešení vytvořit skupinu (např. KANBAN pracovní tým), která na řešení spolupracuje. (Úkol je možné např. zařadit lidem do kalendáře a naplánovat na něj kapacity.) Úkoly mají navíc odhadovanou náročnost, takže vstupují do plánování kapacit.

Potřeba založit úkol záleží na způsobu, jak váš tým pracuje. Pokud si např. kolega synchronizuje úkoly do mobilu, tak vytvořením úkolu se mu bude synchronizovat a problému si všimne, i když se přímo na svůj pracovní stůl v systému nepodívá.

Přímo u problému je možné vykázat práci vynaloženou na jeho řešení. Není důvod vytvářet speciální úkol k řešení jenom kvůli výkazu práce.

Může vás zajímat