Aviva Solutions realiseert al jaren e-commerce oplossingen. We werken vaak met All-In-One platformen zoals Sitecore en Kentico, maar bouwen ook steeds vaker Composable Commerce platformen. Deze type platformen spelen in op verschillende behoeften, waardoor het belangrijk is helder te hebben wat je van je platform verwacht. Een All-In-One wordt vaak gezien als een iets beperkter maar gebruiksvriendelijker platform, terwijl Composable Commerce meer inspeelt op personalisatie en schaalbaarheid. Grote bedrijven, die vaker veranderende behoeften hebben, halen daarom vaak meer voordeel uit een Composable Commerce platform.
Zijn er nog belangrijke verschillen bij een Composable Commerce project, waar je als projectmanager rekening mee moet houden? Het korte antwoord is: ja, er zijn zeker verschillen. We zetten vier belangrijke aandachtspunten op een rij.
Het traject om de juiste services uit te kiezen maakt een groot verschil in de projectplanning. In tegenstelling tot de keuze voor een All-in-One platform, waarbij de vendor (en daarmee de architectuur) direct bekend zijn, moet na de keuze voor een Composable platform eerst nog de vendors en services geselecteerd worden en de architectuur bepaald worden. Dit betekent dat deze twee platformen een ander (voor) traject hebben.
De serviceselectie wordt gebaseerd op de functionele en non-functionele eisen die gelden voor het totale commerce platform. Om dat te kunnen doen, worden de eisen verdeeld per service type (zoals commerce of search) en maken we per service type een short list – een selectie van vendors die aan alle eisen voldoen. Daarna bekijken we de shortlist van services in detail en bepalen we in welke mate zij passen bij de eisen van de klant. In dit proces worden ook de interne gebruikers bij onze klant betrokken, zoals marketeers of product managers, zodat we zeker weten dat de services die zij gaan gebruiken ingericht kunnen worden op een manier die zij prettig vinden.
Je hebt zelf dus volledige controle over de inrichting van je platform. Het voordeel is dat deze aanpak tot beter onderbouwde keuzes voor de services leidt, en het platform altijd perfect past bij je unieke wensen.
Omdat een Composable architectuur niet vooraf bepaald is, vergt het daarom meer aandacht in het begin. Een Composable platform bestaat over het algemeen uit meerdere headless services, een eigen front-end, en integraties tussen de diverse services. We zullen dus eerst moeten bepalen hoe alle services efficiënt met elkaar geïntegreerd kunnen worden. Dit moet per service geëvalueerd en geïmplementeerd worden, waardoor het belangrijk is om vroeg in het project helderheid te krijgen over de totale architectuur. Om het platform te gaan bouwen, werken we eerst de belangrijkste functionele- en kwaliteitseisen uit. Zodra we die helder hebben, kunnen we dat framewerk gaan invullen. Dat geeft houvast tijdens het project.
Omdat een Composable platform normaliter uit meerdere services bestaat, hebben we voor de planning en afstemming binnen het project dus te maken met meerdere partijen. Dit heeft voor- en nadelen. Het voordeel is dat deze partijen gespecialiseerd zijn op hun gebied en dat vraagstukken daardoor altijd heel gericht besproken kunnen worden. Tegelijkertijd moet je als projectmanager wel rekening houden met meer partijen, die allemaal een effect op de projectplanning kunnen hebben. Dit vergt afstemming met meerdere support engineers, op verschillende communicatiekanalen, met allemaal een andere werkwijze en support organisatie.
Het voordeel van een Composable platform is dat enkel de services die belangrijk zijn voor de bedrijfsprocessen van de klant geselecteerd worden. Dit in tegenstelling tot een All-In-One oplossing waarin functies aanwezig kunnen zijn, die nooit gebruikt worden en het gebruik van het platform daardoor potentieel ingewikkelder maken.
Het nadeel van een Composable platform is echter wel dat iedere service een eigen dashboard heeft om het te onderhouden. Eindgebruikers zullen daarom –waar nodig– in meerdere systemen getraind moeten worden. Hou hier in de projectplanning voldoende rekening mee.
Uit de voorgaande voorbeelden blijkt al dat een Composable commerce project een ander zwaartepunt krijgt dan een All-In-One project. Er ligt meer nadruk op het eerste deel van het project, waarin services worden geselecteerd en de architectuur wordt opgesteld. Daarnaast hebben we tijdens het project te maken met meerdere partijen, waarmee we regelmatig afstemmen en waarvan we ook qua planning afhankelijk kunnen zijn. Verandert daarmee de projectaanpak volledig? Nee, zeker niet. Maar wees bewust van deze verschillen.
Eens klankborden over de aanpak van een Composable project? Neem contact met ons op!
Leer hoe je altijd voldoet aan de verwachtingen van je klant.
Lees verderWil je op de hoogte blijven van alles wat er speelt rondom Composable Commerce? Meld je hier aan voor onze updates!
Al meer dan 15 jaar bouwen we converterende e-commerce platformen voor onze klanten.
