De eerste grote klant toont de grenzen van het SaaS-product
Een denkbeeldige extra bestelgoedkeuring verbindt klantvarianten met gezamenlijk onderhoud en de omvang van het product.

Een zakelijke klant vraagt om extra goedkeuring terwijl andere klanten het bestaande proces gebruiken. Voor een SaaS-team wordt een productbeslissing zichtbaar: hoort deze variant bij het gezamenlijke aanbod, en hoe blijft die daarin onderhoudbaar?
Het volgende voorbeeld is volledig hypothetisch. Het beschrijft geen werkelijk bestelde functie of gemeten projectresultaat.
Een variant als navolgbare regel beschrijven
Stel dat het product bestellingen voor bedrijven C10 en C20 verwerkt. De nieuwe klant verlangt goedkeuring door een andere bevoegde persoon. De besteller mag de eigen bestelling niet goedkeuren. Voor de andere klant moet de bestaande route blijven gelden.
Bedrijf | Gewenst proces | Verwachte controle bij een gezamenlijke update |
|---|---|---|
| Na inzending op onafhankelijke goedkeuring wachten | Zelfgoedkeuring wordt geweigerd; alleen de bevoegde andere persoon kan goedkeuren |
| Bestelling zonder extra goedkeuringsstap verwerken | Het bestaande proces blijft werken en krijgt geen goedkeuringsplicht van de andere klant |
Of een beheerde klantinstelling deze variant zinvol kan dragen, hangt af van het productmodel. In dit voorbeeld zou die toetsbaar zijn: de regel, het bereik en het verwachte gedrag voor beide klanten zijn benoemd.
Een aparte oplossing heeft ook een toekomst
Een codekopie die alleen op een klantnaam is toegesneden, moet later ook worden hersteld, getest en bijgewerkt. We zouden daarom eerst onderzoeken of de eis als duidelijk begrensde variant in het gezamenlijke product houdbaar is. Dat is een voorwaardelijke aanbeveling, geen plicht om elke uitzondering tot instelling te maken.
Vraagt een klant om een fundamenteel ander proces met eigen onderhoud en ondersteuning, dan kan een aparte oplossing een bewuste keuze zijn. Omvang en verantwoordelijkheid moeten dan expliciet worden afgesproken. Eigen resources of afzonderlijke uitrol vereisen niet automatisch een andere productcodebasis.
Functie, aanspraak en gegevenstoegang scheiden
Een feature flag kan helpen bij een invoering voor beperkte tijd. Een blijvend overeengekomen aanspraak op dienstverlening vraagt echter om passend beheer en handhaving. Een ingeschakelde functie vervangt evenmin de controle wie voor welk bedrijf mag goedkeuren.
In dit voorbeeld moet een update zowel de goedkeuringsvariant als het ongewijzigde proces testen. De navolgbare productregel en onderhoudslast tellen; het eerste klantverzoek bepaalt niet op zichzelf de architectuur.
Bronnen
Geschreven door
- Katharina WeberRedacteur software en technologieKatharina Weber verzorgt bij ASES de artikelen over softwareontwikkeling. Ze schrijft over de vragen waar bedrijven mee te maken krijgen bij het kiezen van software, het ontwikkelen van nieuwe toepassingen en het moderniseren van bestaande systemen.
Verder lezen
Alle artikelen



Softwareontwikkeling met ASES
Maatwerksoftware, web- en mobiele apps



