AyMINE – Technická dok. (anglicky)
Obchodní procesy
Správa ceníků
Řízení projektů
Komunikace a sdílení informací
Komunikace, porady, rozhodování
Vnitrofiremní procesy
Systém řízení ISM - Integrovaný systém managementu staví pevné základy kvalitnímu vnitřnímu fungování firem
Metodické rámce
Formalizace systému řízení do metodických rámců zakotví systém řízení v popsanýcj pravidlech- Systémy řízení podporující různé standardy
- Dokumentace, která tvoří součást systému řízení
- Odpovědnosti za úrovně systému řízení
- Povinnosti formují metodické rámce
- Politiky a směrnice
- Terminologie a názvosloví
- Vzorový úkol – Pracovní postup
- Objekty vztahující se ke vzorovému úkolu
- RACI matice
- Stanovení odpovědnosti za úkol v metodice
- Řízení posloupnosti úkolů
- Zahajující události
- Aktivace události z úkolu
- Vzor protokolu / záznamu
- Klíčové slova pro automatizaci dokumentů a šablon
- Vzorové riziko
- Řízení zlepšení a preventivních opatření
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
- AyMINE | Správa kritérií kvality
- K čemu jsou kritéria kvality
- Správa fyzických i virtuálních prostor
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
- Osobní 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
- 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ů
- Uživatelská dokumentace k modulu CRM
- Správa a ochrana adresářů ve firmě
- Seznam a správa adresářů
- Správa kontaktů podporuje bezpečnost i sdílení dat
- Skupina kontaktů v adresáři
- Přehled zákaznických objednávek
- Skupiny kontaktů pomáhají členění adresáře a obchodu
- Ochrana osobních a obchodních údajů
- Generování automatických zpráv ze CRM i s pomocí AI
- Přehled informací o přijatých a odeslných zprávách
- Hromadná komunikace s členy, klienty a akcionářit
- Odkaz v hromadné zprávě pro nastavení preferencí
- GDPR: Zapomenutí subjektu
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
Změnové řízení v projektu
Cílem změnového řízení je řádně dokumentovat projektovou změnu. Dokumentace slouží jako podklad pro zdůvodnění důsledků změny, typicky změny termínu dokončení, ceny a rozsahu plnění.
Objekt Projektová změna podporuje evidenci a analýzu změnového řízení v souladu s projektovými standardy. Je součástí evidence projektu v projektové kanceláři. Na pracovním stole jsou změny ve společné přihrádce s podprojekty.
Kdy je potřeba změnové řízení
Změny jsou několika základních typů
Interní změna
Jde o změnu v projektovém plánu, která nemá vliv na zákazníka. Změna typicky nepodléhá schválení řídícím výborem projektu, zákazníkem, nebo jiným podobným orgánem. Příkladem změny může být přerozdělení kompetencí v rámci týmu.
Změna vyvolaná zákazníkem
Změna zahrnuje změny s vlivem na (harmonogram), rozsah prací, pracovní postupy, nebo jakoukoli jinou oblast smluvních závazků vůči zákazníkovi. Klíčovou charakteristikou této změny je, že úvodním podnětem byla buď žádost / pokyn, aby se v projektu zohlednilo rozhodnutí o nějaké změně, nebo vliv vnějších okolností, které si změnu vynucují, a jde o okolnosti v kompetenci zákazníka.
Příklady změn jsou:
- Nové požadavky na projektovou dodávku
- Oznámení o změně dohodnutého termínu důležitého projektového vstupu (např. schváleného zadání a rozpočtu)
- Změna podmínek stavby, kde za podmínky nese odpovědnost zákazník / investor (např. archeologické nálezy ve výkopu)
Změna způsobená problémem
Pokud při řešení projektu nastane problém, který brání dodržení temínů a závazků, je třeba vytvořit změnové řízení způsobené problémem. V principu toto změnové řízení je založeno bez ohledu na to, čí je odpovědnost za problém a kdo bude v případném sporu odpovědný za náklady z problémy vyplývající.
Upozornění: Nepleťte si zaznamenání problému a změny. Problém, na základě kterého změna vznikne, musí být evidován mezi problémy řešenými v projektu. Na jeho základě je následně založena projektová změna.
Nová etapa projektu
V rámci projektu může být dohodou účastníků rozhodnuto, že projekt zvětší svůj rozsah a budou realizovány nové činnosti, které v aktuálním plánu nebyly zahrnuty. Toto rozhodnutí fakticky vede také ke změně, a musí být jako změna zpracováno. Je zaznamenáno jako nová etapa.
Zpracování změny
Jednotlivé oddíly popisují klíčové kroky změny. Metodika může pro jednotlivé kroky připravit samostatné úkoly propojené vazbami. Řízení změny je tak možné spustit přímo příkazem Nový úkol v detailu změny. Tlačítko nabídne úkoly pro realizaci změny.
Identifikace a popis změny
V prvním kroku je třeba popsat, co se skutečně mění. Typicky to budou nové či změněné požadavky na dílo, časový plán, nebo rozpočet. Všechny měněné objekty (ve verzi platné před zahájením změnového řízení) jsou v AyMINE uloženy a do změny zařazeny mezi objekty, které změna ovlivní. Objekty – typicky vstup od zákazníka – mohou být popsány samostatnými informacemi a ke změně připojeny tlačítkem Důvody.
Samotný změna může být podrobně rozebrána na záložce Popis změny.
Analýza změny
Cílem analýzy je najít všechny dopady, které změna v projektu způsobí. Analýza spočívá v nalezení a dokumentování všech důsledků změny. Typicky důsledky jsou:
- Potřeba předělat něco, co už je uděláno
- Potřeba vyvinout novou verzi
- Změnit už vytvořené výstupy – analýzy, design, testy
V závislosti na rozsahu změn je třeba - Upravit harmonogram
- Upravit projektová rizika
Všechny objekty, které budou změnou ovlivněny, jsou ke změně připojeny tlačítkem Přidat v oddílu Objekty související se změnou. Ke každému připojenému objektu by měl být v rámci analýzy doplněn popis, jakým způsobem bude ovlivněn. (Tlačítkem Do záznamu).
Schválení změny
Změna připravuje podklady a dokumentuje analýzu. Samotné rozhodnutí bude provedeno jako rozhodnutí typicky na poradě.
Ke změně se bude vázat rozhodnutí, které by mělo být zařazeno na jednání porady. Výsledek rozhodnutí se dokumentuje jednak přímo v rozhodnutí, jednak změnou stavu u samotné změny.
Průběh změnového řízení
Po schválení změny je třeba změnu realizovat. K jednotlivým objektům, které jsou ve změně identifikovány, jsou vytvořeny úkoly pro změnu, nebo – pokud jsou změny malé – mohou být realizovány v rámci kroků a úkolů přímo u změny. Konkrétní řešení záleží na použité metodice.
Odpovědnosti za změnu
Se změnou v projektu se váže řada odpovědností:
- Za správné procesní zpracování změny vždy odpovídá vedoucí projektu. Vedoucí projektu také změnu do projektové kanceláře vkládá.
- Analýzou změny může vedoucí projektu pověřit kohokoli z projektového týmu. Správně by měl pověřit toho, kdo dopadům změny nejlépe rozumí. Může také v rámci úkolu na analýzu změny vytvořit celý řešitelský tým
- Odpovědnost za rozhodnutí o tom, zda bude změna realizována, je dána smlouvou, metodou projektového řízení nebo jiným způsobem. Typicky to je řídící výbor, nebo je nutný souhlas zákazníka.
- Naplánování projektu se zohledněním změny musí vždy dělat vedoucí projektu, protože odpovídá za dodržování harmonogramu (a nikdy jiný ani projekt plánovat nemůže).
- Realizaci změny – tj. vykonání všech dopadů – vede vedoucí projektu stejně, jako jakékoli jiné projektové činnosti.