De tien meest schadelijke vormen van oneigenlijk gebruik van de spreadsheet als applicatieontwikkelplatform.
Deze blog hoort bij een LinkedIn drieluik over baanbrekende ontwikkelingen in dataverwerking uit de jaren zeventig en tachtig van de twintigste eeuw:
- Over Ted Codd’s relationele database model
- Over het SQL van Chamberlin en Boyce
- En over spreadsheets
waarmee u, samen met deze post, zo wel een indruk heeft van hoe het hoofdstuk over deze belangrijke twee decennia in het boek History of Data er uit is komen te zien.
VisiCalc was in 1979 een zichtbare rekenmachine. Eén gebruiker, één model, directe feedback. Codd had data net een logische laag gegeven. Boyce en Chamberlin gaven die laag een zin: zeg wát je wilt, laat de machine uitzoeken hóe.
De spreadsheet deed het omgekeerde. Hij zei: begin maar. Geen schema. Geen constraints. Geen scheiding tussen betekenis en cel. Precies daarom won hij bij de business.
Vijftig jaar later is dat zelfcijferende werkblad het grootste schaduw IT platform ter wereld. Bedoeld voor what-if. Gebruikt als administratie, workflow, database, rapportage én bron van waarheid. Voor de organisatie is dat duur. Voor de data engineer is het een verdienmodel dat niemand zo had willen ontwerpen.
Hieronder de tien vormen die ik het vaakst heb mogen ont-excelleren.
1. De spreadsheet als systeem van record
Er is een bronsysteem. En dan is er het bestand. Facturatie draait officieel in het ERP. De bedragen waarmee echt gestuurd wordt, staan in jaarrekening_v27_def_(dezekanweg).xlsx.
Schade: twee werkelijkheden. Audits vergelijken systemen met een raster dat niemand durft aan te raken. Besluiten rusten op de kopie, niet op de bron.
Werk voor de data engineer: uitzoeken welke kolom de waarheid beweert te zijn, waarom die afwijkt van de database, en hoe je historische cijfers toch naar het nieuwe platform krijgt.
2. De spreadsheet als database zonder model
Lookups over vijf tabbladen. Klantnamen als sleutel, tot iemand “J. Jansen” en “Jansen, J.” allebei invoert. Geen unieke identifiers, wel 80.000 rijen en een VERT.ZOEKEN die bij elke herberekening de lunch pauzeert.
Schade: dubbele entiteiten, stille fouten, rapportages die “bijna” kloppen. Bijna is in finance en operations een duur woord.
Werk voor de data engineer: modelleren wat er impliciet al in zat — relaties, kardinaliteit, de klant die drie keer bestaat — en dat pas daarna in een echte tabel zetten. Access was ooit de reddingsboei. Tegenwoordig heet dezelfde klus warehouse, dbt of “we moeten eerst de sleutels rechtzetten”.
3. De spreadsheet als multi-userapplicatie
Er is geen gelijktijdig gebruik. Er is e-mail. Maandagochtend liggen er veertien versies in Postvak IN. Iemand heeft in de trein op zijn telefoon een cel overschreven. De “master” is het bestand van degene die het hardst roept.
Schade: verloren wijzigingen, schijnbare consensus, ruzie over welk getal in de boardpresentatie hoort.
Werk voor de data engineer: reconstrueren wie wanneer wat bedoelde. Dat is forensisch werk, geen modellering.
4. De spreadsheet als workflow-engine
Status zit in de vulkleur. Groen is akkoord, oranje is “even nazoeken”, rood is afgekeurd — behalve op tabblad Q3, daar betekent rood “niet van toepassing”. Autofilters zijn het autorisatiemodel. De procesbeschrijving staat in het hoofd van Marie.
Schade: het proces is onzichtbaar voor iedereen die het bestand niet ademt. Audit trails bestaan niet. Als Marie op vakantie is, staat de keten stil.
Werk voor de data engineer: kleuren terugvertalen naar statuswaarden, uitzonderingen documenteren, en uitleggen waarom een workflowtool geen luxe is maar de belofte die het raster nooit kon waarmaken.
5. Versiebeheer via de bestandsnaam
Planning_final.xlsx
Planning_final_ECHT.xlsx
Planning_final_ECHT_gebruiken.xlsx
Planning_v27_def_(dezekanweg).xlsx
Schade: niemand weet welk bestand de beslissing droeg. Vergelijkingen tussen kwartalen zijn archeologie.
Werk voor de data engineer: een tijdslijn bouwen uit datums in eigenschappen, mailthreads en celcommentaar. Daarna pas migratie. De map Archief is zelden een archief. Het is een opgraving.
6. Gekoppelde werkmappen als architectuur
Honderddrieënvijftig sheets. Externe koppelingen naar schijven die hernoemd zijn, naar een collega die weg is, naar \\oud-server\finance\niet-aanraken\. Eén verbroken pad en de hele keten toont #REF! of — erger — stille nullen. Dit was de inkoopdiagnosetool. En de urenregistratie-met-facturen. En de verlofadministratie waarin arbeidsvoorwaarden als codes in formules zaten.
Schade: het “systeem” heeft geen eigenaar, alleen slachtoffers. Performance sterft. Betrouwbaarheid ook.
Werk voor de data engineer: de graaf tekenen. Elke koppeling is een interface die nooit is ontworpen. Ont-excelleren begint met dat plaatje, niet met een nieuw dashboard.
7. Bedrijfsregels opgesloten in cellen
De CAO zit niet in een regelengine. Hij zit in een geneste ALS. Toeslag na 18:00, behalve vrijdag, behalve feestdagen, behalve die ene ploeg in Eindhoven. De maker is vertrokken. De commentaarkolom zegt “klopt volgens overleg 2019”.
Schade: beleid is niet meer te wijzigen zonder het raster te ontcijferen. Juridisch risico. Operationeel giswerk.
Werk voor de data engineer: reverse-engineeren van bedoeling. Dat is het duurste uur van de opdracht: niet het laden van data, maar het interview waarin iemand zegt “volgens mij deed hij het zo”.
8. Rapportage die stiekem de berekening ís
Eerst was het een plaatje voor de directie. Toen moesten de totalen “iets slimmer”. Toen werden bronnen ingelezen in hetzelfde bestand. Nu is het rapport de motor. Het datawarehouse mag blij zijn als het mag toekijken.
Schade: sturen op een afgeleide die zelf is gaan rekenen. Wijzig een filter en de werkelijkheid verschuift.
Werk voor de data engineer: de berekening lostrekken van de presentatie. Semantic layer, metrics store, noem het zoals je wilt: het is de scheiding die Codd in 1970 al eiste en die de spreadsheet systematisch ongedaan maakt.
9. Beveiliging als verborgen tabblad
Wachtwoord op het bestand. Verborgen kolommen met salarissen. Een macro die “alleen voor beheer” is. Delen via WeTransfer omdat de bijlage te groot is. AVG is een poster in de kantine.
Schade: datalekken die er niet uitzien als incidenten, tot het dat wel is. Geen autorisatiemodel, wel persoonsgegevens.
Werk voor de data engineer: scopecrawl. Wat stond erin dat er niet in had gemogen? Welke kopieën circuleren nog? Daarna het saaie, noodzakelijke: rollen, logging, een systeem dat geen Excel-wachtwoord van 2008 meer is.
10. Het migratiegevangenis-bestand
Alles hierboven komt samen op de dag dat er wél een nieuw systeem komt. De historische data moet mee. Niemand weet hoe de 153 sheets zich tot elkaar verhouden. De go-live hangt op een excel bestand dat nooit een interface had.
Schade: projecten die zes maanden extra nodig hebben. Scope die “alleen even de historie” was en een forensisch programma wordt. Kosten die in geen businesscase stonden — behalve in de uren van de data engineer.
Werk voor de data engineer: ont-excelleren. Mapping, uitzonderingen, reconciliatie tot op de cent, en de zin die elke opdracht sluit: “dit had drie jaar eerder gekund, toen het bestand nog twaalf tabbladen had.”
Het idee van de spreadsheet was geweldig. Het democratiseerde rekenen. Het maakte modellering tot iets wat een mens aan een bureau kon doen, zonder ticket naar IT.
Het maakte ook applicatieontwikkeling mogelijk zonder dat iemand het zo noemde. Geen requirements. Geen test. Geen eigenaarschap buiten de maker. Eerst snel. Daarna afhankelijk. Daarna lelijk.
Vijfentwintig jaar geleden leerde ik mijn latere vrouw werken met een database, omdat haar financiële bewerkingen in gekoppelde sheets te groot waren geworden. Ze zegt nog vaak dat die kennis haar hielp in het gesprek met IT — en in het herkennen van de grens van het raster. Die grens ligt eerder dan organisaties denken.
Een deel van mijn werk bestaat sindsdien uit het teruggeven van data aan een model: relaties, betekenis, een taal waarin je kunt zeggen wat je wilt in plaats van te knoeien in cellen. Liever had ik die tijd besteed aan verborgen waarde in bedrijfsverzamelingen. In plaats daarvan ontcijferde ik wat Urenregistratie_verzamelde_totalen_en_facturen.xlsx in godsnaam deed.
Codd scheidde logisch en fysiek. Boyce gaf ons een zin. De spreadsheet gaf ons een rooster en zei: zoek het zelf maar uit.
Waar mensen over data moeten praten, verliezen ze tijd om het over beleid te hebben. Dat is duur voor het bedrijf.
En ja: voor mij blijft het werk.
Dit stuk hoort bij het drieluik over drie uitvindingen uit de jaren zeventig: het relationele model (Codd), de taal SQL (Boyce & Chamberlin) en de spreadsheet (Bricklin & Frankston). Meer patronen: History of Data, via thijscobben.nl.