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
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.