Registratiesysteem - Categorisatie & Diensten

[n00bs]

Ik ben op dit moment betrokken bij een discussie t.b.v. categorisatie en diensten in ons registratiesysteem voor incidenten, changes, etc

Als ICT dienstverlener bieden wij veel verschillende diensten aan, aan veel verschillende type klanten.
Op dit moment hebben wij een inrichting met een categorisatie die deels logisch en grotendeels niet.

De vraag initieel al is eigenlijk: wat is een goede categorisatie met sub-categorisatie.

Als voorbeeld zou "E-mail" een hoofdcategorie kunnen zijn

Diensten die aan die E-mail cat. hangen zijn bijvoorbeeld:
- aanvragen/wijzigen van een shared mailbox
- uitbreiding van mailquota
- spamfiltering
- etc

Daarbij zit ik al gelijk met de vraag wat in dit geval de bijbehorende subcat. zou kunnen zijn en of de diensten het beste opgenomen kunnen worden als: shared mailbox, mailbox quota. Of dit specifieker doen Aanvragen... Opheffen... Muteren.... van ?

Sommigen komen met het idee om de subcat. gelijk te maken aan de dienstnamen, een ander weer met het idee om de subcat. afhankelijk te maken van de klantgroep, etc. Echter naar mijn mening allemaal onjuist. Helaas zit ik hiermee opgescheept en is het notabene niet mijn rol om met een oplossing te komen.

Probleem natuurlijk is dat er geen BESTE keuze is, maar er wel rapportages, doorbelastingen etc uiteindelijk aan komen te hangen. Ik snap ook dat het mini voorbeeldje hierboven zonder goede business case niet echt duidelijk is, maar hoop toch dat er mensen hier zijn met ervaring met inrichten van diensten en hoe dit zich verhoudt t.o.v. een duidelijke categorisatie.

Dat laatste moet gewoon duidelijk zijn, omdat een Helpdesk dit selecteert en op basis van die keuze ook de juiste diensten naar voren moeten komen.

[ Voor 9% gewijzigd door n00bs op 28-09-2016 14:38 ]

[PolarBear]

Mijn ervaring is dat mijn probleem altijd net niet in een categorie past omdat mijn probleem net iets complexer is dan de problemen die verzonnen zijn. En vervolgens wordt ik wel gedwongen een categorie te kiezen.

[Mopshondje]

Bij ons op het werk zitten wij met een vergelijkbaar probleem, dus ik lees even mee

Echter denk ik beter dat je i.p.v een categorie zoals E-mail beter kunt onderbrengen in het "Object ID".
Waardoor je toch iets uitgebreider je rapport kunt uitdraaien, en je categorieën niet eindeloos worden.

En dan inderdaad voor specifieker gaan zoals je beschrijf aanvragen, opheffen en muteren van -> Object ID.

[righthand]

Tip: denk in services zoals de klant/eindgebruiker ze beleeft. Categoriseer niet vanuit techniek. Ga dan kijken hoe de klant ze gebruikt en welke primaire middelen ze daarvoor gebruiken.

Ik zeg dit omdat uiteindelijk de Service Catalogus (standaarden van services en dus vaststaand) wordt gecombineerd met de SLA (met welke KPI's worden de Services geleverd, dus flexibel) en dit moet worden geleverd door de operatie. Dit is je basis waarop je alle andere processen laat volgen.

Dus kijk bij welke Service het hoort. Is het generiek en dus ondersteunend aan alle diensten, dan categoriseer je dit dan ook als een generieke interne Service die je niet direct biedt aan de eindgebruiker, maar wel aan bijvoorbeeld werkplekbeheer, die dan hun services biedt aan de eindgebruiker

[St@m]

De vraag die je moet stellen is: Waar moet op gerapporteerd worden. Wil het MT weten hoeveel shared mailboxen er zijn aangevraagd? Of willen ze weten of de maildienst die ze aanbieden aan de medewerkers goed werkt?

Ik ben altijd voorstander van het inrichten op dienstniveau.

Soort melding: Incident
Object: betreffende laptop
Categorie: Werkplek
Subcategorie: Laptop

Bovenstaande manier is mijns inzien de beste manier, maar werkt uiteraard alleen maar als je een uitgebreide CMDB hebt.

Alle onderdelen van je omgeving zet je dus in de CMDB. Dus ook een spamfilter.
Een gebruiker zal kunnen melden dat die wel erg veel spam krijgt, dat is dan een incident.

Soort melding: Incident
Object: Spamfilter
Categorie: Applicatie (als het een softwarematig ding is, geen verstand van )
Subcategorie: Technisch

Hieruit volgt uiteindelijk een wijziging (als het goed is). Een eenvoudige wijziging waardoor het spamfilter wordt aangepast (noem maar even wat).

Een MS Office vraag zou je kunnen registreren als:
Soort melding: Vraag
Object: MS Office
Categorie: Applicatie
Subcategorie: Functioneel

Dus ga na welke diensten je aanbiedt aan je klanten, denk aan:
Een werkplek (pc/laptop, telefoon, toetsenbord, muis)
Een infrastructuur (bekabeling, wall outlets, servers, routers, switches)
Een printomgeving (de printers, scanners, faxen)
Een applicatieomgeving (functioneel en technisch)

En zo zijn er vast wel meer diensten. Maar de hoofdvraag is: Waar moet op gerapporteerd worden, en hoe richten we dat het handigst in. En met bovenstaande voldoe ik altijd aan de wensen van welk MT dan ook.

Wat ook van belang is, is dat na het oplossen van een incident / beantwoorden van een vraag de melding indien nodig geherclassificeerd wordt. Bijna geen één IT organisatie doet dit, dus het management zal altijd met onjuiste informatie opgescheept worden.

[ Voor 23% gewijzigd door St@m op 29-09-2016 14:11 ]

[Lensent]

Daarnaast wil je het natuurlijk ook werkbaar houden voor de Service Desk.
Niet dat ze 10 velden in moeten vullen voordat een melding eindelijk is aangemaakt.

Verder eens met St@m.

[n00bs]

St@m daar heb je inderdaad hele goede punten, echter is bij ons de CMDB een puinhoop en wordt er ook as we speak nagedacht op een hoger niveau over de CMDB inrichting, dat betekent dus dat we nu een inrichting moeten kiezen tbv de diensten en dienstencatalogus met een goede cat. inrichting en daarbij gekoppelde diensten zonder nog gebruik te maken van de CMDB, maar op zo een wijze dat die achteraf nog naadloos kan samengaan.

Ik ben echter bang dat die CMDB inrichting eerst goed bepaald had moeten zijn.

[St@m]

n00bs schreef op vrijdag 30 september 2016 @ 11:34:
St@m daar heb je inderdaad hele goede punten, echter is bij ons de CMDB een puinhoop en wordt er ook as we speak nagedacht op een hoger niveau over de CMDB inrichting, dat betekent dus dat we nu een inrichting moeten kiezen tbv de diensten en dienstencatalogus met een goede cat. inrichting en daarbij gekoppelde diensten zonder nog gebruik te maken van de CMDB, maar op zo een wijze dat die achteraf nog naadloos kan samengaan.

Ik ben echter bang dat die CMDB inrichting eerst goed bepaald had moeten zijn.

Klopt, je CMDB is de basis van je dienstverlening. Als je niet weet wat je hebt kun je er ook geen diensten op leveren.