Het koppelen van maatwerksoftware aan ERP-pakketten is een situatie die veelvuldig voorkomt. Het is dan ook niet voor niets dat deze problematiek een van de onderwerpen vormt die op het congres van Software Automation aan de orde komt. Wanneer is een koppeling zinvol en waar moet een software-engineer bij het bouwen van interfaces op letten? De visie van Jan Kees Meindersma en Maarten Roset van HSO Business Systems en Willem Dicou en Cor Valkis van Origin.
De autoriteiten van een Nederlandse haven hebben Baan-software aangeschaft. Het probleem is dat dit ERP-pakket bepaalde functies niet afdekt. Bijvoorbeeld de administratie rond de afhandeling van containers. De haven doet dat voor een aantal grote rederijen die daarvoor een rekening krijgen gepresenteerd. Voor de administratie en het factureren wordt speciale software gebruikt. Het Baan-pakket regelt de administratie rond het ontvangen van de betalingen en de openstaande posten. Dit betekent dat gegevens uit het externe pakket op een of andere manier in Baan ingelezen dienen te worden. Daarvoor staan drie wegen open: alle factuurgegevens handmatig in het Baan-systeem invoeren; per maand alleen financiële transacties handmatig inbrengen of een interface schrijven om de factuurgegevens in te lezen in de financiële integratietabellen van Baan, waarna deze op dezelfde manier worden verwerkt als de andere facturen, die vanuit de verkoopmodule van Baan komen.
"We kozen uiteindelijk voor het bouwen van een interface, aangezien we daardoor goed gebruik konden maken van de functionaliteit van beide systemen. Door gegevens in een integratietabel in te lezen, kunnen havenmedewerkers nauwkeurig traceren welke financiële transacties afkomstig zijn uit de facturering van het externe systeem", vertelt Jan Kees Meindersma, senior consultant van het in Scherpenzeel gevestigde HSO Business Systems, gespecialiseerd in het implementeren van Baan-software.
Hij noemt de haven als voorbeeld van een situatie waarin het zinvol kan zijn om maatwerk te koppelen aan een ERP-pakket. Dat geldt vooral wanneer bepaalde functies niet door een ERP-pakket worden afgedekt en toch cruciaal zijn voor een bedrijfsactiviteit. Soms heeft een organisatie al een maatwerkpakket, soms moeten de automatiseerders speciaal iets nieuws schrijven. In beide gevallen geldt dat er goed moet worden gekeken op welke wijze de programma’s het beste kunnen samenwerken. Meindersma waarschuwt er overigens voor om niet al te snel over te gaan tot het koppelen van maatwerkprogrammatuur aan standaardsoftware. Het moet wel zinvol zijn.
Zinvol koppelen
Willem Dicou, senior manager bij de service-line Business Applications Systems/Software Engineering van Origin, is het volledig met Meindersma eens. "ERP-pakketten dekken lang niet alle functies af. Vooral niet als het gaat om unieke processen. Het berekenen van royalties door Buma/Stemra bijvoorbeeld is zo’n uniek proces, waarvan de financiële afhandeling overigens wel kan worden gedaan met een standaardpakket. Een koppeling is hier dus zinvol", stelt Dicou volgens wie in technische zin alles aan elkaar is te knopen. "Het is echter de vraag of zo’n koppeling vanuit bedrijfsmatig oogpunt zinvol is. Bij de beoordeling daarvan spelen factoren als de intensiteit van de koppeling en de hoeveelheid ongecontroleerde redundantie van gegevens een belangrijke rol. Je moet een kosten/baten afweging maken. Wanneer je maar één keer per jaar voor een consolidatie een paar gegevens uit een maatwerkomgeving en een standaardpakket bij elkaar moet optellen, dan is het overtypen van de gegevens in een spreadsheet al snel een stuk goedkoper", meent Dicou, die van oordeel is dat de tools die op de markt beschikbaar zijn om koppelingen tot stand te brengen, verder zijn dan de traditionele ERP-pakketten aankunnen. De meest toegepaste koppeling is vandaag de dag nog steeds de ‘file’-koppeling. Een pakket als Baan heeft standaard een ‘exchange’-tool, waarmee gegevens als Ascii-files kunnen worden geïm- en -exporteerd. Dergelijke koppelingen zijn vrij eenvoudig te realiseren, maar hebben als nadeel dat ze een batchkarakter hebben en dus niet geschikt zijn voor transactiegeoriënteerde omgevingen.
Online koppelingen zijn volgens Dicou te realiseren door middel van zogeheten interface engines en message brokers. Dit soort functionaliteit wordt samengevat onder de noemer middleware. Deze ontvangt boodschappen van de ene applicatie en speelt deze door naar de andere applicatie. In dat proces kan zowel protocol- en formaatconversie als het splitsen en samenvoegen van boodschappen plaatsvinden. De voordelen van dergelijke interface engines en messagebrokers, die overigens eenvoudig met scripts zijn te configureren, zijn volgens Dicou evident. De integriteit van de totale gegevensverzameling is altijd gegarandeerd. Het nadeel is echter een zekere mate van performanceverlies. Een nieuwe ontwikkeling ziet Dicou in het openstellen van de ERP-pakketten door middel van voorgedefinieerde Api’s die als een Com- en/of Corba-object beschikbaar worden gesteld. Hiermee wordt het mogelijk gedistribueerde systemen te bouwen die maatwerk- en standaardoplossingen naadloos integreren.
"Wanneer een applicatie op geen enkele manier gegevens kan uitvoeren naar of inlezen van een bestand, zou je een zogenaamde screenscraper kunnen gebruiken. Deze ‘leest’ de gegevens op een scherm en schrijft ze vervolgens weg in een bestand. Een macro die de gegevens leest en automatisch invoert, is ook een oplossing, De verzamelde gegevens moeten dan echter gefilterd worden om ze te kunnen gebruiken. Dat is een gebruiksonvriendelijke en instabiele oplossing", vult Cor Valkis, development consultant bij de Baan Service Line van Origin, zijn collega aan. Beste alternatief zijn volgens hem applicaties die verschillende databases kunnen benaderen waardoor de verschillende systemen direct kunnen lezen en schrijven in elkaars gegevensverzamelingen. Alleen is hier het probleem dat de applicatielogica wordt gepasseerd. Het gevaar bestaat dan dat er een inconsistentie gaat ontstaan. "Het opnieuw programmeren van de applicatielogica zou theoretisch een oplossing zijn, maar is uit oogpunt van onderhoud, beheer en aansprakelijkheid niet aan te raden", meent Valkis.
Glijdende schaal
"Natuurlijk is technisch gezien alles met alles te koppelen", is ook het oordeel van Maarten Roset die als senior technical consultant werkt bij HSO Business Systems. "Maar wanneer je eraan begint, zul je jezelf een paar vragen moeten stellen. Wat zijn de mate, de frequentie en het type van de interactie en om welke gegevens gaat het? Met andere woorden, je moet kijken naar de complexiteit, de informatiebehoefte en de efficiency. Verder moet je ook de risicofactoren goed inschatten. Heb je een goede definitie opgesteld, hoe is het met de testfase, hoe staat het met de consistentie en de volledigheid van de data in de systemen. Met een slecht geschreven interface loop je immers het risico dat databestanden corrupt raken of dat belangrijke gegevens bijvoorbeeld wel in het ene, maar niet in het andere systeem aanwezig zijn", meent Roset die het verschil tussen ‘integratie’ en ‘interfacing’ als een ‘glijdende schaalverdeling’ ziet. "Een interface is over het algemeen een tool om data van het ene systeem in het andere systeem te importeren (eenrichtingsverkeer) op een bepaalde frequente basis waarbij het aantal verbindingsmomenten laag is. Het is dus een eenrichtingsverkeer. Bij integratie worden gegevens geïmporteerd in een ERP-pakket om vervolgens weer geëxporteerd en ingelezen te worden in de maatwerkapplicatie (tweerichtingsverkeer)."
Valkis van Origin kan zich wel in deze definitie vinden: "Bij interfacing is er sprake van een gegevensuitwisseling waarbij geen directe terugkoppeling bestaat. De data worden dus min of meer batchgewijs verstuurd en verwerkt. Bij integratie is sprake van een ‘gesloten circuit’, waarbij een transactie gezien wordt als het geheel van acties op de verschillende systemen tezamen. Het (mis)lukken van een actie op een van de systemen moet in het geval van een integratie dan ook teruggekoppeld worden naar alle andere relevante systemen. In het algemeen is hier dan ook sprake van een online situatie. Daarmee geef ik gelijk de situaties aan waarin interfacing dan wel integratie zinvol kan zijn: bij online gegevensuitwisseling kun je het beste kiezen voor integratie. Wanneer die online situatie niet echt belangrijk is, kun je beter kiezen voor een (Ascii)-interface.�
Componenten
Veel organisaties hebben de laatste jaren grote sommen geld geïnvesteerd in maatwerksoftware. Het is niet alleen uit oogpunt van functionaliteit zinvol om dergelijke programmatuur in te passen in een nieuwe IT-infrastructuur. Ook kostenoverwegingen spelen een grote rol. Wanneer de software millennium-proof is, is het domweg zonde om haar van de hand te doen. "We hebben in Amerika bijvoorbeeld een integratie gemaakt tussen het Baan-pakket en een belastingpakket Avp genaamd. In deze situatie maakt Baan de orders aan en schiet deze als het ware door aan Avp. Deze software berekent welk belastingtarief van toepassing is en geeft de gegevens door aan Baan. Baan gebruikt de tariefgegevens vervolgens om verdere berekeningen in de orderadministratie te maken en laat deze uiteindelijk ook op de factuur zien", noemt Meindersma als voorbeeld van een integratietraject. Hij waarschuwt, net als zijn collega’s bij Origin, om niet in de ERP-pakketten zelf in te grijpen. Dat levert grote problemen op, wanneer er een nieuwe versie wordt aangeschaft. Dicou pleit, zeker in complexe omgevingen, dan ook voor het opstellen van een integratie-architectuur. "Koppelingen, al dan niet tijdelijk, zijn onlosmakelijk verbonden met de integratie van een ERP-pakket. Het is dan ook typisch een domein van partijen zoals Origin, die implementatiediensten leveren. De pakketleveranciers werken mee door documentatie en een ontwikkelomgeving beschikbaar te stellen. Wel is het zo dat zij hun eigen pakketten als het middelpunt en basis zien. In een complexe omgeving, waarin maatwerk extra functionaliteit moet bieden of waarin meerdere pakketten worden geïmplementeerd, is het daarom zinvol om een integratie-architectuur op te stellen, die niet specifiek aan een pakket of omgeving is opgehangen. Iedereen streeft natuurlijk wel naar een homogene oplossing, maar in de praktijk is dat een utopie. Al was het alleen maar omdat er altijd nieuwe business issues ontstaan, waarvoor niet direct een oplossing in een standaardpakket voorhanden is. Zo’n integratie-architectuur helpt om op een eenduidige en consistente manier door de tijd heen standaard- en maatwerkfunctionaliteit op een zinvolle wijze te integreren. Behoud van geïnvesteerd kapitaal speelt daarbij een belangrijke rol", aldus Dicou.
Overigens zijn de meeste ERP-leveranciers de laatste tijd actief om hun pakketten te ‘componentiseren’. Valkis: "Voor Baan is een volledig open systeem het uiteindelijke doel. Ze gaan naar een architectuur van componenten waarbij deze componenten een transparante interface moeten bieden. Daardoor wordt het mogelijk een applicatie te bouwen met leveranciersonafhankelijke componenten. In de laatste versie van het ERP-pakket, BaanERP, zijn daarom Business Object Interfaces (Boi) geïntroduceerd. Deze bieden applicatieservices in de sfeer van ‘Voeg een order toe en geef een lijst van alle artikelen die extern zijn aan te roepen’. Baan gebruikt de Boi’s, die te vergelijken zijn met de Bapi’s van Sap (Binary Application Interface), om de eigen softwarepakketten te integreren." Daarmee legt Valkis de relatie met een ander onderwerp, dat op het congres van Software Automation uitgebreid aan bod komt: de beschikbaarheid van componentware, waardoor het onderscheid tussen maatwerk- en standaardprogrammatuur steeds meer vervaagt.
Cok de Zwart, freelancemedewerker Computable
