Friday, June 25, 2010
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.
Saturday, June 12, 2010
We recently completed an implementation of our product suite (cash management operations module and electronic funds transfer module) for a large Hedge Fund. This customer uses our EFT module to make payments for margin calls, to manage excess collateral, netted transfers between accounts or to make vendor payments.
In this post, I will share some of the key implementation details of the electronic funds transfer module for this customer, hopefully this information would be useful for other organizations (especially hedge funds) that are planning on implementing an electronic payments solution.
Systematic enforcement of Payment Policies & Procedures: One of the primary needs of this hedge fund customer was the ability to systematically enforce their specific payment policies and procedures. Their policies of payment approval and release described a group of payment originators and another group of payment approvers. The originators would originate payments- either free form wires or wires based on pre-approved templates. One approver would then approve the payment and then the policies requires another approver from the same group of approvers to approve the wire again before systematic release to the payment bank. Note that template based originations made it easier to approve- i.e. the approver already knows that the template is approved which implies that all beneficiary information is approved, so all an approver has to verify is the specific value date and amount.
The TS product team configured the a 3-step workflow as described above and created 2 roles- originators and approvers. These are the only 2 roles that would now participate in the workflow (Yes, system administrators do not have any visibility into the payment approval or release process) .The procedure/policy implementation for this hedge fund customer is below:
TMS software needs to support configurable workflows and roles that can then be tailored to a customer's specific business requirements. If configurability is not an option, then either the customer has to live with a new process dictated by the system or spend significantly on customization.
Support for multiple payment banks: Ability to connect with multiple financial institutions to make payments and transfers while maintaining a seamless end user experience was another key requirement- well supported by Treasury Sciences EFT module. The additions we made for this implementation (and for future needs) was support for additional payment formats. EFT supports the ISO 20022 standard out of the box; now we have added support for SWIFT MT messages as well. Together with that we created a custom adapter for another financial institution; which will eventually be replaced by a standard payment message format (SWIFT MT or ISO 20022).
The key feature TMS's and financial institution's need to provide is the support for payment standards - a standards based implementation reduces time and cost and increases changes of successful implementation. From what I have seen so far, support for either the ISO 20022 (preferred because of the XML based implementation and improved definition) or the SWIFT MT format is required.
Netted Payments: The next key implementation need was the ability to net payments and transfers originating from an investment/portfolio management system (in this case it was Sungard's Virtual Portfolio Manager) and generate netted transactions to multiple financial institutions- the business benefit being the reduction in the number of transactions (wires) and thus cost. Netting capability for payments is a new feature that was introduced into the EFT module and here is a quick overview of its capabilities.
Some of the interesting challenges related to netting were in ensuring that the appropriate validations were in place so that a user does not net transactions that they were not supposed to be netted together, the ability to make sure that a netted transaction that was originated as a payment or transfer is not made available to be netted again, associating appropriate accounting treatments and approval processes to each payment. As part of the netting capability we introduced a transaction manager - a dashboard that lets users manage transactions, import, sort, filter and net. As has been our practice, we have made this functionality fairly configurable and ready to meet the next implementation challenge.
As a final note, one feature not to forget is Ad Hoc reporting capability. I have discussed the importance of reporting multiple times before, so would not go into details again. However would add that no business system or software should exist without a powerful and secure reporting engine- it solves so many problems and is typically very beneficial to users of the system.
Thanks for reading, I will discuss additional features and benefits in a later post.
Monday, February 01, 2010
Recently I saw two job postings on Linkedin, I saw both on the same day which is probably why I noticed the subject matter of this post. There is something very surprising in these postings, if not bothersome. Here are some of the typical needs that you may expect and see
Prior Experience, Forecasting, Daily Positioning, Bank relationship management capabilities, Certification etc..
Now, here is the other set of requirements for a Treasury Analyst that I will discuss today which are also very common to most postings out there.
Proficient in advanced Excel or MS Access and SQL
or in some others
Must have experience with Sungard products or Oracle suite of Treasury Management Products or another vendors products. Some even go to the extent of saying that the Treasury Analyst should have worked on one of these systems for more than 2 years.
If you get a chance, please go through some of the job postings out there in the Treasury Management space. There is a good chance that you will be surprised as well.
From what I understand of business software applications (treasury management systems or treasury workstations included), the primary goal is to help the business function; whatever that function may be. Help via automation, faster processing, elimination of errors, repeatability among other but primarily - Efficiency. On a side note, I still remember (I can almost hear him even now!) an old teacher of mine yelling "Efficiency, Efficiency" on the top of his lungs explaining applied sciences and engineering.
There surely has to be something wrong with the job postings mentioned above. After all, you can't expect to add another totally different and unrelated skill set set to a cash analyst's resume and then hope that it will help with efficiency of the core skill set.
If you look carefully, you would realize that there is one of the two possibilities for the job postings mentioned above. What is even more interesting is that these two possibilities are interconnected.
Let us take the need for specific software product experience for a cash analyst first. The very reason that a specific product has to be mentioned in a job posting for a user of the system indicates that there is a learning curve involved. Users of the system have to spend considerable amount of time understanding and learning the product before they can be functional users of the product. Hence the need for specific experience; after all we all want to hit the ground running.
Now the first point. If someone is interested in expertise in MS Excel, Access and SQL it is unlikely that the organization has a treasury management system. They are making do with something less, something which was never meant to be a treasury management system. Why? Here again, chances are that these organizations realize that making do with something lesser but something much more common like MS Excel is better than hunting for users with expertise in a specific vendor's product.
Going back to my applied science and engineering reference earlier, the very point of using software is to make a business function easier, better, faster. It is to improve efficiency. Unfortunately, a lot of the products out there have missed the point.
Our group of engineers here at the Treasury Sciences are trying not to make these mistakes by providing better usability, better and faster training via product videos and making the adoption process smoother. In fact, our most important selling point or differentiator is that we can get your organization and users up and running on a enterprise class Treasury Management System faster than anyone else.
Our hope is that there will never be a job posting that says "Need cash analyst with 2 years of experience with Treasury Sciences products".
Thank you, feel free to email any comments to sujith@treasurysciences.com.
Friday, January 15, 2010
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.
Friday, October 30, 2009
If you have met with us, or watched either Ravi or I speak about our product suite or if you have spend even a few minutes on our website; you would know that our primary focus is to make sure our customers adopt a solution that meets their unique needs in the lowest possible timeframe.
We understand that most Treasury Management Systems out there provide most features and functionality that a typical organization needs. The challenge is and always has been in meeting those specific needs of a customer in the shortest timeframe possible.
In order to help faster adoption we provide fully functional trials of our product vs. an extended RFP process. We have also discussed extensively about the benefits of Prioritization. To reduce upfront training effort we provide web based videos of each feature within the product suite. From a technology standpoint, the solution was to create a product that is based on standards and one that was configurable.
Typical TMS's support a certain format of accounting treatment per transactions, the more configurable ones let you choose from multiple options they provide. This won't necessarily meet your specific needs. Secondly, if your organization has multiple subsidiaries chances are that you have to do extensive customization (read software development, consultants and time) to get automated connectivity to the multiple backend GL Systems. Finally, synchronization between backend GL Systems and the TMS could take considerable amount of time and resources to implement.
We believe that our solution addresses these issues in the best possible way. The rest of the post discusses these features.
Configurable Accounting Treatment per Backend GL System or Subsidiary
We let you configure the specific accounting treatment fields per subsidiary upfront using a web based interface. So, you can create 2 fields or 10 fields based on how you have setup your accounting system to capture data- essentially meeting the requirements for any backend system. The ability to configure accounting treatments per GL system or subsidiary eliminates customization that is typically required.
Capturing Accounting Treatment Upfront
We believe that the best place to capture accounting treatment is upfront- when you create a payment in EFT or when you create a forecast either using a web based interface or via a bulk upload of transactions or via an automated transmission (details on forecast can be found here). Accounting treatment entered by end users is used in the GL Export after these transactions are processed by the banks (received by our system via automated CD/PD files) - thereby ensuring STP to your GL System.
Rules based application of Accounting Treatment
This is another approach to capturing accounting treatment, via rules that you can create within our system. These rules will dictate what accounting treatment will apply to what transactions.
Standard XML Output to GL Systems
We use XML extensively throughout the product and we use if for our GL Export capability as well. Use of XML provides us the ability to create a standard output that can be easily transformed via adapters into any format- that any backend GL System may need. Note that we could write these adapters for you or you could write it yourself.
GL Synchronization
If you need GL synchronization services - eg: ability to replicate accounts created in your backend GL system automatically into the TMS, the integration is standardized and simple. You can push an XML files via secure web services exposed by our system. Additionally, if there is a need to accommodate true synchronization (changes made in either the TMS or GL, reflected in both systems), that is possible as well.
We believe that the ability to capture configurable accounting treatment, the use of standard formats and transformation capabilities reduce the time to integrate to one or more GL systems considerably. If you would like to hear more about these capabilities of have some questions or comments on our approach, please do let me know.
Friday, October 23, 2009
In this post I will highlight typical challenges in implementing a short term cash forecasting system and discuss the options we provide as part of our product suite to address cash forecasting needs.
Most potential customers and customers that I have talked to understand the importance of cash forecasting and have some form of cash forecasting capability- they have some systems that contain partial forecast data or could possibly provide partial forecast data. If not systematic, most organizations at least have a spreadsheet or multiple spreadsheets.
Typically, most organizations lack in timeliness and accuracy of their cash forecasts and in decision making capabilities based on consolidated enterprise wide forecast data from say multiple subsidiaries or multiple systems.
We will look at how we could help address timeliness and accuracy of consolidated enterprise wide forecasts systematically via our product suite.
Bulk Upload of Forecasts
If your forecast data is stored in a spreadsheet or can be put into a spreadsheet, we provide you with the ability to upload the spreadsheet into the system. This is the easiest and fastest way to manually upload multiple forecasts from multiple subsidiaries into the system. There are multiple value added feature associated with this as well- such as the forecast dash boards which lets users view the forecasts, edit and delete forecasts as well as roll back complete files that were uploaded into the system. You can reimport rolled back files as well.
Ours being a web based system users with appropriate privileges can upload data or view forecast data across subsidiaries and geographical boundaries.
Automated Import of Forecasts
Automated integration of forecasts from external systems that originate these forecasts via transactions (trades from a Trade Management System, Debt Payments or schedule from a debt management system and EFT origination data from an EFT system are examples) is the best way to ensure timeliness and accuracy of forecasts. Via a standard XML and web services exposed by our system, we have the ability to integrate with any system there is - provided the system we need to integrate with is an open system. i.e. the external system or an intermediate system needs the ability to communicate to a web service.
If you were to choose our Electronic Funds Transfer Module or upcoming Debt Management Module, it is already integrated to the CMO Module for Cash Forecasting purposes. Here again, there are multiple value added features that ensure upto-date information reporting and accuracy such as the creation of a forecast in CMO as soon a transaction is originated and the removal of the forecast from CMO if the transaction in EFT were to be rejected by an approver.
Manual Creation of Forecasts
We provide you the ability to create manual forecasts as well. Users with appropriate privileges can use web based forms, you can create and manage forecasts. This feature is typically useful while forecasting incoming transactions from systems that do not have integration capabilities.
Echo Backs
This feature is typically useful to forecast bulk payments. Say your AP system send a bulk file systematically to a bank with no human intervention. For forecasting purposes, we need to find out the appropriate amount that was sent to the bank with the appropriate value date. Now, there are 2 approaches to getting this data - (1) we could connect to the backend A/P system via the external integration capabilities discussed earlier or (2) we could have the bank tell us what they received- which is essentially the echo back.
An echo back is an automated transmission from the banks that lets our system know the most upto-date information on the bulk payment file. This communication typically contains totals and value dates and is sent by the bank as soon as it receives/processes the file. Our system in turn creates appropriate forecasts for the respective value dates automatically.
The four capabilities discussed above provide the ability for an organization, no matter what their situation is, to forecast enterprise cash accurately in a timely manner. There are multiple value added features in addition to the specific options listed above such as forecasting dashboards, calendar based views, ad hoc reporting capabilities, automated and manual reconciliation of forecasts, ability to capture accounting treatment on forecast creation and integration based on standards, all of which would help your organization forecast better.
Please do let me know if you have any comments or questions @ sujith@treasurysciences.com
Friday, October 16, 2009
Treasury & Risk magazine recently announced the finalists for this years Alexander Hamilton Awards- the awards and summit program is scheduled for October 28-29 in New York. we are pleased to announce that we were selected for an award in the Solution of the Year category, which is the ONLY category that was open to product vendors.You can find details about us and the other finalists in various categories here.
We believe that it is a validation of the quality of our solution to be chosen for a prestigious Solution of the year award. I would personally like to take this opportunity to thank our entire product team for their focus, efforts over the last 2 years.
Also thanks to our customers who have either adopted the product or are currently evaluating our product for all their valuable inputs and feedback. Your inputs have enabled us to incorporate best practices into the product, thereby improving the product for all.
Here is a part of what we submitted to AHA, as part of the award submission. The section below outlines some of the benefits a customer of ours achieved by using our solution.
We will be in New York on the 28th and 29th of October for the best practices summit and the Alexander Hamilton Awards. If you are attending the Alexander Hamilton Awards, please do join us between 10:45 and 11:45 AM on the 29th. Additionally, if you would like to know more about the product or meet with us in NewYork on either of those days, please do send me a note at sujith@treasurysciences.com or to Tina or to Ravi ( listed on our contacts page). As always, you could request a detailed demonstration of the product or sign up for a free trial by sending us a note or via our website.
Look forward to seeing you at the awards.
Tuesday, September 15, 2009
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.
Saturday, September 12, 2009
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.
Friday, August 28, 2009
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.
Sunday, August 16, 2009
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.
Friday, August 14, 2009
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.
Previously I have discussed some of the reasons why RFP's are not really the way to go when you are deciding on an appropriate TMS that meets your specific enterprise needs. Here is an excerpt from it where we discuss prioritization issues.
It typically takes an organization between 3 months to 8 months to create the RFP. Add another 3-4 months for the first round of responses, another 3-4 months to evaluate the responses and eventually select a product. That is well over a year in just the selection process. It is important to note that after that year of extensive selection, users in the Treasury would have seen the chosen product maybe once or twice during one of the product demonstrations. When implementation starts, it is typically a "Big Bang" approach and all modules are implemented across the board. Even if the implementation is done module by module, it still takes the better part of a couple of years to get the implementation completed and for users to start using the solution, or more likely beginning vendor product training courses to learn how to use their new solution.
In a separate post I had also discussed some of the demerits of lack of prioritization, especially if you are adopting a Treasury Management System for the first time or if you are considering a replacement solution for an existing solution.
There are multiple reasons why a mid market company would stay with Excel Spreadsheets even when they realize that the best practice to manage cash and forecasts is via the use of a Treasury Workstation. The first and most important factor is the time and cost investment required to get a classical workstation up and running. Higher cost leads to the obvious problem of return on investment, that being the next deterrent in the adoption of a Treasury Workstation. We have discussed the issue of time invested and return on investment before in the blogs. What could be the other reasons?
The answer could lie in over complicated Treasury Workstations and how organizations adopt them. Consider any Treasury Workstation that is available in the market today and you will realize that almost all of them promise better Cash Forecasting, Straight Through Processing, Integration with multiple banks and multiple formats and extensive reporting features. They are all correct, good Treasury Workstations help provide all of the above benefits and more. The real question to ask here is whether your organization needs all of the above on Day 1, agreed these benefits would be good to have but then again do you need to realize all of these benefits on the day you adopt a new Treasury Workstation? How about a simplified,prioritized approach instead of the typical all or none Treasury Workstation implementations?
This post primarily deals with perils of a typical implementation scenario for TMS that involves the adoption of a wide range of product features and functionality at one shot. If you look around, chances are that you will see 2 large groups w.r.t TMS implementations. The largest group as described in my previous post is the "None" group- they have not implemented a TMS yet and they have some good reasons for it. The second largest group (way smaller than the "None" group) are the ones that have tried TMS implementation expecting it to solve all their problems (All Features..), albeit with limited success. There is a third group- the ones with successful TMS implementations but they are a very small minority.
Let us take a step back and look at what a successful implementation of a TMS may be. Very simply put, a successful implementation of a TMS should ensure adequate ROI. There is no other way to judge.
The investment here as you well know includes internal resources and related costs, consulting costs, the cost of the product and implementation, the time factor and opportunity costs. The returns would be better management of cash and additional investment opportunities and reduced operational costs. The upfront and ongoing investment is what gets impacted considerably by adopting the "Big Bang" - all functionality approach. This is typically caused by 2 factors.
First, the most common feature in most RFP's is that there are questions in there about almost every treasury management or related capability. In responding to such an RFP request, most vendors provide excruciating detail on each of the product modules or features and invariably saying "Yes". The important question to be asked here is whether the customer that is putting out the RFP really needs all of the functionality requested? Note that there is a big difference between finding out details on product capability and deciding to use all the features available on day 1.
Secondly, most vendors out there do not provide the ability to pick and choose features based on prioritized needs of a customer. The ability to pick and choose modules and features within modules is critical to prioritization. Together with this, vendors need to make available an upgrade path. One that lets customers start out with say a trial version, then upgrade to a base version they are comfortable with and one that meets their high priority needs and eventually when they are ready adopt any other features or modules based on their priorities. Most vendors do not provide seamless incremental adoption capabilities.
The two factors mentioned above combine to create a typical "Big Bang" implementation. If you look at an implementation plan that is created; it typically has a schedule that includes implementation planning details for all of the product modules or features. Depending upon the organization and needs, this plan could last months and even years in many cases. However, there is no definite way to foresee what your needs will be in 2 years time; by which time you are done with the product implementation. Yes, you can do all the upfront analysis needed and take appropriate risk mitigation measures as any good project manager would tell you- but there is unfortunately no way to know what your needs and priorities would be 2 years down the line.
If you have chosen the "None" approach and have not implemented a TMS yet, I can safely assume that you understand the above picture. Needs change over time. Delays and extensions that result in additional internal resources and change orders to product vendors are costly. In most cases, organizations end up with a product that meets a certain percentage of their needs. They stop at that stage because there is no justification for additional investment.
Let us make an attempt at risk mitigation for a TMS implementation; note that mitigation approach is a bit different in the case of software products. If you were purchasing a TV, you would know that you can only connect as many components (DVDs, Blue Ray etc) to the TV based on the number of inputs available on it. If you have more components you will need an additional piece(s) of hardware. You will not even think of upgrading the number of inputs on the TV- because it is costly, time consuming and nearly impossible to do when considering ROI. Software is sold as a commodity or as a customizable commodity now. What is important to note here is the "soft" in software. It is not a piece of hardware or a utility or device that is set in stone. Unfortunately some software is created badly and hence is not configurable. However, it is important to know that there is software available that lets you pick and choose the features and functionality you need; when you need with extensive configuration options. Let me stress configurability a bit more - in this context, it could be the ability to add banking relationships seamlessly, or to upgrade or change your GL System or to change your positioning process by centralizing it or decentralizing it. All of the above and many more should be achieved purely by configuration of software within a very short time window. Some of the tasks mentioned above could be accomplished in days. None of the tasks mentioned above should take weeks or months or require extensive custom development.
Assuming that you have found this configurable Treasury Management System, lets us go back to our implementation plan. You could redo your Implementation plan such that you meet your most immediate need first based on the priorities defined for your organization, then the next one and so on. Extensive planning is only needed for your most immediate need, so you save a lot of time and associated cost upfront and spend your resources only when you need to. Your chance of success and adequate ROI is considerably higher.
At Treasury Sciences we believe that a simplified prioritized approach is not only possible but desirable, because it has enabled our customers to adopt a solution that can be both easily and incrementally adopted as well as continuously adjusted and improved without costly internal and external investments. i.e. Incremented successfully. My next post would look at additional barriers to adoption of TMS. Please feel free to post any questions or comments; whether you agree or disagree with the post. I would highly appreciate your inputs.
Wednesday, August 12, 2009
Even after a few decades in existence, Treasury Workstations and the more comprehensive Treasury Management Systems (TMS) have still not been widely adopted by corporations and government organizations. On the other hand, many adopted solutions have required organizations to commit significant costs and lengthy deployment cycles on solutions that may not meet some of their significant treasury operational needs. Although vendors have recently introduced new versions of products that attempt to overcome some of barriers to adoption; there continues to be a relatively low adoption of TMS, Note the excerpt below from the Annual AFP Benchmarking Survey conducted last year.
50% of organizations do not use a system! It is important to remember that this is in-spite of many studies and recommendations and proven examples of benefits of utilizing a robust Treasury Management System. What is further more interesting is that even after these many years, there is no Treasury Management System vendor that has achieved a near decent market share.
The above chart reflects that even the most well known vendor (Sungard) has only a market share of 6%. Manual processes and spreadsheets retain almost 50% of the market share among products that are used to manage cash and the only other double digit market share solution is the multitude of treasury functionality offered by banks via their business banking portals.
Spreadsheets provide no historical data storage, very limited to no audit capability and are most prone to user error. Honestly, it is downright embarrassing that established vendors in the Treasury Management System space have not yet been able to provide a viable alternative to potential customers. In the next few posts, we will look at possible reasons as to why it is difficult for customers to cost effectively adopt a TMS and present potential alternatives that may help increase the likelihood of their adopting a product that meets their needs.
Saturday, June 06, 2009
I have been explaining why a trial of a Treasury Management System is better than let us say- any other approach to adoption. To summarize it, I find no better way than to do a top 6 list.
- See if it fits your Treasury's operational Needs. The elementary test to pass here is the first one and trying it out helps you know first hand- not from demos or product manuals or help manuals or the perfect sales pitch.
- Does your team or potential users like to use this product? This is key and here is why. If your forecasting process is cumbersome and painful, chances are that no will use it, and as a cash manager you have limited visibility. The system should evoke responses such as "That was easy" and "Does not take much time to do that" and not "Well, do I have to do this every day? and "Can't the system create forecasts as soon as I originate a payment?""
- Only true test of the configurability of the system. Ask to make a change, specify exactly what you need and see what the response is, and surely your Treasury Management System vendor has to provide you a very specific answer. Pointing you to a well written document or presentation that explains integration capabilities will no longer work.
- Evaluate support team responses if you have questions during the trial period. You will know what to expect.
- Easy and fast Adoption. If your key team members are using the product already to evaluate it, they are much more likely to start using the product on day 1 of adoption. In other words, your team does not have to read a "How to Manual" or attend a series of training sessions. Better still, you will not have to pay for those training sessions either.
- Evaluate actual (not Expected) benefits of the system by comparing the new product to the old solution or process. This is critical as you would see the advantages of using the new solution first hand. And if there are disadvantages, you will know those upfront as well.
A Trial of Treasury Management Systems upfront could lead to the choice of a product that presents the least possible risk to your organization.
To top it off trials are free. Yes, it takes some of your time but it would be well worth it in the long run. BTW, if it takes too much time to get started with the trial, it may be time to move on to the next product on your list.
Thursday, April 30, 2009
After a recent presentation we did at TMAC, I had the opportunity to speak with someone who had just implemented a web based Treasury Workstation. He was happy with how things were except for the lack of effective ad hoc reporting functionality (the functionality was there but not all data could be reported on). He also mentioned that he liked how we did reporting and had some questions regarding that. Had a product evaluation been available, this customer may have been able to make a more informed decision. However, That made me think of our story again, as in how our ad hoc reporting functionality came into existence. Let me start by referring to a previous post on treasury workstation reporting capabilities here. In that post I was discussing the cost benefits of utilizing a consolidated reporting solution. Now, here is how I describe our Ad Hoc reporting capabilities
Ad Hoc Reporting enables customers to report on any piece of information stored within the system, provided the user who runs the report has access to the data. Yes, you can choose your fields, add multiple conditions, save it, share it and export the data. Users can perform all of these tasks by watching a 5 minute video.
The above sentence pretty much describes our capabilities with reporting at a high level. In this post, I will discuss how our Ad Hoc reporting capabilities came about and how we ensure that the above mentioned features are met successfully. It all started with a need, the need for a first large implementation of our product at a large customer. The cash manager told us that (I almost remember this quote verbatim)
"Well, we have 90 reports that are there in our current systems, I am not sure how many our users use but there are 90 in total. We can try to eliminate the number of reports by speaking to various users but then again, we cannot be quite certain".
Note that we are a mid sized company and access to a large number of developers is not always easily available. We have our constraints and that in some ways promote creative efficiencies within our software development teams. To answer the need of our customer, our product architects decided that we should build an ad hoc reporting tool. That way, we did not have to create a multitude of reports and users could create reports to users themselves. Our development team would not have to create any more reports, ever again.
Currently, we have customers trying out our product online, we are doing multiple presentations and demonstrations of the product and almost every time we are told that our ad hoc reporting capabilities are excellent, the best in class. So, thanks to a need from our customer, our constraints and most importantly sound decisions made by our product architects. A need and a challenge has resulted in an asset. You can read more about our software development thoughts and other products on our parent company blog and directly from a product architect of ours here and on his personal blog here.
Tuesday, April 28, 2009
Multiple times over the last several months, I had the opportunity to speak with Treasurers and Cash Managers at various organizations, both small to medium size companies and large ones. One of the questions that come up very frequently is regarding the tangible benefits of using a Treasury Workstation, more so a Treasury Management System. Yesterday, one of our customers had to put together a list of benefits they derived out of using the Treasury Sciences Suite of Products. So here it is - the list of benefits
Dramatically simplified the accounting review for daily banking activity by reducing 10 pages of daily accounting journal entries requiring review to 1 page of entries requiring review and 9 pages of entries directly uploaded to the General Ledger. We’re enhancing the technology to further reduce the need for any manual review prior to upload.
Over 80 users have been boarded with a goal of over 200 spanning multiple subsidiaries and such user groups as: Accounting, Disbursements, Payroll, and Cashiering.
Currently processing about 25% of the Organization's wire and ACH payments through the new payment platform, replacing 3 different Bank of America payment platforms with a single user interface. At completion of the conversion project, 100% of these payments will go through the new system.
Developed intuitive user screens that allowed a simple web delivery (webinars) of online training which simplified the roll out process to remote organizations.
The majority of daily investments and redemptions of investment cash by our subsidiaries (about 80 transactions per month) are now paperless (replaced faxes and emailed notices) and secure (no Faxes, emails, or telephone calls)
o Eliminates missed settlements
o Allows straight through processing with accounting treatment printed directly on bank reports
o Ensure identity of all users
Central delivery of online bank reports reduces bank fees by $10-$15K per month.
Faster, more accurate determination of daily cash position is giving the Treasurer’s Office detailed funding requirements for the day about ½ hour earlier, which translates into improved investment yields.
Better identification of cash available for investment is allowing us to reduce balances left at our bank by about $3-$10 million per day and upgrade them for better investment returns by making them available for direct investment by the Treasurer’s Office
I hope that the above list (I have only altered it enough such that it does not reflect the name of the customer and any other confidential data) provides a tangible list of benefits of adopting a web based Treasury Management System or Treasury Forecasting. If you have any questions, or comments or feedback please let us know by posting a comment here or sending us an email. I hope that this information will help you in your decision making process-when choosing a Treasury Management System or Treasury Workstation.
Monday, April 06, 2009
That is the title of our first white paper in the series of white papers on Treasury Management. You can read it here and if you have any questions or comments please let us know by posting a comment here. Also, here is a quick excerpt from it.
Saturday, March 28, 2009
The talk about switching from Excel Spreadsheets to Treasury Workstations is now at least 6 years old. The switch has been listed as a best practice for Cash management by multiple experts but still, in any meeting or a conference if you ask for a show of hands for companies that use Excel Spreadsheets for cash Positioning, you are likely to see a few. Typically the percentage is at least 20 and if your audience is largely mid market companies, then chances are that the percentage of companies that use Microsoft Excel Spreadsheets for cash positioning is much higher.
There are multiple reasons why a mid market company would stay with Excel Spreadsheets even when they realize that the best practice to manage cash and forecasts is via the use of a Treasury Workstation. The first and most important factor is the time and cost investment required to get a classical workstation up and running. Higher cost leads to the obvious problem of return on investment, that being the next deterrent in the adoption of a Treasury Workstation. We have discussed the issue of time invested and return on investment before in the blogs. What could be the other reasons?
The answer could lie in over complicated Treasury Workstations and how organizations adopt them. Consider any Treasury Workstation that is available in the market today and you will realize that almost all of them promise better Cash Forecasting, Straight Through Processing, Integration with multiple banks and multiple formats and extensive reporting features. They are all correct, good Treasury Workstations help provide all of the above benefits and more. The real question to ask here is whether your organization needs all of the above on Day 1, agreed these benefits would be good to have but then again do you need to realize all of these benefits on the day you adopt a new Treasury Workstation? How about a simplified,prioritized approach instead of the typical all or none Treasury Workstation implementations? Let us look at some of the benefits we discussed above and see how it applies to mid-market organizations and adoption of Treasury Workstations. Note that some of the thoughts on prioritization could well apply to larger organizations as well.
The ability to get banks to push transactions automatically to your Treasury Workstation is a very useful feature. But most organizations that have been using Excel Spreadsheets for cash positioning would be downloading transactions from their banks. It takes anywhere from 2-10 minutes to download multiple files from a bank system. As a first step you don't really need automated communications with banks to download your reporting files. This is especially true if you have fewer banking relationships, which again is true for many organizations. As the need arises for multiple updates through out the day and if you decide to have multiple banking relationships, you can decide to add this feature. By not automating the download of files upfront, note that you have eliminated one of the most time consuming activity in adopting a treasury workstation- working with IT Teams at a bank(s) and setting up the communication.
If the Treasury Workstation your organization is adopting provides Ad Hoc reporting capabilities, chances are that you can create a report that can be imported directly into your GL System. Yes, it is a manual step but then again you have eliminated a major integration task upfront. You can add this feature as you go along, when this feature becomes your highest priority. Similarly, you can provide a web-based interface to multiple users/departments to enter your incoming and outgoing forecasts. Yes, Integration with payment system would have been better, but integrations take time. Integration with a payment system or a bank for echo-back transmissions could be prioritized for a later date.
Now, say that your organization adopted a simplified approach to adoption and adopted a web-based Treasury Workstation. What are the benefits your organization will have on day 1? You have the ability to forecast cash, upload bank transaction files and reconcile transactions with forecasts and create your daily, weekly and monthly Cash Positions. Based on the rules supported by your Treasury Workstation, you may even have Automated Reconciliations. You would also have a multi-user system and with centralized Ad Hoc reporting, the ability for multiple users to create, save and export data from your system. You also have centralized storage of data, unlimited transactions over an unlimited period of time that you could use at a later date to create your Long Term Forecasts based on historical trends. Yes, you have better controls and improved audit-able data (each action by each user user is stored) as well. Since you eliminated most of the time consuming activities upfront, chances are that your Treasury Workstation would cost a fraction of the cost of an employee. Are these not benefits enough?
Now consider this, if your organization is willing to take the above mentioned approach, your externally hosted, web-based Treasury Workstation could be up and running in less than a week.
Friday, March 20, 2009
There are countless articles and multiple presentations that talk about Treasury Workstation RFP's. Articles range from how important selecting a Treasury Workstation is to how to go about making that selection- invariably pointing out that the best way to do that is via the RFP process. I am sure that you are well aware of it by now; if you are not, do a search on google and you can find out for yourself.
Here is how it works in short. You decide to finally retire the old Treasury Workstation or Excel based system that your organization has been using for countless years. The next step is of course to see what is out there while fixing or defining your internal controls and processes better. Now is time for the request for proposal or the RFP. Some one in your treasury organization or in some cases an external consultant is hired to write a detailed and extensive RFP. From responding to multiple RFP's over the last couple years, I can tell you that these are often very very detailed. They are so detailed typically that they cover almost every topic and every need in the space- a recent RFP that we responded to specified a need for Cash Positioning, Bank Polling, Reconciliation, Debt Management, Investments and Electronic Funds Transfer to name some.
It typically takes an organization between 3 months to 8 months to create the RFP. Add another 3-4 months for the first round of responses, another 3-4 months to evaluate the responses and eventually select a product. That is well over a year in just the selection process. It is important to note that after that year of extensive selection, users in the Treasury would have seen the chosen product maybe once or twice during one of the product demonstrations. When implementation starts, it is typically a "Big Bang" approach and all modules are implemented across the board. Even if the implementation is done module by module, it still takes the better part of a couple of years to get the implementation completed and for users to start using the solution, or more likely beginning vendor product trainning courses to learn how to use their new solution.
It has been a few years since the organization decided that it needed a new Treasury Workstation or Cash Management Solution. In a year, a lot can change- new technologies, new rules and regulations, newer standards, new business scenarios- almost everything can change. We recently talked to a prospect of ours who had spend 3 years on implementing a solution. Unfortunately, at the end of it they did not like the product they adopted- it did not meet their needs.
It may be the case that RFP should stand for "Roadblocks For Progress" instead of "Request for Proposal"!
Now let us ask the all important question- After spending a few years in getting a comprehensive solution in place would the organization have the courage, the time, the money or management approval to check out another solution that seems to work better; just in case there are problems with the newly adopted solution? Sorry, but chances are that they are stuck with it.
An alternate and more agile approach would be to request Trial Versions of products that are needed. If the Treasury Workstation solutions out there are truly web-based, easily deployable and configurable to your treasury processes, they should be able to provide you a free trial within a week of your request. Do your cash positioning in parallel on the trial system for the first 1-2 months that you would otherwise spend on creating the RFP. Yes, do request for a feature list, identify what is supported or not and request for demos. Most importantly clearly identify your processes and needs- your current and future needs. However, do not do the extensive multi year RFP process. Get vendors to fill up a check list, ask them to demo the product to you and request that you need to try out the system for 1-2 months. You will not only have a system at the end of 2-3 months, you would also have a system that your users are comfortable using - you hit the ground running. Note that an RFP cannot tell you how adaptable and configurable the product is- A Free Trial of the product lets you do that first hand. Repeat the process for the modules you want to adopt based on your priorities and you will have a treasury solution that meets current and future needs, adoption will be easy and you will have the ability to change- especially if you choose a modular product that is easy to integrate.
So the next time you consider issuing an RFP, think about requesting a Free Trial from your vendor. It may just end up saving you a lot of time and money and you will get a system that meets your continuously changing needs.
Monday, March 09, 2009
Here is another excerpt from our white paper series that we are currently working on. Here we are talking about Bank Independent Payment Solutions and benefits of using such systems.
By moving payment initiation to the Treasury Management System, a standardized payment file, executable at any bank or at multiple banks, can be achieved. This allows the payment initiation process to become bank independent. De-linking payment initiation from a particular bank provides the flexibility to change banks seamlessly or use best of breed payment services from multiple banks (one bank for domestic wires or one-off ACH another for foreign currency payments). A bank independent solution also ensures that your users only have to learn one system for all electronic payments even though the payments are delivered through multiple banks. Bank idiosyncrasies are eliminated and forms to complete payments are all similar regardless of payment type or bank used for execution. There’s less chance of error and better leverage for pricing and you are free to move your payment execution to a new bank.
A key factor that facilitates bank independence is to build or use a payment engine using a standardized payment protocol such as the ISO 20022 payment standard. The ISO standard is a universal standard for payments which supports ACH’s, Wires and Drafts. Several major banks either support the standard or are in the process of supporting it. The ISO 20022 standard can also be used to submit SWIFT payments without requiring the use of a proprietary SWIFT payment format. In addition, the US Fed Wire system has announced that ISO 20022 will be used as a basis for its announced expanded payment format.
Monday, March 02, 2009
We are working on a series of white papers on best practices for Treasury Management, here is an excerpt form one that talks about configurable approval workflows for one-off enterprise payments. The final white paper will be posted on our website, when ready. So here it is..
Configurable Payment Approvals
Bank Independent systems allow organizations to replicate their electronic payment approval process instead of following the ones prescribed by bank proprietary payment solutions. Customers can setup simple 2-step payment origination and approval or choose multi-step approval processes and avail rules based selection of the workflow depending on multiple parameters such as the transaction type, subsidiary making the payment or account.
An indirect benefit of the use of a configurable workflow engine is to enable both centralized and decentralized approvals simultaneously. Transitioning from centralized payment approvals to a decentralized approach can be easy and systematic, organizations can setup 2 workflows – one for centralized and one for decentralized model. To start off you can associate all subsidiaries to make payments via the centralized model replicating your current scenario. Then as your subsidiaries are ready to move to the decentralized model, you can switch those subsidiaries to follow the decentralized workflow.
Finally, you can implement your processes such that they enhance fraud prevention. For example, organizations can set the workflows and rules such that administrators who have most privileges in the system cannot participate in payments or require two administrators to work together to create or change an account or include multiple levels of approval for payments over a certain amount.
Sunday, February 22, 2009
Last week I had the opportunity to travel to Cleveland, OH and speak at the monthly meeting of NEOTMA. I presented a case study on how the University of California adopted a new SaaS Treasury Management Solution. It was a wonderful experience and I had the opportunity to meet with and speak to some great people. Towards the end of the presentation someone from the audience asked a question and that is what this post is based on. The question (not verbatim, but the basic premise is intact) was
"It is good that the new solution helps increase investments and reduces costs, but what about Return on Investment? When will a treasury adopting a treasury management solution achieve enough ROI to cover the costs of implementing the solution itself?"
I thought that this was a very good question and very relevant considering the current economic situation. The answer lies in the Pricing Model of the Treasury Workstation or Cash Management Solution.
Classical Treasury Workstation implementations would require very high startup costs. This would include multiple things such as licensee fees for software, consulting fees for multiple consultants from the workstation provider, a team of people working on connectivity to banks and of course your internal IT team working with the technology team from the workstation provider installing the new system at multiple locations. A process improvement consultant is of course an additional cost. What all of this translates into is a a multi million dollar investment upfront (not to mention the several months to implement), before you even start using the product. Now, say that all goes well and your improved processes and system helps you invest more cash or save on banking costs. It typically takes you a while, in the order of years to recover your upfront investment.
From a cost and ROI perspective, the solution, as I mentioned above is in the Pricing Model. And this is one of the areas the new wave of hosted, SaaS (Software as a Service) Treasury Workstations are different. They eliminate or considerably reduce upfront costs and allow for month to month contracts that let you pay for what you use. Our solution for example, does not require much upfront investment at all. Yes, there will be costs associated with internal process improvements and we highly encourage you to do that. Factors that add to a workstation implementation cost such as license fees, internal IT team costs and installation costs are completely eliminated. Bank communications cost is considerably reduced because of our reliance on new technology and global standards. We no longer have to create and test software that sends and receives information (payments, acknowledgements, reporting etc) as we already have done that with most major banks. Even if we have to, our software is configurable enough to accommodate these additions easily via configuration and not via new development. In most cases, we are able to get a customer up and running in the order of a few weeks to months with very less upfront cost. They pay on a month to month basis and are not required to sign a long term contract. As you may have noted, newer technology and standards helped create this pricing structure.
Implementing a new cash management solution should result in more invested cash and better processes. Eliminating most of the upfront costs ensure that an organization implementing the solution spends less upfront and does not have to go through an extended period of time trying to recover the cost. Immediate ROI.
Wednesday, February 18, 2009
I have to say that this post is a no brainer. It is not a brilliant idea or something that would require a process improvement consultant. However, it is something that a lot of us miss somewhere along the way. Even if we realize it; we may consider it not very significant and/or our technology solution may not be sophisticated enough to handle it.
Let us look at a simple, yet very common scenario. Jill, A user at a subsidiary of yours needs information on a certain transaction. How does she get it? She goes to the respective bank website and downloads a report that contains the details of that transaction. She has the information she needs and you don't even know about it. Yes, if you were to look at monthly bank costs, you would see a small insignificant payment for the information that was downloaded. One among the many other such small insignificant payments that you make to the bank.
Now, consider this. You have already downloaded the information Jill wanted earlier. The details of that transaction was available to you via the prior day and current day files that you had received from the bank earlier. Would it not be better had you shared this information with Jill? If so, you would have saved on the small cost you paid for that transaction. And many other similar transactions. The solution as I mentioned upfront is simple. Have one consolidated data warehouse of all transactions from all the banks that you have relationships with and enable your users access to this database via a web-based interface.
This scenario played out almost exactly as I described above for one of our customers. They had adopted our enterprise reporting module is saving anywhere between 10-15k USD a month, by just having our reporting module be the one front end for all its reporting users, all over the world. Again, no one could predict that the saving will be this high as there were so many different reports being generated from multiple banks at multiple locations. Once the solution was implemented, the cost benefit was clear.
Have you looked at your bank reporting costs lately? Are you paying the bank multiple times over for the same information? There may be room for improvement, just by consolidation of data and having all your users access it from your new enterprise data warehouse.
Thursday, February 12, 2009
This is a very vague question but one of the most frequently asked questions. Most, if not all treasury workstation vendors answer this vaguely as well. The answer could range from few weeks to several months (read years) but everything depends on how complex your needs are. So essentially, the onus is back on the cash manager who is trying to get a new system for his organization. Having said that, there is nothing wrong with that answer. Agreed that it does not really answer the question but then again there are so many things that need to come together for a treasury workstation to work.
Let us look at those several things that need to come together for a classical treasury workstation to work.
The first one and possibly the most important one is the ability to connect with banks, get the prior, current and intra-day files. If your banking relationship is with say 10 banks then there is certainly a possibility that it will take a while to setup communications, do the one hour calls with technology teams daily, test if a file can be sent over FTP. you know the drill. The single most important factor that may help speed up this process lies within your treasury workstation, answer these questions and you will know- How robust is the BAI file processor? If you try to import a BAI file from another bank, how long will it take you to adjust to the idiosyncrasies of that bank? How easy is it to setup file transfer with a new bank? How easily can you use schedulers? If your cash management solution does all of that, then you should be up and running in a couple of months, at least this part should not take several months and years. The answer is Technology and how well your treasury workstation uses it. Most banks do take a long time to setup anything, could be several weeks to months but you can at least be prepared at your end, ensuring that your treasury workstation does not add to the timeline. Then again, how many organizations need to connect to 10 different banks to create a cash position?
The next one would be incoming and outgoing forecasts, How easy is it to get forecasts from your electronic funds transfer system, your debt management system and say echobacks from your bank in response to bulk payments and from an accounting system? The answers, there are two here - Standards and Technology. if all communication to and from you system is based on a standard, there is no work to be done at the treasury workstation end. What if our systems do not support the latest standards yet? The answer is Technology, that technology has come a long way now and that a team working with any product, be it accounting systems or payments systems should be able to easily output data in a certain specified schema in very less time, I mean in the order of 2-6 weeks with testing and testing again. One other thing to consider in the interest of time is if your treasury solution is available as a hosted solution (SaaS, ASP, hosted at a data center)? If it is, then there is very limited installation or setup time for these interfaces.
Then there is reporting. The answer here is Technology again. Does you treasury workstation have a robust ad-hoc reporting tool? If it does, virtually no time has to be spent creating those tens of reports; your users can create, save, print and export them as they need it.
Finally, I am assuming that all workstations provide basic cash reconciliation and positioning services. Again, if the underlying technology is robust and not a mix and match of multiple products and out-dated technologies, chances are that your treasury workstation can accommodate minor changes to say your cash management dashboard or add some additional information you need to the payment screens easily. All of these major setup tasks can be done in parallel, so should it really take 6 months or 2 years to implement a treasury workstation?
During the last couple of years, we have been through these issues ourselves. We have rewritten and updated our technology stack continuously over this period, especially true in the last 6 months. The only truth about technology is that it changes, almost often for the better. We are trying to keep up with it, the best we can. So the next time you ask the question about timeline for implementation of a treasury workstation, check the answers to see if technology and lack of standards is holding you back.
Powered by:
Copyright © Sujith Nair
|