Treasurymanagementsystemen

Treasurymanagementsystemen

I3100^1

Treasurymanagementsystemen Drs. R.Ch.T. Ewals1

1 2 3 3.1 3.2 3.3 3.4 3.5 3.5.1 3.5.2 3.6

1

Inleiding Ontwikkelingen van treasurymanagementsystemen Elementen van standard treasurymanagementsystemen Trademanagement Financie«le instrumenten Operations Cash management Risk management Market risk management Credit risk management Accounting

I3100^ 3 I3100^ 3 I3100^ I3100^ I3100^ I3100^ I3100^ I3100^ I3100^ I3100^ I3100^

4 5 6 6 7 8 8 9 9

De heer drs. R.Ch.T. Ewals is als Senior Manager werkzaam bij PricewaterhouseCoopers op het gebied van Treasury and Risk Management systemen. Zijn werkzaamheden omvatten het adviseren aan en ondersteunen van clie«nten bij vraagstukken als systeemselectie, implementatie van systemen, ontwikkeling van marktrisico- en kredietrisicomodellen, veri¢catie van modellen alsmede het uitvoeren van audits op implementaties en inrichting van de treasuryorganisatie.

26 Hb. Treasury

3B2/SGML {3b2}Losbladigen/HB_ Treasury/Supplement_26/I3100 pagina 1 van 18

juni 2004

Proefpagina: 0001

I3100^2


3.7 3.8 3.8.1 3.8.2 3.8.3 3.9 4 4.1 4.2 4.3 4.4 5 6

Reporting Beveiliging Applicatiebeveiliging Transport van gegevens Databasebeveiliging Technische standaarden Selectie en implementatie van een systeem De¢nie«ren bedrijfsmodel De selectie De implementatie De postimplementatie Marktontwikkelingen Naslagwerken

26 Hb. Treasury


I3100^ 10 I3100^ 10 I3100^ 10 I3100^ 11 I3100^ 11 I3100^ 12 I3100^ 13 I3100^ 13 I3100^ 14 I3100^ 14 I3100^ 15 I3100^ 15 I3100^ 18

juni 2004

Proefpagina: 0001


1

I3100^3

Inleiding

De markt voor treasurymanagementsystemen is in de late jaren negentig enorm gegroeid en heeft inmiddels een behoorlijk niveau van volwassenheid bereikt. De functionaliteit van deze systemen is, mede onder druk van concurrentie, enorm toegenomen en de kwaliteit van de functies als gevolg daarvan ook. Dat gezegd hebbende, blijken leveranciers van treasurymanagementsystemen toch in voorkomende gevallen minder oog voor de precieze wensen van hun clie«nt te hebben alsmede voor de taken en functies van de treasury-afdeling die een systeem wil gaan gebruiken. Daardoor kunnen bijvoorbeeld pogingen van treasurers om een grotere e⁄ci e«ntie te bereiken, moeilijk haalbaar blijken indien een systeem wordt aangeschaft en ge|« mplementeerd, dat niet volledig aan de gewenste vereisten voldoet. Moderne treasurymanagementsystemen hebben een rijkheid aan functionaliteiten, die in veel situaties de feitelijke vereisten van een corporate treasury overstijgen. In dit artikel worden eerst de meest voorkomende functionaliteiten binnen treasurymanagementsystemen beknopt besproken. Hierbij wordt overigens impliciet ervan uitgegaan, dat bedrijven een systeem kopen en implementeren en niet zelf een eigen systeem ontwikkelen. Vervolgens wordt ingegaan op de stappen die een treasury zou moeten doorlopen om een geschikt systeem te kiezen. Tot slot wordt beknopt ingegaan op een aantal belangrijke ontwikkelingen, waarbij aandacht bestaat voor de zienswijze van zowel de treasurers zelf als de systeemleveranciers.

2

Ontwikkelingen van treasurymanagementsystemen

De ontwikkelingen van treasurymanagementsystemen zijn de afgelopen jaren gelijk opgegaan met ontwikkelingen gericht op de veranderende aandachtsgebieden van de treasurer. Dit betreft zowel externe als interne ontwikkelingen. Belangrijke extern gedreven ontwikkelingen hierin voor de treasurer zijn onder meer: ^ verwereldlijking van het speelveld (globalisation). Mede door fusies en overnames hebben bedrijven steeds meer aandacht voor de ¢nancie«le functie, waaronder treasury, als een geheel, dan wel meerdere elementen, die optimaal moeten samenwerken. Er is een grotere ¢nancieringsbehoefte en grotere exposure ten opzichte van bepaalde risico’s, zoals valutaschommelingen. De wereld is het speelveld geworden; ^ wijzigingen in de regelgeving. De belangrijkste stimulansen hiervoor zijn gevonden in de regelgeving omtrent FAS133, gevolgd door IFRS 39 en nog recenter, Sarbanes Oxley; ^ ontwikkelingen in technische mogelijkheden. Door technische

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^4


innovaties, zoals de uiterst snelle ontwikkeling in het wereldwijde gebruik van het internet (web based modules) en de mogelijkheden van elektronische beurzen (zoals FXall), geven de treasurer mogelijkheden om sneller en preciezer in te spelen op zijn behoeften; ^ nieuwe instrumenten. Door met name de ¢nancie«le instellingen zijn nieuwe ¢nancie«le instrumenten ‘bedacht’, die de corporate treasurer nieuwe mogelijkheden geven om bijvoorbeeld zijn risk management nog beter in te richten. Naast de externe ontwikkelingen hebben ook interne ontwikkelingen invloed gehad op de treasurer. Voorbeelden daarvan zijn: ^ snellere en e¡ectievere rapportages: rapportages ten behoeve van het hoger management moeten sneller tot stand komen en met meer details. Daarnaast bestaan meer ad-hocvragen waarover moet worden gerapporteerd; ^ consolidatie en stroomlijnen van ¢nancie«le structuren: zowel organisatorisch als ¢nancieel worden processen en hie«rarchische ketens steeds meer centraal aangestuurd, zodat lokale ¢nancie«le afdelingen en lokale treasury-afdelingen verdwijnen ten faveure van centrale treasury-afdelingen voor bijvoorbeeld Europa; ^ integratie van bedrijfsprocessen: gehele betalingscycli worden centraal aangestuurd; ^ de opkomst van de in-housebank: een in-housebank waarbij de dochters deals doen met de centrale treasury-afdeling, die vervolgens het totale exposure extern afdekt, wordt steeds meer toegepast. Een dergelijke structuur van opereren vereist een vergaande automatisering; ^ meer gebruik van technische standaarden op het gebied van IT: het treasurymanagementsysteem is niet meer een ge|« soleerd systeem, maar onttrekt informatie uit bijvoorbeeld het ERP-systeem en krijgt on-line marktgegevens (vanuit bijvoorbeeld Reuters of Bloomberg). Deze en andere ontwikkelingen zorgen ervoor dat de treasury-afdeling een steeds belangrijker taak krijgt binnen een onderneming. Het adequaat gebruik van systemen zal de doelstellingen van de treasury-afdeling moeten e¤n kunnen ondersteunen.

3

Elementen van standaard treasurymanagementsystemen

De varie«teit in treasurymanagementsystemen is groot. De markt bestaat uit een groot aantal aanbieders (meer dan tachtig) van kleine, middelgrote en grote systemen. Hierbij worden met name de grote systemen ingezet bij de grote corporate treasury-afdelingen, die vaak op wereldschaal werken. Daarnaast worden deze systemen

26 Hb. Treasury


juni 2004

Proefpagina: 0001


I3100^5

aangeschaft door banken. De meeste aanbieders van systemen hebben hun hoofdkantoor buiten Nederland. Daarbij hebben slechts enkele leveranciers een speci¢ek kantoor in Nederland en nog minder hebben daarbij personeel in dienst dat de Nederlandse taal machtig is. Indien we abstraheren van te systeemspeci¢eke elementen, kunnen we de volgende typische treasury-elementen aanwijzen die in meer of mindere mate voorkomen in de treasurymanagementsystemen: ^ trade management (front o⁄ce); ^ ¢nancie«le instrumenten; ^ operations (back o⁄ce); ^ cash management; ^ risk management; ^ accounting; ^ reporting. Andere belangrijke elementen bij treasurymanagementsystemen zijn de mogelijkheden tot beveiliging en functiescheiding alsmede de technische standaarden die vereist zijn om een dergelijk systeem op te nemen in de bestaande IT-infrastructuur. Alle voornoemde elementen worden beknopt besproken. 3.1 Trademanagement

De trademanagement module wordt veelal door de zogenaamde front o⁄ce (ofwel handelsafdeling) gebruikt om een transactie (deal) af te sluiten en te registreren met een tegenpartij (voor corporates vaak een bank). Onder meer afhankelijk van de aantallen en complexiteit van de per dag af te sluiten transacties moet worden beschouwd wat het belang is van de trademanagement module. In vele pakketten zijn bijvoorbeeld faciliteiten opgenomen om een transactie met slechts enkele drukken op de muisknop tot stand te brengen. Een voorbeeld hiervan is dat een hoofdsom van 1 miljoen euro wordt ingegeven als ‘1M’ in plaats van ‘1.000.000’. Ook kunnen vaak al typen transacties deels standaard worden ingevuld. Een voorbeeld is een treasury waarbij alle FX transacties standaard worden afgesloten bij ABN AMRO tegen de dan geldende spotkoers en een vaste fee. Ook de mogelijkheid om bloktransacties te kunnen invoeren verhoogt de e⁄cie«ntie. Daarnaast kan het handig zijn om transacties elektronisch te kunnen laten uitvoeren of om quotes van verschillende partijen met elkaar te kunnen vergelijken. Andere interessante mogelijkheden zijn om pretransacties in te voeren en te kunnen beoordelen of hiermee inderdaad bepaalde posities adequaat worden afgedekt of om vast te stellen, dat limieten niet worden overschreden. Steeds vaker hebben systemen de mogelijkheid om een real time/on-line verbinding te hebben met marktgegevens (bijvoorbeeld Reuters en Bloomberg). Op de schermen van de treasury-applicatie worden de marktgegevens dan zichtbaar gemaakt. De koersgegevens kunnen vervolgens in de treasury-applicatie worden opgeslagen met de stand aan het einde van de dag. Een groot voordeel van informatie over de actuele marktgegevens is dat hiermee, indien nodig, ook de rentecurves kunnen worden gemaakt en gebruikt.

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^6


3.2 Financie« le instrumenten

Het aantal ¢nancie«le instrumenten dat is ge|« ntegreerd in de treasurymanagementsystemen is de laatste jaren enorm gegroeid. Dit is mede te danken aan een verdergaande centralisering van de treasury-afdelingen, die vervolgens op de centrale afdeling de behoefte kregen om bijvoorbeeld op de beurs in Sydney te handelen in speci¢eke instrumenten. Daartegenover staat, dat de meeste treasurers vooral de behoefte hebben om FX transacties, swaps (Interest Rate Swaps en Cross Currency Swaps) en FRA’s af te sluiten. Enkele treasurers hebben daarnaast de behoefte om meer complexe derivaten te gebruiken. Voorts wordt veel gebruik gemaakt van mogelijkheden om (inter)company leningen onder te brengen in de treasury-applicatie. Ook zogenaamde ‘debt securities’ (zoals obligaties, £oating rate notes (FRN)) worden en kunnen worden geregistreerd.

3.3 Operations

De afdeling backo⁄ce heeft als taak om de door de front o⁄ce ingevoerde transacties te controleren en te completeren. Voorts moeten bevestigingen worden verstuurd dan wel ontvangen van tegenpartijen en moeten de vaste gegevens van zowel transacties als diezelfde tegenpartijen worden bewaakt. Het is dan ook in veel gevallen van belang, dat de structuur waarin de tegenpartijen in het systeem wordt gebracht goed is overdacht. Dat wordt nog belangrijker als tegenpartijen relaties met elkaar hebben; denk aan verschillende dochtermaatschappijen of bank¢lialen in meerdere landen. In sommige systemen bestaat hiertoe de mogelijkheid om een moederdochterrelatie tussen tegenpartijen te cree«ren, waarbij zelfs bepaalde kenmerken alleen hoeven te worden onderhouden op ‘moeder’-niveau. Voor een goede administratie van tegenpartijen is daarnaast van belang dat ruime mogelijkheden bestaan om bijvoorbeeld settlement instructies vast te leggen in het systeem. Ook meerdere settlement instructies per tegenpartij kunnen in voorkomende gevallen interessant zijn. Voor een juiste en tijdige afhandeling van transacties is het voor een back o⁄ce van groot belang, dat aan de status van een transactie kan worden gezien welke handelingen nog moeten worden verricht. In veel systemen kunnen statussen worden gede¢nieerd. Een voorbeeld hiervan is de volgorde: pending (eerste invoer door front o⁄ce), completed (door de back o⁄ce), approved (tegenpartij akkoord) en matured (afgesloten). Voorts zal per status moeten kunnen worden gede¢nieerd bij welke medewerker de volgende afhandeling zal of kan plaatsvinden (work£ow). In enkele systemen bestaan mogelijkheden om escalatieniveaus in te bouwen indien bijvoorbeeld transacties te lang blijven ‘hangen’, zodat als bijvoorbeeld een transactie niet binnen twee uren wordt bevestigd, een afdelingshoofd de melding krijgt dat deze transactie nog op afhandeling wacht.

26 Hb. Treasury


juni 2004

Proefpagina: 0001


I3100^7

Indien een bedrijf ook daadwerkelijk handelt in securities, kan het van belang zijn, dat ook functies worden ondersteund op het gebied van de corporate actions (dividenden, stocksplitsing, rentecouponontvangst enzovoort). Dit geeft een extra impuls aan bijvoorbeeld andere belangrijke functies als cash management omdat een goed inzicht in de corporate actions adequaat en ge|« ntegreerd kan worden opgenomen in de cash forecasting. Overigens wordt dit type functionaliteit met name door banken gehanteerd. Tot slot wordt in, met name, handelsafdelingen dagelijks een winst& verliesrekening gemaakt om de dagresultaten en posities te kunnen beoordelen. Vaak is hierbij van groot belang, dat de bestaande transacties op hun marktwaarde (marked-to-market) kunnen worden beoordeeld. Onder de regimes van FAS133 en IFRS 39 en de daar bijhorende ‘fair value’ gedachte is dit een belangrijke ontwikkeling. 3.4 Cash management

Een oud gezegde binnen de treasury wereld is ‘Cash is King’. Dit is de reden, dat juist cash management een centrale rol inneemt in vele treasury-afdelingen. Veelal wordt vanuit een goed beheer van het cash management de rol van een treasury-afdeling uitgebouwd. Voor wat de pakketten betreft wordt hier een essentieel verschil gezien tussen pakketten speci¢ek voor de corporate treasury en pakketten (oorspronkelijk) meer gericht op ¢nancie«le instellingen. De pakketten gericht op de laatste categorie hebben een veel minder uitgebreid functioneel pro¢el op het gebied van cash management. De vereiste functionaliteit op het gebied van cash-management hangt mede samen met de organisatorische inrichting van de treasury. Veelal nemen de eisen op dit gebied toe met de centralisering van de treasury-organisatie. Functionele gebieden die daarbij een rol spelen zijn onder meer: ^ vermindering van interest alsmede maximalisatie van opbrengsten van interest op tijdelijke tegoeden; ^ optimalisatie van ‘cross border’ ¢scale regelgeving; ^ verbetering inzicht in cash£ows en daardoor betere mogelijkheden tot cash forecasting; ^ optimaliseren werkkapitaal door maximaal gebruik te maken van genoten betaaltermijnen en tevens het goed in de greep houden van geboden betaaltermijnen aan klanten (analyse hiervan is cruciaal); ^ de opkomst van payment factories (betalingsfabrieken; centralisatie van uitgaande betalingen). Veel gebruikte functionaliteiten op dit gebied zijn diverse pooling en sweeping mogelijkheden (zoals ‘notional pooling’, ‘zero balancing’ en ‘target balancing’, waarbij nog een zeker bedrag op de balance staat ^ het target bedrag ^). Van groot belang is dat het treasurymanagementsysteem mogelijkheden heeft om de verschillende rekeningen goed inzichtelijk te houden. Ook een voordeel is

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^8


als de banken die de treasury-afdeling gebruikt, kunnen ook met de gewenste pooling structuren werken. In veel gevallen is sprake van een integratie (interface) tussen het elektronisch bankenpakket en het treasurymanagementsysteem. Andere veel gebruikte functionaliteiten zijn bijvoorbeeld cashforecasting-functionaliteiten, waarbij onder andere ook hie«rarchiee«n kunnen worden ingebouwd, die vervolgens kunnen worden gebruikt ten behoeve van rapportages aan het management. Bij analyses en rapportages is ook interessant om te weten in welke mate voorspellingen kunnen afwijken en welke gevoeligheden hierbij bestaan (bijvoorbeeld een verhoging van de rente met 10 basispunten leidt tot een verschuiving van de inkomsten of uitgaven die disproportioneel lijkt). Verder geldt dat cashforecasting (met name de ‘time horizon’) en het belang hiervan erg afhankelijk is van het soort bedrijf (kapitaalintensief, kasstroomgeorie«nteerd of juist rijk aan cash). Afrekenen op cash balances (doet u volledig mee in de cash management structuur of houdt u toch nog rekeningen elders aan) wordt steeds normaler. 3.5 Risk management

Het risicomanagement wordt onderverdeeld in marktrisico en kredietrisico. Beide worden hieronder besproken, maar de nadruk ligt op marktrisico. Marktrisico is immers veelal belangrijker voor corporate treasury-afdelingen dan kredietrisico’s (vooropgesteld, dat de meeste relaties bestaan met kredietwaardige banken).

3.5.1

Voor een corporate is het beheersen van de marktrisico’s belangrijk. Hierbij spelen met name de renterisico’s en de wisselkoersrisico’s een voorname rol. Daarnaast wordt vaak veel aandacht besteed aan liquiditeitsrisico’s. Nagenoeg alle pakketten bieden vele mogelijkheden op dit gebied. Dat geldt eveneens voor mogelijkheden aangaande de gevoeligheidsanalyses voor zowel wijzigingen in rentestanden als wisselkoersen. Dit is echter niet voor alle corporates van groot belang.

Market risk management

Een mogelijkheid die zowel geavanceerd als controversieel onder corporate treasurers is, is de Value-at-Risk (VaR) methode om een ge|« ntegreerd risicobeeld te krijgen (zie artikel E6175 in dit handboek). Deze techniek wordt bij vrijwel alle banken gehanteerd, maar binnen de corporates maar zeer beperkt. Een van de redenen daarvoor is de onbekendheid met de materie, anderzijds is VaR oorspronkelijk gericht op banken, waarbij dagelijks het risicopro¢el werd bepaald, dat de volgende dag kon worden bijgesteld. Corporates verkeren vaak niet in de positie om hun portefeuille op een dagbasis signi¢cant van risicopro¢el te (doen) wijzigen (wel tegen hoge kosten uiteraard) en zoeken derhalve naar maatstaven die niet duidelijk uitgaan van de speci¢eke dagpraktijk van banken. Voor deze problemen bestaan overigens voldoende mogelijkheden om deze binnen de VaR-modellen op te lossen (bijvoorbeeld door de horizon op 10 dagen te stellen). Voorts zijn varianten op de

26 Hb. Treasury


juni 2004

Proefpagina: 0001


I3100^9

markt gebracht die doorgaans als Cash-£ow-at-Risk (CfaR) worden beschreven. Vele pakketten beschikken tegenwoordig over mogelijkheden om VaR-berekeningen uit te voeren, dan wel over functies die het exporteren van de vereiste gegevens naar gespecialiseerde pakketten mogelijk maakt. Een kleiner aantal pakketten heeft mogelijkheden om de gehanteerde modellen te toetsen door gebruik te maken van back testing en stress testing. 3.5.2

Credit risk management

Het managen van de kredietrisico’s wordt vooral ingegeven doordat bedrijven inzicht willen hebben in de risico’s dat hun clie«nten niet voldoen aan, in de meeste gevallen, terugbetalingsvereisten. Op basis van een inschatting van de risico’s kunnen ondernemingen bijvoorbeeld een voorziening opnemen, een risico-opslag incalculeren of andere maatregelen nemen. In treasurymanagementsystemen die gericht zijn op de corporates (en niet op ¢nancie«le instellingen), wordt veelal minder aandacht besteed aan kredietrisico’s. Echter, in veel systemen zijn (uitgebreide) mogelijkheden aanwezig om limieten toe te kennen aan zowel tegenpartijen (binnen bijvoorbeeld de groepsmaatschappijen) als aan banken. Hierbij kan bijvoorbeeld onderscheid worden gemaakt in de totaalbedragen die met banken kunnen worden overeengekomen of kunnen de ¢nancie«le instrumenten, waarmee met een bepaalde bank kan worden gehandeld, zijn beperkt. Een constante monitoring en mogelijke bijstelling (bijvoorbeeld wanneer de credit rating van een bank wordt verlaagd/ verhoogd) blijft echter een functionaliteit die buiten een systeem dient plaats te vinden. Ter beperking van kredietrisico’s (mitigation) hebben sommige systemen de mogelijkheid om gebruik te maken van kredietderivaten. Dit instrument was trouwens het meest nieuwe instrument bij veel pakketten. Ook bieden sommige pakketten de mogelijkheden om collateral te registreren. Met name ¢nancie«le instellingen zullen dit met het oog op Basel II steeds meer gaan toepassen. Ten behoeve van de analyse van kredietrisico’s beschikken vrijwel alle pakketten over mogelijkheden om diverse doorsneden te maken van portfolio’s en kunnen vaak loss calculations en provisions worden bepaald. Ook settlement-risk-exposures zijn steeds vaker onderdeel van pakketten. Een typische functionaliteit die op dit moment geavanceerd is, is de Credit Risk VaR-berekeningen. Weinig pakketten bieden deze functionaliteit, zeker als hierbij ook berekeningen als stress testing, back testing en scenario testing in ogenschouw moeten worden genomen.

3.6 Accounting

Het belang van een accounting-module is onder de invoering van FAS133 en FAS138, alsmede de aanstaande invoering van IFRS 39-standaarden, veel belangrijker geworden. Dit omdat onder de nieuwe regels de waardering van ¢nancie«le instrumenten moet

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^10


plaatsvinden tegen zogenaamde ‘fair value’. Ook de ‘hedge accounting’ onder FAS133 en 138 dragen bij aan de veel groter wordende complexiteit van de accounting-module. De complexiteit wordt onder meer ingegeven doordat wijzigingen in de waardering van instrumenten een (grote) invloed kan hebben op de waarde, zoals die moet worden opgenomen in de boeken. Tevens dient een directe koppeling gemaakt te worden tussen het ‘hedge item’ en de ‘hedge’. De interactie tussen front o⁄ce-module en accounting-module is dus cruciaal. Onder de nieuwe regels geldt tevens dat een uitgebreide documentatie over de hedges aanwezig moet zijn. Ook hier kan een treasurysysteem bij ondersteunen. Dit stelt niet alleen stringente eisen aan de mogelijkheden van het pakket zelf, maar meer in het bijzonder aan de juiste boekhoudregels. En deze zijn vaak dermate complex, dat het verstandig is om bij een implementatie van een nieuw treasurymanagementpakket de accountingprocessen direct te betrekken bij de inrichting van het systeem. 3.7 Reporting

Een groot aantal systemen biedt veel standaardrapporten. Deze rapporten blijken in de praktijk echter vaak niet voldoende te zijn toegesneden op de eisen en wensen van de toekomstige gebruikers. De speci¢eke gewenste rapportages worden daarom als extra toegevoegd gedurende de implementatie van een nieuw systeem. Hiervoor brengen de meeste leveranciers overigens extra kosten in rekening, daar de rapportages vaak zeer speci¢ek zijn en derhalve een (signi¢cante) inspanning vergen om ze te bouwen. Sommige pakketten worden geleverd met een ‘report generator’. Met deze modules kunnen treasurers zelf rapporten bouwen. De vraag is alleen of dit gewenst is vanuit beheersoogpunt (hoe weet het management nu zeker dat de gepresenteerde gegevens accuraat en volledig zijn?).

3.8 Beveiliging

De betrouwbaarheid van de gegevens waarmee in de applicatie wordt gewerkt is van groot belang. Immers, ongewenste of ongeautoriseerde wijzigingen van gegevens (bijvoorbeeld bepaalde cash£ows van deals) kunnen (grote) gevolgen hebben voor het risicopro¢el van een portfolio van deals en leiden tot verkeerde beslissingen van het management. De gehele beveiliging rondom een treasurymanagementsysteem bestaat uit de beveiliging in de applicatie, de beveiliging in de database alsmede de beveiliging van gegevens tijdens transport (van en naar andere applicaties) en de beveiliging van gegevens binnen het besturingssysteem.

3.8.1

De beveiliging in applicaties omvat de identi¢catie, authenticatie en autorisatie van een gebruiker. De identi¢catie en authenticatie bestaan meestal uit een gebruikerspro¢el en een wachtwoord. Vrijwel alle systemen op de markt ondersteunen deze combinatie van beveiliging die erop is gericht ongeautoriseerde gebruikers geen toegang te verlenen. Een betere beveiliging wordt echter bewerkstelligd indien de toegang tot een systeem berust op het ‘to know and to possess’ principe (het principe van weten, kennis hebben van, vergelijk

Applicatiebeveiliging

26 Hb. Treasury


juni 2004

Proefpagina: 0001


I3100^11

dit met de pincode ^ weten ^ alsmede het bezitten van een fysieke sleutel ^ bezitten ^). Slechts enkele systemen beschikken standaard over deze mogelijkheden. Nadat toegang is verkregen tot het systeem bepalen de instellingen in de autorisatiematrix van het systeem welke bevoegdheden een gebruiker heeft. De meeste systemen beschikken over ruime mogelijkheden om speci¢eke bevoegdheden per gebruiker in te stellen. Daartegenover staat dat vele systemen beperkte mogelijkheden hebben om wijzigingen aan gegevens te volgen. Een audit trail (logging waarin alle genomen stappen en wijzigingen zijn vastgelegd) is in lang niet alle gevallen aanwezig. Ook hebben diverse systemen beperkte mogelijkheden om eenduidig vast te stellen wat de bevoegdheden zijn per gebruiker. Zo kan in lang niet alle gevallen eenvoudig een overzicht worden afgedrukt van de toegangsrechten van elke individuele gebruiker. Ook geldt dat log ¢les (de handelingen die door de gebruikers zijn verricht) niet altijd makkelijk leesbaar en dus bruikbaar zijn. 3.8.2

Transport van gegevens

Met transport van gegevens wordt bedoeld dat gegevens van een locatie worden verplaatst naar een andere. Een veel gebruikt middel daartoe is internet of een intern netwerk. De beveiliging van gegevens kan daarbij op verschillende wijzen plaatsvinden. Een maatregel is het gebruik van encryptie van de gegevens. Met encryptie van gegevens wordt ernaar gestreefd de vertrouwelijkheid van gegevens te waarborgen. In veel gevallen hebben systemen hiervoor mogelijkheden. De mate van geavanceerdheid is hierbij overigens wisselend. Veel gebruikte technieken zijn het algoritme DES (Data Encryption Standard) of triple DES (een verbeterde uitvoering van DES). Een voorbeeld van een andere methode die wordt gebruikt is RSA (genoemd naar de drie ontwerpers Rivest, Shamir en Adleman) encryptie. Deze algoritmen versleutelen de oorspronkelijke tekst op een zodanig wijze, dat alleen de bevoegden de tekst weer naar een leesbaar formaat terug kunnen vertalen. Een elektronische handtekening is een maatregel waarbij gegevens worden versleuteld, waarbij een deel van de sleutel speci¢ek is voor een individuele gebruiker. Slechts een beperkt aantal systeemleveranciers geeft aan dat dit een standaard mogelijkheid is. De elektronische handtekening wordt gebruikt om speci¢eke gegevens tussen gebruikers uit te wisselen.

3.8.3

Databasebeveiliging

In nagenoeg alle systemen wordt informatie opgeslagen in een database. De gegevens in de database worden in principe benaderd door de applicatie zelf. In veel gevallen kunnen geprivilegieerde gebruikers echter direct de gegevens benaderen, waardoor de integriteit van deze gegevens kan worden aangetast. Mogelijkheden om de database te beschermen zijn het gebruik van zogenaamde ‘hash-

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^12


totals’ en ‘checksums’. Een hashtotal is een optelling van ongelijksoortige elementen, zoals cijfers en letters. De uitkomst is een uniek getal. Een checksum wordt bijvoorbeeld toegepast bij bankrekeningnummers; aan de hand van de eerste acht cijfers van het bankrekeningnummer kan het laatste getal worden berekend. Hiermee wordt het bestaan vastgesteld van dit nummer. Dit zijn controlegetallen die bijvoorbeeld worden berekend direct nadat de applicatie zelf wijzigingen heeft aangebracht. Naast de beveiliging in relatie tot integriteit van gegevensbestanden, bestaan binnen databases mogelijkheden tot het zekerstellen dat alle wijzigingen die worden ingevoerd in de applicatie ook daadwerkelijk worden verwerkt in de database. Hiervoor bestaat een functie in een systeem waarbij de wijziging wordt ‘bevestigd’ (commitment control). Daarnaast hebben de meeste systemen additionele mogelijkheden om fouten te herstellen (zoals ‘before and after images’, waarmee respectievelijk de stand voor en na mutatie wordt vastgelegd) indien de database echt ‘kapot’ is gegaan. Met deze ‘before and after images’ is het mogelijk om aan de hand van deze standen de gehele database opnieuw op te bouwen. 3.9 Technische standaarden

Een onderdeel dat belangrijk kan zijn bij een nieuw systeem is de technische infrastructuur waarin het treasurymanagementsysteem gaat werken.Vele systemen werken op basis van een Microsoft Windows systeem, maar andere systemen werken speci¢ek binnen een Unix of AS/400 (iSeries) omgeving. Daarbij kunnen sommige pakketten omgaan met meerdere merken databasemanagementsystemen (DBMS), zoals DB2, Oracle en Sybase. Echter, in vele gevallen heeft de leverancier een voorkeur voor een bepaald DBMS. Op dat systeem werkt de applicatie dan vaak het best (meetpunten daarbij zijn performance en stabiliteit). Bij de keuze voor een systeem dient rekening te worden gehouden met zowel de door de leverancier voorgestelde database, als de databasestandaard die reeds binnen de eigen organisatie wordt gebruikt. Naast de harde technische aspecten van een systeem zijn daar ook nog aspecten die te maken hebben met de wijze waarop een systeem omgaat met de typische werkwijze van een organisatie. Bij vele systemen bestaat de mogelijkheid om de ‘work£ow’ van bijvoorbeeld een transactie geheel te de¢nie«ren naar de eisen van de organisatie. Een klassiek voorbeeld is dat een transactie bijvoorbeeld de statussen ‘ingevoerd’, ‘gecontroleerd’, ‘bevestigd’ en ‘einde looptijd’ kan hebben. In vele pakketten bestaat de mogelijkheid om dit met codes aan te geven en kan zelfs per code worden aangegeven welke onderdelen van de transactie nog kunnen worden gewijzigd.

26 Hb. Treasury


juni 2004

Proefpagina: 0001


4

I3100^13

Selectie en implementatie van een systeem

Het selecteren van een nieuw treasurymanagementsysteem is voor de meeste ondernemingen een gecompliceerd en ingrijpend project. De belangrijkste redenen om een nieuw systeem te selecteren kunnen zijn gelegen in de veroudering van het huidige systeem (mogelijk alleen spreadsheets), de ontwikkeling van de onderneming zelf (meer complexe risico’s en kasstromen) of bijvoorbeeld een fusie. De selectie van een nieuw systeem bestaat feitelijk uit een viertal fases: ^ de¢nie«ren van het bedrijfsmodel; ^ de selectie van het nieuwe systeem; ^ de implementatie van het nieuwe systeem; ^ de postimplementatiezorg. Op elk van deze fases wordt hieronder kort ingegaan. 4.1 De¢nie« ren bedrijfsmodel

Van uitermate groot belang is dat het nieuwe pakket de bedrijfsprocessen op de treasury-afdeling goed ondersteunt. Daartoe moeten de doelstellingen worden geformuleerd. In veel gevallen eist de directie ook, dat een speci¢eke business case wordt opgesteld, waarin onder meer aandacht wordt besteed aan de ¢nancie«le aspecten van de investering. Uiteraard moet het project een sponsor hebben (bij voorkeur op directieniveau) en zal een projectteam worden ingericht. Een van de valkuilen hierbij is om de meest betrokken medewerker aan te wijzen als projectmanager. Hierbij bestaat immers het grote risico, dat deze medewerker met name aandacht schenkt aan die zaken, die voor zijn eigen functioneren van belang zijn. Uiteindelijk leidt dit in veel gevallen tot uitstel of zelfs afstel van de invoering van een nieuw systeem. Nadat een projectplan is opgesteld, zal de huidige situatie in kaart moeten worden gebracht. Dat betreft de huidige bedrijfsprocessen en de huidige systemen en infrastructuren, inclusief de interfaces tussen de systemen. Daarbij kunnen ook reeds een aantal knelpunten worden gesignaleerd, die later kunnen worden gebruikt voor de eerste selectie van een nieuw systeem. Een zeer belangrijke stap in het selectieproces is het de¢nie«ren en accorderen van het nieuwe bedrijfsmodel. Dit model geeft zowel weer op welke wijze de nieuwe bedrijfsprocessen zouden moeten zijn ingericht als hoe informatiestromen in pakketten en tussen systemen zouden moeten worden opgesteld. Met het bedrijfsmodel kan mogelijk ook de business case nader worden onderbouwd. Hoewel bedrijven de neiging hebben dit onderdeel van de selectie niet of beperkt uit te voeren, is juist het nieuwe bedrijfsmodel van groot belang voor een e⁄cie«nte en e¡ectieve implementatie. Het bedrijfsmodel wordt namelijk ook gebruikt tijdens dat deel van de selectiefase waarin leveranciers demonstraties geven van het

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^14


systeem. Naarmate het bedrijfsmodel duidelijker vastligt dan wel dat hierover goed is nagedacht, zal de implementatie eenvoudiger verlopen. Tot slot kunnen zogenaamde ‘knock-out’ criteria worden opgesteld. Dit zijn criteria waaraan het systeem moet voldoen, wil het systeem in aanmerking komen voor selectie. 4.2 De selectie

Op basis van de gede¢nieerde knock-outcriteria kan een eerste selectie worden gemaakt van de systemen die in ieder geval voldoen aan deze criteria. Deze systemen worden op de zogenaamde ‘long list’ gezet. Ook kan een (beknopte) Request for Information (RFI) worden gestuurd naar een aantal leveranciers met daarop opgenomen de gede¢nieerde knock-out criteria. De lijst zal vaak niet meer dan ongeveer acht pakketten bevatten. De volgende stap in de selectie is het opstellen van een Request for Proposal (RFP). Een RFP bevat gedetailleerde vragen over de functies en ondersteunende technieken die aanwezig moeten zijn in het pakket. De vragen zullen zich zeker ook moeten richten op de wijze waarop zij de functies uitvoeren (en niet of zij de functies uitvoeren). De leveranciers moeten vervolgens voldoende tijd krijgen om de RFP zo goed mogelijk te kunnen beantwoorden. Aan de hand van de terugontvangen RFP’s kan worden bepaald welke pakketten de voorkeur hebben. Aan de leveranciers van deze pakketten, meestal niet meer dan drie, wordt gevraagd hun pakket te demonstreren. De basis voor de demonstraties, die meestal minimaal een dag per pakket duren, vormt het nieuwe bedrijfsmodel. Immers, aan de hand daarvan kan de onderneming bepalen welk pakket het nieuwe bedrijfsmodel het best ondersteunt. Na de evaluatie van de demonstraties kan de onderneming nog referenties bezoeken (kan ook in een eerder stadium), maar zal daarna een eerste en tweede voorkeur moeten aangeven. Met deze leveranciers kunnen dan de onderhandelingen worden gestart over het contract. Dit zal moeten leiden tot een getekend contract dat voor beide partijen interessant is.

4.3 De implementatie

De implementatie van een nieuw treasurymanagementsysteem neemt veelal een tijdsperiode in beslag die varieert tussen de drie en twaalf maanden. Dit is sterk afhankelijk van de complexiteit van het te implementeren pakket en de reikwijdte ervan binnen de onderneming. Belangrijke elementen bij de implementatie zijn het projectplan, het projectmanagement, de wijze waarop de vaste gegevens moeten worden ingericht en onderhouden, het de¢nie«ren van de instellingen in het systeem (bijvoorbeeld de instrumenten die worden gebruikt, toegangsrechten gebruikers), interfaces (waaruit komen de marktgegevens), de wijze van accounting, de conversie van gegevens uit oude (bestaande) systemen, ‘quality assurance’

26 Hb. Treasury


juni 2004

Proefpagina: 0001


I3100^15

(kwaliteitsborging) en niet in de laatste plaats: het testen en accepteren van het nieuwe systeem. Voor elk van deze elementen geldt dat hieraan substantieel tijd moet worden besteed, omdat in veel gevallen juist deze elementen ook faalfactoren kunnen worden. Bijvoorbeeld het de¢nie«ren en onderhouden van vaste gegevens van tegenpartijen is vaak belangrijk. Ook voor kleine treasury-afdelingen waarbij niet altijd 100% functiescheiding (bijvoorbeeld bij ziekte) te bereiken is, doch waarbij bijzondere aandacht kan worden gegeven aan het verhinderen van mogelijkheden om betalingen te verrichten naar ongeautoriseerde rekeningen. Een inschatting van de impact op het implementatieproject van deze elementen is dan ook aan te bevelen. Overigens kunnen ook andere factoren van belang zijn, zodat een risico-inschatting van de van belang zijnde elementen voor het welslagen van een implementatie project zeker moet worden uitgevoerd voorafgaande aan de feitelijke implementatie. 4.4 De postimplementatie

In het begin van het project was reeds gede¢nieerd wat de doelstellingen waren van de implementatie van een nieuw pakket. De volle omvang van de gerealiseerde baten worden niet altijd direct duidelijk na de ingebruikneming van het pakket. Om deze reden zal vaak zo’n twee tot zes maanden na ingebruikneming een (beknopt) onderzoek worden uitgevoerd naar de realisatie van de geaccepteerde doelstellingen en baten van het nieuwe systeem.

5

Marktontwikkelingen

PricewaterhouseCoopers voert regelmatig onderzoeken uit bij zowel de treasurers als de systeemleveranciers. De onderzoeken, gericht op de treasurers, gaan hierbij onder meer in op de taakvelden en verantwoordelijkheden van treasury-afdelingen, maar ook op het gebruik van systemen alsmede in welke mate benoemde (vermeende) trends een invloed (zouden) hebben op het werk van de treasury-afdeling. De op systeemleveranciers gerichte onderzoeken gaan in op de mogelijkheden van deze systemen. Op basis van deze onderzoeken wordt hieronder een aantal trends geformuleerd. Uit een onderzoek, in 2001 uitgevoerd in de Benelux, blijkt dat de meeste treasury-afdelingen gebruiken maken van een echt treasurymanagementsysteem. In vergelijking met een onderzoek vijf jaren eerder is dit een grote toename (van 50 naar 75 procent van de ondervraagden). Vergelijkbare trends worden ook vastgesteld in onderzoeken in andere landen. Een andere trend is dat veel ondernemingen, die reeds jaren een min of meer ge|« soleerd treasurymanagementsysteem gebruiken, steeds vaker nadenken waar zij verbeteringen kunnen doorvoeren. Dit

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^16


leidt in veel gevallen tot de aanschaf van een meer geavanceerd pakket, dat veelal meer £exibiliteit biedt en ook meer en betere verbindingen heeft met andere pakketten (vergelijk dit met bijvoorbeeld interfaces met leveranciers van marktgegevens en koppelingen met grootboeksystemen). In zijn algemeenheid wordt vastgesteld, dat het gebruik van systemen een bepaalde groeifase doorloopt, die start met het pakket Excel (of vergelijkbaar). Het is relatief eenvoudig een ¢nancieel model te bouwen in Excel en ook de uitbreidingen hierop gaan vaak als vanzelfsprekend. Grote nadelen ontstaan door een gebrek aan documentatie, waardoor anderen niet of niet makkelijk met deze spreadsheets kunnen werken; ook ontstaan afhankelijkheden van een of enkele personen in de organisatie. Tot slot is de onderhoudbaarheid, stabiliteit en kwaliteit van dergelijke spreadsheets veelal ontoereikend. De oplossing wordt vervolgens gezocht in een klein, gespecialiseerd treasurymanagementsysteem. Daarna komt een fase gericht op een ge|« ntegreerd treasurymanagementsysteem, waarin ook de gehele betalingsorganisatie wordt opgenomen en die vele koppelingen heeft met andere bedrijfssystemen. Tot slot worden bewegingen in de markt waargenomen, dat ondernemingen, die gebruik maken van zogenaamde ERP-systemen, ook gebruik gaan maken van de steeds beter beschikbare treasuryfunctionaliteit omdat zij hiermee een optimaal ge|« ntegreerde oplossing nastreven. Deze pakketten maken ook een groei door, omdat zij het vakgebied treasury zien als een groeimarkt. Over het algemeen is gebleken, dat alle systemen steeds meer functies bevatten en zeker de algemene treasurymanagementsystemen beschikken over een allround functionaliteit. Bij een selectie van een nieuw systeem zal dan ook nadrukkelijk de vraag moeten worden beantwoord of een bedrijf een allround systeem wil selecteren, of een zogenaamd ‘best of breed’ oplossing (gespecialiseerd systeem op een deelgebied met diepgaande functionaliteit op een of enkele onderdelen, in tegenstelling tot een generalistisch of allround systeem dat de gehele breedte van de functionaliteit invult, maar met minder diepgang). Een allround systeem biedt voordelen op het gebied van onderhoud, eenduidige vastlegging van gegevens en een ‘best of breed’ oplossing heeft vaak voordelen aangaande de diepgang van de functionaliteit. Daarnaast is het voor ondernemingen vaak belangrijk op welke wijze functionaliteiten worden uitgevoerd. Vaak zal dit zelfs van groot belang zijn in de selectiefase. Naast de trend dat de functionaliteit van systemen steeds rijker wordt, waardoor ook nieuwe marktsegmenten worden bereikt, bestaat een tendens om de £exibiliteit van systemen te vergroten.Veelal wordt dan gekozen voor uitgebreide mogelijkheden om parameters in te stellen in het systeem. Een nadeel daarvan is dat de juiste instellingen een uitstekend businessmodel van de onderne-

26 Hb. Treasury


juni 2004

Proefpagina: 0001


I3100^17

ming veronderstellen. Ook wordt de implementatie van een pakket complexer en tijdrovender. In aansluiting op de verrijking van de functionaliteit ontstaat ook de situatie, dat pakketleveranciers zich meer gaan richten op de complexere corporate treasury of zelfs op ¢nancie«le instellingen (‘up market’ gaan). Hierbij hebben zeker de ¢nancie«le instellingen veelal meer eisen op allerlei gebieden. Een nieuw gebied bij het aanbieden van treasury-oplossingen zijn de ‘Application Service Providers’ (ASP). Een dergelijke oplossing biedt bijvoorbeeld voordelen op het gebied van onderhoud en beheer van de applicatie. Met name nieuwe pakketten op de markt bieden het gebruik direct aan via een ASP. Ook het gebruik van communicatie via het internet neemt sterk toe en daarmee de behoefte aan een goede beveiliging van de datacommunicatie over het internet. Binnen de treasurymanagementleveranciers wordt nog beperkt gebruik gemaakt van standaard beveiligingsmogelijkheden als encryptie, elektronische handtekeningen, Trusted Third Parties (TTP) en Public Key Infrastructuren (PKI) oplossingen. De vraag doet zich voor of zowel ASP’s als outsourcing zich voort zal zetten. Directe mogelijkheden voor outsourcing zijn in hoge mate aanwezig en vele treasuryleveranciers hebben mogelijkheden voor corporates. Echter, de ervaring van treasuryleveranciers is zeer beperkt, slechts enkele leveranciers beschikken over substantiele en langdurige ervaring met outsourcing problematieken. Ook bestaat er bij treasurers weerstand om zulke belangrijke ¢nancie«le processen en vertrouwelijke data ‘buiten de deur’ te zetten. Overigens worden inmiddels speci¢eke treasury-applicaties op de markt ge|« ntroduceerd, die zijn gebaseerd op een ASP-model. Daarnaast wordt waargenomen, dat banken zelf een treasurymanagementsysteem inrichten en met name kleinere bedrijven uitnodigen om voor hun treasury gebruik te maken van het systeem van de bank. Enkele grote internationale banken hebben reeds een aantal corporates op hun systeem draaien. Een groeiend aantal systemen voldoet aan nieuwe regelgeving op het gebied van FAS133/138 en IFRS 39. Echter, de implementatie van dergelijke richtlijnen in een systeem is complex, zodat tijdens de selectie moet worden vastgesteld of een systeem hieraan voldoet. De nieuwe richtlijnen op het gebied van Basel II zullen in de komende jaren zoveel mogelijk worden ge|« ntegreerd in de systemen die zich richten op de ¢nancie«le sector. Deze integratie is een uitdaging aan leveranciers. Als laatste wordt recentelijk steeds meer aandacht gevraagd voor de zogenaamde wettelijk verplichte rapporteringen (regulatory reporting) en de aandacht voor controls in het kader van corporate governance. Mede als gevolg van een aantal ¢nancie«le debacles is

26 Hb. Treasury


juni 2004

Proefpagina: 0001

I3100^18


in 2002 de Sarbanes-Oxley wet in de Verenigde Staten van Amerika aangenomen, die aldaar beursgenoteerde ondernemingen verplicht te rapporteren over hun stelsel van interne controle. Als gevolg hiervan zullen ook treasurers meer en zelfs speci¢ek aandacht moeten schenken aan de adequaatheid van het stelsel van interne controle binnen de treasury-applicaties. In het kielzog hiervan zullen ¢nancie«le managers CFO steeds nadrukkelijker willen weten of ook risico-inschattingen juist zijn en dit zou kunnen leiden tot een verhoogde en verbeterde aandacht voor risicomanagement.

6

Naslagwerken

Treasury en Risk Management systems survey; explore the systems (PricewaterhouseCoopers, 2002). Benelux Corporate Treasury Benchmarking Survey 2001 (PricewaterhouseCoopers, 2001).

26 Hb. Treasury


juni 2004

Proefpagina: 0001

Treasurymanagementsystemen

Recommend Documents