Individualsoftware statt Standardlösung: Wann sich eigene Entwicklung rechnet

Die Frage nach eigener Software stellt sich in Unternehmen selten aus Begeisterung für Technik. Sie stellt sich, wenn etwas nicht mehr funktioniert: wenn die dritte Tabellenkalkulation zur zentralen Datenbank geworden ist, wenn Mitarbeiter Daten zwischen zwei Systemen von Hand übertragen, oder wenn eine Standardlösung nur noch mit Erweiterungen läuft, die niemand mehr überblickt.

Die ehrliche Antwort lautet trotzdem in den meisten Fällen: Standardsoftware zuerst. Sie ist erprobt, sie wird gepflegt, und ihre Kosten sind bekannt. Eigenentwicklung lohnt sich nur unter bestimmten Bedingungen – die sich aber klar benennen lassen.

Werbung

Vier Situationen, in denen Eigenentwicklung sinnvoll wird

• Der Prozess ist der Wettbewerbsvorteil. Wenn ein Unternehmen deshalb erfolgreich ist, weil es etwas anders macht als der Markt, zwingt Standardsoftware es in genau die Abläufe der Wettbewerber.
• Die Anpassungskosten übersteigen den Neubau. Wenn eine Standardlösung nur noch mit umfangreichen Sonderanpassungen läuft, zahlt man Lizenz und Anpassung gleichzeitig – und jede Aktualisierung wird zum Projekt.
• Systeme müssen verbunden werden. Oft ist gar keine große Anwendung nötig, sondern eine schlanke Schnittstelle zwischen zwei bestehenden Systemen. Das ist der häufigste und wirtschaftlichste Fall.
• Die Datenhoheit ist entscheidend. In regulierten Bereichen kann der Betrieb im eigenen Verantwortungsbereich ausschlaggebend sein.

Der teuerste Fehler: zu groß anfangen

Softwareprojekte scheitern selten an schlechter Programmierung. Sie scheitern an Umfang. Ein Vorhaben, das alle Anforderungen aller Abteilungen abbilden soll, hat eine lange Laufzeit, viele Beteiligte und keinen Zeitpunkt, an dem sich zeigt, ob es funktioniert.

Der Gegenentwurf ist unspektakulär: den schmerzhaftesten Teilprozess herausschneiden, ihn in wenigen Wochen produktiv bekommen, mit echten Nutzern arbeiten, dann erweitern. Der Nutzen entsteht früh, das Risiko bleibt begrenzt, und die Anforderungen für den zweiten Schritt werden im Betrieb geklärt statt im Workshop.

Was in den Vertrag gehört

• Rechte am Quellcode. Der Auftraggeber sollte den Code besitzen und Zugang zum Repository haben – ohne Nachfrage, jederzeit.
• Dokumentation als Liefergegenstand. Nicht als Zusage, sondern als Teil der Abnahme.
• Betrieb und Wartung. Wer aktualisiert Abhängigkeiten, wer reagiert bei Störungen, in welcher Zeit?
• Ausstiegsszenario. Was passiert, wenn die Zusammenarbeit endet? Ein Projekt ohne beschriebenen Ausstieg erzeugt eine Abhängigkeit, die sich später nicht mehr verhandeln lässt.

Die laufenden Kosten realistisch ansetzen

Eine eigene Anwendung ist keine einmalige Anschaffung. Abhängigkeiten müssen aktualisiert, Sicherheitslücken geschlossen, Betriebssysteme migriert werden. Wer diesen Aufwand nicht einplant, hat nach drei Jahren eine Anwendung, die niemand mehr anfassen will – und steht vor denselben Fragen wie zu Beginn, nur mit mehr Altlasten.

Als Orientierung hat sich bewährt, für Betrieb und Pflege dauerhaft einen spürbaren Anteil des ursprünglichen Aufwands einzuplanen. Wer das von Anfang an einkalkuliert, trifft eine andere und meist bessere Entscheidung über den Umfang.

Die NexTao GmbH aus Düsseldorf setzt Vorhaben dieser Art um. Programmierung umfasst dort Web-Anwendungen und Schnittstellen zwischen bestehenden Systemen; der Zuschnitt folgt bewusst dem Prinzip, klein zu beginnen und erst nach dem produktiven Einsatz zu erweitern. Wo eine Standardlösung ausreicht, wird das auch so gesagt.

Zwischen Standardlösung und Eigenbau liegt eine dritte Möglichkeit

Die Entscheidung wird gern als Entweder-oder dargestellt. Tatsächlich gibt es eine mittlere Variante, die in vielen Fällen die wirtschaftlichste ist: eine Standardlösung als Grundlage, ergänzt um wenige, klar abgegrenzte eigene Bausteine für genau die Stellen, an denen sich das Unternehmen tatsächlich unterscheidet.

Der Vorteil liegt auf der Hand. Aktualisierungen, Sicherheit und Wartung des Kerns bleiben beim Anbieter, die Eigenentwicklung beschränkt sich auf einen überschaubaren Umfang. Bedingung ist allerdings, dass die Standardlösung eine dokumentierte, stabile Schnittstelle bietet – und dass die eigenen Bausteine sauber davon getrennt bleiben.

Genau daran scheitert die Variante, wenn stattdessen im Kern der Standardsoftware geändert wird. Solche Eingriffe brechen bei der nächsten Aktualisierung, und aus der günstigen Zwischenlösung wird das teuerste aller Modelle: ein System, das weder aktualisierbar noch ersetzbar ist.

Die Vorabfrage, die viel Geld spart

Bevor über Entwicklung gesprochen wird, lohnt eine nüchterne Bestandsaufnahme: Welche Systeme sind im Einsatz, welche Daten liegen wo, und an welcher Stelle entsteht die meiste Handarbeit? In einem erheblichen Teil der Fälle zeigt sich dabei, dass keine neue Anwendung nötig ist, sondern eine Verbindung zwischen zwei vorhandenen.