Voordat je overweegt zaken te doen met een organisatie, wil je eerst ontdekken wat zij te bieden hebben.
Je wilt dat diensten en/of producten op een manier worden georganiseerd en beschreven die voor jou – de (potentiële) klant – logisch is. Advocatenkantoren organiseren hun aanbod bijvoorbeeld per rechtsgebied, zoals ondernemingsrecht, familierecht of strafrecht, zodat je direct kunt zien of ze je kunnen helpen bij het registreren van een octrooi. Een kliniek somt de medische specialismen op waarin zij werkzaam zijn en een autodealer toont de types (en merken) auto’s die hij verkoopt.
Het definiëren van diensten: abstractie en detail
Voor het gemak noemen we in deze blog ‘wat een bedrijf te bieden heeft’ een dienst, en ‘het bedrijf’ een aanbieder. Een aanbieder levert één of meerdere diensten. Deze diensten worden beschreven op een abstractieniveau dat logisch is voor de klant (of gebruiker) en worden samengebracht in een verzameling die we de dienstencatalogus noemen.
Ondanks dat hogere abstractieniveau, zijn details belangrijk. Als je je huis wilt beveiligen, ga je op zoek naar een oplossing voor ‘huisbeveiliging’. Zodra je iets vindt dat mogelijk past bij wat je zoekt, ga je inzoomen op de details: hoeveel camera’s zijn inbegrepen, zijn deze draadloos of bekabeld, waar worden de opnames opgeslagen, hoe ontvang je meldingen bij incidenten, enzovoorts. Je start dus met zoeken op een hoger niveau van abstractie en zoomt vervolgens in op de details.
In een restaurant blader je door het menu op zoek naar een gerecht (dienst) dat je aanspreekt. Daarna kijk je naar de ingrediënten en hoe het gerecht bereid wordt. Als je iets specifieks wilt bestellen, geef je eerst het gerecht aan en daarna de afwijking ten opzichte van het menu. Dus: je wilt de Griekse salade, maar zonder de olijven. De dienst is het centrale onderwerp van het gesprek tussen aanbieder en klant.
De IT-kloof: ingrediënten versus diensten
Hoe logisch en vanzelfsprekend dit ook klinkt, veel IT-organisaties worstelen nog steeds met dit simpele concept. Ze communiceren liever over de ingrediënten van hun diensten (zoals hardware, applicaties en netwerkverbindingen) dan over de dienst zelf.
Als je op een school werkt en verantwoordelijk bent voor het maken en onderhouden van het lesrooster, dan zou een dienst met de naam ‘Roostering’ waarschijnlijk heel logisch voor je zijn. Wanneer de applicatie ‘Classroom Scheduler 2.0’ om wat voor reden dan ook wordt vervangen door ‘Schedule Guru 2020’, verandert de naam en het doel van de dienst niet. De planner hoeft niet te weten dat de vorige applicatie een aparte server en database nodig had, terwijl de nieuwe een clouddienst is.
De oplossing: een klantgerichte benadering
De eerste stap om de kloof tussen een IT-organisatie en haar klanten te dichten, is het definiëren van diensten en het verbergen van complexiteit waar die geen toegevoegde waarde heeft. Zoek naar een bruikbare segmentatie van je gebruikers, bijvoorbeeld op basis van bedrijfsfunctie of afdeling, en beschrijf vervolgens welke functionaliteit je daadwerkelijk aanbiedt – op een abstractieniveau dat voor die gebruikers logisch is.
Je zou dan uit kunnen komen op diensten zoals financiën, salarisadministratie, relatiebeheer, kwaliteitsmanagement of roostering. Combineer deze met generieke diensten zoals werkplekbeheer, e-mail, netwerktoegang en documentbeheer, en je bent goed op weg.
In een vervolgartikel zullen we verder inzoomen op het concept van subdiensten en de rol van de CMDB (Configuration Management Database) binnen deze structuur.