Van Minimum Viable Product naar Earliest Usable Product

Van Minimum Viable Product naar Earliest Usable Product, door een andere mindset een succesvolle SAP-implementatie

“De business krijgt een Minimum Viable Product”, klinkt goed, of toch niet? Bij SAP-eindgebruikers is het een ander verhaal. Zij ervaren over het algemeen geen verbetering met een MVP in vergelijking met het huidig systeem, waardoor zij niet enthousiast zullen reageren op een MVP. Hoe komt dit? In deze blog vertel ik je waarom.

Een MVP is een vroege, uitgeklede versie van het eindproduct, met het absolute minimum aan functionaliteiten om gevalideerde kennis te verzamelen over het product. Kortom, het doel van een MVP is om:

• het product te testen met minimale (financiële) middelen;

• sneller te leren van het gedrag van de eindgebruiker;

• te voorkomen dat ontwikkeltijd wordt verspild aan onnodige functionaliteiten.

Bij organisaties die SAP implementeren zien we een ander gebruik van MVP. Hier wordt het MVP gebruikt met story mapping, welke bestaat uit het ordenen van user stories langs twee assen. Deze story map rangschikt gebruikersactiviteiten langs de horizontale as in de volgorde waarin de activiteiten van het proces worden doorlopen. Langs de verticale as wordt een toenemende verfijning van de functies gerangschikt.

De eerste horizontale rij van een story map is een uitgeklede, maar bruikbare versie van het product. Door de opeenvolgende rijen te doorlopen wordt het product verder aangekleed met extra functionaliteit. De uitgeklede maar bruikbare versie van het product wordt gedefinieerd als het MVP. Het minimale wat nodig is voor de gebruiker om het proces te kunnen doorlopen.

Waarom MVP niet geaccepteerd wordt door de business bij SAP-implementaties

Door uw gebruikers een MVP aan te bieden, in plaats van direct een volledig ontwikkeld product, biedt u uw gebruikers de mogelijkheid om een nieuw idee te testen. Om aan het product te kunnen wennen, maar vooral om feedback te geven op het product. Maar daar zijn de gebruikers niet mee geholpen! Dit is niet wat de SAP-gebruiker verwacht van een state of the art SAP S/4 HANA systeem, om een stap terug te doen. Wanneer een SAP-gebruiker een transactie aan het verwerken is binnen een proces, wil de gebruiker geholpen worden door een systeem wat het proces ondersteunt en het verwerken van de data gemakkelijker en gebruikersvriendelijker maakt. Foutloos en snel een transactie verwerken!

Daarnaast verwacht de gebruiker bruikbare informatie over het proces, meer en sneller inzicht in de verschillende data. Het nieuwe product testen en leren van het gedrag is niet wat in het verwachtingspatroon van een SAP-gebruiker terugkomt. Kortom, maken we de eindgebruikers blij met een dode mus?

Bruikbare oplossingen eerder opleveren

In plaats van een MVP geloven we binnen McCoy dat de business geholpen is wanneer zij zo snel mogelijk gebruik kan maken van het nieuwe SAP-systeem voor een proces, met behoud van kwaliteit. Geen lange ontwikkeltrajecten, maar snelle verbeteringen met minimale impact binnen de business. Dit noemen we binnen McCoy het 'Earliest Usable Product (EUP)'. Welke functionaliteit, transactie of deel van een proces kan zo snel mogelijk gebruikt worden door de gebruikers? Welke oplossing geeft zo snel mogelijk een verbetering en dus waarde voor de business? Een Earliest Usable Product zorgt er voor dat SAP-eindgebruikers enthousiast worden, waardoor een SAP-implementatie succesvol wordt.

Maar wat is nou precies het verschil tussen MVP en EUP?

Het Minimum Viable Product is die versie van een nieuw product die een team in staat stelt om de maximale hoeveelheid gevalideerd leren over gebruikers te verzamelen met de minste inspanning." Met andere woorden, het MVP gaat over gevalideerd leren met behulp van de minste hoeveelheid tijd en geld. Het gaat om het beantwoorden van de vraag: Zijn we goed op weg? Het kan een eenvoudig prototype zijn, zolang het maar helpt de relevante kennis te verwerven of belangrijke risico's aan de orde te stellen. Dus, het product te testen met minimale middelen en sneller te leren van het gedrag van de eindgebruiker.

De Earliest Usable Product is de kleinste eenheid van functionaliteit met intrinsieke waarde die zo snel mogelijk opgeleverd kan worden aan de gebruikers. Bouwen we iets wat toegevoegde waarde heeft? Met andere woorden, de EUP is een echte functie die tastbare waarde biedt aan gebruikers. Het voorziet in een specifieke ondersteuning van het proces, lost een bepaald 'probleem' op, en is van hoge kwaliteit en bruikbaarheid. Het is een functie die opgeleverd wordt aan de business, die gebruikt wordt ter ondersteuning van het proces en die waarde geeft voor de business.

De voordelen van een Earliest Usable Product

Op een aantal punten biedt een EUP-voordelen in vergelijking met een MVP voor SAP-implementaties.

1. Mindset en verwachtingen

MVP geeft een verkeerd verwachtingspatroon. Het geeft een tweestrijd tussen iets wat de gebruiker verwacht en het minimale dat hij krijgt. Niemand zal enthousiast worden van een MVP. "Je gaat een nieuw SAP S/4 HANA systeem krijgen voor je processen, maar we beperken ons op het minimaal noodzakelijke wat nodig is". Het eerste wat een gebruiker zal denken: "Mooi, het kost me de komende periode veel tijd en ik ga er op achteruit in vergelijking met hetgeen er nu is".

EUP gaat over het moment waarop een gebruiker nieuwe functionaliteit kan gebruiken. Het geeft een positieve mindset; de gebruiker verwacht alles op één moment te krijgen, terwijl de focus van het project is om een deel al sneller te leveren. Gedurende het gebruik van het EUP kan gezamenlijk bepaald worden wat de volgende EUP is.

De business heeft een bepaald beeld van MVP, namelijk: ik wil alles (het beste voor de procesondersteuning), maar ik krijg niet alles (wellicht in een later stadium). Hierdoor is de business niet tevreden. Bij de EUP zit de focus niet op scope, maar op het moment. De business verwacht iets op een bepaald moment en wij leveren kleine onderdelen eerder aan. Het geeft een positieve mindset vanaf de start van het project.

2. Businesscase

De MVP houdt geen rekening met de businesscase, deze heeft de focus op het leveren van een minimum aan functionaliteiten om gevalideerde kennis te verzamelen over het product. De MVP zegt niets over het moment waarop de functionaliteit ter beschikking komt en waarde genereerd voor de business, zoals opbrengsten en/of besparingen.

Een EUP heeft een positief effect op de businesscase, uitgedrukt in Netto Contante Waarde, doordat deze al vroeg opbrengsten of besparingen realiseert. Doordat dit eerder wordt gerealiseerd heeft dit een positief effect op de businesscase.

3. Veranderingen

Gedurende het traject van de SAP-implementatie kunnen er veranderingen gewenst zijn in de ontwikkeling van de oplossing. Dit kan impact hebben op het MVP (design of samenstelling van de MVP wijzigt). Er is nog niets opgeleverd, maar toch kan er al een behoefte zijn om iets te veranderen. Hierdoor is de kans groter dat de eerste oplevering verschuift naar een later moment, waardoor een negatief beeld ontstaat over de implementatie (de eerste oplevering vertraagd).

Nadat de EUP is opgeleverd kan met de business na iedere iteratie of increment beoordeeld worden of de EUP voldoet of niet. Zo ja, dan kan de focus naar de volgende EUP. Zo nee, dan gaat de focus op het aanpassen van de eerste EUP. De business kan de EUP nog steeds gebruiken, ook al wordt deze gewijzigd. Dat zorgt voor een positieve mindset.

4. End-to-end solution

Voor het vaststellen van de MVP is inzicht nodig in de totale oplossing. In een vroeg stadium is het noodzakelijk om de minimale set van functionaliteit vast te stellen die voor de totale oplossing waarde genereert. Dit veronderstelt dat er al aan het begin van het traject een goed beeld moet zijn van de totale oplossing en van de target architectuur. Een uitgangspunt dat haaks staat op het agile principe "We staan open voor veranderende behoeften, ook laat in het ontwikkelproces".

Voor EUP is inzicht nodig in het proces, maar niet in de totale oplossing. De ontwikkelvraag richt zich op het proces of deelproces gerelateerd aan de business case. Op deze wijze evolueert de oplossing en wordt het principe gehanteerd van Intentional architecture en Emergent design. Intentional architecture biedt de leidraad die nodig is om ervoor te zorgen dat het hele systeem conceptueel deugdelijk is en geschikt is voor zijn doel. Emergent design maakt snelle en specifieke controle mogelijk, zodat teams adequaat kunnen reageren op veranderende eisen zonder overmatige inspanningen om het systeem toekomstbestendig te maken.

5. Risico mijdend

Kijkend naar voorgaande punten, brengt het MVP aanzienlijke risico's met zich mee wanneer dit wordt gebruikt binnen een SAP-implementatie. Enkele van deze risico’s zijn:

• met het MVP lopen de verwachtingen van gebruikers uiteen;

• de kans is groter dat de business case slechter of zelfs niet haalbaar is;

• veranderingen hebben een grotere impact tijdens het ontwikkeltraject.

EUP is risico mijdend, doordat het kleine onderdelen zijn die direct gebruikt kunnen worden en waarop direct feedback kan komen. Het zorgt ervoor dat je snel en tijdig kan inspelen op veranderingen, bijvoorbeeld wet- en regelgeving. Ook zorgt het ervoor dat je snel financieel resultaat verkrijgt met kleine investeringen die een deel van de realisatie opbrengen.

Als je op enig moment stopt met de implementatie heb je in ieder geval al de voordelen van de eerste EUP(s), dus het eerder stoppen van een project betekent niet een verspilling van de tot dan toe gedane investering. Zeker positief wanneer je snel wilt reageren op een crisis; je wilt geen investeringen doen in een onzeker traject. Met EUP kun je snel stoppen, de eerste EUP's hebben al een deel van de reeds gedane investering opgeleverd.

McCoy’s Simply PM framework hanteert een Earliest Usable Product

Binnen iedere organisatie zijn er specifieke aandachtspunten voor een SAP-implementatie om succesvol te zijn. McCoy heeft het Simply PM framework ontwikkeld met een focus op succes voor én met de klant. Wij willen onze gebruikers niet het minimale geven, maar zo snel mogelijk functionaliteit opleveren die direct gebruikt kan worden. Hierin heeft het gebruik van een EUP een centrale plaats. Samen met de gebruikers uit de business wordt bekeken waar een EUP toepasbaar is en hoe deze zo snel mogelijk geleverd kan worden. Is dit altijd toepasbaar? Er zijn situaties waarin een EUP geen voordelen biedt door onder andere de context waarin de organisatie zich bevindt en de behoefte die er vanuit de klant zijn.

Wil je meer weten over SAP-implementaties binnen een agile omgeving en het Simply PM framework? Mail naar Laurens Verwoest: laurens.verwoest@mccoy-partners.com of Hein van den Heuvel: hein.van.den.heuvel@mccoy-partners.com.