De discovery phase: het geheim van een succesvol e-commerceproject

Hoe houd je een maatwerktraject in e-commerce op de planningsrails en binnen budget? Door vooraf heel erg goed te bepalen wat je wel en wat je niet gaat doen. En door risico’s in kaart te brengen voordat je begint. Wij doen dat in een discovery phase. In dit blog tonen we je het waarom, wat, hoe en wie van zo’n onderzoeksfase. 

Je e-commercebusiness groeit. En nu het aantal orders toeneemt, worden de inefficiënte, handmatige stappen in je proces bottlenecks en bronnen van fouten. Je hebt ook je assortiment uitgebreid. Niet alleen heb je meer verschillende producten, ze zijn er ook in steeds meer verschillende variaties. En betaalmodellen zijn veranderd: abonnementsmodellen zijn in opkomst en niet ieder standaardpakket kan mee in die ontwikkeling. 

Het bouwen van een product- of abonnementsconfigurator, bijvoorbeeld, is meestal maatwerk. En maatwerk is ons specialisme, maar alleen het woord al veroorzaakt vaak koude rillingen bij CEO’s en e-commercemanagers. Want het managen van maatwerktrajecten is een uitdaging, zeker in e-commerce waar budgetten altijd onder druk staan en waar time to market cruciaal is. 

In eerdere blogs hadden we het over de kosten van een e-commerceproject en over onze visie op samenwerking tussen opdrachtgever en agency. Vandaag duiken we dieper in de Discovery Phase: het eerste, superbelangrijke stukje van een project waarin je bepaalt wat je precies wilt en binnen welke grenzen je gaat werken. 

Discovery phase versus Sprint 0 

Volg je ons al wat langer en vraag je je nu af waarom we het in het verleden vaak over ‘Sprint 0’ hadden en nu over een ‘discovery phase’? 

Dat komt omdat de wereld veranderd is. 

Sprint 0 is een functioneel onderzoek dat vooraf gaat aan het de bouw in een Scrum-proces. Het is eigenlijk een sprint waarin je uitvogelt wat je in de volgende, ‘echte’ sprints gaat bouwen. Sprint 0 lijkt op een discovery phase, maar dan met een veel beperktere focus. Waar we in een discovery phase het hele landschap van een opdrachtgever bekijken, inclusief alle data-integraties en huidige en toekomstige businessmodellen, lag bij een sprint 0 meer de nadruk op wat er in het e-commerceplatform zelf moest gaan gebeuren. 

In het verleden werkte dat prima, want e-commercelandschappen waren minder complex dan nu en er was dus heel veel ruimte om ‘met een schone lei te beginnen’. Tegenwoordig heeft ieder e-commercebedrijf een eigen IT-afdeling en een bestaand platform met een bijbehorend systeemlandschap dat bestaat uit on-premises systemen, cloud-infrastructuur en SaaS-oplossingen. Een discovery phase maakt ruimte om te kijken hoe een nieuw platform bij dat landschap past. 

Hoe ziet het team eruit? 

Een discovery phase is dus de eerste fase van je project. Een onderzoeksfase. Toch willen we het liefst al meteen alle disciplines aan tafel hebben. Van onze kant zijn dat een product owner, een software-architect en eventueel nog een developer. Van de kant van de opdrachtgever zien we het liefst (vertegenwoordigers van) alle interne stakholders: management/directie, klantenservice, helpdesk, finance en marketing. Waarbij die laatste vaak de primaire opdrachtgever is. Het liefst hebben we ook input van de eindgebruiker. Dat kan door ze direct mee te laten praten of door klantonderzoek te doen. 

Welke vragen stellen we? 

In de discovery phase willen we vooral antwoorden op de volgende vragen: 

• Wat moet er op de backlog? En wat moet er bovenaan die backlog staan? 

• Welk systemen hebben er interactie met het e-commerceplatform? Hoe moeten die integraties gaan werken? 
• Waar zijn de risico’s? Waar missen we cruciale informatie? 
• Passen de business rules die we willen implementeren eventueel in een standaardpakket? 

Vooral die laatste vraag is natuurlijk belangrijk om te beantwoorden. Want als dat het geval is, kunnen we het project veel eenvoudiger maken. Ook je data onderwerpen we aan een onderzoek. Welke data staat waar? En als data op meerdere plekken bewaard wordt, wat is dan de ‘waarheid’? Wat moeten we bij elkaar zoeken om het nieuwe platform goed te laten werken? En kloppen de bronnen eigenlijk wel? Of zien we uitdagingen op het gebied van datakwaliteit? 

Vaak ligt er al heel veel verzamelde kennis als we aan de discovery phase beginnen. De kennis die er nog niet is, halen we boven tafel in interviews.  

Lijken uit de kast 

We kijken in de discovery phase niet alleen naar nieuwe functionaliteit. We kijken ook kritisch naar functies die je nu hebt. Want de simpele stelling ‘alles moet mee’ houdt geen stand. Zoals bij die opdrachtgever die absoluut een Excel-exportfunctie nodig had in zijn platform. Want dat was nodig om mailings uit te kunnen sturen… Ons advies was om de exportfunctie achterwege te laten en een integratie te maken met een goed marketing automation-pakket. 

Zo’n bureau van buiten dat overal kritische vragen over stelt is een beetje alsof je een vreemde je huis laat doorzoeken. Want we komen bij wijze van spreken je huis binnen en trekken alle kasten open… Ook de kasten die jij al een tijdje niet hebt opgeruimd. En soms valt er een lijk uit zo’n kast: een PIM dat eigenlijk al lang niet meer voldoet, een integratie met een stokoude versie van een API of vreemde dingen in de gebruikerservaring die overduidelijk conversie kosten. 

Het is misschien niet leuk om daarop gewezen te worden. Maar het is stukken minder leuk om ze halverwege je project tegen te komen. 

Deliverables van de discovery phase 

En wat krijg je dan, als je al die moeilijke vragen hebt beantwoord? Dit zijn de deliverables van de discovery phase: 

• Een uitgewerkte scope (meestal in de vorm van een backlog met epics, stories en inschattingen): wat willen we nou echt bouwen en wat hebben we nodig om de eerste business value te leveren? 
• Een inschatting van de kosten, zodat je grip krijgt op de verhouding tussen budget en geleverde functionaliteit 
• Een architectuurschets die laat zien welke datastromen er zijn, welke bestaande systemen een rol spelen en welke systemen je nodig hebt 
• Een beoordeling van je huidige systeemlandschap: wat is bruikbaar, wat moet weg en wat kan blijven met wat aanpassingen? 

Door deze deliverables wordt de discovery phase in feite een onafhankelijk adviestraject dat op zich al veel waarde biedt, of je nou met Enrise verdergaat of niet. Vooral de architectuurschets en de beoordeling van je systeemlandschap kun je echt zien als technisch advies, waar je ook buiten de context van het huidige project veel aan hebt.  

Hoe lang duurt een discovery phase? 

Hoe lang zo’n discovery phase gaat duren? Dat hangt ervan af… Het huidige landschap is daarbij bepalend. Is er nog bijna niets en/of kunnen we met een schone lei beginnen? Dan kunnen we snel aan de gang met de bouw van het nieuwe platform. In een uitgebreid landschap met veel gekoppelde applicaties, SaaS-systemen en integraties met partners hebben we meer uitzoekwerk. Dan duurt de discovery phase dus een aantal weken. 

Over het algemeen zien we dat landschappen complexer worden (en discovery phases dus langer en intensiever). Vroeger kwam je nog wel eens bij een bedrijf waar nog niet zo veel was of waar het nog een optie was om het hele landschap in één project te vervangen. Tegenwoordig komt dat bijna niet meer voor. Processen lopen bijna altijd over meerdere systemen. E-commerceplatforms zijn meestal gebouwd en ingericht om data te halen uit ERP, PIM en externe ordersystemen. Bovendien zijn er vaak integraties met externe partners en systemen. Minimaal zien we meestal een integratie met een payment provider, maar meestal is het nog complexer en zijn er bijvoorbeeld ook fysieke winkels waarvan het kassasysteem een databron is. Die complexiteit levert extra vragen op. En het beantwoorden daarvan kost extra tijd. 

Bepalen wat we niet gaan doen 

In de discovery phase bepalen we dus wat we binnen de scope van het project gaan doen. En daarmee ook wat we allemaal niet gaan doen. Je kunt in een complex landschap nou eenmaal niet alles in één keer vervangen. Al zou je dat soms wel graag willen. Je kunt ook niet alle stakeholders 100% hun zin geven, want dan loop je gegarandeerd uit je budget en je planning. Stakeholdermanagement is dus in deze aanloopfase heel belangrijk. Iedereen moet concessies doen, om de scope te beperken. Dat is de enige manier om het project onder controle te houden. 

Eén ding dat we in ieder geval wel doen, is een slimme architectuur bedenken die het vervangen van systemen en het toevoegen van functionaliteit in de toekomst makkelijk maakt. Dat doen we door bijvoorbeeld een tussenlaag te bouwen, die de verantwoordelijkheid neemt voor alle data-uitwisseling tussen verschillende applicaties. 

Zo houd je je e-commerceplatform niet alleen binnen budget en binnen de scope, maar maak je het ook nog future proof. 

Wil je nog meer leren over hoe wij e-commerceprojecten aanpakken en daarbij risico’s en kosten managen? Kijk de talkshowserie Enrise Business Talks.