Kapitel 8 Auswahl von Standardsoftware

Transkript

1 ProKSy - EBSS Institut AIFB WS 2013/2014 Programmierung kommerzieller Systeme Einsatz betrieblicher Standardsoftware (ProKSy EBSS) Kapitel 8 Auswahl von Standardsoftware Institut für Angewandte Informatik und Formale Beschreibungsverfahren Prof. Dr. Stefan Klink

2 Inhalt der Vorlesung 0. Konzept und Organisation 1. Einführung und Überblick 2. Vorstellung der Standardsoftware Horus 3. Unternehmensmodellierung 4. Betrieblicher Informationssysteme 5. Vorstellung der Standardsoftware Windows SharePoint Services 6. Managementunterstützungssysteme und Business Intelligence 7. Ökonomische Aspekte des Standardsoftwareeinsatzes 8. Auswahl von Standardsoftware 9. Einführung von Standardsoftware 2

3 Inhalt Kapitel 8 8 Auswahl von Standardsoftware 8.1 Vorgehensmodelle für die Softwareauswahl 8.2 Fehler bei Anbieter- und Systemauswahl 8.3 Von der Anforderungsspezifikation bis zur Vertragsgestaltung Gliederung der Anforderungsspezifikation Vorgehen zur Anforderungsspezifikation Vorauswahl von Anbietern Anbieterbefragung Anbieterpräsentation und bewertung Vertragsgestaltung 3

4 8.1 Vorgehensmodelle für die Softwareauswahl Zur Auswahl von Software im Allgemeinen existieren in der Literatur unterschiedliche Vorgehensmodelle Im Folgenden: Diskussion verschiedener allgemeiner Vorgehensmodelle und Darstellung eines Phasenmodells zur Auswahl von Standardsoftware Basis dieses Abschnitts: Gronau, Norbert: Industrielle Standardsoftware Auswahl und Einführung. München: Oldenbourg,

5 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Lang (1989): Projektdefinition Situationsanalyse Grobkonzept Marktanalyse Grobauswahl Feinauswahl Entscheidung/Vertragsverhandlung Feinkonzept Vorbereitende Maßnahmen Einführung Zeit Kritikpunkt: Dargestellte Dauer der einzelnen Phasen in der Praxis unrealistisch (Beispiel: Einführung macht häufig 2/3 der Gesamtdauer aus) 5

6 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Laakmann (1993) / Phasen und Arbeitsblöcke: 1. Konzeption 1. Projekteinrichtung 2. Ist-Analyse 3. Soll-Konzept 2. Systemauswahl 1. Vorauswahl 2. Endauswahl 3. Vertragsabschluss 3. Realisierung 1. Realisierungsvorbereitung 2. Systeminstallation 3. Inbetriebnahme ursprünglich für PPS-Systeme entwickelt, aber auch allgemeiner verwendbar Details... 6

7 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Laakmann (1993) / Arbeitsschritte: 1. Konzeption 1. Projekteinrichtung 2. Ist-Analyse Formulierung von Aufgabenstellung und Zielsetzung Abgrenzung des Untersuchungsbereiches Aufstellung eines Ablauf- und Zeitplanes Bildung eines Projektteams aus allen beteiligten Bereichen Untersuchung von Ablauforganisation und Informationsfluss Ermittlung des Datengerüstes und der Datenqualität Dokumentation der Schwachstellen Bewertung der Schwachstellen 3. Soll-Konzept Entwicklung eines Organisationskonzeptes Definition der Schnittstellen zu benachbarten Bereichen Schätzung des Personalbedarfs Schätzung des Qualifizierungsbedarfs 7

8 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Laakmann (1993) / Phasen und Arbeitsblöcke: 2. Systemauswahl 1. Vorauswahl Erkundung des Marktangebots Erstellen des Anforderungskatalogs Bewertung der Systeme Festlegung der Favoritengruppe 2. Endauswahl Erstellen von Testfahrplänen und Erhebung von Testdaten Durchführung von Anbietertests Durchführung von Anwendertests in Referenzbereichen Erstellung des Pflichtenhefts für Anpassungen 3. Vertragsabschluss Verhandlung der Vertragsmodalitäten Erstellung des Softwarevertrags Erstellung des Hardwarevertrags Dokumentation der eigenen Leistungen 8

9 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Laakmann (1993) / Phasen und Arbeitsblöcke: 3. Realisierung 1. Realisierungsvorbereitung Detaillierung des Sollkonzeptes Erstellung des Realisierungsplanes Durchführen systemtechnischer Schulungen Schaffen der technischen Voraussetzungen 2. Systeminstallation Anpassen der Software Installation von Hard- und Software Konfiguration der Software Realisierung der Schnittstellen 3. Inbetriebnahme Einpflegen der Stammdaten Durchführen des Testbetriebs Abnahme des Systems Übergang in den Echtbetrieb 9

10 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Laakmann (1993) / Phasen und Arbeitsblöcke: 1. Konzeption 1. Projekteinrichtung 2. Ist-Analyse 3. Soll-Konzept 2. Systemauswahl 1. Vorauswahl 2. Endauswahl 3. Vertragsabschluss 3. Realisierung 1. Realisierungsvorbereitung 2. Systeminstallation 3. Inbetriebnahme Trennung dieser Phasen nur sinnvoll, wenn Make-or-Buy-Entscheidung nach Phase 1 möglich! u. U. Verlagerung einzelner Aufgaben in Realisierungsphase (wg. Aktualität) 10

11 8.1 Vorgehensmodelle für die Softwareauswahl Vorgehensmodell von Hamacher (1991): Projektmanagement installieren Zielfindung Analyse der Ausgangssituation (Aufbau- und Ablauforganisation, Informations- und Materialfluss, Personalsituation, Qualifikation, informelle Fähigkeiten) Erstellung eines Anforderungskataloges Abstimmung des Anforderungskataloges Zielfeststellung Konzeptbildung Grobkonzept Feinkonzept Verabschiedung Umsetzungsprozess EDV-technische Umsetzung Erstellung eines Grobpflichtenhefts Diskussion und Verfeinerung des Pflichtenhefts mit EDV-Partnern Beschaffung von Soft- und Hardware Entwicklung und Anpassung der Software entsprechend dem Konzept Organisatorische Umsetzung Rückkoppelung mit Betroffenen Qualifizierung zur Systemmitgestaltung Gemeinsame Entwicklung der neuen Feinorganisation Durchführung von Qualifizierungsmaßnahmen 11

12 8.1 Vorgehensmodelle für die Softwareauswahl Phasenmodell zur Auswahl von Standardsoftware nach Gronau (2001): Aufgabe Ziel 1-4 Wochen Endauswahl 2-4 Wochen Screening 2-6 Wochen Marktübersicht 3-8 Wochen Anforderungen 3-12 Wochen Entscheidung 4-8 Wochen Zeit 12

13 8.1 Vorgehensmodelle für die Softwareauswahl In der Praxis laut Gronau (2001): Dauer von Zieldefinition bis Vertragsunterschrift mindestens vier Monate. Stein (1996) berichtet über durchschnittliche Dauer der Auswahlphase von 17 Monaten. Bei komplexen Systemen kann die Auswahl mehrere Jahre dauern (Beispiel von Stein (1996): bis zu vier Jahre dauernde Auswahl eines PPS-Systems). 13

14 8.2 Fehler bei Anbieter- und Systemauswahl Fehler bei der Systemauswahl nach Stein (1996): auslösende Motive unklare Zielsetzungen fördert überzogene Erwartungen lässt zu bestreitet Notwendigkeit fehlende Analyse, Konzeption und Wirtschaftlichkeitsbetrachtung umfangreiche Zeitdauer gegenseitige Abhängigkeit baut auf hohe verbleibende Unsicherheit Auswahlentscheidung 14

15 8.2 Fehler bei Anbieter- und Systemauswahl Wesentliche Fehler: unartikulierte Zielsetzungen ( Wir wollen in Abteilung X Personal abbauen. ) unklare Zielsetzungen ( Abteilung X soll besser arbeiten. ) übersteigerte Erwartungen ( Durch die neue Software werden unsere Daten aktueller. ) fehlende Analysen / zu früher Ausschluss von Produkten ( Das Produkt X sehen wir uns nicht näher an, weil es das Betriebssystem Y benötigt. ) fehlende Überprüfung von Anbieterangaben fehlende Bewertungsgrundlage vorschnelle Festlegung auf Haus- und Hoflieferanten zu lange Dauer der Auswahl fehlendes Know-how (z. B. in KMUs zu speziellen Systemen) 15

16 8.3 Von der Anforderungsspezifikation bis zur Vertragsgestaltung In der Praxis sind unterschiedliche Extremfälle zu beobachten: Lieferantenvorgabe statt Anforderungsspez. Anforderungsspezifikation mit 2000 Kriterien Besser: nicht zu detaillierte Anforderungsspezifikation, die eine Konzentration auf die Unterschiede einzelner Produkte ermöglicht Anforderungsspezifikation für Standardsoftware brauchen im Allgemeinen weniger detailliert zu sein als Spezifikationen für Individualsoftware (Motto: Wenn die Software schon in 100 Betrieben läuft, wird sie auch mit unseren Artikelnummern zurechtkommen. ) Anforderungen sollten so formuliert werden, dass klar beantwortet werden kann, ob sie von einem Produkt erfüllt werden ( ja, ja, mit Zusatzaufwand, nein ) Anforderungen sollen keine Lösungen enthalten, d. h. die Art der Realisierung spielt in der Anforderung noch keine Rolle 16

17 8.3.1 Gliederung der Anforderungsspezifikation Typische Gliederung: 1. Technische Anforderungen 2. Anforderungen an die Benutzungsfreundlichkeit 3. Funktionale Anforderungen 4. Adaptive Anforderungen 1. Technische Anforderungen Zentrale Frage: Wie lässt sich die Standardsoftware in die vorhandene IT-Architektur eingliedern? Dazu: Formulierung von Anforderungen an Schnittstellen 17

18 8.3.1 Gliederung der Anforderungsspezifikation 2. Anforderungen an die Benutzungsfreundlichkeit Standardsoftware soll mit möglichst wenig Schulungsaufwand benutzt werden können Bei der Formulierung von Anforderungen ist im Allgemeinen die Orientierung an einem Standard sinnvoll (DIN 66234/ISO 9241) Typischerweise sind Anforderungen zu diesen Punkten zu formulieren: Aufgabenangemessenheit Selbsterklärungsfähigkeit Steuerbarkeit Erwartungskonformität Fehlerrobustheit Individualisierbarkeit Lernunterstützung 3. Funktionale Anforderungen Gliederung nach den umzusetzenden Geschäftsprozessen (nicht nach vorhandenen Funktionsbereichen, damit sich Anforderungen nicht an ungeeigneten Organisationsformen orientieren) 18

19 8.3.1 Gliederung der Anforderungsspezifikation 4. Adaptive Anforderungen Zentrale Frage: Wie lässt sich die Standardsoftware an veränderte Bedingungen anpassen? Lebensdauer von Standardsoftware i. A. > Zeitraum zwischen zwei Umstrukturierungen Benötigt werden nachhaltige, d. h. adaptive und flexible Systeme Sinnvoll: Forderung struktureller Analogien zwischen Organisation und Informationssystemarchitektur Organisation Informationssystemarchitektur Segmentierung der Organisation Organisatorische Abläufe über Abteilungsgrenzen hinweg Kontinuierliche Reorganisation, Lernprozesse Auflösung der Unternehmensgrenzen Objektorientierung der Programme Workflow-Management der Anwendungssysteme Releasewechsel Verteilte Anwendungen im Netzwerk 19

20 8.3.2 Vorgehen zur Anforderungsspezifikation Sammeln Bewerten Sammlung von Anforderungen und Gliederung nach Themengebieten (s. o.) Mögliche Quellen: Interviews mit Mitarbeitern/ Management Fachliteratur Externe Berater Anbieter Verdichten 20

21 8.3.2 Vorgehen zur Anforderungsspezifikation Sammeln Bewerten Verdichten Differenzierte Bewertung der Anforderungen Einteilung nach Prioritäten (i. A. gemeinsam mit Management) A = unverzichtbar B = wichtig C = nice to have 21

22 8.3.2 Vorgehen zur Anforderungsspezifikation Sammeln Bewerten Verdichten Zur Auswahl ist eine Beschränkung auf A- oder A-/B-Anforderungen sinnvoll Dadurch: leichtere Überprüfung der wirklich wichtigen Anforderungen 22

23 8.3.3 Vorauswahl von Anbietern Zur Identifikation möglicher Anbieter stehen unterschiedliche Quellen zur Verfügung, z. B.: 1. Fachliteratur 2. Messebesuche 3. Internet-Recherche 4. Anbieterübersichten Diese haben unterschiedliche Vor- und Nachteile und sollten daher kombiniert genutzt werden Details... 23

24 8.3.3 Vorauswahl von Anbietern 1. Fachliteratur: Anwenderberichte in Fachzeitschriften erläutern Programmeinsatz im konkreten Beispiel Berichte des Anbieters informieren über den Stand des Programms, sind in dieser Phase aber kaum nachprüfbar Anzeigen in Fachzeitschriften machen auf Anbieter aufmerksam Anbieterverzeichnisse in Fachzeitschriften sind von unterschiedlicher Qualität (kostenpflichtige im Allgemeinen aktueller als kostenlose, dafür u. U. unvollständig) Zu einigen sehr gebräuchlichen Produktgruppen existieren auch Marktübersichten in Büchern (Aktualisierungsdatum von Buch oder beiliegender CD ist besonders zu beachten) 24

25 8.3.3 Vorauswahl von Anbietern 2. Messebesuche Zur Vorbereitung eignen sich insbesondere Webseiten zur Aussteller- und Produktsuche Aussteller- und Produktsuche 25

26 8.3.3 Vorauswahl von Anbietern 3. Internet-Recherche Allgemeine Suche über Suchmaschinen Gezielte Suche in Katalogen zu bestimmten Produktgruppen (auch hier: kostenpflichtige im Allgemeinen aktueller als kostenlose, dafür u. U. unvollständig) 4. Anbieterübersichten Bestimmte Dienstleister geben Produktübersichten zu bestimmten Produktgruppen heraus und unterstützen z. T. Auswahl und Ausschreibung Datenbanken enthalten z. T. mehrere Programme, die mehr oder weniger detailliert beschrieben sind Bezahlung z. B. nach Nutzungsdauer des Datenbestands oder pro genutztem Softwareprofil Achtung: Trotz detaillierter Beschreibung kann keine Endauswahl auf Basis von Anbieterübersichten getroffen werden! 26

27 8.3.4 Anbieterbefragung Ziel: Vorauswahl soll weiter reduziert werden (zum Beispiel von 20 auf drei Produkte) Anbieterbefragung sollte schriftlich erfolgen Dem Anbieter sollte klar sein, dass seine Angaben als verbindlich angesehen werden allgemeine Marketing-Texte reichen in dieser Phase nicht Befragung sollte nicht zu kleinteilig werden, beispielsweise erreichbar durch Reduzierung auf A-Anforderungen Wenn möglich, sollten Antwortmöglichkeiten vorgegeben werden, z. B. in Standardausführung enthalten mit Implementierungsaufwand realisierbar nicht vorgesehen Angemessene Zeitspanne für Antworten sollte gesetzt werden (i. A. unter vier Wochen) Ansprechpartner für Rückfragen des Anbieters sollte genannt werden 27

28 8.3.4 Anbieterbefragung Inhalt der Anbieterbefragung (1/2) Kurzbeschreibung des anfragenden Unternehmens Branchenzugehörigkeit, Mitarbeiterzahl,... Notwendige Informationen zu vorhandenen Hard-/ Softwarearchitekturen Kurzbeschreibung der vorliegenden Problemstellung Gewünschter Einsatzzeitpunkt des Systems Gezielte Fragen zum Anbieter und zu seinem Produkt Stand der angebotenen Software Anzahl existierender Installationen (Unternehmen und Benutzer) Referenzen Architektur des Systems Serviceleistungen Datenbankkonzept, systemübergreifende Funktionalitäten (Schnittstellen) Anforderungen mit A-Priorität, z. B. gegliedert nach: Stammdaten, Prozessen und Querschnittsfunktionen (mit vorgegebenen Antwortmöglichkeiten, s. o.) 28

29 8.3.4 Anbieterbefragung Inhalt der Anbieterbefragung (2/2) Fragen nach Kosten / Richtangebot Lizenzen, ggf. getrennt nach Clients und Server evtl. benötigte weitere Software (z. B. Datenbanklizenz) Schnittstellenprogrammierung Individualanpassungen Beratung (z. B. Erstellung von Spezifikationen, Sollkonzept u. ä.) Customizing Installation und Übernahme von Altdaten Schulungen Wartungs-/Servicevertrag Festpreise oder Aufwandsschätzungen Schätzung des Zeitaufwands für Mitarbeiter des anfragenden Unternehmens (während Einführung und Regelbetrieb) 29

30 8.3.4 Anbieterbefragung Mögliche Gliederung einer Auswertung / Entscheidungsvorlage: Kurzbeschreibung der vorliegenden Problemstellung Executive Summary der folgenden Auswertung ggf. ausführlichere Darstellung des Unternehmens, der Problemstellung für sachfremde Entscheider (z. B. externer Berater) Anforderungen an das Produkt Kurzbeschreibungen der verglichenen Anbieter Kurzvergleich der Lösungen Empfehlung für engere Wahl und weiteres Vorgehen Anhang mit tabellarischer Darstellung aller Antworten Details... 30

31 8.3.4 Anbieterbefragung Anhang der Auswertung / Entscheidungsvorlage sollte mindestens diese Informationen enthalten: Anzahl existierender Installationen (Unternehmen und Benutzer) Referenzen, möglichst aus der gleichen Branche Zusammenfassendes Urteil über Erfüllung der Anforderungen z. B. Prozentsatz nach Nutzwertanalyse oder verbales Urteil Kosten der Erstinstallation Kosten der Schulungen Laufende Lizenzkosten Kosten eines Servicevertrags Zusammenfassung von Vorteilen Zusammenfassung von Nachteilen 31

32 8.3.4 Anbieterbefragung Basierend auf der Auswertung werden zwei bis drei Produkte in die engere Wahl gezogen. Faustregeln hierzu: Wesentliche funktionale Nachteile führen zum Ausschluss ( k.o.-kriterien ) Liegen bei ähnlicher Funktionalität deutliche Preisunterschiede vor, führt auch das zu Ausschlüssen Weitere Kriterien, falls immer noch zu viele Produkte im Rennen: Nähe zum Anbieter (im übertragenen Sinn und auch räumlich) Anzahl von Installationen in der gleichen Branche (sollte relativ hoch sein es sei denn, dies ist strategisch nicht beabsichtigt!) Schulungskosten (erlauben u. U. Rückschlüsse auf Komplexität und Benutzungsfreundlichkeit des Produkts) Last and least: Bevorzugte Hardware-/Betriebssystemkombinationen 32

33 8.3.5 Anbieterpräsentation und -bewertung Anbieter, die in die engere Wahl gekommen sind, werden zur Präsentation eingeladen Gefahr: Marketing-Mitarbeiter zeigt Fotos vom Firmengebäude und tausendfach erprobte Produktdemo Wirkliche Ziele der Anbieterpräsentation: Es muss herausgefunden werden, welches Produkt am besten zu den Anforderungen im Unternehmen passt Es müssen Informationen gewonnen werden, die über Prospekte und Standard- Folien weit hinausgehen (und die man zum Teil auch niemals schriftlich bekommen würde!) Im nachfragenden Unternehmen sollen alle betroffenen Bereiche in die Entscheidung eingebunden werden Deshalb sollte die Anbieterpräsentation nicht vom Anbieter, sondern vom Nachfrager vorstrukturiert werden 33

34 8.3.5 Anbieterpräsentation und -bewertung Der Anbieter sollte mindestens zwei Wochen vor seiner Präsentation einen konkreten Leitfaden für diese bekommen: Der Anbieter erhält ggf. detailliertere Angaben zum nachfragenden Unternehmen und der vorliegenden Problemstellung (insbes. genaue Darstellung der Daten und Prozesse, die mit der Standardsoftware verwaltet bzw. unterstützt werden sollen) Außerdem erhält er eine Tagesordnung für die Anbieterpräsentation, aus der klar hervorgeht, wie lange welche allgemeinen Informationen und welche konkreten Funktionalitäten präsentiert werden sollen Pro Anbieter sollte ein halber Tag bis max. ein Tag vereinbart werden (wenn das Projekt nicht sehr komplex ist, sind längere Präsentationen unüblich, zumal diese i. A. nicht in Rechnung gestellt werden) 34

35 8.3.5 Anbieterpräsentation und -bewertung Von Seiten des nachfragenden Unternehmens ist außerdem zu beachten: Alle betroffenen Unternehmensbereiche sollten bei allen Anbieterpräsentationen vertreten sein Es sollten immer die gleichen Personen teilnehmen Eine der Personen im Normalfall der designierte Projektleiter sollte alle Anbieterpräsentationen moderieren Jeder Teilnehmer sollte für jede Anbieterpräsentation einen strukturierten Fragebogen erhalten zu beachten ist hierbei: die auszuwählende Software sollte i. A. nicht ausgerechnet werden die Auswertung der Fragebögen soll die Entscheidungsfindung im Team bzw. im Management unterstützen auch subjektive Meinungen sind erwünscht (um auch Vorbehalte erkennen zu können) 35

36 8.3.5 Anbieterpräsentation und -bewertung Beispiel eines Fragebogens zur Anbieterbewertung nach Gronau (2001): Name des Teilnehmers: Name der Firma/des Produkts: Technologie Programmiersprache Datenbanksystem Software/Allgemein Intuitive Erlernbarkeit Oberflächenergonomie Benutzerführung Performanz Parametrisierbarkeit Software/Prozesse Änderungen Termine/Kosten Auswertungen Versionsverwaltung Genehmigungsverfahren Kosten-Controlling Ursachen v. Budgetabweichungen Bewertung Gewichtung Kommentar

37 8.3.5 Anbieterpräsentation und -bewertung Software/Prozesse Liquiditätsplanung Rechnungseingangsbuch Verwendungsnachweise Sicherheitseinbehalte EURO Hauswährung Qualitative Projektdaten Terminänderungen Grundstücksmanagement Anbieter Beratung Fachkenntnis Projektteam Projektmanagement Zeitplanung Benutzerschulung Dokumentation Notfallkonzept Bewertung Gewichtung Kommentar

38 8.3.5 Anbieterpräsentation und -bewertung... Präsentation Bewertung Gewichtung Akzeptanz durch Teilnehmer Qualität des Workshops Projektkenntnis des Anbieters Qualität der Präsentation Kommentar 38

39 8.3.5 Anbieterpräsentation und -bewertung Zusätzlich zur Anbieterpräsentation sollte die Qualität des Anbieters durch Befragung einiger seiner Kunden bewertet werden Der Anbieter nennt hierzu im Allgemeinen Referenzkunden, u. U. können weitere Kunden recherchiert werden Abzufragende Kriterien können sein (1/3): Erreichbarkeit und Qualität der Anwenderhotline 24/7-Erreichbarkeit? Kompetenz und Schnelligkeit Gesprächsgebühren Nutzungsbeschränkungen (nur für bestimmte Benutzer, Einschränkungen in Ferienzeiten u. ä.) Erfahrungen mit Software-Updates Aufwand für Umstellung auf neues Release Unterstützung des Anbieters Auswirkungen auf individuelle Anpassungen an der Software Änderungen an Stammdaten 39

40 8.3.5 Anbieterpräsentation und -bewertung Abzufragende Kriterien können sein (2/3): Qualität der Dokumentation Erfahrungen während Schulung und im Regelbetrieb Dokumentation firmenspezifischer Prozesse und Berücksichtung individueller Anpassungen gedruckte und/oder elektronische Versionen (unterschiedliche Vor- und Nachteile!) Kompetenz des Beratungspersonals insbesondere während der Einführung der Software Qualität von Schulungen Durchführungsort (wegen Reisekosten, Ausstattung der Schulungsräume, Lernen am Arbeitsplatz oder Ablenkung am Arbeitsplatz?) Lernmaterialien Trainerqualität 40

41 8.3.5 Anbieterpräsentation und -bewertung Abzufragende Kriterien können sein (3/3): Effizienz der Softwareeinführung Projektmanagement von Seiten des Anbieters Termintreue Erfahrungen mit Rechnungsstellung Reklamationen von Rechnungen Unterschiede Angebot/Endabrechnung Kulanzregelungen Seriosität des Anbieters Verlässlichkeit des Anbieters, z. B. bei nicht exakt spezifizierten Aufgaben mündlichen / telefonischen Vereinbarungen Kompromissbereitschaft bei ggf. vorhandenen Streitfällen 41

42 8.3.5 Anbieterpräsentation und -bewertung Ca. zehn Tage nach der Anbieterpräsentation sollten die Anbieter ein aktualisiertes/konkretisiertes Angebot vorlegen Auf Basis von Angebot und Präsentation wird eine Entscheidungsvorlage erstellt, die zumindest zu folgenden Punkten vergleichend Stellung nehmen sollte: Technologie Funktionalität Ergonomie, Erlernbarkeit, Benutzerführung Parametrisierbarkeit Performanz Anbieter Qualität der Präsentation Hierbei sollten die Bewertungen aus den Fragebögen zur Anbieterpräsentation geeignet gruppiert und zusammengerechnet werden (Einzelergebnisse ggf. in einem Anhang) Außerdem: Tabelle mit allen Kosten (s. Inhalt der Anbieterbefragung ) Im Anschluss: Zusammenfassung (als Text), wenn gefordert: mit Entscheidungsempfehlung 42

43 8.3.6 Vertragsgestaltung Problem: Der angestrebte Sollzustand soll vertraglich festgelegt werden, ist zu Beginn einer Softwareeinführung aber oft noch unklar (weil z. B. im Rahmen des Projekts auch bestimmte Prozesse verbessert werden sollen) Sog. Projektverträge sind in dieser Hinsicht offen und enthalten Regelungen zu den folgenden Punkten (angelehnt an Gronau (2001) und Bartsch (2000)): 1. Leistung 2. Vergütung 3. Organisations-/Verfahrensregeln während des Projekts (insbesondere für den Fall des unkorrekten Projektablaufs) nach dem Projekt 43

44 8.3.6 Vertragsgestaltung 1. Beschreibung der zu erbringenden Leistungen Voraussetzung: Ziele müssen im Wesentlichen klar sein ggf. in einer Vorstudie zu klären (wird wegen ihrer Kosten von Kunden oft kritisch gesehen, ist aber u. U. notwendig) Inhalt: Zusicherungen des Auftragnehmers Aufzählung zu erbringender Leistungen Darstellung übergeordneter wirtschaftlicher oder organisatorischer Ziele Andere Formulierung als im Pflichtenheft! Dort: Anforderungen des Auftraggebers Zusicherung eines bestimmten Stands der Technik, der Einhaltung von Normen und Standards u. ä. Zusicherung, bestimmte vom Auftraggeber gewünschte Anpassungen in das Standardprodukt zu übernehmen bringt dem Kunden große strategische Vorteile: niedrigerer Anpassungsaufwand bei Folgeversionen wichtiger Aspekt bei Preisverhandlungen (wegen Vermarktung der Anpassungen bei weiteren Kunden) 44

45 8.3.6 Vertragsgestaltung 2. Regelung der Vergütung Je nach Projekt sind unterschiedliche Vergütungsmodelle möglich: Listenpreise (ggf. mit Rabatt) üblich für Lizenzkosten Preise nach Aufwand üblich für Customizing, Schnittstellenprogrammierung, Schulung Festpreise werden vom Anbieter ungern zugesichert Alternative: Vereinbarung eines Projektbudgets (ist dieses aufgebraucht, muss der Anbieter Gründe nachweisen und im Folgenden z. B. Leistungen zu niedrigerem Stundensatz anbieten) Bei allen Preisen ggf. möglich: Bindung an Erfolgskriterien (z. B.: Verkürzung der Durchlaufzeiten um... ) 45

46 8.3.6 Vertragsgestaltung 3. Organisations-/Verfahrensregeln Zeitplan mit Meilensteinen gilt auch für Auftraggeber, wenn dieser z. B. bestimmte Vorleistungen zu erbringen hat! ggf. Aufteilung in Teilprojekte sinnvoll, wenn diese auch einzeln abgenommen werden können Regeln für Vertragsänderungen, z. B. bei neu auftretenden Anforderungen Benennung verantwortlicher Personen und Regelung von Rechten und Pflichten dieser Personen Regelungen zum Projektablauf, z. B. zu Projektbesprechungen und Projektdokumentationen Regeln zur Projektabnahme Prüfungszeitraum nach Fertigmeldung des Anbieters Fristen zur Nachbesserung 46

47 8.3.6 Vertragsgestaltung 3. Organisations-/Verfahrensregeln (Forts.) Vereinbarungen zur Gewährleistung Vereinbarungen zu erworbenen Rechten im Normalfall: nur Nutzungsrechte an der Software weitere Rechte müssen explizit vereinbart (und bezahlt) werden Auffangregeln für den Fall des Projektabbruchs insbesondere finanzielle Aspekte Gerichtsstand, anzuwendendes Recht u. ä. 47

48 8.3.6 Vertragsgestaltung Zusätzlich zum Projektvertrag wird im Allgemeinen ein Service- und Wartungsvertrag abgeschlossen: Regelungen zur Fehlerbeseitigung (insbes. Reaktionszeiten) Regelungen zur Erstellung neuer Programmversionen z. B. für neue Hardware oder bei geänderten rechtlichen Rahmenbedingungen (typisches Beispiel: Steuerrecht) Serviceleistungen Hotline -Support Kundenbereiche auf Anbieter-Website 48

49 Literatur Bartsch, M.: Qualitätssicherung für Software durch Vertragsgestaltung und Vertragsmanagement. Informatik Spektrum 23 (2000) 1, S Becker, J., Vering, O., Winkelmann, A.: Softwareauswahl und - einführung in Industrie und Handel Vorgehen bei und Erfahrungen mit ERP- und Warenwirtschaftssystemen. Springer Gronau, N.: Industrielle Standardsoftware Auswahl und Einführung. München: Oldenbourg, Stein, T.: PPS-Systeme und organisatorische Veränderungen. Ein Vorgehensmodell zum wirtschaftlichen Systemeinsatz. Berlin u. a.: Springer, Teich, I., Kolbenschlag, W., Reiners, W.: Der richtige Weg zur Softwareauswahl Lastenheft, Pflichtenheft, Compliance, Erfolgskontrolle. Springer,