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
Povinnost
Povinnost popisuje vnější pokyn či nařízení, které stanovuje, co má či nemá společnost resp. projekt dělat a dodržovat.
Povinnosti mají vztah buď k metodice, resp. systému řízení kvality nebo k projektu.
projektu
Povinnosti vV rámci projektu povinnosti představují vnější nařízení či závazky, které musí být v projektu dodrženy
Příklady povinností v projektu
V projektu jsou povinnostmi např.:
- Dodržovat externí standard řízení projektu, např. PMBOK, nebo systém řízení bezpečnosti, např. ISO 26262.
- Dodržet stanovený rozpočet projektu
- Dokumentovat průběh celého projektu pomocí workflow systému
projektové požadavky
Povinnosti v projektu nejsouV rámci projektu jsou dokumentovány povinnosti i požadavky. Z projektového hlediska je ale mezi nimi zásadní rozdíl:
- Požadavek je vstupem, který je analyzován, implementován a ovlivňuje, jak vypadá výstup projektu. Požadavek je standardně i předmětem diskuze, může být prioritizován nebo i zamítnut.
- Povinnost v projektu stanovuje tzv. "obligatorní podmínku", kterou musí dodržovat průběh projektu i jeho výstup. Povinnosti nejsou předmětem schvalování v projektu, ale definují, jak se v projektu pracuje.
Zjednodušeně řečeno, povinnosti nemůže projekt ovlivnit, zatímco požadavky (do jisté míry) ano.
metodiky / systému řízení kvality
Povinnosti jakožto součástPovinnosti v pravém slova smyslu nejsou součástí interního systému jakosti. Interní systém by měl být tvořen politikami a směrnicemi, které povinnosti převádí do vnitřní praxe.
Typickými příklady povinností jsou:
- Zákony – např. GDPR, Zákoník práce
- Normy – např. ISO 26262, ISO 27000
- Zákonné předpisy – např. Předpis o vedení účetnictví
- Oborové standardy
- Společenská smlouva s odbory
- Zakladatelské listiny společnosti
- Rozhodnutí valné hromady
- Rozhodnutí vlastníka – typicky korporátní standardy
Společnými znaky povinností je, že:
- Jsou dané z vnějšku
- Interně je společnost akceptuje, ale přímo je neovlivňuje
- Jejich nařízeními by se měly řídit všechny interní směrnice, pravidla a postupy.
AyMINE povinnosti, které definují metodiku, eviduje jako součást dokumentace metodiky; přičemž systém jakosti je nejběžnějším případem i příkladem metodiky. Hlavním užitkem popisu povinností v rámci metodiky je:
- Jasně definovat, jaký externí důvod nařizuje konkrétní postup nebo výstup
- Usnadnit správu a kontrolu správnosti metodiky
Povinnosti pro více metodik
V AyMINE můžete mít více metodik a může nastat situace, kdy stejná povinnost je zohledněna ve více metodikách. Nikdy se nevkládejte do systému povinnost opakovaně, AyMINE umožňuje lepší řešení. V zásadě jsou řešení dvě – buď samostatná metodika, nebo zařazení do některé existující.
Vytvořit si samostatnou metodiku jenom na povinnosti
Pokud je povinností sdílených mezi metodikami více, je nejvhodnějším řešením jejich vyčlenění z metodiky do samostatné oblasti – metodiky s povinnostmi.
Povinnosti se nebudou zobrazovat na pracovní ploše metodik, ale dále je možné vytvářet vazby mezi směrnicemi a povinnosti. Tím, že se v metodice nebudou zobrazovat žádné povinnosti, bude na první pohled patrné, že jsou jinde.
Zařadit povinnost do metodiky, která se řešením nejvíce zabývá
Pokud se řeší situace, kdy povinnost je v zásadě promítnuta jednou metodikou, ale někde ji zohledňuje např. směrnice z jiné metodiky, může být povinnost dále uvedena v rámci metodiky, která se jí primárně zabývá.
Směrnice mohou být navázány na povinnosti z jakékoli metodiky, není proto problém, aby byly využity i povinnosti z jiných metodik. Součásti metodiky pochopitelně nemohou být propojeny s povinnostmi z konkrétních projektů.