AyMINE – Technická dok. (anglicky)
Moduly
Řízení úkolů, projektů a kvality
Řízení úkolů, projektů a kvality
Administrace modulu Řízení úkolů
Systémová práva modulu správy úkolů
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
Tlačítka pro aktivaci události
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, smlouvy
Systémová práva a nastavení modulu CRM
Ochrana osobních a obchodních údajů
Posílejte hromadné zprávy v souladu s GDPR
Jak korektně zapomenout údaje o osobě
Odhlášení a nastavení preferencí
pro hromadnou poštu
Odhlášení a nastavení preferencí
pro hromadnou poštu
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
Personalistika – uživatelská oprávnění
Synchronizace pracovníků a uživatelů systému
Správa údajů o oddělní / divizi
Produkty, aktiva, nákup a prodej
Produkty, aktiva, nákup a prodej
Správa modulu Majetek & Obchod
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
Konektor mezi AyMINE a 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
Plán
Plán obsahuje informace popisující, jak se vykonává určitá část činností
Příklady plánů
- Plán interních auditů – nezbytná součást systému řízení jakosti podle ISO 9001 plánuje interní audity v průběhu roku.
- Plán projektu – podle nekěteré z projektových metodik nebo standardů, např. PMBOK ISO 26262
- Plán řízení rizik – týká se jak projektu (tak či onak jej vyžadují všechny projektové metodiky s PMBOK v čele), tak i organizace, kde by se řízení rizik mělo týkat jednotlivých oblastí; více se tomu věnuje kapitola o rizicích
Co plán obsahuje
Plán je popisem konkrétní realizace činností, které se mají provádět. Může vznikat ad hoc nebo na základě metodiky. Metodickou předlohou je definice plánu.
Podrobnost plánu velmi závisí na tom, kolik je o činnostech definováno jinde. Více si ukážeme na příkladu projektového plánu
Plán projektu
Plán bez metodiky
Pokud není k dispozici metodika, musí projektový plán obsahovat:
- Definici rolí a celého projektového týmu
- Pro každou roli popis, co je pracovní náplní dané roli, jaké jsou její kompetence a odpovědnosti
- Popis, jak se bude v projektu nakládat se vším, s čím se pracuje. Typicky jde o informace (včetně záznamů a dokumentů), ale aktiva pořízená a vyrobená, tedy věci hmotné i nehmotné povahy. Nakládání bude zahrnovat
- Kdo je má na starost
- Jak vznikají
- Jak jsou identifikována
- Kde se ukládají
- Jak jsou oceňována (zahrnuje, kolik se za ně bude např. účtovat zákazníkovi)
- Rizika projektu a jak s nimi pracovat
- Všechny projektové vazby na jiné projekty, účastníky
- Projektové limity, relevantní legislativu
Plán projektu někdy zahrnuje i přehled činností, které budou vykonávány. jindy je přehled samostatně v harmonogramu.
Projektový plán spojený s metodikou
Pokud je plán projektu odvozený z projektové metodiky (typicky z metodiky postavené na obecné metodice, např. PMBOK, SPICE, CMMI apod.), je většina výše uvedeného obsahu definována přímo projektovou metodikou a v ní popsaném vzorovém projektu.
- Role jsou definovány v rámci vzorových projektových rolí
- Projektová rizika jsou odvozena ze vzorových rizik
- Harmonogram vyplývá z předepsaných projektových činností
- Umístění souborů a jejich značení je dáno metodikou a standardními vzory pro jedinečnou identifikaci záznamů
- Vazby na legislativu, normy a jiné externě definované povinnosti popisují v rámci metodiky povinnosti.
Jak vzniká plán
Plán vzniká na začátku rep. před začátkem plánované činnosti:
- Plán projektu se chystá před zahájením projektu spolu s dalšími plány, které se k projektu vztahují – plán zajištění bezpečnosti, plán rizik, komunikace, dodávek apod. (vždy v závislosti na metodice.)
- Plány vyplývající ze SMJ typicky vznikají začátkem roku pro daný rok. Není ale výjimkou, když např. plán interních auditů je tříletý, tedy schvalovaný jednou za 3 roky, a pro každý rok vzniká harmonogram auditů pro daný rok, který naplňuje zadání stanovené plánem.
V každém případě je plán dokumentem, který se vztahuje k projektu nebo oblasti. Měl by vzniknout jako koncept, který je schvalován. Pokud vzniká na základě metodiky, bude metodika obsahovat pracovní postup ve formě vzorového úkolu, který podrobněji popíše, co je třeba v rámci přípravy plánu provést. Podrobnosti mohou být i přímo u vzorového plánu.
Plán není harmonogram
Nadpis oddílku je mírně provokativní, protože součástí plánu samozřejmě typicky je i rozpis úkolů. Provokativnost ale byla záměrná, protože často se mezi oba pojmy klade rovnítko a plánem se pak rozumí jenom soupis toho, kdo co kdy udělá.
V rámci plánování je samozřejmě nutné i říct, kdo co kdy udělá, ale jak jsme si popsali výše, není to to jediné a je docela dost důvodů, proč harmonogram od plánu oddělit.
Rozpis úkolů není v dokumentu
Jak bylo uvedeno, rozpis úkolů je spíše součástí harmonogramu, než přímo plánu. Hlavním důvodem pro rozdělení harmonogramu a plánu je velmi odlišný životní cyklus obou typů informací.
Příklad – změna harmonogramu projektu
- Plán projektu je typicky schvalován na začátku projektu a po celou dobu neměnný
-
Harmonogram projektu
- Vzniká často až po schválení projektu, řada informací z plánu projektu na něj má vliv a je proto nutné plán v harmonogramu zohlednit
- V rámci změnového řízení se aktualizuje harmonogram, ale ne plán projektu
- Na schválení plánu se podílí více lidí – např. manažer kvality, vedení projektové kanceláře, zástupci klienta. Změnu harmonogramu projektu schvaluje řídící komise projektu, kde jsou zástupci zákazníka (u interních projektů interní zákazník) i dodavatele (realizační tým), ale nejsou tam všichni, kdo se vyjadřovali k plánu projektu.
Z rozdílů je patrné, že pro větší projekty je vhodné harmonogram a plán rozdělit.
Jiné plány a harmonogramy jsou podobné
Situace v případě jiných plánů je podobná. Např. změnu harmonogramu interních auditů podle ISO 9001 může většinou provést vedoucí oddělení kvality bez schvalování vedením společnosti, ale plán auditů musí být předmětem schválení ze strany vedení.