Wir sind kein Softwarehersteller · wann sich eigene Software wirklich lohnt

Ein Satz, den man von einem Anbieter selten hört: Wir sind kein Softwarehersteller. Wir bauen Spezialsoftware nur dann, wenn sie sich wirklich lohnt, und das ist selten.

Der Satz kostet Umsatz, und genau deshalb steht er hier. Denn die teuerste Software, die ein Unternehmen besitzt, ist fast immer die, die gebaut wurde, weil niemand die Frage gestellt hat, ob sie gebaut werden muss.

Die Voreinstellung lautet: nicht bauen

Eine Eigenentwicklung ist keine Anschaffung, sondern eine Verpflichtung. Sie endet nicht mit der Auslieferung, sondern beginnt dort: Betrieb, Aktualisierung, Fehlerbehebung, Anpassung an geänderte Schnittstellen, Wissen im Kopf von Menschen, die irgendwann das Haus verlassen. Der Bau ist der kleinere Teil der Rechnung.

Deshalb ist die vernünftige Voreinstellung: nicht bauen. Wer davon abweicht, sollte begründen können, warum. Vier Prüfungen reichen dafür, und alle vier müssen bestanden werden, nicht drei von vier.

Prüfung 1: Ist es Ihr Unterscheidungsmerkmal?

Software lohnt sich als Eigenbau nur dort, wo Ihr Verfahren besser ist als das der anderen. Nicht anders, sondern besser, und zwar auf eine Weise, die Kunden bemerken.

Buchhaltung ist das nicht. Zeiterfassung ist es nicht. Dokumentenablage ist es nicht. Das sind gelöste Probleme, und ein Eigenbau erzeugt dort keinen Vorsprung, sondern nur Wartungsaufwand mit dem eigenen Logo darauf.

Prüfung 2: Verbiegt der Standard Ihren Prozess zum Schlechteren?

Standardsoftware zwingt zu Anpassung, und das ist meistens gut. Die Anpassung an ein bewährtes Verfahren ist oft die eigentliche Verbesserung, während der Eigenbau die Eigenheit festschreibt, die man loswerden sollte.

Die Prüfung ist deshalb ernst gemeint: Verbiegt der Standard Ihren Prozess zum Schlechteren, oder verbiegt er ihn nur? Diese Frage lässt sich nur beantworten, wenn man den Prozess vorher aufgeschrieben hat. Wer sie nicht beantworten kann, hat kein Softwareproblem, sondern ein Prozessproblem.

Prüfung 3: Können Sie es über die gesamte Lebensdauer betreiben?

Nicht: Können Sie es bauen lassen. Sondern: Gibt es in fünf Jahren jemanden, der den Quelltext versteht, die Abhängigkeiten aktualisiert und den Fehler am Freitagabend findet? Und wenn diese Person kündigt, gibt es dann eine zweite?

Eine ehrliche Antwort auf diese Frage beendet die meisten Vorhaben, und zwar bevor sie Geld kosten. Das ist der wertvollste Zeitpunkt, um sie zu beenden.

Prüfung 4: Ist der Prozess stabil genug?

Software erstarrt einen Ablauf. Das ist ihr Zweck und ihr Risiko zugleich. Ein Prozess, der sich noch alle paar Monate ändert, ist nicht reif für eine Eigenentwicklung; er ist reif für eine Tabelle und ein Gespräch.

Umgekehrt gilt: Ein Ablauf, der sich seit Jahren nicht verändert hat und viele Male am Tag stattfindet, ist ein guter Kandidat. Häufigkeit und Stabilität, nicht Wichtigkeit.

Was wir stattdessen tun

In den meisten Fällen fällt mindestens eine der vier Prüfungen negativ aus. Dann bleibt eine Aufgabe, die weniger spektakulär und deutlich nützlicher ist: vorhandene Systeme so verbinden, dass die Arbeit dazwischen entfällt.

• Anbinden statt nachbauen: Was das ERP bereits kann, muss nicht ein zweites Mal entstehen. Es muss erreichbar werden.
• Konfigurieren statt programmieren: Eine Rolle mit klaren Rechten und klarer Aufgabe löst überraschend viele Fälle, für die sonst eine Anwendung gebaut worden wäre.
• Befähigen statt binden: Wenn Ihr Team die Konfiguration selbst ändern kann, brauchen Sie uns für die nächste Änderung nicht.

Der dritte Punkt ist der, der uns Aufträge kostet. Er ist trotzdem richtig, weil die Alternative eine Abhängigkeit ist, die irgendwann beiden Seiten im Weg steht.

Und wann bauen wir doch?

Wenn alle vier Prüfungen bestanden sind. Das kommt vor, und dann meist in derselben Lage: Ein fachlich anspruchsvoller Ablauf, für den es kein Standardprodukt gibt, weil zu wenige Häuser ihn haben, aber genug Häuser, dass er sich lohnt. Regulatorisches Meldewesen mit Sonderfällen ist ein Beispiel, eine Prüfstrecke mit eigener Fachlogik ein anderes.

In diesen Fällen bauen wir klein, dokumentieren so, dass ein anderes Team weiterarbeiten kann, und übergeben den Betrieb, sobald er übergeben werden kann. Software, die nur wir betreiben können, wäre für Sie kein Vermögenswert, sondern eine Fessel.

Fazit

Die Frage ist nie „bauen oder kaufen“. Sie lautet: Was an unserem Verfahren ist wirklich unser Verfahren, und was haben wir nur nie hinterfragt?

Wer diese Frage beantwortet, braucht in den meisten Fällen keine neue Software. Er braucht eine saubere Verbindung zwischen den Systemen, die er längst bezahlt hat. Und das ist eine deutlich bessere Nachricht als ein Angebot.