Van verouderd systeem naar wendbare, schaalbare headless Magento-oplossing.
Open Commerce werd in twee fases betrokken. Eerst om het concept van headless commerce te verkennen en een duidelijke visie te ontwikkelen voor een platform dat zowel de uitgebreide productcatalogus als de klantbeleving ondersteunt. Vervolgens om een intern ontwikkelingsteam op te bouwen en te begeleiden, zodat het platform duurzaam en wendbaar bleef.
Tijdens de conceptfase hielpen we Vrijbuiter een roadmap en featurelijst op te stellen die de voordelen van een gescheiden front-end en back-end maximaal benutten. Dit bood houvast voor de ontwikkelfase, waarin het team samen met bestaande partners de visie tot leven bracht.
Toen de ambities groeiden, werd duidelijk dat eigen ontwikkelcapaciteit nodig was. Open Commerce hielp een nearshore team samenstellen dat nauw samenwerkte met interne stakeholders, van Product Owners en marketing tot ERP-specialisten. Samen optimaliseerden ze Pimcore voor beter productinformatiebeheer, stabiliseerden ze de Vue Storefront front-end voor een soepele winkelervaring en hielden Magento 2 betrouwbaar en schaalbaar.
Door deze aanpak kon Vrijbuiter het platform continu verbeteren, prestaties garanderen en wendbaar blijven voor toekomstige groei. Met een geoptimaliseerd e-commerce ecosysteem, een toegewijd team en een heldere digitale strategie, heeft Vrijbuiter nu een basis om niet alleen te verkopen, maar ook vooruit te denken.
Het herbouwen van de productdata achter Vrijbuiters webshop
De webshop van een outdoor-retailer bleef artikelen verkopen die al waren uitverkocht, en elke poging tot oplossen leidde ergens anders naartoe. De oorzaak zat tussen hun systemen in, niet in één ervan, dus brachten we in kaart hoe productdata zich bewoog en bouwden we de laag die dat consistent houdt.
De webshop die ze wilden bouwen
We ontmoetten Vrijbuiter in 2020, toen Het Echte Werk, een concept- en marketingbureau uit Rotterdam, ons erbij haalde om aan hun nieuwe online concept te werken. Het Echte Werk kende het merk en wilde iemand naast zich die kon aangeven wat een webshop realistisch gezien zou kunnen doen.
Samen ontwierpen we een shop concept waar een klant een wandelroute kon uploaden als GPX-bestand, het formaat waarin een horloge of telefoon een tocht vastlegt, waarna het klimaat en het terrein langs die route werden uitgelezen, de bijpassende uitrusting werd aanbevolen en een checklist voor de tocht werd samengesteld. Iemand die in een winkel stond, kon de voorraad checken en wat ontbrak naar huis laten sturen. Handleidingen voor al gekochte uitrusting zouden op een telefoon opengaan zonder bereik, halverwege een berg.
Onze scope was het concept en een inschatting van wat realistisch te bouwen was. De bouw zelf werd uitgevoerd door de bureaus die Vrijbuiter al had aangesteld.
Elk van die ideeën rustte op dezelfde twee fundamenten: productinformatie rijk genoeg om advies op te baseren, en voorraadcijfers die kloppen zowel online en offline. Deze fundamenten zijn lastiger goed te krijgen dan de features die er bovenop worden gebouwd.
Er ging ongeveer een jaar voorbij voordat we elkaar weer spraken, en tegen die tijd zat het probleem precies in die twee fundamenten.
De zoektocht naar waar het werkelijk mis ging
Ze vroegen ons om de shop betrouwbaar te maken. Die draaide op Magento, met een Vue Storefront-frontend en Pimcore voor de productdata, en dit draaiende houden was een dagelijkse klus geworden: de frontend crashte tot iemand het merkte en herstartte, en Pimcore kon een productupdate binnenkrijgen en data verliezen zonder dat iemand het te horen kreeg. We beoordeelden de frontend en Pimcore apart voordat we ons ergens aan committeerden, namen daarna de codebase over en werkten de storingen af.
Hun ERP, dat ook de kassa's in hun winkels aanstuurt, meldde elke voorraadwijziging, maar kon geen nul melden, waardoor elk systeem verderop in de keten het laatst ontvangen aantal bleef tonen zodra het laatste exemplaar van een product verkocht was, en klanten uitrusting bestelden die al weg was.
Een prijs begint in het ERP als een geadviseerd bedrag, aangepast per fabrikant en nogmaals per verkoopkanaal, en kon te laat bij de shop aankomen of in een vorm die de shop anders uitlas. De data van elk systeem klopte op zichzelf, waardoor elke verklaring naar iets anders wees. Hun e-commercemanager en de collega's die de catalogus het beste kenden, besteedden een groter deel van elke week aan het achtervolgen van incidenten dan aan het vooruithelpen van de business.
Dus legden we het brandjes blussen een dag stil en brachten die dag door op kantoor bij Vrijbuiter, met hun mensen van e-commerce, product en operations in de kamer. Het onderwerp was dataconsistentie, en de vraag die we kwamen beantwoorden was of de data die ze hadden schoon te maken was of dat we eromheen moesten werken. We liepen elk systeem stuk voor stuk langs en tekenden het hele landschap uit. Vier systemen droegen de shop samen: de storefront, Magento erachter, Pimcore met de productdata, en het ERP met voorraad en prijs, met daaromheen nog zo'n dertig andere voor zoeken, betalingen, marktplaatsen, klantenservice en verzending.
"Onze taak was om het te vereenvoudigen. Om het duidelijk genoeg te maken om te zien hoe alles stroomt, en waar het breekt."
Olena Vlasova, projectmanager, Open Commerce
Daarna volgden we de twee routes die bepalen of een shop van dit soort werkt: een bestelling van de klik van de klant tot aan het magazijn, en een product vanaf het moment dat het wordt aangemaakt tot aan elk kanaal dat het verkoopt.
De voorraadstoring was één voorbeeld van een breder patroon: productinformatie kwam binnen van tientallen leveranciers via verschillende systemen, elk met zijn eigen conventies, en elk systeem verderop in de keten nam simpelweg over wat het systeem ervoor had doorgestuurd. Niemand had die conventies ooit op één plek vastgelegd.
Het probleem zat in de afspraken tussen de systemen, niet in een van de systemen zelf, waardoor het steeds nieuwe symptomen bleef opleveren, hoeveel oude we ook oplosten.
"De kern van het probleem was altijd hoe de data was gestructureerd. Negen van de tien keer was dat de oorzaak."
Attila Naghi, Magento developer, Open Commerce
Hoe we besloten het aan te pakken
Een volledige herbouw was technisch gezien de schonere oplossing, en die stelden we voor. De shop draaide echter volop, en een herbouw zou precies de omzet belemmeren die de business juist nodig had. We adviseerden om eerst het platform te stabiliseren en de data eronder gaandeweg te herstructureren, gebied voor gebied. Vrijbuiter woog beide opties af en ging akkoord.
In plaats van de hele catalogus af te schrijven, namen we één categorie, broeken, en inventariseerden die van begin tot eind. Die pilot liet zien hoe een werkend model eruitzag voordat we iemand vroegen zich ergens aan te committeren, en zodra het overeind bleef, pasten we dezelfde aanpak toe op de rest van de catalogus.
Vrijbuiter wilde ook bouwcapaciteit dichterbij hebben, dus stelden we een team voor hen samen en verzorgden we de overdracht van hun vorige bureau zonder de shop te onderbreken: een frontend-developer, een Magento-developer, Pimcore-specialisten en een projectmanager, werkend in agile sprints naast Vrijbuiters eigen Product Owner, marketingcollega's en ERP-mensen. Die opzet liep zo'n anderhalf jaar. Hun e-commercemanager stelde de prioriteiten, hun eigen catalogusspecialisten testten de resultaten, en beide kanten liepen elke week hetzelfde bord samen door. De twee kanten werkten als één team in plaats van als twee partijen die tickets uitwisselden, waardoor de mensen die de producten kenden en de mensen die de systemen kenden al in hetzelfde gesprek zaten zodra er iets uitgelegd moest worden.
Wat we bouwden
Een gedeeld woordenboek voor de data
We voerden kwaliteits poorten in op elk punt waar productinformatie van systeem wisselde, een vertaallaag met als enige taak informatie aan te nemen in welke vorm dan ook waarin een systeem die aanlevert, en er een versie van door te geven waar het volgende systeem mee verder kan. Een conventie als een lege schap wordt nu één keer centraal opgelost, in plaats van apart binnen elk systeem dat het ontvangt.
"We bouwden een woordenboek voor het hele team, zodat iedereen elkaar in datatermen zou gaan verstaan."
Sander Mangel, solutions architect, Open Commerce
Een product data model dat advies kan dragen
Uitgaand van de masterdata van een leverancier, definieerden we ongeveer veertien gestructureerde velden per product, over materiaal, pasvorm, lengte, activiteit, features, gewicht en temperatuurbereik. Daarbovenop schreven we regels die aanvullen wat de leverancier had opengelaten: rek afgeleid uit het elastaangehalte of een elastische taille, een gewichtsklasse afgeleid uit de stof, en geschiktheid voor werk, sport of dagelijks gebruik afgeleid uit snit, kleur en lengte samen.
Dat zijn de velden waar het concept van 2020 op had gewacht, want een shop kan alleen uitrusting aanbevelen voor een natte week op hoogte als hij weet waarvoor zijn producten gemaakt zijn.
De catalogus had één plat model met meer dan zeshonderd attributen, waarvan de meeste irrelevant waren voor een gegeven product. We herstructureerden dat naar categorie-specifieke sets, zodat een broek alleen de velden toont die een broek beschrijven, en verder niets.
Een platform dat past bij wat de business nodig had
We migreerden Vrijbuiter van Magento Commerce naar Magento Open Source. De Commerce-features werden grotendeels niet gebruikt, en de paar die er wel toe deden, waren eenvoudig te vervangen, waardoor de overstap naar de goedkopere editie tienduizenden euro's per jaar van de licentiekosten afhaalde. Tegelijkertijd ruimden we de hosting op, waarbij we opslagkosten schrapten waar de business voor betaalde zonder er iets aan te hebben, en upgradeden we Pimcore van versie 7 naar versie 10.
Waar het nu staat
Het platform stabiliseerde, en de operationele kosten daalden. Een lege schap wordt nu in elk systeem dat ernaar vraagt hetzelfde uitgelezen, waardoor de shop stopte met het aanbieden van uitrusting die niet verstuurd kon worden.
Wanneer gekoppelde systemen het over hetzelfde product oneens zijn, zit de oorzaak meestal in de ruimte ertussen, niet in de software aan een van beide kanten, en houdt de oplossing alleen stand als één plek verantwoordelijk wordt gemaakt voor wat de data betekent. Krijg dat goed, en de rest volgt vanzelf, tot aan de klant die op zoek is naar een jas in zijn maat, hem vindt, bestelt en ontvangt.
Herkenbaar? Als je shop, je ERP en je productsystemen hetzelfde artikel elk anders beschrijven, zit de moeilijkheid hoogstwaarschijnlijk in de data die tussen die systemen doorgaat. Dat is het waard om in kaart te brengen voordat iemand een herbouw voorstelt. Plan een gesprek met ons in.
