download

Service Catalogus

// een frameworkv2.0 / 20 april 2004

Service Catalogus - framework

Doel document

Dit document is bedoeld als basis om binnen een (IT-)organisatie te komen tot een Service Catalogus.

AchtergrondEen Service Catalogus bevat een opsomming van services welke door een IT-organisatie aan klanten kunnen worden geleverd. Het hierna te schetsen framework waarin deze services kunnen worden on-dergebracht is gebaseerd op ITIL en ASL en sluit daar ook op aan. Het proces om te komen tot een Service Catalogus en vervolgens tot concrete afspraken met klanten is verder beschreven in het ITIL cq ASL-proces Service Level Management.

WerkwijzeDit document is niet meer dan een hulpmiddel om te komen tot een Service Catalogus. Elke IT-organ-isatie is uniek, en aldus zal elke Service Catalogus een andere invulling dienen te krijgen. Dit docu-ment kan helpen al vanaf het begin structuur aan te brengen in de beschrijving van de services. Wellicht wordt de IT-organisatie ook op ideeën gebracht. Juist doordat dit framework zo concreet mo-gelijk is gemaakt zullen een aantal beschreven aspecten niet of niet op de beschreven manier van toepassing zijn. Echter, er is de voorkeur aan gegeven heel concreet te zijn, met het gevaar dat er items in staan die voor u niet van toepassing zijn, boven het blijven op een abstract niveau waardoor alles wel past, maar te weinig concrete handvaten voorhanden zijn.

Concrete uitwerkingenEr zijn enkele concrete uitwerkingen beschikbaar, die zich in de praktijk reeds hebben bewezen. Een waarschuwing is hier echter op zijn plaats. In deze uitwerkingen zijn bepaalde keuzes gemaakt, die niet de uwe hoeven te zijn. Wijken uw keuzes sterk af, dan kan het zijn dat u juist op het verkeerde been wordt gezet. U kunt op dat moment beter terugvallen op het framework dat in dit document wordt geschetst, wat meer algemeen geldend is. Op- en aanmerkingenOp- en aanmerkingen zijn van harte welkom op [email protected]. Ook zijn we zeer geïnter-esseerd in uitwerkingen die (mede) zijn gebaseerd op dit framework. Al uw opmerkingen zullen uiter-aard vertrouwelijk worden behandeld en nimmer worden bedrijfsspecifieke gegevens aan derden doorgegeven.

2004 Tot Z IT-diensten BV (dit document is na 20 april 2004 vrijgegeven en mag vrij worden gebruikt)

2 / 14

mailto:[email protected]


Eisen aan een Service Catalogus

Inleiding Om onduidelijkheden te voorkomen worden de eisen die worden gesteld aan een Service Catalogus hier allereerst op een rij gezet. Uiteraard dient een Service Catalogus te voldoen aan het SMART-principe, hetgeen in de specificatie hieronder ook is meegenomen. De eisen moeten tijdens de samenstelling van de Service Catalogus in het oog worden gehouden om de kwaliteit te waarborgen. Na samenstelling van de Service Catalogus kan deze lijst met eisen di-enen om in een evaluatieronde gestructureerd de werkelijke kwaliteit van de Service Catalogus vast te stellen.

1. BegrijpelijkheidDe servicecatalogus heeft als primaire doel inzicht geven aan de klanten wat het dienstenportfolio van de ICT-organisatie is. Het is daarom van belang dat de klant de producten en diensten herkent. De servicecatalogus dient dus opgesteld te worden in een taal die door de klant wordt begrepen.Natuurlijk moet de beschrijving zodanig zijn dat ook de ICT-medewerker de mogelijk te leveren producten en diensten begrijpt.

2. ActualiteitEen Service Catalogus geeft de werkelijk op dit moment en nabije toekomst te leveren services weer. Net als een autoshowroom voorzien is van folders over actuele modellen, en oudere folders zsm wor-den verwijderd, moeten maatregelen worden genomen zodat een Service Catalogus op elk moment de actuele services weergeeft, en oudere versies worden verwijderd.

3. JuistheidDe beschrijvingen dienen (uiteraard) juist te zijn.

4. VolledigheidAlle services van de IT-organisatie dienen te zijn beschreven. Dit geldt ook als deze services geheel of gedeeltelijk door derden worden gerealiseerd.

5. EenduidigheidAlle beschreven services dienen voor slechts 1 interpretatie vatbaar te zijn.

6. Voldoende gedetailleerdheidDe beschrijving van de services dienen voldoende gedetailleerd te zijn. De mate van detaillering kan verschillen per service. Er dient een balans te worden gevonden tussen te abstract en te gedetailleerd.

7. MeetbaarheidAlle services moeten dusdanig zijn beschreven, dat in de daadwerkelijke uitvoering meetbaar aange-toond kan worden of de service op het afgesproken niveau wordt geleverd.

8. AcceptabelAlle beschreven services kunnen door de IT-organisatie tegen redelijke inspanning worden geleverd. Bijvoorbeeld is onacceptabel dat een service alleen kan worden geleverd doordat de betrokken IT-medewerkers voortdurend over moeten werken. Het is hier overigens niet van belang of een aangebo-den service ook voor een klant acceptabel is; deze kan immers besluiten bepaalde services niet af te nemen.

9. RealistischAlle beschreven services worden reeds enige tijd aantoonbaar geleverd of er is afdoende aangetoond dat dit vanaf ingangsdatum van de Service Catalogus zal geschieden.

10. TijdgebondenAlle beschreven services worden aangeboden voor onbepaalde tijd vanaf de ingangsdatum van de Service Catalogus, tenzij anders aangegeven. Indien gewenst kan het ook worden omgedraaid: de gehele Service Catalogus kent een bepaalde geldigheidsduur, die uiteraard duidelijk wordt aangegeven. Kent een service een afwijkende geldigheidsduur dan wordt dit bij de betreffende service aangegeven.


3 / 14


11. BekendheidEen Service Catalogus dient uiteraard bekend te zijn. Bij de betrokken klanten, en bij de IT-organ-isatie. Afspraken omtrent de te gebruiken communicatiekanalen betreffende de Service Catalogus en updates hierop zijn essentieel. Dit geldt zowel voor het ter beschikking stellen van de inhoud als wel op welke wijze vragen betreffende de Service Catalogus worden afgehandeld.

12. Aanpasbaarheid (flexibiliteit)Een duidelijk gevolg van de hiervoor genoemde eisen is dat een Service Catalogus moet worden on-derhouden. De Service Catalogus dient dusdanig te zijn opgezet dat onderhoud tegen lage kosten mogelijk is. Er dienen voor deze activiteit uiteraard voldoende middelen ter beschikking te worden gesteld. Aanbevolen wordt het onderhoud op 1 centraal punt neer te leggen, van waaruit ook de dis-tributie van geautoriseerde nieuwe versies kan plaatsvinden.

13. ZelfverklarendDe Service Catalogus is een document dat een klant op eigen houtje kan raadplegen. Alle gebruikte termen, de indeling etc. moeten dus zelfverklarend zijn.

14. Resultaat- ipv inspanningsverplichtingenZoveel mogelijk moeten resultaatverplichtingen worden beschreven bij de gedefinieerde diensten/pro-ducten, en voor het overige minimaal inspanningsverplichtingen.

15. Klant georienteerdDe beschrijvingen dienen vanuit het perspectief van de klant te zijn opgesteld. Klanten zijn onder te verdelen in een aantal categorieen, die elk hun eigen behoeften hebben. Het nuttig of nodig zijn de Service Catalogus zodanig vorm te geven dat elke klantgroep alleen de voor haar relevante onderde-len ziet.

16. Toegankelijkheid (printbaarheid)De Service Catalogus moet gemakkelijk toegankelijk zijn voor alle betrokkenen. Via intranet, papier of welk ander medium dan ook.

17. EigenaarschapElke genoemde service of product moet een eigenaar hebben.

18. VormgevingDe vormgeving moet de inhoud ondersteunen. De indeling moet helder en inzichtelijk zijn. Indien gew-erkt wordt met fullservices, services en deelservices moet dat ook door de vormgeving worden onder-steund.

Enige indicaties of een Service Catalogus inderdaad op orde is:1. Hoe vaak vraagt een klant om de “verkeerde” dingen2. Hoe vaak vraagt de klant om aanvullende informatie ontrent een beschreven service3. Hoe vaak is een klant teleurgesteld omdat de verwachting niet conform de levering is, terwijl

wel aan de letter van de Service Catalogus (en daarmee aan de SLA) is voldaan


4 / 14


Diverse aspectenRondom de Service Catalogus spelen nog een aantal aspecten die aandacht verdienen. Deze worden hierna kort geraakt.

A. Omvang Service CatalogusVoorkomen moet worden dat de Service Catalogus de omvang van een telefoonboek krijgt. Een richtlijn voor de Service Catalogus is: 10-30 pagina’s.

B. Positionering Service CatalogusOnderstaand schema geeft de positionering van de Service Catalogus goed weer. Ze staat tussen de klant en de IT-organisatie, maar wel dichterbij IT. Een uitbreiding op dit schema zou kunen zijn dat een extra blok tussen klant en Service Catalogus wordt gezet (maar dan dichtbij de klant) waarin de Ser-vice Level Requirements worden samengebracht.

C. Service Catalogus up-to-date houdenHet up-to-date houden van de Service Catalogus is uiteraard cruciaal voor het gebruiksnut ervan. De volgende maatregelen dragen hier sterk toe bij:

1. Beleg de verantwoordelijkheid voor de Service Catalogus bij de Service Level Manager2. Leg uitsluitend afspraken vast in SLA’s die worden gedekt door de Service Catalogus.

Daarmee wordt de druk op het up-to-date houden van de Service Catalogus aanzienlijk verg-root.

3. Breng de Service Catalogus onder versie-control4. Maak beleid rondom het up-to-date houden van de Service Catalogus (en wellicht nog veel

meer documenten)

D. Wanneer starten met een Service Catalogus?Feitelijk dient de IT-organisatie op een redelijk niveau te functioneren voordat een Service Catalogus kan worden samengesteld. Immers, de beschreven diensten moeten ook worden waargemaakt, en niet alleen vandaag, maar ook volgende week, over een maand….. Afgebeeld op IT Service CMM dient een organisatie aldus minimaal op level 2 (repeatable) te oper-eren. Het is echter zeker aan te bevelen met een Service Catalogus te starten op het moment dat de IT-or-ganisatie nog onder dat niveau operereert:

1. Een Service Catalogus werkt structurerend, en helpt daarmee een volgend volwassenheid-sniveau eerder te bereiken

2. Het is zeker mogelijk om een Service Catalogus stapsgewijs op te bouwen. Dat betekent dat de services die reeds op het niveau “repeatable” of hoger kunnen worden geleverd, worden opgenomen. De Service Catalogus wordt daarmee een groeidocument. Wordt gekozen voor deze aanpak, dan is wel van belang dat de klant daarvan op de hoogte is.


5 / 14

KlantIT-

organisatieService

Catalogus

Definiëring van het aanbod

Wat moeten we kunnen waarmaken

Wat wordt aangeboden

Wat kunnen we vragen


E. Wat opnemen in de Service Catalogus?Uitgangspunt van de Service Catalogus is dat alles wat de IT-organisatie kan en wil leveren wordt opgenomen. Vooral het willen moet hier worden benadrukt. Het kan blijken dat de IT-organisatie ser-vice(s) levert of zou kunnen leveren, die zijzelf inmiddels als ongewenst bestempeld. In dat geval is het absoluut af te raden deze service(s) op te nemen in de Service Catalogus. Het zou ertoe kunnen leiden dat anderen ook om deze (ongewenste) service gaan vragen. In plaats daarvan moet uiteraard een lijn worden uitgezet waardoor de ongewenste servicelevering wordt afgebouwd.


6 / 14


Het stappenplan

Doel In het hierna volgende deel van dit document worden in een framework alle elementen van de Service Catalogus uitgewerkt en beschreven. In de praktijk blijkt het vullen van het framework nogal wat hoofdbrekens te kosten. Daarom is een stappenplan ontwikkeld waarlangs de Service Catalogus kan worden ontwikkeld.

Stap 1: Present Mode of OperationEen eerste stap om te komen tot een realistische invulling van de Service Catalogus is een inven-tarisatie van de huidige, werkelijk geleverde services te maken. Gedurende een periode van bijvoor-beeld 3 maanden wordt nauwkeurig bijgehouden welke services worden geleverd. Ze worden direct opgenomen in het framework. Aandachtspunten:

Maak de periode niet te kort: sommige services worden slechts periodiek geleverd. Besteed apart aandacht aan de services met een jaarlijkse frequentie

Veel activiteiten vinden herhaaldelijk plaats. Ook deze kwantitatieve gegevens dienen te wor-den opgenomen (aantal, omvang, frequentie)

Detailleringsniveau Indien nodig testen gekozen oplossing.

Stap 2: Inventarisatie bestaande beschrijvingenIn veel organisaties zijn al (deel)services en producten beschreven. Deze, vaak versnipperde, beschri-jvingen moeten worden verzameld en kunnen uiteraard input vormen voor de Service Catalogus. Aandachtspunten:

Let op de actualiteit van de beschrijvingen De beschrijvingen kunnen bij elkaar een grote lappendeken vormen. Tracht niet op dit mo-

ment dit al te integreren. Deze integratiestap komt in stap 5.

Stap 3: Inventarisatie bestaande SLA’sIn het geval er wel SLA’s met klanten zijn afgesloten, maar er geen Service Catalogus bestaat, is het op basis van “reverse engineering” mogelijk de aspecten die in de SLA’s zijn beschreven alsnog in een Service Catalogus op te nemen. Afbeelding van alle SLA-aspecten op het framework dient plaats te vinden op een lege versie van het framework. In stap 5 vindt integratie plaats met de stappen 1, 2 en 4.


7 / 14

1. Present Mode of Operation

2. Inventarisatie huidige beschrijvingen

4. Inventarisatie huidige afspraken toeleveranciers

6. Zoek en vul “witte vlekken”

5. Integratie

3. Inventarisatie huidige SLA’s

8. Evaluatie &afronding

Framework

7. Afstemming op informatieplan


Aandachtspunten: SLA’s bevatten specifieke services voor een bepaalde klant. Voor de Service Catalog zullen

de services doorgaans meer algemeen geldend moeten worden beschreven. Belangrijke meerwaarde kan worden bereikt indien bekend is of de in de SLA’s afgesproken

servicesniveaus ook (voortdurend) worden nagekomen. Uiteraard dienen in de Service Cata-logus uitsluitend haalbare services te worden beschreven.

Stap 4: Inventarisatie leverancierafsprakenAfspraken (informeel tot formeel, inclusief contracten) met leveranciers betreffende levering van pro-ducten en / of services kunnen worden vertaald naar services in de Service Catalogus. Afbeelding van alle leverancierafspraken op het framework dient plaats te vinden op een lege versie van het frame-work. In stap 5 vindt integratie plaats met de stappen 1, 2 en 3.Aandachtspunten:

Alle door leveranciers geleverde producten / services dienen direct of indirect de in de Service Catalogus beschreven services te ondersteunen. Er kan aldus een checklist worden opgesteld.

Specifieke leveranciercontracten kunnen leiden tot zinvolle vragen die het niveau van de de Service Catalogus belangrijk kunnen verhogen. Bijvoorbeeld een contract voor onderhoud op printers kan leiden tot de vraag hoe onderhoud op alle IT-middelen is geregeld (in- en extern, voor zowel hardware, software, documentatie, handleidingen, etc.). Op deze wijze kunnen witte vlekken worden opgespoord en gedicht.

Hoewel niet een kwestie voor de Service Catalogus, kan ook hier weer de vraag worden afgeleid welke producten / services worden ingekocht, en welke door intern personeel worden geleverd. Mocht deze vraag zinvol zijn, behandel deze dan verder geheel buiten het hier beschreven traject.

Stap 5. IntegratieDe resultaten uit stap 1, 2, 3 en 4 dienen nu te worden geïntegreerd, eventueel veralgemeniseerd en afgebeeld op het framework.

Stap 6. Toetsing informatieplan en andere strategische en beleidsplannenHoewel een Service Catalogus services beschrijft die op dit moment en in de nabije toekomst kunnen worden geleverd, is een vooruitziende blik uiteraard zinvol. Concreet kan het zinvol zijn om in de Ser-vice Catalogus bij de beschreven services kort te schetsen hoe deze services zich in de toekomst zullen ontwikkelen. Aandachtspunten:

Verwachtingenmanagement speelt hier een rol. Een Service Catalogus is een overzicht van wat van een klant concreet en op dit moment van de IT-organisatie mag verwachten. Door scenario’s of toekomstvisies op te nemen wordt dit principe ondergraven. Te overwegen is in de voor de klant toegankelijke Service Catalogus geen potentiële, toekomstige services op te nemen, maar deze in een intern IT-document te verzamelen.

Te overwegen is om alle services te voorzien van een einddatum voor zover dit relevant is.

Stap 7. Inventariseer afwezige of onvolledige servicesVervolgens wordt de nu ontstane concrete Service Catalogus gescand op ‘witte vlekken’. Bedenk hier-bij dat dit framework tamelijk generiek is. Er kan dus alle reden voor zijn dat bepaalde services niet worden geleverd, en dat de uiteindelijke Service Catalogus ‘slechts’ enkele A4’tjes omvat. De meer-waarde hier is ook gelegen in het feit dat helder wordt welke services bewust niet worden geleverd.Aandachtspunten:

Het verdient aanbeveling services die bewust niet worden geleverd in ieder geval toch te be-noemen. Desnoods kan dit in een separaat intern IT-document, waarin ook de beweegrede-nen kunnen worden opgenomen.

Pas op met het zonder meer invullen van de witte vlekken. Het gaat hier immers om services die kennelijk in de huidige situatie niet worden geleverd (stap 1)en ook niet zijn afgesproken (stap 3 en 4). Slechts na degelijke afweging kunnen hier (deel)services worden toegevoegd.

Stap 8. Feedback / evaluatie en afrondingDe nu ontstane Service Catalogus wordt voorgelegd aan de klanten en representanten van de IT-or-ganisatie. Feedback die hieruit wordt verkregen wordt verwerkt.


8 / 14


Tot slot wordt de Service Catalogus afgerond en ter beschikking gesteld aan de organisatie conform de afgesproken communicatiekanalen.


9 / 14


Uitwerking van het frameworkHierna wordt het framework uitgewerkt.

1. Het Service-frameworkDe door IT te leveren services zijn ondergebracht in een framework. De basisindeling van het frame-work is als volgt:

Se

rvice ob-

ject

Se

rvice ob-

ject

Se

rvice ob-

ject

Se

rvice ob-

ject

Se

rvice ob-

ject

aspect

aspect

aspect

aspect

aspect

Service object: Service die aan een klant worden aangeboden. Aspect: kenmerk van de service. Bijvoorbeeld kwaliteitskenmerken, maar ook functionele en lever-ingskenmerken hebben hier een plaats.

Sommige service objecten hebben een grote “product”-component, andere een zeer geringe. Bijvoor-beeld een applicatieservice heeft als kern uiteraard een applicatie, en ook alle onderliggende software + hardware kan daar naar keuze onder worden geschaard. Echter, het niet niet-tastbare deel van de totale service is hierbij doorgaans aanzienlijk groter. Aan de andere kant worden soms ook losse muizen of beeldschermen geleverd, met slechts geringe aanvullende, niet-tastbare services. De feitelijke situatie is dat bij het merendeel van de IT-organisaties pure producten niet meer voorkomen en hier dus altijd van services kan worden gesproken.

2. Afbeelding op het Service framework


10 / 14

aspect

aspect

aspect

aspect

aspect

objectobjectobjectobject

Services / producten

Activiteiten IT-org.

+ hardware, software etc.


Een IT-organisatie voert activiteiten uit, zet hard- en software in en doet dat ook nog eens op een bepaalde manier. Op een of andere wijze zal alles wat is verzameld moeten worden afgebeeld op de matrix zoals geschetst.

Op het moment dat alle Service objecten en alle relevante aspecten zijn bepaald, resteert slechts een invuloefening. Allereerst wordt hier de bepaling van de Service objecten ter hand genomen.

3. Uitwerking item “Service object”Een service object dat steeds weer boven komt drijven is de “applicatie service”. Hiermee wordt de service bedoeld waarin een applicatie met een bepaalde functionaliteit aan een klant ter beschikking wordt gesteld. Alle benodigde onderliggende soft- en hardware is inbegrepen, alsmede ondersteuning, wijzigingen en advies. Een applicatie service kan op diverse niveaus worden beschreven. Allereerst is het mogelijk dit op ap-plicatieniveau te doen. In voorkomende gevallen kan het ook op moduleniveau of zelfs op func-tieniveau. Andersom kan evenzo: een aantal applicaties kan worden gebundeld tot een service. Afhankelijk van de positie van de IT-orgnisatie en de klant kan hier worden gesproken van deelser-vices, services en fullservices. In dit algemene framework wordt deze onderverdeling niet gehanteerd. De reden hiervoor is dat deze indeling op bepaalde aannames zou berusten die niet algemeen geldend zijn. Aldus zou verwarring ontstaan en dat wordt voorkomen door uitsluitend te spreken over services.

Naast applicatie services zijn services rondom werkplekken en management services zoals strate-gisch advies wellicht van toepassing.

NB. Feitelijk is het juister om te spreken over functionaliteiten in plaats van applicaties. Echter, dit zou meer abstracte beschrijvingen opleveren, die minder duidelijk voor klanten zijn. Vandaar dat er hier is gekozen om te spreken in termen van applicaties.

4. Uitwerking “aspect”Per service object dienen een aantal aspecten te worden benoemd en ingevuld, waarmee het betref-fende service object inhoudelijk wordt beschreven. Bij de bepaling van de juiste aspecten kan worden gekozen uit een verzameling die onder andere reeds is beschreven in het compendium van het IT-be-heer jaarboek 2002.


11 / 14

aspect

aspect

aspect

aspect

aspect

object

object

objec

t


Fu

nctie F

unctie

Mo

dule

Mo

dule

Mo

dule

Fu

nctie

Ap

plica

tie


Een complete rij aspecten om een keuze uit te maken is:

• Bedienbaarheid• Bedrijfszekerheid• Beheersbaaheid• Behulpzaamheid• Beschikbaarheid• Bestendigheid• Betrouwbaarheid• Beveiligbaarheid• Beveiliging• Compleetheid• Continuiteit• Controleerbaarheid• Corrigeerbaarheid• Doelmatigheid

• Doeltreffendheid• Duidelijkheid• Exclusiviteit• Foutbestendigheid• Functionaliteit• Gebruikersondersteuning• Gebruiksgemak• Herbruikbaarheid• Herstelbaarheid• Installeerbaarheid• Instelbaarheid• Integriteit• Inzichtelijkheid• Juistheid

• Koppelbaarheid• Leerbaarheid• Middelenbeslag• Overzichtelijkheid• Portabiliteit• Responsiesnelheid• Schaalbaarheid• Testbaarheid• Traceerbaarheid• Transactiesnelheid• Transparantie• Uitrustingsniveau• Veerkracht

Het behoeft geen betoog dat niet bij elke Service alle apsecten moeten worden beschreven. Een scherpe keuze uit deze set is van groot belang.

5. Transformatie “Aspect” naar “Service object”Een fenomeen dat tot buitengewone verwarring kan leiden is dat “Aspecten” kunnen transformeren tot “Service objecten”. In het schema hierna wordt dit aangegeven. Roemruchte voorbeelden hiervan zijn “security” en “gebruikersondersteuning”. Security kan immers als aspect bij Applicatie services worden beschreven. Het is echter ook af te splitsen en als Security service worden beschreven. Aldus ontstaat een samenstelsel van Service objecten die in eerste instantie grote verwarring kan oproepen. Van groot belang is daarom aan te geven wat waar in het framework is te vinden. Op de tweede plaats di-enen de inhoudelijke beschrijvingen elkaar wederzijds uit te sluiten. Indien Security een apart Service object wordt, dan dienen de applicatie security aspecten ofwel bij “Applicatie services” onder het as-pect “security” te worden beschreven, ofwel bij het Service object “Security services”.


12 / 14

aspect

aspect

aspect

aspect

aspect

object

object

objec

t


capaciteit

responsiesnelheid

wijzigingen

gebruikersondersteuning

herstelbaarheid

exclusiviteit

beveiliging

betrouwbaarheid

beschikbaarheid


Voorbeeld resultaat transformatie:


13 / 14

object

object

aspect

aspect

aspect

aspect

aspect

object

object

objec

t


Applicatie

C

Security

aspect

aspect

aspect

aspect

Gebruikers

-ondersteu-ning

Applicatie

B

Applicatie

A


Aspecten en objecten moeten elkaar wederzijds uitsluiten!


TipsEnige tips die wellicht van pas kunnen komen.

A. Indeling Service Objecten en aspectenHet is sterk aan te bevelen elk Service object op een aparte pagina te beschrijven. Op elke pagina moet vervolgens de indeling van de aspecten zoveel mogelijk eenvormig zijn. Dit bevordert sterk de toegankelijkheid van de Service Catalogus. B. Veel gevraagde ServicesEen klein aantal Services zal vaker worden gevraagd. Het kan heel handig zijn voor deze set Services een aparte pagina voorin de Service Catalogus op te nemen waarin de volgende opsomming staat:

- Hoe kan ik ….- Hoe kan ik…..- Etc.

De toegankelijkheid wordt hiermee verder vergroot.


14 / 14

download

Business

Transcript of download