I denne debattråd udtrykker skribenten alene deres egen holdning om emnet. Hold venligst vores debatregler i tankerne hvis du ønsker at deltage i debatten.

Måling på changemanagement

1
4. april 2008 kl. 22:46

En stor del af ITIL er målinger på både processer og systemer.

Konkret er jeg igang med et etablere en måling på changeprocessen. Har I nogle gode inputs?

Mine egne ideer:
- Andel af succesfulde gennemførte changes
- Changes gennemført med errors og impact
- faktisk anvendt tid på changen(til fremtidig estimering)
- katagorier af changes(fx Emergency changes, etc)
- hvilket lag der køres flest changes i(net, system, etc)
- Changes på CIs (fx til udarbejde bagatel grænse)

Har I andre/bedre forslag, hvad mener I changemanageren får behov for?

Derudover er der også mulighed for at måle på selve changeprocessen.

- Gennemførsel af CAB møder
- følges processen
- tid fra request til gennemførsel
- respons / godkendelsestider

Forslag er mere end velkomne.

settingsDebatindstillinger
2
19. juni 2008 kl. 20:06

Hej,

Henrik Søgaard har en god pointe om at resultatmål for processen skal hænge sammen med jeres egne mål. Eller som jeg ville udtrykke det: Du skal gøre dig klart hvad du vil opnå før du definerer hvad du måler.

Når man bevæger sig fra lav til højere procesmodenhed vil man have forskellige udfordringer på de forskellige modenhedsniveauer - og dine målinger skal matche disse forskellige udfordringer.

På lave modenhedsniveuaer er det måske dokumentationen af ændringen og den helt basale CM proces der er problemer med - så kunne relevante målinger være antallet af ændringer der sendes retur til change requester med anmodning om bedre dokumentation & måling procesgennemløb.

Jeg er enig med MD i at de tre første giver god mening.

Skriv evt. lidt mere om de udfordinger som I har med CM processen, så kan vi skræddersy forslagene lidt bedre.

Mvh Kenneth

2
13. juni 2008 kl. 16:34

En KPI som jeg også synes giver mening er antallet af fall-back's. Hvorvidt den er dækket i dine forslag ved jeg ikke, men det giver en indikation på kvaliteten af changes generelt.

2
12. april 2008 kl. 08:41

... om man vil bruge de data man måler. Ellers havner man nemt i et målehelvede hvor man måler alt muligt som inegn bruger. Det fjerner respekten for processen og det er "dødeligt". Jeg syntes det er nogle ganske fornuftige ting du har valgt - start med det - måske i virkeligheden kun et udpluk af de du har valgt. De 3 første giver rigtig god mening - og alle vil kunne forstå hvorfor du måler dem. Start der. Du kan altid senere tage flere på hvis behovet opstår.

2
5. maj 2008 kl. 15:20

Jeg er enig at man bestemt ikke skal måle for bare at måle; og ja det er dødeligt for processen. Når vi definerer mål for en given proces begynder vi altid med resultatmålene; leverer processen overhovedet det den skal. Dernæst definerer vi mål for hvor mange ressourcer der skal til for at levere resultaterne. Dine resultatmål skulle også meget gerne hænge sammen med Jeres overordnede (strategiske) mål. Så hvis det er vigtigt for Jeres organisation at have mange succesfulde change projekter, så er det, det du skal måle på. Er det kvaliteten af Jeres changes, så er det, der skal måles på. Dernæst kan du definere ressourcemålene. Du bør som hovedregel altid have mindst et resultatmål, og gerne mindst et ressourcemål på din proces.

2
5. maj 2008 kl. 19:34

Man skal i den grad overveje om man vil bruge data.

Uden KPI'er ingen SLA, hvordan skulle du ellers kunne afrapportere.

@Mikkel

Du bruger udtrykket LAG, hvad menes?

  • Peter
2
19. juni 2008 kl. 13:25

Når jeg skriver lag, er det mht. ændringer infrastruktur, som er opdelt i forhold til grupper. Dvs. fx netværk, windows, unix, applikationsdrift. En måling på hvor der sker flest changes kan anvendes bla. til ressurse styring samt impact. Fx mange changes på netværksinfrastruktur vil kunne ramme langt bredere end en ændring på en enkeltstående applikation.

2
3. februar 2009 kl. 12:37

Hmm. Jeg er lidt loren ved din definition af LAG, som jeg dog godt forstår. Det indikerer at du/I ikke har "oversat" tekniske infrastruktur elementer til Services, med andre ord, I mangler at definere Jeres Servicekatalog til Services på 'toppen' af tekniske standardleverancer.. Changes, på den lange bane, skal vikles udenom Services, så man her har styr på Changes der påvirker forretningen. Det er her det bliver vanskeligt at mixe Release Management (ITIL V3) og Change Management (på Services). Det betyder IKKE at der ikke skal være styr på ændringer i Infrastruktur, som typisk (per definition) vil berøre indtil flere Services. Det er her 'Service Dependency Mapping' (se indlæg fra Kenneth D Sørensen) og 'Service Catalogue', først bliver rigtigt interessant. Måske er der i virkeligheden behov for en 'wrapper' process (lad os ikke kalde den 'Change Management')der udenom Configuration Management, pragmatisk kan håndtere denne ikke uvæsentlige side af 'ICT Infrastructure Management'...