Die Frage «Standardsoftware oder Individualsoftware?» ist selten rein technisch. Sie entscheidet, ob ein Unternehmen seinen Prozess an ein Produkt anpasst oder die Software an einen bewusst gewählten Prozess. Eine belastbare Antwort entsteht deshalb nicht aus einer Funktionsliste, sondern aus Prozessfit, Integrationslast, Kontrolle, Gesamtkosten und Exit.
Standardsoftware kann der wirtschaftlichere und risikoärmere Weg sein, wenn ihr Modell zum Bedarf passt. Individualsoftware kann richtig sein, wenn der Prozess geschäftskritisch, differenzierend und mit Standardlogik nur durch dauerhafte Umwege abbildbar ist. Dazwischen liegt oft eine konfigurierbare Automation, die bestehende Systeme verbindet. Die Entscheidungsmatrix in diesem Artikel macht diese drei Möglichkeiten prüfbar, ohne einen Sieger vorzugeben.
01 / Entscheidungsobjekt
Nicht Produkte vergleichen, bevor der Sollprozess steht
Ein Anbieter kann nur gegen einen definierten Bedarf bewertet werden. Der Sollprozess beschreibt Eingang, gewünschtes Ergebnis, fachliche Regeln, Ausnahmen, beteiligte Systeme und verantwortliche Rollen. Hinzu kommen nicht verhandelbare Grenzen: Welche Daten dürfen wohin? Welche Entscheidung muss bei Menschen bleiben? Welche Unterbrechung ist akzeptabel? Wie wird bei einem Fehler weitergearbeitet?
Ohne dieses Bild gewinnt meist das Produkt mit der längsten Funktionsliste oder der überzeugendsten Präsentation. Später zeigt sich, dass Mitarbeitende Informationen doppelt pflegen, Ausnahmen ausserhalb des Systems bearbeiten oder kritische Daten nur schwer exportieren können. Das ist kein Einführungsproblem allein, sondern ein fehlender Fit-Nachweis.
Der Vergleich beginnt daher mit einem konkreten Vorgang. «Wir brauchen ein neues CRM» ist zu breit. «Wir wollen qualifizierte B2B-Anfragen vom Eingang bis zur verbindlichen Übergabe an Vertrieb und Projektteam nachvollziehbar steuern» ist prüfbar. Erst danach werden Softwarearten und Anbieter betrachtet.
02 / K.-o.-Gate
Fünf Ausschlussfragen vor jeder Punktbewertung
Ein gewichteter Score kann einen kritischen Mangel verdecken. Deshalb werden zuerst K.-o.-Kriterien geprüft. Scheitert eine Option an einem unverzichtbaren Punkt, wird sie nicht durch gute Werte in weniger wichtigen Kategorien gerettet.
Prozess: Kann der entscheidende Sollablauf ohne unkontrollierte Nebenwege umgesetzt werden?
Daten: Sind Zugriff, Trennung, Export, Löschung und erforderliche Nachweise praktisch möglich?
Kontrolle: Bleiben notwendige Freigaben, Stopps und manuelle Übernahmen wirksam?
Betrieb: Gibt es einen realistischen Störungs-, Support- und Vertretungsweg?
Exit: Kann das Unternehmen Daten und Prozesswissen ohne unvertretbaren Verlust ablösen?
Die Antworten müssen auf Dokumentation, Konfiguration oder einem Test beruhen. «Laut Vertrieb möglich» ist noch kein Nachweis. Ebenso darf eine theoretisch vorhandene Exportfunktion nicht als Exit gelten, wenn das Format den Prozesskontext oder wichtige Beziehungen verliert.
03 / Matrix
Sieben Achsen für Standardsoftware und Individualsoftware
Die Matrix zeigt Signale, keine automatische Empfehlung. Für jede Zeile dokumentiert das Team den eigenen Nachweis und bewertet erst danach, welche Option den Bedarf mit weniger dauerhafter Komplexität erfüllt.
Tabelle auf kleinen Bildschirmen horizontal scrollen.
| Kriterium | Signal für Standardsoftware | Signal für Individualsoftware | Verlangter Nachweis |
|---|---|---|---|
| Prozessnähe | Der Sollprozess lässt sich ohne kritische Umwege in Produktlogik und Konfiguration abbilden. | Der Prozess ist differenzierend und verliert durch Anpassung an das Produkt seinen Kernnutzen. | Abgebildeter Sollprozess mit markierten Abweichungen |
| Änderungstakt | Anforderungen sind relativ stabil und Produkt-Releases können übernommen werden. | Fachlogik ändert sich kontrolliert und muss zum eigenen Releaseplan passen. | Liste erwartbarer Änderungen und verantwortlicher Rollen |
| Integration | Vorhandene Standardschnittstellen decken führende Systeme und Fehlerwege ab. | Spezifische Systeme, Ereignisse oder Transaktionen benötigen eigene Integrationslogik. | Schnittstellenkarte mit Quelle, Ziel, Status und Rückfallweg |
| Daten und Kontrolle | Berechtigungen, Mandantentrennung, Export und Protokolle erfüllen den Bedarf. | Eigene Datenlogik oder Kontrollpunkte sind zentral und im Produkt nicht belastbar umsetzbar. | Datenklassen, Rollen, Nachweise und Löschweg |
| Betriebsfähigkeit | Anbieterbetrieb, Supportmodell und Produkt-Roadmap sind für den Prozess akzeptabel. | Unternehmen braucht eigene Priorisierung, Betriebsfenster oder tiefere technische Kontrolle. | Betriebsmodell mit Störung, Vertretung und Wartung |
| Gesamtkosten | Lizenzen, Einführung, Konfiguration und laufende Nutzung bleiben im erwarteten Umfang tragfähig. | Wiederkehrende Workarounds, Zusatzprodukte oder Nutzungsgebühren übersteigen den Wert des Standards. | TCO-Modell über denselben Betrachtungszeitraum |
| Exit | Daten, Konfiguration und Prozesswissen können in brauchbarer Form exportiert werden. | Eigene Lösung ist nötig, um Abhängigkeit und Übergabe kontrollierbar zu halten. | Praktisch geprüfter Export- und Ablöseplan |
Gewichte werden nicht allgemein vorgegeben. Für einen internen Unterstützungsprozess kann schnelle Einführung wichtiger sein; für einen differenzierenden Kernprozess können Kontrolle und Änderbarkeit dominieren. Die Gewichtung gehört vor die Anbieterbewertung und wird von den verantwortlichen Fach-, Technik- und Betriebsrollen bestätigt.
04 / Standardsoftware
Standard ist stark, wenn Anpassung nicht zum Dauerprojekt wird
Standardsoftware bündelt Produktentwicklung, Wartung, Sicherheitsarbeit und Support über viele Kunden. Das kann Einführung und Betrieb vereinfachen. Der Vorteil bleibt aber nur erhalten, wenn das Unternehmen den Prozess weitgehend mit vorhandener Logik, stabiler Konfiguration und dokumentierten Schnittstellen abbilden kann.
Warnsignale sind zahlreiche Sonderfelder, manuelle Exporte, parallele Tabellen, wiederkehrende Nachbearbeitung und Erweiterungen, die bei jedem Produkt-Release neu geprüft werden müssen. Solche Workarounds wirken anfangs günstiger als Entwicklung, erzeugen aber eine zweite, informelle Softwareebene aus Wissen einzelner Mitarbeitender.
Vor der Entscheidung braucht es deshalb einen realistischen Konfigurationsprototypen. Er enthält Normalfälle, Ausnahmen, Berechtigungen, Export und mindestens einen Fehlerweg. Eine Demo mit vorbereiteten Idealwerten belegt nicht, dass der eigene Prozess im Alltag funktioniert.
05 / Individualsoftware
Individuell ist nur dann ein Vorteil, wenn Eigentum und Betrieb mitgeplant sind
Individualsoftware kann Prozesslogik präzise abbilden, spezifische Systeme integrieren und Änderungen nach eigener Priorität ermöglichen. Sie ist aber kein einmaliger Kauf. Anforderungen, Architektur, Tests, Betrieb, Sicherheit, Dokumentation und Weiterentwicklung bleiben Aufgaben des Unternehmens oder eines klar beauftragten Partners.
Die Entscheidung ist besonders plausibel, wenn der Prozess einen echten Unterschied im Geschäftsmodell schafft, Standardprodukte dauerhaft verbogen werden müssten oder zentrale Kontrollpunkte sonst nicht zuverlässig umsetzbar sind. «Wir möchten unabhängig sein» reicht nicht. Auch eine individuelle Lösung kann von Frameworks, Hosting, Schnittstellen und einzelnen Entwicklern abhängig werden.
Der Nachweis umfasst deshalb Quellcodezugang, Nutzungsrechte, technische Dokumentation, Deploymentweg, Datenexport, Monitoring, Vertretung und Übergabe. Eine massgeschneiderte Oberfläche ohne wartbaren Betriebsweg ist keine belastbare Individualsoftware.
06 / Dritter Weg
Konfigurierbare Automation als Verbindung statt Ersatz
Zwischen Standardprodukt und vollständiger Eigenentwicklung liegt ein häufig sinnvoller Weg: Führende Standardsysteme bleiben bestehen, während eine begrenzte Automationsschicht Daten übergibt, Regeln ausführt und menschliche Freigaben koordiniert. Dadurch wird nicht jedes Fachsystem neu gebaut.
Diese Variante ist geeignet, wenn die einzelnen Systeme den Fachbedarf grundsätzlich decken, aber Übergaben, Status und Ausnahmen nicht zusammenpassen. Sie ist ungeeignet, wenn unklare Datenverantwortung oder ein grundsätzlich falscher Sollprozess nur technisch überbrückt werden sollen.
Auch hier entsteht Betriebspflicht. Schnittstellen ändern sich, Zugangsdaten müssen geschützt, Fehler überwacht und Vorgänge bei Ausfall manuell übernommen werden. Die Automationsschicht braucht daher denselben Nachweis zu Version, Kontrolle und Exit wie andere produktive Software.
07 / TCO
Gesamtkosten über denselben Zeitraum und Umfang vergleichen
Ein fairer Kostenvergleich enthält mehr als Lizenz oder Entwicklungsangebot. Bei Standardsoftware zählen Einführung, Datenmigration, Konfiguration, Zusatzmodule, nutzungsabhängige Gebühren, Integrationen, Schulung, interne Administration und erwartbare Workarounds. Bei Individualsoftware zählen Konzeption, Entwicklung, Infrastruktur, Tests, Wartung, Sicherheitsupdates, Support, Dokumentation und spätere Änderungen.
Beide Optionen benötigen ausserdem eine Wechselperspektive. Welche Aufwände entstehen beim Export, bei der Ablösung von Schnittstellen und bei der Übertragung von Prozesswissen? Ein niedriger Einstiegspreis kann durch dauerhafte manuelle Arbeit oder schwierigen Exit unattraktiv werden. Umgekehrt rechtfertigt eine teure Eigenentwicklung sich nicht allein durch theoretische Flexibilität.
Annahmen werden als Bandbreiten oder Szenarien dokumentiert, nicht als scheinbar genaue Zukunftswerte. Entscheidend ist, welche Kosten sicher bekannt sind, welche vom Nutzungsvolumen abhängen und welche erst ein Pilot klären kann.
08 / Entscheid
Die Entscheidung als prüfbares Briefing abschliessen
Am Ende steht kein anonymer Gesamtscore, sondern ein begründeter Entscheid. Das Briefing nennt Sollprozess, K.-o.-Kriterien, Gewichte, geprüfte Optionen, belastbare Nachweise, offene Annahmen und den kleinsten sinnvollen nächsten Schritt. Abweichende Einschätzungen werden festgehalten, statt sie im Mittelwert zu verstecken.
Entscheidungsakte
- Ein klarer Sollprozess mit Ein- und Ausgang, Regeln und Ausnahmen
- Nicht verhandelbare Daten-, Kontroll-, Betriebs- und Exit-Kriterien
- Nachweise je Matrixzeile statt reiner Anbieterbehauptungen
- Vergleichbarer TCO-Zeitraum und identischer Funktionsumfang
- Prototyp oder Pilot mit Normal-, Ausnahme- und Fehlerfällen
- Benannte Verantwortung für Einführung, Betrieb und spätere Ablösung
- Entscheid: Standard, konfigurierbare Automation, individuell oder bewusst vertagen
Vertagen kann richtig sein, wenn der Sollprozess oder eine kritische Datenfrage noch ungeklärt ist. Eine schnelle Beschaffung ohne Entscheidungsgrundlage ist keine Risikoreduktion. Sie verschiebt die eigentliche Klärung in die Einführung, wo Änderungen teurer und organisatorisch schwerer werden.