Soms hoef je niet ver te zoeken om een probleem in een proces te ontdekken.

Een tijdje geleden bestelden we een partij sleutelkoorden met logo voor Open Commerce. We stuurden de leverancier ons logo, legden uit hoe we wilden dat het eruit zou zien en plaatsten de bestelling.

Toen de sleutelkoorden binnenkwamen, klopte er iets niet.

Een deel van het logo ontbrak. De leverancier had besloten dat een element van het ontwerp te klein was om goed te kunnen reproduceren en had het daarom uit de uiteindelijke versie gehaald. Ook zag het stiksel er anders uit dan we hadden verwacht.

De technische beperkingen zelf waren niet per se het probleem. Dit soort dingen kunnen gebeuren bij de productie van een fysiek product.

Het probleem was dat niemand het ons had verteld.

Er was geen bericht waarin werd gevraagd of we het logo wilden aanpassen. Voor het plaatsen van de bestelling hadden we voorbeeld-pdf's ontvangen en daarop stond het volledige logo. We hadden die versie goedgekeurd. Maar toen de leverancier wijzigingen in het design aanbracht, kregen we niet de kans om die opnieuw te bekijken of goed te keuren voordat de productie begon.

We kwamen er pas achter toen de afgewerkte sleutelkoorden binnenkwamen.

Het klinkt misschien als een klein probleem. En in dit geval was dat ook zo. Maar het zette ons ook aan het denken over iets wat we al vaker in veel grotere projecten hebben gezien: wat gebeurt er wanneer een proces controlemomenten bevat, maar er daarna nog steeds beslissingen kunnen worden gewijzigd zonder de persoon erbij te betrekken die ze moet goedkeuren?

‍

Een probleem dat we eerder hebben gezien

Dit is niet de eerste keer dat we met zo'n situatie te maken kregen.

Bij Open Commerce werkten we eerder met een bedrijf dat promotionele printproducten maakt. Hun uitdaging was natuurlijk heel anders dan die van ons. Zij hadden niet te maken met een aangepast logo op een sleutelkoord, maar met een veel groter probleem rond hun e-commerceplatform, interne systemen en bedrijfsprocessen.

Toch was er een duidelijke overeenkomst.

Het bedrijf had een bestaand monolithisch systeem dat in de loop der jaren was gegroeid en verantwoordelijk was geworden voor een breed scala aan functies, waaronder de webshop, ERP, OMS en CRM. Tegelijkertijd hadden verschillende onderdelen van de organisatie hun eigen manier van werken ontwikkeld, wat voor knelpunten en inefficiënties zorgde.

De voor de hand liggende oplossing was misschien geweest om het oude systeem zo snel mogelijk te vervangen.

In plaats daarvan deden we een stap terug.

‍

Het probleem begrijpen voordat je de oplossing verandert

Voordat we bepaalden hoe de nieuwe technologie eruit moest zien, werkte Open Commerce samen met het bedrijf om te begrijpen hoe de organisatie daadwerkelijk werkte.

We brachten mensen uit verschillende afdelingen bij elkaar en brachten de huidige situatie in kaart. Via workshops, service blueprint mapping (het visueel in kaart brengen van de dienstverlening) en event storming (interactieve sessies om bedrijfsprocessen te begrijpen) bekeken we wat er op dat moment gebeurde, waar processen vastliepen en wat de organisatie in de toekomst daadwerkelijk nodig had.

Die oefening bracht iets belangrijks aan het licht.

Niet elk probleem was een technologieprobleem.

Sommige problemen werden veroorzaakt door de manier waarop informatie tussen teams werd doorgegeven. Andere kwamen voort uit onduidelijke verantwoordelijkheden of inefficiënte workflows. Door eerst de processen in kaart te brengen, kon het bedrijf zien waar de echte problemen lagen, in plaats van simpelweg een nieuw systeem te bouwen op basis van aannames.

‍

De sleutelkoorden deden ons aan hetzelfde denken

Als we terugkijken op onze eigen ervaring met de sleutelkoorden, geldt hetzelfde principe.

De leverancier had een geldige reden om te denken dat een deel van het logo niet goed zou werken. Ook voor het stiksel was misschien een andere aanpak nodig.

Maar die beslissingen hadden niet zonder ons genomen moeten worden.

Het proces had een simpel controlemoment nodig:

“We hebben een probleem met je ontwerp vastgesteld. Dit is wat we voorstellen. Willen jullie dat we hiermee doorgaan?”

Die ene stap had de hele ervaring veranderd.

In plaats van een afgewerkt product te ontvangen dat niet helemaal overeenkwam met wat we hadden besteld, hadden we zelf de beslissing kunnen nemen.

Dat is een klein voorbeeld, maar het geldt ook in het groot.

In een groter e-commerce- of digital transformation-project kunnen de gevolgen van onduidelijke vereisten of ontbrekende beslismomenten veel groter zijn. Een kleine aanname die vroeg in een project wordt gedaan, kan uiteindelijk leiden tot een aanzienlijke hoeveelheid extra werk.

‍

Bouwen op basis van echte vereisten

Dit is een van de redenen waarom we zoveel nadruk leggen op het begrijpen van de business voordat we technologie implementeren.

Bij het bedrijf waarmee we hebben gewerkt, resulteerden de workshops in een duidelijkere set vereisten en een beter inzicht in de verschillen tussen de huidige en gewenste processen. Dit vormde vervolgens de basis voor het ontwerpen van een flexibeler, modulair softwarelandschap, met Shopware als belangrijkste online verkoopplatform.

De technologie was belangrijk, maar kwam pas nadat we het probleem goed hadden begrepen.

En dat is waarschijnlijk de belangrijkste les uit beide situaties.

Of je nu een paar honderd sleutelkoorden bestelt of een volledig e-commercelandschap opnieuw ontwerpt, dezelfde basisregel geldt:

Neem geen belangrijke beslissingen namens iemand anders zonder die persoon de kans te geven om erbij betrokken te zijn.

‍

Betere processen hoeven niet altijd ingewikkeld te zijn

De oplossing voor het sleutelkoord-probleem had geen grote transformatie vereist.

Een simpele goedkeuringsstap was voldoende geweest.

Maar dat maakt die stap niet minder belangrijk.

Goede processen draaien vaak om het beschikbaar maken van de juiste informatie op het juiste moment en ervoor zorgen dat de juiste persoon de beslissing kan nemen.

Dat is ook wat we bij onze klant probeerden te bereiken. Door eerst de tijd te nemen om hun processen te begrijpen voordat we de technologie bepaalden, konden we vaststellen wat de business daadwerkelijk nodig had en de organisatie een basis geven waarop ze verder kon bouwen.

Onze sleutelkoorden waren een veel kleiner voorbeeld, maar ze herinnerden ons aan hetzelfde principe.

Soms is de beste manier om een probleem in een proces te ontdekken simpelweg om het zelf te ervaren.

En soms zijn een paar sleutelkoorden genoeg om je eraan te herinneren waarom goede communicatie, duidelijke requirements en de juiste goedkeuringsmomenten ertoe doen.