PC 2011 / ST

Ergebnis und die Bewertung hinsichtlich der Zielerreichung überprüft.

Daten sind NICHT interpretiert (Grund-Daten). Informationen sind interpretiert.

Rechtzeitig die richtige & korrekte Information an die zuständige Personen zur Verfügung zu stellen.

Damit richtige Entscheidung getroffen werden können.

Auf das Configutation Mangement System (CMS) und das dazugehörige CMDB.

Das Service Knowledge Management System (SKMS) ist das zentrale Repository von Daten, Informationen und Wissen, das die IT-Organisation benötigt.

DIKW-Strukturdiagramm:  Knowledge  Management  wird typischerweise  mithilfe  des  DIKW-Strukturdiagramms  dargestellt.

-          Data (Set  von  Fakten  bezüglich  Ereignissen)

-          Information (Strukturieren Daten, wie Docu, E-Mails, Mutimedia)

-          Knowledge (Knowledge ist die Zusammenführung von Erfahrungen, Ideen & Werten=)

-          Wisdom (Wahrnehmung und Urteilskraft)

·         Fit for use

·         Fit for purpose

Sicherstellen, dass ausgerollte Releases und die daraus resultierenden Services qualitätsgeprüft werden sowie Bewerten, ob der IT-Betrieb in der Lage ist, den neuen Service angemessen zu unterstützen.

·         Durchführen des Tests

·         Dokumentation der Ergebnisse und finaler Testreport

·         Evaluierung der Ausgangskriterien und  Bericht

·         Testbereinigung und Abschluss

Steigerung der Servicequalität durch gezielte Test- und Validierungsmassnahmen

BEWERTEN…….vor dem Change

Das BEWERTEN von umfangreichen Changes, wie z.B. die Einführung eines neuen Service oder Änderungen an einem bestehenden Service, bevor diese Changes die Freigabe für die nächste Phase in ihrem Lebenszyklus erhalten.

PDCA-Modell:  Plan-Do-Check-Act  (PDCA)-Modells

·         Change-Evaluierung vor Planungs-Start

·         Change-Evaluierung vor Build-Start

·         Change-Evaluierung vor Deployment-Start

·         Change-Evaluierung nach Deployment

Der Evaluation Report ist das zentrale  Dokument  im  Rahmen  des  Prozesses  Evaluation im Prozess Change Evaluation

1.       Service Lifecycle CIs (S.M.-Pläne, Serice Desigin Packages, Testpläne)

2.       Service CIs (Organisation, Prozesse, Wisswen und MA)

3.       Ressource Assets (Daten, Infrastruktur, allgemeine Einrichtungen)

4.       Organization CIs

5.       Internal CIs

6.       External CIs

7.       Interface CIs (Schnittstellen CI)

1.       Service review citrieria

2.       Service acceptance citrieria

3.       Service operational citrieria/plan

4.       Service release test citrieria and plan

Service componet build and test

(Service Strategy) Die Service Valuation ist ein Mass der Gesamtkosten, welche bis zur Auslieferung eines IT-Services anfallen und damit auch der gesamte wahrnehmbare Wert des IT-Services für das Business. Die Service Valuation hilft sowohl Business als auch der IT, sich über den Wert eines IT-Services einig zu werden

Service Qualty Policy

- Risk Policy

- Service Tranision Policy

- Release Policy

- Change Mangemant Policy

Ein Snapshot, der als Referenzpunkt verwendet wird. Für später Vergleichsmöglichkeit.

Der Roll-Back

Definitive Media Library

Early Life Support

Know Error Data Base

Service Knowledge Management System

-          Erhöhen der Anzahl Release

-          Reduzieren der Planungskonflikte

-          Team zufriedener

1         Transition Strategie

2         Vorbereitung für die Service Transition

3         Planung und Koordination der  Service Transition

4         Bereitstellung der Transition Prozessunterstützung

Service Design --- > TRANSITION PLANUNG  < ---- Operative Anforderungen

Planung und Koordination der Ressourcen die nötig sind um einen neuen oder geänderten Service in die Produktion zu ermöglichen. Team Unterstützung.

Risiken und Nutzen für den Change.

1.       Strategische Change

2.       Taktische Change

3.       Betriebliche Change

Change registrieren , autorisiert, proristieirt, geplant .., geprüft in geordnete Form.

Angemessen auf sich änderene Anforderungen der Kunden zu reagieren, sowie Störungen und Service Unterbrüch zu vermeinden.

Change Advisory Board

Trifft Entscheidung für den Change.

-          Standard Changes

-          Emergency Changes

-          Normal Changes

Alternative Lösung muss vorhanden sein.

Was getant werden muss, wenn Change nicht erfolgreich war.

(Falls möglich Restore, sonst alternaitve Lösung)

1.       RAISE (Einbringen)?: Wer hat den Change eingebracht?

2.       REASON (Grund)?: Was ist der Grund für den Change?

3.       RETURN (Ertrag)?: Welchen Ertrag soll der Change bringen?

4.       RISK (Risiko)?: Welche Risiken birgt der Change?

5.       RESOURCES  (Ressourcen)?:  Welche  Ressourcen  sind  für die Durchführung des Change erforderlich?

6.       RESPONSIBLE  (Verantvortlich)?:  Wer  ist  für  Build,  Testen & Impl. des Change verantwortlich?

7.       RELATIONSHIP  (Beziehung)?:  Welche  Beziehung  besteht zwischen diesem Change und anderen Changes?

Eine SACM Police ist Voraussetzung.

Configuration Mangement System

CMS ist eine übergreifende Systemdimension (ein logisches Datenmodell), die  die  physikalische  CMDB  und  DML  beinhaltet  und  eine weiterführende  Sicht  auf  die  Daten  liefert,  die  alle  anderen ITSM-Prozesse benötigen.