softify.pro - Insiders

Er bestaat een eenvoudige manier om magazijnsoftware overtuigend te doen ogen.
Een dashboard openen.
Een paar groene cijfers tonen.
Een grafiek toevoegen.
Wat voorraad op een magazijnplan zetten.
Afsluiten met een rapport.
Alles oogt in orde.
En toch kan alles fout zijn.
Want een magazijn maalt er niet om hoe mooi het dashboard eruitziet.
Het gaat erom of elk onderdeel van het systeem het erover eens is wat er werkelijk gebeurd is.
Dat werd het interessante deel van het jongste softify.pro Flow-experiment.
Geen extra scherm.
Geen extra KPI.
Geen extra rapport.
Iets veel minder zichtbaars.
Consistentie.
Het begon met een magazijn.
De huidige softify.pro Flow-demo werkt met meerdere synthetische magazijnomgevingen.
Verschillende magazijn-ID's.
Verschillende capaciteiten.
Verschillende zonestructuren.
Geen productievoorraad.
Geen klantgegevens.
Geen echte operationele informatie.
Maar de proceslogica gedraagt zich alsof dat allemaal telde.
Want in de echte logistiek is dat zo.
Van zodra een magazijn geselecteerd is, wordt die context deel van alles wat volgt.
Flows.
SSCC's.
Bewegingen.
Operators.
Analytics.
Rapporten.
Dat klinkt vanzelfsprekend.
Het wordt aanzienlijk minder vanzelfsprekend van zodra hetzelfde proces in meerdere delen van de applicatie begint op te duiken.
Toen openden we een andere weergave.
Operational Analytics.
Plots zag het magazijn er helemaal anders uit.
Geen opslagplaatsen.
Geen bewegingspijlen.
In de plaats:

• afgeronde Flows,
• actieve orders,
• magazijnbezetting,
• uitzonderingen,
• inbound,
• outbound,
• verwerkingstijd.

De visuele voorstelling was veranderd.
Het magazijn niet.
Dat onderscheid werd belangrijk.
Want onder de KPI's zaten nog steeds individuele records.
Flow-ID's.
SSCC's.
Zones.
Statussen.
Operators.
Verwerkingstijden.
Andere weergave.
Dezelfde operationele realiteit.
Tot zover geen probleem.

Operational Analytics — geaggregeerde magazijnstatus, met de onderliggende Flow-records nog steeds zichtbaar.

88% is alleen nuttig als het systeem het kan verklaren.
Stel dat het dashboard zegt:
Magazijnbezetting: 88%.
Nuttig.
Maar onvolledig.
Sommige plaatsen zijn bezet.
Sommige zijn gereserveerd.
Sommige blijven vrij.
Die statussen zijn niet inwisselbaar.
Het cijfer wordt pas betrouwbaar als het systeem nog kan uitleggen waar het vandaan komt.
Vijf afgeronde Flows?
Toon ze.
Twee actieve orders?
Toon ze.
Eén uitzondering?
Welke?
88% bezetting?
Wat is bezet?
Wat is gereserveerd?
Wat blijft vrij?
Een dashboard hoort de realiteit samen te vatten.
Het hoort ze niet te vervangen.
Toen veranderden we de taal.
Nederlands.
Het magazijn bleef hetzelfde.
De Flow-ID's bleven dezelfde.
De SSCC's bleven dezelfde.
De operators bleven aan hun records gekoppeld.
Enkel de taal veranderde.
Later verscheen dezelfde operationele status in het Kroatisch.
Vervolgens in het Frans.
Hier wordt meertalige software veel interessanter dan vertaalde knoppen.
Een slechte vertaling valt snel op.
Een statuswijziging veroorzaakt door een taalwissel is veel gevaarlijker.
Stel je voor: overschakelen van Duits naar Frans en stilletjes de geselecteerde Flow kwijtraken.
Of een filter heropbouwen tegen het verkeerde magazijn.
Of de juiste SSCC tonen binnen de verkeerde procescontext.
De interface kan er nog steeds perfect uitzien.
Het systeem zou dat niet zijn.
Flow volgt daarom een eenvoudige regel:
Taal mag de woorden veranderen. Ze mag de waarheid niet veranderen.
Vervolgens kreeg de Flow een geschiedenis.
Browse & Drill-down doet geen bijzondere moeite om indrukwekkend te lijken.
Misschien is dat net waarom het nuttig is.
Selecteer een Flow.
De context verschijnt.
Magazijn.
Zone.
Status.
Operator.
SSCC.
En dan de documentketen.
ASN.
Goederenontvangst.
Magazijnbeweging.
Pickorder.
Picken.
Verzending.
FLOW.
Zeven stappen.
Het proces is niet langer enkel een huidige status.
Het heeft een verleden.
En dat verandert de vraag.
In plaats van:
Wat gebeurt er?
kunnen we vragen:
Hoe zijn we hier geraakt?
Dat is een veel betere vraag wanneer er uiteindelijk iets misloopt.

Eén Flow, één SSCC, één documentketen — van ASN tot afronding.

SSCC wordt de rode draad.
Op het eerste zicht ziet een SSCC eruit zoals het is.
Een identificatiecode.
Een lang nummer in een tabel.
Maar doorheen Flow wordt het iets nuttigers.
Een rode draad doorheen het proces.
Volg hem en andere zaken beginnen zich te verbinden.
Een magazijn.
Een Flow.
Een zone.
Een status.
Een operator.
Een documentketen.
Uiteindelijk een rapport.
Hetzelfde fysieke logistieke object is nu zichtbaar vanuit meerdere delen van de applicatie.
Nuttig.
Ook gevaarlijk.
Want elke bijkomende weergave creëert weer een kans voor het systeem om een ander verhaal te vertellen.
En daar wordt het interessant.
Stel dat Analytics zegt dat de Flow actief is.
Drill-down zegt dat de SSCC bij die Flow hoort.
De documentketen zegt dat de operatie verder gevorderd is.
Het rapport zegt iets anders.
Wat klopt er?
Dit is geen Flow-specifiek probleem.
Het is een van de oudste problemen in bedrijfssoftware.
Verschillende delen van hetzelfde systeem ontwikkelen geleidelijk hun eigen versie van de werkelijkheid.
Het ene scherm leest de transactionele status.
Een ander leest een aggregaat.
Nog een ander steunt op gecachte gegevens.
Een rapport berekent iets net iets anders.
Een uitzondering wordt operationeel opgelost maar verdwijnt uit de rapportering.
Elk onderdeel werkt.
Het volledige systeem liegt.
Meestal beleefd.
Dus openden we het Report Center.
Dagelijks operationeel overzicht.
Voorraad en bezetting.
Flow-prestaties.
SSCC-traceerbaarheid.
Uitzonderingen en SLA.
Hetzelfde operationele verhaal verscheen opnieuw.
Afgeronde Flows.
Actieve orders.
Magazijnbezetting.
Uitzonderingen.
Inbound.
Outbound.
Verwerkingstijd.
Maar deze keer was de vraag niet of het rapport correct oogde.
De vraag was:
Kan het zichzelf verantwoorden?
Een goed rapport geeft je een cijfer.
Een beter systeem kan uitleggen waar dat cijfer vandaan komt.

Rapportering vanuit dezelfde operationele status — geen tweede versie van de werkelijkheid.

De uitzondering was er nog steeds.
Een van de stillere details bleek een van de belangrijkere te zijn.
De demogegevens bevatten een uitzondering.
Ze verschijnt in Analytics.
Ze verschijnt in Drill-down.
Ze verschijnt in de SSCC-traceerbaarheid.
Ze verschijnt in het Report Center.
En ze blijft zichtbaar in Exceptions & SLA.
Precies dat hoort te gebeuren.
Operationeel herstellen van een uitzondering betekent niet dat de uitzondering uit de geschiedenis moet verdwijnen.
"Het proces ging door" en "er is niets gebeurd" zijn niet dezelfde bewering.
In de logistiek maakt dat verschil uit.
Op dit punt hadden we een testprobleem.
Geen softwareprobleem.
Een testprobleem.
We hadden nu hetzelfde magazijn voorgesteld als:

• analytics,
• afzonderlijke Flows,
• SSCC-geschiedenissen,
• documentketens,
• rapporten,
• en uitzonderingsweergaven.

Elk kon apart getest worden.
Openen.
Klikken.
Filteren.
Verifiëren.
Slagen.
Volgende.

Dat zou eenvoudig zijn.
Het zou ook het interessante deel missen.
Want zes groene vinkjes bewijzen niet dat zes weergaven met elkaar overeenstemmen.
Daar komt COCO.
Opnieuw.
COCO had al eerder met Flow te maken gehad.
Authenticatie.
Gebruikers.
Rollen.
Databaseomgevingen.
Talen.
Desktop-uitvoering.
Toen kwam de logistiek.
Magazijnen.
Voorraad.
Picken.
Bewegingen.
Uitzonderingen.
Documenten.
Ubuntu.
Red Hat Enterprise Linux.
Deze keer gaven we COCO iets net iets anders.
Geen scherm om te verifiëren.
Een verhaal om te volgen.
Neem dit magazijn.
Neem deze Flow.
Neem deze SSCC.
Open Analytics.
Open Drill-down.
Verander de taal.
Kijk opnieuw.
Open het rapport.
Vind dezelfde Flow.
Vind dezelfde SSCC.
Vind de uitzondering.
Vergelijk.
Vergelijk dan opnieuw.

COCO volgt dezelfde operationele context doorheen softify.pro Flow — analytics, traceerbaarheid, taalwissels en rapportering.

Dat verandert de aard van de test.

De vraag is niet langer:

• Werkt elke module?

Ze wordt:

• Geloven alle modules dat hetzelfde gebeurd is?

Een veel betere vraag.
Veel minder comfortabel.
Een magazijnsysteem hoort één geheugen te hebben.
Operators zien misschien posities.
Magazijnverantwoordelijken zien misschien KPI's.
Support gebruikt misschien drill-down.
Auditors gebruiken misschien rapporten.
COCO ziet ze misschien allemaal.
Maar onder die perspectieven hoort er één geschiedenis te zijn.
Eén Flow hoort niet meerdere biografieën te krijgen, afhankelijk van welke module open staat.
Eén SSCC hoort niet meerdere verledens te hebben.
Eén uitzondering hoort niet enkel te bestaan waar het uitkomt.
Eén magazijn hoort geen ander magazijn te worden omdat de interfacetaal veranderde.
Daar draait het huidige Flow-experiment eigenlijk om.
Niet om dashboards.
Niet om rapporten.
Zelfs niet om afzonderlijke schermen.
Om één operationele waarheid, op verschillende manieren uitgedrukt.
Controle.
Het magazijn kennen.
De status kennen.
Weten wat er beweegt.
Weten welk proces het bezit.
Duidelijkheid.
KPI's terug omzetten in records.
Records omzetten in geschiedenis.
Uitzonderingen omzetten in bewijs.
Een SSCC omzetten in iets traceerbaars.
Flow.
Een magazijn wordt geselecteerd.
Analytics begint het te beschrijven.
Een Flow gaat vooruit.
De SSCC blijft eraan gekoppeld.
Een documentketen groeit.
Een uitzondering verschijnt.
Het proces gaat door.
Het rapport onthoudt het.
Dan verandert de taal.
Het magazijn is nog steeds hetzelfde.
De Flow is nog steeds dezelfde.
De geschiedenis is nog steeds dezelfde.
Dat was het verwachte deel.
Wat daarna gebeurde was interessanter.
COCO stopte met het apart testen van de weergaven.
Het begon ze te vergelijken.
Een tijdlang gebeurde er niets bijzonders.
Zelfde magazijn.
Zelfde Flow.
Zelfde SSCC.
Zelfde verhaal.
Opnieuw.
Opnieuw.
Opnieuw.
En toen stopte COCO.
Niet omdat de applicatie vastliep.
Dat was niet het geval.
Niet omdat een test faalde in de gebruikelijke zin.
Dat was niet het geval.
Het stopte omdat twee perfect redelijke antwoorden een derde vraag opleverden.

Wij weten wat de vraag is.
Flow weet waarom het bestaat.
COCO weet waar het vervolgens moet kijken.

De rest kan wachten.

Control. Clarity. Flow.

We zouden waarschijnlijk moeten stoppen met COCO ideeën te geven.
Het vorige experiment zou genoeg moeten zijn geweest.
Een echte applicatie.
Echte navigatie.
Gebruikers.
Rollen.
Databases.
Talen.
Bewijs.

Een respectabele case study.
Een nette conclusie.
Toen liet iemand het zien: Logistics in Motion.
Dat was waarschijnlijk de vergissing.

Het begon met drie magazijnen
Niets bijzonder opwindends.
Drie DEMO-magazijnen.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Synthetische data.
Geen klantinformatie.
Geen productievoorraad.

Precies het soort omgeving waar niets belangrijks zou moeten gebeuren.
Toen werd het eerste magazijn geselecteerd.
En de applicatie kreeg context.
Vanaf dat moment had elk scherm nog een vraag eraan gekoppeld.

Hoort dit nog bij hetzelfde magazijn?
Verandert de taal alleen de interface?
Blijft het proces op dezelfde stap?
Klopt de voorraad nog?
Wijst de documentreferentie nog naar het juiste evenement?
Ziet de operator precies wat nodig is voor de volgende actie?

Plotseling was niet meer het scherm het interessante deel.
Het was de continuïteit tussen schermen.

COCO doet dat graag.

Logistiek is geen verzameling schermen
Van buitenaf kan magazijnsoftware bedrieglijk eenvoudig lijken.
Goederen komen aan.
Ze worden opgeslagen.
Iemand bestelt ze.
Ze worden gepickt.
Ze worden verzonden.
Klaar.
Behalve dat er een hele operationele wereld verborgen zit tussen aangekomen en verzonden.
Verwacht.
Ontvangen.
Gecontroleerd.
Beschikbaar.
Gereserveerd.
Verplaatst.
Gepickt.
Geblokkeerd.
Gecorrigeerd.
Verzonden.
Gecontroleerd (audit).

De fysieke beweging telt.
Maar het is de statusovergang die die beweging begrijpelijk maakt voor software.
En wanneer die twee realiteiten niet meer overeenkomen, heeft iemand uiteindelijk een slechte dag.



Een magazijn is makkelijker te begrijpen wanneer beweging zichtbaar is, niet slechts geregistreerd.
Daarom is ons logistieke werk nooit echt begonnen met menu's, dashboards, of technologie.
Het begint met de materiële Flow.

Waar komt informatie binnen?
Waar verandert ze?
Waar kan ze verloren gaan?

Waar wordt iemand gedwongen om een ander te vragen wat er is gebeurd?
Waar wordt een handmatige stap stilletjes het zwakste deel van een verder geautomatiseerd proces?
Soms is het antwoord een nieuwe interface.
Soms een integratie.
Soms een scanner.
Soms gewoon een beter statusmodel.

Meer software is niet automatisch betere software.
Het doel is niet automatisering omwille van zichzelf.
Het doel is een proces dat begrijpelijk blijft.

Control. Clarity. Flow.

Het proces begint vóór de eerste boeking.
Vóór de goederenontvangst.
Vóór het picken.
Vóór de voorraadbeweging.
Vóór de eerste transactie.
Flow stelt een heel basale vraag:
In welk magazijn werken we?
Het klinkt bijna triviaal.
Dat is het niet.
Magazijncontext hoort bij alles wat volgt.
Voorraad.
Documenten.
Locaties.
Picken.
Verplaatsingen.
Auditgeschiedenis.
Uitzonderingen.

Het proces kan er perfect gezond uitzien terwijl het in de verkeerde context werkt.
Dat is precies het soort probleem dat een screenshot zelden onthult.
En precies het soort grens die COCO graag bevraagt.

Taal is makkelijk tot het dat niet meer is
Duits.
Engels.
Kroatisch.
Noors.
En andere.

Een gebruikersprofiel definieert de beschikbare talen.
De operator wisselt van taal terwijl de applicatie actief is.
De interface verandert onmiddellijk.
Het bedrijfsproces mag dat niet doen.
Dat onderscheid is belangrijk.
Het magazijn verplaatst zich niet omdat het woord voor magazijn is veranderd.
De pickopdracht start niet opnieuw omdat de gebruiker een andere taal koos.
Een reservering verdwijnt niet.
Een uitzondering behoort niet plotseling tot een andere transactie.
Het proces blijft waar het is.
Alleen de weergave ervan verandert.
Dat klinkt vanzelfsprekend.

Totdat je beseft hoeveel applicaties een taalwissel bijna als een nieuwe sessie behandelen.

Een meertalige bedrijfsapplicatie zou dat niet moeten doen.
De presentatiestatus mag veranderen.
De bedrijfsstatus moet stabiel blijven.
Dat maakt taalwisseling een verrassend nuttige regressietest.
Een kleine functie.
Een heel goede breuklijn.
COCO houdt van breuklijnen.

Stap voor stap begint de applicatie geschiedenis op te bouwen
Goederen komen aan.
Het proces gaat verder.
De goederenontvangst wordt geboekt.
De voorraad verandert.
De magazijnstatus weerspiegelt de nieuwe realiteit.
Het picken begint.
Voorraad wordt gereserveerd.
De operator ontvangt een taak.

Een mobiele weergave reduceert het hele proces tot wat op dat exacte moment telt:
Positie.
Opslaglocatie.
Hoeveelheid.
SSCC.
Operator.
Niet meer.
Niet minder.
Dat is belangrijk.
De mobiele interface is geen tweede bedrijfsproces.
Het is een andere weergave van hetzelfde proces.
De magazijnapplicatie mag alles weten.
De picker hoeft dat niet.
Clarity betekent niet altijd meer informatie tonen.
Soms betekent clarity de discipline hebben om bijna alles te verbergen.

Dan scant iemand de verkeerde locatie
Hier wordt een logistieke workflow interessanter dan een functielijst.
De verwachte locatie is één ding.
De gescande locatie is iets anders.
Flow stopt.
Crasht niet.
Stopt.
Er is een verschil.
De processtatus blijft zichtbaar.
De betrokken voorraad blijft begrijpelijk.
De uitzondering wordt expliciet.

Contextuele hulp legt uit wat relevant is voor de huidige situatie.
De gebruiker lost de discrepantie op.
Het proces gaat verder.
Dit moment zegt meer over operationele software dan meerdere pagina's happy-path screenshots.
Echte logistiek is niet moeilijk wanneer alles klopt.
Echte logistiek wordt moeilijk wanneer iets bijna klopt.
Een nuttig systeem verbergt dat niet achter een groen dashboard.
Het geeft de uitzondering een status.

Een reden.
Een geschiedenis.
En een weg vooruit.

Documenten onthouden wat mensen vergeten

Naarmate de workflow vordert, beginnen referenties zich op te stapelen.
ASN.
Goederenontvangst.
Magazijnbeweging.
Picken.
Verzending.
Flow.
Het interessante deel is niet dat documenten bestaan.
Het interessante deel is dat ze hetzelfde verhaal vertellen als het proces.
Waarom is deze voorraad hier?
Welke ontvangst heeft het geïntroduceerd?
Welke operatie heeft het gereserveerd?
Welke picking heeft het verbruikt?
Welke zending heeft het eruit verplaatst?
Is een uitzondering opgelost vóór de volgende stap?
Wat was het actieve magazijn?
Wat gebeurde er vóór de huidige status?
Wanneer status en documentatie door hetzelfde proces worden geproduceerd, wordt traceerbaarheid gemakkelijker te vertrouwen.
Wanneer dat niet zo is, beginnen mensen uiteindelijk de geschiedenis te reconstrueren.
Meestal in Excel.
Meestal onder druk.
Meestal nadat er al iets misging.
COCO geeft de voorkeur aan bewijs vóór dat moment.
Blijkbaar reist COCO ook
Er was nog een kleine verandering tussen de runs.
Ubuntu had zijn run.
Red Hat Enterprise Linux 10 nam de volgende.
COCO ging door.
Geen ceremonie.
Geen speciale "Red Hat-modus".
Geen herschreven workflow.
Geen handig vereenvoudigde test.
Dezelfde Flow.
Andere ondergrond eronder.
Een eerdere COCO-run had de applicatie al getest op Ubuntu Linux.
De huidige verhuisde naar Red Hat Enterprise Linux 10.
Andere desktopomgeving.
Andere systeembibliotheken.
Andere verpakking.
Andere operationele omgeving.
Hetzelfde magazijn.
Dezelfde bedrijfsstatussen.
Dezelfde voorraadovergangen.
Dezelfde taalwisselingen.
Dezelfde uitzonderingslogica.
Hetzelfde bewijs.
Dat is een behoorlijk mooie manier om cross-platform software te testen.

Kondig niet aan dat het cross-platform is. Verplaats het. Kijk dan wat er breekt.

Taalstatus.
Magazijncontext.
Dialooggedrag.
Timing.
Thema's.
Procesovergangen.
Uitzonderingsafhandeling.
Bewijs.
Besturingssystemen hebben verrassend creatieve manieren om aannames bloot te leggen.

Ubuntu legde er sommige bloot.
Red Hat legt andere bloot.
Dat is nuttig.

Want multi-platform engineering is niet het vermogen om het uitvoerbare bestand tweemaal te starten.

Het is het vermogen om de omgeving te veranderen zonder de betekenis van het proces te veranderen.
Een magazijnoperator zou het niet moeten uitmaken of de applicatie op Ubuntu of Red Hat draait.
Een pickopdracht zou het ook niet moeten uitmaken.
Evenmin een auditspoor.
Als platformverschillen bedrijfsgedrag beginnen te veranderen, is de software niet echt cross-platform.
Het is slechts overdraagbaar.
COCO lijkt aanzienlijk meer geïnteresseerd te zijn in de eerste definitie.
Wij ook.

COCO beslist niet wat correcte logistiek betekent
Dit deel is belangrijk.
COCO wordt geen magazijnexpert alleen omdat het een magazijnworkflow kan volgen.
Mensen blijven correctheid definiëren.
Mensen beslissen wanneer voorraad beschikbaar wordt.
Mensen definiëren wat een geblokkeerde levering betekent.
Mensen beslissen wie een hoeveelheid mag corrigeren.
Mensen definiëren welke beweging een auditspoor vereist.
Mensen beslissen hoe een geldige uitzonderingsoplossing eruitziet.
Mensen beslissen wanneer een zending echt compleet is.
Het werk van COCO is anders.

Herhalen.
Observeren.
Vergelijken.
Onthouden.
Bewijs achterlaten.

Doe het dan opnieuw nadat de software verandert.
En opnieuw.
En opnieuw.
Zonder verveeld te raken.
Zonder te beslissen dat het resultaat van vorige week waarschijnlijk nog geldig is.
Zonder de vervelende uitzondering over te slaan omdat de lunch over twaalf minuten is.
De glamoureuze toekomst van AI-testen bevat een verrassende hoeveelheid herhaling.
Wij beschouwen dat als een functie.

Bewijs verandert het gesprek
Traditioneel testen eindigt vaak met een volkomen redelijke zin:
"Het werkte toen ik het testte."

COCO is geïnteresseerd in de volgende zin.

Wat werkte precies?
Welk magazijn?
Welke gebruiker?
Welke taal?
Welke processtatus?
Welke volgorde?
Welk document?
Welke voorraadwaarde?
Wat gebeurde er onmiddellijk vóór de teststap?
Wat veranderde onmiddellijk daarna?
Kan een andere engineer het resultaat begrijpen zonder de persoon te vragen die de test heeft uitgevoerd?
Dat is waar regressietesten meer wordt dan herhaald klikken.
Eén scherm kan correct zijn terwijl het proces fout is.
Een pickvenster kan er perfect uitzien terwijl de voorraad al is afgedreven.
Een document kan bestaan terwijl de status die het had moeten creëren nooit is opgetreden.
Een applicatie kan 100% weergeven terwijl een auditspoor stilletjes tegenspreekt.
COCO volgt de Flow omdat het in de Flow is dat deze tegenstrijdigheden zichtbaar worden.

Ergens tussen Control en Flow
Er is hier een interessante symmetrie.
Goede logistieke software probeert onzekerheid binnen een operatie te verminderen.
Goed testen probeert onzekerheid over de software die het uitvoert te verminderen.
De ene vraagt:
Waar is het artikel?
De andere vraagt:
Hoe weten we dat de software het nog weet?
De ene vraagt:
Is deze beweging voltooid?
De andere vraagt:
Welk bewijs toont aan dat de status correct is veranderd?
De ene vraagt:
Kan de volgende shift verdergaan?
De andere vraagt:
Kan de volgende engineer begrijpen wat er is gebeurd?
Verschillende vragen.
Hetzelfde instinct.
Maak de status zichtbaar.
Bewaar de redenering.
Verminder de hoeveelheid kennis die alleen in iemands hoofd bestaat.
Misschien is dat de connectie die we oorspronkelijk niet hadden gepland.

Engineering excellentie zonder het spandoek
Niemand klikt op een Engineering Excellence-knop.
Die is er niet.
En die zou er waarschijnlijk ook niet moeten zijn.
Engineering excellentie verschijnt indirect.
De magazijncontext overleeft een taalwissel.
Hetzelfde proces overleeft een ander Linux-platform.
Een voorraadbeweging blijft traceerbaar.
Een mobiele picker ziet precies wat nodig is en niets anders.
Een uitzondering onderbreekt het proces zonder de status ervan te vernietigen.
Het helpvenster legt de huidige context uit in plaats van generieke documentatie te tonen.
De documentketen komt overeen met de operationele volgorde.
De volgende engineer kan begrijpen wat er is gebeurd zonder de persoon te vragen die toevallig aanwezig was.
Er is genoeg theater beschikbaar in moderne software.
AI kan indrukwekkende demonstraties genereren.
Dashboards kunnen animeren.
Cijfers kunnen bewegen.
Video's kunnen er heel overtuigend uitzien.
Niets van dat alles bewijst dat twee voorraadoperaties niet stilletjes een onjuist resultaat kunnen produceren.
Niets van dat alles bewijst dat een uitzondering weken later nog kan worden gereconstrueerd.
Niets van dat alles bewijst dat de magazijnmedewerker, de dispatcher, en de ontwikkelaar naar dezelfde operationele waarheid kijken.

Engineering excellentie begint op een minder fotogenieke plek.

Met consistentie.
Met bewijs.
Met grenzen.

Met de bereidheid om de saaie delen saai te houden.
Onzichtbare betrouwbaarheid produceert zelden de meest dramatische screenshot.
Totdat je er bewust naar begint te zoeken.

Control. Clarity. Flow.
Control is weten welk magazijn, welk proces, en welke status actief zijn.
Clarity is begrijpen wat er veranderde, wanneer het veranderde, en waarom.
Flow is de operatie laten doorgaan zonder het verhaal erachter te verliezen.
Dat werkt voor logistiek.
Het werkt voor softwaretesten.
Het werkt verrassend goed voor engineering zelf.
Het eerste Flow-experiment gaf COCO de Administration.
Gebruikers.
Rollen.
Databases.
Talen.
Toen gaf iemand het een magazijn.
Toen meerdere talen.
Toen mobiel picken.
Toen voorraad.
Toen verplaatsingen.
Toen uitzonderingen.
Toen documenten.
Toen nog een besturingssysteem.
Op dit punt zouden we waarschijnlijk moeten stoppen met dingen toevoegen.
Waarschijnlijk zullen we dat niet doen.

Control. Clarity. Flow.

Ubuntu had zijn beurt.

Red Hat heeft de huidige.

De Flow blijft bewegen.

COCO blijft kijken.
En ergens in het midden van de laatste run werd het duidelijk dat er nog een vraag wacht achter deze.

Wij weten wat het is.
COCO weet wat het is.
Jij weet het niet.
Nog niet.

We zouden het je kunnen vertellen.

Maar dan zou je misschien stoppen met controleren of er een nieuw Insiders-artikel is verschenen.
En dat zou het experiment verpesten.

Aan de engineer die deze repository voor het eerst opent: Welkom.

Misschien ben je hier omdat er iets misliep.

Een dienst reageerde niet meer.

Een deployment gedroeg zich onverwacht.

Een alert maakte je midden in de nacht wakker.

Of misschien ben je gewoon nieuwsgierig hoe dit platform werkt.

Wat je ook hierheen heeft gebracht,
weet dat dit project precies voor zulke momenten werd gebouwd.

Niet om moeilijke problemen weg te nemen.

Maar om moeilijke problemen begrijpelijk te maken.

Je vindt hier code.

Je vindt hier documentatie.

Je vindt hier specificaties.

Maar belangrijker nog,
hoop ik dat je redenering vindt.

Iemand vóór jou stelde moeilijke vragen.

Iemand verzamelde bewijs.

Iemand nam beslissingen.

Iemand legde uit waarom.

Die uitleg maakt deel uit van het platform.

Behandel ze met hetzelfde respect als de broncode.

Op een dag
zal je iets verbeteren.

Misschien is het een piepklein bugje.

Misschien is het een volledig nieuwe mogelijkheid.

Wat je ook verandert,
onthoud dat een andere engineer ooit jouw werk erft.

Laat hen meer na dan werkende software.

Laat hen begrip na.

Leg je bedoeling uit.

Documenteer je aannames.

Bewaar je bewijs.

Vertel het verhaal achter de beslissing.

Dat verhaal kan iemand ooit uren – of dagen – aan onderzoek besparen.

Wees niet bang om technologie te vervangen.

Vervang bibliotheken.

Vervang providers.

Vervang deploymentmodellen.

Vervang programmeertalen.

Vervang architecturen indien nodig.

Maar vooraleer je een idee vervangt,
begrijp waarom het bestond.

Vooruitgang zonder begrip is slechts verandering.

Vooruitgang gebouwd op begrip wordt evolutie.

Er zullen momenten zijn waarop het platform je verrast.

Behandel die momenten als geschenken.

Elke verrassing onthult iets wat de architectuur nog niet begreep.

Onderzoek geduldig.

Verzamel bewijs.

Verbeter doordacht.

Laat de les nadien achter voor wie na jou komt.

Zo groeit technische kennis.

Er zullen ook momenten zijn waarop er niets interessants gebeurt.

Ook die momenten tellen.

Rustige systemen zijn vaak gezonde systemen.

Als COCO naar de achtergrond verdwijnt omdat incidenten korter worden,
omdat uitleg helderder wordt,
omdat onboarding makkelijker wordt,
omdat engineers het bewijs vertrouwen,
dan slaagt het platform.

Onzichtbare betrouwbaarheid is een van de hoogste vormen van technische excellentie.

Meet dit project niet af aan het aantal automatiseringen dat het uitvoert.

Meet het af aan vragen zoals deze:

• Worden mensen minder vaak onderbroken?
• Begrijpen engineers systemen dieper?
• Zijn belangrijke beslissingen makkelijker uit te leggen?
• Overleeft operationele kennis teamwissels?
• Worden fouten minder vaak herhaald?
• Worden nieuwe engineers sneller doeltreffend?

Dat zijn de resultaten die het waard zijn om te bewaren.

Onthoud ten slotte dat geen enkel handboek volledig is.

Geen enkele specificatie voorspelt elke toekomst.

Geen enkele architectuur overleeft voor altijd ongewijzigd.

Dat is geen zwakte.

Het is een uitnodiging.

Observeer de werkelijkheid.

Bevraag aannames.

Verbeter het platform.

Leer het aan wie na jou komt.

En wanneer jouw eigen tijd als beheerder ooit ten einde loopt, laat dan een systeem achter dat rustiger, helderder, begrijpelijker en betrouwbaarder is dan het systeem dat je hebt overgenomen.

Als elke generatie dat doet, zal COCO nooit echt verouderen.

Want het grootste bezit ervan zal niet de software zijn.

Het zal de technische discipline zijn die wordt voortgedragen door de mensen die eraan blijven bouwen.

Dank je dat je een van hen bent geworden.

Het volgende hoofdstuk staat niet meer in dit handboek.

Het volgende hoofdstuk staat in de code die je zo dadelijk gaat schrijven.

Het COCO-handboek

Want software evolueert.
Een goede architectuur evolueert trager.

En een goede filosofie zou beide moeten overleven.

softify.pro