Bedrijfsovername: Wat is de impact op het ERP-systeem bij een Verkoop? Bedrijfsovername: Wat is de impact op het ERP-systeem bij een Verkoop?
erp-data-finance-treasury

Bedrijfsovername: Wat is de impact op het ERP-systeem? Deel 1 – Verkoop

Het komt heel vaak voor in de huidige tijd: bedrijfsovernames. Maar wat houdt dit nu in voor de IT-systemen en dan in het bijzonder het ERP-systeem?

Een bedrijfsovername betekent niet alleen samenvoegen van systemen, ook het afsplitsen van systemen is hier aan de orde. In de verkoopdeal wordt bijvoorbeeld bepaald dat men een jaar lang op het bestaande ERP-systeem blijft werken. Daarna moet het afgesplitste bedrijf op zijn eigen benen gaan staan. Maar… heb je in dat jaar voldoende tijd om alle bedrijfsprocessen te integreren in het bestaande ERP? Of zijn er strategische keuzes om 2 ERP-systemen naast elkaar te draaien?

Het zijn vragen die we bij Cadran Consultancy tegenwoordig vaak horen. Maar waar moet je dan allemaal aan denken? Waar loop je tegenaan? En, hoe pak je dat aan? Wij delen graag onze visie op beide situaties: Overname vs overgenomen worden. In deze blog (deel 1) belicht ik de Verkoop situatie.

Verkoop van een bedrijf

Deze situatie komen we in onze klantenkring regelmatig tegen. Bedrijf X werkt met Oracle JD Edwards ERP en heeft hierin meerdere Companies en Business Units geconfigureerd. Productiebedrijven, distributiebedrijven, servicebedrijven of combinaties hiervan.
Hoe pakken wij dat aan? Allereerst heeft het natuurlijk te maken met de afspraken die er gemaakt zijn bij de verkoop. Wordt er onder de nieuwe eigenaar doorgewerkt met JD Edwards ERP of wordt er geïntegreerd naar het ERP-systeem van de aankopende partij.

Het spreekt voor zich dat onze voorkeur uitgaat naar het blijven werken met JD Edwards en van daaruit te consolideren met het ERP-systeem van de overnemende partij. Dit proces kunnen we opdelen in drie fasen: 1. opsplitsen van werkprocessen en security, 2. fysiek splitsen van de systemen, 3. opruimen van data in de afgesplitste systemen.

Fase 1: Opsplitsen van werkprocessen en security

In eerste instantie gaan we onderzoeken welke processen gedeeld worden door de in JD Edwards opgezette companies. Intercompany leveringen van goederen zijn hier de meest voorkomende, maar denk ook aan Shared Service Centers op financiële afdelingen (AR/AP) of op Customer Service afdelingen.
Het eerste dat uitgevoerd moet worden, is het opdelen van de companies in JD Edwards door het toevoegen van een zogenaamde company security. Hierdoor kunnen medewerkers van bedrijf A niet meer bij bedrijfsprocessen en data van bedrijf B en vice versa. Meestal komen dan direct de eerste problemen om de hoek kijken. Gedeelde klantenbestanden, gedeelde artikelbestanden, gedeeld MRP voor de productie-aansturing bevatten allen set-up en masterdata die door de security scheiding niet meer goed (b)lijken te werken of niet meer beschikbaar zijn.

Daarom kijken wij eerst goed naar alle bedrijfsprocessen en hoe de data gebruikt wordt. Daarna maken we plannen voor de ontvlechting van de processen en data en – als dat nog niet is opgezet – plannen om security van de test/acceptatieomgevingen en productieomgeving te scheiden. Door deze scheiding van security kunnen we testen met security aanpassingen zonder dat direct de productieomgeving verstoord wordt als hier dingen over het hoofd gezien worden.

Voor het ontrafelen van intercompany leveringen of transfer orders tussen eigen bedrijven/magazijnen zal naast de logistieke stroom ook de financiële afhandeling goed moeten worden nagelopen. Hiervoor zetten we een nieuw intercompany leveringsproces op waarbij bedrijf A en bedrijf B klant/leverancier van elkaar worden.

Als al deze stappen gezet zijn, dan voeren we de gescheiden werkprocessen en gescheiden security in de productieomgeving door. Het resultaat is dan één JD Edwards-omgeving waarin 2 bedrijven onafhankelijk van elkaar kunnen werken.

Fase 2: Fysiek splitsen van de systemen

Vervolgens gaan we over naar fase 2, het fysiek scheiden van de hardware. Hiervoor wordt meestal nieuwe hardware aangeschaft waarop we een kopie zetten van de JDE instance (systeem) die nu draait. Naast JD Edwards moeten we hier ook rekening houden met alle overige applicaties die via interfaces zijn aangesloten op het ERP-systeem. Denk hierbij bijvoorbeeld aan AP Scanning (bv ISP Invoice), document opmaak software, externe WMS- systemen, externe productieplanningsystemen of scanningsystemen. Dit gehele landschap zal in de kopieslag moeten zitten om te zorgen dat er een identieke gespiegelde situatie ontstaat. Het kopiëren van alle systemen heeft ook de nodige test en doorlooptijd nodig. Het resultaat na dit GoLive moment is, dat er twee systemen zijn die onafhankelijk van elkaar kunnen draaien.

Fase 3: Opschonen van data

Na het opknippen van de systemen staat alle ‘oude’ data nog in beide omgevingen. Wellicht zijn hier contractuele afspraken over te maken, maar de praktijk leert dat deze data altijd opgeschoond wordt in minimaal 1 van beiden systemen. Er is een overlap in tijd tussen verkoop en fysieke opdeling waardoor data van de nieuwe eigenaar nog in het systeem van de oude eigenaar staat. Dit laten we meestal ongemoeid.
Voor het opschonen van de data gebruiken we bij voorkeur SQL queries. Hier is wel de nodige voorzichtigheid geboden, want je kunt niet zomaar alle data opschonen. Specifiek gedeelde data zoals de eerder genoemde klantendata en artikeldata is altijd lastig op te schonen. Daarnaast zijn er tabellen zonder Company of Business Units velden in JD Edwards die specifieke aandacht nodig hebben. Uiteindelijk moet de database natuurlijk wel integer blijven.

Blog: Bedrijfsovername-Wat is de impact op het ERP-systeem

Database zoals die bestaat op het moment dat fase 2 is afgerond.

  • Sector I en II zijn van voor de verkoop, sector III en IV zijn van na de verkoop.
  • Sector I, data van bedrijf A van voor de verkoop → eigendom van bedrijf A en moet weg uit systeem van bedrijf B.
  • Sector II, data van bedrijf B van voor de verkoop → eigendom van bedrijf A omdat dit data is van voor de verkoop. Data blijft in beide omgevingen aanwezig
  • Sector III, data van bedrijf A van na de verkoop → eigendom van bedrijf A en moet weg uit systeem van bedrijf B.
  • Sector IV, data van bedrijf B van na de verkoop → eigendom van bedrijf B. Vraag is of dit opgeschoond moet worden uit de database van bedrijf A.

De meest voorkomende situatie: in de database van Bedrijf B schonen we sectoren I en III op. In de database van bedrijf A doen we niets. Data in sector II was nog eigendom van voor de verkoop. Om alleen de data in sector IV op te ruimen is ingewikkeld en kost veel tijd. Daarnaast is deze data niet veel anders dan hetgeen nog in sector II staat, alleen van een latere periode. Deze opschoning voeren we vanwege de arbeidsintensiteit vaak niet uit, in een contractvorm wordt onderling afgesproken hoe hiermee om te gaan.

Tot slot

Is dit alles waar rekening mee gehouden moet worden? Nee, dit is slechts het topje van de ijsberg. In 2 blogs beschrijven we in het kort de activiteiten van ERP-ontvlechting of ERP-integratie, maar hebben we geen aandacht besteed aan consolidatie van hardware of netwerken of aspecten als email-integratie. Veelal zaken waar je als JD Edwards ERP-consultant niet mee te maken hebt, maar wat binnen deze trajecten wel een grote rol speelt. De infrastructuur, office software en de integratie of juist het opdelen daarvan vormen minstens zo grote aandachtspunten die ieder voor zich weer ingrijpen op de ERP-projecten.

Meer weten over onze expertise met ontvlechting of integratie van ERP-systemen?

Lees ook het eerste deel dat de Verkoop van een business unit belicht.

Mail ons

Bel ons: +31 (0)33 2471599

patrick-brouwer

Auteur: Patrick Brouwer
Project Manager & Senior JD Edwards Logistic & Distribution Consultant