Naar de inhoud

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.

Katharina Weber2 min leestijd
Groene regelaar met een rechte route van startsymbool naar vinkje, een ruit met vraagteken en een kleine schakelaar erboven.

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

C10

Na inzending op onafhankelijke goedkeuring wachten

Zelfgoedkeuring wordt geweigerd; alleen de bevoegde andere persoon kan goedkeuren

C20

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.

ASES volgen

Verder lezen

Alle artikelen

Softwareontwikkeling met ASES

Maatwerksoftware, web- en mobiele apps