Fallstudie SBB Cargo – Einführung eines unternehmens ...20SBB%20Car… · Fallstudie SBB Cargo...

Fallstudie SBB Cargo – Einführung eines unternehmens-weiten Stammdatenmanagements

Alexander Schmidt Bericht Nr.: BE HSG/ CC CDQ/ 22 Lehrstuhl: Prof. Dr. H. Österle Version: 1.0 Datum: 27.09.2009

Universität St. Gallen - Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften (HSG)

Institut für Wirtschaftsinformatik Müller-Friedberg-Strasse 8 CH-9000 St. Gallen Tel.: ++41 / 71 / 224 2420 Fax: ++41 / 71 / 224 2777 Prof. Dr. A. Back Prof. Dr. W. Brenner (geschäftsführend) Prof. Dr. H. Österle Prof. Dr. R. Winter

Inhaltsverzeichnis 2

Inhaltsverzeichnis Inhaltsverzeichnis .................................................................................................... 2 Abstract ..................................................................................................................... 3 1 Unternehmen .................................................................................................... 4

1.1 Überblick ........................................................................................................ 4

1.2 Geschichte ..................................................................................................... 5

1.3 Unternehmensstruktur ................................................................................... 6

1.4 Herausforderungen im Wettbewerb ............................................................... 7

2 Ausgangssituation .......................................................................................... 9 2.1 Strategie und Leitbilder .................................................................................. 9

2.2 Organisation und Daten ............................................................................... 10

2.3 Leidensdruck ............................................................................................... 11

3 Projekt ............................................................................................................. 14 3.1 Projektziele .................................................................................................. 15

3.2 Durchführung ............................................................................................... 16

3.3 Herausforderungen ...................................................................................... 19

3.4 Derzeitiger Projektstand .............................................................................. 20

4 Neue Lösung .................................................................................................. 21 4.1 Stammdatenstrategie ................................................................................... 21

4.2 Organisation: Rollen und Verantwortlichkeiten für Stammdatenobjekte ...... 22

4.3 Stammdaten und Prozesse.......................................................................... 23

4.4 IT-Systemlandschaft .................................................................................... 31

4.5 Kosten und Nutzen ...................................................................................... 32

4.6 Zukünftige Entwicklungen ............................................................................ 33

5 Erkenntnisse .................................................................................................. 35 Anhang A. Geschäftsdatenmodell (Beispiel) ................................................. 37 Anhang B. Expertengespräche ....................................................................... 38 Literatur ................................................................................................................... 39

Abstract 3

Abstract Die Ausrichtung auf das internationale Transitgeschäft im Zuge der Marktöffnung

im Schienengüterverkehr führte bei der SBB Cargo zunehmend zu der Einsicht, dass

Qualität und Verfügbarkeit der Stammdaten nicht mehr den Anforderungen des

Unternehmens (insbesondere für das finanzielle Reporting und die Planung)

entsprachen. Durch die Erkenntnis, dass die Unternehmensstammdaten eine

wichtige Ressource sind, aus deren Qualitätsverbesserung sich Kosteneinsparungen,

Zeitersparnisse sowie Wettbewerbsvorteile erzielen lassen, gelangte die

Geschäftsleitung der SBB Cargo zu der Überzeugung, dass die Etablierung eines

zentralen, unternehmensweit gültigen Stammdatenmanagements notwendig ist.

Als erster Schritt wurde ein dedizierter Verantwortungsbereich etabliert, der als

koordinierende Instanz projektübergreifend die konsistente Verwendung von

Stammdaten sicherstellt bzw. optimiert. Zur Erreichung dieses Zieles wurden eine

Stammdatenstrategie und entsprechende Handlungsfelder zu deren Umsetzung

definiert. Die Handlungsfelder adressieren u.a. die Festlegung eindeutiger

Verantwortlichkeiten für Stammdatenobjekte, die Verankerung von

Datenmanagementaufgaben in Projekten der SBB Cargo sowie die Spezifikation

standardisierter Daten‐ und Metadatenpflegeprozesse. Ein wesentliches

Handlungsfeld (und gleichzeitig erstes Ergebnis) ist die terminologische

Harmonisierung der Stamm‐ bzw. Geschäftsdaten in einem Geschäftsdatenmodell

als Grundvoraussetzung für die Gestaltung der unternehmensweiten

Stammdatenarchitektur.

Unternehmen 4

1 Unternehmen

1.1 Überblick

Die Schweizerische Bundesbahnen Cargo AG (SBB Cargo) mit Sitz in Basel

(Schweiz) ist mit über 4.200 Mitarbeitern und einer jährlichen Verkehrsleistung von

ca. 12,5 Milliarden Nettotonnenkilometern der marktführende Dienstleister im

Schienengüterverkehr der Schweiz. Zudem ist das Unternehmen die Nummer zwei

im strategisch wichtigen, alpenquerenden Transport von Gütern von den

Nordseehäfen und Deutschland nach Italien, der sogenannten Nord‐Süd‐Achse. Als

vollständiges Tochterunternehmen der Schweizerischen Bundesbahnen (SBB) ist

SBB Cargo im Besitz der Schweizerischen Eidgenossenschaft und hat als solches den

Auftrag, im Rahmen der Eigenwirtschaftlichkeit ein flächendeckendes Netz für den

Wagenladungsverkehr zu betreiben und im Transit mit qualitativ hochstehenden

Gütertransporten zur Verkehrsverlagerung von der Strasse auf die Schiene

beizutragen.

Die SBB Cargo bietet ganzheitliche Transportlösungen im nationalen und

internationalen Wagenladungsverkehr (inklusive Import, Export und Transit), im

Ganzzugsverkehr und im kombinierten Verkehr sowie bahnnahe

Zusatzdienstleistungen (z. B. Rangieren, Flottenmanagement, Beladung) und

Serviceleistungen für andere Bahnen. Damit bedient sie zahlreiche Kunden aus

verschiedensten Industrien, zu denen Unternehmen wie ThyssenKrupp, Exxon

Mobil und BASF gehören.

Während die erbrachte Verkehrsleistung beim Binnen‐ und Transitverkehr

innerhalb der Schweiz in den vergangenen Jahren eine stetig abnehmende Tendenz

aufweist, ist es der SBB Cargo gelungen, die Verluste durch den Auf‐ und Ausbau

der Verkehrsleistung im Ausland (Steigerung um über 30%) zu kompensieren.

Daher wurden 2007 bereits 38% der Verkehrsleistung ausserhalb der Schweiz

http://de.wikipedia.org/wiki/Einzelwagenverkehr

Unternehmen 5

produziert. Infolgedessen ist SBB Cargo heute in Italien und Deutschland das

grösste private Eisenbahnverkehrsunternehmen [SBB Cargo 2008, 6].

SBB Cargo AG

Gründung und Firmengeschichte

• Schweizerische Bundesbahnen (Bern): 01. Januar 1902; Umwandlung in AG zum 01. Januar 1999

• SBB Cargo Schweiz (Basel): Division Güterverkehr zum 01. Januar 1999; Umwandlung zur SBB Cargo AG am 01. Januar 2001

• SBB Cargo Deutschland (Duisburg): Gründung 2002 • SBB Cargo Italien (Gallarate): Gründung 2003

Firmensitz Basel, Schweiz

Branche Logistikdienstleister im Schienengüterverkehr

Geschäftsfelder • Transportgeschäft Schweiz • Transportgeschäft International • Asset Management bzw. Instandhaltung (Service Rollmaterial)

Firmenstruktur Aktiengesellschaft mit drei Tochterunternehmen: ChemOil Logistics sowie SBB Cargo Deutschland und SBB Cargo Italien für die es jeweils eine eigenständige Produktionsgesellschaft und Verkaufsagentur gibt (siehe Abbildung 1‐1)

Homepage www.sbbcargo.com

Umsatz Betriebsertrag: CHF 1.044,2 Mio. (2008), CHF 1.062,6 Mio. (2007) Verkehrsleistung: 12,53 Mrd. Nettotonnenkilometer (2008), davon

• Schweiz: 7,76 Mrd. • Deutschland: 3,64 Mrd. • Italien: 914 Mio. • Einkauf bei Dritten: 198 Mio.

Jahresergebnis CHF ‐29.9 Mio. (2008), CHF ‐190,4 Mio. (2007)

Mitarbeiter 4.248 (2008), 4.406 (2007)

Kunden In zahlreichen Industrien, unter anderem Eisen und Stahl, Chemikalien und Petroleum, Holz, intermodaler Transport, Handel und Baugewerbe, Logistik und Landwirtschaft

Tabelle 1‐1: Kurzprofil der SBB Cargo AG

1.2 Geschichte

Grundsätzlich transportiert die SBB bereits seit ihrer Gründung am 1. Januar 1902

Güter, die verschiedenen Vorläuferbahnen der heutigen Bundesbahnen sogar schon

seit der Gründung der Nordbahn (Spanisch‐Brötli‐Bahn) im Jahr 1847. Die ʺDivision

© HSG / IWI / CC CDQ / 22

http://www.sbbcargo.com/

Unternehmen 6

Güterverkehrʺ wurde 1999 mit der Reorganisation der SBB zu einer

spezialgesetzlichen AG gegründet, ab 2000 wurde für die Division auch der Begriff

ʺSBB Cargoʺ verwendet. Die Ausgliederung des Gütergeschäfts der SBB AG in eine

eigenständige Aktiengesellschaft ʺSBB Cargo“ wurde auf den 1. Januar 2001

wirksam. In den darauffolgenden Jahren wurden zur durchgehenden Unterstützung

der internationalen Güterverkehrs – insbesondere der Nord‐Süd‐Achse –

Tochterunternehmen in Deutschland und Italien gegründet.

1.3 Unternehmensstruktur

Die SBB Cargo ist eine eigenständige Aktiengesellschaft, deren Wertpapiere sich

ausschliesslich im Besitz der SBB befinden. Wie im vorherigen Kapitel beschrieben,

wurden nach Gründung der SBB Cargo AG mehrere Tochterunternehmen

geschaffen. Zu diesen gehören [SBB Cargo 2009a]:

• Die am 24. Juni 2002 gegründete SBB Cargo Deutschland (bestehend aus einer

Produktionsgesellschaft und einer Verkaufsagentur) mit Sitz in Duisburg,

welche Güterzüge in Deutschland plant, disponiert und fährt.

• Die SBB Cargo Italien (bestehend aus einer Produktionsgesellschaft und einer

Verkaufsagentur), welche am 29. April 2003 gegründet wurde und ihren Sitz

in Gallarate hat. Sie plant, disponiert und fährt Güterzüge in Italien.

• Die ChemOil Logistics, die auf die Logistik von Mineralöl und chemischen

Produkten spezialisiert ist. Sie entstand aufgrund der Bedeutung der

chemischen Industrie für das Unternehmen sowie der spezifischen

Anforderungen beim Transport chemischer Produkte.

Organisatorisch gliedert sich die SBB Cargo in fünf übergreifende Zentralbereiche

(Finanzen & Controlling, Human Resources, Qualitäts‐ und Informations‐

management, Corporate Services und Business Development) sowie drei operative

Geschäftsbereiche (siehe unterer Teil von Abbildung 1‐1). Während die

Geschäftsbereiche Schweiz und International das eigentliche Kerngeschäft abdecken,


Unternehmen 7

indem sie wettbewerbsfähige Logistiklösungen sowohl für den

innerschweizerischen als auch den grenzüberschreitenden Transport anbieten, ist

der Geschäftsbereich Asset Management für die technische Sicherheit sowie

Verfügbarkeit der Wagen‐ und Lokomotivflotte verantwortlich. SBB Cargo Asset

Management ist dabei nicht nur für die anderen beiden Geschäftsbereiche der SBB

Cargo, sondern auch für die SBB‐Divisionen Infrastruktur und Personenverkehr

sowie für Drittkunden als Dienstleister tätig.

SBB

Personenverkehr Infrastruktur SBB Cargo AG Immobilien

Produktionsgesellschaft DeutschlandSBB Cargo Deutschland GmbH

Verkaufsagentur DeutschlandSBB Cargo GmbH

Produktionsgesellschaft ItalienSBB Cargo Italia Srl

Verkaufsagentur ItalienSBB Cargo Srl

ChemOil Logistics AG

Leitung SBB Cargo AG

GeschäftsbereichSchweiz

GeschäftsbereichInternational

GeschäftsbereichAsset Management

Corporate Services

Business Development

Finanzen & Controlling

Human Resources

Qualitäts- und Informationsmanagement

Abbildung 1‐1: Unternehmensstruktur der SBB Cargo AG [SBB Cargo 2009b, 14]

1.4 Herausforderungen im Wettbewerb

In den vergangenen Jahren haben sich die Rahmenbedingungen des

Schienengüterverkehrs gewandelt. Mit der Globalisierung und der damit

einhergehenden Auslagerung von Produktionsschritten ins Ausland, ist die

Nachfrage nach einem durchgängigen, grenzüberschreitenden Transport gestiegen.

Vormals national agierende Unternehmen des Schienengüterverkehrs müssen ihre


Unternehmen 8

angebotenen Logistikdienstleistungen im Zuge der 2001 initiierten Marktöffnung

auf angrenzende Länder ausdehnen, um das Kundenbedürfnis nach durchgehender

Transportverantwortung („alles aus einer Hand“) zu erfüllen. Mit dem

grenzüberschreitenden Verkehr ist allerdings die Abhängigkeit von der

Infrastruktur entlang der gesamten Transportkette und somit von ausländischen

Infrastrukturanbietern verbunden. Im Zuge der Marktöffnung steigt daher die

Bedeutung von Partnerschaften in der Branche, weshalb die SBB Cargo

beispielsweise 2006 gemeinsam mit der SNCF Fret (französische Güterbahn), der

CFL (luxemburgische Güterbahn) und B Cargo (belgische Güterbahn) die

Gesellschaft Sibelit gegründet hat, um den grenzüberschreitenden Nord‐Süd‐

Gütertransport durch eine Zusammenarbeit zu vereinfachen. Die Notwendigkeit,

benötigte Infrastruktur (Trassen) für den Schienentransport bereits vorläufig für das

folgende Jahr einzukaufen, führt zu hohen Anforderungen an die Planungsqualität

und die dafür benötigten Daten, um Kosten aufgrund nicht genutzter Trassen zu

vermeiden.

Des Weiteren prägen wachsende Anforderungen seitens der Kunden und der

Öffentlichkeit den Güterverkehrsmarkt. Neben Qualität und Pünktlichkeit werden

zunehmend auch für hochfrequente Sendungen mit kleineren Mengen komplette

Kundenlösungen gefordert. Für die SBB Cargo stellen diese Lösungspakete ein

wesentliches Differenzierungskriterium gegenüber der Konkurrenz dar. Seitens der

Öffentlichkeit besteht ein Interesse an einem nachhaltigen Güterverkehr mit einer

positiven Ökobilanz und unter Berücksichtigung externer Kosten.

Zu den Hauptkonkurrenten zählen im Bereich des Schienengüterverkehrs derzeit

die BLS Cargo AG (als Tochterunternehmen der Bern‐Lötschberg‐Simplon AG), die

Deutsche Bahn Schenker Rail GmbH (zu der unter anderem auch die Railion

Deutschland AG zählt) sowie weitere Nischenanbieter, die ebenfalls einen

durchgängigen grenzüberschreitenden Schienengütertransport anbieten. Ausserdem


Ausgangssituation 9

konkurriert die SBB Cargo als Logistikdienstleister im Schienengüterverkehr

indirekt mit Unternehmen anderer Güterverkehrsarten, insbesondere dem

Strassengüterverkehr und dem Luftverkehr.

2 Ausgangssituation

2.1 Strategie und Leitbilder

Vor dem Hintergrund der im vorhergehenden Kapitel beschriebenen

Herausforderungen verfolgt die SBB Cargo folgende strategische Ziele:

• Konsequente Umsetzung der eingeschlagenen Transitstrategie im

Geschäftsfeld „International“,

• Erstellung eines flächendeckenden Angebots im Rahmen eines

eigenwirtschaftlichen Betriebs im Geschäftsfeld Schweiz,

• Erwirtschaftung eines positiven Jahresergebnisses,

• Erreichung der vereinbarten Pünktlichkeitsstandards im nationalen und

internationalen Güterverkehr,

• Angemessene jährliche Steigerung der Produktivität.

Die Marktöffnung für den Schienengüterverkehr im Jahre 2001 führte zu einer

Fokussierung des grenzüberschreitenden Transportes auf die Nord‐Süd‐Achse. Im

Zuge dessen wurden nicht nur Tochterunternehmen im Ausland gegründet,

sondern auch das Geschäftsmodell angepasst, neue Produkte bzw. Dienstleistungen

eingeführt, Geschäftsprozesse verändert und neue Anwendungen eingeführt

[Schwaar 2009, 7]. Die SBB Cargo setzt hier auf eine durchgehende

Transportverantwortung, durch die der Kunde einen einzigen, verantwortlichen

Ansprechpartner hat [SBB Cargo 2009a].

Darüber hinaus setzt die SBB Cargo primär auf zwei Differenzierungsmerkmale

gegenüber der Konkurrenz. Zum einen hat sie in den vergangenen Jahren die

Qualität ihrer Dienstleistung durch eine erhöhte Pünktlichkeit der Auslieferung am

Zielort gesteigert (so erreichten durchschnittlich mehr als 80% der Züge im


Ausgangssituation 10

grenzüberschreitenden Verkehr ihren Bestimmungsort ohne oder mit einer

Verspätung von maximal 60 Minuten, in der Schweiz über 90% pünktlich oder mit

einer Verspätung von maximal 30 Minuten), zum anderen zeichnet sich der

Transport durch seine Umweltfreundlichkeit aus (50% weniger Energie‐ und 60%

weniger CO2‐Verbrauch im Vergleich zum Strassengüterverkehr) [SBB Cargo 2008,

3ff.]. Das Umweltengagement wird zusätzlich durch für den Kunden

massgeschneiderte Emissionsreports bzw. Energiebilanzen, lärmarme Güterwagen,

die Ausstattung von Gefahrguttransporten mit Entgleisungsdetektoren sowie die

Nutzung von Wasserkraft für die Erzeugung des Bahnstroms unterstützt.

2.2 Organisation und Daten

Bezüglich der Organisationsstrukturen der SBB Cargo ist insbesondere auf die

Schnittstellen zum Mutterkonzern, der SBB, hinzuweisen. Dies betrifft unter

anderem den Zentralbereich Qualitäts‐ und Informationsmanagement (QI), welcher

die Themen Prozesse, Qualität und Informatik bei der SBB Cargo verantwortet. Bei

diesen Themen gibt es eine Differenzierung zwischen „Demand“ (Gestaltung und

Anforderungen aus einer fachlichen Sicht) und „Supply“ (informationstechnische

Umsetzung der fachlichen Anforderungen). Während für ersteres der Zentralbereich

QI zuständig ist, wird die informationstechnische Umsetzung durch die zentrale

Informatik des Mutterkonzerns SBB vollzogen.

Der mit der Reorganisation (Ausrichtung auf das internationale Transitgeschäft im

Zuge der Marktöffnung) einhergehende Zeit‐ und Kostendruck führte zu

punktuellen, prozessverbessernden Lösungen, welche jedoch mit zunehmenden

Redundanzen und unterschiedlichen Verständnissen von Stammdatenobjekten

einhergingen. Für das Stammdatenmanagement gab es bei SBB Cargo bis 2008 keine

eindeutig definierte, übergeordnete Verantwortlichkeit im Sinne einer dedizierten

Organisationseinheit innerhalb der bestehenden Organisationsstrukturen, die das

Stammdatenmanagement aus Unternehmenssicht steuerte und über ein eigenes



Budget verfügte. Die Qualität der Stammdaten wurde entsprechend der jeweiligen

Anforderungen projektspezifisch gewährleistet, ohne dass eine koordinierende

Instanz projektübergreifend die konsistente Verwendung von Stammdaten

sicherstellte bzw. optimierte. Zudem fehlte das Wissen über die

unternehmensweiten Anforderungen an die Stammdatenqualität und eine darauf

aufbauende Stammdatenstrategie. Erste Massnahmen zur Verbesserung dieser

Situation wurden durch die Erarbeitung eines Sollkonzeptes für das

Datenmanagement sowie die Projekte „Master Data Integration“ und „Stammdaten

Information Management“ ab 2006 initiiert. Die Konzepte bzw. Projekte wurden

zwar nur unzureichend umgesetzt, sorgten durch die Dokumentation des

Istzustandes aber dafür, das Bewusstsein um die Bedeutung des

Stammdatenmanagements innerhalb der SBB Cargo zu erhöhen.

2.3 Leidensdruck

Die fehlende projektübergreifende Koordination von Aktivitäten hatte zur Folge,

dass in neuen Projekten nicht auf bestehende Funktionalitäten und Daten

zurückgegriffen wurde, da dies in der Regel einen zusätzlichen

Integrationsaufwand bedeutete. Einerseits wurde die bestehende

Applikationsarchitektur zunehmend intransparent, da innerhalb einzelner Projekte

eigene Anwendungen (Individualsoftware) entwickelt wurden, die

projektübergreifend verwendete Daten speichern. Diese wurden dann eher ad‐hoc

in die bestehende Applikationsarchitektur eingebunden, wodurch zahlreiche,

grösstenteils unkoordinierte Punkt‐zu‐Punkt‐Verbindungen entstanden.

Andererseits wurde bei der Datennutzung und ‐speicherung nicht auf die konforme

Verwendung zum bereits bestehenden Stammdatenbestand geachtet:

Stammdatenobjekte wurden mit eigenen Attributen neu definiert, Schlüsselattribute

zur Identifikation neu vergeben. Dadurch konnte nicht mehr sichergestellt werden,

dass ein Geschäftsobjekt über Applikations‐ und Projektgrenzen hinweg einheitlich



in den Systemen abgebildet wurde. Vielmehr entstanden eine Vielzahl von

Synonymen (dasselbe Geschäftsobjekt wird in verschiedenen Systemen

unterschiedlich abgebildet und identifiziert) und teilweise auch Homonymen

(unterschiedliche Geschäftsobjekte erhalten gleiches Schlüsselattribut). Dies führte

unter anderem dazu, dass für die Planung eine andere Stammdatenbasis (eigene

Anwendung) verwendet wird als für die Auswertung der tatsächlich erbrachten

Leistung und betriebliche und kommerzielle Daten in separaten Systemen gepflegt

werden (siehe Abbildung 2‐1). Für die Integration von betrieblicher und

kommerzieller Welt sowie von Planung und Steuerung wurde eine einheitliche

Datenbasis als Grundvoraussetzung gesehen.

SAP R/3

Betriebliche Planung & Steuerung

SAP BW• Kommerzielle

Stammdaten

Data Warehouse• Kommerzielle

Stammdaten (Rechnungen)

CIS 2• Kommerzielle

Stammdaten (Faktura)

CIS 1• Betriebliche

Stammdaten (Bahnhöfe, Ressourcen, Tarife etc.)

• Betriebliche Stammdaten (Fahrzeuge, Infrastruktur, Trassen)

SAP CRM• Kunden• Verträge• Angebote

Legende: CIS … Cargo Informationssystem

• Ergebnisrech-nung in CO-PA

Abbildung 2‐1: Vereinfachte Applikationsarchitektur der SBB Cargo

Zudem war nicht mehr ersichtlich, welches System für ein bestimmtes

Stammdatenobjekt führend ist. Die Applikationsarchitektur mit ihren zahlreichen




Punkt‐zu‐Punktverbindungen ist in Abbildung 2‐1 vereinfacht dargestellt1.

Erschwert werden die Probleme dadurch, dass die betriebliche Planung und

Steuerung nicht sauber und unzureichend in die Applikationsarchitektur

eingebunden ist und sich ausserdem die Anwendungsowner unterscheiden: das

Cargo Informationssystem (CIS) liegt in der Verantwortung von QI, die SAP‐

Systeme hingegen in der des Finanzbereiches.

Die beschriebenen Probleme schlugen sich vor allem im Reporting und Controlling

nieder, für das eine Konsolidierung über den gesamten Wertschöpfungsprozess

hinweg notwendig ist. Die redundante Speicherung von Stammdaten sowie das

fehlende Wissen über den Ort ihrer Speicherung erschwerte eine Konsolidierung. So

konnten beispielsweise Frachtzahler nicht eindeutig den Geschäftsbereichen

(Sparten) zugeordnet werden. Die falsche Zuordnung dieser Stammdaten führte zur

Berechnung unkorrekter Spartenergebnisse und wirkte sich negativ auf die Qualität

der Finanzreports aus. Zusätzliche Auswirkungen haben diese Probleme auf den

Planungsprozess. Da die Planung für den Kauf notwendiger Infrastruktur (z. B.

Trassen) für den Gütertransport beim Infrastrukturbetreiber mit Vorlauf von ca.

einem Jahr durchgeführt werden muss, ist die Qualität der Stammdaten für die

Planungsqualität von entscheidender Bedeutung. Im Vertriebsbereich schlug sich

die unzureichende Datenqualität primär in Kundenreklamationen nieder. Verschärft

wurde die Problematik durch die sich aus der Reorganisation und Neuausrichtung

des Unternehmens ergebende bereits vorab beschriebene Vernachlässigung des

Stammdatenmanagements.

Die wesentlichen Probleme in Bezug auf die Stammdaten lassen sich wie folgt

zusammenfassen:

1 Die einzelnen Teilanwendungen, z. B. der betrieblichen Planung und Steuerung, wurden aus

Gründen der Übersichtlichkeit nicht abgebildet.

Projekt 14

• Fehlende Strategie für den Themenbereich Stammdatenmanagement

(Welcher Bedarf besteht in Bezug auf Stammdaten? Wo wollen wir hin?

Welche Handlungsfelder gibt es?),

• Fehlendes einheitliches Verständnis, da Begriffe, Stammdatenobjekte und

deren Strukturen nicht eindeutig definiert waren,

• Fehlende Definition von unternehmensweit gültigen Pflege‐ und

Änderungsprozessen,

• Fehlende Festlegung der Datenverantwortung (z. B. durch Bestimmung eines

Datenowners),

• Fehlende Transparenz über Entstehung und Verwendung von Stammdaten

in den Geschäftsprozessen sowie über deren Herkunft (führendes System).

Dies führte zunehmend zu der Einsicht, dass Qualität und Verfügbarkeit der

Stammdaten nicht mehr den Anforderungen des Unternehmens entsprachen. Die

Erkenntnis, dass die Unternehmensstammdaten eine wichtige Ressource sind, aus

deren Qualitätsverbesserung sich Kosteneinsparungen (verbesserte

Planungsqualität benötigter Trassen), Zeitersparnisse (automatisierte

Konsolidierung für das Reporting) sowie Wettbewerbsvorteile (bessere Anpassung

des eigenen Produktangebotes auf Grundlage vollständiger und aktueller

Kundenstammdaten) erzielen lassen, führte innerhalb der Geschäftsleitung der SBB

Cargo zu der Überzeugung, dass die Etablierung eines zentralen, unternehmensweit

gültigen Stammdatenmanagements notwendig ist. Hierfür sollten Massnahmen

definiert und umgesetzt werden, um die Qualität der Stammdaten aktiv zu

überwachen und zu steuern [Schwaar 2009].

3 Projekt Aufgrund der Probleme beim Reporting sowie der Planung war der Leidensdruck

innerhalb des Finanzbereiches der SBB Cargo am deutlichsten. Als konkreter

Auslöser sowie Trägerprojekt für die Stammdateninitiative diente daher das FITS‐


Projekt 15

Projekt (Finanzielle Transparenz und Steuerung), dessen Auftraggeber und Sponsor

der Leiter des Finanzbereiches war. Als eines von acht Teilprojekten des FITS

startete das Datenmanagement im Juli 2008 mit einer (vorläufigen) Laufzeit von

einem Jahr.

3.1 Projektziele

Mit dem FITS‐Projekt soll die Unternehmenssteuerung durch eine erhöhte

Transparenz über Prozesse, Daten und Ergebnisse verbessert werden. Das Projekt

stellte daher eine ideale Plattform dar, um das Thema Stammdaten(‐qualität) zu

platzieren. Das Teilprojekt Datenmanagement verfolgte im Wesentlichen vier Ziele:

• Es sollten die Grundlagen für ein unternehmensweites

Stammdatenmanagement erarbeitet werden. Hierzu zählen insbesondere die

Identifikation und eindeutige Definition der Stammdatenobjekte des

Unternehmens (Geschäftsdatenmodell), die Festlegung eines Datenowners

und eines Master‐Systems für ein Stammdatenobjekt sowie die

Dokumentation der Verwendung des Stammdatenobjektes in

Geschäftsprozessen und Systemen. Dieser Teil ist relativ unabhängig vom

FITS‐Projekt und bezieht sich auf die gesamte SBB Cargo.

• Es sollten Voraussetzungen für ein einheitliches Vorgehen beim

Stammdatenmanagement innerhalb einzelner Projekte (im Besonderen auch

für FITS II) geschaffen werden, um sicherstellen, dass das einmal definierte

Geschäftsdatenmodell in allen Projekten gleichermassen verwendet und

konsistent weiterentwickelt wird.

• Es sollten unternehmensweit standardisierte Pflegeprozesse etabliert werden.

Diese sollten durch ein entsprechendes Workflow‐Tool unterstützt respektive

teilautomatisiert werden.

• Speziell für die Unternehmenssteuerung sollte eine sogenannte

Stammdatenschicht eingeführt werden, die Daten aus verschiedenen


Projekt 16

Systemen und Prozessen konsistent zusammenführt und damit die

Grundlage für Planung und Reporting bildet.

3.2 Durchführung

Noch vor Projektbeginn wurde im Zuge der Erstellung der Stammdatenstrategie

(siehe Kapitel 4.1) eine Roadmap entwickelt, die wesentliche Handlungsfelder sowie

deren zeitliche Einordnung zusammenfasst [Schwaar 2008, 19ff.]. Sie sind in Tabelle

3‐1 dargestellt.

Handlungsfeld Kurzbeschreibung Zeitraum

0. Freigabe Stamm‐datenstrategie

Das Strategiepapier beinhaltet Vision, Ziele, Handlungsfelder und einen Meilensteinplan für das Stammdatenmanagement bei SBB Cargo.

am 02.07.2008

1. Erstellen Stammdaten‐Compliance

Die Stammdaten‐Compliance beschreibt die gesetzlichen, aufsichts‐ und vertragsrechtlichen Risiken sowie die regulativen Konzernvorgaben. Sie stellt damit sicher, dass die Stammdatenqualität auch bezüglich Compliance‐Anforderungen erfüllt wird. Ergebnis des Handlungsfeldes soll ein Leitfaden (bestehend aus Checklisten und Arbeits‐anweisungen) sein, der die Compliance‐Anforderungen beschreibt und den Stammdatenobjekten zuordnet.

05.01.2009 bis 16.07.2009

2. Erstellen Stammdaten‐prozesse

Handlungsfeld 2 definiert, implementiert und dokumentiert nachvollziehbar die für das Management der Stammdaten erforderlichen Prozesse (insbesondere Stammdaten‐Führungsprozesse, Pflegeprozesse, Change Management‐Prozesse, Steuerungsprozesse) sowie die entsprechenden Rollen und Verantwortlichkeiten.

01.07.2008 bis 31.12.2008

2.a Einführen toolunterstützter Workflows

Zur Unterstützung der definierten Pflegeprozesse sollen für jedes Stammdatenobjekt toolbasierte Workflows entwickelt und implementiert werden.

01.07.2008 bis 30.06.2009

3 Aufbau zentrales Stammdaten‐Mutationsteam

Ziel ist die Zentralisierung der heute an verschiedenen Stellen durchgeführten Veränderungen (Mutationen) von Stammdaten in einem eigens verantwortlichen Kompetenz‐zentrum. Dadurch sollen schnellere Durchlaufzeiten und geringere Fehlerquoten bei Stammdatenänderungen erreicht werden.

05.01.2009 bis 31.12.2009

4 Aufbau Stamm‐datenarchitektur

Der Aufbau der Stammdatenarchitektur ist eine der wesentlichen Grundlagenarbeitspakete. Es umfasst:

• Festlegen einer einheitlichen Begrifflichkeit, • Definition von Stammdatenstruktur, ‐eigenschaften

und ‐hierarchie, • Spezifikation des Schlüssels eines Stammdatentyps

05.01.2009bis 31.12.2010


Projekt 17

zur eindeutigen Identifikation, • Festlegen eines führenden Master‐Systems.

Das Handlungsfeld formuliert damit langfristige Anforderungen und Prioritäten des Stammdaten‐managements im Hinblick auf die ICT‐Architektur (Information and Communication Technology).

5 Erstellen Stammdaten‐Landkarte (Metamodell)

Die Stammdatenlandkarte beschreibt, welche Stamm‐datenobjekte in welchen Systemen verwendet werden, welches das führende System ist und wie die Daten zwischen den Anwendungen fliessen. Ihre Entwicklung ist daher eng mit dem vorherigen Handlungsfeld verknüpft. Die bestehende Stammdatenlandkarte bildet die Basis für die Migration in das Unternehmensarchitekturmodell.

01.07.2008 bis 31.12.2008

6 Einführung Stammdaten‐Historisierung

Angabe von Informationen zu den Stammdatenobjekten, die entweder in der Vergangenheit oder für die Zukunft über einen längeren Zeitraum Gültigkeit besassen/besitzen. Dies umfasst auch die Versionierung von Objekten und bildet unter anderem die Grundlage für die Erfüllung von Compliance‐Anforderungen.

01.07.2009 bis 31.03.2011

7 Erarbeiten ICT Stammdaten‐Architektur

Die ICT‐Stammdatenarchitektur definiert notwendige Plattformen und Anwendungen für das Stammdaten‐management sowie die Schnittstellen zwischen stamm‐datennutzenden Cargo‐Anwendungen. Die Anforderungen dafür werden durch die Stammdatenarchitektur gestellt. Dieses Handlungsfeld legt die Grundlage für eine langfristige Optimierung und Weiterentwicklung der Applikationsarchitektur (in Bezug auf Stammdatenqualität).

01.07.2008 bis 31.12.2008

7a Einführen ICT Stammdaten‐Architektur

In diesem Handlungsfeld soll die konzeptionell erarbeitete ICT‐Stammdatenarchitektur unter Berücksichtigung der Ergebnisse der vorhergehenden Handlungsfelder (z. B. Stammdatenarchitektur, Compliance‐Anforderungen usw.) umgesetzt werden

05.01.2009 bis 31.12.2011

8 Aufsetzen Kennzahlen‐Reporting

Das Kennzahlen‐Reporting schafft Rahmenbedingungen, um die Qualität der Daten und der Mutationsprozesse messbar zu machen. Dazu gehört die klare Festlegung von Qualitätszielen, Reportmechanismen und Kennzahlen. Die Ergebnisse werden dem Management periodisch im Stammdaten‐Cockpit präsentiert, um einen Nachweis über den Zustand der Stammdaten zu liefern.

01.01.2009 bis 02.10.2009

9 Umsetzung priorisierte Stammdaten‐Brandherde

Zur Behebung identifizierter Stammdaten‐Brandherde und zur Realisierung von Quick Wins sollen kurzfristige Massnahmen erarbeitet und umgesetzt werden.

01.07.2008 bis 31.12.2008 / 01.01.2009 bis 31.12.2009

Tabelle 3‐1: Handlungsfelder der Stammdaten‐Roadmap [Schwaar 2008, 19ff.]


Projekt 18

Für das Teilprojekt „Stammdatenmanagement“ wurde ein Projektteam unter der

Leitung von Herrn Beat Schwaar gebildet, welches externe Unterstützung von zwei

Vertretern der gicom GmbH, ein auf Datenqualitätsmanagement spezialisiertes

Beratungsunternehmen, erhielt. Organisatorisch ist das Stammdatenprojekt im

Zentralbereich QI angesiedelt, während das Gesamtprojekt FITS in Verantwortung

des Finanzbereiches lag (siehe Abbildung 1‐1). Während der Projektdurchführung

wurden die entsprechenden Vertreter aus den Fachbereichen (insbesondere die

Prozessowner) fortlaufend involviert, um die letztendlichen Nutzer der Stammdaten

und ihre Anforderungen berücksichtigen zu können. Im Rahmen von Interviews

und Workshops identifizierten und definierten die Anwender aus den

Fachabteilungen in Zusammenarbeit mit dem Projektteam die von ihnen

verwendeten Datenobjekte sowie die Prozesse und Systeme, in denen die Objekte

verwendet werden. Eine Einschränkung bezüglich bestimmter Stammdatenobjekte

wurde dabei nicht vorgenommen. Konsolidierung und Aufbereitung der

Informationen aus den Interviews durch das Projektteam führten zu einem

iterativen Abstimmungsprozess mit den Fachabteilungen, an dessen Ende die

verabschiedeten Definitionen im Geschäftsdatenmodell dokumentiert wurden (zum

Vorgehen siehe Kapitel 4.3.1). Ausserdem fanden regelmässige Abstimmungen mit

der zentralen IT der SBB statt, um eine den fachlichen Anforderungen

entsprechende Umsetzung sicherzustellen. Teil‐ und Zwischenergebnisse (vor allem

Definitionen einzelner Stammdatenobjekte) wurden über das unternehmensweite

Intranet wöchentlich publiziert, mit dem Ziel, die Stammdatennutzer frühzeitig zur

Verwendung standardisierter Definitionen und Pflegeprozesse zu animieren.

Zu Beginn des Projektes wurden darüber hinaus parallel zu den zentralen

Handlungsfeldern der Roadmap sogenannte „Business Hot Spots“ (Brandherde) für

Stammdaten identifiziert, für deren Behebung ein separates Handlungsfeld (siehe

Tabelle 3‐1) definiert wurde. Durch die Behebung dieser Stammdaten‐Brandherde


Projekt 19

sollte in kurzer Zeit und mit geringem Aufwand relativ hoher Geschäftsnutzen

(sogenannte „Quick Wins“) durch das zentrale Stammdatenmanagement erzielt

werden. Dies erleichterte es dem Projektteam, den konkreten Nutzen seiner Arbeit

aufzuzeigen sowie über einen längeren Zeitraum immer wieder positive Ergebnisse

vorzeigen zu können. Viele „Hot Spots“ wurden im Finanzbereich (Analysesysteme)

sowie im Vertriebscontrolling (Kundennummern, Datumsangaben) identifiziert.

3.3 Herausforderungen

Die grösste Herausforderung bestand (und besteht weiterhin) in der finanziellen

Zuordnung des Stammdaten‐Vorhabens zu einem nicht in der QI aufgesetzten

Projekt (FITS). Als Teil eines Finanzprojektes, organisatorisch jedoch im

Zentralbereich QI verankert, kommt der Stammdateninitiative organisatorisch nicht

die notwendige Handlungsfähigkeit innerhalb der SBB Cargo zu, welche der in

Kapitel 2.3 aufgezeigten Bedeutung hoher Stammdatenqualität für das

Unternehmen entsprechen würde. Dies erschwert zurzeit noch die effiziente

Durchsetzung standardisierter Definitionen und deren Umsetzung in entsprechende

Stammdatensysteme. Zusätzlich ist es schwierig, nach nur einem Jahr, in dem das

Stammdatenprojekt aktiv läuft, den potentiellen Nutzen der aufwendigen

Grundlagenarbeit aufzuzeigen, da dieser sich erst mit der regelmässigen,

standardgemässen Verwendung einheitlich definierter Stammdaten und

Pflegeprozesse einstellen wird. Zwar konnten durch die anfangs realisierten „Quick

Wins“ in speziellen Teilbereichen positive Ergebnisse vorgewiesen werden,

trotzdem bleibt die aktive Mitarbeit des Fachbereiches als interner Kunde (auch in

Bezug auf die Verwendung der erarbeiteten Ergebnisse) von deren Bereitschaft

abhängig.

Eine weitere Herausforderung bestand in der Sensibilisierung der in ihren

funktionalen Strukturen agierenden Mitarbeiter für eine durchgängige,

stammdatenorientierte Sichtweise entlang der Geschäftsprozesse. Hierfür ist das


Projekt 20

Verständnis der Zusammenhänge und ihrer Komplexität zwischen Systemen und

einzelnen Aufgaben vonnöten, dass nur bei wenigen Mitarbeitern vorhanden war.

Im Zusammenhang damit war und ist die Erstellung der Stammdatenarchitektur

äusserst schwierig, weil das Wissen über die Geschäftsdatenobjekte

unternehmensweit verteilt ist und aufwendig zusammengetragen werden muss.

3.4 Derzeitiger Projektstand

Das erste FITS‐Projekt ist nach einjähriger Laufzeit beendet. Trotzdem geht die

Planung des Teilprojektes für Stammdatenmanagement bis Ende 2011 (siehe

Roadmap in Tabelle 3‐1), da seit Juli 2009 das Nachfolgeprojekt FITS II läuft.

Innerhalb von FITS II ist – analog zum ersten FITS‐Projekt – ein Teilprojekt für das

Stammdatenmanagement vorgesehen, in dem die Arbeit gemäss Roadmap

fortgeführt werden soll. Zusätzlich hat das Stammdatenmanagement die Aufgabe,

für das Gesamtprojekt ein Datenkonzept zu erstellen (siehe Kapitel 4.3.2). Bis zum

Zeitpunkt der Fallstudienaufnahme war Handlungsfeld 2 (Definition

Stammdatenprozesse) abgeschlossen, für Handlungsfeld 2a

(Workflowunterstützung) wurde ein erster Prototyp für ein Stammdatenobjekt und

den entsprechenden Prozess implementiert. Der Umfang der durch das Tool

unterstützten Prozesse soll in den kommenden Monaten stetig erweitert werden.

Handlungsfelder 4 (Aufbau Stammdatenarchitektur) und 5 (Erstellen Stammdaten‐

Landkarte) laufen derzeit parallel. Nach Angaben des Projektteams ist man mit

diesen Aufgaben bereits weit fortgeschritten, da 90‐95% der Geschäfts‐ und

Stammdaten im Geschäftsdatenmodell abgebildet sind und für 93% dieser Objekte

der Masterprozess bzw. für 54% das Mastersystem identifiziert wurde (siehe hierzu

Kapitel 4.3). Der Aufbau eines zentralen Mutationsteams (Handlungsfeld 3) ist einer

der wesentlichen Punkte, die als nächstes angegangen werden. Handlungsfeld 1

(Stammdaten‐Compliance) wurde zu Beginn aus Sicht des Gesamtprojektes im

Vergleich zu den anderen Handlungsfeldern niedriger priorisiert und verschoben,


Neue Lösung 21

da hierfür die Zusammenarbeit mit einer zentralen Stelle für Compliance‐Themen

innerhalb des Konzerns SBB (Security) notwendig ist. Die weiteren Handlungsfelder

werden integraler Bestandteil von FITS II sein.

4 Neue Lösung

4.1 Stammdatenstrategie

Als Grundlage eines erfolgreichen Stammdatenmanagements stellte die Erarbeitung

einer Stammdatenstrategie eine der ersten Arbeitsergebnisse der

Stammdateninitiative dar. Daher wurde sie bereits im Vorlauf des FITS‐Projektes

entwickelt (Dezember 2007 bis März 2008) und zu Projektbeginn im Juli 2008

freigegeben. Mit Hilfe der Strategie sollten fünf wesentliche Bereiche des

Stammdatenmanagements adressiert werden [Schwaar 2009, 13]:

• Goals & Vision. Aufzeigen der langfristigen Möglichkeit, durch standardisierte

und optimierte Datenmanagementprozesse eine hohe Qualität der

Stammdaten zu erreichen.

• Data Governance. Festlegung notwendiger Rollen, Aufgaben und

Verantwortlichkeiten, um eine hohe Qualität der Stammdaten dauerhaft zu

gewährleisten.

• Roadmap. Entwicklung eines Projektplanes mit wichtigen Meilensteinen, der

durch wesentliche Handlungsfelder sowie angestrebte Ergebnisse (inklusive

zeitlicher Rahmen) die definierte Stammdatenstrategie operationalisiert (siehe

Tabelle 3‐1).

• Activities. Beschreibung der Handlungsfelder mit detaillierten Tätigkeiten

und Teilprojekten, die zur Umsetzung der Stammdatenstrategie erforderlich

sind.

• Contributors. Einbindung von Experten aus sämtlichen Fachbereichen sowie

der zentralen IT der SBB in den Prozess der Strategieentwicklung, um den

Fachbereich für das Thema zu sensibilisieren und die Akzeptanz zu erhöhen.


Neue Lösung 22

4.2 Organisation: Rollen und Verantwortlichkeiten für Stammdatenobjekte

Grundsätzlich konzentrieren sich sämtliche Aktivitäten für das

Stammdatenmanagement im Projektteam von Herrn Schwaar. Die Etablierung einer

unternehmensweiten Linienaufgabe für das Management der Datenqualität ist ein

langfristiges Ziel (über 2011 hinaus) und soll sich aus den verschiedenen

Handlungsfeldern ergeben.

Im Zuge der Identifikation und Beschreibung der Stammdaten wurde ein

standardisiertes Rollenmodell entwickelt, welches für jedes Stammdatenobjekt

ausgeprägt werden kann. Die darin spezifizierten Rollen sind: a) der Besteller oder

Auftraggeber, der eine Veränderung an einem Stammdatenobjekt auslöst bzw.

beantragt; b) die Prüfstelle, welche die Abhängigkeiten von und zu anderen

Stammdatenobjekten und damit die Richtigkeit von Veränderungen untersucht; c)

der Datenowner, der für die Freigabe und konsistente Änderungen verantwortlich

ist; d) die Mutationsstelle, welche die Veränderungen am Objekt physisch ausführt,

und e) die Kommunikationsstelle, die Veränderungen im Unternehmen publik

macht und verbreitet. Mit Veränderungen sind hier sämtliche Modifikationen an

einem Stammdatenobjekt gemeint, inklusive seiner Entstehung und seiner

Löschung.

Die Rolle des Datenowners ist zweigeteilt. Es gibt einerseits einen operativen

Datenowner, der in seiner täglichen Arbeit mit dem Objekt zu tun hat, andererseits

einen Verantwortlichen aus dem Management für das Objekt. Der Datenowner im

Management wurde jeweils möglichst eng mit dem entsprechenden Prozessowner

verknüpft, idealerweise fallen beide Rollen zusammen. Er ist für die ihm

zugewiesenen Stammdatenobjekte hauptverantwortlich, d. h. er entscheidet über

jegliche Änderungen des Objekts. Mit dieser Rollenzuteilung wurde das Ziel

verfolgt, das prozessorientierte Datenmanagement (über bisherige Funktions‐ und

Systemgrenzen hinweg) zu fördern sowie – durch die Zuordnung der


Neue Lösung 23

Verantwortung auf Management‐ und nicht auf operativer Ebene – den Stammdaten

das notwendige Gewicht zu geben.

In Bezug auf die Definition von Rollen und Verantwortlichkeiten besteht die nächste

Aufgabe in Übereinstimmung mit der definierten Stammdaten‐Roadmap im Aufbau

eines zentralen Mutationsteams, welches sich unternehmensweit um die konsistente

Umsetzung von Veränderungsanfragen für Stammdateninstanzen (Create, Update,

Delete) kümmert. Dazu wird ein pragmatischer Ansatz gewählt, d.h. das zentrale

Mutationsteam soll überall dort zum Einsatz kommen, wo für das Business ein

spürbarer Nutzen entsteht.

4.3 Stammdaten und Prozesse

4.3.1 Geschäftsdatenmodell

Der in Handlungsfeld 4 definierte Aufbau einer Stammdatenarchitektur umfasst als

wichtiges Ergebnis die Entwicklung eines Geschäftsdatenmodells aus Sicht der

wesentlichen Geschäftsprozesse der SBB Cargo. Das Geschäftsdatenmodell soll die

Kernentitäten des Unternehmens sowohl als graphisches Modell als auch in Form

textueller Beschreibungen (Glossare) abbilden und somit eine Grundlage für ein

unternehmensweit einheitliches Verständnis bilden.

Datenarten

Zu Beginn der Arbeit am Geschäftsdatenmodell wurde deutlich, dass eine

ausschliessliche Beschränkung auf die Stammdaten dem Ziel einer

prozessorientierten Dokumentation nur ungenügend gerecht wird, da sie im

Geschäftsprozess selten und eher indirekt verändert werden. Der

Betrachtungsumfang wurde daher allgemein auf Geschäftsdaten erweitert und eine

Dreiteilung der Datenarten vorgenommen, um eine übersichtlichere Darstellung der

Objekte und ihrer Beziehungen zu ermöglichen. Folgende Datenarten wurden

definiert [Schwaar 2009, 17]:


Neue Lösung 24

• Geschäftsvorfalldaten (Business Transaction Data) sind Daten welche direkt im

Laufe eines Wertschöpfungsprozesses entstehen, verwendet, verändert und

wieder gelöscht werden. Typische Beispiele sind Rechnungen, Verträge oder

Angebote. Sie stehen in Beziehung zu anderen Geschäftsvorfalldaten und

nutzen Stammdaten sowie Kerndatenelemente.

• Stammdatenobjekte (Master Data Objects) werden in den Geschäftsvorfällen

verwendet, durch die Geschäftsprozesse aber nicht direkt verändert. Sie

bleiben über einen längeren Zeitraum konstant und stehen mit anderen

Stammdatenobjekten sowie Kerndatenelementen in Beziehung. Zu

Stammdatenobjekten zählen beispielsweise Kunden, Debitoren oder

Verkäufer/Lieferanten.

• Kerndatenelemente (Core Data Elements) entsprechen am ehesten dem in der

wissenschaftlichen Literatur verwendeten Konzept der Referenzdaten, da

deren Pflege zum Teil nicht im Verantwortungsbereich einzelner

Unternehmen liegt, sondern von übergreifenden Organisationen wie dem

Internationalen Eisenbahnverband durchgeführt wird. Sie dienen in der

Regel der Klassifikation von Stamm‐ und Geschäftsvorfalldaten. Typische

Kerndatenelemente sind der NHM‐Code sowie die Klassifikation von

Wagentypen oder Produkten.

Zusätzlich wurde im Laufe der Dokumentation eine vierte Datengruppe gebildet

(„Glossarbegriffe“), in der Synonyme und Homonyme (mit Begriffsowner und

Attributen) zu bestehenden Objekten zugeordnet werden.

Modellierung

Wie bereits zu Beginn des Kapitels angedeutet, wurde für die Dokumentation der

Geschäftsdaten ein zweigleisiges Vorgehen gewählt. Als erstes wird jedes

Geschäftsvorfalldatum, Stammdatenobjekt, Kerndatenelement sowie jeder

Glossarbegriff einheitlich in einem Glossar gepflegt. Zielgruppe des Glossars ist der


Neue Lösung 25

Fachbereich, dem es über das Intranet zur Verfügung gestellt wird, um damit eine

unternehmensweit einheitliche Verwendung der Begrifflichkeiten zu fördern.

Zusätzlich wird den Datennutzern der verantwortliche Datenowner als

Ansprechpartner angezeigt. Innerhalb des Glossars werden folgende Metadaten

geführt: Name (des Datums bzw. Objektes), unternehmensweit einheitliche

Definition, zugehörige Datenklasse, mögliche Werte bzw. Ausprägungen, Attribute

(nur teilweise), Datenowner, Master‐Prozess, Nutzer‐Prozesse, (führendes) Master‐

System und weitere, nutzende Systeme. Ein Beispiel ist in Tabelle 4‐1 angeführt.

Name Beschreibung

Schl

üsse

lbeg

riff

Bus

ines

s

Master Prozess (Produziert)

Nutzer Prozesse (Konsumiert)

MasterSystem

NutzerSystem

Vorschlag Business Owner

Wagentyp

Typisierung / Codierung unterschiedlicher Wagen. Die Wagentypen beschreiben die Bauart und die Eigenschaften des Fahrzeugs. Die Codierung ist durch die UIC festgelegt.Beispiele: Eaos, Habbiillnss, Shimmns

Wagentyp ist eine Teilmenge von Fahrzeug.

KE Instandhaltung

K4.2 Planung (Produziert)

K1.2 Angebotsplanung (Konsumiert)K2.2 Machbarkeit (Konsumiert)K2.3 Offerte (Konsumiert)K3 Leistung (Konsumiert)K4.1 Live Cycle Management (Konsumiert)K4.3 Bereitstellung (Konsumiert)

SAP/ERP

Muster HansMeier Max

Tabelle 4‐1: Ausschnitt aus dem Glossar der SBB Cargo (Kernentität Wagentyp)

Zusätzlich wird für jedes Geschäftsvorfalldatum ein UML‐Klassendiagramm

erstellt, welches das Objekt mit seinen Schlüsselattributen sowie seinen Beziehungen

zu sämtlichen Stammdatenobjekten und Kerndatenelementen zeigt. Das

Geschäftsvorfalldatum stellt somit den zentralen Ankerpunkt eines jeden

Einzeldatenmodells dar. Zum Zeitpunkt der Fallstudienaufnahme konnten 11

Geschäftsvorfalldatenmodelle in Abstimmung mit Prozess‐/Datenownern und

Produktverantwortlichen erstellt werden. In Anhang A ist ein Beispieldiagramm für

das Geschäftsvorfallsdatenobjekt „Opportunity“ abgebildet.

Eine Modellierung bzw. vollständige Beschreibung der Objekte auf Ebene der

Attribute wurde in diesem ersten Schritt bewusst nicht durchgeführt, um die

Komplexität (insbesondere für den Fachbereich) möglichst gering zu halten. Derzeit

werden pro Objekt zum besseren Verständnis wenige, ausgewählte Attribute


Neue Lösung 26

modelliert; die Ausweitung sowie die Festlegung von globalen und lokalen

Attributen werden erst im Rahmen der Architekturgestaltung

(Stammdatenverteilung) in Zukunft durchgeführt. Überbetriebliche Spezifikationen

wie beispielsweise railML, welche standardisierte Beschreibungen von Entitäten im

Schienenverkehrssektor liefern, kommen nicht zur Anwendung.

Vorgehen

Ausgangspunkt für die Identifikation der Geschäftsdatenobjekte war die bestehende

Dokumentation der Geschäftsprozesse, die im Management‐System Cargo sehr

detailliert abgelegt ist. Anhand dieser Geschäftsprozesse konnten erste Objekte

erkannt und die Prozessowner kontaktiert werden. Ausgehend von Gesprächen mit

den Prozessownern wurden iterativ Informationen zu einzelnen Objekten

gesammelt und konsolidiert (wobei wiederum neue Geschäftsdatenobjekte

identifiziert wurden). Hierfür wurden Interviews und Workshops mit Nutzern der

Geschäftsdatenobjekte durchgeführt, um konzertierte Definitionen zu finden (im

Falle abweichender Verständnisse), Nutzersysteme zu identifizieren, den

zugehörigen Prozess (im Sinne des Datenlebenszyklus) zu spezifizieren und den

Datenowner festzulegen, welcher in Zukunft die Aufgabe hat, bezüglich möglicher

Veränderungen an den Metadaten des Geschäftsdatenobjektes zu entscheiden. Eine

wesentliche Herausforderung besteht in der Festlegung eines eindeutigen Schlüssels

zur Identifikation von Geschäftsdatenobjekten. Da sich die Schlüssel derzeit

anwendungsspezifisch unterscheiden (z.B. Kundennummer im CRM‐ und im SAP‐

System), ist die Bestimmung des Master‐Systems notwendig, dessen Schlüssel dann

bei einer zukünftigen Zusammenführung der Datenbestände massgeblich ist.

Das Stammdatenmanagement‐Projektteam bereitete die Informationen

anschliessend auf, pflegte sie in das Glossar ein und veröffentlichte das aktualisierte

bzw. erweiterte Glossar im Intranet. Sukzessiv wurden auch erste UML‐

Klassendiagramme für einzelne Geschäftsvorfalldaten entlang der


Neue Lösung 27

Wertschöpfungskette erstellt. Im Falle uneinheitlicher bzw. inkonsistenter

Definitionen sowie zur Verfeinerung der Datenmodelle wurden anschliessend

iterativ zusätzliche Abstimmungstreffen durchgeführt.

Für die Metadatenpflege, also die konsistente Fortführung der Informationen in

Glossar und Geschäftsdatenmodell, nach fachlicher Freigabe der Änderungen durch

den jeweiligen Datenowner ist (auch in Zukunft) das Stammdatenmanagementteam

zuständig. Darunter fällt die Definition neuer Geschäftsdatenobjekte, die Anpassung

von Datenformaten oder die Änderung von Hierarchien und

Merkmalszuordnungen im Objekt. Die zentrale Mutationsstelle pflegt nur

Änderungen an den Stammdateninstanzen.

Derzeitiger Stand

Die Modelle sowie das Glossar werden derzeit im unternehmensinternen Enterprise

Architecture Management Tool (MEGA) gepflegt und in 14‐tägigem Rhythmus

aktualisiert. In diesem Tool werden in weiteren Schritten auch sämtliche Prozesse

und Systeme (insbesondere der Bebauungsplan) und der Zusammenhang zwischen

Daten, Prozessen und Systemen abgebildet. Das Tool wird dann nicht nur zur

Dokumentation verwendet, sondern erlaubt auch die Ableitung von Reports und

Auswertungen über die gepflegten Geschäftsdatenmodelle (z. B. in welchen

Modellen bestimmte Objekte vorkommen). Durch die derzeit noch nicht vollständig

vorhandene Basis der Verknüpfung von Daten zu Geschäftsprozessen in MEGA

sind integrierte Analysen (z. B. in welchen Geschäftsprozessen bestimmte Objekte

verwendet werden) mit dem Tool aktuell noch wenig aussagekräftig.

Wie Tabelle 4‐2 verdeutlicht wurden insgesamt 303 Geschäftsdatenobjekte

identifiziert, modelliert und beschrieben. Davon sind 62 Geschäftsvorfalldaten

(entspricht 20%) und 47 Stammdatenobjekte (entspricht 16%). Nach Einschätzungen

des Projektteams entsprechen diese Zahlen 90‐95% der Gesamtobjektzahl. Bereits in

den letzten Wochen ist ein signifikantes Wachstum nur noch bei den


Neue Lösung 28

Glossarbegriffen festzustellen. Ausserdem ist zu betonen, dass bei mehr als 90% der

identifizierten Geschäftsdatenobjekte jeweils ein Datenowner definiert und der

Master‐Prozess bestimmt werden konnte.

Beschreibung Absolute Anzahl Prozentualer Anteil

Ermittelte Geschäftsdatenobjekte 303

davon mit Owner 279 92

davon Owner in Abklärung 23 8

Ermittelte Geschäftsdatenobjekte (pro Ebene) 303

Geschäftsvorfalldaten 62 20

Stammdatenobjekte 47 16

Kernelementdaten 114 38

Glossarbegriffe 78 25

noch offen 2 1

Geschäftsdatenobjekte mit Master‐Prozess 204 93

Geschäftsdatenobjekte mit bekanntem Mastersystem 121 54

Tabelle 4‐2: Übersicht über definierte Geschäftsdatenobjekte (Stand: 29.05.2009)

Schliesslich ist noch auf die Unterschiede zu Versuchen in der Vergangenheit

einzugehen, ein unternehmensweites Datenmodell zu erstellen. Diesbezügliche

Initiativen gab es auch innerhalb der SBB Cargo. Jedoch waren diese stets stark IT‐

getrieben und berücksichtigten nur unzureichend die Anforderungen der Fachseite.

Für das jetzige Projekt wurde bewusst eine konträre Herangehensweise verfolgt.

Stammdatenmanagement wird als fachliche und weniger als technische Aufgabe

betrachtet. Massgeblich für die Erarbeitung der Ergebnisse sind die Anforderungen

des Fachbereiches an das Stammdatenmanagement. Dementsprechend werden

Konzepte primär in Zusammenarbeit mit Fachbereichsvertretern entwickelt. Mit der

zentralen IT der SBB finden in der Regel lediglich Abstimmungstreffen statt, in

denen die informationstechnologische Machbarkeit der Umsetzung diskutiert wird.

Dies trifft in besonderem Masse auf die Spezifikation der Stammdatenarchitektur

bzw. des Geschäftsdatenmodells zu. Deren Ziel ist nicht die Modellierung für die


Neue Lösung 29

anschliessende Anwendungsentwicklung, sondern eine einheitliches

Begriffsverständnis (auch zwischen Fachbereich und IT) und darauf aufbauend eine

konsistente Verwendung von Stamm‐ bzw. Geschäftsdatenobjekten sicherzustellen.

Daher ist die vollständige Beschreibung bezogen auf die Art und Anzahl der

Attribute nicht notwendig.

4.3.2 Projektübergreifende Etablierung von Datenmanagementstandards

Parallel zu der im vorherigen Abschnitt beschriebenen Grundlagenarbeit müssen

ständig laufende Projekte, die erste Ergebnisse der Stammdateninitiative nutzen,

unterstützt werden, um die konsistente Weiterentwicklung der

Stammdatenarchitektur sowie der Stammdatenlandkarte zu gewährleisten. Zur

Erreichung dieses Ziels wurde schon frühzeitig ein einheitlicher Prozess entwickelt

(siehe Abbildung 4‐1), der zukünftig in allen Cargo‐Projekten Berücksichtigung

finden soll. Dieser umfasst datenmanagementspezifische Aufgaben und

Meilensteine, die in den allgemeinen Projektplan integriert werden.

Phasen Projektmanagement

Aufgaben Datenmanagement

Studie Grobkonzept Detailkonzept Realisierung Einführung

PKA PKA PKA PKA

Erstellen desDatenkonzeptes mitSDM-Projektteam

Erstellen desDatendetailkonzeptes

gemässDatenkonzept

Umsetzung gemässDetailkonzept

Nachführen desGeschätsdatenmodells

Ist-Geschäfts-datenmodell

Soll-Geschäfts-datenmodell

Soll-Geschäfts-datenmodell

AktualisiertesGeschäfts-

datenmodell

Legende: SDM … StammdatenmanagementPKA … Projektkreditantrag

Abbildung 4‐1: Einbindung des Stammdatenmanagements in das Projektmanagement


Neue Lösung 30


Die Aufgaben des Datenmanagements fokussieren auf die Konsistenzwahrung des

Geschäftsdatenmodelles. Hierfür muss das Projektmanagement auf Grundlage des

bestehenden Geschäftsdatenmodells frühzeitig ein Datenkonzept erarbeiten und

diejenigen Geschäftsdaten identifizieren, welche im Projekt benötigt (also genutzt)

oder verändert werden. Auf Grundlage des Datenkonzeptes und der darin

formulierten Anforderungen wird ein konsistentes Soll‐Geschäftsdatenmodell in

Zusammenarbeit mit dem Stammdaten‐Projektteam sowie den entsprechenden

Datenownern erstellt. Zur besseren Etablierung sowie zur Unterstützung der

Datenmanagement‐Aufgaben in den Projektabläufen wurden Templates erarbeitet,

welche die Definition des Datenkonzeptes zu Beginn eines jeden Projektes

vereinfachen.

4.3.3 Toolunterstützte Stammdatenworkflows

Am 6. Juli 2009 wurde ein mit einem externen Partner entwickeltes Workflow‐

Management‐System (WfMS)1 in Betrieb genommen. Das Tool unterstützt derzeit

die Änderungs‐ und Pflegeprozesse für das Stammdatenobjekt „Debitor“. Die

Implementierung kann als eine indirekte Bestätigung der erfolgreichen

Grundlagenarbeit gesehen werden, baut sie doch auf deren Ergebnissen auf

(festgelegter Datenowner sowie weitere notwendige Rollen, identifizierte Master‐

und Nutzersysteme pro Objekt, Abhängigkeiten zu anderen Geschäftsdaten‐

objekten, Verwendung im Geschäftsprozess). Für die Umsetzung im WfMS wurde

der Pflegeprozess für das Stammdatenobjekt gemeinsam mit dem Datenowner

genau spezifiziert, inklusive der Kriterien für eine erlaubte Veränderung (als

Entscheidungsunterstützung für den Datenowner), der Geschäftsregeln (Business

Rules) zur Überprüfung der Abhängigkeiten zu anderen Geschäftsdatenobjekten

1 Intern wird das System als Prozess‐Workflow‐Tool bezeichnet. Aufgrund der gängigen

Verwendung des Begriffes Workflow‐Management‐System in Wissenschaft und Praxis, verwenden wir im Weiteren die Bezeichnung WfMS.

Neue Lösung 31

und der Mutationsregeln für jedes betroffene System. Nur so war eine

Implementierung des Prozesses in das WfMS möglich.

Durch das WfMS können eine Vielzahl der Schritte im Prozess automatisiert werden

(beispielsweise die Überprüfung von Stammdatenmutationen bezüglich ihrer

Regelkonformität, die kontinuierliche Dokumentation und Auswertung der

Mutationen, die Benachrichtigung der Prozessschrittverantwortlichen), wodurch

sowohl die Durchlaufzeit des Pflegeprozesses als auch die Fehleranfälligkeit

reduziert werden kann. Da das WfMS über das Intranet grundsätzlich für jeden

zugänglich ist, können Anfragen für notwendige Veränderungen ohne grossen

Aufwand ausgelöst und Informationen über den aktuellen Prozessstatus einfach

abgefragt werden.

Derzeit ist es noch zu früh, um valide Aussagen bezüglich des Nutzens zu treffen. In

den kommenden Wochen soll der Umfang des WfMS schrittweise auf weitere

Objekte ausgedehnt werden, wofür die definierten Prozesse für jedes Objekt in dem

Tool abgebildet werden müssen.

4.4 IT-Systemlandschaft

Die Systemlandschaft (siehe Abbildung 2‐1) hat sich in Bezug auf das

Stammdatenmanagement bis zum derzeitigen Zeitpunkt nicht verändert. Die

zielgerichtete (Um‐)Gestaltung der Applikationsarchitektur wurde als wichtiges

Thema für das Stammdatenmanagement identifiziert (siehe Handlungsfeld 7a der

Stammdaten‐Roadmap), jedoch bewusst nach hinten verschoben. In welcher Form

(eigenes Stammdatenprojekt oder im Zuge der konzernweiten

Integrationsarchitektur) dieses aufgrund zahlreicher Abhängigkeiten schwierige

Handlungsfeld adressiert wird, ist derzeit noch nicht geklärt. Grundvoraussetzung

hierfür ist die eindeutige Definition der Stammdatenobjekte sowie die Identifikation

und Dokumentation der entsprechenden Master‐Systeme, welche führend für sie

verantwortlich sind. Zudem muss festgelegt werden, welche Attribute globale


Neue Lösung 32


(unternehmensweite) Gültigkeit besitzen und welche lediglich über lokale

Gültigkeit (z. B. pro System) verfügen sollen. Langfristiges Ziel soll es sein, die

Vielzahl von stammdatenführenden Systemen auf maximal zwei zentrale Systeme

zu reduzieren, in denen die Stammdaten zentral gepflegt und auf angebundene

Systeme verteilt werden. Dadurch soll die langfristige Konsistenzwahrung mit

minimalem Aufwand gewährleistet werden.

4.5 Kosten und Nutzen

Im Rahmen der Entwicklung des Strategiedokumentes wurde primär eine

qualitative Nutzenbetrachtung durchgeführt, jedoch wurden die Kosten und der

erwartete Nutzen in einzelnen Teilbereichen im Sinne einer vereinfachten Business

Case‐Rechnung grob geschätzt. Der quantifizierte Nutzen wurde auf der Grundlage

der reduzierten Anzahl von nicht abrechenbaren Sendungen (NAS)1 und des damit

einhergehenden, geringeren Zinsverlusts sowie der Reduktion der administrativen

Kosten (z. B. durch weniger Nacharbeit) berechnet. Die Verringerung der

Administrationskosten wurde auf 7,3 FTE (Full Time Equivalent, Vollzeit‐

mitarbeiter) pro Jahr geschätzt. Durch die Verringerung der Anzahl nicht

bewertbarer bzw. fakturierbarer Sendungen als Ergebnis der Stammdateninitiative

wurde ein Einsparpotential für den Zinsverlust von 50% prognostiziert, was ca.

1,8% des monetären Wertes der durchschnittlichen Anzahl NAS entspricht.

Zusätzlich werden weitere Nutzenpotentiale aufgezählt, ohne diese genau zu

beziffern. Hierzu zählen unter anderem die Verminderung der manuellen

Aufwände zur Pflege bzw. Fehlerkorrektur oder die Verringerung der benötigten

Zeit zur Erstellung finanzieller Reports sowie die Reduktion der Anzahl fehlerhafter

1 NAS sind Aufträge, welche die SBB Cargo an den Kunden liefert, obwohl sie mangels vollständiger

Vertragsdaten und/oder falscher Angaben der Kunden nicht bewertbar sind und somit nicht fakturiert werden können. Der durchschnittliche Wert einer NAS beträgt ca. CHF 2.250.

Neue Lösung 33

Reports durch eine höhere Transparenz über Datenbasis und Herkunft verwendeter

Daten.

Mit Abschluss des ersten FITS‐Projektes ist für das Teilprojekt

Stammdatenmanagement ein wichtiger Meilenstein erreicht. Auch wenn es derzeit

noch verfrüht ist, finale quantitative Nutzenbetrachtungen abzuleiten (insbesondere

da Investitionen in das Stammdatenmanagement keine direkten monetären

Rückflüsse generieren), lassen mehrere positive Entwicklungen den Schluss zu, dass

die erste Projektphase als erfolgreich bewertet werden kann. So deuten nicht nur die

Aussagen des Projektteams, das die Einschätzung vertrat, dass die

Stammdateninitiative in den Fachbereichen sehr positiv aufgenommen und aktiv

unterstützt wird, auf eine positive Resonanz hin. Die Expertengespräche zeigten,

dass insbesondere der Finanzbereich den langfristigen Nutzen positiv bewertet und

sich viel von den Ergebnissen verspricht, auch wenn das Stammdatenprojekt im

Moment eher mit Aufwand verbunden ist. Insofern ist mit der deutlichen Erhöhung

des Problembewusstseins für die Stammdatenproblematik in den Fachbereichen

bereits ein wichtiger (wenn auch nicht monetärer) Nutzen erzielt wurden. Auch die

Weiterführung der Stammdateninitiative in FITS II (und somit bis mindestens 2011)

ist ein deutliches Zeichen dafür, dass der Nutzen der Arbeit im Unternehmen

erkannt wird.

Um den Fortschritt in Bezug auf die Stammdatenarchitektur zu dokumentieren und

zu bewerten, werden primär Auswertungen erstellt, die mit denen in Tabelle 4‐2

vergleichbar sind. Hierbei sind vor allem Zahlen zur Festlegung von Datenownern

sowie zur Identifikation von Master‐Prozessen und ‐Systemen von Bedeutung.

Qualitative Aussagen sind jedoch (noch) nicht möglich.

4.6 Zukünftige Entwicklungen

Auf die zukünftigen Herausforderungen beim Aufbau einer zentralen

Mutationsstelle sowie der Optimierung der Applikationsarchitektur


Neue Lösung 34

(Zentralisierung der Stammdatenhaltung) zur Erhöhung der Stammdatenqualität

wurde bereits in den vorangegangenen Kapiteln eingegangen. Für die Fertigstellung

des Geschäftsdatenmodelles wird ein Schwerpunkt (auch im Hinblick auf die

Gestaltung der Applikationsarchitektur) auf der Identifikation der Mastersysteme

liegen, die für fast die Hälfte der Entitäten (siehe Tabelle 4‐2) noch nicht

durchgeführt wurde. Ausserdem sollen bis Ende 2010 schrittweise sämtliche

Stammdatenpflegeprozesse definiert werden.

Eine weitere wichtige Aufgabe wird die Bearbeitung von Handlungsfeld 8 mit dem

Aufbau eines kennzahlenbasierten Reportings für die Messung der

Stammdatenqualität sein. Diesbezüglich wird es in einem ersten Schritt notwendig

sein, aussagefähige Messgrössen und Key Performance Indicators (KPIs) zu

identifizieren, um ein Controlling von Qualität (Vollständigkeit, Korrektheit,

Aktualität, Eindeutigkeit, Verfügbarkeit der Daten) und Pflegekosten zu etablieren.

Dies ist wichtig, um die positiven Auswirkungen der eigenen Arbeit aufzuzeigen

und damit zusätzliche Argumente für eine unternehmensweite Verankerung des

Stammdatenmanagements zu haben.

Eine naheliegende Ausweitung des Projektumfangs auf den gesamten SBB‐Konzern

ist derzeit nicht geplant und wird aufgrund der Heterogenität der einzelnen

Konzernbereiche (Personenverkehr, Infrastruktur, Cargo) kritisch bewertet. Allein

das Verständnis über einen Kunden unterscheidet sich signifikant zwischen SBB

Cargo und SBB Personenverkehr. Sinnvoll erscheint dies lediglich bei gemeinsam

genutzten Geschäftsdatenobjekten, wie z. B. Trassen oder Bahnhöfen zwischen den

Geschäftsbereichen Cargo und Infrastruktur. Trotz alledem wird das

Stammdatenmanagement auch in den anderen Konzernbereichen aus Sicht von SBB

Cargo in naher Zukunft ein Schlüsselthema sein, weshalb der Transfer von

Erkenntnissen und Erfahrungen angestrebt werden sollte.


Erkenntnisse 35

Aufbauend auf den Erkenntnissen aus der Erstellung des Geschäftsdatenmodelles

wird zurzeit ein analoges Vorgehen für die Dokumentation sogenannter

Relationsdaten gewählt. Als Relationen werden kommerzielle Strecken zwischen

zwei Bedienpunkten bezeichnet, welche ein Kunde bestellt. Sie stellen wichtige

Entitäten in der Wertschöpfungskette der SBB Cargo dar, da sie unter anderem die

Grundlage für das Angebot und den Verkauf von Leistungen sowie die Berechnung

von Kosten bilden. Für das Management von Relationen soll bis Ende 2009 ein

Fachkonzept erarbeitet werden.

Vor dem Hintergrund der zunehmenden Internationalisierung der SBB Cargo (siehe

Kapitel 1.4), die mit der Nutzung von Infrastruktur im Ausland einhergeht, hat sich

die Stammdatenproblematik in den vergangenen Jahren noch verschärft, da

Ressourcen und Kapazitäten vermehrt bei Partnerunternehmen (SNCF Fret, B

Cargo) eingekauft werden müssen.

5 Erkenntnisse Als Erkenntnisse aus dem Stammdatenprojekt können bereits zum jetzigen

Zeitpunkt ein paar wesentliche Punkte abgeleitet werden, die für dessen Durch‐ und

Weiterführung mitentscheidend waren. Dies ist zum Ersten das Bewusstsein in der

Geschäftsleitung, dass Stammdaten im Unternehmen nicht über die erforderliche

Qualität verfügen und dies negative Auswirkungen entlang der gesamten

Wertschöpfungskette hat (vor Projektbeginn war dies sowohl beim Leiter des QI‐

Bereiches als auch des Finanzbereiches der Fall). Daraus resultiert der Auftrag, das

Stammdatenprojekt als Teilprojekt von FITS abzuwickeln. Hierdurch ist es leichter

möglich, in relativ kurzer Zeit positive Nutzeneffekte zu erzielen und damit das

Problembewusstsein innerhalb des Fachbereiches (als Kunden eines

Stammdatenprojektes) zu erhöhen sowie zusätzliche Argumente für die

Ausweitung auf weitere Unternehmensteile zu haben. Zudem vereinfacht die

Einbettung in das Projekt FITS die Durchsetzung der erarbeiteten Richtlinien und


Erkenntnisse 36


Standards. In diesem Zusammenhang ist die aktive Mitarbeit des Fachbereiches bei

Aufgaben des Stammdatenmanagements zu betonen, die auf eine positive Resonanz

schliessen lässt.

Im Vergleich zu früheren Massnahmen zur Erhöhung der Stammdatenqualität stellt

die durchgängige Ausrichtung an den Anforderungen und die Einbindung des

Fachbereiches einen entscheidenden Erfolgsfaktor bei der Entwicklung der

Stammdatenarchitektur (inklusive Geschäftsdatenmodell) dar. Dementsprechend

liegt der Fokus auf der Etablierung eines einheitlichen Begriffsverständnisses als

Grundlage für die eindeutige Identifikation und konsistente Verwendung von

Stammdatenobjekten. In diesem Sinne wird die Modellierung mit dem Glossar und

der geringstmöglichen Komplexität der Datenmodelle so gewählt, dass die Nutzung

durch den Fachbereich gefördert wird. Erfolgsentscheidend war ausserdem die

Orientierung an den Geschäftsprozessen der SBB Cargo, um die funktions‐ und

systemspezifischen Sichten auf die Geschäftsdatenobjekte zu integrieren und

sicherzustellen, dass Mitarbeiter, die Daten verändern, sich der Konsequenzen ihrer

Änderungen für Datennutzer zu einem späteren Zeitpunkt im Prozess bewusst sind.

Die Prozessorientierung führte zu der Erkenntnis, dass eine ausschliessliche

Fokussierung auf Stammdatenobjekte unzureichend ist, um die Datenqualität im

Unternehmen zu verbessern, weshalb das Geschäftsdatenmodell zusätzlich

Geschäftsvorfall‐ und Referenzdaten umfasst. Schlüsselthemen bei der

Grundlagenarbeit sind die Festlegung der Datenowner (häufig fühlte sich keiner für

ein bestimmtes Objekt verantwortlich), der verwendeten Geschäftsprozessen und

des Master‐Systems. Diese sind noch nicht vollständig abgeschlossen.

Anhang A 37

Anhang A. Geschäftsdatenmodell (Beispiel) Abbildung A‐1 zeigt das Modell für das Geschäftsvorfallsdatenobjekt (GVD)

„Opportunity“. Es ist mit seinen Beziehungen zu Stammdatenobjekten (SDO) und

Kerndatenelementen (KE) sowie angrenzenden GVDs modelliert.

Abbildung A‐1: Modell für das Geschäftsvorfallsdatenobjekt „Opportunity“

Anhang B 38


Anhang B. Expertengespräche

Nr. Datum, Uhrzeit und Ort Interviewpartner

1 16. Juli 2009, 10:00 – 12:00, Basel (Schweiz)

Beat Schwaar, Leiter des Projektes zum Stamm‐ und Geschäftsdatenmanagement, Qualitäts‐ und Informationsmanagement (QI), Prozessmanagement & IT, SBB Cargo AG (seit 2004 bei SBB Cargo, seit 2008 Hauptverantwortlicher für das Stamm‐ und Geschäftsdatenmanagement bei der SBB Cargo)


Mathias Hirschi, Teilprojektleiter Analysesysteme, Management & Accounting (innerbetriebliche Controllingsysteme), Finanzen & Controlling, SBB Cargo AG (nicht direkt in Stamm‐ und Geschäftsdatenmanagement bei der SBB Cargo involviert, aber wichtiger Ansprechpartner und Kunde im Rahmen von FITS)


Karl‐Heinz Diekmann, Bereichsleiter Stammdatenmanagement, gicom GmbH (seit November 2008 als externer Berater aktiv in das Projekt zum Stamm‐ und Geschäftsdatenmanagement bei der SBB Cargo involviert)

Tabelle B‐1: Die Expertengespräche im Überblick

Die Interviews führte Alexander Schmidt (Wissenschaftlicher Mitarbeiter, IWI‐

HSG).

Literatur 39

Literatur [SBB Cargo 2008] SBB Cargo, Geschäftsbereich International, http://www.maekas.wiwi.uni‐

due.de/fileadmin/fileupload/PROJEKT‐MAEKAS/PDFs/praesasentation_SBB.pdf, 20.07.2009

[SBB Cargo 2009a] SBB Cargo, Organisation, SBB Cargo ‐ Schienengüterverkehr europaweit,

http://www.sbbcargo.com/index/sbbc_organisation.htm, 20.07.2009 [SBB Cargo 2009b] SBB Cargo, SBB Cargo im Jahr 2008 ‐ Auszug aus dem Geschäftsbericht der

SBB, Basel 2009b [Schwaar 2008] Schwaar, B., Stammdatenstrategie bei SBB Cargo ‐ Governance, Vision,

Handlungsfelder und Roadmap, Basel 2008 [Schwaar 2009] Schwaar, B., Master Data Management at SBB Cargo, Presentation at the 2nd

CC CDQ2 Workshop, St. Gallen 2009

Fallstudie SBB Cargo – Einführung eines unternehmens ...20SBB%20Car… · Fallstudie SBB Cargo...

Documents

Transcript of Fallstudie SBB Cargo – Einführung eines unternehmens ...20SBB%20Car… · Fallstudie SBB Cargo...