AyMINE – Technická dok. (anglicky)
Uživatelské moduly
Řízení úkolů, projektů a kvality
Tlačítka pro aktivaci události
Grafy pro dokumentaci problémů a tiketů
Kvalifikace, schopnost / dovednost
Kvalifikace uživatele, pracovníka nebo kontaktu
Právo spravovat kvalifikace uživatelů
Úrovně kompetencí a kvalifikací
Metodika a systém řízení kvality
Co tvoří metodiku / SMJ objectsSVG
Adminitrace oblastí, projektů, kalendářů
Správa jedinečných identifikátorů
Šablony pro jedinečné identifikátory
Problémy, tickety a jejich řízení
Generování odpovědi zákaznického centra
Objekty, kterých se problém týká
Problémy, incidenty, helpdesk tikety
Řízení incidentů, neshod v kvalitě
Grafy pro dokumentaci vývoje zpracování úkolů a problémů
Tým projektu nebo tým k pracovnímu postupu
Vrátit plán projektu podle baseline
Vzorové úkoly a metodiky oblasti
Vzorový úkol – Pracovní postup
Objekty vztahující se ke vzorovému úkolu
Proč nejdou některé údaje smazat
Souhlas vedoucího s výkazem práce
Vliv úkolu na právo měnit připojené objekty
Kontakty, adresáře
Ochrana osobních a obchodních údajů
Přehled objednávek pro zákaznické skupiny
Správa a automatizace webu
Nastavení základních web služeb
Uložit přístup k webové stránce
Odpovídací formulář – nastavení
Uživatelská dokumentace AyMINE
Modul Personalistika
Bezpečnost modulu personalistiky
Synchronizace pracovníků a uživatelů systému
Správa údajů o oddělní / divizi
Produkty, aktiva, nákup a prodej
O kritériích kvality u produktů
Přepočítat nabídku a objednávku
Přístupová práva k nabídkám a cenám
Přijatá objednávka na zboží nebo služby
Vlastnost produktu nebo výrobku
Správa financí
Metriky a měření
Souhrny práce z generovaných dat
Technické moduly
Modul Sabre
Konektor mezi AyMINE a Enterprise Architect
Databázový link do databáze Enterprise Architect
Systémové moduly
Framework – systémový základ
Nastavte si, jak váš systém vypadá a funguje
Soukromé poznámky a značky k záznamům
Správa systému
Zabezpečení příspěvků a interních diskuzí
Kopírování a přesouvání souborů mezi objekty
Nastavení brán pro externí zprávy
Nastavení IMAP brány pro emailovou komunikaci
Nastavení brány pro internetové volání
Skupiny, týmy a pracovní pozice (role)
Vožení podřazené skupiny / role
Propojení uživatelů s VOIP ústřednou
Automatické potvrzení příchozí zprávy
Pravidla pro automatickou odpověď
Pravidla pro odesílanou zprávu
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.