BMW Group Projekt 24/7 Support Projektabschluss Februar 2003.

BMW Group

Projekt 24/7 Support

ProjektabschlussFebruar 2003

BMW 24/7© Accenture 20032

Agenda

• Projektverlauf

• Aufgaben und Zielerreichung

• Benefits für BMW

• Nächste Schritte und Empfehlungen


Ausgehend von Anforderungen des Projekts OO-O und steigenden Anforderungen an zentrale IT-Stellen wurde das Projekt aufgesetzt, um ein abgestimmtes Support-modell für die BMW Group zu entwerfen und pilothaft für OO-O ZJ umzusetzen

Erweiterter BetriebOO-O ZJ

Betrieb

UmsetzungOO-O ZJ

Umsetzungs-plan

OO-O ZJ

Umsetzungs-plan

Supportmodell

Abgestimmtes Supportmodell für BMW Group

Januar 2002

Juni 2002

August 2002

Januar 2003

• Supportzeiten• Kosten• SLA• Arbeitszeiten

ITL-Auftrag Lenkungskreis

FZ-4

VP-6

TG-5

PZ-4

Qualitäts-

kennzahlen

Inbetrieb-nahm

e

Redesign

Rem

edy

Redesign P

rimus

• Anforderung: Erweiterte Supportzeiten• Schwachstellen in der bisherigen

Supportstruktur

neues,globales Supportmodell notwendig !

Grobkonzept Feinkonzept Umsetzung BetriebProjekt OO-O

(Projekt-ende)

ProjektabschlussProjektstart


Agenda

• Projektverlauf





In der Grobkonzeptphase sollte ein Supportmodell zur Sicherstellung der Abdeckung zukünftiger Supportan-forderungen erarbeitet werden

Ziele Projektphase Grobkonzept

Ziele & Anforderungen laut Projektauftrag

•Support-Modell liegt abgestimmt mit allen Prozesspartnern vor (FZ, VP, TG und Personal-Ressort) vor:

• Abdeckung zukünftiger Supportanforderungen ist gewährleistet (7/24)

• Erweiterung auf weitere Fach- / Prozess-IV-Stellen möglich

• Ausrichtung streng nach wirtschaftlichen Gesichtspunkten der Business Seite

•Gemeinsames Verständnis der Support-Struktur (Kunde, 1st, 2nd und 3rd Level) aller Prozesspartner.

•Kosten: 80 PT intern und €330.000 extern.


In der Grobkonzeptphase wurde das neue globale IT-Supportmodell entworfen und vom ITL bestätigt

Zielerreichung Projektphase Grobkonzept

Ergebnisse

• Bewertungsschema zur Klassifizierung von Anwendungssystemen.

• Kernmerkmale des ausgewählten Modells:

•Einteilung in 3 Supportlevel

•Einheitliche Prozesse

•Trennung von Entwicklung und Betrieb

•Trennung von Applikationsbetrieb und Infrastrukturbetrieb

•Ausrichtung der Betriebszeiten an den Business-Anforderungen

• Auswahl und Abnahme eines Supportmodells durch den Steuerkreis (ITL) am 02.05.2002 aus 3 Varianten.

Organisationssicht des Supportmodells:


In der anschließenden Phase sollte das Supportmodell allgemein und speziell für den Piloten OO-O ZJ detailliert werden

Ziele Projektphase Feinkonzept & Umsetzung

Ziele & Anforderungen laut Projektauftrag

•Erweiterte Support für OO-O in ZJ ist auf Basis des vorliegenden Grobkonzepts “Support 7/24” bis Ende 2002 umgesetzt.

•Support für OO-O in ZU und in ME ist auf Basis des vorliegenden Grobkonzepts “Support 7/24” soweit vorbereitet, dass er mit der Implementierung der Systeme an diesen Standorten einsetzen kann.

•Die für die Supportstrukturen benötigten Arbeitszeitmodelle sind abgestimmt und verfügbar.

•Bei VP-6, TG-5 und FZ ist das Supportmodell 7/24 soweit implementiert, dass sie die Support-Anforderungen weiterer, gleich gearteter Applikationen umsetzen können.

•Kosten: 40 PT intern und €179.000 extern.


Im Rahmen der Detaillierung des Supportmodells wurden Arbeitsaufträge zur Durchführung weiterer Umsetzungen erstellt

Zielerreichung Projektphase Feinkonzept & Umsetzung

Ergebnisse• Detaillierte Beschreibung der Kosten und Ableitung kosteneffizienter Supportzeiten (Verhandlungsergebnis: 5/5) für OO-O ZJ.

• Begleitung der SLA-Ausarbeitung und weiterer Umsetzungen in den Ressorts.

• Erstellung eines allgemeinen Feinkonzepts als Grundlage weiterer Implementierungen.

• Erstellung von Arbeitsaufträgen für weitere Umsetzungen (Optimierungen an Remedy und Primus, Serverkennzahlen, Inbetriebnahme).

• Definition der Schnittstellen zwischen den Betriebsstellen (TG-5/FZ und VP-6/FZ).

• Abnahme durch Steuerkreis am 25.07.2002.

Kostenabschätzung für zentralen 2nd Level:


In der Feinkonzeptphase wurden Arbeitsaufträge für weitere Arbeitsumfänge definiert

Zielsetzungen der anschließenden Arbeitsaufträge (Kosten: 60 PT intern und €332.000 extern)

Arbeitsauftrag „Inbetriebnahmeprozess“ Arbeitsauftrag „Optimierung Remedy“

Arbeitsauftrag „Optimierung Primus“ Arbeitsauftrag „Serverkennzahlen“

• Der neue Inbetriebnahmeprozess in den zentralen Betriebsstellen (Applikation und Infrastruktur) liegt als Fachkonzept abgestimmt mit den Prozess-partnern (FZ, TG, VP, EB) vor.

• Es existiert ein gemeinsames Verständnis über die Rollen und Abläufe.

• Umsetzung der im Rahmen des Projekts 24/7 identifizierten Optimierungsmaßnahmen erster Prioritätsstufe: Ticketerfassung, Ticketweiter-leitung, Priorisierung, Supportgruppen etc.

• Die Umsetzungen umfassen sowohl Änderungen an der Konfiguration als auch an der Remedy-Software selbst.

• Definition und Einführung standardisierter Prozesse zum qualitativ hochwertigen Wissensaufbau.

• Einrichtung eines unternehmensglobalen Zugriffs.

• Ausrichtung der Struktur an neu hinzukommenden Nutzergruppen.

• Integration der Lösungsdatenbank in Remedy.

• Das Qualitätskennzahlensystem des Serverbetriebs liegt als Fachkonzept abgestimmt zwischen allen Betriebsstellen bei FZ-441 vor.

• Das Kennzahlensystem unterscheidet zumindest zwischen einer nach innen und einer nach außen gerichteten Perspektive sowie qualitativen und quantitativen Aspekten.


Im Arbeitsauftrag Serverkennzahlen wurde ein Kenn-zahlensystem für den Serverbetrieb (FZ-441) erarbeitet

Zielerreichung Arbeitsauftrag Serverkennzahlen

Ergebnisse

• Erstellung einer Ist-Aufnahme.

• Unterteilung der Kennzahlen in 3 Perspektiven:

•Externe Perspektive -> Kunden

•Interne Perspektive -> FZ-441

•Providerperspektive -> ext. Provider

• Unterteilung jeder Perspektive in 2 Hauptgruppen:

•Qualitätskennzahl: Qualitative Messgrößen

•Serverkennzahl: Quantitative Messgrößen

• Umsetzung eines priorisierten Erstumfangs im System von FZ-400.

• Review-Ergebnis:Messung

InterneInterneKennzahlen

ExterneKennzahlen

Kunden

ExterneKennzahlen

Kunden

ProviderKennzahlen

Provider

ProviderKennzahlen

Provider

FZ-441W

indows

Web

Linux

Tivoli

HP

IBM

SU

N

Controlling (FZ-44)

Folgerungen

Ergebnisse

Folgerungen

Ergebnisse

Kontext der Kennzahlen:

Variante 1


Im Arbeitsauftrag Serverkennzahlen wurde ein Kenn-zahlensystem für den Serverbetrieb (FZ-441) erarbeitet

Zielerreichung Arbeitsauftrag Serverkennzahlen

Ergebnisse

• Erstellung einer Ist-Aufnahme.

• Unterteilung der Kennzahlen in 3 Perspektiven:

•Externe Perspektive -> Kunden

•Interne Perspektive -> FZ-441

•Providerperspektive -> ext. Provider

• Unterteilung jeder Perspektive in 2 Hauptgruppen:

•Qualitätskennzahl: Qualitative Messgrößen

•Serverkennzahl: Quantitative Messgrößen

• Umsetzung eines priorisierten Erstumfangs im System von FZ-400.

• Review-Ergebnis:

Darstellung der Kennzahlen:

Variante 2


Im Arbeitsauftrag Inbetriebnahmeprozess wurde ein globaler Prozess für die geregelte Überführung von IT-Systemen in den Betrieb erarbeitet

Ergebnisse

• Dokumentation des Zusammenhangs mit bereits existierenden und relevanten Beschreibungen.

• Darstellung der Schnittstellen zu anderen Prozessen und Funktionen.

• Formulierung des Prozesses in der MPM-Darstellung.

• Erarbeitung einer Grundlage für die nachfolgende Detaillierung, Umsetzung und Integration in ITPM.

• Review-Ergebnis:

Zielerreichung Arbeitsauftrag Inbetriebnahmeprozess

Beginn

1. Abschätzung & Ressourcenplanung

3. Überprüfung Betriebslösung

8. Rollout / Pilotbetrieb

9. Erstbetrieb / Stabilisierung

10. Abnahme / Übernahme

Ende

5. Approval

2. Beginn Entwicklungs-betrieb bzw. Testbetrieb

4. Integrations-testbetrieb

6. Abschluss SLAs & OLAs 7. Training / Schulung

Abläufe neben dem sequenziellen Pfad stellen parallele Prozesschritte dar, nicht alternative Prozessschritte

Überblick der Prozessschritte:


Zur Optimierung von Remedy und Primus wurden im Projekt 24/7 jeweils Arbeitsaufträge abgestimmt, die sich zurzeit in Bearbeitung befinden

Zielerreichung Arbeitsaufträge Optimierung Remedy und Primus

Ergebnisse Remedy

Ergebnisse Primus

• Input der VGs ist durch VP-62 eingeholt

• Änderungsvorschläge sind mit dem ASZ (für Konfigurationsänderungen) und Softlab (für Änderungen an der Remedy-Software) abgestimmt

• Angebot für Änderungen an der Remedy-Software durch Softlab ist erstellt

• Beauftragung der Änderungen ist erfolgt, Umsetzung bis Ende Februar 2003

• Änderungsvorschläge sind mit dem ASZ abgestimmt

• Überarbeitungsstand ist durch das ASZ vorgestellt

• Projekt-Feedback wurde durch das ASZ eingearbeitet

• 1. Entwurf des Fachkonzepts ist erstellt

• Änderungen werden zum März 2003 produktiv gehen


Agenda

• Projektverlauf





Eine konsistente Umsetzung des Supportmodells und der damit verbundenen Themen sichert BMW eine kurz-, mittel- und langfristige Wertschöpfungssteigerung

Benefits für BMW

Wert-schöpfung

Zeit

KurzfristigeKosten-

ersparnisseQuick Wins

I

MittelfristigeProzessver-besserungen

Erste größere AnpassungenII

LangfristigeKosten-

ersparnisseIV

Längerfristige Maßnahmen

MittelfristigeKosten-

ersparnisseIII

Mittelfristige Maßnahmen

Wertschöpfung

durch:

24/7 Support kann durchgängig und bedarfsorientiert angeboten werden

(„follow the sun“ wo sinnvoll)

•Einheitliche Toolnutzung•Anbindung externer Partner an Remedy•Überwachung des Incident Mgmt. Prozesses•Allgemeiner Zugriff auf Wissensdatenbank

•Kostentransparenz im Business Case•Abstimmung von Arbeitszeitmodellen

•Vereinheitlichung der Prozesse•Angebot von Beratung

•Formen strate-gischer Partner-schaften


Agenda

• Projektverlauf





Insbesondere für die rasche Umsetzung des Inbetriebnahmeprozesses ist das Aufsetzen eines Folgeprojekts zur weiteren Detaillierung und Umsetzung erforderlich

Nächste Schritte & Empfehlungen

• Umsetzung der Rufbereitschaftsregelung für AFKsUmsetzung Projekt 24/7

• Umsetzung des erarbeiteten Kennzahlensystems im System von FZServerkennzahlen

• Integration des Inbetriebnahmeprozesses in ITPM

• Detaillierte Betrachtung der erforderlichen Toolunterstützung für den Workflow

• Ressortspezifische Detaillierung der Rollen und Prozessschritte

• Pilothafte Umsetzung in ausgewählten Projekten

• Aufsetzen einer Projektorganisation mit Leitung bei TG-5 zur Durchführung dieser Schritte

Globaler Inbetriebnahme-

prozess

Bereich: Nächste Schritte & Empfehlungen:

• Abnahme der Ergebnisse des Projekts durch den Lenkungskreis

• Entlastung des Projektteams durch den LenkungskreisAllgemein


Backup

Backup


Option A kann durch 3 Sichten spezifiziert werden: Organisations-, Rollen- und Prozess-Sicht. Darüber hinaus werden die Faktoren Outtasking und Strategie, sowie Randbedingungen und das Bewertungsschema berücksichtigt.

Bewertungsschema

Randbedingungen

Strategie

Out-tasking /

Kern-eigen-

leistung

Organisation(wo wird was gemacht)

Rollen(wer macht wann was)

Prozeß(wie macht man was)

Bewertungsschema

Randbedingungen

Strategie

Out-tasking /

Kern-eigen-

leistung

Organisation(wo wird was gemacht)

Rollen(wer macht wann was)

Prozeß(wie macht man was)

Hauptmerkmale der Sollstruktur

1st Level 2nd Level 3rd Level• ASZ, NHD, Leitstand, evtl. Key-User• Einheitlicher Prozess in allen

Helpdesks• Einheitliche Toolnutzung (Remedy)

mit gleichem Vorgehen (Aufnahme, Eskalation, Routing, Priorisierung)

• Trennung von Applikations-, Applikationsbasis- und Infrastrukturbetrieb

• Einheitlicher Prozess für zentrale Aufgaben

• Keine Codeänderungen ohne Betriebsfreigabe

• Trennung nach intern und extern• Code-Änderungen nach

Beauftragung des 2nd Level im Incident-Fall

• Ausrichtung der SLAs an denen des 2nd Level


In der Organisations-Sicht des BMW-Supportmodells werden Neugestaltungen im 1st, 2nd und 3rd Level definiert.

Key Punkte des 1st Level

• Single-Point-of-Contact für alle Anwender

• Einsatz von ASZ, NHD, Leitstand und Key User

• Zusammenfassung gemeinsam genutzter Dienste zu Shared Services

Key Punkte des 2nd Level

• Trennung von Applikationsbetrieb und Basisbetrieb bestehend aus Applikationsbasisbetrieb und Infrastrukturbetrieb (im Bereich FZ und dessen Customer Service Center)


Key Punkte des 3rd Level

• Trennung in externen und internen Bereich


Organisations-Sicht des Supportmodells


0

1.000

2.000

3.000

4.000

5.000

6.000

7.000

8 / 5 B e trie b 8 / 5 B e trie b m itR ufbe re its c ha f t

16 / 5 B e trie b m itR ufbe re it s c ha f t

2 4 / 7 B e trie b

Tsd. Euro

664 8421.626

3.523+648

+2.602

+162

Applikationsbetrieb (VP-62 / TG-50)

Betrieb in der Prozess IT (VP-6x)

+ 178 + 962 + 2.859Mehraufwand zum 8/5 Betrieb:

8/5 Betrieb 8/5 Betrieb mitRufbereitschaft 24/7

16/5 Betrieb mitRufbereitschaft 24/7 24/7 Betrieb

Empfehlung einer Supportkategorie für OO-O ZJ

Folgende Erkenntnisse konnten aus der Ist-Aufnahme bzw. der Kostenabschätzung für OO-O ZJ gewonnen werden:

Geringes Ticket Aufkommen (ca. 13 T/M bei OO-O ZJ und ca. 20 T/M bei OO-E)

24/7-Fähigkeit ist durch Rufbereitschaft erreichbar

Der 8/5 Betrieb mit Rufbereitschaft ist die effizienteste und günstigste Alternative zur Abdeckung des 24/7 Supports


Für den Support von OO-O ZJ ist der folgende Informationsfluss angestrebt

NHD leitet Anfragen von Anwendern bzgl. OO-O an Kamatsu-Soft zur Ticketerstellung weiter

Kamatsu-Soft im 1st Level leitet Tickets gegebenenfalls an 2nd Level in ZJ weiter

ASZ als zentraler 1st Level kann zur Qualifizierung einbezogen werden

Kann Störung nicht lokal behoben werden bzw. sind zentrale Systeme betroffen, werden Tickets an zentrale Stellen im 2nd Level Support weitergeleitet

Zentrale Stellen untergliedern sich in Applikationssupport VP, TG und Infrastruktursupport

3rd Level Support ist entsprechend zugeordnet


Das System der Kennzahlen bestimmt die Transformation der gemessenen Daten in eine Darstellung, aus der sich Handlungsempfehlungen und Wachstums-planungen ableiten lassen

Messung

Kontext der Kennzahlen

InterneKennzahlen

ExterneKennzahlen

Kunden

ExterneKennzahlen

Kunden

ProviderKennzahlen

Provider

ProviderKennzahlen

Provider

FZ-441

Window

s

Web

Linux

Tivoli

HP

IBM

SU

NControlling (FZ-44)

Folgerungen

Ergebnisse


ServerkennzahlenQualitätskennzahlen

Für jede der Perspektiven (Extern, Intern, Provider) wurden Qualitätskennzahlen und Serverkennzahlen definiert

Fremdeinschätzung Sicht der Qualität aus externer Perspektive Ermittlung durch Befragung

Benchmarking

Messung der Qualität im Verhältnis zu Vergleichs-werten

Folgerungen lassen sich aus dem Vergleich mit vereinbarten Grenzen bzw. Best Practices ableiten

Leistung Darstellung der Leistungsfähigkeit anhand

absoluter Leistungswerte Folgerungen lassen sich aus Verfolgung des

Trends ableiten

Mitarbeiterbezogene Kenngrößen basierend auf Mengengerüsten

Mitarbeiter

Kosten

Betrachtung der Kosten für den Betrieb Darstellung absoluter Kosten und deren Struktur

macht Aussagen über Planungsgüte, zukünftige wie realisierte Einsparpotenziale etc.

Hardware Betrachtung von absoluten Kapazitäten und deren

Auslastung Wachstumsdarstellung bildet die Grundlage für die

Personalwachstumsplanung


Übersicht Kennzahlen Extern


Fremdeinschätzung Kundenzufriedenheit (%)

Benchmarking Termintreue (%) SLA/OLA-Erfüllungsgrad (%)

Leistung Zeit für Übernahme in den Betrieb (Tage, %)

Mitarbeiter

Kosten

Hardware Anzahl Plattformen (Stück) Anzahl Server (Stück) Auslastung Server (%) Wachstum Server (%) Planungsgenauigkeit Server (%)


Übersicht Kennzahlen Intern

ServerkennzahlenQualitätskennzahlenFremdeinschätzung

Kundenzufriedenheit (%) Anteil externer Mitarbeiter (ext. FTE/int. FTE) Mitarbeiterzuwachs (%)

Mitarbeiter

Leistung High-Prio-Tickets (%) Tickets pro Plattform (Stück) Reaktionszeit (Stunden) Lösungszeit (Stunden) Zeit für Übernahme (Tage, %)

Hardware Anzahl Plattformen (Stück) Anzahl Server (Stück) Auslastung Server (%) Wachstum Server (%) Planungsgenauigkeit Server (%)

Benchmarking Kosten Termintreue (%) SLA-Abdeckung Kunden (%) SLA-/OLA-Erfüllungsgrad (%) Eskalierte Tickets (%) Serververfügbarkeit (%)

Absolute Gesamtkosten (Euro) Relative Gesamtkosten (%) Kosten pro Rechenleistung (Euro/MIPS,SPECint) Kosten pro Speicherkapazität (Euro/GB)


Übersicht Kennzahlen Provider


Zufriedenheit mit Provider (%)

Fremdeinschätzung

Benchmarking

Termintreue (%) Serververfügbarkeit (%)

Leistung Anzahl Requests (Stück)

Mitarbeiter

Kosten

Kosten pro Rechenleistung (Euro/MIPS,SPECint) Kosten pro Speicherkapazität (Euro/GB) Kosten pro Ticket (Euro/Stück)

Hardware Anzahl Plattformen (Stück) Anzahl Server (%) Auslastung Server (%) Wachstum Server (%)


Kernziel der Projektphase war die Erarbeitung eines Fachkonzepts für einen Standard-Applikationsinbetriebnahmeprozess

Zielsetzung der Phase „ Standard-Applikationsinbetriebnahmeprozess“

Dieser neue Prozess liegt abgestimmt mit allen Prozesspartnern (EB-21: Hr. Schmid,

FZ-11: Hr. Hierhammer, FZ-30: Hr. Graf, FZ-403: Fr. Pokorny, FZ-441: Hr. Filbig, VP-

62: Hr. Storz, TG-50: Hr. Weickert) vor

Es existiert ein gemeinsames Verständnis über die Rollen und Abläufe

Der Prozess lässt eine weiche Migration vom Projekt in den Infrastruktur- und/oder

Applikationsbetrieb zu

Durch die IT-Neuorganisation wurden die zentralen Applikationsbetriebsstellen in der Ressort-IT geschaffen. Zur Sicherstellung eines termingerechten, qualitativ hochwertigen Produktionsanlaufs müssen diese Stellen in einen Standard-Applikationsinbetriebnahmeprozess eingebunden werden.


Der entworfene Prozess muss folgende Anforderungen erfüllen

Der Prozess, seine Abgrenzung und seine Schnittstellen sind eindeutig beschrieben und konsolidieren bereits

bestehendes

Die beteiligten Rollen sind eindeutig beschrieben und konsolidieren bereits bestehende

Der Prozess kann folgende Szenarien abdecken:

Inbetriebnahme von Applikationen, für die es dedizierten Applikationsbetrieb gibt

Inbetriebnahme von Applikationen, für die das Projekt den Betrieb leistet

Inbetriebnahme nur von Infrastruktur (keine Musterlösungen)

Inbetriebnahme von neuen Releases bereits produktiver Applikationen

Der Prozess ist geeignet, bereits bestehende IV-Systeme koordiniert in den Betrieb durch dedizierte

Betriebsstellen zu überführen

Der Prozess unterstützt den Rollout auf Servern wie auch auf Clients

Möglichkeiten für eine Toolunterstützung des Workflows sind aufgezeigt

Anforderungen an die Phase „Standard-Applikationsinbetriebnahmeprozess”


Der grobe Prozessaufbau zeigt die grundsätzlichen Prozessschritte bei einer entwicklungsbegleitenden Inbetriebnahme

Beginn

1. Abschätzung & Ressourcenplanung

3. Überprüfung Betriebslösung

8. Rollout / Pilotbetrieb

9. Erstbetrieb / Stabilisierung

10. Abnahme / Übernahme

Ende

Grober Prozessaufbau der Inbetriebnahme

5. Approval

2. Beginn Entwicklungs-betrieb bzw. Testbetrieb

4. Integrations-testbetrieb

6. Abschluss SLAs & OLAs 7. Training / Schulung

Abläufe neben dem sequenziellen Pfad stellen parallele Prozesschritte dar, nicht alternative Prozessschritte


Zur Realisierung der Benefits ist eine rasche Umsetzung in den Ressorts am besten anhand eines ressortübergreifenden Pilotprojekts erforderlich

Nächste Schritte

Verfeinerung & Umsetzung

• Weitere Verfeinerung des Prozessmodells

• Pilotierung anhand einer konkreten Inbetriebnahme

• Pilotierung entweder ressortübergreifend oder zumindest mit einem ressortübergreifend besetzten Lenkungskreis zur Abstimmung der Umsetzung

Prozess

• Verfeinerung der Prozessschritte

• Nutzung evtl. bereits implemen-tierter ITSM-Prozesse

• Einarbeitung in ITPM

Tools

• Auswahl eines Tools mit Workflow-Unterstützung

• Abbildung des Prozesses im Tool

Rollen

• Mapping auf die organisatorischen Strukturen

• Einarbeitung in ITPM


In einem nachfolgenden Projekt sind die Integration in ITPM und die detaillierte Betrachtung der Toolunterstützung die wesentlichen Kernpunkte

Weiteres Vorgehen im Gesamtkontext

Fachkonzeptphase Verfeinerung & Umsetzung

Januar 2003

Oktober 2002

• Definition der zu betrachtenden Szenarien

• Analyse hinsichtlich zu betrachtender Schnittstellen (insbesondere zu ITPM, ITSM)

• Erarbeitung des Prozessablaufs und Definition zugehöriger Rollen aus Sicht der Inbetriebnahme

• Abstimmung von Rollen und Prozess mit den beteiligten Prozesspartnern, d.h. EB-21, FZ-11, FZ-30, FZ-403, FZ-441, VP-62, TG-50

• Projekthafte Bearbeitung der nächsten Schritte:

• Integration in ITPM

• Detaillierte Betrachtung der erforderlichen Toolunterstützung für den Workflow

• Ressortspezifische Detaillierung der Rollen und Prozessschritte

• Pilothafte Umsetzung in ausgewählten Projekten

BMW Group Projekt 24/7 Support Projektabschluss Februar 2003.

Documents

Transcript of BMW Group Projekt 24/7 Support Projektabschluss Februar 2003.