Identifikace změny Definice změny a jejího rozsahu a dopadu Schválení změny Prioritizace změn Úprava plánu projektu

Identifikace změny Definice změny a jejího rozsahu a dopadu Schválení změny Prioritizace změn Úprava plánu projektu

Kdo změnu vyvolal? Who RAISED the change? Jaký je důvod změny? What is the REASON for the change? Jaký je výstup/přínos změny? What is the RETURN required from the change? Jaká jsou rizika plynoucí ze změny? What are the RISKS involved in the change? Které zdroje bude třeba zapojit do realizace změny? What RESOURCES are required to deliver the change? Kde je zodpovědný za realizaci změny? Who is RESPONSIBLE for the build, test and implementation of the change? Jaké jsou vazby na ostatní změny? What is the RELATIONSHIP between this change and other changes?

Název změny/id Žadatel Stručný popis změny a její zdůvodnění Podrobný popis změny Dopady do stávajícího prostředí Cena Časová náročnost Request for change - RFC

Změně musí být přiřazena priorita na základě Dopadu (vlivu) Urgence Podle priority se budou upravovat plány přidělovat zdroje

Není nutné dělat vše co si někdo vymyslí ale musí být argumenty/lepší řešení Ne všechno se musí udělat hned Ale musí být argumenty Dá se odkládat do příští verze

Přeplánování času, peněz, zdrojů Změna produktu Architektura, funkčnost, databáze Různá reakce podle metodiky Vodopád UP Agile

Není dopředu jasné kolik bude projekt stát Špatně se navrhuje architektura Náročnější řízení Lidé (motivace/nasazení)

Počet změn Frekvence změn Počet malých/neschválených změn Dopad změn (+/-) Snížení nákladů

Databáze šablon Databáze poučení Databáze aktivit Databáze rizik - Vytvoříme si šablony z dokumentů, které jsme vytvořili během projektu třeba je někdy použijeme - zjištění co se povedlo/nepovedlo jaké si vzít poučení (ideálně by se mělo provádět, hned v situaci, ale na to není čas), často ani po projektu - Mnoho dokumentů, které nikdo nečte, nikdo to nemá na starost, nikdo si nevezme poučení, - Databáze aktivit kategorie, typ, odhad, skutečné trvání, prostředí, požadavky na dovednosti - Databáze rizik - Katagorie, řešení, následky,... Výhody: - standardizace procesu řízení a tvorby - Optimalizace standardů - Výukový materiál

Business cíle a potřeby Business procesy ICT služby Řízení IT služeb ICT infrastruktura

Definice? Jaké procesy znáte?

Nasazení Analýza Testy Prgání Návrh

Zaměření projektu Plánování Analýza Správa kódu Řízení týmu Testy Nasazení Uzavírání projektu Odhad projektu Návrh Prgání Kontrola projektu Kontrola kvality Řízení rizik Řízení zdrojů Řízení změn

Strategické plánování Vstupy Produkty Hlavní činnost firmy Podpůrné procesy

High level definice procesů a rolí Podrobnější definice aktivit, výstupních dokumentů a rolí Detailní popis jednotlivých aktivit Toto není pravidlo, ale je to rozumný koncept

Plan Act Do Check

Doučásti všch procecesů A ct Pl an Ch eck D o Plan Prověřit současnou výkonnost Posoudit problémy, omezení Navrhnout řešení Naplánovat provedení o Do Otestovat u činnost řešení o Check Zhodnotit výsledky testu Posoudit dosažení výsledku Zaměřit se na překážky bránící zlepšení o Act Rozpracovat konečné řešení, aby bylo kdekoli použitelným přístupem

Key Performance Indicator (KPI) Kvantitativní Rychlost dokončení Produktivita Chybovost Náklady Kvalitativní Splnění standardů Plnění účelu

Řízení kapacit a jejich dostupnosti Správa konfigurací Správa požadavků Plánování projektů Měření a vyhodnocování projektů Quality assurance Definice business procesů

Úroveň Úroveň schopnosti Úroveň zralosti 0 Incomplete - 1 Performed Initial 2 Managed Managed 3 Defined Defined 4 Quantitatively Managed Quantitatively Managed 5 Optimizing Quantitatively Managed

Úroveň Úroveň schopnosti 0 Incomplete - 1 Performed Initial Úroveň zralosti 2 Managed Managed 3 Defined Defined 4 Quantitatively Managed Quantitatively Managed 5 Optimizing Quantitatively Managed 0 Standard není prováděn/zaveden - každý projekt vypadá jinak, není ani zvykové právo 1 Schopnost jsou známé základní postupy jak dosáhnout cíle, ale není to nijak popsané Zralost typicky vše ad-hoc, chaos, hrdinské výkony jednotlivců! Neznamená to, že produkty nefungují jen je často překračován budget a plán 2 proces je zavedený a plní svůj cíl; není však žádný progres proces není upravován, aby odpovídal požadavkům; lidé jsou zkušenější znají postupy a jsou schopni se jich držet i v krizových situacích; jsou dostupné prostředky pro jeho zajištění Zralost základní procesy (plánování, dodání, QA) jsou definovány, existují i šablony jak např. plánovat projekt 3 proces a jeho části jsou popsány stejně napříč celou organizací (struktura, hierarchie); není definováno jen co se má udělat, ale i potřebné zdroje, role zaměstnanců apod. Existují metodiky, nástroje definující a podporující proces; přesný popis; 4 jsou stanoveny kvantitativní parametry pro hodnocení procesu, jsou sledovány a vyhodnocovány; rozdílem oproti 3 je to, že se dá předvídat trvání (nebo jiné kvantitativní parametry) procesu na 3 to je jen kvalita výstupu 5 dochází k optimalizaci procesu jak na základě parametrů z 4 tak na základě zkušenosti apod. (procesy sledování procesů) Příklad: open space, kde jsou zaměstnanci a vaří si kávu a objednávají pizzu

Requirements Management Configuration Management Project Planning a Project Monitoring Process and Product Quality Assurance Control Supplier Agreement Management Measurement a Analysis

Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Management Decision Analysis and Resolution Organizational Environment for Integration

Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Management Decision Analysis and Resolution Organizational Environment for Integration RD už jsou rozlišovány typy požadavků (zákaznické uživatelksé, je s nimi kontinuálně pracováno TS vývoj je ustálený je zahrnut design apod PI začlenění vytvářeného do reálného světa, do skupiny ostatních aplikací Ver ověření, že splňuje požadavky Val ověření, že funkčnosti

Výhody Rámec pro prioritizaci akcí a neustále zlepšování. Rámec pro provádění spolehlivého a konzistentního hodnocení současného stavu. Podporuje srovnání bez ohledu na typ poskytované služby. Nevýhody CMMI model nestanoví skutečné řešení pro realizaci. CMMI nepopisuje žádné procesy.

Důvěra v produkt vyhází ze schopnosti výrobce prokázat kvalitu procesu (návrhu, vývoje )

V certifikované organizaci musí být definovány procesy: Řízení kvality Odpovědnost managementu Řízení zdrojů Realizaci výrobků Procesy ve vztahu k zákazníkům Navrhování a/nebo vývoj Nákup Výrobní postupy a postupy při realizaci služeb Měření, analýzu a zlepšení

Snížení zátěže a eliminace duplicitní / nadbytečné práce. Zlepšení kvality a času při dodávce služeb. Zlepšení dostupnosti, spolehlivosti a bezpečnosti kritických služeb IT. Poskytování služeb na základě potřeb zákazníků / uživatelů. Definování jednotlivých rolí a jejich zodpovědnosti. Stanovení odpovídajících ukazatelů výkonnosti nutných pro kontrolu a následné zlepšování (KPI).

Zajištění dodávky služeb dle definované úrovně (SLA) Řízení výkonnosti služeb Řízení technologií Sběr informací pro zlepšení Service desk Incident management Problem management

Plánování Strategie Zlepšování služeb