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

Transkript

1

2

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

4 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?

5 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

6 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

7 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

8 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

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

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

11

12

13 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

14

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

16 Definice? Jaké procesy znáte?

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

18 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

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

20 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

21 Plan Act Do Check

22 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

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

24

25 Ří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ů

26 Ú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

27 Ú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

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

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

30 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

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

32

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

34 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í

35

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

37 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

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

39