Workflow servicedesk in de enterprise

[axis]

Ik denk dat PNS het beste subforum is voor deze vraag, omdat ik wil weten wat jullie ervaring is als professionals in de IT in de omgang met de inrichting van een servicedesk, incidentmanagement, etc. Hoe eenmanszaakjes en mkb hun zaken regelen weet ik ondertussen wel.. Als het ergens anders beter past, graag verplaatsen

Ik wil niet zozeer weten WAT voor jullie tools gebruiken, daar kan ik zelf ook wel uit komen, maar vooral HOE jullie je tools en workflow gebruiken, en wat de achterliggende gedachte is.

Even wat achtergrond
Ik werk nu 11 jaar bij een IT bedrijf dat gegroeid is van 3 man naar 50 man over meerdere vestigingen. Ik was de eerste systeembeheerder, en 5 jaar geleden is de 2e systeembeheerder erbij gekomen. We doen nu al het beheer met z'n tweën. Het bedrijf is een IT-bedrijf dat grote webapplicaties maakt. Het werk dat we doen is een paar werkplekjes beheren, faciliteitsbeheer, maar voornamelijk beheer van ongeveer 350-400 servers.

We lopen nu tegen het probleem aan dat er teveel werk is voor 2 man, dus we zijn extra collega's aan het zoeken. Daarnaast ga ik zelf parttime werken, en veelal dingen van thuis doen. Communicatie wordt dus nog belangrijker.

De huidige werkwijze is als volgt: We hebben nu 1 emailadres, [e-mail], waarop alle nieuwe verzoeken uit komen. Deze komt in de mailbox van beide systeembeheerders. Wij, de systeembeheerders, kijken elkaar aan en beslissen wie welk taakje opneemt. Dit gaat natuurlijk in de toekomst niet meer werken.

De taken die langer duren dan ~15 minuten worden in SharePoint gezet, en van daaruit wordt dan gewerkt. 75% van de taakjes is echter kortdurend (firewall rules aanpassen, TL-balk vervangen, etc), en dat in SharePoint zetten geeft teveel overhead. De 'werkbak' per medewerker is dus zijn lokale emailbox. Daar ben ik niet echt blij mee.

Daarnaast komt er op het gezamelijke emailadres (=distributielijst dus) ook nog dagelijks rapportjes binnen van allerlei backupsoftware, cron jobs, yum rapportjes, etc. Die worden doorgelezen, en af en toe moet er actie worden ondernomen, bijvoorbeeld als een backup is foutgegaan. De andere rapporten worden bewaard ter referentie.

Daarnaast hebben we ook nog Nagios, ons monitoring systeem, die storingen verstuurt via sms en email naar elke systeembeheerder.

Wat nu
Wat ik van plan ben, is een ticketsysteem opzetten (eerst eens spelen met RT, of een ander ticketsysteem, TopDesk+consultancy is ook nog een optie), zodat alle binnenkomende emails en telefoontjes worden geregistreerd, en systeembeheerders taakjes kunnen oppakken uit het ticketsysteem. Het is wel voor iedereen inzichtelijk wat er voor werk ligt.

Alle taken van SharePoint worden overgezet naar het ticketsysteem, zodat dat werk ook daar inzichtelijk is. (betreft momenteel 170 taken, waarvan sommigen al 3 jaar wachten).

Maar hoe om te gaan met bijvoorbeeld storingsmeldingen, en al die dagelijkse rapportmailtjes? Die kunnen natuurlijk ook allemaal in het ticketsysteem lopen, maar dan krijg ik 10-100 onzintickets per dag waarvan ik dan weer 98% moet sluiten. Ik kan natuurlijk ook alle rapportjes naar een aparte folder laten lopen en iemand de opdracht geven deze dagelijks door te lezen. Maar we weten allemaal hoe dat werkt, zoiets raakt na een tijdje toch weer in het slop.

Daarnaast willen we ook nog mensen op bijvoorbeeld een ITIL cursus sturen zodat ze vertrouwd raken met de concepten van incidenten en change requests, wat is een 1e lijns en 2e lijns, etc. Ik roep ook maar wat, ik weet ook niets van ITIL.

Jullie?
Wat zijn jullie ideën bij bovenstaande? Hoe hebben jullie e.e.a. ingericht? Waar zijn jullie tegenaan gelopen? Waarom hebben jullie bepaalde keuzes gemaakt? Ik zie jullie antwoorden of feedback graag tegemoet!

[Remco]

Als ik het zo lees zou ik eerst zelf op een ITIL cursus gaan.

Daarna zou ik een goed service desk pakket kiezen. Al je wensen eisen en workflow worden afgevangen in een dergelijk pakket. Laat voor de lol eens iemand van Topdesk langskomen, dan krijg je een indruk of een dergelijke tool je kan helpen. Ja, sommige kosten een beetje. Maar brengen ook weer geld op.

Dan wat betreft je storingsmeldingen. Schijnbaar krijg je meldingen die geen storing zijn, anders noem je ze geen onzintickets en sluit je ze meteen af.
Je moet dus je monitoring tool wat betreft escalatie beter inrichten.

[Thijs B]

lol dus ik ben niet de enige die dagelijks nog tegen openstaande punten uit 2009 aankijkt

Als je met 2 man het beheer doet lijkt mij de omschakeling naar een ticket systeem niet zo'n probleem, het is meer je gebruikers die daar soms even aan moeten wennen.

Ik ben zelf al jaren zeer tevreden met Servicedesk van ManageEngine, we hebben nog een jaren oude versie maar voldoet prima.

Alle dagelijkse logjes zou ik nooit forwarden naar een ticket systeem tenzij ze dus danig belangrijk zijn dat je ze per dag moet bekijken en dan dus ook in je ticket wilt registreren wie het heeft afgehandeld.

[Pogostokje]

Zorg dat je van dingen die goed gaan geen meldingen krijgt. Bewaar het ergens, voor referentie later, maar breng je monitoring op orde op dat punt. Gebruik tools die de uitvoer van je jobs kan monitoren of iets dergelijks. Besteed alleen aandacht aan dingen die NIET goed gaan. Hoe meer troep je in je ticket systeem hebt, hoe minder serieus het genomen gaat worden. Handmatig doorworstelen van die dingen is nogal raar als je zelf in de IT werkt en juist dingen moet automatiseren.

Een goede ticket tool is een hulpmiddel, je processen eromheen moet je nog steeds zelf op order brengen. ITIL kan je helpen structureren en prioriseren en het brengt wat best-practises met zich mee ... maar na de cursus heb je niet opeens op magische wijze een efficient werkende afdeling, maar dat spreekt voor zich.

Vaak begin je ergens met wat IT'ers vaak niet zo leuk vinden: het afspreken van doorlooptijden. Ja, dat kan voor alles en nee, dat betekent niet dat je nooit iets onverwachts mag hebben wat dagen duurt. Je klant (externe en interne klanten) zal daar om vragen (als ze professioneel zijn) of het waarderen (als ze daar nooit over nagedacht hebben). Dat levert je informatie op waaruit bijvoorbeeld aantoonbaar blijkt dat jullie met te weinig man werken, en tevens is het een begin voor de inrichting van je ticket systeem om onderscheid te kunnen maken tussen 'komt volgende week wel' en 'shit ik lunch later wel' -werkjes.

[akimosan]

Voor iets dergelijks kleins zou ik eens kijken/beginnen met bijvoorbeeld Spiceworks dat is snel en simpel op te zetten en bevat eenvoudige monitoringtools, rapportagetools en ticketsysteem inclusief eindgebruikersportal.

Uitgebreider en open source is bijvoorbeeld OTRS

Voor het inrichten van bijvoorbeeld servicelevels en SLA's e.d. zou ik dan wel een cursus gaan doen. Zoals eerdee genoemd zou ITIL een goede optie zijn om bekend te raken met de processen en procedures die bij het gebruik van een servicedesk tool komen kijken.

Kijk ook uit met het binnenhalen van externe consultancy: voor je het weet wordt je in je hemd gezet door een paar ijverige consultants die een analyse aan het management voorschotelen met als conclusie dat het "..een godswonder is dat de tent nog draait met 2 van zulke systeembeheerders..."

Daarme wil ik niets zeggen over jullie kwaliteiten maar het inzetten van een ITIL tool legt ook behoorlijk wat pijnpunten bloot waar je nu misschien nog niet over hebt nagedacht

[axis]

Alvast bedankt voor jullie reacties, ik neem ze mee in de overwegingen hier

[CH4OS]

Hou er rekening mee, dat áls je ITIL gaat implementeren binnen het bedrijf, dat ITIL niet de heilige graal is, maar meer een handleiding hoe je dingen kan doen binnen de ICT. Het is dus geen beschrijving van "hoe het moet".

[erwinb]

Pogostokje schreef op vrijdag 22 april 2011 @ 12:50:
Zorg dat je van dingen die goed gaan geen meldingen krijgt. Bewaar het ergens, voor referentie later, maar breng je monitoring op orde op dat punt. Gebruik tools die de uitvoer van je jobs kan monitoren of iets dergelijks. Besteed alleen aandacht aan dingen die NIET goed gaan.

zorg wel dat er een tool actief is die in de gaten houd dat de meldingen van systeem XYZ uberhaubt wel binnenkomen.

[Plopeye]

Kijk ook eens naar HESK, een best wel mooi gratis pakket op basis van PHP/MySQL.

http://www.hesk.com/

Heeft een online systeem voor ticket intake, gebruiker wordt automatisch op de hoogte gehouden via mail van status wijzigingen en je kan er de nodige cijfertjes uit trekken....

[ Voor 46% gewijzigd door Plopeye op 10-05-2011 07:23 ]

[morphje]

Stapje voor stapje, dat is toch zo'n beetje wel het correcte advies.

Begin bij IndicentManagement, en zodra je dat kunstje doorhebt, ga dan verder met een ConfigurationManagementDataBase opzetten. Pas na het hebben van deze 2 componenten kan je pas beginnen aan ProblemManagement en ConfigurationManagement.

Ikzelf geef trouwens wel voorkeur aan een zo goed mogelijk opgezette CMDB, liefst in een toegankelijk en uitbreidbaar formaat. Hiermee kan je heel gemakkelijk zaken exporteren naar andere componenten als automatic inventory management en configjes eruit gooien voor Nagios en Cacti.

Respect trouwens voor een team van 2 man om zoveel servers te onderhouden. Kan je wel voorstellen dat je meer mankracht nodig hebt. Hoewel een goed ingerichte nagios (er zijn ook anderen natuurlijk ) heel veel kan helpen om snel problemen te pinpointe

[morphje]

axis schreef op woensdag 20 april 2011 @ 10:28:
De taken die langer duren dan ~15 minuten worden in SharePoint gezet, en van daaruit wordt dan gewerkt. 75% van de taakjes is echter kortdurend (firewall rules aanpassen, TL-balk vervangen, etc), en dat in SharePoint zetten geeft teveel overhead. De 'werkbak' per medewerker is dus zijn lokale emailbox. Daar ben ik niet echt blij mee.

Zelf dingen in sharepoint zetten is per definitie al te veel overhead. Maak gebruik van de mensen die het werk insturen. En inderdaad een emailbox als werkbak is niet efficient, want dan raken er dingen weg. Daarintegen is elke taak belangrijk om te documenteren, inclusief het veranderen van firewall regels (voor je config management en als je back-up gefaald heeft)

Daarnaast komt er op het gezamelijke emailadres (=distributielijst dus) ook nog dagelijks rapportjes binnen van allerlei backupsoftware, cron jobs, yum rapportjes, etc. Die worden doorgelezen, en af en toe moet er actie worden ondernomen, bijvoorbeeld als een backup is foutgegaan. De andere rapporten worden bewaard ter referentie.

Daarnaast hebben we ook nog Nagios, ons monitoring systeem, die storingen verstuurt via sms en email naar elke systeembeheerder.

versturen naar je ITIL systeem en daar onderverdelen. Probleem met een distributielijst zonder toezicht is dat niemand zich verantwoordelijk voelt. dit probleem neemt alleen maar toe naarmate de lijst groter groeit. Nu misschien niet een probleem, maar wel als je groeit. Wat je nu wel hebt is een lijst van issues, indien beheerder A binnen 3 dagen niet de boelt afhandeld kan je er op handelen.

Maar hoe om te gaan met bijvoorbeeld storingsmeldingen, en al die dagelijkse rapportmailtjes? Die kunnen natuurlijk ook allemaal in het ticketsysteem lopen, maar dan krijg ik 10-100 onzintickets per dag waarvan ik dan weer 98% moet sluiten. Ik kan natuurlijk ook alle rapportjes naar een aparte folder laten lopen en iemand de opdracht geven deze dagelijks door te lezen. Maar we weten allemaal hoe dat werkt, zoiets raakt na een tijdje toch weer in het slop.

Een storing IS een ticket en dient afgehandeld te worden en juist daarom is het geen onzin. Tenzij je een overhead in meldingen hebt die onzin creeeren, maar dat lijkt me meer het africhten van Nagios. Een event-handler op allhosts is wellicht wat overdreven. En indien je nagios laat kijken naar calls > 3 dagen geen antwoord is een melding over de melding wat overdreven om een ticket van te ontvangen

Ook je backup meldingen moeten nagelezen worden, elke dag weer, laat de verantwoordelijke er maar voor aftekenen. Je hebt dan wel een "chain of evidence". En wellicht is het handig om bij de 20ste melding van de raidkaart eens te gaan onderzoeken wat nu daadwerkelijk het probleem is (problem management )

Klinkt wel allemaal heel erg formeel, maar het biedt je veel meer inzicht in het werk wat je nou daadwerkelijk afhandeld.

[Flyduck]

Wij werken met Topdesk en het is wat prijzig maar het werkt wel erg goed, en veel rapportage mogelijkheden. Zeker het overwegen waard.

[ Voor 38% gewijzigd door Flyduck op 11-05-2011 21:04 ]

[Verwijderd]

Grappig dat mensen hier allerlei pakketten zitten voor te stellen zonder dat iemand in detail weet hoe de omgeving eruit ziet, wat men verwacht van de "standardisatie", etc...

Dit is een fout die je nu zeker niet mag maken. Vooral nu je een zekere vorm van professionalisering gaat invoeren is het belangrijk dat je niet onmiddellijk concreet gaat werken, maar eerst abstract gaat nadenken over welke processen er binnen jullie bedrijf aanwezig zijn en op welke manier je hierin een standaard kan gaan invoeren.

Al snel zal je bij ITIL uitkomen. Ik raad je aan om hier eerst eens een goed boek over te lezen of eventueel een cursus over te volgen. Wanneer je de basisconcepten (zoals incident management, problem management, change management en asset management) onder de knie hebt, zal het zaak zijn om je bedrijfsprocessen in kaart te brengen en te koppelen aan de ITIL concepten.

Waarschijnlijk zal er overleg gepleegd moeten worden met de bedrijfsleiding en eventueel de andere collega's. Misschien ook een goed moment om eens na te denken over SLA's? Is het bv. wel nodig dat er een extra kracht bijkomt zodat elk brandje binnen 30 minuten geblust is?

Als je dit alles op papier hebt, kan je misschien eens beginnen kijken hoe je dit in de praktijk kan implementeren (maw welk pakketje )

Nu is het aan jou