08S04 Praxis – ITSM-Software konzernweit upgraden
|
Sie stehen vor der großen Herausforderung, die konzernweite ITSM-Software upgraden zu müssen. Dieser Beitrag beschreibt auf der Basis eines Kundenprojekts die wesentlichen Bestandteile zum standardisierten, einheitlichen und kosteneffizienten Upgrade der ITSM-Software. Das Projekt wird auf der Basis des Referenzmodells „Intelligence IT Service Management Software Upgrade Guide (SMUG)” (s. Kap. 08S03) durchgeführt. Ziel des Upgrade-Projekts ist die Abbildung der konzernweiten ITSM-Prozesse in der neuen ITSM-Software bei Nutzung von Standardfunktionalitäten der ITSM-Software. Somit wird sichergestellt, dass zukünftige Upgrades ohne weiteren hohen Personal- und Kostenaufwand durchgeführt werden können. von: |
1 Zielsetzung
Um die konzernweiten IT-Service-Management-Prozesse (ITSM-Prozesse) zur Unterstützung der Geschäftsprozesse abzubilden, setzen internationale Konzerne eine unternehmensweite IT-Service-Management-Software (ITSM-Software) ein. Sie stehen aus unterschiedlichen Gründen vor der großen Herausforderung, die konzernweite ITSM-Software regelmäßig upgraden zu müssen. Hauptsächliches Ziel ist es dabei, das Upgrade standardisiert, einheitlich und kosteneffizient durchzuführen und die konzernweiten ITSM-Prozesse in der neuen ITSM-Software bei Nutzung von Standardfunktionalitäten der ITSM-Software abzubilden. Das soll dadurch erreicht werden, dass die konzernweiten ITSM-Prozesse in der neuen ITSM-Software durch Standardfunktionen abgebildet werden. In der Folge können zukünftige Upgrades ohne weiteren hohen Personal- und Kostenaufwand durchführt werden.
Referenzmodell SMUG
Dazu ist eine standardisierte praxiserprobte Methodik, d. h. ein Referenzmodell, notwendig. Der Beitrag „Guideline – ITSM-Software konzernweit upgraden" (s. Kap. 08S03) beschreibt das vom Autor entwickelte und diesem Beitrag zugrunde liegende Referenzmodell „Intelligence IT Service Management Software Upgrade Guide (SMUG)” als standardisiertes, einheitliches und kosteneffizientes Referenzmodell zum Upgrade einer konzernweit implementierten ITSM-Software [1]. Das Referenzmodell SMUG wurde vom Autor im Jahre 2008 entwickelt. Auf der Basis dieses Referenzmodells wurden seitdem bei internationalen Konzernen mehrere Projekte erfolgreich durchgeführt.
Dazu ist eine standardisierte praxiserprobte Methodik, d. h. ein Referenzmodell, notwendig. Der Beitrag „Guideline – ITSM-Software konzernweit upgraden" (s. Kap. 08S03) beschreibt das vom Autor entwickelte und diesem Beitrag zugrunde liegende Referenzmodell „Intelligence IT Service Management Software Upgrade Guide (SMUG)” als standardisiertes, einheitliches und kosteneffizientes Referenzmodell zum Upgrade einer konzernweit implementierten ITSM-Software [1]. Das Referenzmodell SMUG wurde vom Autor im Jahre 2008 entwickelt. Auf der Basis dieses Referenzmodells wurden seitdem bei internationalen Konzernen mehrere Projekte erfolgreich durchgeführt.
2 Kundensituation
In diesem Abschnitt wird die dem Projekt zugrunde liegende Kundensituation kurz erläutert.
Weltweit agierender Konzern
Der Kunde ist eine weltweit agierende Unternehmensgruppe (Konzern) mit eingegliederten Tochterunternehmen, die wirtschaftlich und finanziell gegenüber dem Mutterunternehmen unselbstständig, rechtlich aber selbstständig sind. Die IT-Organisation liefert weltweite IT-Leistungen innerhalb der Wirtschaftsräume (Regionen) Europa-Arabien-Afrika (EMEA), Asien-Pazifik (APAC) und Nord- und Südamerika (AMER). Die Lieferung der IT-Leistungen wird durch ITSM-Prozesse unterstützt, die wiederum in EMEA, APAC und AMER durch die IT-Organisation geliefert werden.
Der Kunde ist eine weltweit agierende Unternehmensgruppe (Konzern) mit eingegliederten Tochterunternehmen, die wirtschaftlich und finanziell gegenüber dem Mutterunternehmen unselbstständig, rechtlich aber selbstständig sind. Die IT-Organisation liefert weltweite IT-Leistungen innerhalb der Wirtschaftsräume (Regionen) Europa-Arabien-Afrika (EMEA), Asien-Pazifik (APAC) und Nord- und Südamerika (AMER). Die Lieferung der IT-Leistungen wird durch ITSM-Prozesse unterstützt, die wiederum in EMEA, APAC und AMER durch die IT-Organisation geliefert werden.
Abgebildete ITSM-Prozesse
Der Kunde setzt weltweit eine ITSM-Software ein. Innerhalb dieser Software sind folgende IT-Service-Management-Prozesse (ITIL-V3-Prozesse) abgebildet:
Der Kunde setzt weltweit eine ITSM-Software ein. Innerhalb dieser Software sind folgende IT-Service-Management-Prozesse (ITIL-V3-Prozesse) abgebildet:
| • | Service Design
| ||||||
| • | Service Transition
| ||||||
| • | Application Development Service Operation
|
24 × 7 Service Desk
Des Weiteren ist ein weltweiter Service Desk mit einer Erreichbarkeit von 24 × 7 implementiert, der gemäß dem Follow-the-Sun-Prinzip interagiert. Dieses bedeutet, in jeder Region ist ein Service Desk mit lokalen Betriebszeiten implementiert. Gemäß dem Lauf der Sonne wird der Service Desk in EMEA, APAC und AMER als nächster Service Desk zentral für die konzernweiten Leistungsempfänger aktiv.
Des Weiteren ist ein weltweiter Service Desk mit einer Erreichbarkeit von 24 × 7 implementiert, der gemäß dem Follow-the-Sun-Prinzip interagiert. Dieses bedeutet, in jeder Region ist ein Service Desk mit lokalen Betriebszeiten implementiert. Gemäß dem Lauf der Sonne wird der Service Desk in EMEA, APAC und AMER als nächster Service Desk zentral für die konzernweiten Leistungsempfänger aktiv.
Prozesse im Unternehmen
Das Ziel der konzernweiten eingesetzten ITSM-Software ist die Abbildung der ITSM-Prozesse zur Unterstützung der individuellen Business-Unit-Geschäftsprozesse und der übergreifenden Konzern-Geschäftsprozesse.
Das Ziel der konzernweiten eingesetzten ITSM-Software ist die Abbildung der ITSM-Prozesse zur Unterstützung der individuellen Business-Unit-Geschäftsprozesse und der übergreifenden Konzern-Geschäftsprozesse.
Die an die konzernweiten Anforderungen angepassten ITSM-Prozesse (Konzern-ITSM-Prozesse) unterstützen die konzernweit gültigen Geschäftsprozesse. Die an die Business-Unit-Anforderungen angepassten ITSM-Prozesse (Business-Unit-ITSM-Prozesse) unterstützen die Business-Unit-spezifischen Geschäftsvorfälle. Dieses schließt ein, dass unterschiedliche Ausprägungen von ITSM-Prozessen innerhalb der ITSM-Software existieren.
Entscheidungsvorlage
Die ITSM-Organisation (als Bestandteil der IT-Organisation) ist durch die technische Geschäftsführung aufgefordert worden, ein Upgrade der ITSM-Software durchführen. Innerhalb der dafür notwendigen Entscheidungsvorlage sind die Projektmethodik, notwendige Mittel (Hardware- und Softwarelizenzen, Ressourcen, Meilensteine, Vorteile für die Business Units und Vorteile für die IT-Organisation, Projektziele usw.) enthalten. Das Projekt wurde gemäß der Entscheidungsvorlage von den zukünftigen Mitgliedern des Projektlenkungsausschusses, dem Aufsichtsgremium des Projekts, freigegeben. Die Entscheidungsvorlage wurde in den Project Charter überführt.
Die ITSM-Organisation (als Bestandteil der IT-Organisation) ist durch die technische Geschäftsführung aufgefordert worden, ein Upgrade der ITSM-Software durchführen. Innerhalb der dafür notwendigen Entscheidungsvorlage sind die Projektmethodik, notwendige Mittel (Hardware- und Softwarelizenzen, Ressourcen, Meilensteine, Vorteile für die Business Units und Vorteile für die IT-Organisation, Projektziele usw.) enthalten. Das Projekt wurde gemäß der Entscheidungsvorlage von den zukünftigen Mitgliedern des Projektlenkungsausschusses, dem Aufsichtsgremium des Projekts, freigegeben. Die Entscheidungsvorlage wurde in den Project Charter überführt.
Gründe für das Upgrade
Folgende fachlichen Gründe wurden des Weiteren innerhalb der Entscheidungsvorlage zum Upgrade der ITSM-Software aufgeführt.
Folgende fachlichen Gründe wurden des Weiteren innerhalb der Entscheidungsvorlage zum Upgrade der ITSM-Software aufgeführt.
| • | Die implementierte Version der ITSM-Software wird in naher Zukunft vom Softwarehersteller nicht mehr supportet. |
| • | Die implementierte Version der ITSM-Software und die zugehöriger IT-Infrastruktur-Komponenten entsprechen nicht mehr dem aktuellen Stand der Technik und sind somit nicht marktgängig. |
| • | Die im Standardumfang, der vom Softwarehersteller ausgeliefert wird, enthaltenen ITSM-Prozesse und Funktionen sind auf der Basis der oben genannten Anforderungen über Jahre hinweg über das rein vom Softwarehersteller vorgesehene Customizing hinaus tiefgehend geändert worden, sodass die implementierte ITSM-Software nicht mehr dem vom Hersteller festgelegten Standard entspricht. Dieses bedeutet, dass zukünftige Upgrades nur noch mit hohem Personal- und Kostenaufwand durchgeführt werden können. |
Upgradefähigkeit herstellen
Die Upgradefähigkeit der ITSM-Software muss durch Nutzung von ITSM-Software-Standard-Funktionalitäten sichergestellt werden, um zukünftige Upgrades ohne weiteren hohen Personal- und Kostenaufwand durchführen zu können. Dieses bedeutet: Die Kostenfaktoren stehen zu Beginn fest, in der Folge ist das für das Upgrade notwendige Budget klar definiert, und während des Projekts wird keine Anpassung erfolgen.
Die Upgradefähigkeit der ITSM-Software muss durch Nutzung von ITSM-Software-Standard-Funktionalitäten sichergestellt werden, um zukünftige Upgrades ohne weiteren hohen Personal- und Kostenaufwand durchführen zu können. Dieses bedeutet: Die Kostenfaktoren stehen zu Beginn fest, in der Folge ist das für das Upgrade notwendige Budget klar definiert, und während des Projekts wird keine Anpassung erfolgen.
Konsolidierung der Prozesse
Die Durchführung der Konsolidierung der konzernweiten ITSM-Prozesse ist nicht Bestandteil dieses Beitrags. Ziel der Konsolidierung der Prozesse ist, dass ausschließlich konzernweite ITSM-Prozesse existieren, die für alle Business Units Gültigkeit besitzen, und dass für keine Business Unit spezifische ITSM-Prozesse existieren. Es muss innerhalb der Projektdurchführung geprüft werden, inwieweit es notwendig ist, die ITSM-Prozesse anzupassen, um die zukünftige Upgradefähigkeit der ITSM-Software sicherzustellen.
Die Durchführung der Konsolidierung der konzernweiten ITSM-Prozesse ist nicht Bestandteil dieses Beitrags. Ziel der Konsolidierung der Prozesse ist, dass ausschließlich konzernweite ITSM-Prozesse existieren, die für alle Business Units Gültigkeit besitzen, und dass für keine Business Unit spezifische ITSM-Prozesse existieren. Es muss innerhalb der Projektdurchführung geprüft werden, inwieweit es notwendig ist, die ITSM-Prozesse anzupassen, um die zukünftige Upgradefähigkeit der ITSM-Software sicherzustellen.
3 Geplante Projektziele
Die unteren Projektziele wurden innerhalb des Project Charter definiert. Die geplanten Projektziele stellen die festgelegten Anforderungen an die geplanten Ergebnisse des Referenzmodells (s. Kap. 08S03) dar. Für eine bessere Übersicht sind diese hier noch einmal aufgeführt.
| • | Abbildbarkeit der ITSM-Prozesse in der neuen ITSM-Software und deren Auswirkungen bei Nutzung von Standardfunktionalitäten der ITSM-Software zur Sicherstellung der Upgradefähigkeit. |
| • | Die ITSM-Software ist produktionsfähig, performant, sicher und stabil und an die notwendigen Schnittstellensysteme erfolgreich angebunden. |
| • | Das Upgrade der ITSM-Software ist erfolgreich durchgeführt, die ITSM-Software entspricht dem neuesten Stand der Technik und ist marktgängig. |
| • | Die Prozesse sind innerhalb der ITSM-Software abgebildet. Die in den Anforderungsdokumenten beschriebene Funktionalität ist innerhalb der neuen ITSM-Software abgebildet. |
| • | Die Datenmigration und die Übertragung der Daten von der „alten” in die neue ITSM-Software sind erfolgreich durchgeführt. |
| • | Das Upgrade der Infrastrukturkomponenten ist erfolgreich durchgeführt. Dieses umfasst das Upgrade der Datenbanken- und Middleware-Komponenten auf eine andere Herstellerversion und die Übertragung der Parametrisierung von alter Software in die neue ITSM-Software. |
| • | Die Umsetzung der geforderten Funktionalität ist auf der Basis eines mehrstufigen Verfahrens kosteneffizient getestet. |
| • | Planung, Konzeption und Entwicklung der Lerneinheiten und die Durchführung der konzernweiten Schulungen bei den Nutzern der ITSM-Software |
| • | Konzeption, Planung und Anpassung der prozessbegleitenden Dokumentationen (Prozesskonzepte, Arbeitsanweisungen, ...) |
4 Projektvorgehensweise
Herausforderung: Beschränkung auf Standardfunktionen
Die größte Herausforderung ist die Abbildung und Umsetzung der konzernweiten Prozessanforderungen innerhalb der neuen ITSM-Software unter Nutzung von Standardfunktionalitäten der ITSM-Software. Aus diesem Grund liegt der Fokus dieses Beitrags auf der praxisnahen Beschreibung der wesentlichen fachlichen Projektliefergegenstände, mit denen die Abbildung der konzernweiten Prozessanforderungen unter Nutzung von Standardfunktionalitäten gelingt. Dafür wird eine detaillierte Beschreibung der SMUG-Group-Arbeitspakete (s. Kap. 08S03, Abschnitt 4.2.4) mit zugehöriger Prozesssequenz und Prozessen aus einem realen Kundenprojekt gegeben. Auf der Basis dieser praxisnahen Beschreibung und der Beschreibung des Referenzmodells (s. Kap. 08S03) kann ein Kundenprojekt gemäß den genannten Projektzielen (s. Abschnitt 3) termingerecht erfolgreich durchgeführt werden.
Die größte Herausforderung ist die Abbildung und Umsetzung der konzernweiten Prozessanforderungen innerhalb der neuen ITSM-Software unter Nutzung von Standardfunktionalitäten der ITSM-Software. Aus diesem Grund liegt der Fokus dieses Beitrags auf der praxisnahen Beschreibung der wesentlichen fachlichen Projektliefergegenstände, mit denen die Abbildung der konzernweiten Prozessanforderungen unter Nutzung von Standardfunktionalitäten gelingt. Dafür wird eine detaillierte Beschreibung der SMUG-Group-Arbeitspakete (s. Kap. 08S03, Abschnitt 4.2.4) mit zugehöriger Prozesssequenz und Prozessen aus einem realen Kundenprojekt gegeben. Auf der Basis dieser praxisnahen Beschreibung und der Beschreibung des Referenzmodells (s. Kap. 08S03) kann ein Kundenprojekt gemäß den genannten Projektzielen (s. Abschnitt 3) termingerecht erfolgreich durchgeführt werden.
Um Doppelungen zu vermeiden und diesen Beitrag auf die wesentlichen fachlichen Inhalte zu beschränken, sind weitere Beschreibungen zum Referenzmodell und seinen Inhalten im Beitrag „Guideline – ITSM-Software konzernweit upgraden” (s. Kap. 08S03) zu finden.
4.1 Prozess
In Tabelle 1 wird dargestellt, welche ITSM-Prozesse gemäß Prozessmodell innerhalb der neuen ITSM-Software abgebildet werden müssen. Des Weiteren zeigt die Tabelle 1, innerhalb welcher Projektphase welche ITSM-Prozesse als Konzern-ITSM-Prozesse oder als Business-Unit-ITSM-Prozesse abgebildet werden.
Tabelle 1: Abbildung Prozesse innerhalb der Projektphasen
Projektphase | Konzern-ITSM-Prozess | Business-Unit-ITSM-Prozess | ||||||||||||||||
1. |
| --- | ||||||||||||||||
| ||||||||||||||||||
| ||||||||||||||||||
2. |
|
|
4.2 Prozesssequenzen und Funktionssequenzen
Sequenzen
Die Sequenzen stellen die Zusammenfassung von SMUG Groups und die Zuordnung zu einem Prozess dar. In Tabelle 2 werden die im Projekt existierenden Prozesssequenzen und die Zuordnung zu den in Tabelle 1 aufgelisteten Prozessen dargestellt.
Die Sequenzen stellen die Zusammenfassung von SMUG Groups und die Zuordnung zu einem Prozess dar. In Tabelle 2 werden die im Projekt existierenden Prozesssequenzen und die Zuordnung zu den in Tabelle 1 aufgelisteten Prozessen dargestellt.
Tabelle 2: Darstellung Prozess und zugehörige Prozesssequenzen
Prozess | Prozesssequenzen | ||||||||||
Service Desk |
| ||||||||||
Incident Management |
| ||||||||||
Request Fulfilment |
| ||||||||||
Problem Management |
| ||||||||||
Change Management |
| ||||||||||
Service Level Management |
| ||||||||||
Transition Planning and Support |
| ||||||||||
Release and Deployment Management |
| ||||||||||
Service Asset and Configuration Management |
|
Funktionen
Die Querschnittsfunktionen (s. Tabelle 3) sind als Funktionen definiert, die für mehrere Prozesse Gültigkeit besitzen. Die Prozessschnittstellen sind innerhalb der Prozesssequenzen für jeden in die Prozessschnittstelle involvierten Prozess als SMUG-Group beschrieben.
Die Querschnittsfunktionen (s. Tabelle 3) sind als Funktionen definiert, die für mehrere Prozesse Gültigkeit besitzen. Die Prozessschnittstellen sind innerhalb der Prozesssequenzen für jeden in die Prozessschnittstelle involvierten Prozess als SMUG-Group beschrieben.
Tabelle 3: Darstellung Querschnittsfunktionen und zugehörige Sequenzen
Querschnittsfunktionen | Sequenzen | ||||||||||||
Reporting |
| ||||||||||||
Klassifizierungsbaum und Routing |
| ||||||||||||
Status-Modell |
| ||||||||||||
Masken-Layout |
| ||||||||||||
Ticket Templates |
| ||||||||||||
Kommunikation und Eskalation |
| ||||||||||||
Berechtigungskonzept | Das Berechtigungskonzept umfasst die Rollen und deren Berechtigungen zur Teilnahme an den ITSM-Prozessen. Es werden in den meisten Fällen die ITIL-Standardrollen genutzt. Die Berechtigungsvergabe unterliegt dem Standard der Minimalisierung. Dieses bedeutet: Es werden ausschließlich so viele Rechte der jeweiligen Rolle vergeben, wie minimal notwendig sind, damit die jeweilige Rolle ihre vereinbarten Ziele erfüllen kann. Eine weitere Detaillierung des Berechtigungskonzepts würde in einen eigenen Beitrag münden und wird daher hier nicht weiter beschrieben. |
4.3 SMUG-Group-Arbeitspakete
Prozessanforderungsdokumente
Die SMUG-Group-Arbeitspakete stellen die sinnvolle Kombination von Anforderungsdokumenten aus Prozess- und Entwicklungssicht dar.
Die SMUG-Group-Arbeitspakete stellen die sinnvolle Kombination von Anforderungsdokumenten aus Prozess- und Entwicklungssicht dar.
Die konzernweiten Prozessanforderungsdokumente werden von den Prozessmanagern mit dem Ziel der Abbildung der ITSM-Prozesse in der neuen ITSM-Software geliefert.
Auf der Basis der Prozessanforderungsdokumente wurden die SMUG-Group-Arbeitspakete generiert und ausgewählt. Die Komplexität innerhalb der Projektdurchführung besteht aus der korrekten Zusammenfassung der Prozessanforderungen und in der Folge in der Generierung von SMUG-Group-Arbeitspaketen zur Abbildung der zusammengefassten Prozessanforderungen. Dem SMUG-Group-Arbeitspaket sind Anforderungsdokumente, Entwicklungspakete/Pflichtenhefte und Testdokumente zugeordnet. Die Testdokumente, Pflichtenhefte und Entwicklungspakete folgen den definierten Zielen der SMUG-Group-Arbeitspakete.
Das Ziel der nächsten Unterabschnitte ist es, die im Projekt generierten SMUG-Group-Arbeitspakete, zugeordnet zu Prozessen und Prozesssequenzen, auf der Basis von SMUG-Group-Arbeitspaketzielen darzustellen. Pro Zeile wird ein SMUG-Group-Arbeitspaket dargestellt. Es wird nicht der Name des Arbeitspakets, sondern das umzusetzende Ziel des Arbeitspakets beschrieben.
4.3.1 Funktion „Service Desk”
In diesem Abschnitt werden die in der Funktion „Service Desk” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Sequenz: Registrierung
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Registrierung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Registrierung” ab.
Tabelle 4: SMUG-Group-Arbeitspakete der Sequenz „Registrierung”
SMUG-Group-Arbeitspakete Ziele | ||||||
Konzernweite Registrierung (SPoC) und Kategorisierung als
| ||||||
Service-Desk-Interaktionsschnittstellen (Telefonanrufe, E-Mail, Self Service Web Interface, CTI (Computer Telephony Integration) und IVR (Integrated Voice Recognition)) |
Sequenz: Bearbeitung
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Bearbeitung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Bearbeitung” ab.
Tabelle 5: SMUG-Group-Arbeitspakete der Sequenz „Bearbeitung”
SMUG-Group-Arbeitspakete Ziele |
Klassifizierung und Priorisierung |
First Level Support auf der Basis von Standard-Operation-Prozeduren
Anbindung Known Error Database
Anbindung Knowledge Database |
Prüfung, ob weitere ähnliche Tickets vorhanden und Verknüpfung mit bestehenden Tickets |
Schnittstelle Service Desk/Request Fulfilment Management |
Schnittstelle Service Desk/Incident Management |
Schnittstelle Service Desk/Change Management (Standard Change) |
Kommunikation und Information (unterschiedliche Rollen) |
Manuelle und automatische Weiterleitung an Support Gruppe |
Prozesssequenz: Schließen
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Schließen” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Schließen” ab.
Tabelle 6: SMUG-Group-Arbeitspakete der Prozesssequenz „Schließen”
SMUG-Group-Arbeitspakete Ziele |
Service Desk gibt Information an Service Requestor, dass Service Request/Incident/Change beantwortet/gelöst bzw. implementiert ist. |
Abschluss (Kunde prüft, ob Ticket geschlossen werden kann.) |
Schließen inkl. Finalisierung Lösungsdokumentation
Service Desk gibt Information an involvierte Supportgruppen, dass Incident geschlossen worden ist. |
4.3.2 Prozess „Incident Management”
In diesem Abschnitt werden die in dem Prozess „Incident Management” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Prozesssequenzen dargestellt.
Prozesssequenz: Incident Eröffnung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Incident Eröffnung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Incident Eröffnung” ab.
Tabelle 7: SMUG-Group-Arbeitspakete der Prozesssequenz „Incident Eröffnung”
SMUG-Group-Arbeitspakete Ziele |
Erfassung und Vervollständigung Incident
Option: Initiierung Standard Change über die Auswahl eines Wissensdatensatzes vom Typ „Standard Change” |
Bestätigung bzw. Änderung der Priorisierung und der Klassifizierung des Incidents |
Option: Wenn Major Incident => Start des IMoD (Incident Manager on Duty) – Prozess zur priorisierten Behandlung von Major Incidents |
Prüfung, ob weitere ähnliche Incidents vorhanden und Verknüpfung mit bestehenden Incidents
Prüfung oder Aktualisierung oder Erstellung von Beziehungen zwischen den Incidents (z. B. Master/Child-Incident-Beziehungen) |
Prozesssequenz: Incident Bearbeitung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Incident Bearbeitung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Incident Bearbeitung” ab.
Tabelle 8: SMUG-Group-Arbeitspakete der Prozesssequenz „Incident Bearbeitung”
SMUG-Group-Arbeitspakete Ziele |
1st Level Support auf der Basis von Knowledge-Database-Einträgen |
Untersuchung, Diagnose und Bereitstellung Lösung (ggf. Workaround) durch 2nd Level Support und 3rd Level Support u. Dokumentation Lösungsaktivitäten innerhalb Incident Ticket
Anbindung Known Error Database
Anbindung Knowledge Database |
Manuelle oder automatische Weiterleitung Incident gemäß Routing und Klassifizierungsmatrix, wenn Incident nicht gelöst. Incident-Koordinator ist für das Incident Routing zu den korrekten Support-Parteien verantwortlich. |
Schnittstelle Routing und Klassifizierungsmatrix |
Schnittstelle Configuration Management |
Schnittstelle Incident/Problem Management |
Schnittstelle Service Desk/Change Management |
Prozesssequenz: Incident Lösung und Schließen
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Incident Lösung und Schließen” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Incident Lösung und Schließen” ab.
Tabelle 9: SMUG-Group-Arbeitspakete der Prozesssequenz „Incident Lösung und Schließen”
SMUG-Group-Arbeitspakete Ziele |
Incident ist gelöst und Störungsabschluss (Weiterleitung Incident an Funktion „Service Desk” Prozesssequenz „Service Request Schließen”) |
Schnittstelle Incident/Problem Management |
Schnittstelle Service Desk/Change Management (Standard Change) |
4.3.3 Prozess „Request Fulfilment”
In diesem Abschnitt werden die in dem Prozess „Request Fulfilment” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Prozesssequenzen dargestellt.
Prozesssequenz: Service RequestEröffnung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Service Request Eröffnung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Service Request Eröffnung” ab.
Tabelle 10: SMUG-Group-Arbeitspakete der Prozesssequenz „Service Request Eröffnung”
SMUG-Group-Arbeitspakete Ziele |
Erfassung, Vervollständigung und Klassifizierung Service Request und Überprüfung der Berechtigung des Service-Request-Anforderers |
Modellierung Service-Request-Katalog mit Services und Subservices |
Prozesssequenz: Service Request Ausführung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Service Request Ausführung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Service Request Ausführung” ab.
Tabelle 11: SMUG-Group-Arbeitspakete der Prozesssequenz „Service Request Ausführung”
SMUG-Group-Arbeitspakete Ziele |
Ausführung der Aktivitäten gemäß dem Service-Request-Katalog |
Anbindung Knowledge Database |
Prozesssequenz: Service Request Erledigung und Abschluss
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Service Request Erledigung und Abschluss” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Service Request Erledigung und Abschluss” ab.
Tabelle 12: SMUG-Group-Arbeitspakete der Prozesssequenz „Service Request Erledigung und Abschluss”
SMUG-Group-Arbeitspakete Ziele |
Service Request ist gelöst (inkl. Dokumentation aller zum Service Request gehörigen Aktivitäten im Service Request Ticket) und Abschluss (Weiterleitung Service Request an Funktion „Service Desk” Prozesssequenz „Service Request Schließen”) |
4.3.4 Prozess „Problem Management”
In diesem Abschnitt werden die in dem Prozess „Problem Management” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Prozesssequenzen dargestellt.
Prozesssequenz: Problem Eröffnung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Problem Eröffnung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Problem Eröffnung” ab.
Tabelle 13: SMUG-Group-Arbeitspakete der Prozesssequenz „Problem Eröffnung”
SMUG-Group-Arbeitspakete Ziele |
Schnittstelle Incident/Problem Management |
Schnittstelle Incident/Change Management |
Identifizierung, Registrierung, Klassifizierung und Priorisierung Probleme (proaktives Problemmanagement) |
Bei Initiierung Problem aus anderen Prozessen => Vervollständigung, Priorisierung und Klassifizierung Probleme (reaktives Problemmanagement) |
Prüfung, ob weitere ähnliche Probleme vorhanden und Verknüpfung mit bestehenden Problemen
Prüfung oder Aktualisierung oder Erstellung Beziehungen zwischen den Problemen (z. B. Master/Child-Problem-Beziehungen) |
Prozesssequenz: Problem Untersuchung und Diagnose
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Problem Untersuchung und Diagnose” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Problem Untersuchung und Diagnose” ab.
Tabelle 14: SMUG-Group-Arbeitspakete der Prozesssequenz „Problem Untersuchung und Diagnose”
SMUG-Group-Arbeitspakete Ziele |
Manuelle oder automatische Weiterleitung Problem gemäß Routing und Klassifizierungsmatrix. Problem-Koordinator ist für das Problem Routing zu den korrekten Support-Parteien verantwortlich |
Untersuchung, Diagnose und Festlegung Problemlösung durch Support-Parteien u. Dokumentation
Anbindung Known Error Database
Anbindung Knowledge Database |
Schnittstelle Problem/Change Management |
Evaluation/Review Problem (PIR) |
Schnittstelle Incident/Problem Management |
Prozesssequenz: Problem Schließen
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Problem Schließen” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Problem Schließen” ab.
Tabelle 15: SMUG-Group-Arbeitspakete der Prozesssequenz „Problem Schließen”
SMUG-Group-Arbeitspakete Ziele |
Problem-Abschluss inkl. Lösungsdokumentation innerhalb Problem-Ticket |
Aktualisierung/Erstellung Known Error Records (Root-Cause-Beschreibung eines Problems) in Known Error Database |
Wenn notwendig: Erstellung/Update Knowledge-DB-Artikel (KB-Artikel) innerhalb der Knowledge Database |
Schnittstelle Incident/Problem Management |
4.3.5 Prozess „Change Management”
In diesem Abschnitt werden die in dem Prozess „Change Management” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Prozesssequenzen dargestellt.
Prozesssequenz: Change Eröffnung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Einreichung und Erfassung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Einreichung und Erfassung” ab.
Tabelle 16: SMUG-Group-Arbeitspakete der Prozesssequenz „Change Einreichung und Erfassung”
SMUG-Group-Arbeitspakete Ziele |
Schnittstelle Incident/Change Management |
Schnittstelle Incident/Problem Management |
Schnittstelle Incident/SLM Management |
Erstellung Change-Kalender und Implementierung Schichtfunktionalitäten innerhalb des Change-Kalenders. |
RFC Erfassung unter Nutzung von Change-Ticket-Templates. Jeder Change muss mindestens seine Pflichtfelder befüllt haben und eine dem Change zugeordnete Change-Aktivität besitzen. |
Bewertung von Change-Vorschlägen, Review und Rückgabe, wenn Pflichtfelder nicht vollständig befüllt oder Change nicht realisierbar |
Change-Bewertung für zukünftige potenzielle Probleme |
Festlegen Change-Kategorie (Standard Change, Emergency Change, Planbarer Change), Klassifizierung, Priorisierung, Dringlichkeit |
Planbarer Change & Emergency Change |
Bewertung Auswirkung, notwendige Ressourcen und Kosten |
Change Akzeptierung oder Ablehnung unter Angabe von Gründen |
Prüfung, ob weitere ähnliche Changes vorhanden und Verknüpfung mit bestehenden Changes
Prüfung, Aktualisierung oder Erstellung der Beziehungen zwischen den Changes (z. B. Master/Child-Change-Beziehungen) |
Standard Change |
Einmalige Change-Akzeptierung des Standard Change |
Prozesssequenz: Change Bewertung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Bewertung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Bewertung” ab.
Tabelle 17: SMUG-Group-Arbeitspakete der Prozesssequenz „Change Bewertung”
SMUG-Group-Arbeitspakete Ziele | ||||||
Planbarer Change | ||||||
Grobplanung des Change | ||||||
Festlegung der notwendigen Genehmigungen und Genehmigungsgruppen
| ||||||
Bewertung durch Business Units und Funktionen (z. B. CAB) und Genehmigung des Beginns der Change-Implementierungsplanung | ||||||
Emergency Change | ||||||
Grobplanung des Change unter Berücksichtigung des Change-Kalenders | ||||||
Bewertung durch Emergency Committee und Genehmigung des Beginns der Change-Implementierungsplanung | ||||||
Standard Change | ||||||
Einmalige Festlegung der notwendigen Genehmigungen und Genehmigungsgruppen
| ||||||
Einmalige Bewertung durch Business Units und Funktionen (z. B. CAB) und Genehmigung |
Prozesssequenz: Change Koordination
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Koordination” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Koordination” ab.
Tabelle 18: SMUG-Group-Arbeitspakete der Prozesssequenz „Change Koordination”
SMUG-Group-Arbeitspakete Ziele |
Planbarer Change/Emergency Change |
Change- und Release-Planung durch Release Management (Schnittstelle Change/Release Management) |
Genehmigung der detaillierten Change- und Release-Planung durch Business Units und Funktionen (z. B. CAB) unter Berücksichtigung des Change-Kalenders
Eintragen Change in Change-Kalender |
Prüfung der erfolgreichen Release Tests und Freigabe des Release Deployment (Schnittstelle Change/Release Management) |
Change Fallback und Dokumentation |
Standard Change |
Einmalige Standard-Change- und Release-Planung durch Release Management (Schnittstelle Change/Release Management) |
Einmalige Standard-Genehmigung der detaillierten Change- und Release-Planung durch Business Units und Funktionen (z. B. CAB) und Bewertung des Projektplans |
Einmalige Standard-Prüfung der erfolgreichen Release Tests und Freigabe des Release Deployment (Schnittstelle Change/Release Management) |
Durchführungsplanung für den Standard Change |
Erstellung Wissensdatensatz (Typ: „Standard Change”) innerhalb der Knowledge Database als Grundlage des Prozessschritts „Standard Change bei Auswahl eines Wissensdatensatzes vom Typ ,Standard Change’ ” |
Prozesssequenz: Change Evaluierung und Schließen
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Evaluierung und Schließen” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Change Evaluierung und Schließen” ab.
Tabelle 19: SMUG-Group-Arbeitspakete der Prozesssequenz „Change Evaluierung und Schließen”
SMUG-Group-Arbeitspakete Ziele |
Planbarer Change/Emergency Change |
Post Implementation Review inkl. Dokumentation aller notwendigen Change-Aktivitäten im Change Ticket |
Planbarer Change/Emergency Change/Standard Change |
Change-Abschluss |
Schnittstelle Incident/Change Management |
Schnittstelle Change/Problem Management |
4.3.6 Prozess „Release and Deployment Management”
In diesem Abschnitt werden die in dem Prozess „Release and Deployment Management” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Prozesssequenzen dargestellt.
Prozesssequenz: Release Planung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Release Planung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Release Planung” ab.
Tabelle 20: SMUG-Group-Arbeitspakete der Prozesssequenz „Release Planung”
SMUG-Group-Arbeitspakete Ziele |
Schnittstelle Change/Release and Deployment Management |
Zuordnung Changes zu Release Packages, Umfang und Inhalt |
Erstellung detaillierte Release-Planung (Build, Test, Deployment) |
Prozesssequenz: Release Building
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Release Building” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Release Building” ab.
Tabelle 21: SMUG-Group-Arbeitspakete der Prozesssequenz „Release Building”
SMUG-Group-Arbeitspakete Ziele |
Entwicklung des Release inkl. Planung der Entwicklungsaktivitäten, Erstellung der Entwicklungsaufträge an interne und externe Entwicklungslieferanten inkl. Meilensteine und Liefergegenstände |
Schnittstelle Change/Release and Deployment Management |
Durchführung Release Tests |
Prozesssequenz: Release Deployment
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz ab.
Tabelle 22: SMUG-Group-Arbeitspakete der Prozesssequenz „Release Deployment”
SMUG-Group-Arbeitspakete Ziele |
Schnittstelle Change/Release and Deployment Management |
Erstellung Installations- und Deploymentaufträge an die internen und externen Lieferanten und Steuerung Deployment des Release in die Produktionsumgebung |
Prozesssequenz: Release Early Life Support
Für diese Prozesssequenz existieren keine SMUG-Group-Arbeitspakete.
Für diese Prozesssequenz existieren keine SMUG-Group-Arbeitspakete.
Prozesssequenz: Release Schließen
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Release Schließen” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Release Schließen” ab.
Tabelle 23: SMUG-Group-Arbeitspakete der Prozesssequenz „Release Schließen”
SMUG-Group-Arbeitspakete Ziele |
Dokumentation aller durchgeführten Deployment-Aktivitäten in den Activity-Logs |
Schnittstelle Service Asset and Configuration Management/Release and Deployment Management (Update der Configuration Items in der zentralen Configuration Management Database) |
Abschluss Release |
Schnittstelle Change/Release and Deployment Management |
4.3.7 Prozess „Service Asset and Configuration Management”
In diesem Abschnitt werden die in dem Prozess „Service Asset and Configuration Management” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Prozesssequenzen dargestellt.
Prozesssequenz: Configuration Identifizierung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Configuration Identifizierung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Configuration Identifizierung” ab.
Tabelle 24: SMUG-Group-Arbeitspakete der Prozesssequenz „Configuration Identifizierung”
SMUG-Group-Arbeitspakete Ziele |
Manuelle Erfassung/Aktualisierung, Klassifizierung, Kategorisierung (Asset oder Configuration Item), Attribut Befüllung, Status und Beschreibung gemäß dem Configuration-Modell durch Schnittstelle zum Change Management
Zyklisch gesteuerte automatische Erfassung/Aktualisierung, Klassifizierung, Kategorisierung (Asset oder Configuration Item), Attribut Befüllung, Status und Beschreibung gemäß dem Configuration-Modell und manuelle Autorisierung zur Aufnahme in die CMS |
Implementierung CMS (Configuration Management System) mit Configuration-Modell und Abbildung CI oder Asset-Lebenszyklus gemäß Configuration-Modell |
Schnittstelle Service Asset and Configuration Management/Change Management |
Prozesssequenz: Configuration Steuerung
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Configuration Steuerung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Prozesssequenz „Configuration Steuerung” ab.
Tabelle 25: SMUG-Group-Arbeitspakete der Prozesssequenz „Configuration Steuerung”
SMUG-Group-Arbeitspakete Ziele |
Schnittstelle Change/Service Asset and Configuration Management |
Prüfung Vollständigkeit der Asset oder Configuration Items gemäß dem Configuration-Modell |
Ausschließlich Change Management kann CI/Assets hinzufügen und ändern. Löschen eines CI/Asset ist nicht möglich. „Außer Betrieb nehmen” ist möglich. |
4.3.8 Querschnittsfunktion „Reporting”
In diesem Abschnitt werden die in der Querschnittsfunktion „Reporting” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Alle Reporting-Arbeitspakete besitzen das gleiche Ziel: die Lieferung von Berichten an andere ITSM-Prozesse zur Sicherstellung der Prozessziele der einzelnen Prozesse.
Der Inhalt der Reports liefert unterschiedliche Informationen. Zum einen die Informationen zur Steuerung der Einhaltung der vereinbarten Service Level Agreements und zum anderen statistische Auswertungen. Es existieren pro Arbeitspaket (d. h. pro ITSM-Prozess) betriebsrelevante Reports und für KPI (Key-Performance-Indikatoren) relevante Reports.
Gemäß den Prozessanforderungen werden die Reports bei Nutzung von Standardfunktionalitäten der ITSM-Software innerhalb der neuen ITSM-Software abgebildet. Die Reportinhalte basieren auf den Empfehlungen von ITIL V3. Daher ist die ausführliche Darstellung der Reportinhalte nicht Bestandteil dieses Beitrags.
Sequenz: Reporting Erstellung und Publizierung
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Reporting Erstellung und Publizierung” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Reporting Erstellung und Publizierung” ab.
Tabelle 26: SMUG-Group-Arbeitspakete der Sequenz „Reporting Erstellung und Publizierung”
SMUG-Group-Arbeitspakete Ziele |
Implementierung Incident Management Reporting |
Implementierung Problem Management Reporting |
Implementierung Request Fulfilment Reporting |
Implementierung Change Management Reporting |
Implementierung Service Asset and Configuration Management Reporting |
Implementierung Service Level Management Reporting |
4.3.9 Querschnittsfunktion „Klassifizierungsbaum und Routing”
In diesem Abschnitt werden die in der Querschnittsfunktion „Klassifizierungsbaum und Routing” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Übergreifendes Ziel dieser Querschnittsfunktion ist es, eine Methodik bereitzustellen, auf deren Basis eine korrekte Klassifizierung des Tickets (z. B. Incident oder Problem) und gemäß der Klassifizierung eine Weiterleitung an die korrekte Ticket-Support-Gruppe erfolgen kann. Diese Querschnittsfunktion ist ein wesentlicher Erfolgsfaktor dafür, dass der jeweilige Prozess seine Ziele einhalten kann.
Sequenz: Manuelles oder automatisches Routing
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Manuelles oder automatisches Routing” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Manuelles oder automatisches Routing” ab.
Tabelle 27: SMUG-Group-Arbeitspakete der Sequenz „Manuelles oder automatisches Routing”
SMUG-Group-Arbeitspakete |
Manuelles Routing |
(Wenn das Ticket auf der Basis der Routing- und- Klassifizierungsmatrix klassifiziert worden ist, wird eine Support-Gruppe-Empfehlung ausgegeben. Zu dieser Support-Gruppe wird das Ticket nach Bestätigung der Empfehlung weitergeleitet. Wenn die Empfehlung nicht angenommen wird, dann kann aus einer Liste die Support-Gruppe, zu der das Ticket weitergeleitet wird, ausgewählt werden. In der jeweiligen Login-Maske der einzelnen Support-Gruppen werden diese Tickets mit Priorisierung zur weiteren Bearbeitung angezeigt.) |
Automatisches Routing |
(Auf der Basis der Routing- und Klassifizierungsmatrix wird das Ticket automatisch zu einer Support-Gruppe weitergeleitet. In der jeweiligen Login-Maske der einzelnen Support-Gruppen werden diese Tickets mit Priorisierung zur weiteren Bearbeitung angezeigt.) |
Schnittstelle Change Management (alle Änderungen an dem automatischen Routing unterliegen dem Change Management) |
Sequenz: Routing- und Klassifizierungsmatrix
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Routing- und Klassifizierungsmatrix” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Routing- und Klassifizierungsmatrix” ab.
Tabelle 28: SMUG-Group-Arbeitspakete der Sequenz „Routing- und Klassifizierungsmatrix”
SMUG-Group-Arbeitspakete |
Erstellung Service-Baum gemäß der IBPM-Vorgehensweise und des IBPM-Schichtenmodells |
(Das praxiserprobte und standardisierte Referenzmodell IBPM (Intelligence Business Process Monitoring) ist innerhalb des Beitrags „IT Business Service Monitoring – Geschäftsprozessüberwachung leicht gemacht” (s. Kap. 01420) beschrieben [2]. Ziel des Service-Baums ist die Darstellung der Abhängigkeiten und untereinander existierenden Zusammenhänge der Komponenten, IT Services und die Abbildung der IT Services auf die konzernweiten und Business-Unit-spezifischen Prozesse.) |
Klassifizierungs- und Routing-Mechanismus |
(Die Basis des Klassifizierungs- und Routing-Mechanismus ist der in oberer Zeile dargestellte Service-Baum. Es sind die untersten Ebenen des Service-Baums zu identifizieren. Innerhalb dieser untersten Service-Baum-Ebene (in den meisten Fällen die IT-Komponenten-Ebene) wird bis zu dem Klassifizierungslevel detailliert, an dem eine eindeutige Zuordnung zu einem Support-Gruppe-Routing-Pfad stattfinden kann. Inhalt des Routingpfades sind die einzelnen Support-Gruppen, die innerhalb der Bearbeitung des jeweiligen Tickets involviert sind. Ziel ist es, einen Routingpfad zu besitzen, gemäß dem das Routing manuell oder automatisch an die korrekte Ticket Support Group durchgeführt wird.) |
Sequenz: Anbindung an Prozesse
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Anbindung an Prozesse” ab.
Folgende SMUG-Group-Arbeitspakete bilden die Sequenz „Anbindung an Prozesse” ab.
Die Ziele der unteren Arbeitspakete sind gleich. Die Ziele sind die Identifizierung und Eintragung (in die Klassifizierungs- und Routing-Matrix) der Klassifizierungen und zugehörigen korrekten Ticket-Support-Gruppen zur Weiterleitung des Tickets im Rahmen der unten genannten Prozesse.
Tabelle 29: SMUG-Group-Arbeitspakete der Sequenz „Anbindung an Prozesse”
SMUG-Group-Arbeitspakete |
Anbindung Service Desk |
Anbindung Incident Management |
Anbindung Request Fulfilment |
Anbindung Problem Management |
Anbindung Change Management |
Anbindung Release and Deployment Management |
4.3.10 Querschnittsfunktion „Status Modell”
In diesem Abschnitt werden die in der Querschnittsfunktion „Status Modell” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Übergreifendes Ziel dieser Querschnittsfunktion ist es, ein Status-Modell für die ITSM-Prozesse bereitzustellen. Dieses Status-Modell unterscheidet zwischen dem prozessübergreifenden Status (z. B. neu/new, geschlossen/closed) und dem prozessspezifischen Status (z. B. Incident: gelöst/solved u. Change: autorisiert/authorized).
Sequenz: Status Modell
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Status Modell” ab.
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Status Modell” ab.
Tabelle 30: SMUG-Group-Arbeitspakete der Sequenz „Status Modell”
SMUG-Group-Arbeitspakete |
Richtlinien für ein Status-Modell für die ITSM-Prozesse zur Darstellung der gültigen Rahmenbedingungen für prozessübergreifende gleiche Status und für prozessspezifische ungleiche Status |
Statusübergänge innerhalb der jeweiligen Prozesse und innerhalb der Prozessschnittstellen. Die Schnittstellen der Prozesse untereinander sind in den oberen Abschnitten dargestellt. |
Visualisierung der Ticket-Status innerhalb der jeweiligen Prozesse |
4.3.11 Querschnittsfunktion „Masken Layout”
In diesem Abschnitt werden die in der Querschnittsfunktion „Masken Layout” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Übergreifendes Ziel dieser Querschnittsfunktion ist es, Masken-Layouts innerhalb der ITSM-Software für jeden involvierten ITSM-Prozess (siehe obere Abschnitte) bereitzustellen. Das Masken-Layout enthält prozessübergreifende Informationen (z. B. für alle Prozesse einheitliche Felder, gleiche Anordnung und Visualisierung) und die prozessspezifischen notwendigen Felder.
Sequenz: Masken Layout
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Masken Layout” ab.
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Masken Layout” ab.
Tabelle 31: SMUG-Group-Arbeitspakete der Sequenz „Masken Layout”
SMUG-Group-Arbeitspakete |
Richtlinien für das Masken-Layout zur Darstellung der gültigen Rahmenbedingungen für prozessübergreifende gleiche Inhalte und für prozessspezifische Inhalte im Masken-Layout |
Generierung Masken-Layout mit prozessübergreifenden, d. h. für alle Prozesse gültigen Inhalten |
Generierung prozessspezifische Masken-Inhalte speziell für jeden einzelnen Prozess |
4.3.12 Querschnittsfunktion „Ticket Templates”
In diesem Abschnitt werden die in der Querschnittsfunktion „Ticket Templates” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Übergreifendes Ziel dieser Querschnittsfunktion ist es, Ticket Templates innerhalb der ITSM-Software für unten genannte ITSM-Prozesse bereitzustellen. Diese umfasst die prozessübergreifenden Informationen (z. B. Ticket-Namenskonventionen) und die prozessspezifischen notwendigen Felder. Die Ticket Templates basieren auf den Inhalten aus Abschnitt 4.3.11 „Querschnittsfunktion Masken Layout”.
Sequenz: Ticket Templates
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Ticket Templates” ab.
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Ticket Templates” ab.
Tabelle 32: SMUG-Group-Arbeitspakete der Sequenz „Ticket Templates”
SMUG-Group-Arbeitspakete | ||||||||||
Richtlinien für Ticket Templates zur Darstellung der gültigen Rahmenbedingungen für prozessübergreifende gleiche Informationen und für prozessspezifische Informationen innerhalb des Ticket Templates | ||||||||||
Generierung Ticket Templates für untere Prozesse Masken-Layout unter Berücksichtigung der prozessübergreifenden gültigen Informationen und der prozessspezifischen notwendigen Informationen | ||||||||||
|
4.3.13 Querschnittsfunktion „Kommunikation und Eskalation”
In diesem Abschnitt werden die in der Querschnittsfunktion „Kommunikation und Eskalation” enthaltenen SMUG-Group-Arbeitspakete mit zugehörigen Sequenzen dargestellt.
Übergreifendes Ziel dieser Querschnittsfunktion ist es, einen Kommunikations- und Eskalations-Prozess zu implementieren, der für alle Prozesse Gültigkeit besitzt.
Sequenz: Kommunikation und Eskalation Modell
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Kommunikation und Eskalation Modell” ab.
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Kommunikation und Eskalation Modell” ab.
Tabelle 33: SMUG-Group-Arbeitspakete der Sequenz „Kommunikation und Eskalation Modell”
SMUG-Group-Arbeitspakete | ||||||||||
Richtlinien für ein Kommunikations- und Eskalationsmodell zur Darstellung der gültigen Rahmenbedingungen für prozessübergreifende gleiche Kommunikation und Eskalation und prozessspezifische Kommunikation und Eskalation. Gemäß der Klassifizierungs- und Routing-Matrix aus „Querschnittsfunktion ,Klassifizierungsbaum und Routing’ ” (s. Abschnitt 4.3.9) wird die Kommunikation und Eskalation durchgeführt. | ||||||||||
Festlegung für übergreifende und untere Prozesse (siehe Tabelle 34) prozessspezifische Kommunikation und Eskalation. Dies umfasst: | ||||||||||
|
Sequenz: Kommunikation und Eskalation pro Prozess
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Kommunikation und Eskalation pro Prozess” ab.
Folgendes SMUG-Group-Arbeitspaket bildet die Sequenz „Kommunikation und Eskalation pro Prozess” ab.
Tabelle 34: SMUG-Group-Arbeitspakete der Sequenz „Kommunikation und Eskalation pro Prozess”
SMUG-Group-Arbeitspakete | ||||||||||||||||||
Umsetzung der spezifischen Kommunikation und Eskalation innerhalb der unteren Prozesse gemäß den Informationen aus Tabelle 33
|
5 Schlussbemerkung
Auf der Basis dieser Praxisbeschreibung bei detailgenauer Nutzung eines Referenzmodells wie z. B. des Referenzmodells „Intelligence IT Service Management Software Upgrade Guide (SMUG)” (s. Kap. 08S03) kann ein Kundenprojekt seine Projektziele, wie in Abschnitt 3 „Geplante Projektziele” beschrieben, termingerecht erreichen.
