Sinds de invoer van ITIL v3 is het gat tussen de systeembeheerders (pragmatische mensen die zich 100 procent met operations bemoeien) en de systeemmanagers, die vaak door die beheerders als witte boorden theoretici gezien worden, iets minder groot geworden. In ieder geval, dat zou zo moeten, daar ict-operations nu eenmaal één van de activiteiten is van service operations.
En er is een deel van ITIL v3 wat van groot belang is voor het juist beheren en controleren van een infrastructuur: het serviceportfolio. Onderdeel daarvan, de servicecatalogus, is traditioneel meer een statische catalogus, inzichtelijk voor de gebruiker. Deze gebruikers zijn niet zo geïnteresseerd in 'configuration items' of 'dependencies' van de aangeboden services. In de meeste gevallen wordt dan ook alleen de business-servicecatalogus gehanteerd, één die zichtbaar is voor eindgebruikers, partners ee dergelijke.
Maar hoe belangrijk is het niet voor een operationele afdeling de aangeboden services gecategoriseerd te hebben (production, business function, utility), afhankelijkheden duidelijk in beeld te hebben, welke services voor welke busisness processen zijn, etc.? Soms is zelfs de service-eigenaar niet bekend.
Neem de volgende doelen van de technische servicecatalogus in overweging:
i) Een duidelijk beeld geven van de ict-business-services waar het ict-serviceteam verantwoordelijk voor is.
ii) Een duidelijk beeld verschaffen wat de gebruikers mogen verwachten van deze services.
iii) Een basis verlenen voor het beheer en monitoring van de software- en hardwarecomponenten van de service, om zo te borgen dat deze voldoen aan de businessrequirements.
Eerlijk gezegd lijkt het mij heel moeilijk een reële uptime en availability te garanderen, uitvoerbare SLA’s overeen te komen en eigenlijk een duidelijk en compleet overzicht van de hele infrastructuur te hebben, zonder een complete TSC in huis te hebben. Een TSC met onder andere ook configuration items en waar componenten als delivery channels, service-uren, delivery targets, businessprocessen en afhankelijkheden absoluut deel van uitmaken.
Uiteraard zijn er bedrijven waar deze TSC wel degelijk bestaat, of in ieder geval in zekere mate. Vooral de enterprise zal er aandacht aan besteden. Maar bij bijzonder veel midden en zelfs grotere bedrijven met vaak vele complexe businesslines en honderden servers is dat niet het geval.
Na het opzetten van een uitgebreide statische TSC is de volgende stap de dynamische servicecatalogus. Er is interactie tussen de gebruiker en de catalogus. Self service en dergeljke is hier mogelijk, dat maakt de catalogus uiteraard dynamisch. Een organisatie moet wel voldoende ontwikkeld zijn om een self service toe te kunnen passen. Hierarchische structuren moeten al correct toegepast zijn.
Misschien wordt door het verkleinen van het gat tussen infrastructuur en servicemanagement steeds duidelijker dat een gedetailleerde TSC een zeer noodzakelijk instrument is voor een infra-afdeling.
je bedoelt met TSC een goede CMDB?
Ik denk eerder een Total Social Companionship. Dat ontbreekt ook nogal eens op de werkvloer.
Hallo Jeroen,
Sorry, wat onduidelijk. Neen, ik bedoel de technische service catalog. Gaat toch wat verder dan de CMDB. Vooral daar de TSC ook dynamisch kan zijn, oftewel interactie met de gebruiker en de CMDB voldoet niet altijd aan de drie genoemde doelen.
En Total Social Companionship is ook een goede. Eigenlijk heb ik nooit de techniek als struikelblok ondervonden, doc wel de mens.