{"id":5692,"date":"2012-09-28T14:51:54","date_gmt":"2012-09-28T12:51:54","guid":{"rendered":"https:\/\/wpethzprd.ethz.ch\/id\/?p=5692"},"modified":"2012-09-28T14:51:54","modified_gmt":"2012-09-28T12:51:54","slug":"itil-knowledge-incident-problem","status":"publish","type":"post","link":"https:\/\/blogs.ethz.ch\/id\/2012\/09\/28\/itil-knowledge-incident-problem\/","title":{"rendered":"ITIL Knowledge: Incident \/ Problem"},"content":{"rendered":"<p>ITIL unterscheidet streng zwischen einem \u00abIncident\u00bb und einem \u00abProblem\u00bb. Die Verwechslung zwischen den beiden verursacht Stolpersteine. <!--more-->Dieter Gut, ID Direktion Qualit\u00e4ts- und Prozessmanagement,erkl\u00e4rt den Unterschied praxisgerecht.<\/p>\n<ul>\n<li><strong>Incident<\/strong>: Pl\u00f6tzliche oder drohende St\u00f6rung der Serviceerbringung.<\/li>\n<li><strong>Problem<\/strong>: Immer wieder auftretende, identische oder \u00e4hnliche St\u00f6rungen, bekannte Fehler oder nicht mehr behebbare St\u00f6rungen mit <strong>unbekannter<\/strong> <strong>Ursache<\/strong>.<\/li>\n<li><strong>Incident Management<\/strong>: Prozess zur <strong>Beseitigung <\/strong>der<strong> Auswirkungen<\/strong> einer St\u00f6rung durch einfache Massnahmen (z. B. Reboot) oder durch Anwendung eines Workarounds.<\/li>\n<li><strong>Problem Management<\/strong>: Forschung nach der Ursache einer St\u00f6rung oder eines bekannten Fehlers mit dem Ziel diese <strong>Ursache<\/strong> zu <strong>beseitigen<\/strong>. Damit soll k\u00fcnftig ein stabilerer Betrieb erm\u00f6glicht werden.<\/li>\n<\/ul>\n<p>H\u00e4ufig machen die IT Betreiber den Fehler, dass sie keinen Problem Record er\u00f6ffnen und stattdessen nur mit einem Incident Record arbeiten. Das kann dazu f\u00fchren, dass die Incident Records weit \u00fcber die St\u00f6rungsdauer ge\u00f6ffnet bleiben weil ja die Ursache noch gefunden werden soll. Es gibt viele offene Incident Tickets. Das erschwert die \u00dcbersicht. Es sind ja gar nicht so viele St\u00f6rungen vorhanden. Die Reportings an die Kunden machen einen schlechten Eindruck. Andererseits f\u00fchrt ein zu schnelles Schliessen des Incident Tickets zur Gefahr, dass nicht erkannt wird, dass die St\u00f6rung immer wieder auftritt. Dadurch wird der Betreiber belastet und der Kunde ver\u00e4rgert.<\/p>\n<h3>Am folgenden Praxisbeispiel wird der Mechanismus dargestellt<\/h3>\n<p>Ein Kunde ruft beim ID Service Desk an, weil in einer Datenbank kein neuer Datensatz mehr erfasst werden kann. In den vergangenen vier Wochen gab es schon mehrere \u00e4hnliche Calls. Deshalb hat der Service Desk schon einen \u00abKnown Error\u00bb (KE) erfasst. Es war jeweils die Festplatte des Servers pl\u00f6tzlich vollgelaufen. Nach einem Neustart der Datenbank durch die Administratorin bzw. den Administrator ging es immer wieder. Der Service Desk startet die Datenbank noch w\u00e4hrend dem Anruf neu und es kann sofort wieder gearbeitet werden. Der Service Desk sieht, dass dies nun das f\u00fcnfte Mal hintereinander war und schliesst das Incident Ticket. Er macht stattdessen ein Problem Ticket auf, referenziert den KE und alle bisherigen Incident Tickets.<\/p>\n<p>Die Problem Managerin bzw. der Problem Manager akzeptiert den Problem Record, sucht sich Fachkr\u00e4fte und beauftragt sie mit der Analyse. Das Team findet heraus, dass in dieser Version der Datenbank ein Fehler besteht. Speicher wird erst nach dem Neustart der Datenbank wieder freigegeben. Es gibt einen Patch daf\u00fcr vom Hersteller. Es wird ein Request for Change (RfC) gemacht. Das Release Management soll den Patch ausrollen auf alle Datenbanken mit der fehlerhaften Version. Aus der CMDB sieht man, dass nur eine einzige Installation betroffen ist. Der KE wird aktualisiert. Das Problem Ticket bleibt solange offen, bis sicher ist, dass der Change das Problem behoben hat. Da der Change erst im Wartungsfenster gemacht werden darf tritt derselbe Fehler noch einmal auf. Der Service Desk sieht aber diesmal im KE, dass die Ursache bekannt ist und ein Change h\u00e4ngig ist und kann die Anwenderin oder den Anwender kompetent informieren, dass der Fehler nach dem Change Datum nicht mehr auftreten sollte.<\/p>\n<h2>Situation in den Informatikdiensten der ETH Z\u00fcrich<\/h2>\n<p>Alle hier angesprochenen Prozesse sind in den Informatikdiensten der ETH vorhanden. Es mangelt etwas an der Systematik, am Bewusstsein und am Datenfluss zwischen den einzelnen Prozessen. Es fehlt das Wissen, was die Kolleginnen und Kollegen schon gemacht haben. Da gibt es Verbesserungspotenzial.<\/p>\n<h3>Prozesse und Ausdr\u00fccke im Beispiel<\/h3>\n<ul>\n<li>Incident Management <em>Prozess in der Phase Operation<\/em><\/li>\n<li>Ticket\/Call <em>Datensatz<\/em><\/li>\n<li>Service Desk <em>Funktion<\/em><\/li>\n<li>Problem Management <em>Prozess in der Phase Operation<\/em><\/li>\n<li>Known Error (KE) <em>Datensatz<\/em><\/li>\n<li>Service Asset and Configuration Management <em>Prozess in der Phase Transition<\/em><\/li>\n<li>Configuration Management Database (CMDB) <em>Datenhaltung<\/em><\/li>\n<li>Change Management <em>Prozess in der Phase Transition<\/em><\/li>\n<li>Request for Change (RfC) <em>Datensatz<\/em><\/li>\n<li>Release and Deployment Management <em>Prozess in der Phase Transition<\/em><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>ITIL unterscheidet streng zwischen einem \u00abIncident\u00bb und einem \u00abProblem\u00bb. Die Verwechslung zwischen den beiden verursacht Stolpersteine. <\/p>\n","protected":false},"author":838,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1175,1179,1176,25,1181,1177,890,898,1178],"tags":[46919,46921,46900,46920,46922],"class_list":["post-5692","post","type-post","status-publish","format-standard","hentry","category-kommunikation","category-mail-web","category-multimedia-drucken","category-news","category-passwort-applikationen","category-software-arbeitsplatze","category-speicher","category-support","category-wissenschaftl-rechnen","tag-incident","tag-incident-management","tag-itil","tag-problem","tag-problem-management"],"_links":{"self":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/posts\/5692","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/users\/838"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/comments?post=5692"}],"version-history":[{"count":0,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/posts\/5692\/revisions"}],"wp:attachment":[{"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/media?parent=5692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/categories?post=5692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.ethz.ch\/id\/wp-json\/wp\/v2\/tags?post=5692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}