Past IT Service Management bij mijn eisen en wensen?

[Jeremy]

Must-haves	·         Het ticketingsysteem is bruikbaar op de computer. ·         De inrichting van het ticketingsysteem is logisch en aan te passen. Er moet iemand zijn die ervaring heeft als owner van het ticketingsysteem en alles hierin regelt, inricht en beheert. Diegene moet zich er verantwoordelijk voor voelen. De functionaliteiten moeten op een logische plek staan zodat eindgebruikers snel ingewerkt zijn. ·         Melding in de werkmail dat er een nieuw ticket is of wijziging in het ticket.
Should-haves	·         Verschillende dashboards kunnen toepassen zodat eindgebruikers verschillende dashboards zien zonder dat dit extra kosten met zich meebrengt. Voor o.a. de administrator – Service Desk ·         Opmaak in een ticket kan aangepast worden. Verplichte/overbodige kolommen bij het afhandelen van tickets aan kunnen vinken. ·         Het kunnen maken van tabellen met cijfers, maar ook visuele modellen over de voortgang; een integratie naar de financiële applicatie (Twinfield) is belangrijk. ·         Het ticketingsysteem heeft een koppeling naar Outlook. Hiermee kunnen meldingen naar de e-mail worden gestuurd. ·         Melding in de werkmail dat er een nieuw ticket is of wijziging in het ticket. Daarnaast bevat de mail informatie over het ticket(nummer) of de klant aan wie het ticket is gekoppeld.
Could-haves	·         Op het moment dat de klant reageert met een notitie/email, dat de status van het ticket wordt aangepast. Dit kan geautomatiseerd worden. ·         De ticket-types ‘changes’ en ‘problems’ kunnen apart gedocumenteerd worden. Op dit moment wordt dit gedaan door het ticket-type ‘incidents’ te gebruiken. Bijvoorbeeld; een change is een wijziging in een IT-service of hardware bij een klant. Als dit goed wordt gedocumenteerd is het veel makkelijker terug te halen in het systeem. Een problem incident is een vaker voorkomend probleem bij een klant; je maakt een koppeling met een incident aan en je gaat uitzoeken waarom deze incidenten plaatsvinden. Vervolgens los je het op. Meerdere ticket incidenten hang je aan een problem. Als het probleem is opgelost en de oorzaak is er, dan sluit je het probleem en dan worden alle incidenten ook meteen gesloten. ·         Een functie of mogelijkheid om controle op afgehandelde tickets uit te voeren door de Delivery Manager. Handig bij nieuwe werknemers of stagiaires. ·         Het gebruik van een planningstool; tickets plannen bij werknemers en dit wordt automatisch in de agenda gezet. ·         Het kunnen maken van een eigen dashboard. Als dit er niet is dan is dat ook geen probleem. Zo zie je bijvoorbeeld alleen de tickets die in de eigen queue terecht komen. ·         Bij het afhandelen van een ticket een keuze kunnen maken uit een andere hoofd- of subcategorie of zelf eentje kunnen aanmaken.
Would-haves	·         De snelheid van het systeem verloopt wat soepeler dan het huidige; je moet momenteel vaak een aantal seconden wachten op respons als je op opslaan of iets dergelijks klikt. ·         Het automatisch afsluiten van tickets. Als je bijvoorbeeld een reactie op een ticket doorgeeft aan de klant, dan is er een ‘waiting for customer’-functie. Als de klant dan na een tijd van 2 weken niet meer reageert dan wordt het ticket automatisch afgesloten en verdwijnt deze uit de queue.

[Brant Schroeder]

@Jeremy 

Looking through your list majority of those items you will be able to do.  There are a few that are open to your interpretation of the product and there are a couple like the integration with Twinfield that I do not know of a solution or you would have to create the integration using the JIRA APIs on your own.  

The best thing you can do is sign up for a free plan of JSM and use it to ensure it meets your needs before investing in it and deploying it to your organization.  The free plan will allow you to test the service and identify if the product will work for your company.