Hoe u een bestaande FileMaker-oplossing inventariseert

U heeft zojuist een FileMaker-systeem geërfd dat niemand meer volledig begrijpt. De originele ontwikkelaar vertrok vijf jaar geleden, het bestand heet "Orders_FINAL_v3.fmp12," er zijn 40 scripts met namen als "Script 2 copy," en elke poging om iets te wijzigen breekt een rapport dat de financiële afdeling nodig heeft. Voordat u het kunt moderniseren, verbinden met een ander systeem, of zelfs veilig een developer om een offerte kunt vragen, moet u weten wat er werkelijk inzit.

Dit artikel helpt u stap voor stap door het proces van het inventariseren van een bestaande FileMaker-oplossing — wat u moet catalogiseren, welke tools u kunt gebruiken, en hoe u wat u vindt omzet in een document waar u echt mee aan de slag kunt gaan.

Waarom hebt u een formele inventaris nodig voordat u iets aanraakt?

De meeste FileMaker-systemen groeien organisch. Een layout wordt toegevoegd vanwege één verzoek van een klant, een script wordt gedupliceerd in plaats van herzien omdat er geen tijd voor was, en een plug-in wordt geïnstalleerd om één specifiek probleem in 2016 op te lossen en wordt nooit verwijderd.

Tien jaar later hebt u een systeem dat het bedrijf draaiende houdt, maar dat geen enkel persoon — inclusief degene die het heeft gebouwd — volledig uit het hoofd kan uitleggen. Dit is geen kritiek op de originele ontwikkelaar; het gebeurt gewoon met elke applicatie die lange tijd in bedrijf is.

Een inventaris is belangrijk omdat:

• U kunt moderniseringswerk dat u niet ziet niet inschatten. Een developer die een migratie of heropbouw offert zonder inventaris gist.
• Verborgen afhankelijkheden veroorzaken de ergste storingen. Een script dat wordt geactiveerd door een serverschema dat niemand zich herinnert is precies het soort ding dat stiekem breekt tijdens een migratie.
• Compliance- en beveiligingsreviews hebben het nodig. Als u klantgegevens verwerkt, moet u exact weten waar deze zich bevinden, wie het kan zien, en hoe het het systeem verlaat.
• Het beschermt u tegen een enkel faalrisico. Als de enige persoon die het systeem begrijpt vertrekt, is een inventaris wat het bedrijf draaiende houdt.

Deze inventarisstap is ook de basis voor het bredere proces beschreven in hoe u een FileMaker-systeem stap voor stap moderniseert — u kunt werkelijk geen veilig moderniseringspad plannen zonder het.

Wat moet u precies inventariseren in een FileMaker-oplossing?

Denk aan de inventaris in vijf lagen. Het overslaan van één ervan is hoe projecten later worden verrast.

1. Bestanden, tabellen en relaties

• Geef alle betrokken .fmp12-bestanden op, inclusief bestanden die slechts zelden worden geopend (jaarrekeningen, een oude HR-module, een apart factureringsbestand).
• Kaart elke tabel en het aantal records erin in — een tabel met 3 records is waarschijnlijk een overgebleven test; een tabel met 2 miljoen records is cruciale bedrijfsgegevens.
• Documenteer het relatiediagram. In oudere oplossingen kan dit een echte spaghetti zijn van self-joins en cross-file-relaties die over een decennium zijn opgebouwd.

2. Layouts en de interfaces die mensen werkelijk gebruiken

• Noteer elke layout, maar markeer degene die werkelijk dagelijks worden gebruikt versus degene die niemand in jaren heeft geopend.
• Identificeer layouts die zijn gebouwd voor specifieke eenmalige verzoeken ("de layout die Sandra nodig heeft voor de Q3-export") — deze dragen vaak bedrijfslogica die nergens anders is gedocumenteerd.

3. Scripts en automatisering

• Geef alle scripts op, wat ze activeert (een knop, een script-trigger, een serverschema, een plug-in-callback), en wat ze werkelijk doen in eenvoudige taal.
• Let vooral op serverschema's en OnTimer/OnIdle-triggers — deze worden uitgevoerd zonder dat een gebruiker aanwezig is en zijn de meest vergeten onderdelen van een inventaris.
• Markeer scripts die externe tools aanroepen: shell-scripts, AppleScript, Insert from URL, of plug-ins.

4. Integraties en gegevensuitwisseling

• Elke API-verbinding, ODBC/JDBC-link, e-mailverzendstap, webhook en geplande export moet worden gedocumenteerd — inclusief waar de gegevens heen gaan en wie er anders van afhankelijk is.
• Een concreet voorbeeld: een nachtelijk script exporteert een CSV naar een gedeelde schijf die een externe accountant handmatig elke maandag ophaalt. Niets in FileMaker zelf zal u dat vertellen — u vindt het door mensen te vragen, niet door alleen scripts te lezen.
• Plug-ins van derden (hier verschijnt typisch iets als FMBetterForms — gebruikt voor rijkere webformulieren of PDF-achtige layouts) moeten controleren op licentiestatus, versie en platformcompatibiliteit. Een plug-in zonder actieve vendorondersteuning is een echt moderniseringsrisico.

5. AI en "slimme" add-ons die al in het systeem zitten

• Sommige FileMaker-oplossingen hebben al AI-functies toegevoegd — variërend van een OpenAI API-aanroep in een script tot een tool als Klai die wordt gebruikt om conversatie- of AI-geassisteerde lagen boven op FileMaker toe te voegen.
• Documenteer exact welke gegevens deze integraties buiten het FileMaker-bestand sturen, want dit wordt vaak over het hoofd gezien in beveiligings- en compliancereviews, maar is enorm belangrijk als u begint te vragen "waar gaan onze klantgegevens werkelijk heen?"

Welke tools helpen u werkelijk bij dit inventariswerk?

U hoeft dit niet helemaal met het blote oog te doen.

• De Database Design Report (DDR): ingebouwd in FileMaker Pro, dit exporteert een volledig XML- (of HTML-)rapport van elke tabel, veld, layout, script en relatie in uw oplossing. Het is het beste startpunt — voer het uit voordat u iets anders doet.
• FileMaker's ingebouwde Script Workspace-zoekopdracht: hiermee kunt u alle scripts doorzoeken op een specifiek veld, tabel of plug-in-functienaam, wat onmisbaar is voor het traceren van afhankelijkheden.
• Logboeken aan serverzijde: controleer FileMaker Server's statistieken en gebeurtenislogboeken op geplande scripts, ODBC-verbindingen en API-aanroepen die niet in het bestand zelf verschijnen.
• Handmatige interviews: geen tool vervangt een 30-minuten gesprek met de persoon die de factureringslayout elke dag gebruikt. Ze zullen u vertellen over de CSV-export naar de accountant die geen scriptopmerking ooit heeft vermeld.

Hoe zet u dit alles om in een bruikbaar document?

Een hoop DDR-output is geen inventaris — het is grondstof. Zet het om in iets dat een besluitvormer of nieuwe developer werkelijk kan gebruiken:

1. Begin met een systeemkaart van één pagina. Vakken voor elk bestand/module, pijlen voor gegevensstroom, en een korte opmerking in eenvoudige bedrijfstaal over wat elk vakje doet.
2. Maak een tabel van scripts met kolommen: scriptnaam, trigger, doel, laatst gewijzigd, risiconiveau (raakt het financiële gegevens aan, roept het een extern systeem aan).
3. Maak een tabel van integraties met kolommen: systeemnaam, richting (in/uit), methode (API, ODBC, CSV, e-mail), frequentie, en eigenaar (wie zou merken als het breekt).
4. Markeer "onbekenden" expliciet. Als u een script of veld vindt dat niemand kan uitleggen, schrijf het op als onbekend in plaats van gissen of het te verwijderen. Onbekenden zijn precies wat een moderniseringsplan eerst moet onderzoeken.
5. Rangschik alles op bedrijfskriticaliteit, niet op technische complexiteit. Een eenvoudig script dat het dagelijks verzendmanifest genereert is belangrijker dan een elegante maar zelden gebruikte rapportagelay-out.

Wat zijn de meest voorkomende fouten bij het inventariseren van een legacy FileMaker-systeem?

• Alleen de code lezen, nooit met de gebruikers spreken. De DDR laat u zien wat bestaat, niet wat werkelijk dagelijks uitmaakt.
• Serverschema's en achtergrondtriggers negeren omdat ze onzichtbaar zijn tenzij u er specifiek naar zoekt.
• Plug-ins als vaste infrastructuur behandelen. Elke plug-in moet controleren op licentieëring, vendorondersteuningsstatus, en 64-bit/Apple Silicon-compatibiliteit — verschillende eens gebruikelijke FileMaker plug-ins zijn in stilte in de loop der jaren niet meer onderhouden.
• De AI-laag overslaan. Als een script stiekem een externe AI API aanroept, is dat een gegevensverwerkings- en kostenpost die iemand moet eigenaar van zijn.
• Het eenmaal doen en archiveren. Een inventaris die niet na elk project wordt bijgewerkt, wordt binnen een jaar in een actief gebruikt systeem verouderd.

Veelgestelde vragen: inventariseren van een FileMaker-oplossing

Hoe lang duurt een volledige inventaris meestal? Voor een kleine oplossing (een handvol tabellen, minder dan 50 scripts) plan 2-3 dagen in. Voor een grote, multi-file-oplossing die over een decennium is gebouwd, kan het realistisch twee tot drie weken duren, meestal omdat van de interviews en dependency-tracing, niet de DDR-export zelf.

Hebt u een FileMaker-developer nodig om dit te doen, of kan een IT-manager het doen? Een IT-manager of technisch ingestelde bedrijfseigenaar kan absoluut de DDR uitvoeren en de systeemkaart bouwen. Het correct interpreteren van complexe scripts, relatiegrafieken en plug-in-afhankelijkheden heeft meestal baat bij iemand met praktijkervaring met FileMaker-ontwikkeling, vooral om risico's op te spotten, niet alleen feiten op te sommen.

Moet ik inventariseren voor of nadat ik besluit te moderniseren? Altijd daarvoor. U kunt niet verantwoord beslissen tussen een gefaseerde modernisering, een volledige heropbouw, of het toevoegen van een integratielaag totdat u exact weet wat het huidige systeem doet en waarvoor het afhankelijk is.

Wat als de inventaris dingen onthult die me afschrikken? Dat is normaal, en dat is de bedoeling. Het vinden van een niet-onderhouden plug-in, een ongedocumenteerde nachtelijke export, of een kritiek script zonder foutafhandeling is precies waarom u inventariseren voordat u iets aanraakt — het zet onzichtbaar risico om in een beheersbare, geprioriteerde lijst.

Checklist: is uw FileMaker-inventaris werkelijk volledig?

• Elk .fmp12-bestand opgesomd, inclusief zelden geopende bestanden
• Volledige DDR geëxporteerd en gearchiveerd met een datum
• Recordaantal en doel van elke tabel gedocumenteerd
• Trigger en doel van elk script gedocumenteerd in eenvoudige taal
• Serverschema's en OnTimer/OnIdle-triggers gecontroleerd
• Elke plug-in opgesomd met licentie- en ondersteuningsstatus
• Elke externe integratie in kaart gebracht (API, ODBC, CSV, e-mail)
• Alle AI/automatiserings-add-ons en welke gegevens ze extern sturen
• Belangrijke gebruikers geïnterviewd, niet alleen de code herzien
• Alles gerangschikt op bedrijfskriticaliteit, niet technische complexiteit

Als uw inventaris meer risico en complexiteit aan het licht brengt dan u verwachtte, is dat een normaal resultaat, geen mislukking — het betekent gewoon dat de volgende stap verdient voorzichtige planning in plaats van gissen. Loggix kan u helpen die inventaris om te zetten in een concrete moderniseringroutekaart, of u nu een aangepaste FileMaker-oplossing bouwt rond wat nog steeds goed werkt, het systeem verbindt met andere bedrijfstools via API-integraties, AI-mogelijkheden toevoegt waar ze werkelijk tijd besparen, of gewoon samengaat om de veiligste volgende stap voor uw specifieke systeem in kaart te brengen.