Categorieën inrichting servicedesk

[makkie88]

Door een herinrichting van onze servicedesk gaan we een aantal categorieën herinrichten.

Dit kunnen we doen onder categorieën en daaronder Sub-categorieën..

wij werken met een aantal applicatie ontwikkelaars, een (werkplek)Helpdesk en systeembeheer, die eigen categorieën kunnen krijgen..

Ik ben benieuwd hoe jullie de categorieën - en subcategoriën ingedeeld hebben, en dan voornamelijk voor Helpdesk en systeembeheer.

[Question Mark]

Wat is nu precies je vraag? Jullie gaan de bestaande ITIL procedures opnieuw inrichten en zoeken categoriën waarop incidenten, changes en problems geboekt kunnen worden?

Nu ben ik geen moderator in dit forum, maar ik zou dan wel verwachten dat je eerst zelf met een opzet aan komt zetten, dan aangeeft waarover je twijfelt (en vooral waarom). Dan kan er nog een leuke discussie vormen.

Over ITIL en service-requests en procedures is echt ontzettend veel info te vinden. Een goed startpunt voor je zou bijvoorbeeld onderstaand kunnen zijn.

How to come up with categories for our service requests

[R3M1]

Denk ook aan de KPI's die je als gevolg van de her-inrichting wel of niet meer zal gebruiken, ADIR, etc.

[The Eagle]

Doe jezelf een lol en gebruik naast incidents, problems en changes ook operational activities.
Dat geeft je de mogelijkheid ook losse acties vast te leggen (verzoek tot even een bestandje plaatsen bijvoorbeeld, is niet echt een incident te noemen). Maar ook geeft het je de mogelijkheid changes of incidenten in hapklare brokken op te delen voor de diverse afdelingen, zonder dat het bovenliggende incident of change van hot naar het wordt geschoven, met alle vertraging van dien.

[Oberon]

Dat noemen ze een Service Request :-)

[St@m]

Je bent op zoek naar zoiets:
Systeembeheer
- Exchange
- Active Directory
- DNS

(noem maar even wat)

Dat is een inrichting die ik nu niet meer zou gebruiken. Je moet kijken naar je dienstenportfolio naar mijn mening. Je biedt een aantal diensten aan aan je klanten (gebruikers). Bijvoorbeeld een werkplek. Een werkplek kun je onderverdelen in een pc, telefoon, tablet enz. Misschien zelfs bureau en stoel als je Facilitaire dienst ook gebruik maakt van hetzelfde pakket.

Op het moment dat een klant een storing ondervindt aan de werkplek (bijvoorbeeld pc doet het niet), dan log je een call als volgt:
Hoofdcategorie: Werkplek
Subcategorie: PC
Gekoppeld CI: <pcnummer>

Je koppelt je SLA aan de diensten die je aanbiedt.

The Eagle schreef op donderdag 18 september 2014 @ 10:27:
Doe jezelf een lol en gebruik naast incidents, problems en changes ook operational activities.
Dat geeft je de mogelijkheid ook losse acties vast te leggen (verzoek tot even een bestandje plaatsen bijvoorbeeld, is niet echt een incident te noemen). Maar ook geeft het je de mogelijkheid changes of incidenten in hapklare brokken op te delen voor de diverse afdelingen, zonder dat het bovenliggende incident of change van hot naar het wordt geschoven, met alle vertraging van dien.

Operationele activiteiten zijn (terugkerende) activiteiten zoals bijvoorbeeld de logboeken checken, back-ups controleren of de servers voorzien van nieuwe updates. Wat jij noemt zijn inderdaad Service Requests

[ Voor 35% gewijzigd door St@m op 18-09-2014 11:24 ]

[The Eagle]

Oberon schreef op donderdag 18 september 2014 @ 10:33:
Dat noemen ze een Service Request :-)

Nope. Service requests komen vanuit de gebruikersorganisatie. OA's zijn meer voor de IT'ers intern. De naamzegt het al: operationele activiteiten. Een SR kan uiteraard wel een OA opleveren, maar ieder ander type ticket kan dat ook.
Een OA is eigenlijk niks meer dan een hapklare workpackage voor de IT'er: wat moet gebeueren, wanneer, welke randvoorwaarden en afhankelijkheden, etc.

Bij banken en verzekeraars zie je ze veel ivm SOx compliancy: alles moet verantwoord kunnen worden.

[St@m]

The Eagle schreef op donderdag 18 september 2014 @ 11:19:
[...]

Nope. Service requests komen vanuit de gebruikersorganisatie. OA's zijn meer voor de IT'ers intern. De naamzegt het al: operationele activiteiten. Een SR kan uiteraard wel een OA opleveren, maar ieder ander type ticket kan dat ook.
Een OA is eigenlijk niks meer dan een hapklare workpackage voor de IT'er: wat moet gebeueren, wanneer, welke randvoorwaarden en afhankelijkheden, etc.

Bij banken en verzekeraars zie je ze veel ivm SOx compliancy: alles moet verantwoord kunnen worden.

Jij hebt het zelf toch echt over een verzoek..

[makkie88]

op dit moment zitten de categoriën zo in elkaar, waarbij de open bolletjes de Sub-categorieën zijn

 
 Categorie:
Helpdesk
• Software
o Windows
o Office
o Navision
o Internet explorer
o Sun/Java
o Adobe/Reader/Flash

• Werkplek Hardware
o Computer
o Beeldscherm
o Randapparatuur
o Smartphone
o Kabels
o Pda’s

• Account
o AD groep toevoegen
o AD groep Verwijderen
o Account Unlocken
o Account Disablen

• Overige
o Dubbel
o Geen melding
o Informatief

[Question Mark]

Ja, en nu nogmaals.... wat is nu concreet je vraag?

Wat vind je aan deze indeling niet handig, waar lopen jullie tegenaan? Ik kan wel een lijst oplepelen die hier gebruikt wordt, maar die kan totaal onwerkbaar zijn in jullie omgeving.

[righthand]

beste Makkie,

Uitgangspunt voor een Service Desk is de klant. Welke Services zijn met de klant afgesproken en hoe zijn deze Services opgebouwd? M.a.w. welke onderdelen zorgen samen voor een goede en tijdige levering van deze Services? Als het goed is heeft jullie Service (Delivery/Level) Manager een Service Level Agreement met je klanten. Onderdeel daarvan is de Service Catalogus. Dit laatste zou je enigste input moeten zijn voor de primaire inrichting van je categories. Dan begint het echte werk; het opzetten van de processen, workflows en dergelijke in tooling, monitoring en hoofden van je beheercollega's. Vooral dat laatste is belangrijk; 2e en 3e lijn bepalen welke activiteiten onder welke voorwaarden en in welke volgorde voor welke categorie moet worden geleverd. Dus dat zul je vooral in je eigen beheerorganisatie of leveranciers moeten gaan vragen.

Kortom de input van dergelijke categorieën is geen denkoefening maar een overwogen en afgestemde keuze van verschillende processen en stakeholders voortkomende uit verschillende gesprekken en inputsessies. Zelfs na inputvergaring zul je moeten blijven verifiëren of zaken daadwerkelijk goed zijn ingericht. Dit wordt vaak dan door de proceseigenaren gedaan.

Ik hoop dat het een service desk in een kleine organisatie is, anders ben ik bang dat je dit toch flink onderschat en lijkt het me aan te bevelen dat je hierbij professionele hulp bij roept. Desalniettemin; veel succes toegewenst!

[makkie88]

bedankt voorje antwoorden;
k besef me dat er een stuk meer bij komt kijken. ik was opzoek naar voorbeelden van categorieën van eerste/tweedelijns/ werkplekbeheer ondersteuning..
ik ga de door jullie gegeven informatie nog eens grondig bestuderen en kijken hoe ik hierover mijn kennis kan vergroten

[Question Mark]

Beantwoord eerst (voor jezelf) eens de vraag waarom je wilt administreren? Welke informatie (en op welk detailniveau) wil je later terug kunnen vinden/rapporteren.

Als je dat weet, is ook makkelijker te bepalen welke informatie je op moet slaan, en hoe je dit moet gaan categoriseren. Administreren doe je niet om het administreren, het heeft een doel... (anders kun je het net zo goed achterwege laten).