AyMINE – Technická dok. (anglicky)
Obchodní procesy
Správa ceníků
Řízení projektů
Komunikace a sdílení informací
Vnitrofiremní procesy
Kvalita a spolehlivost
Systém řízení kvality
- Stanovení odpovědnosti za úkol v metodice
- Automatizace a metodika systému řízení kvality - SMJ / QMS
- Směrnice a politiky
- Přehled povinností stanovených metodikami nebo předpisy
- Pojmy
- Vzor protokolu / záznamu
- Vzorový úkol – Pracovní postup
- Objekty vztahující se ke vzorovému úkolu
- Řízení posloupnosti úkolů
- Co tvoří systém řízení kvality - SMJ
- Zahajující události
- Aktivace události z úkolu
- Vzorové riziko
- Business událost
FMEA & HARA
Správa majetku
- Produkty, aktiva, nákup a prodej
- Sdílený analytický model urychluje a usnadňuje spolupráci
- Dodavatel produktu
- Kategorie produktů
- Vlastnost produktu nebo výrobku
- Cíl projektu
- Přehledy nabídek
- Přepočítat nabídku a objednávku
- Přehledy objednávek
- Produkty a zboží
- Stav produktu a jeho změna
- Původ produktu
- Kritéria kvality
- O kritériích kvality u produktů
- Lokalita
Personalistika
- Modul personalistiky, HR v ekosystému AyMINE
- Správa personálních digitální dokumentů v souladu s GDPH
- Modul Personalistika - uživatelská oprávnění
- Evidence a správa pracovníků
- Role a odpovědnosti pověřeného personalisty
- Osovbní pracovní přehled pracovníka
- Přehled vlastních pracovníků
- Synchronizace pracovníků a uživatelů systému
- Evidence pracovních smluv a dohod
- Evidence uchazečů o práci
- Přehledy výkonnosti pracovníků
- Změna vedoucího oddělení
- Právo spravovat kvalifikace uživatelů
- Pracovní pozice a pracovní role v personalistice
- Kvalifikace, schopnost / dovednost
- Evidence úrovní zkušeností pro pracovníky
- Kvalifikace uživatele, pracovníka nebo kontaktu
- GDPR a evidence kvalifikací
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele nebo kontaktu
- Správa údajů o oddělní / divizi
- Bezpečnost modulu personalistiky
Technická podpora – helpdesk
CRM & Správa kontaktů
- Adresář obchodních kontakt
- Kontakt v adresáři vám umožní přístup ke všem informacím
- Uživatelská dokumentace k modulu CRM
- Přehled zákaznických objednávek
- Seznam a správa adresářů
- Ochrana osobních a obchodních údajů
- Šablona zprávy
- Skupiny kontaktů pomáhají členění adresáře a obchodu
- Kontakt na osobu nebo firmu
- Rychle dostupné kontakty
- Přehled informací o přijatých a odeslných zprávách
Systémové moduly
Správa systému
Multitenant administrace
Rozhraní na jiné systémy
Konfigurace web služeb
Nastavení web konektorů a služeb pro komunikace s web portály a externími systémyKonektor na ERP Abra Gen
Sabre: webDav, calDav
Konektor na Enterprise Architect
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í.