Der erste Großkunde macht SaaS-Produktgrenzen sichtbar
Eine zusätzliche Bestellfreigabe zeigt im hypothetischen Beispiel, wie Kundenvarianten, gemeinsame Pflege und Produktumfang zusammenhängen.

Ein Unternehmenskunde verlangt eine zusätzliche Freigabe, während andere Kunden mit dem bisherigen Ablauf arbeiten. Für ein SaaS-Team wird damit eine Produktentscheidung sichtbar: Gehört diese Variante in das gemeinsame Angebot, und wie bleibt sie dort pflegbar?
Das folgende Beispiel ist vollständig hypothetisch. Es beschreibt keine tatsächlich beauftragte Funktion und kein gemessenes Projektergebnis.
Eine Variante als nachvollziehbare Regel beschreiben
Angenommen, das Produkt verarbeitet Bestellungen für die Firmen C10 und C20. Der neue Kunde benötigt die Freigabe durch eine weitere berechtigte Person. Die bestellende Person darf ihre eigene Bestellung nicht freigeben. Für den anderen Kunden soll der bisherige Weg bestehen bleiben.
Firma | Gewünschter Ablauf | Erwartete Prüfung bei einem gemeinsamen Update |
|---|---|---|
| Nach dem Absenden auf unabhängige Freigabe warten | Selbstfreigabe wird abgewiesen; nur die zulässige weitere Person kann freigeben |
| Bestellung ohne zusätzlichen Freigabeschritt verarbeiten | Der bisherige Ablauf funktioniert weiter und erhält keine fremde Freigabepflicht |
Ob eine verwaltete Kundeneinstellung diese Variante sinnvoll trägt, hängt vom Produktmodell ab. Im Beispiel wäre sie prüfbar: Die Regel, ihr Geltungsbereich und das erwartete Verhalten beider Kunden sind benannt.
Die Sonderlösung hat einen weiteren Lebensweg
Eine nur auf den Kundennamen zugeschnittene Codekopie muss künftig ebenfalls korrigiert, getestet und aktualisiert werden. Wir würden deshalb zuerst untersuchen, ob die Anforderung als klar begrenzte Variante im gemeinsamen Produkt tragfähig ist. Das ist eine bedingte Empfehlung, keine Pflicht, jede Ausnahme zur Einstellung zu machen.
Verlangt der Kunde einen grundlegend anderen Prozess mit eigener Pflege und Unterstützung, kann eine gesonderte Lösung die bewusst gewählte Entscheidung sein. Umfang und Verantwortung sollten dann ebenso ausdrücklich vereinbart werden. Dedizierte Ressourcen oder getrennte Bereitstellungen erfordern dabei nicht automatisch eine andere Produktcodebasis.
Funktion, Anspruch und Datenzugriff auseinanderhalten
Ein Feature Flag kann bei einer zeitlich begrenzten Einführung helfen. Eine dauerhaft vereinbarte Leistungsberechtigung braucht jedoch eine passende Verwaltung und Durchsetzung. Ebenso ersetzt ein aktivierter Funktionsschalter keine Prüfung, wer für welche Firma freigeben darf.
Für das Beispiel müsste ein Update die Freigabevariante und den unveränderten Ablauf prüfen. Entscheidend ist die nachvollziehbare Produktregel samt Pflegeaufwand; die erste Kundenbitte allein entscheidet noch nicht über die Architektur.
Quellen
Geschrieben von
- Katharina WeberRedakteurin für Software und TechnologieKatharina Weber betreut bei ASES die Beiträge zur Softwareentwicklung. Sie schreibt über Fragen, die Unternehmen bei der Auswahl von Software, der Entwicklung neuer Anwendungen und der Modernisierung bestehender Systeme beschäftigen.
Weiterlesen
Alle Beiträge



Softwareentwicklung mit ASES
Individuelle Software, Web- und Mobile-Apps



