Interfaces, data-uitwisselingen en IT-architectuur, dat zijn toch onderwerpen voor de IT-afdeling? Dit is hoe het vaak ging in het verleden. De IT-afdeling hield zich bezig met de technische details en het zorgen dat alles bleef draaien. Gelukkig gebeurden updates aan grote business applicaties als ERP niet zo vaak. Eens in de 10/15 jaar had je te maken met een groot project en verder was het een kwestie van laten draaien. Met de komst van de cloud, zeker voor ERP, is dit veranderd. De totale IT-architectuur en de keuzes die je maakt, zijn bepalend voor de schaalbaarheid en toekomst van je onderneming. En dus voor jou als manager. In deze blog nemen we je mee waarom dit zo belangrijk is, wat jouw mogelijkheden zijn en bij welke keuzes je betrokken moet zijn.
In blog 4 in de blogsreeks over management & cloud ERP heeft mijn collega René de top 3 managementuitdagingen benoemd bij het invoeren van cloud ERP: het opstellen van een solide business case, weerstand in de organisatie nu er (nog meer) standaardsoftware gebruikt gaat worden en keuzes omtrent tooling en technieken voor de uitwisseling tussen ERP en andere applicaties. Op de eerste twee onderwerpen zijn we verder ingegaan in blog 5 en blog 6 respectievelijk. In deze blog dus het antwoord op de laatste uitdaging.
Cloud ERP legt hogere eisen aan data-uitwisselingen
Zoals vaak benadrukt in de blogreeks, betekent de overstap naar cloud ERP dat jij niet meer kiest wanneer over te gaan naar een nieuwe versie van ERP. De leverancier doet 2-4 keer per jaar een release en jouw bedrijf wordt gedwongen om mee te gaan. Dus in plaats van dat jij eens in de zoveel jaar het hele systeem upgradet, word je nu meermaals per jaar geconfronteerd met een verplichte update en de bijbehorende gevolgen. En de grootste impact zit hem hier in maatwerk en data-uitwisselingen.
In het verleden werd vaak specifieke software ontwikkeld door de leverancier om de functionaliteit aan te passen op jou. Daarnaast werd er gekeken naar welke systemen hebben we nog meer. Een interface speciaal voor jouw bedrijf werd geprogrammeerd en je kon weer een paar jaar door – tot de volgende upgrade. Nu krijg je echter te maken met gedwongen updates – en dus moet bij elke update jouw interfaces en evt. maatwerk geëvalueerd worden (veelal door je eigen organisatie), noodzakelijke aanpassingen geprogrammeerd worden en zowel de losse interfaces als het geheel opnieuw getest worden. Het spreekt voor zich dat hoe meer (handgemaakte) interfaces, hoe meer werk er is en risico je loopt bij elke update.
Waarom is dit een managementthema?
Als management ga je je niet bezig houden met elke specifieke interface en de bijbehorende keuzes. Maar de traditionele aanpak waar de leverancier een aantal interfaces voor jou programmeert is niet (altijd) meer de juiste aanpak. Je wilt jouw IT-landschap mogelijk op een andere manier inrichten, waardoor je flexibeler bent en de impact van de releases beperkt blijft. Dit is noodzakelijk als je schaalbaar wilt blijven als onderneming.
En dan heb je ook nog te maken met dat de software niet meer op een voor jou ingerichte server draait, maar ergens in de cloud. Toegang tot de data is niet zo makkelijk meer als het was. Je moet een plan hebben als organisatie hoe jullie en relevante partners toegang blijven houden tot de data – voor interfaces, maar ook voor bijv. rapportages.
De meest voorkomende manier van data-uitwisselingen: API
De technologie die vaak wordt gebruikt door aanbieders van standaardsoftware, zoals cloud ERP, is API’s. Alle SaaS-systemen worden vaak geleverd met een set aan zogeheten API’s. Een API is een voorgeprogrammeerde manier om data op te halen, gebaseerd op een zekere bedrijfslogica. Bijv. een leverancier heeft de mogelijkheid geprogrammeerd om alle of een specifieke inkooporder op te vragen. De andere applicatie die met de oplossing moet communiceren roept dan deze API aan met een aantal specifieke parameters en krijgt de gewenste informatie op een gestandaardiseerde manier terug. Deze applicatie kan deze informatie dan weer verwerken. Er wordt een beveiligde verbinding tussen beide applicaties gemaakt, waardoor informatie veilig verstuurd kan worden en jouw informatie niet zomaar openbaar beschikbaar is.
Doordat de API calls van tevoren gedefinieerd zijn en zich houden aan een standaardformaat, kan de ontvangende partij deze informatie gewoon blijven gebruiken, ook al besluit de verzendende partij (het cloud ERP) intern dingen aan te passen. Zolang de specificatie niet veranderd, wat vrij zelden gebeurt, blijven de data-uitwisselingen werken. Dus ook bij een nieuwe release.
Deze API’s kunnen gebruikt worden door iedereen die toegang krijgt (security) en die de specificatie heeft. Het is een veilige en schaalbare manier van data-uitwisselingen waarbij je niet de interne werking van het systeem hoeft te snappen. Het grootste probleem in de praktijk zit hem erin dat niet alle partijen waar jij mee werkt, goed gedocumenteerde API’s hebben of maar een beperkte set aan API’s. Heb je andere data nodig, dan kan je die niet zomaar opvragen. Dan moet vaak de leverancier of een implementatiepartner handmatig API’s gaan schrijven/aanpassen, waardoor je weer met maatwerk te maken hebt. Dit zou je zoveel mogelijk moeten voorkomen.
Wat heb je nodig aan de ontvangende kant?
Aan elke interface zit twee kanten. Ervan uitgaande dat de applicatie de juiste API’s ter beschikking heeft, dan moet deze data alsnog geïnterpreteerd worden aan de andere kant, bijv. jouw MES-systeem, PDM-systeem, warehouse applicaties etc. De logica moet worden vastgelegd: wat moet er gebeuren met de data die ik ontvang. Er is hiervoor een aantal scenario’s:
- Een standaard aangeboden integratie. Het kan zijn dat twee applicaties al een bestaande integratie met elkaar hebben. Wat dit betekent is dat de leveranciers al hebben gedefinieerd hoe de uitwisseling eruit moet zien. Het is dan een kwestie van authenticatie – je geeft toestemming dat ze jou data mogen gebruiken – en het werkt. De applicaties hebben dan zelf de verantwoordelijkheid dat het blijft werken en er wordt niks speciaals voor jou ontwikkeld. Dit is de ideale situatie, maar het aantal bestaande integraties is beperkt.
- Er wordt een stuk software voor jou ontwikkeld die om kan gaan met de API calls van cloud ERP. Dit is al minder risicovol dan een helemaal handmatig gebouwde interface – de interne werking van ERP is al onder de motorkap gestopt – maar het is alsnog een stuk maatwerk dat onderhouden moet worden als API specificaties worden aangepast. Je moet hier duidelijke afspraken maken met de leverancier die de interface onderhoudt. Wat gebeurt er bij een release? Hoe snel kun je het aanpassen? Welke informatie heb je nodig?
- Wat in opkomst is, is een zogeheten iPaaS-platform. Dit zijn platformen waarbij je API calls van twee applicaties aan elkaar kunt koppelen. Het is een low-code manier van integreren, wat inhoudt dat je niet programmeert, maar via een interface aangeeft wat er met de data moet gebeuren. Oftewel informatie A van cloud ERP moet vertaald worden naar informatie B in de andere applicatie. Voorbeeld van zo een platform is Boomi of Workato. Ook al zijn deze platformen in opkomst, door de extra kosten en benodigde vaardigheden worden ze nog beperkt gebruikt. Het is interessant om te kijken of jouw leverancier of implementatiepartner hier al gebruik van maakt.
Wat moet jij dan als manager?
Om de schaalbaarheid van jouw bedrijf en organisatie te borgen, moet er een weloverwogen beslissing worden gemaakt over hoe om te gaan met interfaces. Er zijn vier vragen die je voor jezelf moet beantwoorden:
- Wat zijn de kosten van dit totale IT-landschap (zowel eenmalige investering als terugkerende kosten)?
- Stel ik wil over x jaar hier staan met mijn bedrijf, is dat haalbaar met de (technische) keuzes die ik nu maak?
- Heb ik met betrekking tot de vorige punten de juiste afspraken hiervoor gemaakt met mijn leveranciers en partners?
- Welke gevolgen hebben de technische keuzes voor mijn eigen (IT-)organisatie? Kunnen wij dit aan en continuïteit borgen?
Zonder het ingewikkeld te maken, wordt het aangeraden om een eenvoudige IT-architectuur op te stellen. Dit hoeven geen ingewikkelde diagrammen te zijn. Maar een overzicht van alle applicaties, welke bedrijfsprocessen ze ondersteunen en tussen welke applicaties er data moet worden uitgewisseld is genoeg. Vervolgens moet voor deze data-uitwisselingen bepaald worden wat voor een interface er moet komen en wie die gaat onderhouden.
De definitie van de interface kun je overlaten aan de experts. Maar als management moet je wel een visie hebben op de toekomst van het IT-landschap. Je moet meebeslissen over de manier waarop, de selectie van tooling en de onderhoudsafspraken. En de rest van de organisatie meenemen in de beslissingen. Anders hangt het gehele landschap als een molensteen om je nek bij elke release die komen gaat.
