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.