step2.at

business_IT_alignment

Auch SAP möchte am BPM Markt mitnaschen

Dienstag 2. Juni 2009 von wlw

Mit der SAP Netweaver BPM Suite ist der größte ERP Software Hersteller seit einiger Zeit auch am BPM Tool Markt aktiv. Die bereits vor einigen Jahren angekündiget Lösung für prozess- bzw. modell basiertes Customizing könnten in Zeiten von BPMN, Web Dynpros, Web Services und XML endlich Wirklichkeit werden.

sap-netweaver-bpm

Wie integriert sind Ihre (SAP-) Abläufe wirklich? Wo nicht gibt es immer noch eMails oder Telefon-Anrufe, um die Prozesse am Laufen zu halten. Speziell bei den Kernprozessen, die direkt über unternehmerischen Erfolg oder Misserfolg entscheiden, sind solche “Medienbrüche” besonders störend.

Ob die SAP Lösung mit den Branchen Größen wirklich mithalten kann, bleibt noch zu beweisen.

Weitere Infos zur Lösung sind  hier zusammengefasst!

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »

Kundenorientierung oder Effektivität – womit kann die IT mehr bewegen?

Montag 20. April 2009 von wlw

Das IT Management der letzten Jahre ist wesentlich geprägt vom Gendanken der Kundenorientierung. Durch Ausrichtung am Kunden kann die IT ihren Wertbeitrag für das Unternehmen bzw. den Unternehmenserfolg am besten transparent machen …. so dachte man.

Orientierung der IT am Kunden bzw. Business-IT Alignment als ein zentrales Konzept in der heutigen IT. (siehe dazu auch meinen Blogpost)

Reicht Kundenorientierung alleine aus?

Kernfrage dieses Artikels ist, ob alleine die Ausrichtung der IT am Business zu den gewünschten positiven Effekten bzw. IT gestützten Geschäftserfolgen führt oder ob auch andere Einflussfaktoren mit berücksichtigt werden müssen oder ob die Kundenorientierung überhaupt der richtige Weg ist. Gibt es Unternehmen bzw. IT Management Ansätze die ohne einer überhöhten Kundenorientierung auch sehr erfolgreich sind?

Dieser Frage wurde in einer spezifischen Studie “Avoiding the alignment trap in IT” von Bain & Company (erschienen in MITSloan Management Review) auf den Grund gegangen.

Die Auswirkungen der Kundenorientierung

Nahe am Kunden zu sein, bedeutet …

  • … oftmals maßgeschneiderte Lösungen zu bauen (speziell “ge-customizte” Best-of-Breed Lösungen)
  • … individuelle Unterstützung der einzelnen Kunden (mehr auf den einzelnen Kunden, denn auf das gesamte Unternehmen ausgerichtet)

Für die daraus resultierenden IT Lösungen bzw. zu betreibenden IT Umgebungen, bedeutet dies:

  • Es werden hoch spezifische Lösungen notwendig, die den Kundenwünschen entsprechen können.
  • Eine hohe IT Komplexität, sowohl in Infrastruktur, Systemen und Anwendungen (auch mit entsprechendem Aufwand im Betrieb und Wartung bzw. im notwendigen KnowHow) wird (tlw. unbewusst) aufgebaut.
  • Es kommen selten reine Standard Lösungen zum Einsatz (oftmals nur sehr stark angepasste), was den Ansatz von Standard-SW selbst irreleitet und z.B. zu hohen Aufwänden bei Upgrades führt.
  • Standardisierung ist nur sehr schwer zu erreichen

Gilt die Kundenorientierung alleine als oberste Maxime in der IT, so ergibt sich aufgrund der Orientierung an den Kundenanforderungen natürlich vordergründig eine hohe Kundenzufriedenheit. Die vielen unterschiedlichen Anforderungen und die daraus resultierenden sehr spezialisierten Anwendungen und die hohe IT Komplexität zwingen die IT aber “in die Knie”. Sie wird langsam, unflexibel und behäbig, denn die selbst verschuldete Komplexität muss auch gemanagt werden.

Nicht selten ist in Unternehmen in Bezug auf die IT folgendes zu hören: “Diese kleine Änderung … und das dauert 3 Monate?”
“Unsere IT … das dauert mir alles zu lange… “

Nach hoher Kundenzufriedenheit klingt das nicht! – Die Kosten steigen, Verzögerungen bei Projekten, hohe Aufwände im Betrieb, wenig Innovation etc.

Ein Forcieren des Business Alignment in dieser Situation zieht die IT nur noch “tiefer in den Sumpf”. – Gefangen in der Alignment-Falle!

Die Weg führt vorerst zur Effektivität!

Ein Lösungsansatz der zitierten Studie führt über die Effektivität. Die erste Priorität der IT sollte in Richtung Steigerung von Effektivität und Effizienz gehen. Erst in zweiter Linie kommt die Ausrichtung am Kunden.

Sehr simplifiziert könnte man auch sagen: Mit höherer Effektivität und Effizienz zuerst Ressourcen frei räumen, um damit erst die Möglichkeit zu haben, sich am Kunden zu orientieren.

Die Studie zeigt auch, dass Unternehmen in einem solchen effektivitäts-orientierten IT Setup erfolgreicher sind und das zudem auch noch bei geringeren IT Kosten.

(Quelle: www.architectureandchange.com)

Der Schlüssel - How to reach it?

  • Vergessen sie die Erhöhung der Kundenorientierung (für den Moment) - Konzentrieren sie sich auf die Effektivität ihrer IT!
  • Der Weg zuerst Steigerung der Effektivität, dann erst Business Alignment!

1. Einfachheit Fördern, Komplexität reduzieren

Die einfachen und schnellen Antworten auf Business Anforderung gehen in Richtung eines neuen Systems  oder eines neuen Ansatzes und erhöhen somit oftmals die Komplexität.

>> Als IT auch das Standing haben auf Standards zu setzen bzw. Standards zu suchen und durchzusetzen. (Immer das Gesamtunternehmen-Optimum im Fokus)

Auf Standards zu setzen erfordert mehr Aufwand, Diskussion und Kreativität am Beginn, bringt langfristig aber entsprechende Vorteile bei Kosten und Ressourcenauslastung.

2. Die richtige Sourcing Strategie

Eigene Ressourcen richtig einsetzen – dort wo auch wirklich der Mehrwert generiert werden kann. Bei Routinetätigkeiten auch über Outsourcing nachdenken.

Achtung! Outsourcing ist nicht das Allheilmittel. Auf jeden Fall darf diese Spielart nur dosiert und in “Routinebereichen” angewandt werden.

  • Wo liefert die eigene IT Wertbewerbsvorteile?
  • Welche Teile und Dienstleistungen gelten als Commodity?
  • Wo gibt es Standard SW und vorgefertigte Lösungen am Markt?
  • Atmende Organisation/variable Ressourcen (= variabler Einsatz von Externen)
  • Outsourcen von Aktivitäten, die nicht (mehr) wertschöpfend sind
    (Kann/darf man den HelpDesk outsourcen?)

3. Partnerschaftliche Gesamtverantwortung von Business & IT

Liefern “on time” und “on budget”! – Für den Erfolg von Projekten besteht eine gemeinsame Verantwortung von IT und Business.

Die Fachbereiche im Unternehmen weniger zu Kunden “hoch stilisieren” – denn Kunden fordern und Dienstleister setzen um. Und wenn die erbrachte Leistung nicht entspricht, dann sucht man sich einen anderen Dienstleister.

Die einzigen Kunden, die ein Unternehmen wirklich hat, sind die am externen Markt, die Umsätze und Gewinne generieren!

Im “internen Geschäft” führt die partnerschaftliche Zusammenarbeit von IT und Fachbereich eher zu einer zielführenden Beziehung, denn eine Kunden-Lieferanten Beziehung.

Fazit

Die hier zitierte Studie ist einer der mir eindrücklichsten der letzten Zeit. Es erschüttert in gewisser Weise das Grundkonzept von IT, wo die Orientierung am Kunden an höchster/sehr hoher Stelle stand. Bewusst ‘stand’; denn die hier beschriebenen Erkenntnisse verrücken diese Sichtweise durchaus!

Weitere Referenzen:

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ISO.20000, IT-Management | 1 Kommentar »

Das kleine Incident Reporting 1×1

Mittwoch 15. April 2009 von wlw

Ich möchte in diesem Beitrag ein bekanntes Thema etwas vertiefen. Incident Management ist der am weitesten verbreitete Prozess im ITIL-Umfeld. Damit einher geht auch das entsprechende Incident Reporting - also die Auswertung von bearbeiteten Support Calls und die daraus resultierenden Erkenntnisse und Verbesserungs-Ansätze.

image

Die einfachste Form des Reporting ist die Auswertung und Darstellung von Zeitreihen bezogen auf Call-Volumina (siehe unten). Einfach zu erstellen, ist diese Form der Auswertung fast überall anzutreffen. Alleine die daraus ableitbaren Aussagen sind sehr eingeschränkt. Ein vernünftiges Incident Reporting muss weiter, tiefer gehen und zumindest in Ansätzen die Prozess- und die Service-Qualität berücksichtigen.

Volumina – Wie viele Calls je Typ, je Kategorie, je Priorität etc. ? … Gut, es werden Calls erfasst und abgearbeitet; und es gibt Services/Produkte, die mehr oder weniger Calls verursachen - so weit, so gut! Es können aber nur bedingt Aussagen zur Prozess- bzw. Service-Qualität getroffen werden.

Prozess Qualität - Wie gut ist der Incident Management bzw. der Support Prozess selbst? - Messung der Qualität der angebotenen Support-Dienstleistung. Klassische Auswertungen hier betreffen u.a.

  • Erreichbarkeit (meist in Zusammenhang mit dem ServiceDesk als Single Point of Contact - SPOC, durchschnittliche Wartezeit von Anrufern, wie viele Anrufe werden nicht entgegen genommen, etc.)
  • Lösungsraten (Erstlösungsrate im ServiceDesk, Häufigkeit von Vor-Ort Service, Lösungsraten im Second und Third Level)
  • Bearbeitungszeiten (Reaktionszeiten der einzelnen Level, durchschnittliche Störungsdauer, Downtime, Wiederherstellungszeit, Mean Time To Repair MTTR etc.)
    (mehr Details z.B. im DITY Newsletter)
  • Kosten (z.B. Kosten je Störung)

image(Quelle: DITY Newsletter)

Die Auswertung der Prozess Qualität liefert Erkenntnisse für die kontinuierliche Verbesserung (KVP) des Support Prozesses!

Service Qualität - Wie viele Störungen gibt es bei den angebotenen Services / eingesetzten Produkten - Messung der Qualität der angebotenen Dienstleistungen. Maßgeblich hierfür sind die mit dem Kunden vereinbarten Services bzw. Service Levels (in SLAs), Störungs-Häufungen & Schnittstelle zum Problem Management (z.B. in bezug auf Configruation Items), Mean Time Between Failure (MTBF), etc.

Die Auswertung der Service Qualität liefert Erkenntnisse für die kontinuierliche Verbesserung (KVP) des Leistungsangebotes / der angebotenen Services - alles mit dem Ziel die Verfügbarkeit der Services zu erhöhen.

Weitere Aspekte im Incident Reporting könnten sein:

  • Wirksamkeit der IT Organisation = Kundenzufriedenheit
  • Auslastung der Support Mitarbeiter - Call Volumen je Mitarbeiter
  • Sicherheitsbeeinträchtigung (Security Issues)

Auf Basis dieser Grundansätze kann ein erstes Incident Reporting relativ einfach aufgebaut werden. Im Rahmen der laufenden Prozess Management Aufgabe des Incident Managers muss dieses kontinuierlich verbessert, ausgebaut bzw. geschärft werden.

ACHTUNG! Bei Kennzahlen-Systemen und Reporting ist man oft verleitet alles bzw. zu viel auszuwerten! Wesentlich sind einige wenige Kennzahlen, die valide Rückschlüsse auf den Zustand der Prozesse und Services bieten.

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »

… ich bin wieder aufgetaucht!

Freitag 3. April 2009 von wlw

ich bin wieder aufgetaucht.png

Großspurig habe ich in meinem letzten Blogpost die Aktualisierung meiner Homepage verkündet. Das war Mitte Oktober 2008 – das ist dann wohl ca. ½ Jahr her!

Ich bin aus der Versenkung wieder auferstanden! – Welcome back!

In der Zwischenzeit war ich aber nicht untätig. U.a. habe ich mich in meinen Projekten mit folgenden Themen beschäftigt, die sicherlich den einen oder anderen zukünftigen Post beeinflussen werden:

Governance & Strategie

  • Entwicklung von Business Strategien, Balanced Scorecard, Kernkompetenzen (Core Competencies), Erfolgsfaktoren (Success Factors), etc.
  • Erarbeitung und Umsetzung von IT Strategien

Prozesse

  • Ansätze für ein BusinessProcessManagement
  • Effizienz-Steigerung und Kosten-Optimierung in der IT
  • Prozess Orientierung in IT Organisationen
  • Incident & Problem Management – Aufgaben eines Incident Managers, Incident Management Reporting
  • Change Request Management & Release Management
  • SCRUM, Agiles Projekt Management/Agile Software Entwicklung
  • SW Test Management / TPI - Test Prozess

Web & Personal Efficiency

  • GTD, Evernote
  • Microsoft SharePoint
  • Wordpress v2.7, Themes, Plug-in
  • etc.

Einige Ideen für Posts schlummern auch noch in meinen Entwürfen - also Happy Posting in der Zukunft!

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »

Meine Homepage aktualisiert

Sonntag 19. Oktober 2008 von martin

Vielen ist es in der Vergangenheit aufgefallen - meine Homepage/mein Blog war nicht komplett. So etwas wie eine Vision bzw. eine Philosophie war zwar im Menü vorgesehen - “jedoch war nix dahinter”. Auch was meine angebotenen Dienstleistungen nun sind, war nur schwer zu erfahren.

Die endgültige Version ist das nun auch noch nicht, aber zumindest kann man erahnen was dahinter steckt und wofür ich stehe.

In einem Satz ist das ganz einfach zusammen gefasst: “Kundenorientierung in der IT!” - Mein Ziel ist es, IT Abteilungen zu modernen, kundenorientierten Dienstleistern hin zu entwickeln. Einige meiner Posts beschäftigen sich auch geanu damit.

Auch die Kernaussagen der  beiden neuen Seiten lassen diesen Schluss m.M. zu!

Meine Philosophie

Meine Dienstleistungen

… to be continued !

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »

Wer ist eigentlich Shai Agassi?

Freitag 10. Oktober 2008 von wlw

imageHeute schlage ich die Kleine Zeitung auf – und irgendwo im Autoteil lacht mich ein Gesicht an, daß ich schon mal gesehen hatte.  Sieht aus wie Shai Agassi – aber was hat der mit Autos zu tun – der war(!) doch SAP Top-Manager!

Aus meiner Zeit als SAP Berater ist mir Mr. Agassi bestens bekannt. Er war der gefeiert Star in der Führungsriege der SAP, der die Business Software Schmiede ins Internet Zeitalter geschossen hat. Die SAP geriet um das Jahr 2000 massiv unter Druck, da es den Anschein hatte, daß das Unternehmen den Internet Hype etwas verschlafen hatte. Zusätzlich zeichnet Shai´s in den Konzern eingekaufte Software für die KMU Intiative Business One verantwortlich.

image

Nachdem er 2007 den Sprung zum Vorstandschef nicht geschafft hatte, zog er die Konsequenzen und verließ den Dampfer (Vordergründig mal Respekt für diese Entscheidung mit Rückgrat – die genauen Details und Hintergründe kenne ich aber nicht)

Nun – kurze Zeit später – hat er wohl 200 Mio. Dollar auf die Beine gestellt und macht was mit batteriebetriebenen Autos inkl. Austausch-Abo – lt. seiner Aussage: “… die größte Verschiebung in der Geschichte des Kapitalismus …” – sein Projekt: Better Place

image

Tja, mal sehen was draus wird – eine Idee für die Zukunft ist es allemal.

Shai Agassi bezeichnet sich selbst als “Serialentrepreneur” – also sowas wie Ideen am laufenden Band. Anbei ein Podcast (Stanford University) wo er seine Ansätze auf den Punkt bringt! (Achtung! Der Punkt ist 40 min lang)

Reblog this post [with Zemanta]
Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: Management | Keine Kommentare »

Lieben Sie Ihr Unternehmen!

Freitag 10. Oktober 2008 von wlw

image Auf Einladung der Jungen Wirtschaft war ich bei einem Vortrag von Günther Panhölzl - seines Zeichens seit 10 Jahren Trainer & Fachautor.

image  "Unsere Firma - Unsere Zukunfts-Oase" - der Vortrag zum Buch. Das Buch erhält man bei Teilnahme an dem Vortrag als Zugabe.

Mit welchen Erfolgsstrategien können KMUs im Wettberb bestehen. Wie wichtig ist positive Einstellung und ein gutes Team, um seine Kunden zu begeistern.

Es ist am Ende ein Motivations-Vortrag/Buch. Es geht um Team/Firma/Kunden, Eigenmotivation, die (positive) Einstellung zum Leben und zu seiner Arbeit/Aufgabe, Erfolg durch erfolgreiche Teams und natürlich um Kundenorientierung. Eine Sammlung von Methoden, Ansätzen, Ideen und Anregungen, die man irgendwo alle schon mal gehört hat.

Ein Sager, der mir ganz speziell in Erinnerung geblieben ist, weil ich ihn auch laufend in meiner Beratungstätigkeit bringe – bezüglich Veränderungsmanagement – ist:

“Entweder man ist Teil der Hürde
oder man ist Teil der Lösung!”

“Nicht nur Probleme sehen, sondern nach Lösungen suchen!”

image Günther Panhölzl baut - wie andere Motivations-Künstler auch - auf bewährten Thesen auf und mischt alles als sog. Erfolgslotsen zu einem unterhaltsamen Programm zusammen. Gleichzeitig untermalt er die einzelnen Punkte gekonnt mit Beispielen aus der Praxis und (s)einem eigentümlichen Vortragsstil (ein Redner für große Säle).

Alles in allem ein sehr kurzweiliger und unterhaltsamer Abend. Wie bei allen solchen Veranstaltungen gilt die Grundregel: "Nimm einfach das heraus, was für dich relevant/interessant ist!"

In diesem Sinne war es wieder eine willkommene Anregung sich mit Grundthemen des Managements auseinander zu setzen. Das Buch liegt auch am Nachtkastl bereit!

Die weiteren Termine dieser Roadshow findet ihr hier!

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: Management | Keine Kommentare »

Vor-Ort Support in der Praxis

Sonntag 5. Oktober 2008 von wlw

Hier ein anschauliches Beispiel wie Vor-Ort Support funktioniert. Bitte speziell auch darauf achten, wie Benutzer/Menschen an alten erprobten Gewohnheiten festhalten (wollen). IT hat immer mit Veränderung zu tun – ob es in diesem Fall zum Besseren, soll jeder  selbst beurteilen.

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »

Serie: Problem Management - 5. Heureka und mehr

Mittwoch 24. September 2008 von wlw

Das Problem ist erfasst - die Ursache ist untersucht und im besten Fall auch gefunden. - Und nun?

image

Workaround

Wenn im ersten Schritt keine vollständige Lösung gefunden werden kann, so soll zumindest ein Workaround definiert werden. Dies gilt insbesondere bei Störungen und daraus abgeleiteten Problemen - dh. die Störung möglichst schnell beheben - auch mit einem Workaround.

  • Workaround im Problem Record vermerken.
  • Das Problem bleibt aber weiterhin offen.
  • Weiter, tiefer suchen, um eine Lösung zu finden.

Ziel des Problem Management ist die vollständige Behebung des Problems - also kann ein Workaround nur ein Zwischenstep sein.

Known Error

Wenn die Ursache des Problems gefunden wurde und u.U. auch ein Workaround gefunden wurde, kann das Problem als Known Error gekennzeichnet werden. Diese Informationen werden zur schnelleren Abwicklung für zwischenzeitlich auftretende Störungen und Probleme verwendet.

Der genaue Zeitpunkt wann ein Known Error erfaßt wird, hängt von der konkreten Situation ab (kann aus Informations-Gründen auch vor dem Finden der kompletten Ursachen erfolgen)

!! >> Werden neue Funktionen trotz bekannter Fehler produktiv genommen (z.B. weil ein Release trotzdem innerhalb des Zeitplan durchgehen soll), so sollten diese Fehler bereits als Known Errors mit Workaround erfasst werden. Dies wirkt sich im Nachhinein positiv auf die Supportaufwände aus.

Problem Lösung

Im besten Fall wird durch das Problem Management die Lösung zu dem Problem gefunden. Dies wird in den meisten Fällen eine Änderung nach sich ziehen, dh. es ist ein Request for Change zu erstellen.

Die Umsetzung des Changes erfolgt entsprechend den Definitionen im Change bzw. Release Management. Dies kann eine zeitliche Verzögerung bedeuten. Handelt es sich aber um ein signifikantes Problem, so kann ggf. eine Notfall Änderung angestoßen werden.

Egal ob der Change sofort umgesetzt wird oder nicht, die Lösung ist auf jeden Fall im Problem bzw. Known Error Record zu vermerken

Problem Abschluss

Nachdem der angeforderte Change umgesetzt und überprüft wurde, kann das Problem und alle verknüpften Records (z.B. Incidents) abgeschlossen werden. Alle relevanten Dokumentationen, Known Error, Wissensdatenbank, etc. sollen abschliessend noch auf den aktuellsten Stand gebracht werden.

Dies ist das vorläufige Ende meiner Serie zum ITIL Problem Management Prozess - weitere Serien werden folgen!  ;->

Einfach den Feed abonnieren 

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »

Serie: Problem Management - 4. Auf der Suche nach der Ursache!

Montag 22. September 2008 von wlw

Das Erkennen und Registrieren eines Problems ist die eine Seite - die viel wichtigere ist aber, die Ursache zu finden und eine Lösung zu erarbeiten.

Es ist davon auszugehen, daß du Ursache bei Problemen nicht ohne weiteres zu finden ist (denn ansonsten wäre das Problem schon lange gelöst). Es gilt also, spezielle Techniken und Tools anzuwenden, um eine möglichst effektive und effiziente Ursachen-Analyse durchzuführen.

Entsprechend der nachfolgenden Grafik befinden wir uns im Schritt “Problem Control” mit dem Ziel eine Ursache für das Problem zu finden.image

Vortrag während der itSMF Fusion 2008 von Jay Long (gesehen im Blog IT´s About Uptime)

Oft verwendete Hilfsmittel zur Ursachen-Ermittlung:

  • Recherche in den vorhandenen Wissendatenbanken (u.a. in Incidents und Known Errors)
  • Fehler chronologisch nachstellen (im Detail inkl. Ablauf-Protokoll), um die Ursache besser eingrenzen zu können
  • Brarinstorming - kein Kommentar ;–> Wikipedia
  • “Pain Value” Analyse - (aus ITIL v3) berücksichtigt mehrerer Faktoren (Anzahl betroffene User, Dauer des Ausfalls, Kosten des Ausfalls, etc.) und versucht so die Priorisierung zu verfeinern (behandelt also nur indirekt die Ursache) –> Link
  • “Kepner & Tregoe” Methode - Problem definieren, im Detail beschreiben, mögliche Ursache identifizieren, was ist wahrscheinlich, überprüfen. –> Wikipedia, dazu im Problem Mgmnt Blog, itsmsolutions Beitrag, kepner-tregoe.com
  • Ursache-Wirkung (Ishikawa)-Diagram - kein Kommentar
    ;–> Wikipedia, itsmsolutions Beitrag

image

Eine Methode die von vielen Praktikern favorisiert wird ist die “5 Whys” Methode - übersetzt 5 x Warum. Es ähnelt ein klein wenig an Kindererziehung, aber das Ziel ist event. das gleiche - Finde heraus was wirklich dahinter steckt! Hier einige Referenzen dazu: wie immer gibt es alles bei Wikipedia, aber auch Hank Marquis von itsmsolution hat eine kurze Zusammenfassung, genauso wie Dennis Powell im StockSafe Blog.

!! >> Für eine möglichst effiziente Recherche in bereits bekannten Themen ist die laufende Pflege der Wissendatenbanken bzw. der Known Error Datenbank wichtit. Darauf ist bei der Umsetzung der Prozesse zu achten.

!! >> Um Problem nachvollziehen zu können ist meist ein Test-System hilfreich (ähnlich wie auch beim Test von Changes). Daraus  ergibt sich, bei so vielen Systemen wie möglich, zumindet eine 2-System Landschaft.

!! >> Ziel ist es Ursachen zu finden und Probleme zu lösen - immer die für die Organisation und das Problem geeignete Methode auswählen. Auf keinen Fall mit blindem Aktionismus an das Thema ran gehen.

weitere Referenzen:

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren 

Community
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Technorati
  • co.mments
  • email
  • Live
  • TwitThis

Kategorie: ITIL | Keine Kommentare »