Waarom event-operaties een eigen besturingssysteem verdienen

Kijk naar hoe een gemiddelde evenementenoperatie draait en je ziet een paradox. Er is enorm veel structuur: vergunningen, draaiboeken, veiligheidsplannen, roosters, protocollen. En tegelijk is er bijna geen samenhang: het draaiboek staat in de mail, de plattegrond is een PDF, de bezetting in een spreadsheet, de actuele stand in een appgroep, en de meldingen op een kladblok. Vijf bronnen, vijf plekken, geen enkele die de andere kent.

Dat is geen toeval en geen slordigheid. Het is het gevolg van waar dertig jaar software-ontwikkeling naartoe ging. Kantoorwerk werd stap voor stap geïntegreerd — agenda, mail, documenten, projecten, alles praat met elkaar. De structuur van frontline-werk veranderde in diezelfde periode nauwelijks. De mensen die het echte werk buiten doen, werken nog grotendeels met gereedschap dat voor de kantoortuin is ontworpen, of met helemaal niets dat voor hen is gemaakt.

En dat is geen niche. Wereldwijd doet naar schatting 80% van de beroepsbevolking werk dat niet achter een bureau plaatsvindt — en juist die groep wordt het slechtst bediend door software, die vrijwel altijd is gebouwd rond de kantoormedewerker. De grootste groep werkenden werkt met de minste ondersteuning.

Wat hier ontbreekt is geen tool. Het is een operationeel model.

Een zoveelste app erbij lost niets op — dan heb je zeven plekken in plaats van zes. Wat een operatie nodig heeft is het omgekeerde: één plek waar de dingen die nu los zweven samenkomen. Meldingen, kaarten, protocollen, bezetting en programma in hetzelfde beeld, zodat een beslissing op de ene plek meteen zichtbaar is op de andere. Niet omdat het netjes staat, maar omdat de operatie dan als één geheel kan denken in plaats van als zes losse groepschats.

Van aankoop naar werkwijze

Er zit nog een tweede eigenschap aan zo'n model, en die is misschien belangrijker dan de integratie zelf: het onthoudt. Als meldingen, bezetting en beslissingen op één plek samenkomen, dan is het event van vandaag automatisch het startpunt van het event van volgend jaar. Dezelfde locatie, dezelfde organisator, maar dan met de vorige editie als bevraagbaar geheugen ernaast. Elke keer dat je draait, word je een beetje slimmer — niet omdat iemand een evaluatie schreef, maar omdat het systeem het bijhield.

Dat is het verschil tussen een tool die je koopt en een werkwijze die je opbouwt. Een tool gebruik je; een werkwijze wordt onderdeel van hoe je werkt. Wij denken dat frontline-operaties dat laatste verdienen — geen aankoop die in een la verdwijnt, maar een besturingssysteem voor de operatie zelf, dat meegroeit met elke editie.

Dit is deel vier van een serie over frontline-werk. In deel 1 ging het over waar de communicatie leeft, in deel 2 over de kennis die verdampt, in deel 3 over het gereedschap dat je crew al gebruikt. Hier komt het samen: al die losse draden vragen om één plek.

Dezelfde vraag, nu op operatieniveau: wat als de hele operatie — meldingen, kaarten, protocollen, bezetting, programma — als één geheel had gewerkt, en elke editie het geheugen van de vorige al bij zich droeg?

Frontline Futures onderzoekt wat frontline-werk nodig heeft: dezelfde context en ondersteuning die kantoorwerk allang van software krijgt. Elke aflevering opent met een echte operationele observatie en sluit met dezelfde vraag — wat als de juiste kennis al in iemands hand had gezeten? Vorige: 3 · Je crew gebruikt al AI — alleen niet veilig. Volgende: 5 · Wat gebeurt er als élk crewlid context heeft?

Bron: BCG × Flip, "Facing the Deskless Labor Shortage with Technology" (2024) — de digitale kloof tussen kantoor- en deskless-werkers, die circa 80% van de wereldwijde beroepsbevolking vormen en structureel onderbediend worden door software die voor kantoorwerk is ontworpen.