Issue tracker

Een Issue Tracking System ( ITS ): synoniemen: helpdesksysteem , servicekaarten systeem, ticketing systeem, taakvolgsysteem, support ticketing systeem, trouble ticket systeem, request tracking systeem (RTS), deels ook een casemanagementsysteem) is een soort software voor de afhandeling, bevestiging, classificatie en verwerking van klantverzoeken (tickets of cases). Verzoeken omvatten inkomende oproepen van klanten, e-mails, faxen en dergelijke.

Moderne traceersystemen voor problemen hebben vaak interfaces naar andere systemen zoals. Bv . Klantendatabases .

Samen hebben al deze systemen de mogelijkheid om een ​​ticket toe te wijzen aan een werkstation of aan een persoon binnen een werkstation voor verdere verwerking tot de oplossing ( gesloten ticket ). Het doel van het ticketsysteem is ervoor te zorgen dat er geen boodschap verloren gaat en dat een volledig overzicht van de te verwerken processen te allen tijde mogelijk is.

Belangrijke functies

De bezorgdheid van de respondenten kan worden opgesplitst in verschillende urgentieniveaus volgens de Service Level Agreements (SLA) en Operational Level Agreements (OLA), met de bijbehorende escalatieniveaus – als de SLA of OLA niet worden gehaald.

Issuetracking-systemen worden gebruikt om de goede werking van de taak te behouden of te herstellen.

Issue tracking-systemen voeren verschillende functies uit, in het bijzonder

  • Registratie van fouten en fouten en vragen (bijvoorbeeld via e-mailresponsbeheersystemen )
  • Distributie en toewijzing van de agenten
  • Bewaking van verwerking en verwerkingstijd en kwaliteit
  • Garanderen van de naleving van interne processen door middel van gedwongen controle via workflows
  • statistische evaluatie van het ticketvolume
  • automatisch genereren van tickets door alarmsystemen zoals. B. een netwerkmonitoring
  • Naleving van externe serviceverplichtingen ( Service Level Agreement )
  • Systematisch vragen en antwoorden verzamelen voor veelgestelde vragen

Ticket

Een ticket is de elektronische vorm van een aanvraag (meestal gemeld door de IT-gebruiker). Dit kan

  • een fout ( incident )
  • een ander verzoek ( serviceaanvraag ), dergelijke. B.
    • een wijzigingsverzoek ( wijzigingsverzoek , verzoek om wijziging )
    • een informatief verzoek ( verzoek om informatie / educatie )
    • een verzoek om (functie) verbetering ( Request for Enhancement )

naar de servicedesk of de ondersteuningseenheden (volgens ITIL ).

Gegevens van een ticket

Voorbeelden van de inhoud van een ticket

  • uniek (opeenvolgend) ticketnummer
  • Ticketersteller (ondersteuning, aanvraag)
  • Tijd van creatie
  • Persoonlijke gegevens (naam, voornaam, telefoon, adres en woonplaats, toegankelijkheid)
  • prioriteit
  • Urgentie (afspraakverzoeken)
  • categorie
  • Symptomen
  • Problemen oplossen
  • Overzicht van eerdere editors met tijden
  • Verwerkingsstatus (open, toegewezen, wordt uitgevoerd, opnieuw verzonden, opgelost)
  • Betrokken / verstoorde activa (systeem, apparaat, pc, printer, scherm, programma, enz.)

Toepassingen

Case Processing Systems (FBS) worden in verschillende toepassingen gebruikt. Voorbeelden zijn:

  • Contactpunten in het administratiesysteem
  • Technische projecten

In EDP wordt een FBS gebruikt voor aanpassingen, verbeteringen, bugfixes en de systeemtest van een project. Redenen voor het gebruik van een FBS zijn:

  • om de kwaliteit van de geleverde activiteit te verbeteren
  • om het proces transparanter te maken
  • om de geschiedenis van de zaak te bewaren
  • om conclusies te trekken uit de geschiedenis voor de toekomst en om het proces te optimaliseren

Een ticketsysteem maakt ook deel uit van een servicebeheersoftware of Enterprise Resource Planning- software. Het ticketsysteem kan ook worden gebruikt in projectbeheer, bijvoorbeeld om projecttaken te delegeren en de voortgang te bewaken. Om werknemers aan de individuele tickets toe te wijzen, worden functies zoals resourceplanning en planningsborden vaak gebruikt.

Voorbeeld IT-ondersteuning

Casusverwerking in de EDP.

In de regel is de procedure zodanig dat een verzoek om aanpassing, wijziging, uitbreiding of fout wordt ingevoerd door de gebruiker in de FBS. De invoer kan online worden gemaakt of door de hotline te bellen . In dit geval zal de medewerker van de hotline de informatie invoeren in het systeem. De medewerker vindt een oplossing voor het verzoek in de foutendatabase. De klant aanvaardt de oplossing en de zaak is gesloten.

Als dit niet mogelijk is, zal de hotline de zaak illustreren als een storyboard of anderszins opnemen. Indien mogelijk wordt verbale beschrijving weggelaten, vooral in het geval van veranderingen in complexe toepassingen . Omdat het gesproken woord vaak leidt tot misverstanden tussen de expert-hotline persoon of de klant en de technisch onderlegde, maar niet zo goed opgeleide ontwikkelaar van de technologie. Nadien zal een case-analyse worden uitgevoerd door de hotline. Het probleem kan worden opgelost door een systeem in te stellen of opnieuw te installeren .

Als deze stap het probleem niet oplost, zal het gebeuren

  • Toepassing van de techniek: de technische afdeling dringt aan op de case study, die de technische vereisten op een duidelijke en ondubbelzinnige manier toelicht. De analyse kan een over het hoofd gezien of nieuwe optie voor probleemoplossing bieden, in welk geval de hotline op de hoogte wordt gebracht. Als dit niet het geval is of als de hotline het probleem met de suggestie van de technologie niet aankan, gebeurt dit meestal
  • Codewijziging: hier is een ontwerpspecificatie gemaakt. Als het geen fout is , moet de klant op de hoogte worden gesteld van de gemaakte kosten ( inspanning ). Na de codewijziging moet elke ontwikkelaar zijn / haar module (s) testen voordat hij het hele systeem of de integratietest verifieert .
  • De systeemtestafdeling, die vaak identiek is aan de hotline, neemt nu de zaak, test deze met realistische gegevens en retourneert deze naar de technologie in het geval van verschillen. Anders wordt de oplossing voor de zaak voltooid door de klantoverdracht.

Voor- en nadelen

Voordelen

  • Uniform systeem voor wijzigingsvoorstellen, verbeteringen en foutafhandeling vermijdt bureaucratische inspanningen.
  • Automatisch bericht aan de projectmanager, ontwikkelaar / onderhoudspersoneel van het codegedeelte, testafdeling en als laatste aan de klant als de fout is verholpen.
  • Online review door de projectmanager en de klant van de huidige status van een aanpassing / uitbreiding / correctie.
  • Omdat het systeem niet klantspecifiek is, maar een algemene oplossing biedt voor projecten en klanten, is het snel aangepast voor individueel gebruik. Het is dus een kosteneffectieve, uniforme oplossing voor het verwerken van cases.
  • De transparantie van het proces verbetert de kwaliteit van het werk aanzienlijk.
  • Unificatie van processen: door de casuïstiek te analyseren, is het mogelijk om de processen van de organisatie te verbeteren
  • In de meeste gevallen worden kostenbesparingen gerealiseerd door het standaardiseren en verbeteren van processen. Onnodige stappen worden geëlimineerd en veelvuldige fouten worden gemaakt.
  • Voor een duidelijke communicatie tussen de deelnemers, een unieke naam, bijv. Als een ID, worden toegekend.

Nadelen

  • Kosten: de FBS wordt ontwikkeld en onderhouden in de organisatie zelf. Bij de aanschaf van een voltooide FBS worden echter lopende kosten verwacht (hostcomputer, server, infrastructuur, beheerder, tijd om in te voeren en te analyseren, enz.).
  • Vereiste training en training van werknemers en klanten. Hoe lager de kosten, hoe minder gebruikersvriendelijk de toepassing is, maar dit voegt complexiteit toe aan het ontwerp en verhoogt de kosten van het systeem.

Software

Bekende probleemvolgsystemen (selectie):

  • BMC Remedy Action Request System ( eigen )
  • Bugzilla ( gratis software )
  • Comindware Tracker (eigen)
  • FOSSIL (gratis software)
  • HelpLine (eigen)
  • HP OpenView Service Desk (eigen)
  • iTop (gratis software)
  • Jira (eigen)
  • ManageEngine ServiceDesk Plus (eigen)
  • Mantis Bug Tracker (gratis software)
  • OpenProject (gratis software)
  • Open Ticket Request System (gratis software)
  • Phabricator (gratis software)
  • Projektron BCS (eigen)
  • Redmine (gratis software)
  • Verzoek Tracker (gratis software)
  • Roundup (gratis software) (bugtracker)
  • Trac (gratis software)
  • Track + (eigen)
  • USU-software (eigen)
  • Vantive system (proprietary)
  • VMware Service Manager (eigen)

Juridische aspecten

Het gebruik van probleemopsporingssystemen in bedrijven maakt het ook mogelijk om de werkprestaties van individuele werknemers en teams te bepalen – met alle bijbehorende implicaties voor de werkgelegenheid en gegevensbescherming . Systemen voor het bijhouden van problemen kunnen bijvoorbeeld worden gebruikt om de prestaties en het gedrag van medewerkers te volgen . Het is ook nodig om te controleren of werknemers binnen een groep elkaars werk kunnen observeren. De auteurs van het open source-programma Request Tracker vermelden in dit verband de “groepsdruk” die is gecreëerd door het gebruik van systemen voor het volgen van problemen. [1]

Dit artikel of deze paragraaf beschrijft de situatie in Duitsland . Geef een beschrijving van de situatie in andere staten.

Wanneer medezeggenschap van bedrijven van toepassing is, kan de invoering en toepassing van dergelijke hulpmiddelen medezeggenschap vereisen ( § 87 (1) (6 ) van de Works Constitution Act ). De opdracht kan dan worden geregeld met bedrijfsovereenkomsten , zoals. In openbare dienst, waar er overeenkomstige serviceovereenkomsten zijn. [2] De applicatie resulteert bijvoorbeeld in de mogelijkheid van werkconsolidering en een toename van de externe determinatie van het werk. Om deze reden kan een risicobeoordeling vereist zijn. [3]

Webkoppelingen

  • RFC 1297 – NOC Intern geïntegreerd probleemmeldingssysteem Functionele specificatie Verlanglijst
  • Vergelijking van de issue tracker (Engels)

Individuele proeven

  1. Spring omhoog↑ “Dit kind brengt een hoge zichtbaarheid …”, van Jesse Vincent, Robert Spier, Dave Rolsky, Darren Chamberlain en Richard Foley: RT Essentials , 2005, ISBN 0-596-00668-3
  2. Jump up↑ Voorbeeld van een serviceovereenkomst voor “RT” in gebruik in de RRZ van de universiteit van Hamburg (PDF, 391 kB)
  3. Jump up↑ Specificatie van § 5 ArbSchG door § 3 par. 1, zin 3 van de werkplaatsverordening (ArbStättV)

Leave a Reply

Your email address will not be published. Required fields are marked *