In het jaar 2002 moet de gulden zijn vervangen door de euro. Nog maar weinig bedrijven hebben een euro-programma uitgevoerd; ervaringscijfers zijn daarom nauwelijks voorhanden. Geschat wordt dat zo’n 60 procent van de kosten van een euro-programma voor rekening van de IT komt. Het ‘optimale’ scenario is voor elk bedrijf anders en is afhankelijk van factoren als de wensen van de belangrijkste leveranciers en klanten en de samenhang tussen de systemen. Een medewerker van American Management Systems geeft inzage in de problematiek.
Waar men het millennium- of ‘jaar 2000’-probleem zou kunnen omschrijven als een IT-probleem met consequenties voor de bedrijfsvoering, is de euro juist veel meer een zakelijk probleem met IT-consequenties.
Door de invoering van de euro krijgt een bedrijf immers te maken met vragen als: Moet ik mijn contracten met leveranciers en afnemers aanpassen? Biedt de gemeenschappelijke munt mij de mogelijkheid om nieuwe afzetmarkten aan te boren? Zijn er mogelijkheden voor nieuwe producten of diensten? Moet ik voor een bepaald product in het hele EMU-gebied dezelfde ‘mooie’ prijs gaan vragen?
Het antwoord op dergelijke vragen moet in eerste instantie gegeven worden door afdelingen als strategie en marketing. Pas bij de praktische uitwerking, zoals de introductie van een verzekeringspolis in euro’, komt de IT om de hoek kijken.
Anderzijds kan een bedrijf slechts dán realistische en haalbare keuzen maken als het voldoende inzicht heeft in de gevolgen daarvan voor de geautomatiseerde systemen: geschat wordt dat zeker 60 procent van de kosten van een euro-programma voor rekening van de IT komt.
Inventarisatie
Nadat het management bewust is gemaakt van het belang en de urgentie van het euro-probleem, en er een euro-programma is gestart, zal het bedrijf een inventarisatie moeten maken van de aanwezige systemen, inclusief decentrale applicaties als spreadsheets. Bedrijven die reeds begonnen zijn met de aanpak van het millennium-probleem, kunnen hun ‘jaar 2000’-inventarisatie gebruiken als basis voor de euro-inventarisatie. Ze moeten zich echter wel realiseren dat het hierbij om twee verschillende problemen gaat. Zo zal veelal alleen gekeken zijn of een bepaald spreadsheet-programma ‘jaar 2000’-bestendig is, terwijl nu alle individuele spreadsheets moeten worden onderzocht op de aanwezigheid van valutavelden!
Vervolgens moet worden gekeken op welke systemen de euro invloed heeft (systemen die geldbedragen verwerken, dus de urenregistratie mogelijk niet, maar de salarisadministratie weer wel). Pas daarna kan het bedrijf bepalen welke van deze systemen wanneer en op welke wijze gereed worden gemaakt voor de euro.
Binnen de systemen die geldbedragen verwerken, kunnen we grofweg vier typen onderscheiden: ‘non-currency’-systemen, ‘mono-currency’- systemen, ‘multi-currency’-systemen met een enkele basisvaluta, en ‘multi-currency’-systemen met meerdere basisvaluta’s. Sommige van deze typen zijn makkelijker aan de euro aan te passen (en met name aan de overgangsperiode waarin zowel met de nationale muntsoort als met de euro kan worden betaald) dan andere.
‘Non-currency’-systemen bevatten geen expliciete valuta-aanduiding: de muntsoort is impliciet die van het land waarin deze gebruikt wordt. In Nederland staat 20,00 dus voor twintig gulden. ‘Non-currency’-systemen kunnen slechts één muntsoort verwerken. Dit geldt ook voor ‘mono-currency’ systemen. Zij bevatten echter wél een expliciete valuta-aanduiding: het scherm in het genoemde voorbeeld zou daarom iets dergelijks als ‘HFL 20,00’ of ‘NLG 20,00’ tonen.
De meeste systemen die niet speciaal bedoeld zijn voor handelsbedrijven of de financiële sector, zijn van het type non- of mono-currency. Zij zijn het moeilijkst aan te passen aan de euro.
‘Multicurrency’-systemen met een enkele basisvaluta kunnen verschillende muntsoorten verwerken. Zij slaan echter alles op in één basisvaluta, en voeren ook alle berekeningen daarin uit. Een valuta-tabel zorgt ervoor dat bedragen in andere valuta’s bij in- of uitvoer worden omgerekend tegen de dan geldende wisselkoers. Dergelijke systemen zijn eenvoudiger aan te passen aan de euro, hoewel ook hier problemen als afrondingsverschillen zullen optreden.
‘Multicurrency’-systemen met meerdere basisvaluta’s tenslotte kunnen verschillende valuta’s verwerken en opslaan, en daarin ook berekeningen uitvoeren. Deze systemen zijn het makkelijkst aan de euro aan te passen: het bedrijf hoeft alleen de euro als nieuwe basisvaluta in te voeren. Het belangrijkste probleem hier is dat systemen van dit type complexer en duurder zijn dan andere typen systemen. Ze zijn daarom moeilijk te rechtvaardigen als oplossing als het er alleen maar om gaat de overgangsperiode van 1999 tot 2002 te overbruggen.
Interfaces
Systemen functioneren zelden in isolatie: de meeste ontvangen gegevens van andere systemen, al dan niet buiten het eigen bedrijf, en leveren zelf gegevens voor weer andere systemen. Het spreekt vanzelf dat een ontvangend systeem niet zomaar kan worden omgezet naar euro, terwijl de aanleverende systemen nog uitsluitend met guldens werken. In zo’n geval moeten speciale maatregelen worden getroffen aan de uitvoerzijde van de aanleverende systemen of aan de invoerkant van het ontvangende systeem, of er moet een aparte laag tussen worden gezet die voor conversie zorgt. Zodra ook de aanleverende systemen met de euro kunnen werken, kan de tussenlaag weer verdwijnen.
Een bedrijf moet daarom nagaan wat de onderlinge samenhang is tussen de bedrijfsinterne systemen, en welke interfaces er met externe systemen zijn. Het verdient aanbeveling om ook vooraf vast te leggen hoe het interface-probleem zal worden aangepakt: door het aanpassen van de uitvoerzijde, het aanpassen van de invoerzijde, of het tijdelijk tussenvoegen van een conversielaag. Zo valt te voorkomen dat, in twee aparte deelprojecten, onnodig zowel het aanleverende als het ontvangende systeem wordt aangepast.
Aanpassingsmogelijkheden
Bedrijven zullen bij elk systeem moeten aangeven hoe het aan de euro zal worden aangepast. De belangrijkste mogelijkheden zijn: modificeren, geheel herschrijven of vervangen door een standaardpakket. Die laatste optie lijkt aantrekkelijk, omdat hiermee in een klap zowel het euro- als het millennium-probleem zou kunnen worden opgelost. Voor veel bedrijven die recentelijk op erp-pakketten als Baan en SAP zijn overgestapt, zal deze overweging zeker hebben meegespeeld.
Standaardpakketten bieden echter zelden of nooit àlle gewenste functionaliteit. Bovendien kan de implementatie van een bedrijfsbreed pakket een tot twee jaar duren.
De uiteindelijke keuze is afhankelijk van factoren als kosten, beheersbaarheid, het strategisch belang van het systeem, de samenhang tussen systemen, en de aan- of afwezigheid van documentatie.
Bedrijven zullen ook moeten besluiten wanneer elk systeem overgaat op de euro. De twee extremen zijn: alle systemen per 1 januari 1999 overzetten (te verwachten bij bedrijven binnen de financiële wereld), of juist wachten tot 1 januari 2002 (te verwachten bij een groot deel van het mkb). Bij veel middelgrote bedrijven zal sprake zijn van een tussenvorm: bijvoorbeeld de factureringssystemen reeds in een vroeg stadium overzetten, maar met de salarisadministratie wachten tot het laatste moment. Uiteraard moet hierbij goed gelet worden op de interfaces tussen systemen, en moet zonodig voor een tijdelijke conversie worden gezorgd.
Het ‘optimale’ scenario is voor elk bedrijf anders. Het is afhankelijk van factoren als: de wensen van de belangrijkste leveranciers en klanten, de kosten en beheersbaarheid, de samenhang tussen systemen, en de beschikbare menskracht.
Leveranciers
Bij software die niet in eigen beheer is gebouwd, zoals pakketten en maatwerk verricht door derden, moeten bedrijven nagaan of de leverancier tijdig met een euro-update komt. Met name bij kleinere leveranciers bestaat het risico dat de oplossing niet op tijd beschikbaar is; bedrijven moeten zonodig tijdig naar alternatieven zoeken. Indien een euro-update wel tijdig beschikbaar komt, moet worden nagegaan wat de kosten zijn, en of de euro-aanpassing onder het onderhoudscontract valt.
In het geval van standaardpakketten kunnen klanten wellicht de krachten bundelen in een gebruikersgroep of inkoopcombinatie om druk uit te oefenen op de leverancier of om de kosten te delen.
Tevens zouden bedrijven van elk nog nieuw aan te schaffen systeem vooraf moeten nagaan of het voldoet aan alle euro- en ‘jaar 2000’-eisen.
Naar verwachting komt zeker 60 procent van de kosten van een euro-programma voor rekening van de IT. Door het overlappen van het euro- en het millennium-probleem zal de komende jaren de vraag naar ervaren automatiseerders het aanbod sterk overtreffen. Bedrijven moeten daarom nu reeds nagaan of voldoende automatiseerders met de juiste vaardigheden intern voorhanden zijn, rekening houdend met te voorziene werving en verloop. Elk bedrijf moet zich afvragen met welke financiële en niet-financiële middelen het deze medewerkers voor langere tijd aan zich kan binden, en of eventuele tekorten zijn op te vangen met behulp van externe krachten. Daarbij moet men zich ervan bewust zijn dat dit probleem speelt binnen vrijwel alle organisaties!
Aandachtspunten
Bij de euro-conversie moet aan enkele zaken speciale aandacht worden besteed. Allereerst is daar het probleem van de ‘harde’ coderingen. In veel programma’s zijn vaste valutaverwijzingen als ‘NLG’ en ‘HFL’ opgenomen; deze zullen moeten worden vervangen door ‘EUR’, de ISO-aanduiding voor de euro (wellicht kan die aanduiding in één moeite door worden geparametriseerd). Ook vaste drempelbedragen zullen moeten worden aangepast: als verpakkings- en verzendkosten worden gevraagd bij bestellingen onder de tien gulden, dan moet dat laatste bedrag natuurlijk worden omgezet in het overeenkomstige euro-bedrag. Dit punt speelt bijvoorbeeld in België nog sterker dan in Nederland: honderd frank is iets héél anders dan honderd euro!)
Ook historische bestanden zullen moeten worden geconverteerd, opdat vergelijkingen met het verleden mogelijk blijven. Bedrijven zullen moeten besluiten hoeveel jaar ze hierbij terug willen gaan. Het is verstandig om geconverteerde bestanden duidelijk als euro-bestand te identificeren (met een expliciete valuta-indicatie in het bestand, of via de naam van het bestand), om verwarring op een later tijdstip te voorkomen.
Ook moet goed gekeken worden welke koers gebruikt wordt voor het omzetten van buitenlandse muntsoorten. Stel dat een Nederlands bedrijf een Duitse dochter heeft die jaarlijks precies honderdduizend mark omzet. Als gevolg van wisselkoersschommelingen komt dit bijvoorbeeld het ene jaar overeen met 90.000 gulden, het volgende jaar met 110.000 gulden, en het laatste jaar met 100.000 gulden. Om de historische gegevens vergelijkbaar te houden, zou het Nederlandse bedrijf de Duitse omzet steeds eerst moeten omrekenen naar guldens (de basisvaluta binnen het bedrijf), zoals voorheen is gedaan, en vervolgens de bedragen in guldens moeten omrekenen naar euro’s op basis van de wisselkoers die volgend jaar zal worden vastgesteld.
Voor spreadsheets en soortgelijke applicaties is haast nooit fatsoenlijke documentatie voorhanden, en bij het bouwen worden zelden standaarden in acht genomen. Als gevolg daarvan is het vrijwel onmogelijk om geautomatiseerde conversiehulpmiddelen voor dit soort toepassingen te ontwikkelen. Binnen veel bedrijven spelen ze echter een belangrijke rol bij het ondersteunen van beslissingen, zodat ze toch in een euro-versie beschikbaar moeten komen. Vanwege hun complexiteit zal het vaak eenvoudiger zijn om spreadsheets geheel opnieuw te ontwikkelen dan om ze te converteren. Hun grote aantal vormt hierbij een extra probleem. Bovendien hoeven de oorspronkelijke makers niet meer bij het bedrijf werkzaam te zijn.
Driehoeksberekening
Wettelijk is vastgelegd dat de wisselkoersen van de euro naar de verschillende nationale muntsoorten steeds zes significante cijfers zullen bevatten. Eén euro zou bijvoorbeeld gelijk kunnen zijn aan NLG 2.19181. Om van guldens naar euro’s te gaan, moet dan gedeeld worden door 2,19181; het is niet toegestaan om de inverse daarvan te nemen (met zes significante cijfers: 0,456244) en daar mee te vermenigvuldigen. Honderdduizend gulden is in dit voorbeeld dus gelijk aan (100.000/2,19181 =) 45.624,39 euro, en niet aan (100.000 * 0,456244 =) 45.624,40 euro.
Ook voor het converteren van de ene nationale valuta naar de andere bestaan voorschriften. In zo’n geval moet een ‘driehoeksberekening’ worden toegepast: eerst omrekenen van bijvoorbeeld Franse franc naar euro, en vervolgens van euro naar gulden. Het is niet toegestaan om direct een ‘cross rate’ van de Franse franc naar de gulden te gebruiken, tenzij dit, zo zeggen de voorschriften, hetzelfde resultaat zou geven. Dat zou bijvoorbeeld het geval kunnen zijn als die ‘cross rate’ voldoende significante cijfers zou bevatten; maar het is waarschijnlijk in de meeste gevallen eenvoudiger, en altijd veiliger, om steeds de voorgeschreven methode te gebruiken.
Door het correct navolgen van deze voorschriften kan een bepaalde klasse van afrondingsfouten worden vermeden; er blijven echter situaties waarin afrondingsproblemen onvermijdelijk zijn. Dit kan met name het geval zijn als bedragen herhaaldelijk moeten worden omgerekend van de nationale muntsoort naar euro en terug. Ook bij het optellen van een groot aantal deelbedragen kan de som van de geconverteerde bedragen ongelijk zijn aan de conversie van de originele som. Hoewel dergelijke verschillen zoals gezegd onvermijdelijk zijn, is het van belang om ze te identificeren en vooraf te besluiten wat er mee moet gebeuren (bijvoorbeeld: wegboeken naar een speciale verschillenrekening). Indien het werkelijk nodig is om de afrondingsverschillen zo klein mogelijk te houden, kan een bedrijf ervoor kiezen om alle bedragen vast te leggen in zowel de nationale muntsoort als in de euro, en bij berekeningen steeds de oorspronkelijke valuta te gebruiken. Zoals we nog zullen zien, is deze oplossing echter ingrijpender en kostbaarder dan alternatieve oplossingen.
Conversiemogelijkheden
‘Multicurrency’-systemen kunnen betrekkelijk eenvoudig overschakelen op de euro. Voor het aanpassen van systemen van het type ‘non’- en ‘monocurrency’ bestaan verschillende mogelijkheden. De belangrijkste hiervan zijn: de ‘Big Bang-conversie’, het tussenvoegen van schillen, het gebruik van een ‘converter’, en het uitbreiden van de database.
Bij een ‘Big Bang-conversie’ worden eenmalig alle valutavelden in de database omgezet van guldens naar euro’s. Een veld dat een waarde van ‘100,00’ [gulden] bevat, krijgt bijvoorbeeld een nieuwe waarde van ‘45,62’ [euro], bij een hypothetische koers van fl. 2.19181 per euro. Een dergelijke conversie is betrekkelijk eenvoudig uit te voeren, maar heeft als nadeel dat slechts één muntsoort tegelijk wordt ondersteund: guldens voor de conversie, en euro’s erna. Voor sommige bedrijven kan dit toch een goede oplossing zijn, aangezien de banken binnenkomende bedragen in guldens op een euro-rekening automatisch en zonder kosten zullen converteren.
Bij een oplossing met behulp van schillen blijven de applicaties zelf ongewijzigd, maar er komt tijdelijk een ‘schil’ omheen die in- en uitvoer zonodig vertaalt naar de muntsoort die gebruikt wordt door de applicatie. De meest voor de hand liggende oplossing hierbij is om applicaties en gegevens reeds in een vroeg stadium te converteren naar de euro, en de schillen te gebruiken voor de tijdelijke omzetting van bedragen in guldens tijdens de overgangsperiode. Bij deze oplossing zijn in die periode zowel de nationale muntsoort als de euro te verwerken.
Een ‘converter’ is een centrale module die zorgt voor de omzetting van de ene muntsoort in de andere, en die wordt aangeroepen op alle plaatsen waar moet worden omgerekend. Bij deze oplossing worden de applicaties zelf dus wél aangepast.
Bij het uitbreiden van de database tenslotte wordt aan elk valutaveld een euro-veld toegevoegd waarin het corresponderende euro-bedrag komt te staan. Om afrondingsfouten zo klein mogelijk te houden kan nog een extra veld worden toegevoegd, waarin wordt bijgehouden wat de oorspronkelijke valuta was. Berekeningen worden dan eerst uitgevoerd in de oorspronkelijke muntsoort, en pas daarna omgerekend naar de andere. Deze oplossing is het meest flexibel, maar vergt ingrijpende aanpassingen van zowel databases als programma’s, en is daarom verreweg het kostbaarst. In feite wordt zo een soort ‘multicurrency-systeem met meerdere basisvaluta’s’ gecreëerd!
Geautomatiseerde hulpmiddelen
Voor de aanpak van het euro-probleem is tot op zekere hoogte gebruik te maken van geautomatiseerde hulpmiddelen die veelal oorspronkelijk werden ontwikkeld voor de aanpak van het millennium-probleem.
Met ‘scan’- en ‘parse’-programma’s kunnen valutavelden in programma’s worden geïdentificeerd en (eventueel van systeem tot systeem) gevolgd.
Database-converters zijn te gebruiken om euro-velden aan een database toe te voegen en te vullen, of om valutavelden om te zetten in hun euro-equivalent bij een ‘Big Bang-conversie’.
Met test-tools zijn op systematische wijze de juistheid en de volledigheid van de gemaakte aanpassingen na te gaan.
Dit zijn overigens slechts hulpmiddelen, en niet meer dan dat: ze zullen het euro-probleem nooit volledig kunnen oplossen voor een bedrijf. Voor decentrale applicaties als spreadsheets zullen wellicht zelfs helemaal geen hulpmiddelen beschikbaar komen.
Er zijn nog maar weinig bedrijven die een euro-programma hebben uitgevoerd, en ervaringscijfers zijn daarom nauwelijks voorhanden. Wellicht kunnen de schattingen van de Gartner Group met betrekking tot het ‘jaar 2000’-probleem een eerste indruk geven: dit onderzoeksbureau schat dat de kosten daar tussen de een en twee dollar per regel broncode (Cobol) liggen. De werkelijke IT-kosten bij het euro-probleem hangen ook af van de gekozen aanpak: een ‘Big Bang-conversie’ zal normaal gesproken goedkoper zijn dan een wijziging van de database-structuur. Helaas zal een dergelijke conversie niet voor elk bedrijf als oplossing voldoen.
Knelpunten
Nu reeds zijn enkele knelpunten aan te geven die bij de meeste euro-programma’s aan het licht zullen komen.
Allereerst is daar het probleem van de ouderdom. Veel systemen zijn al meer dan tien jaar in gebruik, en hun documentatie en specificaties, voor zover nog aanwezig, zijn niet meer ‘up to date’. De oorspronkelijke ontwerpers en bouwers werken allang niet meer bij het bedrijf. Wellicht zijn zelfs nergens meer deskundigen te vinden die ervaring hebben met de gebruikte programmeertalen en databases. Voor dergelijke systemen is aanpassen nauwelijks een optie.
Het vorige knelpunt doet zich ook voor bij het millennium-probleem. Bij de euro is bovendien sprake van een functioneel probleem, zodat ook de inzet van deskundige gebruikers vereist is.
Als gevolg van het euro- en het millennium-probleem zal er de komende jaren een enorme vraag naar automatiseringsdeskundigen zijn. Bovendien hebben de beide problemen een gemeenschappelijke karakteristiek die voor automatiseringsprojecten tamelijk uniek is: de ‘harde’ einddatum is in dit geval ook werkelijk hard! En tot overmaat van ramp zal het mislukken van een euro-of millennium-programma voor de meeste bedrijven rampzalige gevolgen hebben. Hierdoor zullen enerzijds de uurtarieven in de IT tot ongekende hoogten kunnen stijgen, maar anderzijds kunnen automatiseringsbedrijven worden geconfronteerd met ingrijpende aansprakelijkheidsclaims.
Hieraan gerelateerd, zij het wat minder dramatisch, zijn de consequenties voor anderssoortige (functionele) systeemaanpassingen: het tekort aan automatiseringsdeskundigen in de komende jaren zal veel bedrijven ertoe brengen om dergelijke aanpassingen uit te stellen. Als gevolg hiervan zullen veel systemen na het afsluiten van de euro-operatie wellicht alweer functioneel verouderd zijn, zodat een inhaalslag moet plaatsvinden.
Drs. Marcel Feenstra, Mald Mba, European Consulting Group, American Management Systems te Den Haag.
Literatuur
Gedetailleerde informatie over veel van de onderwerpen uit dit artikel is te vinden in Exposure Draft: Preparing Information Systems for the Euro van Pieter Dekker (Europese Commissie, DG XV). Dit paper kan men downloaden van http://www.cordis.lu/esprit/src/y2keuro.htm.
Verdere informatie over de gevolgen van de introductie van de euro is ondermeer te vinden op de website van de Association for the Monetary Union of Europe (http://amue.lf.net) en de sites van de grote banken (zoals http://www.abnamro.nl/euro/index.html en http://www.rabobank.nl/).
