Tagungsband zum HSE-06 (PDF, ca. 1.3 MB)

Transcription

Technische Universität München
Institut für Informatik
VSEK & Lehrstuhl für Software & Systems Engineering
Workshop
Hot Spots der Software Entwicklung
05. Juli 2006
Vertragsmodelle und Haftung
in der Software-Entwicklung
München, 14. Juli 2006
Gerd Beneken
Patrick Keil
Tilman Seifert
Inhaltsverzeichnis
1.
Einleitung ______________________________________________________ 3
2.
Programm ______________________________________________________ 5
3.
Einführung: Herausforderungen des Lieferantenmanagements und der
Vertragsgestaltung in der Software-Entwicklung ________________________ 6
4.
Leistungsvereinbarung und Haftung in der SW- und System-Entwicklung:
rechtliche Rahmenbedingungen ____________________________________ 9
5.
Einkauf von IT-Dienstleistungen bei der Münchener Rück ________________ 21
6.
IT-Beschaffung in der BMW AG ____________________________________ 35
7.
Lieferantenmanagement: Erfahrungen, Anforderungen, Vorschläge aus Sicht
eines Lieferanten _______________________________________________ 45
HSE 2006
2
1.
Einleitung
Leistungsbeziehungen, bei denen ein Software-Dienstleister für die Erbringung von
Entwicklungsleistungen oder für die Lieferung fertiger Systeme verpflichtet wird, sind
meist von Unsicherheit und teils langwierigen Verhandlungen geprägt. Prominente
Beispiele zeigen, dass derartige Beziehungen leider nicht selten erst vor Gericht
beendet werden. Doch auch wenn der Auftragnehmer die vertraglich vereinbarten
Projektziele verfolgt und die vereinbarten Leistungen erbringt, bleibt noch zu prüfen,
ob diese tatsächlich den übergeordneten Zielen des Auftraggebers entsprechen.
Etwa 20 Teilnehmer aus Industrie und Wissenschaft folgten am 05. Juli 2006 der
Einladung der Technischen Universität München und der Initiative VSEK („Virtuelles
Software-Engineering-Kompetenzzentrum, www.software-kompetenz.de) zum HotSpots-Workshop. Der Workshop widmete sich den Fragen, wie Verträge gestaltet
werden und wie Haftung und Gewährleistung heute in der Software- und SystemEntwicklung geregelt sind. Dies sind nicht zuletzt deshalb aktuelle und relevante
Themen, weil
-
Teams und Projekte zunehmend über Landes- und Kulturgrenzen hinweg
zusammenarbeiten,
-
die Einbindung externer Partner und Lieferanten immer umfassender wird (in
bestimmten Branchen ist bereits von „virtuellen Unternehmen“ die Rede, die
letztlich einen (zeitlich begrenzten) Zusammenschluss unabhängiger Partner
zur Erbringung bestimmter Leistungen darstellen),
-
infolgedessen die Konzentration der Unternehmen auf die eigenen
Kernkompetenzen weiterhin anhält (die BMW Group bspw. hat eine
Leistungstiefe von ca. 25%, in der IT liegt der Anteil der Eigenleistung sogar
noch niedriger). Durch das verstärkte „Outtasking“ können zwar Fixkosten
gespart und Erfahrungs- und Größenvorteile des Outsourcing-Partners
genutzt werden, dem gegenüber steht aber eine höhere Abhängigkeit, höhere
Qualitätskosten und abnehmendes Know-how im eigenen Unternehmen.
Vor diesen Hintergründen wurden von den Referenten folgende Themen vorgestellt
und diskutiert: Welche Gestaltungsmöglichkeiten hat das Lieferantenmanagement?
Wie ist der Einkauf von IT-Dienstleistungen in Großunternehmen eingebettet und
organisiert? Welche Spielräume gibt es zwischen den beiden "Extremen" Festpreis
und Bezahlung nach Aufwand? Welche juristischen Rahmenbedingungen und
Leitlinien müssen beachtet werden? Welche Strategien gibt es, um "faire"
Vereinbarungen zu erreichen?
Die Beiträge der Referenten regten zu lebhafter Diskussion an. Weitgehende
Einigkeit bestand u.a. zu folgenden Themen:
-
Oftmals werden in Verträgen Vereinbarungen festgehalten, die die Projektziele
und das geplante Vorgehen nicht optimal wiedergeben oder ihnen oftmals
sogar widersprechen.
-
Die Einbindung von juristischen und kaufmännischen Fachleuten erfolgt meist
zu spät im Einkaufsprozess. Dies vergrößert die oftmals schon bestehenden
„Gräben“ zwischen Fachabteilungen, Controlling und Rechtsabteilung.
HSE 2006
3
-
Projektausschreibungen und Aufgabenbeschreibungen sollten möglichst klare
Informationen über die Auswahlkriterien enthalten.
-
Es existieren noch keine befriedigenden Indikatoren und Kriterien, anhand
derer der Projekterfolg objektiv gemessen werden kann. Daher werden in
Verträgen zu selten variable Honorare vereinbart.
-
Eine objektive und regelmäßige Lieferantenbeurteilung hilft beiden Seiten,
Stärken und Schwächen des Lieferanten zu erkennen und die
Leistungsbeziehung zu optimieren.
Dieser Tagungsband enthält in den folgenden Kapiteln
Präsentationen der Referenten. Es gilt das gesprochene Wort.
HSE 2006
die
vollständigen
4
2.
Programm
Einführung und Begrüßung
14:00 bis 14:05
Begrüßung durch Prof. Manfred Broy,
Lehrstuhl für Software & Systems Engineering, TU München
14:05 bis 14:15
Patrick Keil (TUM):
Einführung zum Workshop
Rechtliche Rahmenbedingungen
14:15 bis 15:00
Dr. Nadja Kaeding (Graefe Rechtsanwälte):
„Leistungsvereinbarung und Haftung in der SW- und System-Entwicklung:
rechtliche Rahmenbedingungen“
Erfahrungen I
15:00 bis 15:45
Norbert Schmelz (Münchener Rückversicherungs-Gesellschaft):
„Einkauf von IT-Dienstleistungen bei der Münchener Rück“
Kaffeepause
Erfahrungen II
16:00 bis 16:45
Reinhold Noppe (BMW Group):
„IT Beschaffung in der BMW AG"
Erfahrungen III
16:45 bis 17:30
Jürgen Lohrmann (MSG Systems AG, IT Service & Integration Solutions):
„Lieferantenmanagement: Erfahrungen, Anforderungen, Vorschläge aus Sicht
eines Lieferanten“
Diskussion
17:30 bis 18:00
Abschlussdiskussion
Anschließend
Empfang
HSE 2006
5
3.
Einführung: Herausforderungen des
Lieferantenmanagements und der Vertragsgestaltung
in der Software-Entwicklung
Patrick Keil ist wissenschaftlicher Mitarbeiter am Lehrstuhl für Software & Systems
Engineering der Technischen Universität München und beschäftigt sich dort mit den
verschiedenen Aspekten (räumlich) verteilter und interorganisationaler SoftwareEntwicklung.
CHAIR IV
Ausgangssituation
Software &
Systems
Engineering
Problem:
- „Projektrisiko Entwicklungsvertrag“ (Toll Collect, Chaos Report,
anekdotische Evidenz)
- Verträge implementieren Anreize, die den eigentlichen Interessen
zuwiderlaufen
- Gilt nicht nur zwischen Unternehmen, sondern auch für
Leistungsbeziehungen innerhalb einer Organisation
Analysemethode:
- Erklärung von „strategischem Verhalten“
Prämissen:
- Parteien (Personen, Unternehmen) treffen rationale Entscheidungen
- Ziel: Nutzen-/Gewinnmaximierung
2
HSE 2006
6
CHAIR IV
Ausgangssituation
Software &
Systems
Engineering
Zielkonflikte durch
1.
Interessensdivergenz
2.
Handlungen des AN haben externe Effekte auf AG
3.
Asymmetrische Information zu Lasten des AG
→ mangelnde Fähigkeit des AG, Handlungen des AN
zu beobachten und zu bewerten
→ AN hat diskretionäre Handlungsspielräume, d.h.
Möglichkeit opportunistischen Verhaltens
Ziel: effiziente Verträge, „faire“ Risikoteilung
3
CHAIR IV
Probleme
Software &
Systems
Engineering
Vor Vertragsabschluss:
- adverse Selektion („negative Auslese“)
•
•
hidden characteristics (Skills, Produktivität etc.)
hidden intention (Wissen sammeln, Resourcen sparen etc.)
→ Unsicherheit bezüglich Qualität (und dadurch auch
hinsichtlich fairem Preis)
Nach Vertragsabschluss:
- Moral Hazard: hidden action, hidden information
Æ diskretionäre Freiräume Æ Ineffizienzen
Nach Projektende:
- Hold-Up: hidden intention: AN nutzt Abhängigkeiten
(spezifische Investitionen, implizites Wissen) aus
→ Preise steigen, Qualität sinkt
HSE 2006
4
7
CHAIR IV
Lösungen
Software &
Systems
Engineering
Moral Hazard:
Monitoring: Kontrolle der Handlungen des AN + Sanktionen
Probleme:
- Kosten
- fehlende Indikatoren für Qualität und Quantität des Inputs
Anreizsysteme: anreizkompatible Verträge (variables Honorar)
Æ
Æ
Æ
Æ
Alignment of Interests Æ Gewinn des AN = f (Gewinn AG)
Partizipationsbedingung + Anreizkompatibilitätsbedingung
Vereinbarung von Kennzahlen, Indikatoren, Messverfahren etc.
Probleme: „gaming the system“, fehlende Indikatoren / Metriken für die
“Qualität” / den RoI des Projektergebnisses (Gewinn AG?)
Institutionen: gesetzliche Vorschriften, Haftungsregeln, etc.
Restriktionen und Vorgaben
Wiederholte Interaktion
Unabhängige Bewertung Æ Reputation
5
HSE 2006
8
4.
Leistungsvereinbarung und Haftung in der SW- und
System-Entwicklung: rechtliche Rahmenbedingungen
Dr. Nadja Kaeding ist Rechtsanwältin in der Kanzlei Graefe Rechtsanwälte in
München, wo sie im Rechtsbereich IT- und Medienrecht arbeitet. Frau Dr. Kaeding
verfasste zahlreiche Publikationen, v.a. zu Outsoucing-Verträgen, Lizenzrecht und
zum Themengebiet öffentliche Ausschreibungen.
HotSpots der Software-Entwicklung 2006
Vertragsmodelle und Haftung in der Software-Entwicklung
- Rechtliche Rahmenbedingungen -
Referentin: Dr. Nadja Kaeding, GRAEFE Rechtsanwälte
18.07.2006
HSE 2006
1
9
Software- und Softwareentwicklung
langwieriger Prozess, der faktische Abläufe IT-technisch
umsetzen muss
Vorstrukturierung
Ablaufpläne/Datenflusspläne
18.07.2006
2
Schutz von Software/Softwareentwicklung
Urheberrechtsschutz
Patentschutz?
18.07.2006
HSE 2006
3
10
Patentschutz? I
Zwar sind auch "Computerprogramme„ in Art. 52 (2) aufgeführt, hat der beanspruchte Gegenstand
jedoch technischen Charakter, so ist er durch Art. 52 (2) und (3) nicht von der Patentierbarkeit
ausgeschlossen. Ein von einem Computerprogramm gesteuerter Datenverarbeitungsprozess kann
theoretisch aber auch mittels spezieller Schaltkreise durchgeführt werden, und die Ausführung eines
Programms umfasst immer physikalische Wirkungen, z. B. elektrische Ströme. Nach T 1173/97 sind
solche normalen physikalischen Wirkungen alleine noch nicht ausreichend, um einem
Computerprogramm technischen Charakter zu verleihen. Kann ein Computerprogramm beim Betrieb auf
einem Computer aber eine weitere technische Wirkung hervorbringen, die über diese normalen
physikalischen Wirkungen hinausgeht, so ist es nicht von der Patentierbarkeit ausgeschlossen, und zwar
unabhängig davon, ob es allein oder als Aufzeichnung auf einem Datenträgerbeansprucht wird.
Weist eine beanspruchte Erfindung nicht prima facie technischen Charakter auf, so ist sie entsprechend
Art. 52 (2) und (3) zurückzuweisen. In der Praxis ist es für den Prüfer bei der Prüfung
computerimplementierter Erfindungen aber unter Umständen zweckmäßiger, direkt die Frage der
Neuheit und der erfinderischen Tätigkeit abzuklären, ohne zuvor auf den technischen Charakter
einzugehen. Zur Beurteilung, ob eine erfinderische Tätigkeit vorliegt, muss der Prüfer eine objektive
technische Aufgabe bestimmen, die gelöst wurde (siehe IV, 9.8.2). Die Lösung dieser Aufgabe ist der
technische Beitrag der Erfindung zum Stand der Technik. Das Vorliegen eines solchen technischen
Beitrags bedeutet, dass der beanspruchte Gegenstand technischen Charakter hat und damit tatsächlich
eine Erfindung im Sinne von Art. 52 (1) ist. Wird eine solche objektive technische Aufgabe nicht
gefunden, so weist der beanspruchte Gegenstand zumindest keine erfinderische Tätigkeit auf, weil kein
technischer Beitrag zum Stand der Technik geleistet werden kann, und der Anspruch ist aus diesem
Grund zurückzuweisen. (Richtlinien des EPA)
18.07.2006
4
Patentschutz? II
EPA 31.05.1994, Az.: T 769/92 - 3.5.1 - universelles Verwaltungsprogramm/ SOHEI - Leitsatz 1
Eine Erfindung, die durch Software (Computerprogramme) realisierte funktionale Merkmale umfasst, fällt
nicht unter das Patentierungsverbot gemäß Art 52 Abs. 2 c) und Abs. 3 EPÜ, wenn die
erfindungsgemäße Lösung der Aufgabe in ihren Einzelheiten technische Überlegungen erforderlich
macht, damit die Erfindung ausgeführt werden kann.
Solche technischen Überlegungen verleihen der Erfindung insofern technischen Charakter, als sie eine
technische Aufgabe implizieren, die durch (implizite) technische Merkmale zu lösen ist. Eine Erfindung
dieser Art bezieht sich nicht auf ein Computerprogramm als solches im Sinne des Art 52 Abs. 2 c) und
Abs. 3 EPÜ.
18.07.2006
HSE 2006
5
11
Software als Gegenstand des Urheberrechts I
BGH „Inkassoprogramm“ 1985
EU –RL 1991
Umsetzung §§ 69 a dUrhG
Mit der Umsetzung der EU-RL ist ein Computerprogramm auch dann geschützt, wenn
eine Schöpfung anderer Werksgattung bei gleicher Schutzhöhe nicht schutzfähig wäre
Achtung: teilweise wird Schöpfungshöhe eines Computerprogramms nicht mehr geprüft
- eigener Leistungsschutz
18.07.2006
6
Software als Gegenstand des Urheberrechts II
Geschützt ist Software in jede Ausgestaltung
Kein Schutz für Materialien, die Software begleiten diese aber nicht
selbst verkörpern.
Materialien können aufgrund eigener Schöpfungshöhe
Urheberschutz genießen.
Materialien können außerhalb des Urheberrechts wettbewerblichen
Leistungsschutz beanspruchen.
Gilt auch für Bildschirmmasken
18.07.2006
HSE 2006
7
12
Erwerb des Urheberrechts
Durch Schaffung der Software
Wer persönliche geistige Schöpfungsleistung erbringt, ist
Miturheber.
Problem:
Freie Mitarbeiter eines Softwareentwicklungsunternehmens
18.07.2006
8
Kollision Eigentumsrecht -Urheberschutz
Grundsätzlich: Erschöpfungsgrundsatz §17III UrhG und § 69c Nr.3
S. 2 UrhG
Konkretisierung: §§ 69a ff UrhG
– Definition immer gestatteter Nutzung
– Gestattet sind immer solche Nutzungshandlungen, die zur
bestimmungsgemäßen Benutzung erforderlich sind.
– Erwerb einer Software durch Übereignung des Datenträgers
- vgl. BGH „Holzhandelsprogramm“
18.07.2006
HSE 2006
9
13
Erstellung von Software für einen Dritten I
Vertragstypologische Einordnung
Werkvertrag/ Werklieferungsvertrag
Vertrag immer wie Werkvertrag formulieren
18.07.2006
11
Erstellung von Software für einen Dritten II
Erstellung des Pflichtenheftes
eigener vorgeschalteter Vertrag
Ermöglichung privater Ausschreibung
Pflichtenhefterstellung
gemeinsam zu erbringender Leistung
Erstellung der Software
Leistung des Softwareherstellers
Pflichtenheft bestimmt Sollzustand der Software
18.07.2006
HSE 2006
12
14
Erstellung von Software für einen Dritten III
Testphase
– Prüfung der Software auf Maßgaben des Pflichtenheftes
– Testumgebung /Echtzeittests
– Testdaten durch den Auftraggeber, ggflls. unter Einschaltung
von Beratern
– Ausschlußkonzept möglich
18.07.2006
13
Quellcode -Hinterlegung
Vereinbarung, daß und was hinterlegt wird und wer hinterlegt im
Rahmen des Vertrages zwischen Lizenzgeber und Lizenznehmer.
Vereinbarung über die Hinterlegung selbst mit dem
Treuhänder/Hinterleger
18.07.2006
HSE 2006
14
15
Gewährleistung bei Lizenzierung I
Mängelgewähr
bei Fehlen von eigenen Regelungen : Regelungen des Gesetzes
Fehler im Sinne des Gesetzes: jede Abweichung des Ist-Zustandes
vom Soll-Zustandes (Vereinbarung)
18.07.2006
15
Gewährleistung bei Lizenzierung II
Fehlermöglichkeiten bei Software
– Planungsfehler
– Konstruktionsfehler
Fehler in der Sphäre
Lizenzgeber
– Programmierfehler
– Testen
– Bedienfehler
18.07.2006
HSE 2006
Fehler in der Sphäre
Lizenznehmer
16
16
Gewährleistung bei Lizenzierung III
Fehler aus Sicht des Lizenznehmers
– fehlende (von Lizenznehmers vorausgesagte) Funktionen und
Funktionalitäten
– fehlende Performance
– fehlerhafte Ergebnisse
– unzureichende Bedienbarkeit
– unzureichende fehlende Kompatibilität
18.07.2006
17
Gewährleistung bei Lizenzierung IV
Typische Klausel
Der Kunde ist sich bewußt, daß Software nicht fehlerfrei ist.
18.07.2006
HSE 2006
18
17
Gewährleistung bei Lizenzierung V
Folgen dieser Klausel
– zu Lasten der Lizenzgeber
– Vertragliche Regelungen im BGB
Regelung führt im deutschen Recht zu Nichterfüllung, §§ 433, 633 BGB
18.07.2006
19
Gewährleistung bei Lizenzierung VI
mögliche oder tatsächliche Fehler vermindern durch eindeutige
vertragliche Regelung
Erfassen und Ausschließen der Erwartungen des Lizenznehmers
durch vertragliche Regelung
wird Software neu eingeführt, gegebenenfalls Pilotbetrieb
vereinbaren. (verringerte Vergütung; verstärkte Mitwirkung)
Problem: Patches
18.07.2006
HSE 2006
20
18
Haftung für Rechtsverletzung
Freistellung
Gewissheit über Rechtekette
Schadensersatz
18.07.2006
21
Zusammenfassung
maßgeblicher Schutz der Software durch das Urheberrechtsgesetz
Absicherung durch Verträge erforderlich
Keine Hemmung vor eindeutiger Interessenformulierung
18.07.2006
HSE 2006
22
19
GRAEFE Rechtsanwälte
Theresienstrasse 6, 80333 München
www.graefe-portal.de
18.07.2006
HSE 2006
23
20
5.
Einkauf von IT-Dienstleistungen bei der Münchener
Rück
Norbert Schmelz ist Leiter IT-Beschaffung im Zentralbereich Informatik der
Münchener Rückversicherungsgesellschaft.
Der Einkauf von IT-Dienstleistungen in der
Münchener Rück
Norbert Schmelz, Leiter IT-Beschaffung
05.07.2006
HSE 2006
21
Agenda
Der Einkauf von IT-Dienstleistungen bei der Münchener Rück
Überblick
Strategie
Lieferantenbewertung
Vertragskonstrukte und -gestaltung
Ausblick
18.07.2006
2
18.07.2006
3
Überblick
HSE 2006
22
Münchener-Rück-Gruppe
Diversifizierte Struktur – diversifiziertes Risiko
Rückversicherung
Erstversicherung
Assetmanagement
18.07.2006
4
Unternehmenskennzahlen
2005
in Mio. €
Konzernergebnis1)
Gebuchte
Bruttobeiträge
SchadenKostenQuote in %
1.397
22.358
110,53)
Schaden/Unfall
420
14.547
Leben/Gesundheit
976
7.811
Erstversicherung
1.179
17.572
Schaden/Unfall
585
5.242
Leben/Gesundheit
594
12.330
Rückversicherung
Assetmanagement
31
Konsolidierung
Gesamt
4)
Konzernergebnis2)
1.666
1.234
11,3
93,14)
432
317
292
14,7
25
–45
–1.731
–51
2.751
38.199
1.887
72
Angepasst aufgrund Erstanwendung IAS 19 (rev. 2004).
Angepasst aufgrund Erstanwendung IAS 1 (rev. 2003).
Nicht-Leben
Schaden/Unfall inkl. Rechtsschutz
HSE 2006
Emb.-ValueRendite
in %
144
davon auf Minderheitsanteile entfallend
1)
2)
3)
2004
54
18.07.2006
5
23
Rückversicherung
Präsent auf allen Märkten

Atlanta
Boston
Chicago
Columbus
Dallas
Hartford
Kansas City
Los Angeles
Montreal
New York
Philadelphia
Princeton
San Francisco
Seattle
Toronto
Vancouver
Waltham

München
Athen
Genf
London
Madrid
Mailand
Moskau
Paris
Warschau

Bogotá
Buenos Aires
Caracas
Mexiko
Santiago de Chile
São Paulo
Accra
Durban
Harare
Johannesburg
Kapstadt
Nairobi
Port Louis

Hongkong
Kalkutta
Kuala Lumpur
Mumbai
Peking
Schanghai
Seoul
Singapur
Taipeh
Tokio
Auckland
Brisbane
Melbourne
Perth
Sydney
18.07.2006
6
Münchener Rück – die Geschichte
Auf Initiative von
Carl von Thieme,
Freiherr Theodor
von Cramer-Klett
und Wilhelm Finck
wird am 19.4.1880
die Münchener Rück
gegründet.
Erster großer
Schadenfall im 20.
Jahrhundert:
Das Erdbeben in San
Francisco am
18.4.1906.
MR-Haftung:
2,5 Mio. US$ =
11 Mio. Mark.
Die Münchener Rück
beschäftigt 511
Mitarbeiter und hat
ein Prämienvolumen
von 737 Mio. DM.
Schnelle Schadenregulierung durch
MR vor Ort:
Die MR zahlt insgesamt 150 Mio. DM.
„Thieme is money“
1880
1906
HSE 2006
Größter
Blechschaden in der
Versicherungsgeschichte:
Am 12.7.1984 fallen
in München golfballgroße Hagelkörner
vom Himmel. Jedes
zweite Auto in
München (=240.000)
wird beschädigt.
1960
1984
Die Münchener Rück
berät über 5.000
Kunden in 150
Ländern und hat
weltweit über 50
Außenstellen.
Im EV-Geschäft
betreut die MR über
die ERGO-Gruppe
über 31 Mio. Kunden.
Das Vermögen der
MR-Gruppe wird von
der MEAG verwaltet.
2004
18.07.2006
7
24
Der Einkauf IT-Dienstleistungen ist organisatorisch im ZB
Informatik dem Referat IT-Beschaffung zugeordnet.
Aufbauorganisation des Referates IT 1.9.3 – IT-Beschaffung
CIO
CIO
ZB
ZB Informatik
Informatik
IT-Stab
IT-Stab
Infrastruktur
IT-Beschaffung
IT-Beschaffung
Juristische
Beratung
Einkauf
Einkauf
IT-Produkte
IT-Produkte
strategischer
strategischer
Einkauf
Einkauf
operativer
operativer
Einkauf
Einkauf
Einkauf
Einkauf
IT-Dienstleistungen
IT-Dienstleistungen
strategischer
strategischer
Einkauf
Einkauf
Anwendungsentwicklung
Qualitätsmanagement
Qualitätsmanagement
und
und weitere
weitere Services
Services
Controlling
Controlling
…
Schulung
Schulung
BeschaffungsBeschaffungslogistik
logistik
operativer
operativer
Einkauf
Einkauf
18.07.2006
8
Der Einkauf IT-Dienstleistungen beschafft entsprechend der ITStrategie des ZB Informatik ein breites Technologieportfolio.
Warum werden IT-Dienstleistungen beschafft?
Welche IT-Dienstleistungen werden beschafft?
Flexible Ressourcenplanung
Temporärer Know-how Zukauf
IT-Beratung
Softwareentwicklung
Outtasking
Systemadministration
Wartungsleistungen
Netzwerk- / Server-Betriebsleistungen
Desktop Services
Helpdesk
etc.
HSE 2006
18.07.2006
9
25
Überblick über den Beschaffungsprozess des Einkaufs ITDienstleistungen der MR:
Wie werden IT-Dienstleistungen beschafft?
IT-Einkauf
Preise jährlich neu
verhandeln
Lieferantenbeurteilung
auswerten
IT-Einkauf führt Jahrespreisverhandlungen mit
Lieferanten durch. Für Anforderungen führte er
umfangreiche fachspezifische und juristische
Beratungen durch.
Crossfunktionales
Team
IT-Anforderer
Rahmenvertrag
verifizieren
Leistungsbeschreibung
verifizieren
IT-Dienstleistungen
anfordern
Lieferantenportfolio
aktiv managen
Lieferanten
entwickeln und
ausphasen
Vertrag
erstellen
Bestellung
auslösen
Preise zu Leistungen
zuordnen
(Skillkategorien)
Ausschreibung
durchführen
Nachverhandlung
durchführen
Ggfls. juristisch
beraten
Bedarf / Leistung
spezifizieren
IT-Anforder hat komplexe IT-Anforderung die zusammen mit dem IT-Einkauf in enger
Interaktion als crossfunktionales Team bearbeitet wird.
18.07.2006
10
18.07.2006
11
Strategie
Aktives Lieferantenmanagement
HSE 2006
26
Die theoretisch preisgünstige Alternative für den Zukauf
externer Ressourcen bei Softwareentwicklungsprojekten
sind die Internetportale für Freiberufler.
Entwicklung der Stundensätze von Freiberuflern (Marktdurchschnitt)
74,00 €
72,50 €
72,00 €
70,50 €
70,00 €
68,00 €
66,00 €
66,00 €
65,00 €
64,50 €
2004
2005
64,00 €
62,00 €
60,00 €
2002
2003
1. HJ. 2006
18.07.2006
Quelle: www.gulp.de
12
Hingegen sind die Stundensätze der renommierten größeren
IT-Dienstleister bzw. Systemhäuser wesentlich höher,
abhängig von der jeweiligen Branche .
Aktuelle durchschnittliche Stundensätze für IT-Dienstleistungen nach Branchen
120 €
100 €
100 €
85 €
90 €
100 €
90 €
99 €
82 €
80 €
80 €
95 €
60 €
40 €
20 €
HSE 2006
Quelle: Eigene Recherche
Others
Training
Public
Sector
Industry
Health
Care
TK
IT
Banking /
Insurance
Automotiv
0€
18.07.2006
13
27
Die MR hat sich bewusst für das Sourcing bei renommierten
größeren IT-Dienstleistern bzw. Systemhäusern entschieden.
Vor- / Nachteile von Freiberuflern und IT-Dienstleistern bzw. Systemhäusern
Freiberufler
IT-Dienstleister / Systemhäuser
kostengünstig
flexibel und einfach im Umgang
teilweise hoher Spezialisierungsgrad
schnelle Verfügbarkeit am Markt
Akzeptanz der AGB‘s der MR
hohe Versorgungssicherheit
Beschaffungshebel durch langfristige
Partnerschaft
Gesicherter Service und Qualität
Breites Kompetenzspektrum
Projektstaffing möglich
Fachexpertise für Rückversicherung
Lieferantenentwicklung nicht möglich
hohes AÜG-Risiko
Aufbau wechselseitiger Abhängigkeit
keine Redundanz bei Ausfall
Verliert Mehrwert bei Dauertätigkeit
höherer Preis als Freiberufler
teilweise schwierige Verhandlungen
18.07.2006
14
Die IT-Dienstleister bzw. Systemhäuser werden bei der MR in
ein Lieferantenportfolio, bestehend aus vier Kategorien,
eingeordnet.
Übersicht über die Definition der einzelnen Quadranten des Lieferantenportfolios
Stratege
Grosses Leistungs- und Personalportfolio
Tiefe MR-Fachkenntnisse
Ist präferierter Partner bei Ausschreibungen
und der Vergabe von Outtasking
Vorzugslieferant
Eingeschränktes Leistungs- und
Personalportfolio
Hat Nachweispflicht, dass erkannte Defizite
erfolgreich bearbeitet werden
Hat nur eingeschränkten Zugang zu
Ausschreibungen und der Vergabe von
Outtasking
HSE 2006
Speziallieferant
Nur eingeschränktes MR-konformes
Leistungsportfolio
Arbeiten in speziellen Nischen
Beteiligung an Ausschreibungen eher selten
Sonstige Lieferanten
Sonstige Lieferanten unterteilen sich in:
- Neueinsteiger,
- Wiedereinsteiger und
- Ausphasungskandidat
Eine erfolgreiche Lieferantenentwicklung führt
zu neuem Status im Lieferantenportfolio
18.07.2006
15
28
Mit ausgewählten IT-Dienstleistern aus dem Lieferantenportfolio
werden die Preise anhand der standardisierter Skills in den MRKategorien 0 bis 4 in einem jährlichen Turnus verhandelt.
Skilleinordnung anhand der MR-Kategorien
MRKategorie
Tätigkeiten
0
Junior-Programmierer
Junior-Entwickler
Projektassistenz
1
Programmierer
Entwickler
Systembetreuer
Benutzerservice
Netzwerktechniker
2
Senior-Programmierer
Senior-Entwickler
Systemengineer
Datenbankspezialist
Systemmanager
Systemarchitekt
Netzwerktechniker
Berater
Teilprojektleitung
Qualitätssicherer
3
Senior Berater
Datawarehousespezialist
Senior Systemarchitekt
Netzwerkberatung
Projektleitung
Qualitätsmanager
Individuelle Verhandlung
4
•
•
•
•
•
•
•
•
Durchführung von komplexen Programmieraufgaben auf Basis eines
Fachkonzepts (auch bei ERP-Systemen)
Analyse und Design von Datenmodellen und Softwarespezifikationen
Erstellung von Fachkonzepten mit qualifizierter Beratung
Erstellung von Testkonzepten mit qualifizierter Beratung
Konzepterstellung für den Einsatz von individuellen
branchenspezifischen Lösungen
Durchführung von Softwareimplementierungen
Konzeption und Durchführung von Softwareteststellungen
Weiterbearbeitung von Fällen aus dem 1st- und 2nd-level-Support bzw.
Bearbeitung von „trouble tickets“ inkl. Fehleranalyse und –behebung
anhand des Source Codes
18.07.2006
16
Die Steuerung des Lieferantenportfolios und das
Berichtswesen an das Management erfolgt quartalsweise
anhand eines standardisierten Managementcockpits.
Beispielgrafiken und Kennzahlen aus dem Management-Cockpit
Beschaffungsvolumen gem. Lieferantenportfolio
Bestellvolumen pro Gruppe
12%
7%
16%
n
N
eb
en
ko
st
e
pr
e
is
4
st
Fe
3
G
ru
pp
e
2
G
ru
pp
e
1
G
ru
pp
e
G
ru
pp
e
G
ru
pp
e
0
65%
Strategen
HSE 2006
Vorzugslieferanten
Speziallieferanten
Sonstige Lieferanten
18.07.2006
17
29
18.07.2006
18
Die Lieferantenbewertung ist bei der MR ein wichtiger
Baustein für die Erstellung des Lieferantenportfolios.
Kriterien und Prozess der Lieferantenbewertung in der MR
Kriterien für die Lieferantenbewertung
Kundenorientierung
Projektabwicklung
Problemverhalten
Kontrollverhalten
Preis- / Leistungsverhältnis
Fachliche Leistung der externen Mitarbeiter im Projekt
• Die Lieferantenbewertung erfolgt durch die IT-Projektleiter zum Vertragsende.
• Zusätzlich werden die Lieferanten auch durch den IT-Einkauf bewertet.
• Das Gesamtergebnis der Lieferantenbewertung und das Ergebnis der
Jahrespreisverhandlung sind relevant zur Eingruppierung der Lieferanten in das
Lieferantenportfolio.
HSE 2006
18.07.2006
19
30
Ausschnitt aus der Eingabemaske zur Lieferantenbewertung
von IT-Dienstleistern bzw. Systemhäusern.
Vertragsnummer:
Bitte tragen Sie den Namen
Ihres Projektes ein
Projektname:
Innenauftragsnummer:
Externer Partner:
Projektbeginn:
Projektende:
Kriterium
Kundenorientierung
Projektabwicklung
Problemverhalten
Kontrollverhalten
Preis-/Leistungsverhältnis
Zwischenbewertung
Projekt
Gew.
Faktor
150
125
100
75
50
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
1
0
0
0
0
0
1
Bitte tragen Sie in der entsprechenden Zelle
für die Bewertung eine "1" anstatt der "0" ein.
Falsch ausgefüllte Bewertungszeilen werden
mit einer Fehlermeldung angezeigt!
weitgehend nicht erfüllt
mit Einschränkungen erfüllt
voll erfüllt
übertroffen
deutlich und
dauerhaft übertroffen
Ansprechpartner MR:
Anmerkungen für
projektbezogene Stärken
und Schwächen:
Bitte tragen Sie in den
entsprechenden Zellen
Kommentare zu Ihren
Bewertungen ein.
FALSCHE WERTE
FALSCHE WERTE
FALSCHE WERTE
FALSCHE WERTE
FALSCHE WERTE
0
18.07.2006
20
18.07.2006
21
Vertragskonstrukte und -gestaltung
Beauftragung von IT-Dienstleistern und zugehörige Vertragsdokumente
HSE 2006
31
Grundlage zur Beauftragung eines IT-Dienstleisters /
Systemhauses ist bei der MR die vom IT-Projektleiter erstellte
Vertragsleistungsbeschreibung.
Standardisiertes Inhaltsverzeichnis für Vertragsleistungsbeschreibungen in der MR

Kurzdarstellung des Projektes
qualitativ

Leistungsumfang des Auftragnehmers
hochwertige

Aufgaben des Auftragnehmers im Projekt
Leistungs-

Vorgehen und Meilensteinplan
beschreibung

Zu erbringende Ergebnisse des Auftragnehmers

Maßnahmen zur Qualitätssicherung
Lieferanten mit in

Abnahmekriterien für die zu erbringenden Ergebnisse
die Projekt-

Vom Auftragnehmer einzuhaltende Richtlinien /
Rahmenbedingungen

Sondervereinbarungen
Durch eine
besteht die
Möglichkeit, die
verantwortung
einzubinden.
18.07.2006
22
18.07.2006
23
Abhängig von der Art der Vertragsgestaltung werden ITDienstleister bzw. Systemhäuser mehr oder weniger in die
Projektverantwortung eingebunden.
1
Einzelvertrag nach Aufwand
• Vergütung nach Aufwand
• auf Basis von Stunden oder Tagen
• ein direkter Erfolg des Lieferanten wird nur für autarke Aktivitäten geschuldet
• Risiko verbleibt bei der MR, zumeist keine Service Level / Pönalen
2
Einzelvertrag zum Festpreis
• Vergütung zum Festpreis
• auf Basis von Ergebnissen, Abnahmekriterien und Meilensteinen
• ein direkter Erfolg des Lieferanten wird für die Gesamtleistung geschuldet
• Risiko trägt der Lieferant, Vereinbarung von Service Level / Pönalen möglich
3
Projektvertrag für Großprojekte
• Projektvertrag legt die rechtlichen Grundlagen, Konditionen und Preise
für die Zusammenarbeit mit dem Lieferanten für ein definiertes Großprojekt fest
• Definition von Verantwortungskreisen anhand definierter Rollen
3
MR-Standard-Rahmenvertrag
• Rahmenvertrag legt die rechtlichen Grundlagen für die Zusammenarbeit
mit dem Lieferanten fest
• Konditionen und Preise werden meist jährlich separat verhandelt
• Wird in der Regel nur mit Strategen und Vorzugslieferanten vereinbart
HSE 2006
32
Folgende grundsätzlichen rechtlichen Themenstellungen
sind in den Standard-Rahmenverträgen geregelt:
Grundsätzliche Themenstellungen von Standard-Rahmenverträgen
1
Geltungsbereich / Vertragsgegenstand / Durchführung / Zusammenarbeit
2
Vergütung / Kosten des Auftraggebers / Leistungsänderungen /
Behinderung des Auftragnehmers
Lieferanten die nicht den
Status Stratege oder
Vorzugslieferant haben,
werden auf Basis der
3
Rechte / Erfindungen / Eigentum
AGB‘s der MR
beauftragt, die inhaltlich
Werkvertragliche Leistungen / Dienstvertragliche Leistungen /
Software Hinterlegung / Abnahme / Haftung / Verzug
4
zum StandardRahmenvertrag identisch
5
Geheimhaltung / Datenschutz und –sicherheit / Verpflichtung Personal
6
Herausgabe Material / Aufrechnung / Zurückbehaltungsrecht
sind.
Konditionen und Preise
werden jährlich separat
verhandelt.
7
…
Laufzeit / Kündigung / Schlussbestimmung
/ Sonstiges
18.07.2006
24
18.07.2006
25
Ausblick
Die Herausforderungen für die Zukunft
HSE 2006
33
Themen für die Zukunft:
Festlegung Fertigungstiefe / Sourcing
Definieren der Stufe für die Eigenfertigung und dem Fremdbezug
in Form von Zukauf externer IT-Dienstleistungen auf Basis
strategischer Bedeutung und Komplexität des Projektes
Managed Services statt Beauftragung nach Aufwand
Leistungen als abgeschlossene Arbeitspakete definieren und zu
einem Festpreis im Rahmen einer Ausschreibung vergeben
Nearshoring / Offshoring
Prüfen und Bewerten der Möglichkeiten der Softwareentwicklung
in Ländern mit einem niedrigen Lohnniveau
HSE 2006
18.07.2006
26
34
6.
IT-Beschaffung in der BMW AG
Reinhold Noppe ist Leiter des technischen Einkaufs bei der BMW AG. Herr Noppe ist
an der Entwicklung des Programms Join BMW IT beteiligt, mit dem Lieferanten
qualifiziert und zertifiziert werden.
Join BMW IT
PZ-T-1
18.07.2006
Seite 1
HSE 2006
Join BMW IT.
Basisqualifizierung.
35
Join BMW IT
PZ-T-1
18.07.2006
Seite 2
Join BMW IT
PZ-T-1
18.07.2006
Seite 3
HSE 2006
Grundlagen der IT Beschaffung in der BMW AG
Inhaltsübersicht
1
Struktur und Ausrichtung der IT Beschaffung
2
Organisatorische und operative Ausgestaltung der Beschaffung
IT Sourcing.
Rolle der IT bei BMW.
36
Join BMW IT
PZ-T-1
18.07.2006
Seite 4
IT Sourcing.
Besonderheiten der IT Beschaffung.
Besonderheiten der IT Beschaffung
Lieferantenstruktur
Ca. 1250 IT Lieferanten
Sehr dynamischer
Beschaffungsmarkt
Breites Lieferantenspektrum
(Freelancer bis hin zu global
Playern)
Von extremen Wettbewerb bis hin
zu de facto Monopolisten
Commodity Struktur
Breites Warengruppenspektrum von
Standard Produkten bis zu hoch
spezialisierten Individuallösungen
Die Komplexität der Gewerke ist bei
Vergabe nicht immer exakt abschätzbar
Kundenstruktur
Breite Kundenstruktur aus der
gesamten IT Community
(ca. 2500 Mitarbeiter)
Join BMW IT
PZ-T-1
18.07.2006
Seite 5
IT Sourcing.
Fokusthemen der IT Beschaffung.
Strategische Ausrichtung der Beschaffung
Sourcing Strategien
Portfoliomanagement
Ausbau Internationalisierung
Leistungsorientierte
Lieferantenmanagement
Wir erwirken nachhaltig das
bestmögliche Verhältnis von
Leistung zu Gesamtkosten.
Durchgehender, IT gestützter Beschaffungsprozess
Methoden- und Toolunterstützung entlang der Beschaffungskette
Operative Prozessunterstützung
HSE 2006
37
Join BMW IT
PZ-T-1
18.07.2006
Seite 6
IT Sourcing.
Kompetenzfeldmatrix.
Die „ Kompetenzfeldmatrix“ ist in allen relevanten Einkaufssystemen implementiert
und ist die Basis für ein differenziertes Portfoliomanagement.
Geometriemethoden & - systeme
CAE/CAT
Prozess / Ressort
Prod.technische Integration
Elektrik/Elektronik
E - Entwicklung
PEP PDM
Collaborative Engineering
T - Produktion
Fahrzeugmanagementsysteme
V - Vertrieb
Einkaufsprozessunterstützung &
systeme
SF – Sparte Finanzdienstleistung
F - Finanzen
P - Personal
FZ – Zentrale IT
Individual
SW
Entwicklung
IT Beratung
Join BMW IT
PZ-T-1
18.07.2006
Seite 7
Anw endungsbetrieb
Hardw are &
Infrastruktur
Leistungsart
IT Sourcing.
Sourcing Prozessmodell.
IT Strategie
FZ-10
IT Beschaffungsplanung
IT Ressourcensteuerung
TE-5-S
IT Planung
Eigenleistungssteuerung
TE-5x
Skill
Management
Lieferanten
Assessment
Entwicklungsmaßnahmen
Phase2
Fachkonzept
Phase 3
IT
Konzept
Phase 4
Implem., Test
und Integr.
Steuerung Beschaffungsplanung
Bedarfsplanung
Beschaffungsportfolio
RIT 1
FZ-x1
TE-5x1
Ein-, Ausphasung
Phase 5
Installation
u. Abnahme
Analyse der
Lieferanten
Ranking
Lieferanten
AusschreibungsIT Beschaffung
unterlagen
planen und Einkaufserstellen
meth. festlegen
Umsetzungsplanung
Lieferanten Management
Projekthaftes Lieferanten Management
nach Partnerschaftsmodell
TE-5x
IT Projektabwicklung
Phase 1
Grobkonzept
Initialisierung
Sourcing
Team
Sourcingprogramm
Lieferanten Entwicklung
Lieferantendatenbank
Phase 0
Projektauftrag
Standard
SW
Lizenzen
Relationship
Management
IT Einkauf
…
Bestellung
Vertragsdurchführung
Lieferant
bewerten
Prozesstreiber
1 ) Themenspezifisch
HSE 2006
38
Join BMW IT
PZ-T-1
18.07.2006
Seite 8
Teilprozess Leistungssteuerung.
Input
Handlungsbedarfe
• Eigenleistungsstrategie
Nutzenpotentiale
• Verbesserte Verhandlungsposition durch gezielten Aufbau
von Wettbewerb
Strategisches Sourcing
• Abhängigkeits- oder M onopolsituation
• IT Strategie
• Neue Technologien oder Leistungen
• FZ/RIT-Planung
• Erweiterung der Lieferantenportfolios mit innovativen
Dienstleistern
• Potential innovatives Sourcingmodell
• Einkaufsanforderungen
Sourcingprogramm
• Ressortübergreifende Strukturmaßnahme
(Bündelung, Standardisierung)
• Reduzierung von Risiken durch
aktive Lieferantensteuerung
• Skalen- und Verbundeffekte
Operatives Sourcing
• Höhere Effizienz im Prozess
• Potenzial Volumenbündelung
• Höhere Qualität der
Leistungserbringung durch
Konzentration auf best-fit
Lieferanten
• Optimierungsbedarf in der Lieferantenstruktur
• Skaleneffekte
Join BMW IT
PZ-T-1
18.07.2006
Seite 9
Teilprozess IT Beschaffungsplanung.
Teamorientierter Ansatz zur Erarbeitung von Sourcingstrategien
1
Vereinbarung
Arbeitsauftrag
2
Beschreibung
Kompetenzfelder
3
Ermittlung
Gesamtbedarf
4
Positionierung im
Kompetenzfeldportfolio
Dokumentation
IT Bedarfsportfolio
Analyse u.
Assessment der
Lieferanten
Power to Execute
5
6
Festlegung der
Vergabestrategie
und Umsetzungsplanung
2
1
7
Abnahme und
Review der
Strategie
8
Review der
Umsetzung der
Strategie
3
Completeness of Vision
HSE 2006
39
Join BMW IT
PZ-T-1
18.07.2006
Seite 10
Teilprozess Lieferantenentwicklung.
1
Bewerber-/ LieferantenDatenbank
2
- Datenpflege durch
Lieferanten selbst über
Lieferantenportal
- Gezielte Assessments
des Unternehmens
- Kontinuierliche
Bewertung der
Leistungserbringung des
Lieferanten
- Basis für Bedarfsrecherchen der IT
Community und des
IT Einkaufs
Join BMW IT
PZ-T-1
18.07.2006
Seite 11
Lieferantenpositionierung
- Positionierung im
Lieferantenportfolio
3
Entwicklungsmaßnahmen
- BMW IT Zertifizierung
der Mitarbeiter in
Projekten
- Verbindliche Vereinbarung von Qualitätsund Leistungszielen auf
Basis regelmäßiger
Leistungsbewertungen
Lieferantenbewertung.
Preis / Leistungsverhältnis
Qualität der
Zusammenarbeit
2,0
1.4
2.5
Projektorganisation
2.1
3.0
Kompetenz
Eine systematische Bewertung
der Leistungserbringung durch
Lieferanten ist unabdingbare
Voraussetzung für eine
qualitätsgesteuerte Optimierung
des Lieferantenportfolios.
Qualität der
Leistung
Ziele
- Transparenz der Schwachstellen durch differenziertes Feedback
- Vereinbarung von gezielten Maßnahmen, kontinuierliche Entwicklung
- Die Objektivierung und Optimierung der Lieferantenauswahl
HSE 2006
40
Join BMW IT
PZ-T-1
18.07.2006
Seite 12
Ziele des Lieferantenmanagements.
Ziele des Lieferantenmanagements
Join BMW IT
PZ-T-1
18.07.2006
Seite 13
1
Strategische Positionierung des
Lieferanten durch Konzentration auf
seine Kernkompetenzen.
2
Nachhaltige Verbesserung der
Qualität durch Vereinbarung und
Umsetzung von gezielten
Entwicklungsmaßnahmen.
3
Stärkung der partnerschaftlichen
Zusammenarbeit und Beherrschung
von Risiken und Abhängigkeiten
durch ressortübergreifende
Steuerung des Partners.
4
Aufzeigen und Nutzen der Innovationspotenziale des Lieferanten zur
Steigerung des Businessnutzens bei
BMW.
Aktive Lieferantensteuerung.
Nutzen für BM W:
Gesamthafte Interessenvertretung durch ressortübergreifende
Steuerung, vollständige Transparenz der Geschäftsbeziehungen,
Erkennen von Synergien und Bündelungschancen.
Sicherung von wettbewerbskritischem Know-How, gezielter Einsatz
von best practices, frühzeitige Einbindung in technologische Weiterentwicklungen und Innovationen
Erzielung von höherer Qualität und Prozesssicherheit in der Zusammenarbeit und im Beschaffungsablauf.
Nachhaltige Verbesserung der Leistungserbringung durch Zielvereinbarungen auf Top M anagementebene.
HSE 2006
41
Join BMW IT
PZ-T-1
18.07.2006
Seite 14
Aktive Lieferantensteuerung.
Nutzen für den Partner:
Optimale M itarbeiterpositionierung und –entwicklung durch
frühzeitigen Austausch, Aufbau von Kernteams in strategisch
wichtigen Themen.
Deutliche Verbesserung der Zusammenarbeit durch gegenseitigen
Vertrauensaufbau in langfristigen Strukturprojekten.
Chance der Geschäftsausweitung, Verbesserung der M arktposition
durch Partnerschaft mit BM W.
Join BMW IT
PZ-T-1
18.07.2006
Seite 15
HSE 2006
Grundlagen der IT Beschaffung in der BMW AG
Inhaltsübersicht
1
Struktur und Ausrichtung der IT Beschaffung
2
Organisatorische und operative Ausgestaltung der Beschaffung
42
Join BMW IT
PZ-T-1
18.07.2006
Seite 16
IT Sourcing.
Organisation des IT Einkaufs.
Vorstand der BMW AG
A
Vorstandsvorsitzender
H. Panke
E
Entwicklung
/ Einkauf
B. Göschel
F
Finanzen
S. Krause
P
Personal- u.
Sozialwesen
E. Baumann
EM
Materialeinkauf
K. Richter
Join BMW IT
PZ-T-1
18.07.2006
Seite 17
T
V
Produktion
Vertrieb
N. Reithofer
M. Ganal
TE
Technischer
Einkauf
H. Woebcken
IT Einkauf.
Organisation und Einkaufsumfänge.
TE
Technischer Einkauf
Hinrich Woebcken
TE-5
Informationstechnik
Friedrich Bruckmeyer
TE-50
TE-51
TE-52
TE-53
TO-M-1
Kalkulation
IT Beratung,
Software für
die Ressorts
E, T
IT Beratung,
Software für
die Ressorts
A, F, P, V
Hardware,
Infrastruktur u.
Services
Oxford, Hams
Hall,
Goodwood
Michael
Kormann
Edward
Bednarek
Reinhold
Noppe
Karl-Heinz
Herrmann
Tony Harris
TE-5-S
Steuerung IT Partnermanagement
Lothar Heggmair
HSE 2006
43
Join BMW IT
PZ-T-1
18.07.2006
Seite 18
IT Einkauf.
IT Beschaffung und Projektabwicklung.
Projektdurchführung nach ITPM
Phase 1:
Grobkonzept
IT Beschaffung
planen u.
Einkaufsmethod
ik festlegen
Phase 2:
Fachkonzept
Ausschreibungsunterlagen
erstellen
Lieferantenvorauswahl u.
Bieterkreis
Phase 4:
Implementierung,
Test u. Integration
Phase 3:
IT Konzept
Angebote
einholen
…
Vertragsdurchführung
Phase 5:
Installation u.
Abnahme
Lieferant
bewerten
IT Einkauf
IT Beratung /
IndividualEntwicklung
Standard
Software
HSE 2006
Allgemeine Vertragsbedingungen (AVB) für IT Projektleistungen
BMW AVBs zur Überlassung von
Standard-SW-Produkten
BMW AVBs für
SW-Pflege
44
7.
Lieferantenmanagement: Erfahrungen,
Anforderungen, Vorschläge aus Sicht eines
Lieferanten
Jürgen Lohrmann ist Bereichsleiter IT Service Management & Solutions bei der msg
systems ag.
.consulting .solutions .partnership
Lieferantenmanagement:
Erfahrungen, Anforderungen, Vorschläge
aus Sicht eines Lieferanten
Hot Spots der Software-Entwicklung 2006
Vertragsmodelle und Haftung in der Software-Entwicklung
TU München und VSEK, 5. Juli 2006
Jürgen Lohrmann, msg systems ag
IT Service Management & Solutions
A msg systems ag, J. Lohrmann: Lieferantenmanagement: Erfahrungen, Anforderungen, Vorschläge aus Sicht eines Lieferanten
HSE 2006
1
45
Agenda
1. Aktuelle Erfahrungen und Anforderungen
2. Welche Konsequenzen haben wir daraus gezogen?
3. Beispiele für innovative Vertragskonstrukte
4. Diskussion
2
Aktuelle Erfahrungen
Fallbeispiel: Implementierung einer Systemintegrations-Plattform
• Request for Proposal mit Fragenkatalog zu Unternehmensprofil, Referenzen,
Support und Service Vorschlag, Preisfindung, Voraussetzungen, Implementierung
• Ablieferung der Antworten über ein Angebots-Portal
• Ausführliche Präsentation im Rahmen eines zweistündigen Workshops
• E-Auktion zwischen drei im Rennen verbliebenen Anbietern anhand des Preises
Herausforderungen in diesem Auswahlprozess (ca. drei Wochen)
Unklare Ausgangssituation und fehlende Randbedingungen:
• Suche nach „strategischem Partner“
• Enorme Bandbreite von der Strategieentwicklung bis zur Umsetzung in konkreten
Integrationsprojekten
• Entsprechend großer Aufwand für die Spezifikation der anzubietenden Leistungen
Entscheidungskriterien für Anbieter nicht transparent:
• K.o.-Kriterium Branchen-Know-how
HSE 2006
3
46
Anforderungen an Lieferanten
Anforderungen aus Sicht des Anbieters in einem Neukunden-Szenario
• Extrem kurze Fristen im Auswahlprozess
• Fundierte Inhalte unter diffusen Randbedingungen
• Kundenspezifische Lösungen gefordert, bei unklarer Ausgangssituation
• Realistische Kostenschätzung
• Überzeugendes Staffing mit passenden Profilen für Mitarbeiter,
die im geplanten Projekt zur Verfügung stehen
4
Agenda
4. Diskussion
HSE 2006
5
47
Auftragsklärung als Projekt
Dynamisch – der zeitliche Ablauf
Phasen
Auftragsklärung
Ausarbeitung
Realisierung
Inbetriebnahme
Zeit
Teilprozesse
Anforderungsanalyse
Design
Implementierung
Test
Einführung
Projektmanagement
Konfigurationsmanagement
(mögliche) Iterationen
Iter. #1
Iter. #2
Iter. #n
Iter. #m
Meilensteine
6
Warum iterative Software-Entwicklung?
Software-Entwicklung
• ist komplex, risikoreich
• ist Individualfertigung, keine Massenproduktion
• hat hohe Änderungswahrscheinlichkeit und -raten
Iterative Software-Entwicklung
• beherrscht Komplexität und mindert Risiken
• erzeugt schnelles Feedback für die Benutzer
• erlaubt flexiblere Anpassung an Änderungen
HSE 2006
7
48
Was ist iterativ-inkrementelle Entwicklung?
Feedback aus Iteration N führt zu
Verfeinerung und Anpassungen
von Anforderungen und Design in
Iteration N+1
Umsetzung
einiger
Anforderungen
Eine Iteration (z.B.
4 Wochen)
Feedback
Umsetzung
einiger
Anforderungen
Feedback
Das System wächst
inkrementell
Umsetzung
einiger
Anforderungen
AUSLIEFERUNG
ZUM KUNDEN
8
Auftragsklärung: Beginn eines Projekts
HSE 2006
9
49
Auftragsklärung: Wichtigste Ergebnisse
• Aufwandsschätzung
• Risikobewertung (!)
• Grober Projektplan
• Leistungsumfang
10
Aktivitäten Auftragsklärung - Überblick
Präsentation
vorbereiten
Fachliche
Anforderungen
identifizieren
Angebotsmanagement
Nichtfachliche
Anforderungen
identifizieren
Angebot
prüfen
Preiskalkulation
Risiken
erfassen
Projekt
grob
planen
ProjektErgebnisse
festlegen
Aufwand
schätzen
HSE 2006
11
50
Agenda
4. Diskussion
12
Beispiele für innovative Vertragskonstrukte (1)
Iterative Vorgehensweise
Insbesondere bei unbekannten Kundenumfeldern, um in einer frühen Phase das
Zusammenspiel mit dem Kunden zu üben, etwa bei der Erstellung von Testfällen oder
bei der Durchführung von Installationen beim Kunden; Abkehr vom Wasserfallmodell,
um frühzeitig wesentliche Qualitätsaspekte in den SW-Entwicklungsprozess
einzubringen
Rahmenverträge mit Einzelaufträgen
Wesentliche Rahmenbedingungen wie Skillstufen-bezogene Aufwandskosten, Testund Abnahmeverfahren, Haftung, Verwertungsrechte etc. werden im Rahmenvertrag
geregelt. Die Einzelabrufe legen die Details für ein abgegrenztes Aufgabenpaket fest,
wie etwa den Leistungsumfang, Mitwirkungspflichten des Kunden, Projekt- und
Zahlungsplan.
Konsortialkonstrukte bei strategischen Projekten
Konsortialkonstrukte anstelle von Generalunternehmerschaften in Situationen, wo die
Sicherstellung des Projekterfolgs wichtiger ist als die Reduzierung des Kostenrisikos
HSE 2006
13
51
Beispiele für innovative Vertragskonstrukte (2)
Profit Share im Application Management
Anreiz für Effizienzsteigerungen im Application Management:
Vereinbarung eines Budgetrahmens (Sollwert zu Jahresbeginn),
Messung der erbrachten Leistungen (Istwert am Jahresende),
anteiliger Rückfluss der erzielten Einsparungen an den Auftraggeber
Separate Pilotierung und Bonus/Malus-Regelung bei technischer Migration
Pilotprojekt: Klärung der Vorgehensweise, Festlegung von Phasen und Paketen
Bonus/Malus-Regelung für „kritische“ Projektinhalte
(zu migrierende Assets, Änderungsdynamik während der Migration,
Termintreue bezüglich Frozen Zones)
14
Profit Share im Application Management (1)
System-Typ A
System-Typ B
bis 6 M onate nach
Produktivsetzung mit
Überprüfung und Festelegung
A und B
Standard
(System im
eingeschwungenen Zustand)
Festpreis
Festpreis
Time & Material
Festpreis („Profit Share“)
mit Leistungsmessung
Inbetriebnahmemanagement
Time & Material
(nach Absprache mit
dem Kunden)
Time & Material
(nach Absprache mit
dem Kunden)
Zusätzliche Services
(wie z.B. Auswertungen)
Time & Material
(nach Absprache mit
dem Kunden)
Time & Material
(nach Absprache mit
dem Kunden)
Produktionsüberwachung
Reporting, Steuerung, Rufbereitschaft
Incident Management (2nd & 3rd Level)
Problem Management
HSE 2006
15
52
Profit Share im Application Management (2)
Umsetzung Profit Share
Vorteile für den AG:
• Kein Risiko durch gedeckelten
Festpreis
• Detailliertes & transparentes
Aufwandsreporting
• Rückzahlung bei Unterschreitung des
Festpreises durch die msg
Rückzahlung an AG
Bonus für msg
Vereinbarter
Jahres-Festpreis
Ist-Aufwand
im Festpreisanteil
„Soll“ zu Jahresbeginn
Vorteile für msg:
• Möglichkeit zur
Deckungsbeitragserhöhung durch
Effizienzerhöhung & nachhaltiges
Problem Management
„Ist“ am Jahresende
16
Portierung: Separate Pilotierung, Bonus/Malus
Ausgangssituation:
Direkte Portierung auf die Zielplattform
Technisch:
Plattform aus dem letzten Jahrtausend, Programmcode
auf Basis älterer oder nicht so stark verbreiteter
Programmiersprachen (z.B. VAGen), Erweiterbarkeit
des Systems unzureichend.
Fachlich:
Individualsystem (Bestandsführung von Versicherungsverträgen) mit hoher Relevanz, das auch
zukünftig breit genutzt werden soll. Ablösung durch
Standardsystem scheidet aus.
Zielsetzung:
• Ablösung der technologisch veralteten Plattform
• Gewährleistung der Wartbarkeit und Erweiterbarkeit
dieses Kernsystems
• Programmkonsolidierung als Basis für eine
zukünftige schrittweise Modernisierung auf einer
modernen System-/ Applikationsarchitektur mit
zeitgemäßen Werkzeugen und Programmiersprachen.
ProjektDaten: Laufzeit:
Umfang:
Termin:
Pilot 7 Monate/ Hauptproj. 12 Monate
Projektleitung, Konzeption, Aufbau der
Test- und Entwicklungsumgebungen,
Steuerung des franz. Subunternehmers
(Umsetzung), Testkonzeption und
Durchführung, Schulung der MA,
Switch over
Assembler
RPG
COBOL
CICS &
BATCH
C or
COBOL
MF MTO &
KSH for BATCH
COBOL
MF MTO &
KSH for BATCH
PHOENIX
DL/1
PHOENIX
UDB
UDB
IBM AIX
IBM AIX
DB2
IBM VM/VSE
MIGRATION followed by RATIONALIZATION
TODAY
PHASE 1
Herausforderungen:
• Gewählter Ansatz setzt eine erprobte Methodik und
erfahrenes Projekt Management voraus
• Klare Definition aller beteiligten Rollen sowie der
damit verbundenen Verantwortlichkeiten
• Automatisierte Konvertierung von Assembler und
VAGen zu wartbarem Micro Focus COBOL
• Ausgeprägtes Test Management
• Einhaltung der Performance-Kriterien
• Einbindung von Metaware
• Begleitung der kundenseitigen Entwickler auf die
ungewohnte neue Entwicklungsumgebung
11.2005 – 06.2007
HSE 2006
PHASE 2
17
53
Resümee
• Ernsthaft gelebtes und professionell umgesetztes
partnerschaftliches Kunden-Lieferantenverhältnis
• Auch der Kunde sollte sich in die Rolle des Lieferanten versetzen,
nicht nur der Lieferant in die des Kunden
• Keine einseitige Minimierung des Risikos mit Knebelverträgen,
die u.U. die Zukunft des Lieferanten aufs Spiel setzen können,
sondern Maximierung des Projekterfolgs
HSE 2006
18
54