Individualsoftware oder Standardsoftware: woran die Entscheidung hängt

Standard, Konfiguration und Eigenentwicklung bezeichnen drei Ausgangspunkte

Die Grundfrage wird oft als Wahl zwischen zwei Dingen gestellt, obwohl drei Ausgangspunkte zur Auswahl stehen. Standardsoftware ist ein Programm, das ein Hersteller für eine Vielzahl von Betrieben zugleich entwickelt und über Einstellungen an den Einzelfall anpasst. Individualsoftware ist eine für einen einzelnen Betrieb entwickelte Anwendung, deren Datenmodell und deren Eingabemasken den Abläufen genau dieses Betriebs folgen. Dazwischen liegt die angepasste Standardsoftware: dasselbe Fertigprogramm, aber mit eigenen Feldern, eigenen Freigabewegen und programmierten Erweiterungen versehen.

Dieser mittlere Weg ist der häufigste, und er hat viele Abstufungen. Am Anfang stehen Einstellungen, die das Programm selbst vorsieht, etwa Nummernkreise oder Textbausteine. Darauf folgen eigene Felder, eigene Statusketten und schließlich programmierte Ergänzungen innerhalb der Architektur des Herstellers. Wie viele Stufen zwischen der bloßen Einstellung und der tiefen Erweiterung liegen und wo jede endet, ordnen die Wissensbeiträge zu Standardsoftware und Individualsoftware ein. Für die Entscheidung genügt zunächst, dass zwischen den beiden Enden ein ganzes Feld von Anpassungstiefen liegt, aus dem ein Betrieb wählt.

Die Entscheidung hängt daran, wie weit Ihr Ablauf vom Standard abweicht

Jede Standardsoftware bringt eine Annahme darüber mit, wie ein Ablauf üblicherweise aussieht. Ein Angebot entsteht, wird zum Auftrag, der Auftrag wird geliefert und berechnet. Wo der eigene Betrieb dieser Annahme folgt, passt das Fertigprogramm ohne Umbau und zu geringen Kosten. Die Reibung beginnt dort, wo der Ablauf von der Annahme abweicht: bei einer Preislogik, die kein Standardfeld abbildet, bei einer Prüfkette, die das Programm nicht kennt, bei Sonderfällen wie Teillieferungen mit eigener Nachweispflicht.

An dieser Stelle stehen zwei Richtungen offen. Der Betrieb passt seinen Ablauf an das Programm an, oder er passt das Programm an seinen Ablauf an. Die erste Richtung ist billig in der Anschaffung und kann teuer im Alltag werden, wenn ein eingespielter Vorgang künstlich umgebaut wird. Die zweite Richtung kostet in der Umsetzung und zahlt sich aus, wenn der Ablauf ein echter Vorteil des Betriebs ist. Die Größe der Abweichung ist damit die erste Messgröße jeder Softwareauswahl. Sie lässt sich benennen, indem man die eigenen Vorgänge auflistet und zu jedem prüft, ob das Fertigprogramm ihn im Auslieferungszustand abbildet.

Ein Beispiel macht den Unterschied greifbar. Ein Betrieb rechnet seine Preise nach einer Staffel ab, die sich aus Abnahmemenge, Kundengruppe und einer saisonalen Zusatzregel zusammensetzt. Ein Standardprogramm kennt Mengenrabatte und Kundengruppen, die saisonale Zusatzregel jedoch nicht. Jetzt zeigt sich die Feld der Möglichkeiten: Die Regel lässt sich als wiederkehrende Handarbeit außerhalb des Systems führen, sie lässt sich über ein Zusatzfeld und eine angepasste Berechnung im Standard nachbilden, oder sie ist von Beginn an Teil einer eigenen Anwendung. Welche der drei Formen die richtige ist, hängt daran, wie oft die Regel greift, wie oft sie sich ändert und wie viele Arbeitsplätze sie berührt. Erst diese Angaben führen zur Entscheidung; die Regel allein tut es nicht.

Der Anpassungsaufwand wächst mit jedem Schritt weg vom Auslieferungszustand

Das erste Kriterium ist der Aufwand, das Programm auf den eigenen Ablauf zu bringen. Er steigt in Stufen, und jede dieser Stufen erhöht zugleich die spätere Pflege. Eine Einstellung, die das Programm vorsieht, ist schnell gesetzt und übersteht ein Update unverändert. Ein eigenes Feld speichert eine Information, prüft aber nichts und muss von den Mitarbeitenden diszipliniert gefüllt werden. Eine eigene Regellogik nimmt Arbeit ab und braucht dafür eine benannte Person, die sie pflegt, wenn sich die fachliche Grundlage ändert.

Am tiefsten greifen programmierte Erweiterungen ein. Sie erweitern das Programm über das hinaus, was der Hersteller vorgesehen hat, und stehen deshalb bei jedem Update auf dem Prüfstand: Ändert der Hersteller die Grundlage, auf der die Erweiterung aufsetzt, muss sie nachgezogen werden. Ein Fertigprogramm mit sehr vielen tiefen Erweiterungen verhält sich bei Aktualisierungen ähnlich sperrig wie eine eigene Anwendung, ohne deren Vorteil zu bieten, dass alles aus einer Hand stammt und aufeinander abgestimmt ist. Der Anpassungsaufwand ist deshalb eine dauerhafte Größe: Er begleitet die Software über ihre gesamte Nutzung.

Jeder Weg bindet an einen Anbieter, die Wege unterscheiden sich im Ausstieg

Das zweite Kriterium ist die Abhängigkeit vom Anbieter. Sie lässt sich nicht vermeiden, nur bewusst wählen. Wer Standardsoftware einsetzt, bindet sich an den Hersteller: an dessen Produktfahrplan, an dessen Preisgestaltung und an die Möglichkeit, dass ein Produkt eingestellt oder in ein anderes überführt wird. Wer eine eigene Anwendung entwickeln lässt, bindet sich an den Entwicklungspartner, der sie kennt und fortführt.

Der Unterschied zeigt sich im Ausstieg. Bei einer eigenen Anwendung lässt sich der Wechsel zu einem anderen Dienstleister vertraglich offenhalten, wenn drei Dinge gesichert sind: der Zugang zum Quellcode, ein Export der Daten in einem offenen Format und eine Dokumentation, mit der ein Zweiter die Anwendung versteht. Sind diese Punkte geregelt, ist die Bindung eine Frage der Bequemlichkeit und keine des Zwangs. Bei Standardsoftware liegen dieselben Hebel weniger in der eigenen Hand: Der Quellcode bleibt beim Hersteller, und der Wechsel bedeutet einen kompletten Systemwechsel. Wie dessen Datenseite abläuft, beschreibt der Beitrag zur Datenübernahme beim Systemwechsel.

Über eine lange Nutzungsdauer verteilt sich der Aufbauaufwand einer Eigenentwicklung

Das dritte Kriterium ist die erwartete Lebensdauer der Lösung. Eine Eigenentwicklung verlangt einen Aufwand zu Beginn, der danach in eine laufende Pflege übergeht. Dieser Anfangsaufwand rechnet sich, wenn die Software viele Jahre in Betrieb bleibt, weil er sich über diese Jahre verteilt. Bleibt der abgebildete Ablauf über lange Zeit stabil, arbeitet die Anwendung diesen Vorschuss ab.

Umgekehrt spricht ein Ablauf, der sich häufig ändert, für die Standardsoftware. Ihr Hersteller pflegt sie für viele Betriebe zugleich und trägt die Kosten für Aktualisierungen an geänderte Vorschriften oder neue Anforderungen im Verbund. Einen sich ständig wandelnden Vorgang in einer eigenen Anwendung nachzuziehen, bindet dagegen fortlaufend Entwicklungszeit. Für die Entscheidung zählt deshalb zweierlei: wie lange die Software voraussichtlich läuft und wie stabil der Ablauf in dieser Zeit bleibt. Je länger und je stabiler, desto eher trägt der eigene Weg.

Beide Größen lassen sich nicht auf das Jahr genau vorhersagen, und das muss die Entscheidung auch nicht. Es genügt eine begründete Einschätzung: Ein Ablauf, der in einem geregelten Handwerk oder einer eingespielten Fertigung wurzelt, ändert sich langsamer als einer, der an einer jungen, noch beweglichen Geschäftsidee hängt. Wer die Lebensdauer prüft, sieht sich außerdem an, was eine spätere Änderung auslösen würde: eine neue gesetzliche Vorgabe, ein zusätzlicher Vertriebsweg, eine Erweiterung des Sortiments. Sind solche Änderungen absehbar, gehören sie in die Planung, damit die gewählte Lösung sie aufnehmen kann, ohne von Grund auf neu gebaut zu werden. Diese Vorausschau kostet wenig und verhindert, dass eine tragfähige Entscheidung an einer einzigen unbedachten Anforderung scheitert.

Software ohne Dokumentation und Quellcode-Zugang lässt sich nicht übergeben

Das vierte Kriterium ist die Übergabefähigkeit: die Frage, ob ein Zweiter die Software fortführen kann, wenn der Erste ausfällt. Bei Standardsoftware ist die Antwort meist unkritisch, weil viele Dienstleister dasselbe Programm kennen und Fachkräfte dafür am Markt zu finden sind. Bei einer eigenen Anwendung entscheidet sich die Übergabefähigkeit an drei Bedingungen: einer Dokumentation, die Aufbau und Regeln festhält, dem Zugang zum Quellcode und der Abwesenheit von Wissen, das nur in einem einzigen Kopf steckt.

Fehlt eine dieser Bedingungen, wird die Anwendung zum Risiko, sobald die Person oder der Betrieb dahinter nicht mehr verfügbar ist. Dasselbe Muster kennt jeder Betrieb aus der über Jahre gewachsenen Tabellendatei, deren Formeln nur eine einzelne Person versteht; woran sich dort der Zeitpunkt für die Ablösung erkennen lässt, beschreibt der Beitrag zu Tabellendateien als Betriebsrisiko. Die Übergabefähigkeit gehört deshalb von Beginn an in den Vertrag und in die Arbeitsweise; nachträglich lässt sie sich nur mit hohem Aufwand herstellen.

Ein umgangener Standard verursacht laufende Kosten neben der Lizenz

Das fünfte Kriterium sind die Kosten, die entstehen, wenn ein Betrieb den Standard übernimmt, obwohl sein Ablauf davon abweicht, und die Lücke im Alltag umgeht. Diese Kosten stehen auf keiner Rechnung, weil sie sich über viele kleine Handgriffe verteilen: eine Tabellendatei neben dem Programm, in der die eigentliche Logik liegt, eine doppelte Erfassung, weil zwei Systeme nicht miteinander sprechen, eine Rückfrage zwischen zwei Abteilungen, die das Programm nicht auflöst.

Einzeln fällt jeder dieser Handgriffe kaum auf. In der Summe binden sie täglich Arbeitszeit und erzeugen Fehlerquellen an den Übergabestellen. Genau diese laufenden Kosten fehlen im ersten Vergleich, der eine günstige Lizenz gegen einen teuren Eigenbau stellt, und drehen das Bild, sobald man sie über die Nutzungsdauer hochrechnet. Wo ein einzelner, den Betrieb kennzeichnender Ablauf betroffen ist, lohnt sich der Blick auf eine eigene Anwendung, die genau diesen Ablauf abbildet und an die vorhandenen Systeme andockt; dieser Fall ist im Beitrag Software für Abläufe, die es nur bei Ihnen gibt ausgeführt. Die Kosten der Abweichung sind damit das Kriterium, das eine scheinbar teure Entscheidung häufig zur wirtschaftlichen macht.

Fünf Fragen ordnen den Einzelfall zwischen Standard und Eigenbau ein

Die fünf Kriterien lassen sich zu fünf Fragen bündeln, die ein Betrieb vor der Auswahl für sich beantwortet. Keine einzelne Antwort entscheidet allein; das Bild entsteht aus der Summe.

1. Wie weit weicht der Ablauf vom Standard ab? Je mehr Vorgänge das Fertigprogramm im Auslieferungszustand nicht abbildet, desto eher lohnt eine Anpassung oder ein Eigenbau.
2. Wie hoch ist der Anpassungsaufwand über die Nutzung? Neben der Einrichtung zählt die laufende Pflege, die jede Erweiterung bei jedem Update nach sich zieht.
3. Welche Anbieterbindung ist tragbar? Entscheidend ist, ob sich der Ausstieg über Quellcode, Datenexport und Dokumentation offenhalten lässt.
4. Wie lange läuft die Lösung, wie stabil ist der Ablauf? Eine lange Nutzung bei stabilem Ablauf verteilt den Aufbauaufwand und spricht für den eigenen Weg.
5. Was kostet die Abweichung im Alltag? In die Rechnung gehören die Lizenz und die Umwege, die Doppelerfassung und die Rückfragen neben dem Programm.

In der Übersicht ordnen sich die drei Wege entlang dieser Kriterien so:

Fällt die Summe der Antworten in Richtung geringer Abweichung und wandelbarer Abläufe, ist die Standardsoftware der wirtschaftliche Weg. Häufen sich hohe Abweichung, lange Nutzung und ein stabiler, betriebseigener Ablauf, trägt der Eigenbau. Dazwischen liegt der angepasste Standard, den die meisten Betriebe wählen. Die Entscheidung bekommt ein Datum, an dem sie erneut geprüft wird: Ein Ablauf, der heute zum Standard passt, kann in einigen Jahren so weit abweichen, dass sich die Abwägung verschiebt.