Hoe voer je een prijswijziging door op elke locatie zonder elke kassa afzonderlijk te bewerken?

Je voert een prijswijziging door op elke locatie door de wijziging één keer door te voeren in één centrale catalogus en elke kassa daarvan te laten lezen. Dat is het hele antwoord. Als je met je systeem in plaats daarvan langs elke kassa moet lopen, op afstand moet inloggen op zes backoffices of een bestand van een usb-stick moet laden, staat de prijs niet echt in je prijslijst. Dan staat hij in de hardware. En een prijs die in de hardware staat, moet overal worden gewijzigd waar de hardware zich bevindt.

Waarom betekent een prijswijziging dat je elke kassa moet bewerken?

Omdat oudere POS-systemen elke kassa als een op zichzelf staande kleine database behandelen. Het apparaat slaat een lokaal prijsboek op (de opgeslagen lijst met artikelen en prijzen van de kassa) en de kassa leest uit die lokale kopie. Het hoofdkantoor kan wel een perfect moederspreadsheet bijhouden, maar de kassa weet niet eens dat het bestaat. Wanneer de kassa de 'system of record' is (de kopie die iedereen daadwerkelijk vertrouwt), moet elke kassa individueel op de hoogte worden gebracht van de wijziging.

Dat ontwerp was logisch toen kassa's nog offline apparaten waren en een internetverbinding een luxe was. Het heeft al jaren geen zin meer, maar het datamodel is overeind gebleven in veel geïnstalleerde systemen, en in een aantal nieuwere systemen die het hebben overgenomen. Het resultaat is hetzelfde patroon als bij nachtelijke CSV-exports die doorgaan voor rapportage: personeel dat permanent handmatige routines uitvoert om te compenseren voor de plek waar de data staat.

Wat kost het bewerken van prijzen per kassa je nu echt?

Meer dan alleen de avond die het kost. De voorspelbare knelpunten:

• Afwijkingen tussen locaties. Dezelfde SKU (unieke productcode) wordt in het centrum voor de ene prijs aangeslagen en in het winkelcentrum voor een andere, omdat er in maart één kassa is overgeslagen. Niemand merkt het op totdat een klant erachter komt. Voorraadgegevens gaan uit zichzelf al afwijken; handmatig gekopieerde prijzen wijken nog sneller af.

• Gemiste apparaten. Een kassa die tijdens de update net bezig was met een verkoop, uitgeschakeld was of simpelweg is vergeten, behoudt het oude prijsboek en blijft wekenlang vrolijk de oude prijs rekenen.

• Schapkaartjes en kassabonnen komen niet overeen. Elke handmatige bewerkingsronde is een nieuwe kans dat de gescande prijs niet meer overeenkomt met het etiket op het schap. Een klant die de afwijking opmerkt, heeft meteen minder vertrouwen in alle andere prijzen in je winkel.

• Onduidelijke rapportages. Wanneer een product in dezelfde week voor drie verschillende prijzen wordt verkocht, zeggen margetellingen niet veel meer en verandert het vergelijken (je rapportages afstemmen op het geld dat daadwerkelijk is binnengekomen) in archeologie.

• Werken buiten openingstijden. Aanpassingen per kassa moeten wachten tot na sluitingstijd, dus ze kosten overwerk of worden uitgesteld. Als de inkoopprijs van een leverancier al is gestegen, is elke dag wachten een stukje marge dat je weggeeft.

Welke tijdelijke oplossingen werken wél op een systeem per kassa?

Als je voorlopig vastzit aan prijzen per kassa, werken sommige routines minder slecht dan andere:

1. Werk in batches, typ nooit opnieuw over. Houd één centraal prijsbestand aan en laad dit via de export- en importtools van het systeem, zelfs als je dit apparaat voor apparaat moet doen. Het opnieuw intypen van getallen op een toetsenbord is de bakermat van fouten.

2. Wijs een hoofdkassa aan. Als je systeem de configuratie van één kassa naar de andere kan kopiëren, maak dan van één apparaat de bron en kloon deze. Een halve synchronisatie is beter dan geen.

3. Wees strikt met het wijzigingsmoment. Één persoon, één gedateerd hoofdbestand, één checklist met elk apparaat erop. De meeste afwijkingen zijn terug te voeren op "Ik dacht dat jij kassa 2 had gedaan."

4. Controleer door te scannen, niet door te kijken. Reken na de update op elke locatie een testverkoop af voor een paar gewijzigde artikelen. Een instellingenscherm kan het ene zeggen, terwijl het afrekenen het andere in rekening brengt.

5. Houd een logboek met prijswijzigingen bij. Wanneer er later afwijkingen optreden, is een gedateerd logboek het verschil tussen een duidelijke diagnose en gissen.

Wees eerlijk over wat dit is: onderhoud aan een ontwerpfout. Het valt in dezelfde categorie als handmatig btw verwijderen voor elke vrijgestelde koper; iemand die voor altijd herhaalt wat het datamodel één keer had moeten doen.

Hoe zou een prijswijziging eigenlijk moeten werken?

De prijs zou op precies één plek moeten staan: een centrale catalogus in de cloud, waarbij elke kassa werkt als een client van die catalogus in plaats van als eigenaar van een eigen kopie. Wijzig het productrecord en er hoeft niets te worden doorgevoerd, omdat niets anders een prijs vasthoudt. Dit is het belangrijkste argument voor cloudsystemen boven traditionele installaties, zoals besproken in POS-systemen voor elk type bedrijf: welk type past bij jou?

In Final POS is de catalogus op deze manier gebouwd. Producten staan in één productlijst in de Merchant Hub, prijs is een veld in het productrecord en verkooppunten (je winkellocaties) bepalen waar elk product wordt verkocht. Elk station bij elk verkooppunt leest hetzelfde record, dus de prijs één keer bewerken is het enige wat je hoeft te doen.

Twee belangrijke kanttekeningen. Een kassa moet nog steeds online zijn om een update te ontvangen, dus de controlestap krimpt in tot bevestigen dat de apparaten verbonden zijn, in plaats van getallen opnieuw in te voeren. En als je bewust verschillende prijzen hanteert op verschillende locaties, is dat een prijsbeslissing die als regel in de catalogus thuishoort, en niet iets wat je simuleert door kassa's handmatig uit elkaar te laten lopen.

Dus, hoe voer je een prijswijziging door op elke locatie zonder elke kassa te bewerken?

Bij een systeem per kassa doe je dat niet. Je verwerkt de wijziging in een batch, kloont deze waar het systeem dat toelaat en controleert het met testscans, omdat het ontwerp niets beters biedt. Bij een systeem met een centrale catalogus bewerk je het product één keer en ben je klaar. De vuistregel: als het wijzigen van een prijs betekent dat je hardware moet aanraken, zijn je kassa's eigenaar van je catalogus in plaats van andersom. Als je een nieuw systeem evalueert, zet dan "pas één prijs aan en laat me zien dat dit op elke kassa is doorgevoerd" op je demoscript, en loop vervolgens door een instelchecklist voor de eerste week zodra je overstapt.