Zusammenspiel Incident Management und Problem Management

In der Praxis stellt sich häufig die Frage, wie man das Zusammenspiel zwischen Incident Management und Problem Management erfolgreich gestaltet. Soll aus dem Incident Management heraus aktiv die Initiierung von Problem Investigations angestoßen werden? Oder lieber anders herum aus dem Problem Management heraus eine Analyse der Incidents erfolgen, aus welcher potentielle Problems einer Untersuchung unterzogen werden?

Problem Management nach dem Push- oder Pull-Prinzip

Je nach Komplexität und Größe Ihres Service Desk macht es in jedem Fall Sinn, nicht auf einen Schlag und ohne dedizierte Schulung alle First und Second Level Mitarbeiter nach eigenem Ermessen Problem Investigations zu generieren. In der Praxis erweist es sich eher als erfolgsversprechend, eine geringer Anzahl an Mitarbeitern im Problem Management zu qualifizieren und durch Auswertungen der Incidents die Generierung von Problem Investigations zu starten.

Fazit

Statt vieler Mitarbeiter ohne weiterführendes Wissen zum Problem Management lieber wenige Mitarbeiter gut qualifizieren und den Kreis zu Beginn schlank halten.

Problem Management in BMC ITSM Suite Service Desk

Hintergrund

Problem Management hat zum Ziel, IT-Probleme dauerhaft zu lösen. Es ist ein Prozess aus ITIL und steht bei der Erkennung von Problems in engem Zusammenhang zu Incident Management. Bei der Lösung der Problems wiederum gibt es eine enge Zusammenarbeit mit dem Change Management. Ein Eintrag eines Problems nennt sich Problem Record.

Ziele des Problem Managements

• Vermeidung potentieller Incidents
• Reduzierung der Auswirkung von Incidents
• dauerhafte Behebung der Ursache von wiederkehrenden Incidents

 

Der Problem Management Prozess

• Identifizierung von Problems
• Erfassung (schriftlich dokumentieren)
• Problem-Kategorisierung
• Problem-Priorisierung
• Problem-Diagnose und -Lösung
• Problem-Überwachung und -Steuerung
• Problem-Abschluss und -Auswertung
• Review von Major Problems
• Reporting
• Pflege der Known Error Database

Die Prozessphasen in der BMC ITSM Suite

• Identification and Classification
• Review
• Investigation and Diagnosis
• Resolution and Recovery
• Closed

Die Status eines Problem Records in der BMC ITSM Suite

• Draft
• Under Review
• Request for Authorization
• Assigned
• Under Investigation
• Pending
• Completed
• Rejected
• Closed
• Cancelled

Known Error Record

Ein Known Error Record bezeichnet im Rahmen von ITIL einen Datensatz, welcher ein Problem mit der Ursache sowie einem verifizierten Workaround beinhaltet.
Im Rahmen der BMC ITSM Suite wird der Known Error Record auch dazu genutzt, das Change Management anzusteuern. Statt aus einem Problem heraus direkt einen Change Request zu generieren, wird ein Known Error Record erstellt und in der Zuständigkeit dem Change Manager zugewiesen. Dieser kann die Lösung des Known Errors dann in seiner Change Planung einfließen lassen.

Incident Management

Incident Management ist die wohl häufigste ITIL Disziplin, die in der Praxis anzutreffen ist. Denn mit Incident Management bekommt man die täglichen kleinen "Brände", die in einer lebendigen IT-Umgebung nun einfach gelegentlich entstehen, in einem strukturierten Prozess gelöscht.

Viele Organisationen hatten vor der Einführung von Incident Management das Problem, dass die IT-Störungen auf Zuruf an den lokalen IT-Ansprechpartner gemeldet wurden. Die IT-Mitarbeiter konnten dann die Prioritäten der Störungen und Vorfälle nicht zentral beurteilen und Ihre Ressourcen nicht zielgerichtet einsetzen. Auch der Ablauf einer Störungsbeseitigung verläuft ohne Incident Management häufig unterschiedlich, je nachdem mit welchen IT-Mitarbeiter man gerade zusammentrifft.

 

Incident Management in der Praxis

Ein Incident wird an einer zentralen Stelle (Service Desk) gemeldet und registriert. Dann erfolgt eine Bewertung des Incidents nach Auswirkung und Dringlichkeit. Aus der gewichteten Kombination dieser Parameter wird die Priorität ermittelt. Dieser Schritt ist besonders wichtig, da User dazu neigen, alle IT-Störungen mit höchster Priorität zu melden. Das entspricht der jeweiligen subjektiven Sicht, ist aber für das Unternehmen als ganzes natürlich zu kurz gedacht. Denn wenn alle IT-Mitarbeitern mit unwichtigen Störungen beschäftigt sind und eine wirklich wichtige zentrale Störung daher nicht beheben können, hätte das Unternehmen dadurch einen unverhältnismäßig hohen Schaden.

Nach der Aufnahme und Bewertung wird der Incident Request an einen zuständigen Bearbeiter zugewiesen. Dieser ist nun für die Behebung der Störung und ggf. Einbindung weiterer Experten zuständig.

Im Incident Request werden Bearbeitungsnotizen hinzugefügt, damit alle Informationen an zentraler Stelle nachgelesen werden können.

Nach Abschluss des Incidents wird üblicherweise eine Nachricht an den Kunden versandt, welche die Incident Nummer und die Lösung des Incidents beinhaltet.

Strategie, ein kritischer Erfolgsfaktor von ITSM Projekten

Keine Schlacht wird gewonnen, indem man einfach drauf los rennt. Es gilt eine Strategie zu entwickeln, welche die geplante Aktion zum Erfolg führt.
Wie starten die meisten Unternehmen in ein ITSM Projekt? Entwickelt man tatsächlich eine Strategie oder legt man einfach los?
Natürlich planen die meisten Unternehmen, bevor Sie eine neue ITSM Lösung implementieren. Doch handelt es sich dabei tatsächlich um strategische Überlegungen? Oder geht es viel mehr um die durch operative Notwendigkeit zu treffenden Entscheidungen?

Die fünf wichtigsten Fragen zum Strategieabgleich Ihres ITSM Projektes:

• Welche Ziele der Unternehmensstrategie werden durch das ITSM Projekt unterstützt?
• Wie werden die Entwicklungsziele der IT-Strategie durch das ITSM Projekt umgesetzt?
• Steht das TOP-Management hinter der ITSM Initiative?
• Wird die Personalpolitik durch die ITSM Initiative getragen?
• Werden die strategischen Ziele der Finanz- und Ressourcenpolitik durch die ITSM Initiative unterstützt?

Sicher ist diese Liste nicht abschließend. Doch eines ist klar: Wer es schafft, das ITSM Projekt möglichst synchron zu den Unternehmenszielen aufzusetzen, wird es in der erfolgreichen Umsetzung wesentlich leichter haben.

Beziehungen des Incident Managements zu anderen ITIL-Prozessen

Incident Management ist als Teilprozess in Service Operation besonders stark mit seinen Nachbarprozessen dieser Phase verbunden. In diesem Blogbeitrag möchte ich die unterschiedlichen Beziehungen und Interaktionen beschreiben.

Auslösung von Incidents:
Der klassische Weg einer Incident-Meldung ist der Anruf eines aufgebrachten Users beim Service Desk. Dies ist, ganz im Sinne der Effizienzsteigerungen, natürlich auch per Webinterface online durch den User durchfürbar.
Nun können Incidents aber auch durch ein gut funktionierendes Event Management (hier ist nicht die Organisation von Partys und Konzerten gemeint ;-) automatisiert angelegt werden.

Change Management
Ist die Ursache des Incidents durch einen Minor Change lösbar, so wird dieser unmittelbar aus dem Incident Management heraus angestossen. Anders herum könnte die Ursache des Incidents auch in einem vorher durchgeführten Change begründet sein. Dann wird im Incident Record eine Beziehung zum Change dokumentiert.

Problem Management
Kann die eigentliche Ursache eines Incident nicht unmittelbar gelöst werden, so wird es an das Problem Management übergeben.

Diese Prozesse sollten daher nicht isoliert betrachtet und eingeführt werden. Eine reibungslose Interaktion zwischen den Prozessen ist wichtig für den erfolgreichen IT-Betrieb.

CMDB - Grundsätze zu Daten

Welche Grundsätze sind bei der Planung einer CMDB zu berücksichtigen?

So wenig Daten wie möglich, nur so viele Daten wie nötig

Dieser Grundsatz soll verdeutlichen, dass die Datenmenge in der CMDB in einem beherschbaren Umfang gehalten werden sollte.

Nur Daten, die den Prozess unterstützen

Es gibt viele unterschiedliche Stellen, an denen man in einer komplexen IT Umgebung technische Detaildaten auslesen kann. In der CMDB sollten nicht alle Daten abgelegt werden, nur weil sie es könnten. Beschränken Sie sich insbesondere zu Beginn nur auf die Daten, die für die Service Prozesse wirklich relevant sind.

Vollständigkeit gewährleisten

Damit ist nicht gemeint, dass Sie möglichst alles in die CMDB übertragen sollten. Aber wenn Sie sich für einen bestimmten Informationstypen entschieden haben, ihn in der CMDB zu pflegen, dann sollten diese Daten auch unbedingt vollständig sein.

Aktualität sicherstellen

Übernehmen Sie nur Daten in die CMDB, von denen Sie auch Monate oder Jahre nach der initialen Datenbefüllung die Aktualität sicherstellen können.

Managed Service Transition Phase

Managed Service Transition Phase

Die Managed Service Transition Phase wird bei der Planung von Managed Services häufig vergessen.

Der Anbieter eines Managed Services möchte einen IT-Service im Auftrage des Kunden betrieben. Also beschreibt er die Leistungen seines Services.
Doch nur zu häufig wird eine Frage vergessen: Wie komme ich denn eigentlich vom jetztigen Betriebsmodell bis zum geplanten Betrieb im Managed Service?
Also wie genau wird die Veränderung vom Status Qou hin zur geplanten Zielsituation ablaufen?
Genau hier liegt viel Potential, derarige Vorhaben erflogreicher zu machen. Bereits in der Planung und Angebotserstellung sollten folgende Punkte berücksichtigt werden:
- Kenntnisse über das bestehende System erlangen
- Kenntnisse über die bestehenden Prozesse erlangen, welche das System nutzen
- Migrationen zum Zielsystem planen
- Knowledge Transfer einplanen
- Faktor Mensch einplanen (Informationen, Schulungen, usw)
- Mögliche Rückfall-Optionen einplanen
- Zeitplanung für die Übergangsphase erstellen
- Klarheit über Verantwortlichkeiten und Ansprechpartner während der Übergangsphase sicherstellen

Werden diese Schlüsselaspekte bei der Managed Service Transition Phase berücksichtig, steigen die Erfolgs-Chancen bei der Implementierung des Managed Services deutlich!

Sie haben Gedanken, Anregungen oder Fragen zum Thema Managed Service Transition Phase? Dann hinterlassen Sie einfach eine Anmerkung hier im Blog.

Service Asset and Configuration Management (SACM) als Managed Service

Service Asset and Configuration Management (SACM) als Managed Service

Service Asset and Configuration Management (SACM) ist eine Kernkomponente der IT-Service Management Prozesse. Denn nur mit einem gut effizienten SACM können die benachbarten ITIL Prozesse ihre volle Effektivität entfalten. Etwas konkreter: Sind die Daten in der CMDB aktuell, so kann man in einem Incident auf betroffene Assets und den Benutzer verweisen. Die Problemsuche und Störungsbehebung wird aufgrund der Daten wesentlich schneller ablaufen. Und wiederholte Probleme am gleichen Asset können einfacher identifiziert werden.

Doch eine wirklich gut nutzbare CMDB mit aktuellen und konsistenten Daten ist keine Selbstverständlichkeit. Vielen große Unternehmen haben hier einen der größten Schmerzpunkte im Service Management. Das ist nicht verwunderlich, wenn man bedenkt, dass diese "Schaltzentrale" mit einer Unmenge an Daten aus unterschiedlichen Quellen gut geplant und gut gepflegt werden muss. Es bedarf Erfahrung, die Struktur, Prozesse und Schnittstellen so zu planen, das am Ende auch wirklich brauchbare Daten verfügbar sind.

Muss ein Unternehmen nun alle ITIL Prozesse und insbesondere das Service Asset and Configuration Management selbst planen? Muss es das SACM selbst implementieren? Und muss das SACM intern betrieben werden? Klar ist, es handelt sich um eine Kernkomponente des Service Managements. Es ist also von strategischer Bedeutung, dass Service Asset and Configuration Management erfolgreich betrieben wird.
Die eine Wahrheit gibt es hier wohl nicht. Doch klar ist, wenn das bisherige SACM nicht funktioniert, muss etwas unternommen werden. Und wenn die bisherigen internen Maßnahmen nicht fruchtbar waren, so sollte man eine andere Variante in Betracht ziehen.

Das Service Asset and Configuration Management könnte auch als Managed Service von einem spezialisierten Provider bezogen werden. Sicher kann es nicht losgelöst als einfacher Commodity Service betrachtet werden. Doch ein Dienstleister mit guten Kenntnissen über die IT Service Management Implementierung der betroffenen Organisation könnte hier der richtige Ansprechpartner sein.

Wenn nun noch einige wichtige Faktoren zusammen kommen, so ist dieses Modell durchaus erfolgsversprechend:
- Prozess-Know-How / hohe ITIL Kompetenz
- sehr gute Erfahrung mit den eingesetzten Service Management Tools
- gute Kenntnisse über die betroffene IT-Organisation (insb. der bislang implementierten ITSM Prozesse)
- Kooperativer Ansatz
- klare Zuordnung der Verantwortlichkeiten

Sie haben Anmerkungen oder Fragen? Dann schreiben Sie einfach einen Kommentar!

BMC Financial Planning and Budgeting

Financial Planning and Budgeting

Das Modul Financial Planning and Budgeting unterstützt den Planungsprozess rund um Budgets für die IT-Abteilung. Es ermöglicht unterschiedliche Planungsszenarien mit unterschiedlichen Laufzeiten. Budgets können hierachisch geplant und erfasst werden. Hierdurch kann eine wesentlich höhere Transparenz und Granularität im Planungsprozess erreicht werden.

Budgetplanungen beziehen sich auf

• Laufende Ausgaben
• Anlagen
• Abschreibungen

Bei der Budgetplanung können verschiedene Budget-Elemente wie z.B. Assets, Personal, Projekte, externe Kosten berücksichtigt werden. Eine Zuordnung von Budget-Elementen auf verschiedene Budget-Bereiche ist möglich. Viele der hierfür benötigten Daten sind bereits im BMC System verfügbar und werden hierfür verwendet.
Eine Zuordnung von Budgets zu Planungselementen wie Kostenstellen ist natürlich möglich.

Financial Planning and Budgeting ermöglicht darüber hinaus auch eine laufende Kostenüberwachung sowie den Vergleich zur Budgetplanung.

BMC Service Costing

Service Costing

Im Modul Service Costing dreht sich alles um Kosten und Preise für IT-Services. Zielsetzung ist eine transparente Kosten- und Preisplanung, laufende Überwachung und Ermöglichung von transparenter Rechnungsstellung.

Zusätzliche Analysemöglichkeiten ver
Plan-Kosten und tatsächliche IST-Kosten können übersichtlich dargestellt und ins Verhältnis gesetzt werden.
Welche Services werden wie stark nachgefragt?
Wie haben sich die Kosten und Umsätze im Verlauf der Monate entwickelt?
Service Consting wird nicht nur für Kostentransparenz genutzt sondern ermöglicht auch eine fundierte Preisgestaltung von IT-Services.

Abbildung von Kosten-Modellen:

• Buttom-up: Aus detaillierten im System vorhandenen Einzeldaten wird das Modell zusammengesetzt
• Top-down: Es werden übergeordnete Annahmen getroffen und auf einzelne Positionen runtergebrochen

Als Kostenpositionen können Assets, Supporting Services, Projekte, Lieferantenkosten usw. einbezogen werden.

Die Verrechnungseinheiten können flexibel festgelegt werden. Storage wird z.B. nach Gigabyte verrechnet, aber der E-Mail-Service wird nach der Anzahl der Postfächer verrechnet.

Im Kostenmodell können insbesondere zwei Dimensionen genutzt werden. Es wird unterschieden zwischen Zuordnung und Konsum. Durch die Zuordnung wird festgelegt, in wie weit Kosten grundsätzlich verrechnet werden. Z.B. ob Overhead-Abteilungen einbezogen werden oder nicht. Über den Konsum werden die tatsächlichen Kostenverteilungen auf die unterschiedlichen Konsumenten aufgeteilt.

Mittels Benchmarks können die geplanten und die tatsächlichen Kostem mit Brachenstandards verglichen werden. Dies unterstützt Entscheidungsprozesse für Optimierungsmaßnahmen.
Zusammensetzung der Kostenpositionen kann grafisch übersichtlich dargestellt werden.
Bill of IT (Verrechnungsgrundlage)

Mittels Kostenszenarien können z.B. on-premise Varianten vs. Cloud Lösungen von IT-Services abgewogen werden.

Die Verrechnung wird allerdings nur ermöglicht und nicht tatsächlich durchgeführt. Es werden weiterhin die im Unternehmen genutzten Verrechnungssysteme genutzt.

BMC Supplier Management

BMC Supplier Management

Das Modul Supplier Management deckt den Lifecycle für Lieferanten und Partner ab. Es ermöglicht die strukturierte Aufnahme und Dokumentation neuer Supplier.
Sind die Supplier aufgenommen, so lässt sich die laufende Steuerung über das Supplier Management durchführen. Es können regelmäßige Analysen und Reviews durchgeführt werden.
Das Partner- und Lieferantenportfolio kann über Auswertungen analysiert und optimiert werden. Welche Partner sind strategisch relevant, wie viel Budget war über diese Partner geplant und wie haben sich die Kosten tatsächlich entwickelt? Läuft die operative Zusammenarbeit gut? All diese Informationen lassen sich übersichtlich darstellen.

Welche Initiativen zu dem Supplier stehen in der nächsten Zeit an und wer ist dafür verantwortlich? Die Initativen können übersichtlich verwaltet und Personen zugeordnet werden.

Es können RfPs angefordert werden und der Vertragsprozess von der Initiierung bis zum Abschluss abgebildet werden.

Ähnliche Produkte sind unter dem Namen Vendor Relationship Management bekannt.

BMC Demand and Resource Management (2/2)

Resource Management

Der zweite Teil vom BMC Demand and Resource Management ist das Resource Management. Hierbei handelt es sich tatsächlich um ein Modul, mit dem sich Ressourcen planen und controllen lassen. Der Fokus liegt auf der Planung von Personalverfügbarkeit, der Zuordnung der Ressourcen zu Projekten und weiteren Tätigkeiten und dem typischen jonglieren mit Anforderungen, tatsächlichen Aufwänden und real verfügbaren Ressourcen.

Es können Auslastungsanalysen für einzelne Mitarbeiter aber auch für Funktionsgruppen durchgeführt werden. Zusätzlich kann im Bereich "Resource Outlook" die Auslastung auf Basis der Planung für die Zukunft darststellt werden. Hierbei wird recht schnell sichtbar, wann z.B. durch eine Lastspitze ein Ressourcenengpass entstehen wird.

Im Bereich "Resouce Assignments" können angeforderte Ressourcen den einzelnen Tasks vom Ressourcenmanager zugeteilt und freigegeben werden.

Ein integriertes Zeiterfassungssystem bietet typische Basisfunktionen zur Erfassung von Zeiten gegen Projekte, Services, sonstige Zeiten usw.

Natürlich werden auch die Assets im Resource Management verfügbar gemacht. Hier ist es möglich, die entsprechenden Kosten direkt dem Asset zugeordnet zu erfassen.

Ein genereller Aspekt aus dem BMC Resource & Demand Management ist die Möglichkeit, direkt aus dem Projekt zu den entsprechenden Tasks auch Releases und Changes in der ITSM Suite zu erzeugen. Hier schließt sich für mich ein bislang unbeantworteter Kreis: Wie integriert sich Projektmanagement z.B. nach PRINCE 2 und Service Management nach ITIL v3 2011? Jetzt habe ich auf Basis der Software eine konkrete Schnittmenge gefunden.

BMC Demand and Resource Management (1/2)

BMC Demand and Resource Management

Das Modul Demand and Resource Management besteht im Wesentlichen aus zwei großen Bereichen. Im folgenden möchte ich den Bereich Demand Management näher beschreiben. Der zweite Bereich, das Resource Management, wird im zweiten Post dieser Reihe erscheinen.

Demand Management

Hinter Demand Management verbirgt sich ganz konkret Projekt- und Portfolio-Management. Es kann also aus der Business Sicht der Bedarf an IT-relevanten Projekten erfasst und hier zentral priorisiert und gesteuert werden. Der Fokus liegt hierbei eher auf einer übergeordneten Management-Sicht, denn auf der operativen Detail-Arbeit von Projekten. Es unterstützt Einzelprojektmanagement, Projektportfoliomanagement und Programmanagement.

Das Modul Demand ans Resource Management integriert sich in BMC Service Request Management und ermöglicht somit die Erfassung von Projektanträgen durch die Enduser direkt im Self-Service Portal. Diese Projektanfrage kommt im Demand and Resource Management konkret als Business Case Review Anfrage an und ist dem Lifecycle eines Business Case Reviews zugeordnet. Erst wenn der Business Case vollständig erfasst und abschließend reviewed wurde, erfolgt ein Approval und damit die Anlage eines tatsächlichem Projektes im System, welches dem Projekt Lifecycle unterworfen ist.

Um in größeren Umgebungen auch unterschiedliche Methodiken zu ermöglichen, kann in dieser Phase ggf. aus einer Reihe von unterschiedlichen Standards der passende Lifecycle-Prozess als Template ausgewählt werden.

Kleines Manko: Im Projektmanagement können zwar Tasks verwaltet und Ressourcen zugewiesen werden, die Abbildung von Abhängigkeiten der verschiedenen Tasks untereinander ist bislang nicht abgebildet. Für die operative Projektarbeit können Kernfunktionen von z.B. MS-Projekt nicht abgelöst werden und sind somit weiterhin parallel nötig.

BMC ITBM - Financial Planning and Budgeting (5/5)

BMC Financial Planning and Budgeting

• IT-Budgetierung (Bottom-up, hierachische IT-Budget-Planung)
• Kostenmanagement (Überwachen, Trends & Drill-down)
• Kapital und Ausgabenplanung (Ermittlung, Priorisierung und Zuteilung von Kapitalbedarfen)

Vorteile vom Financial Planning and Budgeting

• Verkürzt den Planungsprozess von Monaten auf Wochen
• Bessere Analysemöglichkeiten
• Ermöglicht Baselining und Implementierung von Kostenreduktionsprogrammen
• Erhöht die Budgetverantwortung durch Klarheit und Transparenz

BMC ITBM - Supplier Management (4/5)

Supplier Management

(auch bekannt unter Vendor Relation Ship Management)

• Lieferanten Portfolio (Konsolidierung und Harmonisierung des Lieferanten-Portfolios mittels Kosten-, Performance- und Risikobetrachtung)
• Lieferanten Governance (Steuerung des Supplier Lifecycle Prozesses)
• Performance Management (Überwachen von Zusagen und Lieferungen inkl. 360° Qualitätsmessung)
• Lieferanten Risiko Management (Ermittlung und Steuerung von Lieferantenrisiken)
• Vertrags- und Kostenmanagement (Verträge und Angebote vs laufende Kosten überwachen)

Vorteile von Supplier Management

• Erhöhen der Lieferantenperformance
• Konsolidierung des Lieferanten-Portfolios
• Fokusierung auf die wichtigsten Lieferanten
• Reduzierung der Lieferanten-Ausgaben

BMC ITBM - Demand and Resource Management (3/5)

Demand & Resource Management liefert

• Bedarf ermitteln und steuern
• Kapazitätsmanagement (z.B. Labor-Ressourcen)
• Organisationsplanung (Skills, Kosten und Effizenz der Ressourcen)
• Ressourcenallokation (Allokieren und Analysieren von Ressourcen-Zuordnungen)
• Umsetzungssteuerung (Planen und Steuern der Umsetzung von Aktivitäten im Portfolio)

Vorteile von Demand & Resource Management

• Stellt sicher, dass Mitarbeiter dem wichtigesten und wertschöpfensten Tätigkeiten zugeordnet werden
• Vermeidet ungeplante Überbuchung von Ressourcen
• Reduziert Projektverzögerungen wegen Ressourcen-Konflikten
• Unterstützt eine optimale Personaldecke um die Unternehmensanforderungen zu erreichen

BMC ITBM Service Cost Management (2/5)

Mittels BMC Service Cost Management werden IT-Organisationen finanziell transparent - für das Business

Zum Versteckspiel denkbar ungeeignet - doch um gut geführte IT-Organisationen in ihrer Wirtschaftlichkeit auch nach aussen gezielt transparent zu machen, eignet sich BMC Service Cost Management. Denn welcher CIO kennt die Budget-Diskussion nicht? Plötzlich soll ich mit 20% weniger Budget auskommen? Wie lassen sich die Auswirkungen belastbar darstellen und die kann der CIO die Unternehmensleitung davon überzeugen, dass das Budget gerade in der IT gut eingesetzt ist und einen deutlichen Wertbeitrag für das Business liefert?

BMC Service Cost Management ermöglicht

• Service Portfolio definieren
• Kostenmodelle und Analysen
• Verbrauchsermittlung
• Verrechnung von IT / Chargeback (enables / führt es nicht selbst aus)
• Benchmarking / Vergleiche

Vorteile vom BMC Service Cost Management

• Verbessert die IT-Transparenz für das Business
• Ermöglicht genauere und wertbeitragsorientierte Analysen
• Ziehen von Baselines & Einführen von messbaren Kostenreduktions-Programmen
• Verbessert Budget-Verantwortlichkeit und Zurechenbarkeit
• Ermöglicht fundierte Informationsbasis für Transformations-Entscheidungen

BMC IT Business Management 8.0 - ITBM 8.0 (Teil 1/5)

BMC IT Business Management (ITBM) ist in Deutschland noch recht unbekannt. Daher möchte ich in dieser Blog-Reihe einen kurzen Überblick über ITBM und die enthaltenen Module geben.

ITBM deckt insbesondere die Anforderungen zur "Govern & Control" ab. Es unterstützt große Unternehmen und Organisationen also bei der Planung und laufenden Überprüfung von IT-Services und dazugehörigen Management Aufgaben.

Welche Module beinhaltet ITBM?

• BMC Service Cost Management
• BMC Demand and Resource Management
• BMC Supplier Management
• BMC Financial Planning and Budgeting

Welche Vorteile ergeben sich aus BMC ITBM?

ITIL hat sich in den vergangenen Jahren stark in Richtung Business Alignment entwickelt. Es betont die Notwendigkeit, dass IT-Organisationen nicht zum Selbstzweck existieren, sondern stets zur Unternehmenswertschöpfung beitragen muss. Der Fokus wandert also von einem ursprünglich eher betriebsorientierten Framework hin zu einem ganzheitlichen Rahmen, der Unternehmensziele und Strategien als wesentliche Rahmenparameter berücksichtigt und sich daran orientiert.

Um nun die Unternehmensstrategie unterstützen und das "Business Alignment" herstellen zu können, muss eine Transparenz über alle IT-Leistungen, deren Kosten und deren Wertbeitrag für das Unternehmen geschaffen werden. Zusätzlich muss der Strategie- und Planungsprozess stärker integriert werden.
Genau hier setzt BMC ITBM an.
Über Service Cost Management werden Kosten und Nutzen der Services analysiert und dargestellt.
Mit Hilfe von Demand and Resource Management wird der Scope der eher betriebsorientierten ITSM Suite um die Integration von Projektportfoliomanagement und Ressourcenplanung und -controlling erweitert.
Mittels BMC Supplier Management werden wird das Lieferantenmanagement transparent und integriert.
Der stärkste Schritt in Richtung Planungs- und Strategieunterstützung wird durch BMC Financial Planning and Budgeting erreicht. Hier kann der unternehmensweite Planungs- und Budgetierungsprozess speziell für die IT Business Services integriert und abgebildet werden.