Rabo Vastgoed HR integratie
Rabo Vastgoed is onderdeel van Rabobank en behoort tot de grootste vastgoedondernemingen van Europa. Rabo Vastgoed is in 2006 ontstaan door integratie van Bouwfonds, de FGH-bank en Rabo Vastgoed.
Context en opdracht
Tot 2008 golden voor de verschillende onderdelen van Rabo Vastgoed nog afzonderlijke arbeidsvoorwaarden. De personeels- en
salarisadministratie werd nog door de oorspronkelijke organisaties uitgevoerd.
Vanaf 2008 geldt er voor heel Rabo Vastgoed een nieuwe CAO. De CAO is het resultaat van de arbeidsvoorwaardelijke integratie van Bouwfonds, FGH-bank en Rabo Vastgoed. Om dit te kunnen uitvoeren werd de personeels- en salarisadministratie geïntegreerd en aangepast aan de nieuwe arbeidsvoorwaarden.
De dataconversie van de personeelsgegevens vormde een onderdeel van dit project. De personeels- en salarisgegevens van medewerkers van Rabo Vastgoed en FGH-Bank moesten worden geconverteerd naar het HR-systeem van Bouwfonds. Ook voor de medewerkers van Bouwfonds was een beperkte conversie noodzakelijk in verband met de nieuwe arbeidsvoorwaarden.
salarisadministratie werd nog door de oorspronkelijke organisaties uitgevoerd.
Vanaf 2008 geldt er voor heel Rabo Vastgoed een nieuwe CAO. De CAO is het resultaat van de arbeidsvoorwaardelijke integratie van Bouwfonds, FGH-bank en Rabo Vastgoed. Om dit te kunnen uitvoeren werd de personeels- en salarisadministratie geïntegreerd en aangepast aan de nieuwe arbeidsvoorwaarden.
De dataconversie van de personeelsgegevens vormde een onderdeel van dit project. De personeels- en salarisgegevens van medewerkers van Rabo Vastgoed en FGH-Bank moesten worden geconverteerd naar het HR-systeem van Bouwfonds. Ook voor de medewerkers van Bouwfonds was een beperkte conversie noodzakelijk in verband met de nieuwe arbeidsvoorwaarden.
Aanpak en resultaten
Vanuit 3 verschillende bronsystemen werden de gegevens de geconverteerd naar één doelsysteem. De bronsystemen waren SAP, PMS en PView. Het doelsysteem was PView. Naast de gegevens uit de bronsystemen werden ook gegevens geconverteerd die niet uit deze systemen kwamen. Die gegevens werden door de HR-medewerkers in enkele spreadsheets verzameld. Om de betrokkenen voorafgaand aan de definitieve conversie te informeren over wat er geconverteerd zou worden, werden voor alle medewerkers Personal Benefit Statements (PBS) opgesteld, waarop een samenvatting van de gegevens vóór conversie en de gegevens na conversie werden getoond. Door middel van dit overzicht werden voor iedere medewerker de arbeidsvoorwaardelijke wijzigingen inzichtelijk gemaakt. Ook kon daarmee de juistheid van de conversie worden vastgesteld.
Deze conversie is uitgevoerd met de methode en de conversietool DataTranscript.Tussen bron en doel werd een conversiedatabase geplaatst. De beschrijving, inrichting van deze conversiedatabase en de aansturing van de feitelijke conversie gebeurde met de tool
DataTranscript.
Deze conversie is uitgevoerd met de methode en de conversietool DataTranscript.Tussen bron en doel werd een conversiedatabase geplaatst. De beschrijving, inrichting van deze conversiedatabase en de aansturing van de feitelijke conversie gebeurde met de tool
DataTranscript.
De gegevensstructuur van alle bron- en doelgegevens werd volledig geanalyseerd en beschreven: tabellen, kolommen, datatypes,
waardebereiken, etc. Op basis van deze analyse werd de databasestructuur voor de conversiedatabase door de conversietool gegenereerd. Vervolgens werden de conversieregels opgesteld. De uiteindelijke conversiescripts (de SQL-statements die voor de feitelijke conversiezorgen) werden door de tool gegenereerd vanuit die conversieregels. Daarna konden de conversieregels worden getest en, waar nodig, aangepast. Voor het testen werden in de conversietool testscripts en controletellingen gedefinieerd.
Ook werden kwaliteitscontroles in de tool opgenomen, waardoor voorkomen werd dat het doelsysteem met onjuiste gegevens
vervuild zou worden. Dit leidde tot verbetering van de gegevenskwaliteit in de bronsystemen. Daarna kwamen de verbeterde gegevens met een nieuwe gegevenslevering in de conversiedatabase.
Het project is cyclisch, iteratief aangepakt. We begonnen met een beperkt deel van de gegevenssoorten van slechts één bron. Daarmee werden alle activiteiten uitgevoerd. Daarna werden steeds meer gegevenssoorten en bronnen toegevoegd.
Dankzij de uitgebreide testfase waarbij een aantal proefconversies is uitgevoerd, kon de definitieve conversie succesvol en zonder
complicaties worden uitgevoerd.
waardebereiken, etc. Op basis van deze analyse werd de databasestructuur voor de conversiedatabase door de conversietool gegenereerd. Vervolgens werden de conversieregels opgesteld. De uiteindelijke conversiescripts (de SQL-statements die voor de feitelijke conversiezorgen) werden door de tool gegenereerd vanuit die conversieregels. Daarna konden de conversieregels worden getest en, waar nodig, aangepast. Voor het testen werden in de conversietool testscripts en controletellingen gedefinieerd.
Ook werden kwaliteitscontroles in de tool opgenomen, waardoor voorkomen werd dat het doelsysteem met onjuiste gegevens
vervuild zou worden. Dit leidde tot verbetering van de gegevenskwaliteit in de bronsystemen. Daarna kwamen de verbeterde gegevens met een nieuwe gegevenslevering in de conversiedatabase.
Het project is cyclisch, iteratief aangepakt. We begonnen met een beperkt deel van de gegevenssoorten van slechts één bron. Daarmee werden alle activiteiten uitgevoerd. Daarna werden steeds meer gegevenssoorten en bronnen toegevoegd.
Dankzij de uitgebreide testfase waarbij een aantal proefconversies is uitgevoerd, kon de definitieve conversie succesvol en zonder
complicaties worden uitgevoerd.