Was macht eine Software zum Software-Produkt?

Als Gerichts- und Privatgutachter bin ich in meiner Sachverständigenpraxis naturgemäß häufig mit Fällen konfrontiert, in denen Firmenkunden ein Software-Produkt mit zugehörigem Einführungsprojekt bestellt haben und dann mit dem Ergebnis unzufrieden sind. Über die Gründe und Verantwortlichkeiten für einen solchen Misserfolg kann man im Einzelfall immer trefflich streiten und es gibt sicherlich keine pauschale, fachliche Antwort auf die „Schuldfrage“.

Allerdings hat sich über eine ganze Reihe von Fällen hinweg in letzter Zeit zunehmend ein Problembild herauskristallisiert, das man im Informatiker-Denglisch als „not yet a product"-Syndrom bezeichnen könnte. Dabei versucht ein Anbieter, der typischerweise bisher sehr erfolgreich Software-Projekte für seine Kunden durchgeführt hat, auf Basis seiner Projekterfahrungen zum ersten Mal ein eigenes Software-Produkt zu vermarkten. Die Entwicklung und Vermarktung eines echten Software-Produkts stellt ein Unternehmen jedoch vor ganz andere technische und organisatorische Herausforderungen als die erfolgreiche Durchführung von einzelnen, kundenindividuellen Projekten. Diese Herausforderungen stelle ich im Folgenden kurz vor. Jedoch zunächst:

Erkennungszeichen des „Not yet a product“- Syndroms in Projekt-Schieflage

Die fünf typischen Symptome (einzeln oder in Kombination) sind:

• Kundenindividuelle Anpassungen werden als neue Produktversionen ausgeliefert.
• Die gelieferte Software ist, obwohl vermeintlich ein Produkt, noch stark fehlerbehaftet.
• Bei Neuinstallationen im Rahmen von Fehlerbehebungen hat die Software plötzlich neue, nicht bestellte Features und andere funktionale Änderungen.
• Es gibt keine nennenswerte Dokumentation des Funktionsumfanges.
• Ein Upgrade auf eine neue „Major“-Version des Produkts ist nicht möglich.

Diese Symptome sind ein Anzeichen dafür, dass der Anbieter seine internen Prozesse und Strukturen (noch) nicht auf die nachhaltige Entwicklung und Pflege von Software-Produkten umgestellt hat und sich das Gesamtprodukt inklusive aller Kundenanpassungen eher wie ein einzelnes oder mehrere reine Individualsoftwareprojekte entwickelt. Diese Vorgehensweise führt typischerweise zu den fünf genannten Symptomen.

Im Folgenden wird der zur Vermeidung dieser Probleme notwendige Schritt von einer Software zum Software-Produkt erläutert.

Was unterscheidet ein „echtes“ Software-Produkt von anderer Software?

Der wesentliche (und triviale) rechtliche Unterschied zwischen Individualsoftware und Produktsoftware ist, dass das herstellende Unternehmen seinen Kunden auf jeden Fall nur die nicht-ausschließlichen Nutzungsrechte an seinem Software-Produkt überlässt. Auch wird häufig der Sourcecode nicht mitgeliefert, so dass eine Escrow-Vereinbarung zur Absicherung des Kunden angeboten werden sollte.

Damit ist es aus technischer und organisatorischer Sicht aber noch lange nicht getan. Insbesondere in den folgenden Bereichen muss eine „Produkt-Firma“ gänzlich anders agieren als einen „Projekt-Firma“:

a)      Schaffung von technische Anpassungs- und Erweiterungsmöglichkeiten in der Software

Selten passt eine Software sofort und dauerhaft zu einem Kunden. Gerade ERP-Software (ERP = Enterprise Ressource Planning) wird häufig aufwändig an die besonderen Geschäftsprozesse und Firmenspezifika angepasst. Um nicht für jeden Kunden eine eigene Produktversion verwalten zu müssen, haben Produkte häufig wohldefinierte Anpassungs- und Erweiterungsmöglichkeiten, bis hin zu produktspezifischen Programmiersprachen (z.B. ABAP bei SAP), die einen stabilen, über längere Zeit unveränderlichen Produktkern bei gleichzeitiger Flexibilität in Kundenprojekten erlauben. Folglich kann man bei der Entwicklung einer Produkt-Software einiges falsch machen:

• Keine Trennung zwischen Kernprodukt und Anpassung:  Die Entwicklung einer anpassbaren Software geht typischerweise weit über die Anforderungen in Individualsoftwareprojekten hinaus und erfordert gänzlich andere Fähigkeiten und Technologien. Sind keine angemessenen Anpassungsmöglichkeiten gegeben, wird entweder die Software nicht von den Kunden angenommen oder es entsteht pro Kunde ein Individualsoftwareprojekt, das aber nie wieder mit vertretbarem Aufwand auf eine neuere Produktversion gehoben werden kann, da Anpassungen und Kernprodukt untrennbar vermischt sind.
• Alle Kundenwünsche werden als Feature der Software implementiert:  Ein weiteres Phänomen in diesem Bereich (siehe „Symptome“ oben), ist, dass alle individuellen Kundenwünsche direkt in neue Produktversionen eingebaut werden, auch wenn die neuen Features von anderen Kunden nicht gewünscht und daher irritierend sind.

Ein weitergehender Überblick über effektive Konzepte zur Anpassbarkeit für Software an unterschiedliche Kunden ist einem zukünftigen Blog-Beitrag vorbehalten.

b)      Komplexes Versions- und Konfigurationsmanagement

Ein Software-Produkt hat typischerweise eine aktuelle Version, die gerade vermarktet wird. Dennoch müssen auch Fehler und insbesondere Sicherheitslücken in älteren Versionen der Software behoben werden, solange diese noch bei Kunden installiert sind und der Umstieg auf die neueste Version nicht möglich oder nicht gewünscht ist. Um diese Evolution der verschiedenen Versionen korrekt zu verwalten und insbesondere auch dafür zu sorgen, dass Fehler in allen bei Kunden aktiven Versionen der Software behoben werden, benötigt man ein ausgefeiltes Versions- und Konfigurationsmanagement. Insbesondere wenn im Rahmen von Kundenwünschen auch wieder Software (z.B. als Erweiterung über eine genau definierte API) programmiert wird, müssen Produktversion, Erweiterungsversion und der aktuelle Stand der Produktanpassungen präzise verwaltet und zueinander in Relation gesetzt werden können. Beispielsweise muss für eine programmierte Erweiterung genau nachgehalten werden, mit welcher Produktversion diese Erweiterung kompatibel ist.

c)       Komplexes Servicemanagement

Analog zum Versions- und Konfigurationsmanagement stellt sich auch der Service zur Software (Wartung und Pflege) bei einem Software-Produkt ungleich komplexer dar. Eine Anfrage am Service-Desk bezieht sich dabei immer auf eine bestimmte, ggf. auch ältere Version des Produkts und resultiert in komplexeren Bearbeitungsprozessen.

Es stellt sich beispielsweise aus technischer Sicht die Frage, ob ein Problem im Produkt oder in den kundenindividuellen Anpassungen vorliegt. Die Lösungen können je nach Problemursache von verschiedenen Abteilung geliefert werden (Produktentwicklung vs. Professional Services), so dass eine passende abteilungsübergreifende Koordination des Service aufgesetzt werden muss.

d)      Trennung von Produktweiterentwicklung und projektbasierter Einführung

Während das Versions-, Konfigurations- und Servicemanagement das technische Grundhandwerkszeug des IT-Produktherstellers darstellt, sollte dieser auch eine nachhaltige Strategie zur Produktweiterentwicklung haben:

Der Erfolg eines Produkts am Markt wird bestimmt die weichenstellende Differenzierung,

• welche Anforderungen in neue Produkt-Features resultieren und
• welche Anforderungen eher kundenindividuell als Erweiterungen und Anpassungen umgesetzt werden sollten.

Für Kunden besteht die Attraktivität des Kaufs einer Produkt-Software im kostengünstigen Erwerb von weitgehend passenden Standardfeatures, deren Entwicklungskosten effektiv über alle Kunden verteilt werden. In der passenden Auswahl und Evolution der Standardfeatures eines Produkts besteht die Kunst der Entwicklung eines langfristig erfolgreichen Software-Produkts.

Fazit

Die unter a) - d) genannten zusätzlichen Herausforderungen beim Schritt von der „Projekt“- zur „Produkt-Firma“ zeigen deutlich, dass die Entwicklung eines echten Software-Produkts keine trivial Aufgabe ist. Daher ist es auch nicht verwunderlich, dass viele Projekte zur Einführung einer vermeintlichen Produkt-Software an den genannten Symptomen kranken und zum Schaden von Kunden und Produkthersteller nicht nachhaltig funktionieren.

Während es für die organisatorischen Punkte Versions-, Konfigurations- und Servicemanagement weitgehend standardisierte Lösungsansätze gibt (beispielsweise auf Basis ITIL), ist insbesondere die passende Gestaltung der technischen Anpassungs- und Erweiterungsmöglichkeiten zur Trennung von Produktentwicklung und projektbasierter, kundenindividueller Einführung eine schwierige Herausforderung, die aber für den langfristigen Erfolg des Produkts (über mehrere Versionen hinweg) entscheidend ist.