IT Prozess Automatisierung mit BMC Atrium Orchestrator

In der Industrie erhielt die Automatisierung bereits vor über einem Jahrhundert den Einzug. Auch in der IT-Welt wird immer stärker von industrialisierten IT-Services und Commodity gesprochen. Doch tatsächlich ist der Grad der Automatisierung von IT-Betriebsaufgaben in den meisten Unternehmen noch recht gering.

Woran liegt der geringe Automatisierungsgrad von IT-Betriebsaufgaben?

Bei Automatisierung von IT-Betriebsabläufen denken die meisten Administratoren an Scripts – kleinen Programmbausteinen, die eine Teilaufgabe automatisch ausführt. Doch damit lässt sich in der Regel nur ein geringer Teil der Aufgaben automatisieren. Es fehlt häufig am übergreifenden Ansatz, der keine Grenzen zwischen Technologie-Silos kennt. Ein Ansatz, der Systeme miteinander verbindet und Dokumentationen ebenfalls automatisch integriert. Aus dieser Perspektive geht es gar nicht mehr so sehr um die technische Automatisierung der Einzelaufgaben sondern um die Orchestrierung – das Zusammenspiel – der vielen kleinen Bausteine.

Wie geht man sinnvoll an IT Prozess Automatisierung heran?

Generell lässt sich nur automatisieren, was bereits standardisiert ist. Es empfiehlt sich folgende Reihenfolge:

1.       Konsolidierung

2.       Standardisierung

3.       Automatisierung

Zum Beginn sollten also IT-Service Prozesse identifiziert werden, welche bereits einen hohen Standardisierungsgrad erreicht haben. Sie sollten nicht nur wiederholbar sondern auch durchgängig dokumentiert sein – sofern man sich in der Praxis auch tatsächlich an die dokumentierten Prozesse hält.

Zu jedem zu automatisierenden Prozess sollte eine IST-Aufnahme und eine Zielsetzung festgelegt werden. Besonders interessante quantitative Kennzahlen sind:

-          Durchlaufzeit des Prozesses

-          Personalaufwand je Durchlauf

-          Häufigkeit der Prozessausführung

Darüber hinaus stehen qualitative Kriterien auf dem Prüfstand:

-          Kontinuität in der Service Erbringung

-          Fehlerquellen wie Tippfehler durch manuelle Aufgaben

-          Zufriedenheit der Service-Konsumenten

Es sollte also exakt ermittelt werden, wie der Prozess aktuell funktioniert und welche Ziele durch die Automatisierung erreicht werden sollen. Diese Betrachtung kann auch als Basis des Business Cases dienen.

Wo fängt man an mit der IT-Prozess Automatisierung?

Es gilt der Grundsatz: Vom Kleinen zum Großen!
Beginnen Sie bei den kleinen IT-Service Prozessen mit geringer Komplexität. Diese sind schnell umsetzbar und dienen am besten als Quick-Wins für die Projektakzeptanz.  Außerdem lernen Sie bei der Umsetzung dieser Prozesse und sammeln wichtige Erfahrungen, die Sie für die Automatisierung komplexerer IT-Service-Prozesse benötigen.
Ganz konkret beginnen die meisten Unternehmen mit der Automatisierung einfacher Prozesse im Bereich des User-Managements. Die Favoriten sind hier:

-          Anlegen neuer User-Accounts

-          Zurücksetzen von Passwörtern

Diese Prozesse eignen sich aufgrund der überschaubaren Komplexität und sind bei den meisten Organisationen aufgrund der Sicherheitsanforderungen bereits gut dokumentiert. Sie werden gerade in größeren Unternehmen häufig durchgeführt und die eingesetzten Systeme verfügen über nötige Schnittstellen zur Ansteuerung der Automatisierung. Sie sind auch die Grundlage für die meisten komplexeren IT-Service-Prozesse.

Einsatz von Werkzeugen zur IT-Prozess Automatisierung

Generell lässt sich bei den Tools zwischen zwei Ebenen unterscheiden.

-          Steuerung / Orchestrierung der IT-Prozess Automatisierung

-          Technische Automatisierung einzelner Komponenten und Systeme

Um eine IT-Prozess Automatisierung in Enterprise-Umgebungen ganzheitlich umsetzen zu können, benötigen Sie beide Arten von Tools. Das Orchestrierungstool sollte übergeordnet betrachtet werden, da es die logischen Prozessabfolgen abbildet und alle einzelnen Bausteine in der entsprechenden Reihenfolge anstößt und verbindet. Dieses Tool sollte möglichst mächtig sein und über geeignete Mittel verfügen, um die Komplexität der Prozesse einfach abzubilden. Bereits vordefinierte Module können Ihnen helfen, das Automatisierungsprojekt in kürzerer Laufzeit und mit weniger Aufwand umzusetzen. Es sollte sich auch über bestehende Schnittstellen in Ihre IT-Service Management Landschaft und Dokumentationssystemen wie CMDB einbetten. Da insbesondere große Unternehmen in diesem Bereich häufig BMC Produkte wie die ITSM Suite und die Atrium CMDB nutzen, eignet sich in solchen Umgebungen die BMC Lösung Atrium Orchestrator aufgrund der nahtlosen Einbettung besonders.

Die Tools zur technischen Automatisierung einzelner Komponenten und Systeme sind wesentlich fachspezifischer und vielfältiger. Unterschiedliche Technologien werden unterschiedliche Tools erfordern. Viele Systeme bieten bereits integrierte Management-Komponenten mit geeigneten Schnittstellen. Hierzu lässt sich keine generelle Empfehlung geben – viel mehr sollten Sie mit den Fachverantwortlichen die verfügbaren Möglichkeiten evaluieren und auf Integrierbarkeit mit dem Orchestrierungswerkzeug prüfen.

Organisatorische Aspekte bei der IT-Prozess Automatisierung

Projekte zur Automatisierung von IT-Prozessen haben direkten Einfluss auf die IT-Organisation. Da IT-Prozesse sich nicht an die organisatorischen Grenzen halten, wird das teamübergreifenden Denken und Arbeiten gefordert und gefördert. Dieser Aspekt kann nicht deutlich genug hervorgehoben werden, denn durch den Willen und die Qualität der übergreifenden Zusammenarbeit wird der Projekterfolg wesentlich beeinflusst.

Die Umsetzung der IT-Prozess Automatisierung erfordert auch nach der Projektorganisation ein Umdenken bei Mitarbeitern im IT-Betrieb. Die Tätigkeiten verlagern sich tendenziell von Routinetätigkeiten hin zu steuernden Aufgaben. Es werden neue Rollen geschaffen und diese gilt es in der Organisation zu verankern und mit Leben zu füllen.

Fazit

IT-Prozess Automatisierung bietet hohe Potentiale für Qualitätssteigerung bei gleichzeitiger Senkung der Betriebskosten. Diese Potentiale sind in den meisten Organisationen bislang kaum genutzt. Die Einführung der IT-Prozess Automatisierung sollte nicht als rein technisches Projekt betrachtet werden. Organisatorische Aspekte und der Faktor Mensch sollten gerade zum Beginn mit hoher Priorität betrachtet und berücksichtigt werden. Die Umsetzung der IT-Prozess Automatisierung reduziert keine Komplexität – Sie verlagert Komplexität von Einzelpersonen in einen Automatisierungsprozess. Dies erfordert hohes Abstraktionsvermögen, Detailgenauigkeit und Erfahrung in der Herangehensweise. Es empfiehlt sich folglich die Kombination aus internen Wissensträgern mit externen Beratern mit Erfahrung in der IT-Prozess Automatisierung.

Stehen Sie vor oder in einem IT-Prozess-Automatisierungsprojekt?  Haben Sie konkrete Fragen oder Anregungen? Bitte schreiben Sie einen Kommentar zu diesem Post.

MyIT von BMC - Enduser stehen im Fokus

Mit MyIT möchte BMC das Erlebnis für Endanwender wesentlich verbessern.

MyIT wird kommen - voraussichtlich Anfang 2013. Und es wird eine wesentliche Verbesserung in der Wahrnehmung der IT-Abteilung durch die Endanwender unterstützen. Der erste Schritt war bereits durch Service Request Management (SRM) getan. Doch gerade in der aktuellen Zeit
- privat ist man gewohnt über Amazon zu bestellen und mit dem iPhone ganz einfach Termine zu vereinbaren - wird es immer wichtiger, die Erwartungen der Endanwender zu erfüllen. Und der Weg zum Herzen der User führt über das User Portal zur IT-Abteilung.

Der erste Eindruck von MyIT war positiv. Die Oberfläche ist modern und ansprechend gestaltet. Die wichtigsten Funktionen sind übersichtlich zu finden. Endanwender können sich schnell und einfach einen Überblick über Ihre IT-Services bekommen. Die Anfordernugen eines anspruchsvollen Users scheinen wirklich gut erfüllt zu werden.

Infos von BMC Software:
http://www.bmc.com/products/myit/

BMC BSM International Airport Simulation

Heute möchte ich die BMC BSM International Airport Simulation vorstellen.
Es handelt sich um eine spannende Variante des praxisnahen Lernens. Im Rahmen eines Tages nehmen die Teilnehmer unterschiedliche Mitarbeiter-Rollen eines fiktiven Flughafens ein. So ist vom Technischen Experten, über den Service Desk Mitarbeiter bis zum Management alles vertreten.
Ähnlich wie in einem Rollenspiel fürs Business gibt es mehrere Runden, die gespielt werden. Es werden üblicherweise 3-5 Runden gespielt. Eine Runde dauert jeweils 25 Minuten. Während der Runden sind die Teilnehmer - je nach zugeordneter Rolle - fleißig am Arbeiten in diesem virtuellen Flughafen.
Beispiel Szene: Das Radar fällt aus. Die Manager werden nervös, weil einige Flüge nicht starten können. Beim Service Desk läuft das Telefon ununterbrochen. Die technischen Experten rätseln und rätseln, was wohl die Lösung sein könnte.

Zwischen den Runden wird Reflektiert. Wie haben wir gearbeitet. Was lief gut - was nicht so gut? Wie läuft die Kommunikation und wie funktionieren Prozesse und Tools? Daraus werden Verbesserungsmaßnahmen für die nächste Runde abgeleitet.

Besonders wichtig: Es gibt keinen Trainer sondern lediglich einen Spielbegleiter, der den Ablauf und die Lernprozesse begleitet. Alle Lernergebnisse werden durch die Teilnehmer selbst erarbeitet.

Dieses Lernen auf Basis eigener Erfahrungen hat wesentliche Vorteile:

• Es macht unheimlich viel Spaß.
• Es prägt sich viel besser ein, als eine Powerpoint-Schlacht.
• Die Lernergebnisse sind später wesentlich leichter in die Praxis umzusetzen.

Inhaltlich geht es im Kern um die ITIL Prozesse sowie geeignete Tools und deren Einsatz in der Praxis.

Ich hatte das große Vergnügen, für dieses Programm als Trainer ausgebildet zu werden. Es macht auch als Trainer unheimlich viel Spaß. Ich hatte selten andere Seminare mit so guter Stimmung und so viel Lernerfolg.

Wer selbst schon mal bei einer Simulation teilgenommen hat, ist herzlich dazu eingeladen, die eigenen Erfahrungen im Kommentar zu hinterlassen.

IT-Outsourcing Due Diligence

IT-Outsourcing Due Diligence

Ob es den Begriff IT-Outsourcing Due Diligence wirklich gibt, ist noch eine offene Frage. Aber dass eine Due Diligence vor einem IT-Outsourcing Deal sinnvoll ist, weiß jeder Bid Manager, der auf Basis mangelhafter Daten ein defizitäres Projekt gewonnen hat.

Worum geht es in der Due Diligence für IT-Outsourcing?
Die Zielsetzung ist, ein möglichst klares und transparentes Bild über den Vertragsgegenstand - die bestehende IT des Kunden - zu bekommen.

Folgende quantitativen technischen Fragen werden beantwortet:
Wie viele Server sind im Betrieb?
Wie alt sind die Server?
Welche Betriebssysteme, Middleware und Applikationen laufen auf den Servern?
Welche Storage-Arten und Kapazitäten werden betrieben?
Wie viele Clients, Art der Clients, Hersteller, Modelle, Betriebssysteme, Applikationen usw. werden betrieben?

Die quantitative organisatorische Frage ist typischerweise:
Wie viele Mitarbeiter arbeiten in der IT-Abteilung?

Eine weitere Dimension, die in einer IT-Due Diligence für Outsourcing betrachtet werden sollte, bezieht sich auf die Organisation.
Sind die Prozesse ITIL orientiert?
Wie ist der Reifegrad?
Liegen Zertifizierungen wie ISO 9000 oder ISO 20000 vor?
Ist das Unternehmen bezüglich der IT SOX / EURO-SOX compliant?
Ist Cobit implementiert und etabliert?


Auch der Umgang mit kritischen Risiken sollte untersucht werden:
Wie ist es um Backups bestellt?
Gibt es Desaster Recovery Konzepte?
Sind Mitarbeiter auf den K-Fall vorbereitet?
Gibt es Doppelbesetzung bzw. Vertreterregelungen bei Schlüsselpersonen?
Welche Maßnahmen für Availability und Continuity werden unternommen?

Sicher gibt es noch viele weitere Punkte, die berücksichtigt werden sollten. Doch klar ist auch, dass die Durchführung einer Due Diligence kein Selbstzweck ist. Nicht aller Informationen und Daten, die erfasst werden können, sind für die Entscheidungsprozesse im Outsourcing relevant und hilfreich. Daher sollte man gut darauf achten, welche Informationen bei einer IT-Outsourcing Due Diligence tatsächlich erfasst und ausgewertet werden. Manchmal ist weniger einfach mehr.

SRM Approval: Alternate Approver unter Remedy ITSM 7.6.04

Ein Service Request unterliegt in den meisten Fällen einem Approval Prozess. So muss z.B. der Manager erst zustimmen, bevor die Bestellung eines neuen Notebooks auch wirklich durchgeführt wird. Nun haben Manager gern die Angewohnheit, in solchen Situationen nicht an Ort und Stelle zu sein. Vielleicht lässt er oder sie sich gerade die Sonne auf einer schönen Südseeinsel auf den Bauch scheinen. Um nicht zu lange warten zu müssen, ist es im ITSM 7.6.04 möglich, einen Alternate Approver festzulegen. Dieser bekommt, je nach Einstellungen, dann auch entsprechende Benachrichtigung, wenn es neuer Request zu bestätigen ist. Im Approval Central können dann durch den Alternate Approver quasi im Auftrag des eigentlichen Approvers die Genehmigungen gesetzt werden. So findet der Manager nach seinem Urlaub auch glückliche Mitarbeiter mit vielen neuen Notebooks vor.

BMC CLM 3.0 - Cloud Lifecycle Management 3.0

Auch dieses Post ist vorbereitend auf einen Beitrag zur CLM 3.0 / Cloud Lifecycle Management 3.0 gedacht. Haben Sie Fragen oder Themen, die Sie zur CLM 3.0 / Cloud Lifecycle Management 3.0 hier gern lesen würden?

BMC ITSM 8.0

BMC hat die ITSM Suite 8.0 als Nachfolgeversion von ITSM Suite 7.6.04 veröffentlicht. Doch was hat sich mit diesem Major Update geändert?
Die Frage ist nicht ganz einfach zu beantworten, das offizielle "What´s new in ITSM 8.0" Dokument umfasst einige hundert Seiten. Ich möchte die aus meiner Sicht wichtigsten Änderungen vorstellen:

Die größte Veränderung ergibt sich im Service Request Management (SRM 8.0) und ist damit auch für die Enduser direkt spürbar. Die Benutzerführung und das komplette Look&Feel wurde deutlich modernisiert und verbessert. Insbesondere die Integration vom Knowledge Management in SRM 8.0 ist gelungen und ein deutlicher Schritt nach vorn.
Es wurden auch weitere Kommunikationsmöglichkeiten in Richtung Web 2.0 integriert, die auf mich allerdings eher einen "Me-too" Eindruck für das Marketing machen. Vielleicht verbessert sich hier die Integration und Nutzbarkeit in der ITSM Suite 8.1.

Aus architektonischer Sicht dürfte die größte Neuerung die Hub and Spoke Funktionalität sein, welche es insbesondere bei großen Organisationen vereinfacht, verteilte Strukturen auch duch das System gezielter zu adressieren.

Das Remedy User Tool war schon länger todgesagt - nun ist es auch tatsächlich nicht mehr nutzbar. User greifen per Webbrowser über den MidTier Server auf die Applikationen zu. Das trifft auch auf die Administratoren zu. Dank optisch ansprechender und schneller Oberflächen fällt die Umgewöhnung in der Praxis wesentlich einfacher, als man es sich vorher vorstellen mag.

ITSM Basics: Vom Service Request zum Change

In diesem Beitrag möchte ich einfach und Verständlich den Weg vom Service Request zum Change Ticket darstellen.

Das Service Request Management bietet mit dem Self Service Portal Endbenutzern die Möglichkeit, Requests direkt im System einzugeben. Dies entlastet das Service Desk und wird häufig als angenehmer Service empfunden.

Aus einem Katalog an Services kann der Endbenutzer auswählen. Der Bestellprozess ist recht einfach gehalten und kann von jedem Computer-Benutzer einfach durchlaufen werden.

Nach der Bestellung werden viele Requests wie z.B. eine Notebookbestellung, zum Manager für die Genehmigung gesendet. Nach dieser Genehmigung erzeugt das System automatisch aus dem Service Request ein Change Ticket und weißt es der zuständigen Bearbeitungsgruppe zu.

Der Prozess schaut auch bei Incidents aus dem Service Request Management ganz ähnlich aus. Nur wird hier in der Regel auf Genehmigungen vom Manager verzichtet.

OT: Tandoor Ofen

Für Grillfreunde und Indian-Fans gibt es etwas ganz besonderes. Der erste deutsche Tandoor Ofen Lieferant hat eröffnet. Unter Tandoor Ofen "The German Tandoor" finden sich nützliche Informationen. Holen Sie sich ein Stück indische Kochkultur in Ihren Garten.

Service Request Management - Akzeptanz im Unternehmen

Das Tor zur Welt! Für die Mitarbeiter eines Unternehmens, in dem eine ITSM Lösung mit Self Service Portal eingeführt wird, sehen nur diese eine Stelle der Lösung. Sie loggen sich im Service Request Management (SRM) ein und suchen nach den passenden Bestell- oder Störungsmeldungs-Möglichkeiten. Handelt es sich nun um die Bestellung einer IT-Komponente, welche wegen der Kosten durch den Vorgesetzten genehmigt werden muss, so kommt die potentielle Schlüsselperson "Manager" ins Spiel. Nur wenn Sie den Managern das System erklärt habe und sie sich schnell und einfach im System zurecht finden, arbeiten sie gern damit. Dann wird es als positive Unterstützung empfunden, dass man den Antrag per Handy freigeben kann und keine lästigen Formulare mehr ausfüllen und unterschreiben muss. Doch wenn die Benachrichtigungen unprofessionell ausschauen und der Manager sich nicht unmittelbar im System zurecht findet, dann wird es als Last empfunden. Schließlich ist es etwas Neues. Dem gegenüber sind viele Manager generell erst einmal skeptisch. Wenn sich die Befürchtungen dann einmal bestätigen, ist die Akzeptanz kaum wieder herzusellen. Machen Sie sich also Freunde und keine Feinde. Sorgen Sie dafür, das Mitarbeiter und Manager das Self Service Portal / Service Request Management vorab kennenlernen und sich gut zurecht finden.

ITSM Schulungen für Endbenutzer

Checkliste

Ein wesentlicher Erfolgsfaktor einer ITSM Einführung ist die Schulung der Benutzer. Denn nur, wenn sich die User sicher mit dem neuen System fühlen, werden Sie es positiv aufnehmen.

Wie geht man diese Schulung am besten an? Folgende Checkliste soll dabei helfen.

Identifikation der Zielgruppe:
Finden Sie heraus, wer genau mit dem System arbeiten wird. Lassen sich die Benutzer in verschiedene Gruppen einteilen? Typische Gruppen wären First Level Support, Second Level Support sowie Endbenutzer mit Zugriff auf das Self Service Portal (Service Request Management).

Vorwissen feststellen:
Welchen Kenntnisstand bringen die Teilnehmer mit? Handelt es sich um eine Ablösung eines bestehenden Systems? Welches Wissen kann davon weiter angewendet werden? Gibt es Teilnehmer ohne Vorkenntnisse? Je mehr Sie über das Vorwissen in Erfahrung bringen können, um so genauer treffen Sie Erwartungen der Teilnehmer.

Festlegen der Lernziele:
Was genau sollen die Teilnehmer nach der Schulung wissen und können? Je genauer Sie die Lernziele vorab beschreiben, um so leichter fällt Ihnen die Ausarbeitung der Trainingsunterlagen.
Für mich bewährt hat sich, die zukünftigen Arbeitsprozesse der Teilnehmer als Grundlage für die Lernziele zu verwenden.

Methode festlegen:
Welche Methode ist für die ITSM Schule am besten geeignet? Sind die Teilnehmer am selben Ort oder müssen Reisen einkalkuliert werden? Ist das Unternehmen technisch up-to-date und nutzt bereits häufiger Websessions?
Für mich bewährt haben sich Websessions von 1,5 Stunden mit Live-Zugriff auf das ITSM-System.

Trainings-Script schreiben:
Gehen Sie alle Schritte des Trainings genau durch und halten Sie diese schriftlich fest. Wann sollen welche Informationen vermittelt werden? Was wird in welchem Ablauf im System gezeigt? Welche Accounts mit den passenden Berechtigungen werden an welcher Stelle verwendet? Am besten Sie haben einen Co-Trainer, der auch im Hintergrund Eingriffe im System durchführen kann (Beispiel Approvals).

Trainingsunterlagen erstellen:
Erstellen Sie die Unterlagen möglichst frühzeitig. Doch achten Sie im laufenden Pojekt auf die Inhalte und Screenshots. Die Unterlagen sollten identisch mit dem tatsächlichen Live-System sein und keine alten Stände beinhalten.

Termine planen und Teilnehmer einladen:
Planen Sie die Termine so, dass eine große Varianz entsteht. Vormittag und Nachmittag; Beginn der Woche und Ende der Woche sowie einen Termin mit mindestens 2 Wochen zeitlichem Abstand. So können auch Teilzeitkräfte und Urlauber ohne Probleme teilnehmen.
Senden Sie die Einladung nach Möglichkeit 2-4 Wochen vor dem Termin.

Probelauf:
Machen Sie eine Generalprobe. Durchlaufen Sie die komplette Schulung inklusive aller Schritte im ITSM-System. Nur so finden Sie heraus, ob alles funktioniert und Sie im zeitlichen Rahmen liegen.

Seien Sie entspannt:
Während des Trainings sollten Sie entspannt sein. Sorgen Sie für sich. Achten Sie darauf, dass Sie vor und nach dem Training genügend Pause haben. Gehen Sie vorher noch eine Runde spazieren oder lesen Sie einen guten Witz.

Nach Feedback fragen:
Nutzen Sie die Zeit zum Ende des Trainings und fragen Sie die Teilnehmer, wie es ihnen gefallen hat. Gibt es Verbesserungsmöglichkeiten. Hat es Spaß gemacht? Wurden die Erwartungen erfüllt? Dieses Feedback ist für Sie besonders wertvoll, denn so kann man sich schnell und einfach bis zum nächsten Training verbessern.


Habe ich auf der Checkliste etwas vergessen? Wie bereiten Sie Ihre Trainings vor?

Langfristige Strategie versus Quick Wins

Der Erfolg jeder Unternehmung ist die Differenz zwischen Input und Output!
So einfach dieses Grundprinzip ist, so schwierig ist es im täglichen Leben, es in konkrete Entscheidungen und Maßnahmen umzusetzen. Denn dieses Prinzip trifft keine Aussage über den zeitliche Betrachtungshorizont.
Steht das Unternehmen wirtschaftlich auf einem solieden Fundament und möchte z.B. neue Märkte erschließen um weiter zu wachsen, so wird wahrscheinlich der langfristige Erfolg im Fokus stehen. Es ist nicht zwingend erforderlich bereits nach kürzester Zeit Erfolge zu erzielen. Der Erfolg wird eher nach 3-5 Jahren betrachtet.
Stehen jedoch konkrete wirtschaftliche Probleme oder Risiken an und führen zu einem Handlungsdruck, so wird der kurzfristige Erfolg wesentlich stärker in den Fokus rücken.
Denn nur wenn die Maßnahme bereits nach einigen Wochen oder Monaten Erfolge zeigt, so kann das Unternehmen es sich leisten, diese Maßnahme weiter zu führen.

Auf das Beispiel von Geldanlagen übertragen, so kann ich mit einer kurzfristigen Anlage sicheren Gewinn einfahren, welcher zwar ok ist, aber niemanden so richtig vom Hocker reißt. Wenn ich das Geld über habe und langfristige Anlagestrategien verfolge, so kann ein wesentlich höherer Ertrag erwirtschaftet werden. Doch durch Wertschwankung kann es gerade zum Beginn auch durchaus zu einem zeitweisen Wertverlust führen.

Als Ergebnis dieses Beispieles wären langfristige Strategien wegen der höheren Rendite zu bevorzugen. Doch neben den Ergebnissen der Berechnung treffen immer auch Menschen mit eigenen Erfahrungen und Werten die Entscheidungen in Unternehmen. Und so kann es wichtig sein, die persönlichen Präferenzen der Entscheidungsträger in die Auswahl der geeigneten Maßnahmen einzubeziehen.
Eine langfristige Strategie läst sich vielleicht auch dann verkaufen, wenn ich sie mit Quick Wins auf die Bedürfnisse des Entscheiders zuschneide. In dieser Kombination gewinnen beide Seiten. Die hohe Renditechanche wird gekoppelt an kleine und schnell spürbare Erfolge.

ITSM Projekte mit Entwicklungsanteilen managen und dokumentieren

ITSM Projekte können dank guter Standards wie ITIL v3 sowie Tools wie die ITSM Suite von BMC, welches out-of-the-box bereits die wesentlichen IT Service Management Prozesse abbildet, auf einer weit entwickelten Basis aufsetzen. Doch trotz aller Standards und Best Practice sind immer wieder Anpassungen und Erweiterungen notwendig.
Doch wie kann man diese Entwicklungstätigkeiten gezielt steuern und dokumentieren? In vielen ITSM Projekten werden diese Anpassungen nur rudimentär in behelfsweise eingesetzen Dokumenten mit Excel oder Word dokumentiert.
Was passiert, wenn ich die Anpassung auf der Entwicklungsumgebung fertiggestellt habe? Wie können die Anpassungen auf die Integrationsumgebung für Tests und Qualitätssicherung migriert werden? Und wie geht es dann anschließend weiter auf die Produktionsumgebung? Wie lässt sich die Notwendigkeit der Anpassung nach einigen Monaten oder sogar Jahren rekonstruieren? "Warum genau hatten wir das damals noch mal so gemacht?"
Diese Fragen sollten in der durchgängigen Dokumentation beantwortet werden. Und die Erstellung dieser Dokumentation sollte integraler Bestandteil des Entwicklungsprozesses sein.

Projektmanagement: Vertrauensverhältnis zwischen Projektleiter und Auftraggeber

Projekte sind komplexe Organisationen und können und in einem gut funktionierenden Team erfolgreich umgesetzt werden. Dies gilt ganz besonders für die Beziehung zwischen Auftraggeber und Projektleiter.
Der Auftraggeber beauftragt den Projektleiter mit der Lösung eines für ihn wichtigen Problemes unter zuhilfenahme bestimmter Ressourcen. Das bedeutet konkret, dass der Auftraggeber einen Teil seines unternehmerischen Erfolges in der Verantwortung an den Projektleiter überträgt. Allein die Benennung des Projektleiters ist also ein Vertrauensbeweis. Und Vertrauen ist in dieser Beziehung von entscheidender Bedeutung.
Anders herum ist der Projektleiter zur erfolgreichen Abwicklung seines Projektes direkt abhängig vom Auftraggeber. Nur wenn dieser die Voraussetzungen schafft und Ressouren bereitstellt, kann das Projekt erfolgreich abgewickelt werden. Und ein gescheitertes Projekt im persönlichen Lebenslauf des Projektleiters könnte negative Fogen haben - ganz unabhängig von den Gründen hierfür.

Doch was passiert, wenn dieses Vertrauen irritiert ist? Wenn Auftraggeber und Projektleiter durch ein gestörtes Vertrauensverhältnis nicht mehr optimal zusammen arbeiten können?
Wenn gegenseitig das Gefühl entsteht, der jeweils andere entspricht nicht den eigenen Erwartungen - und daher könnte das Projekt scheitert?

1. Offene Kommunikation
Sprechen Sie diesen Punkt unbedingt an. Auftraggeber und Projektleiter müssen auf Augenhöhe miteinander sprechen können. Wählen Sie den direkten Weg der offenen Kommunikation.

2. Gute Kommunikation - der Ton macht die Musik
Achten Sie in dieser Situation besonders auf die Regeln der guten Kommunikation. Sprechen Sie über Ihre Wahrnehmung und schwerpunktmäßig in Ich-Botschaften. Vermeiden Sie Vorwürfe oder Unterstellungen. Ermöglichen Sie Ihrem Gegenüber in jedem Fall, das Gesicht zu wahren.

3. Entwicklung beobachten
Vertrauen entwickelt sich über die Zeit. So wird auch ein gestörtes Vertrauensverhältnis nicht unbedingt innerhalb von wenigen Stunden wieder optimal wiederhergestellt sein. Beobachten Sie de Entwicklung daher aufmerksam und geben Sie sich etwas Zeit.

4. Konsequenzen ziehen
Sollte trotz offener Kommunikation keine Besserung eintreten und sich die Lage möglicherweise zuspitzen, so sollten Sie Konsequenzen ziehen.
Im Zweifelsfall ist der Abbruch eines Projektes sinnvoller als das Durchhalten bis zum bitteren Ende. Vielleicht lässt sich ein anderer Pojektleiter einsetzen, welcher das Projekt weiter abwickelt.
Halten Sie sich nicht zu lange in solchen Situationen auf, Sie sollten möglichst bald handeln und die Situation verbessern. Beißen Sie im Zweifelsfall lieber früher als zu spät in den sauren Apfel.

OT: Grillfleisch

Der Sommer ist da und das Grillfleisch will gegrillt und gegessen werden. Wer - wie ich - ein Liebhaber gut gegrillter Delikatessen ist, der kann ja mal unter meiner neuen Website Grillfleisch vorbei schauen.

Alternativ habe ich auch noch einen Link über Ebay zu der Seite: Grillfleisch

ITSM Projektplan Arbeitspaketbeschreibungen

Wie setze ich ein ITSM Projekt erfolgreich auf? Wie schaffe ich es, dass sich die einzelnen Projektmitarbeiter mit ihren Arbeitspaketen identifizieren und diese engagiert umsetzen?

Machen Sie Betroffene zu Beteiligten.
Die erste Aufgabe Ihrer Projektmitabeiter ist die Erstellung einer Arbeitspaketbeschreibung. Hierzu sollten Sie ein Template zur Verfügung stellen, um eine einheitliche Darstellung und einheitliche Inhalte zu bekommen. Erst wenn die Arbeitspaketbeschreibung so klar formuliert ist, dass für Sie ersichtlich ist, dass der Mitarbeiter die Inhalte treffend wiedergegeben hat, geben Sie das Arbeitspaket zur Bearbeitung frei.
Durch dieses Verfahren erreichen Sie eine höhere Tranzparenz über das Verständnis der Mitarbeiter zu den zu erfüllenden Aufgaben. Darüber hinaus erreichen Sie ein höheres Commitment zu dem Arbeitspaket. Somit kann vermieden werden, dass in einer späten Projektphase jemand nicht weiß, was eigentlich seine Aufgabe ist. Oder Termine und Inhalte erst spät als nicht machbar erklärt werden. Denn dies müsste bereits bei der Beschreibung auffallen.

Der erhöhte Dokumentationsaufwand wird in der Regel druch einen reibungsloseren Projektverlauf belohnt!

Workorder versus Change

Workorders:

Sind gedacht für nicht IT-spezifische Objekte und Tätigkeiten, die keinem gesteuerten ITIL Prozess unterliegen.

Beispiel: Bestellung eines neuen Schreibtisches.

Eigenschaften: Unterliegt nicht dem  gesteuerten Change-Prozess. Daher sehr einfach in der Implementierung

Nachteile:

-          Die Nutzung von Workorders für Änderungen an der IT entspricht einer geringen ITIL Prozessreife.

-          Standardisierte Approval-Prozesse werden nicht angesteuert

-          Mangelnde Integration in weitere Prozesse wie z.B. Incident Management & Problem Management

Changes:

Ist gedacht für alle relevanten Änderungen an IT-Komponenten, Systemen und Services.

Beispiel: Installation einer Software

Eigenschaften: Der Change unterliegt dem gesteuerten Change Prozess.

Vorteile: Volle Toolunterstützung des ITIL Change-Prozesses inkl. Approvals und revisionssicherer Dokumentation.

Toolspezifisch bedeutet das:

-          Change Kalender steht zur Verfügung

-          Approval Engine wird angesteuert

-          Funktionale Rollen können genutzt werden

-          CIs können related werden. Später können zum CI die historischen Changes aufgerufen werden.

-          SLAs & Reporting

-          Release Management

-          Integration in weitere Prozesse wie Incident Management sichergestellt (z.B. Kann aus einem Incident ein Change erstellt werden)

Thema Zukunftssicherheit: Mit der Wahl für Changes sind Sie definitiv besser für die Zukunft vorbereitet, insb. wenn das Change Management noch um die Atrium CMDB ergänzt wird.

Fragen an die Verfechter der Workorder:

-          Wie wird der ITIL Change Management Prozess sicher gestellt?

-          Wie wird sichergestellt, dass an einem CI nachvollziehbar ist, welche Änderungen daran stattgefunden haben? Stichwort Compliance & Revisionssicherheit.

-          Wie können mehrere Änderungen im Release Management weiterverarbeitet werden?

Fazit: Eine Workorder entspricht sinngemäß einer ungesteuerten E-Mail oder eines Telefonanrufes. Ist die Aufgabenstellung auch Change Management einzuführen und zu nutzen, so ist der Change das  Mittel der Wahl.

BMC Cloud Lifecycle Management - Management VLAN konfigurieren

Im BMC Cloud Lifecycle Management CLM 2.1 wird für virtuelle Maschinen ein Management VLAN eingerichtet, damit die VMs über ein sicheres VLAN gemanaged werden können. Das VLAN Network Lable muss mit der VLAN ID übereinstimmen und ist keine allgemeine Namensbezeichnung. Nur wenn das Lable mit der ID übereinstimmt, funktioniert das Management VLAN einwandfrei.

BMC Cloud Lifecycle Management - vCenter Integration

Mit BMC Cloud Lifecycle Management CLM 2.1 ist es möglich, Vmware vCenter Server direkt einzubinden und Managementaufgaben zu automatisieren. Hierzu muss lediglich ein spezieller Client vom BladeLogic for Server Automation auf dem vCenter Server installiert und im BBSA Server konfiguriert werden. Und schon kann mit der Konfiguration von virtuellen Paketen für CLM begonnen werden.

Cloud Lifecycle Manager CLM 2.1 - Installation Planner

CLM 2.1 bringt einen Installation Planner mit, welcher die Installationsroutinen der einzelnen CLM Komponenten in der empfohlenen Reihenfolge aufruft und somit über eine zentrale Stelle die komplette Installation planen und durchführen kann. Der Installation Planner ist auf der einen Seite sehr hilfreich - aber voll ausgereift ist er auch noch nicht. So ist besonders darauf zu achten, den "cancel" Button möglichst zu vermeiden, da er zu unerwünschten Ergebnissen wie einer zerschossenen Installation führen kann. Darüber hinaus sind die eingegebenen Variablen besonders genau zu prüfen, da sich nicht alle Angaben später ohne Neuinstallation ändern lassen.

Erst UseCases - dann CMDB Datenmodell

Einer der wichtigsten Bausteine einer ITSM-Initiative ist immer die CMDB. Denn nur mit einer gut aufgebauten und gepflegten CMDB können die ITIL Prozesse auf saubere Daten aufsetzen und konsistente Daten zurückspielen. Daher stürzen sich viele Leute bereits in einer sehr frühen Phase auf das Datenmodell der CMDB. Doch aus dieser Perspektive ist die Aufgabe nur schwer lösbar: Wenn ich nicht weiß, was genau ich mit den Daten mache, kann ich auch nur schwer die Anforderungen an die Datenstruktur ermitteln.
Daher empfiehlt sich hier genau die Gegenteilige Vorgehensweise:
-> Erst alle UseCases ermitteln
-> daraus die Anforderungen an das Datenmodell ableiten
-> mit diesen Information das Datenmodell designen

Erst danach sollte die technische Umsetzung z.B. mittels Atrium CMDB erfolgen.

Cloud Lifecycle Management - CLM 2.1

Cloud Computing ist seit Jahren das Buzzword im IT-Marketing überhaupt. Nun stellen insbesondere große Organisationen fest, dass die Komplexität mit Cloud Computing durchaus auch steigen kann. Es wird immer schwieriger Compliances sicherzustellen. Einzelne Business Bereiche greifen ohne Rücksicht auf Unternehmensrichtlinen und Sicherheitsvorgaben auf Cloud Services zu ohne die IT-Abteilung überhaupt zu involvieren. Unterschiedliche Cloud Services lassen sich nicht ganzheitlich orchestrieren und mit on-premise Lösungen kombinieren. Und es gibt eine Unzahl unterschiedlicher Management- und Administrationswerkzeuge für die einzelnen Komponenten, aus denen sich eine Cloudlösung zusammensetzt.

BMC Software hat mit Cloud Lifecycle Management in der Version CLM 2.1 eine umfassende Plattform geschaffen, die es ermöglicht, Cloudumgebungen im Enterprise und Service Provider Umfeld ganzheitlich zu managen. Kunden können einfach auf ein Service Portal zugreifen und Cloud Services auswählen und bestellen. Das Deployment läuft dann voll automatisch nach den hinterlegten und ausgewählten Parametern wie z.B. Qualität oder Größe. Im Hintergrund werden Compute, Netzwerk und Storage Ressourcen automatisch provisioniert und konfiguriert. Auf Basis von Templates werden virtuelle Maschinen eingerichtet und Applikationen installiert. Die Systeme können in das Monitoring aufgenommen werden. Der Endbenutzer bekommt innerhalb kurzer Zeit voll automatisch den Cloud Service, den er bestellt hat, bereitgestellt und kann ihn nutzen.

Die Cloud Lifecycle Management Lösung ist eine sehr mächtige Lösung. Dem entsprechend sollte bei der Planung vorausschauend gedacht und designd werden.

Wenn Ihr Fragen habt, was man bei Planung & Design von Cloud Lifecycle Management Projekten berücksichtigen sollte, postet einfach einen Kommentar.

Wichtige Fragen fürs Incident Management

Warum soll Incident Management eingeführt werden?
Welche Unternehmensziele sollen durch Incident Management unterstützt werden?
Welcher Manager trägt diese?
Ist der Manager von dem Nutzen der Incident Management Initiative überzeugt?
Welche Ziele werden durch die Incident Management Initiative verfolgt?
Welcher Manager trägt diese?
Ist der Manager von dem Nutzen der Incident Management Initiative überzeugt?
Welche Interessensgruppen sind im Kontext der Incident Management Initiative zu berücksichtigen?
Welche Interessen werden durch diese vertreten?

Wurde eine Stakeholder Analyse durchgeführt?
Werden die Stakeholder-Beziehungen aktiv gepflegt?
Wer hat den größten Nutzen von der Incident Management Initiative?
Wer muss mit den Ergebnissen der Incident Management Initiative arbeiten?

Wurde eine Zieldefinition durchgeführt?
Ist eine hierachische Zielekaskade bis hin zu den Unternehmenszielen erstellt worden?
Sind die definierten Ziele S.M.A.R.T.?

Struktur des Incident Management Prozesses nach ITILv3

In diesem Bloggbeitrag möchte ich die Unterprozesse des Incident Managements in einem vereinfachten Überblick darstellen. Da ITILv3 sich gern am Lebenszyklus-Modell orientiert, ist auch die Struktur im Incident Management entsprechend aufgebaut.



Incident-Erfassung und Kategorisierung
Ziel: Die wichtigesten Informationen der Incident-Meldung werden aufgenommen und festgehalten, um eine schnelle Incident Behebung zu ermöglichen. Der Incident wird priorisiert.

Direktlösung im 1st Level Support
Ziel: Innerhalb einer vereinbarten Lösungszeit soll der Incident gelöst werden. Um eine schnellstmögliche Wiederherstellung des Services zu erreichen, unternimmt der 1st Level den Versuch der Direktlösung, ggf. auch mit Workarounds. Zeichet sich ab, dass der 1st Level den Incident nicht selbst lösen kann oder die vereinbarte Lösungszeit durch den 1st Level überschritten wird, so wird der Incident an den 2nd Level übergeben.

Incidentlösung im 2nd Level Support
Ziel: Der 2nd Level soll den IT-Service schnellstmöglich wiederherstellen. Falls nötig, werden Support-Gruppen oder Supplier (3rd Level Support) eingebunden. Sollte die Behebung der Ursache nicht möglich sein, so wird es an das Problem Management weitergebenen und dort ein Problem Record erzeugt.

Vorgehensweise im SRM - von Use Case bis SRD

Optimal werden vor der technischen Abbildung im SRM die Use Cases formuliert und verifiziert. Erst wenn die Use Cases abgenommen sind, werden z.B. Templates für SRDs erstellt.
Dann werden die Task Templates, Task Group Templates, Change Templates, AOTs, PDTs und SRDs implementiert. Ziel sollte sein, die Anzahl der SRDs möglichst übersichtlich und in der "Sprache" der User zu halten.

Freitextsuche im Service Request Management

Wie bilde ich einen komplexen Software Katalog im SRM der ITSM 7.6.04 ab? Mit den Standardelementen der Form ist es nur schwer so zu strukturieren, dass User auch unter hunderten oder tausenden von Atikeln die gewünschte Software finden. Doch auf Customizing wollen wir bewusst verzichten, denn der Rattenschwanz an möglichen folgenden Problemen ist es nicht wert.
Noch spannender wird es, wenn die Quelldaten für den Softwarekatalog gar nicht in der Atrium CMDB gehalten werden.
In diesem Beispiel wird eine externe SQL Datenbank angebunden und per View-Form verfügbar gemacht. Im Query Builder kann nun erst ein Freitext-Feld eingefügt werden, welches dem User die Eingabe des Such-String ermöglicht. Danach kommt ein Menü-Feld, welches nur die Daten aus der Quelle anzeigt, die identlisch mit dem Such-String sind. Mit % Zeichen kann als Wildcard verwendet werden. Und fertig ist die Volltextsuche mit Menüsauswahl.

Software Katalog in ITSM 7.6.04 und Neuerung in 7.7

In der aktuellen Version ITSM 7.6.04 ist die Abbildung des Software Kataloges für die Enduser im Request Management noch sehr kompliziert. In der neuen Version 7.7 (2. Hj. 2012)werden sehr gute neue Templates mitgeliefert. Hier sollte im Zweifelsfall auf kurzfristiges Customizing verzichtet werden.

Sprachen in BMC ITSM Suite - weniger ist mehr

Eine Installation der ITSM sollte möglichst schlank gehalten werden. Dies beinhaltet auch die installierten Sprachen. Wir empfehlen in der Installation der ITSM daher unbedingt auf unnötige Sprachen zu verzichten und ausschließlich Englisch zu installieren. Damit sind einige Vorteile verbunden:

• kürzere Installationszeit
• kürzere Updatezeiten - dadurch höhere SLAs durch kürzere Wartungsfenster
• wenige Updateaufwand
• weniger Aufwand in der Erstellung von Manuels und Schulungsunterlagen
• weniger Missverständnisse durch unterschiedliche Begriffe

Sollten Sie später gezwungen sein, eine weitere Sprache zu Installieren, so ist dies nachträglich möglich. Anders herum lassen sich einmal installierte Sprachen nicht wieder aus dem System entfernen.

Daher: Tobt euch bei der Mehrsprachigkeit in der Erziehung eurer Kinder aus - aber lasst die ITSM davon verschont!

Abgrenzung Incident & Problem

Wie ist die Abgrenzung von Incident Requests und Problem Records definiert?

Steht ein Service einem Nutzer ungeplant nicht mehr zur Verfügung, so schränkt ihn dies in seiner Tätigkeit ein. Um diese Einschränkung möglichst schnell zu beheben, meldet der Nutzer die Störung dem Service Desk. Diese Einschränkung wird als Incident bezeichnet. Die Meldung der Einschränkung bezeichnet man als Incident Request. Nun soll also der Service schnellst möglich wieder hergestellt werden. Der Incident Request wird nun unterschiedliche Bearbeitungsphasen durchwandern. Jetzt könnte es sich um ein besonders kniffliges Problem handeln und ein Techniker beißt sich daran die Zähne aus. Es ist klar absehbar, dass er die Ursache des Incidents nicht in der vereinbarten Wiederherstellzeit beseitigen kann. Genau wenn dies absehbar wird, sollte aus dem Incident Management ein Problem Record erfasst werden.

Incident

Service Einschränkung oder Service Unterbrechung, welche es schnellstmöglich, ggf. durch Workarounds, zu beheben gilt. Der Fokus liegt nicht auf der besten Lösung sondern auf der schnellen Wiederherstellung der Funktion.

Problem

Besonderen Fällen muss man auf den Grund gehen. Um vorzubeugen und um das Problem bei der Wurzel zu packen. Diese Fälle müssen genau analysiert werden und unterschiedliche Lösungsmöglichkeiten müssen abgewogen werden. Dies steht im Gegensatz zur schnellen Vorgehnsweise beim Incident Management. Daher wird nach ITIL hier das Problem Management eingebunden, welches sich nach eigenem Prozess und Rollen um genau diese Fälle kümmert.

Abgrenzung

Die Abgrenzung von Incident und Problem liegt demnach in der unterschiedlichen Zielsetzung der Prozesse:
Incident - schnell
Problem - nachhaltig

Abgrenzung Incident und Service Request

Wie unterscheiden sich Incident Requests von Service Requests?

Incident Request: Service Unterbrechung
Beispiel: Der E-Mail Service ist unterbrochen. Es können keine Mails mehr gesendet oder empfangen werden.

Service Request: Generelle Service Anfrage
Beispiel: Der Mitarbeiter in der Produktion hatte bislang keinen E-Mail Service, benötigt zukünftig aber auch E-Mails.

Service Requests sind also häufig Anforderungen für die Service-Bereitstellung oder Änderungen an bestehenden Services. Sie können daher zur weiteren Ausführung einen Change anstoßen.

Gelegentlich treten auch Service Requests in Form von reinen Informationsanfragen auf.

SLA Messung für Service-Verfügbarkeit

In diesem Blogbeitrag möchte ich die unterschiedlichen Methoden zur SLA Messung der Service Verfügbarkeit mit den jeweiligen Vor- und Nachteilen darstellen.

SLA Messung "Incidents von Meldung bis Lösung"
Vorteile
Einfache Messmethode, da kein zusätzlicher Aufwand für die Ermittlung der Service Verfügbarkeit entsteht.

Nachteile
Es wird eigentlich nicht die tatsächliche Downtime sondern die Bearbeitungszeit von Incidents gemessen. Es kann also zu Abweichungen der ermittelten und tatsächlichen Verfügbarkeit kommen.

SLA Messung "Service Downtime"
Vorteile
Unabhängig der Incident Bearbeitungszeit wird die Service Downtime im Incident manuell durch den Incident Bearbeiter erfasst.

Nachteile
Die Bearbeitungsdauer ist abhängig von der Disziplin der Erfassung von Service Downtimes und Restores. Es kann also zu Abweichungen der eingetragenen und tatsächlichen Verfügbarkeit kommen.

SLA Messung "System- und Service-Monitoring"
Vorteile
Die Messung der Serviceverfügbarkeit erfolgt automatisiert und stetig. Es werden also auch Serviceunterbrechungen erfasst, welche nicht als Incident gemeldet werden. Sobald die Service Verfügbarkeit wieder hergestellt ist, wird auch dies erfasst. Es ist also eine sehr genaue und umfassende Messmethode.

Nachteile
Es muss ein umfangreiches Service-Monitoring implementiert und betrieben werden. Eine fehlerhafte Konfiguration kann zu falschen Daten führen.

Incident Management - die einzelnen Schritte von der Meldung bis zum Abschluss

In diesem Blogbeitrag möchte ich die typischen Schritte eines Incidents von der Meldung bis zum Abschluss darstellen.

Incident Request Registration
Der Incident und die nötigen Informationen für eine schnelle Behebung des Incidents werden aufgenommen. Es erfolgt eine Priorisierung durch Festlegung der Dringlichkeit und Störungsauswirkung.

Incident Request Assignment
Die verantwortliche Gruppe oder Person zur weiteren Bearbeitung wird zugordnet.

Incident Request Tracking
Um die Termingerechte Incident-Bearbeitung sicher zu stellen, wird der Incident kontinuierlich auf mögliche Terminüberschreitungen überwacht.

Incident Request Resolution by Specialist
Die Behebung der Ursache wird durch einen Specialist durchgeführt. Bei Bedarf kann der 3rd Level Support (Supplier) hierzu eingebunden werden.

Incident Escalaton Handling
Kann der Incident durch die Specialists nicht im nötigen Zeitrahmen gelöst werden, so kann er bei Bedarf an das Continuity Management z.B. zur Wiederherstellung in der Recovery Site oder das Change Management z.B. als Emergency Change anstossen.

Incident Request Closure
Nachdem der Incident behoben wurde, wird er nach Bestätigung des Users geschlossen.

Solution Approval
Soll die neue Lösung allen zugänglich gemacht werden, so kann über "Solution Approval" eine neue Lösung aktiviert werden.

Basics rund um Incident Management

Als frisch gebackener Solution Architekt für Incident Management verschaffe ich mir erst einmal die nötigsten Informationen.

Was ist Incident Management?

Eine ordentliche Google-Recherche lässt den Einsteiger einen guten Überblick bekommen. Es könnte sich also um einen Prozess aus ITIL handeln? Dann aber am besten gleich aus ITILv3, denn wir wollen ja up to date sein. Es könnten alle Maßnahmen sein, die zur Steuerung von "Incidents" eingesetzt werden. Nun dann ist erst einmal eine Definition von Incident nötig.

Incident (englisch): Fehler, Vorfall, Ereigniss, - am besten gefällt mir aber "Affäre" ;-)

Es geht also um mehr, als ausschließlich Fehler, das könnte noch mal wichtig sein...

Nun gibt es auch zum Begriff Management viele Definitionen. Im Wesentlichen verstehe ich darunter Organisation und Steuerung. Es soll also vermieden werden, dass die Incidents unkoordiniert bearbeitet oder eben auch gar nicht bearbeitet werden.

Incident Management definiert und steuert also die Vorgehensweise von der Entstehung bis zur abschließenden Erledigung eines Incidents über den gesamten Lebenszyklus.

Wenn wir wissen, was es ist, stellt sich mir noch die Frage, wozu es überhaubt benötigt wird.

Was führt zu einem Bedarf nach Incident Management?

Um diese Frage zu beantworten, sollten wir uns kurz ins Gedächtnis rufen, warum wir überhaupt IT-Services erbringen. Im Wesentlichen wollen wir das Unternehmen durch IT-Services dabei unterstützen, die Unternehmensziele zu erreichen. Wenn wir dieser Anforderung ordentlich nachkommen, ergibt sich hieraus folgender Rückschluss:

Wenn ein IT-Service nur eingeschränkt oder gar nicht funktioniert, dann ist auch die Erreichung der Unternehmensziele gefährdet.

Ziele von Incident Management:

Das wichtigeste Ziel vom Incident Management ist, die Funktion des IT-Services schnellst möglich wieder im vereinbarten Zustand herzustellen.

Nun ist es sicher möglich, die Effektivität und Effizienz von Incident Management durch Kennzahlen zu messen.

Kennzahlen zu Incident Management:

• Anzahl gemeldeter Incidents
• Durchschnittliche Antwortszeit nach Incident Meldung
• Dauer bis zur Behebung des Incidents
• Erstlösungsrate
• Bearbeitung innerhalb der SLAs
• Aufwand der Incidentbearbeitung
• Remote-Lösungsquote durch Fernzugriff
• Anzahl Eskalationen
• Anzahl doppelter Incidents

Besonders wichtig bei der Nutzung und Auswertung von Kennzahlen, ist die ausgewogene Auswahl von Kennzahlen zur Effektivität und Effizienz. Darüber hinaus sollten einzelne Kennzahlen immer im Kontext des Gesamtsystems betrachtet werden. Eine einzelne Kennzahl isoliert zu betrachten, und hieraus direkt Handlungen abzuleiten, wäre sicher zu kurz gesprungen.

Welche Anforderungen müssen für gutes Incident Management erfüllt sein?

• Die vereinbarte Funktion des Services muss bekannt sein.
• Die vertraglichen Vereinbarung im Bezug auf Qualitätsparameter bei der Störungsbehebung müssen bekannt sein.
• Die vom Incident betroffenen Services müssen identifiziert werden.
• Die Wichtigkeit dieser Services muss bekannt sein.

Funktionen vom Incident Management:

• Annahme einer Incident Meldung
• Dokumentation der Incident Meldung
• Spezifizierung der relevanten Informationen zum Incident und für dessen Bearbeitung
• Priorisierung des Incidents
• Behebung - ggf. auch durch Workaround - eines Incidents
• Information über den Bearbeitungsstatus und Erledigung des Incidents

Links:

http://wiki.de.it-processmaps.com/index.php/Incident_Management