The technical scope to be covered, from daily liquidity management to detailed matters of treasury accounting, and the need to consider specific local circumstances in individual national subsidiaries automatically result in a highly heterogeneous requirements profile.
Despite a structure involving many local company units, the typical strategic aim is to reduce interfaces and standardise processes in the central system and thereby to harmonise and standardise the IT map to become more cost-efficient and to allow transparency throughout the company. This desire for transparency comes about generally in finance – and specifically in treasury – to account for compliance and monitoring specifications and external regulatory requirements. In this light, it is understandable that there is a trend towards replacing the isolated solutions scattered worldwide by setting up central treasury platforms to combine the risks that must be managed. The advantages are clear: for instance, you could compare compliance and efficiency of dozens of local electronic banking solutions wits a central solution for global payment transactions and its features of standardised processes and uniform formats and bank interfaces.
That's just the theory of formulating strategy for a standardised central system solution for corporate treasury based on harmonised processes and technical properties. In the specific, practical context of a global company that has to master a plan to set up central treasury architecture, executing a global implementation project is certainly not such a simple task. The technical scope to be covered, from daily liquidity management to detailed matters of treasury accounting, and the need to consider specific local circumstances in individual national subsidiaries, for example different regulatory requirements, specific sources for currency exposures and liquidity flows or specifics of payment transactions in individual countries, automatically result in a highly heterogeneous requirements profile. These issues also present the project team with a number of technical and design-related challenges. Moreover, there is no sure formula for an approach that satisfactorily addresses these specific circumstances and provides planning security. This is the reason why many IT projects – not only in treasury – sooner or later go off track.
Most of those involved will clutch at the magic straw of 'standardisation' in such situations. Technical requirements, processes, system functionalities, project activities – everything is harmonised based on an imaginary standard, to channel the treasury project into a straightened river – figuratively speaking. Because only in this way can the advantages of a central, global treasury platform be realised – if company-specific templates created for the key treasury processes serve as a basis for the predefined standard functions in the treasury management system and allow them to be adapted specifically to individual needs. In this regard, it is critical for the notion of standardisation to run as a thread through all project activities. It is not cost-efficient to use process templates and to leave treasury system settings in standard configuration only to have the laborious task of redeveloping training materials and test case catalogues at a later stage of the project. Therefore, standard templates must be used over the entire duration of the project and over all project steps. This begins with predefined project plans or the scoping template to specify requirements, continues with best practice templates for concepts and blueprints and runs to treasury-specific technical requirements (e.g. templates for entry and valuation rules relating to the TMS) and to test case catalogues.
Efficiency advantages of standardisation are clear, as it becomes a lot more likely that a system integration project is plannable and comparatively quicker and cheaper. Accordingly, whether or not the project will ultimately be successful depends on how the tightrope between standardisation and local specifics is walked. Thus, it should be no secret that using templates also naturally harbours a number of risks: establishing processes and system functions without sufficient and timely involvement of local treasury process experts, or exclusively using the specifications of the system developer leads to it being impossible – or very expensive – to map individual treasury processes critical to the company in the TMS, or means that these must coexist with the old local solutions. For all efforts to standardise, therefore, the solution must involve a certain flexibility to optimally cover the technical requirements. Functional shortcuts should remain the exception.
Admittedly, projects to set up global treasury platforms are heterogeneous and complex. Standardisation is a means to reducing complexity which, used in combination with other project approaches like agile methods, can significantly increase the chances of success. Nevertheless, especially in treasury, with its diverse technical areas and local specifics, the 'standardisation trap' must be avoided. Many companies want to reduce time and costs of system implementation by consistently introducing 'the standard' and avoiding any adjustments to processes and system functions. Doubtless, it remains correct to not modify systems in the vast majority of cases. What is not correct is faith in an often imaginary standard. This standard doesn't exist.
As soon as the initial design of system architecture for treasury is complete and a decision has been taken on one or maybe even several systems, building blocks are decided upon to construct the ultimate platform and thus to define the company's own specific standard. There are countless templates and build guidelines to do this, from which the most suitable must be chosen and adapted to individual needs. After all, buying a set of lego blocks doesn't mean you've bought a finished house.