i NORIS - IMS Incident Management System

Transkript

1 spezial- und individualsoftware best practice lösungen cloud-computing internet und mobile solutions it-beratung & personalleistungen netzwerk / it-infrastruktur i NORIS - IMS

2 ....ist eine universelle Softwarelösung zur Unterstützung und Optimierung von Geschäftsprozessen im Bereich von Service- und Helpdesks. Die Steigerung der Effizienz und Qualität in den Bereichen Incident-, Problem-, Request-, Change- sowie Service Level- und Knowledge Management führen letztendlich zu einer deutlichen Erhöhung der Kundenzufriedenheit. 1 Grundlagen Das i NORIS -IMS ist eine Webapplikation zur Erfassung, Bearbeitung und Nachverfolgung aller Tätigkeiten eines Service Desks. Vorgänge werden dabei in sogenannten Calls erfasst. 2

3 1.1 Technische Daten Die Webapplikation ist in C# geschrieben und läuft im Microsoft ASP.net-Framework ab Version 2. Als Web- und Applikationsserver dienen die Microsoft Internet Information Services ab Version 6. Als zugrundeliegendes Datenbanksystem wird der Microsoft SQL Server ab Version 2005 eingesetzt. Clientseitig wird ein aktueller Browser (Microsoft Internet Explorer ab Version 8, Mozilla Firefox ab Version 10, Google Chrome ab Version 10) vorausgesetzt. Die Kommunikation mit den Kunden- und Service Desk-Benutzern erfolgt per . Hierzu wird nur ein erreichbarer SMTP-Relayserver benötigt, ein lokaler SMTP-Dienst wird nicht vorausgesetzt. 1.2 Schnittstellen Das IMS verfügt über eine LDAP-Schnittstelle zur Abfrage von Benutzerinformationen aus dem Microsoft Active Directory. Hierüber können Benutzer beim ersten Zugriff auf das System automatisch angelegt und die notwendigen Informationen aus der vorhandenen Benutzerdatenbank geladen werden. Ein manuelles Anlegen von Benutzern ist so nicht notwendig, kann aber beispielsweise für Service Desk-Mitarbeiter mit höheren Berechtigungen weiterhin durchgeführt werden. Auch hierbei können die notwendigen Zusatzinformationen nach Eingabe von z.b. -Adresse oder Windows-Account automatisch geladen werden. Per OLEDB- beziehungsweise ODBC-Verbindung kann von externen Programmen direkt auf die Basisdaten der Anwendung zugegriffen werden, um beispielsweise spezielle Auswertungen direkt in Excel durchzuführen. Entsprechende Datenbankviews sind hierzu vorbereitet, die Benutzerauthentifizierung erfolgt hierbei direkt über das Rechtemodell des SQL Server. Call-Listen können direkt aus der Applikation heraus nach Excel exportiert werden. Dabei können benutzerdefinierte Filter oder Volltextsuchen verwendet werden, um die Ergebnisse vorzufiltern, und anschließend eine Feinfilterung in Excel vorgenommen werden. Der Microsoft Office Communicator bzw. der Nachfolger Microsoft Lync können in die Applikation eingebunden werden, um beispielsweise dem Einreicher eines Calls direkt eine Sofortnachricht schicken zu können oder über die Desktopfreigabe Probleme direkt nachvollziehen zu können. 1.3 Betrieb Die Applikation kann lokal als eigenständige Installation auf einem dedizierten Server oder (unter Berücksichtigung der Performance-Anforderungen) auf einem vorhandenen Web- und Datenbankserver betrieben werden. 1.4 Service Im Rahmen eines Wartungsvertrags steht unser telefonischer Support Montag bis Freitag von 8:00h bis 17:00h zur Verfügung. Parallel dazu besteht auch außerhalb der Servicezeiten jederzeit die Möglichkeit, über das IMS der NORIS-IB Calls einzustellen. Nach Vereinbarung sind hierfür auch garantierte Reaktionszeiten möglich. 3

4 1.5 Sicherheit Die Applikation verfügt über ein feinstufiges Rechte- und Rollenkonzept. Für jede Ebene innerhalb der flexibel konfigurierbaren Struktur kann festgelegt werden, welche Benutzer Zugriff haben sollen. Zusätzlich zu den reinen Zugriffsrechten können Sonderrollen wie Key User oder Projektleiter vergeben werden. Besonders sensible s wie Zugangsdaten oder Einmalpasswörter können verschlüsselt verschickt werden. Das hierzu benötigte Empfängerzertifikat wird direkt aus dem Active Directory entnommen. Abhängig von der Konfiguration des Webservers kann sichergestellt werden, dass der Zugriff auf die Applikation ausschließlich SSL-verschlüsselt erfolgt. Optional können die zugrundeliegenden Datenbanken verschlüsselt werden. Dies kann entweder durch die in SQL Server integrierte Funktionalität oder direkt in der Datenzugriffsschicht der Anwendung selbst erfolgen. 4

5 Eine Aufteilung der Datenbanken in Benutzer- und Bewegungsdaten ist möglich, um z.b. externen Dienstleistern einen Abzug der Bewegungsdaten geben zu können, ohne dass hierin personenbezogene Daten enthalten sind. Alle Änderungen am Datenbestand werden auf Datenbankebene automatisch als Audit-Trail mitprotokolliert. Änderungen an den Bewegungsdaten eines Calls können mit der entsprechenden Berechtigung direkt im Call eingesehen werden. Die Anmeldung und Authentifizierung an der Applikation erfolgt wahlweise durch Single Sign On über das Windows-Benutzerkonto oder durch eine in der Applikation integrierte Benutzerverwaltung. In keinem Fall werden Passwörter im Klartext im System gespeichert. 5

6 1.6 Mobile Version Für die Erfassung und Statuskontrolle von Calls auf einem mobilen Gerät (Tablet oder Smartphone) steht eine spezielle, auf Touchscreen-Bedienung optimierte Mobilversion der Applikation zur Verfügung. 6

7 2 Grundfunktionen Alle Anfragen an den Service Desk werden als Call im System erfasst. Mittels einer Klassifizierung durch den Einreicher und ggf. Korrektur durch den First Level Support wird gesteuert, welchen Prozess der Call anschließend durchläuft, d.h. ob es sich um einen Incident, einen Change Request oder einen Service Request handelt. Diese Klassifizierungen können frei konfiguriert werden. 7

8 2.1 Call-Erstellung In der Regel erfolgt die Erfassung eines Calls direkt durch den betroffenen User im IMS selbst. Hier werden alle für die Bearbeitung erforderlichen Daten abgefragt und die entsprechenden Auswahlmöglichkeiten vorbelegt. Erfolgt die Meldung eines Problems telefonisch, so kann der Service Desk den Call parallel in der Applikation erfassen und dem Anrufer zuordnen. Über die Active Directory-Schnittstelle kann mit der Telefonnummer des Anrufers der zugehörige Benutzer gesucht und, falls noch nicht vorhanden, in der Applikation angelegt werden. Erfolgt die Meldung eines Problems per , besteht die Möglichkeit, ein dediziertes Postfach periodisch im Hintergrund auszulesen und aus den vorliegenden s automatisch Calls zu erstellen. Durch Unterordner im Postfach kann dabei gleich gesteuert werden, in welchem Strukturzweig der Call angelegt werden soll. Für das Erfassen von Calls stehen frei definierbare Textvorlagen zur Verfügung, um z.b. Standard Changes schneller erfassen zu können und bei bestimmten Unterprozessen eine Vorgabe für die zu hinterlegende Beschreibung geben zu können. 8

9 2.2 Status Der Workflow wird durch frei definierbare Statusfolgen gesteuert. Für jeden Status kann festgelegt werden, welche Folge-Status zulässig sind, und ob eine beim Statuswechsel verschickt werden soll oder z.b. vor dem Statuswechsel zwingend ein bestimmter Kommentar hinterlegt worden sein muss. Weiterhin kann zu jedem Status hinterlegt werden, ob der Call sich damit noch beim Service befindet oder ob auf eine Kundenaktion gewartet wird. Auf dieser Basis erfolgt die Berechnung der Reaktions- und Durchlaufzeiten und somit die Bewertung der Service Desk-Performance. Eine Wiedervorlage für bestimmte Status ist ebenfalls möglich. Hierdurch kann ein Call beispielsweise nach drei Tagen Wartezeit auf eine Kundenaktion automatisch abgeschlossen werden. 9

10 2.3 Kommentare Zu jedem Call können beliebig viele Kommentare sowohl durch den Service Desk als auch durch den Kunden hinterlegt werden. Kommentare können als intern oder öffentlich sichtbar gekennzeichnet werden, so dass z.b. interne Bearbeitungsvermerke eingetragen werden können, die der Kunde nicht sehen kann. Kommentare können verschiedene Typen haben, über die dann wiederum der Status-Workflow beeinflusst werden kann. Beispielsweise kann ein Incident-Call nur als gelöst gemeldet werden, wenn auch eine entsprechende Beschreibung der Lösung eingetragen wurde. Auch für Kommentare stehen Textbausteine zur Verfügung, um z.b. Standard Changes ohne großen Bearbeitungsaufwand abwickeln zu können. 2.4 Aufwände Zu jedem Call können die dazugehörigen Aufwände und ausgeführten Arbeiten direkt erfasst werden. Verschiedene Aufwandskategorien wie beispielsweise innerhalb Servicezeit, Wochenende, Vor-Ort-Einsatz können hinterlegt und ausgewählt werden. Der zu einem Call bereits angefallene Aufwand ist jederzeit in der Übersichtsliste ersichtlich. 10

11 2.5 Dateianlagen Service Desk und Kunde können Dateien wie z.b. Screenshots an einen Call anhängen. Jeder Anhang kann dabei als intern oder öffentlich sichtbar markiert und mit einem ausführlichen Kommentar versehen werden. 2.6 Filter Jeder Benutzer kann sich beliebig viele Sichten als Filter auf die Call-Daten anlegen. Hierzu stehen zwei verschiedene Masken zur Verfügung, eine mit komfortablerer Filterdefinition und dafür nur den wichtigsten Felder, und eine weitere mit vollen Zugriff auf alle vorhandenen Datenfelder. Mit der entsprechenden Berechtigung können Sichten als öffentlich gekennzeichnet werden und stehen damit allen Benutzern der jeweiligen Rolle zur Verfügung. 11

12 2.7 Suche Mittels der Volltextsuche kann in allen Textfeldern aller Calls gesucht werden. Über die aktuell ausgewählte Sicht kann eine Vorfilterung erfolgen. Die Liste wird dann durch die Volltextsuche weiter auf die Calls gefiltert, die den entsprechenden Suchbegriff enthalten. Die Textsuche unterstützt hierbei MUSS-, KANN- und NICHT-Begriffe sowie eine Unterscheidung zwischen festen Zeichenketten und Wildcardsuche. 12

13 2.8 Dashboard In der Call-Liste wird jederzeit die Statusverteilung der angezeigten Calls sowie der Verlauf an neuen, noch bearbeiteten und abgeschlossenen Calls über die Zeit dargestellt. Über den Strukturbaum sowie die konfigurierbaren Sichten kann hier eine Filterung der zugrundeliegenden Daten durchgeführt werden. 2.9 SLA-Überwachung Es können beliebig viele SLAs definiert werden. Ein SLA überwacht dabei den Zeitraum zwischen zwei ausgewählten Call-Status. Je nach Priorität des Calls können hierfür verschiedene Zeitstrecken konfiguriert werden, innerhalb derer der Statuswechsel erfolgt sein muss. Die Zeitberechnung erfolgt dabei auf Basis des Arbeitskalenders, der zum jeweiligen Kunden hinterlegten und mit ihm vereinbarten Servicezeiten und unter Ausschluss von etwaigen Zwischenstatus, bei denen auf eine Kundenaktion gewartet werden musste und eine Weiterbearbeitung nicht möglich war. 13

14 Bei Erreichen einer definierten Zeit vor Ablauf eines SLA erfolgt eine Benachrichtigung per an die zugewiesenen Bearbeiter, um eine Verletzung des SLA zu verhindern Auswertungen Die definierten SLA können auf ihre Einhaltung ausgewertet werden. Hierbei werden pro Tag, Woche, Monat oder Jahr innerhalb eines konfigurierbaren Zeitraums die Anzahl der Calls, die innerhalb der vereinbarten Zeit bearbeitet wurden, und die Anzahl der Überschreitungen grafisch aufgetragen. Weiterhin steht eine Auswertung über die eingegangenen und abgearbeiteten Calls pro Kalenderoder Geschäftsjahr zur Verfügung. Per Drilldown kann zu jedem Datenpunkt auf die zugrundeliegenden Calls zugegriffen werden. 14

15 Weitere spezielle Auswertungen z.b. für definierte KPIs, spezielle Durchlaufzeiten, die Aufteilung der Calls nach den Abteilungen der Einreicher oder die aufgelaufenen Kosten können per Customizing individuell integriert werden. 15

16 3 Prozesse Wie eingangs beschrieben steuert die Klassifizierung durch den Einreicher und den First Level Support, welcher Prozess in der Bearbeitung eines Calls durchlaufen wird. 3.1 Incident Management Incident-Calls werden durch den First Level Support im System angenommen. Anschließend wird beurteilt, ob das Problem direkt gelöst werden kann; falls nicht, erfolgt eine Weiterleitung an den Second Level Support oder die entsprechende Fachabteilung. Ein Incident-Call kann erst als gelöst gemeldet werden, wenn auch eine entsprechende eingetragen wurde. In Verbindung mit einer integrierten Configuration Management Database kann so eine detaillierte Knowledge Base aufgebaut werden. Benutzer mit der entsprechenden Berechtigung können ein Call zum Service Manager eskalieren. Der Call erhält dadurch eine entsprechende Kennzeichnung, die in Auswertungen herangezogen werden kann. 3.2 Change Management Change Requests werden nach Annahme durch den First Level Support an die entsprechende Fachabteilung weitergeleitet. Im Prozess kann konfiguriert werden, dass für Change Requests eine detaillierte Anforderungsbeschreibung durch den Kunden im Call hinterlegt sein muss, bevor die weitere Verarbeitung erfolgen kann. 16

17 Der Change Request wird anschließend bewertet. Im Prozess kann konfiguriert werden, dass analog zur Anforderungsbeschreibung auch eine Designspezifikation im Call hinterlegt sein muss, bevor der Workflow weiterlaufen kann. Bei kostenpflichtigen Calls kann optional erst eine Genehmigung und Freigabe durch einen Verantwortlichen auf Kundenseite erforderlich sein, bevor mit der Entwicklung begonnen werden kann. Change Requests können für eine bestimmten Termin (z.b. KW 30) oder eine Versionsnummer terminiert werden. Aus einem Call heraus können beliebig viele Folge-Calls als Unteraufträge erstellt werden, die mit dem ursprünglichen Call verknüpft bleiben. Dies ermöglicht es auch, z.b. aus Teilen eines Incidents einen Change Request zu machen und beide Prozesse unabhängig voneinander weiterlaufen zu lassen. Aus einem Call heraus kann direkt eine Arbeitsaufgabe im Team Foundation Server angelegt werden. Die Arbeitsaufgabe wird mit dem Call verknüpft und die Beschreibung des Calls in die Beschreibung der Arbeitsaufgabe übernommen. 17

18 Nach Abschluss eines Calls kann ein Call-Dokument erzeugt werden, in dem alle relevanten Informationen wie auch die Anforderungsbeschreibung und die Designspezifikation sowie die Statushistorie enthalten sind. 18

19 3.3 Service Management Für Service Requests stehen im Wesentlichen dieselben Funktionen zur Verfügung wie für Change Requests. Zusätzlich können für Standard Changes feste Textvorlagen und zusätzliche Auswahlfelder hinterlegt werden, um die Bearbeitung zu erleichtern. (Bild: Speziell angepasste Kundenversion - daher noch keine Überführung ins neue Design) 19

20 3.4 Configuration Management In der integrierten CMDB (Configuration Management Database) können beliebige Configuration Items hinterlegt werden. Hierfür können beliebig viele CI-Typen, Hersteller und Modelle gepflegt werden. 20

21 Pro CI-Typ können beliebig viele Eingabefelder definiert werden, die bei CIs dieses Typs dann jeweils ausgefüllt werden können. Configuration Items können beliebig untereinander verknüpft werden, um Abhängigkeiten abzubilden. Zu jedem Call kann das betroffene Configuration Item (z.b. PC des Endanwenders bei Incidents, oder zu ändernde Applikation bei Change Requests) ausgewählt werden. 21

22 Die Felder des zum Call erfassten Configuration Items stehen als Datenfelder für die Erstellung von Sichten zur Verfügung, so dass z.b. gezielt nach bereits aufgetretenen Problemen eines speziellen Modells gesucht werden kann. 22

23 NORIS-IB GmbH Kopernikusstraße 18 Postfach D Nürnberg D Nürnberg T / info@noris-ib.de F / Web: