Waar veel bedrijven tegenwoordig al een tweede of derde (of nog vaker) slag hebben gemaakt in het selecteren, implementeren en inzetten van ERP, is heden ten dage een veelbesproken onderwerp het migreren c.q. onder architectuur toewerken naar één platform. Dit wordt versterkt door via acquisitie en fusies ontstane internationale bedrijven. Mitopics heeft hier recent bij diverse internationale bedrijven ervaring mee opgedaan.
Bij het toewerken naar één platform dient rekening te worden gehouden met diversiteit en complexiteit in gewenste business functionaliteit enerzijds (concerns met vestigingen die zich bezighouden met productie, assemblage, handel, Field Service, projectondersteuning etc., eventueel in combinatie met een aantal centrale magazijnen.) en anderzijds beheerbaarheid (standaardisering en uniformering ten voordele – lees lagere kosten – van onderhoud en beheer van alle in gebruik zijnde systemen). Dit ook gezien de trend naar centralisering van secundaire diensten, zoals IT ondergebracht in bijvoorbeeld shared service centers. Een specifieke vorm van centralisatie komen wij in onze adviespraktijk regelmatig tegen bij buitenlandse – vaak Amerikaanse – bedrijven, met vestigingen in Europese landen, met een Europees hoofdkantoor. Mede vanuit lokalisatie, maar ook gezien verschillen tussen in gebruik zijnde oplossingen tussen het ‘oude’ en het ‘nieuwe’ continent (o.a. met het oog op beschikbaarheid van deskundige consultants en bewezen implementaties) wordt in toenemende mate gekozen voor de strategie van standaardiseren en uniformiseren naar één platform binnen het Europese continent in plaats van de in Amerika in gebruik zijnde oplossingen uit re rollen in Europa.
Één van de belangrijke vragen die aan de orde dient te komen bij het selecteren van één platform is van louter technische aard: welke multi-tenant architectuur dient de ERP-oplossing te ondersteunen. Bij een volledige multi-tenant oplossing maken alle organisatie entiteiten gebruik van dezelfde applicatie op dezelfde database en mogelijk zelfs van dezelfde informatietabellen. De specifieke configuratie van de applicatie kan per tenant wel verschillen, denk bijvoorbeeld aan de lay-out, I/O en landspecifieke configuraties, rapporten, formulieren en workflows. Echter, in de regel is dit het ultieme om na te streven. In de praktijk zijn ook andere oplossingen denkbaar, die gezien de organisatie beter passen of simpelweg veel eenvoudiger – lees goedkoper – zijn te realiseren en ook voldoen.
1. Eén systeem, één database voor alle entiteiten
Eén installatie van de applicatie waarin de afzonderlijke entiteiten als aparte administratie worden gedefinieerd maar wel vergelijkbare producten en klanten hebben.
2. Eén platform, eigen database voor alle entiteiten
De verschillende entiteiten delen dezelfde applicatie maar op een aparte database. Het betreft dus aparte installaties waarbij data tussen entiteiten wordt gedeeld middels een zogenoemde “broker”, meestal een web-interface (zie figuur 2).
3. Best-of-breed strategie
In deze strategie wordt per organisatie entiteit de best passende oplossing vastgesteld. Hiervoor wordt meestal gekozen wanneer de verschillende entiteiten wezenlijk andere processen, producten en/of klanten hebben, bijvoorbeeld een handelsorganisatie, een productieorganisatie en een serviceorganisatie. De data wordt in middels een directe interface tussen de entiteiten gedeeld.
4. Hub-and-spoke strategie
In het geval dat één entiteit het hoofdkantoor is en de andere entiteiten de afzonderlijke business units of divisies zijn die aan het hoofdkantoor rapporteren kan een deze strategie goed werkbaar zijn. Het hoofdkantoor implementeert een zwaardere applicatie waar vanuit de andere entiteiten worden aangestuurd.
Voor meer informatie, inclusief een verdere uitwerking van de genoemde strategieën, met hun voor- en nadelen, en architecturen voor ERP-oplossingen kunt u contact met ons opnemen.