Welke onderdelen van een bestaande applicatie moet u behouden?

Uw FileMaker ERP draait al twaalf jaar. Het verwerkt orders, voorraden, facturatie en planning — niet perfect, maar wel betrouwbaar. De druk om te moderniseren is reëel, en iemand in de vergadering stelt voor: "Laten we gewoon opnieuw beginnen." Maar voordat die beslissing wordt genomen, is er een belangrijkere vraag te beantwoorden: wat bent u precies van plan weg te gooien, en weet u zeker dat het geen waarde meer heeft?

Dit artikel biedt u een praktisch kader om uw bestaande applicatie laag voor laag te evalueren — zodat u vol vertrouwen kunt moderniseren zonder de institutionele kennis, bewezen logica en schone data weg te gooien die uw bedrijf in meer dan tien jaar heeft opgebouwd.

Waarom "opnieuw beginnen" bijna altijd de verkeerde standaardkeuze is

De neiging om alles opnieuw te bouwen voelt logisch wanneer een systeem er verouderd uitziet. De interface is gedateerd, de code is moeilijk te volgen, en iets nieuws toevoegen kost dubbel zoveel tijd als zou moeten. Maar het zichtbare oppervlak van een applicatie — de UI, de lay-out, de scripts — is niet hetzelfde als de waarde ervan.

De waarde zit eronder: in de bedrijfsregels die zijn vastgelegd in berekeningsvelden, in de werkstroomsequenties die aansluiten op de manier waarop uw team daadwerkelijk werkt, in de relaties tussen tabellen die tien jaar aan echte operationele beslissingen weerspiegelen. Een nieuw systeem dat zonder die kennis is gebouwd, begint niet met een voorsprong — het begint met een achterstand.

De duurste fout die bedrijven maken bij modernisering is het vervangen van het volledige systeem zonder eerst te evalueren welke onderdelen hun werk nog goed doen. Het resultaat: budgetten die worden overschreden doordat logica opnieuw wordt gebouwd die al werkte, maanden van verstoring, en een nieuw systeem dat — op dag één — al functies mist die het oude systeem op dag duizend wel had.

Wat bevat een bestaande applicatie eigenlijk?

Voordat u kunt beslissen wat u behoudt, heeft u een helder mentaal model nodig van waaruit een applicatie is opgebouwd. De meeste zakelijke applicaties — FileMaker-ERP's incluis — bestaan uit vijf afzonderlijke lagen, elk met een eigen moderniseringsprofiel:

1. Datalaag — de feitelijke records, historische transacties, klantgegevens, productconfiguraties
2. Datamodel — de tabelstructuur, relaties, velddefinities en sleutels
3. Bedrijfslogica — berekeningsvelden, validatieregels, prijsformules, workflowtriggers
4. Proceslaag — scripts, automatiseringen en sequenties die data door de bedrijfsvoering sturen
5. Presentatielaag — lay-outs, UI, formulieren, dashboards en de gebruikerservaring

Deze lagen verouderen in zeer verschillende mate. De presentatielaag ziet er vaak al verouderd uit na drie tot vijf jaar. De bedrijfslogica, mits zorgvuldig opgebouwd, kan na vijftien jaar nog steeds accuraat en betrouwbaar zijn. Beide als één geheel behandelen — en alles tegelijk vervangen — is waar projecten misgaan.

Laag 1: Uw data — bijna altijd bewaren

Historische data is onvervangbaar. Een decennium aan orders, facturen, leveranciersgegevens, voorraadmutaties en klantinteracties is niet zomaar opslag — het is het operationele geheugen van uw bedrijf. Prijsontwikkelingen, seizoenspatronen, klantgedrag, betrouwbaarheid van leveranciers: dat alles zit in de data.

De vraag is niet óf u de data behoudt, maar of u deze opschoont en migreert, of live houdt. Bij de meeste moderniseringsprojecten wordt historische data naar het nieuwe of bijgewerkte systeem gemigreerd met een vastgestelde overgangsdatum. Actieve records — openstaande orders, huidige voorraad, lopende projecten — worden volledig overgenomen. Gearchiveerde records worden in een doorzoekbare maar alleen-lezen vorm overgezet.

Let op het volgende:

• Dubbele records die zich door de jaren heen hebben opgestapeld zonder deduplicatie
• Velden die voor meerdere doeleinden worden gebruikt omdat de oorspronkelijke datastructuur niet de juiste opzet had
• Data die inconsistent is ingevoerd (vrije tekstvelden waar een keuzelijst gebruikt had moeten worden)

Dit zijn opschoontaken, geen redenen om de data weg te gooien. Een data-audit vóór de migratie is standaardpraktijk — geen optie.

Laag 2: Uw datamodel — zorgvuldig evalueren, minimaal aanpassen

De tabelstructuur van een volwassen ERP weerspiegelt vaak zorgvuldig doordachte beslissingen. Een "verzending"-tabel die deelleveringen bijhoudt, een prijstabel met klantspecifieke uitzonderingen, een productieplanning die werkorders koppelt aan voorraadreserveringen — deze structuren zijn niet in een vergaderzaal bedacht. Ze zijn ontstaan onder echte operationele druk.

Het datamodel onnodig wijzigen is een van de meest risicovolle stappen in een moderniseringsproject. Elke relatie die u hernoemt of herstructureert, vereist aanpassingen in elk script, elke berekening en elk rapport dat daarmee in aanraking komt.

Behoud het datamodel wanneer:

• De relaties tussen entiteiten correct zijn (orders zijn gekoppeld aan klanten, regelitems aan producten)
• De veldstructuur aansluit op de manier waarop het bedrijf data daadwerkelijk categoriseert en rapporteert
• Migratie naar een nieuwe structuur uitgebreide transformatie zou vereisen zonder dat dit zakelijke meerwaarde oplevert

Herbouw het datamodel wanneer:

• De structuur een tijdelijke oplossing was die nooit de werkelijkheid weerspiegelde (bijv. één "notities"-veld dat vijf verschillende soorten gestructureerde data bevat)
• Het model een kritieke nieuwe mogelijkheid in de weg staat (bijv. ondersteuning voor meerdere valuta's, locaties of entiteiten)
• Prestatieproblemen direct herleid kunnen worden tot structurele inefficiëntie, en niet alleen tot index- of queryproblemen

Laag 3: Bedrijfslogica — de laag die het vaakst per ongeluk wordt weggegooid

Dit is de laag die de meeste bescherming verdient én de meeste aandacht vereist.

Bedrijfslogica is de vastgelegde kennis van hoe uw bedrijf werkt. Een berekeningsveld dat een verkoopsmarge berekent na volumekorting, retourvergoeding en valutacorrectie is niet zomaar een formule — het is een beslissing die uw financiële afdeling door de jaren heen heeft genomen en verfijnd. Een validatieregel die voorkomt dat een order wordt bevestigd zonder gekoppeld afleveradres is niet zomaar een beperking — het is een procesfout die uw team ooit heeft gemaakt en als beveiliging heeft vastgelegd.

Wanneer een bedrijf zijn systeem herbouwt zonder deze laag te auditen, verdwijnt die kennis. Het nieuwe systeem gaat live zonder de afhandeling van randgevallen, de uitzonderingslogica en de beperkingsregels. En dan, drie maanden na de livegang, begint het bedrijf — op pijnlijke wijze — te herontdekken waarom die regels bestonden.

Concreet voorbeeld: Een distributiebedrijf migreert van zijn FileMaker-ERP naar een nieuw platform. In het oude systeem berekende een automatische berekening een vrachtopslag voor orders onder een minimaal gewichtsdrempel, met verschillende drempelwaarden per productcategorie. De logica was in vier jaar verfijnd. In het nieuwe systeem documenteert niemand dit tijdens de migratie. Gedurende zes maanden na de livegang wordt vrachtkosten te laag berekend op een aanzienlijk deel van de orders, voordat de fout aan het licht komt bij een margeanalyse.

Hoe u bedrijfslogica auditt vóór een herbouw:

1. Exporteer een volledige lijst van elk berekeningsveld, elk script en elke validatieregel
2. Schrijf voor elk item een beschrijving in gewone taal van wat het doet en waarom
3. Markeer elke regel die verwijst naar een bedrijfsspecifieke conditie (klanttype, productcategorie, geografische zone, enzovoort)
4. Classificeer elk item als: ongewijzigd bewaren, bewaren en migreren, herschrijven met dezelfde intentie of afschrijven
5. Laat een domeinexpert — niet alleen een ontwikkelaar — de gemarkeerde regels beoordelen

Deze audit kost tijd. Ze brengt ook regelmatig regels aan het licht die niemand in het huidige team kende, geschreven door iemand die het bedrijf jaren geleden al heeft verlaten. Dat is precies de reden waarom ze de moeite waard is.

Laag 4: Procesworkflows — de intentie bewaren, de uitvoering moderniseren

De scripts en automatiseringen in een FileMaker-ERP vertegenwoordigen vaak de operationele volgorde die uw bedrijf daadwerkelijk hanteert — de echte volgorde van stappen, niet de theoretische uit een procesdocument. Een facturatiescript dat een PDF genereert, de voorraad bijwerkt, het magazijn informeert en de order markeert als factureerbaar, doet vijf dingen in een specifieke volgorde — omdat die volgorde ertoe doet.

De juiste aanpak hier is om te scheiden wat het proces doet van hoe het momenteel is geïmplementeerd. Het wat — de volgorde, de afhankelijkheden, de triggers — is de moeite van het bewaren waard. Het hoe — de specifieke scriptmethode, de hardgecodeerde paden, de oplossingen voor platformbeperkingen — vaak niet.

Moderniseringspatroon: Breng elk significant proces in kaart als stroomdiagram vóórdat u de code aanraakt. Documenteer invoer, stappen, beslismomenten en uitvoer. Dit wordt de specificatie voor het herbouwde proces en zorgt ervoor dat de logica wordt overgedragen, ook als de implementatie volledig verandert.

Dit is ook de laag waar API-integraties een rol spelen. Een proces dat momenteel volledig binnen FileMaker verloopt — zoals een inkooporderworkflow waarbij iemand handmatig gegevens opnieuw moet invoeren in een boekhoudpakket — kan vaak worden gemoderniseerd door de FileMaker-workflow intact te laten en een API-connector toe te voegen om data automatisch door te sturen. Het proces blijft behouden; de handmatige stap verdwijnt.

Laag 5: De presentatielaag — de veiligste laag om opnieuw te bouwen

De UI is bijna altijd het juiste antwoord op de vraag "wat moeten we herbouwen?" Lay-outs die logisch waren op een scherm uit 2010 met een workflow uit 2010, voelen vandaag de dag vaak onhandig aan. Navigatie die vijf klikken vereist om een veelgebruikte functie te bereiken, formulieren die 40 velden tonen terwijl de gebruiker er slechts 8 nodig heeft, rapporten die niet geëxporteerd kunnen worden — dit zijn legitieme UX-problemen, en ze zijn de minst risicovolle dingen om te veranderen.

De presentatielaag herbouwen betekent niet de applicatie herbouwen. Een moderne UI bovenop bewaarde bedrijfslogica en een solide datamodel is een volledig valide moderniseringsresultaat — en vaak een veel snellere, goedkopere en minder risicovolle uitkomst dan een volledige herbouw.

Hoe goede UI-modernisering eruitziet:

• Op rol gebaseerde lay-outs die elke gebruiker alleen tonen wat zij nodig hebben
• Mobiel- of browser-toegankelijke interfaces waar medewerkers in het veld die nodig hebben
• Dashboardweergaven die de KPI's tonen waar een manager dagelijks naar kijkt
• Overzichtelijkere invoerformulieren die fouten verminderen en de inwerktijd voor nieuwe medewerkers verkorten

Niets hiervan vereist dat u de onderliggende logica aanraakt. Het vereist inzicht in wat gebruikers daadwerkelijk met het systeem doen — wat betekent: gebruikersinterviews, en niet alleen aannames van ontwikkelaars.

Hoe u de beslissing structureert: een praktisch kader

Wanneer u met uw team gaat zitten om uw bestaande applicatie te evalueren, gebruik dan dit vijfstappenproces:

1. Inventariseer alle vijf lagen — data, datamodel, bedrijfslogica, processen en UI — afzonderlijk. Evalueer de applicatie niet als één geheel.
2. Beoordeel elk onderdeel op twee assen: zakelijke nauwkeurigheid (weerspiegelt het nog steeds hoe de bedrijfsvoering daadwerkelijk werkt?) en technische gezondheid (is het onderhoudbaar, performant en uitbreidbaar?).
3. Breng afhankelijkheden in kaart — identificeer welke onderdelen van welke anderen afhankelijk zijn. Een UI-wijziging waarvoor geen logicawijziging nodig is, heeft een laag risico. Een datamodelwijziging die doorwerkt in 200 scripts, heeft een hoog risico.
4. Prioriteer knelpunten — welke onderdelen veroorzaken vandaag de dag daadwerkelijk problemen? Begin de modernisering daar, niet bij wat er het oudst uitziet.
5. Definieer een moderniseringspad — geen binaire beslissing bewaren/vervangen, maar een gefaseerd plan: wat wordt ongewijzigd bewaard, wat wordt gemigreerd, wat wordt herbouwd met dezelfde intentie, en wat wordt afgeschreven.

Zo werkt het moderniseren van een zakelijke applicatie zonder opnieuw te beginnen in de praktijk — onderdeel voor onderdeel, met een duidelijke onderbouwing voor elke beslissing.

Checklist: wat bewaren en wat herbouwen

Bijna altijd bewaren:

• ✅ Historische transactiedata
• ✅ Kernentiteitsrelaties (klanten, orders, producten, leveranciers)
• ✅ BedrijfslogicaRegels die operationele beslissingen vastleggen
• ✅ Regels voor afhandeling van uitzonderingen en randgevallen
• ✅ Processequenties die echte operationele afhankelijkheden weerspiegelen

Zorgvuldig evalueren:

• 🔍 Datamodelstructuur (bewaren tenzij het een kritieke mogelijkheid blokkeert)
• 🔍 Automatiseringsscripts (intentie bewaren; beoordelen of de implementatie verbeterd kan worden)
• 🔍 Integraties met andere systemen (nagaan of er nu betere API-opties beschikbaar zijn)

Doorgaans veilig om te herbouwen:

• 🔄 UI-lay-outs en navigatie
• 🔄 Rapporten en dashboards
• 🔄 Handmatige gegevensinvoerformulieren
• 🔄 Oplossingen die alleen bestonden vanwege platformbeperkingen

FAQ

Hoe weten we of onze bedrijfslogica nog accuraat is? Laat een domeinexpert — iemand die dagelijks in het proces werkt — elke regel samen met een ontwikkelaar doorlopen. De ontwikkelaar legt uit wat het systeem doet; de expert bevestigt of dat overeenkomt met de huidige operationele werkelijkheid. Afwijkingen betekenen dat de logica bijgewerkt moet worden, niet per se vervangen.

Wat als niemand in het huidige team weet waarom een regel bestaat? Dat komt vaker voor dan u zou verwachten in een systeem van 10 tot 15 jaar oud. De standaardpositie moet zijn: behandel onbekende regels als potentieel belangrijk totdat het tegendeel is bewezen. Test ze met echte scenario's voordat u besluit ze te verwijderen.

Is het ooit juist om volledig opnieuw te beginnen? Zelden, maar soms wel — wanneer het datamodel zo structureel gebrekkig is dat migratie meer zou kosten dan herbouw, of wanneer het bedrijf zo fundamenteel is veranderd dat geen van de bestaande logica nog van toepassing is. Zelfs dan wordt de data bijna altijd gemigreerd.

Hoe lang duurt een gedegen preservatie-audit? Voor een typisch FileMaker-ERP met 20 tot 50 tabellen, meer dan 100 scripts en jaren aan berekeningslogica: reken op twee tot vier weken gestructureerde analyse voordat de ontwikkeling begint. Dit is geen overhead — het is het werk dat ervoor zorgt dat het moderniseringsproject slaagt.

Kunnen we incrementeel moderniseren, of moet het in één keer? Incrementeel is bijna altijd beter. Moderniseer eerst de UI terwijl de logica intact blijft. Voeg API-integraties toe om handmatige stappen te elimineren. Refactor één module tegelijk. Een gefaseerde aanpak vermindert het risico, houdt het bedrijf draaiende en stelt u in staat elke wijziging te valideren voordat de volgende wordt doorgevoerd.

---

Als u precies met dit soort beslissing bezig bent — een volwassen FileMaker-ERP dat zijn werk nog doet maar verder moet kunnen evolueren — werkt Loggix de analyse samen met u door: uw bestaande logica in kaart brengen, bepalen wat de moeite van het bewaren waard is, en een moderniseringspad ontwerpen dat past bij uw bedrijfsvoering en uw budget. Of dat nu betekent uitbreiden wat u heeft, het via API-integraties verbinden met andere systemen, of specifieke modules herbouwen op een schonere basis — het startpunt is altijd een helder beeld van wat u daadwerkelijk in handen heeft.