Vraag Prioritering van aanvragen in een kleine IT-afdeling [gesloten]


Ik ben op zoek naar ITSM in een IT-afdeling van twee personen. We hebben een webgebaseerd workflowsysteem waarbij vijf aanvraagtypen zijn gedefinieerd die op onze afdeling terechtkomen. De reden achter de verdeling van de aanvraagtypen is in feite voor categorisering, maar de gebruikers begrijpen vaak niet welk verzoektype moet worden gekozen.

Ik ben van plan om het systeem te vereenvoudigen door slechts één aanvraagtype zichtbaar te maken voor de gebruikers en vervolgens zullen we het type indien nodig wijzigen. Maar in plaats van te scheiden op technisch gebied (de huidige aanvraagtypen zijn Computerondersteuning, Webondersteuning, ERP-ondersteuning, CRM-ondersteuning en Ondersteuning van analisten), denk ik dat het beter is om te scheiden in een incident, probleem, wijzigingsverzoek en serviceverzoek. De oude manier van categoriseren zal worden vervangen door het koppelen van elke aanvraag aan een project dat de bijbehorende dienst vertegenwoordigt, en dit zal door ons worden gedaan in plaats van door de gebruikers.

Ons werkstroomsysteem geeft nu alle aan u toegewezen aanvragen in één gigantische lijst weer. Het is mogelijk om de velden aan te passen die worden weergegeven, zodat u kunt zien welke incidenten versus wijzigingsverzoeken zijn. Ik heb overwogen om mijn eigen frontend te schrijven om elk verzoektype in een aparte groep op het scherm te plaatsen. Dit deed me vragen stellen over prioritering van verzoeken. Aan elke aanvraag wordt een prioriteit toegekend tussen 1 en 5, dus een prioriteit 1 wijzigingsverzoek is belangrijker dan een prioriteit 3 ​​wijzigingsverzoek. Maar is een Prioriteit 2-incident belangrijker dan het Prioriteit 1 Wijzigingsverzoek omdat het een incident is? Omdat er maar twee van ons zijn op de afdeling, denk ik niet dat we tijdens een incident aan veranderingsverzoeken kunnen werken. Ik ben altijd van mening geweest dat je dingen moet repareren die kapot zijn voordat je iets nieuws bouwt. Of ga ik hier lunchen? Moeten we het verzoektype en het werken alleen op basis van het prioriteitsniveau negeren?

Als ik de goede weg op ga met alle incidenten voorrang te geven op al het andere, hoe zou ik dan prioriteit moeten geven aan de andere aanvraagtypes? Mijn aanvankelijke neiging is om volgende serviceverzoeken te doen omdat ik verwacht dat ze vrij snel zijn, gevolgd door wijzigingsverzoeken en tot slot problemen. Ik ben echter enigszins bezorgd dat ze nooit problemen zullen onderzoeken door problemen op te lossen. Misschien moet de order Incident, Service Requests, Problems, Change Requests zijn?


5
2017-08-06 14:36


oorsprong


Alleen mijn 2p hier, maar dat lijkt een machtige ingewikkelde opstelling voor een 2-man afdeling. - Ben Pilbrow
Ik ben het met Ben eens: dit klinkt alsof je meer tijd gaat besteden aan het indelen van je werk dan dat je eraan besteedt. Een wachtrij moet dit doen, samen met een tijdmanagementsysteem waarmee u projectwerkzaamheden kunt uitvoeren, ongeacht de huidige problemen of incidenten. - Sven♦
@Scott - Alleen voor context, ik ben ook in een 2-man IT-afdeling. We hebben een standaard ticketingsysteem met een aantal brede categorieën (Algemeen / overig, Printer, PC Hardware, Outlook, internet enz.) En het is in principe zo dat we tickets kunnen koppelen aan bezittingen en mensen en notities kunnen achterlaten, voor het geval iemand van ons nodig heeft neem het ticket over. We hebben geen dingen zoals incidenten, problemen, wijzigingsverzoeken. Het basisidee is dat iedereen die zijn werk niet kan doen een prioriteit is, dan mensen die vervelende problemen hebben, maar nog steeds in staat zijn om te werken, dan andere willekeurige stukjes en beetjes, dan projecten. - Ben Pilbrow
Mijn beste advies is om iets relatief eenvoudigs te proberen en te zien hoe het gaat. Als het moet worden aangepast, doe dat dan en voer het een tijdje uit. Was, spoel en herhaal totdat je iets hebt dat voor jou werkt. Probeer je processen niet te laten passen rond iets anders, wees erg egoïstisch en doe alles wat het gemakkelijkst en het meest productief is voor jou en je afdeling om dingen gedaan te krijgen. - Ben Pilbrow
Zorg ervoor dat je niet met het puntige haar in de gaten houdt. je bent manier dingen overbruggen (en dit komt van iemand die sympathieën dingen om sterk te worden beheerd). - womble♦


antwoorden:


Ik wilde dit gewoon in opmerkingen achterlaten, maar eigenlijk ga ik een antwoord plaatsen, want hoewel ik denk dat je goede bedoelingen hebt, denk ik dat je het op een ingewikkelder manier gaat doen dan nodig.

Het is goed dat u een soort ticketsysteem plant en ik ben van mening dat het voor iets meer dan ongeveer 20 computers een goed idee is om dingen bij te houden. Waar u rekening mee moet houden, is dat helpdesksystemen in vele soorten en maten beschikbaar zijn, variërend van een verrijkte lijst met kaartjes tot zeer gecompliceerde systemen met vele categorieën, prioriteiten, toegewezen personen, escalaties, SLA's en tientallen andere toeters en bellen. Hoe groter en meer gescheiden uw IT-afdeling is, des te meer voordeel hebben deze meer gecompliceerde systemen, maar voor kleinere afdelingen kunnen ze meer een belemmering zijn dan wat dan ook.

Ter vergelijking: ik werk ook op een IT-afdeling van 2 man en doe dus een beetje van alles, dus teveel verschillende opties op de helpdesk zouden me gewoon in de weg zitten. We hebben een relatief eenvoudige, in eigen land ontwikkelde helpdesk met een kant van de gebruiker en een technicus die kant op kijkt.

De zijde van de gebruiker heeft een minimaal aantal velden om ze niet af te schrikken met informatie-overload (titel, categorie, prioriteit, getroffen activatag, probleemomschrijving). Alle IT-problemen worden hier vastgelegd, we hebben geen verschillende systemen voor wijzigingsverzoeken, serviceverzoeken enz. Onze categorieën zijn ook opzettelijk breed, opnieuw om verwarring te voorkomen (computerhardware, printerprobleem, Outlook, internet, algemeen / Overig).

De kant van de technicus heeft nog een paar velden, maar is nog steeds niet erg ingewikkeld (rechtverkrijgende, status, follow-updatum). Het biedt ons voldoende flexibiliteit om tickets te categoriseren (voornamelijk voor rapportagedoeleinden) maar staat niet echt in de weg om het probleem daadwerkelijk op te lossen. We kunnen opmerkingen achterlaten op het ticket en laten zien wat we hebben gedaan. Als een van ons moet werken aan de andere tickets, weten we wat al is gedaan.

Het belangrijkste doel van onze helpdesk is om de problemen bij te houden die onze assets hebben (en wie de tickets maakt), zodat we kunnen zien welke assets het meest hinderlijk zijn of welke mensen mogelijk trainingseisen hebben. We hebben niets gecompliceerds zoals het indelen van incidenten, problemen, serviceverzoeken, wijzigingsverzoeken, enz. - dat zou voor ons niet nodig zijn, alles komt binnen als een ticket en we behandelen het op gepaste wijze.

Als u een vergelijking van prioriteiten wilt, zijn die van ons over het algemeen als volgt. De gebruiker heeft de mogelijkheid om een ​​prioriteit in te stellen bij het maken van het ticket, maar we hebben ook de mogelijkheid om het opnieuw uit te lijnen met de realiteit (we kennen allemaal één gebruiker die prioriteit 1 kaartjes maakt voor werkelijk alles: P).

  1. Iedereen die niet in staat is om te werken
  2. Iedereen die een probleem heeft maar nog steeds in staat is om te werken
  3. Algemene dagelijkse dingen en willekeurige dingen gooiden onze kant op
  4. Project Werk

Kortom, ja, je zou waarschijnlijk een soort helpdesksysteem moeten implementeren, maar misschien niet zo ingewikkeld als je in je vraag beschrijft. Uiteindelijk moet u elke dag met dit systeem communiceren, dus het moet zo gestroomlijnd en gebruiksvriendelijk zijn als praktisch voor u is. Laat het proces voor je werken, probeer niet om te werken met een proces dat is ontworpen voor tientallen IT-afdelingen. Als je niet tevreden bent met een deel van het proces, verander het dan een beetje en zie hoe dat gaat en blijf het verfijnen totdat je blij bent dat het efficiënt voor je werkt.


5
2017-08-06 16:45



Dit is ongeveer hoe we nu werken, maar we hebben het nooit expliciet als zodanig vermeld, dus het voelt alsof we elke dag op de stoel van onze broek vliegen. - Scott