Home

PeopleSoft conversie bij top-3 bank.

Begin november 2003 is -samen met 2 medewerkers van een collega-bedrijf, onder de naam van dat bedrijf- een start gemaakt met de uitwerking van de conversie van een personeelssysteem naar PeopleSoft volgens de methodiek van Koorneef DMS, gebruik makend van de daarbij behorende ondersteunende tooling. De afronding van het traject heeft in augustus 2004 plaatsgevonden.

Binnen het project was al een start gemaakt met het opstellen van de conversieregels. Dit traject (de feitelijke functionele specificatie van de conversie) werd uitgevoerd door 3-4 functioneel ontwerpers. Voor de realisatie voerden wij de volgende stappen uit:

  • intake functionele beschrijvingen;

  • omwerken beschrijvingen naar parameters en teksten voor de workbench;

  • genereren en verder uitwerken van de programmatuur;

  • testen van de programmatuur.

Na oplevering van (delen van) de conversie werden de resultaten door 3 testers tegen het licht gehouden.

Het gemaakte conversiesysteem bestond uit de standaard onderdelen kwaliteitscontrole en conversie.

Het bronsysteem registreerde een groot aantal 'medewerkers' waarvan een deel feitelijk nooit een dienstverband had; ze waren  in het systeem opgenomen om uitbetaling van reiskosten mogelijk te maken. Na uitfiltering van dit soort gevallen en al te ver in het verleden liggende historie restte voor conversie nog iets minder dan de helft van de 'medewerkers'.

Binnen het bronsysteem (een 50-tal te converteren bestanden groot) waren meerdere administraties opgenomen. In de loop van de loopbaan van de medewerker was het mogelijk, dat de medewerker wisselde van administratie. Met die wisseling werd dan een deel van de gegevens overgenomen naar de andere administratie om daar verder onderhouden te worden. Meermalen wisselen was geen uitzondering. Een en ander leidde ertoe, dat het construeren van een eenduidig beeld van de medewerker niet altijd eenvoudig was. Door het toepassen van relatief eenvoudige, geparameteriseerde aanpassingsmechanismen bleek het mogelijk een en ander op verfijnde manier bij te stellen.

Voor het PeopleSoft systeem moesten een 40-tal templates worden aangeleverd. Met de beheerders van het nieuwe systeem was overeengekomen, dat in principe alle conversieactiviteiten zouden worden uitgevoerd door de door ons op te leveren conversieprogrammatuur, waarmee een eenduidig aangrijpingspunt voor wijzigingen is gecreŽerd.

Vanuit gegevensconversie gezien kenmerken (vooral pakket) implementaties zich door soms sterk wisselende inzichten. Zo ook binnen dit traject. Bij opstarten van het conversietraject waren dan ook in dit geval al een fors aantal beslissingen voor de inrichting genomen. Deze beslissingen dienden als basis voor het opstellen van de conversieregels.

Als gevolg van voortschrijdend inzicht bij het team dat verantwoordelijk was voor de inrichting van het pakket, is in de loop van het traject dan ook nog een groot deel van de conversieregels herzien:

Op bestandsniveau (relatie tussen bestanden, waar de meeste complexe regels worden beschreven) zag het er als volgt uit:

Dit houdt in, dat ondanks uitgebreid overleg reviews en communicatie het toch noodzakelijk bleek om in meer dan de helft van de gevallen (bij ca 135 regels) de conversieregels 1 of meer keer te wijzigen.

Op het niveau van veld op veld vertaling zag het beeld er iets gunstiger uit:

Maar ook in dit geval werd toch nog rond 40% van de ca. 870 regels 1 of meer keer herzien.

Bij deze aantallen wijzigingen heeft de workbench zijn waarde meer dan eens bewezen. Vanwege de sterke koppeling die het ontwikkelproces van de conversieprogrammatuur met de in de workbench vastgelegde gegevens heeft was het bij wijze van spreken van minuut tot minuut mogelijk, om de status van de ontwikkeling op het dashboard af te lezen. Daarmee bleef het traject gedurende de doorlooptijd van het project stuurbaar.

Bij het testen van de conversie is uitgebreid gebruik gemaakt van het selectiemechanisme voor cases. Op basis van selectiecriteria enerzijds ("ik wil een geval waarbij die en die verschijnselen voorkomen") en op basis van tijdens testen, bekijken van gesignaleerde problemen in de invoer en bekende moeilijke gevallen anderzijds werd een testset van tussen de 500 en 1000 "heel gemene" gevallen samengesteld, waarmee een goed dekkende testset werd geselecteerd. Als er een nieuwe download beschikbaar kwam werd ook de testset opnieuw geselecteerd (voor zover dit wenselijk was). De geselecteerde gevallen werden voor inspectie in een MsAccess database geladen waar het mogelijk was om bronrecords samen met de daaruit afgeleide doelrecords naast elkaar te bekijken.

Na uitvoering van een conversie(test)run werd de kwaliteit van de opgeleverde bestanden gemeten door vergelijking ervan met de binnen de workbench daarvan opgenomen beschrijving. (basis kwaliteitsmeting)

Bij herhaalde testen werd gebruik gemaakt van het vergelijkingstool, dat aangeeft

  • welke records zijn er nu wel en waren er de vorige keer niet
  • welke records zijn er nu niet die er de vorige keer wel waren
  • welke velden komen niet overeen met de vorige keer, wat was toen hun waarde en wat is nu hun waarde.

Terug kijkend is de conclusie, dat het een succesvol conversietraject was.