De taal van logbestanden en best practices voor migratie

Deel 5 van de 6-delige serie "Het Migratiehandboek"

In deel 4 hebben we het overgangsmigratieplan, ons gedetailleerde draaiboek voor de livegang. Een draaiboek is echter pas effectief als de acteurs hun tekst grondig hebben geoefend.

Als je in de laatste week je eerste volledige lading probeert te verwerken, is de kans op mislukking extreem hoog. Er zullen te veel fouten gemaakt worden, de stress te hoog en de tijd te kort om ze te herstellen.

In dit artikel nemen we afstand van de lancering zelf en focussen we op de maandenlange voorbereiding die eraan voorafgaat. We verkennen de iteratieve cyclus van testruns, de kunst van het 'humaniseren' van logboekenen de strikte naamgevingsconventies die voorkomen dat je project in chaos vervalt.

De iteratieve lus: de weg naar perfectie

Datamigratie verloopt als een cyclische cyclus van fouten en verbeteringen, in plaats van een eenvoudig lineair proces (Extraheren -> Transformeren -> Laden -> Klaar).

We voeren deze cycli uit in een speciale simulatieomgeving (TRN), die een exacte kopie van de productieomgeving moet zijn.

Loops uitvoeren:

1. Run 1: we laden de ruwe data en verwachten een hoog foutpercentage. Dat is normaal. Het systeem wijst alles af wat niet voldoet aan de strikte validatieregels van het ERP-systeem.
2. Analyse en correctie: we pakken de hoofdoorzaak in de bronbestanden (of de transformatielogica) zoveel mogelijk, in plaats van handmatige correcties rechtstreeks in Infor LN toe te passen.
3. Run 2: we herladen. Nu daalt het foutpercentage aanzienlijk. Dit zijn de subtiele logische fouten (bijvoorbeeld: Artikel A hoort bij een verkoopgroep die niet bestaat).
4. Run 3: we bereiken bijna perfectie . Nu logt de hoofdgebruiker in. Naast het tellen van rijen probeert hij/zij het artikel te verzenden en de klant te factureren
5. Run N: we herhalen dit totdat het proces saai wordt. Een saaie migratie is een succesvolle migratie.

Strategische waarde: ten eerste worden veelvoorkomende fouttypen nauwkeurig bijgehouden, waardoor een schema van verwachte fouten wordt opgebouwd en we niet voor verrassingen komen te staan. Ten tweede, en misschien nog belangrijker,bieden deze tests de beste gelegenheid om vertrouwen op te bouwen; niet alleen in de data, maar ook tussen teams. Datamigratie is een technische handeling, maar het berust op een fundament van mensen die elkaar moeten corrigeren, verifiëren en vertrouwen.

Zonder dit wederzijds vertrouwen kan geen enkel migratiescript je redden. Wanneer Key Users zien dat hun feedback wordt toegepast en fouten worden opgelost in volgende runs, verdwijnt de "wij versus zij"-barrière en ontstaat er een verenigd team dat klaar is voor de Go-Live.

De taal van logbestanden: fouten menselijker maken

Wanneer Infor LN een record afwijst, gebruikt het technische referenties.

• Voorbeeld: Referentie bestaat niet: tibom3109001.cmbb->tibom3009001.cmba ['WS0001' ' 9861532' '012' '000002']

Het is niet effectief om dit onbewerkte logbestand naar een productiemanager te sturen. Die heeft geen idee wat tibom310 of cmba betekent. Als consultant is het jouw taak om als vertaler.

De vertaalmatrix

Je moet cryptische databasefouten omzetten in concrete bedrijfstaken en daarbij de meest waarschijnlijke oorzaken achterhalen.

• Ruwe log: Referentie bestaat niet: tibom3109001.cmbb->tibom3009001.cmba ['WS0001' ' 9861532' '012' '000002']
• Analyse van de consultant: dit logboek geeft aan dat het hoofditem (ouder) van de stuklijst die u probeert te importeren ongeldig is. Hiervoor kunnen twee belangrijke redenen zijn: Het item bestaat letterlijk niet in de itemstamgegevens. Het item bestaat wel, maar mist de specifieke subentiteitsinstellingen die nodig zijn om als productie- item te worden beschouwd.
• Vertaalde actie: Artikel 9861532 kan niet als bovenliggend artikel in de stuklijst worden gebruikt. Controleer of de artikelcode correct is in het bronbestand en zorg ervoor dat de juiste subentiteiten zijn ingesteld voor productie.

Beste werkwijze: Verwerk het onbewerkte tekstbestand voordat u het naar de klant stuurt. Importeer het in Excel, filter de technische ruis eruit (de "valse positieven" die we in deel 3 hebben besproken ), voeg een kolom toe met duidelijke instructies in natuurlijke taal en stuur het vervolgens naar de eigenaar van de gegevens

Naamgevingsconventies: orde scheppen in de chaos

Tegen de derde maand van het project heb je honderden bestanden. Het lukraak benoemen van bestanden (bijvoorbeeld Items_Final.csv, Items_Final_v2.csv) leidt tot fouten en verwarring. Bij de Go-Live Run is precisie essentieel.

Je hebt een strikte naamgevingsconventie.

Elk bestand moet een strikte syntaxis volgen: [Object]_[Omgeving]_[BatchID]_[Datum]_[Status]

• Object: Wat zit erin? (bijv. ItemMaster, SalesOrder).
• Milieu: Waar gaat het naartoe? (TRN, PRD).
• Batch-ID: Komt overeen met de taak-ID in uw overgangsplan (bijv. 10A).
• Datum: ISO-formaat (JJJJMMDD).
• Status: Origineel (Onbewerkte bron), Invoer (Getransformeerd voor upload), Logboek (Resultaat/Fouten).

Voorbeeld:

• Origineel bestand: ItemMaster_PRD_10A_20251101_Original (het onbewerkte bestand dat van de klant is ontvangen, vóór enige bewerking).
• Invoerbestand: ItemMaster_PRD_10A_20251101_Input (het bestand dat daadwerkelijk is verwerkt).
• Logbestand: ItemMaster_PRD_10A_20251101_Log (de uitvoer bevat fouten en verwerkingsdetails).

Mappenhiërarchie

Gebruik een gedeelde opslagplaats met een vergrendelde mapstructuur om de orde te bewaren:

1. 01_Source_Received (Onveranderlijke originelen van de client).
2. 02_Klaar_voor_upload (Bestanden gevalideerd, wachtend op groen licht).
3. 03_Archief_Verwerkt (Bestanden succesvol geladen).
4. 99_Errors_Logs (Waar het slechte nieuws te vinden is).

De proefdraai is goedgekeurd

Voordat we het overgangsplan in productie uitvoeren, doen we een volledige proefdraai in de testomgeving. Dit is een generale repetitie. We meten de tijd van elke stap.

• De strategische buffer: als het laden van verkooporders tijdens de testrun precies 4 uur duurde, reserveren we nooit precies 4 uur in het implementatieplan. We voegen systematisch een tijdbuffer in om onvoorziene problemen op te vangen (netwerkvertraging, een vergrendelde databasetabel of een lastminuteaanpassing van gegevens), zodat een enkele hapering de gehele implementatie niet in de war stuurt.
• Als er iets vastloopt: we analyseren en verhelpen de storing onmiddellijk.

De testfase eindigt met een formele goedkeuring. De belangrijkste gebruikers moeten bevestigen: "We hebben de gemigreerde gegevens in TRN getest en we geven toestemming voor de verplaatsing naar PRD." Deze handtekening beperkt het risico en zorgt ervoor dat de livegang een weloverwogen implementatie is.

Waarom dit verplicht is

Deze eis sluit direct aan op wereldwijde normen voor compliance en risicomanagement.

• Auditcompliance (SOX/ITGC): Voor elk bedrijf dat onderworpen is aan audits (Sarbanes-Oxley of vergelijkbare wetgeving), is datamigratie een cruciaal controlepunt. Externe auditors (zoals de Big 4) vereisen bewijs van door de gebruiker (User Acceptance Testing, UAT) voordat financiële gegevens in het grootboek worden verwerkt. Zonder deze goedkeuring slaagt u niet voor de IT General Controls (ITGC) -audit. Referentie: ISACA – IS Audit Basics: Audit Programs
• Projectmanagementstandaard (PMBOK): Volgens het Project Management Institute (PMI) is "Scope valideren" een formeel proces dat schriftelijke acceptatie van de deliverables (de data) door de stakeholders vereist om de projectfase af te sluiten. Referentie: PMI Community – Validate Scope Process
• Methodologie van de leverancier: De officiële Infor-implementatiemethode vereist expliciet een "Go/No-Go"-beslissingsfase die gebaseerd is op succesvolle tests in een simulatieomgeving.

Nu hebben we het proces zo grondig getest dat het saai is geworden. We hebben onze bestanden zo goed georganiseerd dat zelfs een vreemde de migratie zou kunnen uitvoeren. We hebben de fouten van de machine vertaald naar menselijke handelingen.

We zijn er klaar voor. Het systeem is live. De gebruikers loggen in. Maar het project is nog niet voorbij. Sterker nog, de zwaarste 72 uur beginnen nu pas. In het laatste deel van deze serie bespreken we Validatie & Hypercare. We gaan het hebben over het aantonen van de waarde aan de CFO en het omgaan met de onvermijdelijke crisissituaties .

Geschreven door Andrea Guaccio 

9 april 2026