Praktijkcase Electrolux
Transformatiedoorloskoppeling
Hoe verkoop je dezelfde stofzuiger via tientallen webshops en marketplaces in meer dan veertig landen, terwijl elk kanaal zijn eigen eisen stelt? Electrolux koos er niet voor om steeds nieuwe koppelingen met SAP te bouwen. Het bedrijf plaatste ChannelEngine als vertaallaag tussen de eigen systemen en de verkoopkanalen.
Tekst: ROBBERT HOEFFNAGEL Beeld: AI – WONDERWORKS
Wie via één webshop producten verkoopt, kan de benodigde koppelingen met het erp-systeem doorgaans nog redelijk overzien. Maar zodra een fabrikant tientallen landen, merken en online verkoopkanalen wil bedienen, verandert diezelfde integratievraag in een complex en kostbaar probleem. Want iedere webshop en marketplace hanteert eigen productcategorieën, technische velden, afbeeldingsformaten, omschrijvingen en regels voor prijzen, voorraad en bestellingen. Electrolux liep precies tegen deze complexiteit aan toen de producent van huishoudelijke apparatuur zijn verkoop via externe webshops en online marktplaatsen wilde uitbreiden. De onderneming beschikt over productinformatie, prijzen en voorraaddata in de eigen SAP-omgeving, maar kon die informatie niet zonder meer naar ieder afzonderlijk verkoopkanaal sturen.
‘Het lijkt misschien eenvoudig: je hebt producten en die wil je op een marketplace zetten’, zegt Suhel Mukherjee, product manager marketplaces en digital commerce bij Electrolux Group. ‘Maar iedere marketplace heeft andere eisen en wensen. De complexiteit neemt daardoor heel snel toe.’
Mukherjee zocht de oplossing niet in steeds meer een-op-een koppelingen tussen het erp-systeem en individuele verkoopplatformen. Electrolux plaatste daarentegen ChannelEngine als extra softwarelaag tussen de eigen bedrijfssoftware en de verschillende marketplaces. Die tussenlaag vertaalt de interne product- en orderdata naar het formaat en de processen die een specifiek verkoopkanaal verlangt.
‘Wanneer je iedere nieuwe marketplace als een afzonderlijk it-project behandelt, kost uitbreiding veel tijd en dus veel geld’
Iedere webshop spreekt een eigen taal
Een erp- of commerceomgeving werkt met een intern datamodel dat is ingericht rond de processen van de fabrikant. Daarin staan bijvoorbeeld artikelnummers, productnamen, technische specificaties, prijzen, beschikbare voorraad en logistieke informatie. Een marketplace kan echter een geheel andere indeling gebruiken. Een koelkast die in het interne systeem onder één productcategorie valt, moet bij de ene webshop misschien worden voorzien van velden voor energieklasse, netto-inhoud, geluidsniveau en afmetingen. Een andere marketplace vraagt dezelfde informatie onder andere veldnamen op, gebruikt andere categorieën of stelt aanvullende eisen aan afbeeldingen en producttitels. Ook aspecten als maximale tekstlengtes en toegestane tekens kunnen flink verschillen.
Een fabrikant kan voor ieder verkoopkanaal een afzonderlijke interface bouwen. Technisch is dat mogelijk, maar deze aanpak wordt al snel moeilijk beheersbaar. Iedere koppeling moet worden ontwikkeld, getest, beveiligd, gedocumenteerd en onderhouden. Verandert een marketplace zijn api, categorie-indeling of datavereisten, dan moet de koppeling worden aangepast. ‘Wanneer je iedere nieuwe marketplace als een afzonderlijk it-project behandelt, kost uitbreiding veel tijd en dus veel geld’, zegt Mukherjee. ‘Je wilt nieuwe verkoopkanalen kunnen openen zonder telkens opnieuw een volledige integratie te moeten ontwikkelen.’
Dat probleem wordt extra zichtbaar door de schaal waarop Electrolux opereert. De marketplace-activiteiten in Europa en de regio Azië-Pacific bestrijken meer dan veertig landen. Daarbinnen werkt het bedrijf met veertien verschillende operationele modellen en drie logistieke en zogeheten last mile-partners. De onderliggende omgeving omvat bovendien meer dan dertig SAP-producten en -modules en ruim acht SAP-instances.
Een verzameling een-op-een-koppelingen zou in zo’n omgeving niet alleen duur zijn, maar ook nieuwe afhankelijkheden creëren. Een wijziging in het interne datamodel kan gevolgen hebben voor tientallen interfaces. Omgekeerd kunnen veranderingen bij marketplaces aanpassingen in de centrale systemen noodzakelijk maken. Ook het beveiligen van al die individuele koppelingen wordt een enorme uitdaging die bovendien aanzienlijke risico’s met zich meebrengt. Een klein configuratiefoutje kan criminelen al een ingang bieden.
‘Een klein configuratiefoutje in een van de vele koppelingen kan criminelen al een ingang bieden’
ChannelEngine als abstractielaag
ChannelEngine fungeert in de gekozen architectuur als een abstractielaag. Electrolux levert productinformatie, prijzen, voorraadgegevens en andere relevante data vanuit zijn bestaande erp-omgeving aan ChannelEngine. Dit platform zet die informatie vervolgens om naar de structuur die een marketplace nodig heeft.
Daarbij gaat het niet uitsluitend om het in technische zin doorgeven van velden. De gegevens moeten ook inhoudelijk worden gemapt. Een intern veld voor een commerciële productomschrijving kan bijvoorbeeld worden gekoppeld aan het titelveld van een webshop. Technische kenmerken worden regelmatig door webshops vertaald naar de attributen van een productcategorie. Regels van marketplaces kunnen daarnaast informatie inkorten, aanvullen, combineren of anders formatteren.
‘Wij verbinden de achterliggende systemen één keer met ons platform’, legt Niels Floors van ChannelEngine uit. ‘Daarna verzorgen we vanuit die centrale laag de vertaling naar de afzonderlijke verkoopkanalen. De bronsystemen hoeven dus niet voor iedere marketplace anders te worden ingericht.’
Ook veranderingen kunnen grotendeels in deze vertaallaag worden opgevangen. Wanneer een webshop bijvoorbeeld de maximale lengte van een titel verandert of een nieuw verplicht productveld introduceert, hoeft Electrolux zijn centrale datamodel niet aan te passen. De mapping binnen ChannelEngine kan worden gewijzigd, terwijl SAP de interne bron van product- en transactiedata blijft.
De gegevensstroom werkt bovendien in twee richtingen. Productinformatie, prijzen en voorraad gaan naar de marketplaces. Bestellingen en statusinformatie komen vanuit die kanalen terug en worden in de achterliggende processen opgenomen. Daarmee blijft het erp-systeem leidend voor onder meer orderverwerking, beschikbaarheid en logistiek.
Sneller een nieuw kanaal openen
Het belangrijkste voordeel voor Electrolux is dat bij deze manier van werken de marginale inspanning voor ieder volgend verkoopkanaal drastisch afneemt. De eerste integratie tussen de enterprise-omgeving en de tussenlaag vraagt nog altijd ontwerp-, configuratie- en testwerk. Maar daarna hoeft niet opnieuw de volledige keten vanaf SAP te worden gebouwd. Een nieuwe marketplace kan grotendeels worden aangesloten door categorieën, attributen, prijzen, voorraadregels en orderstromen te configureren. Dat maakt het mogelijk om sneller te experimenteren met lokale of gespecialiseerde platformen. Een kanaal hoeft niet meteen een omvangrijk, meerjarig integratieproject te rechtvaardigen voordat Electrolux er producten kan aanbieden.
‘Technologie maakt de schaal mogelijk, maar technologie alleen is niet voldoende’
‘De waarde zit niet alleen in de eerste koppeling’, aldus Mukherjee. ‘Het gaat er vooral om dat we daarna sneller kunnen schalen. We kunnen nieuwe marketplaces toevoegen zonder dat de technische complexiteit in hetzelfde tempo meegroeit.’
Tegelijkertijd blijft lokaal werk noodzakelijk. Productteksten moeten worden vertaald, assortimenten verschillen per land en ook prijzen, belastingregels, leveringsmogelijkheden en retourprocessen zijn niet overal hetzelfde. Een integratieplatform neemt deze commerciële en organisatorische keuzes niet weg. Het voorkomt wel dat voor iedere keuze opnieuw maatwerk in de kernsystemen moet worden ontwikkeld.
De operationele omvang van de samenwerking illustreert dat onderscheid. Electrolux gebruikt twee productie-instances van ChannelEngine, werkt daarbij met twee serviceproviders en heeft een team waarin meer dan vijf talen worden gesproken.
Digitale transformatie door complexiteit los te koppelen
De aanpak van Electrolux laat zien dat digitale transformatie niet altijd begint met het vervangen van bestaande kernsystemen. De onderneming heeft juist geprobeerd de waarde van de bestaande SAP-omgeving te behouden en de kanaalspecifieke complexiteit erbuiten te plaatsen. Daarbij is met name het architectuurprincipe relevant. Door de interne systemen via één gestandaardiseerde laag met externe verkoopkanalen te verbinden, worden veranderingen beter van elkaar gescheiden. SAP hoeft niet alle technische bijzonderheden van iedere webshop te kennen. De marketplaces hoeven op hun beurt niet rechtstreeks te worden gekoppeld aan alle onderdelen van de gebruikte enterprisesoftware.
Dat vermindert het aantal maatwerkinterfaces, voorkomt dubbel beheer en verkleint de kans dat kanaalspecifieke aanpassingen de centrale architectuur vervuilen. It-specialisten kunnen zich daardoor meer richten op de betrouwbaarheid van de kernintegratie, datakwaliteit en procesbewaking, in plaats van op het onderhouden van een voortdurend groeiende verzameling individuele koppelingen.
‘Technologie maakt de schaal mogelijk, maar technologie alleen is niet voldoende’, benadrukt Mukherjee. ‘Je hebt ook duidelijke verantwoordelijkheden, goede samenwerking en een operationeel model nodig dat die groei ondersteunt.’ Daarmee is ChannelEngine voor Mukherjee niet simpelweg een extra applicatie naast SAP. Het is als het ware een ontkoppelingslaag die voorkomt dat de groei van het aantal webshops leidt tot een min of meer onbeheersbare groei van het aantal interfaces, aanpassingen en beheeruren. Juist daarin zit de productiviteitswinst: niet iedere verbinding opnieuw bouwen, maar één keer een fundament leggen dat voor veel verschillende verkoopkanalen kan worden hergebruikt.
