Ein Unternehmen sucht eine neue Software und findet zunächst zwei scheinbar eindeutige Angebote: ein sofort verfügbares Produkt mit monatlichen Lizenzen und eine individuell entwickelte Anwendung. Der Preisvergleich ist schnell erstellt. Die eigentliche Entscheidung beginnt allerdings erst dort, wo Vertriebspräsentationen enden: bei den täglichen Abläufen, den vorhandenen Daten und den Menschen, die mit der Lösung arbeiten sollen.

Eine Standardsoftware kann eine ausgezeichnete Wahl sein. Ebenso kann eine kleine individuelle Anwendung mehr bewirken als die Einführung einer umfangreichen Suite. Entscheidend ist, welche Anforderungen tatsächlich unverzichtbar sind und welche Gewohnheiten sich sinnvoll verändern lassen. Dafür braucht es einen Vergleich über den gesamten Lebenszyklus, einschließlich Einführung, Betrieb und späterem Ausstieg.

Zuerst den Prozess verstehen

Bevor Funktionen gesammelt werden, sollte ein konkreter Vorgang beschrieben werden: Wer beginnt ihn, welche Informationen werden benötigt, welche Entscheidungen fallen und wann ist das Ergebnis erreicht? Ein beispielhafter Wartungsauftrag könnte vom Kundenanruf über die Einsatzplanung bis zur Rückmeldung des Technikers reichen. An jedem Übergang entstehen Anforderungen, etwa mobile Erfassung, Freigaben oder die Übergabe an die Abrechnung.

Dabei lohnt die Trennung zwischen gesetzlichen oder vertraglichen Vorgaben, wirtschaftlich wichtigen Besonderheiten und historisch gewachsenen Vorlieben. Ein Feld muss vielleicht aus Nachweisgründen existieren. Die Farbe einer bestimmten Tabellenzeile ist dagegen selten ein guter Grund für eine Individualentwicklung. Erst diese Unterscheidung macht Angebote vergleichbar und verhindert, dass ein neues System lediglich alte Umwege digital nachbaut.

Was Standardsoftware gut kann

Standardprodukte bündeln Anforderungen vieler Anwender. Für verbreitete Aufgaben wie Terminverwaltung, allgemeine Buchhaltung oder einfache Zusammenarbeit ist das oft vorteilhaft: Grundfunktionen sind vorhanden, Schulungsmaterial existiert und der Hersteller entwickelt das Produkt weiter. Ein Unternehmen kann von Verbesserungen profitieren, ohne jede Änderung selbst beauftragen zu müssen.

Der Nutzen hängt jedoch vom konkreten Produkt und Tarif ab. Rollenmodelle, Schnittstellen oder Datenexporte sind möglicherweise erst in höheren Paketen verfügbar. Hinzu kommen Einführungsaufwand und die Pflege von Erweiterungen. Eine Lizenz allein beseitigt keine ungeklärten Prozesse. Im Auswahlgespräch sollten deshalb typische Vorgänge mit eigenen, bereinigten Beispieldaten durchgespielt werden, einschließlich eines Fehlers oder einer nachträglichen Korrektur.

Anpassbarkeit hat verschiedene Formen

Konfiguration, Erweiterung und Änderung am Produktkern sind wirtschaftlich unterschiedlich. Ein konfigurierbares Freigabeverfahren lässt sich meist leichter aktualisieren als eine tiefgreifende Sonderentwicklung innerhalb eines fremden Systems. Fragen Sie nach, welche Anpassungen bei Updates erneut geprüft werden müssen und wer dafür verantwortlich ist. Eine vermeintlich günstige Erweiterung kann langfristig eine beträchtliche Wartungsaufgabe darstellen.

Wann Individualsoftware sinnvoll wird

Eine maßgeschneiderte Anwendung kommt besonders dann infrage, wenn ein wichtiger Prozess mit verfügbaren Produkten nur über viele Medienbrüche abgebildet werden kann. Das betrifft beispielsweise branchenspezifische Kalkulationen, ungewöhnliche Freigabeketten oder eine enge Verbindung vorhandener Fachsysteme. Auch eine bewusst kleine Benutzeroberfläche für einen klar begrenzten Vorgang kann einen eigenen Entwicklungsansatz rechtfertigen.

Der Vorteil liegt in der Gestaltungsfreiheit. Datenmodell, Bedienoberfläche und Integrationen lassen sich auf die tatsächlichen Aufgaben abstimmen. Dafür übernimmt das Unternehmen zusätzliche Verantwortung: Anforderungen müssen entschieden, Änderungen priorisiert und Wartungsleistungen dauerhaft eingeplant werden. Individuelle Software wird durch ihren Quellcode nicht automatisch einfach, sicher oder unabhängig. Entscheidend sind nachvollziehbare Architektur, Dokumentation und eine realistische Betriebsorganisation.

Gesamtkosten statt Einstiegspreis

Ein brauchbarer Vergleich enthält mindestens Einführung, Datenbereinigung, Migration, Schulung, Schnittstellen, Hosting, Support, Updates und Weiterentwicklung. Auch interne Arbeitszeit gehört dazu. Bei Standardsoftware können nutzerabhängige Gebühren, Zusatzmodule und Preisänderungen relevant werden. Bei Individualsoftware entstehen Kosten für Spezifikation, Entwicklung, Tests und technische Pflege. Unterschiedliche Laufzeiten müssen im selben Betrachtungszeitraum verglichen werden.

Eine Beispielrechnung sollte Annahmen sichtbar machen. Wenn Beschäftigte täglich Daten doppelt erfassen, lassen sich Zeitaufwand und Fehlerkorrekturen über einen begrenzten Zeitraum beobachten. Daraus entsteht eine nachvollziehbare Schätzung, keine Erfolgsgarantie. Zu prüfen ist außerdem, ob eingesparte Zeit tatsächlich für andere Aufgaben nutzbar wird. Eine theoretische Minute pro Vorgang ist wirtschaftlich etwas anderes als eine vollständig entfallende Tätigkeit.

Mit Unsicherheit rechnen

Statt einen einzigen vermeintlich präzisen Betrag zu verwenden, sind drei Szenarien hilfreich: geringe Nutzung, erwartete Nutzung und deutliches Wachstum. Ändert sich die Empfehlung bereits durch kleine Abweichungen, braucht die Entscheidung mehr belastbare Daten. Häufig lässt sich diese Unsicherheit durch einen begrenzten Pilotbetrieb günstiger reduzieren als durch zusätzliche Präsentationsrunden.

Die Mischform wird oft übersehen

Viele Unternehmen benötigen weder eine vollständig selbst entwickelte Systemlandschaft noch eine einzige Software für alle Aufgaben. Ein Standardprodukt kann die stabile Grundlage bilden, während eine individuelle Webanwendung einen besonderen Prozess ergänzt. Voraussetzung sind geeignete Schnittstellen, eindeutige Datenverantwortung und eine klare Trennung der Zuständigkeiten.

Ein fiktives Beispiel: Die kaufmännische Abwicklung bleibt in einer vorhandenen Warenwirtschaft. Ein kleines Portal nimmt technische Kundenfreigaben entgegen und übermittelt nur den freigegebenen Status zurück. Damit bleibt die Spezialfunktion überschaubar. Gleichzeitig muss geregelt werden, was bei einer nicht erreichbaren Schnittstelle passiert und welches System im Konfliktfall den verbindlichen Stand enthält.

Abhängigkeiten und Ausstieg planen

Bei beiden Ansätzen können Bindungen entstehen. Ein Standardanbieter bestimmt möglicherweise Exportmöglichkeiten und Vertragsbedingungen. Eine Individualentwicklung kann von einzelnen Personen, unzureichender Dokumentation oder schwer übertragbaren Betriebsumgebungen abhängen. Der Begriff Unabhängigkeit sollte deshalb an überprüfbare Voraussetzungen geknüpft werden.

Dazu gehören ein lesbarer Datenexport, dokumentierte Zugänge und Schnittstellen, geregelte Nutzungsrechte sowie ein Wiederherstellungsverfahren. Lassen Sie einen beispielhaften Export vorführen und prüfen, ob Beziehungen, Anhänge und Statusinformationen enthalten sind. Bei Individualsoftware sollten Quellcodeverwaltung, Bauanleitung, Abhängigkeiten und Übergabeunterlagen vereinbart werden. Ein zweites Team muss den Betrieb grundsätzlich übernehmen können, ohne den gesamten Prozess neu zu erraten.

Eine Entscheidungsvorlage, die im Alltag trägt

  • Beschreiben Sie drei bis fünf typische Vorgänge und mindestens einen Ausnahmefall.
  • Gewichten Sie unverzichtbare Anforderungen und überprüfbare Qualitätsziele.
  • Vergleichen Sie Gesamtkosten mit denselben Annahmen und Zeiträumen.
  • Prüfen Sie Datenexport, Rechte, Schnittstellen und Wartungsverantwortung.
  • Vereinbaren Sie einen Pilot mit klaren Abnahmekriterien.

Die Entscheidung muss außerdem organisatorisch getragen werden. Wer den Einkauf verantwortet, kennt nicht automatisch die Probleme in Lager oder Service. Beteiligen Sie deshalb Personen, die täglich mit den Daten arbeiten. Ein kurzer Test mit realistischen Aufgaben zeigt oft mehr als eine lange Funktionsliste. Beobachtet werden sollten Suchwege, Fehlermeldungen und die Verständlichkeit von Statuswechseln.

Den Pilot mit einer klaren Abnahme beenden

Ein Pilot ist nur dann eine Entscheidungshilfe, wenn vorher feststeht, was geprüft wird. Für den beschriebenen Wartungsauftrag könnten das die vollständige Erfassung, eine Vertretungsübergabe und die nachvollziehbare Übergabe an die Abrechnung sein. Zusätzlich wird ein absichtlich unvollständiger Vorgang durchgespielt. Beobachtet wird, ob das System verständlich erklärt, was fehlt und wer handeln muss.

Die Teilnehmenden sollten ihre Aufgabe möglichst ohne laufende Erläuterung durch den Anbieter erledigen. Sonst wird eher die Qualität einer Präsentation als die Bedienbarkeit der Software bewertet. Rückmeldungen werden nach Schwere geordnet: Ein ungeklärter Berechtigungsfehler hat eine andere Bedeutung als ein unpassender Abstand zwischen Feldern. Für jede notwendige Korrektur werden Zuständigkeit und erneute Prüfung festgelegt.

Auch ein negatives Ergebnis kann nützlich sein. Vielleicht erfüllt ein Standardprodukt die wesentlichen Anforderungen, sobald ein bisher unnötiger Sonderweg entfällt. Vielleicht zeigt sich umgekehrt, dass ein entscheidender Prozess nur mit tiefen Anpassungen funktionieren würde. In beiden Fällen hat der Pilot die Unsicherheit verringert. Die Entscheidung kann dann anhand beobachteter Vorgänge begründet werden, statt auf dem allgemeinen Eindruck einer Funktionsliste zu beruhen.

Vor einer langfristigen Bindung sollten die Ergebnisse schriftlich zusammengeführt werden. Dazu gehören offene Risiken, erwartete Folgekosten und die Voraussetzungen des Betriebs. So bleibt später erkennbar, unter welchen Annahmen die Auswahl getroffen wurde.

Ein passender nächster Schritt

Individualsoftware lohnt sich, wenn der Nutzen einer gezielten Anpassung ihren Entwicklungs- und Betriebsaufwand rechtfertigt. Standardsoftware passt, wenn sie die wesentlichen Aufgaben zuverlässig abdeckt und die verbleibenden Anpassungen beherrschbar sind. Eine kombinierte Lösung kann beide Stärken verbinden. Keine dieser Varianten ersetzt saubere Daten und klare Verantwortung.

GRITTMANN kann die technische Bestandsaufnahme und die Konzeption einer begrenzten Anwendung unterstützen. Ein sinnvoller Einstieg ist ein gemeinsam beschriebener Geschäftsprozess mit nachvollziehbaren Anforderungen, bevor über Frameworks oder Bildschirmmasken entschieden wird. Ein anschaulicher Ausgangspunkt sind unsere fiktiven Software-Anwendungsbeispiele.

Quellen und weiterführende Dokumentation

Fachliche Grundlagen und ergänzende Hinweise der jeweiligen Herausgeber. Links zuletzt geprüft am 16.02.2026.