Van maatwerk naar een standaard oplossing

Vooral in de tijd dat e-commerce nog in opkomst was en in de kinderschoenen stond, waren de generieke tools of standaardoplossingen nog niet zodanig compleet dat bedrijven het alleen daarmee afkonden. De logische reactie was dan ook om die specialistische maatwerkoplossingen dan maar zélf te bouwen. Veel van onze klanten hebben veel baat gehad van zo’n maatwerkoplossing en we hebben zelf flink meegebouwd. Onze klanten zijn retailers met een omnichannel-propositie die dus zowel in de Nederlandse winkelstraten als online te vinden zijn, met een eventueel derde en vierde kanaal erbij.

De afgelopen tijd hebben wij aanzienlijk meer trajecten gedaan waarbij partijen van een volledige maatwerksituatie de overstap maakten naar een systeem met standaardcomponenten. Dit had een aantal redenen, die vooral neerkomen op organisatorische en financiële overwegingen.

Groeiende afhankelijkheid

Er hangen namelijk ook nadelen aan een volledige maatwerkoplossing. Zo draag je de risico’s en verantwoordelijkheid van het beheer, de ontwikkeling en beveiliging van deze tools en platformen volledig zelf, en ben je zeer afhankelijk van je eigen mensen die de unieke en specifieke code van jouw oplossing kennen. Daarbij groeit de afhankelijkheid van je systeem enorm op het moment dat de e-commercetak groeit en bloeit. Maar wanneer er in zulke situaties iets fout gaat, op wie kun je dan terugvallen?

Zodra het succes van de e-commerce operatie toeneemt, wordt het belang van een kwalitatief ontwikkelproces ook groter. En doorgaans neemt daarmee de doorlooptijd sterk toe, en de snelheid waarmee nieuwe features worden geïntroduceerd dus enorm af. Daarnaast zitten er in veel gevallen grote delen zeer specifieke code in zulke maatwerkoplossingen, dat je er als ontwikkelaar eigenlijk ook niet meer aan wilt zitten.

Het tempo waarmee mainstream features stabiel kunnen worden ingepast in je e-commerce landschap en waarmee je nieuwe opties introduceert, ligt bij een standaardoplossing veel hoger. In plaats van het opnieuw moeten bouwen van onderdelen, is het nu al bedacht.

Daarnaast wordt die tool waarschijnlijk al door meerdere organisaties gebruikt, wat ook de kwaliteit ten goede komt. Deze toepassingen zijn al veelvuldig getest door anderen en de kinderziektes zijn er al uit gehaald. Dat is bij een op maat gemaakte feature echt wel anders.

Standaard wensen

In het geval van een maatwerkoplossing wordt ieder blokje van het bouwwerk custom ontwikkeld. Daar is natuurlijk duurbetaalde development-capaciteit voor nodig en tegelijkertijd creëer je een uniek product. En daar ontstaat frictie, omdat je ook voor vrij basale nieuwe features altijd weer naar de ontwikkelaar moet stappen.

Als een marketeer bij een retailer bijvoorbeeld een actie bedenkt met 3 halen, 2 betalen, die ook online moet gelden, dan is dat geen hele bijzondere actie. Maar dit moet voor de betreffende retailer wél apart gebouwd worden. Bij standaardsoftware kun je verwachten dat je dit soort acties direct kunt configureren. Er komen bij maatwerkoplossingen dus ook kosten kijken die onnodig zijn, en het ontwikkelen van de feature en het uitrollen van de actie duurt vele malen langer.

Standaard is goed

We merken tegelijkertijd dat standaardoplossingen de laatste jaren zo uitgebreid zijn geworden dat ze inmiddels voor de meest gangbare wensen een oplossing zijn. De e-commerceplatforms van nu ondersteunen dat je meerdere voorraden, afzetkanalen en bezorgopties hebt. Dit is nu een kwestie van configuratie, voorheen moest je echt aan de bak om dat soort regels in je code te krijgen. De ‘feature-volwassenheid’ van die platforms is dus enorm toegenomen.

Dus voor het overgrote deel van de usercases zijn die standaardoplossingen nu gewoon toereikend. Eventueel hier en daar aangevuld met een add-on om in extra wensen te voorzien.

Het proces

De tendens is dan ook al langere tijd dat maatwerk uit de gratie raakt. Zo’n gedachtegang is natuurlijk makkelijk als je als bedrijf een nieuw e-commerceplatform opzet, maar wat doe je als je al jaren zo’n maatwerkoplossing hebt? Hoe vind je de juiste weg naar een standaardoplossing?

Bij de gang van maatwerk naar ‘standaard’, moet je de afweging maken of bepaalde onderdelen onmisbaar zijn voor jouw organisatie. Het is een kwestie van inschatten of je kunt leven zonder een bepaalde tool of feature, deze er apart bij moet laten ontwikkelen door je agency, of voor een meerprijs al uit de marketplace kunt halen.

Veranderingsleer

Die veranderingsleer kan ook veel opleveren. Een leverancier van een standaardplatform heeft een bepaalde kijk op hoe het proces of platform zou moeten werken, en wat goed is voor veel bedrijven. Daardoor wordt ook jouw bedrijfsproces doorgelicht. Daarin is het weer belangrijk om jezelf af te vragen: Is dit specifieke onderdeel of proces zo gegroeid? En zijn we hierin onderscheidend? Als dat laatste het geval is, dan moet daar natuurlijk extra de nadruk op liggen in het proces. Als dat niet zo is, misschien moet je dan je proces wel aanpassen.

Het is essentieel dat bedrijven, na het maken van de genoemde financiële en organisatorische afwegingen, ook echt een stap durven maken als blijkt dat ze onnodig dure en specialistische tools hebben. Als je de stap naar een meer standaardoplossing maakt, heb je nu eenmaal gebieden waarop je achteruitgaat. Maar de keerzijde is dat je op heel veel gebieden juist vóóruitgaat. Dat bepaalde features al geregeld zijn, ontwikkeld zijn, of dat ze in de nabije toekomst vanzelf beschikbaar komen.

Daarnaast is verwachtingsmanagement erg belangrijk, sommige dingen gaan anders werken. Dat is het mentale en organisatorische aspect waarin alle stakeholders moeten worden meegenomen. Deze stakeholders moeten soms opnieuw worden ‘opgevoed’ en beseffen dat ze sommige features heel snel zullen krijgen, en op andere veel langer moeten wachten of helemaal niet kunnen krijgen.

Best of both worlds

In de praktijk hebben we mooie voorbeelden van klanten die (deels) zijn overgestapt naar een standaardoplossing, waar we zoals altijd, écht naar de specifieke situatie van een klant hebben gekeken. Wat is wenselijk? Wat werkt het beste?

Zo had een klant de hele webshop, het hele orderafhandelingsproces, de integratie met de backoffice, het ERP, de logistiek en dat soort zaken zelf ontwikkeld en in eigen hand gehouden met zijn developmentteam. Het nieuwe en standaard e-commerceplatform hebben wij er vóór geplaatst, waardoor het nieuwe platform nu de transactie en orders aflevert naar dat oude platform, dat dus doorleeft in afgeslankte vorm.

Hierdoor is de opgedane kennis en expertise niet verloren gegaan, maar zeer efficiënt opnieuw ingezet. Ook de mensen houden perspectief dat zij kunnen blijven ontwikkelen en, zij het nu met focus op de backoffice, nog steeds bijdragen. Maar waarbij de afdelingen die gaan over marketing en commercie een nieuw platform kregen en ineens hun wensenlijst konden afvinken, waar ze anders nog jaren op hadden moeten wachten.

Dan heb je echt “the best of both worlds”. Zo’n aanpak leidt ook tot een lager projectrisico. Hadden we alle onderdelen vervangen, dan was er echt sprake geweest van een omslag naar een nieuwe bedrijfsvoering met andere systemen. Zo’n ‘big-bang’ livegang is veel spannender en soms zelfs ongecontroleerd.

Wij zoeken altijd naar dat soort openingen, in slimmigheidjes en faseringen. Hoe kunnen we bepaalde aspecten behouden, en zelfs tot voordeel maken? Zowel voor historische als toekomstige investeringen van onze klanten, gaan we op zoek naar maximaal rendement. En tegen het verlagen van projectrisico’s en het verkorten van de doorlooptijd, kan niemand bezwaar hebben toch?

Dit artikel van onze CTO Bram Hoekman is eerder gepubliceerd op de website van Emerce.