Wenn Standardsoftware nicht mehr ausreicht: Ein „Build-vs-Buy“-Rahmenkonzept für führende Schweizer mittelständische Unternehmen 

Die meisten „Build-vs-Buy“-Rahmenwerke sind durch Auslassungen irreführend. Sie werden entweder von SaaS-Anbietern verfasst, die die Antwort bereits kennen, oder von Beratern, die unabhängig davon, welche Option sich durchsetzt, das gleiche Honorar erhalten. Sie listen Vor- und Nachteile auf, wägen diese höflich ab und kommen zu einem Ergebnis, das genau das bestätigt, was der Leser ohnehin schon hören wollte. Gerade dann, wenn die Entscheidung schwerfällt, sind sie nutzlos. 

Für Technologieführer in Schweizer mittelständischen Unternehmen ist die Entscheidung fast immer schwierig. Die Standardplattform, die vor fünf Jahren noch zum Unternehmen passte, hat mittlerweile eine Vielzahl von Notlösungen, parallele Tabellenkalkulationen und eine Integrationsschicht angehäuft, die von einem überlasteten Entwickler gewartet wird – und es herrscht eine unterschwellige Unsicherheit darüber, was beim nächsten Anbieter-Upgrade passieren wird. Niemand ist sich sicher, ob das Unternehmen der Standardsoftware entwachsen ist oder ob das Unbehagen einfach der Preis für den Betrieb eines echten Unternehmens ist. Dieser Beitrag bietet einen Rahmen, um den Unterschied zu erkennen. Wir schreiben ihn ausgehend von den Grundprinzipien und nicht aufgrund eines einzelnen anonymisierten Auftrags, denn die Muster sind für jeden offensichtlich, der Schweizer mittelständischen Unternehmen mehr als einmal dabei geholfen hat, diese Entscheidung zu treffen. 

Das Konzept geht nicht davon aus, dass die Lösung in einem Austausch liegt. In den meisten Fällen ist ein Austausch die falsche Entscheidung. Die größere Herausforderung besteht darin, zu erkennen, in welcher Situation man sich befindet. 

Die Passformlücke, die den Punkt markiert, an dem Standardsoftware nicht mehr ausreicht 

Standardsoftware richtet sich an den Durchschnitts-Kunden. Ihr Unternehmen ist kein Durchschnitts-Kunde. 

Bei der Einführung ist die Kluft zwischen den Annahmen der Software und Ihrer betrieblichen Realität noch gering genug, um sie durch Konfiguration auszugleichen. In den folgenden drei bis sieben Jahren entwickeln sich zwei Dinge in entgegengesetzte Richtungen. Ihr Unternehmen investiert in die Reifung seiner Prozesse, die Arbeitsabläufe werden spezifischer, die Anzahl der Integrationen nimmt zu und die Compliance-Anforderungen werden strenger. Die Software hingegen entwickelt sich gemäß der Roadmap des Anbieters weiter und wird für den Durchschnittskunden optimiert, auf den sie schon immer ausgerichtet war. Die Kluft vergrößert sich. 

Irgendwann – und das ist die Schwelle, an der eine bewusste Entscheidung getroffen werden sollte – steigen die Kosten für die Schließung der Lücke innen Die Kosten für ein Standardtool übersteigen die Kosten für eine externe Entwicklung. Schweizer mittelständische Unternehmen erreichen diese Schwelle aus strukturellen Gründen tendenziell früher als Grossunternehmen oder kleinere KMU: Die Prozessspezifität in Schweizer Unternehmen ist oft höher, als es die Plattform vorsieht, während die internen Entwicklungskapazitäten selten gross genug sind, um eine massgeschneiderte Entwicklung kostengünstig zu gestalten. Die Entscheidung fällt in den schwierigsten Bereich. 

Vier Anzeichen dafür, dass Sie maßgeschneiderte Software brauchen – und nicht nur mehr Konfigurationsaufwand 

Ein nützliches Rahmenkonzept muss bis Freitagnachmittag auf eine reale Organisation anwendbar sein. Vier Variablen entscheiden darüber, ob die Reibungspunkte, die Sie spüren, ein echtes Signal sind, echte Anzeichen dafür, dass Sie maßgeschneiderte Software benötigen, oder lediglich die Kosten, die entstehen, wenn man ein ambitioniertes Unternehmen auf einer generischen Infrastruktur betreibt. Drei davon sind Routine. Die vierte entscheidet stillschweigend über die meisten Fälle, und die meisten „Build-vs-Buy“-Rahmenkonzepte messen ihr zu wenig Bedeutung bei. 

Prozessspezifität: Wenn die Notlösungen zum Tagesgeschäft werden 

Wie einzigartig sind Ihre betrieblichen Arbeitsabläufe, und wie allgemein gehalten sind die Annahmen der Software? Der ehrliche Test: Bringen Sie neuen Mitarbeitern bei der Einarbeitung die Software bei, oder zeigen Sie ihnen die Workarounds? Ersteres ist normal. Letzteres bedeutet, dass die Software nicht mehr widerspiegelt, wie die Arbeit tatsächlich erledigt wird, und dass die Ebene der Workarounds zu einem unbezahlten, undokumentierten Schulungsprogramm geworden ist. 

Integrationsfläche: Wenn Middleware eine eigene Roadmap hat 

Wie lange dauert es, ein neues System in Ihren Stack zu integrieren? Wenn die Integration eines neuen Tools früher zwei Wochen dauerte und nun drei Monate in Anspruch nimmt, ist die Standardplattform nicht mehr länger ein Integrationsknotenpunkt, sondern mittlerweile ein Integrationsproblem. Die Middleware ist keine Infrastruktur mehr. Sie hat ihre eigene Roadmap, ihr eigenes Backlog und ihren eigenen Single Point of Failure – meist einen leitenden Ingenieur, der seit zwei Jahren keinen richtigen Urlaub mehr hatte. Eines der deutlichsten Anzeichen dafür, dass Sie maßgeschneiderte Software benötigen, ist, wenn die Integrationsschicht mehr technische Aufmerksamkeit erfordert als die Systeme, die sie verbindet. 

Konfigurationstiefe vs. logische Verzweigung: Die Variable, die still und leise den Ausschlag gibt 

Hier ist die Variable, die stillschweigend über die meisten Fälle von veralteter Software entscheidet und die bei den meisten beschaffungsorientierten Bewertungen völlig übersehen wird. 

Es gibt eine Grenze zwischen legitimer Konfiguration und einer abgezweigten Implementierung der Herstellerlogik, die niemand unterstützen kann. Konfiguration bedeutet, Parameter zu ändern, die der Hersteller für eine Änderung vorgesehen hat. Abzweigen bedeutet, Geschäftsregeln auf eine Weise in die Plattform zu integrieren, die der Hersteller nie beabsichtigt hat, benutzerdefinierte Felder mit Logik zu füllen, Skripte zu verwenden, die das Standardverhalten überschreiben, oder Workflow-Erweiterungen zu nutzen, die von undokumentierten Eigenheiten einer bestimmten Version abhängen. Jeder Anbieter fördert die Konfiguration. Kein Anbieter wird Ihnen sagen, wann Sie die Grenze zur Abspaltung überschritten haben, denn sein Anreiz besteht darin, Sie auf der Plattform zu halten, und nicht darin, Ihnen mitzuteilen, dass die Plattform nicht mehr zu Ihnen passt. 

Ein Fork erscheint immer kostengünstiger als die Entwicklung maßgeschneiderter Software. Das ist jedoch selten der Fall. Drei Kostenfaktoren summieren sich unbemerkt. Erstens wird die Upgrade-Gebühr für jede neue Version des Anbieters zu einem Regressionstest-Projekt, da die Anpassungen auf undokumentierten Grundlagen beruhen. Zweitens führt die Konzentration des Fachwissens dazu, dass die Anpassungen von nur einem oder zwei Ingenieuren erstellt werden und in dem Moment, in dem diese das Unternehmen verlassen, für die Organisation unlesbar werden. Drittens der stille Ausfallmodus: Ein Update des Anbieters ändert ein Verhalten, auf dem die Anpassung beruhte, das System läuft weiter, und sechs Monate lang fließen falsche Daten weiter, bevor es jemand bemerkt. 

Der ehrliche Test: Wenn der Entwickler, der die Anpassungen vorgenommen hat, morgen das Unternehmen verlässt, kann dann jemand anderes diese Anpassungen warten? Wenn die Antwort „nein“ lautet, birgt die Standardplattform bereits das Risiko von kundenspezifischer Software, ohne dass die damit verbundene Disziplin einer entsprechenden Praxis vorhanden ist. Sie zahlen die Lizenz und Der Wartungsaufwand für maßgeschneiderten Code – das Schlimmste aus beiden Welten, ohne die Vorteile einer sauberen Programmierung. 

Regulatorische Anforderungen und Datenstandort: Die Realität der Schweiz als Drittland 

Für Schweizer Unternehmen ist dies keine reine Formalität. Der Drittlandstatus der Schweiz im Rahmen der DSGVO bedeutet, dass der Datenaustausch mit der EU Einschränkungen unterliegt, die die meisten SaaS-Anbieter mit Sitz in den USA durch Standardvertragsklauseln und im Vertrauen auf den guten Willen der Partner bewältigen. Nimmt man das revidierte DSG (revDSG) hinzu, geht es nicht mehr darum, ob der Anbieter Compliance behauptet – das tun sie alle –, sondern darum, ob die Architektur des Anbieters tatsächlich die Datenresidenz in der Schweiz, die Transparenz bei Unterauftragsvergabe und die Prüfpfade unterstützt, die eine Aufsichtsbehörde innerhalb eines Zeitrahmens anfordert, der kürzer ist als der typische Reaktionszyklus des Anbieters. Für von der FINMA beaufsichtigte Sektoren liegt die Messlatte noch höher. Wenn die Antwort des Anbieters lautet: „mit Aufwand und einer Nebenvereinbarung“, passt die Plattform lediglich an Ihre Compliance-Anforderungen an, statt diese zu unterstützen. 

SaaS-Einschränkungen im Mittelstand: Warum Schweizer Unternehmen früher an ihre Grenzen stoßen 

Die vier oben genannten Variablen beschreiben den Mechanismus. Der Schweizer Mittelstand stößt früher auf diesen Mechanismus als seine internationalen Pendants, und zwar aus Gründen, die es wert sind, genannt zu werden. 

Die Grenzen von SaaS im Mittelstand treten aufgrund von drei strukturellen Faktoren früher zutage als bei US-amerikanischen mittelständischen Unternehmen. Erstens ist die operative Spezifität höher; Schweizer Unternehmen haben ihre Prozesse in der Regel über einen längeren Zeitraum hinweg verfeinert, und diese Prozesse wurden nicht so konzipiert, dass sie den Annahmen generischer SaaS-Lösungen entsprechen. Zweitens ist die regulatorische Belastung höher; die Position der Schweiz als Drittland im Hinblick auf die DSGVO, die revFADP und die FINMA-bezogenen Anforderungen verwandeln «Compliance-Reibungsverluste» von einem Randfall in eine architektonische Einschränkung. Drittens sind die internen technischen Kapazitäten geringer als in Grossunternehmen, die Komplexität der Arbeitsabläufe ist jedoch vergleichbar, was bedeutet, dass die Last der Anpassung auf ein Team fällt, das diese nicht ohne Weiteres bewältigen kann. 

Dies ist die Art von SaaS-Einschränkungen, mit denen Führungskräfte im Mittelstand tatsächlich konfrontiert sind: kein dramatischer Plattformausfall, sondern eine schleichende Anhäufung von Integrationsschulden, Konfigurationsabweichungen und Compliance-Workarounds, die die Kapazitäten der Entwickler still und leise von der Produktentwicklung hin zu technischen Routineaufgaben verlagern. 

Standardsoftware vs. massgeschneiderte Software: Wie Schweizer Führungskräfte die Entscheidung angehen sollten 

Die Entscheidung zwischen Standard- und Individualsoftware wird auf dem Schweizer Markt anders interpretiert als in den meisten angloamerikanischen Fachpublikationen und unterscheidet sich sogar vom allgemeineren DACH-Kontext. 

Schweizer mittelständische Unternehmen neigen dazu, Technologieinvestitionen über einen längeren Zeitraum zu bewerten als ihre US-amerikanischen Pendants – nämlich über sieben bis zehn Jahre statt über dreijährige Abonnementzyklen. Sie bevorzugen eine disziplinierte Kapitalausgabenpolitik gegenüber der Bequemlichkeit von Betriebsausgaben, was die Wirtschaftlichkeit von SaaS-Modellen mit wiederkehrenden Lizenzgebühren von Natur aus weniger attraktiv macht, als es die Kalkulationstabelle vermuten lässt. Zudem agieren sie in einem regulatorischen Umfeld, in dem Datenhoheit ein strategischer Vorteil und keine Compliance-Belastung ist, was Individualsoftware in allen Fällen begünstigt, in denen Datenstandort, Kontrolle von Unterauftragsverarbeitern oder spezifische Audit-Anforderungen eine entscheidende Rolle spielen. 

Es geht nicht darum, dass massgeschneiderte Software besser ist. Die Frage «Standardsoftware oder massgeschneiderte Software» ist kein Entweder-oder, und sie als solches zu behandeln, ist der häufigste Fehler bei Technologieentscheidungen im Schweizer Mittelstand. Der Punkt ist, dass die Schweizer Herangehensweise an diese Entscheidung ehrlicher ist. Aus den US-Technologiemedien importierte „Build-vs-Buy“-Rahmenkonzepte gewichten die strukturellen Faktoren, die dazu führen, dass Schweizer Mittelstandsunternehmen die Schwelle früher erreichen, systematisch zu gering. Die Entscheidung verdient die Ernsthaftigkeit, die ihr von Schweizer Führungskräften in der Regel bereits entgegengebracht wird, sowie einen Rahmen, der die Variablen benennt, die tatsächlich von Bedeutung sind. 

Wann sollte man Standardsoftware ersetzen, wann erweitern und wann abwarten? 

Der Nutzen dieses Rahmens liegt in der Richtung, die er aufzeigt. Bewerten Sie jede der vier Variablen informell auf einer Skala von 1 (hohe Übereinstimmung) bis 5 (ständige Reibung, wachsendes Risiko). Es handelt sich hierbei um eine Heuristik, nicht um ein empirisches Instrument. Der Wert liegt nicht in der Gesamtsumme. Der Wert liegt in dem Gespräch, das durch die Bewertung angeregt wird – zwischen Ihnen, Ihrem technischen Leiter und Ihrem Finanzvorstand. 

Es lassen sich drei Bereiche unterscheiden, die sich damit befassen, wann Standardsoftware direkt ersetzt werden sollte. 

Zone 1 – Beibehalten und optimieren. Die Lösung passt wirklich. Es gibt zwar Reibungspunkte, diese lassen sich jedoch innerhalb der Plattform lösen. Widerstehen Sie der Versuchung, das System zu überkonstruieren. Investieren Sie in Integrationsdisziplin, Dokumentation und die technischen Verfahren, die verhindern, dass die Konfiguration in eine Zweigbildung abgleitet. Die meisten Unternehmen in dieser Phase tauschen ihre Lösung zu früh aus, weil das Unbehagen schlimmer erscheint, als es tatsächlich ist. 

Zone 2 – Mit benutzerdefinierten Ebenen erweitern. Der Kern funktioniert. Die Peripherie stößt an ihre Grenzen. Entwickeln Sie gezielte, maßgeschneiderte Software auf Basis der Standardplattform – Analysen, Workflow-Koordination, spezifische Integrationen, kundenorientierte Schnittstellen –, anstatt den gesamten Stack zu ersetzen. Dies ist die häufigste ehrliche Antwort von Schweizer mittelständischen Unternehmen und zugleich die am wenigsten beachtete. Die Wirtschaftlichkeit einer selektiven kundenspezifischen Entwicklung rund um einen stabilen Kern ist in der Regel besser als die eines vollständigen Austauschs. 

Zone 3 – Austausch planen. Die Notlösungen sind zu tragenden Säulen der Infrastruktur geworden. Die Anpassungen bergen Risiken, die niemand beziffern kann. Eine Ablösung ist kein Modernisierungsschauspiel mehr, sondern dient der Risikominderung. Beginnen Sie mit der architektonischen Planung, um zu definieren, was an die Stelle der alten Systeme treten soll, und um einen Migrationspfad festzulegen, der die Kontinuität gewährleistet. Die Frage, wann Standardsoftware ersetzt werden sollte, ist selten eine Frage der Leistungsfähigkeit; es geht vielmehr darum, ob das Risiko einer Fortführung die Kosten einer Umstellung übersteigt. 

Es gibt noch eine vierte ehrliche Antwort, die nicht in die Bewertungsmatrix passt: noch nicht. Wenn Sie gerade mitten in einer M&A-Integration, einem Führungswechsel, einer laufenden behördlichen Einführungsphase oder einer geplanten ERP-Konsolidierung stecken, ist es durchaus legitim, die Entscheidung aufzuschieben. Abwarten ist eine bewusste Entscheidung. Untätigkeit ist es nicht. 

Die eine Frage, die Sie sich stellen sollten, bevor Sie den Schritt wagen, auf Standardsoftware zu verzichten 

Die Entscheidung, etwas gegen die Unzulänglichkeiten von Standardsoftware zu unternehmen, hängt weniger von der Software selbst ab als vielmehr von einer Frage, die sich viele Unternehmen bewusst nicht stellen: 

Wie würde unser Arbeitsalltag aussehen, wenn sich die Software an uns anpassen würde, anstatt dass wir uns an die Software anpassen müssen? 

Für die meisten Schweizer mittelständischen Unternehmen sagt diese Antwort mehr aus als ein ganzes Jahr voller Beratungsberichte. Sie deckt die Prozesse auf, die vom System stillschweigend verzerrt wurden, die Arbeitsabläufe, die nur dazu dienen, die Plattform zu füttern, und die strategischen Fähigkeiten, die zurückgestellt wurden, weil die Software sie nicht unterstützen konnte. 

Unternehmen, die sich diese Frage ernsthaft stellen, treffen andere Entscheidungen als solche, die fragen: „Sollten wir das ersetzen?“ Bei der ersten Frage geht es darum, was das Unternehmen braucht. Bei der zweiten geht es um die Kosten der Software. Nur eine davon führt zu einer Strategie. 

Wenn sich Ihr Unternehmen in dieser Phase der Abwägung befindet – irgendwo zwischen Optimierung und Erneuerung – und nach einem Rahmen sucht, um die richtige Entscheidung zu treffen, dann ist dies genau das Gespräch, das geführt werden sollte, bevor architektonische Entscheidungen getroffen werden.