Maatwerksoftware & portalen

Gegevens importeren in nieuwe software: van exportbestand naar beoordeelde dossiers

Bereid een gegevensimport voor met een afgebakende selectie, veldmapping, vaste referenties, proefimport, aansluiting en inhoudelijke goedkeuring.

Op deze pagina

Een nieuwe applicatie kan pas bruikbaar worden wanneer de benodigde bestaande gegevens begrijpelijk en controleerbaar beschikbaar zijn. Een exportbestand succesvol inlezen is daarvoor niet genoeg. Namen kunnen dubbel voorkomen, statussen kunnen een andere betekenis krijgen en een bijlage kan ontbreken terwijl het aantal hoofdrecords wel klopt. Een gegevensimport vraagt daarom zowel technische controles als inhoudelijke beoordeling door iemand die het werk kent.

Deze gids gaat over het voorbereiden en beoordelen van een gegevensset voor een nieuwe applicatie of klantportaal. Zij behandelt niet de volledige overgang tussen twee live systemen of hun gezamenlijke schrijfverantwoordelijkheid. Het fictieve voorbeeld betreft een adviesbureau dat klanten, lopende aanvragen en bijlagen wil overnemen. De getallen en proefgevallen zijn illustratief; het zijn geen gemeten klantresultaten of beloften over een concrete migratie.

Bepaal welke gegevens werkelijk nodig zijn

Begin met de taak die de eerste softwareversie gaat ondersteunen. Het adviesbureau heeft misschien alleen actieve klanten met openstaande aanvragen nodig. Oude concepten, ongebruikte velden en afgesloten dossiers kunnen een andere behandeling vragen. Beschrijf de selectie met een datum, toestand en verantwoordelijke, zodat twee mensen onafhankelijk dezelfde export kunnen herkennen en verklaren.

Noteer ook wat bewust buiten de eerste import blijft en hoe medewerkers die informatie zo nodig terugvinden. Een beperkte selectie is geen kwaliteitsverbetering wanneer belangrijk werk daardoor ongemerkt uit beeld verdwijnt. Vraag de gegevenseigenaar daarom of de eerste dataset voldoende is om de gekozen taak uit te voeren en welke historische context daarbij onmisbaar blijft voor een inhoudelijke beoordeling.

Maak van veldnamen een betekenisvolle mapping

Een mapping legt per bronveld vast waar het terechtkomt en welke omzetting nodig is. Beschrijf ook de betekenis. Een datum kan een ontvangstdatum, afspraakdatum of laatste wijziging aanduiden. Een status “gereed” kan betekenen dat een medewerker klaar is, terwijl het nieuwe portaal die term gebruikt voor een afgeronde klantbevestiging. Alleen kolomnamen vergelijken laat dat verschil onzichtbaar.

Bij verschillen tussen systeembegrippen kan een expliciete vertaallaag helpen. Microsoft beschrijft die begrenzing in het Anti-Corruption Layer-patroon. Voor deze import kan een eenvoudige vastgelegde omzetting voldoende zijn; een extra platform is geen verplichting. Bewaar vooral de gekozen betekenis en de verantwoordelijke die haar heeft bevestigd, zodat later duidelijk blijft waarom een bepaalde bronwaarde naar een bepaald doelgegeven is vertaald.

Microsoft Azure Architecture: Anti-Corruption Layer pattern ↗

Bewaar identiteit en relaties

Kies een herkenbare bronreferentie voor ieder overgenomen object. Een naam of e-mailadres is niet vanzelf een geschikte vaste sleutel. Twee contactpersonen kunnen een adres delen en een bedrijfsnaam kan veranderen. Leg daarom vast welke referentie een klant, aanvraag of document identificeert en hoe de relatie met het nieuwe record wordt bewaard of teruggevonden tijdens controle.

Test de samenhang met een klant die meerdere aanvragen heeft en met een aanvraag die meerdere bijlagen bevat. Onderzoek ook een document zonder duidelijke klantrelatie. Het doel is niet elk twijfelgeval automatisch op te lossen. Maak een beoordelingslijst waarop iemand kan beslissen wat hoort te worden gekoppeld, apart gezet of uitgesloten. Een onzekere relatie mag niet ongemerkt een definitieve samenvoeging worden.

Bij een draaiend oud systeem vraagt migratie ook een overgangsperiode en een herstelbesluit: Een draaiend legacysysteem migreren: eigenaarschap, omschakelen en terugvallen.

Spreek formaat en lege waarden af

Beschrijf de technische bestandsafspraken: tekencodering, kolomvolgorde, scheidingstekens, datumweergave en de manier waarop lege waarden worden aangegeven. Een lege cel kan ontbreken, bewust leeg of niet van toepassing betekenen. Geef voor die gevallen expliciete doelwaarden of een beoordelingsroute. Het importproces moet de betekenis volgen die is afgesproken, niet de toevallige standaardinstelling van één programma.

Een databasehulpmiddel zoals PostgreSQL COPY kan bestanden in tabellen laden, maar dat commando beslist niet of de geïmporteerde dossiers zakelijk bruikbaar zijn. Kies het hulpmiddel passend bij de omgeving en controleer hoe het omgaat met foutieve invoer. Bewaar een kleine veilige proefset met de belangrijke formaatverschillen. Daardoor kan een latere aanpassing aan export of parser op dezelfde gevallen worden beoordeeld.

PostgreSQL: COPY ↗

Voer eerst een kleine representatieve proef uit

Gebruik een afgeschermde proefomgeving en een gegevensset die de verschillende relevante situaties bevat. Neem gewone records op, maar ook een ontbrekende referentie, dubbele naam, aangepaste status en bijlage met een afwijkend type. Werk met geschikte fictieve of zorgvuldig voorbereide testgegevens. Het gaat om bewijs over het ontwerp; een willekeurige verzameling echte dossiers is niet automatisch een verantwoorde proefset.

Laat na het inlezen de werkelijke schermen en relaties bekijken. Een technisch log met “geslaagd” vertelt niet of een klantcontactpersoon de juiste aanvraag terugvindt. Vraag een medewerker de gekozen taak met de geïmporteerde voorbeelden uit te voeren. Noteer inhoudelijke fouten apart van formaatfouten. Zo wordt zichtbaar of de mapping moet veranderen of dat het oorspronkelijke bestand eerst door de gegevenseigenaar moet worden verduidelijkt.

Sluit aantallen aan zonder ze te overschatten

Maak een overzicht van geselecteerde bronrecords, geaccepteerde doelrecords, afgewezen invoer en bewust uitgesloten gevallen. Leg een reden vast voor verschillen. Tel relaties en bijlagen waar dat voor het werk belangrijk is. Hetzelfde aantal klanten aan beide kanten kan nog steeds samengaan met verkeerde adressen, ontbrekende aanvragen of een status die voor iedere klant verkeerd is omgezet.

Gebruik daarnaast inhoudelijke steekproeven op vooraf benoemde eigenschappen. Kies bijvoorbeeld klanten met meerdere aanvragen en controleer enkele bronreferenties volledig. De omvang en selectie van die beoordeling hangen af van de gegevens en gevolgen van fouten. Een eenvoudige telling en een gerichte inhoudelijke proef vullen elkaar aan. Geen van beide mag worden gepresenteerd als bewijs dat iedere denkbare fout onmogelijk is geworden.

Maak opnieuw uitvoeren voorspelbaar

Een proefimport moet vaak worden herhaald nadat een mapping of bestand is verbeterd. Spreek daarom af hoe een volgende uitvoering dezelfde bronrecords herkent. Worden proefgegevens gecontroleerd vervangen, bestaande doelrecords bijgewerkt of nieuwe records toegevoegd? De gekozen route moet zichtbaar zijn voordat opnieuw wordt gestart, zodat een reparatie van de proef geen nieuwe onverklaarde duplicaten veroorzaakt.

Bewaar per uitvoering welke invoerversie, mapping en selectie zijn gebruikt. Houd een foutlijst met bronreferenties en uitkomsten bij. Daarmee kan het team verschillen tussen twee proeven onderzoeken zonder te raden welk bestand destijds is ingelezen. Dit artikel beperkt zich tot de importset; voortdurende wijzigingen in twee live systemen vragen daarnaast een eigen overgangsontwerp en afspraken over waar gedurende die periode wordt geschreven.

Laat de gegevenseigenaar een inhoudelijk besluit nemen

Benoem wie voldoende kennis en verantwoordelijkheid heeft om de proefimport te beoordelen. Dat kan per gegevenssoort een andere persoon zijn. De klantadministratie beoordeelt bijvoorbeeld identiteit en contactgegevens, terwijl een behandelaar de betekenis van lopende aanvragen controleert. Vraag geen algemene handtekening op een bestand dat niemand volledig heeft kunnen begrijpen; verbind goedkeuring aan concrete bevindingen en bekende beperkingen.

Het besluit beschrijft wat is geaccepteerd, welke correcties nodig zijn en welke open punten een volgende stap blokkeren. Bewaar voorbeelden waarop het besluit rust. Zo kan een ontwikkelaar aantonen welke technische invoer heeft plaatsgevonden en kan de organisatie uitleggen waarom die gegevens bruikbaar zijn voor de eerste taak. Deze verantwoordelijkheden vullen elkaar aan; technische toegang tot de database maakt iemand niet automatisch de inhoudelijke eigenaar.

Lever de importkennis mee op

Bewaar de veldmapping, bronselectie, uitvoeringsreferenties, controles en bekende uitzonderingen bij de nieuwe applicatie. Geef aan hoe medewerkers een mogelijk verkeerd geïmporteerd record melden en hoe de herkomst wordt teruggevonden. Een beheerder moet niet afhankelijk zijn van de herinnering van degene die het eerste bestand heeft voorbereid om een klacht over een dossier te kunnen onderzoeken.

Beoordeel na invoering welke fouten werkelijk optreden en onderscheid importproblemen van nieuwe gebruikershandelingen. Verander niet stilzwijgend oude brongegevens om een afwijking te verbergen. Leg de correctie en haar reden vast volgens de gekozen werkwijze. De import wordt zo een verklaarbare stap in het project, met een beperkte dataset, een herhaalbare aanpak en een inhoudelijke beslissing over de bruikbaarheid van de uitkomst.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

Open de voorbereidingstool ↗

Vragen over dit onderwerp

Is een gelijke recordtelling voldoende voor acceptatie?

Nee. Zij helpt ontbrekende of extra records ontdekken, maar zegt weinig over veldbetekenis en relaties. Combineer tellingen met controle van klant-aanvraagrelaties, bijlagen en gerichte inhoudelijke voorbeelden. Benoem welke eigenschappen in de eerste import belangrijk zijn en wie ze beoordeelt.

Moeten alle historische gegevens mee?

Niet automatisch. Bepaal wat nodig is voor de eerste taak en hoe overige informatie beschikbaar blijft wanneer zij nodig is. Een kleinere dataset kan eenvoudiger te beoordelen zijn, maar de selectie moet inhoudelijk worden verantwoord. Gegevens weglaten zonder werkbare vervolgroute kan problemen verplaatsen.

Wie moet de import goedkeuren?

Wijs een inhoudelijke gegevenseigenaar aan en geef die persoon een begrijpelijk controleoverzicht. De ontwikkelaar levert technisch bewijs en openstaande fouten. Goedkeuring moet aangeven welke dataset en beperkingen zijn beoordeeld, zodat zij niet wordt verward met een garantie over alle toekomstige gegevens.

Verder met een aansluitende vraag

Bronnen en technische achtergrond

Bespreek je project met Ricardo ↗