Vertragsmodelle und Haftung in der Software-Entwicklunghse/HSE06_Lieferantenmanagement.pdf · HSE 2006 3 1. Einleitung Leistungsbeziehungen, bei denen ein Software-Dienstleister für

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

HSE 2006 2

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 3

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 Hot-Spots-Workshop. Der Workshop widmete sich den Fragen, wie Verträge gestaltet werden und wie Haftung und Gewährleistung heute in der Software- und System-Entwicklung 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 4

- 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 die vollständigen Präsentationen der Referenten. Es gilt das gesprochene Wort.

HSE 2006 5

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 6

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 Software-Entwicklung.

2

CHAIR IV Software & Systems Engineering

Ausgangssituation

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

HSE 2006 7

3


Zielkonflikte durch1. Interessensdivergenz2. 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

Ausgangssituation

4


Probleme

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 8

5


Lösungen

Moral Hazard:Monitoring: Kontrolle der Handlungen des AN + SanktionenProbleme:

- 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ätsbedingungVereinbarung 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 InteraktionUnabhängige Bewertung Reputation

HSE 2006 9

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.

18.07.2006 1

HotSpots der Software-Entwicklung 2006

Vertragsmodelle und Haftung in der Software-Entwicklung

- Rechtliche Rahmenbedingungen -

Referentin: Dr. Nadja Kaeding, GRAEFE Rechtsanwälte

HSE 2006 10

18.07.2006 2

Software- und Softwareentwicklung

langwieriger Prozess, der faktische Abläufe IT-technisch umsetzen muss

Vorstrukturierung

Ablaufpläne/Datenflusspläne

18.07.2006 3

Schutz von Software/Softwareentwicklung

Urheberrechtsschutz

Patentschutz?

HSE 2006 11

18.07.2006 4

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)

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.

Patentschutz? I

18.07.2006 5

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Ü.

Patentschutz? II

HSE 2006 12

18.07.2006 6

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 7

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

HSE 2006 13

18.07.2006 8

Erwerb des Urheberrechts

Durch Schaffung der Software

Wer persönliche geistige Schöpfungsleistung erbringt, ist Miturheber.

Problem:Freie Mitarbeiter eines Softwareentwicklungsunternehmens

18.07.2006 9

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“

HSE 2006 14

18.07.2006 11

Erstellung von Software für einen Dritten I

Vertragstypologische Einordnung

Werkvertrag/ Werklieferungsvertrag

Vertrag immer wie Werkvertrag formulieren

18.07.2006 12

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

Erstellung von Software für einen Dritten II

HSE 2006 15

18.07.2006 13

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

Erstellung von Software für einen Dritten III

18.07.2006 14

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

HSE 2006 16

18.07.2006 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 16

Gewährleistung bei Lizenzierung II

Fehlermöglichkeiten bei Software

– Planungsfehler

– Konstruktionsfehler

– Programmierfehler

– Testen

– Bedienfehler

Fehler in der Sphäre Lizenzgeber

Fehler in der Sphäre Lizenznehmer

HSE 2006 17

18.07.2006 17

Gewährleistung bei Lizenzierung III

Fehler aus Sicht des Lizenznehmers

– fehlende (von Lizenznehmers vorausgesagte) Funktionen undFunktionalitäten

– fehlende Performance

– fehlerhafte Ergebnisse

– unzureichende Bedienbarkeit

– unzureichende fehlende Kompatibilität

18.07.2006 18

Gewährleistung bei Lizenzierung IV

Typische Klausel

Der Kunde ist sich bewußt, daß Software nicht fehlerfrei ist.

HSE 2006 18

18.07.2006 19

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 20

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

HSE 2006 19

18.07.2006 21

Haftung für Rechtsverletzung

Freistellung

Gewissheit über Rechtekette

Schadensersatz

18.07.2006 22

Zusammenfassung

maßgeblicher Schutz der Software durch das Urheberrechtsgesetz

Absicherung durch Verträge erforderlich

Keine Hemmung vor eindeutiger Interessenformulierung

HSE 2006 20

18.07.2006 23

GRAEFE Rechtsanwälte

Theresienstrasse 6, 80333 München

www.graefe-portal.de

HSE 2006 21

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 22

218.07.2006Der Einkauf von IT-Dienstleistungen bei der Münchener Rück

Agenda

Der Einkauf von IT-Dienstleistungen bei der Münchener Rück

Überblick

Strategie

Lieferantenbewertung

Vertragskonstrukte und -gestaltung

Ausblick


Überblick

HSE 2006 23


Diversifizierte Struktur – diversifiziertes RisikoMünchener-Rück-Gruppe

Münchener-Rück-Gruppe

Assetmanagement

ErstversicherungRückversicherung


UnternehmenskennzahlenMünchener-Rück-Gruppe

1.88738.1992.751Gesamt

20042005

72

144

31

594

585

1.179

976

420

1.397

Konzern-ergebnis1)

93,14)

110,53)

Schaden-Kosten-

Quote in %

2925.242Schaden/Unfall

2514,712.330Leben/Gesundheit

1.23414.547Schaden/Unfall

1.66622.358Rückversicherung

–1.731

17.572

7.811

Gebuchte Brutto-

beiträge

54

–51

–45

317

432

Konzern-ergebnis2)

11,3

Emb.-Value-Rendite

in %

Assetmanagement

Leben/Gesundheit

davon auf Minderheits-anteile entfallend

Erstversicherung

in Mio. €

Konsolidierung

1) Angepasst aufgrund Erstanwendung IAS 19 (rev. 2004).2) Angepasst aufgrund Erstanwendung IAS 1 (rev. 2003).3) Nicht-Leben4) Schaden/Unfall inkl. Rechtsschutz

HSE 2006 24


Präsent auf allen MärktenRückversicherung

AtlantaBostonChicagoColumbusDallasHartfordKansas CityLos AngelesMontrealNew YorkPhiladelphiaPrincetonSan FranciscoSeattleTorontoVancouverWaltham

BogotáBuenos AiresCaracasMexikoSantiago de ChileSão Paulo

AucklandBrisbaneMelbournePerthSydney

HongkongKalkuttaKuala LumpurMumbaiPekingSchanghaiSeoulSingapurTaipehTokio

MünchenAthenGenfLondonMadridMailandMoskauParisWarschau

AccraDurbanHarareJohannesburgKapstadtNairobiPort Louis


Münchener Rück – die Geschichte

1880

Auf Initiative vonCarl von Thieme, Freiherr Theodor von Cramer-Klett und Wilhelm Finck wird am 19.4.1880 die Münchener Rückgegrü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.

Schnelle Schaden-regulierung durch MR vor Ort:

„Thieme is money“

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 derMR-Gruppe wird von der MEAG verwaltet.

20041906

Die Münchener Rück beschäftigt 511 Mitarbeiter und hat ein Prämienvolumen von 737 Mio. DM.

1960 1984

Größter Blechschaden in der Versicherungs-geschichte: Am 12.7.1984 fallen in München golfball-große Hagelkörner vom Himmel. Jedes zweite Auto inMünchen (=240.000) wird beschädigt.

Die MR zahlt insge-samt 150 Mio. DM.

HSE 2006 25


EinkaufIT-Produkte

EinkaufIT-Produkte

EinkaufIT-Dienstleistungen

EinkaufIT-Dienstleistungen

Beschaffungs-logistik

Beschaffungs-logistik

IT-BeschaffungIT-Beschaffung

strategischer Einkauf


operativer Einkauf

operativer Einkauf

Juristische Beratung



operativer Einkauf

operativer Einkauf

Der Einkauf IT-Dienstleistungen ist organisatorisch im ZB Informatik dem Referat IT-Beschaffung zugeordnet.

Aufbauorganisation des Referates IT 1.9.3 – IT-Beschaffung

ControllingControllingQualitätsmanagementund weitere Services

Qualitätsmanagementund weitere Services

IT-StabIT-Stab

CIOZB Informatik

CIOZB Informatik

Infrastruktur Anwendungsentwicklung …

SchulungSchulung


Der Einkauf IT-Dienstleistungen beschafft entsprechend der IT-Strategie des ZB Informatik ein breites Technologieportfolio.

Warum werden IT-Dienstleistungen beschafft?

Flexible RessourcenplanungTemporärer Know-how ZukaufOuttasking

Welche IT-Dienstleistungen werden beschafft?

IT-BeratungSoftwareentwicklungSystemadministrationWartungsleistungenNetzwerk- / Server-BetriebsleistungenDesktop ServicesHelpdesketc.

HSE 2006 26


IT-A

nfor

dere

rIT

-Ein

kauf

IT-Dienstleistungenanfordern

Bedarf / Leistung spezifizieren

Rahmenvertrag verifizieren

Preise jährlich neu verhandeln

Lieferantenportfolio aktiv managen

Lieferantenbeurteilung auswerten

Vertragerstellen

Bestellungauslösen

IT-Anforder hat komplexe IT-Anforderung die zusammen mit dem IT-Einkauf in enger Interaktion als crossfunktionales Team bearbeitet wird.

IT-Einkauf führt Jahrespreisverhandlungen mit Lieferanten durch. Für Anforderungen führte erumfangreiche fachspezifische und juristische Beratungen durch.

Leistungs-beschreibung

verifizieren

Preise zu Leistungen zuordnen

(Skillkategorien)

Lieferanten entwickeln und

ausphasen

Überblick über den Beschaffungsprozess des Einkaufs IT-Dienstleistungen der MR:

Wie werden IT-Dienstleistungen beschafft?

Ausschreibung durchführen

Nachverhandlungdurchführen

Cro

ss-

funk

tiona

les

Team Ggfls. juristisch

beraten


Strategie

Aktives Lieferantenmanagement

HSE 2006 27


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)

72,50 €70,50 €

65,00 € 64,50 €66,00 €

60,00 €62,00 €64,00 €66,00 €68,00 €70,00 €72,00 €74,00 €

2002 2003 2004 2005 1. HJ. 2006

Quelle: www.gulp.de


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

85 €

100 €90 €

100 €

80 €90 €

99 €

82 €95 €

0 €

20 €

40 €

60 €

80 €

100 €

120 €

Aut

omot

iv

Ban

king

/In

sura

nce IT TK

Hea

lthC

are

Indu

stry

Pub

licS

ecto

r

Trai

ning

Oth

ers

Quelle: Eigene Recherche

HSE 2006 28


Freiberufler IT-Dienstleister / Systemhäuser

kostengünstigflexibel und einfach im Umgangteilweise hoher Spezialisierungsgradschnelle Verfügbarkeit am MarktAkzeptanz der AGB‘s der MR

hohe VersorgungssicherheitBeschaffungshebel durch langfristige PartnerschaftGesicherter Service und QualitätBreites KompetenzspektrumProjektstaffing möglichFachexpertise für Rückversicherung

Lieferantenentwicklung nicht möglich hohes AÜG-RisikoAufbau wechselseitiger Abhängigkeitkeine Redundanz bei AusfallVerliert Mehrwert bei Dauertätigkeit

höherer Preis als Freiberuflerteilweise schwierige Verhandlungen

Vor- / Nachteile von Freiberuflern und IT-Dienstleistern bzw. Systemhäusern

Die MR hat sich bewusst für das Sourcing bei renommierten größeren IT-Dienstleistern bzw. Systemhäusern entschieden.


Stratege Speziallieferant

Vorzugslieferant Sonstige Lieferanten

Die IT-Dienstleister bzw. Systemhäuser werden bei der MR in ein Lieferantenportfolio, bestehend aus vier Kategorien, eingeordnet.

Grosses Leistungs- und Personalportfolio

Tiefe MR-Fachkenntnisse

Ist präferierter Partner bei Ausschreibungen und der Vergabe von Outtasking

Nur eingeschränktes MR-konformesLeistungsportfolio

Arbeiten in speziellen Nischen

Beteiligung an Ausschreibungen eher selten

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

Sonstige Lieferanten unterteilen sich in:

- Neueinsteiger,

- Wiedereinsteiger und

- Ausphasungskandidat

Eine erfolgreiche Lieferantenentwicklung führt zu neuem Status im Lieferantenportfolio

Übersicht über die Definition der einzelnen Quadranten des Lieferantenportfolios

HSE 2006 29


Mit ausgewählten IT-Dienstleistern aus dem Lieferantenportfolio werden die Preise anhand der standardisierter Skills in den MR-Kategorien 0 bis 4 in einem jährlichen Turnus verhandelt.

Skilleinordnung anhand der MR-Kategorien

• 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

MR-Kategorie Tätigkeiten

0 Junior-ProgrammiererJunior-EntwicklerProjektassistenz

1 ProgrammiererEntwicklerSystembetreuerBenutzerserviceNetzwerktechniker

2 Senior-ProgrammiererSenior-EntwicklerSystemengineerDatenbankspezialistSystemmanagerSystemarchitektNetzwerktechnikerBeraterTeilprojektleitungQualitätssicherer

3 Senior BeraterDatawarehousespezialistSenior SystemarchitektNetzwerkberatungProjektleitungQualitätsmanager

4 Individuelle Verhandlung


Die Steuerung des Lieferantenportfolios und das Berichtswesen an das Management erfolgt quartalsweiseanhand eines standardisierten Managementcockpits.

Beispielgrafiken und Kennzahlen aus dem Management-Cockpit

Gruppe

0

Gruppe

1

Gruppe

2

Gruppe

3

Gruppe

4

Festpr

eis

Neb

enko

sten

Bestellvolumen pro Gruppe Beschaffungsvolumen gem. Lieferantenportfolio

65%16%

12%7%

Strategen Vorzugslieferanten Speziallieferanten Sonstige Lieferanten

HSE 2006 30


Lieferantenbewertung


Kriterien für die Lieferantenbewertung

KundenorientierungProjektabwicklungProblemverhaltenKontrollverhaltenPreis- / LeistungsverhältnisFachliche Leistung der externen Mitarbeiter im Projekt

Die Lieferantenbewertung ist bei der MR ein wichtiger Baustein für die Erstellung des Lieferantenportfolios.

Kriterien und Prozess der Lieferantenbewertung in der MR

• 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 31


Ausschnitt aus der Eingabemaske zur Lieferantenbewertung von IT-Dienstleistern bzw. Systemhäusern.

Vertragsnummer:

Projektname:

Innenauftragsnummer:

Projektbeginn:

Ansprechpartner MR:

deut

lich

und

daue

rhaf

t übe

rtro

ffen

über

trof

fen

voll

erfü

llt

mit

Eins

chrä

nkun

gen

erfü

llt

wei

tgeh

end

nich

t erf

üllt

Kriterium Gew.Faktor

150 125 100 75 50

Anmerkungen für projektbezogene Stärken und Schwächen:

Kundenorientierung1 0 0 0 0 0

FALSCHE WERTE

Projektabwicklung1 0 0 0 0 0

FALSCHE WERTE

Problemverhalten1 0 0 0 0 0

FALSCHE WERTE

Kontrollverhalten1 0 0 0 0 0

FALSCHE WERTE

Preis-/Leistungsverhältnis1 0 0 0 0 0

FALSCHE WERTE

Zwischenbewertung Projekt 1 0

Projektende:

Externer Partner:

Bitte tragen Sie den Namen Ihres Projektes ein

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!

Bitte tragen Sie in den entsprechenden Zellen Kommentare zu Ihren Bewertungen ein.


Vertragskonstrukte und -gestaltung

Beauftragung von IT-Dienstleistern und zugehörige Vertragsdokumente

HSE 2006 32


Durch eine

qualitativ

hochwertige

Leistungs-

beschreibung

besteht die

Möglichkeit, die

Lieferanten mit in

die Projekt-

verantwortung

einzubinden.

Standardisiertes Inhaltsverzeichnis für Vertragsleistungsbeschreibungen in der MR

Kurzdarstellung des Projektes

Leistungsumfang des Auftragnehmers

Aufgaben des Auftragnehmers im Projekt

Vorgehen und Meilensteinplan

Zu erbringende Ergebnisse des Auftragnehmers

Maßnahmen zur Qualitätssicherung

Abnahmekriterien für die zu erbringenden Ergebnisse

Vom Auftragnehmer einzuhaltende Richtlinien / Rahmenbedingungen

Sondervereinbarungen

Grundlage zur Beauftragung eines IT-Dienstleisters / Systemhauses ist bei der MR die vom IT-Projektleiter erstellte Vertragsleistungsbeschreibung.


Abhängig von der Art der Vertragsgestaltung werden IT-Dienstleister bzw. Systemhäuser mehr oder weniger in die Projektverantwortung eingebunden.

2

3

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

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

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 33


Lieferanten die nicht den

Status Stratege oder

Vorzugslieferant haben,

werden auf Basis der

AGB‘s der MR

beauftragt, die inhaltlich

zum Standard-

Rahmenvertrag identisch

sind.

Konditionen und Preise

werden jährlich separat

verhandelt.

Vergütung / Kosten des Auftraggebers / Leistungsänderungen / Behinderung des Auftragnehmers

…

Rechte / Erfindungen / Eigentum

Werkvertragliche Leistungen / Dienstvertragliche Leistungen /Software Hinterlegung / Abnahme / Haftung / Verzug

Geheimhaltung / Datenschutz und –sicherheit / Verpflichtung Personal

Herausgabe Material / Aufrechnung / Zurückbehaltungsrecht

2

3

4

5

6

7 Laufzeit / Kündigung / Schlussbestimmung / Sonstiges

1 Geltungsbereich / Vertragsgegenstand / Durchführung / Zusammenarbeit

Grundsätzliche Themenstellungen von Standard-Rahmenverträgen

Folgende grundsätzlichen rechtlichen Themenstellungen sind in den Standard-Rahmenverträgen geregelt:


Ausblick

Die Herausforderungen für die Zukunft

HSE 2006 34


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 35

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 ITPZ-T-118.07.2006Seite 1

Join BMW IT.Basisqualifizierung.

HSE 2006 36


Grundlagen der IT Beschaffung in der BMW AGInhaltsübersicht

Struktur und Ausrichtung der IT Beschaffung1

Organisatorische und operative Ausgestaltung der Beschaffung2


IT Sourcing.Rolle der IT bei BMW.

HSE 2006 37


IT Sourcing.Besonderheiten der IT Beschaffung.

LieferantenstrukturCa. 1250 IT Lieferanten Sehr dynamischer BeschaffungsmarktBreites Lieferantenspektrum (Freelancer bis hin zu global Playern)Von extremen Wettbewerb bis hin zu de facto Monopolisten

Commodity StrukturBreites Warengruppenspektrum von Standard Produkten bis zu hoch spezialisierten IndividuallösungenDie Komplexität der Gewerke ist bei Vergabe nicht immer exakt abschätzbar

KundenstrukturBreite Kundenstruktur aus der gesamten IT Community(ca. 2500 Mitarbeiter)

Besonderheiten der IT Beschaffung


IT Sourcing.Fokusthemen der IT Beschaffung.

Durchgehender, IT gestützter Beschaffungsprozess Methoden- und Toolunterstützung entlang der Beschaffungskette

Sourcing StrategienPortfoliomanagementAusbau Internationalisierung

Leistungsorientierte LieferantenbewertungLieferantenmanagement

Strategische Ausrichtung der Beschaffung

Wir erwirken nachhaltig das bestmögliche Verhältnis vonLeistung zu Gesamtkosten.

Operative Prozessunterstützung

HSE 2006 38


IT Sourcing.Kompetenzfeldmatrix.

Die „Kompetenzfeldmatrix“ ist in allen relevanten Einkaufssystemen implementiert und ist die Basis für ein differenziertes Portfoliomanagement.

IT BeratungIndividual

SWEntwicklung

StandardSW

LizenzenAnwendungs-

betriebHardware &Infrastruktur Leistungsart

Prozess / Ressort

E - Entwicklung

T - Produktion

V - Vertrieb

SF – Sparte Finanzdienstleistung

F - Finanzen

P - Personal

FZ – Zentrale IT

Geometriemethoden & -systeme

CAE/CAT

Prod.technische Integration

Elektrik/Elektronik

PEP PDM

Collaborative Engineering

Fahrzeugmanagementsysteme

Einkaufsprozessunterstützung & systeme


IT Sourcing.Sourcing Prozessmodell.

IT Ressourcensteuerung

Sourcing-programm

SkillManagement

Eigen-leistungs-steuerung

IT Beschaffungsplanung

Umsetzungs-planung

Ranking Lieferanten

Analyse der Lieferanten

Beschaffungs-portfolio

Bedarfs-planung

Initialisierung Sourcing

Team

Steuerung Beschaffungsplanung

Lieferanten Entwicklung

Ein-, Aus-phasung

Entwicklungs-maßnahmen

Lieferanten Assessment

Lieferanten-datenbank

Lieferanten Management

RelationshipManagement

Projekthaftes Lieferanten Management nach Partnerschaftsmodell

IT Einkauf

Lieferant bewerten

Vertrags-durchführungBestellung…

Ausschreibungs-unterlagenerstellen

IT Beschaffung planen und Einkaufs-

meth. festlegen

IT Strategie

IT Planung

IT Projektabwicklung

Phase 5Installation

u. Abnahme

Phase 4Implem., Test

und Integr.

Phase 3IT

Konzept

Phase2Fach-

konzept

Phase 1Grob-

konzept

Phase 0Projekt-auftrag

FZ-10

TE-5-S

TE-5x RIT1

FZ-x1

TE-5x1

TE-5x

Prozesstreiber 1) Themenspezifisch

HSE 2006 39


Sourcing Prozessmodell.Teilprozess Leistungssteuerung.

Sourcing-programmInput Handlungsbedarfe Nutzenpotentiale

• Eigenleistungs-strategie

• IT Strategie

• FZ/RIT-Planung

• Einkaufs-anforderungen

Strategisches Sourcing

• Abhängigkeits- oder Monopolsituation

• Neue Technologien oder Leistungen

• Potential innovatives Sourcingmodell

• Ressortübergreifende Strukturmaßnahme (Bündelung, Standardisierung)

Operatives Sourcing

• Potenzial Volumenbündelung

• Optimierungsbedarf in der Lieferantenstruktur

• Verbesserte Verhandlungs-posit ion durch gezielten Aufbau von Wettbewerb

• Erweiterung der Lieferanten-portfolios mit innovativen Dienstleistern

• Reduzierung von Risiken durch aktive Lieferantensteuerung

• Skalen- und Verbundeffekte

• Höhere Effizienz im Prozess

• Höhere Qualität der Leistungserbringung durch Konzentration auf best-fitLieferanten

•Skaleneffekte


Sourcing Prozessmodell.Teilprozess IT Beschaffungsplanung.

1 2 3 4

Teamorientierter Ansatz zur Erarbeitung von Sourcingstrategien

Dokumentation

5 7 8

IT Bedarfsportfolio

2 1 3Completeness of Vision

Pow

er to

Exe

cute

Vereinbarung Arbeitsauftrag

Beschreibung Kompetenzfelder

Ermittlung Gesamtbedarf

Positionierung im Kompetenzfeld-portfolio

Analyse u. Assessment der Lieferanten

Abnahme und Review der Strategie

Review derUmsetzung der Strategie

6 Festlegung der Vergabestrategie und Umsetzungs-planung

HSE 2006 40


Sourcing Prozessmodell.Teilprozess Lieferantenentwicklung.

Bewerber-/ Lieferanten-Datenbank

Lieferantenpositionierung Entwicklungsmaß-nahmen

1 2 3

- Datenpflege durch Lieferanten selbst über Lieferantenportal

- Basis für Bedarfs-recherchen der IT Community und des IT Einkaufs

- Gezielte Assessmentsdes Unternehmens

- Kontinuierliche Bewertung der Leistungserbringung des Lieferanten

- Positionierung im Lieferantenportfolio

- BMW IT Zertifizierungder Mitarbeiter in Projekten

- Verbindliche Verein-barung von Qualitäts-und Leistungszielen auf Basis regelmäßiger Leistungsbewertungen


Sourcing Prozessmodell.Lieferantenbewertung.

Eine systematische Bewertung der Leistungserbringung durch Lieferanten ist unabdingbare Voraussetzung für eine qualitätsgesteuerte Optimierung des Lieferantenportfolios.

Ziele

- Transparenz der Schwachstellen durch differenziertes Feedback- Vereinbarung von gezielten Maßnahmen, kontinuierliche Entwicklung - Die Objektivierung und Optimierung der Lieferantenauswahl

Preis / Leistungsverhältnis

Qualität der Zusammen-arbeit

Kompetenz Qualität der Leistung

Projekt-organisation

2,0

2.5

2.1

3.0

1.4

HSE 2006 41


Sourcing Prozessmodell.Ziele des Lieferantenmanagements.

Ziele des Lieferantenmanagements

1 2Strategische Positionierung des Lieferanten durch Konzentration auf seine Kernkompetenzen.

Nachhaltige Verbesserung der Qualität durch Vereinbarung und Umsetzung von gezielten Entwicklungsmaßnahmen.

3 4Stärkung der partnerschaftlichen Zusammenarbeit und Beherrschungvon Risiken und Abhängigkeitendurch ressortübergreifende Steuerung des Partners.

Aufzeigen und Nutzen der Innovations-potenziale des Lieferanten zur Steigerung des Businessnutzens bei BMW.


Sourcing Prozessmodell.Aktive Lieferantensteuerung.

Nutzen für BMW:

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 Weiter-entwicklungen und Innovationen

Erzielung von höherer Qualität und Prozesssicherheit in der Zusam-menarbeit und im Beschaffungsablauf.

Nachhaltige Verbesserung der Leistungserbringung durch Zielverein-barungen auf Top Managementebene.

HSE 2006 42


Sourcing Prozessmodell.Aktive Lieferantensteuerung.

Nutzen für den Partner:

Optimale Mitarbeiterpositionierung 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 Marktposition durch Partnerschaft mit BMW.


Grundlagen der IT Beschaffung in der BMW AGInhaltsübersicht

Struktur und Ausrichtung der IT Beschaffung1

Organisatorische und operative Ausgestaltung der Beschaffung2

HSE 2006 43


IT Sourcing.Organisation des IT Einkaufs.

AVorstands-vorsitzender

H. Panke

EEntwicklung

/ EinkaufB. Göschel

PPersonal- u. SozialwesenE. Baumann

VVertrieb

M. Ganal

TProduktion

N. Reithofer

FFinanzen

S. Krause

EMMaterial-einkauf

K. Richter

TETechnischer

EinkaufH. Woebcken

Vorstand der BMW AG


IT Einkauf.Organisation und Einkaufsumfänge.

TETechnischer EinkaufHinrich Woebcken

TE-5Informationstechnik

Friedrich Bruckmeyer

TE-50

Kalkulation

TE-51

IT Beratung, Software für die Ressorts

E, T

TE-52

IT Beratung, Software für die Ressorts

A, F, P, V

TE-53

Hardware, Infrastruktur u.

Services

TE-5-S

Steuerung IT PartnermanagementLothar Heggmair

MichaelKormann

EdwardBednarek

ReinholdNoppe

Karl-HeinzHerrmann

TO-M-1

Oxford, Hams Hall,

Goodwood

Tony Harris

HSE 2006 44


IT Einkauf.IT Beschaffung und Projektabwicklung.

IT Beratung / Individual-Entwicklung

Standard Software

BMW AVBs für SW-Pflege

Allgemeine Vertragsbedingungen (AVB) für IT Projektleistungen

BMW AVBs zur Überlassung von Standard-SW-Produkten

Projektdurchführung nach ITPM

Phase 1:Grobkonzept

Phase 2:Fachkonzept

Phase 3:IT Konzept

Phase 4:Implementierung, Test u. Integration

Phase 5:Installation u.

Abnahme

IT Beschaffung planen u.

Einkaufsmethodik festlegen

Ausschreibungs-unterlagenerstellen

Lieferantenvor-auswahl u. Bieterkreis

Angebote einholen

… Vertragsdurch-führung

Lieferantbewerten

IT Einkauf

HSE 2006 45

7. Lieferantenmanagement: Erfahrungen, Anforderungen, Vorschläge aus Sicht eines Lieferanten

Jürgen Lohrmann ist Bereichsleiter IT Service Management & Solutions bei der msg systems ag.

msg systems ag, J. Lohrmann: Lieferantenmanagement: Erfahrungen, Anforderungen, Vorschläge aus Sicht eines Lieferanten 1

.consulting .solutions .partnership

A


Lieferantenmanagement: Erfahrungen, Anforderungen, Vorschlägeaus Sicht eines Lieferanten

Hot Spots der Software-Entwicklung 2006Vertragsmodelle und Haftung in der Software-EntwicklungTU München und VSEK, 5. Juli 2006

Jürgen Lohrmann, msg systems agIT Service Management & Solutions

HSE 2006 46



A

Agenda

1. Aktuelle Erfahrungen und Anforderungen

2. Welche Konsequenzen haben wir daraus gezogen?

3. Beispiele für innovative Vertragskonstrukte

4. Diskussion



A

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 47



A

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



A

Agenda




4. Diskussion

HSE 2006 48



A

Auftragsklärung als Projekt

ZeitTeilprozesse

Anforderungsanalyse

Design

Implementierung

Test

Einführung

Projektmanagement

Konfigurations-management

Auftragsklärung Ausarbeitung Realisierung InbetriebnahmePhasen

(mögliche) Iterationen Iter. #1 Iter. #2 Iter. #mIter. #n

Meilensteine

Dynamisch – der zeitliche Ablauf



A

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 49



A

Was ist iterativ-inkrementelle Entwicklung?

Feedback aus Iteration N führt zu Verfeinerung und Anpassungen

von Anforderungen und Design in Iteration N+1

Feedback Feedback

Eine Iteration (z.B. 4 Wochen)

Das System wächst inkrementell

AUSLIEFERUNG ZUM KUNDEN

Umsetzungeiniger Anforderungen

Umsetzungeiniger Anforderungen

Umsetzung einiger Anforderungen



A

Auftragsklärung: Beginn eines Projekts

HSE 2006 50



A

Auftragsklärung: Wichtigste Ergebnisse

• Aufwandsschätzung

• Risikobewertung (!)

• Grober Projektplan

• Leistungsumfang



A

Aktivitäten Auftragsklärung - Überblick

Risikenerfassen

Projekt grob

planen

Preis-kalkulation

Angebotprüfen

Präsentation vorbereiten

Aufwandschätzen

FachlicheAnforderungenidentifizieren

Angebots-management

NichtfachlicheAnforderungenidentifizieren

Projekt-Ergebnissefestlegen

HSE 2006 51



A

Agenda




4. Diskussion



A

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, Test-und 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 52



A

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 PaketenBonus/Malus-Regelung für „kritische“ Projektinhalte(zu migrierende Assets, Änderungsdynamik während der Migration,Termintreue bezüglich Frozen Zones)



A

Profit Share im Application Management (1)

System-Typ BSystem-Typ A

bis 6 Monate nach Produktivsetzung mit

Überprüfung und Festelegung A und B

ProduktionsüberwachungReporting, Steuerung, Rufbereitschaft

Incident Management (2nd & 3rd Level)Problem Management

Inbetriebnahmemanagement

Zusätzliche Services(wie z.B. Auswertungen)

Standard (System im

eingeschwungenen Zustand)

Festpreis Festpreis

Festpreis („Profit Share“) mit LeistungsmessungTime & Material

Time & Material(nach Absprache mit

dem Kunden)


dem Kunden)


dem Kunden)


dem Kunden)

HSE 2006 53



A

Profit Share im Application Management (2)

Umsetzung Profit Share

VereinbarterJahres-Festpreis

„Soll“ zu Jahresbeginn „Ist“ am Jahresende

Ist-Aufwand im Festpreisanteil

Bonus für msg

Rückzahlung an AGVorteile für den AG:• Kein Risiko durch gedeckelten

Festpreis• Detailliertes & transparentes

Aufwandsreporting• Rückzahlung bei Unterschreitung des

Festpreises durch die msg

Vorteile für msg:• Möglichkeit zur

Deckungsbeitragserhöhung durch Effizienzerhöhung & nachhaltiges Problem Management



A

Portierung: Separate Pilotierung, Bonus/Malus

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

Projekt-Daten: Laufzeit: Pilot 7 Monate/ Hauptproj. 12 Monate

Umfang: Projektleitung, Konzeption, Aufbau der Test- und Entwicklungsumgebungen, Steuerung des franz. Subunternehmers (Umsetzung), Testkonzeption und Durchführung, Schulung der MA, Switch over

Termin: 11.2005 – 06.2007

Ausgangssituation: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 Versiche-rungsverträ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.

Direkte Portierung auf die Zielplattform

PHASE 1PHASE 1

IBM VM/VSEIBM VM/VSE

DL/1

DB2

COBOLMF MTO &

KSH for BATCH

IBM AIXIBM AIX

UDB

MIGRATIONMIGRATION followed by RATIONALIZATIONfollowed by RATIONALIZATION

IBM AIXIBM AIX

C orCOBOL

MF MTO &KSH for BATCH

UDB

PHOENIXPHOENIXPHOENIXPHOENIX

TODAYTODAY PHASE 2PHASE 2

AssemblerRPG

COBOLCICS &BATCH

HSE 2006 54



A

Resümee

• Ernsthaft gelebtes und professionell umgesetztespartnerschaftliches 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

Documents

Vertragsmodelle und Haftung in der Software-Entwicklunghse/HSE06_Lieferantenmanagement.pdf · HSE 2006 3 1. Einleitung Leistungsbeziehungen, bei denen ein Software-Dienstleister für