Standardsoftware erweitern oder individuell entwickeln lassen?

Nicht alles neu bauen. Die entscheidende Lücke lösen.

Wenn eine vorhandene Software den Kern eurer Arbeit zuverlässig abdeckt, ist ein kompletter Neubau nicht automatisch sinnvoll. Fehlt nur eine Übergabe zwischen zwei Programmen, kann eine Schnittstelle genügen. Passt dagegen die entscheidende betriebliche Regel in keine verfügbare Lösung, lohnt sich die Prüfung einer individuellen Anwendung. Es gibt also nicht nur „kaufen oder bauen“, sondern auch eine Kombination. GOV.UK beschreibt diese drei Beschaffungswege ausdrücklich. Die Quelle richtet sich an die britische Verwaltung; die folgenden Prüffragen sind unsere praktische Einordnung für Unternehmen, keine Übernahme ihrer Beschaffungsvorschriften.

Originalquelle: GOV.UK zu Kaufen, Entwickeln und Kombinationen

Beschreibt zuerst einen Vorgang — nicht zwanzig Wunschfunktionen.

Nehmt einen typischen Auftrag und zeichnet seinen Weg vom Eingang bis zur Erledigung auf. Wo entsteht die Information, wer entscheidet und welches System enthält den verbindlichen Stand? Trennt echte Muss-Anforderungen von Gewohnheiten. Eine neue Oberfläche löst keine unklare Zuständigkeit. Im GOV.UK Service Manual ist der bestehende System- und Datenkontext ein Ausgangspunkt für Technologieentscheidungen; daraus leiten wir für euren ersten Projektbrief diese Fragen ab:

• Aufgabe: Was muss am Ende des Vorgangs erledigt oder entschieden sein? Zum Beispiel eine Anfrage prüfen, nicht pauschal „alles digitalisieren“.
• Regeln: Welche Mengen, Freigaben, Ausnahmen oder Abhängigkeiten verändern den nächsten Schritt? Welche davon sind wirklich betriebsspezifisch?
• Übergaben: Wer arbeitet nach wem weiter? Welche Angaben müssen dabei erhalten bleiben, ohne erneut eingetragen zu werden?
• Grenzen: Welche vorhandenen Systeme sollen bleiben? Welche Daten sind vertraulich und welche Rollen dürfen sie sehen?

Originalquelle: GOV.UK zur Auswahl von Technologie im bestehenden Umfeld

Drei Wege — mit jeweils einer anderen Grenze.

Die folgenden Kriterien sind eine Orientierung, keine pauschale Rangliste. Entscheidend ist, ob euer konkreter Kernfall funktioniert und der Betrieb dauerhaft tragbar ist.

• Standardsoftware konfigurieren: prüfen, wenn die Kernaufgabe bereits abgedeckt ist und Rollen, Felder oder Abläufe über unterstützte Einstellungen passen. Die Grenze ist erreicht, wenn entscheidende Regeln nur durch ständig gepflegte Umwege funktionieren. Nicht jede bisherige Gewohnheit muss unverändert übernommen werden.
• Standardsoftware gezielt ergänzen: prüfen, wenn das bestehende System bleiben soll, aber ein Anfrageweg, eine Freigabe oder ein Datenaustausch fehlt. Nutzt dokumentierte Erweiterungen oder Schnittstellen, statt ungeprüft in den Produktkern einzugreifen. Die Ergänzung bleibt von den Möglichkeiten und Änderungen des Basissystems abhängig.
• Individuelle Anwendung entwickeln: prüfen, wenn der besondere Ablauf selbst die Kernaufgabe ist und geeignete Produkte ihn nicht ausreichend abbilden. Dafür müssen Regeln, Zuständigkeiten und Abnahme klar sein. Ein eigener Quellcode ersetzt weder Wartung noch Dokumentation oder einen verantwortlichen Betreiber.

„Hat eine API“ ist noch keine funktionierende Verbindung.

Eine API ist eine technische Schnittstelle, über die Programme miteinander kommunizieren. Für euren Ablauf zählt nicht nur, ob sie existiert, sondern was sie tatsächlich lesen und schreiben darf. Die Verbindung muss zum gebuchten Produktumfang, zu euren Rechten und zum erwarteten Datenfluss passen. Diese Punkte gehören vor einer Integrationszusage in die technische Prüfung:

• Inhalt: Sind die benötigten Felder, Dokumente und Bearbeitungsstände über die Schnittstelle verfügbar? Ein Kontakt-Export allein bildet noch keinen vollständigen Auftrag ab.
• Richtung: Welches System führt den verbindlichen Stand? Was passiert, wenn Informationen auf beiden Seiten geändert werden?
• Fehler: Wie werden abgebrochene Übertragungen erkannt, wiederholt und geprüft? Ein wiederholter Versuch darf nicht unbemerkt denselben Vorgang mehrfach anlegen.
• Abhängigkeit: Gibt es Nutzungsgrenzen, zusätzliche Kosten, Versionswechsel und eine dokumentierte Ankündigung von Änderungen? Wer pflegt die Verbindung danach?

Originalquelle: GOV.UK zu API-Dokumentation, Zugriffsrechten und Versionierung

Vergleicht den gesamten Betrieb — nicht nur den Startpreis.

GOV.UK empfiehlt, bei der Technologiewahl die gesamten Besitz- und Betriebskosten sowie spätere Anpassbarkeit zu betrachten. Für euren Vergleich ist ein gemeinsamer Zeitraum sinnvoll, beispielsweise drei Jahre. Das ist eine Planungshilfe, keine Empfehlung für eine bestimmte Vertragslaufzeit. Notiert tatsächliche Angebote und nachvollziehbare Annahmen getrennt. Ein unbekannter Aufwand ist kein Null-Euro-Posten.

• Start: Einführung oder Entwicklung, Datenübernahme, Einrichtung von Rechten, Schulung und Abnahmetests.
• Laufend: Lizenzen nach dem benötigten Umfang, Hosting, Betreuung, Updates, Schnittstellenpflege und interner Arbeitsaufwand.
• Veränderung: neue Rollen, zusätzliche Standorte, geänderte Regeln oder mehr Vorgänge. Welche Anpassungen sind enthalten, welche müssen gesondert beauftragt werden?
• Ausstieg: Export, Übergabe, mögliche Parallelphase und Wechsel in ein anderes System. Welche technischen und vertraglichen Grenzen bestehen?
• Nutzen: Prüft am eigenen Ablauf, ob Rückfragen, doppelte Eingaben oder Wartezeiten tatsächlich zurückgehen. Ohne Ausgangswert sind behauptete Einsparungen keine belastbare Entscheidungsgrundlage.

Originalquelle: GOV.UK zu Gesamtkosten, Anpassbarkeit und Datenkontrolle

Wartung und Sicherheit brauchen einen Namen, nicht nur ein Versprechen.

Bei beiden Wegen sollte feststehen, wer Updates, Zugriffsrechte, Fehlerbehebung und Wiederherstellung verantwortet. Fragt nach dem konkreten Leistungsumfang statt nach dem Etikett „sicher“. Für Webanwendungen bietet OWASP mit dem Application Security Verification Standard eine Grundlage für prüfbare Sicherheitsanforderungen. Das ist kein automatisches Gütesiegel: Welche Anforderungen gelten und wie sie getestet werden, muss zum jeweiligen System passen.

• Welche Rollen dürfen welche Daten sehen und ändern? Wie wird Zugang entzogen, wenn jemand das Team verlässt?
• Wer bemerkt einen Ausfall, wer reagiert und welche Unterstützung ist tatsächlich vereinbart?
• Wer hält Anwendung und Abhängigkeiten aktuell? Wie werden Änderungen getestet und bei Fehlern zurückgenommen?
• Wie werden benötigte Daten gesichert und wiederhergestellt? Gibt es einen geprüften Wiederherstellungsweg und eine aktuelle Dokumentation?

Originalquelle: OWASP ASVS für prüfbare Anforderungen an Webanwendungen

Könnt ihr Daten und Betrieb später wirklich übergeben?

Anbieterabhängigkeit ist nicht allein ein Problem von Standardsoftware. Auch eine individuelle Lösung kann an undokumentierten Regeln, einem einzigen Dienstleister oder bestimmten Cloud-Diensten hängen. GOV.UK beschreibt technische Abhängigkeit als Abwägung zwischen Nutzen und Wechselaufwand, nicht als vollständig vermeidbares Risiko. Unser praktischer Vorschlag: Prüft den Ausstieg schon vor dem Einstieg.

• Lasst euch einen Beispielexport zeigen: Sind benötigte Inhalte, Anhänge und Zuordnungen enthalten und verständlich dokumentiert? Eine Datei allein beweist noch keine erfolgreiche Übernahme.
• Klärt bei Individualsoftware die vereinbarten Nutzungsrechte, Quellcode-Zugänge, Dokumentation und Übergabe des Betriebs. „Individuell“ bedeutet nicht automatisch, dass alles euch gehört.
• Haltet fest, welche Drittanbieter und Lizenzen nötig sind und was bei deren Änderung passiert. Auch offene Software beseitigt nicht jede Abhängigkeit.
• Definiert, wer beim Anbieterwechsel hilft und welche Arbeiten zusätzlich anfallen. Für kritische Teile kann ein begrenzter Übergabetest sinnvoll sein.

Originalquelle: GOV.UK zum Abwägen und Begrenzen technischer Anbieterabhängigkeit

Belegtes Beispiel: der Anfrageweg bei Enke & Sohn.

Für Enke & Sohn hat Klickunst einen Projekt-Konfigurator mit Leistungen und Unterleistungen, regelbasierter unverbindlicher Preisorientierung und einem geschützten Verwaltungsbereich umgesetzt. Der spezielle Anfrageablauf ist der abgegrenzte Baustein: Welche Angaben sind nötig, welche Regeln gelten und wie übernimmt das Team den Vorgang? Das belegt den umgesetzten Umfang, nicht, dass Standardsoftware grundsätzlich ungeeignet wäre. Es ist auch kein Nachweis bestimmter Einsparungen. Für ein anderes Unternehmen müssen vorhandene Systeme und Anforderungen neu geprüft werden.

Referenz: Konfigurator und Verwaltungsbereich für Enke & Sohn

Die nächste Entscheidung: einen schwierigen Kernfall testen.

Bevor ihr das ganze System bestellt, prüft einen kleinen, aber anspruchsvollen Vorgang. Diesen Ansatz empfiehlt auch GOV.UK bei Produkttests. Unser Vorschlag für die Abnahme: Testet denselben Ablauf in den ernsthaft passenden Varianten und haltet fest, was funktioniert, was offen bleibt und wer die offenen Punkte übernimmt. Verwendet dafür Testdaten statt vertraulicher Kunden- oder Mitarbeitendendaten.

• Ein normaler Vorgang funktioniert vom Eingang bis zur Bearbeitung, ohne verlorene Angaben.
• Ein Sonderfall lässt sich bearbeiten oder wird sichtbar zur persönlichen Klärung angehalten.
• Eine fehlgeschlagene Übergabe ist erkennbar und kann kontrolliert wiederholt werden.
• Eine zuständige Person kann den Stand prüfen; Rollen, Export und relevante Änderungen sind nachvollziehbar.
• Umfang, offene Grenzen, Betrieb und Abnahmekriterien sind schriftlich festgehalten. Erst danach über die nächste Ausbaustufe entscheiden.

Originalquelle: GOV.UK zu kleinen Tests mit einem anspruchsvollen Problem