Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Gegevensconversieprojecten beter besturen

 

Computable Expert

Marco Stuit
Data Integratie Consultant, ITCG (IT Consultancy Group). Expert van Computable voor de topics Datamanagement en Zorg.

Een gegevensconversieproject wordt hoofdzakelijk gezien als een technische aangelegenheid en produceert daarom voornamelijk it-producten. Echter, het betrekken van de business bij (de besturing en besluitvorming van) het project, door hen te voorzien van zakelijke conversieproducten, draagt aanzienlijk bij aan de kans op succes. Een overzicht van zakelijke conversieproducten.

Een gegevensconversieproject heeft in de meeste gevallen een technische focus. Het produceert daarom voornamelijk it-producten. Gangbaar zijn:

  • Export/extract van de brongegevens (de te converteren data).
  • De doelgegevens (de geconverteerde data).
  • Het technisch conversieontwerp (specificatie van de mappingregels van bron naar doel).
  • Conversieprogrammatuur/conversiescripts (om de geconverteerde data in te lezen in het doelsysteem).
  • Conversiecontroleresultaten (overzichten met controletellingen, kwaliteitsmetingen, functionele afwijkingen/vervuiling, uitval- en signaallijsten).

Deze producten vormen de kern van een succesvol gegevensconversieproject. In zowel de vakliteratuur, als in documentatie van adviesbureaus die gespecialiseerd zijn in gegevensconversie, krijgen ze voldoende aandacht.

Zonder draagvlak van de business tijdens het converteren, is er snel sprake van een slechte acceptatie. Succesvol converteren vereist aandacht van de business om ervoor te zorgen dat de stuurman niet spreekwoordelijk aan wal staat. Echter, in de literatuur is weinig aandacht voor zakelijke conversieproducten die in grotere mate geschikt zijn voor het actief betrekken van de business bij (de besturing en besluitvorming van) het project.

Zakelijke conversieproducten

1. Conversiestrategie
Een document dat inzicht geeft in de grote lijnen van de gegevensconversie: wat wordt er geconverteerd en hoe gaat dit in zijn werk. Indien het bron- of doelsysteem uit meerdere applicaties bestaat, kan een separate conversiestrategie per applicatie worden geformuleerd. De ervaringen en inzichten die worden opgedaan met proefconversies kunnen aanleiding zijn om (elementen van de) conversiestrategie bij te stellen.

De conversiestrategie geeft in elk geval inzicht in de volgende aspecten (A t/m D):
A. Globale scope. Geeft aan welke (categorieën en leeftijd van) gegevens wel en niet worden geconverteerd. Een detaillering van de scope per (proef)conversie wordt opgenomen en verantwoord in het functioneel conversieontwerp (zie product 3).
B. Conversieaanpak. Een beschrijving van de fases die doorlopen worden om te komen tot een geconverteerde dataset in de productieomgeving van het doelsysteem (bijv. voorbereiding/contextanalyse, inrichting en proefconversies, definitieve conversie). De fasering en hoeveelheid (proef)conversies sluit aan op de gehanteerde implementatiestrategie in de projectomgeving (bijvoorbeeld big bang of gefaseerd) zodat het resultaat van de conversies kan worden ingelezen in de juiste (productie- of test)omgeving van het doelsysteem. De specifieke conversieactiviteiten binnen elke fase volgen de gehanteerde conversiemethode- en tooling van de datamigratie-specialist en worden gespecificeerd in het conversiedraaiboek (zie product 2). In de conversieaanpak wordt tevens aandacht besteed aan de timing van de (proef)conversies. Hoe wordt ervoor gezorgd dat de bronsystemen tijdens de conversie zo kort mogelijk uit de lucht zijn. Er kan bijvoorbeeld worden gekozen voor een voorconversie waarmee de bulk van de brongegevens wordt geconverteerd voordat het nieuwe systeem live gaat en de bronsystemen worden uitgezet. Via een (delta)conversie na de livegang van het nieuwe systeem worden vervolgens in een korter tijdsbestek de mutaties in de bronsystemen t.o.v. de voorconversie geconverteerd.
C. Laadstrategie. Een uiteenzetting van mogelijke laadstrategieën en de voorkeursstrategie. De laadstrategie is de wijze waarop de geconverteerde gegevens in de doeldatabase worden geladen:
-   ‘Onderlangs’ converteren: de geconverteerde gegevens worden rechtstreeks in de database van het doelsysteem geladen zonder langs de applicatie-logica te gaan. De inhoudelijke controle van de gegevens vindt plaats in de conversieprogrammatuur en niet in het doelsysteem.
-   ‘Bovenlangs’ converteren: de geconverteerde gegevens worden via applicatie-services of operaties aangeboden aan het doelsysteem die deze controleert en verwerkt.
D. Techniek. Een globale beschrijving van de technische middelen die nodig zijn voor verwerking, transport en opslag van gegevens (omgevingen, servers, bandbreedte, et cetera).

2. Conversiedraaiboek
Voor iedere in de fasering genoemde (proef)conversie wordt een draaiboek opgesteld met geplande activiteiten inclusief datums en tijden. Het draaiboek loopt van begin tot eind. Van extractie van de gegevens uit de bronsystemen tot het laden van de gegevens in het doelsysteem. Het draaiboek volgt de standaard conversiemethode van de datamigratie-specialist. De eerste versie van het draaiboek wordt opgesteld voor de eerste proefconversie waarna de bevindingen input zijn voor de volgende versie. Dit leidt tot een getest draaiboek voor de definitieve conversie.

Het draaiboek benoemt afhankelijkheden en sluit daarmee aan op de activiteiten en producten in de projectomgeving (bijv. tijdig ontvangen van de gegevensstructuren van het doelsysteem, tijdig aanleveren van testdata aan het testteam). Het draaiboek is een separaat product of onderdeel van het implementatiedraaiboek in de projectomgeving.

3. Functioneel conversieontwerp
Het functioneel conversieontwerp wordt gemaakt voor elke (proef)conversie en maakt de vertaling/mapping van bron naar doel inzichtelijk en verifieerbaar voor de business. Ervaringen uit voorgaande (proef)conversies zijn verwerkt. Gemaakte ontwerpbesluiten worden expliciet genoemd. Het functioneel conversieontwerp is de basis voor het technisch conversieontwerp.

4. Conversiecontroleplan
Een document dat beschrijft op welke wijze wordt vastgesteld dat de conversie van de gegevens juist, volledig en controleerbaar heeft plaatsgevonden. Het conversiecontroleplan wordt uitgevoerd voor zowel proefconversies als definitieve conversies. Een beschrijving van welke schoningsacties kunnen worden geïnitieerd om uitval en/of foutieve gegevens te herstellen kan tevens onderdeel zijn van het plan. Het plan kan eventueel worden opgesteld in samenwerking met een externe partij (bijvoorbeeld een auditdienst).

5. Conversiedossier
Van iedere (proef)conversie wordt een conversiedossier bijgehouden, het dossier bevat onder meer informatie over de gebruikte (versies van de) gegevensstructuren van het doelsysteem, extractieverslagen van de bronsystemen, resultaten van de uitvoering van het draaiboek inclusief gerealiseerde datums en tijden en resultaten van de uitvoering van het conversiecontroleplan (testrapporten).

6. Beslisnotities
Indien door afwijkingen tussen de oude en nieuwe gegevensstructuren en processen bepaalde gegevens niet kunnen worden geconverteerd dan verdient het aanbeveling om het voorgenomen conversiebesluit voor te leggen aan de business via een beslisnotitie. Dit zal voornamelijk nodig zijn wanneer het besluit leidt tot verlies van gegevens in de bronsystemen, of tot het niet kunnen genereren van bepaalde gegevens in het doelsysteem op basis van de gegevens in het bronsysteem.

7. Presentaties
Presentaties zijn een belangrijk zakelijk conversieproduct. Over het algemeen is een conversie niet ‘sexy’. Echter, door aan te sluiten bij de oplevering van tussenproducten in de projectomgeving kunnen conversieresultaten goed zichtbaar worden gemaakt. In presentaties over nieuwe functionaliteit van het doelsysteem kunnen bijv. geconverteerde gegevens worden getoond.

Meer dan het overzetten van gegevens van A naar B

Binnen veel bedrijven heerst een angst voor gegevensconversietrajecten. Men is bang dat cruciale gegevens en daarmee cruciale bedrijfsfuncties in het nieuwe systeem niet meer beschikbaar zijn. Het is daarom van wezenlijk belang te realiseren dat een gegevensconversieproject meer is dan een technische conversie (het overzetten van gegevens van A naar B). Betrokkenheid en acceptatie door de business is vereist om de angst weg te nemen. Echter, voor het betrekken van de business zijn wel de juiste conversieproducten nodig. Het gebruik van de genoemde zakelijke conversieproducten draagt bij aan de succesfactor van een gegevensconversieproject.

Het strekt tot aanbeveling een producteigenaar/business liaison aan te stellen voor het gegevensconversieproject. Iemand die de business formeel vertegenwoordigt en fungeert als opdrachtgever/klant voor de gegevensconversie. De belangrijkste verantwoordelijkheid van de business liaison is het beoordelen en goedkeuren van de zakelijke conversieproducten.
Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5050199). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Beste Marco,

Dank voor dit artikel.

Ik ben er blij mee dat je aangeeft dat gegevensconversie meer is dan een technische conversie. De business en de functionele waardering van de gegevens krijgt over het algemeen te weinig aandacht tijdens gegevensconversieprojecten.

Het is een goede overpeinzing en uiteenzetting. Zal deze kijk het succes van een conversie programma doen toenemen? Kort en goed, neen. Is het louter een IT technisch feestje? Ja en neen.

Elk IT project dient aan een groot aantal voorwaarden te voldoen om succesvol te zijn. De grootste mijn in het veld is telkens weer de mens die op enig moment een aanslag pleegt op een lopend IT project. Vaak zijn dat mensen die vinden iets in de melk te brokken te hebben maar geen affiniteit hebben met IT of de processen.

Dat zie je dan telkens weer terug in gestrande IT projecten. Begin bij het begin namelijk een gewoon standaard en bestaand template voor IT projecten.

Beste Marco,

Je geeft een aantal essentiele zaken aan in je artikel.
Inderdaad is er per definitie angst bij de organisatie dat er gegevensverlies optreedt.
Een weg terug is er meestal ook niet. Migraties zijn nagenoeg onomkeerbaar.

Een perfect uitgevoerde conversie zorgt voor gegevens in de nieuwe omgeving, die in het verleden in die nieuwe omgeving ingevoerd lijken te zijn.
Als de validatieregels tijdens de migratie voor uitval zorgen, dan is er alleen geen gebruiker die de fouten "even" corrigeert.

In de praktijk loop je tegen problemen aan als:
-eigenaarschap dat niet goed binnen de organisatie belegd is
-meerdere organisatie-onderdelen met ieder eigen belangen, een eigen (verborgen) agenda, prioriteiten en budgetten
-missende gegevens die niet, of slechts met gegevens van mindere kwaliteit aangevuld kunnen worden
-vertaling van functionaliteit, waardoor de historische data niet 1:1 "past" in de nieuwe omgeving
-vertaling van uiteenlopende historische schrijfwijzen naar stamtabellen
-heel uitlopende ideeen binnen de organisatie over de kwaliteit van de historische data, waardoor hier veel verwarring en dus onrust over ontstaat
-verrijkingen die mogelijk niet het gewenste kwaliteitsniveau opleveren
-inconsistenties in de brongegevens, die pas in een laat stadium aan het licht komen of waarvan de impact (te) laat duidelijk wordt
-tot laat in het ontwikkelproject wijzigende requirements en specificaties

Zoals je aangeeft, kunnen een strakke regie en de benoemde controles een gegarandeerde minimum kwaliteit waarborgen.

Ik hoop dat je artikel voor meer acceptatie in "data-migratieland" zal zorgen.
In ieder geval dank voor je poging daartoe.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×