6.5 Six Sigma toepassen in de IT

Methoden en modellen Six Sigma toepassen in de IT

6.5 Six Sigma toepassen in de IT

397

TIL-processen geven geen garantie voor korte doorlooptijden met zo min mogelijk defecten. Ronald van Gelder en Theo Tops tonen in dit artikel aan dat Six Sigma een bruikbare methode is om deze processen te verbeteren.

I

Van twee praktijksituaties beschrijven we hoe Six Sigma is ingezet en met welk resultaat. Ook geven we een aantal suggesties voor het gebruik van Six Sigma binnen change-, service level- en configuratiemanagement. Maar eerst leggen we uit wat Six Sigma eigenlijk is.

WAT IS SIX SIGMA Six Sigma is een uit Amerika overgewaaide methode om processen op een gestructureerde manier te verbeteren. Mikel Harry en Richard Schroeder ontwikkelden haar in de jaren tachtig bij Motorola. Daarna kreeg Six Sigma vooral bekendheid door de wereldwijde invoering bij General Electric. Six Sigma draait om het terugdringen van de variantie in een proces: als een proces op een constant niveau presteert, heeft de service altijd een bepaald niveau. Een klant waardeert dit meer dan een bij vlagen extreem goede service die bij vlagen ook veel slechter is, zelfs als dit tot een betere gemiddelde kwaliteit leidt. Six Sigma bestaat uit vijf fasen, DefineMeasure-Analyze-Improve-Control, afgekort DMAIC: • De definitiefase (Define) bepaalt de scope en te verwachten eindresultaten en legt vast welke prestatiekenmerken worden gemeten. Ook maakt het team een businesscase om aan te tonen dat het project zichzelf snel terugverdient. • De meetfase (Measure) meet het proces in

de bestaande vorm (As-Is). • De analysefase (Analyse) analyseert de meetgegevens om te komen tot verbeteringen. • De verbeterfase (Improve) test de verbeteringen. • De controlefase (Control) controleert of de verbeteringen blijvend zijn en draagt ze over aan het lijnmanagement. Alle fasen gebruiken data uit metingen. Bij het bepalen van de eisen aan het proces stellen zij de klanteisen centraal. Zo brengt een Voice of the Customer (VOC) onderzoek de klanteisen in kaart. En berekent een Proces Capability Analyse de prestatie van het proces. Hierbij bepaalt een Meet Systeem Analyse (MSA) of de gemeten variantie inderdaad uit het proces komt en niet uit het gebruikte meetsysteem. Een Design of Experiments tenslotte heeft als doel om door middel van experimenten aan te tonen dat de aannames en gemaakte hypothesen correct zijn.

6

Rollen in Six Sigma Six Sigma heeft rollen ontwikkeld om de planning en organisatie van verbeterprojecten in goede banen te leiden (zie figuur 1): • Champion: degene die het (Black Belt) programma van verbeterprojecten voor het bedrijf ondersteunt (vaak ook als sponsor). Een vuistregel is 1 Champion voor 15 Black Belts. Een Champion is gemiddeld 1 dag per week bezig met Six Sigma. • Master Black Belt: mentor, trainer en coach van de Black Belts. Master Black

IT Service Management, best practices, deel 4 Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

398

Belts zijn minimaal twee jaar fulltime beschikbaar voor de Black Belts. Meestal is er 1 Master Black Belt per 100 Black Belts. • Black Belt(s) (BB): de projectleider(s) van het verbeterproject. Ook Black Belts zijn voor een periode van ongeveer twee jaar volledig vrijgemaakt voor het uitvoeren van meerdere gelijktijdige verbeterprojecten. Meestal is er één Black Belt per 50 tot 100 medewerkers. • Green Belts (GB): de teamleden van het verbeterproject. Omdat ze slechts voor 1 dag per week, over een periode van ongeveer 4 tot 6 maanden, zijn vrijgemaakt voor Six Sigma, vraagt de Black Belt hen de Six Sigma-principes binnen de organisatie en op hun afdeling verder uit te dragen. Soms zijn er ook nog andere rollen: • Yellow Belt: het projectteam kan een beroep doen op zijn specifieke kennis. • Money Belt: controleert of de berekende besparingen zijn gebaseerd op de juiste aannames en verifieert dat ze ook daadwerkelijk worden behaald. • Managen van de processen met het doel de strategische en tactische doelstellingen te behalen • Plannen, budgetteren en sponsoren van de teams

• Leidt meerdere Master projecten naar Black Belt goed resultaat • Deskundige voor BB’sen GB’s • Plannen vervolg projecten • Rapporteren aan Six Sigma-stuurgroep

Hoewel dit verschilt per organisatie, is een goede vuistregel dat twintig procent van de medewerkers een Six Sigma-training moet hebben gevolgd. Ieder Six Sigma-projectteam is samengesteld uit verschillende Green Belts en heeft een Black Belt als projectleider. Keuze voor Six Sigma Grote bedrijven starten regelmatig verbeterprogramma’s. Door het verbeteren van hun interne processen willen ze beter aan de wensen van de klant voldoen. Maar meestal gebruiken ze hier geen gestructureerde methode voor. Als er al dingen verbeteren, dreigt de organisatie toch terug te vallen in het oude patroon zodra het programma stopt. Six Sigma is een bewezen methodische aanpak die veel industrieën succesvol gebruiken. Pas als als de (lijn-)organisatie aantoont dat ze de bereikte resultaten vast kan houden, is de controlefase klaar.

SixSigma-stuurgroep Dir./Man., Six Sigmaproceseigenaren, champions

• Ondersteunen het Six Sigma-initiatief • Review Six Sigma-projecten • Managen ondersteunende processen Financiën Money Belt

• Berekent voordelen van het project

Black Belt • Project teamleider & technische ondersteuning • Voltijds voor twee jaar

Green Belt

• Teamleden werken parttime aan Six Sigma-projecten

Figuur 1 Six Sigma-rollen

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Uit verschillende projecten blijkt dat IT-medewerkers aanvankelijk sceptisch zijn omdat ze Six Sigma vooral zien als een methode voor productiebedrijven. Ze hebben de indruk dat Six Sigma niet werkt in een complexe IT-omgeving met veel klantspecifieke kwaliteitskenmerken. Soms speelt ook mee dat er al verschillende initiatieven met het oog op kwaliteitsverbetering, zoals CMMI en ISO 20000, zijn ontplooid, en dat leidt tot ‘methodemoeheid’. Basu & Wright (2003) en Brue (2005) hebben inmiddels aangetoond dat Six Sigma in meerdere sectoren en verschillende bedrijven, dus ook IT-bedrijven, succesvol is. Omdat het succes van het verbeterproject sterk afhangt van de inzet van de medewerkers, moet het management hier in het begin voldoende aandacht aan besteden.

SIX SIGMA IN ITIL-PROCESSEN De IT-Infrastructure Library (ITIL) is zeer populair in de IT-sector. Het Office of Government Commerce (Groot-Brittannië) ontwikkelde ITIL in de jaren tachtig. De methode groeide in het midden van de jaren negentig uit tot de de facto wereldwijde standaard voor IT-servicemanagementprocessen. ITIL onderscheidt de volgende processen: • incidentmanagement • probleemmanagement • configuratiemanagement • changemanagement • releasemanagement • servicelevelmanagement • financieel management voor IT-services • capaciteitsmanagement • IT-servicecontinuitymanagement • availabilitymanagement • securitymanagement Als er nog geen ITIL-processen zijn, moeten die eerst worden ingevoerd. Daarna verkleint Six Sigma de variantie van die processen, door hier correcte en volledige gegevens over te verzamelen. Die maken het mogelijk om de vinger op de zere plek te leggen en doelge-

richt te verbeteren. Een service gaat hierdoor constanter en vaak ook beter presteren, bijvoorbeeld doordat het aantal fouten daalt. We geven hiervan twee voorbeelden: één van Six Sigma in het incidentproces en één van Six Sigma in availabilitymanagement.

399

VERBETEREN VAN INCIDENTMANAGEMENT IN SERVERBEHEER Incidentmanagement moet een verstoorde service zo snel mogelijk herstellen zodat de klant hem kan blijven gebruiken. Om dit te bereiken analyseert incidentmanagement de verstoring, lost haar op, bewaakt de voortgang en escaleert het incident als dit nodig is. Dat brengt kosten met zich mee, en die moeten zoveel mogelijk worden beperkt. Verstoringen kunnen dus beter worden voorkomen. Een belangrijke maat voor het aantal verstoringen is de zogenaamde Defects Per Million Opportunities (DPMO) berekening. Iedere mogelijke handeling in een proces (mogelijkheid of opportunity) kan slagen of falen. Als de handeling faalt, noemt Six Sigma dit een defect. Hoe groter het aantal mogelijkheden, hoe groter de mogelijke variantie en hoe minder het proces onder controle is. Servers, applicaties en andere componenten vormen een dergelijke complexe infrastructuur met veel mogelijkheden. Ieder extra onderdeel vergroot de kans op defecten aanzienlijk. Bewakingssoftware en gebruikers helpen deze systemen onder controle te houden. Zij melden storingen aan de servicemedewerkers. Die verifiëren en analyseren de melding en ondernemen de benodigde actie.

6

Definitiefase De definitiefase bepaalt wat het doel is van het verbeteringsproject en wie het gaan uitvoeren. In dit voorbeeld is het doel het halveren van het aantal storingsmeldingen in een bedrijfsonderdeel met ongeveer dertig medewerkers.


Anderson-Darling Normality Test A-Squared 1,18 P-Value < 0,005 Mean 81,403 StDev 26,298 Variance 691,568 Skewness 0,916695 Kurtosis 0,949688 N 72 Minimum 36,000 1st Quartile 65,000 Median 76,500 3rd Quartile 95,000 Maximum 161,000 95% Confidence Interval for Mean 75,223 87,582 95% Confidence Interval for Median 71,220 84,780 95% Confidence Interval for StDev 22,594 31,466

400

0

30

60

90

120

150

95% Confidence Intervals Mean Median 70

75

80

85

90

Figuur 2 gemiddelde en standaarddeviatie in de meetfase

Meetfase Eerst doet het Six Sigma-projectteam een nulmeting om het aantal storingsmeldingen vóór de verbetering vast te stellen. De registratiesoftware van de helpdesk is vaak heel goed bruikbaar om dit soort data te verzamelen. Deze nulmeting duurt drie maanden. Het resultaat is een gemiddelde van tachtig storingsmeldingen per dag en een standaarddeviatie van 26 (zie figuur 2). Ook voert het team een Meet Systeem Analyse (MSA) uit. Een MSA controleert of de hele meetketen in orde is, en toont aan welk deel van de variantie uit het proces komt en welk deel uit de meting zelf. Hierbij moeten we rekening houden met de deskundigheid en ervaring van de medewerker die de MSA uitvoert. Hij leest immers de meetinstrumenten af en beoordeelt de kwaliteit. Een MSA in een productiebedrijf vraagt twee of drie medewerkers een proefstuk te maken of laat hen dezelfde set productieonderdelen beoordelen en vergelijkt de beoordelingen. Bij een proces dat vrijwel uitsluitend uit men-

sen bestaat is een dergelijk experiment veel lastiger. Als het al mogelijk is om bijvoorbeeld kunstmatige verstoringen te genereren beïnvloeden medewerkers (on)gewild het resultaat omdat zij zich bewust zijn van de meting. Het team heeft in dit bedrijfsonderdeel toch een MSA kunnen uitvoeren, door de totale dataset van storingsmeldingen te gebruiken. Hier zocht het team drie exact dezelfde storingen uit die door meerdere medewerkers waren afgehandeld. Vervolgens werden de uitkomsten met elkaar vergeleken. Analysefase De analysefase neemt het proces grondig onder de loep. Daarbij is het van essentieel belang om niets als vanzelfsprekend aan te nemen. Het gevaar van terugvallen op de processen zoals die op papier zijn beschreven is bijvoorbeeld dat ingeslepen gewoontes en afwijkingen van het beschreven proces niet worden opgemerkt. Om dit te voorkomen, kunnen medewerkers in brainstormsessies vertellen over hun werkelijke routines. Of het team interviewt hen hierover. Aan de hand hiervan inventariseren



Geen verstoring

Monitoring

Software

Backup SW

Overbodige meldingen

Productieopdracht

401

Client SW

Informatieve meldingen

Herstelaanvraag

Te veel onnodige meldingen

No restore test Capaciteit

No recovery

Gecorreleerd

Open files

WAN HW

Tijdslot te krap Identiek

Tooling

Server HW

Tape handling Dubbele meldingen

Mensen

Hardware

Figuur 3 Cause and Effect diagram

30000 100 25000

Aantal

60

15000

40

10000

20

5000 0 Cn

25493 1500 92,9 5,5 92,9 98,4

122 0,4 98,8

86 0,3 99,1

46 0,2 99,3

28 0,1 99,4

22 0,1 99,5

th er O

9 45 r0

Cn

r0 38 0 Cn r0 00 3 Cn r0 01 9

7 53 r0 Cn

r0 00 0

50

Cn

r0 Cn

M on

ito

rin

g

9

0

bron

Aantal Percentage Cum %

Percentage

80 20000

22 0,1 99,6

6

121 0,4 100,0

Figuur 4 Paretodiagram (histogram)

de medewerkers de belangrijkste oorzaken van verstoringen en leggen deze vast in een visgraatdiagram (Ishikawa of Cause and Effect-diagram, zie figuur 3).

Daarna zet het team deze foutoorzaken in een Paretodiagram (histogram, figuur 4). Hieruit blijkt dat de bewakingssoftware (Monitoring) het overgrote deel van alle storingsmeldingen genereert. Verdere analyse legt de


402

grondoorzaken bloot die het team tijdens de verbeterfase moet wegnemen. Veel storingsmeldingen blijken alleen voor informatieve doeleinden te worden gebruikt, zoals meldingen over goed verlopen backups. Dat zijn dus geen echte verstoringen. Andere meldingen zijn een gevolg van een andere storing en voegen geen informatie toe. Verbeterfase Het team kan een aantal overbodige meldingen eenvoudig uitschakelen. Dat levert de eerste zogenaamde ‘quick win’ op. Het team heeft echter het voornaamste resultaat geboekt met een uitgebreid onderzoek naar de ingestelde regels in de bewakingssoftware. Het heeft alle bewakingsgrenzen op de juiste waarde ingesteld en een aantal correlatieregels toegevoegd, zodat de software alleen nog de hoofdstoring meldt en de gevolgstoringen onderdrukt. Het resultaat is een gemiddelde van 15 storingsmeldingen per dag met een standaarddeviatie van 11 (zie figuur 5). Door de lagere gemiddelde waarde zijn de foutkosten met tachtig procent afgenomen. En door de la-

0

30

60

90

120

gere standaarddeviatie is het proces stabieler en voorspelbaarder. Het aantal storingsmeldingen is in een zeer korte periode met tachtig procent afgenomen (zie figuur 6). De doelstelling om dit aantal te halveren is dus ruimschoots gehaald. De afdeling heeft nu een veel beter overzicht van storingen waar ze daadwerkelijk actie op moet ondernemen. Daarnaast komt er tijd vrij om maatregelen te nemen om nu nog voorkomende storingen in de toekomst te voorkomen. Controlefase In de controlefase zorgt het team ervoor dat de lijnorganisatie zelfstandig doorgaat met verbeteren. Het bereikte resultaat moet in ieder geval worden vastgehouden. Daar gebruikt Six Sigma Control Charts voor. Deze diagrammen laten zien of de uitkomsten van het proces binnen vooraf ingestelde grenzen blijven (de zogenoemde controlelimieten). In het voorbeeldproject is een lijnmedewerker aangesteld, die dagelijks de storingsmeldingen controleert en direct actie onderneemt

150

95% Confidence Intervals Mean

Anderson-Darling Normality Test A-Squared 3,09 P-Value < 0,005 Mean 15,806 StDev 11,050 Variance 122,102 Skewness 1,79427 Kurtosis 4,92975 N 108 Minimum 1,000 1st Quartile 8,250 Median 13,000 3rd Quartile 21,000 Maximum 64,000 95% Confidence Interval for Mean 13,698 17,913 95% Confidence Interval for Median 11,000 16,000 95% Confidence Interval for StDev 9,747 12,758

Median 10

12

14

16

18

Figuur 5 gemiddelde en standaarddeviatie in de controlefase



Improve

Measure

Control

180

11

140

1

1 1 1

403 1

1 1

120

1 1 1

100 80

1 1

60 11 1 11 1

1 1

1

-2

-2 -6

00

6

111 6

06

11

20

00

6 66-

6 18

-5

-2

00

6 -4

-2

00 29

-4

-2 10

-3

-2

00

6

06 20 21

06

31-

20 29-

-2 -1 21

1-

20

00

6

06

11

-7

0

2-

UCL=27,7 _ C=15,8 LCL=3,9

1

00

20

1 111 11 1

1

15

1 11

40

25

Aantalstoringsmeldingen

160

datum Figuur 6 Control Chart van het aantal storingsmeldingen per projectfase

om het aantal storingsmeldingen tot een minimum te beperken. Als er een Green Belt van de betreffende afdeling in het verbeterteam zit, is dat een logische kandidaat om deze functie te vervullen.

VERBETEREN VAN AVAILABILITYMANAGEMENT Availabilitymanagement zorgt er voor dat de IT-componenten zoals backups beschikbaar zijn op de met de klant overeengekomen tijdstippen. Klanten gaan er vaak van uit dat ze na een calamiteit altijd kunnen terugvallen op een backup. In de praktijk kunnen er verschillende redenen zijn waardoor een backup toch onbruikbaar is, zoals problemen met de netwerkconnectie, hardware of naamsherkenning. Het verbeteren van het backupproces verhoogt het percentage geslaagde backups fors. Het onderstaande voorbeeld illustreert dit aan de hand van een Six Sigma-project van negen maanden in een bedrijfsonderdeel met ongeveer vijftien medewerkers. Definitiefase Een Voice of the Customer (VOC) onderzoek helpt bij het definiëren van de doelstelling

voor de verbetering van het backupproces. Dit onderzoek geeft het woord aan de belangrijkste klant van een organisatie over welke kwaliteitsaspecten hij belangrijk vindt. Vaak is dit degene die betaalt, maar soms ook de gebruiker of de medewerker die het meest contact heeft met de klant. Een Voice of the Customer onderzoek kan bijvoorbeeld bestaan uit het afnemen van interviews, enquêtes of het organiseren van een brainstormsessie. Uit het Voice of the Customer onderzoek in dit voorbeeld kwam een streefwaarde voor het foutpercentage van het backupproces van één procent of lager. Ter vergelijking: Gartner hanteert een ‘best-in-class’ foutpercentage van vijf procent of lager.

6

Meetfase Een Six Sigma-projectteam heeft in 2006 de performance van het backupproces gemeten. Hiervoor heeft het de logfiles van de backupsystemen gebruikt. Om een goed beeld te krijgen heeft het team de data van acht maanden gebruikt voor de centrale backups en de data van vijf weken voor de lokale backups. In die


404

periode zijn er ongeveer 24.000 centrale backups gemaakt en 4.100 lokale backups. De nulmeting gaf een foutpercentage van zeven procent voor de lokale backups. Hier concentreren we ons in dit artikel op. Analysefase In de analysefase gaat het niet alleen om de meetdata, maar ook om de beschikbare rapportages, de gebruikte tools, en het contact met de klant. Er kunnen een aantal zaken verbeterd worden: • Afspraken over backups in SLA’s vastleggen • Taken, verantwoordelijkheden en bevoegdheden verduidelijken • Rapportages verbeteren • Bewakingsregels verbeteren • Criteria over het gebruik van tapes en de termijn van vervanging aanscherpen Verbeterfase Hoewel op het moment van schrijven de verbeterfase nog loopt, zijn de eerste resultaten al zichtbaar. Het gemiddelde foutpercentage is gedaald van zeven naar vier procent en ook de variantie is aanzienlijk afgenomen (zie figuur 7).

CHANGEMANAGEMENT Het doel van het changemanagementproces is het beheersen van de veranderingen aan de systemen van een klant. Dit varieert van het resetten van pincodes en verlenen van autorisaties tot het bestellen, testen en installeren van systemen. Het is moeilijk te bepalen aan welke eisen deze zeer uiteenlopende activiteiten moeten voldoen, zelfs na opsplitsing in diverse deelprocessen. Bovendien ziet een organisatie deze processen niet altijd als werkelijk toegevoegde waarden, maar vooral als ondersteunend of faciliterend. En daarvoor maakt een dienstverlener slechts in enkele situaties afspraken, zoals de tijd waarbinnen een wijziging van de bestaande installaties of applicaties moet worden uitgevoerd. De uitvoering en beheersing van de vele subprocessen is een verantwoordelijkheid van de dienstverlener, en die is het meten van fouten of overschrijdingen niet altijd gewend. Six Sigma helpt hier vooral om bestaande processen beter op elkaar af te stemmen, bijvoorbeeld door:

Verbeterfase

Analysefase 14% 12%

Foutpercentage

10% 8% UCL=6,67% 6% _ X=3,68%

4% 2%

LCL=0,68% 0% 37

38

39

40

41

42 43 week

44

45

46

47

48

Figuur 7 Foutpercentage in analyse- en verbeterfase



• procedures en werkinstructies korter te maken, • klantspecifieke wijzigingsvoorstellen die tot standaard zijn verheven te reduceren, • taken en verantwoordelijkheden te definiëren.

CONFIGURATIEMANAGEMENT Dit proces beschrijft de systeem- en applicatiegegevens van de aanwezige installaties en IT-infrastructuur. Configuratiemanagement heeft een aantal belangrijke foutbronnen die de kwaliteit van de informatie sterk kunnen beïnvloeden. Vaak nemen IT-dienstverleners de wijze van registratie van infrastructuur direct over van hun klanten, met als gevolg dat er na enige tijd een grote verscheidenheid van informatiebronnen ontstaat waarvan de inhoud en de toepassing slechts bij enkele specialisten bekend is. Invoering van een centrale database voorkomt niet altijd dat klantspecifieke informatie alsnog in gescheiden databases wordt bijgehouden. De beheersbaarheid van de informatie komt daarmee onder grote druk te staan en het risico dat verkeerde beslissingen worden genomen neemt toe. Hier komt bij dat bijna alle ITIL-processen sterk afhankelijk zijn van de juistheid en aanwezigheid van de informatie van configuratiemanagement. Six Sigma onderzoekt op gestructureerde wijze welke minimale eisen de klant stelt aan registratie en onderhoud van de gegevens. Ook hier is transparantie in taken en verantwoordelijkheden noodzakelijk. De informatie moet er niet alleen zijn, ze moet ook kloppen. Six Sigma heeft instrumenten voor het meten van de beschikbaarheid van informatie én voor het meten van het aantal fouten in de registratie.

SERVICELEVELMANAGEMENT Servicelevelmanagement zorgt ervoor dat de geleverde diensten overeen komen met de afspraken met de klant. Daarmee sluit het aan bij een van de belangrijkste doelstellingen van Six Sigma: bepaal de prestatie van je processen op basis van de eisen van de klant.

Vaak hebben klanten veel verschillende eisen. Dit druist in tegen het standaardiseren en vereenvoudigen van de processen door de IT-dienstverlener. We maken daarom Service Level Agreements (SLA’s) die in hoofdlijnen de afspraken met de klant vastleggen en spreken verschillende serviceniveaus af om zoveel mogelijk aan die specifieke wens van de klant te voldoen. Hierbij ontstaan twee problemen: 1. Er blijven veel klantenwensen over die een SLA niet vastlegt, maar die impliciet wel het oordeel van de klant vormen over de algemene dienstverlening. Een Voice Of the Customer (VOC) onderzoek helpt inzicht te krijgen in de ‘impliciete klanteisen’. Druk deze wensen uit in meetbare procesvariabelen. Als dat niet kan, horen ze niet in een SLA. Leg ze dan op een andere, meetbare, manier vast. Zo is ‘ondersteuning door deskundige medewerkers’ een belangrijke eis. Six Sigma zegt dat een meetbare variabele een dergelijke eis moet vastleggen. Hiervoor kunt u bijvoorbeeld nagaan hoe u deskundigheid kunt toetsen en met de klant overleggen aan welke manier hij de voorkeur geeft, en wat de minimale uitkomst is. 2. De SLA-prestatienormen zijn niet altijd makkelijk te vertalen naar interne processen. Afspraken worden op een hoog abstractieniveau gemaakt. Dan weten medewerkers niet welke prestatie ‘hun’ proces moet leveren om de norm te halen. Hierdoor zijn ze niet in staat om dit te sturen. Six Sigma lost het tweede probleem op door in iedere processtap te bepalen welke variabelen een bijdrage leveren aan de uiteindelijke prestatie.

405

6

Bepaal dus welke procesvariabelen belangrijk zijn om te voldoen aan de afspraak met de klant en welke waarde of prestatie iedere variabele moet leveren. Dwing uzelf om de variabelen uit te drukken in meetbare, kwantitatieve eenheden. Vertaal de variabelen naar andere processen en bepaal ook de aard van de variabele en de (interne) prestatienorm. Ook deze moet meetbaar zijn.


406

Uiteindelijk ontstaat zo een overzicht van de belangrijkste stuurvariabelen van de ITIL-bedrijfsprocessen en de onderlinge relaties van meetbare en dus ook bestuurbare prestatieindicatoren. Six Sigma helpt niet alleen deze variabelen te bepalen, ze helpt tevens deze te verbeteren en onder controle te houden.

MANAGEMENTAANDACHT BIJ EEN SIX SIGMAPROJECT Een Six Sigma-project verandert veel in een organisatie. Het management moet hier voldoende aandacht aan besteden. Zo stelde een Black Belt in één van de projecten een eenvoudig systeem voor om de oorzaken van de storingsmeldingen te coderen. Dit om de meest voorkomende oorzaken te vinden en als eerste aan te pakken. Hoewel hij dit meerdere malen met de medewerkers besprak, bleef het resultaat achter bij de verwachtingen. Er was zeer intensieve aandacht van het management voor nodig om dit te verbeteren. Medewerkers twijfelen vaak over voorgespiegelde verbeteringen, omdat er al verschillende verbetertrajecten zijn geweest. Maar zodra de eerste verbeteringen zichtbaar worden slaat deze twijfel om in enthousiasme. Als de resultaten dan aanhouden wil men uiteindelijk nooit meer terug naar de oude situatie. Bij verbetertrajecten komen naast complexe veranderingen vaak ook een aantal zeer eenvoudige verbeteringen naar boven, die in zeer korte tijd kunnen worden doorgevoerd. Als er bijvoorbeeld backups fout lopen, terwijl de betreffende server al lang is uitgezet, kan dat snel worden verholpen door de server uit het backup-schema te halen. Dergelijke snelle resultaten motiveren de deelnemers om zich voor het project te blijven inzetten. Het (lijn-)management is in dit soort trajecten cruciaal: van topmanagement tot teamleiders. Zolang het management naar de metingen kijkt en om verbetervoorstellen vraagt, wordt het resultaat gehaald. Zodra de aandacht verslapt, valt iedereen al snel terug in het oude patroon. Daarom moeten de metin-

gen continu doorgaan en bijvoorbeeld worden opgenomen in de maandelijkse reviews van het management.

CONCLUSIE De gegeven voorbeelden tonen aan dat Six Sigma uitstekend geschikt is om ITIL-processen beter en constanter te laten presteren. Zowel de de technieken om variantie op te sporen als de DMAIC-structuur vormen een waardevolle aanvulling op bestaande methoden voor kwaliteitsverbetering. De resultaten laten zien dat doorlooptijd, het aantal defecten en foutkosten door toepassing van Six Sigma tot wel tachtig procent kunnen afnemen. Hierbij moeten wel eerst de ITIL-processen worden geïmplementeerd. Naast het verbeteren van de processen draagt de training en coaching van vakbekwame medewerkers tot Green Belts en Black Belts er toe bij dat er continu nieuw inzicht wordt verkregen in hoe iedereen kan bijdragen aan het gezamenlijk boeken van successen . Green Belts spelen hierin een zeer belangrijke rol, omdat zij met hun kennis in staat zijn de implementatie van verbeteringen in de lijn te waarborgen. Voorwaarden voor een succesvolle Six Sigma-implementatie en uitvoering van projecten zijn dat alle lagen van het (lijn)-management voldoende betrokken zijn bij het verbeterproject. Ir. Ronald van Gelder is Programma Manager bij Atos Origin. Hij is verantwoordelijk voor diverse verandertrajecten, waarbij het vergroten van de efficiency en effectiviteit van processen een grote rol speelt. Ing. Theo Tops (MTL) is Senior Consultant en Six Sigma Master Black Belt bij de George Group. Hij is gespecialiseerd in het trainen en coachen van de Lean Six Sigmamethodiek voor diverse organisaties en bedrijven.



BRONNEN • Basu, R. en N. Wright (2003). Quality beyond Six Sigma. Burlington: Butterworth-Heinemann. • Boer, S. den, e.a., (2006). Six Sigma for IT-management. Zaltbommel: Van Haren Publishing. • Brue, G. (2005). Six Sigma for Managers. New York: Mc Graw-Hill. • Chowdhury, S. (2001). De Kracht van Six Sigma. Upper Sadle River: Prentice Hall. • George, M. L. (2002). Lean Six Sigma. Combining Six Sigma Quality with speed. New York: McGraw-Hill. • George, M. L. (2003). Lean Six Sigma for Service. New York: Mc Graw-Hill. • Harry, M. en R. Schroeder (2000). Six Sigma: the breakthrough management strategy revolutionizing the World’s Top Corporations. New York: Currency Doubleday. • Pande, P. en L. Holpp (2002). Werken met Six Sigma. Deventer: Kluwer. • Pande, S., R. P. Neuman en R. R. Cavanagh (2000). The Six Sigma way. New York: Mc Graw-Hill. • Pyzdek, T. (2001). The Six Sigma Handbook. New York: Mc Graw-Hill. • Smith, D., J. Blakeslee en R. Koonce (2002) Strategic Six Sigma. Hoboken: Wiley. • Snee, R. D. en R. W. Hoerl (2003). Leading Six Sigma. Upper Sadle River: Prentice Hall.

407

6


408


6.5 Six Sigma toepassen in de IT

Recommend Documents