AyMINE – Technická dok. (anglicky)
Personalistika
- Role modulu personalistiky
- Bezpečnost modulu personalistiky
- Modul Personalistika
- Pracovník
- Odpovědný personalista
- Správa údajů o oddělní / divizi
- Pracovní smlouva
- Pracovní pozice
- Změna vedoucího oddělení
- Synchronizace pracovníků a uživatelů systému
- Personalistika – uživatelská oprávnění
- Přehled práce pracovníků
- Evidence uchazečů o práci
- Přehled vlastních pracovníků
CMS - Webové portály
- Bloky na webové stránce
- Příjem zprávy z webu
- Web portál
- Nastavení základních web služeb
- Konektor pro webové služby
- Popis webové stránky
- Skript generující stránku
- Blok webové stránky
- Uložit přístup k webové stránce
- Správa a automatizace webu
- CMS pro velký web
- Web se speciálními potřebami
- Odpovídací formulář – nastavení
- Uživatelská dokumentace AyMINE
Řízení úkolů a projektů
- Evidence projektových požadavků
- Podpora řízení testů a kontrol při projektu nebo dodávce
- Business oblast
- Popis pracovního postupu zahrnuje i popis rolí, které postup vykonávají
- Evidence povinností umožňuje efektivní kontrolu a začlnění do pracovních postupů
- Přehled úkolů spolu s Kanban náhledem jsou základním pohledem na úkoly celého týmu
- Business událost
- Značky a jedinečné identifikátory
- Přehled oblastí – seznam
- Evidence rozhodnutí dává všem pracovníkům jistotu, jaká pravidla platí
- Varianta rozhodování
- Definice úkolu je základem metodik, ale i automatizace a efektivní firmy
- Úrovně kompetencí a kvalifikací
- Záznam o provedených činnostech a operacích
- Požadavky na projekt nebo řešení
- Sledování úkolů a jejich plnění
- Busines události aktivují zpracování podle scénáře
- Notifikující události
- Informace
- Souhlas vedoucího s výkazem práce
- Šablony pro jedinečné identifikátory
- Mé projekty
- Aktivace události z úkolu
- Klientské nastavení modulu
- Zpracovávané záznamy
- Definice projektu
- Požadavky čekající na vás
- Definice balíku
- Vliv úkolu na právo měnit připojené objekty
- Událost
- Oblast
- Riziko
- Záznamy zpracovávané v úkolu
- Výskyty událostí
- Potřebné schopnosti
- Změnové řízení v projektu
- Automatizace systému řízení kvality - SMJ / QMS
- Problémy, tickety a jejich řízení
- Projekt
- Událost
- Objekty vztahující se ke vzorovému úkolu
- Upozornění a vzkazy
- Vzorové riziko
- Tlačítka pro aktivaci události
- Řízení posloupnosti úkolů
- Zaznamenané činnosti
- Výkaz práce
- Časové návaznosti úkolů
- Záznamy spravované projektem
- Vzor protokolu / záznamu
- Co tvoří systém řízení kvality - SMJ
- Vzorové úkoly a metodiky oblasti
- Upozornění pro sebe
- Akce, události a porady
- Konfigurační balík
- Evidence porad a akcí
- Zpracovávané objekty
- Tým řešící úkol
- Přehled vlastních úkolů
- Osobní kalendář
- Předmět rozhodování
- Pojmy
- Vzor plánu / strategie
- Mé oblasti
- Porada
- Plánování úkolů
- Záznamy a protokoly
- Akce
- Tým úkolu a člen týmu
- Zahajující události
- Definice projektových rolí je důležitou součástí projektové metodiky
- Směrnice a politiky
- Řízení úkolů, projektů a kvality
- Kvalifikace, schopnost / dovednost
- Zahajující události
- Proč nejdou některé údaje smazat
- Objekty, o kterých se rozhoduje
- Tlačítka pro aktivaci události
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele nebo kontaktu
- Oblast / projekt / metodika
- Vzorové úkoly a metodiky oblasti
- Plán
- Tým projektu nebo tým k pracovnímu postupu
- Drag & Drop mezi záznamy
- Diskuze
- Lokalita
- Právo spravovat kvalifikace uživatelů
- Kvalifikace uživatele, pracovníka nebo kontaktu
- Kanban – přehled úkolů
- Harmonogram projektu
- Projektová baseline
- Vrátit plán projektu podle baseline
- Společné řešení více problémů
- Problémy, incidenty, helpdesk tikety
- Adminitrace oblastí, projektů, kalendářů
- SLA podmínky helpdesku
- Administrace modulu Řízení úkolů
- Osobní úkol
- AyMINE poskytuje kompletní podporu pro zpracování incidentů různého druhu
- Interní helpdesk
- Systémová práva modulu správy úkolů
- Typy testů
- Pracovník odpovědný za úkol
- Zakázky
- Založit nový projekt
- Používejte správné nástroje pro zpracování 8D reportu
- Generování odpovědi zákaznického centra
- Grafy pro dokumentaci problémů a tiketů
- GDPR a evidence kvalifikací
- FMEA - Analýza vlastností a funkcionality výrobku
- FMEA proces podle platného Guidebook
- FMEA: Hodnocení pravděpodobnosti výskytu závady
- FMEA Hodnocení závažnosti dopadů selhání
Správa majetku
- Produkty, aktiva, nákup a prodej
- Produkty a zboží
- Sdílený analytický model urychluje a usnadňuje spolupráci
- Kategorie produktů
- Stav produktu a jeho změna
- Dodavatel produktu
- Cíl projektu
- Přepočítat nabídku a objednávku
- Kritéria kvality
- Přehledy nabídek
- Přehledy objednávek
- Původ produktu
- Vlastnost produktu nebo výrobku
- O kritériích kvality u produktů
- DFMEA: Produktová FMEA - systémová podpora
- HARA - Analýza hrozeb, které může způsobit váš výrobek nebo proces
CRM: Správa kontaktů
- Seznam a správa adresářů
- Kontakt v adresáři vám umožní přístup ke všem informacím
- Adresář poskytuje správu kontatků, ochranu informací, možnost hromadných zpráv
- Kontakt na osobu nebo firmu
- Uživatelská dokumentace k modulu CRM
- Přehled objednávek pro zákaznické skupiny
- Přehled zákaznických objednávek
- Skupiny kontaktů
- Ochrana osobních a obchodních údajů
- Šablona zprávy
- Rychle dostupné kontakty
Metriky a hodnocení
chartsMetrics
Systémové moduly
frm
- Hlavní pracovní stůl
- Moduly AyMINE
- AyMINE — Nápověda k systému
- Uživatelské zámky
- Framework for SaaS aplikace
- Seznam záznamů
- Detail záznamu
- Soukromé poznámky a značky k záznamům
- Ikony v AyMINE
- Mazání
- Seznamy záznamů
- Gesta a klávesové zkratky
- Drag & Drop mezi záznamy
- Nastavte si, jak váš systém vypadá a funguje
- Systémová oprávnění
- Rozšíření objektů
- Jak AyMINE funguje
- Nastavte si, jak váš systém vypadá a funguje
- Filtrování v seznamu záznamů
- Zásady uchovávání hesel
- Přehled modulů a objektů
- Gesta a klávesové zkratky
- AyMINE — Aplikace pro Windows
sys
- Dokumenty a soubory
- Vztahy mezi záznamy
- Veřejný odkaz na dokument
- Systémové nastavení skupin a rolí
- Prezentace obrázků
- Nástěnka
- Klientské nastavení modulu
- Revize a komentáře
- Uživatel systému
- Administrace uživatele
- Doplňkové funkce se soubory
- Administrace uživatele
- Správa systému
- Klient
- Překlady
- Kopírování a přesouvání souborů mezi objekty
- Umístění objektu na nástěnce
- Klientské položky
- Bezpečné přihlašování
- Zařízení uživatele
- Nastavení bran pro externí zprávy
- Nastavení systému
- Klientské číselníky
- Nastvení VOIP brány
- GDPR a uživatelé systému
- Propojení uživatelů s VOIP ústřednou
- Zpráva s vnějším světem
- Bezpečná obchodní komunikace
- Volejte přímo ze CRM
- Emailové zprávy
- Posílejte SMS přímo ze CRM
- Formátované texty v aplikaci
- Pravidla pro externí zprávy
- Automatické potvrzení příchozí zprávy
- Procesy uživatelů
- Využívané procesy
- Proměnné do šablony emailu
- Přijaté a odeslané zprávy
- Typy relací (vztahů)
- Zabezpečení příspěvků a interních diskuzí
- Elektronický podpis pro podepisování i v mobilu
Rozhraní na jiné systémy
Požadavek
Požadavek je zadáním i analýzou řešení. AyMINE podporuje práci s požadavky podle projektových i analytických standardů
- Vstupní a odvozené požadavky
- Typy požadavků
- Analýza požadavků
- Stavy požadavků
- Synchronizace požadavků do Enterprise Architect
Požadavky jsou součástí správy při řízení projektu. O tom co všechno do agendy projektového řízení spadá, je více zde. Požadavky jsou navrženy tak, abyste pomocí nich dokumentovali zadání, mohli zpracovat analýzu i řídit zpracování celého projektu.
Vstupní a odvozené požadavky
Vstupní požadavky projektu jsou požadavky, které přicházejí z vnějšího prostředí, typicky od zákazníka, zadavatele projektu, nebo týmu, který projekt vymyslel. Říká se jim obecně uživatelské požadavky.
Naproti vstupním požadavkům jsou požadavky odvozené, tedy takové, které vznikly v projektu na základě analýzy, jak realizovat projekt. Odvozené jsou všechny požadavky, které vyplynuly ze vstupních požadavků, nebo jiného vstupu do projektu. Typickým vstupem, který generuje požadavky, je povinnost, metodika, jen výjimečně něco jiného.
Typy požadavků
Rozdělení na vstupní odvozené požadavky vyplývá z toho, jak požadavky vznikly. Většinou se používá pro odvozené požadavky podrobnější dělení, popsané dále. Samozřejmě v projektu mívají smysl jen některé typy požadavků v závislosti na tom, co je smyslem (produktem) projektu.
Uživatelské – už jsme si popsali. Vždy se jedná o vstupní požadavky
Systémové – požadavky, které se týkají celého řešení, systému (samozřejmě pouze pokud v projektu nějaký systém vzniká, tak je tomu i nadále)
Softwarové – Požadavky, které má/musí splnit software vytvářený v rámci projektu. Nejde o požadavky na software používaný pro realizaci projektu, ale vytvářený
Hardwarové – Požadavky, které má plnit elektronická část projektu, obecně hardware
Inženýrské – Požadavky, které má/musí splnit konstrukce v projektu vyráběné nebo vyvíjené. V závislosti na typu projektu může jít o vyvíjenou mechanickou součástku, nebo třeba připravovanou stavební realizaci
Procesní – Požadavky na proces realizace požadavku. Jde o specifické požadavky, jak se konkrétní činnost nebo etapa má realizovat, kdo se jí má účastnit apod. Pozor, neměly by opakovat metodiku, podle které je projekt realizován. Pokud tedy je požadavek na nějaký procesní úkon, např. revizi, který je dán metodikou, nemělo by být nutné jej znovu psát jako procesní požadavek (je možné jej najít jako povinnost nebo vzorový úkol v metodice).
Testy / Zkoušky – Požadavky na testy, ověřování a zkoušení jakýchkoli projektových výstupů. Požadavky by měly společně definovat vše, co má být provedeno pro ověření kvality díla. (Podle metodiky může zahrnovat i testy vstupních zařízení, např. kalibrace měřících zařízení. Většinou jsou ale tyto požadavky na kontrolu vstupů přímo součástí metodiky, nebo by měly být procesními požadavky, protože jde o kontrolu v procesu, nikoli kontrolu výstupu.)
Obchodní / Business – Požadavky vyplývající z obchodního aspektu projektu. Typicky jde o požadavky vyplývající z obchodních potřeb (mohou se týkat designu, výrobních nákladlů apod.). Pozor na rozlišení mezi požadavky a povinnostmi. Pokud je např. obchodním zadáním, aby vyvinutý výrobek měl výrobní náklady pod 10€, je dobré jej chápat jak povinnost, kterou musí projekt dodržet. Tato povinnost se promítá do všech činností od plánování projektu, po výběr dodavatelů, a nelze jednoznačně říci, že je něčím plněn.
Analýza požadavků
Pokud jsou požadavky a hlavně vyvíjený systém složitější, není možné vyvíjet / realizovat projekt přímo na základě uživatelských požadavků. Tyto požadavky je třeba promyslet, rozdělit, podle toho, kde, jak a kým budou realizovány a často podrobněji rozebrat. Těmto krokům se říká analýza. V rámci analýzy vznikají ze vstupních požadavků požadavky odvozené.
Analytické vztahy
- Z uživatelských požadavků vznikají požadavky na systém (systémové)
- Ze systémových požadavků vznikají požadavky na jednotlivé části systému, často už rozdělené podle toho, jakou podstatu ta která část systému má (inženýrský návrh – technologická část, software, hardware). Ty jsou popsány analytickým modelem.
- Požadavky na části systému se mohou dále rozpadat na dílčí, ale je lepší se tomu snažit vyhnout a nevytvářet další vrstvu. Pokud ale jde o velký systém, může to být potřeba
- Požadavky na testování mohou být vstupními i odvozenými požadavky. Pokud jsou odvozené, jsou výsledkem analýzy, co je třeba ověřit, aby byla splněna typicky kvalitativní kritéria.
Jak dokumentovat vztahy
Vztahy se dokumentují vazbou stopa / trace. Vazba vede vždy z požadavku, na základě kterého vzniká požadavek nový, odvozený. Vazby se snadno vytvářejí pomocí příkazových tlačítek v detailu požadavku.
Stavy požadavků
Zpracování požadavku je řízeno stavy. Stavy požadavků jsou:
- Nový – dosud není analyzován a čeká na zpracování
- V analýze – probíhá analýza, ale není dosud dokončena
- Analyzován – Analýza proběhla, ale měla by být ověřena.
- Ověřen (verifikován) – Proběhla kontrola, jak byl analyzován. Požadavek se do kroku dostane pouze v případě, že jej analyzuje někdo jiný, než kdo za něj odpovídá (odpovědný pracovník je uveden v požadavku). Pokud je analyzován přímo odpovědným pracovníkem, krok ověření je přeskočen
- Dokončen – Analýza byla dokončena. Stav dokončen neznamená, že je analyzované řešení realizováno, ale že je dokončena analýza, jak realizovat
- V nepořádku – Požadavek není možné analyzovat, protože tomu něco brání. Typickými důvody, proč je požadavek v nepořádku jsou
- Požadavek je v rozporu s jinými požadavky a nelze tedy všechno splnit
- Požadavek je v rozporu s omezeními, které nelze změnit. Např. je v rozporu s obecně platnými předpisy nebo jej nelze realizovat v ceně díla
- Zamítnut – požadavek byl ze zpracování vyřazen. U vyřazení by měl být vždy uveden důvod vyřazení. Typickými důvody vyřazení jsou:
- Požadavek je duplicitní s jiným požadavek, který je řešen
- Požadavek byl podán někým, kdo není oprávněn požadavek vznést
- Zrušen – požadavek zrušil svým rozhodnutím zadavatel
Synchronizace požadavků do Enterprise Architect
Požadavky i další prvky analýzy je možné automaticky synchronizovat do modelu v Enterprise Architect. Synchronizace vám umožní spojit výhody webového přístupu k zadání pro celý projektový tým i plné analytické možnosti oblíbeného nástroje.
