Dubbele registraties is een bekend probleem. Het vraagt niet alleen extra onderhoudsinspanning, maar geeft ook problemen bij het leveren van managementinformatie en het correct uitvoeren van bedrijfsprocessen. Dit artikel beschrijft hoe DX doublures detecteert en corrigeert.
In dit artikel worden de drie pensioenadministraties onderling vergeleken. Wat zijn de overeenkomsten en verschillen? Er zijn ook verschillen in flexibiliteit. Hoe gemakkelijk kunnen aanpassingen in de datastructuur of in de rekenregels doorgevoerd worden? De drie soorten administraties worden vergeleken op kenmerken als datastructuur, TWK mutaties, reproduceerbaarheid, rekenregels en queries & batches.
In dit artikel wordt beschreven welke gegevens het Stelsel van Basisregistraties bevat, hoe u (c.q. uw organisatie) kan aansluiten en hoe u de gegevens kan toepassen.
Iedereen kan zich voorstellen wat er bedoeld wordt met het begrip datakwaliteit, maar het is lastig om precies aan te geven wanneer die kwaliteit hoog of laag is. Een bruikbare definitie geeft Thomas Redman in zijn boek Data Driven (http://www.dataversity.net/contributors/thomas-redman/): de datakwaliteit is hoog als de betreffende gegevens geschikt zijn voor het beoogde gebruik in bedrijfsactiviteiten, besluitvorming en planning.
Als datamigratie specialist komen we het maar al te vaak tegen: De opdrachtgever start een implementatietraject, waar datamigratie een noodzakelijk onderdeel van is. Zonder naar de daadwerkelijke brondata te kijken wordt aangenomen dat deze data voldoet aan de algemeen geldende business rules. De migratiestrategie en migratiespecificaties worden op basis van deze aanname (en daarmee theoretische situatie) opgesteld. Vervolgens wordt de migratieprogrammatuur gebouwd en worden de eerste test- en proefmigraties gestart. En wat blijkt: ontzettend veel uitval!
Gegevensverwerkende software test je met behulp van data. In de meeste testomgevingen mogen testers niet met productiedata werken, daarom gebruiken ze meestal een dataset die speciaal voor testdoeleinden is gemaakt. Hierbij bestaat een spanningsveld tussen bruikbaarheid en beveiliging: hoe realistischer de testdata, hoe meer de software zich bij het testen zal gedragen als in een productieomgeving, maar ook hoe groter het risico dat de testset gegevens onthult die niet in een testomgeving thuis horen.
100% succes is vereist als je grote hoeveelheden data migreert. Maar, hoe weet je nu zeker dat de datamigratie is geslaagd? Dat in de set van honderdduizenden records die gemigreerd zijn er niet één mist? Dat gegevens niet verwisseld zijn? Ben je als controller of testcoördinator betrokken bij een datamigratieproject? Dan heb je jezelf deze vragen vast ook gesteld. Dit artikel bevat de 7 bewijzen die je kan gebruiken wanneer 100% succes echt belangrijk is!
This case study describes how a complex data migration was 100% tested using a reconciliation solution. 100% testing means 100% coverage: all non-technical data fields of all records of all tables must be compared before and after the data migration. Custom practice with data migration is to test a representative sample survey, covering 5% or less and only the most critical data fields. Sample surveys, counters and hash codes are insufficient to exclude all possible mismatches and (un)intentional exchanges in the data. 100% coverage is necessary for critical business data, e.g. customer and contract data.
