Today I had the privilege to be the guest panelist for the Corporate Executive Board’s Treasury Leadership Roundtable Cash Management Cohort webinar on “Trends
in Treasury Technology”.
These kinds of events are always
fun for me because I can deliver some of Treasury Café’s insights to a new
audience in a different setting. As an added bonus, the folks at the Treasury
Leadership Roundtable do most of the “heavy lifting” - I just have to show up!
However, since my short-term
memory is notoriously fickle, I decided it best to cover that event now while
things are still fresh in my mind.
Choices, Choices
For cash management and
related roles, a company’s treasury
function will utilize either a) the
organization’s accounting system
functionality, b) traditional spreadsheets and other
generic office tools, c) bank supplied
functionality, or d) specialized software systems referred to as Treasury Workstations (hence the title
of this blog post).
There are pros and cons to each alternative.
Option A – Jump In With the Accountants
The accounting system
functionality (and by accounting system I am referring to SAP, Oracle/Peoplesoft and others) is somewhat limited
compared to the specialized alternatives. It is also more cumbersome. It
can also be quite costly.
But the primary drawback in
my mind to this is that the Finance and Treasury
group is beholden to the IT department. And the IT is much more interested in serving the accountants than the Finance and Treasury folks.
It all makes sense, though.
It is difficult to see how it can be different. The accounting system is
typically of primary concern to accountants, not finance folks (see Why You Need a Finance Person for some of the differences).
Accountants
in an organization outnumber finance
folks by large orders of magnitude - 5 to 1, 10 to 1, 20 to 1.
CFO’s of
organizations usually emanate from the
accounting fold, which makes that group their favorite, and the source of
their technical chops.
There are a lot of Sarbanes-Oxley (SOX) requirements for
accounting, and since CFO’s are on the line personally when certifying the
validity of the accounting results, these issues get a lot of C-level
attention.
Let’s recap - the masses like it and the powerful elite
like it.
Now imagine being the IT
person assigned to the accounting system. You have two requests, one from
accounting and one from finance. Whose request
do you act on first, and whose do
you postpone until the tail-end of the three-year planning horizon?
Or when it is budget time,
and you need to give up 5% of the planned spend to hit the stretch targets, do you
take it out of the accounting projects or the finance projects?
In other words, if the
organization is going with option “a”, Finance
and Treasury will get the standard, delivered system functionality and nothing
more…ever!
They might not tell us this
outright. What usually happens is that any request is met by a lot of
arm-waving and concerns that it will take 1,000 man-years to accomplish the
request.
Option B – Jump In With Bill Gates
Option “b” involves using standard office software to manage cash.
This has the advantage of being
versatile and completely under
Finance and Treasury’s control, thereby freeing us from IT’s 1,000
man-years constraint.
For simple cash management
set-ups it can be the most viable alternative. The basic usage of these tools
are some of the more familiar to most
employees, so they can all participate without any significant training
periods or change management efforts.
Most software vendors earn
their living by maligning use of spreadsheets due to the risk of error and the somewhat more manual nature of the processes to use them.
These disadvantages can be eliminated, but generally require programming solutions in Visual Basic for
Applications. The software language skills might not be possessed by all of
the Finance and Treasury staff.
Option C – Jump In With Your Bank
Option “c” – bank systems - I
do not have any personal familiarity with, but am told that these are useful for very basic functions but
leave a lot to be desired as the needs of the organization become more
complicated.
And if we have more than one
bank, we end up using a lot of different systems to do the same thing, which
can be inefficient as well.
In addition, there is a great
loss of flexibility, as usage of one bank or another becomes an organizational
process and procedure issue in addition to bank services.
Option D – Jump In With People Who Want to Do Business With You
Option “d” – Treasury Workstations
– is the route that delivers to Finance
and Treasury the most functionality in an efficient package, overcoming the
drawbacks to options “b” or “c”, and usually priced much more attractively than
option “a”, even if we do not include the added benefit that IT is taken out of
the picture for the most part.
Workstations these days come
in two different flavors – installed software on the organization’s
infrastructure, and the Software as a
Service (SaaS) variety, where the software is hosted on the vendor’s
servers and is accessed via web portals. Each of these approaches has their
pros and cons.
The installed model plays better with the organization’s infrastructure
and is more “self-sufficient”. The software will still work the day after the
vendor goes out of business. Interfaces between programs are internally constructed
which also allows greater organizational control, though if we need IT to
perform some of this function we run back into the 1,000 man-year problem. It
is also more costly.
The SaaS model is less expensive because it is subscription based as
opposed to license based, and the vendor can leverage its scale to innovate and
include features more effectively. For example, interfacing with Bank A’s
system will be less costly for a SaaS provider because they can do it once, and
spread the cost of this effort over the x number of subscribers to the
software. Under the installed option all the interface programming costs are
borne by each individual company.
There is risk here, however. If the company shuts down its business overnight we are in a
major lurch. Years and years of data
might be lost forever. An emergency situation is created, which is likely
to occur at the most inopportune of times.
We Need WikiFinance, WikiTreasury skills!
The technology alternatives that
we can use to manage cash and other Treasury functions is one of the primary
elements to the Wikifinance, WikiTreasury
environment we are moving towards.
For this reason, and others,
it helps immensely to have a set of IT
skills in the Finance and Treasury group. This was one of the slides in the
Treasury Leadership Roundtable presentation, the ideal Treasury person as a mix
of both finance knowledge and capabilities combined with technological
knowledge of infrastructure, interfaces, and programming.
Let’s be clear - no software is ever going to provide 100%
of the needed functionality. There is always going to be a certain amount
of customization. This can take place within the Workstation software (if it is
installed), the interface process, or through “off-line” activities.
To the extent that our own
internal people understand the processes, the architecture, and the interfaces,
and have some modicum of programming capabilities, we are able to utilize the
product to the best of our ability while simultaneously making it work within
our organization’s infrastructure with the minimum amount of added inefficiency.
And we can do it without relying on IT and the subsequent 1,000
man-year problem.
Key Takeaways
There are several choices to be made when
determining the technology direction
of the Treasury and Finance area. Each choice has advantages and disadvantages.
In order to maximize the
Treasury and Finance area’s impact, key
technology capabilities, such as programming, architecture, and interface, need to be held within the group. This
cannot be outsourced without critical loss of control!
Questions
·
Which of the
options are you currently using to manage your cash and treasury functions?
·
What is the
status of IT skills housed within the Treasury and Finance area?
·
What steps can you
take today to enhance your capabilities?
·
Do you have a
roadmap for the future?
Add to the discussion with your thoughts, comments, questions and feedback! Please share Treasury Café with others.
Thank you!
Interesting article. I'm interested to read more about the concept of WikiTreasury. As a consultant with over 40 treasury workstation implementations under my belt, I have a few comments:
ReplyDelete1. Regarding the installed model of treasury workstations, and its interaction with IT. I've experienced the full spectrum, from IT departments who minimize their involvement to other IT departments that want to take over the project after vendor selection! I agree that the most successful implementations have treasury heading up the project, rather than IT.
2. Regarding both the on-premise and SaaS models of treasury workstations, I have found that the most prevalent planning ommission in planning, to be data accessibility OUTSIDE of the chosen solution. With an on premise solution, if there is direct access to the stored data and some knowledge of its structure, creative reporting and interfaces can be opened by, as you say, a good measure of technical ability in treasury. With SaaS solutions, we are at a statage in the technology's evolution where data is mostly available through the provided interface, although there are "export to Excel" and web service exceptions. The long-term vision of SaaS should, in my opinion, include "structured data access" on its roadmap. Some vendors will argue over this point, but this will eventually be the key provision that allows SaaS systems to "talk to" other systems, including internally installed or written accounting systems.
3. The availability of the raw, structured data that you accumulate in a treasury workstation also suits your caution about risking the loss of years and years of data. With such access, one would only have to ensure the regular export and redundant storage of treasury data to alleviate the risk. In fact, this can even bolster your negotiating position when contract renewal comes along, or if the SaaS solution is acquired and subordinated by a megavendor. If you have all of your data, you can choose a competing system and migrate to it. My clients who have had legacy data to draw upon have experienced significant acceleration in implementations and the ability to provide a steeper learning curve (steeper means learning more, faster because knowledge is on the Y axis) to consultants and staff, and better redundancy.
So there are my two cents. Congrats on a very informative article.
Henry,
ReplyDeleteThank you so much for your sharing the benefit of your insights on this topic, and furthering the conversation!
With respect to item #2 - am I understanding the comment correctly that the data is difficult to get out of the SaaS system in a way where it can be further used?
In item #3 access to the raw data and routinely backing it up was recommended on a LinkedIn discussion based on this post.
Henry, my question to you is have you seen the raw data as being compatible across systems? Say I use SaaS product A for 5 or 10 years and then want to go to B. Are the data schema's similar enought that the data can be moved easily, or is this another "1,000 man-year" IT project?
Thanks again for your comments! I hope you keep coming back.
I use to be the finance person with IT skills in the Treasury department. Management went that route to bypass the 1,000 man-year problem. I was able to develop many reports using a report writer that interfaced with the SaaS workstation. To paraphrase Henry, there is a shortcoming in the existing workstation technology that you can't connect directly to the data. I think as more companies want to easily share Treasury data with other systems, there will be a harder push for the vendor to provide that ability. The vendor will surely charge extra for this feature. I think this will be one item eventually addressed in the evolution of the workstation.
ReplyDeleteJamie,
ReplyDeleteThank you for taking the time to respond to this post!
This inability to connect with the data is very interesting. I think most would consider this a negative when making the Installed vs. SaaS evaluation.
It seems to me this would bring up Sarbanes-Oxley issues as well, there are a lot of data retention requirements, I wonder how can companies comply if they cannot access the data?
David,
DeleteThis inability to easily provide the data across the enterprise is a selling point for going with an ERP system instead of a SaaS workstation. It will depend on your need for enterprise-wide data and what you want to spend.
Surprisingly, we didn't have SOX issues with the vendor storing the data. Our internal audit thoroughly went through the vendor's data retention policies, backups, and controls.
Thank you for participating in the disucssion!
DeleteFrom what I have seen so far, it seems that as far as Sarbanes-Oxley is concerned one organization's major concern can be the next one's non-issue. There does not appear to be as much standardization as one would think, even within the auditing firms. I suppose it goes to show that organizations are as unique as people are.
Thanks for a good, thoughtful article. Having spoken to a group of treasurers on just this topic earlier this month at the European Treasurers Council in Brussels, I'm sure the future can't be spreadsheet-based, however easy it is for an experienced Excel jockey to come up with a quick fix for any given requirement. In treasury, as in most other fields, SaaS has to be the way forward. What's needed is a really robust API so that any competent developer can build links between external data sources and the SaaS app. It's happening in other fields all the time - just ask any salesforce.com user - and even with the greater compliance and security issues around the finance function, it'll happpen here too.
ReplyDeleteMike,
ReplyDeleteIt is certainly true that SaaS will be the way forward for many organizations. In addition, it will certainly make for a more compelling case if a strong Application Programming Interface (API) is available to address the data access issues mentioned by other commentors to this post.
A couple of questions along that route would be how much background does a Treasury person need in order to be the "competent developer", or will going that route require the IT group's involvement, forcing Treasury back into the "1000-man-year" problem?
Another question about going that route would be whether it will be possible to sync things up so well with the rest of the IT infrastructure so as to make long-lasting competitive advantage possible?
My guess is that neither the ERP route nor the Excel route goes away entirely. The former due to a strong single-platform philosophy, and the latter due to its universality.
Thank you for visiting Treasury Cafe and adding to the discussion!