VIVES - graduaat systeem- en netwerkbeheer - IT essentials

IT-Essentials

Studiegebied Handelswetenschappen en bedrijfskunde

Opleiding systeem- en netwerkbeheer

Legende van de gebruikte iconen

Legende van de gebruikte iconen

Voortgangstoets

Toledo

Opdracht/Oefening

7.4.1

7.11

7.14.2

1 Cursusbeschrijving

1.1 Doelstellingen van deze cursus

Deze cursus is ontworpen als een inleiding tot ITIL 4 en stelt de studenten in staat om te kijken naar IT service management door middel van een end-to-end operationeel model voor creatie, levering en voortdurende verbetering van technologie-gebaseerde producten en diensten.

Het doel is om studenten kennis te laten maken met het beheer van moderne IT -ondersteunde diensten, om hen inzicht te geven in de gemeenschappelijke taal en de belangrijkste concepten, e n hen te laten zien hoe zij hun werk en het werk van hun organisatie kunnen verbeteren met behulp van ITIL 4-richtlijnen. Verder zal deze cursus de student inzicht geven in het ITIL 4 service management framework en hoe het zich heeft ontwikkeld om moderne technologieën en manieren van werken te adopteren.

1.2 Manier van werken

• Er is een presentatie om de theorie uit te leggen.

• Er zullen oefeningen zijn om deze theorie in praktijk te brengen.

• Er zal ruimte zijn voor discussie, om de theorie beter te begrijpen.

1.3 Tijdschema

Deze cursus bestaat uit 9 lesmomenten van telkens 4 uur. Er is een pauze na een blok van 2 uur.

Opmerking: Het kan heel nuttig zijn om thuis in de cursus te lezen die u verkregen he eft.

Afhankelijk van het oordeel van uw docent, kan het zijn dat er wat huiswerk wordt meegegeven aan het einde van een lesmoment.

De docent zal u vertellen wanneer u een oefening moet maken.

Het examen zal na deze 9 lesmomenten plaatsvinden, de datum vindt u terug op het lesrooster.

1.4 Vereiste competenties (op het niveau van ITIL Foundation)

Aan het einde van de cursus zult u in staat zijn om:

• De belangrijkste concepten van ITIL service management te begrijpen.

• Begrijpen hoe ITIL-richtlijnen een organisatie kunnen helpen bij het invoeren en aanpassen van ITIL service management.

• De vier dimensies van ITIL servicemanagement begrijpen.

• Het doel en de componenten van het ITIL servicewaarderingssysteem begrijpen, en de activiteiten van de waardeketen, en hoe ze onderling verbonden zijn.

• De sleutelconcepten van continue verbetering begrijpen.

• De verschillende ITIL praktijken leren en hoe die bijdragen aan de waardeketenactiviteiten.

1.5 Verklaring van de Bloom -niveaus

Niveau 1: Kennis

“ Herinneren” / “Definiëren” duidt op basisherinnering en -herkenning op niveau 1.

Niveau 2: Begrip

“Beschrijven” / “Uitleggen” geeft het begripsniveau 2 aan.

2 Service management

2.1 Inleiding

Definitie Dienst

Een middel om co-creatie van waarde mogelijk te maken door resultaten te faciliteren die klanten willen bereiken, zonder dat de klant specifieke kosten en risico's hoeft te beheren.

Volgens de Wereldhandelsorganisatie vormen diensten de grootste en meest dynamische component van zowel ontwikkelde als zich ontwikkelende economieën. Diensten zijn de belangrijkste manier waarop organisaties waarde creëren voor zichzelf en hun klanten. Bijna alle diensten zijn tegenwoordig IT-gebaseerd, wat betekent dat er enorme voordelen zijn voor organisaties bij het creëren, uitbreiden en verbeteren van hun IT service management capaciteiten.

Technologie ontwikkelt zich vandaag de dag sneller dan ooit tevoren. Ontwikkelingen zoals cloud computing, infrastructure as a service (IaaS), machine learning, en blockchain hebben nieuwe mogelijkheden geopend voor waarde creatie, en hebben ertoe geleid dat IT een belangrijke business driver en bron van concurrentie voordeel. Op zijn beurt positioneert dit IT service management als een belangrijke strategische capability.

Om ervoor te zorgen dat ze relevant en succesvol blijven, beginnen veel organisaties aan grote transformatieprogramma's om deze kansen te benutten. Hoewel deze transformaties vaak 'digitaal' worden genoemd, gaat het om meer dan technologie. Ze zijn een evolutie in de manier waarop organisaties, zodat ze kunnen floreren in het licht van aanzienlijke en voortdurende veranderingen.

Organisaties moeten de behoefte aan stabiliteit en voorspelbaarheid in evenwicht brengen met de toenemende behoefte aan operationele wendbaarheid en verhoogde snelheid. Informatie en technologie worden steeds meer geïntegreerd met andere organisatorische capaciteiten, silo's vallen weg en er wordt meer gebruikt. Service management verandert om deze organisatorische verschuiving aan te pakken en te ondersteunen en ervoor te zorgen dat de kansen die nieuwe technologieën en nieuwe manieren van werken bieden, optimaal worden benut. Service management evolueert, en zo ook ITIL, de meest verspreide leidraad voor IT service management (ITSM) in de wereld.

Definitie Dienstenbeheer

Een geheel van gespecialiseerde organisatorische mogelijkheden om waarde voor klanten te creëren in de vorm van diensten.

Een gedeeld begrip van de belangrijkste concepten en terminologie van ITIL door organisaties en individuen is van cruciaal belang voor het effectief gebruik van deze richtlijn om echte uitdagingen op het gebied van servicemanagement aan te gaan.

Daartoe worden in dit hoofdstuk enkele van de belangrijkste concepten van servicemanagement uitgelegd,inclusief:

- de aard van waarde en waarde co-creatie

- organisaties, dienstverleners, afnemers van diensten, en andere belanghebbenden

- producten en diensten

- dienstverleningsrelaties

- waarde: uitkomsten, kosten en risico's.

Deze concepten zijn van toepassing op alle organisaties en diensten, ongeacht hun aard en onderliggende technologie. Maar het eerste dat moet worden geschetst is de meest fundamentele vraag van allemaal: Wat is service management?

Het ontwikkelen van de gespecialiseerde organisatorische capaciteiten die in de definitie worden genoemd, vereist een begrip van:

- de aard van waarde

- de aard en het bereik van de betrokken belanghebbenden

- hoe waarde creatie mogelijk wordt gemaakt door diensten

Het doel van een organisatie is waarde te creëren voor belanghebbenden.

De term "waarde" wordt regelmatig gebruikt in servicemanagement, en het i s een belangrijk aandachtspunt van ITIL 4; het moet daarom duidelijk worden gedefinieerd.

Definitie Waarde

De waargenomen voordelen, het nut en het belang van iets.

Inherent aan deze definitie is het inzicht dat waarde afhankelijk is van de perceptie van de stakeholders, of zij nu de klanten of consumenten van een dienst zijn, of deel uitmaken van de dienstverlenende organisatie(s) zijn. Waarde kan subjectief zijn.

Er was een tijd dat organisaties die zichzelf "dienstverleners" noemden, hun rol zagen als he t leveren van waarde aan hun klanten op dezelfde manier als een pakket wordt afgeleverd aan een gebouw door een bezorgbedrijf. Deze visie behandelde de relatie tussen de dienstverlener en de dienstafnemer als eenrichtingsverkeer en afstandelijk. De dienstverlener levert de dienst en de consument ontvangt de waarde; de consument speelt geen rol in het creëren van waarde voor zichzelf. Dit houdt geen rekening met de zeer complexe en onderling afhankelijke dienstverleningsrelaties die in werkelijkheid bestaan.

Organisaties erkennen steeds meer dat waarde mede wordt gecreëerd door een actieve samenwerking tussen aanbieders en consumenten, alsmede andere organisaties die deel uitmaken van de relevante relaties. Aanbieders moeten niet langer geïsoleerd proberen te bepalen wat van waarde zal zijn voor hun klanten en gebruikers, maar moeten actief streven naar wederzijds voordelige, interactieve relaties met hun consumenten op te bouwen en hen in staat te stellen creatief mee te werken aan de waardeketen v an de dienst. De stakeholders in de waardeketen van de dienst dragen bij tot de definitie van de vereisten, het ontwerp van dienstenoplossingen en zelfs aan de creatie en/of levering van de dienst zelf.

Later in dit hoofdstuk zal dieper worden ingegaan op waarde. Maar voor het zover is, is het belangrijk om een overzicht te geven van de verschillende stakeholders die betrokken zijn bij waarde creatie en de taal die in ITIL gebruikt wordt om hen te beschrijven.

Om te beoordelen of een dienst of een dienstenaanbod de door de consumenten gewenste resultaten zal bevorderen en dus waarde voor hen creëert, moeten het algemene nut en de garantie van de dienst worden beoordeeld.

Definitie Nut

De functionaliteit die een product of dienst biedt om in een bepaalde behoefte te voorzien. Nut kan worden samengevat als "wat de dienst doet" en kan worden gebruikt om te bepalen of een dienst “geschikt is voor zijn doel”. Om nut te hebben, moet een dienst ofwel de prestaties van de consument ondersteunen, ofwel beperkingen van de consument wegnemen. Veel diensten doen beide.

Definitie Garantie

De verzekering dat een product of dienst aan de overeengekomen eisen zal voldoen. Garantie kan worden samengevat als "hoe de dienst presteert" en kan worden gebruikt om te bepalen of een dienst geschikt is voor gebruik'. Garantie heeft vaak betrekking op serviceniveaus die zijn afgestemd op de behoeften van consumenten. Dit kan gebaseerd zijn op een formele overeenkomst, maar het kan ook een marketingboodschap of merkimago. Garantie heeft typisch betrekking op gebieden als de beschikbaarheid van de dienst, de capaciteit, het niveau van veiligheid en continuïteit. Van een dienst kan worden gezegd dat hij een aanvaardbare zekerheid, of "garantie", als aan alle gedefinieerde en overeengekomen voorwaarden is voldaan.

Bij de beoordeling van een dienst moet rekening worden gehouden met het effect van kosten en risico's op nut en garantie om een volledig beeld te krijgen van de levensvatbaarheid van een dienst. Zowel nut als garantie zijn essentieel voor een dienst om de gewenste resultaten te vergemakkelijken en dus waarde te helpen creëren. Een pretpark kan bijvoorbeeld vele spannende attracties aanbieden die zijn ontworpen om parkbezoekers spannende ervaringen te bezorgen (nut), maar als een aanzienlijk aantal van de attracties vaak niet beschikbaar zijn vanwege mechanische problemen, voldoet het park niet aan de garantie (het is niet geschikt voor gebruik) en zullen de consumenten hun verwachte waarde niet ontvangen. Evenzo, indien de attracties altijd in werking zijn tijdens de geadverteerde uren, maar zij hebben niet de kenmerken die de door de bezoekers verwachte opwinding, wordt het nut niet vervuld, ook al is de garantie voldoende. Ook dan zouden de consumenten niet de verwachte waarde ontvangen.

Het bereiken van gewenste resultaten vergt middelen (en dus kosten) en gaat vaak gepaard met risico's. Dienstverleners helpen hun consumenten om resultaten te bereiken, en nemen daarbij een deel van de bijbehorende risico's en kosten op zich. Aan de andere kant kunnen dienstverleningsrelaties nieuwe risico's en kosten met zich meebrengen, en in sommige gevallen kunnen zij een aantal van de beoogde uitkomsten negatief beïnvloeden, terwijl andere worden ondersteund.

Dienstverleningsrelaties worden alleen als waardevol ervaren wanneer zij meer positieve dan negatieve effecten hebben

Als dienstverlener produceert een organisatie outputs die haar consumenten helpen om bepaalde resultaten te bereiken.

Definitie Output

Een tastbaar of ontastbaar resultaat van een activiteit.

Definitie Resultaat

Een resultaat voor een belanghebbende dat mogelijk wordt gemaakt door een of meer outputs.

Het is belangrijk duidelijk te zijn over het verschil tussen outputs en uitkomsten. Bijvoo rbeeld, een output van een trouwreportage kan een album zijn waarin geselecteerde foto's kunstig zijn gerangschikt. Het resultaat van de dienst is echter het bewaren van herinneringen en de mogelijkheid voor het bruidspaar van het bruidspaar en hun familie en vrienden om die herinneringen gemakkelijk te kunnen ophalen door het album te bekijken.

Afhankelijk van de relatie tussen de aanbieder en de consument, kan het moeilijk zijn voor de aanbieder om volledig te begrijpen welke resultaten de consument wil bereiken. In sommige gevallen samen om de gewenste uitkomsten te definiëren. Bijvoorbeeld, business relationship managers (BRM's) van interne IT- of HR-afdelingen kunnen regelmatig met klanten praten en hun behoeften en verwachtingen. In andere gevallen articuleren de consumenten hun verwachtingen heel duidelijk, en de aanbieder verwacht dat zij dit doen, zoals wanneer gestandaardiseerde diensten worden aangeboden aan een brede consumentengroep groep. Dit is de manier waarop mobiele exploitanten, aanbieders van breedbanddiensten en transportbedrijven te werk gaan. Ten slotte voorspellen of creëren sommige dienstverleners zelfs de vraag naar bepaalde uitkomsten, waardoor zij een doelgroep voor hun diensten maken. Dit kan gebeuren met innovatieve diensten die inspelen op behoeften waarvan consumenten zich voordien niet eens bewust van waren. Voorbeelden hiervan zijn sociale netwerken of smart home oplossingen.

Definitie Kosten

Het bedrag dat aan een bepaalde activiteit of een bepaald middel wordt besteed.

Vanuit het oogpunt van de afnemer van de dienst zijn er twee soorten kosten gemoeid met relaties:

- kosten die door de dienst bij de consument worden weggenomen (een deel van de waarde propositie). Dit kan kosten van personeel, technologie en andere middelen omvat ten, die de consument niet hoeft te verstrekken

- kosten die door de dienst aan de consument worden opgelegd (de kosten van dienstenconsumptie). De totale kosten van het verbruik van een dienst omvatten de prijs die door de dienstverlener in rekening wordt gebracht (indien van toepassing) plus andere kosten, zoals opleiding van personeel, kosten van netwerkgebruik, aankoop, enz. Sommige consumenten omschrijven dit als wat zij moeten "investeren" om de dienst te consumeren.

Beide soorten kosten worden in aanmerking genomen wanneer de consument de waarde beoordeelt die hij van de dienst zal ervaren. Om ervoor te zorgen dat de juiste beslissingen worden genomen over de dienstenrelatie, is het belangrijk dat beide soorten kosten volledig worden begrepen.

Vanuit het oogpunt van de dienstverlener is een volledig en correct begrip van de kosten van de dienstverlening essentieel. Aanbieders moeten ervoor zorgen dat de diensten worden geleverd binnen de budgettaire beperkingen en voldoen aan de financiële verwachtingen van de organisatie.

Definitie Risico

Een mogelijke gebeurtenis die schade of verlies kan veroorzaken, of het moeilijker kan maken om doelstellingen te bereiken. Kan ook worden gedefinieerd als onzekerheid van resultaat, en kan worden gebruikt in de context van het meten van de waarschijnlijkheid van zowel positieve als negatieve uitkomsten.

Net als bij de kosten zijn er twee soorten risico's die van belang zijn voor de afnemers van diensten - risico's die door de dienst aan een consument worden ontnome n (deel van de waarde propositie). Deze kunnen het falen van de server hardware zijn van de consument of een gebrek aan beschikbaarheid van het personeel. In sommige gevallen kan een dienst alleen de risico's van een consument verminderen, maar de consument kan bepalen dat deze vermindering voldoende is om het waarde voorstel te ondersteunen

- risico's die een consument door de dienst worden opgelegd (risico's van dienstenconsumptie). Een voorbeeld hiervan zou kunnen zijn dat een dienstverlener zijn activiteiten staakt of te maken krijgt met een inbreuk op de beveiliging

Het is de taak van de aanbieder om het risiconiveau namens de consument in detail te beheren.

Dit moet gebeuren op basis van een evenwicht tussen wat voor de consument en wat voor de aanbieder het belangrijkst is. De consument draagt bij tot de vermindering van het risico door:

- actief deel te nemen aan de vaststelling van de eisen van de dienst en de verduidelijking van de vereiste resultaten

- duidelijk te communiceren over de kritische succesfactoren (KSF's) en de beperkingen die van toepassing zijn op de dienst

- ervoor te zorgen dat de dienstverlener toegang heeft tot de nodige middelen van de consument tijdens de gehele dienstverleningsrelatie.

2.2 Belanghebbenden

In dienstenbeheer zijn er veel verschillende soorten belanghebbenden, die elk moeten worden begrepen in de context van de creatie van waarde in de vorm van diensten. Ten eerste, de term “organisatie” gedefinieerd worden.

Definitie Organisatie

Een persoon of een groep mensen die zijn eigen functies heeft met verantwoordelijkheden, bevoegdheden, en relaties om haar doelstellingen te bereiken.

Organisaties variëren in omvang en complexiteit, en in hun relatie tot rechtspersonen, van een enkele persoon of een team tot een complex netwerk van j uridische entiteiten die verenigd zijn door gemeenschappelijke doelstellingen, relaties, en autoriteiten.

Naarmate samenlevingen en economieën zich ontwikkelen, worden de relaties tussen en binnen organisaties complexer. Elke organisatie is voor haar werki ng en ontwikkeling afhankelijk van anderen. Organisaties kunnen verschillende rollen vervullen, afhankelijk van het perspectief dat wordt besproken. Bijvoorbeeld, een organisatie die avontuurlijke vakanties coördineert, kan de rol van dienstverlener aan een reisbureau vervullen wanneer zij een vakantie verkoopt, en tegelijkertijd de rol van consument van diensten vervullen wanneer zij luchthaventransfers aankopen om aan hun vakantieaanbod toe te voegen.

Bij de levering van diensten neemt een organisatie de rol van dienstverlener op zich. De leverancier kan extern zijn aan de organisatie van de consument, of zij kunnen beiden deel uitmaken van dezelfde organisatie.

In de meest traditionele opvattingen over ITSM wordt de providerorganisatie gezien als de ITafdeling van een bedrijf, en de andere afdelingen of andere functionele eenheden in het bedrijf worden gezien als de consumenten. Dit is echter slechts een zeer eenvoudig provider -consumer model. Een aanbieder zou diensten op de open markt verkopen aan ander e bedrijven, aan individuele consumenten, of hij kan deel uitmaken van een dienstenalliantie, die samenwerkt om diensten te verlenen aan consumentenorganisaties. Het belangrijkste is dat de organisatie in de rol van aanbieder een duidelijk inzicht heeft in wie zijn consumenten in een bepaalde situatie zijn en wie de andere stakeholders zijn in de bijbehorende dienstverleningsrelaties.

Wanneer een organisatie diensten ontvangt, neemt zij de rol aan van afnemer van diensten.

Service consumer is een generieke rol die wordt gebruikt om de definitie en beschrijving van de structuur van dienstrelaties te vereenvoudigen. In de praktijk zijn er meer specifieke rollen betrokken bij serviceconsumptie, zoals zoals klanten, gebruikers en sponsors. Deze rollen kunnen gescheiden of gecombineerd zijn.

Definitie Klant

De rol die de eisen aan een service definieert en verantwoordelijkheid neemt voor de uitkomsten van serviceconsumptie.

Definitie Gebruiker

De rol die services gebruikt.

Definitie Sponsor

De rol die budget autoriseert voor serviceconsumptie.

Bijvoorbeeld, als een bedrijf mobiele telefoondiensten voor zijn werknemers wil afnemen van een draadloze provider (de service provider), kunnen de verschillende rollen van de consument als volgt worden verdeeld:

- De chief information officer (CIO) en de belangrijkste leden van het communicatieteam vervullen de rol van klant wanneer zij de mobiele communicatiebehoeften van de werknemers van het bedrijf analyseren van de werknemers van het bedrijf, onderhandelen over het contract met de draadloze provider en toezicht houden op de prestaties van de provider ten opzichte van de gecontracteerde vereisten.

- De chief financial officer (CFO) vervult de rol van de sponsor wanneer hij de voorgestelde dienstverleningsovereenkomst en de kosten van het contract goedkeurt zoals onderhandeld.

- De werknemers (waaronder de CIO, de CFO en de leden van het communicatieteam) vervullen de rol van gebruikers wanneer zij de mobiele telefoondiensten bestellen, ontvangen en gebruiken volgens het overeengekomen contract.

In een ander voorbeeld treedt een individuele particuliere consument van dezelfde draadloze drager (een persoon die gebruik maakt van het mobiele netwerk) tegelijkertijd optreden als gebruiker, klant en sponsor.

Het is belangrijk deze rollen in dienstverleningsrelaties vast te stellen om te zorgen voor doeltreffende communicatie en stakeholdermanagement. Elk van deze rollen kan verschillende, en soms zelfs tegenstrijdige, verwachtingen hebben van diensten, en verschillende definities van waarde.

Een belangrijk aandachtspunt van service management, en van ITIL, is de manier waarop organisaties waarde co-creëren met hun consumenten door middel van servicerelaties. Naast de rollen van consument en leverancier, zijn er gewoonlijk vele andere belanghebbenden die belangrijk zijn voor waarde creatie. Voorbeelden zijn individuele werknemers van de dienstverlenende organisatie, partners en leveranciers, investeerders en aandeelhouders, overheidsorganisaties zoals regelgevers, en maatschappelijke groeperingen. Voor het succes, en zelfs het voortbestaan van een organisatie, is het belangrijk dat de relaties met alle belangrijke stakeholders worden begrepen en beheerd. Als stakeholders ontevreden zijn over wat de organisatie doet of hoe zij dat doet, kan de de relaties van de aanbieder met zijn consumenten in gevaar komen.

Producten en diensten creëren op een aantal manieren waarde voor stakeholders. Sommige zijn heel direct, zoals het genereren van inkomsten, terwijl andere meer indirect zijn, zoals de ervaring van werknemers.

2.3 Diensten

De diensten die een organisatie levert, zijn gebaseerd op een of meer van haar producten. Organisaties bezitten of hebben toegang tot een verscheidenheid van middelen, met inbegrip van mensen, informatie en technologie, waarde stromen en processen, en partners en leveranciers. Producten zijn configuraties van deze middelen, gecreëerd door de organisatie, die waardevol kunnen zijn voor haar klanten.

Definitie Dienst

Een middel om co-creatie van waarde mogelijk te maken door resultaten te faciliteren die klanten willen bereiken, zonder dat de klant specifieke kosten en risico's hoeft te beheren.

Definitie Product

Een configuratie van de middelen van een organisatie, ontworpen om waarde te bieden aan een consument.

Elk product dat een organisatie aanbiedt, wordt gecreëerd met een aantal doelgroepen van consumenten in gedachten, en de producten worden op maat gemaakt om deze groepen aan te spreken en in hun behoeften te voorzien. Een product is niet exclusief voor één co nsumentengroep, en kan worden gebruikt om in de behoeften van verschillende groepen te voorzien. Een softwaredienst kan bijvoorbeeld worden aangeboden als een "lite" -versie, voor individuele gebruikers, of als een meer uitgebreide bedrijfsversie.

Producten zijn doorgaans complex en zijn niet volledig zichtbaar voor de consument. Het deel van een product dat de consument daadwerkelijk ziet, vertegenwoordigt niet altijd alle componenten waaruit het product bestaat en de levering ervan ondersteunen. O rganisaties bepalen welke productcomponenten hun consumenten zien, en stemmen ze af op hun consumentendoelgroepen.

Dienstverleners presenteren hun diensten aan consumenten in de vorm van dienstenaanbiedingen, die een of meer diensten beschrijven op basis van een of meer producten.

Definitie Dienstenaanbod

Een formele beschrijving van een of meer diensten, bedoeld om te voorzien in de behoeften van een consumentengroep. Een dienstenaanbod kan goederen, toegang tot middelen en dienstenacties omvatten.

Het dienstenaanbod kan het volgende omvatten

- goederen die aan een consument moeten worden geleverd (bijvoorbeeld een mobiele telefoon). Goederen worden verondersteld worden overgedragen van de aanbieder aan de consument, waarbij de consument de verantwoordelijkheid voor het toekomstige gebruik ervan overneemt

- toegang tot middelen die onder overeengekomen voorwaarden aan een consument wordt verleend of in licentie wordt gegeven (bijvoorbeeld tot het mobiele netwerk, of tot de netwerkopslag). De middelen blijven onder de provider en zijn alleen toegankelijk voor de consument gedurende de overeengekomen dienst verbruiksperiode - serviceacties die worden uitgevoerd om aan de behoeften van een consument te voldoen (bijvoorbeeld gebruikersondersteuning). Deze acties worden uitgevoerd door de dienstverlener volgens de overeenkomst met de consument.

Diensten worden aangeboden aan consumentendoelgroepen, en die groepen kunnen zowel intern als extern zijn van de dienstverlenende organisatie. Op basis van hetzelfde product kunne n verschillende aanbiedingen worden gecreëerd, waardoor het op meerdere manieren kan worden gebruikt om aan de behoeften van verschillende consumentengroepen te voldoen. Voor Bijvoorbeeld, een softwaredienst kan worden aangeboden als een beperkte gratis ve rsie, of als een uitgebreide betaalde versie, op basis van één product van de dienstverlener.

Om waarde te creëren, moet een organisatie meer doen dan alleen een dienst verlenen. Zij moet ook samenwerken met de consumenten in dienstverleningsrelaties.

Servicerelaties worden tot stand gebracht tussen twee of meer organisaties om waarde te co -creëren.

In een dienstverleningsrelatie nemen organisaties de rol van dienstverlener of consumenten. De twee rollen sluiten elkaar niet uit, en organisaties bieden gewoonlijk aan en consumeren zowel een aantal diensten op een gegeven moment.

Definitie Servicerelatie

Een samenwerking tussen een serviceprovider en een serviceafnemer. Servicerelaties omvatten dienstverlening, dienstenconsumptie en dienstenrelatiebeheer.

Definitie Dienstverlening

Activiteiten die door een organisatie worden verricht om diensten te verlenen. Dienstverlening omvat:

- beheer van de middelen van de dienstverlener, geconfigureerd om de dienst te leveren

- het verzekeren van toegang tot deze middelen voor gebruikers

- uitvoering van de overeengekomen dienstverleningsacties

- beheer van het dienstverleningsniveau en voortdurende verbetering.

Dienstverlening kan ook de levering van goederen omvatten.

Definitie Dienstenconsumptie

Activiteiten die door een organisatie worden verricht om diensten te consumeren.

Dienstenconsumptie omvat:

- beheer van de middelen van de consument die nodig zijn om de dienst te gebruiken

- dienstacties uitgevoerd door gebruikers, met inbegrip van het gebruik van de middelen van de leverancier, en het aanvragen van dienstenacties die moeten worden uitgevoerd.

Het verbruik van diensten kan ook het ontvangen (verwerven) van goederen omvatten.

Wanneer diensten door de dienstverlener worden geleverd, creëert hij nieuwe hulpbronnen voor de afnemers van de dienst, of hun bestaande wijzigen. Bijvoorbeeld:

- een opleidingsdienst verbetert de vaardigheden van de werknemers van de consument

- een breedbanddienst stelt de computers van de consument in staat te communiceren

- een autoverhuurdienst stelt het personeel van de consument in staat klanten te bezoeken

- een dienst voor softwareontwikkeling creëert een nieuwe toepassing voor de serviceconsument.

De serviceconsument kan zijn nieuwe of gewijzigde middelen gebruiken om zijn eigen pr oducten te creëren om tegemoet te komen aan de behoeften van een andere consumentendoelgroep, en wordt zo een dienstverlener.

3 ITIL en ITIL-richtlijnen

3.1 ITIL

ITIL leidt de ITSM-industrie al meer dan 30 jaar met richtlijnen, training en certificatieprogramma's.

ITIL 4 brengt ITIL bij de tijd door veel van de gevestigde ITSM -praktijken opnieuw vorm te geven in de bredere context van klantervaring, waardestromen en digitale transformatie, evenals het omarmen van nieuwe manieren van werken, zoals Lean, Agile, en DevOps.

ITIL 4 biedt organisaties de leidraad die ze nodig hebben om nieuwe uitdagingen op het gebied van servicemanagement aan te gaan en het potentieel van moderne technologie te benutten. Het is ontworpen om een flexibel, gecoördineerd en gecoördineerd en geïntegreerd systeem voor effectief bestuur en beheer van IT-ondersteunde diensten.

3.2 De ITIL-richtlijnen

De ITIL-richtlijnen kunnen worden gebruikt om de beslissingen en acties van een organisatie te sturen en te zorgen voor een gedeeld begrip en een gemeenschappelijke benadering van servicemanagement in de hele organisatie. De ITIL richtlijnen vormen de basis voor de cultuur en het gedrag van een organisatie, van strategische besluitvorming tot dagelijkse werkzaamheden.

Een leidend principe is een aanbeveling die een organisatie in alle omstandigheden leidt, ongeacht veranderingen in de doelstellingen, strategieën, soort werk of managementstructuur. Een leidend principe is universeel en duurzaam.

De leidende principes die hier worden gedefinieerd, belichamen de kernboodschappen van ITIL en van servicemanagement in het algemeen, en ondersteunen succesvolle acties en goede beslissingen van alle soorten en op alle niveaus. Ze kunnen worden gebruikt om organisaties te begeleiden in hun werk als ze een service management aanpak aannemen en ITIL aanpassen aan hun eigen specifieke behoeften en omstandigheden. De leidende principes stimuleren en ondersteunen organisaties in voortdurende verbetering op alle niveaus.

Deze principes worden ook weerspiegeld in vele andere raamwerken, methoden, normen, filosofieën en/of kennisinstellingen, zoals Lean, Agile, DevOps, en COBIT. Dit stelt organisaties in staat om het gebruik van meerdere methoden effectief te integreren in een totaalaanpak van servicemanagement.

De leidende principes zijn van toepassing op praktisch elk initiatief en op alle relaties met groepen belanghebbenden. Bijvoorbeeld, het eerste principe, focus op waarde, kan (en zou moeten) worden toegepast niet alleen op afnemers van diensten, maar op alle relevante belanghebbenden en hun respectieve definities van waarde.

3.2.1 Focus op waarde

Alle activiteiten die door de organisatie worden uitgevoerd zouden, direct of indirect, terug moeten leiden tot waarde voor zichzelf, haar klanten, en andere stakeholders.

Dit deel is vooral gericht op het creëren van waarde voor de afnemers van diensten. Nochtans, draagt een dienst ook bij aan waarde voor de organisatie en andere stakeholders. Deze waarde kan verschillende vormen aannemen zoals inkomsten, klantenbinding, lagere kosten, of groeimogelijkheden. De volgende aanbevelingen kunnen worden aangepast aan de verschillende groepen stakeholders en de waarde die voor hen door de organisatie wordt gecreëerd.

Wie is de serviceconsument?

Bij het focussen op waarde, is de eerste stap te weten wie er wordt bediend. In elke situatie moet de dienstverlener dus bepalen wie de afnemer van de dienst is en wie de belangrijkste stakeholders zijn (bijvoorbeeld klanten, gebruikers, of sponsors). Daarbij moet de dienstverlener nagaan wie waarde zal ontvangen van wat wordt geleverd of verbeterd.

Het waarde perspectief van de consument

Vervolgens moet de dienstverlener begrijpen wat werkelijk van waarde is voor de afnemer van de dienst. De dienstverlener moet weten:

- waarom de consument de diensten gebruikt

- wat de diensten hen helpen te doen

- hoe de diensten hen helpen hun doelstellingen te bereiken

- de rol van de kosten/financiële gevolgen voor de dienstverlenende consument

- welke risico's de afnemer van de dienst loopt.

Waarde kan vele vormen aannemen, zoals verhoogde productiviteit, verminderde negatieve impact, verlaagde kosten, de mogelijkheid om nieuwe markten aan te boren, of een betere concurrentiepositie. Waarde voor de consument:

- wordt gedefinieerd door hun eigen behoeften

- wordt bereikt door de ondersteuning van de beoogde resultaten en de optimalisatie van de kosten en risico's van de consument

- verandert in de tijd en in verschillende omstandigheden.

De ervaring van de klant

Een belangrijk element van waarde is de ervaring die consumenten van diensten hebben wanneer zij interageren met de dienst en de dienstverlener. Dit wordt vaak klantervaring (CX) of gebruikerservaring (UX) genoemd, afhankelijk van de gehanteerde definities, en deze moet actief worden beheerd.

CX kan worden gedefinieerd als het geheel van interacties die een klant heeft met een organisatie en haar producten. Deze ervaring kan bepalen hoe de klant denkt over de organisatie en haar producten en diensten.

CX is zowel objectief als subjectief. Bijvoorbeeld, w anneer een klant een product bestelt en ontvangt voor de beloofde prijs en binnen de beloofde levertijd, is het succes van dit aspect van hun ervaring objectief meetbaar. Aan de andere kant, als ze de stijl of de lay -out van de website waar ze bestellen niet mooi vinden, is dit subjectief. Een andere klant vindt het ontwerp misschien wel heel mooi.

Toepassing van het beginsel

Om dit beginsel met succes toe te passen, kunt u het volgende advies in overweging nemen

- Weet hoe de afnemers van de dienst elke dienst gebruiken. Begrijp hun verwachte resultaten, hoe elke dienst daartoe bijdraagt, en hoe de afnemers van de dienst de dienstverlener beschouwen. Verzamel doorlopend feedback over de waarde, niet alleen aan het begin van de service relatie.

- Stimuleer een focus op waarde bij al het personeel Leer personeel om zich bewust te zijn van wie hun klanten zijn en CX te begrijpen.

- Focus op waarde tijdens normale operationele activiteiten, maar ook tijdens verbeterinitiatieven. De organisatie als geheel draagt bij aan de waarde die de klant ervaart, en dus moet iedereen binnen de organisatie de waarde die hij creëert maximaliseren. Het creëren van waarde moet niet alleen worden overgelaten aan de mensen die werken aan spannende projecten en nieuwe dingen.

- Neem focus op waarde op in elke stap van elk verbeterinitiatief. Iedereen die betrokken is bij een verbeterinitiatief moet begrijpen welke resultaten het initiatief probeert te bevorderen, hoe de waarde gemeten zal worden, en hoe zij moeten bijdragen aan de co -creatie van die waarde.

3.2.2

Start waar je bent

Bij het proces om oude, onsuccesvolle methoden of diensten te elimineren en iets beters te creëren, kan de verleiding groot zijn om te verwijderen wat in het verleden is gedaan en iets geheel nieuws te

bouwen. Dit is zelden nodig, of een verstandige beslissing. Deze aanpak kan uiterst verkwistend zijn, niet alleen in termen van tijd, maar ook in termen van het verlies van bestaande processen, mensen en hulpmiddelen die van grote waarde zouden kunnen zijn voor de verbeteringsinspanning. Begin niet opnieuw zonder eerst te overwegen wat er al beschikbaar is om als hefboom te gebruiken.

Evalueer waar u bent

Reeds bestaande diensten en methoden moeten direct worden gemeten en/of geobserveerd om goed te begrijpen wat hun huidige staat is en wat daaruit kan worden hergebruikt. Beslissingen over hoe verder te gaan moeten gebaseerd zijn op informatie die zo nauwkeurig mogelijk is. Binnen organisaties is er vaak een discrepantie tussen rapporten en de werkelijkheid. Dit is te wijten aan de moeilijkheid om het meten van bepaalde gegevens, of de onbedoelde vertekening of vervorming van gegevens die via rapporten komen. Het verkrijgen van gegevens uit de bron helpt om veronderstellingen te vermijden die, indien ongegrond gebleken, rampzalig kunnen zijn voor tijdschema's, budgetten en de kwaliteit van de resultaten.

Degenen die een activiteit observeren, moeten niet bang zijn om vragen te stellen die misschien dom lijken. Het kan soms nuttig zijn voor een persoon met weinig of geen voorkennis van de dienst om deel uit te maken van de van de dienst, omdat zij geen vooroordelen hebben over de dienst en dingen kunnen opmerken die degenen die die er meer bij betrokken zijn, zouden missen.

De rol van metingen

Het gebruik van metingen is belangrijk voor dit beginsel. Het moet echte r ondersteunen maar niet vervangen van wat wordt waargenomen, aangezien een te groot vertrouwen in gegevensanalyse en rapportage onbedoeld kan leiden tot vooroordelen en risico's in de besluitvorming kan brengen. Organisaties zouden een verscheidenheid aan technieken moeten overwegen om kennis te ontwikkelen van de omgeving waarin zij werken. Hoewel het waar is dat sommige dingen alleen kunnen worden begrepen door hun effect te meten (bijvoorbeeld natuurverschijnselen zoals de wind), dient rechtstreekse waarneming altijd de voorkeur te hebben. Maar al te vaak worden bestaande gegevens gebruikt zonder rekening te houden met rechtstreeks persoonlijk onderzoek.

Opgemerkt dat de handeling van het meten soms van invloed kan zijn op de resultaten, waardoor deze onnauwkeurig worden. Bijvoorbeeld, als een service desk weet dat het wordt gecontroleerd op de tijd die aan de telefoon wordt besteed, zou het zich te veel kunnen richten op het minimaliseren van de betrokkenheid van de klant (wat leidt tot goede rapporten), in plaats van gebruikers te helpen problemen naar tevredenheid op te lossen. Mensen zijn erg creatief in manieren te vinden om te voldoen aan de maatstaven waartegen ze worden afgemeten. Daarom moeten de metingen zinvol zijn en direct verband houden met het gewenste resultaat.

Het principe toepassen

Een goed begrip van de huidige toestand van diensten en methoden is belangrijk voor de selectie van welke elementen hergebruikt, gewijzigd of verder uitgewerkt moeten worden. Om dit principe met succes toe te passen, kunt u het volgende advies in overweging nemen:

- Kijk zo objectief mogelijk naar wat er bestaat, met de klant of het gewenste resultaat als het uitgangspunt. Zijn de elementen van de huidige toestand geschikt voor het doel en voor het gebruik? Er zijn waarschijnlijk veel elementen van de huidige diensten, praktijken, projecten, en vaardigheden die kunnen gebruikt kunnen worden om de gewenste toekomstige toestand te creëren, op voorwaarde dat de mensen die dit oordeel vellen objectief zijn.

- Wanneer voorbeelden van succesvolle praktijken of diensten in de huidige staat worden gevonden, bepaal dan of en hoe deze kunnen worden gekopieerd of uitgebreid om de gewenste staat te bereiken. In veel, zo niet de meeste gevallen, zal het benutten van wat al bestaat de hoeveelheid werk verminderen die nodig is om van de huidige toestand naar de gewenste toestand te evolueren. De nadruk moet liggen op leren en verbetering, niet alleen replicatie en uitbreiding.

- Pas uw vaardigheden op het gebied van risicobeheer toe. Er zijn risico's verbonden aan het hergebruiken van bestaande praktijken en processen, zoals de voortzetting van oud gedrag dat schadelijk is voor de dienst. Er zijn ook risico's verbonden aan het invoeren van iets nieuws, zoals nieuwe procedures die niet correct worden uitgevoerd. Deze moeten worden overwogen als onderdeel van het besluitvormingsproces proces, en de risico's van het al dan niet doorvoeren van een verandering moeten worden geëvalueerd om te beslissen over de beste handelwijze.

- Erken dat soms niets van de huidige toestand kan worden hergebruikt. Ongeacht hoe wenselijk het kan zijn om te hergebruiken, herbestemmen en recyclen, er zullen momenten zijn dat de enige manier om het gewenste resultaat te bereiken is om helemaal opnieuw te beginnen. Er moet echter worden opgemerkt dat deze situaties zeer zeldzaam zijn.

3.2.3

Iteratieve vooruitgang met feedback

Weersta de verleiding om alles in één keer te doen. Zelfs grote initiatieven moeten worden verwezenlijkt in iteraties. Door het werk te organiseren in kleinere, beheersbare secties die kunnen worden uitgevoerd en tijdig kunnen worden voltooid, zal de focus op elke inspanning scherper zijn en gemakkelijker vol te houden.

Verbeteringsiteraties kunnen opeenvolgend of gelijktijdig zijn, gebaseerd op de eisen van de verbetering en welke middelen beschikbaar zijn. Elke afzonderlijke iteratie moet zowel beheersbaar en beheerd worden, zodat er tijdig tastbare resultaten zijn en er op voortgebouwd kan worden voor verdere verbetering.

Een belangrijk verbeteringsinitiatief of -programma kan worden georganiseerd in verscheidene belangrijke verbeteringen en elk van deze initiatieven kan op zijn beurt uit kleinere verbeteringsinspanningen bestaan. Het algemene initiatief of programma, evenals de iteraties van de onderdelen, moeten voortdurend opnieuw worden geëvalueerd en eventueel worden herzien om rekening te houden met gewijzigde omstandigheden en ervoor te zorgen dat de aandacht voor waarde niet verloren gaat.

Bij deze herevaluatie moet gebruik worden gemaakt van een breed scala van feedbackkanalen enmethoden om ervoor te zorgen dat de status van het initiatief en de voortgang ervan goed worden begrepen.

De rol van feedback

Of men nu werkt aan de verbetering van een dienst, een groep van diensten, een praktijk, een proces, een technische omgeving, of ander service management element, geen enkele verbeteringsiteratie vindt plaats in een vacuüm. Terwijl de iteratie wordt ondernomen, kunnen omstandigheden veranderen en nieuwe prioriteiten ontstaan, en de noodzaak voor de iteratie kan gewijzigd of zelfs geëlimineerd worden. Feedback vragen en gebruiken voor, tijdens en na elke iteratie zal ervoor zorgen dat acties doelgericht en passend zijn, zelfs in veranderende omstandigheden.

Een feedback loop is een term die gewoonlijk wordt gebruikt om te verwijzen naar een situatie waar een deel van de output van een activiteit wordt gebruikt voor nieuwe input. In een goed functionerende organisatie wordt feedback actief verzameld en verwerkt in de waardeketen. Goed geconstrueerde feedbackmechanismen vergemakkelijken het inzicht in:

- de perceptie van de eindgebruiker en de klant over de gecreëerde waarde

- de efficiëntie en effectiviteit van activiteiten in de waardeketen

- de doeltreffendheid van service governance en managementcontrole s

- de interfaces tussen de organisatie en haar partner- en leveranciersnetwerk

- de vraag naar producten en diensten.

Eenmaal ontvangen, kan de feedback worden geanalyseerd om verbetermogelijkheden, risico's en problemen te identificeren.

Iteratie en feedback samen

Werken op een timeboxed, iteratieve manier met feedback loops ingebed in het proces zorgt voor

- meer flexibiliteit

- snellere reacties op de behoeften van de klant en het bedrijf

- de mogelijkheid om fouten eerder te ontdekken en erop te reageren

- een algemene verbetering van de kwaliteit.

Het hebben van passende feedback loops tussen de deelnemers van een activiteit geeft hen een beter inzicht in waar hun werk vandaan komt, waar hun output naartoe gaat, en hoe hun acties en hoe hun acties en outputs de resultaten beïnvloeden, waardoor zij op hun beurt betere beslissingen kunnen nemen.

Toepassing van het beginsel

Om dit principe met succes toe te passen, overweeg dit advies:

- Begrijp het geheel, maar doe iets. Soms is de grootste vijand van iteratief werken, de wens om alles te begrijpen en te verantwoorden. Dit kan leiden tot wat soms wat soms 'analyseverlamming' wordt genoemd, waarbij zoveel tijd wordt besteed aan het analyseren van de situatie dat er nooit iets aan gedaan wordt. Inzicht in het grote geheel is belangrijk, maar dat geldt ook voor vooruitgang boeken.

- Het ecosysteem verandert voortdurend, dus feedback is essentieel . Er vinden voortdurend veranderingen plaats, dus is het heel belangrijk om altijd en op alle niveaus feedback te vragen en te gebruiken.

- Snel betekent niet onvolledig. Alleen omdat een iteratie klein genoeg is om snel gedaan te worden betekent niet dat het niet alle elementen zou moeten bevatten die nodig zijn voor succes. Elke iteratie moet worden geproduceerd in lijn met het concept van het minimum levensvatbaar product. Een minimaal levensvatbaar product is een versie van het eindproduct die de maximale hoeveelheid gevalideerd met de minste inspanning.

3.2.4 Samenwerken en zichtbaarheid bevorderen

Wanneer de juiste mensen in de juiste rollen bij initiatieven worden betrokken, profiteren de inspanningen van een betere buy-in, meer relevantie (omdat er betere informatie beschikbaar is voor de besluitvorming) en een grotere kans op succes op lange termijn.

Creatieve oplossingen, enthousiaste bijdragen en belangrijke perspectieven kunnen worden verkregen uit onverwachte hoek. Daarom is inclusie meestal een beter beleid dan uitsluiting. Samenwerking en coöperatie zijn beter dan geïsoleerd werk, dat vaak wordt aangeduid als "siloactiviteit". Silo’s kunnen ontstaan door het gedrag van individuen en teams, maar ook door structurele oorzaken. Dit gebeurt typisch wanneer functies of business units in een organisatie worden belemmerd of niet in staat zijn om samen te werken, omdat hun processen, systemen, documentatie en communicatie zijn ontworpen om te voldoen aan de behoeften van slechts een specifiek deel van de organisatie. Het toepassen van het leidende principe van holistisch denken en werken kan organisaties helpen barrières tussen werksilo's te doorbreken.

De erkenning van de behoefte aan echte samenwerking is een van de drijvende factoren geweest in de evolutie van wat nu bekend staat als DevOps. Zonder effectieve samenwerking zullen noch Agile, noch Lean, noch enig ander ITSM-raamwerk of -methode werken.

Samenwerken op een manier die leidt tot echte prestaties vereist informatie, begrip, en vertrouwen.

Werk en de resultaten ervan moeten zichtbaar worden gemaakt, verborgen agenda's moeten worden vermeden, en informatie moet zo veel mogelijk worden gedeeld. Hoe meer mensen zich bewust zijn van wat er gebeurt en waarom, des te meer zullen zij bereid zijn te helpen.

Wanneer verbeteringsactiviteiten in betrekkelijke stilte plaatsvinden, of met slechts een kleine groep die op de hoogte is van de details, kunnen veronderstellingen en geruchten de overhand krijgen. Er zal vaak weerstand tegen verandering ontstaan omdat personeelsleden speculeren over wat er verandert en hoe het hen zou kunnen beïnvloeden.

Met wie samen te werken

Het identificeren en managen van alle groepen belanghebbenden waarmee een organisatie te maken heeft is belangrijk, omdat de mensen en perspectieven die nodig zijn voor succesvolle samenwerking kunnen worden gevonden binnen deze stakeholder groepen. Zoals de naam suggereert, is een stakeholder iedereen die een belang heeft in de activiteiten van de organisatie, met inbegrip van de organisatie zelf, haar klanten en/of gebruikers, en vele anderen. De reikwijdte van stakeholders kan uitgebreid zijn.

De eerste en meest voor de hand liggende stakeholdergroep zijn de klanten. Het belangrijkste doel van een dienstverlener is resultaten te faciliteren waarin zijn klanten geïnteresseerd zijn, zodat de klanten een groot belang hebben in de dienstverlener om de diensten effectief te beheren. Sommige organisaties, echter, doen een slecht werk van interactie met klanten. Een dienstverlener kan het gevoel hebben dat het te moeilijk is om input of feedback te krijgen van de klant te krijgen, en dat de daaruit voortvloeiende vertragingen tijdverspilling zijn. Evenzo kunnen klanten het gevoel hebben dat, nadat zij hun behoeften hebben vastgesteld, de dienstverlener de dienst kan leveren zonder geen verder contact meer nodig is. Wanneer het gaat om de verbetering van de praktijken van een dienstverlener, ziet de klant het misschien helemaal niet nodig om betrokken te worden. Maar uiteindelijk zal de juiste mate van samenwerking met klanten leiden tot betere resultaten voor de organisatie, haar klanten en andere belanghebbenden.

Andere voorbeelden van samenwerking met belanghebbenden zijn:

- ontwikkelaars die samenwerken met andere interne teams om ervoor te zorgen dat wat wordt ontwikkeld kan worden efficiënt en effectief kan worden bediend. Ontwikkelaars dienen samen te werken met technische en niet -technische operationele teams om er zeker van te zijn dat zij klaar, bereid en in staat zijn om de overgang naar de nieuwe of veranderde dienst in werking te stellen, en misschien zelfs deel te nemen aan het te sten. Ontwikkelaars kunnen ook samenwerken met operationele teams om defecten (problemen) te onderzoeken en om workarounds of permanente fixes te ontwikkelen om deze defecten op te lossen.

- leveranciers die samenwerken met de organisatie om haar eisen te definiëren en te brainstormen naar oplossingen voor problemen van klanten

- relatiebeheerders die samenwerken met serviceconsumenten om tot een volledig begrip van de behoeften en prioriteiten van de serviceconsument

- klanten die met elkaar samenwerken om tot een gedeeld begrip te komen van hun problemen

- interne en externe leveranciers die met elkaar samenwerken om gedeelde processen te herzien en mogelijkheden voor optimalisatie en potentiële automatisering te identificeren.

Communicatie voor verbetering

De bijdrage aan verbetering van elke stakeholdergroep op elk niveau moet worden begrepen; het is ook belangrijk om de meest effectieve methoden te bepalen om met hen in contact te treden.

Bijvoorbeeld, de bijdrage aan verbetering van klanten van een publieke clouddienst kan bijvoorbeeld via een enquête of checklist met opties voor verschillende functionaliteiten. Voor een interne klantengroep kan de bijdrage aan verbetering komen uit feedback die wordt gevraagd via een workshop of een samenwerkingstool op het intranet van de organisatie.

Sommige medewerkers moeten misschien op een zeer gedetailleerd niveau worden betrokken, terwijl anderen gewoon als beoordelaars of goedkeurders fungeren. Afhankelijk van de dienst en de relatie tussen de dienstverlener en de afnemer van de dienst, kunnen de verwachtingen over het niveau en het type van samenwerking aanzienlijk verschillen

De urgentie verhogen door zichtbaarheid

Wanneer stakeholders (zowel intern als extern) slecht zicht hebben op de werklast en de voortgang van het werk, bestaat het risico dat de indruk wordt gewekt dat het werk geen prioriteit heeft. Als een initiatief gecommuniceerd aan een team, afdeling of een andere organisatie en vervolgens nooit of zelden meer wordt genoemd, zal de indruk ontstaan dat de v erandering niet belangrijk is. Evenzo, wanneer personeelsleden proberen om prioriteit te geven aan verbeteringswerk tegenover andere taken met dagelijkse urgentie, kan verbeteringswerk een activiteit met een lage prioriteit lijken, tenzij het belang ervan transparant is gemaakt en het wordt gesteund door het management van de organisatie.

Onvoldoende zichtbaarheid van het werk leidt tot slechte besluitvorming, wat weer gevolgen heeft voor het vermogen van de organisatie om de interne capaciteiten te verbete ren. Het wordt dan moeilijk om verbeteringen door te voeren omdat het niet duidelijk is welke de grootste positieve impact op de resultaten zullen hebben. Om dit te vermijden, moet de organisatie kritische analyseactiviteiten uitvoeren zoals:

- inzicht in de stroom van werk in uitvoering - het identificeren van knelpunten, evenals overtollige capaciteit - het aan het licht brengen van verspilling.

Het is belangrijk dat de belanghebbenden op alle niveaus bij het proces worden betrokken en dat op hun behoeften wordt ingespeeld. Leiders op verschillende niveaus moeten ook passende informatie verstrekken over de verbeteringswerkzaamheden in hun eigen communicatie naar anderen. Samen zullen deze acties dienen om te versterken wat er wordt gedaan, waarom het wordt geda an, en hoe het verband houdt met de visie, de missie, de doelstellingen en de objectieven van de organisatie.

Het bepalen van het type, de methode en de frequentie van dergelijke berichtgeving is één van de centrale activiteiten in relatie tot communicatie.

Toepassing van het beginsel

Om dit beginsel met succes toe te passen, kunt u het volgende advies in overweging nemen:

- Samenwerking betekent niet consensus. Het is niet nodig, of zelfs altijd verstandig, om consensus van iedereen die bij een initiatief betrokken is te krijgen alvorens verder te gaan. Sommige organisaties zijn zo begaan met het verkrijgen van consensus dat zij proberen het iedereen naar de zin te maken en uiteindelijk ofwel niets doen of iets produceren dat niet goed aansluit bij iemands behoeften.

- Communiceer op een manier die het publiek kan horen In een poging om verschillende belanghebbenden in de loop te brengen, gebruiken veel organisaties zeer traditionele communicatiemethoden, of ze gebruiken dezelfde methode voor alle communicatie. Het selecteren van de juiste methode en boodschap voor elk publiek is van cruciaal belang voor succes.

- Beslissingen kunnen alleen worden genomen op basis van zichtbare gegevens. Beslissingen nemen bij gebrek aan gegevens is riskant. Beslissingen moeten worden genomen over welke gegevens nodig zijn, en dus welk werk moet worden zichtbaar worden gemaakt. Het verzamelen van gegevens kan kosten met zich meebrengen, en de organisatie moet die kosten afwegen tegen de baten en het beoogde gebruik van de gegevens.

3.2.5 Holistisch denken en werken

Geen enkele dienst, praktijk, proces, afdeling of leverancier staat op zichzelf. De output die de organisatie levert aan zichzelf, haar klanten en andere belanghebbenden zal eronder lijden tenzij zij op een geïntegreerde manier werkt om haar activiteiten als een geheel te behandelen, in plaats van als afzonderlijke delen. Alle activiteiten van de organisatie zouden gericht moeten zijn op het leveren van waarde

Diensten worden geleverd aan interne en externe serviceconsumenten door de coördinatie en integratie van de vier dimensies van servicemanagement.

Het hanteren van een holistische benadering van servicemanagement omvat het vaststellen van een begrip van hoe alle onderdelen van een organisatie op een geïntegreerde manier same nwerken. Het vereist end-to-end zichtbaarheid van hoe vraag wordt vastgelegd en vertaald in resultaten. In een complex systeem kan de wijziging van één element gevolgen hebben voor andere en waar mogelijk moeten deze gevolgen worden vastgesteld, geanalyseerd en gepland.

Toepassing van het beginsel

Overweeg de volgende adviezen om dit beginsel met succes toe te passen:

- Erken de complexiteit van de systemen. Verschillende niveaus van complexiteit vereisen verschillende heuristieken voor de besluitvorming. Het toepassen van methoden en regels die zijn ontworpen voor een eenvoudig systeem kan ondoeltreffend of zelfs schadelijk zijn in een complex systeem, waar de relaties tussen componenten ingewikkeld zijn en vaker veranderen.

- Samenwerking is de sleutel tot holistisch denken en werken Indien de juiste mechanismen worden ingesteld voor alle relevante belanghebbenden om tijdig samen te werken, zal het mogelijk zijn om een kwestie holistisch aan te pakken zonder onnodige vertraging op te lopen.

- Zoek waar mogelijk naar patronen in de behoeften en interacties tussen systeemelementen. Maak gebruik van de kennis op elk gebied om vast te stellen wat essentieel is voor succes, en welke relaties tussen elementen van invloed zijn op de resultaten. Met deze informatie kunnen behoeften worden geanticipeerd, kunnen normen worden vastgesteld en kan een holistische visie worden bereikt.

- Automatisering kan holistisch werken vergemakkelijken. Waar de gelegenheid en voldoende middelen beschikbaar zijn, kan automatisering end-to-end zichtbaarheid voor de organisatie ondersteunen en een efficiënt middel voor geïntegreerd beheer zijn.

3.2.6 Hou het eenvoudig en praktisch

Gebruik altijd het minimum aantal stappen om een doel te bereiken. Op resultaten gebaseerd denken moet worden gebruikt om praktische oplossingen te produceren die waardevolle resultaten opleveren. Als een proces, dienst, actie of metriek geen waarde of nuttig resultaat oplevert, elimineer het dan. Hoewel dit principe voor de hand lijkt te liggen, wordt het vaak genegeerd, wat resulteert in te complexe werkmethodes die zelden de resultaten maximaliseren of de kosten minimaliseren.

Proberen om een oplossing te bieden voor elke uitzondering zal vaak leiden tot over -complicatie. Bij het creëren van een proces of een service, moeten ontwerpers nadenken over uitzonderingen, maar ze kunnen ze niet allemaal behandelen. In plaats daarvan moeten regels worden ontworpen die kunnen worden gebruikt om uitzonderingen in het algemeen te behandelen.

Beoordelen wat te behouden

Bij het analyseren van een praktijk, proces, dienst, metriek, of ander verbeterdoel, vraag altijd of het bijdraagt tot waarde creatie.

Bij het ontwerpen of verbeteren van service management, is het beter om te beginnen met een ongecompliceerde benadering en dan zorgvuldig controles, activiteit en, of metrieken toe te voegen wanneer men ziet dat ze echt nodig zijn. Essentieel voor het eenvoudig en praktisch houden van servicemanagement is het precies begrijpen hoe iets bijdraagt aan waarde creatie. Bijvoorbeeld, een stap in een proces kan door het betrokken operationeel personeel als tijdverspilling gezien worden. Echter, vanuit een bedrijfsperspectief kan dezelfde stap belangrijk zijn voor de naleving van de regelgeving en is het daarom op een indirecte manier, maar niettemin belangrijk. Het is noodzakelijk een holistische visie op het werk van de organisatie te ontwikkelen en uit te dragen zodat individuele teams of groepen holistisch kunnen denken over hoe hun werk wordt beïnvloed door, en op zijn beurt anderen beïnvloedt.

Tegenstrijdige doelstellingen

Houd bij het ontwerpen, beheren of toepassen van praktijken rekening met tegenstrijdige doelstellingen. Bijvoorbeeld, het management van een organisatie wil misschien een grote hoeveelheid gegevens verzamelen om beslissingen te kunnen nemen, terwijl de mensen die de administratie moeten doen misschien een eenvoudiger proces willen dat niet zo veel gegevens hoeven te worden ingevoerd. Door de toepassing van deze en de andere leidende beginselen moet de organisatie het eens worden over een evenwicht tussen haar concurrerende doelstellingen. In dit voorbeeld zou dit kunnen betekenen dat diensten alleen gegevens mogen genereren die werkelijk van waarde zijn voor het besluitvormingsproces, en het bijhouden van gegevens moet worden vereenvoudigd en waar mogelijk geautomatiseerd om de waarde te maximaliseren en geen -waarde toevoegend werk te verminderen.

Toepassing van het beginsel

Om dit beginsel met succes toe te passen, kunt u het volgende advies in overweging nemen:

- Zorg voor waarde Elke activiteit moet bijdragen tot het creëren van waarde.

- Eenvoud is de ultieme verfijning Het lijkt misschien moeilijker om te vereenvoudigen, maar het is vaak doeltreffend.

- Doe minder dingen, maar doe ze beter Door activiteiten te minimaliseren en alleen die activiteiten op te nemen die waarde hebben voor één of meer belanghebbenden, kan meer aandacht worden besteed aan de kwaliteit van die acties.

- Respecteer de tijd van de betrokkenen Een proces dat te ingewikkeld en te bureaucratisch is een slecht gebruik van de tijd van de betrokkenen.

- Gemakkelijker te begrijpen, meer kans op adoptie Om een praktijk te verankeren, moet u ervoor zorgen dat hij gemakkelijk te volgen is.

- Eenvoud is de beste manier om quick wins te behalen Of het nu in een project is, of bij het verbeteren dagelijkse operationele activiteiten, met quick wins kunnen organisaties vooruitgang aantonen en de verwachtingen van belanghebbenden te managen. Werken op een iteratieve manier met feedback zal snel incrementele waarde leveren met regelmatige tussenpozen.

3.2.7 Optimaliseren en automatiseren

Organisaties moeten de waarde maximaliseren van het werk dat door hun menselijke en technische middelen bereikt wordt. Het vier dimensies model biedt een holistische kijk op de verschillende beperkingen, soorten middelen, en andere gebieden die zouden moeten worden overwogen bij het ontwerpen, managen, of het runnen van een organisatie. Technologie kan organisaties helpen om op te schalen en frequente en repetitieve taken op zich te nemen, waardoor menselijke middelen kunnen worden ingezet voor complexere besluitvorming. Er moet echter niet altijd op technologie worden vertrouwd zonder de mogelijkheid van menselijke tussenkomst, aangezien automatisering omwille van de automatisering de kosten kan verhogen en de robuustheid en veerkracht van de organisatie kan verminderen.

Optimalisatie betekent iets zo effectief en nuttig maken als het moet zijn. Voordat een activiteit effectief kan worden geautomatiseerd, moet deze worden geoptimaliseerd in elke mate die mogelijk en redelijk is. Het is essentieel dat er grenzen worden gesteld aan de optimalisatie van diensten en praktijken, aangezien zij bestaan binnen een reeks beperkingen, zoals financiële beperkingen, nalevingsvereisten, tijdsbeperkingen en beschikbaarheid van middelen.

De weg naar optimalisatie

Er zijn vele manieren waarop praktijken en diensten kunnen worden geoptimaliseerd. De concepten en praktijken beschreven in ITIL, in het bijzonder de praktijken van voortdurende verbetering, en meting en rapportage, zijn essentieel voor deze inspanning. De specifieke praktijken die een organisatie gebruikt voor het verbeteren en prestaties te verbeteren en te optimaliseren kunnen gebaseerd zijn op richtlijnen van ITIL, Lean, DevOps, Kanban, en andere bronnen.

Ongeacht de specifieke technieken, volgt de weg naar optimalisatie deze stappen op hoog niveau:

- De context begrijpen en overeenkomen waarin de voorgestelde optimalisatie bestaat Dit omvat Overeenstemming over de algemene visie en doelstellingen van de organisatie.

- Beoordeel de huidige staat van de voorgestelde optimalisatie Dit zal helpen om te begrijpen waar het kan worden verbeterd en welke verbetermogelijkheden waarschijnlijk de grootste positieve impact zullen hebben.

- Overeenkomen wat de toekomstige status en prioriteiten va n de organisatie moeten zijn, met de nadruk op vereenvoudiging en waarde Dit omvat meestal ook standaardisatie van praktijken en diensten, wat het gemakkelijker zal maken om later te automatiseren of verder te optimaliseren.

- Zorg ervoor dat de optimalisatie het juiste niveau van betrokkenheid en betrokkenheid

- Voer de verbeteringen uit op een iteratieve manier Gebruik meetgegevens en andere feedback om de voortgang te controleren, op koers te blijven en de aanpak van de optimalisatie waar nodig aan te passen.

- Monitor voortdurend de impact van de optimalisatie Dit zal helpen om kansen te identificeren om werkwijzen te verbeteren.

Automatisering gebruiken

Automatisering verwijst doorgaans naar het gebruik van technologie om een stap of een reeks stappen correct en consistent uit te voeren met beperkte of geen menselijke tussenkomst.

Bijvoorbeeld, in organisaties die gebruik maken van continue deployment, verwijst het naar de automatische en continue vrijgave van code van ontwikkeling tot live, en vaak automatisc h testen in elke omgeving. In zijn eenvoudigste vorm echter, is automatisering ook de standaardisatie en stroomlijning van handmatige taken, zoals het definiëren van de regels van een deel van een proces, zodat beslissingen "automatisch" kunnen worden geno men. De efficiëntie kan aanzienlijk worden verhoogd door de noodzaak van menselijke betrokkenheid te verminderen om elk onderdeel van een proces te stoppen en te evalueren.

Mogelijkheden voor automatisering kunnen in de hele organisatie worden gevonden. Zo eken naar mogelijkheden om standaard en repeterende taken te automatiseren kan de organisatie helpen kosten te besparen, menselijke fouten te verminderen, en de ervaring van werknemers verbeteren.

Toepassing van het beginsel

Om dit beginsel met succes toe te passen, kunt u het volgende advies in overweging nemen:

- Vereenvoudig en/of optimaliseer voordat u automatiseert Pogingen om iets te automatiseren dat complex of suboptimaal is, is het onwaarschijnlijk dat het gewenste resultaat wordt bereikt. Neem de tijd om de standaard en herhalende processen zoveel mogelijk in kaart te brengen, en te stroomlijnen waar u kunt (optimaliseren). Van daaruit kunt u beginnen met automatiseren.

- Bepaal uw metrieken Het beoogde en werkelijke resultaat van de optimalisatie moeten worden geëvalueerd met behulp van een geschikte set van metrieken. Gebruik dezelfde metrieken om de basislijn te bepalen en de resultaten te meten. Zorg ervoor dat de metrieken resultaatgericht zijn en gericht op waarde.

- Gebruik de andere leidende principes bij het toepassen van deze. Bij het optimaliseren en automatiseren is het slim om ook de andere principes te volgen:

- Iteratieve vooruitgang met feedback Iteratieve optimalisatie en automatisering zal vooruitgang zichtbaar en vergroot de buy-in van belanghebbenden voor toekomstige iteraties.

- Houd het simpel en praktisch Het is mogelijk dat iets simpel is, maar niet geoptimaliseerd, dus gebruik deze twee principes samen bij het selecteren van verbeteringen.

- Focus op waarde Het selecteren van wat te optimaliseren en automatiseren en hoe dat te doen moet gebaseerd zijn op wat de beste waarde voor de organisatie zal creëren.

- Begin waar u bent De technologie die al beschikbaar is in de organisatie kan mogelijkheden en functionaliteiten die momenteel onbenut of onderbenut zijn. Maak gebruik van wat er al is om mogelijkheden voor optimalisatie en automatisering snel en economisch te implementeren.

Naast het feit dat u zich bewust moet zijn van de ITIL -richtlijnen, is het ook belangrijk om te erkennen dat ze met elkaar interageren en afhankelijk zijn van elkaar. Als een organisatie bijvoorbeeld streeft

naar iteratieve vooruitgang met feedback, moet het ook holistisch denken en werken om ervoor te zorgen dat elke iteratie van een verbetering alle elementen bevat die nodig zijn om echte resultaten te leveren. Op dezelfde manier is het gebruik van de juiste feedback de sleutel tot samenwerking, en door te focussen op wat echt waardevol is voor de klant is het gemakkelijker om de zaken eenvoudig en praktisch te houden.

Organisaties zouden niet slechts één of twee van de principes moeten gebruiken, maar zouden de relevantie van elk van hen en hoe ze samen van toepassing zijn moeten overwegen. Niet alle principes zullen in elke situatie van cruciaal belang zijn, maar ze moeten bij elke gelegenheid opnieuw worden bekeken om te bepalen in hoeverre zij geschikt zijn.

4 De vier dimensies van dienstenbeheer

De vier dimensies van dienstenbeheer moeten worden geïntroduceerd. Deze dimensies zijn relevant voor, en beïnvloeden alle elementen van het SVS (service value system).

Om hun gewenste resultaten te bereiken en zo effectief mogelijk te werken, moeten organisaties rekening houden met alle aspecten van hun gedrag. In de praktijk echter zijn organisaties vaak te zeer gericht op één gebied van hun initiatieven en verwaarlozen zij de andere. Bijvoorbeeld, procesverbeteringen kunnen worden gepland zonder voldoende rekening te houden met de mensen, partners en technologie die erbij betrokken zijn, of technologie oplossinge n kunnen worden geïmplementeerd zonder de nodige zorg voor de processen of mensen die ze geacht worden te ondersteunen. Er zijn meerdere aspecten aan servicemanagement, en geen van deze is voldoende om de vereiste resultaten te bereiken als ze afzonderlijk worden beschouwd.

Om een holistische benadering van servicemanagement te ondersteunen, definieert ITIL vier dimensies die gezamenlijk kritisch zijn voor het effectief en efficiënt faciliteren van waarde voor klanten en andere stakeholders in de vorm van producten en diensten. Deze zijn:

- organisaties en mensen

- informatie en technologie

- partners en leveranciers

- waardestromen en processen.

Deze vier dimensies vertegenwoordigen perspectieven die relevant zijn voor de gehele SVS, inclusief de gehele waardeketen van de service en alle ITIL-praktijken. De vier dimensies worden beperkt of beïnvloed door verschillende externe factoren die vaak buiten de controle van het SVS liggen.

Indien de vier dimensies niet naar behoren worden aangepakt, kan dit ert oe leiden dat diensten niet kunnen worden geleverd, of niet aan de verwachtingen inzake kwaliteit of efficiëntie. Als bijvoorbeeld de dimensie waardestromen en processen niet holistisch te benaderen kan leiden tot verspilling, dubbel werk, of erger nog, werk dat in strijd is met wat elders in de organisatie wordt gedaan. Evenzo kan het negeren van de partners en leveranciers betekenen dat uitbestede diensten niet zijn afgestemd op de behoeften van de organisatie. De vier dimensies hebben geen scherpe grenzen en kunnen elkaar overlappen. Zij zullen soms op onvoorspelbare manieren op elkaar inwerken, afhankelijk van de mate van complexiteit en onzekerheid waarin een organisatie opereert.

Het is belangrijk op te merken dat de vier dimensies van servicemanagemen t van toepassing zijn op alle diensten die worden beheerd, alsook op de SVS in het algemeen. Het is daarom essentieel dat deze perspectieven overwogen worden voor elke dienst, en dat elk ervan aan bod moet komen bij het beheren en verbeteren van het SVS op alle niveaus.

4.1 Organisatie en mensen

De eerste dimensie van dienstenbeheer is organisaties en mensen.

De doeltreffendheid van een organisatie kan niet worden gewaarborgd door een formeel vastgestelde structuur of een systeem van autoriteit alleen. De organisatie heeft ook een cultuur nodig die haar doelstellingen ondersteunt, en het juiste niveau van capaciteit en bekwaamheid onder

haar personeel. Het is van vitaal belang dat de leiders van de organisatie waarden verdedigen en uitdragen die mensen motiveren om op de gewenste manier te werken. Uiteindelijk, echter, is het de manier waarop een organisatie haar werk uitvoert die gedeelde waarden en attitudes creëert, die na verloop van tijd worden beschouwd als de cultuur van de organisatie.

De complexiteit van organisaties neemt toe, en het is belangrijk ervoor te zorgen dat de manier waarop een organisatie is gestructureerd en wordt geleid, evenals haar rollen, verantwoordelijkheden, en systemen van autoriteit en communicatie, goed gedefinieerd is en de algemene strategie en het model ondersteund.

Het is bijvoorbeeld nuttig om een cultuur van vertrouwen en transparantie te bevorderen in een organisatie die haar leden aanmoedigt om problemen aan te kaarten en te escaleren en corrigerende maatregelen vergemakkelijkt voordat problemen een impact hebben op klanten. Het overnemen van de ITIL-richtlijnen kan een goed beginpunt zijn voor het tot stand brengen van een gezonde organisatiecultuur.

Mensen (of het nu klanten, werknemers van leveranciers, werknemers van de serviceprovider, of een andere stakeholder in de servicerelatie) zijn een sleutelelement in deze dimensie. Er moet aandacht worden besteed niet alleen aan de vaardigheden en bekwaamheden van teams of individuele leden, maar ook aan management- en leiderschapsstijlen, en aan communicatie- en samenwerkingsvaardigheden. Naarmate de praktijken evolueren, moeten ook mensen hun vaardigheden en competenties op peil houden. Het wordt steeds belangrijker voor mensen om te begrijpen dat de raakvlakken tussen hun specialisaties en rollen en die van anderen in de organisatie, zorgen voor de juiste mate van samenwerking en coördinatie. Bijvoorbeeld, in sommige gebieden van de IT (zoals software ontwikkeling of gebruikersondersteuning), wordt steeds meer erkend dat iedereen een brede algemene kennis van de andere gebieden van de organisatie moet hebben, gecombineerd met een diepgaande specialisatie op bepaalde gebieden.

Elke persoon in de organisatie zou een duidelijk inzicht moeten hebben in zijn bijdrage aan het creëren van waarde voor de organisatie, haar klanten, en andere stakeholders. Het bevorderen van een focus op waarde creatie is een effectieve methode om organisatorische silo's af te breken.

De organisaties en mensen dimensie van een dienst omvat rollen en verantwoordelijkheden, formele organisatorische structuren, cultuur, en vereiste personeelsbezetting en bekwaamheden, welke allemaal gerelateerd zijn aan de creatie, levering, en verbetering van een dienst.

4.2 Informatie en technologie

De tweede dimensie van dienste nbeheer is informatie en technologie. Net als bij de andere drie dimensies, is informatie en technologie zowel van toepassing op dienstenbeheer als op de diensten die het beheerd.

Toegepast op de SVS, omvat de dimensie informatie en technologie de informatie en kennis die nodig zijn voor het beheer van diensten, alsook de vereiste technologieën. Zij omvat ook de relaties tussen de verschillende componenten van de SVS, zoals de inputs en outputs van activiteiten en praktijken.

De technologieën die het dienstenbeheer ondersteunen, omvatten, maar zijn niet beperkt tot, workflow managementsystemen, kennisbanken, inventarisatiesystemen, communicatiesystemen, en analytische hulpmiddelen. Servicemanagement profiteert steeds meer van technologische ontwikkelingen. Kunstmatige intelligentie, machine learning en andere cognitieve computeroplossingen worden op alle niveaus gebruikt, van strategische planning en portfoliooptimalisatie tot systeemmonitoring en gebruikersondersteuning. Het gebruik van mobiele platforms, cloudoplossingen, tools voor samenwerking op afstand, geautomatiseerde test - en implementatieoplossingen is gemeengoed geworden onder dienstverleners.

In de context van een specifieke IT-dienst omvat deze dimensie de informatie die wordt gecreëerd, beheerd en gebruikt in de loop van de serviceverlening en -consumptie, en de technologieën die die service ondersteunen en mogelijk maken. De specifieke informatie en technologieën hangen af van de aard van de diensten en bestrijken gewoonlijk alle niveaus van de IT-architectuur, met inbegrip van toepassingen, databanken, communicatiesystemen, en hun integraties. Op veel gebieden maken IT-diensten gebruik van de nieuwste technologie ontwikkelingen, zoals blockchain, kunstmatige intelligentie en cognitive computing. Deze diensten bieden een zakelijk differentiatiepotentieel aan early adopters, vooral in sterk concurrerende industrieën. Andere technologische oplossingen, zoals cloud computing of mobiele apps, zijn inmiddels wereldwijd in veel sectoren gemeengoed gewo rden. Met betrekking tot de informatiecomponent van deze dimensie dienen organisaties zich de volgende vragen te stellen:

- Welke informatie wordt door de diensten beheerd?

- Welke ondersteunende informatie en kennis zijn nodig voor het leveren en beheren van de diensten ?

- Hoe zullen de informatie- en kennisactiva worden beschermd, beheerd, gearchiveerd en verwijderd?

Voor veel diensten is informatiebeheer het belangrijkste middel om waarde voor de klant te creëren.

Voor bijvoorbeeld, een HR-dienst faciliteert waardecreatie voor zijn klanten door de organisatie in staat te stellen toegang te krijgen tot accurate informatie over haar werknemers, hun tewerkstelling en hun voordelen en deze te onderhouden zonder dat onbevoegden toegang krijgen tot privéinformatie. Een netwerkbeheerdienst creëert waarde voor zijn gebruikers door het onderhouden en verstrekken van nauwkeurige informatie over de actieve netwerkverbindingen van een organisatie en het gebruik ervan, zodat de organisatie de bandbreedte van haar netwerk k an aanpassen aan de gevraagde capaciteit. Informatie is over het algemeen de belangrijkste output van de meeste ITdiensten die worden gebruikt door zakelijke klanten.

Een andere belangrijke overweging in deze dimensie is hoe informatie wordt uitgewisseld tussen verschillende diensten en servicecomponenten. De informatiearchitectuur van de verschillende diensten moet goed worden begrepen en voortdurend geoptimaliseerd, rekening houdend met criteria als beschikbaarheid, betrouwbaarheid, toegankelijkheid, tijdigheid, nauwkeurigheid en relevantie van de informatie die aan gebruikers wordt verstrekt en tussen diensten wordt uitgewisseld.

De uitdagingen van het informatiebeheer, zoals die welke voortvloeien uit eisen op het gebied van beveiliging en en regelgevingsvereisten, vormen eveneens een aandachtspunt in deze dimensie. Een organisatie kan bijvoorbeeld onderworpen zijn aan de General Data Protection Regulation (GDPR) van de Europese Unie, die van invloed is op het beleid en de praktijken op het geb ied van informatiebeheer. Andere sectoren of landen kunnen regelgeving hebben die beperkingen opleggen aan het verzamelen en beheren van gegevens van multinationale ondernemingen. Voor In de VS bijvoorbeeld voorziet de Health Insurance Portability and Acco untability Act van 1996 in gegevens privacy en veiligheidsvoorschriften voor de bescherming van medische informatie.

De meeste diensten zijn tegenwoordig gebaseerd op IT, en zijn er sterk van afhankelijk. Wanneer men overweegt een technologie te gebruiken bij de planning, het ontwerp, de overgang of de werking van een product of dienst, kunnen vragen die een organisatie zich kan stellen zijn onder meer:

- Is deze technologie compatibel met de huidige architectuur van de organisatie en haar klanten? Werken de verschillende technologieproducten die door de organisatie en haar belanghebbenden samen? Hoe zijn opkomende technologieën (zoals machine learning, kunstmatige intelligentie, en Internet of Things) die de dienst of de organisatie waarschijnlijk verstoren?

- Levert deze technologie regelgevings- of andere nalevingsproblemen op met het beleid van de organisatie beleid en informatiebeveiligingscontroles, of die van haar klanten?

- Is dit een technologie die in de afzienbare toekomst levensvatbaar zal blijven? Is d e organisatie bereid het risico te aanvaarden van het gebruik van verouderde technologie, of van het omarmen van opkomende of onbewezen technologie?

- Past deze technologie in de strategie van de dienstverlener, of van zijn afnemers?

- Beschikt de organisatie over de juiste vaardigheden bij haar personeel en leveranciers om de technologie te ondersteunen en te onderhouden?

- Heeft deze technologie voldoende automatiseringsmogelijkheden om te verzekeren dat zij efficiënt kan worden kan worden ontwikkeld, ingezet en gebruikt?

- Biedt deze technologie extra mogelijkheden die als hefboom kunnen worden gebruikt voor andere producten of diensten?

- Brengt deze technologie nieuwe risico's of beperkingen met zich mee voor de organisatie (bijvoorbeeld, bijvoorbeeld door de organisatie aan een specifieke leverancier te binden)?

De cultuur van een organisatie kan een belangrijke invloed hebben op de technologieën die zij kiest te gebruiken. Sommige organisaties hebben meer belang bij de voorhoede van technologische ontwikkelingen dan andere. Evenzo kan de cultuur van sommige organisaties traditioneler zijn. Een bedrijf wil misschien graag profiteren van kunstmatige intelligentie, terwijl een ander bedrijf misschien nog nauwelijks toe is voor geavanceerde gegevensanalyse-instrumenten.

De aard van het bedrijf zal ook van invloed zijn op de technologie waarvan het gebruik maakt. Bijvoorbeeld, een bedrijf dat belangrijke zaken doet met overheidsklanten kan beperkingen hebben op het gebruik van sommige technologieën, of heeft het beduidend meer te maken met veiligheidsproblemen die moeten worden aangepakt. Andere industrieën, zoals de financiële sector of de biowetenschappen, zijn ook onderworpen aan beperkingen rond hun gebruik van technologie.

Zo kunnen zij doorgaans geen gebruik maken van open source bij overheidsdiensten wanneer zij te maken hebben met gevoelige gegevens.

4.3 Partners en leveranciers

De derde dimensie van dienstenbeheer zijn partners en leveranciers. Elke organisatie en elke dienst zijn tot op zekere hoogte afhankelijk van diensten die door andere organisaties worden geleverd.

De dimensie partners en leveranciers omvat de relaties van een organisatie met andere organisaties die betrokken zijn bij het ontwerp, de ontwikkeling, de uitrol, de levering, de ondersteuning, en/of voortdurende verbetering van diensten. Het omvat ook contracten en andere overeenkomsten tussen de organisatie en haar partners of leveranciers.

Relaties tussen organisaties kunnen verschillende niveaus van integratie en formaliteit omvatten.

Deze varieert van formele contracten met een duidelijke scheiding van verantwoordelijkheden, tot flexibele partnerschappen waar partijen gemeenschappelijke doelstellingen en risico's delen, en samenwerken om de gewenste resultaten te bereiken.

De vormen van samenwerking liggen niet vast, maar bestaan als een spectrum. Een organisatie die als dienstverlener optreedt, zal een positie in dit spectrum hebben, die zal variëren afhankelijk van haar strategie en doelstellingen voor klantrelaties. Evenzo zal, wanneer ee n organisatie optreedt als consument van diensten, de rol die zij aanneemt op zich nemen, afhankelijk van haar strategie en doelstellingen voor sourcing en leveranciersmanagement. Wanneer het aankomt op het gebruik van partners en leveranciers, zou de strategie van een organisatie gebaseerd moeten zijn op haar doelstellingen, cultuur, en zakelijke omgeving. Sommige organisaties kunnen bijvoorbeeld van mening zijn dat zij het meest gebaat zijn bij hun aandacht te richten op het ontwikkelen van bepaalde kerncompetenties en partners en leveranciers te gebruiken om andere behoeften te voorzien. Andere organisaties kunnen ervoor kiezen om zo veel mogelijk te vertrouwen op hun eigen middelen en zo weinig mogelijk gebruik te maken van partners en leveranciers. Er zijn natuurlijk vele variaties tussen deze twee tegengestelde benaderingen.

Eén methode die een organisatie kan gebruiken om de partners en leveranciers dimensie aan te pakken is service integratie en management. Dit impliceert het gebruik van een speciaal opgerichte integrator om ervoor te zorgen dat de dienstrelaties naar behoren worden gecoördineerd.

Dienstenintegratie en -beheer kan binnen de organisatie worden gehouden, maar kan ook worden gedelegeerd aan een vertrouwde partner.

Factoren die de strategie van een organisatie bij het gebruik van leveranciers kunnen beïnvloeden zijn onder andere:

- Strategische focus Sommige organisaties geven er de voorkeur aan zich te concentreren op hun kerncompetentie en besteden niet-kern ondersteunende functies uit aan derden; andere geven er de voorkeur aan om zo veel mogelijk zelfvoorzienend te blijven en de volledige controle te behouden over alle belangrijke functies.

- Bedrijfscultuur Sommige organisaties hebben een historische voorkeur voor de ene aanpak boven een andere. Langdurige culturele vooroordelen zijn moeilijk te veranderen zonder dwingende redenen.

- Schaarste aan middelen Als er een tekort is aan de vereiste middelen of vaardigheden, kan het moeilijk zijn voor de dienstverlener om de nodige middelen te verkri jgen zonder een beroep te doen op een leverancier.

- Kostenoverwegingen Een beslissing kan worden beïnvloed door de vraag of de dienstverlener van mening is dat het economischer is om een bepaalde vereiste bij een leverancier te betrekken.

- Deskundigheid op een bepaald gebied De dienstverlener kan van mening zijn dat het minder riskant is een beroep te doen op een leverancier die reeds deskundigheid heeft op een vereist gebied, in plaats van te proberen de deskundigheid in huis te ontwikkelen en te onderhouden

- Externe beperkingen Overheidsvoorschriften of -beleid, gedragscodes van de industrie, en sociale, politieke of wettelijke beperkingen kunnen van invloed zijn op de leveranciersstrategie van een organisatie.

- Vraagpatronen De activiteit van de klant of de vraag naar diensten kan seizoensgebonden zijn of een hoge mate van variabiliteit vertonen. Deze patronen kunnen van invloed zijn op de mate waarin organisaties gebruik maken van externe dienstverleners om aan de wisselende vraag te voldoen.

Het laatste decennium is er een explosie geweest van bedrijven die technische middelen (infrastructuur) of capaciteiten (platforms, software) "als een dienst" aanbieden. Deze bedrijven bundelen goederen en diensten in één productaanbod dat kan worden verbruikt als een nutsvoorziening, en dat doorgaans wordt geboekt als bedrijfsuitgaven. Dit bevrijdt bedrijven van investeringen in dure infrastructuur en software die als kapitaaluitgaven moeten worden geboekt.

4.4 Waardestromen en processen

De vierde dimensie van dienstenbeheer zijn waardestromen en processen. Net als de andere dimensies, is deze dimensie van toepassing op zowel de SVS in het algemeen, als op specifieke producten en diensten. In beide contexten definieert zij de activiteiten, werkstromen, controles en procedures die nodig zijn om overeengekomen doelstellingen te bereiken.

Toegepast op de organisatie en haar SVS, houdt de dimensie waardestromen en processen zich bezig met hoe de diverse delen van de organisatie werken op een geïntegreerde en gecoördinee rde manier werken om waarde creatie door producten en diensten mogelijk te maken. De dimensie concentreert zich op welke activiteiten de organisatie onderneemt en hoe zij worden georganiseerd, evenals hoe de organisatie ervoor zorgt dat zij waarde creatie voor alle stakeholders efficiënt en effectief verzekert.

ITIL geeft organisaties die optreden als dienstverleners een bedrijfsmodel dat alle belangrijke activiteiten omvat die nodig zijn om producten en diensten effectief te beheren. Dit wordt de ITIL servicewaardeketen genoemd.

Het operationeel model van de servicewaardeketen is generiek en kan in de praktijk verschillende patronen volgen. Deze patronen binnen de werking van de waardeketen worden waardestromen genoemd.

Waardestromen voor service management

Definitie Waardestroom

Een reeks stappen die een organisatie onderneemt om producten en diensten te creëren en te leveren aan consumenten.

Een waardestroom is een reeks stappen die een organisatie onderneemt om producten en diensten te creëren en te leveren aan een serviceconsument. Een waardestroom is een combinatie van de waardeketenactiviteiten van de organisatie

Het identificeren en het begrijpen van de diverse waardestromen die een organisatie heeft is essentieel voor het verbeteren van zijn algemene prestatie. Het structureren van de activiteiten van de organisatie in de vorm van waardestromen maakt het mogelijk om een duidelijk beeld te hebben van wat zij levert en hoe, en om voortdurend verbeteringen aan te brengen in haar diensten.

Organisaties zouden moeten onderzoeken hoe zij hun werk uitvoeren en alle waardestromen die zij kunnen identificeren in kaart brengen. Dit zal hen in staat stellen om hun huidige staat te analyseren en eventuele belemmeringen voor workflow en niet waarde toevoegende acti viteiten, d.w.z. verspilling te identificeren. Verspillende activiteiten moeten worden geëlimineerd om de productiviteit te verhogen.

Mogelijkheden om waarde toevoegende activiteiten te verhogen kunnen in de hele waardeketen van de dienstverlening worden gevonden. Deze kunnen nieuwe activiteiten zijn of wijzigingen aan bestaande activiteiten, die de organisatie productiever kunnen maken. De optimalisatie van de waardestroom kan procesautomatisering omvatten of de toepassing van opkomende technologieën en werkwijzen om de efficiëntie te verhogen of de gebruikerservaring te verbeteren.

Waardestromen moeten door organisaties worden gedefinieerd voor elk van hun producten en diensten. Afhankelijk van de strategie van de organisatie, kunnen waardestromen worden geherdefinieerd om te reageren op veranderende vraag en andere omstandigheden, of stabiel blijven voor een aanzienlijke hoeveelheid tijd. In elk geval, zouden zij voortdurend moeten worden verbeterd om ervoor te zorgen dat de organisatie haar doelstellingen op een optimale manier bereikt.

Processen

Definitie Proces

Een geheel van onderling samenhangende of op elkaar inwerkende activiteiten die inputs omzetten in outputs. Een proces neemt een of meer welomschreven inputs en zet die om in welomschreven outputs. Processen definiëren de opeenvolging van acties en hun afhankelijkheden.

Een proces is een reeks activiteiten die inputs omzetten in outputs. Processen beschrijven wat wordt gedaan om een doel te bereiken, en goed gedefinieerde processen kunnen de productiviteit binnen en tussen organisaties verbeteren. Zij worden gewoonlijk gedetailleerd beschreven in procedures, die aangeven wie betrokken is bij het proces, en werkinstructies, waarin wordt uitgelegd hoe ze worden uitgevoerd.

Toegepast op producten en diensten, helpt deze dimensie bij het beantwoorden van de volgende vragen, die van cruciaal belang zijn voor ontwerp, levering en verbetering van diensten:

- Wat is het generieke leveringsmodel voor de dienst, en hoe werkt de dienst?

- Wat zijn de waardestromen die betrokken zijn bij het leveren van de overeengekomen outputs van de dienst?

- Wie, of wat, voert de vereiste dienstverleningsacties uit?

De specifieke antwoorden op deze vragen zullen variëren naar gelang van de aard en de architectuur van de dienst.

4.5 Externe factoren

Dienstverleners opereren niet in een isolement. Zij worden beïnvloed door vele externe factoren en werken in dynamische en complexe omgevingen die een hoge mate van volatiliteit en onzekerheid kunnen vertonen en beperkingen opleggen aan de manier waarop de dienstverlener kan werken. Om deze externe factoren te analyseren, worden raamwerken zoals het PESTLE (of PESTEL) model gebruikt. PESTLE is een acroniem voor de politieke, economische, sociale, technologische, wettelijke (legal), en milieu(environment) factoren die de manier waarop een dienstverlener opereert, beïnvloedt of beperkt.

Gezamenlijk beïnvloeden deze factoren hoe organisaties hun middelen en de vier dimensies van service management configureren. Bijvoorbeeld:

- De houding van de overheid en de maatschappij ten opzichte van milieuvriendelijke producten en diensten kan ertoe leiden dat de organisatie meer investeert in hulpmiddelen en technologieën die voldoen aan externe verwachtingen. Een orga nisatie kan ervoor kiezen om samen te werken met andere organisaties (of diensten van externe leveranciers) die kunnen aantonen dat zij milieuvriendelijk zijn. Sommige bedrijven publiceren bijvoorbeeld milieurapporten over hun producten, waarin wordt beschreven hoe producten worden afgezet tegen hun beleid inzake klimaatverandering, veiliger materialen en andere hulpbronnen.

- Economische en maatschappelijke factoren kunnen organisaties beïnvloeden om verschillende versies van hetzelfde product om verschillende consumentengroepen met verschillende koopgedrag aan te spreken. Een voorbeeld van voorbeeld zijn muziek - en videostreamingdiensten, waarvan er veel een gratis tier (met reclame), een premium tier (zonder reclame), en in sommige gevallen een "familieplan" dat meerdere individuele profielen onder één betaalde account mogelijk maakt.

- Wet- en regelgeving op het gebied van gegevensbescherming (zoals GDPR) heeft de manier veranderd waarop bedrijven klantgegevens moeten verzamelen, verwerken, raadplegen en opslaan, en hoe ze moeten samenwerken met externe partners en leveranciers.

5 De ITIL SVS en SVC

5.1 De ITIL service value system (SVS)

Om goed te kunnen functioneren, moet service management werken als een systeem. De ITIL SVS beschrijft de inputs voor dit systeem (gelegenheid en vraag), de elementen van dit systeem (organisatorische bestuur, servicemanagement, voortdurende verbetering, en de mogelijkheden en middelen van de organisatie), en de output (het bereiken van organisatiedoelstellingen en waarde voor de organisatie, haar klanten, en andere belanghebbenden).

Het ITIL SVS beschrijft hoe alle componenten en activiteiten van de organisatie samenwerken als een systeem om waarde creatie mogelijk te maken. Het SVS van elke organisatie heeft interfaces met andere organisaties, die een ecosysteem vormen dat op zijn beurt waarde kan creëren voor die organisaties, hun klanten en andere belanghebbenden.

De belangrijkste inputs voor het SVS zijn kansen en vraag. Opportunities vertegenwoordigen opties of mogelijkheden om waarde toe te voegen voor belanghebbenden of anderszins de organisatie te verbeteren. De vraag is de behoefte of het verlangen naar producten en diensten bij interne en externe consumenten. Het resultaat van de SVS is waarde, dat wil zeggen, de waargenome n voordelen, het nut en het belang van iets. De ITIL SVS kan het volgende mogelijk maken van het creëren van veel verschillende soorten waarde voor een brede groep belanghebbenden.

Het ITIL SVS omvat de volgende componenten:

- Leidende principes Aanbevelingen die een organisatie in alle omstandigheden kunnen leiden, Ongeacht veranderingen in de doelstellingen, strategieën, soort werk of managementstructuur.

- Governance De manier waarop een organisatie wordt bestuurd en gecontroleerd.

- Servicewaardeketen Een reeks onderling verbonden activiteiten die een organisatie uitvoert om een waardevol product of dienst aan zijn consumenten te leveren en om waarde realisatie te vergemakkelijken.

- Praktijken Reeksen organisatorische middelen ontworpen voor het uitvoeren van werk of het bereiken van een doel.

- Voortdurende verbetering Een terugkerende organisatorische activiteit die op alle niveaus wordt uitgevoerd om te verzekeren dat de prestaties van een organisatie voortdurend voldoen aan de verwachtingen van belanghebbenden. ITIL 4 ondersteunt voortdurende verbetering met het ITIL model voor voortdurende verbetering.

Het doel van het SVS is ervoor te zorgen dat de organisatie voortdurend waarde co -creëert met alle stakeholders door het gebruik en beheer van producten en diensten. De structuur van de SVS wordt weergegeven in de figuur. De linkerkant van de figuur toont kansen en vraag die in de SVS van zowel interne als externe bronnen komen. De rechterkant toont de waarde die wordt gecreëerd voor de organisatie, haar klanten en andere belanghebbenden.

Het ITIL SVS beschrijft hoe alle componenten en activiteiten van de organisatie samenwerken als een systeem om waardecreatie mogelijk te maken. Deze componenten en activiteiten, samen met de middelen van de organisatie, kunnen worden geconfigureerd en opnieuw geconfigureerd in meerdere combinaties op een flexibele manier als omstandigheden veranderen, maar dit vereist de integratie en coördinatie van activiteiten, praktijken, teams, bevoegdheden en verantwoordelijkheden, en alle partijen om echt effectief te zijn.

Een van de grootste uitdagingen waar een organisatie mee te maken kan krijgen als ze effectief en efficiënt probeert te werken met een gedeelde visie, of om wendbaarder en veerkrachtiger te worden, is de aanwezigheid van organisatorische silo's. Organisatiesilo's kunnen zich op vele manieren en om vele verschillende redenen vormen. Silo's kunnen resistent zijn tegen verandering en kunnen gemakkelijke toegang tot de informatie en gespecialiseerde e xpertise verhinderen die in de hele organisatie, wat op zijn beurt de efficiëntie kan verminderen en zowel de kosten als de risico's kan verhogen. Silo's maken het ook moeilijker om te communiceren of samen te werken tussen verschillende groepen.

Een verzuilde organisatie kan niet snel handelen om kansen te benutten of om het gebruik van middelen binnen de organisatie te optimaliseren. Het is vaak niet in staat om effectieve beslissingen te nemen over veranderingen, als gevolg van beperkte zichtbaarheid en veel verborgen agenda's. Praktijken kunnen ook silo's worden. Veel organisaties hebben praktijken geïmplementeerd zoals organisatorisch veranderingsmanagement of incidentmanagement zonder duidelijke interfaces met andere praktijken. Alle practices zouden meerdere interfaces met elkaar moeten hebben. De uitwisseling van informatie tussen practices zou op belangrijke punten in de workflow in gang moeten worden gezet, en zijn essentieel voor het goed functioneren van de organisatie.

De architectuur van het ITIL SVS maakt specifiek flexibiliteit mogelijk en ontmoedigt het werken in silo's. De service value chain-activiteiten en de praktijken in het SVS vormen geen vaste, rigide structuur. Integendeel, ze kunnen worden gecombineerd in meerdere waardestromen om te voldoen aan de behoeften van de organisatie in een verscheidenheid van de organisatie in een

verscheidenheid van scenario's. Deze publicatie geeft voorbeelden van service waardestromen, maar geen van hen is definitief of voorschrijvend. Organisaties moeten in staat zijn hun waardestromen te definiëren en te herdefiniëren op een flexibele, maar veilige en efficiënte manier. Dit vereist voortdurende verbeteringsactiviteiten die moeten worden uitgevoerd op alle niveaus van de organisatie; het ITIL-model voor voortdurende verbetering helpt deze activiteit te structureren.

Ten slotte worden de voortdurende verbetering en de algemene werking van een organisatie vormgegeven door de ITIL leidende principes. De leidende principes creëren een basis voor een gedeelde cultuur in de hele organisatie, waardoor samenwerking en coöperatie binnen en tussen de teams wordt ondersteund, en de noodzaak wegnemen van beperkingen en controles die voorheen door silo's werden geleverd. Met deze componenten, ondersteunt het ITIL SVS vele werkbenaderingen, zoals Agile, DevOps en Lean, maar ook traditioneel proces - en projectmanagement, met een flexibel waardegericht besturingsmodel.

Een organisatie kan een aantal vormen aannemen, waaronder, maar niet beperkt tot, eenmanszaak, vennootschap, corporatie, firma, onderneming, autoriteit, partnerschap, liefdadigheid of instelling, of enig deel of combinatie daarvan, al dan niet met rechtspersoonlijkheid, en openbaar of particulier zijn. Dit betekent dat het toepassingsgebied van het SVS een hele organisatie of een kleinere subgroep van die organisatie kan zijn. Om de maximale waarde van het SVS te bereiken en het probleem van de organisatorische silo's naar behoren aan te pakken, verdient het de voorkeur de gehele organisatie in het toepassingsgebied op te nemen in plaats van een subgroep.

5.2 De ITIL service value chain (SVC)

Het centrale element van het SVS is de dienstenwaardeketen, een operationeel model dat de belangrijkste activiteiten schetst die nodig zijn om aan de vraag te voldoen en waarde te creëren door het creëren en beheer van producten en diensten.

De zes activiteiten van de waardeketen zijn

- plannen

- verbeteren

- betrekken

- ontwerp en overgang

- verkrijgen/bouwen

- leveren en ondersteunen.

Deze activiteiten vertegenwoordigen de stappen die een organisatie neemt bij het creëren van waarde. Elke activiteit transformeert inputs in outputs. Deze inputs kunnen vraag van buiten de waardeketen zijn of outputs van andere activiteiten zijn. Alle activiteiten zijn met elkaar verbo nden, waarbij elke activiteit triggers voorziet voor verdere actie

Om inputs om te zetten in outputs, maken de waardeketenactiviteiten gebruik van verschillende combinaties van ITIL-praktijken (sets van middelen voor het uitvoeren van bepaalde soorten werk), gebruikmakend van interne of externe middelen, processen, vaardigheden en competenties, naargelang vereist. Bijvoorbeeld, de engage-activiteit kan gebruik maken van leveranciersbeheer, servicedeskbeheer, relatiebeheer, en service request management om te reageren op nieuwe vraag naar producten en diensten, of informatie van verschillende belanghebbenden.

Ongeacht welke praktijken worden toegepast, zijn er enkele gemeenschappelijke regels bij het gebruik van de service waardeketen:

- Alle inkomende en uitgaande interacties met partijen buiten de waardeketen worden uitgevoerd via engage

- Alle nieuwe middelen worden verkregen via obtain/build

- Planning op alle niveaus wordt uitgevoerd via plan

- Verbeteringen op alle niveaus worden geïnitieerd en beheerd via im prove.

Om een bepaalde taak uit te voeren of op een bepaalde situatie te reageren, creëren organisaties service value stromen. Dit zijn specifieke combinaties van activiteiten en praktijken, en elk daarvan is ontworpen voor een bepaald scenario. Eenmaal ontworpen, zouden de waardestromen onderworpen moeten zijn aan voortdurende verbetering. Een waardestroom zou, bijvoorbeeld, kunnen worden gecreëerd voor een situatie waarin een gebruiker van een dienst een incident moet oplossen. De waardestroom zal specifiek worden ontworpen om dit probleem op te lossen, en zal een volledig overzicht geven van de activiteiten, praktijken en rollen die erbij betrokken zijn.

Het doel van het “plan” waardeketen activiteit is om te zorgen voor een gedeeld begrip van de visie, huidige status, en verbeteringsrichting voor alle vier dimensies en alle producten en diensten in de hele organisatie.

Het doel van de activiteit waardeketen “verbeteren” is te zorgen voor voortdurende verbetering van producten, diensten en praktijken in alle activiteiten van de waardeketen en de vier dimensies van dienstenbeheer.

Het doel van de activiteit "engage" is te zorgen voor een goed begrip van de behoeften van de belanghebbenden, transparantie, en een voortdurende betrokkenheid en goede relaties m et alle stakeholders.

Het doel van de waardeketenactiviteit “ontwerp en overgang” is ervoor te zorgen dat producten en diensten voortdurend voldoen aan de verwachtingen van de belanghebbenden inzake kwaliteit, kosten en marktintroductietijd.

Het doel van de "obtain/build"-waardeketenactiviteit is ervoor te zorgen dat de dienstcomponenten beschikbaar zijn wanneer en waar zij nodig zijn, en voldoen aan de overeengekomen specificaties.

Het doel van de waardeketenactiviteit "leveren en ondersteunen" is ervoor t e zorgen dat diensten worden geleverd en ondersteund volgens de overeengekomen specificaties en de verwachtingen van de belanghebbenden.

6 ITIL-praktijken

ITIL is een reeks best-practice-publicaties voor IT-servicemanagement (ITSM). ITIL werd aanvankelijk ontwikkeld door het Central Computer and Telecommunications Agency van de Britse regering aan het einde van de jaren 1980 als een IT-raamwerk voor gebruik binnen organisaties in de Britse openbare sector. Dit werd al snel overgenomen door zowel de Britse openbare sector als enkele grote wereldwijde organisaties in de particuliere sector. De tweede versie van ITIL, vaak versie 2 genoemd, werd gepubliceerd in 2001. De boeken over Service Delivery en Service Support werden opnieuw doordacht en ontwikkeld tot meer bruikbare beknopte volumes. ITIL werd al snel de meest gebruikte bron van ITSM-goede praktijken wereldwijd, zowel in de openbare als in de privésector. In 2007 werd een nieuwe versie van ITIL gepubliceerd, die een levenscyclusbenadering van ITSM hanteerde. Deze versie, die soms versie 3 (V3) wordt genoemd, introduceerde verscheidene nieuwe processen, waaronder het voldoen aan verzoeken. In 2011 werd een bijgewerkte versie van ITIL gepubliceerd. ITIL 2011 loste fouten en inconsistenties in de tekst en diagrammen in de hele reeks publicaties op. In 2019 is een nieuwe versie van ITIL gepubliceerd, die bekend staat als ITIL V4.

ITIL geeft richtlijnen voor het leveren van IT-diensten van hoge kwaliteit en de processen, functies en andere capaciteiten die nodig zijn om deze te ondersteunen. Het ITIL -raamwerk is gebaseerd op een servicelevenscyclus en bestaat uit vijf levenscyclusfasen (servicestrategie, serviceontwerp, servicetransitie, servicewerking en voortdurende serviceverbetering), die elk hun eigen ondersteunende publicatie hebben. Er is ook een reeks aanvullende ITIL -publicaties die richtlijnen geven die specifiek zijn voor industriesectoren, organisatietypen, bedrijfsmodellen en technologiearchitecturen.

6.1 Wat is ITIL?

Organisaties richten zich sterk op processen en technologie om hun klanten uitmuntende service te bieden. Door een verzameling best practices en raamwerken in de sector te volgen, kunnen be drijven hun doelstellingen gemakkelijk realiseren. Dit heeft direct invloed op de productiviteit en verbetert de klanttevredenheid. Maar het belangrijkste is om alleen die best practices toe te passen die nodig en geschikt zijn voor uw bedrijfsmodel. Dit helpt bij het bieden van uitstekende serviceondersteuning en levering.

IT Infrastructure Library (ITIL) is een verzameling best practices voor een effectief IT Servicemanagement. ITSM wordt gevolgd door bedrijven van elke omvang. ITIL stelt bedrijven in staat om IT-problemen en serviceverzoeken efficiënt af te handelen door duidelijke rollen en verantwoordelijkheden toe te wijzen. Het helpt individuen en organisaties om bedrijfsgroei en transformatie te realiseren. Het primaire doel van ITIL is het continu verbeteren van de manier waarop services voor IT-ondersteuning worden geleverd. Tegenwoordig wordt ITIL door veel organisaties breed toegepast om de bedrijfsvoering te stroomlijnen. Wat houdt ITIL in? ITIL omvat een verzameling processen die kunnen worden geïmplementeerd op basis van de behoeften en

volwassenheid van de organisatie. Ticketingsystemen op de servicedesk van IT en andere functies passen de best practices van ITIL toe om de processen en workflows te stroomlijnen.

6.2 Overzicht van de ITIL service levenscyclus

De ITIL service levenscyclus bestaat uit vijf fasen. Elke fase heeft een verzameling ITILprocessen en het is belangrijk om het doel van elk proces te begrijpen voordat u het implementeert.

Bedrijven kunnen echter selectief weinig processen implementeren die nodig zijn.

• Servicestrategie - Servicestrategie omvat een duidelijk begrip van de behoeften van de klant en de markt. Dit pleit voor een markt gestuurde langetermijnaanpak om IT-ondersteuning te leveren. Servicestrategie omvat strategiebeheer voor IT-services, serviceportfoliobeheer, vraagbeheer, financieel beheer voor IT-services en beheer van zakelijke relaties dat zich richt op klanttevredenheid.

• Serviceontwerp - Dit is een holistische benadering voor het ontwerpen van een ondersteunende dienst. De juiste aanpak voor serviceontwerp vertaalt zich in een hogere klanttevredenheid en bruikbaarheid. Sommige van de ITIL-processen in serviceontwerp

omvatten service level agreement, service catalogusbeheer, beschikbaarheidsbeheer en ITservice continuïteitsbeheer.

• Servicetransitie - Deze fase zorgt ervoor dat wijzigingen in de levenscyclus van de service met minimaal risico en impact worden afgehandeld, zodat er minimale of geen uitvaltijd is. Enkele van de processen hier zijn wijzigingsbeheer, release management, configuratiebeheerdatabase en kennisbeheer.

• Serviceproductie - ITIL serviceproductie zorgt voor een naadloze service in de dagelijkse bedrijfsactiviteiten. De daadwerkelijke levering en consumptie van diensten vinden in deze fase plaats. Dit heeft een directe invloed op de productiviteit van eindgebruikers. Typische processen zijn onder meer incidentbeheer, request fulfillment en probleembeheer.

• Continue Serviceverbetering - CSI streeft naar procesevaluatie en -verbetering gedurende de hele levenscyclus van de service. Dit is van toepassing op alle servicefasen, inclusief strategie, ontwerp, transitie en productie. In dit stadium vinden de definitie van meetwaarden en prestatiebeoordeling plaats, wat bedrijven helpt om het bestaande proces opnieuw te bekijken.

6.3 Overzicht van ITIL processen

Laten we enkele van de belangrijkste ITIL -processen en hun voordelen bespreken die vaak worden gebruikt in ticketingsystemen voor servicedesks.

Incidentbeheer

Het ticketingsysteem van de servicedesk is het enige aanspreekpunt voor eindgebruikers om elk probleem te melden dat van invloed is op hun normale routine. Incidentbeheer is gericht op een snel herstel van elke vorm van onderbreking aan services. Incidentbehee r stelt IT-teams in staat om incidenten snel op te lossen door meerdere kanalen te configureren en automatiseringen in te stellen om handmatig werk te verminderen. De processtroom voor incidentbeheer omvat incidentregistratie, classificatie, prioritering, onderzoek, diagnose, oplossing en afsluiting.

Probleembeheer

Het team voor Probleembeheer is verantwoordelijk voor het uitvoeren van een Root Cause Analysis (RCA) en het vinden van een permanente/tijdelijke oplossing voor terugkerende incidenten. Het wordt aanbevolen om een effectieve communicatiestrategie te hebben en een proactieve aanpak te volgen om grote incidenten te voorkomen. Een probleem bestaat uit een of meerdere incidenten met een onbekende hoofdoorzaak. Probleembeheer houdt een bekende foutenda tabase (“Known Error Database” of KEDB) bij waarvan de oplossing onbekend is.

Wijzigingsbeheer

Wijzigingsbeheer is verantwoordelijk voor de evaluatie en planning van een wijziging met minimaal risico en impact op het huidige ecosysteem. Het proces voor wij zigingsbeheer begint met

wijzigingsevaluatie, planning en het verkrijgen van de nodige goedkeuringen van de Change Advisory Board (CAB). Het werkt nauw samen met andere ITIL -modules zoals incidentbeheer en configuratiebeheer om infrastructuur en CI's te beheren die worden beïnvloed of gewijzigd.

Release Management

Nadat het wijzigingsbeheer is voltooid, wordt het gevolgd door release management met een specifiek implementatieschema. Het doorvoeren van wijzigingen gebeurt met behulp van het releasemanagementproces. De releaseplanning omvat een gedetailleerd bouw - en testplan. U moet ervoor zorgen dat de wijziging goed wordt getest en dat dit wordt gevolgd door een beoordeling na de implementatie als onderdeel van Doorlopende Serviceverbetering (Continual Serv ice Improvement , ofwel CSI).

Asset Management

Bedrijven hebben verschillende soorten activa (of: assets), waaronder IT - en niet-IT-activa.

Activabeheer volgt de configuratie van de activa, de status van de activa en de eigenaar van de activa. Dit verbetert het beheer en helpt bij audits van assets. Het beheer van de levenscyclus van activa zorgt ervoor dat activa worden gevolgd vanaf het moment dat ze in voorraad zijn tot het moment dat ze verwijderd worden, samen met de gemaakte kosten in elke fase. ROI -analyses van assets en contractverlenging worden efficiënter met asset management.

Serviceaanvraagbeheer

Bedrijven vervullen verschillende soorten serviceverzoeken, zoals onboarding, terugbetaling, verzoeken voor nieuwe hardware of software enz. Automatisch goedkeuringsbeheer voor serviceverzoeken elimineert handmatige tussenkomst en verbetert de tijd die nodig is om op te lossen. De servicecatalogus is een verzameling serviceartikelen die eindgebruikers een ervaring biedt die doet denken aan een digitaal winkelwagentje.

6.4 Fouten Bij ITIL Adoptie

De meeste bedrijven hebben de neiging om een van de onderstaande fouten te maken bij het implementeren van ITIL. Ze negeren vaak het grotere geheel en implementeren processen zonder enig doel. Dit leidt tot onnodige overhead en schept verwarring over het doel van deze processen.

• Gebrek aan Kennis en Visie over ITIL

• Aanname dat ITIL voldoet als naleving

• Gebrek aan initiële planning en evaluatie

• ITIL implementeren als een 'Big Bang' project

• Een one size fits all-benadering volgen

• Belanghebbenden niet betrekken bij de implementatie

6.5 Wanneer moet u het ITIL proces implementeren?

Er is geen goed of fout moment om een ITIL -proces te implementeren, omdat het volledig afhangt van de zakelijke behoeften en prioriteiten. Voordat u een ITIL-proces implementeert, moet u begrijpen wat de doelstellingen zijn en welke problemen u probeert op te lossen. Begin klein bij het implementeren van ITIL-processen door een gefaseerde aanpak te volgen in plaats van een big bangimplementatie. Identificeer de kritieke functie en implementeer om te beginnen kernprocessen zoals incidentbeheer, probleembeheer en wijzigingsbeheer. Een continue evaluatie van processen is belangrijk om ervoor te zorgen dat de doelen van het proces compatibel zij n met bedrijfsdoelen. Zorg ervoor dat proceseigenaren worden geïdentificeerd en toegewezen met duidelijke rollen en verantwoordelijkheden.

6.5.1 De Rol van ITIL in ITSM

ITIL is een katalysator voor IT Service Management (ITSM). Twijfelt u of uw organisatie een I TILservicedesk nodig heeft of niet? Hier is een lijst met de primaire redenen om een op ITIL gebaseerd servicedesk ticketingsysteem te implementeren. Sommige bedrijven kunnen ervoor kiezen om slechts een gedeelte van deze processen te gebruiken

• Naadloze dienstverlening en werkzaamheden

• Beheer de chaos binnen uw organisatie

• Betere afstemming van IT-processen met de visie van het bedrijf

• Neem weloverwogen beslissingen

• Minder kosten en middelen

Checklist voor een succesvolle implementatie van ITIL

• Begrijp de doelen van ITIL-processen voordat u deze implementeert

• Begin klein door de noodzakelijke processen te implementeren

• Meet prestatieverbetering, herdefinieer de processen van het ticketingsysteem van de servicedesk indien nodig

• Breid de best practices van de ITIL servicedesk uit naar andere teams

6.6 Hoe past ITIL binnen de organisatorische structuur van IT?

Het is over het algemeen een mythe dat de implementatie van ITIL een organisatorische herstructurering vereist. Maar in werkelijkheid vereist het adopteren van het ITIL-proces inzicht in de huidige organisatiestructuur en het implementeren van de vereiste processen. Begin met ITIL serviceproductie, inclusief incidentbeheer, probleembeheer en beheer van serviceverzoeken. Stel dynamische teams samen om effectief samen te werken en stel duidelijke rollen en

verantwoordelijkheden vast voor elk lid. Het implementeren van ITIL verstoort het huidige ecosysteem niet, het verbetert eerder de transparantie en verhoogt de algehele efficiëntie van het team. Het is belangrijk om uw IT-team in te delen in verschillende groepen op basis van expertise, zodat er duidelijke doelen worden gesteld.

Helpdesk vs servicedesk

Een helpdesk heeft tot doel problemen op te lossen en systemen te herstellen naar normale werk ing. Een helpdesk is meestal reactief, ontvangt problemen van eindgebruikers en biedt een oplossing.

Voor een helpdesk zijn het aantal opgeloste tickets belangrijk en de tijd die nodig is om ze op te lossen. Een helpdesk is het gezicht van de IT-ondersteuning en handelt voornamelijk tactische werkzaamheden af. Een servicedesk is verantwoordelijk voor de volledige IT-ondersteuning enservices, waaronder beheer van serviceverzoeken, wijzigingsbeheer en asset management. Een servicedesk is strategisch en werkt samen met andere functionele eenheden om de ondersteuning te stroomlijnen. Een servicedesk volgt een holistische benadering om de visies van het bedrijf en de IT op elkaar af te stemmen. Proactief probleembeheer wordt uitgevoerd om grote incidenten te voorkomen. Een servicedesk is een uitbreiding van de helpdesk met een uitgebreide verzameling functies en streeft naar uitmuntende dienstverlening.

6.7 ITIL implementatie op kleine schaal

ITIL is niet specifiek ontworpen voor een branche of organisatie. Kleinschalige branches kunnen ook relevante processen vanuit het ITIL-raamwerk implementeren. Volg een stapsgewijze aanpak voor ITIL-implementatie op kleine schaal. Voor kleinschalige branches zijn kosten een belangrijke factor om te overwegen. Daarom is het belangrijk om klein te beginnen en alleen de noodzakelijke processen te implementeren. Zorg ervoor dat de langetermijnvisie voor elke belanghebbende duidelijk is tijdens de kleinschalige implementatie van ITIL. Er zijn veel iteraties van ITIL -versies. ITIL v3 is een uitbreiding van v2 met meer focus op strategie en uitvoering. ITIL v3 volgt een servicelevenscyclus en beveelt een servicegericht raamwerk aan, terwijl ITIL v2 zich meer op processen richt. ITIL v3 volgt een geïntegreerde aanpak, terwijl v2 een tradi tionele teamstructuur met eilandjes volgt.

7 IT-Dienstverlening

Het doel van de service level management praktijk is om duidelijke bedrijfsgebaseerde doelen te stellen voor dienstverleningsniveaus, en ervoor te zorgen dat de levering van diensten naar be horen wordt beoordeeld, bewaakt, en beheerd tegen deze doelstellingen.

Service level management biedt end-to-end zichtbaarheid van de diensten van de organisatie. Om dit te bereiken, service level management:

- creëert een gedeeld beeld van de diensten en de beoogde serviceniveaus met klanten

- zorgt ervoor dat de organisatie voldoet aan de gedefinieerde service levels door het verzamelen, analyseren, opslag, en rapportage van de relevante metrieken voor de geïdentificeerde diensten

- voert service reviews uit om ervoor te zorgen dat de huidige set van diensten blijft voldoen aan de behoeften van de organisatie en haar klanten

- registreert en rapporteert over serviceproblemen, inclusief prestaties ten opzichte van de gedefinieerde serviceniveaus.

De vaardigheden en bekwaamheden voor service level management omvatten relatiebeheer, bedrijfsliaison, bedrijfsanalyse, en commercieel/leveranciersbeheer. De praktijk vereist pragmatische focus op de gehele dienst en niet alleen op de samenstellende delen; bijvoorbeeld, eenvoudige individuele metrieken (zoals het percentage systeembeschikbaarheid) mogen niet worden opgevat als representatief voor de gehele dienst.

Definitie Service Level Agreement

Een gedocumenteerde overeenkomst tussen een dienstverlener en een klant waarin zowel de vereiste diensten en het verwachte niveau van dienstverlening beschreven staan.

Service Level Agreements (SLA's) worden al lang gebruikt als een instrument om de prestatie van diensten te meten vanuit het oogpunt van de klant, en het is belangrijk dat zij worden overeengekomen in de bredere bedrijfscontext. Het gebruik van SLA's kan veel uitdagingen met zich meebrengen; vaak weerspiegelen zij niet volledig de bredere dienstprestaties en de gebruikerservaring.

Enkele van de belangrijkste vereisten voor succesvolle SLA's zijn:

- Ze moeten gerelateerd zijn aan een gedefinieerde 'service' in de service catalogus; anders zijn het gewoon individuele metrieken zonder doel, die niet voldoende zicht bieden of het dienstperspectief reflecteren.

- Ze moeten betrekking hebben op gedefinieerde resultaten en niet louter op operationele maatstaven. Dit kan worden bereikt met evenwichtige bundels van metrieken, zoals klanttevredenheid en belangrijke bedrijfsresultaten.

- Zij moeten een "overeenkomst" weerspiegelen, d.w.z. betrokkenheid en discussie tussen de dienstverlener en de afnemer van de dienst. Het is belangrijk om alle belanghebbenden erbij te betrekken, met inbegrip van partners, sponsors, gebruikers en klanten.

- Ze moeten eenvoudig geschreven zijn en voor alle partijen gemakkelijk te begrijpen en te gebruiken zijn.

In veel gevallen kan het gebruik van op één systeem gebaseerde maatstaven als doelstellingen resulteren in verkeerde afstemming en een disconnectie tussen s ervicepartners over het succes van de serviceverlening en de gebruikerservaring. Als een SLA bijvoorbeeld alleen is gebaseerd op het percentage uptime van een service, kan de dienstverlener deze als succesvol beschouwen, maar toch voorbij gaan aan belangrijke bedrijfsfunctionaliteiten en resultaten die belangrijk zijn voor de consument. Dit wordt het "watermeloen-SLA"-effect genoemd.

Service level management vereist focus en inspanning om te luisteren naar de eisen, problemen, zorgen, en dagelijkse behoeften van klanten:

- Betrokkenheid is nodig om de werkelijke lopende behoeften en eisen van klanten te begrijpen en te bevestigen aan klanten, niet simpelweg wat wordt geïnterpreteerd door de dienstverlener of wat een aantal jaren eerder is overeengekomen.

- Luisteren is belangrijk als relatie- en vertrouwensopbouwende activiteit, om klanten te tonen dat zij worden gewaardeerd en begrepen. Dit helpt om de dienstverlener af te leiden van het altijd in de 'oplossingsmodus' te staan en nieuwe, constructievere partnerschappen op te bouwen.

De activiteiten van betrekken en luisteren bieden een geweldige kans om betere relaties op te bouwen en om zich te concentreren op wat echt moet worden geleverd. Het geeft dienstverlenend personeel ook een op ervaring gebaseerd begrip van het dagelijkse werk dat wordt gedaan met hun technologie, waardoor ze in staat zijn om een meer bedrijfsgerichte service te leveren.

Service level management omvat het verzamelen en analyseren van informatie uit een aantal bronnen, waaronder:

- Klantbetrokkenheid Dit omvat in eerste instantie luisteren, ontdekken, en informatie vastleggen waarop metrieken, metingen en voortdurende voortgangsbesprekingen kunnen worden gebaseerd. Overweeg om klanten een aantal eenvoudige open vragen te stellen, zoals:

- Wat houdt uw werk in?

- Hoe helpt technologie u?

- Wat zijn uw belangrijkste zakelijke momenten, gebieden, mensen en activiteiten?

- Wat onderscheidt een goede dag van een slechte dag voor u?

- Welke van deze activiteiten is het belangrijkst voor u?

- Wat zijn uw doelen, doelstellingen en metingen voor dit jaar?

- Wat is de beste maatstaf voor uw succes?

- Waarop baseert u uw mening en evaluatie van een dienst of IT/technologie?

- Hoe kunnen we u nog beter helpen?

- Feedback van klanten Deze wordt idealiter verzameld uit een aantal bronnen, zowel formele als informele, waaronder:

- Enquêtes Deze kunnen afkomstig zijn van onmiddellijke feedback, zoals follow -upvragen naar incidenten, of uit meer reflectieve periodieke enquêtes die feedback peilen over de algehele service-ervaring. Beide zijn gebaseerd op gebeurtenissen.

- Belangrijke bedrijf gerelateerde maatregelen Dit zijn maatregelen die zijn overeengekomen tussen de dienstverlener en zijn klant, op basis van wat de klant belangrijk vindt. Dit kan een bundel SLA-metrieken zijn of een zeer specifieke bedrijfsactiviteit, zoals een transactie, projectafronding, of een operationele functie zoals een ambulance op de plaats van een ongeval binnen x minuten.

- Operationele metrieken Dit zijn de low-level indicatoren van diverse operationele activiteiten en kunnen zijn: systeembeschikbaarheid, respons- en hersteltijden bij incidenten, verwerkingstijden van wijzigingen en verzoeken verwerkingstijden, en systeemreactietijden.

- Bedrijfsstatistieken Dit kan elke bedrijfsactiviteit zijn die door de klant als nuttig of waardevol wordt beschouwd en wordt gebruikt als middel om het succes van de dienst te meten. Dit kan variëren van enkele eenvoudige binaire metingen van transacties, zoals de beschikbaarheid van geldautomaten of betaalterminals tijdens kantooruren uren (09:00-17:00 dagelijks) of succesvolle voltooiing van bedrijfsactiviteiten zoals het check-in.

Zodra deze feedback is verzameld en geordend voor voortdurende evaluatie, kan hij worden gebruikt als input voor het ontwerpen van geschikte meet- en rapporteringsmodellen en -praktijken.

7.1 SLA

Service Level Agreements (SLA's) zijn een belangrijk onderdeel van IT Service Management (ITSM). SLA's zijn overeenkomsten die bepalen wat gebruikers en klanten van de IT-services mogen verwachten; ze definiëren doelen voor leveranciers en ze voorzien leveranciers, klanten en belanghebbenden van regelmatige informatie over hoe de diensten aan deze verwachtingen voldoen. Deze informatie wordt gebruikt om verbeteringen te stimuleren. Het ge bruik van SLA's kan effectieve werkrelaties tussen IT en het bedrijf ondersteunen, aangezien beide betrokken moeten zijn bij het maken, onderhouden en gebruiken van SLA's. Service Level Management is het proces dat verantwoordelijk is voor SLA's in een organisatie.

7.2 De basis van SLA

7.2.1 Wat is een SLA?

Een Service Level Agreement is een formele, gestructureerde overeenkomst tussen twee partijen om een of meer diensten te leveren op een onderling overeengekomen niveau. Een van de partijen is altijd de klant van de dienstverlening. De wederpartij is de leverancier die de diensten levert. Een leverancier kan onderdeel zijn van dezelfde organisatie als de klant (dienstverlener) of in een andere organisatie (extern). De SLA kan een fysiek of elektronisch document zijn. Personen van beide partijen met een passende bevoegdheid moeten het document ondertekenen. Het breidt de definitie van een service uit ten opzichte van de definitie in de servicecatalogus en biedt een overeengekomen en gegarandeerd minimumniveau van serv iceprestaties.

7.2.2 Wat staat er in een SLA?

Een SLA beschrijft de services die het omvat, de reikwijdte van de services; de kenmerken van de service, inclusief de uren waarop deze beschikbaar is en de uren die worden ondersteund; de doelstellingen voor deze services (ook wel serviceniveaus genoemd) en de verantwoordelijkheden van beide partijen, inclusief verantwoordelijkheden voor beoordeling en onderhoud van de inhoud. Het kan ook een prijsmodel bevatten, met eventuele kosten voor het gebruik van de service e n boetes die moeten worden betaald voor het niet voldoen aan de serviceniveaus. De SLA moet worden geschreven vanuit het standpunt van de klant, om begrip te vergemakkelijken.

7.2.3 Wat is een Onderliggend contract?

Een Onderliggend Contract (“Underpinning Contract” of UC) beschrijft een contract tussen een klant en een leverancier, inclusief SLA's voor de geleverde diensten. Het UC zal ook contractuele clausules bevatten die niet rechtstreeks verband houden met de serviceniveaus, zoals het gebruik van onderaannemers, technische normen die vereist zijn van de leverancier en wie de intellectuele eigendomsrechten voor de services bezit. Voor elke vereiste in een contract is het een goede gewoonte om aan te geven wat er zal gebeuren als niet aan de vereiste wordt voldaan. Het opnemen van streefdoelen voor naleving in SLA's is een nuttig mechanisme, aangezien naleving kan worden gemeten en gerapporteerd. Dit kan doelen omvatten voor het indienen van wijzigingsverzoeken binnen een bepaalde tijdsperiode, het bijwonen van servicebeoordelingsbijeenkomsten en het naleven van beleid voor kennisoverdracht. Het gebruik van SLA's biedt een hoger profiel voor eventuele storingen en kan leiden tot financiële sancties als deze zijn gedefinieerd.

7.2.4

SLA, OLA of UC?

Deze verschillende termen kunnen verwarrend zijn, vooral voor degenen die niet gekwalificeerd zijn in ITSM (waarin ze voorkomen). Het is belangrijk om te onthouden dat er altijd een formele overeenkomst moet zijn over de serviceniveaus die een leverancier aan een klant levert , welke

gedocumenteerd is in een SLA. Zo weet de klant wat hij of zij kan verwachten en weet de leverancier wat hij moet leveren. De term is niet zo belangrijk; als het maar gebruikt wordt. Veel organisaties gebruiken de term SLA gewoon om naar al deze drie varianten van service level agreement te verwijzen. Dat kan de gesprekken tussen alle partijen, vooral die buiten ITSM, aanzienlijk vereenvoudigen, aangezien de meeste mensen het concept van serviceniveaus begrijpen. Het gebruik van de term SLA tijdens het gesprek leidt eerder tot succes bij het gebruik van ITSM. In de rest van deze cursus zal deze term worden gebruikt voor alle drie de soorten overeenkomsten, inclusief die met interne leveranciers en degenen die deel uitmaken van een contract met externe leveranciers.

7.3 Voordelen van SLA’s

Goed ontwikkelde en geïmplementeerde service level agreements kunnen de klant, de gebruikers en de leveranciers, inclusief interne IT, ten goede komen. Deze voordelen worden het best gerealiseerd door zorgvuldig ontwerp, geplande implementatie, actief gebruik en voortdurende verbetering. Enkele voordelen van SLA's zijn:

• Ze helpen bij het garanderen van goede dienstverlening en tevreden klanten

• Ze bieden eindgebruikers een verwachting over de kwaliteit van de service die ze gaan krijgen

• Ze helpen bij het voorkomen van misverstanden of verwarring over wat er gedaan moet worden

• Ze bieden een vertrouwde bron van informatie voor de overeenkomst

• Ze zorgen dat de klant en de leverancier attent zijn op de details van de services

• Ze beschermen leveranciers tegen onduidelijke en niet vermelde eisen

7.3.1 Welk proces wordt gebruikt voor het beheren van SLA’s?

Een Service Level Management (SLM) is het proces dat onderhandelt over SLA's tussen de klant en de leverancier en erop gericht is dat deze worden nagekomen. Een SLM moet ervoor zorgen dat alle andere processen die worden gebruikt in ITSM-ondersteuning de overeengekomen serviceniveaus bereiken. Dit omvat het controleren of alle SLA's de overeengekomen serviceniveau -doelen kunnen ondersteunen, inclusief die in OLA's en UC's. Service level management bewaakt en rapporteert over de serviceniveaus die zijn vastgelegd in de overeengekomen SLA's, voert regelmatig servicebeoordelingen uit met klanten en leveranciers, identificeert de vereiste verbeteringen en rapporteert vervolgens over verbeteracties. SLM moet worden uitgevoerd bij zowel de klant als de leveranciers.

7.3.2 Hoeveel SLA's moet een organisatie hebben?

Het is een goede gewoonte voor een organisatie om één SLA per leverancier te hebben, die alle diensten omvat die de leverancier levert. Dit vereenvoudigt de totstandkoming van de overeenkomst, aangezien de algemene vereisten hetzelfde zijn en de diensten vaak dezelfde serviceniveaus hebben. De SLA kan vervolgens worden bijgewerkt om nieuwe services toe te voegen of oude services te verwijderen. Er is geen limiet voor het aantal services in één overeenkomst. Het is een goede gewoonte om ervoor te zorgen dat er voor elke leverancier SLA's bestaan, ook voor interne leveranciers. Dit helpt ervoor te zorgen dat de verwachtingen van de klant expliciet worden vermeld en dat de leveranciers ze begrijpen, en de klant op zijn beurt begrijpt welke service hij kan verwachten.

7.4 SLA Procesbeheer

7.4.1 Wat is een SLA met meerdere niveaus?

Een SLA met meerdere niveaus is een structuur die wordt gebruikt om duplicatie te voorkomen en de frequentie van updates van de SLA's te verminderen, terwijl het de flexibiliteit biedt om ze aan te passen aan specifieke klanten en diensten. Het gebruik van een SLA-structuur met meerdere niveaus is typisch voor het documenteren van serviceniveaus wanneer de leveranciers zich binnen dezelfde organisatie bevinden. Het kan ook bijzonder nuttig zijn wanneer een externe leverancier meerdere diensten aanbiedt, die meestal gemeenschappelijke vereisten delen, maar waar bepaalde diensten andere serviceniveaus of vereisten hebben, zoals 24/7 ondersteuningsvereisten. Een typische SLAstructuur met meerdere niveaus bestaat uit drie niveaus:

• Zakelijk niveau, dat betrekking heeft op vereisten die elke klant binnen een bedrijf gemeen heeft. Een voorbeeld is een SLA voor elke gebruiker van een e -mailsysteem, waarbij wachtwoorden elke 30 dagen gewijzigd kunnen worden.

• Klantniveau, dat betrekking heeft op vereisten die specifiek zijn voor een bepaalde klant of een verzameling klanten binnen een bedrijf, inclusief alle diensten die eraan worden geleverd. Een voorbeeld is een standaard servicebeschikbaarheid voor alle diensten die aan één klant worden geleverd.

• Serviceniveau, met vereisten voor specifieke diensten. Dit is het laagste niveau en kan worden gebruikt als een specifieke dienst andere eisen en serviceniveaus heeft dan de standaard voor het bedrijf of een klant.

7.4.2

Wie is de klant binnen een SLA?

De klant is de persoon of organisatie die de diensten gebruikt. De klant kan intern of extern zijn aan de organisatie. Alle bedrijven leveren diensten aan externe klanten. Dit kunnen services zijn die op IT zijn gebaseerd, zoals cloudgebaseerde applicaties, of niet-IT-services, zoals een callcenter voor vakantieboekingen. De klant van de service kan een individu of een ander bedrijf zijn. Zelfs als het voor externe klanten niet praktisch is om een overeenkomst formeel te ondertekenen, moeten er toch SLA's worden gemaakt, omdat ze een duidelijke en nauwkeurige beschrijving geven van wat de klant kan verwachten en omdat ze verbeteringen van de servicekwaliteit stimuleren.

7.4.3 Welke soorten diensten moeten onderdeel

zijn van een SLA?

SLA's kunnen nuttig zijn wanneer er behoefte is aan een formele overeenkomst tussen twee partijen, met gedetailleerde informatie over het verwachte serviceniveau en de bijbehorende verantwoordelijkheden. ITSM heeft traditioneel gezien alleen IT-services opgenomen in SLA’s, inclusief de servicedesk. Serviceniveaus en de bijbehorende overeenkomsten moeten echter in feite voor elk type service worden gebruikt. Dit kunnen onder meer arbeidsgerelateerde diensten zijn, zoals het bieden van consultancy; ondersteunende diensten, zoals het leveren van verbruiksartikelen en technische, niet-IT-diensten, zoals ondersteunende brandalarmsystemen. SLA's kunnen ook worden gebruikt voor procesgerelateerde activiteiten waarbij de naleving moet worden gedefinieerd, bewaakt en gemeten. Dit kan bestaan uit het bijwonen van formele vergaderingen, streefdoelen voor het reageren op klachten en het halen van deadlines voor het indienen van facturen.

7.5 SLA’s monitoren en rapporteren

Het behalen van elk serviceniveau dat in de overeenkomst is vastgelegd, moet worden gecontroleerd en gerapporteerd. Hoe dit wordt bereikt, hangt af van de precieze aard van het serviceniveau. De methode en de frequentie van monitoring moeten worden gedefinieerd en gedocumenteerd in de SLA. Evenzo moeten de methode, het formaat en de frequentie van de rapportage over het bereike n

van het serviceniveau worden vastgelegd in de SLA. Voor ingewikkelde doelen en doelen waarbij sancties bestaan als ze niet behaald worden, is het een goede gewoonte om alle berekeningen te testen voordat ze live gaan. Rapporten moeten automatisch worden geproduceerd op basis van de gegevens die tijdens de monitoring zijn vastgelegd, omdat dit een nauwkeurig beeld geeft van de werkelijke SLA-prestatie. Er moeten vaak genoeg rapporten worden opgesteld om trends in SLAprestaties te herkennen en benadrukken voordat er fouten optreden en ook om vertrouwen in het proces te wekken. Tijdens de vroege stadia van een service kan er een wekelijkse rapportage worden gebruikt om te controleren of alle processen, systemen enz. werken zoals verwacht. Het rapporteren aan klanten kan worden teruggebracht tot een maandelijks interval en zelfs driemaandelijks als het vertrouwen wordt gewonnen in zowel de diensten als de leverancier; een goede leverancier rapporteert intern echter vaker om problemen te herkennen voordat de SL A-doelen worden overtreden.

7.6 Sancties voor het niet voldoen aan SLA's

Wanneer SLA's zijn opgenomen in een onderliggend contract met leveranciers, is het standaardpraktijk om boetes op te nemen voor services die niet volgens de overeengekomen niveaus worden geleverd. De boete kan een vast bedrag zijn voor elke storing of een variabel bedrag afhankelijk van hoeveel het doel is overtreden. Het is erg belangrijk om de boetes in te stellen op een niveau dat geschikt is voor de impact van de niet-naleving op het bedrijf. Het instellen van te hoge SLA-boetes kan ertoe leiden dat leveranciers de overeenkomst niet ondertekenen of vragen om het contract vroegtijdig te beëindigen. Om dezelfde reden moeten partijen overeenkomen een sanctieplafond vast te stellen wanneer een variabel bedrag voor sancties is opgenomen. Wanneer het totaal van de boetes gedurende een periode dit plafond bereikt, worden er geen boetes meer opgelegd. Dit kan er echter toe leiden dat de leverancier niet wordt gestimuleerd om de storingen te verhelpen wanneer de limiet is bereikt. Dit kan worden verholpen door een "herhaal -faal"mechanisme in de SLA, waarbij de financiële sanctie wordt verhoogd als de limiet gedurende twee of meer opeenvolgende perioden wordt bereikt.

7.7 Hoe gebruik te maken van een service level agreement: de basis

Het is belangrijk om de details van de SLA-overeenkomst consistent te gebruiken en toe te passen. Serviceniveauprestaties moeten worden gerapporteerd en beoordeeld tussen de klant en de leverancier. Als er niet wordt voldaan aan de overeengekomen serviceniveaus, bestaat de mogelijkheid om deze open te breken, of wanneer een van de partijen hun in de SLA gedocumenteerde verantwoordelijkheden niet is nagekomen, moeten ze overeenstemming bereiken over de maatregelen die moeten worden genomen om de redenen te onderzoeken en op te lossen. Als er sancties zijn voor mislukking, moeten deze routinematig worden toegepast. Een van de meest voorkomende redenen voor het schenden van SLA's met externe leveranciers is inconsistentie en er niet voor zorgen dat de details van de SLA-overeenkomst ook daadwerkelijk plaatsvinden. Dit omvat

onder meer het opstellen van rapporten in het overeengekomen formaat en deze leveren volgens de planning, en het toepassen van boetes wanneer deze veroorzaakt worden door schendingen. Gebeurt dit niet, dan zal de leverancier eerder tegen de klant ingaan wanneer deze uiteindelijk besluit om de service level agreement toe te passen. Als beide partijen problemen met de overeenkomst erkennen, kan de SLA worden gewijzigd met dezelfde aanpak als voor de totstandkoming ervan.

7.8 SLA’s in de Praktijk

7.8.1 Wat is de rol van SLA’s in een bedrijf?

Gebruikers verwachten te weten welk serviceniveau ze zullen ontvangen. Ze zijn misschien pas geïnteresseerd als ze problemen ondervinden, maar het is nog steeds een goede gewoonte om dit in een SLA op te nemen, zodat de inhoud wordt gepresenteerd op een manier die gebruikers kunnen begrijpen. SLA's helpen een bedrijf om zijn leveranciers te beheren door hun verwachte prestaties vast te stellen. Er is een risico voor een bedrijf dat zijn SLA's aan externe klanten publiceert zonder ervoor te zorgen dat aan de serviceniveaus kan worden voldaan. Klanten beschouwen deze serviceniveaus als beloften en worden snel ontevreden als er niet aan voldaan wordt. Zelfs één fout kan al leiden tot een afname van klantloyaliteit.

7.9 SLA’s in het digitale tijdperk

Wanneer een bedrijf dezelfde online diensten aanbiedt aan meerdere individuele klanten en gebruikers buiten de organisatie, bijvoorbeeld een financiële instelling die online bankdiensten aanbiedt, is er meestal één SLA voor alle klanten, met een beschrijving van de diensten en doelen die zij zullen ontvangen. Het zal niet mogelijk zijn om van al deze klanten toestemming te krijgen, dus wordt een SLA van dit type doorgaans overeengekomen met een vertegenwoordiger, zoals de interne producteigenaar in het bedrijf voor die diensten. Als er een gebruikersgroep is voor de diensten, moet deze worden geraadpleegd over de vereisten voor de serviceniveaus; het ka n echter een uitdaging zijn om consensus en overeenstemming over de definitieve SLA te verkrijgen.

7.9.1 SLA’s en geleverde diensten vanuit de cloud

Leveranciers die diensten via de cloud aanbieden, moeten nog steeds SLA's gebruiken, omdat deze hun klanten een garantie bieden voor het serviceniveau dat ze kunnen verwachten. Dit kan het bedrijf concurrentievoordeel opleveren. De meeste cloudproviders bieden alle klanten dezelfde standaard SLA met gemeenschappelijke serviceniveaus. Sommige bieden verbeterde ondersteuningsniveaus in gelaagde "Gouden/Zilveren/Bronzen" SLA's, waarbij de klant betere serviceniveaus ontvangt als de klant een hogere vergoeding betaalt. Klanten die cloudservices kopen, moeten over het algemeen de aangeboden serviceniveaus accepteren. Het is onwaarschijnlijk dat een cloudleverancier een SLA speciaal voor hen aanpast.

7.10 De SLA opnieuw uitvinden

Sommige organisaties richten zich meer op het serviceniveau van hun individuele IT -services dan op de service die klanten daadwerkelijk ontvangen. Dit leidt vaak tot het zogenaamde 'watermeloen'effect, waarbij de SLA-statistieken laten zien dat alles goed is ('groen'), maar de klant is niet tevreden ('rood'). Een typisch voorbeeld is wanneer servicerapporten aantonen dat aan alle servicen iveaus wordt voldaan, ook al hadden de services tijdens de werkdag ongeplande downtime. Dit komt meestal omdat de serviceniveaus zijn ontworpen vanuit een IT -perspectief, kijkend naar één ITservice tegelijk. Dit kan worden voorkomen met een techniek die b ekend staat als 'Outside in'. SLA's moeten in eerste instantie worden ontworpen vanuit het perspectief van de klant, kijkend naar de services die ze gebruiken en de zakelijke vereisten voor een goede service. De serviceniveaus voor de IT en aanverwante services, zoals de servicedesk, moeten vervolgens worden ontworpen om aan deze zakelijke vereisten te voldoen. Dit resulteert in serviceniveaus die zowel de klantervaring als de individuele IT en andere services weerspiegelen die de ervaring creëren.

7.11 SLA's ge bruiken om het risico van niet -naleving van de wetgeving inzake gegevensbescherming te

beheersen

Service level agreements kunnen u helpen om te voldoen aan de wetgeving inzake gegevensbescherming, zoals de AVG. Naast het specificeren van doelen voor tradit ionele ITSMserviceniveaus, zoals beschikbaarheid, moeten SLA's ook doelen bevatten voor andere soorten vereisten, waaronder beveiliging. Met een doel kunt u de naleving meten. Dit kan zo simpel zijn als een serviceniveau om te reageren op verzoeken om toe gang tot een onderwerp, bijvoorbeeld wanneer een persoon de opgeslagen gegevens over zichzelf wil weten. Dit is vooral belangrijk als u externe leveranciers gebruikt om uw zakelijke diensten te verlenen.

7.12 Best practices voor het implementeren en uitvoeren

v an SLA's

De inhoud van een SLA zal evolueren vanuit de service level requirements (SLR's) die zijn gemaakt tijdens het eerste ontwerp van een service. Deze inhoud moet ondubbelzinnig zijn en geschreven in een makkelijk te begrijpen stijl. Hoewel ze deel uitmaken van een contract als de leverancier extern is, moeten ze het gebruik van juridische taal en terminologie vermijden. Er zijn verschillende stappen om een SLA te maken:

1. Documenteer doelen en mogelijkheden

De klant moet definiëren wat hij of zij nodig heeft in een verzameling Service Level Requirements, inclusief de servicegebruikers; kriticiteit voor gebruikers en de organisatie; beschikbaarheidsuren van de service; uren voor serviceondersteuning; kritieke periodes; maximale uitvaltijd; beveiligings - en gegevensbeschermingsvereisten; rapportagevereisten; en alle verplichte wettelijke, beleids - of normvereisten. Eerder overeengekomen SLA's kunnen als uitgangspositie worden gebruikt.

De leverancier moet definiëren wat hij kan leveren, inclusief de systemen die hij van plan is te gebruiken, ondersteuningsregelingen, uren van beschikbaarheid en ondersteuning, hoe toegang te krijgen tot ondersteuning, doelen voor foutoplossing, beschikbaarheid en prestaties, beschikbare rapporten, regelingen voor noodherstel en beveiligingsregelingen. Een leverancier heeft waarschijnlijk een standaard SLA die hij wil gebruiken.

2. Kweek wederzijds begrip

Een facilitator, zoals een service level manager, moet worden gebruikt om de klant en leverancier uit te nodigen voor een workshop. Het doel is dat beide partijen begrijpen wat er nodig is en wat mogelijk is voordat de SLA wordt opgesteld.

De facilitator moet opmerken waar er een sterke match is. Als er verschillen moeten worden opgelost, moet de facilitator discussies aanmoedigen om een oplossing te vinden.

3. Maak concept-SLA’s

Iemand die bekwaam en ervaren is in het ontwerpen van service level agreements moet de SLA, leverancierscapaciteiten, de aantekeningen uit de workshop en de eigen ervaring gebruiken om concept-SLA's te maken.

Alle openstaande items moeten worden toegevoegd aan een actielijst.

4. Onderhandel over SLA’s

Vertegenwoordigers van de klant en de leverancier moeten bijeenkomen om de SLA af te ronden, inclusief het onderhandelen over eventuele openstaande punten voor een onderlinge overeenkomst.

Dit moet de definitie bevatten van alle rapporten, inclusief de productiefrequentie en hoe ze zullen worden gepubliceerd.

Als er over een punt geen overeenstemming kan worden bereikt, moet de kwestie voor bespreking en overeenstemming worden geëscaleerd naar beide organisaties.

Een SLA moet niet ondertekend worden totdat beide partijen het eens zijn met de volledige inhoud.

5. Onderteken en communiceer de overeenkomst

Beide partijen moeten de overeenkomst formeel ondertekenen.

Het moet vervolgens worden gecommuniceerd aan iedereen binnen beide organisaties die hiervan op de hoogte moet zijn, en beschikbaar worden gesteld voor toekomstige verwijzing en herziening.

6. Gebruik en beoordeel de SLA

Het heeft geen zin om overeenstemming te bereiken over SLA's die dan niet worden gebruikt. Wat is afgesproken moet gebeuren.

Beide partijen moeten SLA's minstens jaarlijks herzien, aangezien de eisen van klanten en de capaciteiten van leveranciers kunnen veranderen.

7.13 Voorbeeldsjabloon voor SLA's

Een organisatie gebruikt normaal gesproken een standaardsjabloon voor alle SLA's. Dit faciliteert gemeenschappelijk begrip bij degenen die de serviceniveaus in ITSM, IT en de organisatie van de klant moeten begrijpen. Het maakt vergelijking van SLA-prestaties tussen verschillende dienstverleners ook mogelijk. Een standaardsjabloon is wellicht niet mogelijk bij leveranciers die goederendiensten leveren waarbij de klant het formaat moet accepteren dat de dienstverlener gebruikt. Een typische SLA-sjabloon bevat de items in de volgende tabel:

Namen van diensten

• De naam (namen) waaronder de dienst(en) bekend is/zijn, plus eventuele unieke referentiecode(s) die deze verbindt met de servicecatalogus/CMDB

Goedkeuringsinformatie

• Handtekeningen ter goedkeuring van de klant en de leverancier

• De datum waarop de SLA ondertekend is

Gerelateerde contractuele informatie

(niet vereist voor OLA’s)

• Gerelateerde contractnummers

• Start-, einde- en beoordelingsdatum

• Regels voor vernieuwing en beëindiging van de overeenkomst, inclusief vroegtijdige beëindiging

Korte omschrijvingen van diensten

• Voldoende informatie waarmee de lezer kan begrijpen wat de dienst(en) is/zijn

• Een omschrijving van de zakelijke activiteiten die door de dienst(en) en de SLA onders teund worden

• Wie de dienst(en) gebruikt

Gewenste resultaten van de SLA

• Een beschrijving van wat de SLA probeert te bereiken, inclusief de beoogde resultaten. Deze kunnen 'zacht' zijn, zoals gedragsveranderingen, maar ook 'hard', zoals altijd beschikbare services

Communicatie

• Verantwoordelijke persoon bij de klant, inclusief contactgegevens

• Verantwoordelijke persoon bij de leverancier, inclusief contactgegevens

• Procedures voor de omgang met uitzonderingen, escalaties, klachten en aanpassingen

• Procedures voor servicebeoordelingen voor de services die deze SLA omvat

• Vereisten en procedures voor tevredenheidsonderzoeken voor de services

Servicerapportage

• Aard en frequentie van rapporten, die prestaties tonen ten opzichte van SLA serviceniveaus

Servicebeoordelingen

• Aard en frequentie van servicebeoordelingen

• Vereiste aanwezigen bij servicebeoordelingen

• Voorzitter van servicebeoordelingen

• Procedures voor servicebeoordelingen voor de services die deze SLA omvat

Kriticiteit

• Hoe kritiek de service(s) zijn voor het bedrijf

• Alle kritieke bedrijfsfuncties die ondersteund worden door de service(s)

• Alle kritieke asset(s) die de service(s) gebruikt/gebruiken

Veiligheid

• Alle veiligheidseisen voor de service(s) en de SLA

Servicetijden

• Tijden waarop de service(s) beschikbaar moeten zijn

• Alle specifieke uitzonderingen zoals nationale feestdagen

Ondersteuningstijden

• Tijden waarop ondersteuning beschikbaar is voor de service(s)

• Alle specifieke uitzonderingen zoals nationale feestdagen

Ondersteuningsvereisten

• Waar incidenten gemeld moeten worden

• Alle andere vereisten voor specifieke locaties of gebruikersgroepen

Doelen voor serviceniveaus

• Doelen voor beschikbaarheid

• Doelen voor oplossingstijd

• Doelen voor prestaties

• Doelen voor beveiliging

• Doelen voor servicerapportage

• Alle andere doelen

Uitsluitingen

• Onderhoudsvensters

• Toegestane downtime

Servicecontinuïteit

• Vereisten voor servicecontinuïteit, inclusief een doel voor de benodigde tijd om de service te herstellen en de benodigde tijd om terug te keren naar gebruikelijke serviceniveaus

Technische standaarden

• Verplichte technische standaarden

• Alle technische interfaces

Verantwoordelijkheden

• Verantwoordelijkheden van de klant

• Verantwoordelijkheden van de gebruiker

• Verantwoordelijkheden van de leverancier

Prijsmodel (alleen als het gebruik van de service(s) in rekening wordt gebracht)

• Definitie van de prijs en hoe deze berekend wordt

• Regels voor het berekenen van sancties bij het niet naleven van de serviceniveaus

Wijzigingshistorie

• Versiegeschiedenis van de SLA met data en goedkeurders

Gerelateerde documenten

• Alle gerelateerde SLA-documenten in een structuur met meerdere niveaus

• Verwijzingen naar gerelateerde procedures die niet in dit document opgenomen zijn

Woordenlijst

• Omschrijving van de in het document gebruikte woorden

1 Servicelevels Beheer

1.1 Helpdesk

Indicator Omschrijving (indicator) en meetmethodiek

Minimale bezetting tijdens venstertijden

Venstertijden; Op werkdagen van 8.00 tot 17:30

1.2 Incident Management (eerste lijn)

Norm Verantwoordelijke Rapportage

Helpdesk <naam opdrachtnemer> 1 FTE

<naam opdrachtnemer>

Het registreren en terugmelden aan de gebruikers van incidenten.

Indicator Omschrijving (indicator) en meetmethodiek

Tijdigheid

Norm Verantwoordelij ke Rapportage

<naam opdrachtgever> kan garanderen dat het proces van melden, classificeren en terugmelden tijdig wordt uitgevoerd, zodat dit niet vertragend werkt in de totale oplostijd van incidenten.

De normen die gelden voor de <naam opdrachtgever> helpdesk met de gebruiker sorganisatie van de <naam opdrachtgever>.

<naam opdrachtgever>

1.3 Incident Management (tweede lijn)

Het classificeren, beheren en afhandelen van incidenten.

Indicator Omschrijving (indicator) en meetmethodiek Norm Verantwoordelij ke Rapportage

Reactietijd Binnenkomst incident bij helpdesk <naam opdrachtnemer> tot en met de terugmelding bij de Helpdesk van de <naam opdrachtgever>.

Afhandeltijd Vanaf de hierboven genoemde terugmelding tot en met het gereed melden van de helpdesk <naam opdrachtnemer> aan de helpdesk <naam opdrachtgever>.

Prioriteit 1 : 1 uur

Prioriteit 2 : 3 uur

Prioriteit 3 : 8 uur

Prioriteit 4 : 1 week

Prioriteit 1 : 8 uur

Prioriteit 2 : 40 uur

Prioriteit 3 : 2 mnd

Prioriteit 4 : 3 mnd

<naam opdrachtnemer>

<naam opdrachtnemer>

7.14 Service Catalog: altijd duidelijk overzicht

Een service catalog, oftewel een service catalogus, is een overzicht van alle diensten die een bedrijf zijn eigen teams of externe klanten aanbiedt.

7.14.1 Wat is een service catalog? – Betekenis

Een service catalog geeft een overzicht van alle diensten die een onderneming haar klanten, partners of interne teams aanbiedt. Dit gaat meestal in de vorm van een catalogus omdat veel klanten aangeven een dergelijke visuele vormgeving het duidelijkst te vinden. De service catalog kan verschillende elementen omvatten – bijvoorbeeld een online portal, een document, of een shopping-

pagina op de website. Voor klanten is het fijn dat ze duidelijk weten wat ze kunnen verwachten van het dienstenaanbod. Maar ook bedrijven hebben baat bij een service catalog doordat deze de klanttevredenheid verhoogt en helpt nieuwe mogelijkheden voor selfservice te identificeren.

7.14.2

Twee soorten service catalogs: ICT vs. business

Een service catalog kan in verschillende vormen en soorten gebruikt worden. Hoe een service catalog eruit komt te zien zal vooral liggen aan de specifieke behoeftes van de doelgroep en de gebruikers. Over het algemeen maken we onderscheid tussen twee soorten service c atalogs:

ITIL service catalog

Oorspronkelijk werd de IT service catalog ingevoerd als onderdeel van ITIL (IT Infrastructure Library) en bevatte deze diverse richtlijnen voor ITSM (IT Service Management). In de ITIL Life Cycle wordt de service catalog gedefinieerd als een grote database met accurate informatie over de huidige ITservices. Deze vormen een essentieel onderdeel van het service portfolio, waarin alle aangeboden diensten en producten worden opgeslagen. Ook geeft het service portfolio gebruikers i nzicht in welke producten niet meer op de markt zijn en welke binnenkort worden gelanceerd.

De technische service catalog wordt in de eerste plaats gebruikt door het IT -team en de dienstverleners. Het biedt inzicht in workflow- en beveiligingsinstellingen, zodat IT’ers de catalogus kunnen gebruiken om na te gaan of alle aangeboden diensten beschikbaar zijn en goed geleverd worden. Bovendien is de technische service catalog een essentieel instrument voor alle werknemers die verantwoordelijk zijn voor verschillende taken rondom het creëren, beheren en ondersteunen van de aangeboden diensten. Zonder een duidelijke service catalog is het vaak niet mogelijk om te zien hoe de afzonderlijke componenten samenhangen en elkaar beïnvloeden. De technische service catalog bevat dus onder meer:

• Workflows

• Handleidingen

• Procesbeschrijvingen

• Overzicht van klanten en service-eigenaren

• Configuraties

• Instructies

Business service catalog

De voornaamste gebruikers van de business catalog zijn de klanten van een bedrijf. Om een ove rzicht van het bedrijf te krijgen of om een specifieke dienst op te zoeken kunnen ze gebruik maken van de business service catalog. In veel gevallen hebben bedrijven zonder service catalogus moeite om duidelijk maken welke producten of diensten het bedrijf aanbiedt. Als de nodige informatie ontbreekt, kunnen veel klanten moeilijk een keuze maken voor een dienst. Hoe beter en duidelijker de diensten worden gepresenteerd, hoe sneller de klanten ervoor zullen kiezen. Een business service catalog moet dan ook de volgende informatie bevatten:

• Beschrijving van de dienst

• Categorie van de dienst

• Dienstverleningsniveaus

• Kosten

• Diensturen

• Informatie over klantenondersteuning

7.14.3 Waarom heeft uw bedrijf een service catalog nodig?

Succesvolle ondernemingen begrijpen de eisen van hun klanten en hoe ze aan die behoeften kunnen voldoen. De meeste klanten verwachten een intuïtieve gebruikersinterface waarmee ze de aangeboden diensten zonder moeite kunnen vinden, begrijpen en misschien zelfs uitproberen. Een service catalog kan hierbij uitkomst bieden, doordat het bedrijven ondersteunt met het classificeren van de diensten die ze aanbieden en het verstrekken van aanvullende informatie. De service catalog fungeert ook als interface tussen de IT van het bedrijf en de eindgebruikers. In de loop der jaren is IT steeds belangrijker geworden omdat veel bedrijven diensten aanbieden zoals web-access, e-mails, apps en software oplossingen waarvoor een goed gepositioneerde IT -afdeling onmisbaar is.

Het gebruik van een service catalog draagt bij aan de volgende bedrijfsdoelstellingen:

• Duidelijke communicatie over de aangeboden diensten

• Eén enkele bron van informatie voor alle diensten

• Transparant overzicht van de aangeboden producten en diensten

• Eenvoudig beheer van de aangeboden diensten

• Kwaliteitsgarantie en onderhoud

• Verbetering van de koopervaring

7.14.4 Wat zijn de voordelen van een service catalog?

Een service catalog is in feite vergelijkbaar met een restaurantmenu: klanten krijgen een overzicht zodat ze sneller kunnen vinden wat ze zoeken en hun wensen aan u doorgeven op een duidelijke en nauwkeurige manier. Andere voordelen van een service catalog zijn onder meer:

Verhoogde efficiëntie

Zonder een service catalog moeten klanten zonder begeleiding of o ndersteuning op zoek gaan naar de informatie die ze nodig hebben. Als gevolg daarvan krijgen de servicedesks ontelbare basisvragen over de aangeboden diensten. Uiteindelijk kan de servicedesk complexere problemen niet meer aanpakken omdat het team overbelast is met simpele verzoeken. Dit heeft gevolgen voor de productiviteit van de servicedesk en het hele bedrijf. Met een service catalog is de nodige informatie

veel toegankelijker, waardoor tijdrovende basisvragen niet meer hoeven te worden behandeld door uw supportteam.

Meer standaardisering

Een service catalog kan flink bijdragen aan de standaardisering van werkprocessen en aangeboden diensten. Het bevat namelijk een duidelijke lijst van alle diensten, inclusief omschrijving en parameters – onmisbaar om te werken naar een gestandaardiseerd werkproces. Service catalogs bieden verder ook een overzicht van de noodzakelijke workflows, die meestal vooraf ingesteld en afgestemd worden. Niet elk verzoek hoeft natuurlijk als een afzonderlijk probleem te worden behandeld. Zo kunt u mogelijkheden herkennen voor automatiseringen en standaardiseringen die een positief effect hebben op de kwaliteit van de dienstverlening.

Lagere kosten

In een service catalog kunnen bedrijven al hun aanbiedingen in één oogopslag zien en b eter inzicht krijgen in zowel de vraag naar als het gebruik van hun diensten. Zo kan gemakkelijker worden nagegaan welke middelen weinig respons van de klanten krijgen en welke het sterkst presteren.

Bovendien vermindert een service catalog de tijd die nodig is om verzoeken en vragen te verwerken, zodat werknemers zich kunnen richten op wat ze het beste doen: waarde genereren voor uw klanten en voor uw bedrijf. Zo kan uw team besparen op de kosten en zich richten op winstgevende activiteiten.

Verbeterde bedrijfsstrategie

Met een service catalog worden alle processen in uw servicemanagement gedocumenteerd, van aanvraag tot levering. Dit maakt workflows traceerbaar en geeft u inzicht in de processen en hun efficiëntie. Om uw bedrijf zo goed mogelijk te beheren, gebruikt u deze kennis om workflows te optimaliseren en uw IT-werkzaamheden af te stemmen op de bedrijfsstrategie.

Meer tevreden klanten

Door gebruik te maken van een service catalog krijgen klanten een goed gesorteerde lijst van alle aangeboden diensten. Concreet betekent dit dat de klant het gehele aanbod zelf kan bekijken, een aanvraag gemakkelijk kan indienen, in één oogopslag alle nodig informatie kan inzien en altijd op de hoogte is van veranderingen. Al deze factoren verhogen de tevredenheid van de eindgebruiker van uw diensten.

7.14.5 Hoe creëert u een goede service catalogus? – 5 stappen

Overtuigd van de voordelen van een goede service catalog? Dan hebben wij hieronder de 5 meest belangrijke stappen verzameld om te beginnen met uw eigen service catalogus:

Stap #1: Begrijp de behoeften van uw klanten

De diensten die u aanbiedt kunnen alleen succesvol zijn als ze zijn afgestemd op de eisen en behoeften van de eindgebruikers. Om het juiste aanbod te kunnen bieden, is het belangrijk dat u uitzoekt waar potentiële klanten naar op zoek zijn. Vraag en aanbod op elkaar afstemmen is cruciaal.

Naarmate uw bedrijf groeit, veranderen ook de eisen van uw eindgebruikers. Daarom moeten nieuwe diensten worden toegevoegd en bestaande diensten continue bijgewerkt worden om relevant te blijven.

De service catalog kan in de hele organisatie worden gebruikt, niet alleen voor IT -diensten. Daarom is samenwerking van verschillende teams en inzicht in hun specifieke diensten belangrijk om tot een holistische service catalog te komen. Om deze eerste onderzoeksfase zo goed mogelijk te laten verlopen kunt u letten op de volgende actiestappen:

• Voer een enquête uit om inzicht te krijgen in de huidige behoeften van klanten en hun verwachtingen van een service catalog

• Bepaal uw voorkeurskanaal voor klantverzoeken

• Identificeer uw eigen behoeften: van de onboarding van nieuwe werknemers tot dagelijkse activiteiten tot offboarding

• Onderzoek en stel duidelijk vast wie uw stakeholders zijn

• Bepaal duidelijke en praktische doelstellingen voor uw bedrijf

Stap #2: Stel de juiste teams samen

De manier waarop u uw teams samenstelt, heeft een directe invloed op de kwaliteit van uw dienstverlening. Daartoe moet elk teamlid duidelijke taken en verantwoordelijkheden krijgen. Vorm verschillende groepen op basis van de verschillende verzoeken die u verwacht te ontvangen, zodat de expertise en behandeltijd zo goed mogelijk geregeld zijn. Als alles goed verloopt, heeft u één enkele database met daarin alle diensten en werkprocessen verzameld, zowel op het gebied van uw

IT als de rest van uw onderneming. In grotere bedrijven zult u er dan ook op moeten letten dat bepaalde delen van de service catalog afgeschermd worden van klanten of bepaalde teams. Niet alle elementen van de dienst hoeven zichtbaar te zijn voor iedereen in de organisatie.

In deze tweede stap zijn de volgende taken belangrijk :

• Classificeer uw medewerkers in meerdere groepen op basis van het dienstenaanbod

• Ken de juiste rechten toe aan uw eindgebruikers zodat zij alleen toegang hebben tot de service-elementen die relevant zijn

• Identificeer controleurs of beheerders voor ieder item in uw service catalog. Deze zijn verantwoordelijk voor het ontwerp en de configuratie van de inhoud. Beheerders moeten dan ook volledige toestemming krijgen voor de relevante gebieden van uw service catalog

Stap #3: Maak uw service catalog

Hoe u ervoor kiest om uw service catalog vorm te geven en in te richten zal ook een impact hebben op de customer experience. Configureer de juiste formulieren zodat al le nodige informatie beschikbaar en zichtbaar wordt gemaakt bij ieder item in uw service catalog. Organiseer hierbij de diensten in duidelijke en intuïtieve categorieën, en maak de items visueel aantrekkelijk.

Beperk ook het aantal kliks dat nodig is om to t de juiste informatie te komen en vermijd lange formulieren. Afbeeldingen kunnen helpen om informatie behapbaar en duidelijk over te laten komen en de gehele ervaring fijner te maken.

Denk er ook aan een inventaris bij te houden van alle diensten die u als aangeboden weergeeft, de onderliggende workflows die de dienst ondersteunen en de verwachte leveringstijd van iedere dienst. Begin bij dit proces met één afdeling en ga zo stapsgewijs het hele bedrijf door.

Samenvattend is het dus belangrijk dat u let op de volgende handelingen:

• Configureer formulieren om diensten toe te voegen

• Voeg visuele elementen toe zoals afbeeldingen of een winkelwagentje

• Voeg een beschrijving van de dienst toe – inclusief kosten, beschikbaarheid en verwachte leveringsdatum

• Maak de service catalog ook toegankelijk voor smartphone -gebruikers, wellicht met een toegewijde app of ingebouwd in een bestaande app

• Breid de service catalog stapsgewijs uit over alle afdelingen van uw bedrijf

Eenmaal begonnen aan deze stap, is het ook meteen een goed moment om uw IT -diensten en de ondersteunende werkprocessen te documenteren en zo nodig te optimaliseren. Ook kan uw IT -team op dit moment gebreken in het dienstenaanbod opsporen en deze opvullen met nieuwe diensten. Het eindresultaat moet in ieder geval een duidelijke catalogus zijn die inspeelt op de behoeften van de klant, gemakkelijk te navigeren en gebruiken is en waarmee aanvragen op een efficiënte manier bij uw team binnenkomen.

Stap

#4: Automatiseer de workflows

Zorg voor een duidelijk inzicht in de workflows van iedere aangeboden dienst, van aanvraag tot afhandeling. Identificeer de juiste teams en wijs duidelijke verantwoordelijkheden toe. Alleen zo kunt u succesvol gebruik maken van automatiseringsmogelijkheden om de efficiëntie va n uw customer support te verbeteren. Bouw daartoe ook sterke communicatiekanalen op met andere teams, zodat iedereen op de hoogte is van veranderingen en leidinggevenden weten wat er speelt. Als u eenmaal uw workflows goed in kaart hebt gebracht, kunt u automatisering bijvoorbeeld gebruiken voor:

• Geautomatiseerde workflow voor goedkeuringen, inclusief goedkeuring in meerdere stappen

• Automatische afhandeling of verwijdering van meervoudige verzoeken

• Aanmaken van wijzigingsverzoeken gebaseerd op inzichten in het gedrag van uw gebruikers

Stap #5: Herzie uw service catalog

De huidige processen en de opmaak van de service catalog moeten regelmatig worden herzien op basis van feedback van klanten en medewerkers. Deze herziening stelt u in staat bestaande elementen bij te werken en zo nodig nieuwe items toe te voegen die de klantervaring zullen verbeteren. Om dit te doen houdt u uw diensten aan de hand van KPI’s in de gaten, zoals het aantal ontvangen serviceverzoeken of het aantal opgeloste aanvragen. Deel de resultaten ook met het

managementniveau en zorg voor een continue verbetering van de service catalog op basis van feedbackloops.

Eerder vergeleken we de service catalog al met een restaurantmenu. Over het algemeen zijn de werkzaamheden die deze twee ondersteunen ook vaak vergelijkbaar. In de tabel hieronder hebben wij een overzicht van de verschillen en overeenkomsten bij het creëren van een service catalog en een restaurantmenu verzameld:

ICT Service Catalog

Onderzoek en begrijp de behoeften van uw eindgebruiker

Stel het juiste team samen om ervoor te zorgen dat er aan de eisen wordt voldaan

Plan in fasen en werk stapsgewijs: begin met een bepaald bedrijfsmodel en breid deze uit

Automatiseer workflows voor het aannemen van verzoeken, de afhandeling van de dienst en de toewijzing van verantwoordelijkheden

Verbeter de efficiëntie van het personeel door processen blijvend te herzien en aandacht te besteden aan stroomlijning

Restaurantmenu

Onderzoek en begrijp de voorkeuren van de gast zoals het eten, de sfeer, de openingstijden

Verzamel geschikt personeel voor posten als ontvangst, keuken, bediening, etc.

Begin bijvoorbeeld met een specifieke keuken voor een specifieke doelgroep en breid deze uit

Investeer in een automatiseringsapplicatie voor orderopname en betalingen

Verzamel realtime feedback van gasten en vraag ze om beoordelingen te plaatsen op externe reviewsites

8 Service Desk

Het doel van de servicedesk praktijk is het vastleggen van de vraag voor het oplossen van incidenten en service verzoeken. Het moet ook het ingangspunt en het enige contactpunt zijn voor de dienst provider met al zijn gebruikers.

Servicedesks bieden een duidelijk pad voor gebruikers om problemen, vragen en verzoeken te melden, en ze worden erkend, geclassificeerd, beheerd en afgehandeld. Hoe deze praktijk wordt beheerd en uitgevoerd kan variëren van een fysiek team van mensen in ploegendienst tot een gedistribueerde mix van mensen die virtueel verbonden zijn, of geautomatiseer de technologie en bots. De functie en de waarde blijven hetzelfde, ongeacht het model.

Met de toegenomen automatisering en de geleidelijke opheffing van de technische schuld, komt de nadruk van de servicedesk te liggen op om ondersteuning te bieden voor "mensen en zaken" in plaats van alleen technische problemen. Servicedesks worden in toenemende mate gebruikt om verschillende zaken geregeld, uitgelegd en gecoördineerd te krijgen, in plaats van alleen om defecte technologie te laten repareren, en de servicedesk is een vitaal onderdeel geworden van elke serviceoperatie.

Een belangrijk punt dat moet worden begrepen is dat, hoe efficiënt de servicedesk en haar mensen ook zijn, er altijd problemen zullen zijn die escalatie en ondersteunende ondersteuning van andere teams nodig hebben. Ondersteunende en ontwikkelteams moeten nauw samenwerken met de servicedesk om een gezamenlijke aanpak voor gebruikers en klanten te bekomen.

De servicedesk hoeft niet per se zeer technisch te zijn, hoewel sommige dat wel zijn. Echt er, zelfs als de servicedesk vrij eenvoudig is, speelt hij toch een vitale rol in de dienstverlening, en moet hij actief worden gesteund door zijn peer groups. Het is ook van essentieel belang te begrijpen dat de servicedesk een grote invloed heeft op de ervaring en hoe de dienstverlener door de gebruikers wordt gepercipieerd.

De medewerkers van de service desk

• Call center : calls registreren en doorverwijzen naar gespecialiseerde oplosteams

• Unskilled: calls registreren, globaal vastgelegd, standaardprocedures en daarna doorsturen naar gespecialiseerde teams

• Skilled : meer kennis en deskundigheid en kan eenvoudige problemen oplossen aan de hand van gedocumenteerde oplossingen

• Expert: ervaren gebruiker die veel specialistische kennis met betrekking tot een bepaalde applicatie zal de meeste problemen zelf oplossen.

Een ander belangrijk aspect van een goede servicedesk is zijn praktische begrip van de bredere bedrijfscontext, de bedrijfsprocessen en de gebruikers. Servicedesks voegen niet alleen waarde toe door de transactionele handelingen van, bijvoorbeeld, het loggen van incidenten, maar ook door het

begrijpen van en handelen naar de bedrijfscontext van deze actie. De servicedesk moet de empathische en geïnformeerde schakel zijn tussen de dienstverlener en zijn gebruikers.

Met de toegenomen automatisering, AI, robotic process automation (RPA), en chatbots, zijn service desks naar meer self-service logging en direct -resolustion via online portals en mobiele applicaties geëvolueerd. Het effect op servicedesks is minder telefonisch contact, minder werk op laag niveau, en een groter mogelijkheid om zich te richten op uitstekende CX wanneer persoonlijk contact nodig is.

Servicedesks bieden een verscheidenheid aan toegangskanalen. Deze omvatten:

- telefoongesprekken, die gespecialiseerde technologie kunnen omvatten, zoals interactieve voice response (IVR), conferentiegesprekken, spraakherkenning, en andere

- serviceportalen en mobiele toepassingen, ondersteund door catalogi van diensten en verzoeken, en kennisbanken

- chat, via live chat en chatbots

- e-mail voor registratie en actualisering, en voor follow-uponderzoeken en bevestigingen. Ongestructureerde e-mails kunnen moeilijk te verwerken zijn, maar opkomende technologieën op basis van AI en machinaal leren beginnen hier iets aan te doen

- in sommige sectoren, zoals het hoger onderwijs, komen de inloopbalies steeds vaker voor waar hoge pieken van activiteit fysieke aanwezigheid vereisen

- berichten via sms en sociale media, die nuttig zijn voor meldingen bij grote incidenten en om contact op te nemen met specifieke groepen belanghebbenden, maar kunnen ook worden gebruikt om gebruikers in staat te stellen om ondersteuning te vragen

- openbare en zakelijke sociale media en discussieforums voor contact met de dienstverlener en voor peer-to-peer ondersteuning.

Sommige servicedesks hebben een beperkt ondersteuningsvenster waarin dekking door de dienst beschikbaar is (bijvoorbeeld, 08.00-20.00 uur, maandag-vrijdag). Van het personeel wordt daarom verwacht dat zij in ploegen werken om consistente ondersteuningsniveaus te bieden.

In sommige gevallen is de servicedesk een tastbaar team, dat op één locatie werkt. Een gecentraliseerde service desk vereist ondersteunende technologieën, zoals:

- intelligente telefoniesystemen, met integratie van computer-telefonie, IVR, en automatische oproepverdeling

- workflowsystemen voor routering en escalatie

- systemen voor personeelsbeheer en resourceplanning

- een kennisbank

- gespreksopname en kwaliteitscontrole

- hulpmiddelen voor toegang op afstand

- dashboard- en monitoringtools

- systemen voor configuratiebeheer.

In andere gevallen stelt een virtuele servicedesk agenten in staat om vanuit meerdere locaties te werken, geografisch verspreid. Een virtuele servicedesk vereist meer geavanceerde ondersteunende technologie, met meer complexere routing en escalatie; deze oplossingen zijn vaak cloud -gebaseerd.

Servicedeskmedewerkers moeten worden opgeleid en bekwaam in een aantal brede technische en zakelijke gebieden. In het bijzonder moeten zij blijk gev en van uitstekende vaardigheden op het gebied van klantenservice, zoals empathie, het analyseren van incidenten en het stellen van prioriteiten, doeltreffende communicatie en emotionele intelligentie. De belangrijkste vaardigheid is om in staat te zijn een specifiek incident volledig te begrijpen en te diagnosticeren in termen van bedrijfsprioriteit, en om de juiste actie te ondernemen om dit op te lossen, met gebruikmaking van de beschikbare vaardigheden, kennis, mensen en processen.

8.1 Wat is een service de sk?

Servicedesks zijn ontworpen om zowel incidenten als serviceverzoeken te behandelen. De servicedesk is een centraal punt voor eindgebruikers om contact op te nemen met IT of een andere ondersteuningsfunctie. Zij kunnen incidenten melden (gebeurtenissen die resulteren in een verstoring van de beschikbaarheid/kwaliteit van de service) en serviceverzoeken doen (routineverzoeken voor services zoals het verkrijgen van een nieuwe laptop, onboarding van een nieuwe medewerker).

Ze hebben een meer brede en gebruikersgerichte benadering van dienstverlening. Een servicedesk wil de integratie van bedrijfsprocessen in de servicemanagement infrastructuur vergemakkelijken.

8.2 Wat is een IT servicedesk?

Een IT-servicedesk is een centraal contactpunt tussen de serviceprovider en de gebruikers. ITIL biedt een kader om diensten beter te leveren, met behulp van de servicelevenscyclus zoals

servicestrategie, ontwerp, operaties, transitie en CSI (Continu Service Improvement). IT-servicedesks gebruiken het ITIL-raamwerk om te bepalen hoe IT-teams diensten creëren, catalogiseren, aanbieden en oplossen voor de eindgebruiker.

8.3 Verschillen tussen helpdesk en servicedesk

Een helpdesk en een servicedesk lijken veel op e lkaar, maar zijn toch heel verschillend. Er zijn gevallen waarin de twee door elkaar worden gebruikt, wat voor veel verwarring zorgt. Hoe zijn de twee dan verschillend?

Zoals de naam al doet vermoeden, is een helpdesk bedoeld om u te helpen wanneer u een p robleem hebt en de normale gang van zaken te herstellen. Gebruikers vertrouwen op helpdesks om hen te helpen met problemen zoals het oplossen van problemen met de printer, of het opzetten van een nieuw systeem. Een helpdesk is meestal reactief en ontvangt problemen van eindgebruikers en biedt een oplossing. Een helpdesk biedt "hulp" of "break-fix" ondersteuning, terwijl een servicedesk assisteert bij break-fix ondersteuning en serviceverzoeken. De servicedesk is verantwoordelijk voor de volledige IT-ondersteuning en -diensten, met inbegrip van service request management, change management en asset management. De servicedesk volgt een holistische benadering om de bedrijfsen IT-visie op elkaar af te stemmen. Servicedesks kunnen worden opgezet om proactief te voorkomen dat incidenten zich voordoen. Simpel gezegd is een service desk een uitbreiding van de helpdesk met een uitgebreide set van functionaliteiten en is gericht op excellente dienstverlening.

HELPDESK

Biedt "hulp" of "break-fix" ondersteuning

Is een component van de servicedesk, die zich het meest bezighoudt met eindgebruikersfunctionaliteit en incidentbeheer om ervoor te zorgen dat problemen snel worden opgelost.

Bevat meestal een ticketsysteem dat zich richt op het oplossen van het incident

IT SERVICEDESK

Nadruk ligt meer op een service lifecycle benadering van ITSM

Breidt de helpdesk uit door een manier te bieden om probleem-, wijzigings-, configuratie-, kennis- en releasemanagement uit te voeren, naast incidentmanagement.

Ze hebben een doel - voortdurende verbetering van de diensten, om de efficiëntie te verhogen en de kosten te verlagen (CSI), door de huidige processen en trends te beoordelen.

8.4 Kenmerken van IT service desk software

Een effectieve IT Service Desk moet de agent in staat stellen om met de juiste informatie effectief in te spelen op de behoeften van de eindgebruikers. Het moet ook gemakkelijk te gebruiken zijn door de eindgebruiker, en hem helpen om gemakkelijk oplossingen te vinden. Hier zijn enkele van de belangrijkste kenmerken van een service desk software:

8.4.1

Multi-channel ondersteuning

De IT servicedesk software fungeert als een contactpunt tussen de eindgebruiker en een agent. Of de eindgebruiker nu een incident wil melden, of een verzoek wil indienen, de servicedesk software fungeert als het aanspreekpunt. Het is essentieel om meerdere contactpunten te hebben met de eindgebruiker zodat deze gemakkelijk contact kan opnemen. Dit kan zijn via telefoon, e -mail, selfservice portal, enz.

8.4.2

Aanpasbare kennisbank of self-service

Kennisbank is een van de belangrijkste functies van een service desk software. Routinematige/herhaalde vragen worden verzameld in deze sectie, waardoor agenten tijd hebben om zich te concentreren op meer dringende of belangrijke problemen, e n een snellere manier bieden voor de eindgebruiker om een oplossing te krijgen. Vragen van klanten moeten worden georganiseerd in FAQ's of oplossingsartikelen, die gemakkelijk toegankelijk zijn. Filter mogelijkheden om oplossingen per categorie te vinden, meest gestelde vragen bovenaan, auto -suggestie oplossingen gebaseerd op de zoekvraag, zijn must-have features in een service desk software.

Een efficiënte selfservice portal heeft de mogelijkheid om een nieuw incident in te dienen, een service request te versturen, toegang te krijgen tot de kennisbank, de status van hun incident te volgen, aankondigingen te bekijken, etc. Een aangepaste selfservice portal voor uw eindgebruiker stelt hen in staat om zelf informatie te vinden, waardoor de overhead voor agente n vermindert.

8.4.3

Automatisering

Automatisering is een krachtige functie in een service desk software die de overhead van een agent drastisch kan verminderen en de productiviteit kan verbeteren. Repetitieve of routinematige taken zoals het omzetten van e-mails naar tickets, het informeren van managers over in behandeling zijnde of opgeloste tickets, het automatisch toewijzen van tickets aan de juiste agenten of groepen, het opzetten van goedkeuringen op meerdere niveaus, het beheren van SLA -overtredingen, enz. kunnen worden ingesteld met behulp van automatiseringen. Zelfs processen zoals travel desk goedkeuringen, onboarding van medewerkers kunnen worden geautomatiseerd.

8.4.4

Rapportage en analyse

Dashboards helpen agents om data te zien die het meest relevant en belangrijk zijn bij het inloggen. Dit kunnen bijvoorbeeld statistieken zijn van tickets zoals in behandeling zijnde tickets, nieuwe tickets etc. Een goed dashboard moet managers ook belangrijke statistieken geven die direct en essentieel inzicht geven in hoe de servicedesk presteert, zoals de algehele prestaties van de agents, het oplossingspercentage, het oplossingspercentage bij de eerste oproep, enzovoort.

Een andere belangrijke functie is rapportage, met inbegrip van vooraf gedefinieerde rapporten en aangepaste rapporten. Het automatisch genereren, plannen, delen en exporteren van rapporten zijn gerelateerde functies die essentieel zijn.

Met big data als buzzword, is analytics een uiterst belangrijke functie om inzichten te verkrijgen en de prestaties van de servicedesk te verbeteren. Dit helpt bij het consolideren van alle servicedeskgegevens en ze te analyseren op patronen en trends. Trendanalyses op inkomende tickets, hoeveel er worden opgelost, agentprestaties, gebruik van de servicedesk enz. helpen om het servicedeskbeheer beter te begrijpen en te optimaliseren.

8.4.5 Meerdere SLA-beleidslijnen

Geef prioriteit aan tickets op basis van SLA en stel regels in voor escalatie of deadlines. Het vermijden van SLA-overtredingen en het verzekeren van maximale SLA-conformiteit is de sleutel tot het leveren van een kwaliteitsvolle service desk-ervaring. Het is essentieel om effectief om te kunnen gaan met overtredingen en diegenen die overtredingen naderen door ze te verplaatsen naar een andere groep, ze opnieuw toe te wijzen aan een andere agent, of prioriteiten en niveaus opnieuw in te stellen.

Escaleer tickets automatisch of stuur notificaties over SLA-overtredingen door vooraf automatiseringsregels te definiëren die passen bij uw ticketprioriteiten. Krijg inzicht in uw dienstverlening door het bijhouden van uw prestaties ten opzichte van SLA's

8.5 Waarom hebt u een IT servicedesk software nodig?

Heeft u echt een IT servicedesk software nodig? Het antwoord is JA! Niet alleen organiseert het informatie, stroomlijnt het workflows en elimineert het veel handmatige processen, het helpt ook om zaken efficiënt te laten verlopen. Hier zijn enkele redenen: Fungeert als een enkele bron van waarheid voor uw eindgebruikers

Het leveren van een geweldige eindgebruikerservaring is cruciaal, maar niet eenvoudig.

• Een servicedesk kan meerdere contact-/toegangspunten en communicatiekanalen bieden, van telefoon tot self-service en chat, wat de ervaring van de eindgebruiker verbetert omdat het hen in staat stelt gemakkelijker in contact te komen met een agent.

• Eindgebruikers in staat stellen zichzelf te helpen met self-service verbetert niet alleen de algehele productiviteit en efficiëntie van de IT-afdeling, maar ook die van de eindgebruiker. Geef uw eindgebruikers meer mogelijkheden en werk toe naar agentloze ondersteuning via

self-service. Een self-service portal is de sleutel tot het verbeteren van de eindgebruikerservaring.

Neem beslissingen op basis van gegevens

Gegevens en rapportage zijn van cruciaal belang voor elk bedrijf dat naar het volgende niveau wil opschalen.

• Servicedesks bevatten veel gegevens, variërend van incidenten, productspecificaties tot prestaties, en bieden een hoop inzichten wanneer ze worden samengevoegd.

• Deze gegevens kunnen worden geanalyseerd om u te helpen herhaalde problemen, ROI van IT-strategieën, servicedeskprestaties, enz. te identificeren en weloverwogen beslissingen te nemen over toepassingen, diensten, IT-infrastructuur, tools en best practices voor het bedrijf.

Ze houden uw bedrijf draaiende

• Een servicedesk fungeert als centraal aanspreekpunt voor alles wat met IT te maken heeft. Dit betekent dat de dienstverlening gestructureerd en consistent is.

• Ze zorgen voor proactieve IT-ondersteuning door belangrijke incidenten tijdig te signaleren en te voorkomen.

• IT is altijd gezien als een kostenplaats. Een service desk kan helpen bij het realiseren van business value door het begrijpen en beperken van de impact van incidenten/issues op het moment dat ze zich voordoen.

• De kwaliteit van de IT-dienstverlening en de beschikbaarheid van bedrijfsservices zullen toenemen naarmate de servicedesk IT-problemen sneller en efficiënter oplost.

• Een servicedesk biedt IT-teams het platform dat ze nodig hebben om veranderingen te verwerken, incidenten efficiënter te beheren en ervoor te zorgen dat ze de bedrijfsactiviteiten niet in de weg staan.

9 IT asset management

Het doel van de IT asset management praktijk is het plannen en beheren van de volledige levenscyclus van alle IT assets, om de organisatie te helpen:

- de waarde te maximaliseren

- kosten te beheersen

- risico's te beheren

- de besluitvorming te ondersteunen over de aankoop, het hergebruik, de buitengebruikstelling en de verwijdering van activa

- te voldoen aan reglementaire en contractuele vereisten.

Definitie IT-activa

Elk financieel waardevol onderdeel dat kan bijdragen aan de levering van een IT -product of service.

Het doel van de praktijk van monitoring en event management is het systematisch observeren van services en servicecomponenten, en het registreren en rapporteren van geselecteerde veranderingen van de toestand die geïdentificeerd zijn als gebeurtenissen. Deze praktijk identificeert en prioriteert infrastructuur, diensten, bedrijfsprocessen en informatiebeveiligingsgebeurtenissen; het bepaal t ook de gepaste reactie op die gebeurtenissen, en omstandigheden die wijzen op potentiële fouten of incidenten.

Definitie Gebeurtenis

Elke verandering van status die van belang is voor het beheer van een service of ander configuratieitem (CI). Events worden typisch herkend door notificaties gecreëerd door een IT service, CI, of monitoringtool.

9.1 IT-activabeheersoftware

Volgens de International Association of IT Asset Managers (IAITAM) is IT Asset Management (ITAM) "een reeks bedrijfspraktijken die IT-activa in alle bedrijfseenheden van de organisatie integreert. Het verenigt de financiële, inventaris-, contractuele en risicobeheersverantwoordelijkheden om de totale levenscyclus van deze activa te beheren, met inbegrip van tactische en strategische besluitvorming". Activa omvatten alle elementen van software en hardware die zich in de bedrijfsomgeving bevinden. IT asset management wordt ook wel IT inventory management genoemd, omdat het doorgaans gaat om het verzamelen van gedetailleerde hardware- en software-inventarisinformatie, die vervolgens wordt gebruikt om beslissingen te nemen over aankopen en het gebruik van activa. Een nauwkeurige inventarisatie van IT-activa helpt bedrijven hun activa effectiever te gebruiken en onnodige aankopen van activa te voorkomen door bestaande middelen opnieuw te gebruiken. IT asset management stelt organisaties ook in staat om de risicokosten te verlagen van het onbewust bouwen van nieuwe IT-projecten op verouderde (of onbekende) infrastructurele fundamenten.

IT Asset management wordt effectief gemaakt door gebruik te maken van metadata en elektronische records om de assets van de organisatie op te sporen en te categoriseren. Metadata is de beschrijving van het fysieke of digitale asset en alle ondersteunende inform atie die nodig is om asset management beslissingen te onderbouwen. De diepte van de metadata kan variëren naargelang de behoeften van de organisatie.

Laat ons nu diep duiken in de volgende gebieden:

9.2 Waarom is Asset Management belangrijk voor IT?

IT-organisaties beheren een groot deel van de totale activa van het bedrijf. IT assets zijn zowel kostbaar in aanschaf als in onderhoud. Daarom speelt asset management een cruciale rol bij het helpen van IT-teams om te zorgen voor efficiënt gebruik van de middelen v an de organisatie bij het ondersteunen van de behoeften van gebruikers en bedrijfsfuncties.

Gartner definieert IT Asset Management (ITAM) als: "het verschaffen van een accurate weergave van de kosten en risico's van de levenscyclus van technologische activ a om de bedrijfswaarde van technologiestrategie, architectuur, financiering, contractuele en sourcingbeslissingen te maximaliseren." Deze definitie benadrukt dat IT Asset Management niet alleen over het inventariseren van activa gaat, maar over het gebruik van de vastgelegde informatie om beslissingen te sturen. IT-organisaties richten zich steeds meer op de bruikbaarheid en de informatieve waarde van IT asset data om de bedrijfswaarde te verhogen, in plaats van zich alleen te richten op de kwantiteit en nauwkeurigheid van de data.

Hier volgen enkele van de belangrijkste doelstellingen van asset management in IT:

• Naleving van bedrijfsbeveiligingsbeleid en wettelijke vereisten afdwingen

• Verbetering van de productiviteit door het inzetten van technologie ter o ndersteuning van gebruikers- en bedrijfsbehoeften

• Licentie- en ondersteuningskosten verlagen door onderbenutte resources en licenties te elimineren of opnieuw toe te wijzen

• De overheadkosten voor het beheer van de IT -omgeving beperken

9.3 Soorten IT- middelenbe heer

Asset Management is een brede term en kan veel verschillende dingen betekenen. Hier zijn enkele van de meest voorkomende types van asset management die vaak voorkomen in ITorganisaties

IT Asset Management

Is de overkoepelende set van bedrijfspraktijken die financiële, contractuele en inventarisfuncties samenvoegen om life cycle management en strategische besluitvorming voor de IT -omgeving te ondersteunen. ITAM is een onderdeel van de IT Service Management functie van een bedrijf.

Beheer van digitale activa

maakt deel uit van de functies voor het beheer van intellectuele eigendom van een bedrijf en is een vorm van beheer van elektronische mediacontent die zich bezighoudt met het beheer van digitale activa zoals foto's, video's en digitale gegevens die het bedrijf zelf produceert of in licentie krijgt van derden.

Software Asset Management en Licentiebeheer houden zich bezig met het doeltreffend beheer, de controle en de bescherming van softwaremiddelen. Dit omvat software die door het bedrijf is geproduceerd en software waarvoor licenties van derden zijn verkregen, om ervoor te zorgen dat voor alle software die binnen de organisatie wordt gebruikt, naar behoren wordt betaald en dat deze in overeenstemming is met de licentieovereenkomsten.

9.4 Wat is een voorbeeld van IT bedrijfsmiddel?

Nu IT-omgevingen complexer en diverser worden naarmate de technologie evolueert en er meer aanbod komt van derde partijen, kan het moeilijk zijn om een duidelijke definitie te geven van wat een IT-asset is. Veel bedrijven zijn begonnen af te stappen van strikte definities en in plaats daarvan zal de definitie van IT assets variëren van organisatie tot organisatie op basis van de aard van de business, de rol van specifieke soorten dingen binnen het totale IT ecosysteem en de behoefte aan informatie om de besluitvorming te ondersteunen.

Infrastructuur hardware

Netwerkapparatuur, datacenters, fysieke servers, enz., die uw bedrijf heeft aangeschaft en beheert. Huurovereenkomsten voor faciliteiten en infrastructuur

Infrastructuur die door derden wordt geleverd, wordt niet beschouwd als bedrijfsmiddelen van uw bedrijf. De overeenkomsten voor toegang tot en gebruik van de infrastructuur van derden kunnen als activa worden beschouwd.

In-house ontwikkelde software

Dingen die uw IT-personeel intern heeft geschreven of gebouwd en waarvan uw bedrijf eigenaar is.

Softwarelicenties

Soms aangeduid als Common Off the Shelf (COTS) software, dit zijn dingen die iemand anders heeft gemaakt en waarvoor u een licentie hebt gekocht om ze gedurende een bepaalde periode te gebruiken. Denk eraan dat de licentie het bedrijfsmiddel is, niet de software zelf.

Eindgebruikersapparatuur in bedrijfseigendom

Desktopcomputers, monitors, printers, telefoons en andere eindgebruikersapparaten worden van oudsher beschouwd als IT-activa. Houd er rekening mee dat apparaten die eigendom zijn van werknemers of ter beschikking worden gesteld, geen bedrijfsmiddelen zijn. Dit is belangrijk nu BYOD steeds meer wordt geaccepteerd.

Digitale gegevens van activiteiten

Gegevens worden in toenemende mate behandeld als een IT-bedrijfsmiddel dat wordt gewaardeerd, gekost, beheerd en onderhouden gedurende de gehele levenscyclus. Operationele gegevens zijn bijzonder belangrijk voor digitale ondernemingen

9.5 Wat is de levenscyclus van IT-activa?

Plan

De strategie en de beslissingen over welke middelen nodig zijn binnen de organisatie, hoe ze moeten worden aangeschaft, hoe ze zullen worden gebruikt en hoe ze zullen worden gefinancierd. De planning omvat vaak een TCO- en kosten/batenanalyse van alternatieven.

Verwerven (Aqcuire)

De aankoop van middelen door ze te bouwen, te kopen, te leasen of in licentie te geven.

Ingebruikneming (Commission)

Het introduceren van het bedrijfsmiddel in het IT-ecosysteem. Dit omvat installatie, integratie met andere componenten, het opzetten van operationele / ondersteunende processen en het verlenen van gebruikerstoegang.

Onderhouden (Maintain)

Naarmate de asset wordt gebruikt, kunnen onderhoud, reparatie, upgrades en revisies nodig zijn om de waarde voor gebruikers te maximaliseren, de levensduur van de asset te verlengen, risico's te beperken en ondersteuningskosten te verlagen.

Buiten gebruik stellen (Retire)

Aan het einde van de levensduur van een bedrijfsmiddel moet het worden afgestoten of anderszins vervreemd. De buitengebruikstelling omvat vaak de overgang van gebruikers naar andere middelen, het bijwerken van de asset records, het opzeggen van ondersteuningsovereenkomsten, het beëindigen van licentieverlengingen en het initiëren van de planning voor vervangende assets.

Iedereen heeft met verandering te maken en heeft een andere kijk op wat veranderingsmanagement is. Door de overeenkomsten en verschillen te begrijpen, zult u beter voorbereid zijn om het beste raamwerk en de beste software voor veranderingsbeheer te selecteren die aan de behoeften van uw organisatie voldoen.

9.6 Wat is een asset management tool?

Asset management is een zeer data-intensieve set van processen. Automatisering kan een belangrijke rol spelen bij het helpen van een organisatie bij het vastleggen, catalogiseren, beheren, analyseren en rapporteren van asset data. In moderne organisaties is asset management technologie essentieel om operationele processen en besluitvorming schaalbaar te maken over grote ass et footprints. Hier volgt een greep uit enkele van de meest voorkomende soorten tools die bedrijven gebruiken om asset management processen te ondersteunen:

Ontdekking / Geautomatiseerde Inventarisatie

Intelligente "ontdekking" van hardware- en softwarecomponenten die in het IT-ecosysteem van het bedrijf zijn geïnstalleerd.

Licentiebeheer

Een opslagplaats voor licentierechten (die vervolgens kunnen worden vergeleken met gegevens van inventarisatietools om de organisatie een beeld te geven van waar de organisatie te weinig licenties heeft (met het risico op een compliance -audit) of te veel licenties heeft (geld verspillen aan onnodige softwareaankopen). Tools voor licentiebeheer houden ook licentievoorwaarden (soms EULA's genoemd) en vervaldatums bij.

Patch- en versiebeheer

Automatiseert de implementatie van softwarepatches om ervoor te zorgen dat computers up -todate zijn en voldoen aan de toepasselijke beveiligings- en efficiëntienormen.

Beheer van aanvragen

(vaak onderdeel van een inkoop- of provisioneringssysteem) stelt medewerkers in staat om aanvragen in te dienen voor softwareproducten, apparaten en andere bedrijfsmiddelen met behulp van een gecentraliseerd formulier en is ontworpen om specifieke licentievereisten vast te leggen en te beoordelen, alsmede om het inkoop- en implementatieproces te beheren en te volgen.

Product-/dienstencatalogus

Biedt een hoofdlijst van middelen en bronnen die zijn goedgekeurd voor gebruik binnen de organisatie. Dit kan zowel standaard aanbiedingen als niet-standaard goedgekeurde items omvatten. De catalogus legt productspecifieke informatie vast, zoals naam, editie, versie en type licentieovereenkomst, evenals andere belangrijke gegevens.

Configuratie Management Database (CMDB)

De CMDB is een onderdeel van het IT Service Management systeem van een organisatie en biedt een gecentraliseerde opslagplaats voor het vastleggen van IT assets, hun configuratie en relaties met andere componenten.

Vaste Activa Systeem

De opslagplaats voor vaste activa maakt deel uit van het financiële beheersysteem van de organisatie en is verantwoordelijk voor het beheer en de rapportage van activagegevens ter ondersteuning van financiële processen.

Digitaal middelenbeheer

Het bedrijfsproces voor het organiseren, opslaan en ophalen van rich media en he t beheren van digitale rechten en permissies. Rich media assets omvatten foto's, muziek, video's, animaties, podcasts en andere multimedia-inhoud.

9.7 Software voor het traceren van activa

Asset tracking combineert fysieke apparaten, desktop software, barcode scanners, barcode labels en mobiele apparaten om het traceren van goederen te stroomlijnen, van aanschaf tot buitengebruikstelling in een organisatie.

Asset tracking heeft in principe drie hoofdfuncties:

• Documentatie van alle apparaten binnen een organisat ie

• Identificeren waar deze apparaten zich op een bepaald moment bevinden

• Planning van onderhoud en berekening van de afschrijving van deze activa

Waarom hebben we Asset Tracking Software nodig?

Assets worden door hun aard gekocht en ingezet op verschillende plaatsen. Als u IT-assets beschouwt, varieert de inzet ook vaak en verspreid over meerdere kantoren of locaties. Wanneer een bepaalde asset troubleshooting vereist, kan het echt moeilijk zijn om alles wat er gebeurd is met de asset te volgen. U hebt dan niet genoeg gegevens om een beslissing te nemen. Asset tracking geeft ons de geschiedenis van Assets en alle veranderingen die de asset heeft doorgemaakt over een periode van tijd, zodat het echt gemakkelijk wordt voor een service desk agent om eventuele problemen op te lossen die zich kunnen voordoen met de asset.

Na verloop van tijd verouderen bedrijfsmiddelen en moeten ze worden vervangen of onderhouden.

Asset tracking creëert de voorspelbaarheid waarin dit gebeurt en we kunnen de activa gedurende hun hele levenscyclus bijhouden en er zo voor zorgen dat onze financiën en belastingen in orde zijn.

Licentiebeheer

License Management helpt ons om de risico's, kosten en complexiteit van software assets te verminderen. Iedereen wil minder uitgeven aan softwaremiddelen en er tegelijkertijd voor zorgen dat ze volledig in overeenstemming zijn met de licentieregels. Licentiebeheer omvat meestal het creëren van een trial of demo voor de software, het verkrijgen van licentiesleutels voor de software, het activeren en deactiveren van de software en ervoor zorgen dat de software op het juiste moment wordt vernieuwd om ervoor te zorgen dat de activiteiten voor de eindgebruikers soepel verlopen. Het houdt ook een regelmatige controle in van alle softwarelicenti es waarvoor we betalen en ervoor zorgen dat we niet te veel uitgeven aan licenties.

9.8 Voordelen van IT Asset Management

Geïnformeerde aankoop- en implementatiebeslissingen

Een van de belangrijkste voordelen van IT Asset Management is inzicht in welke bedrijfsmiddelen u hebt en waar ze voor worden gebruikt. Consistent bijgehouden en nauwkeurige IT asset management gegevens kunnen een organisatie helpen bij het evalueren van inkoop- en implementatiebeslissingen uit het verleden en het sturen van toekomst ige acties. Dit omvat het selecteren van de beste leveranciers, niet alleen op basis van de aankoopprijs, maar ook op basis van de kwaliteit van het product of de dienst en de ondersteuning na de verkoop. IT asset management kan ook helpen bij het verbeteren van beslissingen over uitrol en het voorkomen van overaankopen van middelen die niet nodig zijn.

Bedrijfscontinuïteit

Rampen en uitval komen voor. Gegevens over IT-activa en -configuratie kunnen leiders en personeel helpen bij het vaststellen van de impact van gebeurtenissen die van invloed zijn op de bedrijfsvoering en bij het nemen van meer betrouwbare beslissingen om de dienstverlening aan gebruikers te herstellen. Gegevens over assets kunnen ook een waardevolle bijdrage leveren aan de ontwikkeling van IT-architecturen die redundant en veerkrachtig zijn in tal van situaties.

Naleving van licenties en abonnementen

Een van de grootste uitdagingen voor moderne IT-organisaties is het bijhouden van softwarelicenties en cloudabonnementen, zodat het bedrijf geen resources gebruikt waarvoor het niet betaalt of betaalt voor resources die het niet nodig heeft. Niet-compliant is niet alleen een juridisch en financieel risico voor het bedrijf, maar ook een potentieel kostbaar probleem om op te lossen.

Totale kosten van eigendom

De kosten van een IT-middel zijn veel meer dan alleen de aankoopprijs die werd betaald om het te verwerven. Om waarde te creëren, moeten IT-middelen gedurende hun hele levenscyclus worden gebruikt, ondersteund en onderhouden. TCO is een maatstaf voor de totale kosten van het bezit en de exploitatie van een asset. Het effectief beheren van de TCO helpt kosten te elimineren die voortvloeien uit het dupliceren van assets of het niet gebruiken ervan nadat ze zijn aangeschaft.

Standaardisatie

Niet-standaard IT-apparatuur en -software kan een organisatie veel geld kosten. Het zorgt ervoor dat IT-medewerkers minder productief zijn omdat ze geen expertise hebben in het beheren van de nietstandaard assets, zodat elk probleem resulteert in een leerproce s. Door standaarden toe te passen op IT-middelen wordt niet alleen het IT-personeel productiever, maar worden gebruikers ook productiever in hun interactie met systemen en gegevens waarmee ze vertrouwd zijn.

9.9 CMDB

9.9.1 Wat is CMDB?

CMDB staat voor Configuration Management Database. Deze databases worden vaak gezien als “het hart van uw ITSM-systeem”. Een CMDB is een opslagplaats die dienstdoet als een datawarehouse – het bevat informatie over uw IT-omgeving, de componenten die gebruikt worden voor de levering van IT-diensten. De data die in een CMDB is opgeslagen omvat onder meer een lijst assets (configuratie-items) en hun onderlinge relaties. CMDB’s en de bijbehorende configuratiemanagementprocessen vormen de kern van moderne IT-activiteiten – hiermee kan het bedrijf op één plek data beheren over een gevarieerde verzameling IT -componenten (zelfs als de daadwerkelijke apparaten wijdverspreid zijn). De CMDB helpt de organisatie bij het uitvoeren van servicemanagement-processen zoals incidentbeheer, wijzigingsbeheer en probleembeheer. Het is ook een essentieel hulpmiddel voor besluitvormers die deze informatie nodig hebben om de kosten, kwaliteit en prestaties van de door de organisatie geboden IT -services te verbeteren.

9.9.2 Evolutie van ITIL CMDBs

De IT Infrastructure Library (ITIL) omschrijft een verzameling processen voor service asset en configuratiemanagement, met het doel om informatie te behouden over configuratie -items (CI’s). Dit zijn de vereiste componenten om een IT-service te leveren. De informatie die beheer d wordt als onderdeel van ITIL-service asset en configuratiemanagement bevat niet alleen een lijst met

componenten, maar ook de onderlinge relaties. ITIL beschrijft de onderliggende technische mogelijkheden die nodig zijn voor ondersteuning van asset - en configuratiemanagement, aangezien een configuratiemanagementsysteem (CMS) een logisch datamodel is dat meerdere fysieke ITIL CMDBs kan bevatten.

Terwijl bedrijven nieuwe processen omarmen zoals Agile en DevOps, neemt de CMDB een uitgebreidere rol in en stelt het IT-werknemers in staat om de productie-omgeving te begrijpen en real-time beslissingen te nemen over zaken zoals problemen en wijzigingen. Met de toename van cloud infrastructuur en gebruik van SaaS, moeten bedrijven meer externe gegevensbronnen integreren in het configuratiebeheer model om het grote plaatje te blijven zien van een moderne, hybride IT-omgeving. Veel bedrijven beginnen ook met het onderzoeken van nieuwe manieren om data-assets te beheren in de context van de CMDB, ter ondersteuning van digitale transformatieinitiatieven en digitale bedrijfsprocessen.

In de toekomst zal de CMDB een uitgebreidere rol spelen in niet alleen de IT -activiteiten, maar ook in bedrijfsactiviteiten (in digitaal getransformeerde bedrijven). De juiste CMDB -oplossing om op te bouwen zal cruciaal zijn; een oplossing die uw huidige behoeftes ondersteunt, maar ook met u mee ontwikkelt terwijl uw bedrijf groeit en de bedrijfsomgeving verandert.

9.9.3 Configuration management ITIL

CMDB’s zijn aanvankelijk gemaakt als opslagplaats voor handmatig verzamelde IT-asset inventarisgegevens. Nu ITSM-processen volwassen zijn geworden en technologie zoals discovery tools automatisering van het verzamelproces mogelijk hebben gemaakt, heeft de rol van CMDBs zich uitgebreid en is het nu voor de meeste bedrijven een kernonderdeel van de ITSM -oplossing. De rol

van de CMDB heeft zich altijd afgestemd op de evolutie van servicemanagement en andere ITprocessen en zal dit ook in de toekomst blijven doen.

9.9.4 Hoe werkt CMDB-software?

Een CMDB is een opslagplaats (een database) die lijsten met informatie en onderliggende relaties opslaat. Wat een CMDB uniek en waardevol maakt is de data die het bevat. De lijsten met configuratie-items en de bijbehorende attributen en onderliggende relaties vormen h et bindweefsel van de fysieke IT-omgeving. Configuratiebeheer is vaak onderdeel van het bredere ITServicemanagement (ITSM) platform of pakket aan mogelijkheden, waarin verder waarschijnlijk tools te vinden zijn voor het invoeren van data in de CMDB-software (zoals discovery en data import tools), een wie-doet-wat database, en tools voor het gebruiken van data vanuit de CMDB (zoals een ticketingtool, wijzigingsbeheersysteem, rapportagemogelijkheden).

De CMDB biedt een gemeenschappelijke plek voor de opslag van informatie over IT-assets en andere configuratie-items, in een gemeenschappelijke plek waar men toegang toe heeft. Deze data is doorgaans afkomstig uit meerdere bronnen en zonder de CMDB zou het zeer lastig zijn om een volledig en nauwkeurig beeld te vormen van de IT-omgeving. Discovery en data import tools worden doorgaans gebruikt voor de identificatie van configuratie-items in de IT-omgeving en de invoer in de CMDB. Sommige organisaties hanteren ook handmatige inventarissen en audits om de CMDB -data bij te werken. Zodra data uit de verschillende bronnen in de CMDB is geladen (of bijgewerkt als zaken veranderen), kan de informatie benaderd worden op een uniforme en consistente manier, door tools en processen die de informatie nodig hebben.

Het komt niet vaak voor dat men configuratiegegevens direct in de CMDB benadert, vanwege de hoeveelheid aanwezige data en het formaat waarin het opgeslagen is. Het is moeilijk om veel data te interpreteren in rijen en kolommen. Dat is waar andere ITSM-tools en rapportagemogelijkheden een rol gaan spelen. Deze tools benaderen de data in de CMDB, sorteren en filteren deze en tonen informatie aan gebruikers op een manier die beter aansluit bij het operationele probleem of bedrijfsprobleem dat ze proberen op te lossen.

9.9.5 Voordelen en nadelen van CMDB’s

Net als met andere soorten technologie, heeft het gebruik van een CMDB zowel voordelen als nadelen. Hoewel vroegere CMDB-implementaties (een paar decennia geleden) zeer kostbaar, omslachtig te beheren en moeilijk in gebruik waren, zijn moderne CMDB’s voor de meeste bedrijven nu een kerneigenschap van de ITSM-oplossing. De voornaamste voordelen van een CMDB zijn:

• Toegang tot een volledige verzameling gegevens over uw IT-omgeving, op een gecentraliseerde plek voor eenvoudige to egang.

• Data integreren uit externe gegevensbronnen (zoals leveranciers)

• Begrip van de samenstelling van kritieke assets en de componenten waar zij afhankelijk van zijn

• Begrijpen waar verschillende assets voor gebruikt worden en welke bedrijfsprocessen en gebruikers er afhankelijk van zijn

• Informatie bieden ter ondersteuning van besluitvorming over de IT -omgeving, operationele kosten en technologiebeslissingen

• Mogelijkheid tot risicobeheer door een inventaris te bieden van welke technologie -assets u heeft die mogelijk kwetsbaarheden bevatten

CMDB’s hebben echter ook minpunten. Het aanmaken, beheren en effectief gebruiken van een grote set aan configuratiegegevens kan kostbaar zijn, zowel op het gebied van technische hulpmiddelen als de menselijke aandacht die nodig is om kwaliteit en waarde te waarborgen. Enkele nadelen van het gebruik van CMDB’s zijn:

Kosten van data-acquisitie en opslag

CMDB’s bevatten vaak een kopie van gegevens uit andere bronsystemen. Als bedrijven groeien en ontwikkelen, kan de verzameling gegevens behoorlijk groot worden. De CMDB zal waarschijnlijk een van uw grootste gegevensopslagplaatsen worden binnen de IT.

Data actueel en relevant houden

Uw IT-omgeving verandert continu en terwijl dit gebeurt, moet uw CMDB actueel blijven met nieuwe assets die geïntroduceerd worden in de omgeving, verwijdering van assets die niet meer gebruikt worden en wijzigingen aan bestaande assets.

Bruikbaarheid van data

De toegevoegde waarde van uw configuratiebeheer database zit niet in de gegevens, maar in het gebruik. Om CMDB-data effectief te gebruiken, heeft u waarschijnlijk tools nodig (zoals ITSM -apps en rapportagesystemen), data-analyse vaardigheden (om data de organiseren en verfijnen) en processen voor het gebruik van configuratiedata als onderdeel van de bedrijfsactiviteiten.

CMDB vs Asset management

Er bestaat veel verwarring over het verschil tussen configuratiemanagement en assetmanagement binnen ITSM. Configuratiemanagement en de CMDB houden zich bezig met de data die u gebruikt voor het beheer van uw assets, gedurende de periode dat ze gebruikt worden en aanwezig zijn binnen uw IT-omgeving. Dit is inclusief het begrip over de componenten waaruit een service of asset bestaat, waar het voor wordt gebruikt en wat de relatie is met andere ass ets en/of services.

Assetmanagement is de verzameling processen die gebruikt worden voor het beheren van de levenscyclus van assets, van begin tot eind. Assetmanagementprocessen omvatten vaak zaken zoals werving en aankoop, software licentiebeheer, assetwaardering en processen voor technologieverversing.

10 Incident management

Het doel van de praktijk van incidentenbeheer is de negatieve gevolgen van incidenten door de normale werking van de dienst zo snel mogelijk te herstellen.

Incidenten kunnen worden gediagnosticeerd en opgelost door mensen in veel verschillende groepen, afhankelijk van de complexiteit van het probleem of het incidenttype. Al deze groepen moeten het incident management proces begrijpen , en hoe hun bijdrage daaraan bijdraagt aan het be heer van de waarde, de resultaten, de kosten en risico's van de geleverde diensten:

- Sommige incidenten zullen door de gebruikers zelf worden opgelost, met behulp van zelfhulp. Het gebruik van specifieke zelfhulp moeten worden vastgelegd voor gebruik in meet- en verbeteringsactiviteiten.

- Sommige incidenten zullen worden opgelost door de servicedesk.

- Meer complexe incidenten zullen gewoonlijk worden doorverwezen naar een supportteam om te worden opgelost. Typisch, routing is gebaseerd op de categorie van het incident, wat zou moeten helpen om het juiste team te identificeren.

- Incidenten kunnen worden doorverwezen naar leveranciers of partners, die ondersteuning bieden voor hun producten en diensten.

- De meest complexe incidenten, en alle grote incidenten, verei sen vaak een tijdelijk team om een oplossing te vinden. Dit team kan bestaan uit vertegenwoordigers van vele belanghebbenden, waaronder de dienstverlener, leveranciers, gebruikers, enz.

- In sommige extreme gevallen kan een beroep worden gedaan op noodherste lplannen om een incident op te lossen.

Effectief incident management vereist vaak een hoge mate van samenwerking binnen en tussen teams. Deze teams kunnen de servicedesk, technische ondersteuning, applicatie -ondersteuning en leveranciers omvatten. Samenwerking kan het delen van informatie en leren vergemakkelijken, en ook helpen om het incident efficiënter en effectiever op te lossen.

Producten en diensten van derden die als onderdelen van een dienst worden gebruikt, vereisen ondersteuningsovereenkomsten nodig die de verplichtingen van de leverancier op één lijn brengen met de verplichtingen van de service provider aan klanten. Incident management kan frequente interactie met deze leveranciers vereisen, en routinematig beheer van dit aspect van leverancierscontracten is vaak onderdeel van de incident management praktijk. Een leverancier kan ook optreden als een service desk, die alle incidenten registreert en beheert en ze escaleert naar materiedeskundigen of andere partijen, indien nodig.

Er zou een formeel proces moeten zijn voor het loggen en beheren van incidenten. Dit proces omvat gewoonlijk geen gedetailleerde procedures voor het diagnosticeren, onderzoeken en oplossen van incidenten, maar kan wel voorzien in technieken om onderzoek en diagnose efficiënt er te maken. Er kunnen scripts zijn voor het verzamelen van informatie van gebruikers tijdens het eerste contact, en dit kan direct leiden tot diagnose en oplossing van eenvoudige incidenten. Onderzoek van meer gecompliceerde incidenten vereist vaak kennis en expertise, in plaats van procedurele stappen.

Omgaan met incidenten is mogelijk in elke waardeketenactiviteit, hoewel het meest zichtbaar (vanwege het effect op gebruikers) zijn incidenten in een operationele omgeving.

Definitie Incident

Een ongeplande onderbreking van een dienst of vermindering van de kwaliteit van een dienst.

Incident management kan een enorme impact hebben op klant - en gebruikerstevredenheid, en op hoe klanten en gebruikers de dienstverlener zien. Elk incident moet worden geregistre erd en beheerd om ervoor te zorgen dat het wordt opgelost in een tijd die voldoet aan de verwachtingen van de klant en gebruiker. (Doel)oplostijden worden overeengekomen, gedocumenteerd en gecommuniceerd om ervoor te zorgen dat de verwachtingen realistisch zijn. Incidenten worden geprioriteerd op basis van een overeengekomen classificatie om ervoor te zorgen dat incidenten die de hoogste impact hebben, het eerst worden opgelost.

Organisaties moeten hun incidentbeheersingspraktijk zodanig inrichten dat zij een passend beheer en de toewijzing van middelen aan verschillende soorten incidenten hebben. Incidenten met een geringe impact moeten efficiënt worden beheerd om ervoor te zorgen dat ze niet te veel middelen opslokken. Incidenten met een grotere impact kunnen meer middelen en een complexer beheer vereisen. Er zijn gewoonlijk afzonderlijke processen voor beheer van grote incidenten en voor het beheer van informatiebeveiligingsincidenten.

Informatie over incidenten moet worden opgeslagen in incidentendos siers in een geschikt instrument. Idealiter zou dit instrument ook links naar gerelateerde CI's, wijzigingen, problemen, bekende fouten, en andere kennis om een snelle en efficiënte diagnose en herstel mogelijk te maken. Moderne IT-servicemanagementtools kunnen zorgen voor geautomatiseerde koppeling van incidenten aan andere incidenten, problemen of bekende fouten, en kunnen zelfs intelligente analyse van incidentgegevens om aanbevelingen te genereren voor hulp bij toekomstige incidenten.

Het is belangrijk dat mensen die aan een incident werken tijdig updates van goede kwaliteit leveren. Deze updates moeten informatie bevatten over de symptomen, de impact op de business, de getroffen CI's, de voltooide acties en geplande acties. Elk van deze updates moet een tijdstempel hebben en informatie over de betrokken personen, zodat de betrokken of belanghebbende personen op de hoogte kunnen worden gehouden. Er kan ook behoefte zijn aan goede samenwerkingstools, zodat mensen die aan een incident werken effectief kunnen samenwerken.

10.1 Wat is Incident Management?

Een IT-servicedesk fungeert als enig contactpunt tussen het IT -team en de eindgebruikers. Bedrijven gebruiken ITIL om de efficiëntie en de productiviteit van de dienstverlening te verbeteren. ITIL-servicewerking omvat technieken voor incidentbeheer die als hoofddoel hebben om te zorgen voor een soepele bedrijfsvoering met minimale of geen downtime. Een competent proces voor incident management of incident beheer overbrugt de communicatiekloof tussen eindgebruikers en

IT-medewerkers. Het ITIL incident management proces volgt een reeks beste praktijken voor effectieve incidentafhandeling en incidentoplossing. Laten we eens kijken naar enkele basisprincipes van incidentbeheer.

10.1.1

Wat is een Incident?

Een incident is een onverwachte onderbreking van een dienst. Het verstoort de normale werking en heeft dus invloed op de productiviteit van de eindgebruiker. Een incident kan worden veroorzaakt door een apparaat dat niet goed werkt of door een netwerkstoring. Voorbeelden van incidenten zijn onder meer printerproblemen, problemen met de wifi -verbinding, problemen met toepassingsvergrendeling, problemen met e -maildiensten, gecrashte laptops, fouten met ADverificatie, problemen met het delen van bestanden enz.

10.1.2

Incident vs serviceaanvraag

Serviceaanvragen zijn 'een formeel verzoek van een gebruiker om iets dat moet worden verstrekt, bijvoorbeeld een verzoek om informatie of advies'. Het belangrijkste verschil tussen een incident en een serviceaanvraag is dat vooraf goedgekeurde standaardwijzigingen vaak worden geclassificeerd als serviceaanvragen waar eindgebruikers om vragen. Een UX-ontwerper vraagt bijvoorbeeld om Adobe Photoshop-software en meer RAM-ruimte. Het wordt aanbevolen om een intuïtieve servicecatalogus te hebben om deze aanvraag vast te leggen.

10.1.3

Incident vs probleem

Een probleem is een reeks incidenten met een onbekende hoofdoorzaak, terwijl een incident zich voordoet zodra er iets stuk gaat of niet meer werkt en de normale dienst wordt verstoord. Incidentafhandeling is meestal een reactief proces, terwijl probleembeheer proactiever is. Een incidentbeheersysteem is gericht op het snel herstellen van diensten, terwijl probleembeheer erop is gericht een permanente oplossing te vinden.

10.2 Het ITIL incident management proces

10.2.1

Incidenten Vastleggen

De eerste stap van incident beheer is het melden van het geïdentificeerde incident. Dit kan door de eindgebruikers zelf gedaan worden, of medewerkers kunnen dit namens hen doen. Het ITteam moet volledige informatie over het incident vastleggen met behulp van een formuliersjabloon

om het herstelproces te versnellen. Ze moeten ook relevante kanalen opzetten zodat eindgebruikers een probleem gemakkelijk kunnen melden.

10.2.2 Incidenten Classificeren

Segmenteer de incidenten met de juiste categorie / subcategorie om gemakkelijk de juiste groep en agent te identificeren. Pas het incidentformulier aan met de juiste velden en stel geautomatiseerde regels in voor ticketclassificatie, prioritering en toewijzing en bespaar hierbij kostbare tijd. Een correcte classificatie van incidenten zal helpen bij het sneller genereren van rapporten.

10.2.3 Incidenten Prioriteren

Het toekennen van de juiste prioriteit aan een ticket heeft een directe impact op het bepalen van het SLA-beleid en het op tijd aanpakken van bedrijfskritische problemen. Stel daarom een realistische SLA-definitie op om aan de eisen van de klant te voldoen.

10.2.4 Onderzoek en Diagnose

Wanneer een incident gemeld wordt, voert de incident manager of het IT -team een eerste analyse uit en stuurt een oplossing naar de eindgebruiker. In het geval dat de oplossing niet onmiddellijk beschikbaar is, escaleren ze het incident naar de teams op de tweede en derde lijn voor gedetailleerd onderzoek. Onderdelen die nodig zijn om een incident te identificeren, analyseren en op te lossen worden beoordeeld. Het incident wordt ook gekoppeld aan het relevante CI (configuratie-item) voor een snellere diagnose.

Functionele escalatie

Hierbij is sprake van inschakeling van meer specialismen of toegangsrechten (technische bevoegdheid) in het oplostraject, waarbij soms afdelingsgrenzen worden overschreden.

Hiërarchische escalatie

Hierbij wordt een verticaal beroep gedaan op hogere lagen van de organisatie omdat de huidige autoriteit onvoldoende is (organisatorische bevoegdheid of macht) of de resources voor het oplossen niet in voldoende mate beschikbaar zijn.

1- nde lijns support

1-ste lijns is meestal de Service Desk, 2-de lijn de beheerafdelingen, 3-de lijn de ontwikkelaars en architecten, n-de lijn: de leveranciers.

10.2.5 Incidentoplossing en Sluiting

Een van de belangrijkste doelen van elk IT-team is om elk incident zo snel mogelijk op te lossen. Efficiënte communicatie over het oplossen en sluiten van de opgeloste tickets is erg belangrijk. Het team kan zelfs het proces van het sluiten van de opgeloste tickets automatiseren of de gebruiker kan dit zelf doen via het selfserviceportaal.

10.3 Checklist voor het incident management proces vo or incident beheer

• Kanalen - Ondersteuning voor meerdere kanalen breidt de mogelijkheid uit om altijd en overal beschikbaar te zijn

• Gebruikersbeheer - Beheer automatisch de gegevens in het gebruikersprofiel van de helpdeskmedewerkers en aanvragers. Dit kan ook handmatig worden gedaan via CSVbulkimport, Active Directory-integratie of integratie van externe identiteitsproviders. Dit biedt een betere context voor servicedesk medewerkers bij het oplossen van incidenten.

• Aangepaste formulieren - Pas het formuliersjabloon van incidenten aan om de juiste informatie vast te leggen, het aantal oplossingen binnen het eerste gesprek (First Call Resolution of FCR) te verbeteren en het ticket aan de juiste agent toe te wijzen.

• Automatische toewijzing - Automatiseer ticketclassificatie en toewijzing op basis van ticketeigenschappen met behulp van workflows. Schakel indien nodig beurtelingse toewijzing van tickets in voor de verdeling van de werklast. Dit verhoogt de efficiëntie en elimineert overbodige activiteiten zoals het toewijzen van tickets.

• Realistische SLA-definitie - Maak meerdere SLA-beleidsregels wanneer meer dan één groep is opgenomen in de servicedesk. Definieer escalatieregels om SLA-schendingen aan te pakken, zodat agents die aan de tickets werken op tijd of vooraf worden geïnformeerd. Voldoen aan de SLA verbetert de productiviteit en gebruikerstevredenheid. Meer over sla management

• CMDB - Koppel het juiste configuratie-item (CI), dat het incident veroorzaakt of beïnvloedt, aan het ticket. Dit geeft een betere context tijdens de afhandeling van incidenten. Onderhoud relaties tussen apparaten zodat de diagnose gemakkelijker wordt. Dit helpt bij het analyseren van de oorzaak en het verminderen van MTTR.

• Kennisbank - Integreer de kennisbank binnen incident management om vaak ingediende tickets te voorkomen. Voeg visuele elementen toe, zoals afbeeldingen en video's, en

categoriseer de artikelen in relevante mappen om de kennisbank te vergroten. Meer over kennisbank

• Meldingen - Personaliseer e-mailsjablonen voor het verzenden van meldingen door dynamische plaatshouders op te nemen en het proces te automatiseren. Configureer meldingen via meerdere kanalen zoals e-mail, mobiele pushmeldingen, sms enz. om gebruikers en helpdeskmedewerkers op de hoogte te houden.

• Klanttevredenheidsonderzoek - Configureer een enquête om de klanttevredenheid na oplossing te beoordelen. Dit is een voorbeeld van continue serviceverbetering en het stimuleren van goed presterende agents op basis van de resultaten.

• Sluiting - Stel een automatiseringsregel in om het proces voor het sluiten van tickets te automatiseren of laat eindgebruikers zelf tickets sluiten via het selfserviceportaal.

10.4 Best practices voor incident management

Eenvoudig toegankelijk

Zorg ervoor dat u uw servicedesk sterk promoot bij eindgebruikers en meerdere kanalen aanbiedt, zoals e-mail, web en een mobiele app om een incident te melden. Het vastleggen van incidenten wordt efficiënter met een gemakkelijk toegankelijke IT-servicedesk met meerdere kanalen.

Effectieve communicatiestrategie

Communiceer het eerste antwoord en oplossing aan eindgebruikers door relevante e -mailmeldingen te verzenden. Volg een effectieve strategie om meldingen te activeren voor ticketupdates, antwoorden en statusupdates.

Automatiseer zo veel mogelijk

Identificeer taken die geautomatiseerd kunnen worden om handmatig werk te verminderen en de efficiëntie te verbeteren. Automatiseer e-mailmeldingen zodat helpdeskmedewerkers en eindgebruikers op de hoogte blijven.

Motiveer uw agents

Stel duidelijke doelen voor uw team en communiceer KPI's die zijn afgestemd op bedrijfsdoelen. Dat gezegd hebbende, speelt het moreel van agents een grote rol bij het leveren van hoogwaardige dienstverlening en het verbeteren van de tevredenheid van eindgebruikers. Gamificeer daarom uw IT-servicedesk door spelelementen toe te voegen.

10.5 Rollen & verantwoordelijkheden van de incident manager

Een incident manager is iemand die het ITIL incident management proces voor de organisatie bedenkt en beheert en de beste praktijken van ITIL in het proces opneemt. De incident manager is verantwoordelijk voor de volgende taken:

• Het opzetten van het proces in lijn met de bedrijfsdoeleinden

• Het naleven van het proces en SLA

• Het beheren van het incidentteam op meerdere niveaus (eerste, tweede en derde lijn)

• Het genereren van periodieke rapporten en behouden van Prestatie -indicatoren (Key Performance Indicators of KPI)

• Het fungeren als escalatiepunt om grote incidenten op te lossen

• Het coördineren met andere teams zoals probleembeheer, wijzigingsbeheer en configuratiebeheer.

10.6 Voordelen van Incident management

Het incident management systeem biedt de volgende voordelen

• Soepele bedrijfsvoering

• Verbeterde productiviteit

• Tevreden eindgebruikers

• Behoud van consistente serviceniveaus

• Proactieve identificatie en voorkomen van grote incidenten

10.7 5 DON’Ts van Incident Management

• Volg het proces niet blindelings - Beoordeel de volwassenheid en bedrijfsvisie. Pas het proces aan; test en beoordeel continu met eindge bruikers.

• Focus niet altijd op oplossingen binnen het eerste gesprek - Statistieken zijn belangrijk, maar het oplossen van het probleem is belangrijker dan het bieden van een onnauwkeurige oplossing tijdens het eerste gesprek. Stel daarom realistische stat istieken op en meet ze voor constante verbetering

• Werk niet afgesloten - Werk samen met collega's en andere teams zoals probleembeheer, assetbeheer en wijzigingsbeheer voor een betere context.

• Kies niet voor een servicedeskoplossing die niet geschikt is - De servicedeskoplossing die u implementeert, moet aanpasbaar zijn op het gebied van merkuitstraling, het configureren van kanalen, formulieren en SLA. Stem de servicedeskoplossing af op uw zakelijke behoeften.

• Raak niet overweldigd door de vele incidenten - Soms demotiveert een enorm aantal tickets de medewerkers. Gamificeer uw servicedesk om het moreel te verbeteren en de motivatie van servicedesk medewerkers te vergroten.

11 Request fulfilment

Het doel van de praktijk van service request mana gement is het ondersteunen van de overeengekomen kwaliteit van een service door alle vooraf gedefinieerde, door de gebruiker geïnitieerde serviceverzoeken op een effectieve en gebruikersvriendelijke manier te behandelen.

Definitie Serviceverzoek

Een verzoek van een gebruiker of een gemachtigde vertegenwoordiger van een gebruiker die een serviceactie initieert die is overeengekomen als een normaal onderdeel van de dienstverlening.

Elk dienstverzoek kan een of meer van de volgende elementen omvatten

- een verzoek om een dienstverleningsactie (bijvoorbeeld het verstrekken van een rapport of het vervangen van een toner cartridge)

- een verzoek om informatie (bijvoorbeeld hoe een document moet worden aangemaakt of wat de openingstijden van het kantoor zijn)

- een verzoek om levering van een middel of dienst (bijvoorbeeld het verstrekken van een telefoon of laptop aan een gebruiker, of een virtuele server voor een ontwikkelingsteam)

- een verzoek om toegang tot een middel of dienst (bijvoorbeeld toegang tot een besta nd of map)

- feedback, complimenten en klachten (bijvoorbeeld klachten over een nieuwe interface of complimenten aan een ondersteuningsteam).

De afhandeling van serviceverzoeken kan wijzigingen in diensten of onderdelen daarvan omvatten; gewoonlijk zijn dit standaardwijzigingen. Serviceverzoeken zijn een normaal onderdeel van de dienstverlening en zijn geen storing of verslechtering van de dienstverlening, die worden behandeld als incidenten. Aangezien dienstverzoeken vooraf worden gedefinieerd en vooraf worden overeengekomen als een normaal onderdeel van de dienstverlening, kunnen ze meestal worden geformaliseerd, met een duidelijke, standaard procedure voor initiatie, goedkeuring, uitvoering, en management. Sommige service requests hebben zeer eenvoudige wor kflows, zoals een verzoek om informatie. Andere, zoals de aanstelling van een nieuwe werknemer, kunnen vrij complex zijn en vereisen bijdragen van vele teams en systemen voor de afhandeling.

Ongeacht de complexiteit moeten de stappen om een verzoek in te w illigen bekend en beproefd zijn. Daarvoor kan de dienstverlener tijdstippen afspreken voor de afhandeling en kan hij de status van het verzoek aan de gebruikers duidelijk communiceren.

Voor sommige dienstverzoeken is autorisatie nodig op grond van financieel, informatiebeveiligings-, of ander beleid, terwijl voor andere misschien geen autorisatie nodig is. Om met succes te worden afgehandeld, moet het beheer van serviceverzoeken deze richtlijnen volgen:

- Service requests en de afhandeling ervan moeten zoveel mogelijk gestandaardiseerd en geautomatiseerd worden.

- Er moeten beleidsregels worden opgesteld met betrekking tot welke service requests zullen worden vervuld met beperkte of zelfs geen extra goedkeuringen, zodat de afhandeling kan worden gestroomlijnd.

- De verwachtingen van de gebruikers inzake uitvoeringstermijnen moeten duidelijk worden vastgesteld, gebaseerd op wat de organisatie realistisch gezien kan leveren.

- Mogelijkheden voor verbetering moeten worden geïdentificeerd en geïmplementeerd om snellere service te bieden en voordeel te halen uit automatisering waar mogelijk.

- Beleid en workflows moeten worden opgenomen voor het documenteren en doorsturen van alle verzoeken die worden ingediend als service requests, maar die eigenlijk moeten worden beheerd als incidenten of wijzigingen.

Sommige service requests kunnen volledig door automatisering worden afgehandeld van indiening tot afsluiting, door het toestaan van een volledige self -service ervaring. Voorbeelden zijn de installatie van clientsoftware of de levering van virtuele servers.

Beheer van serviceverzoeken is afhankelijk van goed ontworpen processen en procedures, die worden worden geoperationaliseerd door middel van tracking- en automatiseringstools om de efficiëntie van de praktijk te maximaliseren.

Verschillende soorten serviceverzoeken zullen verschillende workflows hebben, maar zowel de efficiëntie als de onderhoudbaarheid worden verbeterd als een beperkt aantal workflowmodellen wordt vastgesteld. Wanneer nieuwe nieuwe verzoeken moeten worden toegevoegd aan de dienstencatalogus, moeten bestaande workflowmodellen zoveel mogelijk worden benut.

11.1 Wat is een verzoek?

Een verzoek is een formeel verzoek van een gebruiker om iets te leveren. ITIL gebruikt ook de term service request voor een verzoek dat onder ITSM wordt beheerd. De details van een serviceverzoek worden door request fulfilment vastgelegd in een serviceverzoekrecord. Serviceverzoeken worden vaak naar de servicedesk gestuurd, maar kunnen ook rechtstreeks worden gerouteerd naar het team dat verantwoordelijk is voor de afhandeling van het verzoek. Soms wordt deze routering van een dienstverzoek voor latere afhandeling bereikt door gebruik te maken van software voor dienstverzoeken. Serviceverzoeken zijn meestal gericht aan IT, maar een serviceverzoek kan ook een verzoek zijn aan de servicedesk om iets te doen of aan andere onderdelen van het bedrijf om iets te leveren, waaronder personeelszaken en inkoop.

Serviceverzoeken kunnen een verzoek om informatie, een verzoek om het opnieuw instellen v an een wachtwoord, een verzoek om advies, een verzoek om nieuwe software en een verzoek om het verplaatsen van apparatuur omvatten. Voorbeelden zijn het vragen van een adreswijziging in een personeelsdossier, het aanvragen van een nieuwe mobiele telefoon, en het vragen om een nieuwe versie van flowcharting software op een laptop te laden. Sommige categorieën van serviceverzoeken moeten worden goedgekeurd voordat ze kunnen worden uitgevoerd. Zo kan het bijvoorbeeld nodig zijn dat een budgethouder een verzoek om een nieuwe laptop aan te schaffen goedkeurt voordat het serviceverzoek wordt doorgegeven aan de inkoopafdeling.

11.2 Wat is het verschil tussen een incident en een service request?

Simpel gezegd: een incident treedt op als er iets kapot is gegaan, terwijl een request wordt gedaan als een gebruiker iets nieuws of anders wil. In ITIL wordt een incident gedefinieerd als "Een ongeplande onderbreking van een IT-service of vermindering van de kwaliteit van een IT -service. Het falen van een configuratie-item dat de service nog niet heeft beïnvloed is ook een incidentbijvoorbeeld het falen van één disk uit een mirrorset." Terwijl ITIL een serviceverzoek definieert als "Een formeel verzoek van een gebruiker om iets te leveren - bijvoorbeeld een verzoek om informatie of advies; om een wachtwoord opnieuw in te stellen, of om een werkstation te installeren voor een nieuwe gebruiker". Het afhandelen van een verzoek verschilt van incident management. Incident management richt zich op het herstellen van services als er e en onderbreking of kwaliteitsvermindering is geweest, terwijl request fulfilment zich niet bezighoudt met service storingen.

11.3 Wat is request fulfilment in ITIL?

Request fulfilment is het proces dat serviceverzoeken beheert gedurende hun levenscyclus, vanaf de initiële indiening van het verzoek tot aan de afsluiting ervan. Request fulfilment werd als een nieuw proces toegevoegd aan ITIL V3 met het doel een specifiek proces te hebben voor het behandelen van serviceverzoeken. Voordien beheerde het incidentbeheerproces zowel verzoeken als incidenten. Dit was ingegeven door een duidelijk onderscheid in ITIL V3 tussen incidenten (dienstonderbrekingen) en dienstverzoeken (standaardverzoeken van gebruikers, bv. wachtwoordresets). Request fulfilment is volledig herzien. Request fulfilment bestaat uit vijf subprocessen, waarbij elk subproces een gedetailleerde beschrijving geeft van de gerelateerde activiteiten en beslispunten. Request fulfilment heeft raakvlakken met incident management, voor verzoeken die vervolgens worden gediagnosticeerd als incidenten, en met service transitie voor als het voldoen aan het verzoek de betrokkenheid van change management vereist. ITIL request fulfilment verwijst naar een service request model, dat specifieke overeengekomen stappen definieert die zullen worden gevolgd voor een service request van een bepaald type of categorie. ITIL kent ook het concept van statusinformatie van een serviceverzoek. Dit is een bericht met de huidige status van een service request dat kan worden verstrekt aan de gebruiker die het verzoek heeft gedaan. Statusinformatie wordt typisch verstrekt aan gebruikers door het request fulfilment proces op verschillende momenten tijdens de levenscyclus van een service request.

11.4 Wat zijn de doelstellingen van het ITIL reque st fulfilment proces?

Het primaire doel van ITIL request fulfilment is het vervullen van serviceverzoeken die door gebruikers worden gedaan. In veel gevallen zijn de service requests standaardwijzigingen, zoals een

verzoek om een wachtwoord te wijzigen, of een verzoek om informatie. Eenvoudig gezegd, request fulfilment gaat over het verlenen van toegang aan gebruikers tot de services die IT voor hen beschikbaar maakt. Verwante doelstellingen voor het request fulfilment proces zijn onder andere:

• Gebruikers helpen te begrijpen welke services voor hen beschikbaar zijn, hoe ze die kunnen aanvragen, en hoe lang het zou moeten duren voordat ze worden vervuld

• Een bruikbaar proces creëren voor het verwerken en afhandelen van dienstverzoeken

• De levering van de gevraagde diensten binnen de gestelde termijn beheren

• gebruikers op de hoogte houden van de status van hun verzoek

• Verzoeken om algemene informatie, opmerkingen en klachten verwerken.

11.4.1 Wat zijn de activiteiten bij het afhandelen van verzoeken?

De activiteiten bij het afhandelen van verzoeken worden in volgorde van binnenkomst uitgevoerd:

• De eerste activiteit is wanneer een gebruiker een dienstverzoek plaatst. Gebruikers kunnen op verschillende manieren een serviceverzoek indienen, onder meer per telefoon, e -mail, sociale media en via selfservice met behulp van software voor request fulfilm ent. De informatie wordt vastgelegd in een service request record.

• Zodra een verzoek is ingediend, moet het worden goedgekeurd voordat het kan worden uitgevoerd op het eerste niveau of kan worden doorgestuurd naar het tweede niveau om te worden uitgevoerd. Sommige soorten diensten vereisen goedkeuring van het management, de financiën, de beveiliging of de naleving van de regelgeving voordat aan het verzoek kan worden voldaan. Het verzoek model zal alle passende goedkeuringsstappen definiëren, inclusief hoe afgewezen verzoeken moeten worden beheerd.

• Zodra een verzoek is goedgekeurd kan het worden toegewezen aan de juiste persoon of verzoek fulfilment groep om te beoordelen en vervolgens te vervullen. Eenvoudige verzoeken worden vaak direct door de 1e lijns support afgehandeld. Verzoeken die de aankoop van producten van derden of de levering van diensten door een 2e niveau vereisen, kunnen worden doorgestuurd naar leveranciers of naar interne bronnen om te worden uitgevoerd.

• In elke fase van de afhandeling van een verzoek moet de gebruiker op de hoogte worden gehouden van de status van zijn verzoek met behulp van informatie over de status van het verzoek.

• Een verzoek moet worden afgesloten zodra het is ingewilligd en de aanvrager heeft bevestigd dat hij tevreden is over de inwilliging, of indien het verzoek is afgewezen.

• De verzoeken moeten worden gerapporteerd aan het management, zodat eventuele noodzakelijke verbeteringen in het proces van uitvoering van het verzoek kunnen worden geïdentificeerd en uitgevoerd.

11.5 Wat zijn de subprocessen van ITIL request fulfilment?

ITIL request fulfilment heeft vijf subprocessen:

Request fulfilment ondersteuning

Dit deelproces van request fulfilment levert en onderhoudt de tools, het service request model, de processen, de vaardigheden en het beleid die nodig zijn voor de effectieve en efficiënte uitvoering van de efficiënte afhandeling van service requests.

Loggen en categoriseren van verzoeken

Dit deelproces van request fulfilment registreert en categoriseert de service reques ts, inclusief het controleren van de requests op volledigheid en de autorisatie van de requester om ze in te dienen, ter ondersteuning van een snelle en effectieve afhandeling van de service requests.

Uitvoering van het verzoekmodel

Het doel van dit deelproces van de afhandeling van verzoeken is om de levenscyclus van een dienstverzoek uit te voeren binnen het tijdschema dat is overeengekomen in de service level agreement.

Monitoring en escalatie van verzoeken

Dit deelproces van de afhandeling van verzoeken heeft tot doel de afhandelingsstatus van lopende dienstverzoeken voortdurend te bewaken, zodat zo snel mogelijk actie kan worden ondernomen als het serviceniveau dreigt te worden overschreden.

Afsluiting en evaluatie van verzoeken

Dit deelproces van de afhandeling van verzoeken voert kwaliteitscontroles uit op de afhandeling van het dienstverzoek en het bijbehorende dienstverzoekdossier voordat het verzoek volledig kan worden afgesloten. Het doel is ervoor te zorgen dat het verzoek op bevredigende wijze i s afgehandeld en dat alle informatie die nodig is om de levenscyclus van het verzoek te beschrijven, voldoende gedetailleerd is vastgelegd. Het deelproces heeft ook tot doel het proces van afhandeling van verzoeken voortdurend te verbeteren door lessen te trekken uit de afhandeling van dit verzoek voor de toekomst.

11.6 Wat zijn de rollen en verantwoordelijkheden bij de afhandeling van verzoeken?

Bij het afhandelen van verzoeken zijn een aantal verschillende rollen betrokken. Deze rollen kunnen worden vervuld door dezelfde persoon, of door verschillende personen.

Gebruikers - Aanvrager

Gebruikers zijn verantwoordelijk voor het indienen van serviceverzoeken volgens de methode die is overeengekomen en gedocumenteerd in het model voor serviceverzoeken bij de afhande ling van verzoeken. Gebruikers moeten worden opgeleid in het indienen van dienstverzoeken, in het

verkrijgen van updates over de status van hun verzoek, en in het aanvaarden van de afsluiting van het dienstverzoek nadat het is uitgevoerd.

1e niveau ondersteuning

1e niveau support, vaak de service desk, heeft als taak service verzoeken te registreren en te categoriseren op basis van de informatie die hen door de gebruikers wordt verstrekt. 1e niveau support is verantwoordelijk voor het doorgeven van onvervulde verzoeken aan 2e niveau support voor afhandeling. Deze staan ook bekend als request fulfilment groups. 1e niveau support is ook verantwoordelijk voor het op de hoogte houden van de gebruikers over de status van de service verzoeken via het request fulfilment proces.

Request fulfilment groep

Er kunnen meerdere request fulfilment groepen zijn, waarbij elke groep verantwoordelijk is voor het uitvoeren van de afhandeling van specifieke categorieën en types van service requests. Voor sommige soorten dienstverzoeken kan het nodig zijn dat een fulfilment group de hulp inroept van een andere gespecialiseerde request fulfilment group, bijvoorbeeld het inschakelen van een inkoopfunctie wanneer apparatuur of diensten moeten worden aangekocht om aan het dienstverzoek te voldoen.

Goedkeurders van dienstverzoeken

Sommige categorieën van dienstverzoeken moeten worden goedgekeurd voordat zij kunnen worden uitgevoerd. Het kan gaan om financiële goedkeuring wanneer uitgaven vereist zijn en de kosten om het dienstverzoek in te willigen hoger liggen dan de goedkeuringslimiet van de verzoeker. Het kan ook gaan om veiligheidsgoedkeuring indien het type van gevraagde dienst vereist dat de aanvrager over voldoende veiligheidsmachtiging beschikt. Sommige organisaties staan erop dat lijnmanagers alle service requests die niet alleen informatieverzoeken zijn, beoordelen en goedkeuren.

Incident Manager

De incident manager is de proceseigenaar voor het request fulfilment proces. Hij is verantwoordelijk voor het effectieve ontwerp, de implementatie, het change management en de voortdurende verbetering van het request fulfilment proces. De rol voert ook de rapportage uit voor de Key Performance Indicators (KPI's) van het proces en is verantwoordelijk voor het definiëren va n de interfaces tussen het request fulfilment proces en gerelateerde ITSM processen waaronder incident management, access management, knowledge management, change management, financial management, en configuration & asset management. De functie biedt de ee rste fase van escalatie voor eventuele problemen met request fulfilment, met inbegrip van en verzoeken die niet kunnen worden voldaan binnen de overeengekomen service levels.

11.7 Wat zijn typische request fulfilment workflows?

De precieze details van request fulfilment workflows zullen afhangen van de behoeften en de organisatorische structuren van elk bedrijf. Hier volgen enkele voorbeelden van verschillende

soorten typische request fulfilment workflows die kunnen worden geconfigureerd in de service request software:

Verzoek om informatie

In dit type service request vraagt de gebruiker om informatie, zoals 'Op welke uren is de servicedesk beschikbaar'. Om dit type serviceverzoeken te verminderen, zou idealiter zoveel mogelijk informatie ter beschikking van de gebruikers moeten worden gesteld in een gemakkelijk toegankelijke en begrijpelijke kennisbank. Het is echter nooit mogelijk om dit soort verzoeken volledig te elimineren bij de afhandeling van verzoeken. De eerste stap in deze request fulfilment workflow is dat de gebruiker de vraag stelt, hetzij door deze in te voeren in een request fulfilment software tool of door contact op te nemen met de servicedesk die de vraag dan namens de gebruiker invoert. Een request fulfilment tool kan type-ahead zoekmogelijkheden hebben, waarbij mogelijke antwoorden worden gepresenteerd en worden verfijnd naarmate meer informatie over het verzoek wordt ingevoerd. Het kan mogelijk zijn om op dit punt aan het verzoek te voldoen door de gebruiker de informatie te geven waarnaar hij op zoek is. Indien dit niet mogelijk is, moet de workflow voor de afhandeling van het verzoek gebruik maken van de in het verzoek verstrekte informatie en de regels in het model van het dienstverzoek om het verzoek naar de juiste afhandelingsgroep te ro uteren. Deze fulfilment groep kan dan ofwel rechtstreeks contact opnemen met de gebruiker met de gevraagde informatie ofwel deze informatie naar de gebruiker sturen met behulp van de request fulfilment tool. Het service request kan in de software worden gesloten zodra de gebruiker heeft bevestigd dat zijn verzoek naar tevredenheid is afgehandeld.

‘Hoe doe ik' verzoek

Dit zijn service verzoeken waarbij de gebruiker vraagt hoe hij iets moet doen. De workflow voor dit type verzoek lijkt sterk op die van een verzoek om informatie. Sommige organisaties gebruiken dezelfde workflow voor het afhandelen van verzoeken. Ook hier is het ideaal dat het verzoek kan worden afgehandeld met behulp van een request fulfilment software tool en zo niet automatisch wordt gerouteerd naar de juiste request fulfilment groep. Het verschil tussen dit type verzoek en een verzoek om informatie is dat een "hoe doe ik" -verzoek aangeeft dat de gebruiker verdere opleiding nodig heeft in het onderwerp waar hij naar vraagt, of dat het opleidingsmateriaal dat gebruikt werd om hem op te leiden, ontoereikend is. Daarom is het een goede praktijk om "hoe doe ik" -verzoeken bij de afhandeling van verzoeken apart te categoriseren van informatieverzoeken. Voor deze categorie kunnen rapporten worden gegenereerd en naar de opleidingsfunctie worden gestuurd, zodat zij passende actie kunnen ondernemen.

Wachtwoord reset verzoek

De meeste organisaties hebben nu software geïnstalleerd waarmee verzoeken om wachtwoorden te resetten kunnen worden afgehandeld zonder dat daarbij ondersteuning nodig is van iemand anders dan de gebruiker zelf. Deze software kan deel uitmaken van de software voor het vervullen van verzoeken of er los van staan, maar met een link ernaar, zodat de gebruiker toegang heeft tot de reset-functionaliteit via het menu in de software voor het vervullen van verzoeken. Als dit niet is gedaan, is het waarschijnlijk dat er een groot volume aan wachtwoordresetverzoeken zal zijn, dus het

request fulfilment-proces voor het beheer ervan moet efficiënt zijn. Het is belangrijk om verzoeken voor het resetten van wachtwoorden bij te houden om eventuele recidivisten te identificeren die baat zouden kunnen hebben bij training. Dit soort workflow voor het verwerken van verzoeken heeft een veiligheidsaspect. Het is belangrijk om de identiteit te verifiëren van de gebruiker die het verzoek indient, omdat het kan gaan om een frauduleuze poging om toegang te krijgen tot systemen met gebruikmaking van hun inloggegevens. Daarom is het van vitaal belang om een verzoekve rvullende workflowstap op te nemen die de verificatie van de identiteit van de gebruiker omvat voordat het wachtwoord wordt gereset. Dit is in wezen toegangscontrole, het proces dat ervoor zorgt dat gebruikers gebruik kunnen maken van IT-diensten, gegevens of andere bedrijfsmiddelen.

Verzoek om bureauverplaatsing

In dit type verzoek-workflow verhuist een gebruiker bureaus van de ene locatie in een organisatie naar een andere. Hierbij kunnen een aantal verschillende activiteiten en fulfilment groepen betrokken zijn, waaronder IT om de apparatuur te verplaatsen, beveiliging om nieuwe toegangspassen uit te geven, en kantoordiensten om de locatiegegevens van het gebouw bij te werken. Een efficiënte request fulfilment workflow voor dit type verzoek zou alle relevante request fulfilment groepen op hetzelfde moment informeren over de verhuizing, en hen alle zicht geven op de plannen van de andere request fulfilment groepen, zodat zij de verhuizing onderling kunnen coördineren. Het dienstverzoek kan pas worden afgesloten in het verzoekvervullingsproces wanneer alle samenstellende activiteiten zijn voltooid. Dit is een goed voorbeeld van een multi -branch request fulfilment workflow.

Nieuwe software aanvraag

Wanneer een gebruiker nieuwe software aanvraagt, zal de workflow voor de afhandeling van het verzoek waarschijnlijk een aantal verschillende goedkeurders omvatten. Als de software nergens anders in de organisatie wordt gebruikt, dan zal het request fulfilment proces goedkeuring moeten vragen aan het team dat verantwoordelijk is voor de IT architectuur. Als IT budgetten centraal worden beheerd dan zal de request fulfilment workflow een stap moeten bevatten om goedkeuring te vragen aan de budgethouder voor IT. Sommige organisaties kunnen ook de goedkeuring en een schriftelijke rechtvaardiging van het afdelingshoofd van de gebruiker vragen. Zodra alle goedkeuringen zijn gegeven, moet het serviceverzoek worden doorgegeven aan inkoop om de software aan te schaffen, vervolgens aan IT om het te testen, en mogelijk aan desk top support om het te implementeren. Dit type service request kan complex zijn om te definiëren in het request fulfilment model, maar zodra dit is voltooid kunnen alle gelijksoortige service requests efficiënt worden beheerd om te worden vervuld.

Rapportage verzoek

Deze request fulfilment workflow wordt gebruikt wanneer een gebruiker wil dat IT een rapport voor hem maakt. Dit is een eenvoudige workflow voor het request fulfilment proces, omdat het gewoonlijk direct naar IT kan worden gerouteerd zonder enige voorafgaande review of goedkeuringsfase.

11.8

Hoe kunt u de effectiviteit van request fulfilment meten?

ITIL omvat de definitie van enkele belangrijke meetcriteria voor request fulfilment die kunnen worden gebruikt om zowel de efficiëntie als de effectiviteit van het request fulfilment proces te beoordelen. De voorgestelde metrieken omvatten:

• Hoe tevreden de gebruikers zijn met de manier waarop hun serviceverzoeken worden beheerd en afgehandeld

• Het aantal openstaande service requests op elk moment

• Hoe lang het duurt om elk type service request af te handelen

• De gemiddelde kosten van het afhandelen van elk type service request

• Het percentage dienstverzoeken dat door het proces van afhandeling binnen de overeengekomen serviceniveaus wordt afgehandeld

• Een uitsplitsing van dienstverzoeken naar stadium, inclusief ontvangen, in behandeling, in afwachting van goedkeuring, afgesloten en afgewezen.

12 Problem management

Het doel van de probleembeheerpraktijk is de waarschijnlijkheid en de impact van incidenten te verminderen door de werkelijke en potentiële oorzaken van incidenten te identificeren, en workarounds en bekende fouten te beheren.

Definitie Probleem

Een oorzaak, of potentiële oorzaak, van één of meer incidenten.

Definitie Bekende fout

Een probleem dat is geanalyseerd maar nog niet is opgelost.

Elke dienst heeft fouten, gebreken of kwetsbaarheden die incidenten kunnen veroorzaken. Het kan gaan om fouten in elk van de vier dimensies van servicemanagement. Veel fouten worden geïdentificeerd en opgelost voordat een service live gaat. Echter, sommige blijven ongeïdentificeerd of onopgelost, en kunnen een risico vormen voor live services. In ITIL worden deze fouten problemen genoemd en ze worden aangepakt door de probleembeheerpraktijk.

Problemen zijn verwant aan incidenten, maar moeten van elkaar worden onderscheiden omdat ze op verschillende manieren worden beheerd:

- Incidenten hebben een impact op gebruikers of bedrijfsprocessen, en moeten worden opgelost zodat de normale bedrijfsactiviteit kan plaatsvinden.

- Problemen zijn de oorzaken van incidenten. Ze vereisen onderzoek en analyse om de oorzaken te identificeren, workarounds te ontwikkelen en oplossingen op langere termijn aan te bevelen. Dit vermindert het aantal en de impact van toekomstige incidenten.

Wanneer een probleem niet snel kan worden opgelost, is het vaak nuttig om een workaround te vinden en te documenteren voor toekomstige incidenten, gebaseerd op een goed begrip van het probleem. Workarounds worden gedocumenteerd in probleem records. Dit kan in elk stadium worden gedaan; er hoeft niet te worden gewacht tot de analyse is voltooid. Als een workaround vroeg in het probleembeheer is gedocumenteerd, dan moet deze worden herzien en worden verbeterd nadat de probleemanalyse is voltooid.

Definitie Workaround

Een oplossing die de impact van een incident of probleem vermindert of elimineert waarvoor nog geen volledige oplossing nog niet beschikbaar is. Sommige workarounds verminderen de kans op incidenten.

Een effectieve incident workaround kan een permanente manier worden om met sommige problemen om te gaan wanneer het oplossen van het probleem niet haalbaar of kosteneffectief is. In dat geval blijft het probleem in de bekende foutstatus, en wordt de gedocumenteerde workaround

toegepast als zich gerelateerde incidenten voordoen. Elke gedocumenteerde workaround moet een duidelijke definitie bevatten van de symptomen waarop hij van toepassing is. In sommige gevallen kan de toepassing van de workaround worden geautomatiseerd.

Probleembeheer omvat drie afzonderlijke fasen:

Probleemidentificatie

Probleemidentificatie identificeert en registreert problemen. Deze omvatten:

- uitvoeren van trendanalyses van incident records

- opsporen van dubbele en terugkerende problemen door gebruikers, service desk, en technische support medewerkers

- tijdens het beheer van grote incidenten, vaststellen van een risico dat een incident zich opnieuw voordoet

- analyse van informatie ontvangen van leveranciers en partners

- analyseren van informatie ontvangen van interne softwareontwikkelaars, testteams, en project teams.

Ook andere informatiebronnen kunnen leiden tot het identificeren van problemen.

Probleembeheersing

Probleembeheersingsactiviteiten omvatten probleemanalyse, en het documenteren van workarounds en bekende fouten.

Problemen worden met voorrang geanalyseerd op basis van het risico dat ze vormen, en worden beheerd als risico's op basis van hun potentiële impact en waarschijnlijkheid. Het is niet essentieel om elk probleem te analyseren; het kan waardevoller z ijn om significante vooruitgang te boeken bij de problemen met de hoogste prioriteit dan om elk minder belangrijk probleem te onderzoeken waarvan de organisatie op de hoogte is.

Incidenten hebben doorgaans vele onderling samenhangende oorzaken, en de relat ies tussen die oorzaken kunnen complex zijn. Probleembeheersing moet alle bijdragende oorzaken in overweging nemen, inclusief oorzaken die hebben bijgedragen aan de duur en de impact van incidenten, maar ook aan de oorzaken die ertoe hebben geleid dat de incidenten plaatsvonden. Het is belangrijk om problemen te analyseren vanuit het perspectief van alle vier de dimensies van service management.

Bijvoorbeeld, een incident dat werd veroorzaakt door onnauwkeurige documentatie kan niet alleen een correctie betekenen van die documentatie, maar ook training en bewustwording van ondersteunend personeel, leveranciers en gebruikers.

Foutcontrole

Er moet een manier worden gevonden om de fout te herstellen. Dit is een onderdeel van foutbeheersing. Foutenbeheersing is gericht op bekende fouten, d.w.z. problemen waarvan de initiële analyse is voltooid; meestal betekent dit dat foutieve onderdelen zijn geïdentificeerd.

Foutenbeheersing omvat ook de identificatie van potentiële permanente oplossingen die kunnen leiden tot een wijzigingsverzoek voor de uitvoering van een oplossing, maar alleen als dit kan worden gerechtvaardigd in termen van kosten, risico's en baten.

Bij foutenbeheersing wordt de status van bekende fouten die niet zijn opgelost, regelmatig opnieuw beoordeeld, met inbegrip van algemene impact op klanten, beschikbaarheid en kosten van permanente oplossingen, en effectiviteit van workarounds. De doeltreffendheid van workarounds moet telkens worden geëvalueerd wanneer een workaround wordt gebruikt, aangezien de workaround op basis van de evaluatie kan worden verbeterd.

Probleembeheeractiviteiten zijn zeer nauw verwant met incidentbeheer. De praktijken moeten worden ontworpen om samen te werken binnen de waardeketen. Activiteiten uit deze twee praktijken kunnen elkaar aanvullen (bijvoorbeeld, het identificeren van de oorzaken van een incident is een probleem management activiteit die kan leiden tot het oplossen van incidenten), maar ze kunnen ook conflicteren (bijvoorbeeld het onderzoeken van de oorzaak van een inc ident kan acties vertragen die nodig zijn om de service te herstellen).

Voorbeelden van raakvlakken tussen problem management, risk management, change enablement, kennismanagement, en continue verbetering zijn de volgende:

- Probleembeheeractiviteiten kunnen worden georganiseerd als een specifiek geval van risicomanagement: zij zijn gericht op het identificeren, beoordelen en beheersen van risico's in een van de vier dimensies van servicemanagement. Het is nuttig om risicomanagementinstrumenten en -technieken te gebruiken voor probleembeheer.

- De uitvoering van probleemoplossing valt vaak buiten het bestek van problem management. Problem management initieert meestal het oplossen van problemen via change enablement en neemt deel aan de post -implementatie review; echter, het goedkeuren en implementeren van veranderingen valt echter buiten het bereik van de problem management praktijk.

- Output van de problem management praktijk omvat informatie en documentatie over workarounds en bekende fouten. Daarnaast kan problem management gebruik maken van informatie in een kennismanagementsysteem om problemen te onderzoeken, te diagnosticeren en op te lossen.

- Problem management activiteiten kunnen verbetermogelijkheden identificeren in alle vier dimensies van service managem ent. Oplossingen kunnen in sommige gevallen worden behandeld als verbetermogelijkheden, dus worden ze opgenomen in een continu verbeteringsregister (CIR), en continu verbeteringstechnieken worden gebruikt om ze te prioriteren en te beheren, soms als onderdeel van een product backlog.

Veel probleembeheeractiviteiten berusten op de kennis en ervaring van het personeel, veeleer dan op het volgen van gedetailleerde procedures. Mensen die verantwoordelijk zijn voor het diagnosticeren van problemen moeten vaak het vermogen hebben om complexe systemen te begrijpen en na te denken over hoe verschillende storingen kunnen zijn ontstaan. Het ontwikkelen van deze combinatie van analytisch en creatief vermogen vereist mentorschap en tijd, alsmede passende opleiding.

12.1 Wat is Problem management?

Problem management (Probleembeheer) is het geheel van processen en activiteiten dat verantwoordelijk is voor het beheer van de levenscyclus van alle problemen die zich kunnen voordoen in een IT-service. Het belangrijkste doel is om problemen en de daaruit voortvloeiende incidenten te voorkomen. Voor incidenten die al hebben plaatsgevonden, probeert Problem management te voorkomen dat deze zich opnieuw voordoen of, als ze onvermijdelijk zijn, de impact op het bedrijf te minimaliseren. Om Problem management te begrijpen, is het nuttig om eerst te definiëren wat een probleem is. ITIL definieert een probleem als de oorzaak van een of meer incidenten. Een andere manier om ernaar te kijken is: een probleem is een onderliggende aandoening die negatieve gevolgen kan hebben voor de dienst en daarom moet worden aangepakt. Problemen hebben een levenscyclus die begint wanneer het probleem wordt gecreëerd (vaak door een verandering in de omgeving). Het omvat identificatie en de stadia van diagnose en herstel, en eindigt wanneer het probleem wordt opgelost door ofwel een actie te ondernemen of wanneer de onderliggende situatie verdwijnt.

Problem management is zowel een transactieproces voor het beheer van de levenscyclus van een individueel probleem als een portfoliobeheerproces om beslissingen te nemen over welke problemen moeten worden aangepakt, de middelen die ervoor worden ingezet en de risico’s voor de organisatie die problemen opleveren. Problem management omvat activiteiten die nodig zijn om de hoofdoorzaak van incidenten te diagnosticeren en de juiste oplossingsstappen te bepalen die moeten worden genomen. Het is ook verantwoordelijk voor de veilige en effectieve implementatie van alle oplossingen, in overeenstemming met het beleid en de procedures voor wijzigingsbeheer en release management.

Het portfoliogedeelte van Problem management is verantwoordelijk voor het bijhouden van informatie over problemen die bestaan in de omgeving, eventuele tijdelijke oplossingen die zijn ontwikkeld en de geïdentificeerde oplossingsopties. Deze informatie stelt leiders in staat beslissingen te nemen die het aantal incidenten en de impact van incidenten verminderen.

12.2 De Rol van een Problem Manager

Problem managers zijn verantwoordelijk voor het beheer van de levenscyclus van problemen om ervoor te zorgen dat ze goed worden begrepen en dat er passende maatregelen worden genomen. Zijn/haar doel is het voorkomen van incidenten en het minimaliseren van de impact van incidenten die niet kunnen worden voorkomen. Problem managers zullen vaak communiceren met de afdeling incidentbeheer en de aanwezige technici om ervoor te zorgen dat diagnostische gegevens worden vastgelegd over gerelateerde incidenten en om gevingsomstandigheden die verband houden met het probleem. Problem managers zijn verantwoordelijk voor het uitvoeren van root cause analyse (RCA) om de organisatie te helpen bij het achterhalen waarom een incident heeft

plaatsgevonden en hoe het onderliggende probleem in de omgeving is geïntroduceerd. Analyse van de hoofdoorzaak resulteert vaak in het identificeren van een aantal alternatieve oplossingen. De problem manager speelt een sleutelrol bij het beoordelen van de alternatieven met betrekking tot kosten, baten en risico's om een aanbeveling te doen aan de besluitvormers van het management. Het is gebruikelijk dat oplossingen enige tijd nodig hebben om te worden gekanaliseerd via de juiste wijzigings- en releasebeheerprocessen. Gedurende deze tijd zijn problem managers ervoor verantwoordelijk dat bronnen voor kennisbeheer en databases met bekende fouten up-to-date worden gehouden, zodat de afdeling incidentbeheer effectief kan reageren op terugkerende incidenten en/of serviceaanvragen. Hoewel incident m anagement en problem management afzonderlijke processen zijn, zullen problem managers doorgaans dezelfde tools, vergelijkbare categorisatie, impact en prioriteitscoderingssystemen gebruiken als de incident managers, om zo een effectieve samenwerking tussen procesgebieden te bevorderen.

12.3 Proactief Problem Management

Problem Management bestaat uit twee hoofdprocessen:

• Reactief problem management - wordt uitgevoerd als onderdeel van servicewerkzaamheden en richt zich op de opvolging van incidenten die al hebben plaatsgevonden

• Proactief problem management - wordt geïnitieerd tijdens servicewerkzaamheden, maar wordt over het algemeen beschouwd als onderdeel van continue serviceverbetering en is gericht op het identificeren van problemen via omgevingssignalen en het voorkomen van incidenten.

Proactief problem management is gericht op het identificeren van toekomstige incidenten en het voorkomen dat deze zich opnieuw voordoen, door de hoofdoorzaak te identificeren en te elimineren voordat het incidenten kan veroorzaken die een impact hebben op de dienstverlening. Proactieve probleemanalyse wordt sterk beïnvloed door gegevens die zijn gegenereerd door geautomatiseerde monitoringmogelijkheden, analyse van wijzigingsrecords en het gebruik van trendanalyse. Proactief problem management verschilt van zijn reactieve tegenhanger door zich op drie belangrijke gebieden te richten

• Proactieve detectie – wordt uitgevoerd als onderdeel van servicewerkzaamheden en richt zich op de opvolging van incidenten die al hebben plaatsgevonden

• Probleempreventie wordt geïnitieerd tijdens servicewerkzaamheden, maar wordt over het algemeen beschouwd als onderdeel van continue serviceverbetering en is gericht op het identificeren van problemen via omgevingssignalen en het voorkomen van incidenten

• Preventieve actie - wordt uitgevoerd als onderdeel van servicewerkzaamheden en richt zich op de opvolging van incidenten die al hebben plaatsgevonden

• Foutdiagnose -wordt geïnitieerd tijdens servicewerkzaamheden, maar wordt over het algemeen beschouwd als onderdeel van continue serviceverbetering en is gericht op het identificeren van problemen via omgevingssignalen en het voorkomen van incidenten.

12.4 Tijdelijke Oplossingen

Problem management kan een tijdrovend proces zijn en terwijl het gaande is, moet de IT -organisatie nog steeds diensten verlenen aan gebruikers. Een van de meest gebruikelijke tools/technieken die servicemanagementpersoneel gebruikt om dit te doen zijn tijdelijke oplossingen. Tijdelijke oplossingen zijn gericht op het verminderen of elimineren van de impact van bekende problemen en problemen waarvoor nog geen volledige oplossing beschikbaar is. Dit kan zijn omdat onderliggende oorzaken niet gemakkelijk kunnen worden geïdentificeerd, er geen oplossingsstappen zijn ontwikkeld of de organisatie nog geen permanente oplossingen heeft geïmplementeerd.

Tijdelijke oplossingen corrigeren de hoofdoorzaak van een probleem niet, maar pakken alleen de symptomen en effecten aan. Bekende voorbeelden van tijdelijke oplossingen zijn het opnieuw opstarten van servers, het wissen van applicatiecaches of het gebruik van een alternatief proces of systeem om de bedrijfsactiviteit te voltooien. Tijdelijke oplossingen kunnen worden uitgevoerd door de afdeling incidentbeheer of door eindgebruikers en ze kunnen voor el k tijdsbestek (van seconden tot jaren) worden gebruikt.

De meeste organisaties documenteren tijdelijke oplossingen als onderdeel van hun kennisbeheersysteem en linken naar records in de database met bekende fouten. Deze records kunnen aan gebruikers worden gepresenteerd in de vorm van veelgestelde vragen of ze kunnen alleen zichtbaar zijn voor servicemanagementpersoneel in de vorm van diagnostische instructies. Het is belangrijk om te onthouden dat tijdelijke oplossingen dezelfde levenscyclus volgen als het onderliggende probleem en dat daarom, als het probleem is opgelost, de tijdelijke oplossing moet worden beëindigd om verwarring te voorkomen.

12.5 Problem management ITIL Processen

ITIL definieert problem management (ITIL proces probleembeheer) als een onderde el van serviceproductie met sterke relaties tot incidentbeheer, wijzigingsbeheer en continue serviceverbetering. ITIL v3 splitst probleembeheer op in de volgende subprocessen:

• Proactieve probleemidentificatie – verbeter de algehele beschikbaarheid van diensten door problemen proactief te identificeren zodat ze opgelost kunnen worden, of zodat tijdelijke oplossingen gevonden kunnen worden voordat toekomstige incidenten plaatsvinden.

• Probleemdiagnose en oplossing – identificeer de onderliggende hoofdoorzaak van een probleem en initieer de meest toepasselijke oplossing.

• Probleem en foutcontrole - verbeter de algehele beschikbaarheid van diensten door problemen proactief te identificeren zodat ze opgelost kunnen worden, of zodat tijdelijke oplossingen gevonden kunnen worden voordat toekomstige incidenten plaatsvinden.

• Probleemafsluiting en beoordeling –zorg dat er na het afsluiten van een ITIL -problem een volledige historische omschrijving bestaat en dat de gegevens over bestaande fouten en kennisbeheer bijgewerkt zijn.

• Beoordeling van grote problemen – beoordeel de oplossing van een groot probleem om er zeker van te zijn dat probleemsituaties volledig geëlimineerd zijn, de geleerder lessen vast te leggen en preventieve acties te identificeren (zoals proceswijzigingen) die genomen moeten worden om te voorkomen dat het probleem terugkeert.

• Problem management ITIL rapportage – informeer andere servicemanagementprocessen en IT-management over lopende problemen, de status en bestaande tijdelijke oplossingen van ITIL-problems.

12.6 Incident management vs. problem management

Het verschil tussen incident management en probleembeheer is een van de grootste oorzaken van verwarring binnen ITIL- en servicemanagementprocessen. Hoewel deze processen zeer nauw met elkaar verbonden zijn, zijn ze opzettelijk verschillend en gescheiden. Incident management heeft de taak om te reageren op een gebeurtenis die zich heeft voorgedaan, waardoor de impact op het bedrijf wordt geminimaliseerd en de dienst zo snel mogelijk wordt herst eld. Problem Management is belast met het begrijpen van de hoofdoorzaak van waarom de gebeurtenis plaatsvond en hoe deze in de toekomst kan worden voorkomen.

We hebben de processen die betrokken zijn bij problem management al besproken. De belangrijkste activiteiten van incident management zijn:

• Identificatie van incidenten

• Vastleggen van incidenten

• Categoriseren van incidenten

• Prioriteren van incidenten

• Initiële diagnose

• Escalatie waar nodig

• Oplossing van incidenten

• Afsluiting van incidenten

• Communicatie met de gebruikers gedurende de levenscyclus van het incident

Het kan zijn dat er meerdere incidenten nodig zijn voordat problem management voldoende gegevens heeft om te analyseren wat er fout gaat en te bepalen welke stappen benodigd zijn om de situatie te corrigeren. Communicatie en coördinatie tussen incidentbeheerders en probleembeheerders is daarom essentieel. Problem management vormt een cruciaal onderdeel van

uw IT-servicemanagementfunctie. Het gebruikt de kennis die verkregen is via monitoring, incidentbeheer en andere onderdelen van de servicewerkzaamheden ter verbetering van de processen voor continue serviceverbetering. Hierdoor worden de diensten die u aan gebruikers verleent robuuster en betrouwbaarder.

12.7 Known error database (KEDB)

Een van de tools in een Problem Management systeem is het gebruik van een known error database. Als er ergens iets misgaat dat kunnen helpdeskmedewerkers snel opzoeken of het gaat om bekend probleem (known error) met een al uitgezochte methode en beproefde route naar ee n oplossing. Gaat het om een losstaand incident dan wordt dit ook vastgelegd. Als er zich een serie incidenten voordoet kan er sprake zijn van een probleem.

Goede Problem Management software maakt problemen inzichtelijk en helpt door het automatisch bijwerken van de database om suggesties te doen voor bekende problemen die mogelijk de onderliggende oorzaak zijn van incidenten die worden gerapporteerd.

13 Identity and access management (IAM)

13.1

Wat is Identiteit & Toegangsbeheer (IAM) ?

Identity & Access Management is in feite het beheren van gebruikersidentiteiten (zoals e -mail ID's) en hun niveau van toegang tot applicaties of gegevens binnen uw bedrijf. Een IAM (of IDam) is een manier om de gegevens van uw bedrijf te beschermen tegen zowel interne als exter ne bronnen. Zie IAM als een lidmaatschapskaart van een luchtvaartmaatschappij. Alleen omdat u een vliegticket hebt gekocht, geniet u niet van privileges zoals toegang tot lounges en bedden. Die zijn uitsluitend voorbehouden voor leden van een luchtvaartclub. Op een vergelijkbare manier krijgen niet alle werknemers binnen een bedrijf toegang tot alle gegevens die het bedrijf heeft. Het hebben van een IAM beleid biedt een elegante oplossing voor het probleem van gegevensbeveiliging binnen het bedrijf.

Welke problemen helpt IAM voorkomen?

• Het identificeren van gebruikers met een unieke identificatiecode zoals gedefinieerd door uw bedrijfsbeleid

• Helpt de toegang tot de middelen van uw bedrijf te beveiligen

• Vermindert de kosten voor identiteitsbeheer

• Biedt het IT-team een manier om gebruikersactiviteiten op te sporen en te controleren en de veiligheid van gegevens te garanderen

• Helpt de naleving van de nieuwste beveiligingsstandaarden en het bedrijfsbeleid te garanderen

Wat zijn de bouwstenen van IAM?

• Een manier om gebruikersgegevens op te slaan (personeelsdossiers, bijvoorbeeld)

• Het IT-team in staat stellen om veilig toegang te krijgen tot de gegevens & het gedrag van gebruikers te monitoren.

• Mogelijkheid om de gegevens aan te passen (wanneer een werknemer bij een bedrijf komt werken of het verlaat, bijvoorbeeld)

• Een effectieve manier om rapporten & analyses op te stellen over een voldoende lange periode.

13.2 Hoe IAM implementeren in een bedrijf?

1. Onderzoek uw huidige IAM implementatie

Een audit van uw bestaande databeveiligingsbeleid en de implementatie daarvan zou een idee moeten geven van wat de juiste oplossing is die nodig is voor uw bedrijf. Een goede eerste stap is het inventariseren van de bestaande inventaris van uw IT-middelen (zowel on-premise als cloudgebaseerde applicaties). Uw account moet ook de applicaties weergeven die onder "Shadow IT" vallen, d.w.z. de applicaties die kunnen worden geïnstalleerd zonder enige beheerderscontrole

Bekijk ook uw huidige beleid voor het vaststellen van gebruikerstoegang tijdens onboarding- of offboardingprocessen. Dit gedetailleerde overzicht zou u moeten helpen bij het identificeren van de zwakke plekken in uw IT-pantser.

2. Stel doelen & verwachtingen voor uw nieuwe IAM-beleid

Voordat u begint met de implementatie van uw IAM-strategie, moet u begrijpen welke impact het zal hebben op het werk dat u momenteel doet. Het zou een goed idee zijn om uw verwachtingen voor een nieuwe implementatie vast te stellen. U kunt bijvoorbeeld kijken naar hoe uw beveiliging en andere bedrijfsbeleidsregels moeten veranderen op basis van uw plan. Dit kan een idee geven van de taak die voor ons ligt en ook van het werk dat erin moet worden gestoken. Houd ook rekening met de kosten-batenfactor. Uw implementatie mag niet te ingewikkeld en duur zijn, zodat uw hele exercitie zinloos wordt.

3. Bereid een IAM implementatiestrategie voor

De volgende logische stap is het opstellen van een stappenplan voor uw implementatiepla n. Dit stappenplan moet worden bepaald met alle belangrijke stakeholders in het proces. Beoordeel uw vereisten en ga ook na of er afhankelijkheden zijn. In dit stadium zou het ook goed zijn om uw succes metrics te definiëren en een tijdlijn op het implemen tatieproces te zetten. Een ander belangrijk onderdeel van uw strategie zou moeten zijn om de juiste IAM -leveranciers en hun best practices te beoordelen. Zorg er ten slotte voor dat uw IAM-plan in strikte overeenstemming is met uw beveiligingsstandaarden en andere industriebenchmarks die normaal door uw bedrijf worden gevolgd.

4.

Meet uw vooruitgang

Zodra het juiste IAM-raamwerk is ingevoerd, evalueert u periodiek uw metrics om ervoor te zorgen dat ze voldoen aan de doelen die in de vorige stap zijn gestel d. Een grondige maandelijkse of driemaandelijkse audit is een efficiënte manier om uw implementatie te beoordelen. Dit geeft u de kans om eventuele fouten te corrigeren en de aanbevolen IAM best practices te implementeren. Een goede manier om het succes van uw IAM-plan te verzekeren is om de adoptie binnen het bedrijf te stimuleren. Dit kan bijvoorbeeld door interne webinars te plannen waarin wordt uitgelegd hoe het proces werkt of door regelmatig e-mails te sturen naar al uw medewerkers als een frequente herinnering.

13.3

Welke IAM technologieën en tools moet u kennen?

In de afgelopen tien jaar hebben IAM-technologieën een fenomenale groei doorgemaakt. Zowel wat betreft hun mogelijkheden als hun adoptie. Wanneer u een oplossing probeert te vinden voor gebruikersidentificatie en gegevensbeheer, is het belangrijk dat u de juiste tools kiest voor uw IAM-plan. Dit helpt om de overheadkosten (zoals onderhoud, enz.) te verminderen en tegelijkertijd mogelijk fouten bij uw implementatie te minimaliseren. Hoewel uw IAM -tool robuust en rijk aan functies moet zijn, moet het ook tot op zekere hoogte aanpasbaar zijn omdat elke organisatie zijn eigen eigenaardigheden heeft. In deze sectie bespreken we enkele van de beschikbare technologieën in de IAM industrie van vandaag. Hoewel we geen namen noemen van tools, zou dit u een idee moeten geven van wat u mag verwachten van uw IAM-leverancier.

Single Sign-on (SSO)

SSO is misschien wel de makkelijkste vorm van IAM implementatie voor uw organisatie. Het vereist dat de gebruiker alleen de gebruikersnaam en het wachtwoord voor een bepaalde applicatie onthoudt. SSO integreert de gebruikersgegevens automatisch met al uw andere verbonden applicaties. Wanneer een gebruiker zich aanmeldt bij een van uw applicaties, hoeft hij het authenticatieproces dus niet te herhalen wanneer hij zich aanmeldt bij een andere interne applicatie die met SSO is gekoppeld. Zelfs vanuit het perspectief van de eindgebruiker is dit een efficiënte manier om toegangsbeheer te garanderen.

Meerfactorauthenticatie (MFA)

Hoewel SSO een elegante oplossing is voor het IAM-probleem, zijn bedrijven altijd op zoek naar betere beveiligingsimplementaties. Dit is waar MFA om de hoek komt kijken. Dit kan uw SSOmogelijkheden aanvullen en uw IAM-spel naar een hoger niveau tillen. Binnen MFA evolueren organisaties gestaag van 2-factor naar 3-factor authenticatiemethodes. 3FA is gebaseerd op drie parameters die, wanneer ze worden gecombineerd, een specifieke gebruiker uniek kunnen identificeren. Het gaat om iets dat een gebruiker kent (zoals een wachtwoord), iets dat de gebruiker heeft (een smartphone) en iets dat uniek is voor de gebruiker (zoals een vingerafdruk). Alle drie gecombineerd vormen ze een robuuste methode voor het beveiligen van gebruikersidentificatie en toegangsbeheer.

Cloudgebaseerde integratie

Naarmate bedrijven overstappen van on-premise applicaties naar cloud-gebaseerde, moeten hun IAM-plannen dat ook doen. Vanwege de steeds meer op afstand werkende werknemers, is dit veel logischer, omdat het niet alleen de kosten van implementatie vermindert, maar ook helpt bij het dekken van een brede spreiding van uw werknemersnetwerk. Geavanceerde IAM-oplossingen in de cloud kunnen helpen bij het detecteren van elke vorm van hack op uw apparaten en fungeren als een killswitch door de hacker onmiddellijk buiten te sluiten.

Een opmerking over de risico's van IAM-implementatie

Hoewel IAM-tools en -technologieën enorm nuttig zijn bij het veilig afdekken van uw gegevens, zijn ze niet zonder risico's. Wanneer u een IAM-plan implementeert, vertrouwt u in wezen op een derde partij om de gebruikerstoegang tot uw applicaties te beveiligen en ook om uw bed rijfsgegevens te beheren. Als die derde partij gehackt wordt, zijn al uw inspanningen dan voor niets geweest? Niet als u de juiste voorzorgsmaatregelen neemt. Bepaal in de planningsfase het type gegevens dat u onder IAM wilt laten vallen en maak daar back-ups van. Ook het uitvoeren van frequente audits, zoals hierboven vermeld, helpt bij het identificeren van inactieve gebruikersaccounts in uw database. Als u weet hoe uw IAM-leverancier uw gegevens beveiligt en opslaat (welke encrypties ze gebruiken, hoe geanonimiseerd uw gegevens zijn, etc.) kan dat helpen om u gerust te stellen.

13.4 Toegangsbeheer

13.4.1

Inleiding

Toegangsbeheer (`access management') verleent geautoriseerde gebruikers het recht om een service te gebruiken, maar ontzegt niet -geautoriseerde gebruikers de toegang. Sommige organisaties noemen het ook wel 'rechtenmanagement' of `identiteitsmanagement'.

Toegangsbeheer kan via een aantal mechanismen worden geïnitieerd, bijvoorbeeld door een service request via de servicedesk.

13.4.2

Basisbegrippen

Toegangsbeheer kent de volgende basisconcepten:

• Toegang - verwijst naar het niveau en de omvang van de functionaliteit van een service of gegevens die een gebruiker mag gebruiken.

• Identiteit - verwijst naar de informatie over diegenen die een organisatie als individuen onderscheidt. Het stelt hun status binnen de organisatie vast.

• Rechten (ook wel privileges genoemd) - verwijst naar de feitelijke instellingen voor een gebruiker; van welke service(groep) mag hij gebruikmaken? Typische rechten zijn bijvoorbeeld lezen, schrijven, uitvoeren, wijzigen en verwijderen.

• Services of servicegroepen - De meeste gebruikers maken gebruik van meerdere services. Het is daarom effectiever om iedere gebruiker of groep gebruikers toegang te geven tot een hele reeks services die ze op hetzelfde moment mogen gebruiken.

• Directory services - verwijst naar een specifiek type tool dat wordt gebruikt om toegang en rechten te beheren.

13.4.3

Activiteiten

Toegangsbeheer (figuur) bestaat uit de volgende activiteiten:

• Toegang vragen - Toegang (of beperking van toegang) kan aangevraagd worden via een aantal mechanismen, zoals een standaard verzoek door de afdeling human resources; een RFC, een RFC ingediend via het request fulfilment-proces, of de uitvoering van een geautoriseerd script.

• Verifiëren - Toegangsbeheer moet ieder verzoek voor toegang tot een IT -service vanuit twee perspectieven verifiëren:

o Is de gebruiker die om toegang vraagt inderdaad de persoon die hij zegt dat hij is?

o Heeft de gebruiker een legitieme reden om de service te gebruiken?

• Rechten geven - Toegangsbeheer beslist niet wie toegang heeft tot welke IT -services, maar voert slechts het beleid en de regels uit die servicestrategie en service -ontwerp hebben gedefinieerd.

• Monitoren van de identiteitstatus - Rollen van gebruikers kunnen door de tijd heen veranderen, en daarmee hun behoefte aan services. Voorbeelden waardoor een rol kan wijzigen zijn verandering van baan, promotie, ontslag, pensioen of overlijden.

• Toegang registreren en volgen - Toegangsbeheer moet niet alleen reageren op verzoeken. Het moet er ook voor zorgen dat de rechten die het heeft verleend ook goed worden gebruikt. Daarom moet toegangsbewaking en -beheersing worden opgenomen in de monitoringactiviteiten van alle technische en applicatiebeheerfuncties en alle serviceproductieprocessen.

• Rechten verwijderen of beperken - Behalve dat toegangs-beheer rechten verleent om een service te gebruiken, heeft het ook de bevoegdheid die rechten weer in te trekken. Dit is echter niet een beslissing die het zelf mag nemen.

14 Event management

14.1 Inleiding

Een event wordt gedefinieerd als "een toestandswijziging met betekenis voor een IT -service of een ander CI". De term wordt ook gebruikt om een alert of een melding aan te duiden die wordt voortgebracht door een IT-service, CI of beheertool. Events vereisen dat IT-beheerders actie ondernemen, en leiden vaak tot het registreren van incidenten.

Eventmanagement is het proces dat alle events bewaakt die plaatsvinden in de IT -infrastructuur om de normale uitvoering mogelijk te maken en die ook bijzondere omstandigheden opspoort en escaleert. Eventmanagement kan geautomatiseerd worden onvoorziene omstandigheden op te sporen en te escaleren.

14.2 Basisbegrippen

Events kunnen geclassificeerd worden als:

• events die een normale handeling aangeven - zoals een gebruiker die heeft ingelogd om een applicatie te gebruiken

• events die een ongebruikelijke handeling aangeven - zoals een gebruiker die probeert in te loggen op een applicatie met een onjuist wachtwoord, of een PC-scan die onthult dat er nietgeautoriseerde software is geïnstalleerd

• events die een ongebruikelijke maar niet uitzonderlijke bewerking signaleren - bijvoorbeeld een aanwijzing dat een situatie wat meer toezicht vereist, zoals de melding dat het gebruik van geheugencapaciteit van een server binnen vijf procent van het hoogst mogelijke niveau komt dat nog acceptabel is.

Eventmanagement kan worden toegepast op ieder aspect van servicemanagement dat moet worden beheerd en dat geautomatiseerd kan worden.

14.3 Activiteiten

De belangrijkste activiteiten van het eventmanagementproces zijn:

1. Er doet zich een event voor - Events vinden voortdurend plaats, maar ze worden niet allemaal gedetecteerd of geregistreerd. Het is daarom belangrijk dat iedereen begrijpt wat voor soorten events er gedetecteerd moeten worden.

2. Eventnotificatie - De meeste CI's zijn zo ontworpen dat ze bepaalde informatie over zichzelf communiceren op een van de volgende manieren:

a. Een managementtool ondervraagt een apparaat en verzamelt bepaalde gegevens. Dit staat ook wel bekend als 'polling'.

b. De CI genereert een rapportage als aan bepaalde voorwaarden is voldaan.

3. Eventdetectie - Een managementtool of een agent ontdekt een eventrapportage en leest en interpreteert deze.

4. Eventlogging - Een event en de daaropvolgende acties worden gelogd als een event-record in de eventmanagementtool, of er wordt alleen een entry in de systeemlog bewaard van het apparaat of de applicatie die het event genereerde.

5. Eerste-niveau eventcorrelatie en -filtering - Eventfiltering beslist of een event al of niet opgenomen wordt in een managementtool. Als dat niet het geval is wordt het event gewoonlijk vastgelegd in een logbestand van het apparaat, zonder dat actie wordt ondernomen. Dit wordt normaliter uitgevoerd door een geautomatiseerde `agent'.

6. De significantie van events - Het event wordt gecategoriseerd naar significantie, door bijvoorbeeld gebruik te maken van de indeling in informatief, waarschuwing, en uitzondering (exception).

7. Tweede-niveau eventcorrelatie - De betekenis van het event wordt bepaald, veelal gebaseerd op een set businessregels waarmee de business -impact wordt bepaald.

8. Reactie vereist? - Als het event wordt herkend, is er een reactie nodig. Het mechanisme dat die reactie in gang zet, wordt een trigger genoemd.

9. Reactieselectie - Het proces biedt een aantal reactiemogelijkheden, waaronder automatische reactie, alert en menselijk ingrijpen, een RFC indienen, een incident aanmaken, openen of koppelen van problemrecord.

10. Beoordeling van acties - Controleer alle belangrijke events of uitzonderingen om te zien of ze op de juiste manier zijn behandeld, en of eventtypes worden geteld.

11. Event afsluiten - Sluit het event. Sommige events blijven geopend totdat bepaalde acties zijn ondernomen.

Het schema in de figuur geeft de flow van eventmanagement weer.

Ieder type event kan eventmanagement in gang zetten. Triggers bestaan onder meer uit:

• uitzonderingen op ieder niveau van de CI-performance die is vastgesteld in de ontwerpspecificaties, OLA's of standaardverwerkingsprocedures

• een uitzondering in een businessproces dat door eventmanagement wordt bewaakt

• een statuswijziging in een apparaat of databaserecord.

15 Change enablement

Het doel van de change enablement praktijk is het maximaliseren van het aantal succesvolle serviceen productwijzigingen door ervoor te zorgen dat risico's juist zijn beoordeeld, het autoriseren van wijzigingen voor door te voeren, en het wijzigingsschema te beheren.

De reikwijdte van change enablement wordt door elke organis atie bepaald. Het zal typisch alle IT infrastructuur, applicaties, documentatie, processen, relaties met leveranciers, en al het andere dat direct of indirect van invloed kan zijn op een product of dienst.

Het is belangrijk om een onderscheid te maken tussen change enablement en organisatorisch change management. Organisatorisch veranderingsmanagement beheert de menselijke aspecten van veranderingen om ervoor te zorgen dat verbeteringen en organisatorische transformatie -initiatieven met succes worden geïmplementeerd. Change enablement is gewoonlijk gericht op veranderingen in producten en diensten.

Change enablement moet een evenwicht vinden tussen de noodzaak om gunstige veranderingen aan te brengen die extra waarde zullen leveren met de noodzaak om klanten en gebruikers te beschermen tegen de nadelige gevolgen van veranderingen. Alle veranderingen moeten worden beoordeeld door mensen die in staat zijn de risico's en de verwachte voordelen te begrijpen. De wijzigingen moeten vervolgens worden geautoriseerd voordat zij worden ingevoerd. Deze beoordeling mag echter niet onnodige vertraging veroorzaken.

Definitie Verandering

De toevoeging, wijziging of verwijdering van iets dat een direct of indirect effect kan hebben op diensten.

Wijzigingsautoriteit

De persoon of groep die een wijziging goedkeurt, staat bekend als een wijzigingsautoriteit. Het is essentieel dat de juiste change authority wordt toegewezen aan elk type change om ervoor te zorgen dat change enablement zowel efficiënt en effectief is. In organisaties met een hoge snelheid is het gebruikelijk om de goedkeuring te decentraliseren, waardoor de collegiale toetsing (peer review) een topvoorspeller wordt van hoge prestaties.

Wijzigingsschema

Het wijzigingsschema wordt gebruikt om wijzigingen te plannen, te helpen bij de communicatie, conflicten te vermijden, en middelen toe te wijzen. Het kan ook worden gebruikt nadat wijzigingen zijn doorgevoerd om informatie te verschaffen die nodig is voor incident management, problem management, en verbeteringsplanning. Ongeacht wie de wijzigingsautoriteit is, kan het nodig zijn dat deze breed in de organisatie communiceert. Risicobeoordeling, bijvoorbeeld, kan het nodig zijn dat zij input verzamelen van veel mensen met specialistische kennis. Bovendien is het meestal nodig om informatie over de verandering te communiceren om ervoor te zorgen dat mensen volledig voorbereid zijn voordat de verandering wordt doorgevoerd.

Er zijn drie soorten wijzigingen die elk op een andere manier worden beheerd:

- Standaard wijzigingen Dit zijn vooraf geautoriseerde wijzigingen met een laag risico die goed worden begrepen en volledig gedocumenteerd, en kunnen worden geïmplementeerd zonder dat aanvullende autorisatie nodig is. Ze worden vaak geïnitieerd als service requests, maar kunnen ook operationele wijzigingen zijn. Wanneer de procedure voor een standaardwijziging wordt gecreëerd of gewijzigd, moet er een volledige risicobeoordeling en autorisatie plaatsvinden zoals voor elke andere wijziging. Deze risicobeoordeling hoeft niet te worden herhaald elke keer dat de standaardwijziging wordt uitgevoerd; dat hoeft alleen te gebeuren als er een wijziging in de manier waarop deze wordt uitgevoerd.

- Normale wijzigingen Dit zijn wijzigingen die moeten worden gepland, beoordeeld en geautoriseerd volgens een proces. Wijzigingsmodellen op basis van het type wijziging bepalen de rollen voor beoordeling en autorisatie. Sommige normale wijzigingen hebben een laag risico, en de wijzigingsautoriteit voor deze wijzigingen is meestal iemand die snel beslissingen kan nemen, vaak met behulp van automatisering om de verandering te versnellen. Andere normale wijzigingen zijn zeer ingrijpend en de wijzigingsautoriteit kan zo hoog zijn als tot de raad van bestuur (of gelijkwaardig). Het initiëren van een normale wijziging wordt in gang gezet door het aanmaken van een wijzigingsverzoek. Dit kan handmatig worden aangemaakt, maar organisaties die beschikken over een geautomatiseerde pijplijn voor continue integratie en continue implementatie, automatiseren vaak de meeste stappen van het change enablement proces.

- Noodwijzigingen Dit zijn wijzigingen die zo snel mogelijk moeten worden doorgevoerd; bijvoorbeeld om een incident op te lossen of een beveiligingspatch te implementeren. Noodwijzigingen worden meestal niet opgenomen in een wijzigingsschema, en het proces voor beoordeling en autorisatie wordt versneld om ervoor te zorgen dat ze snel kunnen worden uitgevoerd. Voor zover mogelijk moeten wijzigingen in noodgevallen aan dezelfde tests, beoordeling en autorisatie worden onderworpen als normale wijzigingen, maar het kan aanvaardbaar zijn om bepaalde documentatie uit te stellen tot na de wijziging is uitgevoerd, en soms zal het nodig zijn de wijziging met minder tests uit te voeren als gevolg van tijdsdruk. Er kan ook een afzonderlijke wijzigingsbevoegdheid zijn voor noodwijzigingen, meestal bestaande uit een klein aantal senior managers die inzicht hebben in de betrokken bedrijfsrisico's.

15.1 ITIL Change Management

Innovaties in IT en technologie leiden tot nieuwe wijzigingen binnen de organisatie. Om te blijven concurreren is het voor bedrijven cruciaal dat ze zich sneller aanpassen aan de veranderende trends. Het is echter belangrijk om de huidige werkstaat niet te onderbreken terwijl deze wijzigingen geïmplementeerd worden. ITIL Change management (of wijzigingsbeheer) helpt bedrijven bij het implementeren van nieuwe changes (wijzigingen) zonder onderbreking of downtime. ITIL change management volgt een standaard werkprocedure om alle onbedoelde onderbrekingen te v oorkomen en omvat onder meer wijzigingsbeoordeling, planning en goedkeuring. Het change management proces is de poortwachter die zorgt voor minimale risico’s en impact op de bestaande infrastructuur en werkzaamheden. Change management omvat pre-release activiteiten zoals uitrol, backout-planning en het inplannen van wijzigingen. Het voert kwaliteitscontrole uit om te waarborgen dat de wijzigings- en release-activiteiten zoals gepland zijn.

Doelen

Het primaire doel van ITIL Change management is het verminde ren van risico en impact. Change management draagt zorg voor de autorisatie om elke wijziging goed te keuren voor de implementatie. Het beschermt de productieomgeving tijdens het uitvoeren van een nieuwe wijziging. Het ITIL Change management proces heeft de volgende doelen.

• Vermindering van risico en impact

• Behoud van de huidige werkstaat

• Communicatie- en goedkeuringsbeheer

• Effectieve wijzigingsplanning met geoptimaliseerde middelen

• Vermindering van het aantal incidenten vanwege de uitvoer van de wijziging

Scenario’s waarin ITIL Change Management gebruikt wordt:

• Implementatie van een nieuw datacenter

• De oplossing voor een bug implementeren in de productieomgeving

• Windows patch

• Vervangen van een ERP-dienstverlener

• Upgraden van het besturingssysteem

15.2

Change Management Processtroom

Het ITIL Change management proces omvat verschillende stappen die elk detail vastleggen over een wijzigingsaanvraag zodat dit in de toekomst gevolgd kan worden. Deze processen zorgen ervoor dat de wijziging wordt gevalideerd en getest voordat deze wordt geïmplementeerd. Het Release management proces is verantwoordelijk voor succesvolle implementatie. De Change Manager (Wijzigingsbeheerder) zorgt voor planning en evaluatie, terwijl de Release Manager zorgt voor de daadwerkelijke implementatie van de wijziging. De processtroom voor wijzigingsbeheer ziet er ongeveer zo uit:

Request for Change

Request For Change (RFC of Wijzigingsaanvraag) wordt ingediend bij het change management team voor validatie en goedkeuring. Wijzigingsaanvragen komen voort uit een van de volgende bronnen.

• Een Incident dat een wijziging veroorzaakt

• Een bestaand probleem dat een wijziging veroorzaakt

• Een eindgebruiker die een nieuwe wijziging aanvraagt

• Een wijziging als resultaat van doorlopend onderhoud

Een RFC-sjabloon wordt gebruikt om de wijziging vast te leggen

• Reden voor wijziging - Rechtvaardigt waarom de wijziging nodig is, samen met de risico / batenanalyse.

• Impact- & Risicobeoordeling - Potentiële impact en risico’s worden berekend en gedocumenteerd, inclusief configuratie-items (CI’s).

• Kosten-batenanalyse - Geschatte kosten tegenover potentiële baten worden met elkaar vergeleken.

• Implementatieplanning - Stappen voor de implementatie van de wijziging, inclusief projectleden, tijdlijnen en methodologie.

Wijzigingsbeoordeling en Planning

Deze fase behandelt de beoordeling en planning van wijzigingsactiviteiten. Het omvat onder meer prioritering en geplande activiteiten om risico en impact te minimaliseren.

• Prioritering - Bepaal het type wijziging en prioriteer de aanvragen op basis daarvan.

• Planning - Controleer de Releaseplanning voor een schatting van het tijdsbestek en leg de geplande startdatum en einddatum vast

• Uitrolplan - Plan de implementatieactiviteiten

• Backoutplan - Backoutplan in het geval van onverwachte tegenslagen

Goedkeuringen van wijzigingen

Elk wijzigingsverzoek dat binnenkomt, moet worden goedgekeurd. Het Change management team verzorgt end-to-end communicatie en goedkeuringen van de Change Advisory Board (CAB).

Goedkeuring van wijzigingen is cruciaal om eventuele uitvoeringsfouten en downtime uit te sluiten. Het goedkeuringsproces varieert afhankelijk van het wijzigingstype. Voor een belangrijke wijziging zoals de vervanging van een ERP -oplossing is bijvoorbeeld goedkeuring van de CAB en management vereist, terwijl voor een standaardwijziging zoals patchimplementatie geen CAB -goedkeuring vereist is, omdat deze wijzigingen vooraf zijn goedgekeurd. Het wijzigingsverzoek wordt alleen goedgekeurd als alle CAB-leden het goedkeuren. Bij afwijzing wordt een herbeoordeling uitgevoerd en opnieuw ingediend voor CAB-goedkeuring.

Implementatie van wijzigingen

De implementatie van wijzigingen wordt afgehandeld door het Release management team en de Post Implementation Review (PIR) wordt verzorgd door het Change management team. Het Release management team volgt hun eigen processen omtrent planning en testen. De beoordeling van de wijziging vindt plaats zodra de implementatie is voltooid om te zorgen dat a lles volgens plan is verlopen. Het bestaande wijzigingsbeheerproces wordt voortdurend herzien en waar nodig bijgewerkt.

15.3

Integratie met andere ITIL-modules

Change management staat dicht bij andere ITIL -modules zoals incident management (incidentbeheer), problem management (probleembeheer), release management en CMBD om updates te delen. Deze associatie is essentieel om consistentie van de informatie te behouden.

Change Management & CMDB

Change management kan wijzigingen in configuratie-items (CI's) inhouden die deel uitmaken van de Configuration Management Database (CMDB). De CMDB beheert relaties op verschillende apparaten en het Change management proces begrijpt deze relaties en de impact voordat een nieuwe implementatie wordt uitgerold. Als een bepaalde activa meerdere afhankelijkheden of relaties met andere activa heeft, is de impact groot. Koppel de juiste CI's die mogelijk worden beïnvloed door de wijziging of die de wijziging hebben veroorzaakt en werk deze informatie bij binnen de CMDB.

Change & Release Management

Het hoofddoel van het wijzigingsbeheerproces is ervoor te zorgen dat de geplande wijziging onder controle is en releasebeheer zorgt voor de daadwerkelijke implementatie van geplande wijzigingen. Het is van cruciaal belang om de rollen en verantwoordelijkheden van change - en release management te onderscheiden om conflicten te voorkomen. Succesvolle change leidt tot nieuwe release en change management coördineert met release management voor de bouw -, test- en implementatieplannen.

Change & Incidentbeheer

Incidenten zijn direct gerelateerd aan een wijziging als de behoefte er is om nieuwe implementaties uit te rollen. Het IT-team ontdekt bijvoorbeeld dat de terugkerende WiFi-problemen te maken hebben met een routerprobleem. In dit geval vervangt het team de oude router met een nieuwe router via het ITIL change management proces. Als de onderliggende oorzaak onbekend is, wordt het incident gekoppeld aan een probleem om Root Cause Analysis (RCA) uit te voeren. Het doel van incidentbeheer is het zo snel mogelijk herstellen van services, terwijl change management een permanente oplossing probeert te vinden. Eindgebruikers melden een Incident dat omgezet kan worden tot wijziging en vervolgens behandeld wordt door het change management team.

15.4 Wat zijn de soorten wijzigingen die u kunt verwachten op een Servicedesk?

In grote lijnen kunnen veranderingen in een IT-team worden onderverdeeld in:

Grote wijzigingen

Wijzigingen met een hoog risico die bedrijfskritisch zijn. Dit zijn zaken die de hoogste prioriteit vergen en die financiële gevolgen kunnen hebben. Een bestaande ERP -oplossing kan bijvoorbeeld vreselijk falen in het leveren van de waarde die u verwacht en u moet mogelijk zo snel mogelijk een nieuwe tool kopen. Het aankoopproces van de software, het installeren en het zorgen dat uw eindgebruikers het accepteren en gebruiken is waar wijzigingsbeheer om de hoek komt kijken.

Standaardwijzigingen

Zoals de naam al doet vermoeden, zijn dit de vrij eenvoudige wijzigingen die een lage impact hebben, inclusief de vooraf goedgekeurde wijzigingen. Dit soort wijzigingen vereisen minimale tot geen betrokkenheid van de eindgebruiker. De reikwijdte van wijzigingsbeheer is in deze gevallen beperkt tot hoe snel en efficiënt het IT-team de wijzigingen kan implementeren. Het upgraden van het besturingssysteem en het implementeren van patches zijn goede voorbeelden van standaardwijzigingen.

Kleine wijzigingen

Dit zijn wijzigingen die niet direct van invloed zijn op de bedrijfsvoering en relatief eenvoudig uit te voeren zijn. Wijzigingen aan de website en het verbeteren van de prestaties van applicaties zijn enkele voorbeelden van kleine wijzigingen. Dit zijn wijzigingen die niet vaak voorkomen, maar die elke fase van de levenscyclus van wijzigingsbeheer doorlopen.

Spoedwijzigingen

Dit zijn wijzigingen die ad-hoc zijn en vereisen dat het IT-team wijzigingen op een dynamische manier implementeert. De goedkeuringen kunnen worden beheerd via het Emergency Change Management Board (ECAB). Het is echter belangrijk om deze wijzigingen te documenteren voor toekomstige referenties en context.

16 Release management

Het doel van de release management praktijk is om nieuwe en veranderde diensten en functies beschikbaar te maken voor gebruik.

16.1 Wat is Release Management?

Bij Release Management gaat het erom de systemen en diensten van een organisatie te laten veranderen om de veranderende zakelijke behoeften te ondersteunen. Het is het proces van het coördineren van de verplaatsing van projecten naar productieomgevingen waar ze kunnen worden geconsumeerd door eindgebruikers. Het belangrijkste doel van releasebeheer is ervoor te zorgen dat de integriteit van de live-omgeving wordt beschermd en dat de juiste componenten worden vrijgegeven. In sommige organisaties houdt releasebeheer zich alleen bezig met de technische implementatie van IT-producten en -functies, terwijl andere organisaties een breder perspectief hebben van releasebeheer, inclusief zaken als adoptie en wijzigingen in bedrijfsprocessen met betrekking tot een release.

16.1.1 Release Management in ITIL

Release- en implementatiebeheer is een van de hoofdprocessen in het gedeelte Servicetransitie van het IT Infrastructure Library (ITIL®) raamwerk. Dit proces wordt in het kort va ak aangeduid als simpelweg “release management”. ITIL definieert release - en implementatiebeheer als het proces van planning van de uitrol van IT-services, updates en releases naar de productieomgeving. Release verwijst in deze context naar de ontwikkeling van een nieuwere versie van een service of component en implementatie betekent het proces van integratie in de live productieomgeving.

Release management speelt een belangrijke rol bij het overbruggen van de kloof tussen projectactiviteiten en de dingen die projectteams produceren enerzijds, en de lopende werkzaamheden en gebruikers die deze zaken zullen consumeren anderzijds. Het komt veel voor dat organisaties meerdere projecten tegelijkertijd hebben lopen en release management biedt een gestructureerde aanpak om wijzigingen samen te brengen, te testen of ze correct werken en ze vervolgens veilig te introduceren in de live-omgevingen waar bedrijfsactiviteiten op vertrouwen. Release management zorgt er ook voor dat alle toepasselijke kennis en middelen wor den overgedragen van de teams die de nieuwe functies of componenten ontwikkelen naar het operationele team dat verantwoordelijk is voor de ondersteuning ervan.

16.2 Het Release Management proces

Het is belangrijk dat elk projectteam dat wijzigingen in de productieomgeving wil aanbrengen, op elkaar is afgestemd en op de hoogte is van elkaars wijzigingen en het gebruik van middelen. Ze moeten hetzelfde proces, beleid en richtlijnen volgen voor het plannen, bouwen, testen en implementeren van een release. ITIL verdeelt release management in zes subprocessen waarmee release management effectief, efficiënt en veilig kan worden uitgevoerd om de stroom van wijzigingen in de operationele omgeving te vergemakkelijken.

• Release management ondersteuning: biedt richtlijnen en ondersteuning voor de implementatie van releases, inclusief de rollen die betrokken zijn bij andere delen van het release- en implementatiebeheerproces

• Releaseplanning: definieert de reikwijdte en inhoud van releases volgens het releasebeheerbeleid, wijst geautoriseerde wijzigingen toe in releasepakketten en definieert een schema voor het bouwen, testen en implementeren van de release

• Releasebouw: houdt zich bezig met de daadwerkelijke ontwikkeling van alle vereiste releasecomponenten, inclusief de uitgifte van alle noodzakelijke werkorders en inkooporders voor componenten afkomstig van leveranciers en zorgt ervoor dat alle releasecomponenten klaar zijn voor validatie en testen

• Release uitrol: beheert de implementatie van releasecomponenten in de live productieomgeving en de overgang van documentatie en training naar eindgebruikers en operationeel personeel.

• Ondersteuning in de vroege fase na release: de eerste periode na de implementatie van een nieuwe release, wanneer het managementteam voor release en implementatie samenwerkt met het incidentbeheerteam om operationele problemen op te lossen en fouten en tekortkomingen die veroorzaakt zijn door de release te verwijderen.

• Release afsluiting: release-activiteiten formeel afsluiten, controleren of alle documenten en gegevens correct zijn bijgewerkt en release -resultaten en feedback rapporteren aan projectteams.

16.3 De Rol van een Release Manager

De release manager (of releasebeheerder) speelt een gecombineerde rol van coördinatie en bestuur/toezicht, met de taak ervoor te zorgen dat de release effectief en veilig wordt voltooid. Release managers zijn doorgaans IT-professionals met gespecialiseerde vaardigheden en ervaring die standaarden, processen en tools gebruiken om release-activiteiten te coördineren. In IT-context werken release managers samen met bedrijfsleiders, IT -projectteams en operationele medewerkers om te zorgen voor een goed gestructureerde release van technische functies in de IT -omgeving. In de context van product management werken release managers samen met bedrijfsontwikkeling, marketing, R&D en andere teams om binnen het hele bedrijf te coördineren ter ondersteuning van een geplande productrelease.

Bij grote releases kunnen meerdere medewerkers als releaseteam sa menwerken. Als dit het geval is, biedt de release manager een overkoepelende management- en leiderschapsfunctie, die zowel het releaseteam als de release zelf coördineert. De release manager is verantwoordelijk voor governance en kwaliteitstoezicht op de release, bepaalt welk risico en complexiteit de release vertegenwoordigt en zorgt ervoor dat het juiste niveau van voorbereiding wordt toegepast om ervoor te zorgen dat de release-doelstellingen worden bereikt zonder de lopende activiteiten van het bedrijf in gevaar te brengen .

16.4 Waarom is Release Management nodig?

Het primaire doel van releasebeheer is het plannen en controleren van de implementatie van ITservices en updates in de live-omgevingen. Bedrijven ontwikkelen zich en als ze dat doen, veranderen hun behoeften, dus de IT-omgeving moet ook veranderen. Release management biedt een middel om wijzigingen effectief en veilig door te voeren. Dit doet het door ervoor te zorgen dat alleen voldoende geteste services en componenten kunnen worden vrijgegeven in de live-omgeving die het bedrijf gebruikt.

Enkele andere voordelen van release management zijn:

• Snellere levering van wijzigingen en nieuwe functies aan gebruikers

• Minder risico dat ongeautoriseerde releases zorgen dat functies kapotgaan die mensen gebruiken

• Voorspelbare planning van uitrol op tijden met een minimale impact op de bedrijfsvoering

• Waarborging dat nieuwe of gewijzigde services voldoen aan de overeengekomen servicevereisten

• Goede kennisoverdracht aan gebruikers en ondersteuningspersoneel

16.5 Benaderingen voor Release- en Installatiebeheer

ITIL v3 definieert zes benaderingen voor release- en implementatiebeheer. De meeste bedrijven gebruiken een variant van deze benaderingen, hoewel ze er mogelijk met verschillende namen naar verwijzen. Het is ook gebruikelijk dat verschillende benaderingen worden gebruikt voor verschillende soorten en maten projecten.

• Big Bang Benadering : nieuwe of gewijzigde service wordt naar alle gebruikers tegelijkertijd uitgerold.

• Gefaseerde Benadering: services worden eerst uitgerold naar een deel van het gebruikersbestand en als er geen problemen optreden wordt de uitrol herhaald voor andere gebruikersgroepen via een ingepland uitrolplan

• Push Benadering: het servicecomponent wordt vanuit een centrale locatie uitgerold en op een vooraf ingestelde tijd doorgezet naar de doelgroep en/of locatie

• Geautomatiseerde Benadering: wijzigingen worden uitgerold in de productieomgeving met geautomatiseerde workflows en distributiemechanismen

• Handmatige Benadering: afhankelijk van handmatige activiteiten om een release uit te rollen (wordt vaak gebruikt wanneer de release afhankelijk is van systemen die voor of na de uitrol handmatig gecontroleerd moeten worden)

Release en Installatiebeheer heeft als taak de systemen en services van ee n organisatie te laten veranderen om de veranderende bedrijfsbehoeften te ondersteunen. Er kunnen meerdere projectteams en leveranciers zijn die bezig zijn met het ontwikkelen van individuele veranderingen en het is de taak van release management om ervoor te zorgen dat alle puzzelstukjes samenkomen en op de juiste manier worden getest voordat ze worden geïntroduceerd in de live -omgeving waarop zakelijke gebruikers vertrouwen. Release management processen die worden gecoördineerd door een bekwame en ervaren release manager, die is uitgerust met de juiste verzameling release management tools om het werk effectief te doen, kunnen een bedrijf helpen om veilige en effectieve wijzigingen in hun IT-omgeving te organiseren.

16.6 Begrippen

• Release of uitgave: Samenstelling van één of meer Changes

• Categorieën: Impact en omvang

o Major: (belangrijke roll-out nieuwe hard/software, aanzienlijke uitbreiding functionaliteit, neemt vaak aantal Known Errors weg, inclusief Workarounds en Quick Fixes)

o Minor (kleine verbeteringen, Fixes op Known Errors, laatste goede basisconfiguratie wordt geactualiseerd)

o Emergency

• Type

o Delta (alleen die software/hardware die gewijzigd is)

o Full (alle onderdelen van een programma, incl. wat niet gewijzigd is)

o Package (gebundelde) release

• Omgeving van de release

o Ontwikkelomgeving, testomgeving, exploitatieomgeving en archief

• Definitive software library: Fysieke bibliotheek waarin alle definitief geautoriseerde softwareversies beschermd liggen opgeslagen evt. op disk

• Definitive hardware store: Een ruimte waar alle reserve apparatuur staat

• Configuration management

• Back-outplanning

o Terugdraaien

o Noodmaatregelen

17 Oefeningen

17.1 Service management

1. Vul de volgende definities aan met een van de woorden uit de onderstaande lijst.

a) Een ...................................................... is een middel om co -creatie van waarde mogelijk te maken door het faciliteren van resultaten die klanten willen bereiken, zonder dat de klant specifieke kosten en risico's hoeft te beheren.

b) Een ...................................................... is een geheel van gespecialiseerde organisatorische capaciteiten om waarde te creëren voor klanten in de vorm van diensten.

c) Een ...................................................... is een tastbaar of ontastbaar resultaat van een activiteit.

d) Een ...................................................... is een resultaat voor een stakeholder dat mogelijk wordt gemaakt door een of meer outputs.

e) Een ...................................................... is een mogelijke gebeurtenis die schade of verlies kan veroorzaken, of het moeilijker maakt om doelstellingen te bereiken.

f) Een ...................................................... is het waargenomen voordeel, nut en belang van iets.

Lijst:

• Output

• Servicebeheer

• Waarde

• Dienst

• Risico

• Resultaat

2. Zet de woorden onder het plaatje, op de juiste plaats op het plaatje.

Teken dit gerust op een blad.

EN OF EN

Geschikt voor doel?

Nut

Geschikt voor gebruik? Veilig genoeg?

Beschikbaar genoeg? Prestaties voldoende?

Capaciteit genoeg? Garantie Beperkingen weggenomen?

Continu genoeg? Waarde gecreëerd

3. Vul de ontbrekende delen aan

a) Welke soorten kosten kennen we (vanuit het oogpunt van de afnemer van de dienst):

........................................ -

b) Welke soorten risico's zijn van belang voor de afnemer van de dienst:................................................................................

c) Hoe kan de consument bijdragen tot de vermindering van risico's?........................................

4. Vul de volgende definities aan met een van de woorden uit de onderstaande lijst.

a) Een ...................................................... is een persoon of een groep mensen die zijn eigen functies heeft met verantwoordelijkheden, bevoegdheden en relaties om zijn doelstellingen te bereiken.

b) Een ...................................................... is de rol die gebruik maakt van de diensten.

c) Een ...................................................... is de rol die de vereisten voor een dienst bepaalt en verantwoordelijkheid neemt voor de resultaten van het gebruik van de dienst.

d) Een ...................................................... is de rol die budget autoriseert voor service gebruik.

Gebruik volgende woorden:

Gebruiker Sponsor

Klant Organisatie

5. Wat kan een dienstenaanbod omvatten?........................................

17.2 ITIL guiding principles

1. Welk van de volgende is GEEN principe?

• Focus op waarde

• Houd het eenvoudig en praktisch

• Manage door het goede voorbeeld te geven

• Denk en werk holistisch

2. Bij welk principe moeten we zorgvuldig beoordelen wat we moeten behouden?

• Hou het simpel en praktisch

• Werk iteratief met feedback

• Werk samen en bevorder de zichtbaarheid

• Focus op waarde

3. In welk principe is de rol van feedback belangrijk?

• Begin waar je bent

• Bevorder iteratief met feedback

• Houd het simpel en praktisch

• Optimaliseer en automatiseer

4. In welk principe moeten we definitief weten wie de serviceconsument is?

• Begin waar je bent

• Hou het eenvoudig en praktisch

• Denk en werk holistisch

• Focus op waarde

5. In welk principe is meten belangrijk?

• Begin waar je bent

• Focus op waarde

• Optimaliseer en automatiseer

• Werk samen en bevorder de zichtbaarheid

6. In welk principe is communicatie erg belangrijk?

• Optimaliseren en automatiseren

• Samenwerken en zichtbaarheid bevorderen

• Houd het eenvoudig en praktisch

• Werk iteratief met feedback

17.3 De vier dimensies van dienstenbeheer

1. Welke dimensie omvat de technologieën die nodig zijn voor het beheer van diensten?

• Organisaties en mensen

• Informatie & technologie

• Partners & leveranciers

• Waardestromen & processen

2. Welke dimensie omvat de relaties van een organisatie met andere organisaties?

• Organisaties & mensen

• Informatie & technologie

• Partners & leveranciers

• Waardestromen & processen

3. Welke dimensie omvat de kennis die nodig is voor het beheer van diensten?

• Organisaties & mensen

• Informatie & technologie

• Partners & leveranciers

• Waardestromen & processen

4. Welke dimensie richt zich op welke activiteiten de organisatie onderneemt en hoe deze georganiseerd worden?

• Organisaties & mensen

• Informatie & technologie

• Partners & leveranciers

• Waardestromen en processen

5. Welke dimensie zorgt voor de manier waarop een organisatie gestructureerd en beheerd wordt?

• Organisaties & mensen

• Informatie & technologie

• Partners & leveranciers

• Waardestromen & processen

6. Welke dimensie houdt zich bezig met hoe de verschillende delen van de organisatie op een geïntegreerde en gecoördineerde manier werken?

• Organisaties & mensen

• Informatie & technologie

• Partners & leveranciers

• Waardestromen en processen

17.4 SVS en SVC

17.4.1 Service Value System

1. Zet het nummer van het onderdeel in het plaatje.

2. Verbind ook deze componenten met de juiste uitleg.

Onderdeel Uitleg

1 Dienst waardeketen a Een terugkerende organisatorische activiteit die op alle niveaus wordt uitgevoerd om ervoor te zorgen dat de prestaties van een organisatie voortdurend voldoet aan de verwachtingen van belanghebbenden. ITIL 4 ondersteunt voortdurende verbetering met het ITIL-model voor voortdurende verbetering.

2 Leidende principes b Reeksen organisatorische middelen ontworpen voor het uitvoeren van werk of het bereiken van een doelstelling.

3 Praktijken c Aanbevelingen die een organisatie kunnen leiden in alle omstandigheden, ongeacht veranderingen in zijn doelstellingen, strategieën, type van werk, of managementstructuur.

4 Voortdurende verbetering d De manier waarop een organisatie wordt geleid en gecontroleerd.

5 Governance e Een set van onderling verbonden activiteiten die een organisatie uitvoert om een waardevol product of dienst te leveren aan zijn

consumenten en om waardeverwezenlijking te vergemakkelijken.

17.4.2

Service Value Chain

1. Breng het aantal activiteiten van de waardeketen in beeld.

2. Verbind ook deze waardeketenactiviteiten met het juiste doel.

Activiteit Doel

1 Betrokkenheid a Ervoor zorgen dat producten en diensten voortdurend voldoen aan de verwachtingen van belanghebbenden voor wat betreft kwaliteit, kosten, en tijd om op de markt te komen.

2 Plannen b Om te zorgen voor voortdurende verbetering van producten, diensten en praktijken in alle activiteiten van de waardeketen en de vier dimensies van service management.

3 Ontwerp & transitie c Ervoor zorgen dat de componenten van de dienst beschikbaar zijn wanneer en waar ze nodig zijn, en voldoen aan de overeengekomen specificaties.

4 Verbeteren d Zorgen voor een goed inzicht in de behoeften van de belanghebbenden, transparantie, voortdurende betrokkenheid en goede relaties met alle belanghebbenden hebben.

5 Leveren & ondersteunen e Zorgen voor een gedeeld begrip van de visie, de huidige status, en verbeteringsrichting voor alle vier dimensies en alle producten en diensten in de hele organisatie.

6 Verkrijgen/bouwen f Om te verzekeren dat diensten worden geleverd en ondersteund volgens overeengekomen specificaties en verwachtingen.

17.5 ITIL-praktijken

1. Vul het model voor voortdurende verbetering in, met behulp van de vragen uit de onderstaande lijst.

1 Waar zijn we nu?

2 Hoe komen we daar?

3 Hoe houden we het momentum gaande?

4 Onderneem actie

5 Wat is de visie?

6 Zijn we er geraakt?

7 Waar willen we zijn?

2. Welke zijn de 3 soorten verandering die we kennen?

3. Wat zijn de typische fasen van het problem management proces, en zet ze in de juiste volgorde.

Probleem creatie

Fout beheer

Probleem identificatie

Probleem ontwikkeling

Fout beoordeling

Probleem classificatie

Foutdetectie Foutoplossing

Probleem evaluatie Probleem controle Probleem verificatie

Probleem categorisatie Foutverwijdering Foutdefinitie

Probleem beschrijving

Probleem beoordeling Fout-record logging

Probleemregistratie Foutcontrole Probleem definitie

4. Wat zijn de vier informatiebronnen voor service level management? (kies uit de lijst)

Klachten van klanten Complimenten van klanten Feedback van klanten

Bedrijfsstatistieken Servicemetingen

Waarde metrics

Technologiemetingen

Operationele metrics Klantervaring

Klantperceptie Klantvoorkeur

Gebruikersparticipatie Gebruikerservaring

Betrokkenheid van de gebruiker

Betrokkenheid van de klant

5. Verbind het juiste doel met de juiste ITIL praktijk.

Praktijk Doel

Eis van de klant

Betrokkenheid van de gebruiker

Verbetering van de technologie

1 leveranciersbeheer a Ervoor zorgen dat nauwkeurige en betrouwbare informatie over de configuratie van diensten, en de CI's die deze ondersteunen, beschikbaar is wanneer en waar dat nodig is. Dit omvat informatie over de wijze waarop CI's zijn geconfigureerd en de relaties tussen de CI's.

2 Vrijgave beheer b Het overbrengen van nieuwe of gewijzigde hardware, software, documentatie, processen, of een andere component naar live omgevingen. Het kan ook betrokken zijn bij het uitrollen van componenten naar andere omgevingen voor testen of staging.

3 Dienst configuratie management c Tot stand brengen en onderhouden van de banden tussen de organisatie en haar stakeholders op strategisch en tactisch niveau.

4 Informatie beveiliging management d Nieuwe en gewijzigde diensten en functies beschikbaar stellen voor gebruik.

5 Monitoring en gebeurtenis management e Het plannen en beheren van de volledige levenscyclus van alle IT assets, om de organisatie te helpen.

6 Deployment management f Ervoor zorgen dat de leveranciers van de organisatie en hun prestaties op de juiste wijze worden beheerd om de naadloze levering van kwaliteitsproducten en -diensten te garanderen.

7 IT-activa management

g Om systematisch een service of servicecomponent te observeren, en vastleggen en rapporteren van geselecteerde veranderingen en toestanden geïdentificeerd als gebeurtenissen.

8 Relatie management h De informatie beschermen die de organisatie nodig heeft om haar zaken te doen.

6. Vul de volgende definities aan met een van de woorden uit de onderstaande lijst.

a) Een ...................................................... is de toevoeging, wijziging of verwijdering van iets dat een direct of indirect effect op diensten kan hebben.

b) Een ...................................................... is elke verandering van toestand die van belang is voor het beheer van een dienst of een ander configuratie-item (CI). Ze worden typisch herkend door meldingen die worden aangemaakt door een IT-service, CI of monitoringtool.

c) Een ...................................................... is een probleem dat is geanalyseerd maar nog niet opgelost.

d) Een ...................................................... is elk onderdeel dat moet worden beheerd om een IT-dienst te leveren.

e) Een ...................................................... is een ongeplande onderbreking van een dienst of vermindering de kwaliteit van een dienst

f) Een ...................................................... is een oorzaak, of potentiële oorzaak, van een of meer incidenten.

g) Een ...................................................... is een waardevol onderdeel dat kan bijdragen aan de levering van een IT-product of -dienst.

Probleem IT-onderdeel Wijziging Configuratieonderdeel

Bekende fout Gebeurtenis Incident

18 Vereiste voorkennis

18.1 Cloud computing

Eenvoudig gezegd is Cloud computing het leveren van computingservices, inclusief servers, opslag, databases, netwerkfuncties, software, analysefuncties en intelligentie) via internet ('de cloud') waarmee u een snellere innovatie, flexibele resources en schaalvoordelen krijgt. U betaalt doorgaans alleen voor de Cloud services die u gebruikt, waardoor u minder bedrijfskosten hebt, uw infrastructuur efficiënter draait en u kunt schalen al naar gelang uw bedrijf wijzigingen nodig heeft.

18.1.1 De belangrijkste voordelen van cloudcomputing

Cloudcomputing betekent een grote verandering in denken ten opzichte van de traditionele manier waarop bedrijven over IT-bronnen dachten. Er zijn zeven algemene redenen waarom organisaties Cloud computing gaan gebruiken:

Kosten

Cloudcomputing elimineert de noodzaak om kosten te maken voor de aanschaf van hardware en software en voor het opzetten en beheren van eigen on-site datacenters (rekken met servers, de elektriciteit die dag en nacht nodig is voor stroomvoorziening en koeling, en de IT -experts die de infrastructuur moeten beheren). Dat loopt snel in de papieren.

Snelheid

De meeste Cloud computingservices worden als selfservice op aanvraag geleverd. Daardoor kunnen zelfs grote aantallen computerbronnen in enkele minuten worden ingericht, en meestal kan dat via een paar muisklikken. Dit alles biedt bedrijven veel flexibiliteit en zorgt voor minder druk tijdens het plannen van capaciteit.

Wereldwijde schaal

Een van de voordelen van Cloud computingservices is de mogelijkheid tot flexibele schaalaanpassing. In Cloud termen gesproken, houdt dat in dat het juiste aantal IT-bronnen wordt geleverd (bijvoorbeeld meer of minder rekenkracht, opslag, bandbreedte) afgesteld op de behoefte van dat moment en vanaf de juiste geografische locatie.

Productiviteit

On-site datacenters vereisen veel rekken en veel gestapel, hardware die moet worden ingesteld, softwarepatches die moeten worden geïnstalleerd en andere tijdrovende taken die met het beheer van IT zijn gemoeid. Cloudcomputing maakt veel van deze taken overbodig, zodat IT -teams hun tijd kunnen besteden aan het bereiken van belangrijkere bedrijfsdoelstellingen.

Prestaties

De omvangrijkste Cloud computingservices worden op een wereldwijd netwerk van beveiligde datacenters uitgevoerd. Ze worden regelmatig bijgewerkt naar de laatste nieuwe generatie, snelle en efficiënte computing hardware. Dit heeft diverse voordelen in vergelijking met de noodzaak tot het hebben van een enkel bedrijfsdatacenter, waaronder een verminderde netwerklatentie voor toepassingen en grotere schaalvoordelen.

Betrouwbaarheid

Cloudcomputing maakt zaken als het maken van back -ups van gegevens, noodherstel na een ramp en het waarborgen van de bedrijfscontinuïteit eenvoudiger en goedkoper, omdat gegevens gespiegeld kunnen worden op meerdere redundante sites in het netwerk van de cloudprovider.

Beveiliging

Veel Cloud providers bieden een uitgebreide serie beleidsregels, technolo gieën en regelingen die uw algehele beveiligingspostuur versterken. Zo worden uw gegevens, apps en infrastructuur beschermd tegen potentiële bedreigingen.

18.1.2 Typen cloudcomputing

Niet alle Cloud zijn gelijk en er bestaat geen enkel type Cloud computing dat geschikt is voor iedereen. Er zijn verschillende modellen, typen en services ontwikkeld om u de juiste oplossing te bieden voor uw behoeften.

Eerst moet u het type Cloud implementatie of Cloud computingarchitectuur bepalen waarop uw Cloud services worden geïmplementeerd. Er zijn drie verschillende manieren om Cloud services te implementeren: in een openbare cloud, privécloud of hybride cloud.

Openbare Cloud

Openbare Clouds zijn het eigendom van en worden beheerd door externe cloudserviceproviders, die de computerbronnen, zoals servers en opslag, via internet leveren. Microsoft Azure is een voorbeeld van een openbare cloud. Bij een openbare cloud is alle hardware, software en andere ondersteunende infrastructuur het eigendom van de cloudprovider en voert deze partij ook het onderhoud ervan uit. De toegang tot services en het beheer van uw account verloopt via een webbrowser.

Privécloud

Een privécloud heeft betrekking op bronnen voor cloudcomput ing die uitsluitend door één bedrijf of één organisatie worden gebruikt. Een privécloud kan zich fysiek in het datacenter op locatie bij de organisatie zelf bevinden. Sommige bedrijven betalen externe serviceproviders voor het hosten van hun privécloud. Een privécloud is een cloud waarvoor de services en de infrastructuur op een privénetwerk worden onderhouden.

Hybride cloud

Een hybride cloud waarin openbare en privéclouds samengaan en deze zijn verbonden via technologie die het mogelijk maakt dat gegevens en toepassingen tussen de clouds kunnen worden gedeeld. Doordat gegevens en toepassingen zich kunnen verplaatsen tussen privéclouds en openbare clouds, biedt een hybride cloud uw bedrijf meer flexibiliteit, meer implementatieopties en de mogelijkheid om uw bestaande infrastructuur, beveiliging en naleving te optimaliseren.

18.1.3 Typen cloudservices: IaaS, PaaS en SaaS

De meeste cloudcomputingservices kunnen in drie hoofdcategorieën worden onderverdeeld: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) en Software as a Service (SaaS). Ze worden ook wel de 'cloudcomputingstack' genoemd, omdat ze in een stack of stapel boven op elkaar worden gebouwd. Door te weten wat het zijn en hoe ze van elkaar verschillen, wordt het gemakkelijker om uw bedrijfsdoelstellingen te halen.

Infrastructure as a service (IaaS)

De meest elementaire categorie cloudcomputingservices. Met IaaS huurt u een IT-infrastructuur (servers en virtuele machines (VM's), opslag, netwerken, besturingssystemen) bij een cloudprovider op basis van betalen per gebruik.

Platform as a Service (PaaS)

PaaS (Platform as a Service) verwijst naar cloudcomputingservices die bestaan uit de levering op aanvraag van een omgeving voor het ontwikkelen, testen, leveren en beheren van softwaretoepassingen. PaaS is ontworpen voor ontwikkelaars die eenvoudig en snel mobiele en webapps willen maken, zonder dat ze zich bezig hoeven te houden met het opzetten of het beheren van de onderliggende infrastructuur van de servers, de opslag, het netwerk en de databases die nodig zijn voor de ontwikkeling van deze toepassingen.

Software as a Service (SaaS)

SaaS (Software-as-a-Service) is een methode voor de levering van softwaretoepassingen via internet.

Dit gebeurt op aanvraag en doorgaans op basis van een abonnement. Met SaaS zijn cloudproviders in staat de softwaretoepassingen en de onderliggende infrastructuur te hosten en te beheren, en onderhoudstaken uit te voeren zoals het installeren van software-upgrades en beveiligingspatches.

Gebruikers maken verbinding met de toepassing via internet, meestal met een webbrowser op hun telefoon, tablet of pc.

18.1.4 Waar cloudcomputing voor wordt gebruikt

Waarschijnlijk maakt u nu al gebruik van cloudcomputing, maar bent u zich daar niet van bewust. Als u een onlineservice gebruikt voor het verzenden van e-mail, het bewerken van documenten, het kijken naar films of tv-programma's, het luisteren naar muziek, het spelen van games of als u foto's en andere bestanden opslaat, dan is het waarschijnlijk dat dit allemaal mogelijk wordt gemaakt door middel van cloudcomputing achter de schermen. De eerste cloudcomputingservices bestaan nog maar nauwelijks tien jaar, maar er zijn nu al een groot aantal verschillende bedrijven, van kleine startende ondernemingen en multinationals tot overheidsinstellingen en non-profitorganisaties, die deze technologie om tal van redenen graag gebruiken.

Hier zijn een paar voorbeelden van wat tegenwoordig mogelijk is met cloudservices van de kant van een cloudprovider:

Maak cloudtoepassingen

Ontwikkel, implementeer en schaal snel toepassingen - via web, mobiel en API. Benut cloudeigen technologieën en methoden, zoals containers, Kubernetes, microservicesarchitectuur , communicatie op basis van API's en DevOps.

Toepassingen testen en ontwikkelen

Bespaar kosten en tijd voor app-ontwikkeling door gebruik te maken van cloudinfrastructuren die eenvoudig omhoog en omlaag te schalen zijn.

Gegevens opslaan, back-ups van gegevens maken en gegevens herstellen

Bescherm uw gegevens meer kostenbesparend (en op zeer grote schaal) door uw gegevens via internet over te zetten naar een extern cloudopslagsysteem dat toegankelijk is vanaf elke locatie en via elk apparaat.

Gegevens analyseren

Voeg de gegevens van al uw teams, divisies en locaties samen in de cloud. Gebruik dan cloudservices, zoals machine learning en kunstmatige intelligentie, om inzichten te verkrijgen voor meer geïnformeerde besluiten.

Audio en video streamen

Maak waar, wanneer en met welk apparaat dan ook verbinding met uw publiek via HD -video enaudio met een wereldwijde distributie.

Intelligentie integreren

Gebruik intelligente modellen om klanten meer erbij te betrekken en zorg voor waardevolle inzichten uit de vastgelegde gegevens.

Software op aanvraag leveren

Met software op aanvraag, tevens bekend als SaaS (Software as a service), kunt u klanten de nieuwste softwareversies en -updates aanbieden, wanneer en waar zij die dan ook nodig hebben.

18.2 Blockchain

Blockchain wordt wel de grootste uitvinding sinds die van het internet genoemd. Steeds meer bedrijven verkennen de mogelijkheden van deze technologie om data en transacties veilig en efficiënt op te slaan. Wat is Blockchain en wat kunnen we erva n verwachten?

18.2.1

Nieuw soort database

Blockchain is een nieuw soort database, waarin transacties opgeslagen kunnen worden. Dat kunnen allerlei soorten transacties zijn. In het ene geval gaat het om betalingen met een digitale munt, in het andere om belangrijke gegevens die 2 partijen uitwisselen, zoals contracten, diploma's of eigendomsbewijzen.

Eén ding hebben ze gemeen. Het worden blokjes informatie die digitaal 'ondertekend' zijn door beide partijen. Zonder tussenkomst van een derde partij en ze worden direct opgeslagen in de database.

18.2.2 Onkraakbare ketting

Alle informatie wordt versleuteld opgeslagen in Blockchain met behulp van cryptografie. Digitale betaalmiddelen die gebruik maken van Blockchain-technologie - zoals de Bitcoin - worden daarom wel ‘cryptovaluta’ genoemd. Alle transacties worden in blokjes opgeslagen in een groot netwerk van computers. Een nieuw blokje bevat altijd informatie over het vorige blokje, wat weer informatie over het vorige bevat. Zo ontstaat een lange, onveranderbare en onkraakbare informatieketting.

18.2.3

Geen middelpunt

De meeste traditionele databases zijn centraal georganiseerd. Dat betekent dat er één locatie is waar alle gegevens opgeslagen zijn. Alleen daar worden gegevens gewijzigd en gedeeld met gebruikers. Bij Blockchain is dat anders: er is juist géén centraal punt, maar er zijn meerdere knooppunten (computers) die allemaal een exacte kopie van de database bevatten. Die knooppunten worden ook wel 'nodes' genoemd. Het verschil ziet er zo uit:

18.2.4

Toezicht

Bij Blockchain is er dus niet één eigenaar of toezichthouder, zoals dat bij normale databases wel het geval is. Het toezicht ligt bij de gebruikers zelf. Nieuwe transacties worden door de ‘nodes’ in de database opgeslagen. Daarvoor moeten ze eerst een code zien te vinden die a angeeft dat alle informatie klopt. De nodes moeten het met elkaar ‘eens’ zijn dat de code juist is. Pas dan wordt de informatie opgeslagen in de ketting.

Niemand kan dus op eigen houtje informatie opslaan of wijzigen in de database. Kwaadwillenden kunnen zo onmogelijk foute transacties doen of data manipuleren.

18.2.5 Veilig?

Alle wijzigingen in de database worden automatisch gekopieerd naar alle computers. Het systeem is daarmee niet afhankelijk van één centrale database. Zo ontstaat er niet meteen een groot prob leem als er iets met een van de knooppunten gebeurt. Wordt één van de computers in het netwerk gehackt of valt de stroom uit, dan zijn er altijd nog de andere ‘nodes’ met elk hun eigen kopie van de database. Dat maakt het veiliger dan systemen met een cent rale database.

18.2.6 Toekomst

Blockchain is een 'open' technologie die voor veel verschillende toepassingen ingezet kan worden. Dat betekent dat iedereen die de techniek beheerst, zelf zijn eigen Blockchain-database kan bouwen

voor zijn eigen toepassing. Je bepaalt daarbij een zogenoemd protocol. Een verzameling regels waaraan de database (en het gebruik ervan) moet voldoen. Zo onstaan dus verschillende blockchains.

Een van de voordelen van Blockchain is dat het onhandige papieren contracten en documentatie kan vervangen door veilige en slimme elektronische documenten. Dat kan veel processen efficiënter maken.

Een aantal voorbeelden:

• Cryptovaluta: de bekendste Blockchain-toepassing. Vooral Bitcoin is veel in het nieuws. Maar er zijn er al honderden verschillende cryptovaluta. Ethereum en Litecoin zijn daar voorbeelden van. Elk hebben hun eigen variant van een Blockchain-database, waarbij tussenkomst van een financiele instelling overbodig is. Dat maakt het proces veel efficiënter. Internationale betalingen die normaal dagen of soms weken duren, zijn nu binnen 10 minuten geregeld.

• Zorg: zogenoemde Smart-contracts kunnen afspraken tussen bijvoorbeeld een zorgverzekeraar en een klant vastleggen. Zorgverzekeraars kunnen dit in de toekomst gebruiken. Op het moment dat je zorg krijgt, kun je dat aan je slimme contract voorleggen. Dat kan zelf bepalen of je ervoor verzekerd bent. Zo ja, dan wordt het automatisch vergoed. Dus geen tijdrovende procedures meer aan de kant van de verzekeraar.

• Patiëntgegevens: patiëntgegevens uit ziekenhuislaboratoria worden vaak nog per post verstuurd naar andere ziekenhuizen, en vervolgens handmatig ingevoerd in de computer. Een duur, foutgevoelig en traag proces. Met Blockchain-technologie kan het sneller, goedkoper en fouten zijn vrijwel onmogelijk.

• Auteursrechten: ook voor componisten, tekstschrijvers en auteurs is het mogelijk om rechten op te slaan in een Blockchain-database. Zo kunnen ze steeds als er iemand gebruik van maakt, automatisch een vergoeding krijgen. Een tussenpersoon die zic h bezighoudt met auteursrechten is dan overbodig.

18.2.7 Energie

Het systeem van de blockchain vereist een enorme hoeveelheid rekenkracht, dus elektriciteit van een computer, om elke blokje te verifiëren en toe te voegen aan de ketting. En in het hele netwerk gaat het ook nog eens om duizenden computers.

Het aantal Bitcointransacties is nog relatief beperkt. Toch verbruiken alle Bitcoin-transacties enhandelingen samen al meer dan het totale stroomverbruik van een land als Zwitserland. Daarom wordt volop gezocht naar nieuwe manieren om gegevens te controleren en toe te voegen in de database.

18.3 Agile Scrum

18.3.1

Doel van Scrum

Scrum is een raamwerk voor het ontwikkelen en onderhouden van comple xe producten. Dit hoofdstuk beschrijft de definitie van Scrum. Deze definitie bestaat uit de Scrum rollen, gebeurtenissen, artefacten en de regels die deze zaken samenbrengen. Ken Schwaber en Jeff Sutherland hebben Scrum ontwikkeld.

18.3.2

Definitie van Scrum

Scrum: Een raamwerk waarbinnen mensen complexe, adaptieve problemen adresseren en tegelijkertijd op een productieve en creatieve wijze producten van de hoogst mogelijk waarde leveren.

Scrum is:

• Lichtgewicht

• Simpel om te begrijpen

• Moeilijk om te leren beheersen

Scrum is een procesraamwerk dat sinds de jaren 1990 gebruikt wordt om complexe productontwikkeling te managen. Scrum is geen proces of techniek voor het bouwen van producten; het is een raamwerk waar binnen je de verschillende processen en technieken kunt inzetten. Scrum maakt de effectiviteit van jouw productmanagement en ontwikkeltechnieken inzichtelijk zodat je kunt verbeteren.

Het Scrum raamwerk bestaat uit Scrum Teams en hun bijbehorende rollen, gebeurtenissen, artefacten en regels. Elk onderdeel binnen het raamwerk dient een specifiek doel en is essentieel voor het gebruik en succes van Scrum.

De regels van Scrum verbinden de gebeurtenissen, rollen en artefacten, en beschrijven de relaties en interactie tussen deze. De regels van Scrum worden beschreven door deze hele tekst heen.

Specifieke tactieken voor het gebruik van het Scrum raamwerk verschillen en worden niet in dit hoofdstuk beschreven.

18.3.3 Scrum Theorie

Scrum is gebaseerd op de theorie van empirische procesbesturing , ofwel het empirisme. Empirisme gaat er vanuit dat kennis ontstaat uit ervaring en het nemen van beslissingen op basis van wat bekend is. Scrum gebruikt een iteratieve, incrementele aanpak om voorspelbaarheid te optimaliseren en risico’s te beheersen.

Drie pijlers vormen het fundament van elke implementatie van empirische procesbesturing : transparantie, inspectie en aanpassing.

18.3.3.1 Transparantie

Significante aspecten van het proces moeten zichtbaar zijn voor diegenen die verantwoordelijk zijn voor het resultaat. Transparantie vereist dat deze aspecten gedefinieerd zijn volgens een gezamenlijke standaard zodat waarnemers een gezamenlijk begrip hebben van wat er gezien wordt.

Bijvoorbeeld:

• Een gemeenschappelijke taal met betrekking tot het proces moet door alle deelnemers worden gedeeld.

• Een gemeenschappelijke definitie van “Klaar” (Definition o f Done) moet worden gedeeld door degenen die het werk uitvoeren en degenen die het werkende product accepteren.

18.3.3.2 Inspectie

Scrum gebruikers moeten frequent de Scrum artefacten en de voortgang ten opzichte van het doel inspecteren, om ongewenste variantie te kunnen detecteren. Hun inspecties mogen niet zo frequent zijn dat de inspecties in de weg gaan zitten van het werk. Inspecties zijn het meest nuttig wanneer ze zorgvuldig worden uitgevoerd door vaardige inspecteurs, daar waar het werk gedaan wordt.

18.3.3.3 Aanpassing

Als een inspecteur bepaalt dat één of meer aspecten van een proces buiten de acceptabele limieten vallen en dat het resulterende product onacceptabel zal zijn, zal het proces of het onderhanden werk aangepast moeten worden. Een aanpassing moet zo snel mogelijk uitgevoerd worden om verdere afwijkingen te minimaliseren.

Scrum schrijft vier formele gelegenheden voor ten behoeve van inspectie en aanpassing, zoals beschreven in het Scrum Gebeurtenissen gedeelte van dit document.

• Sprint Planning

• Dagelijkse Scrum

• Sprint Review

• Sprint Retrospective

18.3.4 Scrum Waarden

Wanneer de waarden inzet, moed, focus, openheid en respect worden uitgedragen en geleefd dor het Scrum Team, komen de Scrum pilaren van transparantie, inspectie en aanpassing tot leven en bouwen deze vertrouwen voor iedereen. De Scrum Teamleden leren en ontdekken deze waarden als zij werken met de Scrum gebeurtenissen, rollen en artefacten.

Succesvol gebruik van Scrum hangt af van de vaardigheid waarmee de mensen naar deze vijf waarden leven. Mensen spreken af zich in te zetten om de doelen van het Scrum Team te halen. De Scrum Teamleden hebben de moed om het juiste ding te doen, en om lastige problemen aan te pakken. Iedereen focust op het werk in de Sprint en de doelen van het Scrum Team. Het Scrum Team

en de belanghebbenden spreken af open te zijn over al het werk en de uitdagingen in het uitvoeren van het werk. Scrum Teamleden respecteren elkaar om capabele, onafhankelijke mensen te zijn.

18.3.5 Het Scrum Team

Het Scrum Team bestaat uit een Product Owner, het Ontwikkelteam en een Scrum Master. Scrum Teams zijn zelf organiserend en multidisciplinair. Zelforganiserende teams kiezen zelf hoe zij het beste hun werk kunnen uitvoeren, in plaats van dat dit verteld wordt door iemand van buiten het team. Multidisciplinaire teams hebben alle competenties die nodig zijn om het werk uit te voeren, zonder afhankelijk te zijn van anderen buiten het team. Het team model in Scrum is ontworpen voor optimale flexibiliteit, creativiteit en productiviteit.

Scrum teams leveren iteratief en incrementeel producten, waarbij gelegenheden voor feedback gemaximaliseerd worden. Incrementele leveringen van een “Klaar” (Done) product zorgen ervoor dat een potentieel bruikbare versie van het product altijd beschikbaar is.

18.3.5.1

De Product Owner

De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product en de werkzaamheden van het Ontwikkelteam. Hoe dit precies gedaan wordt verschilt enorm per organisatie, Scrum Team en individu.

De Product Owner is de enige persoon die verantwoordelijk is voor het managen van de Product Backlog. Product Backlog management omvat o.a.:

• Helder omschrijven van Product Backlog items;

• Ordenen van Product Backlog items zodat doelen en missie op de beste manier behaald kunnen worden;

• Optimaliseren van de waarde van het werk dat het Ontwikkelteam uitvoert;

• Ervoor zorgen dat de Product Backlog zichtbaar, transparant en duidelijk is voor iedereen, en dat het laat zien waar het Scrum Team als volgende aan gaat werken; en

• Ervoor zorgen dat het Ontwikkelteam de Product Backlog items begrijpt tot het niveau dat nodig is.

De Product Owner kan het bovenstaande werk zelf uitvoeren, of het door het Ontwikkelteam laten doen. In elk geval blijft de Product Owner verantwoordelijk.

De Product Owner is één persoon, geen comité. De Product Owner kan de wensen van een comité vertegenwoordigen via de Product Backlog, maar iedereen die een verandering wil in prioriteit van een Backlog Item, moet de Product Owner aanspreken.

Om te kunnen slagen als Product Owner, moet de gehele organisatie zijn of haar beslissingen respecteren. De beslissingen van de Product Owner zijn zichtbaar in de inhoud en ordening van de Product Backlog. Niemand mag het Ontwikkelteam aan een andere set van requirements laten

werken het en het Ontwikkelteam is het niet toegestaan te acteren op basis van wat iemand anders zegt.

18.3.5.2 Het Ontwikkelteam

Het Ontwikkelteam bestaat uit professionals die het werk doen om een potentieel uitleverbaar Increment van het “Klaar” (Done) product op te leveren aan het einde van elke Sprint. Alleen leden van het Ontwikkelteam creëren het Increment.

Ontwikkelteams worden door de organisatie zodanig gestructureerd en voorzien van bevoegdheden dat zij hun eigen werk kunnen organiseren en beheren. De resulterende synergie optimaliseert de algehele efficiëntie en effectiviteit van het team.

Ontwikkelteams hebben de volgende karakteristieken:

• Ze zijn zelfsturend. Niemand (zelfs de Scrum Master niet) vertelt het Ontwikkelteam hoe zij de Product Backlog moeten omzetten in Incrementen van potentieel uitleverbare functionaliteit.

• Ontwikkelteams zijn multidisciplinair, met alle benodigde vaardigheden om als team een product Increment te kunnen maken.

• Scrum erkent geen titels voor Ontwikkelteamleden anders dan Ontwikkelaar, ongeacht het werk dat door de persoon wordt uitgevoerd; er zijn geen uitzonderingen op deze regel.

• Ontwikkelteams omvatten geen subteams die toegewijd zijn aan een specifiek domein zoals testen of business analyse; er zijn geen uitzonderingen op deze regel.

• Individuele Ontwikkelteamleden kunnen specifieke vaardigheden of focusgebieden hebben, maar verantwoordelijkheid ligt bij het Ontwikkelteam als geheel.

18.3.5.2.1 Ontwikkelteam grootte

De optimale Ontwikkelteam grootte is klein genoeg om wendbaar te blijven en groot genoeg om significant werk te kunnen leveren binnen een Sprint. Minder dan drie Ontwikkelteamleden maakt dat interactie vermindert en resulteert in lagere productiviteitswinst. Kleinere Ontwikkelteams kunnen tegen een gebrek aan vaardigheden aanlopen tijdens de Sprint, wat resulteert in het niet kunnen opleveren van een potentieel uitleverbaar Increment. Meer dan negen leden in het team vereist teveel coördinatie. Grote Ontwikkelteams genereren teveel complexiteit om door een empirisch proces bestuurd te kunnen worden. De Product Owner en de Scrum Master worden hierin niet meegeteld tenzij zij ook werk van de Sprint Backlog uitvoeren.

18.3.5.3 De Scrum Master

De Scrum Master is ervoor verantwoordelijk dat Scrum wordt beg repen en goed wordt uitgevoerd. Scrum Masters doen dit door ervoor te zorgen dat het Scrum Team zich houdt aan de Scrum theorie, praktijk en regels.

De Scrum Master is een dienend leider voor het Scrum Team. De Scrum Master helpt diegenen buiten het Scrum Team te begrijpen welke van hun interacties met het Scrum Team behulpzaam zijn en welke niet. De Scrum Master helpt iedereen deze interacties te veranderen om zo de waarde die door het Scrum Team wordt gecreëerd te maximaliseren.

18.3.5.3.1 Scrum Master diensten aan de Product Owner

De Scrum Master dient de Product Owner op een aantal manieren, waaronder:

• Het vinden van technieken voor een effectief Product Backlog management.

• Het Scrum Team de noodzaak laten inzien om duidelijke en beknopte Product Backlog items te maken.

• Inzicht verkrijgen in de product planning in een empirische omgeving.

• Ervoor zorgdragen dat de Product Owner weet hoe de Product Backlog te ordenen zodat de maximale waarde verkregen kan worden.

• Inzicht verkrijgen in en het beoefenen van agility.

• Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig.

18.3.5.3.2 Scrum Master diensten aan het Ontwikkelteam

De Scrum Master dient het Ontwikkelteam op een aantal manieren, waaronder:

• Coachen van het Ontwikkelteam op het vlak van zelforganisatie en multidi sciplinair werken.

• Het Ontwikkelteam helpen bij het maken van producten van hoge waarde.

• Het verwijderen van belemmeringen (‘impediments’) in de voortgang van het Ontwikkelteam.

• Het faciliteren van Scrum gebeurtenissen wanneer gevraagd of nodig.

• Het coachen van het Ontwikkelteam in organisatorische omgevingen waarbinnen Scrum nog niet volledig is opgenomen en begrepen.

18.3.5.3.3 Scrum Master diensten aan de Organisatie

De Scrum Master dient de organisatie op een aantal manieren, waaronder:

• Het leiden en coachen van de organisatie in haar Scrum adoptie.

• Plannen van Scrum implementaties in de organisatie.

• Helpen van medewerkers en belanghebbenden bij het begrijpen en doorleven van Scrum en empirische productontwikkeling.

• Initiëren van veranderingen die de productiviteit van het Scrum Team verhogen.

• Met andere Scrum Masters samenwerken om de effectiviteit van de toepassing van Scrum binnen de organisatie te verhogen.

18.3.6

Scrum Gebeurtenissen

Binnen Scrum worden voorgeschreven gebeurtenissen gebruikt om regelmaat te creëren en om de behoefte aan overige, niet in Scrum gedefinieerde bijeenkomsten te minimaliseren. Scrum maakt gebruik van timeboxes bij gebeurtenissen, zodat elke gebeurtenis aan een maximale tijdsduur

is gebonden. Als een Sprint eenmaal begonnen is, is de duur niet meer aanpasbaar en kan dus niet ingekort of verlengd worden. De andere gebeurtenissen mogen eindigen zodra het doel van de gebeurtenis is bereikt, zodat de juiste tijd wordt gespendeerd zonder waardevermindering (“waste”) van het proces.

Anders dan de Sprint zelf, die een container is voor alle andere gebeurtenissen, is elke gebeurtenis in Scrum een formele gelegenheid om iets te inspecteren en aan te passen. Deze gebeurtenissen zijn specifiek ontworpen om kritieke transparantie en inspectie mogelijk te maken. Het niet opnemen van één van de deze gebeurtenissen resulteert in een vermindering van transparantie en is een gemiste kans voor inspectie en aanpassing.

18.3.6.1

De Sprint

Het hart van Scrum is een Sprint, een timebox van één maand of minder waarbinnen een “Klaar”, bruikbaar en potentieel uitleverbaar product Increment wordt gecreëerd. Sprints hebben idealiter een consistente lengte gedurende de ontwikkelinspanning. Een nieuwe Sprint start direct nadat de vorige Sprint is afgesloten.

Sprints bevatten en bestaan uit een Sprint Planningsbijeenkomst, Dagelijkse Scrums, het ontwikkelwerk, de Sprint Review en de Sprint Retrospective.

Gedurende de Sprint:

• Worden geen veranderingen aangebracht die het Sprint Doel in gevaar k unnen brengen.

• Verminderen kwaliteitsdoelstellingen niet.

• Mag de scope worden verduidelijkt en heronderhandeld tussen Product Owner en Ontwikkelteam naarmate meer is geleerd.

Elke Sprint mag worden beschouwd als een project met een horizon van niet meer dan één maand. Net als projecten worden Sprints gebruikt om iets te bereiken. Elke Sprint bestaat uiteen definitie van wat er gemaakt moet worden, een ontwerp en een flexibel plan dat richting geeft aan de bouw, de werkzaamheden zelf en het resulterende product.

Sprints worden beperkt tot één kalendermaand. Wanneer een Sprinthorizon te ver weg is kan de definitie van wat gemaakt wordt veranderen, complexiteit kan verhogen en risico ’s kunnen vergroot worden. Sprints geven de mogelijkheid van voorspelbaarheid door ervoor te zorgen dat via inspectie en aanpassing naar een Sprint Doel wordt gestuurd, op zijn minst elke maand. Sprints zorgen er ook voor dat het risico wordt beperkt tot maximaal één maand aan kosten.

18.3.6.1.1 Afbreken van een Sprint

Een Sprint kan worden afgebroken voordat de Sprint timebox voorbij is. Alleen de Product Owner heeft de autoriteit om een Sprint af te breken, hoewel hij of zij dit kan doen onder invloed van de belanghebbenden, het Ontwikkelteam of de Scrum Master.

Een Sprint wordt typisch afgebroken als het Sprint Doel achterhaald is geworden. Dit kan gebeuren als de organisatie van richting verandert of indien de markt- of technologieomstandigheden veranderen. In zijn algemeenheid zou een Sprint moeten worden afgebroken indien deze, gegeven de omstandigheden, niet zinvol meer is. Echter, gezien de korte looptijd van een Sprint, is het afbreken zeer zelden zinvol.

Indien een Sprint wordt afgebroken, worden Product Backlog items die “Klaar” zijn geïnspecteerd. Indien een deel van het werk potentieel uitleverbaar is zal de Product Owner dit normaal gesproken accepteren. Alle incomplete Product Backlog Items worden opnieuw ingeschat en terug op de Product Backlog gezet. Het werk dat reeds gedaan is voor deze items vermindert snel in waarde en moet frequent opnieuw worden ingeschat.

Sprints afbreken brengt kosten met zich mee, want iedereen moet hergroeperen in een nieuwe Sprint Planning om een nieuwe Sprint te starten. Het afbreken van een Sprint is vaak traumatisch voor het Scrum Team en komt zelden voor.

18.3.6.2 Sprint Planning

Het werk dat uitgevoerd moet worden tijdens een Sprint wordt gepland tijdens de Sprint Planning. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team.

De Sprint Planningsbijeenkomst heeft een timebox van acht uur voor een Sprint van één maand. Voor kortere Sprints is de bijeenkomst normaliter korter. De Scrum Master draagt er zorg voor dat deze gebeurtenis plaats vindt en dat de deelnemers het doel begrijpen. De Scrum Master leert het Scrum Team hoe ze de Planning binnen de timebox kunnen afronden.

Sprint Planning beantwoordt de volgende vragen:

• Wat kan worden geleverd in het resulterende Increment van de komende Sprint?

• Hoe wordt het benodigde werk om dit Increment te leveren behaald?

18.3.6.2.1 Onderwerp één: Wat kan worden gedaan deze Sprint?

In dit deel werkt het Ontwikkelteam aan een prognose van de functionaliteit die in deze Sprint ontwikkeld zal worden. De Product Owner bespreekt de beoogde doelstelling van deze Sprint en de

Product Backlog items welke, als ze worden gecompleteerd tijdens de Sprint, het Sprint Doel zullen vervullen. Het hele Scrum Team werkt samen om het werk van de Sprint te begrijpen.

De input voor deze bijeenkomst is de Product Backlog, het laatste product Increment, de verwachte capaciteit van het Ontwikkelteam gedurende de Sprint en de prestaties uit het verleden van het Ontwikkelteam. Het aantal items dat wordt geselecteerd van de Product Backlog is volledig aan het Ontwikkelteam. Alleen het Ontwikkelteam kan inschatte n wat zij kan bereiken binnen de aankomende Sprint.

Nadat het Ontwikkelteam een prognose heeft gegeven van de Product Backlog items die zij kunnen gaan leveren, formuleert het Scrum Team een Sprint Doel. Het Sprint Doel is een doelstelling die gedurende de Sprint bereikt zal worden middels het implementeren van de Product Backlog en geeft richting aan het Ontwikkelteam met betrekking tot het waarom van het bouwen van het Increment.

18.3.6.2.2 Onderwerp twee: Hoe zal het gekozen werk gedaan worden?

Na het Sprint Doel te hebben vastgesteld en het werk voor de Sprint te hebben geselecteerd, beslist het Ontwikkelteam hoe het deze functionaliteit realiseert tot een “Klaar” product Increment gedurende de Sprint. De voor de Sprint geselecteerde Product Backlog it ems plus het plan voor het leveren ervan wordt de Sprint Backlog genoemd.

Gebruikelijk is dat het Ontwikkelteam start met het ontwerpen van het systeem en het werk dat gedaan moet worden om de Product Backlog om te zetten in een werkend product Increment. Werk kan variëren in grootte of geschatte inspanning. Tijdens de Sprint Planningsbijeenkomst plant het Ontwikkelteam zodanig veel werk dat een voorspelling gedaan kan worden met betrekking tot wat het denkt te kunnen opleveren in de komende Sprint. Aan het einde van deze meeting heeft het team het werk voor de eerste dagen van de Sprint opgedeeld in onderdelen , vaak van één dag of kleiner. Het Ontwikkelteam organiseert zichzelf om het werk in de Sprint Backlog gedaan te krijgen, zowel gedurende de Sprint Planning als gedurende de Sprint.

De Product Owner mag helpen om de geselecteerde Product Backlog items verder te verduidelijken en om afwegingen te maken. Indien het Ontwikkelteam bepaalt dat er te veel of te weinig werk is, mag het team over de Sprint Backlog items opnieuw onderhandelen met de Product Owner. Het Ontwikkelteam mag ook andere mensen uitnodigen om advies te leveren op technisch vlak of over het domein.

Aan het einde van de Sprint Planningsbijeenkomst zou het Ontwikkelteam in staat moeten zijn om aan de Product Owner en Scrum Master uit te leggen hoe zij van plan zijn, als zelf organiserend team, het Sprintdoel te behalen en het verwachte Increment te realiseren.

18.3.6.3

Sprint Doel

Het Sprint Doel is een doelstelling die voor de sprint bepaald wo rdt, welke gehaald kan worden door Product Backlog te implementeren. Het geeft richting aan het Ontwikkelteam over waarom zij dit Increment bouwen. Het wordt opgesteld tijdens de Sprint Planning Meeting. Het Sprint Doel geeft het Ontwikkelteam de nodige flexibiliteit ten aanzien van de functionaliteit die geïmplementeerd wordt in de Sprint. De geselecteerde Product Backlog items leveren een samenhangende functie, wat het Sprint Doel kan zijn. Het Sprint Doel kan elke andere samenhang zijn die ervoor zorgt dat het Ontwikkelteam gaat samenwerken in plaats van aan verschilende initiatieven.

Tijdens het werken houdt het Ontwikkelteam het Sprint Doel in het oog. Functionaliteit en technologie worden geïmplementeerd om het Sprint Doel te bereiken. Indien het werk anders blijkt te zijn dan het Ontwikkelteam had verwacht, werken zij samen met de Product Owner om over de scope van de Sprint Backlog binnen deze Sprint te onderhandelen.

18.3.6.4 Dagelijkse Scrum

De Dagelijkse Scrum is een 15 -minuten-timeboxed gebeurtenis voor het Ontwikkelteam om activiteiten te synchroniseren en een plan te maken voor de komende 24 uur. Dit wordt gedaan door het werk sinds de laatste Dagelijkse Scrum te inspecteren en te voorspellen welk werk gedaan kan worden tot de volgende Dagelijkse Scrum.

De Dagelijkse Scrum wordt elke dag gehouden op dezelfde tijd en plaats om complexiteit te reduceren. Gedurende de bijeenkomst licht elk Ontwikkelteamlid het volgende toe:

• Wat heb ik gisteren gedaan wat het team heeft geholpen het Sprint Doel te bereiken?

• Wat ga ik vandaag doen om het team te helpen het Sprint Doel te bereiken?

• Zie ik enig obstakel die mij of het team in de weg staat het Sprint Doel te bereiken?

Het Ontwikkelteam gebruikt de Dagelijkse Scrum om te voortgang ten opzichte van het Sprint Doel te beoordelen en om te beoordelen hoe de trend is van het gedane werk ten opzichte van de Sprint Backlog. De Dagelijkse Scrum optimaliseert de waarschijnlijkheid dat het Ontwikkelteam het Sprint Doel behaalt. Elke dag moet het Ontwikkelteam begrijpen hoe zij samen gaan werken als zelforganiserend team om het Sprint Doel te behalen en hoe het verwachte Increment gerealiseerd te hebben aan het eind van de Sprint. Het Ontwikkelteam houdt regelmatig een bijeenkomst direct na de Dagelijkse Scrum voor gedetailleerde discussies, of om de rest van het werk in de Sprint aan te passen of te herplannen.

De Scrum Master zorgt ervoor dat het Ontwikkelteam de bijeenkomst houdt, maar het Ontwikkelteam zelf is verantwoordelijk voor het uitvoeren van de Dagelijkse Scrum. De Scrum Master leert het Ontwikkelteam om de Dagelijkse Scrum binnen de 15 -minuten-timebox te houden.

De Scrum Master dwingt de regel af dat alleen Ontwikkelteamleden participeren in de Dagelijkse Scrum. Dagelijkse Scrums verbeteren communicatie, elimineren andere bijeenkomsten, identificeren obstakels bij de ontwikkeling zodat die verwijderd kunnen worden, belichten en bevorderen het maken van snelle beslissingen en verbeteren het kennisniveau van het Ontwikkelteam. Dit is een zeer belangrijke inspectie- en aanpassingsbijeenkomst.

18.3.6.5

Sprint Review

Een Sprint Review wordt gehouden aan het einde van de Sprint om het Increment te inspecteren en indien nodig de Product Backlog aan te passen. Gedurende de Sprint Review bekijken het Scrum Team en de belanghebbenden samen wat er bereikt is gedurende de Sprint.Op basis hiervan en op basis van veranderingen in de Product Backlog, werken de aanwezigen samen aan de volgende stappen die genomen kunnen worden om waarde te optimaliseren. Dit is een informele

bijeenkomst, geen status meeting, en de presentatie van het Increment heeft als doel feedback te verzamelen en samenwerking te bevorderen.

Dit is een vier-uur-timebox bijeenkomst bij Sprints van één maand. Over het algemeen wordt er minder tijd gebruikt bij kortere sprints. De Scrum Master draagt er zorg voor dat de gebeurtenis plaatsvindt en dat de aanwezigen het doel begrijpen. De Scrum Master leert iedereen om het binnen de timebox te houden.

De Sprint Review omvat de volgende elementen:

• De aanwezigen zijn het Scrum Team en belangrijke belanghebbenden die worden uitgenodigd door de Product Owner.

• De Product Owner legt uit welke Product Backlog items “Klaar” zijn en wat er niet “Klaar” is.

• Het Ontwikkelteam bespreekt wat er goed ging gedurende de Sprint, welke problemen ze zijn tegengekomen en hoe deze problemen werden opgelost.

• Het Ontwikkelteam demonstreert het werk dat “Klaar” is en beantwoordt vragen over het Increment.

• De Product Owner bespreekt de Product Backlog zoals deze nu is. Hij of zij projecteert waarschijnlijke data van completering op basis van de voortgang tot nu toe (als nodig);

• De gehele groep werkt samen aan wat er vervolgens gemaakt gaat worden, zodat de Sprint Review waardevolle input levert voor de komende Sprint Planningsbijeenkomst.

• Een beoordeling van wijzigingen in de markt of in potentieel gebruik van het product kunnen beïnvloeden wat het meest waardevolle is om vervolgens te doen.

• Een overzicht van de tijdlijn, budget, potentiele mogelijkheden, en markt voor de volgende verwachte ingebruikname van het product.

Het resultaat van de Sprint Review is een herziene Product Backlog welke de waarschijnlijke Product Backlog items voor de volgende Sprint definieert. De Product Backlog kan ook worden aangepast om nieuwe kansen te kunnen omarmen.

18.3.6.6 Sprint Retrospective

De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.

De Sprint Retrospective vindt plaats na de Sprint Review en vóór de volgende Sprint Planning. Dit is een drie-uur-timebox bijeenkomst voor Sprints van één maand. Over het algemeen wordt minder tijd gepland voor kortere sprints. De Scrum Master draagt er zorg voor dat de gebeurtenis plaatsvindt en dat de aanwezigen het doel begrijpen. De Scrum Master leert iedereen om het binnen de timebox te houden. De Scrum Master neemt deel als een gelijkwaardig teamlid aan de bijeenkomst vanuit zijn verantwoordelijkheid voor het Scrum proces.

Het doel van de Sprint Retrospective is om:

• Te inspecteren hoe de laatste Sprint is gegaan met betrekking tot mensen, relaties, processen en tools.

• Dingen die goed gingen en potentiële verbeteringen te identificeren en te ordenen.

• Een plan te creëren om verbeteringen op de manier waarop het Scrum Team zijn werk doet te implementeren.

De Scrum Master moedigt het Scrum Team aan om, binnen het Scrum proces raamwerk, hun ontwikkelproces en practices te verbeteren, om het team effectiever en plezieriger te maken voor de volgende Sprint. Gedurende elke Sprint Retrospective plant het Scrum Team manieren om de kwaliteit van het product te verhogen door zo nodig de definitie van “Klaar” aan te passen.

Tegen het einde van de Sprint Retrospective zou het Scrum Team verbete ringen moeten hebben benoemd die geïmplementeerd zullen worden in de volgende Sprint. Het implementeren van deze verbeteringen in de volgende Sprint is de aanpassing naar aanleiding van de inspectie van het Scrum Team zelf. Alhoewel verbeteringen altijd geïmplementeerd mogen worden, biedt de Sprint Retrospective een formeel moment gericht op inspectie en aanpassing.

18.3.7 Scrum Artefacten

De artefacten van Scrum vertegenwoordigen werk of waarde die transparantie bieden en mogelijkheden tot inspectie en adaptie. De artefacten die Scrum definieert zijn specifiek ontworpen voor maximale transparantie van sleutelinformatie zodat iedereen hetzelfde begrip heeft van het artefact.

18.3.7.1 Product Backlog

De Product Backlog is een geordende lijst van alles dat mogelijk nodig i s in het product, en is de enige bron van requirements voor elke wijziging die aan het product gemaakt moeten worden. De Product Owner is verantwoordelijk voor de Product Backlog, inclusief de inhoud, beschikbaarheid en ordening.

Een Product Backlog is nooit compleet. De eerste versies ervan bevatten alleen de initieel bekende en best begrepen requirements. De Product Backlog ontwikkelt zich net zoals het product en de omgeving waarin het gebruikt gaat worden zich verder ontwikkelen. De Product Backlog is dynamisch: hij verandert voortdurend om duidelijk te maken wat het product nodig heeft om passend, concurrerend en bruikbaar te zijn. Zolang het product bestaat, bestaat de bijbehorende Product Backlog ook.

De Product Backlog somt alle kenmerken, functies, requirements, verbeteringen en foutherstel op die gezamenlijk de wijzigingen zijn die in toekomstige releases aan het product gemaakt moeten worden. Product Backlog items hebben als kenmerken een beschrijving, ordening, een schatting en een waarde.

Vanaf het moment dat het product gebruikt wordt en waarde oplevert, en de markt terugkoppeling levert, wordt de Product Backlog een grotere en meer uitputtende lijst. Requirements blijven altijd veranderen, en dus is de Product Backlog een levend artefact. Veranderingen in bedrijfseisen, marktomstandigheden of technologieën kunnen veranderingen in de Product Backlog tot gevolg hebben.

Meerdere Scrum Teams werken vaak samen aan hetzelfde product. Één Product Backlog wordt gebruikt om het aankomende werk op het product te beschrijven. Er wordt dan mogelijk een Product Backlog attribuut gebruikt om items te groeperen.

Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog Refinement worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner en naar de Product Owner’s eigen beoordeling.

Product Backlog items met een hogere rangorde zijn normaliter duidelijker en meer gedetailleerd dan die met een lagere rangorde. De schattingen zijn meer precies vanwege de hogere mate van duidelijkheid en detaillering. Hoe lager de rangorde, hoe minder details. De Product Backlog items waarmee het Ontwikkelteam de komende Sprint aan de slag gaat zijn zo ver verfijnd dat elk item “Klaar” kan zijn binnen een Sprint. De Product Backlog items die door het Ontwikkelteam “Klaar” kunnen zijn binnen een Sprint worden beschouwd als “Ready” voor selectie in een Sprint Planningsbijeenkomst. Product Backlog items verkrijgen deze mate van transparantie over het algemeen door de verfijningsactiviteiten die hierboven beschreven staan.

Het Ontwikkelteam is verantwoordelijk voor alle schattingen. De Product Owner mag het Ontwikkelteam beïnvloeden door te helpen bij het begrijpen en maken van afwegingen, maar de mensen die het werk moeten doen maken de uiteindelijke schatting.

18.3.7.1.1 Controle op de voortgang tot een doel

Op elk moment in de tijd kan het totale werk, dat nog nodig is om een doel te bereiken, worden opgeteld. De Product Owner houdt de totale resterende hoeveelheid werk bij, op zijn minst elke Sprint Review. De Product Owner vergelijkt dit totaal met de resterende totale hoeveelheid werk uit eerdere Sprint Reviews om een inschatting te maken of het resterende werk binnen de gewenste tijd kan zijn afgerond voor het gestelde doel. Deze informatie wordt transparant gemaakt voor alle stakeholders.

Verschillende voorspel-technieken voor trendanalyse: burndown, burnup en andere predictiemethoden zijn gebruikt om voortgang te voorspellen. Deze zijn nuttig gebleken. Echter, ze vervangen niet het belang van empirisme. In complexe omgevingen is niet bekend wat er in de toekomst gaat gebeuren. Alleen wat er is gebeurd mag gebruikt worden vo or toekomstgerichte besluitvorming.

18.3.7.2

Sprint Backlog

De Sprint Backlog is de verzameling Product Backlog items geselecteerd voor de Sprint inclusief het plan voor opleveren van het product Increment en voor realisatie van het Sprint Doel. De Sprint Backlog is een voorspelling door het Ontwikkelteam over de functionaliteit die aanwezig zal zijn in het volgende Increment en het werk dat nodig is om die functionaliteit te leveren in een “Klaar” Increment.

De Sprint Backlog maakt al het werk zichtbaar dat het Ontwikkelteam heeft geïdentificeerd als noodzakelijk voor behalen van het Sprint Doel.

De Sprint Backlog is een plan met voldoende detail zodat veranderingen in de voortgang begrepen kunnen worden in de Dagelijkse Scrum. Het Ontwikkelteam past de Sprint Backlog gedurende de Sprint aan, en de Sprint Backlog ontwikkelt zich gedurende de Sprint. Deze ontwikkeling gebeurt als

het Ontwikkelteam het plan afwerkt en meer leert over het werk dat nodig is om het Sprintdoel te halen.

Als er nieuw werk nodig is voegt het Ontwikkelteam dat toe aan de Sprint Backlog. Wanneer werk wordt uitgevoerd of afgerond wordt de schatting van het resterende werk bijgesteld. Als onderdelen van het plan overbodig blijken, worden ze verwijderd. Alleen het Ontwikkelteam kan haar Sprint Backlog bijwerken gedurende een Sprint. De Sprint Backlog is een zeer zichtbaar, real-time beeld van het werk dat het Ontwikkelteam van plan is te doen gedurende de Sprint, en het behoort uitsluitend toe aan het Ontwikkelteam.

18.3.7.2.1 Controle op Sprint voortgang

Op elk moment in de Sprint kan de totaal resterende hoeveelheid werk voor de Sprint Backlog items worden opgeteld. Het Ontwikkelteam houdt dit totaal minstens voor elke Dagelijkse Scrum bij om de waarschijnlijkheid van het halen van het Sprintdoel te projecteren. Door het bijhouden van de resterende hoeveelheid werk gedurende de Sprint kan het Ontwikkelteam haar voortgang bewaken.

18.3.7.3 Imcrement

Het Imcrement is het totaal van alle Product Backlog items voltooid tijdens een Sprint en de opgeleverde waarde van de Imcrements van alle voorgaande Sprints. Aan het eind van een Sprint moet het nieuwe Increment “Klaar” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Klaar” gebruikt door het Scrum Team. Het moet in bruikbar e conditie zijn ongeacht of de Product Owner daadwerkelijk besluit het te in gebruik te nemen.

18.3.7.4 Artefact Transparantie

Scrum is afhankelijk van transparantie. Beslissingen die genomen worden om de waarde te optimaliseren en risico’s te beheersen, worden genomen op basis van de waargenomen toestand van de artefacten. Voorzover de transparantie compleet is, hebben deze beslissingen een goede basis. Als de artefacts niet geheel transparant zijn, kunnen deze beslissingen verkeerd zijn, neemt waarde af en neemt risico toe.

De Scrum Master werkt met de Product Owner, het Ontwikkelteam, en andere betrokken partijen om duidelijk te krijgen of de artefacten volledig transparant zijn. Er zijn practices voor het omgaan met onvolledige transparantie; de Scrum Master moet iedereen helpen om de meest toepasselijke practices te gebruiken in geval van absentie van volledige transparantie. Een Scrum Master kan onvolledige transparantie detecteren door de artefacten te inspecteren, patronen te herkennen, nauwkeurig te luisteren en verschillen te vinden tussen verwachte en echte resultaten.

Het is de taak van de Scrum Master om met het Scrum Team en de organisatie de transparantie van de artefacten de vergroten. Dit werk behelst meestal leren, overtuigen en verandering. Transparantie zal niet plotsklaps plaatsvinden; het is een traject.

18.3.8 Definitie van “Klaar” (Definition of “Done”)

Indien een Product Backlog item wordt omschreven als “Klaar”, moet iedereen begrijpen wat “Klaar” betekent. Hoewel dit significant verschilt per Scrum Team, moeten de teamleden een gezamenlijk begrip hebben wat het betekent om het werk af te hebben, om transparantie te kunnen garanderen. Deze “Definitie van Klaar” (“Definition of Done”) voor het Scrum Team wordt gebruikt om te controleren wanneer het werk voor een product Increment klaar is.

Dezelfde definitie helpt het Ontwikkelteam te bepalen hoeveel Product Backlog items zij kunnen selecteren tijdens de Sprint Planning. Het doel van elke Sprint is om Incrementen va n potentieel opleverbare functionaliteit te leveren die voldoen aan de huidige Definitie van “Klaar” van het Scrum Team.

Ontwikkelteams leveren elke Sprint een Increment van product functionaliteit . Dit Increment is bruikbaar, zodat een Product Owner kan besluiten dit onmiddellijk in gebruik te nemen. Als de ontwikkelorganisatie al een Definitie van “Klaar” heeft als conventie, standaard of richtlijn, zullen alle Scrum Teams deze tenminste moeten volgen. Als de ontwikkelorganisatie nog geen Definitie van “Klaar” heeft als conventie, standaard of richtlijn, zal het Ontwikkelteam van het Scrum Team zelf een Definitie van “Klaar” moeten definieren die geschikt is voor het product.Als er meerde Scrum Teams werken aan hetzelfde systeem of productrelease, moete n de Ontwikkelteams van alle Scrum Teams gezamenlijk de Definitie van “Klaar” definieren.

Elk Increment is additief aan alle voorgaande Incrementen en grondig getest zodat wordt gegarandeerd dat alle Incrementen samen werken.

Naarmate Scrum Teams meer volwassen worden, is de verwachting dat hun Definitie van “Klaar” uitgebreid wordt met striktere criteria ten behoeve van een hogere kwaliteit. Elk product of systeem zou een Definitie van “Klaar” moeten hebben die als standaard geldt voor elk werk wat eraa n gedaan wordt.

18.4 Devops

Alles evolueert vandaag steeds sneller. Bestaande toepassingen moeten voortdurend aangepast worden, in een steeds hoger tempo. Vaak echter ontstaat er een bottleneck tussen developers en het operationele team. De DevOps-aanpak kan dit verhelpen.

18.4.1 Hoe ontstond de DevOps aanpak?

Meer dan een methodologie bij het ontwikkelen van software is DevOps een cultuur, die nodig is om te kunnen beantwoorden aan de huidige behoeften van bedrijven bij het ontwikkelen van toepassingen - websites, applicaties en meer.

Bij het traditionele waterval-model waren de vereisten voor een software op voorhand duidelijk en vastomlijnd. De definitie van het product zelf was ook stabiel. De developers codeerden de software, en de operationele teams moesten die dan implementeren, ten uitvoer brengen op de bedrijfssystemen of het web.

Maar de IT-wereld evolueert steeds sneller. De vereisten veranderen vaak, en ook het ontwikkelen van de software moet steeds sneller gaan. Software en webapplicaties moet en niet alleen sneller op de markt gebracht worden, maar ook voortdurend aangepast kunnen worden. Nieuwe features moeten naadloos toegevoegd kunnen worden, inmiddels ontdekte bugs moeten opgelost worden. Dit leidde tot het Agile Development model.

Het is echter niet alleen het team ontwikkelaars dat snel en wendbaar moet reageren, ook het operationele team, dat de nieuwe toepassingen moet uitrollen en monitoren. Dit leidt op zijn beurt tot de DevOps aanpak. Velen associëren deze term met een nauwere samenwe rking tussen de ontwikkelaars, de bedenkers van een product, en de ops, het operationele team dat zorgt voor de release, het uitrollen, het opereren en monitoren van de software.

Maar DevOps is veel meer - het is een 'state of mind', een gezamenlijke aanpak van een probleem.

Een aanpak die verder gaat dan het puur technische, een aanpak waarbij alle geledingen van het bedrijf betrokken worden, ook financiën en marketing, en waarbij communicatie levensnoodzakelijk is.

Iedereen, van developer tot sysadmin, de mensen die het netwerk beheren, de business analysts: zij behoren voortaan tot hetzelfde team. Zij hebben een gemeenschappelijk doel: het welslagen van het héle project, niet enkel van hun onderdeel.

18.4.2 Wat zijn de principes van de DevOps aanpak?

Communicatie tussen developers en het operationele team is cruciaal. De traditionele silo's tussen ontwikkelaars, testers, release managers en sysadmins worden afgebroken. Zij werken nauwer samen, tijdens het hele proces van zowel ontwikkelen als uitrollen, waardoo r zij meer inzicht krijgen in elkaars uitdagingen en vragen.

Ontwikkelaars bijvoorbeeld denken meer na over operaties, bronnen, uptime, betrouwbaarheid. Zij kunnen bijvoorbeeld switches inbouwen waarmee ops teams functies kunnen aan/uitzetten, bepaalde mogelijkheden uitschakelen bij piekverkeer, enz. De ops teams staan de ontwikkelaars bij door snelle testen mogelijk te maken en te monitoren, enz.

De Devops aanpak vereist dan ook mensen met multidisciplinaire vaardigheden. Die zowel met infrastructuur en configuratie vertrouwd zijn, maar evengoed testen willen uitvoeren en software debuggen. Devops zijn bruggenbouwers, die in alle kampen een pijler hebben staan. Zij zijn, in de woorden van Stephen Nelson-Smith "ambassadeurs, vredestichters, facilitators en communicatoren".

Wanneer het hele projectteam agile is, kan code voor bijvoorbeeld een nieuwe feature of bugfix snel in productie gebracht worden, en indien nodig teruggedraaid worden. Hoe kleiner de stap tussen opeenvolgende versies, hoe kleiner de impact van een eventueel falen: de "fail fast, fail cheap" benadering. Hierdoor kunnen bedrijven regelmatig innoveren - wat vooral voor online bedrijven belangrijk is. Amazon zou zelfs elke 2 seconden nieuwe code implementeren of wijzigen!

De DevOps aanpak heeft gevolgen voor de hele delivery pipeline van een project, waaronder:

• Snellere time to market

• Lager faalpercentage bij nieuwe releases

• Kortere lead time tussen fixes

• Kortere tijd voor herstel (als een nieuwe release crasht)

18.4.3 Wat houdt DevOps in?

Deze illustratie van de DevOps-manier van werken is het symbool voor oneindigheid, of liever: continu werkzaamheid. DevOps houdt in:

• Continu ontwikkelen

• Continu testen

• Continu integreren

• Continu implementeren

• Continu monitoren

In de DevOps levenscyclus ga je van het plan-stadium naar het monitoringstadium en altijd maar terug. Het blauwe deel verwijst naar de ontwikkelfase, het gele gedeelte naar het operationele gedeelte, maar door de steeds weerkerende wisselwerking vloeien beiden ineen.

De DevOps Agile Skills Association heeft 6 principes vooropgezet bij het uitbouwen van een DevOps strategie:

1. Klantgericht werken, met korte feedback periodes gegeven door échte klanten en eindgebruikers.

2. Geen waterval model waar iedere afdeling apart werkt, zonder overzicht, maar een bedrijf waar iedereen de engineering mindset deelt om een werkend product te maken.

3. Verticaal georganiseerde teams die aansprakelijk zijn 'from concept to grave'.

4. All-round profielen, werkend in autonome teams waar zij zich persoonlijk kunnen ontwikkelen.

5. Voortdurende optimalisatie op vlak van snelheid, kost en het product/dienst zelf.

6. Automatisering van alles wat geautomatiseerd kan worden, ook de infrastructuur, door bijvoorbeeld next-gen container gebaseerde cloudplatformen (infrastructure as code).

18.4.4 Welke technologie heb je nodig voor DevOps?

Docker en Kubernetes - tools voor DevOps. De populariteit van DevOps is de jongste jaren hand in hand gegaan met de komst van nieuwe technologische tools, die je manier van werken compleet veranderen. Dat geldt zowel voor ontwikkeling als voor Operations.

Door een betere, permanente afstemming tussen de ontwikkeling en de infrastructuur, schrijven ontwikkelaars niet langer een specifieke versie voor een specifieke hardware - of infrastructuurconfiguratie. Ze rollen continu nieuwe versies uit dankzij CI/CD (continuous integration / continuous deployment), met tools zoals GitLab, Jenkins…

Wie constant nieuwe versies uitrolt, moet aan de infrastructuurkant beschikken over duidelijke procedures en maximale automatisering. Dat kan met container-technologie zoals Docker, of een automatiseringsplatform zoals Kubernetes. Wie zich zuiver wil richten op software -ontwikkeling, en het infrastructuurbeheer liever kwijt dan rijk is, kan zelfs kiezen voor ‘serverless’ en ‘Function-as-aService’ (FAAS).

18.4.5 Wat zijn de voordelen van de DevOps aanpak?

Uiteraard is op menselijk gebied de mentaliteitswijziging het grote voordeel. De DevOps aanpak leidt tot grotere empathie tussen de teamleden, het maakt een einde aan de 'us and them' silo's van mensen die wantrouwig, soms zelfs angstig tegenover elkaar staan.

Wat de DevOps aanpak op zakelijk gebied concreet oplevert, wordt duidelijk in het rapport 'Puppet's State of DevOps'. Dit jaarlijkse rapport vergelijkt bedrijven die DevOps praktijken toepassen (hoogpresterende of HP-organisaties) met bedrijven die het goed doen op vlak van implementatie van het product, loyaliteit van het personeel, beveiliging, enz. Uit het rapport 2016 blijkt:

• IT-performantie: HP-organisaties implementeren 200 keer sneller, met 2.555 snellere lead tijd. Zij hebben een 24 keer snellere recovery tijd en een 3 keer lager falen bij wijziging.

• Loyaliteit van het personeel : medewerkers in HP-organisaties zijn 2,2 keer meer geneigd om hun organisatie aan te bevelen als een goede werkgever.

• Tijdgebruik: 22% minder tijd gespendeerd aan ongepland werk of het overdoen van werk bij HP-organisaties. Zo kan 29% meer tijd besteed worden aan nieuw werk zoals nieuwe functies.

• Veiligheid: 50% minder tijd vereist om beveiligingsprobleme n op te lossen doordat de informatie over beveiligingsdoelstellingen beter in het dagelijkse werk geïntegreerd is.

18.4.6 DevOps: hoe begin je eraan?

Een DevOps cultuur ontwikkelen vraagt planning. Deze tips kunnen je helpen bij het ontwikkelen van een DevOps mindset:

• Denk na over hoe jij wil dat jouw webteam functioneert over 12 -18 maanden.

• Bekijk je huidige werkprocessen en vraag jezelf (en je team!) af waar het stroef loopt, waar er risico's zijn.

• Laat je teams hun zeg doen: hoe denken zij dat de processen realistisch verbeterd kunnen worden? Wat denken zij ervan om ops op dev projecten te zetten?

• Ga na wie van de bestaande medewerkers nieuwe skills wil leren.

• Aarzel niet om je conclusies en je plan te delen met andere afdelingen: cross-functionele teams kunnen in je hele organisatie ingevoerd worden om de efficiency te verbeteren!

• Ga bij nieuwe aanwervingen doelbewust voor DevOps, met cross -functionele skills, en bied hen de mogelijkheid zich verder te bekwamen.

18.4.7 Is een DevOps aanpak iets voor iedereen?

DevOps is een prachtige aanpak voor (online) bedrijven die voortdurend innoveren. Voor hen wordt de 'time to market' beduidend verkort, wat een groot financieel voordeel oplevert.

Maar verkeert jouw bedrijf niet in dat geval, dan zal de DevOps aanpak de samenhang tussen je medewerkers uiteraard verbeteren, maar zal je bedrijf wellicht ook zonder deze cultuur wel kunnen overleven. Indien de enige in-house gemaakte applicatie enkel dient om de aanwezigheid op vergaderingen te noteren of om de verlofdagen te plannen, dan heeft die niet elke dag een update nodig!

18.5 Projectinitiatie

18.5.1 Inleiding

De eerste stap in een willekeurig nieuw project is altijd dat iemand - een manager, personeelslid, vertegenwoordiger of systeemanalist - een mogelijkheid ziet om de bedrijfsvoering te verbeteren. Praktisch altijd ligt een zakelijke behoefte of winstmogelijkheid aan een nieuw systeem ten grondslag. Veel ideeën voor nieuwe systemen of verbeteringen van bestaande systemen zijn weliswaar het natuurlijke gevolg van de opkomst van een nieuwe technologie, maar niettemin is

kennis van de technologie gewoonlijk ondergeschikt aan een gedegen inzicht in de gang van zaken en doelstellingen van het bedrijf.

Wellicht vindt u dit de gewoonste zaak van de wereld. Toch wor den veel projecten helaas opgestart zonder helder voor ogen te hebben hoe het systeem het reilen en zeilen van het bedrijf zal verbeteren. In de IT-branche circuleren ontelbare toverwoorden, modegrillen en trends (bijvoorbeeld klantgerichtheid, smartphones, data mining). Wat deze innovaties beloven, kan dermate aantrekkelijk lijken dat bedrijven met een bepaalde technologie in zee gaan, zelfs als ze niet weten welke waarde zo'n stap voorwaarts heeft, omdat ze menen dat de technologie in kwestie op zichzelf al waardevol zal zijn. Uit een onderzoek van de Standard Group in 1996 bleek dat met 42% van alle onderzochte commerciële IT-projecten voortijdig was gestopt. Een vergelijkbare studie van het General Accounting Office bracht aan het licht dat 53% van alle Amerikaanse overheidsprojecten nooit was voltooid. In de meerderheid van de gevallen konden de problemen worden herleid tot de allereerste stappen van de SDLC, waarin te weinig aandacht was geschonken aan de waarde voor het bedrijf en de risico's die aan het project waren verbonden.

Betekent dit dat nieuwe systeemprojecten niet door technici moeten worden aangedragen?

Natuurlijk niet. Idealiter werken IT-mensen (oftewel de systeemexperts) en de zakenlui (oftewel de experts op commercieel gebied) in de praktijk nauw samen bij het zoeken naar manieren om zakelijke behoeften door nieuwe technologieën te laten ondersteunen. Op die manier kunnen bedrijven en organisaties profijt trekken van de opwindende nieuwe technologieën die beschikbaar komen, terwijl ze er tegelijkertijd zeker van zijn dat de projecten op echte commerciële behoeften (bijvoorbeeld een stijging van de omzet, een verbeterde klantenservice of lagere bedrijfskosten) zijn gestoeld. Uiteindelijk moeten informatiesystemen de winst van het bedrijf (uiteraard positief) beïnvloeden.

Globaal gesproken is een project een verzameling activiteiten met een begin- en een eindpunt, en is het bedoeld om een systeem te creëren dat voor het bedrijf van waarde is. Projectinitiatie vangt aan wanneer iemand (of een groep) binnen de organisatie (de zogenoemde projectsponsor) commerciële mogelijkheden ziet die met behulp van een nieuwe technologie kunnen worden gerealiseerd. Het voorgestelde project wordt bondig geformuleerd via een techniek die de systeemaanvraag word t genoemd. De systeemaanvraag wordt aan een commissie ter goedkeuring aangeboden. De commissie evalueert de systeemaanvraag en neemt op basis van de verstrekte informatie een voorlopig besluit om het voorstel al dan niet te laten uitwerken. Na goedkeuring is een haalbaarheidsanalyse de volgende stap.

De haalbaarheidsanalyse speelt een belangrijke rol bij de beslissing om een IT -ontwikkelproject al dan niet te continueren. De technische, economische en organisatorische voor- en nadelen van de systeemontwikkeling worden tegen elkaar afgewogen, waardoor het bedrijf een iets gedetailleerdere indruk krijgt, zowel van de baten van de investering in het systeem als van mogelijke hinderpalen die zich kunnen voordoen. Meestal werkt de projectsponsor samen met een ana list (of een team analisten) om de haalbaarheidsanalyse ten behoeve van de commissie te ontwikkelen.

Zodra de haalbaarheidsanalyse is voltooid, wordt deze tezamen met de herziene systeemaanvraag aan de goedkeuringscommissie overhandigd. Vervolgens beslist de commissie of het systeem moet

worden goedgekeurd, afgekeurd of op de plank gelegd tot er aanvullende informatie beschikbaar is.

Projecten worden geselecteerd nadat de risico's tegen de winstgevende aspecten zijn afgewogen en er bovendien op organisatorisch niveau een keuze is gemaakt.

18.5.2 Projectidentificatie

Van identificatie van een project is sprake wanneer iemand in het bedrijf een commerciële behoefte ontdekt om een systeem te bouwen. De aandrager van het idee kan een afdeling zijn, de IT, een commissie die met het zoeken naar commerciële mogelijkheden is belast of een aanbeveling van een extern adviesbureau. Voorbeelden van behoeften zijn de ondersteuning van een nieuwe marketingcampagne, het aanboren van een nieuwe groep consumenten of een verbeterin g van de interactie met leveranciers. Soms zijn behoeften het gevolg van 'pijnpunten' binnen een bedrijf, zoals een krimpend marktaandeel, een slechte klantenservice of toegenomen concurrentie. Op andere momenten worden nieuwe strategieën bedacht of nieuwe initiatieven op commercieel gebied ondernomen en is er een systeem nodig om die doelen te kunnen verwezenlijken.

Behoeften kunnen eveneens opduiken wanneer het bedrijf unieke en concurrerende mogelijkheden ziet om van IT gebruik te maken. Veel bedrijven houden nieuwe technologieën (en dan met name technologieën die zich nog in het ontwikkelstadium bevinden en nog niet op grote schaal in het bedrijfsleven worden gebruikt) nauwlettend in het oog. Als een bedrijf bijvoorbeeld voorop wil lopen op het gebied van internet, smartphones of IOT, zal het strategieën ontwikkelen waarbij de mogelijkheden van deze technologieën worden uitgebuit en zal men hun producten als eerste op de markt proberen te brengen. Idealiter kunnen ze van deze pionierstrategie profiteren door winst te maken en te blijven innoveren terwijl de concurrentie achterblijft. De projectsponsor is iemand die de sterke behoefte aan een systeem inziet en er belang bij heeft dat het systeem zal slagen. Hij of zij ziet erop toe dat het project vanuit zakelijk oogpunt in de goede richting verloopt. De projectsponsor is voor het systeem het primaire aanspreekpunt. Gewoonlijk is de projectsponsor iemand van de marketing- of boekhoudafdeling, al fungeren mensen van de ITafdeling ook regelmatig als sponsor o f medesponsor van een project.

Het benodigde type sponsor wordt bepaald door de omvang of de reikwijdte van het project. Voor een klein systeem op afdelingsniveau is wellicht een enkele manager als sponsor voldoende, terwijl voor een groot initiatief op bedrijfsniveau ondersteuning van het volledige managementteam nodig is. Als een project puur technisch van aard is (bijvoorbeeld verbetering van de bestaande ITinfrastructuur of onderzoek naar de mogelijke waarde van een nieuwe technologie), komt sponsoring vanuit de IT in aanmerking. Als projecten niet alleen voor het bedrijf van groot belang worden geacht, maar ook technisch ingewikkeld zijn, is gezamenlijke sponsoring door zowel het bedrijf als de IT geboden.

De behoefte vormt de basis voor de globale eis en aan het systeem worden gesteld. Die eisen omvatten wat het informatiesysteem zal doen of welke functionaliteit het zal leveren. Dit moet op globaal niveau worden geformuleerd, en wel zodanig dat de goedkeuringscommissie (en vervolgens

het projectteam) begrijpt wat het bedrijf van het eindproduct verwacht. De eisen beschrijven welke functies en mogelijkheden het informatiesysteem moet bevatten, zoals de mogelijkheid voor klanten om online bestellingen te doen of de mogelijkheid om leveranciers voorraadinformatie te verstrekken wanneer bestellingen worden geplaatst en handelscontracten worden gesloten.

De projectsponsor moet bovendien een indruk hebben van de waarde die het systeem zal toevoegen, zowel de grijpbare (concrete) als de ongrijpbare waarde. Grijpbare waarde kan gemakkelijk worden gekwantificeerd en gemeten (bijvoorbeeld een vermindering van de operationele kosten met 2%). Een ongrijpbare waarde hangt daarentegen samen met een intuïtieve overtuiging dat het systeem het bedrijf een belangrijk maar moeilijk te meten voordeel zal opleveren, zoals een verbeterde klantenservice of een gunstiger concurrentiepositie.

Zodra de projectsponsor een project identificeert dat een belangrijke behoefte kan bevredigen, kan hij of zij de eisen en de waarde voor het bedrijf bepalen en het project vervolgens formeel initiëren. In de meeste bedrijven vangt de projectinitiatie aan met een procedure die de projectaanvraag wordt genoemd.

18.5.2.1 De projectaanvraag

Een projectaanvraag is een document waarin de zakelijke redenen om een project te gaan doen en de verwachte baten daarvan worden beschreven. Gewoonlijk stelt de projectsponsor dit document op als onderdeel van, de formele selectieprocedure van een systeemproject binnen het bedrijf. De meeste projectaanvragen bevatten de volgende vijf onderdelen: de projectsponsor, de behoefte, de eisen, de waarde en speciale onderdelen . De sponsor is de persoon die als belangrijkste contactpersoon voor het project zal fungeren. terwi jl de behoefte de reden voor het project is. De eisen van het project hebben betrekking op de mogelijkheden die het systeem dient te hebben. De waarde ten slotte verwijst naar de baten die het bedrijf van het systeem kan verwachten. Speciale onderwerpen maken deel uit van het document als vergaarbak voor alle andere informatie die bij het project in aanmerking dient te worden genomen. Zo kan er bijvoorbeeld worden afgesproken dat het project vóór een bepaalde deadline moet zijn voltooid.

Projectteams dienen zich bewust te zijn van eventuele speciale omstandigheden die van invloed kunnen zijn op wat het systeem uiteindelijk zal opleveren.

Onderdeel

Projectsponsor

Toelichting Voorbeelden

Diegene die het project initieert en die voor de onderneming als belangrijkste contactpersoon fungeert

• Een aantal leden van de financiële afdeling

• Hoofd van de marketingafdeling

• IT-manager

Behoefte De (zakelijke) reden om het project te initiëren

• Stuur commissie

• Directeur

• Stijging van de omzet

• Groter marktaandeel

• Verbeterde toegang tot informatie

• Minder producten met gebreken

• Stroomlijning van de aanvoer van grondstoffen

Eisen De (zakelijke) mogelijkheden die het project zal leveren

Waarde De voordelen die het project het bedrijf zal opleveren

Speciale onderwerpen of beperkingen

Kwesties die voor de implementatie van het project en de besluitvorming ten aanzien van het project relevant zijn

• Online toegang tot informatie

• Vastleggen van demografische klanten informatie

• Mogelijkheden verruimen om producten op te zoeken

• Productie van management verslagen

• Online gebruikers ondersteuning

• 3 % omzetstijging

• 1 % begroting van marktaandeel

• Personeelsinkrimping met vijf FTE’s

• Besparing van € 200.000 op de leveringskosten

• Besparing van € 150.000 doordat het huidige systeem vervalt

• Door de overheid opgelegde deadline van 31 maart

• Systeem moet werken voordat het komende wintervakantieseizoen begint

• Beveiliging van topniveau nodig voor het projectteam dat met gegevens gaat werken

De voltooide projectaanvraag wordt aan een goedkeuringscommissie overhandigd. Deze goedkeuringscommissie is bijvoorbeeld een bedrijfsstuurcommissie die regelmatig vergadert om besluiten over informatiesystemen te nemen, een senior executive die over bedrijfsbronnen kan beschikken of een ander besluitvormingsorgaan dat de toewijzing van investeringen regelt. De commissie bekijkt de aanvraag en neemt op grond van de verstrekte informatie een voorlopig besluit om het voorstel al dan niet goed te keuren. Na goedkeuring volgt als volgende stap een haalbaarheidsanalyse.

18.5.3 Haalbaarheidsanalyse

Zodra de behoefte aan het project en de bijbehorende eisen zijn vastgesteld, is het moment gekomen om een gedetailleerdere use-case te ontwikkelen om meer inzicht te krijgen in de mogelijkheden en beperkingen van het voorgestelde project. Aan de hand van een haalbaarheidsanalyse kan een bedrijf besluiten of het al dan niet met het project doorgaat. Een haalbaarheidsanalyse stelt ook de belangrijke risico's vast die aan het project verbonden zijn en die in aanmerking moeten worden genomen als het project wordt goedgekeurd. Net zoals bij de projectaanvraag het geval is, heeft elk bedrijf weer zijn eigen procedures en formules voor een haalbaarheidsanalyse, maar de meeste analyses bevatten drie onderdelen: de technische haalbaarheid, de economische haalbaarheid en de organisatorische haalbaarheid. De resultaten van deze analyses worden gerapporteerd in een haalbaarheidsonderzoek dat aan het eind van de initiatie fase aan de goedkeuringscommissie wordt overhandigd.

Hoewel de haalbaarheidsanalyse nu in het kader van de projectinitiatie zal worden besproken, zullen de meeste projectteams hun haalbaarheidsonderzoek in de loop van het project reviseren en de inhoud op bepaalde momenten opnieuw bestuderen. Als de risico's en de beperkingen van het project op een bepaald moment zwaarder gaan wegen dan de voordelen, kan het projectteam besluiten het project te annuleren of noodzakelijke verbeteringen aan te brengen.

18.5.3.1 Technische haalbaarheid

De eerste methode in de haalbaarheidsanalyse is de technische haalbaarheid van het project, oftewel de mate waarin het systeem met succes door de IT -afdeling kan worden ontworpen, ontwikkeld en geïnstalleerd. In essentie is technische haalbaarheid een technische risicoanalyse die de vraag “Zijn we in staat om het te bouwen?” probeer t te beantwoorden. Er zijn tal van risico's die een geslaagde voltooiing van het project kunnen hinderen . De belangrijkste factor is wel de vertrouwdheid met de toepassing van gebruikers en analisten. Als analisten niet met de toepassing bekend zijn, is de kans groter dat ze de gebruikers verkeerd begrijpen of kansen missen om het bestaande systeem te verbeteren. Dit risico neemt bovendien sterk toe als de gebruikers zelf niet met de toepassing vertrouwd zijn, bijvoorbeeld wanneer een systeem wordt ontwikkeld om een nieuwe commerciële omgeving te ondersteunen (bijvoorbeeld Microsoft die een

nieuwe Internet dating service opstart). In het algemeen is een nieuw systeem ontwikkelen riskanter dan een bestaand systeem uitbreiden, omdat men in een bestaand systeem vaak meer inzicht heeft.

Vertrouwdheid met de technologie is een andere belangrijke bron van technisch risico. Wanneer een systeem gebruik zal maken van een technologie die binnen het bedrijf nog niet eerder werd gebruikt, is de kans op problemen en vertragingen groter vanwege de noodzaak om de technologie te leren gebruiken. Dat risico neemt dramatisch toe als de technologie zelf ook nieuw is (bijvoorbeeld een nieuwe Java-ontwikkeltoolkit).

De projectomvang is een belangrijke factor die gekwantificeerd k an worden aan de hand van het aantal mensen in het ontwikkelteam, de tijdsduur die nodig wordt geacht om het project te voltooien of het aantal functies dat het gewenste systeem moet bieden. Hoe groter het project is, des te groter de uitdaging wordt, enerzijds omdat grotere projecten moeilijker te beheren zijn, anderzijds omdat er een grotere kans bestaat dat een belangrijke systeemeis over het hoofd wordt gezien of niet goed wordt begrepen. De mate waarin het project met andere systemen geïntegreerd is (wat kenmerkend is voor grote systemen), kan eveneens gemakkelijk tot problemen leiden, aangezien de complexiteit toeneemt als veel systemen moeten samenwerken.

Ten slotte moeten projectteams de compatibiliteit van het nieuwe systeem met de in het bedrijf al bestaande systemen in het oog houden. Systemen worden zelden in een vacuum gebouwd; men voegt ze veeleer toe aan een bestaande situatie waarin al tal van systemen om tal van redenen worden gebruikt. Nieuwe technologieën en toepassingen moeten veelal in he t bestaande omgeving worden geïntegreerd. Ze maken bijvoorbeeld gebruik gegevens van bestaande systemen of moeten gegevens leveren aan andere systemen, of zijn aangewezen op de in het bedrijf aanwezige infrastrucuur. Zo zal een nieuw CRM-systeem slechts weinig waarde hebben als het niet gebruikmaakt van de klantgegevens die in bestaande verkoopsystemen, marketingtoepassingen en klantenservicesystemen van het bedrijf worden gebruikt. Vaststellen van de technische haalbaarheid van een project is geen eenvoudig karwei, omdat in veel gevallen onderliggende condities moeten worden geïnterpreteerd (bijvoorbeeld: hoe groot moet een project worden om technisch haalbaar te zijn?) Een mogelijke aanpak is om het onderhevige project te vergelijken met eerdere projecten die in het bedrijf werden uitgevoerd. IT-mensen in het bedrijf of externe adviseurs raadplegen is een andere optie; vaak zullen deze mensen kunnen beoordelen of een project in technisch opzicht haalbaar is.

18.5.3.2 Economische haalbaarheid

Het tweede onderdeel van een haalbaarheidsanalyse is de economische haalbaarheidsanalyse (ook wel een kosten-batenanalyse genoemd), waarin de financiële risico's van het project worden vastgesteld. Deze analyse probeert antwoord te geven op de vraag: moete n we het systeem bouwen? Economische haalbaarheid wordt bepaald door de kosten en baten van het systeem na te gaan, deze kosten en baten te kwantificeren en vervolgens het batig saldo en het investeringsrendement van het project te berekenen. Hoe kostbaarder het project is, des te

rigoureuzer en gedetailleerder de analyse zal worden uitgevoerd. In de volgende paragrafen zullen alle stappen uitvoerig worden beschreven.

Bepaal kosten en baten

Wijs waarden aan de kosten en baten toe

Bepaal de cash-flow

Bepaalde netto huidige waarde

Bepaal het rendement van de investering

Bereken het break-even punt

Geef het break-evenpunt grafisch weer

18.5.3.2.1 Kosten en baten bepalen

Maak een lijst van de grijpbare kosten en baten van het project. Raam zowel de eenmalige als de jaarlijks terugkerende kosten

Werk samen met zakelijke gebruikers en IT professionals om alle kosten en baten in getallen uit te drukken. Kwantificeer zo mogelijk ook ongrijpbare kosten en baten

Bepaal hoe de kasgeldenstroom er over een tijdsperiode gewoonlijk 3-5 jaar uitziet. Hou zo nodig rekening met groei.

Bereken wat de waarden van de toekomstige kosten en baten op basis van de huidige normen zullen zijn. U dient een groei te specificeren om de NHW-formule te kunnen toepassen

Bereken met behulp hoeveel geld het bedrijf zal binnen vloeien in ruil voor de investering die het heeft gedaan

Bepaal het eerste jaar waarin de baten van het systeem groter zullen uitvallen dan de kosten. Pas de breakevenformule toe met behulp van de cijfers van dat jaar. U weet dan hoe lang het zal duren voordat het systeem het bedrijf echt winst oplevert

Visualiseert de jaarlijkse kosten en baten in een lijn die. Het break-evenpunt is het punt waar de lijnen elkaar kruisen

De eerste stap bij de ontwikkeling van een economische haalbaarheidsanalyse is het bepalen van de typen kosten en baten die aan het systeem verbonden zijn. Plaats ze in de linkerkolom van een spreadsheet.

De kosten en baten kunnen worden onderverdeeld in vier categorieën: (1) ontwikkelkosten, (2) operationele kosten, (3) grijpbare baten en (4) ongrijpbare baten. Ontwikkelkosten zijn de grijpbare uitgaven die tijdens het project moeten worden gedaan, zoals het salaris van het projectteam, kosten van hardware en software, adviseurskosten en kosten van opleiding, bedrijfsruimte en apparatuur. Ontwikkelkosten worden gewoonlijk als eenmalige kosten beschouwd. Operationele kosten zijn de grijpbare kosten die gemoeid zijn met het draaiend houden van het systeem, zoals het salaris van de operator(s), kosten van softwarelicenties, upgrades van de apparatuur en verbindingskosten. Operationele kosten worden gewoonlijk als terugkerende kosten beschouwd.

Winsten en kostenbesparingen zijn grijpbare baten die het systeem het bedrijf oplevert of grijpbare kosten die het bedrijf kan vermijden doordat het systeem wordt gebruikt. Tot grijpbare baten behoren bijvoorbeeld eer stijging van de omzet, personeelsinkrimping of een vermindering van de voorraad.

Uiteraard kan een project ook invloed hebben op een bedrijf via ongrijpbare baten of ongrijpbare kosten. Ongrijpbare kosten en baten zijn moeilijker in de economische haalbaarheidsanalyse te verwerken, omdat ze niet op harde cijfers maar op intuïtie en overtuiging zijn gebaseerd. Niettemin dienen ze te samen met de grijpbare kosten en baten in de spreadsheet te worden opgenomen.

Ontwikkel kosten

Salaris van het team

Honorarium van adviseurs

Opleiding van ontwikkelteamleden

Hardware en software

Installatiekosten

Bedrijfsruimte en bedrijfsapparatuur

Kosten van gegevensconversie

Grijpbare baten

Omzetstijging

Minder personeel nodig

Minder voorraad nodig

Lagere IT-kosten

Lagere prijzen van grondstoffen

Operationele kosten

Upgrades van software

Kosten van softwarelicenties

Reparaties van hardware

Upgrades van hardware

Salaris van het operatorsteam

Kosten van verbindingen

Opleiding van de gebruikers

Ongrijpbare baten

Groter marktaandeel

Grotere naamsbekendheid

Producten van hoge kwaliteit

Verbeterde klantenservice

Betere relaties met leveranciers

18.5.3.2.2 Waarden aan de kosten en baten toewijzen

Zodra de typen kosten en baten zijn vastgesteld, zult u ze in specifieke bedragen moeten uitdrukken. Dit lijkt soms ondoenlijk, want hoe kan iemand kosten en baten aangeven die nog moeten komen?

En hoe kan men daar reële voorspellingen over doen? Hoewel dit inderdaad een erg lastige taak is, zult u alle moeite moeten doen om redelijke getallen aan alle kosten en baten toe te kennen. Pas dan kan de goedkeuringscommissie een zinnige beslissing nemen over het al dan niet voorzetten van het project.

De beste werkwijze om kosten en baten te schatten, is op de mensen te vertrouwen die er het meeste inzicht in hebben. Zo kunnen kosten en baten die aan de technologie of het project zelf verbonden zijn, door de IT-afdeling van het bedrijf of door externe adviseurs worden geraamd, terwijl commerciële gebruikers commerciële aspecten kunnen berekenen (bijvoorbeeld de geraamde omzet, omvang van bestellingen). Verder kunt u projecten uit het verleden, brancherapporten en leveranciersinformatie raadplegen, hoewel een dergelijke aanpak waarschijnlijk minder nauwkeurige resultaten zal opleveren. Waarschijnlijk zullen alle schattingen in de loop van het project moeten worden bijgesteld.

Hoe is het gesteld met de ongrijpbare kosten en baten? Soms is het voldoende om ongrijpbaar voordeel slechts te vermelden zonder een bedrag te noemen (bijvoorbeeld verbeterde klantenservice), maar in de meeste projecten dient toch te worden geschat hoeveel een ongrijpbaar voordeel.waard' is. Wij raden u om ongrijpbare baten te specificeren wanneer dat -maar enigszins mogelijk is. Als u dat niet doet, hebt u geen manier om erachter te komen of u ze hebt gerealiseerd. Stel dat een project de klantenservice moet verbeteren. Dit is ongrijpbaar, maar laten we veronderstellen dat het aantal klachten van klanten de komende drie jaar dankzij de verbeterde service elk jaar met tien procent terugloopt en dat er 200.000 euro wordt uitgegeven aan telefoonkosten en personeel dat de klachten moet verwerken. We hebben dan plotseling de beschikking over uiterst grijpbare getallen waarmee we een doelstelling kunnen formuleren en het aanvankelijke ongrijpbare voordeel kunnen kwantificeren.

Ontwikkel kosten

kosten

18.5.3.2.3 Batig saldo bepalen

Een formele kosten-batenanalyse bevat meestal de kosten en baten met betrekking tot een aantal jaren (gewoonlijk drie tot vijf jaar) om het batig saldo in de loop van de tijd aan te geven. Bij zo ’n batig saldo methode worden de jaren bovenaan in de spreadsheet gezet om de geanalyseerde tijdsperiode aan te duiden, terwijl de geldbedragen in de desbetreffende cellen van de spreadsheet worden geplaatst. Soms worden in de kolommen vaste bedragen vermeld. Gewoonlijk worden de cijfers met een bepaald groeipercentage opgehoogd om voor inflatie of verbeterde bedrijfsvoering te corrigeren, zoals wordt aangegeven door de 6%-toename die in de voorbeeldspreadsheet aan de omzetcijfers werd toegevoegd. Ten slotte wordt het totaal berekend om te bepalen hoeveel de baten globaal bedragen. Hoe hoger het totaal, des te haalbaarder het project in economisch opzicht zal zijn.

ongrijpbare baten

(629.421/2.575.331)

Deze service wordt momenteel door de concurrenten aangeboden Grotere tevredenheid van klanten

18.5.3.2.4 Break-evenpunt bepalen

Als het projectteam een rigoureuze kosten-batenanalyse moet opstellen, kan het nodig zijn informatie te verstrekken over het moment waarop de opbrengst van het project evenveel bedraagt als de investering. Hoe langer het duurt om het break-evenpunt te bereiken, des te riskanter het project is. Het break-evenpunt wordt bepaald door naar het batig saldo over de jaren heen te kijken en het jaar te bepalen waarin de baten meer bedragen dan de kosten . Vervolgens worden de jaarlijkse en cumulatieve NHW van dat jaar gedeeld door de jaarlijkse NHW om te bepalen op welk tijdstip in dat jaar het break-evenpunt zal worden bereikt.

Het break-evenpunt kan ook grafisch worden weergegeven. De cumulatieve huidige waarde van de kosten en baten van elk jaar worden in een lijndiagram getekend. Het punt waar de vinnen elkaar kruisen, is het break-evenpunt.

18.5.3.3 Organisatorische haalbaarheid

Het bepalen van de organisatorische haalbaarheid van het systeem is een derde onderdeel van een haalbaarheidsanalyse. Hoe goed zal het systeem uiteindelijk door zijn gebruikers worden

geaccepteerd en in de dagelijkse gang van zaken in het bedrijf worden opgenomen? Doorgewinterde ontwikkelaars weten maar al te goed dat organisatorische haalbaarheid het lastigste aspect is om mee om te gaan, aangezien er veel organisatorische factoren zijn die een project kunnen beïnvloeden. In wezen probeert een organisatorische haalbaarheidsanalyse antwoord te geven op de vraag: Als we het bouwen, zullen ze het dan gebruiken?'

Een manier om de organisatorische haalbaarheid van het project vast te stellen, is om na te gaan hoe goed de doelstellingen van het project sporen met de doestellingen van het bedrijf. Strategische afstemming is de mate waarin de strategie van het project en het bedrijf overeenkomen. Hoe mee r overeenstemming te minder riskant het project vanuit organisatorisch gezichtspunt zal zijn. Stel dat de marketingafdeling besluit om klantgerichter te werken. In zo'n geval zou een CRM -project dat geïntegreerde klantinformatie produceert, strategisch ste rk op de doelstelling van de marketingafdeling zijn afgestemd. Veel IT-projecten mislukken wanneer de IT-afdeling zelf deze projecten initieert, want in zo'n geval is er vaak geen afstemming op de commerciële of organisatorische strategieën van het bedrijf

Een tweede manier om de organisatorische haalbaarheid te bepalen is om een belanghebbendenanalyse uit te voeren.' Een belanghebbende is een persoon, groep of organisatie die door het nieuwe systeem zal worden beïnvloed. In het algemeen zijn de projectvoo rvechters, de systeemgebruikers en de bedrijfsleiding bij de introductie van een nieuw systeem de belangrijkste belanghebbenden, maar soms zijn er nog andere groepen bij betrokken. Zo kan de afdeling informatiesystemen een belanghebbende zijn, aangezien de taken van het personeel van die afdeling na de implementatie aanzienlijk zullen veranderen. Afgezien van de voorvechters, de gebruikers en de directie was het Amerikaanse ministerie van Justitie een belangrijke belanghebbende bij een project van Microsoft waarbij Internet Explorer als standaardonderdeel in Windows werd opgenomen.

Rol

Voorvechter

Bedrijfsmanagers

• Initieert het project

• Prijst het project aan

• Besteedt zijn tijd aan het project

• Verschaft hulpbronnen

• Hebben kennis van het project

• Stellen voldoende geld voor het project beschikbaar

Technieken voor verbetering

• Verzorgt een presentatie over de doelstellingen van het project

• Maakt een prototype van het systeem om de potentiële waarde ervan te demonstreren

• Verzorgen een presentatie voor de directie over de doelstellingen van het project en de verwachte baten

Systeem gebruikers

• Moedigen gebruikers aan het systeem te accepteren en te gebruiken

• Nemen beslissingen die op het project van invloed zijn

• Nemen deel aan testfasen van het project

• Bepalen uiteindelijk of het systeem succes geeft door het systeem al dan niet daadwerkelijk te gebruiken

• Prijzen de voordelen van het systeem aan

• Moedigen de voorvechter aan om met zijn collega’s over het project te praten

• Geven gebruikers officiële rollen in het project

• Geven gebruikers specifieke opdrachten met een duidelijke Deadline

• Vragen gebruikers regelmatig om feedback

• (bijvoorbeeld tijdens wekelijkse vergaderingen)

De voorvechter is een leidinggevend persoon van de afdeling informatiesystemen, gewoonlijk (maar niet altijd) de projectsponsor die het projectvoorstel heeft geschreven. De voorvechter ondersteunt het project door tijd en bronnen (bijvoorbeeld geld) te investeren en invloed binnen het bedrijf uit te oefenen door andere leidinggevenden te doordringen van het belang van het systeem. De voorkeur gaat uit naar twee of meer voorvechters, want zou de voorvechter bij het bedrijf weggaan, dan zou de ondersteuning eveneens wegvallen.

Terwijl voorvechters het systeem dagelijks steunen, moet de bedrijfsleiding het project eveneens ondersteunen. Deze steun moet de overige bedrijfsmedewerkers duidelijk maken dat het systeem een waardevolle bijdrage kan leveren en dat de benodigde hulpbronnen beschikbaar zullen zijn. Idealiter moedigt de bedrijfsleiding mensen in het bedrijf aan om het systeem te gebruiken en de vele wijzigingen te accepteren die het systeem waarschijnlijk met zich zal meebrengen.

Een derde belangrijke groep belanghebbenden zijn de systeemgebruikers die uiteindelijk na de installatie met het systeem zullen werken. Maar al te vaak vergadert het projectteam met de gebruikers aan het begin van het project, om vervolgens te verdwijnen en pas weer op te duiken op het moment dat het systeem wordt geïnstalleerd. In zo'n geval voldoet het eindproduct zelden aan de verwachtingen van degenen die ermee moeten werken, aangezien behoeften onderhevig zijn aan veranderingen en gebruikers in de loop van het project slimmer worden. Tijdens het hele ontwikkelproject dient de deelname van gebruikers aangemoedigd te worden door hen actief aan de ontwikkeling van het systeem te laten deelnemen (bijvoorbeeld dam taken uit te voeren, feedback te geven of besluiten te nemen).

Het haalbaarheidsonderzoek als geheel helpt bedrijven om wijzer te investeren in systeemprojecten, aangezien het projectteam wordt gedwongen rekening te houden met de technische, economische en organisatorische factoren die van invloed kunnen zijn op de voortgang van het project. Het beschermt IT-mensen tegen kritiek doordat de commerciële afdelingen van de besluiten op de hoogte worden gehouden en bij de besluitvorming een cruciale rol spelen. Onthoud dat de haalbaarheidsanalyse tijdens het project verscheidene malen herzien dient te worden, en wel op de momenten waarop het projectteam belangrijke besluiten over het systeem neemt (bijvoorbeeld voordat de ontwerpfase begint). De analyse kan dienen als ondersteuning en verklaring van de elementaire keuzes die worden gemaakt.

18.5.4

Projectselectie

Zodra de haalbaarheidsanalyse is voltooid, wordt deze samen met een herziene projectaanvraag aan de goedkeuringscommissie overhandigd. De commissie besluit vervolgens het project goed te keuren, af te wijzen of uit te stellen totdat aanvullende informatie beschikbaar is. Op projectniveau evalueert de commissie de waarde van het project door de behoeften (zoals geformuleerd in de projectaanvraag) te bezien en de risico’s van de bouw (zoals beschreven in de haalbaarheidsanalyse) in overweging te nemen.

Alvorens het project goed te keuren, bekijkt de commissie het project ook vanuit organisatorisch oogpunt. Daarbij speelt een rol welke projecten het bedrijf momenteel in portefeuille heeft. Deze manier om projecten te beheren wordt portfoliobeheer genoemd. Bij portfoliobeheer wordt gekeken naar de verschillende typen projecten die momenteel in een bedrijf bestaan (groot, klein, riskant, betrekkelijk risicoloos, strategisch en tactisch). Een goede project portfolio bestaat uit de juiste mix van projecten in het licht van behoeften van het bedrijf. De commissie fungeert als portfoliobeheerder en geeft tot doel de kosten-baten verhouding en andere belangrijke aspecten van projecten te maximaliseren. Een bedrijf wil bijvoorbeeld niet meer dan een vijfde gedeelte van zijn projectportfolio spenderen aan projecten met hoog risico.

De goedkeuringscommissie moet selectief zijn ten aanzien van de hulpbronnen, aangezien het bedrijf over beperkte geldmiddelen beschikt. Dit result eert in een afweging van belangen waarbij het bedrijf soms een project moet opgeven in ruil voor iets anders teneinde het evenwicht in de portfolio te handhaven. Als er bijvoorbeeld drie projecten met een potentieel hoog rendement zijn, kan mogelijk slechts één project worden geselecteerd. Verder zijn er gevallen denkbaar waarbij een systeem aantrekkelijk lijkt op projectniveau, maar niet op organisatorisch niveau. Zodoende kan een project een hoog investeringsrendement beloven en aan belangrijke behoeften van een gedeelte van het bedrijf voldoen, maar toch niet worden geselecteerd. Hiervoor kunnen tal van redenen zijn: het bedrijf beschikt niet over het budget om nog een systeem te financieren, het bedrijf staat op het punt een fusie aan te gaan, er wordt binnenkort een ander bedrijfssysteem geïmplementeerd dat aan dezelfde behoeften kan voldoen of het systeem strookt niet geheel met de huidige of toekomstige strategie van het bedrijf.

Omvang Hoe omvangrijk is het project? Hoeveel mensen moeten aan het proje ct gaan werken?

Kosten Hoeveel kost het project het bedrijf?

Doel Wat is het doel van het project? Heeft het als doel de technische infrastructuur te verbeteren? Om een huidige commerciële strategie te ondersteunen? Om werkzaamheden te stroomlijnen? Om een nieuwe innovatie te demonstreren?

Lengte Hoelang duurt het project voor dat het voltooid is? Hoe lang duurt het voor dat het systeem het bedrijf winst zal opleveren?

Risico Hoe groot is de kans dat het project zal slagen? Mislukken?

Reikwijdte Welk onderdeel van het bedrijf wordt door het systeem beïnvloed? Een afdeling? Een divisie? Het hele bedrijf?

Investerings rendement

Hoeveel geld verwacht het bedrijf te ontvangen in ruil voor het bedrag van de projectkosten?

18.6 Projectbeheer

In dit hoofdstuk worden de belangrijke projectbeheer stappen beschreven. Dit begint in de planningfase. Om te beginnen schat de projectmanager de omvang van het project en bepaalt hij de taken die moeten worden uitgevoerd. Vervolgens bemant hij het project en start hij een aantal activiteiten op die het werk aan het project moeten helpen coördineren. Deze stappen produceren belangrijke tastbare resultaten, waaronder het werkplan, het bemanningsplan en een lijst met standaarden.

Leerdoelen :

• vertrouwd raken met schattingen;

• in staat zijn om een werkplan voor een project op te stellen

• begrijpen waarom projectteams gebruikmaken van tijdvakken

• weten hoe u een project kunt bemannen

18.6.1 Inleiding

Neem eens een van de grote projecten in gedachten die zich in een mensenleven voordoen, zoals een eindexamenfeest of een bruiloftsfeest. Al maanden van tevoren worden er taken vas tgesteld, verdeeld en uitgevoerd zoals uitnodigingen versturen of een geschikte locatie selecteren. Tijd en geld worden zorgvuldig besteed. Het hele traject door worden er besluit genomen, problemen aangepakt en veranderingen aangebracht. De toenemende populariteit van de organisator van het feest, iemand wiens enige taak het is om een feestje in goede banen te leiden, geeft aan hoe lastig dat karwei wel is. Uiteindelijk hangt het succes van een willekeurig feest voo r een groot deel af van de moeite die er in de planning werd gestoken.

Systeemprojecten zijn vaak heel wat ingewikkelder dan de projecten die we in ons eigen leven starten, want gewoonlijk zijn er meer mensen bij be trokken (bijvoorbeeld het bedrijf), zijn de kosten hoger en moeten er meer taken worden uitgevoerd. Daarom zult u niet verbaasd zijn te horen dat er ook 'feestorganisatoren' (projectmanagers geheten) voor informatiesysteem projecten bestaan.

Projectbeheer is het proces waarbij de ontwikkeling van een systeem met de juiste functionaliteit binnen een bepaalde periode en tegen minimale kosten wordt gepland en geregeld. De projectmanager is de hoofdverantwoordelijke voor het beheren van honderden taken en rollen die zorgvuldig moeten worden gecoördineerd. Tegenwoordig is projectmanager een beroep en werken analisten jarenlang aan allerlei projecten voordat ze projectmanager worden. In 2019 bleek uit een onderzoek van Computerworld dat meer de helft van de ondervraagde bedrijven meldde dat ze ITprojectteams nu een formele opleiding in projectbeheer gaven. Daarnaast is er een gevarieerd assortiment projectbeheersoftware beschikbaar (Microsoft Proje ct,Plan View en PMOffice zijn er voorbeelden van) die projectbeheer activiteiten ondersteunen. Hoewel er opleidingen en softwarepakketten beschikbaar zijn om projectmanagers bij te staan, wordt het beheren van een project moeilijk als er door projectsponsors en bedrijfsmanagers onredelijke eisen worden gesteld. Maar al te vaak worden projectmanagers vanwege het naderende vakantieseizoen, de kans om een voorstel met een laag bod binnen te halen of de druk van een plotselinge financieringsmogelijkheid min of meer verplicht een project afleveringsdatum te beloven die ze niet kunnen waarmaken. Zo'n overduidelijk te optimistisch tijdschema wordt als een van de grootste problemen beschouwd waarmee projecten te maken hebben, want in plaats van een project sneller voort te stuwen, leiden ze tot vertragingen.

Een essentiële succesfactor bij projectbeheer is derhalve dat wordt begonnen met een realistische inschatting van het werk dat moet worden verricht, waarna de projectmanager het project in overeenstemming met die inschatting gaat beheren. Dit kan worden verwezenlijkt door de vier stappen, zorgvuldig op te volgen: bepaal de projectomvang, creëer en beheer een werkplan, beman het project en coördineer de projectactiviteiten. De projectmanager stelt uiteindelijk een werkplan, een bemanningsplan en een lijst standaarden op, die naderhand -hele het hele project door worden verfijnd.

18.6.2 De omvang van het project bepalen '

Bij projectbeheer is het de kunst om de volgende belangrijke zaken tegen elkaar af te wegen: de omvang van het systeem (in termen van wat het aan functionaliteit biedt), de tijd die nodig is om het project te voltooien (wanneer het project gereed is) en de kosten van het project.

Beschouw deze drie aspecten als drie van elkaar afhankelijke schuifregelaars die de projectmanager gedurende het hele project bijregelt. Wanneer de ene schuifregelaar wordt versteld, worden de standen van de twee andere schuifregelaars daardoor ook beïnvloed. Als de projectmanager bijvoorbeeld een deadline naar een vroeger tijdstip moet verplaatsen, heeft hij geen andere keu s dan de omvang van het project te verkleinen (door een of meer functies te schrappen) of de kosten te verhogen (door meer mensen toe te voegen of ze te laten overwerken). Vaak zal een projectmanager de doelstellingen van het project in overleg met de proj ectsponsor moeten wijzigen, bijvoorbeeld door een systeem met minder functionaliteit te ontwikkelen of de deadline van een systeem naar een later tijdstip te verplaatsen om het project redelijke en haalbare doelen te verschaffen.

Daarom moet de manager in het begin van het project elk van deze drie schuifregelaars schatten en vervolgens voortdurend inschatten hoe het project zodanig moet worden gestuurd dat het aan de behoeften van het bedrijf voldoet. Schatten is het proces waarbij voorspelde waarden aan tijd en arbeid worden toegekend. De schattingen die aan het begin van een project worden gedaan, zijn gewoonlijk gebaseerd op een bereik van mogelijke waarden (geschat wordt bijvoorbeeld dat de ontwerpfase drie tot vier maanden in beslag zal nemen) en worden geleidelijk specifieker naarmate het project voortschrijdt (bijvoorbeeld: de ontwerpfase zal naar verwachting op 22 maart zijn voltooid).

De getallen die als uitgangspunt voor deze schattingen dienen, kunnen uit verschillende bronnen afkomstig zijn. Ze kunnen worden geleverd door de gebruikte technologie of door ervaren IT’ers worden aangedragen. In het algemeen dienen de getallen aan de conservatieve kant te zijn. Een goede werkwijze is de feitelijke tijd en arbeid in de loop van het project bij te ho uden, zodat de getallen naderhand kunnen worden bijgesteld en het volgende project gebruik kan maken van echte getallen. Een van de sterkste punten van systemen die de diensten van een consultant inroepen, is dat deze kan bogen op ervaring met projecten. Consultants beschikken over schattingen en methodologieën die hun waarde in de loop der jaren hebben bewezen en op honderden projecten zijn toegepast.

18.6.3 Het werkplan opstellen en beheren

Zodra een projectmanager een globale indruk van de omvang en het tijdschema van een project heeft gekregen, stelt hij een werkplan op, een dynamisch schema waarin alle taken die in de loop van een project moeten worden uitgevoerd, worden vastgelegd en bijgehouden. Behalve de taakomschrijvingen bevat het werkplan belangrijke informatie over wanneer een taak voltooid moet zijn, de persoon aan wie de taak is toegewezen en eventuele tastbare resultaten die de taak moet opleveren. De mate van gedetailleerdheid en de hoeveelheid informatie in het werkplan is afhankelijk van het project in kwestie (en zal gewoonlijk in de loop van het project toenemen).

Gewoonlijk is het werkplan het belangrijkste component van de projectbeheer software die we al eerder noemden.

Teneinde een werkplan te creëren bepaalt de projectmanager om te beginnen welke taken moeten worden uitgevoerd en hoeveel tijd met elke taak gemoeid is. Vervolgens worden de taken binnen een werkplan gerangschikt en door middel van een Gannt-diagram of PERT-diagram grafisch weergegeven. Al deze methoden, die in de volgende paragrafen zullen worden besproken, helpen de projectmanager inzicht te krijgen in de voortgang van een project en deze voortgang te leiden.

18.6.3.1

Taken bepalen

De globale eisen voor het project kunnen in de projectaanvraag worden gevonden. Het is vervolgens de taak van de projectmanager om alle taken te bepalen die moeten worden uitgevoerd om de doelstellingen van het project te halen. Dit klinkt als een hopeloze taak , want hoe kan iemand weten wat er allemaal moet worden gedaan om een project tedoendat nog nooit tevoren is gedaan?

Een manier om taken vast te stellen is om een lijst van reeds ontwikkelde taken ter hand te nemen en deze lijst aan te passen. Er bestaan standaard takenlijsten oftewel methodologieën die als vertrekpunt kunnen dienen. Een projectmanager kan een bestaande methodologie gebruiken, de stappen en tastbare resultaten kiezen die op het huidige project van toepassing zijn en ze aan het werkplan toevoegen. Als er binnen het bedrijf geen bestaande methodologie voorhanden is, kunnen methodologieën bij adviseurs of bedrijven worden aangeschaft, hoewel ook boeken als leidraad kunnen dienen. Gebruikmaken van een bestaande methodologie is de meest geliefde manier om een werkplan te ontwikkelen, aangezien de meeste bedrijven een methodologie in huis hebben die ze voor projecten gebruiken.

Als een projectmanager er de voorkeur aan geeft om van het begin af aan te starten, kan hij een gestructureerde top-down aanpak hanteren, waarbij hij eerst de globale taken omschrijft en ze daarna ze in subtaken opsplitst. Als voorbeeld ziet u een lijst van globale taken die verricht moeten worden om een nieuwe IT-opleidingscursus te implementeren. Tot de belangrijkste stappen in het proces behoren het bepalen van de leveranciers, het opstellen en afnemen van een vragenlijst en de bouw van een nieuw klaslokaal. Een stap wordt eventueel in substappen opgesplitst en op een

hiërarchische manier genummerd. Zo bestaat het opstelle n en afnemen van een vragenlijst uit acht subtaken en zijn er drie subtaken die tezamen de evaluatie van de oorspronkelijke vragenlijst uitmaken. Een takenlijst die op deze manier hiërarchisch is genummerd, wordt een werkopsplitsingsstructuur genoemd en vormt de ruggengraat van het projectwerkplan.

Het aantal taken en de gedetailleerdheid van die taken hangen af van de complexiteit en de omvang van het project. Hoe groter het project is, des te belangrijker het is om taken zo gedetailleerd mogelijk te omschrijven om essentiële stappen niet over het hoofd te zien.

18.6.3.2 Het projectwerkplan

Het projectwerkplan wordt gebruikt om de taken de beheren waarin het werk is opgesplitst. Het is het belangrijkste middel waarmee de projectmanager het project beheert. Aan de hand van het projectwerkplan kan de projectmanager zien of het project voor ligt of achter ligt op het schema, hoe goed het project werd geschat en welke wijzigingen er nodig zijn om ervoor te zorgen dat de deadline wordt gehaald.

In wezen is het werkplan een tabel met een opsomming van alle taken waarin het werk is opgesplitst, plus belangrijke taakinformatie, zoals de mensen die de taken moeten uitvoeren, de feitelijke uren die aan de taak werden besteed en het verschil tussen de geschatte en de daadwerkelijke duur van

de taken (zie figuur ). Op zijn minst moet de informatie bestaan uit de duur van de taak, de huidige status van de taken (bijvoorbeeld open, bezig, voltooid) en de afhankelijkheden van de taken. Van taakafhankelijkheid is sprake als een bepaalde taak pas kan worden uitgevoerd nadat een andere taak is voltooid. Zo meldt de figuur dat de taak Wijzigingen aan de vragenlijst aanbrengen (taak 7.4) een week zal duren, maar pas uitgevoerd kan worden nadat de vragenlijst is geëvalueerd (taak 7 .2) en via een pilot is getest (taak 7.3). Belangrijke mijlpalen, oftewel belangrijke datums, worden in het werkplan eveneens aangegeven. Presentatie van het project aan de goedkeuringscommissie, de begindatum waarop met de opleiding van eindgebruikers wordt begonnen en de leveringsdatum van een systeemprototype zijn mijlpalen die belangrijk zijn om in het werkplan te vermelden.

18.6.3.3 Gannt-diagram

Een Gannt-diagram is een horizontale staafgrafiek die dezelfde taakinformatie toont als het projectwerkplan, maar dan op grafische wijze. Soms zegt een plaatje werkelijk meer dan duizend woorden; in elk geval kan een Gannt-diagram de globale status van een project veel sneller en gemakkelijk weergeven dan een werkplan. Een Gannt-diagram maken is eenvoudig : u kunt het doen met een spreadsheetprogramma, met grafische software (bijvoorbeeld Microsoft Visio) of met een projectbeheerpakket. Elke taak wordt in de tabel op een afzonderlijke rij vermeld, terwijl de tijd aan de bovenzijde van de tabel wordt weergegeven in eenheden die voor het project relevant zijn. Een kort project kan worden onderverdeeld in uren of dagen, terwijl voor een project van gemiddelde grootte een onderverdeling in weken of maanden wenselijk kan zijn. Horizontale balken representeren de duur van elke taak, waarbij het begin en het eind van elke balk precies aanduiden waar de desbetreffende taak moet beginnen en eindigen. Terwijl mensen aan hun taken werken, worden de desbetreffende balken ingekleurd om pro portioneel aan te geven welk gedeelte van de taak is voltooid. Te veel taken in een Gannt -diagram kunnen verwarrend werken, zodat u het aantal taken het best tot twintig of dertig kunt beperken. Als er meer taken zijn, splitst u op ze in subtaken en maakt u een Gannt-diagram voor elk niveau.

Uit een Gannt-diagram kunnen projectmanagers een heleboel zaken snel opmaken. Behalve dat het duidelijk is hoe lang taken duren en hoe ver ze zijn gevorderd, is het ook helder welke taken achtereenvolgens en welke taken tegelijkertijd worden uitgevoerd, en welke taken elkaar gedeeltelijk overlappen. Een projectmanager kan in een oogwenk zien welke taken op het tijdschema vooruitlopen of achterlopen door vanuit de huidige datum een verticale lijn te trekken. Als een horizontale balk niet is ingekleurd en zich links van de lijn bevindt, is de taak in kwestie achter op het schema. In een Gannt-diagram worden vaak enkele speciale symbolen gebruikt. Mijlpalen worden aangegeven door middel van omgekeerde driehoekjes of ruiten, terwijl pijlen tussen de taken taakafhankelijkheden aanduiden. Soms worden de namen van de verantwoordelijke mensen naast de taakbalken vermeld om aan te geven wie er met de uitvoering van de desbetreffende taak zijn belast.

18.6.3.4 PERT -diagram

Een tweede grafische manier om de informatie over het projectwerkplan inzichtelijk te maken is het

PERT-diagram waarin de taken in de vorm van een stroomdiagram worden weergegeven. Elke taak wordt gerepresenteerd door een rechthoek (ook wel een node genoemd), terwijl de afhankelijkheid van twee taken wordt aangeduid door een lijn die twee rechthoeken met elkaar verbindt. Gewo onlijk worden gedeeltelijk afgeronde taken door een diagonale lijn in de rechthoek aangeduid, terwijl twee kruisende lijnen een geheel voltooide taak aangeven. Mijlpaaltaken worden opvallender gemaakt; in onderstaande figuur is dit gedaan door ze van een dikke rand te voorzien.

PERT-diagrammen zijn de beste manier om afhankelijkheid van taken aan te duiden, omdat ze de taken weergeven in de volgorde waarin ze moeten worden voltooid. Het langste pad van het begin tot het einde van een project wordt het kritieke pad genoemd. Het kritieke pad toont alle taken die volgens schema voltooid moeten zijn, wil men het project als geheel op tijd afronden. Elke taak op het kritieke pad is een kritieke taak. Kritieke taken worden gewoonlijk op een speciale manier aangeduid; in de figuur zijn ze door middel van dubbele randen aangeduid.

Het voordeel van projectbeheersoftware zoals Microsoft Project is dat het werkplan slechts eenmaal ingevoerd hoeft te worden, waarna de software de informatie op allerlei manieren kan weergeven. Al naargelang de behoeften van het projectbeheer kunt u heen en weer schakelen tussen het werkplan, een Gannt-diagram en een PERT-diagram.

18.6.3.5 Schattingen verfi jnen

De schattingen die tijdens de planningsfase plaatsvinden, zullen in de loop van het project moeten worden bijgesteld. Dit betekent niet dat er aan het begin van het project slecht werd geschat, m aar louter dat het praktisch ondoenlijk is om het exacte tijdsverloop van een project aan te geven voordat de analysefase en ontwerpfase worden doorlopen. Een projectma nager zal zich tevreden moeten stellen met globale schattingen die steeds verfijnder worden naarmate het product van het project nauwer wordt omschreven.

Wat gebeurt er als een schatting te klein is uitgevallen (oftewel als de planningsfase bijvoorbeeld twee weken langer duurt dan aanvankelijk was gepland)? Er zijn verschillende manieren om toekomstige schattingen bij te stellen. Als een projec t een stap op het tijdschema vooruitloopt, halen de meeste projectmanagers de deadlines eenzelfde periode naar voren, maar passen ze de beloofde afleveringsdatum niet aan. Lastiger wordt het echter als het project een geplande deadline niet haalt. Mocht een schatting aan het begin van een project naderhand te optimistisch blijken, dan raden wij aan om er niet van uit te gaan dat er tijd zal worden ingehaald, want in de praktijk is dit in slechts een handjevol projecten het geval. Wijzig de toekomstige schattingen liever door ze eenzelfde percentage groter te maken dan de te optimistische schatting. Als de eerste fase bijvoorbeeld 10% langer heeft geduurd dan gepland, hoog dan de rest van uw schattingen eveneens met 10% op.

18.6.3.6 Reikwijdtebeheer

Misschien gaat u ervan uit dat uw project niet met tijdschemaproblemen zal kampen omdat u uw project van het begin af aan zorgvuldig hebt geschat en gepland. Toch komt het vaak voor dat er in de loop van een project problemen met de geschatte tijdsduur en de kosten opduiken en de oorzaak van die problemen is oprek van de reikwijdte .

Van oprek van de reikwijdte is sprake wanneer nieuwe eisen aan het project worden toegevoegd nadat de oorspronkelijke reikwijdte van het project werd bepaald en 'bevroren'. Di t kan gebeuren om tal van redenen: gebruikers beseffen plotseling de mogelijkheden van het nieuwe systeem en verlangen nog meer functionaliteit, ontwikkelaars ontdekken interessante mogelijkheden die ze dolgraag willen uitdiepen, of een leidinggevende wil dat zijn systeem een nieuwe strategie ondersteunt waartoe afgelopen maandag tijdens de laatste directievergadering werd besloten.

Helaas wordt het na de start van een project steeds moeilijker om een wijziging van de eisen te honoreren. De wijzigingen moeten op grotere schaal worden aangebracht, de nadruk op de oorspronkelijke doelstellingen verschuift en de kosten en het tijdsschema komen in meer of mindere mate onder druk te staan. Daarom speelt de projectmanager een kritieke rol bij het regelen van de ze wijzigingen, aangezien hij de oprek van de reikwijdte tot een minimum dient te beperken.

De crux is om de eisen zo vroeg mogelijk in het project op te sporen en de analysemethoden effectief toe te passen. Als bijvoorbeeld de wensen in het begin van een project niet helder zijn, kan een combinatie van intensief overleg met gebruikers en het werken met een proof of concept ervoor zorgen dat gebruikers de eisen 'aan den lijve ervaren' en zich beter kunnen voorstellen hoe het systeem hun behoeften zou kunnen ondersteunen. In de praktijk is namelijk gebleken dat een combinatie van overleg en het gebruik van een proof of concept de oprek van reikwijdte in een doorsnee project tot minder dan 5% kan terugbrengen.

Uiteraard is het mogelijk dat sommige eisen over het hoofd worden gezien, ongeacht welke voorzorgen u neemt, maar er zijn wel degelijk werkwijzen die u kunnen helpen om te voorkomen da t er al te veel taken aan de bestaande takenlijst worden toegevoegd. Ten eerste moet de projectmanager uitsluitend toestaan dat alleen de absoluut noodzakelijke eisen na aanvang van een project alsnog worden toegevoegd. Maar zelfs in dat geval moeten de leden van het projectteam de implicaties daarvan zorgvuldig bepalen en terugkoppelen naar de gebruikers. Het is bijvoorbee ld denkbaar dat er twee of meer manmaanden nodig zijn om een zojuist opnieuw gedefinieerd rapport op te stellen, waardoor de deadline van het hele project twee weken zou moeten opschuiven. Elke wijziging die wordt aangebracht, moet zorgvuldig worden bijgehouden, zodat er een controlemogelijkheid is om de invloed van de wijziging te meten.

Soms kunnen wijzigingen niet in het systeem worden geïncorporeerd, hoe wenselijk en zegenrijk ze ook zouden zijn. In zo’n geval moeten deze aspecten worden vastgelegd en kunnen ze als uitgangspunt voor toekomstige uitbreidingen van het systeem worden gebruikt. De projectmanager kan aanbieden om de desbetreffende functionaliteit in volgende versies van het systeem te leveren en omzeilt op deze manier dat hij iemand 'nee' mo et verkopen.

18.6.3.7

Tijdvakmethode

De tijdvakmethode is een andere manier om de reikwijdte van een project te beheren. Tot dusverre hebben we taakgerichte projecten beschreven. Anders gezegd, we hebben projecten beschreven met een schema dat wordt bepaald door de taken die moeten worden uitgevoerd. Hoe groter het aantal taken en eisen is, des te langer een project zal duren. Sommige bedrijven hebben echter weinig op met projecten die lang duren en hanteren daarom een tijdgerichte aanpak die het halen van een deadline boven de aflevering van functionaliteit verkiest. Neem bijvoorbeeld uw tekstverwerkingsprogramma. Tachtig procent van de tijd gebruikt u waarschijnlijk slechts twintig procent van de functies (zoals de spellingcontrole, vet, cursief, onderstrepen, tekst knippen en plakken). Andere functies, zoals documenten samenvoegen en verzendetiketten maken, zijn misschien handig, maar zijn niet essentieel voor uw dagelijks werk. Hetzelfde geldt voor andere software toepassingen; de meeste gebruikers benutten s lechts een fractie van de mogelijkheden. Ironisch genoeg zijn de meeste ontwikkelaars het erover eens dat 75% van de functionaliteit van een toepassing veelal snel kan worden opgeleverd en dat met de overige 25% functionaliteit de meeste tijd is gemoeid.

Deze incongruentie kan worden verholpen door de tijdvakmethode, een techniek die snel aan populariteit heeft gewonnen, met name binnen het kader van de SOT -methodologie. De tijdvakmethode hanteert een vaste deadline voor een project en levert het systeem hoe dan ook tijdig af, zelfs als de functionaliteit daardoor moet worden ingeperkt. De tijdvakmethode garandeert dat projectteams niet verzanden in de afwerking die eindeloos kan voortduren en stelt het bedrijf tevreden door binnen betrekkelijk korte tijd een product te leveren.

Er zijn verscheidene stappen nodig om de tijdvakmethode in een project te implementeren. Om te beginnen wordt de afleveringsdatum voor de voorgestelde doelen vastgesteld. Deze deadline moet binnen de mogelijkheden vallen, dus kan het projectteam het best een realistische datum bepalen. Vervolgens wordt de kern van het gewenste systeem gebouwd. U zult tot de ontdekking komen dat de tijdvakmethode een gevoel van urgentie bevordert en een concentratie op de belangrijkste functies helpt handhaven. Aangezien het tijdschema onwrikbaar vaststaat, moet de functionaliteit die niet tijdig kan worden afgeleverd, tot een later tijdstip worden uitgesteld. Het helpt als het team van tevoren een prioriteit van functies opstelt om na te gaan welke functies de gebruikers absoluut nodig hebben. Ongeacht de beperkingen mag de kwaliteit hieronder nooit lijden, reden waarom de tijd die voor taken is uitgetrokken, niet wordt verkort, tenzij de eisen worden gewijzigd. (Verkort bijvoorbeeld nooit de tijd die voor tests is uitgetrokken, tenzij het aantal functies wordt verminderd.) Aan het eind van het project wordt een kwaliteitssysteem afgeleverd, maar waarschijnlijk zal er in de toekomst wel een aanvullend project nodig zijn om wijzigingen of uitbreidingen te realiseren. De tijdvakmethode kan dan wederom worden gebruikt.

1 Bepaal de datum waarom het systeem moet worden afgeleverd.

2 Bepaal de prioriteiten van de functies die het systeem moet hebben.

3 Bouw de ruggengraat van het systeem (de kernfunctionaliteit die het belangrijkst wordt geacht).

4 Stel functionaliteit uit die niet binnen de toegewezen tijd kan worden geleverd.

5 Lever het systeem af met de kernfunctionaliteit.

6 Herhaal de stappen 3 tot en met 5 om verfijningen en uitbreidingen aan te brengen.

18.7 Prince 2

Kenmerken van een project

• Resultaat: Doel binnen de grenzen van tijd, geld en kwaliteit

• Tijdelijk: Bij einddoel stopt het project

• Multi disciplinair: Samenwerking tussen mensen van verschillende disciplines

• Nieuw: Een nieuw product of dienst voor de organisatie

• Voorbeeld een website : Bouwen VS onderhouden

Projectmatig werken

3 werkvormen

4 Invalshoeken

• Ik : Projectmanager

• Wij : Samenwerkingskant van het project

• Zij: Omgeving van het project

• Het: Structuurkant van het project (methodiek, processen en procedures Projectorganisatie

• Functie vs rol

• Functie : beroep vb informaticus

• Rol: tijdelijke positie binnen een uitvoerende organisatie vb wijzigingscoördinator

• Opdrachtgever

• Business Executive (Business manager)

• Opdrachtnemer

• Project manager

Organisatie

Bij het opzetten van PRINCE 2 projecten geldt als belangrijk uitgangspunt het logische principe dat het projectresultaat dóór de leveranciers (met gebruik van eventuele sub-contractors), vóór de gebruikers en ten behoeve van de business wordt geproduceerd. Deze drie partijen en hun belangen vormen dan ook een integraal onderdeel van PRINCE 2 projecten door middel van een vertegenwoordiging in het management van het project. Binnen dit management wordt het zogenaamde ‘BUS-principe’ gehanteerd. Vertegenwoordigers vanuit de Business, de Users en de Suppliers vormen tezamen de Project Board (zie figuur ). Deze Board kan worden beschouwd als de tegenhanger van de bekende stuurgroep binnen andere methodieken. Binnen PRINCE 2 is het echter de Project Board die expliciet verantwoordelijk is voor het welslagen van h et project: het opleveren van een bruikbaar resultaat met een toegevoegde waarde voor de business. In een PRINCE 2 projectmanagement omgeving hebben namelijk die leden zitting in de Project Board die zeggenschap hebben over de benodigde resources. Op deze wijze wordt het veelvuldig voorkomende probleem van de projectmanager (wel verantwoordelijk maar onvoldoende bevoegdheden) door een eenduidige inrichting van de projectorganisatie weggenomen. De projectmanager zal namelijk op basis van ondubbelzinnige afspraken met de Project Board de dagelijkse leiding van het project verzorgen. Hierbij zal richting de Project Board binnen de projectfasen het ‘Management by Exception’-principe gehanteerd worden. Onderdeel van de afspraken is een op de taak afgestemde afbakening van verantwoordelijkheden en bevoegdheden.

• Directie of programmamanagement

o Hoogste laag

o Verantwoordelijk voor de afstemming van de verschillende projecten binnen de organisatie

• Programma

o Tijdelijke organisatievorm

o Aantal projecten om een doel te bereiken

• Project board (stuurgroep) – BUS

De Project Board is zoals gezegd eindverantwoordelijk voor het project. De leden beslissen over de voortgang en stellen resources ter beschikking en dienen dan ook van voldoende ‘zwaarte’ te z ijn.

Het is essentieel dat de Project Board drie belangen vertegenwoordigt: Business, User en Supplier (BUS-principe). Iedere rol behartigt dan ook één van deze drie belangen. Dit is inzichtelijk te maken door aan te geven wat de kernvraag van een ieder is

o Business executive

 Voorzitter

 Meeste belang/meeste baat

o Senior user

o Senior supplier

o Project manager rapporteert aan PB

o Bewaakt doel, budget en einddatum van het project

• Project manager

De Project Manager is verantwoordelijk voor het dagelijks managen van het project binnen de gemaakte afspraken met de Project Board. De Project Manager is daarmee verantwoordelijk voor het opleveren van producten die voldoen aan de gestelde kwaliteitseisen, binnen de afgesproken tijd en budget. Hierdoor is de Project Manager mede verantwoordelijk voor het invullen van de Business Case. De Project Board blijft hierin echter eindverantwoordelijk.

o Verantwoordelijk voor de oplevering project

o Dagelijkse voortgang bewaken

o Binnen tijd, geld en kwaliteitsgrenzen

o 1 per project

• Team manager

Het projectteam draagt zorg voor de projectuitvoering en de oplevering van de producten. Dit team rapporteert aan de Project Manager. Bij kleinere projecten is de Project Manager vaak zelf ook een lid van het projectteam en dus, naast de projectbeheersing, belast met de projectuitvoering. Bij een groter project kan het uit te voeren werk door verschillende teams worden uitgevoerd, waarbij Team Managers worden aangewezen als aanspreekpunt voor de Project Manager.

o Verantwoordelijke specialistische teams

o Oplevering product

o Rapporteert aan Project manager

• Project assurance of Projectborging

Dit betreft een gedelegeerde rol vanuit de Project Board. Project Assurance heeft een onafhankelijke positie ten opzichte van de Project Manager en bewaakt of het project en de op te leveren producten nog binnen de afspraken vallen. Hiermee kan deze rol worden beschouwd als het ‘geweten’ van het project. Belangrijk hierbij is het bewaken van de Business Case, het waarborgen van de betrokkenheid van de gebruikers en het volgen van standaarden door de leveranciers. Bij kleinere projecten kan deze rol ook door de leden van de Project Board worden ingevuld.

o Verantwoordelijk voor de kwaliteit van het project

o Indirect van de kwaliteit van het product

o Ondersteunen PM en BUS

o Verantwoordelijkheid BUS

• Project Support of Projectondersteuning

Project Support verzorgt de benodigde administratieve ondersteuning en verschaft expertise omtrent het gebruik van tools en standaarden. Tevens wordt in sommige gevallen ondersteuning gegeven bij planning en configuratiebeheer.

o Administratieve werkzaamheden

o Planning, registratie en administratie

o Staf(functie), delegatie per project, zorgt voor uniformiteit

Projectplanning

Een plan is uiteraard nodig om de route waarlangs het eindresultaat bereikt gaat worden uit te stippelen. Een belangrijke toepassing van een planning in de praktijk is om tot een goede resourceallocatie te komen. Hierdoor is het mogelijk om de juiste producten op het juiste tijdstip te vervaardigen. PRINCE 2 hanteert bij het opstellen van plannen het eerder geïntroduceerde productbased planning. Hierbij worden eerst de producten gedefinieerd en op basis daarvan de activiteiten. Om continu een realistisch plan te hebben maakt PRINCE 2 gebruik van plannen op drie niveaus. Allereerst het overall Project Plan met een indeling van de op te leveren hoofdproducten en uit te voeren activiteiten ingedeeld naar fasen. Vervolgens wordt gedurende het verloop van het project per fase een gedetailleerd Stage Plan gemaakt. Hierin wordt voorafgaand aan iedere fase een gedetailleerd overzicht gegeven van de op te leveren producten en uit te voeren activiteiten. Eventueel wordt er per fase gebruik gemaakt van Team Plans waarin de details voor de diverse teams zijn uitgewerkt. Door het onderkennen van deze drie niveaus wordt bereikt dat details pas dan worden aangebracht als reële informatie voorhanden is. Hierdoor is een gezonde basis voorhanden om afgegeven planningen als goede leidraad voor het daadwerkelijk verloop van het project te gebruiken.

• Planning van globaal naar gedetailleerd

o Top down: grote lijnen en dan details uitwerken

• Een goede voorbereiding is het halve werk

o Globale voorbereiding voor het gehele project

o Gedetailleerde voorbereiding voor de volgende fase

• Beter ten halve gekeerd, dan ten hele gedwaald

o Omstandigheden veranderen, moeilijke beslissing

o Durven ophouden

• Eerst plannen dan uitvoeren

o Doel moet vooraf duidelijk zijn om problemen in een later stadium te vermijden

• Van je fouten kun je leren

o Leerpunten documenteren op het einde van een project en meenemen naar een volgende

• GOKIT

Projectbeheersing

o Geld: budget overschrijdingen

o Organisatie: verdeling van taken, verantwoordelijkheden en bevoegdheden

o Kwaliteit: voldoen aan kwaliteitsvereisten

o Informatie: vastleggen activiteiten en afspraken

o Tijd: Einddatum meermaals verplaatsen

Projectfasering

1. Opstartfase: er wordt getoetst of het oorspronkelijke probleem of idee in aanmerking komt om projectmatig te worden aangepakt. Bepalen eindresultaat en grenzen

2. Definitiefase: definiëren aan welke eisen het project moet voldoen. Analyse van de problemen en vastleggen eisen van het product.

3. Ontwerpfase: op basis van de eisen worden alternatieve oplossingen ontwikkeld en de wordt de beste gekozen. Denk aan modellen of prototypes.

4. Voorbereidingsfase: voor de uitvoeringsfase. Alles wat nodig is voor de uitvoering moet worden gepland. Opstellen van werkinstructies

5. Uitvoeringsfase: realisatie van het eindproduct. Acceptatietest om na te gaan of product voldoen aan de gestelde (kwaliteits)eisen. Na acceptatie kan dit worden ingevoerd.

6. Evaluatie: Lessons learned voor volgende projecten. Documentatie van goede en slechte punten.

• Project mandaat

o Voorstel van de directie om een bepaald probleem op te lossen met een project

• Projectvoorstel ~ systeem aanvraag

o Formeel, bindend document met afspraken tussen de opdrachtnemer en opdrachtgever

o Uitwerking van het projectmandaat tijdens de opstartfase

• Project plan

o Uitwerking van het projectvoorstel

• Wie stelt er geld en middelen beschikbaar ?

• Wat is de achtergrond van het project ?

• Wat is het doel van het project ?

• Welke producten moeten er worden opgeleverd ?

Project mandaat

• Aan welke kwaliteitscriteria moeten de eindproducten voldoen ?

• Wat zijn de grenzen van het project ?

• Met welke randvoorwaarden moet worden rekening gehouden ?

• Wat zijn de relaties met andere projecten of producten ?

• Waarom moet het project worden gestart ?

• Wie zijn de belanghebbenden ?

• Binnen welke grenzen kan de projectmanager zelfstandig beslissingen nemen ?

Business case

• Aanleiding

o Korte beschrijving waarom een project moet worden uitgevoerd

• Alternatieven

o De verschillende opties die overwogen zijn

• Investeringsbegroting

o Alle kosten i.v.m. de ontwikkeling, het gebruik en beheer t.o.v. de voordelen

• Opbrengsten

o Duidelijk en meetbaar beschrijven

o Alternatief: verlies, boetes, onderhoud indien project niet wordt uitgevoerd

• Risico’s

o Risicologboek: risico’s en tegenmaatregelen

• Planning

Kenmerken van prince 2

• Resultaatgerichte aanpak

o Sturen op de business case, resultaat centraal

• Procesmatige werkwijze

o Doel processen centraal

• Best practice

o Actief gebruikt, gebruikersgroepen,…

• Productgerichte planning

o Planning van specialistische producten centraal

• Management by exception

o Stuurgroep komt alleen in uitzonderingssituaties tussen buiten de marges van tijd, geld en kwaliteit

Procesbenadering

Prince2 benadert projectmanagement procesmatig

Een proces is als een zwarte doos die een bepaald doel heeft. Je steekt er iets in er gebeuren activiteiten en er komt iets uit. Vb. Belastingsaangifte Prince2 opstarten project. Heeft het zin om het project te doen. Verzamelen informatie en dan beslissen of we er mee door gaan

• Is het doel bereikt :

• KPI

• Procedures

• Werkinstructies Wat moet er gedaan worden niet wie

Cirkel van Deming

Procesbenadering komt overeen met plan do check act levenscyclus van een kwaliteitssysteem Alert voor kwaliteit van de processen en activiteiten brengt deze naar een hoger niveau Theorie van Demming om de kwaliteit te verbeteren :

• Plan: wie doet wat, waar en wanneer

• Do: Het uitvoeren van de geplande activiteiten.

• Check: meten of het geplande we rk werd gehaald.

• Act: de plannen worden bijgesteld

Door deze stappen uit te voeren rolt het wiel bergopwaarts en kan de kwaliteit worden verbeterd.

Structuur van een Prince 2-proces

• Input

o Projectmandaat om een project op te starten

• Doel

o SMART

• Activiteiten

o Om doel te bereiken, verschillende activiteiten

• Output

o Resultaat van een proces. Vb. rapport

• Schaalbaarheid (proces toepasbaar?)

o Voor elk proces nagaan of deze nodig is

• Sleutelfactoren

o Factoren die bepalen of proces zal slagen of mislukken

• Verantwoordelijkheden

o Wie is verantwoordelijk voor de activiteiten binnen het proces en wie is verantwoordelijk voor het resultaat.

Levenscycli

Projectomgeving

Prince2 processen

Opstarten van een project : opstartfase, projectmandaat, projectmanager en stuurgroep aanstellen, opstellen projectvoorstel, projectgroep keurt voorstel goed

Initiëren van een project : activiteiten na goedkeuring, om project verder uit te werken, eerste fase van het project om goed voor te bereiden, projectinitiatiedocument opstellen (wie wat waar wanneer en waarom)

Dirigeren van een project: activiteiten van de stuurgroep, na elke fase go of nogo, treedt op wanneer buiten de toleranties wordt gegaan. Management by exception

Managen faseovergangen: beslismoment voor de stuurgroep op basis van gegeven informatie uit deze fase. Buiten tolerantie gaan –> afwijkingsplan

Beheersen van een fase: dagelijks werk van de Pm gedurende het project vb plannen., correc tieve maatregels, doel opleveren (deel-)producten

Managen van een productoplevering: werkzaamheden van de teams. Wat er gedaan wordt, wordt overeengekomen tussen PM en team manager

Plannen maken: pm , initiatieplan, projectplan, teamplan, faseplan of afwijkingsplan

Afsluiten van een project: resultaat wordt geaccepteerd door de gebruikers en overgedragen aan de opdrachtgever. Pm leerpuntenrapport en aanbevelingen. Einde projectorganisatie

Technieken

• Techniek 1 : productgerichte planning

o Management producten

 Vb. projectvoorstel, faseplan, risicologboek

o Specialistische producten

 Vb. een nieuwe informatiesysteem, een website, …

• Techniek 2: wijzigingsbeheer

o Project aandachtspunt

 Issue log

o wijzigingsverzoek

 RFC

 CAB

o Afwijking

 Concessie

Issue log : lijst van aandachtspunten die belangrijk zijn voor een project

RFC: request for change

CAB change advisory board, gedelegeerd door de stuurgroep

Concessie: acceptatie om een afwijking toe te staan

 Techniek 3: kwaliteitsbeoordeling

o Drie stappen

 Voorbereiding

 Beoordeling

 Afronding

o Rollen

 Producent

 Beoordelaar

 Voorzitter

 Notulist

 Projectmanager

 Teammanager

Opstarten van een project

Dit proces beschrijft het werk dat gedaan wordt vóór de eigenlijke start van het project. Het proces begint na de opdracht vanuit de staande organisatie om een project te starten. Binnen PRINCE 2 wordt deze opdracht de Project Mandaat genoemd. Het belangrijkste doel van het proces is om relatief snel inzichtelijk te maken of de te nemen investeringen ten behoeve van het project te rechtvaardigen zijn in termen van toegevoegde waarde voor de business. Hiervoor is het proces bewust losgekoppeld van het volgende proces (Initiating a Project). Voordat er meer tijd en geld in de initiatie van het project wordt gestoken is het verstandig om snel inzichtelijk te maken of het om een levensvatbaar project gaat. Hiervoor wordt een vertaling van de opdracht naar projectmanagement termen gemaakt. Dit gebeurt door middel van de Project Brief. Hierin zijn onder meer de projectdefinitie, de initiële Business Case en de kwaliteitsverwachtingen opgenomen. Een belangrijk onderdeel van dit proces is tevens het benoemen van de kern van het Project Management Team: de Project Manager en de Project Board. Daarnaast wordt de Risk Log aangemaakt en een plan voor de volgende fase opgesteld: het Initiation Stage Plan. De Project Board neemt op basis van de Project Brief, de beschreven risico’s en het plan voor de volgende fase een ‘go/no-go’ beslissing. Deze geldt overigens slechts voor de volgende fase. Per fase-overgang zal een soortgelijke beslissing genomen moeten worden.

 Opstarten van het project

 Input voor het proces OP

 De oorsprong van een project

 Haalbaarheid

o Stand alone

o Programma

o Klein project

 De lessen uit het verleden



Sub processen van OP

⦁Business manager en projectmanager benoemen

 Projectmanagement team samenstellen

 Projectmanagement team benoemen

 Projectvoorstel opstellen

 projectaanpak definiëren

 Initiatiefaseplan opstellen

Projectvoorstel

 Project achtergrond

 Project definitie

o Doelstellingen

o Bereik

o Resultaten

o Uitzonderingen

o Beperkingen

o Relaties

 Hoofdlijnen business case

 Kwaliteits verwachtingen

 Acceptatiecriteria

 Risico’s

 Organisatiestructuur

 Project aanpak

 Initiatiefaseplan

 Risicologboek

Opstellen van een plan

Planning is het proces dat wordt gebruikt door andere PRINCE 2 processen om het Project Plan, de Stage Plans en de eventuele Team Plans op te stellen. Het planningsproces levert invoer voor de processen: Starting Up a Project, Initiating a Project, Managing Product Delivery en Managing Stage Boundaries. Tijdens dit proces worden onder andere de volgende stappen doorlopen:

• het definiëren van de producten (product-based planning);

• het identificeren van de activiteiten en de onderlinge afhankelijkheden;

• het inschatten van de benodigde resources;

• het plannen van deze resources;

• het analyseren van de risico’s die door het doorlopen inzichtelijk zijn geworden.

Prince 2 plannen

 Projectplan

 Faseplan

 Teamplan

 Afwijkingsplan

Opbouw van een plan

 Beschrijving

 Grafische weergave

 Opleverdatum

 Beslismomenten

 Risico’s

 Toleranties

 Verantwoordelijkheden

 Afhankelijkheden

Globaal overzicht van het planningproces

Subprocessen van PL

 Plan ontwerpen

 Producten definiëren en analyseren

o Product decompositie structuur

o Product beschrijving

o Product stroomschema

 Activiteiten en afhankelijkheden identificeren

 Schatting maken

 Tijdschema opstellen

 Risico’s analyseren

 Werkplan voltooien

Project plan

 Beschrijving

 Fasering

 Randvoorwaarden

 Afhankelijkheden

 Aannamen

 Onderdelen

o Activiteiten wijst, budget, middelen, toleranties, risico ’s, uitwijkplannen

 Samenvatting

Fase plan

 Beschrijving

 Kwaliteitsplan

 Randvoorwaarden

 Afhankelijkheden

 Voortgang

 Rapportage

 Aannamen

 Onderdelen

o Activiteiten lijst, budget komen toleranties, middelen, risico ’s

 Samenvatting

Dirigeren van een project

Dit proces geeft de rol van de Project Board aan. De start van elke volgende projectfase dient expliciet door de Board geautoriseerd te worden, default is de beslissing immers ‘no -go’. De autorisatie gebeurt bij de start van het project op basis van de Project Brief en het Project Initiation Document. Tijdens het project vormen de Stage Plans de basis. Ook het einde van het project wordt door de Project Board geautoriseerd. Er dient namelijk een eenduidig toets plaats te vinden die duidelijk maakt of aan alle gemaakte afspraken is voldaan en of alle producten daadwerkelijk zijn opgeleverd en geaccepteerd. Daarnaast moet het voor alle betrokkenen helder zijn dat het project ook echt is afgelopen en dat de projectorganisatie ontmanteld wordt. Gedurende het project geeft de Project Board indien van toepassing advies aan de Project Manager.

Subprocessen van DP

 Project initiatie autoriseren

 Project autoriseren

 Fase- of afwijkingsplan autoriseren

 Ad-hocsturing geven

 De project afsluiting bevestigen

Initiëren van een project

De daadwerkelijke initiatie van het project. Op basis van de Project Brief wordt een gedetailleerd Project Initiation Document opgesteld: de PID. Eigenlijk is dit een verdere uitwerking van de Project Brief nadat de Project Board door middel van ee n ‘go’ te kennen heeft gegeven dat het project op de goede weg is. Belangrijke onderdelen van de PID zijn onder andere:

• de projectdefinitie;

• de projectorganisatie;

• het Project Quality Plan;

• het Project Plan met daarin de specificatie van de op te levere n producten;

• de Business Case;

• de beheersingsmechanismen.

Globale procesbeschrijving

 Kwaliteit plannen

 Project plannen

 Business case opnieuw bekijken

 Risico’s opnieuw bekijken

 Projectbeheersing opzetten

 Projectinitiatiedocument opstellen

 Goedkeuring vragen voor het project

Subprocessen van IP

 Kwaliteitsplan opstellen

o Configuratiebeheer

o Wijzigingsbeheer

 Project plannen

 Business case en risico’s aanscherpen

 Projectbeheersing opzetten

 Project dossier aanleggen

 Project initiatie document samenstellen

Managen van faseovergangen

Managing Stage Boundaries (SB) Managing Stage Boundaries draagt zorg voor een gestructureerde en beheerste werkwijze rond cruciale beslismomenten. Dit zijn binnen PRINCE 2 niet allee n alle faseovergangen maar ook dreigende overschrijdingen van de tolerantiegrenzen van een betreffende fase of zelfs van het gehele project (zie Exception bij Controlling a Stage). Op die momenten dient de Project Board namelijk te besluiten of, en zo ja hoe, het project gecontinueerd zal worden. Dit besluit wordt binnen het proces Directing a Project genomen. De projectmanager bereidt deze beslismomenten voor door het opstellen van de volgende documenten:

• End Stage Report: een verslag van de afgelopen fase;

• Next Stage Plan: een plan voor de eerstvolgende fase;

• Business Case: de actuele stand van zaken met betrekking tot de verwachte toegevoegde waarde van het project;

• Risk Log: een beschrijving van de te lopen risico’s en te nemen tegenmaatregelen.

Subprocessen van MF

 Fase plan opstellen

 Projectplan actualiseren

 Business case actualiseren

 Risicologboek actualiseren

 Faseafsluiting rapporteren

 Afwijkingsplan opstellen

Beheersen van een fase

Hierin worden de dagelijkse activiteiten van de Project Manager beschreven zoals het bepalen van het uit te voeren werk, het bewaken van de voortgang en het ondernemen van eventuele correctieve maatregelen. Per fase zal op basis van het Project Plan uit het Project Initiation Document een gedetailleerd Stage Plan zijn opgesteld. Binnen dit plan liggen de afspraken vast met betrekking tot de tolerantiegrenzen waarbinnen de Project Manager zich met de besturingsparameters (veelal in termen van tijd en geld) mag bewegen. Binnen deze grenzen geldt richting de Project Board het ‘management by exception’-principe. Dreigt er een overschrijding en heeft de projectmanager geen middelen, of bevoegdheden, om adequaat bij te sturen dan gaat de fase in Exception. De situatie zal aan de Project Board worden voorgelegd en in onderling overleg worden de te ondernemen stappen besloten. Eén van de alternatieven die PRINCE 2 hierbij aanreikt is het opstellen van een Exception Plan. Deze vervangt het onderhavige Stage Plan omdat deze in het geval van een Exception immers niet meer aansluit bij de werkelijkheid.

Controlling a Stage wordt meerdere malen doorlopen en wel overeenkomstig het aantal fasen dat binnen een project onderkend wordt. Dit in tegenstelling tot de processen Starting up Project en Initiating a Project die ieder slechts éénmaal per project doorlopen worden. Controlling a Stage behelst het aansturen en beheersen van de eigenlijke projectuitvoering. Er zijn in het proces dan ook geen activiteiten opgenomen die direct bijdragen aan de op te leveren producten, er wordt niet ‘gebouwd’. Dit vindt namelijk plaats binnen Managing Product Delivery. Door het onderkennen van deze twee verschillende processen zijn uitvoering en beheersing van het proje ct van elkaar gescheiden. De aansturing van het proces Managing Product Delivery gebeurt via zogenaamde Work Packages. Als basis hiervoor dienen de Product Descriptions uit het Stage Plan. De Work Packages

bevatten dan ook een beschrijving van de op te leveren producten tezamen met de kwaliteitsverwachtingen. Tevens worden er afspraken met betrekking tot de rapportage gemaakt.

Subprocessen van BF

 Werkpakket autoriseren

 Voortgang bewaken

 Projectaandachtspunten verzamelen

 Projectaandachtspunten beoordelen

 Status fase beoordelen

 Hoofdlijnen rapporteren

 Corrigerende maatregelen nemen

 Aandachtspunten aan de orde stellen

 Afgerond werkpakket ontvangen

Het uitvoeren van werk met werkpakketten

Managen van productoplevering

Subprocessen van MP

Dit proces beslaat de productie en oplevering van de businessproducten en kan daarmee als tegenhanger van Controlling a Stage beschouwd worden. Na acceptatie van de Work Package vindt de daadwerkelijke ‘bouw’ en kwaliteitscontrole van de (deel-)producten plaats. Binnen Controlling a Stage vindt er vervolgens een officiële acceptatie plaats van de door de projectmedewerkers opgeleverde producten. Eenmaal goedgekeurd en geaccordeerd kunnen producten enkel nog worden gewijzigd door middel van het in PRINCE 2 geïntegreerde Change Control proces.

 Werkpakket aannemen

 Werkpakket uitvoeren

 Werkpakket opleveren

 Datum

 Teamleden

 Beschrijving

 Product beschrijvingen

 Technieken

 Kwaliteitsbeheersing

 Configuratie Beheer

 Samenvatting

 Afspraken

 Kwaliteitsbeoordeling

 Rapportage

 Probleem afhandeling

Afsluiten van een project Maar al te vaak is er in de dagelijkse praktijk sprake van zogenaamde ‘never -ending projects’. Het doorlopen van dit proces zorgt echter voor een gestructureerd projecteinde waarbij de projectresultaten officieel worden overgedragen aan de organisatie.

Zo wordt er ondermeer een End Project Report door de projectmanager opgemaakt waarin het daadwerkelijke verloop van het project wordt vergeleken met het Project Initiation Document. Daarnaast wordt een Lessons Learned Report samengesteld en worden er aanbevelingen gedaan voor eventuele vervolgacties. Om te kunnen bepalen of het projectresultaat daadwerkelijk die toegevoegde waarde voor de organisatie biedt die het in de Business Case werd toegedicht wordt een datum voor een Post-Project Review bepaald. Uiteindelijk wordt de projectorganisatie opgeheven en wordt de staande organisatie hiervan op de hoogte gebracht door middel van een Project Closure Notification.

Inhoud van een Werkpakket

van AP

 Project afbouwen

 Vervolg acties identificeren

 Project evalueren

Subprocessen