BREED - over de grenzen van informatie

NETWERK VOOR DE INNOVATIEVE INFORMATIEWERKER

Datamigratie

Goedemiddag,

De gemeente waar ik werk start op niet al te lange termijn met de aanbestedingsprocedure voor een financieel systeem. Hierbij is er ook sprake van datamigratie.

Het GIBIT (gemeentelijke inkoopvoorwaarden bij IT) is onlangs gepubliceerd (www.gibit.nl). Het college besluit op korte termijn om het GIBIT te hanteren als inkoopvoorwaarden.

Dit document geeft in algemene zin kwaliteitseisen waaraan een migratie/conversie moet voldoen (artikel 1.5).

1.5 Conversie: Het converteren en migreren van gegevensbestanden van Opdrachtgever van het oude systeem naar de nieuwe ICT Prestatie, zonder daarbij de volledigheid, de integriteit en de metadata van de gegevens aan te tasten.

In de onderliggende ICT kwaliteitsnormen wordt in hoofdstuk 5 Dataportabiliteit hierop nader ingegaan.

De kwaliteitseisen worden natuurlijk door de gemeente bepaald.

Maar hoe meet je de kwaliteit en hoe bepaal je het betrouwbaarheidsniveau van de resultaten van de steekproef?

Voor mijn gevoel kan de AQL methodiek ook gebruikt worden voor de kwaliteit van de uitgevoerde migratie.

Maar het belangrijkste kan ik niet uit het AQL halen. Welke kwaliteit is nu daadwerkelijk behaald als het aantal fouten uit de steekproef wordt vertaald naar een foutmarge over het gehele bestand.

In dit document http://www.sempermed.com/fileadmin/img/sempermed/content/medical/pd... wordt in een tabel op pagina 3 (op basis van een binomiaalverdeling) hierover meer inzicht gegeven.

Wie kan mij meer informatie verschaffen hoe het aspect kwaliteit bij migratie in het aanbestedingsdocument is opgenomen, hoe de kwaliteit is gemeten en hoe het betrouwbaarheidsniveau is bepaald.

Voorbeelden uit de praktijk zijn zeer welkom.

Alvast bedankt voor de input.

Vind ik leuk

2 leden vinden dit leuk

▶ Hierop reageren

Berichten in deze discussie

Permalink Antwoord van Rens op 13 April 2017 op 9.09

De kwaliteit is mede afhankelijk van hoe het datamodel in de oude applicatie is ingericht. Soms is die dusdanig complex, dat van de opvolgende leverancier redelijkerwijs niet kan worden verwacht dat alle data op een goede, interpreteerbare manier kan worden ingelezen. En daarbij geldt het aloude adagium "garbage in/garbage out".

Bij het opstellen van een PvE voor een nieuwe applicatie, is het verstandig om er rekening mee te houden dat ook die applicatie ooit weer wordt uitgefaseerd. Dus stel bijvoorbeeld als functionele eis dat de data in een bepaalde vorm geëxporteerd kunnen worden ten behoeve van toekomstige migratie en denk na over hoe het datamodel opgebouwd moet worden.

Als blijkt dat migratie met de gewenste kwaliteit een probleem is of tot hoge kosten leidt, denk dan ook na over alternatieven. In mijn organisatie hebben we er bijvoorbeeld voor gekozen om een aantal oude financiële pakketten te laten pruttelen totdat de wettelijke bewaartermijn van de gegevens is verlopen, met een beperkt aantal licenties. Van een aantal andere pakketten hebben we alleen de database bewaard en die kunnen we via een rapportagetool raadplegen. De informatie is dan niet optimaal toegankelijk, maar omdat de raadpleegfrequentie in de praktijk laag is, is dat voor onze business acceptabel. In geval van nood kost het wat moeite en misschien wat geld, maar we kunnen er wel bij.

Je kunt ook kiezen voor een dergelijke oplossing in combinatie met een migratie. Als dan achteraf blijkt dat de gegevens niet goed zijn meegekomen, kun je altijd nog de oorspronkelijke database raadplegen.

Voor het meten van de kwaliteit van een migratie is het in mijn ogen toch vooral een kwestie van testen, herstellen en hertesten. Het opstellen van een goed testplan met goede testscripts is misschien wel belangrijker dan de formulering van je kwaliteitseisen in een PvE. En verwacht vooral niet dat het in één keer goed gaat.