De euro wordt steeds minder waard ten opzichte van de dollar. Toch zal de euro binnenkort voor elke organisatie binnen de EMU de valuta zijn waarin gerekend moet worden. In een eerder artikel werd de euroconversie binnen een SAP-omgeving belicht. Nu zetten consultants Wouter-Bas van der Vegt en Marc Schmitz uiteen hoe risico’s te vermijden zijn bij een gefaseerde aanpak binnen Oracle Financials-systemen.
De euro biedt verschillende ‘uitdagingen’ en mogelijkheden. Zo zal er voor marketing, verkoop en logistieke afdelingen meer transparantie in de markt ontstaan. Een betere mogelijkheid tot het vergelijken van prijzen kan leiden tot sterkere merken en meer inzicht in de prijsstrategieën van concurrenten. De euro zal ook positieve gevolgen hebben voor de afdelingen productie en inkoop omdat de transparantie van prijzen in de toekomst waarschijnlijk zal leiden tot lagere kosten en productdifferentiatie. Bovendien biedt de euro het financieel management en de boekhouding de mogelijkheid om budgetten, prognoses, rapportages en rekeningen in dezelfde valuta vast te stellen. Interne en externe transacties kunnen plaatsvinden in euro en de resultaten van verschillende business-units in EMU-landen kunnen eenvoudiger vergeleken worden. Dat geldt ook voor kosten en winstgevendheid, als gevolg van vestiging in verschillende landen op grond van fiscale en juridische motieven. Zo kan het fiscaal aantrekkelijk zijn om een ‘shared service center’ in een specifiek EMU-land te vestigen.
Het komt altijd ongelegen
Een weloverwogen bepaling van het tijdstip voor de euroconversie zal het realiseren van de bovenstaande mogelijkheden ten goede komen. Er kan een keuze worden gemaakt tussen een euroconversie aan het einde van het boekjaar of op een willekeurige datum gedurende het jaar.
Het uitvoeren van de conversie aan het einde van het boekjaar heeft als voordeel dat de balans reeds is afgesloten, waardoor het eenvoudiger is om conversieresultaten te controleren. Verder kan het lopende jaar als testfase worden gebruikt en kan de balans het nieuwe jaar in euro’s worden geopend. Voor de eerste keer zal dan officieel in euro’s gerapporteerd worden. Wel moet rekening gehouden worden met de conversie van openstaande posten die betrekking hebben op lopende transacties. Een nadeel is dat het einde van het boekjaar binnen de meeste organisaties geldt als een drukke periode voor de financiële administratie.
Als de conversie gedurende het boekjaar plaatsvindt, kunnen de euroconversieactiviteiten gepland worden op een moment dat er minder bedrijvigheid is. Het is echter aan te raden de euroconversie gedurende de eerste maanden van het boekjaar te laten plaatsvinden, aangezien de hoeveelheid om te zetten transacties gedurende het boekjaar blijft toenemen. De totale hoeveelheid te converteren data neemt daardoor ook steeds toe.
Gefaseerd of ‘big bang’
De euroconversie kan globaal op twee manieren worden ingericht: gefaseerd en volgens de ‘big bang’-strategie. Fasering maakt een flexibeler opzet van de euroconversie van Oracle- en andersoortige systemen mogelijk. Een gefaseerde conversie is complex, en omdat deze over een langere periode loopt, moet er veel aandacht worden besteed aan de organisatie en de beheersing van het project. Verder zal het (financiële) systeem meerdere malen buiten bedrijf zijn, hoewel steeds van korte duur (korter dan een dag). Daarnaast bestaat er het risico van inconsistentie van het (financiële) systeem vanwege de getraptheid van het traject.
Het alternatief is de ‘big bang’-strategie. Feitelijk is dit een gefaseerde euroconversie die daarentegen over een heel korte tijdspanne wordt uitgevoerd. Ook is het een manier van converteren die snel duidelijkheid oplevert. Daarnaast is het risico van inconsistentie van het (financiële) systeem minder groot dan bij een gefaseerde overgang. Daarom is deze methode het best te gebruiken, wanneer binnen een organisatie in sterke mate sprake is van een vervlechting van verschillende systemen. Er zal echter wel een grote behoefte zijn aan systeem-resources op het conversiemoment, zoals rekencapaciteit op de server, waardoor het systeem meerdere dagen niet of niet volledig beschikbaar zal zijn. Binnen grotere organisaties zal dit niet zelden een grote impact hebben op de bedrijfsprocessen.
MRC-tool
Oracle zelf acht voor grotere, complexere organisaties een gefaseerde conversie het meest opportuun (Oracle Financials, The Euro’s Impact on Business and Financial Systems, 1999). Een ‘big bang’-conversie is waarschijnlijk ook mogelijk. Als gevolg van een ‘big bang’ kunnen echter onderdelen van de organisatie tijdelijk stil komen te liggen. Indien voor een ‘big bang’ gekozen wordt, zal een euroconversie gedurende het boekjaar waarschijnlijk de minste problemen opleveren. Er zijn echter ook tussenvormen mogelijk waarbij bepaalde fases dichterbij of verder van elkaar liggen.
Oracle heeft onder andere vanwege de euro Release 11 ontwikkeld. Release 10.7 bood weliswaar reeds tijdelijk de mogelijkheid om te werken met de euro als transactievaluta, maar de Multiple Reporting Currency tool (MRC) die nodig is om Oracle Financials euro-proof te maken, was pas vanaf Release 11 beschikbaar (mei 1998).
De MRC-tool maakt de realisatie van extra rapportageboeken mogelijk in valuta ongelijk aan de huisvaluta. Daarnaast kun je met MRC parallel boekhoudingen voeren in verschillende valuta, bijvoorbeeld de gulden en de euro. Deze functionaliteit is nodig voor de fase van dubbele valuta. Verder voorziet het in de vervulling van de wettelijke verplichtingen met betrekking tot de euroconversie. De koersomrekening moet namelijk uitgevoerd worden volgens fiscale en handelsrechtelijke voorschriften (koersfixatie, geen inverse koers, triangulatie, enzovoort). Er duikt echter een probleem op. Door de gefixeerde koersomrekeningsregels en vanwege een koers met meerdere cijfers achter de komma (Eur 1 = Nlg 2,20371) ontstaan per definitie afrondingsverschillen tussen de som van de individueel geconverteerde posten en de geconverteerde totalen. Het afstemmen van het parallel gebruik van gulden en euro en correcties bij de euroconversie zijn in dit kader dan ook belangrijk.
‘Upgrades’
De volgende organisaties hebben de MRC-tool (waarschijnlijk) nodig:
- Organisaties binnen de EMU, die graag hun verslaggeving (zowel extern als intern) willen doen in zowel hun functionele valuta (bijvoorbeeld NLG), als in de euro;
- Multinationals, die in meerdere valuta financieel verslag moeten uitbrengen;
- Organisaties in landen met een hoge inflatie, zodat de verslaggeving kan plaatsvinden in een sterke, stabiele valuta. Ook hier wordt weer een aparte rapportagevaluta naast de functionele valuta gebruikt.
Hoewel de euroconversie met behulp van MRC pas vanaf Release 11 wordt ondersteund, is het gebruik van de euro als transactievaluta wel mogelijk voor versies voorafgaand aan Release 11.
Om de euroconversie in Release 11 goed te laten verlopen zijn de volgende upgrade-pakketten nodig: 11.0.1: FA 11.0.2 maintenance pack (733163); MRC Transactions Upgrade Mini-Pack (740124); 11.0.2: MRC Transactions Upgrade Mini-Pack (740124), en 11.0.3: Post MRC 11.0.3 mini pack (797753).
Daarnaast wordt altijd het Euro Enhancements Summer 1999 Mini-Pack (912631) aangeraden, dat extra functionaliteit bevat voor Accounts Receivable.
In Release 10.7 en eerder kunnen echter wel euro-boekhoudingen worden gedefinieerd. Daarvoor moeten de ‘normale’ Oracle-functionaliteiten voor het opzetten van rekeningen, rekeningen voor de openingsbalans en de definitie van de primaire valuta worden gebruikt. Wie voor deze oplossing kiest, heeft dus niet de beschikking over de logica voor omrekening en boeking van de afrondingsverschillen waarbij rekening is gehouden met de wettelijke verplichtingen rond de euroconversie. Oracle raadt deze handelswijze derhalve niet aan. Een upgrade van 10.7 (de laatste versie vóór de volledig ondersteunde euro versie) naar 11 kost volgens Oracle circa twintig dagen, afhankelijk van de omvang en complexiteit van het systeem.
Voorts beschikt men bij Oracle over zogenaamde EFC-Utilities. Deze zorgen ervoor dat in euro gevoerde boekhoudingen als primaire rekeningen worden gedefinieerd. Alle Oracle-gegevens die in het kader van de dubbele valuta fase nog niet geconverteerd zijn, moeten geconverteerd worden. Dit zal uiteindelijk resulteren in het afsluiten van de dubbele valuta fase (uiterlijk op 1-1-2002) – een onomkeerbaar proces.
Drie fases
De eerder genoemde gefaseerde euroconversie bestaat uit drie fases. Tijdens de eerste fase is de gulden de boekhoudkundige valuta; de euro kan als transactievaluta gebruikt worden. In de tweede fase kan Oracle Applications stapsgewijs voor de euro worden ingericht. De volledige overgang naar de euro als huisvaluta vindt plaats gedurende de derde fase.
Naast het doorlopen van deze drie fases dient er ook voorbereidingstijd ingeruimd te worden voor het samenstellen van een euro-projectteam en het opzetten van een projectplan. Ook zal achteraf nog een aantal activiteiten moeten worden uitgevoerd om de euroconversie af te ronden.
Fase 1: Initialisatie MRC. De eerste stap is het inrichten van een extra set rapportageboeken in euro, zowel voor het grootboek als de subboeken.
De openingsbalans moet worden opgezet in het euro-grootboek. Eventueel dient de historie voor euro-grootboek teruggerekend te worden. Transacties in euro-subboeken moeten voor een configureerbare historie-tijdspanne gerealiseerd worden.
Bij de activering van MRC wordt een nieuw grootboek met een openingsbalans in euro opgezet, gegenereerd uit de actuele stand van het grootboek in guldens. In de sub-grootboeken worden eveneens de open posten geconverteerd. De andere posten kunnen tot een te configureren tijdstip in het verleden worden overgenomen.
In aansluiting hierop volgt een reconciliatie tussen de nieuwe en oude grootboeken en sub-grootboeken, als ook tussen de grootboeken en sub-grootboeken in de gestandaardiseerde valuta. De conversie van de historie van het grootboek is facultatief. Afhankelijk van het conversiescenario kan het aanvangstijdstip voor de conversie van de historie van het grootboek ver in het verleden worden gelegd of zeer kort terug in de tijd, bijvoorbeeld op de eerste dag van fase 1. Als voor een tijdstip verder in het verleden wordt gekozen, zal het systeem in fase 1 langere tijd niet beschikbaar zijn. Wordt voor een tijdstip minder ver in het verleden gekozen, dan zal het systeem in fase 3 aanmerkelijk langer niet beschikbaar zijn.
Als de historieconversie volledig wordt uitgevoerd in fase 3, dan is er feitelijk sprake van een ‘big bang’-scenario. De conversie van de sub-grootboeken van vóór 01-01-1999 kan op basis van een variabele of een vaste omrekenkoers plaatsvinden. In het geval van een variabele koers blijft alle historie zowel in guldens als in euro bewaard. In het geval van een vaste wisselkoers wordt alle historie (of dat deel van de historie dat geconverteerd wordt) vanaf dat moment in euro bewaard en is de historie niet meer in guldens beschikbaar. De conversie van het grootboek moet altijd gebeuren middels triangulatie met behulp van de vaste omrekenkoers.
Fase 2: MRC operationeel. Boekingen verlopen automatisch parallel in de primaire- en rapportageboeken. Gegevens zijn in beide valuta direct beschikbaar. Het euro-grootboek is volledig operationeel, waarbij rapportages in guldens en euro’s mogelijk zijn. Andere systemen kunnen in euro’s gegevens aanleveren en extra historische gegevens kunnen in de achtergrond worden geconverteerd.
Door het gebruik van parallelle grootboeken wordt een verdubbeling van de gegevenshoeveelheid vermeden, omdat alleen de benodigde velden uit de sub-grootboeken extra in euro opgeslagen worden. Volgens Oracle is voor de sub-grootboeken – afhankelijk van de applicatie -10 tot 50 procent extra opslagcapaciteit nodig. Hierdoor is er volgens Oracle hoegenaamd geen prestatieverlies in geval van twee parallelle sets boeken.
Fase 3: Euro als functionele valuta. De volledige historie van sub-grootboeken wordt in deze fase naar euro’s geconverteerd. Gegevens die euro-gerelateerd zijn en nog niet geconverteerd (zoals gegevens uit onderdelen die niet door MRC worden ondersteund – bijvoorbeeld Inventaris en Human Resources), moeten geconverteerd worden. De euro wordt als primaire valuta gedefinieerd. Vervolgens zijn de gegevens in de nationale valuta te verwijderen (natuurlijk nadat een back-up gemaakt is). Op deze wijze wordt een correcte afsluiting van de dubbele-valutafase bewerkstelligd.
In de afrondingsfase worden Oracle-controlescripts uitgevoerd en rapportages gegenereerd, om de correcte conversie te bevestigen. De tijdens de conversie aangelegde tijdelijke tabellen kunnen worden verwijderd. Tevens kan de National Currency Unit Set of Books (NCU-SoB’s) verwijderd worden. Wel dient hierbij rekening te worden gehouden met bewaartermijnen.
Risico’s
Er is een aantal risico’s te onderscheiden als gevolg van een niet correct verlopen of mislukte euroconversie. De onderstaande opsomming geeft een grove verdeling in drie groepen.
Allereerst zijn er de risico’s die betrekking hebben op de omgevingsfactoren. Als er geen organisatiebrede planning is gemaakt en er geen (internationale) afstemming van de euroconversie heeft plaatsgevonden, dan kan dit leiden tot problemen bij de consolidatie van de jaarrekening en is het minder goed mogelijk om de financiële prestaties van de verschillende organisaties te vergelijken. Bij organisaties met vestigingen in meerdere landen kan zich het probleem voordoen dat op detailniveau de wettelijke verplichtingen per deelnemend EMU-land verschillen, waardoor coördinatie nodig is binnen Europa. Er zijn bovendien (per land) allerlei (wettelijke) documentatievoorschriften waaraan voldaan moet worden. Ook zal men rekening moeten houden met klanten en leveranciers, en moet men dus afwegen hoe hiermee wordt omgegaan gedurende de conversieperiode (wanneer wordt in guldens en wanneer in euro’s gecommuniceerd?). Er dient tevens afstemming plaats te vinden met de betrokken openbare instellingen, zoals de belastingdienst en de sociale verzekeringsinstellingen, voor een effectieve interne communicatie en voor de coördinatie van de benodigde voorbereidingsmaatregelen.
Vervolgens zijn er meerdere risico’s op projectmanagementniveau te identificeren. Het tijdstip en de complexiteit van de geplande conversiescenario’s zullen een grote invloed hebben op het project, zeker gezien de korte tijdspanne die nog beschikbaar is. Het verkrijgen van de benodigde resources, zowel intern als extern, zal veel moeite vergen. In dat kader zullen ook de benodigde medewerkers moeten worden geworven, dan wel aanwezige medewerkers moeten worden opgeleid. Ook de coördinatie van de bijkomende afstemmingsactiviteiten tijdens de parallelle fase, zoals bijvoorbeeld de interfaces met legacy-systemen, is een belangrijk onderdeel dat niet mag worden vergeten. Er zal rekening moeten worden gehouden met het realiseren van voldoende back-up faciliteiten en bijbehorende procedures. Hierbij dienen alle afdelingen en dochterondernemingen betrokken te zijn. In het projectplan moet ook een ‘contingency’-plan opgenomen worden dat herstartscenario’s bevat met betrekking tot het opnieuw uitvoeren van het inrichten van MRC en EFC. Een eventuele ‘upgrade’ naar Release 11 moet ook worden gepland.
Door middel van doortastend projectmanagement zijn de risico’s, verbonden aan het euroconversieproject, op tijd te ondervangen. Daarom is het goed voorbereiden en plannen van de euroconversie de eerste prioriteit. Mochten hierbij bepaalde zaken over het hoofd worden gezien, dan zal dit leiden tot extra inspanning om alsnog te realiseren dat de euroconversie het gewenste resultaat oplevert. Voor de verschillende aandachtsgebieden binnen het project dienen oplossingen geïmplementeerd te worden, rekening houdend met mensen, processen en technische componenten. Voorbeelden van deze aandachtsgebieden zijn management van integratie, reikwijdte, tijd, kosten, kwaliteit, mensen, communicatie en risico’s.
De laatste groep risicofactoren betreft de technische kant. Er dient rekening te worden gehouden met specifiek voor de organisatie aangebrachte wijzigingen in het systeem, waarbij zelf ontwikkelde onderdelen niet buiten beschouwing mogen blijven. Interfaces met andere systemen verdienen extra aandacht. Er moet worden voorzien in voldoende technische capaciteit, zoals opslagruimte en ‘performance’, waarbij duidelijk moet zijn hoeveel systeemuitvaltijd eventueel acceptabel is.
Auditor
Al deze factoren kunnen tot gevolg hebben dat de euroconversie faalt. Hierdoor zullen bedrijfsprocessen ernstig in gevaar komen en zullen rapportages fouten bevatten, ontbreken of verlaat zijn. Door een mislukte conversie zullen ook ongeplande extra kosten opdoemen en kunnen er capaciteitsproblemen optreden. Het is evident dat het voorkomen van deze zaken een soepele overgang naar de euro zal bespoedigen. Hiertoe moeten meerdere controles ingebouwd worden. Verder zal duidelijk moeten worden gerapporteerd of deze controles hebben plaatsgevonden en wat daar de resultaten van zijn geweest. Achteraf zal nogmaals gecontroleerd moeten worden of bepaalde risico’s zich niet toch hebben voorgedaan. Daarom zijn uitgebreide tests noodzakelijk, zowel tijdens het conversieproces als achteraf. De risico’s van dit bijzondere project kunnen alleen worden uitgesloten door een testprocedure op meerdere niveaus in de aanloop naar implementatie, en door het uitvoeren van module-, integratie- en stresstesten.
Het is algemeen bekend dat een groot deel van IT-gerelateerde projecten uiteindelijk niet leiden tot het gewenste resultaat.
Vanwege de hoge complexiteit zal het onwaarschijnlijk zijn dat het complete omschakelingsproces zonder professionele sturing en advies succesvol verloopt. Velen zullen deze hordes slechts succesvol kunnen nemen met hulp van een auditor met voldoende vaardigheden op alle gebieden. Te denken valt aan ervaring met projectmanagement, kennis van Oracle met betrekking tot de euroconversie en de bekwaamheid een controlesysteem te bouwen om risico’s van alle beschrijvingen te minimaliseren. Voor veel Oracle-gebruikers en ook gebruikers van andere erp-pakketten gaat de tijd behoorlijk dringen, dus het ondernemen van actie is noodzaak voor een juiste en probleemloze euroconversie!
Wouter-bas Van Der Vegt Marc Schmitz Consultants Arthur Andersen Technology Risk Consulting