Case study: SAP Masterdata bij globale fusie

 

Samenvatting:

Bij de fusie van Douwe Egberts met koffie- en thee activiteiten van Mondelēz was een zeer complexe omzetting nodig van Customer Masterdata. Bij de tweede test bleek dat er nog teveel fouten optraden, en er was een 100%-controle nodig; steekproeven waren niet voldoende. Deze ingewikkelde transformatie is parallel in Access gedaan om tot een ‘verwachting’ te komen. Deze verwachting is één-op-één vergeleken met de werkelijke migratie, en daarmee de 97% ‘goed’ gescheiden van de 3% ‘fout’.

Hier zitten twee effecten in:

·         die 3% kon worden opgelost zodat de transactiedata daarna foutloos in het systeem kwam

·         Bron+Verwachting+Migratie waren tegelijk te benaderen met één query. Hiermee kon het ontwerp tijdig worden bijgesteld, impact van fouten worden bepaald en konden selecties worden gemaakt voor correcties. Dit was onmogelijk in de verschillende SAP-omgevingen

Bij de post-mortem bleek dat deze Access methode achteraf gezien goedkoper en sneller was dan de migratie volgens de gekozen SAP-methodiek.

 

Achtergrond:

DE Master Blenders fuseert met de koffie- en thee activiteiten van Mondelēz. Voor de fusie zijn het concurrenten dus data mag niet (volledig) worden uitgewisseld (anti-thrust wetgeving). Daags na de fusie moet de volledige inkoop vanuit één punt gebeuren (belastingwetgeving). Gezien de wereldwijde omvang van deze retailer nogal een opgave om dit dus in één keer goed te krijgen. Mislukken is geen optie.

Uitdaging:

De eerste migratie-tests laten een te groot percentage fouten zien op de masterdata. Dit is binnen SAP zeer kritische data voor een goede werking. Besloten wordt dat een volledige controle nodig is om geen onaanvaardbare risico’s te lopen. Er zijn nog 6 weken te gaan tot de fusie.

De problemen zaten daarmee op verschillende vlakken:

Oplossing:

Downloads uit Amerika zijn (geautomatiseerd) in Access gezet waarbij ook het aanmaken van de tabellen geautomatiseerd werd. Alleen op deze manier is voldoende snelheid halen, de dynamische omgeving maakt namelijk dat de structuur ook regelmatig veranderd. Immers, het ontwerp van de migratie zelf werd parallel uitgevoerd aan het maken van deze validatie-tool (tóch meer of minder tabellen, andere kolommen die relevant blijken, etc.).

Binnen deze flexibele omgeving zijn daarnaast twee doel-databases aangemaakt. Eén voor de verwachting, en één om de daadwerkelijke migratie in te zetten.

Door queries te gebruiken als programmeertaal kon de ‘verwachting’ worden gevuld op basis van de complexe migratie-rules (soms regels samenvatten, soms regels verdubbelen, soms bron-veld vertalen, soms niet, soms default gebruiken, etc.). Dit alles moest uiterst flexibel worden ingericht omdat de business rules nog veranderden tot in de week voor de uiteindelijke migratie.
Dit is de T van ETL, en hier kon de ervaring van Essent (2011) en SNS-Propertize (2015) worden ingezet.

De resultaten van het SAP-migratieteam werden in de derde database gezet, en daarmee konden de technieken worden gebruikt die bij Essent (2004) de administratieve problemen hebben opgelost.

Resultaat van de vergelijking was een scheiding waar de validatie-tool en de migratie dezelfde data gaven, ten opzichte van waar verschillen kwamen.
Deze verschillen konden daarna worden geanalyseerd, en uit de validatietool konden bovendien correctie-lijsten worden gegenereerd.

Conclusies:

De scheiding tussen de foute- en de correct gemigreerde data is van onschatbaar belang geweest om de migratie tot een succes te maken. Daarbij is erkend dat ook in het ontwerp fouten konden zitten, en is deze validatie ingericht om daarmee om te kunnen gaan.

Als je geautomatiseerd fouten maakt, dan moet ook het oplossen geautomatiseerd worden. Alleen dan kan je grip houden op de systemen.

Daarnaast bleek het van onschatbare waarde om de drie databases vanuit één punt te kunnen benaderen. Alleen daarmee konden lijsten worden gemaakt van het type “Retail-customer met prijsconditie X bij Mondelēz die vertaald is naar Wholesale-customer bij DE”. (In SAP zelf zou je eerst in de ene omgeving een download moeten maken, dan ook in de andere omgeving, en vervolgens met Excel een speciale vertaalslag moeten maken om de doorsnede te kunnen bepalen.)

Vervolg:

Met de correctielijsten kon ‘de business’ tijdig de fouten oplossen zodat de zaterdag daarna de transactiedata foutloos werd gemigreerd. De migratie zelf duurde een halve dag, maar de validatietool deed hetzelfde in een kwartier. Door de flexibiliteit en de snelheid van de validatietool bleek ook dat daarmee ook een grote impuls is gegeven aan het vinden van de uitzonderingen (en kon het migratieplan worden bijgewerkt).

Na afloop zei de projectleider van de Masterdata: “Misschien hadden we deze aanpak moeten kiezen voor de migratie zélf.”

Voor verdere informatie, stuur een email naar:Bas Hartkamp