Standardsoftware am Limit: Selbst bauen oder kaufen?

Niemand wächst an einem bestimmten Tag aus seiner Software heraus. Es geschieht schleichend, und der erste Hinweis ist nie ein Systemausfall — sondern eine Tabelle.

Jemand exportiert jeden Montag Daten, weil das Berichtsmodul die benötigte Sicht nicht erzeugt. Jemand anderes pflegt eine Parallelliste, weil ein Feld fehlt. Eine dritte Person überträgt Bestellungen von Hand zwischen zwei Systemen, die eigentlich verbunden sein sollten.

Nichts davon erscheint als Softwareproblem. Es erscheint als Personalbedarf.

Die Passungslücke — und warum sie wächst

Standardsoftware ist für den Durchschnitt ihres Marktes gebaut. Genau das macht sie günstig. Je weiter Ihr Prozess von diesem Durchschnitt entfernt liegt, desto mehr der Lücke decken Sie selbst ab — zuerst mit Konfiguration, dann mit Notlösungen, dann mit Personal.

Die Lücke bleibt nicht konstant. Sie wächst, aus zwei Gründen, die sich verstärken:

• Ihr Geschäft verändert sich. Neue Produkte, neue regulatorische Anforderungen, eine Übernahme. Jede Veränderung entfernt Sie weiter vom ursprünglich angenommenen Durchschnitt.
• Das Produkt verändert sich ebenfalls. Anbieter optimieren für ihr grösstes Segment. Gehören Sie nicht dazu, entfernt sich der Durchschnitt mit jeder Version weiter von Ihnen.

Die Frage lautet also nicht «Passt das Produkt heute?», sondern «Wird die Lücke grösser oder kleiner?».

Vier Anzeichen, dass Sie herausgewachsen sind

1. Prozessspezifität — die Notlösung ist zum Prozess geworden

Zwischen einer Notlösung und einem Verfahren besteht ein Unterschied. Eine Notlösung ist vorübergehend, und jemand weiss noch, warum es sie gibt. Ein Verfahren ist dokumentiert, geschult und wird weitergegeben.

Sobald der Excel-Export in einem Einarbeitungsdokument auftaucht, ist die Notlösung zum Prozess geworden. Ab diesem Punkt steuert das Standardsystem den Ablauf nicht mehr; es speichert nur noch Daten für einen Ablauf, der anderswo stattfindet.

Prüfung: Könnte eine neue Mitarbeiterin die Aufgabe allein mit der Software und ihrer Dokumentation erledigen? Braucht die ehrliche Antwort ein «ja, aber», haben Sie ein Spezifitätsproblem.

2. Integrationsfläche — die Middleware hat eine eigene Roadmap

Die meisten KMU betreiben fünf bis fünfzehn Geschäftssysteme. Sie zu verbinden ist normal. Das Warnzeichen ist, wenn das Bindegewebe selbst zu einem System wird — mit eigenen Störungen, eigener Pikettbereitschaft und eigenem Rückstand.

Prüfung: Wenn zwischen zwei Systemen etwas bricht, ist klar, wer die Behebung verantwortet? Lautet die Antwort «kommt darauf an», ist Ihre Integrationsschicht ein undokumentiertes Produkt, das niemand bewusst pflegt.

3. Konfigurationstiefe gegen Logikverzweigung

Konfiguration heisst, die vorgesehenen Optionen zu nutzen. Logikverzweigung heisst, das Produkt zu einem Verhalten zu biegen, für das es nicht gebaut wurde — eigene Skripte in Anbieter-Hooks, zweckentfremdete Felder, Erweiterungen, die Kernverhalten überschreiben.

Verzweigte Logik ist die teure Variante, weil sie bei Aktualisierungen bricht. Teams verschieben daraufhin Aktualisierungen, was Sicherheitsupdates verzögert — und damit aus einer Produktentscheidung eine Risikoentscheidung macht.

Prüfung: Wie lange liegt Ihr letzter grosser Versionswechsel zurück, und lag die Verzögerung an Ihren Anpassungen?

4. Regulatorische Passung und Datenstandort

Hier weichen Schweizer Unternehmen von allgemeinen Ratgebern ab — und hier hört ein globales SaaS-Produkt oft auf, eine neutrale Wahl zu sein.

Nach revDSG/nDSG und, bei EU-Daten, nach DSGVO müssen Sie wissen, wo Daten liegen und wer darauf zugreifen kann. Das sind zwei verschiedene Fragen, und die zweite wird regelmässig übersehen. Ein Anbieter mit Schweizer oder EU-Region braucht trotzdem eine Antwort zum Supportzugriff von ausserhalb, zu seinen eigenen Unterauftragsverarbeitern und dazu, was mit Ihren Daten bei Vertragsende geschieht.

Für FINMA-beaufsichtigte Unternehmen kommt eine weitere Anforderung dazu: ein dokumentierter, belegbarer Ausstiegspfad. «Wir würden migrieren» ist keiner.

Kann ein Produkt diese Fragen nicht beantworten, geht es nicht mehr um Funktionen. Es geht darum, ob Sie das Produkt in einem regulierten Umfeld überhaupt einsetzen dürfen.

Was das nicht bedeutet

Es bedeutet nicht, alles selbst zu bauen. Das teuerste Ergebnis dieser ganzen Diskussion ist ein Unternehmen, das eine Standardfunktion nachbaut — Buchhaltung, Lohn, E-Mail, CRM-Grundlagen — weil ein Bericht fehlte.

Nützlicher ist es, die Systemlandschaft in zwei Teile zu trennen:

• Wo Sie sich vom Wettbewerb unterscheiden — der Prozess, der wirklich Ihrer ist. Hier passt ein Standardprodukt zwangsläufig schlecht, denn gut passen hiesse durchschnittlich sein.
• Überall sonst — kaufen, leicht konfigurieren und nicht mehr darüber nachdenken.

Die meisten KMU haben ein bis zwei Bereiche in der ersten Gruppe. Umfasst Ihre Liste acht, ist die Liste falsch.

Eine Entscheidung, die eine Sitzung übersteht

Vier ehrlich beantwortete Fragen entscheiden:

1. Ist dieser Prozess ein Unterscheidungsmerkmal oder eine Notwendigkeit? Notwendigkeiten werden gekauft.
2. Wächst die Lücke oder schrumpft sie? Eine schrumpfende Lücke ist ein Konfigurationsprojekt, kein Neubau.
3. Was kostet die Notlösung pro Jahr — in Stunden, Fehlern und verzögerten Entscheidungen? Rechnen Sie es um. Eine unbezifferte Notlösung wirkt immer gratis.
4. Kann der Anbieter die regulatorische Anforderung überhaupt erfüllen? Wenn nein, sind die anderen drei Fragen gegenstandslos.

Nur wenn der Prozess ein Unterscheidungsmerkmal ist, die Lücke wächst, die Notlösungskosten spürbar sind und Compliance erreichbar ist, gewinnt das Selbstbauen.

Die mittlere Variante, die gern vergessen wird

Bauen oder kaufen ist ein falsches Entweder-oder. Eine dritte Variante deckt die meisten realen Fälle ab: Das Standardsystem bleibt führendes System, und gebaut wird nur die Schicht, in der Sie sich unterscheiden — eine Ablaufanwendung, ein Integrationsdienst, ein Entscheidungswerkzeug — die daraus liest und dorthin schreibt.

Sie behalten Aktualisierungen, Support und Standardfunktionen des Anbieters. Sie verantworten nur den Teil, der tatsächlich Ihrer ist. Er ist kleiner, günstiger und leichter umkehrbar als eine Ablösung.

So sind die meisten unserer Projekte in der Softwareentwicklung zugeschnitten: kein Neubau, sondern eine sauber gezogene Grenze. Liegt die Grenze an einem Altsystem, das seine Daten nicht sauber herausgibt, steht zuerst die Modernisierung an.

Wenn Sie mitten in dieser Entscheidung stehen und eine zweite Meinung zur Grenzziehung möchten, vereinbaren Sie ein Gespräch. Unverbindlich.