Treasury System Adoption

Configuring Centralized & Decentralized Cash Management in TS CMO - Part 2

Sujith Nair — Wed, 27 Jul 2011 21:40:44 GMT

Todays post continues that series of posts that describes the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. Today we will look at a case of decentralized cash management. (Please read the first post the describes a centralized scenario as well)

Decentralized Cash Management - Consider an organization head quartered in the US with operations in US and Canada, the US organization managing the treasury (cash and investments) for the US and the Canadian subsidiary managing their cash.

A decentralized cash management scenario is described below - the organization receives BAI files from banks and proprietary investment updates in the US and Bank proprietary files for cash and investments in canada. Cash management and Investments are decentralized and taken care of by treasury users in respective locations. Also note that two backend GL systems that TS CMO synchronizes with are part of this setup as well. You can read more about the GL integration capabilities of TS CMO here and here.

To accommodate this need 2 Treasury Operations Entities are configured - Canada and US and respective users or roles and accounts or account groups are assigned. Now users in the respective organizations can perform their day to day forecasting, reconciliation, positioning, reporting and other functions w.r.t the specific set of accounts. As noted previously, not all accounts need to be used position and they can be classified as such.

A third Treasury Operational Entity called North America is created with access to all accounts and is assigned to a specific set of senior management users who would need access to data across the enterprise- Note that users using this entity will use it for view only access as the cash management functions are performed within the US or Canada entities created earlier. This configuration is described below.

It is important to note here that we went from centralized positioning (described in the previous post) to decentralized positioning purely via end user configuration. It is also important to note that in the event that a new user or set of users need to perform a cash management function, all an administrator has to do is to assign that user or the role of the user to the appropriate tag using a web browser.
We will look at the same feature set in even more complex scenarios in the next couple posts. Thank you for reading.

Configuring Centralized & Decentralized Cash Management in TS CMO - Part I

Sujith Nair — Mon, 18 Jul 2011 19:47:56 GMT

Over the next 4 posts, I will describe the ability of TS CMO to support multiple centralized and decentralized cash management and positioning needs of enterprise organizations. To start, we will look at less complex scenarios and move towards the more complex models.

Centralized Cash Management - Consider an organization head quartered in the US with operations in US and Canada, the US organization managing the treasury (cash and investments) for the entire enterprise.

The centralized cash management scenario is described below - the organization receives BAI files from banks in US and Bank proprietary files for cash and investments in canada and investments in the US, it has one backend GL system that TS CMO synchronizes with. You can read more about the GL integration capabilities of TS CMO here and here.

TS CMO allows for the configuration of this model via the creation of cash operations entities or tags. In this case, since all cash management is done by the central US organization one cash operations entity (tag) called North America is created by the end user. All bank and investment accounts across the enterprise (US and Canada) that are used for cash management purposes (note that accounts can be marked as not used for cash management as well, useful when concentration accounts are used for positioning) assigned this tag. Appropriate users or roles (groups of users) from US treasury organization are assigned this tag as well ensuring that they can position for US and Canada.

Once a US treasury user logs, he or she will be able to position both in USD and CAD for the enterprise without any custom development effort. Exports to the backend GL system can be automated . In the above example the only transformations needed are to transform the proprietary bank and investment formats into TS XML format and transformation of the TS XML GL export to Oracle GL Specific format. Note that these transformations are fairly quick and either the TS managed services team or your internal IT team could do that.

In the next post, we will look at a decentralized cash management scenario.

Customer Hosted Treasury Management System Deployment

Sujith Nair — Mon, 27 Sep 2010 22:05:51 GMT

This morning, we responded to a request from a large corporation wanting to know if we support customers hosting our treasury management system in-premise at their location and what our self-hosted deployment model would be like. This post talks about what we offer for customers who need the treasury workstation deployed in-house.

As you probably know by now, Treasury Sciences provides hosting, managed services and support for all treasury management system modules, but if your organization's policies require you to utilize an in-house or in-premise hosted system we offer that as well. In fact, we have a hedge fund customer that has deployed our cash management operations and electronic funds transfer modules at their data center.

This chart shows you at a high level what an in-premise deployment would look like (our managed services team would provide relevant details to your IT folks). All modules and services shown below are deployed behind a firewall, we will need in-house IT involvement to provide us the connectivity, access etc but for end users of the treasury workstation it will be the same- they will access all features via a web-browser. We do offer managed services and support for in-house deployed systems as well.

Thank you for reading, do let me know should you have any questions.

White Labelling our Treasury Management Suite

Sujith Nair — Fri, 25 Jun 2010 20:33:18 GMT

Over the last few months our product team has received multiple requests on whether we can white label our product suite for a bank or another financial institution. i.e. can we make the treasury sciences suite of products available to say, the customers of a bank via the banks portal. This post describes how a bank or a financial institution can go about white labeling our products and how it will work providing potential benefits for the bank and the bank's customers.

I am making an assumption upfront that you are the bank and that you have had conversations with us, have seen our product demonstrations, believe that our Cash Management Operations module (for the purposes of this post) will be beneficial to your customers and have decided to white label one or more of our modules- say our Cash Management Ops module.

Working backwards from the end result, the integrated white labelled solution will work as shown in the picture below.

Your bank's customer's account manager would be able to login into your banks backend administration portal and make the TS CMO product available to the respective customer - the integration that is needed will be accomplished by our product team working with the technical folks at the bank. The TS CMO system can be setup such that all relevant customer accounts are automatically loaded into it from internal bank system - again an integration point that can be accomplished at the backend. In addition to this, the third integration point at the backend between TS CMO and bank internal systems will ensure that prior and current day reporting files are automatically loaded into the TS CMO instance for the customer.

Now let us discuss some of the other key questions or features that potential customers of the bank would expect out of a Treasury Management System.

Multi Bank Connectivity

So the bank's customer is now ready to use the bank branded TS CMO product for their cash management purposes using the accounts at the bank fairly quickly . What if the customer has additional accounts at other banks that would contribute their cash position? The customer has 2 choices, they could manually upload any bank reporting files from any number of banks into their CMO instance with minimal end user setup OR setup automated connectivity between their other banks and TS CMO. Our product support team could do the integration or the bank's internal IT staff could do that.

Training

A key element here with regards to bank customer on-boarding is training the customers users. Each feature and functionality provided by our products is available as short videos that are available to users 24x7, so users can view the demonstrative videos and perform their daily tasks. Our product support team could always train the bank's support staff as well as needed. Most importantly, all our products are intuitive and easy to understand and use, there by reducing the training needs considerably.

Product Features

All treasury management features that are supported by the product module chosen will be available to the customers of the bank. A detailed look at all our product modules and the features and functionality supported can be viewed here. For this post I have chosen CMO as the product module being white labelled but do note that all our product modules can be white labelled.

Integration with a customer's internal systems

Configurability and Integration are a core strengths of our product- be it integrating into one or more GL systems to enable straight through processing or multiple systems that can forecast transactions; our product suite enables XML based standard integration features out of the box. What this means to the bank's customer is that they can use the integration features provided out of the box to integrate with any internal system they have by simply transforming the output file provided or input files required by the treasury sciences suite. Our product suite could always help them with these needs as well.

We believe that by white labeling our CMO module, a bank or financial institution can provide enterprise treasury management functionality to their customers in a seamless, cost effective way. Do let me know should you have any questions.

Bank Treasury Workstation, Treasury Workstation, White Labelled TMS

Why should an organization migrate from Manual Positioning using Excel Spreadsheets to a Treasury Management System (or Treasury Workstation) ?

Sujith Nair — Fri, 15 Jan 2010 08:08:21 GMT

The reason for the post is a question from a potential customer of ours. After spending an hour or so on our Cash Management Operations Module, a cash manager of a large retail chain told us that they were intrigued by it, believed that the features provided by our product will be very useful to them and wanted like to try the product out. Then he had a question.

"How do I justify the cost of a Treasury Management System? I can hire an analyst and use a spreadsheet to continue daily positioning, it has worked for us so far".

I will make an attempt at looking at the possible benefits in the rest of this post. Hard cost benefits of using an enterprise TMS typically include 3 types of cost benefits (reduction in cost).

Detection of Errors: Detection of errors in forecasted data or in early detection and cancellation of inaccurate electronic payments can result in operational cost savings. Detection of errors in banking data can result in accurate positions.

Reduced reporting costs via consolidation: Reports are run enterprise wide. Ensuring that all data from banks and other internal and external systems are consolidated and reported via an easy to use interface results in efficient reporting and reduces reporting costs considerably. Typically financial institutions charge customers for each generation of a report. As an example, a customer of ours with 8 subsidiaries is currently saving over 15,000 USD a month by not paying the bank for each report run- the data is extracted from the bank once and stored in our TMS, the data (up-to 7 years of historical data) is reported to over 150 users via our reporting tool.

Accurate and timely positions resulting in accurate investible cash sooner: The actual dollar benefits derived varies from one organization to another- the more complex an organization is, the larger the risk of inaccuracy and the better the chances of improvements in accuracy via the use of a system. In typical large implementations, we see improved position accuracy in tens of thousands of dollars almost daily; we also see improvement in predicting tens of millions of dollars of investible cash on a pretty regular basis.

The primary benefit in utilizing an enterprise TMS vs. manual process for cash positioning is the improvement in accuracy and the timeliness of cash positions day after day provided by automated forecasting, bank connectivity, reconciliation and positioning capabilities of an enterprise TMS.

There is more to a Treasury Management System but unfortunately not all of it is visible upfront, when you are making a choice. Let us look at some of the se benefits in a bit more detail.

Accuracy & Timeliness: Reduced manual intervention and increased automation results in more accurate forecasts and positions. Typical spreadsheet errors such as typos, formula errors etc are eliminated. Additionally, automation ensures that data that needs to be collected for forecasting and positioning is collected at the earliest available time - this typically results in automated, systematic positions being available sooner than manual positions. Accuracy results in better-informed investment decisions and timeliness ensures that your investments can be made at the earliest, ensuring that the best available investment options are available to you.

Scalability & Manageability: As the positioning process becomes more and more complicated, say by the introduction of new subsidiaries in multiple countries; it becomes more and more difficult to position cash on an enterprise basis using a manual process/spreadsheets. Organizations that stick to manual positions in such scenarios typically have 2 choices –(1) position each country/subsidiary/currency separately thereby losing visibility of enterprise cash or (2) try enterprise positioning with an excel spreadsheet typically resulting in inaccurate positions.

Consistency & Reliability: Systematic processes eliminate issues with consistency, not matter how complex or simple the cash positioning needs are resulting in reliable, consistent cash positions day after day. Typically, this eliminates the need to double-check each calculation. More importantly, it has been a regular experience for us to find errors reported by banks. If positions were created manually, typically there is limited ability to double check data reported by the banks. Enterprise TMS's typically calculate the CAB, OAB along with floats and compare it to the numbers provided by the banks ensuring that any discrepancy can be identified. Again, the more the number of banks and accounts the more likely an organization will find errors.

Security: An enterprise TMS typically encrypts all confidential data and the use of roles in a system ensures that users with the appropriate privileges see the data. The level of security and access restrictions provided by an enterprise TMS is way better than what can be achieved via an Excel document.

Multi-user Access: Enterprise web based TMS like the Treasury Sciences Suite of Treasury Management products provide unlimited access to multiple users of the treasury and across the enterprise. For example, delegating forecast input and management directly to the departments that are responsible for the forecast can ensure accountability and accuracy of forecasts. Additionally, you can have subsidiaries create their own positions in multiple currencies while having the ability to view consolidated enterprise free cash in a currency of your choosing. An excel system is typically useful for one user.

Compliance & Audit-Ability: Manual approvals and audit are not efficient ways to ensure the enforcement of organization policies and controls. Use of a TMS considerably reduces chances of fraud by tracking and reporting on each action by all users of the system and provides you the ability to enforce organization policies and processes across the enterprise. A system audit is typically much faster than a manual process audit as well.

Who wrote the macros in that spreadsheet?: This is something we have seen in multiple instances - a spreadsheet is created and updated over a long period of time. The person who wrote the macros is no longer with the organization and typically the organization is stuck with it. Even if the author is around, it does not take much for a spreadsheet to get very complex- well, it was never meant to be a treasury management system.

Focus on more important things: There are typically more important things that a cash analyst or a treasury manager can do instead of downloading bank files manually or printing out multiple reports from multiple banks and entering the data into a spreadsheet. An enterprise Treasury Management System makes your life much simpler and lets you focus on how best to manage your cash.

All of the benefits mentioned above have a cost and a cost saving associated with it. What it is depends on your organization, the scale of your operations and your situation. Also note that the improvements in cash positions, cost savings and improved investments via the use of a Treasury Management System are typically not easily predicted upfront as there is an element of unknown-unknown's (manual positioning and related processes over a period of time in an organization typically result in hiding the possibilities of better forecasting and positioning) here.

The only way to find the true benefits for the organization is by trying out an enterprise TMS for a reasonable period of time and by comparing it to an organization's manual process. This has become a very long post. Thanks for reading and do let me know your thoughts at sujith@treasurysciences.com.

Barriers to Treasury Management System Adoption - Implementation Timeline & Cost

Sujith Nair — Wed, 16 Sep 2009 06:57:34 GMT

We have looked at multiple reasons for the lack of Treasury Workstation Adoption including Misinformation, Integration Challenges, Lack of Configurability, Training Needs and the approach to Treasury Management System adoption. The underlying disadvantage caused by all of these factors is essentially the considerable time needed for implementation and hence the higher cost of Treasury Workstation or Treasury Management System Implementation/Adoption.

In a typical implementation of a Treasury Management System, considerable time is spent on the RFI/RFP process without actually using and evaluating the product for what it provides functionally. This is followed by an extensive planning phase, again planning that is largely done on paper and most often one that considers the complete implementation cycle for the product- i.e. adoption of all products modules, rollout to all departments and sub-organizations and adoption of all features is planned upfront.

At the outset of any such TMS implementation, the choices made and the planning almost always seem perfect. Of course sufficient contingencies are built in as well. The first major disadvantage that such TMS implementations have is the vendor & product selection is based on pages and pages of text written in a word document and a marketing product demonstration of a few hours. This leads to the end users of the product having little to no understanding of the product- or having significant misunderstanding on product functionality and what the product offers. As the implementation begins the "Request for Change" process also starts in full swing. Now, there is only so much contingency you can build into any product implementation timeframe. As the product implementation timeline itself is based on limited understanding of product features, chances are the timeline would be adversely affected by the new features or changes needed. Configurability of the product can help meet some of the needs here but then again it can only help so much.

Additional changes, new features and functionality and customized functionality ensures significant involvement of consultants or internal employees. Add time leads to added cost and before you know it newer plans are made- the changes to the plans are in 2 areas - the end date & cost.

As third party observer, if you have seen an organization go through the above mentioned process you would have noticed the added time, the significant costs incurred and the frustration of your counterparts in that organization who are involved in the process.

Now, here is an excerpt from a conversation we had with the Treasurer of one of the largest software vendor/integration services provider. After spending a hour seeing our product and discussing our approach, he said "We are 2 years into implementation of our Treasury Management System and we do not have a definite end date now. Note that this is when our internal resources who are trained and who typically consult on TMS implementation of the large third party TMS product we choose are implementing the TMS for us internally. I wish we had considered the alternate approach you are recommending"

At Treasury Sciences, we are not saying that we have a magic wand that can help resolve all of the issues, however we can certainly assure you that we have a better approach and very configurable suite of products. These two when put together with our Free Trial will go a long way in eliminating some of the challenges to TMS adoption.

Barriers to Treasury Management System Adoption - Misinformation

Sujith Nair — Sat, 12 Sep 2009 13:23:18 GMT

As part of what I do at Treasury Sciences, I interact with multiple treasury professionals on a regular basis- at conferences, at our speaking engagements of course potential customers. Most of the time, the conversation revolves around the current issues they are facing with TMS. What I also realized over the last year or so is that there is quite a bit of misinformation regarding Treasury Management Systems- mostly in the area of how technology addresses a certain business need. I will try to address some of these in this blog post.

1. Hosted Treasury Management Systems are not Configurable

This statement is true for a large number of hosted software products or SaaS products out there. Hence the implication that since this is true for many software products, it must also be true for a hosted or SaaS Treasury Management System. However, there are some other points to consider when discussing Treasury Management Systems. It is widely understood, that even though the core treasury management needs are the same, organizations differ in how each of their treasury management processes are implemented. Best practices in Treasury Management could also vary from organization to organization based on the organizations industry and many other factors. Hence, configurability is an absolute need for Treasury Workstations or larger Treasury Management Systems.

Most Treasury Management System Vendors understand this, I know that we do because we have spent countless hours making our suite of Treasury Management Products configurable, in most scenarios- end user configurable. Now, if our products are configurable does that mean that there is a catch? Well, the answer to that is that it does not matter whether a vendor (us included) calls it SaaS or hosted or internet based or whatever. Ignoring these larger classifications for a bit, let us look at what a TMS should provide such that it provides most value to customers.

Treasury Management Systems are best hosted at an external data center as this considerably reduces overall costs and hassles and considerably reduces or eliminates internal IT costs, the TMS needs to be configurable as business needs differ and access to TMS is best delivered via a web browser over the internet, as this reduces unwanted access constraints and improves maintainability - downloaded software is a pain to manage and maintain from a users perspective and to support from a vendors perspective.

If the product you are considering does all of the above well, trust me you can ignore the buzz words and marketing speak which all vendors provide (including us).

2. Try before you buy can lead to Sunk Costs & Unintentional Decision Making.

This is something we started hearing lately- that a Free Trial of a Treasury Management System leads to sunk costs and unintentional decision making - i.e a potential customer utilizing a Free trial to evaluate TMS will loose investment and unknowingly choose a product. As much funny and completely irrational as that sounds, this is a concern out there regarding Free Trials.

The premise of a Free Trial is that a customer uses a product before making a choice, that the product will be configurable fairly quickly (without years of technology consultants burning through your budget) and extremely user friendly ensuring that it takes as less as 1-2 days to get started. Of course, it is Free- so customers do not have to pay the vendor for a Free Trial.

Please note that there are not many vendors out there that provide free trials, this is because you need a well designed configurable product to give out a Free Trial. However almost every software vendor that is a leader in their respective segment provides a Free Trial. The model of a Free Trial has been tried and tested multiple times over in multiple industry segments, some of which are far more complicated when compared to Treasury Workstation functionality. Now, what is ironical here is that the very people who complain about "Sunk Costs" of a Free Trial are the same ones that spend months on an RFI followed by months on an RFP trying to figure out what is out there- without ever using a product.

Hopefully that addresses the "sunk costs" part of misinformation. Now, for the "Unintentional Decision Making" part- honestly, I don't know what to say but for this that I do not expect any of my customers to choose anything unintentionally, more so a Treasury Management System. We are not talking about 5th graders here, we are talking about a group of Treasury Professionals selecting a Treasury Management System. This is not Free Candy! A Free Trial of a TMS is meant for serious people making informed decisions.

3. Internet Based Treasury Management Systems are not secure.

We need to move on from here- yes, I have heard this from multiple CIOs in the late 90's through early 2000's. But now? There are secure mechanisms of delivery over the internet and multiple mission critical systems that use the internet to deliver secure data.

Would love to hear your thoughts, any experiences that you may have had in this regard.

Barriers to Treasury Management System Adoption - Training Needs & Usability

Sujith Nair — Fri, 28 Aug 2009 09:19:28 GMT

A significant challenge to TMS adoption is enterprise wide rollout and the ability to train and get users upto speed with the new TMS, especially when additional features such as say, EFT capability is adopted along with basic treasury workstation functionality. i.e. if the system is required to support subsidiary origination of payments (decentralized origination, centralized approval), the user base could be scattered across multiple locations and thus classical training becomes a hassle. This is especially true for large enterprises that have multiple subsidiaries in multiple countries. In their case, even basic TMS functionality such as cash positioning could present a training nightmare.

Let us take an example of an organization with say 5 subsidiaries that represent 5 regions across the globe. Even if they are considering basic TMS functionality, there are still users to train across multiple continents. Classical training methods to solve this problem are often costly. i.e. you need to fly out a crew to each location and train users on the product. This in itself can be a considerable added cost to the product.

Additionally, there is the problem of availability of help when it is needed most. i.e when users start using the product after training. Upfront training, no matter how much time was invested in it; will not help answer some of these questions. Support time from the vendor and associated cost kicks in. Even then, there is no guarantee that adequate help will be available to the user to create that cash position before say, 8 AM. The only solution then is to sign up for 24x7 support, which of course will be the costliest support option provided by the vendor.

Then there is the issue of product user interface design. Some products are simply very complicated to use- this is typically true with products that are put together by vendor by purchasing multiple product modules from multiple vendors. Note that this a typical case with many treasury workstation products out there. With these products, end users typically end up having more issues and more questions resulting in reduced productivity and added cost. It may not seem to be much upfront, but over years of use these costs and inefficiencies add up.

However, there are other products that are easier to use and are more intuitive because they were specifically designed to be so. So usability should be a consideration while evaluating multiple products during vendor selection. The key here is evaluation of the product, however if the product was chosen by a paper based RFP process together with one or two demonstrations, chances are that the organization does not know how usable the product is, they will only find out when it is too late.

We utilize extensive usability analysis, design of intuitive interfaces and product videos that are available 24x7 to users of the product to help address the issues listed above. I will cover our approach in much detail in a later post.

Barriers to Treasury Management System Adoption - Integration

Sujith Nair — Sun, 16 Aug 2009 09:09:21 GMT

Integration capabilities are a must have while considering Treasury Management Systems. Even if you are choosing multiple or all features and functionality from one TMS vendor, you still need to integrate the TMS with banks and accounting & GL systems. If you are choosing a best of breed approach, then you need a TMS module from one vendors to integrate with modules from other vendors as well. There is no getting away from integration.

A very important fact to remember regarding integration is that most organizations implementing Treasury Management Systems spend most of their time and resources on integration. Typically, Integration is the single most expensive element of a TMS implementation and lack of seamless integration options and the added cost act as a major barrier to adoption of Treasury Management Systems.

Multiple systems need to talk to each other to achieve significant business operational benefits such as Straight Through Processing. The problem with multiple systems talking to each other is that not all systems are created with similar technologies or design philosophies or with the thought that this system would have to integrate with these many other systems at a later date. It ends up more like a typical tourist asking a question in English and a native providing a response in French (or vice versa). There are two parts to successful integration, one is the ability of the native to provide a response in English and the second is the information contained in the response- hopefully the native knows that answer and can provide it in a way that the tourist understands or tell him otherwise and point the tourist to possible channels where the tourist can receive such information.

This is where standards come in. Standards based integrations ensures that two systems meet a certain standard and use that standard (typically a format, XML) to communicate with each other. The internal implementation of functionality for each product is totally up to them, however they conform to a standard to communicate. Now this approach ensures that all products that meet the standard can talk to each other. For example, In the case of payment origination systems that support the ISO 20022 standard, a customer ultimately gets the flexibility to switch payment banks seamlessly, without any custom development if the both banks support the ISO standard.

However, not all standards are adopted, or adopted in time. Unfortunately for all of us, most of the TMS vendors, banks, ERP and other system vendors are notoriously slow in adopting the latest standards as the standards become available. Unfortunately for me, I have first hand experience in waiting for a large bank to adopt the ISO 20022 standard. It took us the best part of 8 months, hours and hours of meetings and escalations to finally get this done. Well, in the most part we actually helped the bank test their end of the system. This also leads me to how integrations are executed- note that this is of significant importance. In the case of this bank, they of course had their internal payment systems and internal payment formats. Based on my understanding of their system, what they did to integrate using the ISO 20022 standard was to create a wrapper; a wrapper on top of their existing payment format and thereby passing on any of the inefficiencies of their internal, outdated payment format to the newer format. This is a very common problem with integration- most systems do not provide enough flexibility inherently to accommodate newer standards and integrate with other systems. Like any other problem, this one has consequences as well. The system had added an additional layer of complexity and maintenance and chances are that these costs will be passed on to the customer. What is worse is that any improvement in the standard or inclusion of more features in the standard will not be implemented in the product easily.

There is one other thing to consider, not all integration is absolutely necessary and not all integrations provide adequate benefits and justifiable ROI. Most organizations that implement TMS do not analyze each integration from an ROI perspective. An example is a company with 1 banking relationship (for cash management reporting purposes) and one that utilizes only one current day file per bank deciding to automate the communication between the bank and the TMS. Typical integration of bank reporting files takes between a week to 3 weeks depending upon the responsiveness of the banks. Of course, banks do charge for it as well. Is it really worth it to integrate in this case?

Another example in the case of a large implementation- Integration of bank accounts from multiple backend systems to a TMS. I spoke with a large fortune 100 organization recently and found that they are integrating their multiple backend GL systems to their new TMS that they are adopting. They decided to integrate such that bank account creation, modification and deletion in any backend GL system reflects in the TMS and vice versa. So, changes could be made in any GL system or the TMS; the systems would sync information with each other and thus all systems will reflect the latest information. Cash concentration and management in their case is centralized and the have a limited small set of TMS users that help create the cash position for the day. When I spoke to them, they were 2 years into implementation and they were still integrating. From a technology implementation perspective, I can tell you that if the GL systems were considered the master record system and if this organization choose to implement one way integration- i.e. allows changes and additions to accounts only within the GL systems and reflect these changes in realtime or near realtime into their TMS; they would be done with the implementation and would be using the product now. I am not second guessing them and saying that they were absolutely wrong, they could well have had a legitimate need for complex integration. However, what I am not sure is if the question regarding ROI on this integration need was asked upfront.

Would love to hear you thoughts and experiences.

Barriers to Treasury Management System Adoption - Customization, Lack of Configurability

Sujith Nair — Sat, 15 Aug 2009 04:28:41 GMT

In the last post, we discussed extensively about demerits of the "Big Bang" Approach and the benefits of prioritization of needs and incremental adoption. We also looked at configurability of software products and how it enables Treasury Management Systems to meet enterprise needs and challenges of an organization, as these needs arise. Technology is what brings us a Treasury Management System. However, in many cases improper use of technology combined with unnecessary processes act a barrier to adoption - I will look at each of these in some of my future posts.

This post focusses on configurability, or the lack of it and the unfortunate but all too common need for customization of a Treasury Management System to meet an organizations needs.

Configurability essentially provides the end users of a product or managed services and support users the ability to configure the product to meet the organization specific needs. A simple example here would be Ad hoc reporting. The ability for end users to create conditional query based reports, save, share and export data. A more complex sounding example here is the ability for and end user to configure their TMS to create an appropriate output for each GL system of theirs- each having its own defined accounting treatment. The second example may sound complex, and in most cases extensive customization of the TMS is required to achieve it.

Another example could be a organization that is in transition- say from a decentralized payment approvals model to a centralized payment approvals model or vice versa. Most TMS out there would require considerable time and effort to accomplish such a task and consequently most organizations wait till they have accomplished the transition and then consider adopting a TMS Payment module.

Now, let us not confuse customization with configurability- customization requires a product implementation consultant to create multiple reports for you or to write new code such that the TMS can integrate with each GL system or accommodate your specific payment approval processes. In other words, configurability acts as an enabler, enabling an organizations need for change. Need for customization reduces the ability of an organization to meet with changes, without considerable investment in time and effort and thus in cost. Customization acts as a deterrent to Treasury Management Adoption, and rightly so.

Let is first look at how configurability is achieved and why most systems fall short and need extensive customization. Most of the large TMS our there are a conglomeration of multiple products - well in most cases a conglomeration of products from multiple independent companies that were bought by a parent company and somehow sold as one product. Seamless integration of these products is in simple terms very difficult and requires time and resources; which unfortunately is challenging even for the largest of the TMS vendors out there. Hooks are built in at multiple places within each product so they can talk to each other. The problem with this is that any change or configurability of one product will affect the very functioning of the other products that are connected to it. These products were never meant to be working together. End result is that end user configurability options are not provided by the vendor and custom configuration for a customer is expensive. A possible solution to the problem mentioned above is to pick products that are built from the ground-up. Configurable products that use the latest stable technology and utilize standards where available.

Ultimately, lack of configurability and the need for extensive customization,both upfront and as and when an organization's needs change result in additional time and resources, impacting the ROI for TMS adversely. If you have not adopted a TMS so far or have limited adoption, chances are that you agree with and understand some of the challenges that I have described above. If you have implemented a solution and agree or disagree with the post, please let me know your thoughts. I will continue this thread on subsequent posts, meanwhile please feel free to post a comment on what your thoughts may be.