AMS01:00
AMS01:00
AMS01:00

Je eerste eCommerce-platform ontgroeid? Zo kies je het volgende

Teamlid van Flatline Agency voor een bakstenen gebouw

Door Robin Laseur

Whitepaper aanvragen

Door je aan te melden ga je akkoord met ons privacybeleid

IN DIT ARTIKEL

Welk platform beter is, zegt weinig. De echte vraag is wat je beperkt: je catalogus, je team of je roadmap. Zo kies je een eCommerce-platform dat echt past.

Welk platform beter is, zegt weinig. De echte vraag is wat je beperkt: je catalogus, je team of je roadmap. Zo kies je een eCommerce-platform dat echt past.

Welk platform beter is, zegt weinig. De echte vraag is wat je beperkt: je catalogus, je team of je roadmap. Zo kies je een eCommerce-platform dat echt past.

Laptop met een vergelijkingsmatrix van eCommerce-platforms en drie tegels voor catalogus, team en roadmap

Een featurevergelijking is het verkeerde instrument voor deze beslissing, en iedereen die er ooit een heeft gemaakt weet dat. Elk enterpriseplatform kan bijna alles wat op de lijst staat. Daarom komt de matrix vrijwel vol terug en beslist hij niets. Het juiste platform is niet het platform dat het meeste kan. Het is het platform dat past bij je catalogus, je team en je komende twee jaar. En welke vergelijking je moet maken, hangt af van welke van die drie je op dit moment echt beperkt.

Dit stuk gaat over hoe je die beperking eerst vaststelt. Weet je of je catalogus, je team of je roadmap het knelpunt is, dan worden de onderlinge vergelijkingen nuttig in plaats van uitputtend. Je weet dan welke rijen in de matrix ertoe doen.

Waarom de featurematrix steeds tekortschiet

Drie redenen, en ze versterken elkaar.

Aan de bovenkant van de markt kunnen platforms inmiddels grotendeels hetzelfde. Meerdere valuta, B2B-prijzen, headless en composable integraties zijn bijna overal in een of andere vorm beschikbaar. Een vergelijking op basis van een checklist eindigt dus vrijwel gelijk, en de beslissing valt uiteindelijk bij wie als laatste heeft gepresenteerd.

De kosten die de uitkomst bepalen zijn geen features. Het gaat om hoe je totale kosten zijn opgebouwd: licentie tegenover infrastructuur, een retainer bij een bureau tegenover eigen mensen in dienst, upgradecycli tegenover automatische updates, en hoe snel je team een wijziging live zet zonder developer. Niets daarvan staat in een rij met functionaliteiten.

En een platformkeuze is eigenlijk een keuze over hoe je organisatie werkt, in een technisch jasje. Het platform voor een merchandisingteam van twee dat elke week wijzigingen doorvoert, is niet het platform voor een intern engineeringteam van acht met een vast releaseproces. Allebei legitiem. Uitwisselbaar zijn ze niet.

eCommerce-platform kiezen op basis van de beperking: catalogus, team of roadmap, elk met eigen criteria en afwegingen

Bepaal eerst je knelpunt

Er zijn drie mogelijke knelpunten, elk met een herkenbaar patroon. Bij de meeste merken overheerst er één, bij sommige twee.

Knelpunt: catalogus. De complicatie zit in je commerciële model. Configureerbare producten, kits en bundels, contractprijzen per klant, meerdere entiteiten met eigen btw- en valutaregels, of een groothandelsmodel waarin elk account een eigen catalogus ziet. De vraag is of een platform je commerciële werkelijkheid kan vastleggen zonder een omweg die maar één persoon begrijpt.

Knelpunt: team. Je mensen zijn de beperking, en dat kan twee kanten op. Een klein commercieel team zonder developers heeft een platform nodig waarop merchandisers zelf wijzigingen doorvoeren. Een merk met een echt engineeringteam en een uitgesproken productvisie heeft een platform nodig dat niet in de weg zit. Kiezen alsof je het andere team hebt, is de duurste versie van deze beslissing.

Knelpunt: roadmap. Er komt iets concreets aan, met een datum: drie nieuwe markten, een groothandelskanaal, een marketplace, een overname die geïntegreerd moet worden, een abonnementsmodel. De vraag is of het platform daar een kwestie van configureren van maakt, of een project.

Zo zie je snel waar je staat: beschrijf de laatste drie dingen die je team wilde doen en niet kon. Waren het commerciële regels die het systeem niet kon vastleggen, dan zit je knelpunt in je catalogus. Kon het systeem het wel, maar had niemand de tijd of de kennis om het te bouwen, dan zit het in je team. Werden ze uitgesteld tot na een grotere verandering, dan zit het in je roadmap.

Wat je knelpunt betekent voor de vergelijking

De aanwijzing die de meeste tijd bespaart, staat in de derde kolom. Een vergelijking die elk criterium even zwaar laat wegen, kan geen beslissing opleveren.

Vier categorieën eCommerce-platforms per afweging: hosted PaaS, self-hosted open source, composable headless, enterprisesuites

De categorieën, eerlijk bekeken

Vier categorieën, beschreven aan de hand van de afweging die elk maakt en niet aan de hand van leveranciers. Afzonderlijke producten schuiven in de loop van de tijd tussen deze posities. Daarom zegt de vorm meer dan het logo.

Hosted platform-as-a-service. De leverancier regelt infrastructuur, beveiliging en upgrades. Sterk als je voorspelbaar wilt draaien, snel live wilt en met een klein team zonder developers werkt. De prijs is beperkte controle: checkout, backendprocessen en datamodel zijn uitbreidbaar binnen grenzen. Voor de meeste merken zijn die ruim, voor sommige knellen ze echt.

Self-hosted open source. Je hebt alles in handen en je draagt ook alles: hosting, beveiligingspatches, upgrades en de developers om dat te doen. Sterk als je commerciële model echt afwijkt, of als regelgeving en eisen over waar je data staat de architectuur bepalen. De prijs: de totale kosten verschuiven van een licentieregel naar personeel, en ze blijven verschuiven.

Composable en headless architectuur. De beste losse componenten rond een commerce-engine, met een frontend die helemaal van jou is. Sterk voor merken met eigen developers en een uitgesproken productvisie, en voor complexe structuren met meerdere merken of regio's. De prijs is dat de integraties van jou zijn: als twee componenten het oneens zijn, is niemand anders verantwoordelijk.

Enterprise suites. Veel standaard in huis voor complexe B2B, productconfiguratie en organisaties met meerdere entiteiten, met implementatie- en licentiekosten die daarbij horen. Sterk als het commerciële model het product is. De prijs is snelheid: elke wijziging kost tijd en geld.

Of een categorie bij een merk past, hangt volledig af van het knelpunt hierboven. Daarom wordt hetzelfde platform in dezelfde week terecht aangeraden en terecht afgewezen.

Waar de vergelijking nu het scherpst is

Weet je wat je knelpunt is, dan doen de onderlinge vergelijkingen het detailwerk. Welke de moeite waard zijn, hangt af van waar je vandaan komt.

Kom je van Magento of Adobe Commerce, dan zit de kern in de totale kosten, niet in features. Onze analyse van de verborgen kosten in de vergelijking tussen Magento en Shopify laat zien wat zich echt opstapelt: upgraderisico, infrastructuur en de experimenten die je in een traag ecosysteem niet kunt draaien.

Is de prijsopbouw je open vraag, dan rekent de vergelijking tussen BigCommerce en Shopify de transactiekosten door en laat hij zien hoe die som is veranderd.

Zit je in een Europese markt met een Shopware-installatie, dan behandelt de vergelijking tussen Shopware en Shopify het als een vraag over hoe je werkt, niet over features. Dat sluit aan bij het argument hier.

En voor maatwerk op een developerframework legt ons stuk over Sylius en Shopify uit waarom je bij diepe eigen logica anders migreert dan bij een standaardplatform.

Lees die naast de rij in de matrix die voor jou geldt, en sla de rest over.

Wanneer het voor de hand liggende antwoord niet klopt

Een eerlijke vergelijking noemt ook de gevallen waarin het advies de andere kant op valt. Vier daarvan zijn het benoemen waard.

Je commerciële model is echt ongebruikelijk. Niet ingewikkeld, ongebruikelijk. Geconfigureerde producten met afhankelijkheidsregels, prijsstructuren die alleen in jouw branche bestaan, gereguleerde categorieën met afwijkende compliance-eisen. Als het model het bedrijf is, kan een platform dat precies dat model standaard tot in detail vastlegt zijn kosten en zijn tragere tempo waard zijn.

Eisen rond dataopslag of regelgeving bepalen de architectuur. Zijn dat harde eisen en geen voorkeuren, dan vallen er al opties af voordat een commerciële vergelijking begint.

Je hebt een echt engineeringteam en een duidelijke productvisie. Een merk dat zich onderscheidt met een ervaring die het zelf bouwt, en de mensen heeft om die te bouwen en te onderhouden, kiest anders dan een merk dat commerce-infrastructuur liever aan een ander overlaat. Allebei terecht.

Het platform is eigenlijk niet je knelpunt. Dit komt van de vier het vaakst voor. Liepen je laatste drie initiatieven vast op onduidelijk eigenaarschap of ontbrekende data, en niet op de grenzen van het systeem? Dan neem je het probleem bij een nieuw platform gewoon mee. Ons stuk over de groeibeslissingen in eCommerce die merken te laat nemen laat zien hoe je het verschil ziet voordat je een kwartaal aan het verkeerde project besteedt.

Beslisregels

  1. Benoem het knelpunt voordat je iets vergelijkt. Catalogus, team of roadmap. Noemen drie mensen in je bedrijf drie verschillende knelpunten, dan is dat meningsverschil het eerste wat je oplost.

  2. Vergelijk op de vier tot zes criteria die bij je knelpunt horen, en scoor verder niets. Een volledige matrix eindigt per definitie gelijk.

  3. Reken de totale kosten over drie jaar door, niet alleen de licentie. Neem infrastructuur mee, uren van het bureau en van eigen developers, upgradecycli en de kosten van de experimenten die een trager platform tegenhoudt.

  4. Test de roadmap, niet de featurelijst. Neem de drie concrete dingen waarvan je weet dat ze eraan komen en vraag elke leverancier hoe die ze zou aanpakken. Vraag daarna wat er stukgaat als er onverwacht een vierde bij komt.

  5. Kies voor het team dat je hebt, plus één nieuwe collega die al gepland staat. Niet voor het team dat je misschien ooit bouwt, en niet voor het team van twee jaar geleden.

  6. Controleer of het platform echt het knelpunt is voordat je aan een migratie begint. Verbeteren op je huidige platform is kleiner, goedkoper en terug te draaien, en soms is dat het hele antwoord.

Twijfel je of je platform nog past? Een kort adviesgesprek brengt de vraag terug tot je eigen knelpunten. Bij Flatline toetsen we een platform eerst aan je catalogus, je team en je roadmap, en pas daarna adviseren we. Soms luidt dat advies: blijf waar je zit.

Veelgestelde vragen

Hoe weet ik of we ons platform echt ontgroeid zijn? 

Zet de laatste drie dingen op een rij die je team wilde doen en niet kon, en deel ze in. Commerciële regels die het systeem niet kan vastleggen, wijzen op een beperking van het platform. Dingen die het systeem wel kan maar die niemand tijd had om te bouwen, wijzen op een tekort aan mensen of budget. Dingen die zijn uitgesteld tot na een grotere verandering, wijzen op een kwestie van volgorde. Alleen de eerste groep is een platformprobleem.

Moeten we overstappen op headless als we van platform wisselen? 

Alleen als je de developers hebt om de frontend en de integraties blijvend zelf te beheren, en een productreden die het rechtvaardigt. Met headless ligt de verantwoordelijkheid voor wat de klant ziet bij je eigen team. Dat is een voordeel als je een uitgesproken visie hebt, en een kostenpost als je die niet hebt. Het is een andere beslissing dan welk commerceplatform je draait. Wie die twee samenvoegt, ziet de scope van het project verdubbelen.

Verschillen de totale kosten echt per platform, of is dat een verkoopargument? 

Ze verschillen echt, en het verschil zit in posten die je makkelijk vergeet in een vergelijking: hosting en infrastructuur, beveiligingspatches, upgradeprojecten, developeruren voor wijzigingen die een merchandiser anders zelf had gedaan, en wat trage oplevering je aan gemiste kansen kost. Reken het over drie jaar door met je eigen cijfers. Neem geen gepubliceerde vergelijking van een leverancier over, ook die van ons niet.

Kunnen we deze beslissing nog een jaar uitstellen? 

Soms, en de toets is concreet. Houdt het platform commerciële afspraken met een vaste datum tegen, dan heeft uitstel een prijs die je kunt uitrekenen. Maakt het het werk alleen onhandig, dan levert verbeteren op het huidige platform meestal meer dan een jaar op, voor veel minder geld dan een migratie.

De belangrijkste punten

  • Bepaal je knelpunt voordat je iets vergelijkt. Catalogus, team en roadmap maken elk andere criteria doorslaggevend, en een volledige featurematrix eindigt per definitie gelijk.

  • Vergelijk categorieën, geen logo's. Hosted, self-hosted, composable en enterprise suites maken elk een andere afweging, en afzonderlijke producten schuiven in de loop van de tijd tussen die posities.

  • Reken de totale kosten over drie jaar door, inclusief infrastructuur, developeruren, upgradecycli en de experimenten die een traag platform tegenhoudt. De vergelijking van licenties zegt daarbij het minst.

  • Controleer of het platform echt het knelpunt is. Loopt werk vast op onduidelijk eigenaarschap of ontbrekende data en niet op de grenzen van het systeem, dan verhuist een migratie het probleem voor veel geld naar een nieuw systeem.

Een platform kiezen is een van de weinige beslissingen in eCommerce die duur is om te nemen en duur om terug te draaien. Besteed daarom meer tijd aan de diagnose dan aan de demo's. Een merk dat zijn knelpunt in één zin kan benoemen, doorloopt een kortere en betere selectie dan een merk dat binnenkomt met een scoresheet maar zonder standpunt.

Gerelateerde artikelen

Mis niets, schrijf je in

Door je aan te melden ga je akkoord met ons privacybeleid

Mis niets, schrijf je in

Door je aan te melden ga je akkoord met ons privacybeleid

Mis niets, schrijf je in

Door je aan te melden ga je akkoord met ons privacybeleid

Vertel ons over je project.

Vertel ons over je project.

Vertel ons over je project.