Deutsch

Individualentwicklung vs. Standard

Was ist die beste Lösung für Ihre Technische Redaktion?

CONSULT
Individualentwicklung vs. Standard

Nachdem unser Marketing die Frage an mich herangetragen hatte, ob ich einen Artikel zum Thema "Standardsoftware versus Individualsoftware" schreiben möchte, nagte ich zunächst etwas ratlos an dem imaginierten Bleistift. Sicher, die Frage begegnet uns in der IT häufiger. Zugleich hat sie aber auch den deutlichen Nachteil, dass eine einfache Antwort nicht möglich ist, sie sich also denkbar schlecht für einen Beitrag eignet, nach dessen Lesen man sich – um eine Frage erleichtert – erfreut zurücklehnen kann.

Natürlich gibt es Fälle, in denen die Antwort leichtfällt. Wer ein Office-Programm sucht, wird es vermutlich nicht in Betracht ziehen, dieses selber zu programmieren. Es gibt bereits vorzügliche Produkte auf dem Markt. Ähnlich verhält es sich beispielsweise mit Redaktionssystemen für die Technische Redaktion. Auch hier gibt es großartige Produkte und außer Abenteuerlust kaum eine Rechtfertigung, eine Eigenentwicklung vorzunehmen. Spannend ist hier allenfalls die Frage, welches der verfügbaren Produkte am besten zu den eigenen Anforderungen passt.

Derweil in diesen Fällen die Antwort also naheliegt, wird es komplizierter, wenn es um Software geht, die weniger standardisierte Anforderungen adressiert, und/oder um eine Software, die vielschichtig mit Unternehmensprozessen verbunden ist. In diesem Fall führt eine unpassende Software im schlimmsten Fall z. B. zu Produktionsausfällen und in der Konsequenz zu erheblichen finanziellen Einbußen.

Die Vor- und Nachteile

Schauen wir uns die grundlegenden Vor- und Nachteile der beiden Optionen an, so ergibt sich in etwa das folgende Bild:
(wir haben zur Vereinfachung an den Anfang jedes Punkts eine Bewertung gestellt: "S+" spricht für eine Standardlösung, "I+" spricht für eine Individuallösung)

  • S+ Eine Standardlösung hat unter Beweis gestellt, dass sie funktioniert und den Anforderungen gewachsen ist. Der Investitionsbedarf lässt sich recht zuverlässig ermitteln (was natürlich keineswegs bedeutet, dass er notwendigerweise niedrig ist). Der Einführungszeitraum sollte ebenfalls gut zu kalkulieren sein. Die Planungssicherheit ist vergleichsweise hoch, das Risiko eines grundsätzlichen Scheiterns des Projekts vergleichsweise niedrig. Allerdings zeigen zahlreiche vergebliche Versuche, z. B. ein ERP-System verzweiflungsfrei einzuführen, dass bei komplexer Software ein erhebliches Restrisiko verbleibt. 
  • I+ Andererseits kann eine Standardlösung ihrem Wesen gemäß nicht perfekt auf ein Unternehmen zugeschnitten sein, schließlich zielt sie auf eine Gesamtheit von Anforderungen aus diversen Unternehmen, Branchen etc. Zum Ausgleich bieten allerdings nahezu alle Produkte die Möglichkeit, sie anzupassen, z. B. durch Workfloweditoren oder Script-Programmierung – wodurch gleichzeitig der Einführungsaufwand steigt – unter Umständen bis zur faktischen Nichteinführbarkeit (diesen Hinweis werden Sie allerdings normalerweise in den Marketingbroschüren der Anbieter nicht finden).
  • S+ Eine Individuallösung kann durch Anpassung an die konkreten Prozesse, Produkte, Mitarbeiterwünsche, technologische Vorgaben usw. optimiert werden. Nachteilig sind hier der (üblicherweise) wesentliche höhere finanzielle, zeitliche und emotionale Aufwand sowie, hieraus resultierend, ein erheblich höheres Risiko eines technischen oder ökonomischen Scheiterns des Projekts.
    Hier braucht es also sowohl gute Gründe als auch risikobereite Entscheider – Chancen und Gefahren liegen meist unangenehm nah nebeneinander.

Über diese grundlegenden Aspekte hinaus scheinen mir die folgenden Punkte relevant:

  • S+ Sofern eine Individualentwicklung geplant ist, ist die Frage spannend, ob die bestehenden Unternehmensprozesse wirklich so viel besser als ein Standardprozess sind, dass sie mit Hilfe einer Individualentwicklung konserviert werden sollten. Oder sind sie eher das Produkt eines Zufalls? Ist dieser ggf. vorhandene Vorteil der bestehenden Prozesse so groß, dass unterstellt werden kann, dass die Prozesse auch langfristig nicht geändert werden sollen (eine Individualentwicklung ist selten so flexibel anpassbar, wie es eine Standardsoftware ist)?
  • S+ Ist es überhaupt möglich, die bisher gelebten Prozesse sinnvoll in einer Individualsoftware abzubilden? Häufig stellt sich beim Formalisieren gelebter Prozesse heraus, dass diese eben nicht so klar sind, wie es angenommen wurde ("Eigentlich gehen wir immer so vor … Außer im Fall X, da fragen wir Y, manchmal auch Z oder jemand anderen. Je nachdem."). Stets sollte auch in Betracht gezogen werden, dass der Versuch, informelle Prozesse zu formalisieren, zu erheblichen Konflikten zwischen den Prozessbeteiligten führen kann, mit hieraus resultierenden emotionalen, zeitlichen und finanziellen Erschütterungen. Ein Verweis auf die Notwendigkeiten einer Standardlösung kann der einfachere Weg sein.
  • I+ Umgekehrt kann eine Individualsoftware einen Wettbewerbsvorteil gegenüber Mitbewerbern darstellen. So könnte man etwa argumentieren, dass es sinnvoll ist, verstärkt auf Individualsoftware zu setzen, wenn es sich um Software handelt, mit denen der Endkunde unmittelbar in Berührung kommt (z. B. mobile Apps).
  • I+ Zudem lässt sich der theoretische Vorteil einer Standardsoftware teilweise nicht realisieren, z. B. wenn die Aufwände für Anpassung der Software und Prozessanpassungen im Unternehmen den Aufwand einer Individualprogrammierung schlussendlich deutlich übersteigen. Auch ist die Frage zu klären, wie ein Unternehmen oder eine Abteilung zeitgleich eine neue Software und auf die neue Software angepasste Prozesse einführen kann, ohne dass die Produktion Schaden nimmt.
  • I+ Schließlich kann die Universalität einer Standardlösung zu einer erheblichen Komplexität des Gesamtsystems führen. Eine Software, die den Anspruch hat, "alle" Anforderungen abzudecken, deckt bezogen auf den Einzelfall üblicherweise viel zu viele Anforderungen ab. Konfiguration, Schulung, Administration, Updates und Verwendung gestalten sich entsprechend umständlich.
  • S+ Gegen eine Individuallösung kann sprechen, dass normalerweise eine erhebliche Mitarbeit auf Kundenseite notwendig ist – für die Spezifikation von Anforderungen, das Begutachten von Prototypen, das Testen der Anwendung. Auch muss initial mit einer erheblichen Anzahl von Fehlern gerechnet werden.

Schlussfolgerung

Was folgt aus alledem? Erstens: Es ist komplex. Zweitens (bisher unausgesprochen und offensichtlich): Es gibt keine strikte Alternative "Individualsoftware" versus "Standardsoftware". Vielmehr stellt sich bei komplexen Systemen die Frage, für welchen Aspekt der Lösung jeweils Standard- oder Individualkomponenten sinnvoll sind.

Was heißt das nun für unsere Branche? Angenommen, wir stehen vor der Aufgabe, das Erstellen einer variantenspezifischen Dokumentation weitgehend automatisieren zu wollen (dieses Szenario eignet sich immer gut für ein Beispiel). Unsere Grundidee ist, dass ausgehend von Informationen, die in diversen führenden Systemen vorhanden sind (SAP, Confluence, Jira, CAD, Dateisystem etc.), sowie aus Inhaltsbausteinen, die in einem Redaktionssystem zu finden sind, Informationsprodukte für verschiedene Zielsysteme erzeugt werden sollen. Die Informationen sollen den Kunden teilweise als mobile Apps zur Verfügung gestellt werden.

Eine mögliche Lösung sieht bei unseren aktuellen Projekten beispielsweise so aus, dass wir im Falle des Redaktionssystems, der Metadatenverwaltung und des Publikationsservers auf Standardsoftware vertrauen. Für die Schnittstellen und die Datentransformation hingegen entwickeln wir eine individuelle Lösung. Im Falle der Schnittstellen liegt das ohnehin aufgrund ihres sehr spezifischen Charakters nahe. Im Falle der mobilen Apps entscheiden wir uns für eine modifizierte Standardlösung. Hiermit erreichen wir, dass die App zwar grundsätzlich den kundenspezifischen Anforderungen entspricht, aber doch schneller zu realisieren und einfacher zu warten ist als eine komplette Neuentwicklung. Unsere Lösung impliziert einen recht überschaubaren Aufwand, zugleich ist die Erfolgswahrscheinlichkeit sehr hoch. Einfach ist diese Lösung deshalb noch lange nicht.

Haben Sie Ideen oder Anregungen zum Thema? Wir freuen uns über Rückmeldungen.

Peter Ritthoff
Autor:
Blog post Peter Ritthoff