Hoe u bedrijfsregels documenteert

Vraag vijf mensen in je bedrijf "wat gebeurt er als een bestelling boven de €5.000 ligt?" en je krijgt often vijf verschillende antwoorden — één van de salesmanager, één van een script dat een developer zes jaar geleden schreef, één van een Excel macro die finance nog steeds gebruikt, en twee mensen die hun schouders ophalen. Dit is geen trainigsprobleem. Dit is een documentatieprobleem: je bedrijfsregels bestaan, maar ze leven in scripts, in het hoofd van één persoon, en in tribal knowledge dat verdwijnt zodra iemand opstapt of met pensioen gaat.

Dit artikel laat zien hoe je die verborgen regels daadwerkelijk vindt, ze op een manier opschrijft die personelswisselingen en systeemupgrades overleeft, en hoe je voorkomen dat de documentatie staal wordt zodra iemand een script verandert.

Wat telt eigenlijk als een "bedrijfsregel"?

Een bedrijfsregel is elke beslissingslogica die je bedrijf consistent toepast, ongeacht of deze ergens is opgeschreven. Enkele voorbeelden die constant voorkomen in FileMaker en ERP-systemen:

• Bestellingen boven een bepaald bedrag hebben goedkeuring van een manager nodig voordat ze worden gefactureerd.
• Klanten in land X krijgen VAT anders berekend dan klanten in land Y.
• Een product kan niet verzonden worden als de voorraad onder de veiligheidsvoorraad daalt.
• Kortingen stapelen in een bepaalde volgorde — volumekortingeerst, daarna loyaliteitskortingnooit andersom.
• Een supportticket wordt automatisch geëscaleerd als het 48 uur niet is aangeraakt.

Dit zijn geen "functies." Dit zijn beslissingen die je bedrijf ooit heeft genomen, meestal informeel, en die vervolgens zijn ingebakken in een script, een berekeningsveld of een voorwaardelijke opmaakregel — en nooit ergens opgeschreven waar een mens het kan lezen zonder het Developer Tool te openen.

Waarom is dit belangrijker in aangepaste software dan in kant-en-klare software?

In een pakket als SAP of Exact zijn bedrijfsregels op zijn minst gedeeltelijk zichtbaar in configuratieschermen — je kunt naar de VAT-tabel of de goedkeuringsmatrix kijken. In aangepaste FileMaker of ERP-systemen is de regel vaak gewoon... een scriptstap. If [Orders::Total > 5000] Set Field [Orders::Status; "Needs Approval"]. Die regel werkt perfect. Niemand kan hem in zes maanden vinden behalve de persoon die hem schreef, en hij zal nooit verschijnen als je naar "approval process" zoekt in een handleiding, omdat er geen handleiding is.

Dit is het kernrisico dat in ons gerelateerde artikel over hoe je aangepaste business software betrouwbaar en overdraagbaar maakt wordt behandeld: een systeem kan technisch onberispelijk zijn en nog steeds een aansprakelijkheid als de logica erin nergens is gedocumenteerd waar een nieuwe developer, IT-manager of auditor dit kan vinden.

Waar verbergen bedrijfsregels zich eigenlijk? (de gebruikelijke verdachten)

1. Scripts en scripttriggers. De meest voorkomende verstopplek. Een script genaamd "Process Order" zou vijf verschillende bedrijfsbeslissingen kunnen bevatten zonder opmerkingen.
2. Berekeningsvelden. Een veld genaamd cDiscount zou een hele gestaffelde prijsstelling in één geneste Case()-statement kunnen coderen.
3. Voorwaardelijke opmaak op lay-outniveau. Regels zoals "de rij rood maken als deze meer dan 10 dagen verlopen is" zijn echte bedrijfslogica, maar ze leven in een layout inspectorpaneel dat bijna niemand opent.
4. Validatieregels en vereiste veldsinstellingen. "Een inkooporder kan niet worden opgeslagen zonder een kostenplaats" is een beleid, niet alleen een technische beperking.
5. In iemands hoofd. De riskantste. "Oh, we verzenden nooit naar die klant op vrijdagen" — eenmaal per jaar gezegd, nergens opgeschreven.
6. E-mailsjablonen en PDF-lay-outs. Teksten als "betaling verschuldigd binnen 14 dagen, tenzij klant Tier A-voorwaarden heeft" is een bedrijfsregel die verborgen in een sjabloon zit.

Hoe vind en extract je deze regels eigenlijk? Een stap-voor-stap-benadering

Stap 1: Audit scripts en berekeningen systematisch

Ga bestand voor bestand, script voor script. Vraag jezelf voor elk script af: "bevat dit een If, een Case of een drempelwaarde?" Als ja, dat's een kandidaat voor een bedrijfsregel. Probeer dit niet in één zitting voor een groot systeem te doen — begroten het als een echt projecttask, niet als een side task tussen tickets.

Stap 2: Interview de mensen die "het gewoon weten"

Zit met de salesmanager, de magazijnleider, de financiepersoon — en vraag hen hun proces door te lopen alsof ze een nieuwkomer trainen. Neem het op (met toestemming). Je zult dingen horen als "ja, we checken altijd met de klant als het een spoedbeslelling is van meer dan 20 eenheden" — een regel die nergens in het systeem bestaat en momenteel alleen wordt afgedwongen omdat die ene persoon eraan denkt om het handmatig te doen.

Stap 3: Schrijf elke regel in dezelfde eenvoudige indeling

Schrijf geen prosaïsche paragrafen. Gebruik een consistente structuur zodat regels scanbaar en vergelijkbaar zijn:

• Regelnaam: Goedkeuring manager voor grote orders
• Trigger: Bestelwaarde > €5.000
• Actie: Orderstatus ingesteld op "Needs Approval"; e-mail verzonden naar salesmanager
• Waar geïmplementeerd: Orders script "Process Order", stap 12
• Eigenaar: Afdeling sales
• Laatst geverifieerd: datum

Deze indeling is meer waard dan het klinkt — het is wat de documentatie later werkelijk bruikbaar maakt voor iemand die jij niet bent.

Stap 4: Controleer de geschreven regel tegen wat het systeem werkelijk doet

Het is gebruikelijk om te ontdekken dat de gedocumenteerde "officiële" regel en het werkelijke script niet meer overeenkomen, omdat het script twee jaar geleden tijdens een deadline-crisis werd gerepareerd en de beleidsdocumentatie nooit werd bijgewerkt (omdat die niet bestond). Test cases, geen aannames: voer een werkelijke order exact €5.000,01 door het systeem en kijk wat er gebeurt.

Stap 5: Sla de documentatie ergens op waar developers werkelijk zullen kijken

Een bedrijfsregelsdocument dat in een verlaten SharePoint-map leeft, wordt genegeerd. Opties die in de praktijk beter werken:

• Een toegewezen wiki-pagina die rechtstreeks is gekoppeld aan het projectversiebeheer.
• Opmerkingen rechtstreeks in het script zelf ingebed, plus een samenvattingsdoc die naar de scriptnaam linkt.
• Een gestructureerde regelstabel in het systeem zelf (een BusinessRules tabel met velden voor trigger, actie, eigenaar) die zowel technische als niet-technische medewerkers kunnen raadplegen.

Hoe veranderen AI-tools dit? (en waar Klai in past)

Handmatig honderden scripts voor verborgen logica controleren is vervelend, en vervelende taken worden overgeslagen. Dit is waar AI-assistentie in FileMaker — zoals Klai — werkelijk zijn plek verdient, in plaats van een gimmick te zijn. Goed gebruikt kan een AI-laag:

• Een script scannen en een eerste schetsversie in duidelijk Engels produceren van wat het doet, die een mens vervolgens verifieert en corrigeert — veel sneller dan vanuit een leeg vel beginnen.
• Berekeningsvelden met ongebruikelijke complexiteit (diep geneste Case() of If() logica) markeren als kandidaten die het eerst waard zijn om te documenteren.
• Een medewerker's vraag in duidelijk taal beantwoorden ("waarom had deze order goedkeuring nodig?") door naar de gedocumenteerde regel te verwijzen, in plaats van dat die medewerker een developer moet vragen.

De waarschuwing: AI-gegenereerde beschrijvingen van wat een script doet zijn niet hetzelfde als documentatie van wat het bedrijf bedoelt. Laat altijd een menselijke eigenaar bevestigen dat de regel correct is gesteld — AI versnelt het eerste schets, het vervangt niet het gesprek met de salesmanager.

Doet de lay-outlaag ertoe bij het documenteren van bedrijfsregels?

Meer dan de meeste teams aannemen. Wanneer bedrijfsregels alleen worden uitgedrukt als logica die diep in scripts begraven is, heeft de persoon die gegevens invoert geen idee dat een regel bestaat totdat deze vuurt. Een moderne forms/layout-laag als FMBetterforms stelt je in staat de regel op het gegevensinvoerpunt aan het licht te brengen — bijvoorbeeld een zichtbare waarschuwing "Deze order overschrijdt €5.000 en vereist goedkeuring van de manager" recht op het formulier, in plaats van dit als een onzichtbare scriptactie te verbergen. Dit doet dubbel werk: het maakt het systeem gebruiksvriendelijker, en het dwingt de regel expliciet en zichtbaar te zijn, wat het naturel makkelijker maakt om te documenteren omdat het niet langer twee lagen diep in een script verborgen is.

Hoe zorg je dat documentatie van bedrijfsregels niet staal wordt?

Dit is waar de meeste documentatie-inspanningen stil gaan sterven. Enkele praktijken die werkelijk stand houden:

• Bind documentatie-updates aan veranderingsverzoeken. Als een developer de goedkeuringslimiet van €5.000 naar €7.500 verandert, moet hetzelfde ticket het bijwerken van de regelsdoc bevatten — maak het een checklist-item in je veranderingsproces, niet een nagedachte.
• Wijs een bedrijfseigenaar per regel toe, niet alleen een developer. Developers weten hoe de regel is geïmplementeerd; de afdelingseigenaar weet waarom het bestaat en wanneer het zou moeten veranderen. Documentatie zonder bedrijfseigenaar drijft af.
• Bekijk regels jaarlijks, niet "ooit." Zet een herinneringstaak in de agenda voor elke afdeling om hun regels opnieuw te lezen en te bevestigen dat ze nog steeds nauwkeurig zijn.
• Versie de regel, overwrite het niet zomaar. Houd een korte geschiedenis ("veranderd van €5.000 naar €7.500 limiet, maart 2024, goedgekeurd door finance") zodat je kunt uitleggen waarom het systeem anders werkt dan vorig jaar.

Een snelle checklist voordat je zegt dat je documentatie "klaar" is

• Elk script met een If/Case/drempelwaarde is gereviewd op verborgen bedrijfslogica
• Sleutelmedewerkers zijn geïnterviewd over niet-gedocumenteerde "tribal knowledge" regels
• Elke regel is in een consistente, scanbare indeling geschreven (trigger, actie, eigenaar, locatie)
• Regels zijn crosschecked tegen wat het systeem vandaag werkelijk doet, niet wat het deed bij lancering
• Documentatie leeft ergens waar developers en bedrijfsmedewerkers deze werkelijk zullen vinden
• Een bedrijfseigenaar (niet alleen een developer) is aan elke regel toegewezen
• Een proces bestaat om de doc bijwerken telkens wanneer de regel zelf verandert

Veelgestelde vragen

Hoeveel tijd moeten we hieraan besteden? Voor een middelgroot FileMaker-systeem met 5-10 jaar verzamelde scripts, verwacht enkele dagen tot enkele weken voor een eerste volledige audit, afhankelijk van systeemgrootte — het is waard om als eigen kort project te behandelen in plaats van het tussen tickets te persen.

Moet elke kleine regel worden gedocumenteerd? Nee — concentreer je eerst op regels die geld, compliance of klantgericht gedrag beïnvloeden. Een cosmetische lay-outkleur regel is minder belangrijk dan een VAT-berekeningsregel.

Wie zou deze documentatie op lange termijn moeten bezitten? Idealiter een bedrijfszijde eigenaar (afdelingshoofd) gekoppeld aan het technische team, zodat de doc blijft bestaan zelfs als de originele developer vertrekt.

Kan AI bedrijfsregeldocumentatie volledig automatiseren? Nee — AI-tools zoals Klai kunnen het ontwerpen versnellen en complexe logica markeren die waard is om te reviewen, maar een mens moet nog steeds bevestigen dat de regel werkelijk bedrijfsbedoeling weerspiegelt, niet zomaar wat de code toevallig doet.

Niet-gedocumenteerde bedrijfsregels zijn één van de stilste risico's in elk aangepast systeem — onzichtbaar totdat de dag waarop iemand er een moet veranderen en niemand zeker kan zeggen wat het op dit moment doet. Als je naar een FileMaker-systeem (of elk aangepast ERP) stare vol logica die niemand opschreef, kan Loggix je helpen het te controleren, het goed te documenteren, en — waar het voornaam — die regels duidelijker zichtbaar maken via een moderne lay-outlaag, een AI-assistent getraind op je eigen systeem, of een bredere consultatiesessie om in kaart te brengen wat eerst moet worden opgelost.