Barcodescanner-app laten bouwen: alles wat je moet weten

Een barcode is niets anders dan een getal dat een machine sneller en betrouwbaarder leest dan een mens. De waarde zit niet in het lezen maar in wat eraan hangt: het artikel, de locatie, de order of het apparaat dat door dat getal wordt aangewezen. Een scanner-app is daarom in de kern een app die iets opzoekt en daar een handeling aan koppelt.

Dat verklaart waarom scanprojecten zelden op de scanner stuklopen. Ze lopen stuk op de vraag wat er moet gebeuren als de code onbekend is, als iemand twee keer scant, als het artikel op een andere plek ligt dan het systeem denkt, of als het netwerk wegvalt terwijl er al vijftig regels zijn ingevoerd.

De winst is meestal wel goed te benoemen. Overtikken verdwijnt, en daarmee de typefouten die daarbij horen. Handelingen worden sneller, vooral als de app na de scan meteen het volgende veld klaarzet. En de registratie is completer, omdat scannen minder moeite kost dan opschrijven en dus vaker gebeurt.

Op consum­entena­rtikelen staat meestal een EAN-code, het streep­jespatroon met dertien cijfers dat wereldwijd een artikel aanwijst. Die code zegt welk product het is, maar niets over de partij, de houdbaarheid of het serienummer. Voor voorra­adtellingen en kassasystemen is dat genoeg.

In de logistiek en de zorg komt u vaker GS1-128 tegen, een code die meerdere gegevens combineert: artikelnummer, batch, houdba­arheid­sdatum en soms een serienummer, elk voorafgegaan door een kenmerk dat zegt wat het betekent. Een app die zulke codes moet lezen, moet ze ook kunnen ontleden, en dat is meer werk dan alleen scannen.

Voor eigen toepassingen is een QR-code vaak de praktische keuze. Hij bevat meer tekens, is vanuit elke hoek te lezen en blijft leesbaar als hij deels beschadigd is. Voor eigen etiketten op apparatuur, locaties of dossiers werkt dat beter dan een streepjescode, zeker als de sticker slijtage te verduren krijgt.

• Verzamel echte voorbeelden voordat u ontwerpt. Fotografeer de codes die u werkelijk tegenkomt, inclusief de rommelige exemplaren van leveranciers.
• Bepaal of u de code moet ontleden. Alleen het artikelnummer eruit halen is iets anders dan batch en houdbaarheid apart vastleggen.
• Kies bewust voor eigen etiketten. Als leveranciers geen bruikbare code voeren, drukt u zelf. Dat is een eigen deelproject.
• Test op beschadigde en vuile codes. In een magazijn of werkplaats ziet een etiket er na een maand anders uit dan in een demo.
• Let op codes die op elkaar lijken. Een interne code die toevallig hetzelfde formaat heeft als een EAN, geeft stille verwisselingen.

De camera van een moderne telefoon leest codes goed genoeg voor de meeste toepassingen. Voor een monteur die twintig keer per dag een apparaat scant, of een medewerker die een paar dozen afmeldt, is een telefoon de logische keuze: hij is er al, hij heeft internet en hij kan meer dan alleen scannen.

Bij honderden scans per dienst verandert het beeld. Een handscanner leest sneller, vaak op grotere afstand, en ligt anders in de hand: de gebruiker richt en drukt af zonder naar een scherm te kijken. Dat verschil van een halve seconde per scan telt op tot een merkbaar deel van de dag, en het scheelt vermoeidheid.

Er is een tussenvorm die vaak over het hoofd wordt gezien: een ruggedized handterminal met een ingebouwde scankop draait gewoon een app en combineert allebei. En een losse bluetooth-scanner die aan een telefoon hangt, laat uw app op de telefoon draaien terwijl het scannen met echte hardware gebeurt. Dat is doorgaans de goedkoopste manier om snelheid te winnen.

In een magazijn met stalen stellingen, in een kelder of op een bouwlocatie is de verbinding wisselvallig. Een app die per scan een server moet bevragen, staat dan stil, en juist op die plekken wordt het meest gescand. Offline werken is daarom bij dit type app bijna altijd een voorwaarde en geen extra.

Praktisch betekent dat twee dingen. De gegevens die de app nodig heeft om een code te herkennen, staan op het toestel: de artikelenlijst, de locaties, de openstaande orders. En de scans die iemand doet, worden lokaal opgeslagen en verstuurd zodra er weer verbinding is, zonder dat de gebruiker daar iets voor hoeft te doen.

Dat brengt een vraag mee die u vooraf moet beantwoorden: wat als twee mensen offline hetzelfde artikel boeken. Bij tellen is dat op te lossen door beide tellingen te bewaren en het verschil te laten zien. Bij voorra­admutaties is het lastiger. Kies bewust hoe u met dat soort botsingen omgaat voordat u laat bouwen, want achteraf repareren is duur.

Dit is het onderdeel dat het vaakst wordt overgeslagen en dat het meest bepaalt of uw app wordt gebruikt. Er komt een code voorbij die het systeem niet kent: een nieuw artikel, een leverancier die zijn verpakking veranderde, een interne sticker die iemand ooit heeft gedrukt. Wat doet de medewerker dan.

Het slechtste antwoord is een foutmelding en verder niets. Dan legt de medewerker het artikel apart, schrijft hij iets op een briefje en gaat hij verder. Het beste antwoord hangt af van uw proces, maar het komt er meestal op neer dat de scan wordt vastgelegd als onbekend, met de mogelijkheid om er een foto en een aantal bij te zetten, zodat iemand het achteraf kan koppelen.

Dezelfde redenering geldt voor andere afwijkingen. Een aantal dat niet klopt met de order, een artikel op een locatie waar het niet hoort, een code die twee keer wordt gescand. Elk daarvan is een ontwerpvraag met een antwoord dat uit uw proces komt, en samen vormen ze het grootste deel van het werk.

Veel scanprojecten ontdekken halverwege dat er ook etiketten gedrukt moeten worden. Niet alles heeft een bruikbare code: locaties in een magazijn, eigen apparatuur, halffabricaten, dossiers. Zonder eigen etiket valt de helft van het proces buiten de app.

Dat is een deelproject met eigen keuzes. Welk formaat sticker, welk materiaal, en vooral: welke printer. Een thermische labelprinter drukt scherp en snel en is de gangbare keuze in magazijnen. Wat erop komt is een tweede vraag: alleen de code, of ook leesbare tekst voor mensen die niet kunnen scannen.

Let op de omstandigheden. Een etiket in een koelcel, in de buitenlucht of op een machine met olie erop, moet daar tegen kunnen. Een standa­ardsticker laat na een paar weken los of vervaagt, en een onleesbaar etiket is erger dan geen etiket omdat iemand het toch probeert te scannen.

1. Verzamel echte codes uit uw praktijkFotografeer wat u werkelijk tegenkomt, inclusief de rommelige en beschadigde exemplaren.
2. Benoem de scanmomentenWelke handeling hoort bij welke scan, en wie doet die handeling waar.
3. Kies de hardware per scanmomentTelefoon, bluetooth-scanner of handterminal, afhankelijk van het aantal scans per dienst.
4. Ontwerp de foutpadenOnbekende code, afwijkend aantal, dubbele scan en verkeerde locatie. Dit is het meeste werk.
5. Regel offline werkenGegevens op het toestel, scans lokaal bewaard en een zichtbare teller van wat nog moet worden verstuurd.
6. Bepaal of u etiketten druktFormaat, materiaal en printer, en of er ook leesbare tekst op moet.
7. Koppel aan uw voorraad- of ordersysteemZodat een scan iets doet in plaats van alleen wordt vastgelegd.
8. Test in de werkelijke omgevingIn het magazijn, met handschoenen, met vuile etiketten en met slecht netwerk.

Het scannen zelf kost weinig ontwikkeltijd; daar bestaan beproefde bibliotheken voor. De kosten zitten in het aantal processen dat u ondersteunt. Ontvangst, tellen, orderverzamelen en verzending zijn vier verschillende handelingen met elk hun eigen schermen en foutpaden, en dat is vier keer werk in plaats van één keer met een knop erbij.

De tweede post is de koppeling. Een scan die alleen wordt vastgelegd, is een logboek. Een scan die een voorraadmutatie boekt in uw bestaande systeem, vraagt afstemming met dat systeem: welke velden, welke controles, wat als het systeem de boeking weigert. Dat is doorgaans meer werk dan de app zelf.

De derde is hardware. Telefoons heeft iedereen, maar handterminals en labelprinters kosten geld per stuk en vragen beheer: opladen, uitgifte, vervanging bij schade. Dat is geen ontwikkelkost maar het hoort wel in de vergelijking als u afweegt of u een scanner-app laat bouwen.

Vraag bij het eerste gesprek naar de foutpaden en niet naar de scanfunctie. Iemand die uitgebreid vertelt hoe snel zijn scanbibliotheek is maar geen antwoord heeft op wat er bij een onbekende code gebeurt, heeft dit type app nog niet in productie gezien.

Vraag daarnaast om een test in uw eigen omgeving voordat er veel gebouwd is. Niet in een vergaderruimte maar in het magazijn, met echte etiketten, met werkha­ndschoenen en op de plek waar het netwerk slecht is. Een half uur daar levert meer ontwer­pinformatie op dan een week overleg.

En let op wie de app straks gebruikt. Scannen gebeurt door mensen die er de hele dag mee werken en die geen geduld hebben voor een scherm dat drie keer bevestigt. Elke overbodige tik telt op. Laat daarom de mensen die gaan scannen meekijken bij het ontwerp, niet alleen hun leidinggevende.

• Vraag naar de foutpaden, niet de scanfunctie. Onbekende code, dubbele scan en afwijkend aantal zijn waar het project op staat of valt.
• Test vroeg in de echte omgeving. Met echte etiketten, werkha­ndschoenen en slecht netwerk, niet in een vergaderruimte.
• Tel de handelingen per scan. Elke overbodige bevestiging kost tijd die honderden keren per dag terugkomt.
• Laat de scanners meekijken. De mensen die het gaan gebruiken zien binnen vijf minuten wat een ontwerper niet ziet.
• Neem hardware en beheer mee in de vergelijking. Terminals en printers kosten per stuk en iemand moet ze onderhouden.

• Gids: QR-scanner-app
• Gids: voorraadbeheer
• Gids: checklist-app
• Gids: supply chain management