AyMINE – Technická dok. (anglicky)
Obchodní procesy
Nabídky a zákaznické objednávky
Správa ceníků
Zákaznická podpora
Řízení projektů
Plánování a řízení projektu
Řízení požadavků a testy
Komunikace a sdílení informací
Vnitrofiremní procesy
Kvalita a spolehlivost
Systém řízení kvality
- Stanovení odpovědnosti za úkol v metodice
- Metodika v systému řízení kvality
- 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ů
- Součástí systému řízení kvality
- Zahajující události
- Aktivace události z úkolu
- Vzorové riziko
- tskdefusertask_raisingevents
Projektová metodika
Metriky a hodnocení
Správa majetku
- Produkty, aktiva, nákup a prodej
- Analytický model
- 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
- Bezpečnost modulu personalistiky
- Modul Personalistika
- Personalistika – uživatelská oprávnění
- Evidence uchazečů o práci
- Správa údajů o oddělní / divizi
- Změna vedoucího oddělení
- Pracovní pozice
- Pracovník
- Přehled vlastních pracovníků
- Odpovědný personalista
- Synchronizace pracovníků a uživatelů systému
- Pracovní smlouva
- chartsstaffer
- Modul personalistika | Systémové role
- Kvalifikace, schopnost / dovednost
- GDPR a evidence kvalifikací
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele, pracovníka nebo kontaktu
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele nebo kontaktu
- Evidence úrovní zkušenosí
Technická podpora – helpdesk
CRM & Správa kontaktů
- Adresář obchodních kontakt
- Kontakt v adresáři
- AyMINE modul CRM - uživatelská dokumentace
- Přehled zákaznických objednávek
- Seznam a správa adresářů
- Ochrana osobních a obchodních údajů
- Šablona zprávy
- Skupiny kontaktů
- Přehled objednávek pro zákaznické skupiny
- Kontakt na osobu nebo firmu
- Rychle dostupné kontakty
- Statistiky e-mailů
Správa Web portálů (CMS)
- Správa a automatizace webu
- Blok webové stránky
- Bloky na webové stránce
- Skript generující stránku
- Příjem zprávy z webu
- Odpovídací formulář – nastavení
- Popis webové stránky
- Web se speciálními potřebami
- Web portál
- CMS pro velký web
- Nastavení základních web služeb
- Uložit přístup k webové stránce
- Konektor pro webové služby
Systémové moduly
Úvod do AyMINE
- Rozšíření objektů
- introhelp_generalinfo
- introhelp_settings
- Zásady uchovávání hesel
- introhelp_shortcuts
- Systémová oprávnění
- introhelp_settings_dnadrhal9000_mar-22-220236-2023_caseconfl
- Moduly AyMINE
- Úvod do systému AyMINE
- Uživatelské zámky
- introhelp_privateobjectnotes
- introhelp_keyshortcuts
- Framework – systémový základ pro SaaS
Správa systému
Přizpůsobení potřebám firmy
Multitenant administrace
Rozhraní na jiné systémy
Konektor 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í.