Erp-systemen vormden eind vorige eeuw de belofte van de toekomst, en ze hebben hun werk goed gedaan. Nu zitten veel organisaties met de verouderde systemen in hun maag. Hoe vervang je legacy-erp’s op verantwoorde wijze? En welke rol is daarin weggelegd voor low-code-technologie en integratieplatformen?
Erp-systemen zijn in de jaren tachtig en negentig van de vorige eeuw massaal uitgerold als vervangers van maatwerksystemen. Bekende en populaire voorbeelden als SAPR/3, Oracle E-Business Suite, Agresso, Baan, Coda en kleinere systemen van onder andere Exact hadden een vergelijkbare doelstelling: een standaardsysteem bouwen voor standaardbedrijfsprocessen, met veel flexibiliteit, functionaliteit en een beheersbaar kostenniveau.
Hoewel elke oplossing haar bijzonderheden heeft, delen erp-systemen een aantal kenmerken:
-
Een modulaire opzet met modules zoals finance, sales, supply chain, manufacturing, projects, warehouse managing, hr en crm;
-
Een groot deel van de functionaliteit is configureerbaar;
-
De data bevinden zich in een gedeelde database. Je hoeft stamdata dus maar één keer in te voeren.
Blok aan het been
In de loop der jaren zijn de systemen verder ontwikkeld. Ze kregen nog meer modules en functionaliteit. De makers voegden functies toe waarmee complete maatwerkmodules gebouwd konden worden met dezelfde look & feel als de standaardmodules.
Dat leek uiteraard handig, maar het verder uitbouwen van erp-systemen is nogal uit de hand gelopen. Veel erp-systemen zijn zo complex geworden dat het oorspronkelijke idee van snel werkende systemen verdween.
Er zijn dan ook diverse problemen waar bedrijven tegenaan lopen met hun legacy-erp’s. Zo wordt vaak nieuwe technologie aan het platform toegevoegd, maar de oude technologie wordt zelden uitgefaseerd. Hierdoor zijn erp-systemen zo log geworden. Het upgraden van een legacy-systeem naar een nieuwe, vaak in de cloud draaiende versie, is moeilijk of zelfs onmogelijk. Een her-implementatie is in zo’n geval het enige alternatief. Door de verouderde technologie is een legacy-erp bovendien niet altijd snel en soepel te integreren in moderne systemen. En laat dat nu net een van de meeste gestelde vragen van ondernemingen zijn in de afgelopen periode.
De monoliet
Erp-systemen oude stijl kenmerken zich door een monolithische architectuur. Alle software wordt als geheel geïnstalleerd, waardoor er een monoliet ontstaat. Ook zijn er vaak verschillende versies van zo’n erp in gebruik. En dan hebben we het nog niet over de vele parameters die ervoor zorgen dat elk erp-systeem uniek is qua gedrag en versies. Er is geen klant die met exact dezelfde versie en modules draait. Dat verklaart ook waarom upgrades complex zijn en lang duren. Het bij de tijd houden van een legacy-erp is niet meer behapbaar.
Hoe moet het verder met bedrijven die oude erp’s hebben draaien? Niet upgraden en het oude systeem niet vervangen zijn geen serieuze opties. De ondersteuning van het verouderde erp-platform houdt immers een keer op, terwijl het bedrijf doorgaat.
Functionaliteit bepalen en overzetten
Het probleem moet in stukken gehakt worden, een advies dat letterlijk is te nemen. Het is onmogelijk een groot erp-platform in één grote big-bang-operatie te vervangen. Het erp-systeem zal dus in kleinere functionele stukken geknipt moeten worden. Het oude erp-systeem wordt dan vervangen door meerdere standaard- en/of maatwerksystemen. Dat kan op onderstaande manieren:
Bepaal welke basisfunctionaliteit het nieuwe erp-systeem moet hebben. Voorbeelden van functies/modules zijn financiën, verkoop, inkoop, activa, logistiek en voorraad.
Verhuis de overige functies naar een andere omgeving. Je hebt hierbij de keuze uit:
-
‘Best-of-breed-applicaties’. Voorbeelden hiervan zijn crm, salarisverwerking en een warehousemanagementsysteem;
-
Een maatwerkplatform met één of meerdere apps als laag over standaardsystemen heen. Denk aan klantportalen, mobiele apps, klantspecifieke business of processen die uniek zijn voor de organisatie.
Vervolgens wordt het waarom, wat en hoe bepaald. Het waarom bestaat uit het ontwikkelen van een degelijke it- en business-strategie met duidelijke doelstellingen en prioriteiten. Het wat draait om het praktisch uitwerken van de IT-oplossingen die nodig zijn om te kunnen voorzien in wensen en behoeften. Het hoe omvat het herdefiniëren van de IT-architectuur. Let hierbij op de onderstaande onderdelen:
-
Gebruik de juiste technologie voor het juiste probleem;
-
Maak platformkeuzes op basis van wat nodig is. Meestal is dit een combinatie van best-of-breed applicaties, maatwerk-apps, een integratieplatform en een rapportageplatform (datawarehouse, BI);
-
Ontkoppel applicaties altijd via een integratielaag en voorkom rechtstreekse koppelingen tussen systemen;
-
Ontwerp oplossingen die schaalbaar zijn. Stel de vraag: “Werkt alles nog naar behoren als het aantal transacties de komende jaren explosief gaat stijgen met een factor 2, 3, 5, 10, 100, etc?”;
-
Kies de juiste infrastructuur. Er is keuze tussen een publieke of private cloud, een combinatie van de twee in een hybride omgeving, of meerdere private of publieke clouds naast elkaar. Zo’n multi-cloud komt steeds vaker voor;
-
Bepaal dan ook de eisen ten aanzien van security. Waar bevindt zich de data? En hoe dient die data beveiligd te worden?
Maak een planning
Het laatste deel van de verbouwing is de planning. Kijk in deze fase naar deze aandachtspunten:
-
Breng afhankelijkheden in kaart;
-
Maak een stappenplan en bepaal de prioriteiten (wat moet eerst, wat kan later?);
-
Zet dit plan om in een concrete roadmap of een projectportfolio.
Een integratieplatform speelt een cruciale rol. Het is noodzakelijk een erp-monoliet succesvol en stap voor stap te migreren. Een integratie-oplossing is dus een onmisbare schakel. Voor het realiseren van innovatieve maatwerkapplicaties is low-code-technologie geschikt. Middels de gecombineerde low-code- en no-code-aanpak worden applicaties snel en efficiënt ontwikkeld. Deze applicaties sluiten altijd perfect aan bij diverse vraagstukken.
De flexibiliteit van low-code- en integratieplatformen helpen bij het beheersbaar maken en oplossen van het erp-legacyprobleem. Gefaseerd, stap voor stap én agile.
Altijd leuk om ‘Can Do’ verhalen van muizen te lezen die olifanten willen verslaan want ERP systemen zijn gemodelleerd naar een organisatie, de onderliggende techniek heeft hierin als doel om de bedrijfsprocessen te ondersteunen. Dat sommige het omgekeerd proberen te doen komt doordat ze maatwerk systemen proberen te vervangen door standaard systemen, we hebben een hamer en daarom is alles een spijker. En de cowboys vergeten dan ook dat een ERP systeem vervangen meer is dan een IT project als we kijken naar de organisatorische samenhang van processen. Je kunt daarom beter bij de planning beginnen want een opdeling in allerlei losse schakels gaat volledig voorbij aan de essentie van een enterprise architectuur. Vandaag low-code, morgen slow-code als enige vervanging de code is.
Ik kan de termen Muizen, Olifanten en Cowboys niet helemaal plaatsen. Volgens mij probeert Pim aan te geven wat het probleem is van organisaties die zich doorontwikkelen maar waar het IT landschap niet snel genoeg meebeweegt. Uiteindelijk levert dat een probleem op met ERP want daar komen data en bedrijfsprocessen in digitale vorm bij elkaar.
Het moment dat je als organisatie besluit er echt werk van te maken komt vaak een paar jaar te laat en kamp je met alle legacy problemen vandien. En dat is verklaarbaar, want je ERP systeem aanpassen is net zoiets als een openhartoperatie.
Naar mijn mening kun je met een doordacht plan en diverse data integraties prima je ERP landschap herbouwen en tegelijk je werkwijze meeveranderen naar de nieuwe situatie terwijl de winkel open blijft. En Low-Code kan daarin een bescheiden, maar zeer waardevolle rol spelen waar het gaat om puntoplossingen en experimenteren met nieuwe standaarden.
Jasper,
Zoals jezelf al zegt is het aanpassen van een ERP systeem een openhartoperatie, je zult dan ook zeker moeten stellen dat de vitale functies overgenomen worden voordat je het hart stil legt. Pim begint al met snijden voordat de patiënt onder narcose is. Het laatste deel van de verbouwing is volgens Pim namelijk de planning en dat klinkt niet doordacht. Nu is de gehele diagnose al opmerkelijk want het is nog maar de vraag of IT niet snel genoeg meebeweegt met de organisatie of dat de organisatie vooruit loopt op de wetten die de bedrijfsprocessen bepalen. Boekhoudkundige regels zijn uiteindelijk niet zo veranderlijk en uiteindelijk draait het hele idee van ERP om de governance.
Puntoplossingen die vanuit een exportfunctie data aftappen om vanuit één punt een geheel eigen realiteit te modelleren leveren achteraf nogal wat verrassingen op in het planningsproces want bij de data integraties moet je goed op de data kwaliteit letten. Het ontkoppelen van applicaties via een integratielaag is dan ook het architectuur denken van de jaren 90, tegenwoordig hebben we een data lake want ik ben het met je eens dat de werkwijze van data vergaren veranderd.