Herausforderungen in der Verhandlung von Software-Entwicklungsverträgen

Auch bei der Beschaffung von Software-Entwicklungsleistungen gilt, dass gute Spezifikationen bzw. Anforderungen spezifisch, messbar, akzeptiert, realistisch und zeitbezogen oder auf Neudeutsch „SMART“ (specific, measurable, accepted, realistic, timely) sind. Weil die vielfältigen funktionalen und nicht-funktionalen Anforderungen nicht immer perfekt „SMART“ sein können, ist das Ergebnis der Dienstleistung Software-Entwicklung trotz der Vielzahl der verfügbaren Metriken und Tools hinsichtlich Qualität und Wert oft schwer zu bewerten. Besonders hier gilt: Masse ist nicht gleich Klasse. Ein kurzer, gut strukturierter Quellcode in einer modernen Programmiersprache ist mehr wert, als ein in einer älteren Programmiersprache geschriebener langer und unübersichtlicher Quellcode – von Software-Entwicklern gerne als „Spagetticode“ bezeichnet.

Ohne Wettbewerb erfolgt die Preisfindung auf Basis der Entwicklungskosten.

Da die Entwicklung von Spezialsoftware oftmals aufgrund von Single-Sourcing Entscheidungen unter langjährigen Programmen und unter Vorliegen von Ausnahmetatbeständen im Sinne des Vergaberechts erfolgt, fällt Wettbewerb als preisbestimmender Faktor oftmals weg. Für die Vertragsverhandlung bedeutet das, dass die Preisfindung auf Basis des Aufwands für die Software-Entwicklung beim Lieferanten erfolgen muss. Dies wiederum erfordert eine gehörige Transparenz über die Kosten- und Preisstruktur beim Lieferanten sowie einige Expertise über Kostenschätzung und ggf. Tools beim Einkaufsteam des Auftraggebers.

Maßgeblich für den Preis von Spezialsoftware sind vor allem die Nutzungsrechte.

Neben der Komplexität von Anforderungen und Software-Architektur sowie der Erfahrung und Effizienz der Programmierer sind die Rechte an der Software maßgeblich für den Preis. Diejenigen Unternehmen, die eigene Ressourcen zur Wartung und Pflege von Spezialsoftware haben, werden auf die Lieferung von Quellcode mit den Rechten zur Eigenwartung oder auch zur Wartung durch Dritte fordern. Diejenigen, die sich aufgrund einer hervorragenden Lieferantenbeziehung ganz auf ihren strategischen Partner verlassen und selbst so gut wie Nichts selber machen, können darauf auch mal verzichten. Alles ist eine Preisfrage.

Die Flexible Lieferantenargumentation. Lieferanten bieten gerne günstige „Commercial of the Shelf“ Produkte, häufig abgekürzt mit „COTS“, also ein quasi Standardprodukt mit wenigen kundenspezifischen Änderungen mit einer in Hinblick auf Eigenwartung, Übertragbarkeit im eigenen Hause und an Dritte eingeschränkten Lizenz an. Einschränkungen der Nutzungsrechte existieren insbesondere für die wiederverwendete, bereits zuvor mit dem Geld anderer Kunden entwickelten „Background“-Software. Vielleicht weil Software kein triviales Produkt und die Kostenschätzung auch für den Lieferanten schwierig ist, kommt es schon mal vor, dass der Anteil der kundenspezifisch entwickelten „Foreground“-Software in der selben Verhandlung durch den Lieferanten je nach Bedarf einmal groß und ein anderes Mal klein dargestellt wird: Bei der Verhandlung des Preises wird auf den großen Entwicklungsaufwand hingewiesen. Bei der Diskussion der Nutzungsrechte werden limitierte Nutzungsrechte mit dem großen Anteil an der Background-Software, die durch viele andere Kunden und den Lieferanten selbst finanziert wurde, begründet. Wenn später das sogenannte COTS-Produkt noch den zehnfachen Anpassungs- und Integrationsaufwand erfordert, bevor es in den operativen Betrieb gehen kann, dann ist das allerdings nicht unbedingt dem Lieferanten zuzuschreiben, sondern oft auch den eben nicht SMARTen Spezifikationen und manchmal unstabilen Anforderungen beim Kunden.

Kostenschätzungsmethoden. Idealerweise ist der Auftraggeber in der Lage, selbst aus den Anforderungen und der Architekturplanung den Aufwand, die Kosten und die Zeit für die Entwicklung der Software abzuschätzen, um dann seine Schätzung mit dem Angebot des Lieferanten zu vergleichen und eine Basis für die Preisverhandlungen zu haben. Als Schätzmethoden kommen die parametrische Kostenschätzung, Expertenschätzung mit Analogiebetrachtung, Parkinsons Gesetz und Design-to-Budget zur Anwendung.

Obwohl die erstgenannten Methoden professioneller erscheinen, kommen die beiden letztgenannten und gelegentlich als unprofessionell verpönten Methoden in der Praxis mindestens genauso häufig zur Anwendung. Parkinsons Gesetz geht davon aus, das sich der Aufwand aus den verfügbaren Ressourcen beim Entwickler und dem für das Projekt vorgegebenen Zeitrahmen ableitet: Bei Verfügbarkeit von fünf Entwicklern und einem Zeitrahmen von zwölf Monaten ergibt sich ein Entwicklungsaufwand von sechzig Personenmonaten. Der Auftragnehmer muss eben seine Mitarbeiter bei diesem Release beschäftigen, damit sie für die Entwicklung des nächsten Releases noch da sind. Eine nicht nur bei amerikanischen Unternehmen mit einer Hire-and-Fire-Kultur beliebte Argumentation. Beim auf der Auftragnehmerseite ebenfalls beliebten Design-to-Budget sorgt der Lieferant mit der mehr oder weniger vom Auftraggeber gewollten Unterstützung dafür, dass der Preis für die Software-Entwicklung zufälligerweise genau dem beim Auftraggeber verfügbaren Budget entspricht. Interessanterweise kommen die zumindest theoretisch professionellsten, nämlich die auf Parametrik basierenden Methoden, bei vielen großen Software-Entwicklungsunternehmen, wenn überhaupt, dann nur unterstützend oder in der Praxis gar nicht zur Anwendung. Expertenschätzung mit Analogiebetrachtungen scheint die Methode der Wahl zur Angebotslegung und Preisverhandlung. Aufwand und Kosten für die meisten Phasen im Software-Entwicklungsprojekt, z. B. für die Erstellung der Dokumentation oder die Durchführung von Tests, werden aus der geschätzten Anzahl der neuen und wiederverwendeten Programmzeilen über den Daumen gepeilt.

Dabei mangelt es nicht an Tools zur parametrischen Kostenschätzung. Auf dem Markt sind solche, die auf einer parametrischen Methode, wie z. B. den funktionsorientierten Function Points basieren oder der größenorientierten COCOMO-Methode basieren und andererseits solche Tools, die die Anwendung diverser Methoden erlauben, zum Beispiel CostXpert. Voraussetzungen für die effiziente und effektive Nutzung dieser Tools beim Auftraggeber sind die Verfügbarkeit von Ressourcen in Einkauf und Technik, die Spezialkenntnisse in der Materie Software-Entwicklung haben und die nicht trivialen Tools regelmäßig anwenden. Ein nicht unerheblicher Aufwand entsteht für die notwendige erste Kalibrierung der Tools, d.h. die Einstellung an das Projekt, die Organisation, die technische Umgebung und die diesbezügliche Aktualisierung der Daten im Tool.

Kleine Datenbank mit großer Wirkung. Wo eine eigene parametrische Kostenschätzung aufgrund des Fehlens der nötigen Ressourcen, fehlender Kostenschätzungstools und Know-how nicht möglich ist, sollte der Auftraggeber zumindest durch den Vergleich mit ähnlichen Projekten im eigenen Hause oder in der Industrie in der Lage sein, den angebotenen Entwicklungsaufwand nachzuvollziehen und auf Plausibilität zu überprüfen. Zur Reduzierung diese Aufwands für die Angebotsanalyse und zur Erhöhung der Effektivität bei der Preisverhandlung reicht manchmal schon eine einfache Excel Datenbank, die auf einem einfachen einheitlichen „Standard“ Kostenaufbruch basiert, nach dem alle Software-Lieferanten ihre Angebotskalkulationen aufzuschlüsseln haben.

Ein einheitlicher Kostenaufbruch sollte generisch genug sein, um alle relevanten SoftwareEntwicklungsprojekte abbilden zu können und er muss mit allen in solche Projekte eingebundenen Fachbereiche, und in gewissem Maße auch mit den wichtigsten Lieferanten, abgestimmt sein. Diese sollen schließlich ihre Angebotsdaten in der vorgegebenen Form zusammenfassen und müssen als strategische Partner die Methodik als Basis für Preisverhandlungen anerkennen.

Solch einheitlicher Kostenaufbruch beinhaltet daher alle typischen Schritte, Aufgaben und Kostentreiber bei Software-Entwicklungsprojekten und bietet die Möglichkeit zur Eingabe von Aufwand pro Mitarbeitertyp und Kosten, bzw. Preisen für diese Elemente. Als wesentliche Kostentreiber sind die angewendeten Programmiersprachen, die vom Lieferanten geschätzte Anzahl der neuen und modifizierten Programmzeilen und, wenn verfügbar, weitere Metriken wie Function Points oder die Anzahl der Systemanforderungen einzugeben. Als Output errechnet das Tool alle möglichen und relevanten Effizienzkennzahlen, wie Kosten pro Programmzeile oder relativer Aufwand pro Mitarbeiterkategorie und Teilaufgabe.

Einfache Plausibilitätsbetrachtungen als Einstieg in die Preisverhandlungen. Diese Kennzahlen können dann von Projekt zu Projekt oder Release zu Release verglichen werden und erlauben Plausibilitätsbetrachtungen und Fragen zum Einstieg und zur Unterstützung der Preisverhandlungen: Warum ist der Testaufwand relativ hoch, obwohl Umfang und Komplexität der Software eher klein sind? Warum setzt der Auftragnehmer bei dieser eher unspektakulären Software vorwiegend die teuerste Entwicklerkategorie ein? Diese Betrachtungen ersetzen zwar nicht die Analyse des detaillierten Kostenaufbruchs durch die Softwareexperten, können aber den Analyse- und Verhandlungsprozess leiten und effizienter gestalten. Zur detaillierten Analyse der Preis- und Kostenstruktur des Lieferanten müssen die Einkäufer darüber hinaus versuchen, Kostenfaktoren wie Zuschläge für Gewinn, Risiko und Verwaltungskosten zu verstehen und zu verhandeln. In der Praxis gewähren aber nur diejenigen Lieferanten Einblick in solche Details, die durch Wettbewerb dazu „motiviert“ werden oder die sich wirklich als strategische Partner verstehen.

Lessons learned. In der Entwicklung strategisch wichtiger Software ist der Einkauf mit einer traditionellen Auftraggeber-Auftragnehmer-Beziehung nicht immer der wirtschaftlichste Ansatz. Die Vertragsparteien sollten sich stattdessen um eine wirkliche strategische Partnerschaft bemühen, in der sich die Beteiligten auch die Risiken angemessen teilen. Basis dafür ist Vertrauen und eine Transparenz bezüglich der Prozesse in Entwicklung und Administration und der Kostenstrukturen. Preisfindungsmethoden und Prozesse sind dann zwischen Auftraggeber und Auftragnehmer abgestimmt. Dazu kann auch verabredet werden, dass bei Nicht-Einigung eine auf parametrische Kostenschätzung spezialisierte Beratungsfirma zur Bestimmung des Zielpreises für den Entwicklungsvertrag zu Rate gezogen wird. Nachträgliche Kostenaudits dienen in einer solchen Beziehung nicht unbedingt zur Kontrolle und zur nachträglichen Preisreduzierung, sondern zur kontinuierlichen Verbesserung der gemeinsamen Prozesse und der Geschäftsbeziehung. Wenn erkannt wird, dass die Anforderungen nicht klar und stabil sind, sollten mit Prototypenentwicklungen auf der Basis von Erstattungspreisen, anstelle von Festpreisen gearbeitet werden. In den Verträgen wird dann gegebenenfalls auch auf Gewährleistung, Vertragsstrafen und Schadensersatz verzichtet, um Aufschläge für den gemeinsamen Blindflug bis hin zur stabilen, SMARTen Spezifikation zu vermeiden.

Lesen Sie zum Thema Einkauf von Software- und IT-Dienstleistung in der Ausgabe auch die Beiträge auf den Seiten 48f. und 62f.