Een winkel vol unieke stukken, zonder leverancier en zonder nabestelling, bediend door mensen die er soms pas sinds vorige week staan. Bijna alle winkelsoftware gaat uit van het omgekeerde. Hieronder staat waar dat wringt en wat ik erop gebouwd heb.
Winkelsoftware is gebouwd voor nieuwe spullen. Er is een leverancier, er is een bestelbon, er is een artikelnummer met dertig dezelfde stuks erachter, en de vraag die het systeem het beste beantwoordt is hoeveel er nog van iets in het rek ligt. In een kringwinkel klopt geen van die vier aannames. Wat binnenkomt, komt binnen omdat iemand het wegdeed, elk stuk is een eigen ding, en de vraag is niet hoeveel er nog ligt maar of het weg raakt voor het plaats inneemt.
Het gevolg is dat een standaardpakket voor tachtig procent past en op de twintig procent die het verschil maakt niets te zeggen heeft. Daar zit het werk: niet een nieuw kassasysteem bouwen, wel de laag ernaast die de vragen beantwoordt waar het pakket niet voor gemaakt is, en die het pakket blijft voeden zodat de boekhouding en de kassa aan elkaar gelijk blijven.
Daar komt bij dat een kringwinkel zelden alleen een winkel is. Er hangt een sociale opdracht aan: mensen die werkervaring opdoen, een kringloopcentrum dat ook ophaalt en sorteert, en een koepel die over alle vestigingen heen moet kunnen rapporteren aan wie de werking mee betaalt. Elk van die drie legt zijn eigen eis op het systeem, en ze spreken elkaar geregeld tegen.
Zes stukken tussen een zak die binnenkomt en een cijfer waar iemand iets aan heeft.
Een boek inlezen met de camera van een telefoon, en er meteen bij tonen wat het elders opbrengt. De scanner slaat het isbn op, haalt titel, auteur en uitgave op, en houdt bij wat er al langsgekomen is. Wie achter de tafel staat hoeft geen inschatting meer uit het hoofd te maken.
Een groep winkels die elk hun eigen kas, hun eigen aanbod en hun eigen boekhouding hebben, maar samen willen rapporteren. Dat vraagt een gegevensmodel waarin een vestiging echt een vestiging is, en niet een filterveld dat er achteraf bij geplakt werd.
Een pasje dat kwijtraakt, verkreukt of thuis ligt is een pasje dat niet gescand wordt. In Apple en Google Wallet staat het altijd op zak, werkt het in elke winkel van de groep, en komt een nieuw saldo er vanzelf op.
Wat er per winkel, per productgroep en per periode binnenkomt en buitengaat, uit het kassasysteem getrokken en in een eigen scherm gezet. Niet om een export te vervangen maar om de vraag te beantwoorden zonder dat er iemand een export moet maken.
Iemand die aan de kassa lid wil worden heeft geen zin in een formulier van twaalf velden. Een code op het scherm, de telefoon erbij, klaar. De koppeling met het kassasysteem zorgt dat de kaart meteen werkt bij de volgende aankoop.
Gegevens over een stuk, waar het vandaan kwam en wat ermee gebeurde, gestructureerd bijhouden in plaats van in een vrij tekstveld. Dat is nu nog administratie; over enkele jaren is het de enige manier om aan een paspoort te raken.
Vijf uitgangspunten die bepalen of een systeem in deze sector gebruikt wordt of enkel geinstalleerd.
In gewone retail hangt alles aan een artikelnummer: dertig dezelfde truien, een leverancier, een bestelbon. Hier is elke trui een eigen ding met een eigen prijs en een eigen verhaal. Een systeem dat uitgaat van voorraad per artikel telt hier niets zinnigs. Wat wel werkt is een productgroep voor de rapportering en een uniek stuk voor de verkoop.
Er valt niets na te bestellen. Loopt een categorie leeg, dan is dat geen tekort maar een gegeven, en een melding "voorraad laag" is dan ruis. Wat er wel toe doet is de stroom aan de andere kant: wat er binnenkwam, wat ervan naar de winkel ging, en wat er is blijven liggen.
Een deel van de mensen achter de kassa is er om werkervaring op te doen, soms met een taalachterstand of na een lange onderbreking. Een scherm dat vier kliks vraagt waar er een volstaat is daar geen ongemak maar een drempel. Dat maakt het schermontwerp een functionele eis en geen afwerking.
De prijs komt van iemand die het stuk in handen heeft. Software kan daar hoogstens bij helpen: tonen wat vergelijkbare stukken opbrachten, een vork voorstellen, een uitschieter aanstippen. Wie die schatting probeert te automatiseren krijgt een systeem dat genegeerd wordt, en dan zijn de cijfers erna niets meer waard.
Het interessante getal in hergebruik is niet de omzet maar wat er de tweede ronde niet haalt. Dat staat zelden in een kassasysteem, want dat is gebouwd om verkopen te tellen. Het bijhouden vraagt een eigen stap, en die stap moet zo klein zijn dat ze op een drukke dag toch gezet wordt.
Europa werkt aan een paspoort per product: een datadrager, meestal een qr-code, die naar een dossier wijst met wat erin zit, waar het vandaan komt, hoe het hersteld kan worden en wat ermee moet als het op is. De bedoeling is dat een product zijn eigen geschiedenis meedraagt in plaats van die achter te laten bij de fabrikant.
Voor wie nieuwe producten maakt is dat een administratieve opdracht. Voor wie hergebruikt is het iets anders: jij hebt dat paspoort niet gemaakt, je krijgt een stuk binnen dat het misschien wel heeft. De vraag wordt dan of je het terugvindt, of je eraan mag, en of je er iets aan kan toevoegen wanneer je het herstelt of doorverkoopt. Die drie vragen zijn technisch, en ze worden op dit moment beslist.
Wat een hergebruikorganisatie er nu al mee kan: de gegevens die ze toch al verzamelt gestructureerd bijhouden in plaats van in een vrij tekstveld, en per stuk vasthouden wat ermee gebeurde. Dat is vandaag extra werk zonder onmiddellijke opbrengst, en het is precies het werk dat achteraf niet meer in te halen valt.
Loop je aan tegen een pakket dat je stukken als artikelen behandelt, tegen cijfers die per winkel wel kloppen maar samen niet, of tegen de vraag wat het productpaspoort voor jou gaat betekenen, dan is dat het soort gesprek waar ik graag in zit. Stuur gerust een bericht.
De kant van de kassa en de klantenkaart staat bij retail en kassa, de api van het kassasysteem zelf bij de Tilroy-koppeling, en een uitgewerkt voorbeeld bij de case studies.