Printer Friendly

Treasury and IT integration in plain English: Part III when treasury shares.

We can argue from now until sun-up about the way in which treasury and IT should integrate. Where the question is managing information or initiating transactions, it almost always boils down to one of two broad protocols:

1. Using a treasury-specific application called a "workstation" or "Treasury Management System" (TMS) that gathers information from banks, initiates transactions, structures "deals," and, generally, provides "middleware" functionality bridging the outside world with a corporation's internal financial systems. When treasurers purchase workstations, they typically play a lead role in the system's selection and implementation. Some vendors use "interface" over "integrate" to describe what they do, but differences can be obscure.

2. Using the treasury module of an Enterprise Resource Planning (ERP) system. Such modules have improved over the last couple of years, but generally still focus more attention on integrating within corporations than between corporations and the outside world. Selecting and implementing an ERP is typically a corporate activity, the final decision made at the CFO or even CEO level, the best overall solution selected to support a diverse range of activities including treasury but usually dominated by accounting and other issues. Treasury has a place at the table during selection and participates on the implementation team, but may not play a lead role in either activity.

The mechanics of managing and moving information, initiating transactions and doing deals are only a small part of the integration job. Whether or not treasury has titular responsibility for IT integration, there are critical elements of project leadership for which treasury must take responsibility, and the cost of not doing so, or doing so in a passive-aggressive way, may be disaster.

This third and final article in our "Treasury and IT Integration in Plain English" series takes a look at some of those things and offers advice about why treasury must assert leadership even if CFOs or CEOs are calling the shots at enterprise levels.

Treasurers have kept an eye on their employers' assets and financial risks since King Henry I of England gave Nigel of Ely the keys to his vault in 1120. The job has changed a lot in 875 years, but important elements have remained. Regardless of what we call it these days, treasurers are still responsible for managing their employers' "stores of value," they identify and manage most risks, certainly major risks of a financial nature, and they are their employers' forward-looking "eyes and ears" with respect to future developments that might impact on things financial. That's not everything treasurers do, of course, but they are very important things when it comes to IT integration.

Managing the "Store of Value"

Remembering Walter Wriston's observation in the 1960's about information becoming the new money, a treasurer's first jobs in 2003 are probably understanding how better information, and information better managed, creates value, then deciding how best to apply this knowledge for the company's benefit. That involves education for both treasurer and staff.

Fifteen years ago treasury staffs needed enough training to turn on a computer and download a balance report. They may also have had to use "canned" packages that facilitated key entry of account analysis and similar data for report production. Ten years ago, they were working with Excel spreadsheets or Access databases, sharing information over local area networks, and five years ago the Internet emerged. IT integration requires a different level of knowledge and skill. The technology is more complex. Treasury staffs have their own issues to resolve as integration projects get underway; they also have to understand and help communicate everyone else's issues and speak their language. Treasurers and their staffs need to get trained before the game begins.

Then the staff has to do some major soul searching to identify what is not working to the treasurer's satisfaction and creating a vision of how it should work better in the future. Given both treasurers and CIOs put "human resource constraints" at the top of their headache lists, finding either the time or the people for soul searching and visioning over IT integration will be a challenge, though company-wide integration projects mandated at senior levels usually come with implementation support. Similar help may or may not be forthcoming when projects are driven from a departmental level. Vendors typically operate on tight budgets and focus on operational training when contracts are modest. Problem solving usually encompasses neither soul searching nor visioning without significant expense, and integration may fall short of seamless linkage, either between treasury and IT or between treasury and external sources like banks unless treasurers deal with it themselves.

The vision of some treasurers may not extend beyond a command to "Install a Workstation." That decision will suffice in many cases, producing benefits that outweigh risks or costs. Automating the daily cash position is a major step forward for companies that previously relied on spreadsheets and multiple balance reporting connections. The same can be said for automatically preparing general ledger transactions, tracking maturity of debts and technology vendors and banks--seldom sing in investments and similar activities that have been included in treasury software solutions for more than a decade.

But it will probably not satisfy a treasurer committed to really transforming the function or a CFO familiar with the tools and technologies that have redefined "finance" in recent years. A more discerning treasurer will survey what peers have accomplished and what tools are available, examine the entire function in detail, identifying opportunities for process improvement at all levels, then incorporate vision and requirements into a plan for senior management action. The plan will consider both current needs and future contingencies. It will take time and resources, it may get completely shot down, but it will be what has to be done to manage the "store of value."

Treasury cannot rely on IT or any external provider to do this job completely, nor should it. Two of the reasons integration projects have failed in the past have been (a) the assumption someone outside of treasury, an IT professional, for instance, completely understands what treasury needs and does and (b) technology and software can solve all problems. A treasurer committed to transforming the function will insist on playing a defining role even if the job is only part of the total integration process because treasury differs from most other corporate areas, and success demands that differences are put on the table.

Treasury success depends on intimate knowledge about how the world works beyond the firewalls that separate IT from everyone else. Treasurers are accustomed to working with multiple vendors, indeed their success depends on working with vendors who differ from one another, and they understand how fast things can change, like payment systems, regulations, and bank services. Success also depends on thinking critically about all the business processes that support and are supported by IT. Treasury managers are the intellectual "middleware" that facilitate integration regardless of what software or platform gets implemented. They are central to defining the functional requirements that drive integration decision-making and implementation, and they are central to successful operation and evolution when implementation is complete.

Treasury IT Integration and Risk Management

Treasurers also manage risk, and risk is fundamental to the treasury-IT integration process in a way it is not to ERP accounting, customer relationship management applications (CRM) and even supply chain management applications (SCM). ERP accounting and CRM are internally focused; they happen within a corporation. Treasury operates in the world of external linkage and communications to a greater degree than other functions. Its role in managing internal corporate risks is understood; it is more subtle and complex with IT-integration because risks are both internal and external. They have to be managed differently, and they always have to be managed in balance. Treasury has the perspective needed to accomplish this.

Five or six years ago, functional differences between ERPs and TMS' were significant. Many early ERP treasury modules were naive to the point of embarrassment, freebies or near-freebie developers threw in to get a contract signed, often in the certain knowledge it would take two years to implement "core" ERP modules, by which time either something better would be available or the licensee would be so committed to a particular integration approach it had no alternative but to implement the developer's offerings ... or, perhaps, no remaining budget.

A lot has changed and continues changing. ERP treasury modules and TMS' have improved significantly, still templating themselves around a front-middle-back office structure but now offering a wealth of functionality and connectivity in all those areas, as well as a breadth of options for acquiring and operating that functionality. Increasingly, "web enablement" is playing an important role in Treasury operations, involving issues like security and fraud on the one hand, and changing business processes on the other. Today's treasury can operate around-the-clock because the web allows that to happen. It can manage on a global basis, and even companies operating only in the United States can write checks, access images, extract information from documents or invest funds from just about anywhere on demand.

There are now more than fifty commercially available approaches for integrating IT and treasury. As has historically been the case, the simplest remain little more than single-site software packages for downloading balance and activity data from banks. Several, some very sophisticated, are the deliverables of commercial banks encouraging use of their technology as a client's exclusive portal for treasury activities. Others are network-based or web-enabled applications for data gathering and transaction initiation across multiple banks and multiple currencies, automatically linking treasury with general ledger and budgeting systems inside the corporation and with trading desks, information and other services outside. As noted earlier, integration tools are available for purchase or lease, from outsourcing firms and over the web. Major suppliers, whether TMS or ERP, routinely "leapfrog" one another, adding and improving functionality, blurring distinctions among them. Some, unfortunately, have leapfrogged right out of the marketplace, and others are scrambling to assemble their next rounds of financing. Therein lies a critical role for the treasurer-as-risk-manager in the integration process.

For all the attention it gets in the financial community, once you separate the revenue streams of banks from those of the software community, treasury-IT integration is not very big business. Systems are purchased and used by relatively few corporations, and worldwide revenues are less than $1 billion. Solutions are growing in popularity, but many developers remain dependent on venture capitalists, and aggressive competition puts heavy demands on their financial and other resources. One important thing to consider: however treasury participates in the integration process must be a developer's ability--not only to survive, but also to rapidly evolve while simultaneously looking further into the future for new ideas.

And as integration evolves, treasury must continually assess its "providership risk," the ability of a vendor to meet not only the functional requirements detailed in an RFP today or those in a maintenance contract tomorrow, but also to anticipate how the world will change in the future and a developer's ability, financial, intellectual and technological to anticipate those events.

A corollary consideration for treasurers-as-risk-managers may be "transition risk" if a company chooses or is forced to make an alternative integration choice before" realizing the full benefits of an earlier investment or if some sudden problem occurs. There was a time when putting a copy of the developer's source code in a safe deposit box provided comfort in the event of bankruptcy, but the price of comfort is higher today and the process more complex. Underlying, "invisible," technologies change rapidly in a web-enabled world and software, for technological or functional reasons, can become obsolete in a short time. Consider, for instance, changes that will be occasioned by Sarbanes-Oxley or other legislation and the speed with which such changes must be made.

Questions of "providership" and "transition" risk management apply equally to financial and software providers. Both play a critical role in integration, and treasurers have almost exclusive responsibility for measuring bank performance and assessing risks associated in doing business with them. The major risk is one of operational, not institutional, failure. Banks have not responded uniformly to integration challenges. Many have had problems with web delivery, others with software interfaces. Still others have relied on intermediaries or service partners to complete vital linkages, and partner performance has been disappointing. Among other key risks treasurers must assess, whether it leads or supports the integration effort, is how well its banks will support the effort or at what price.

And even when "core" software is properly maintained in current form on a secure server, some vital link, domiciled on somebody else's computer, possibly in somebody else's country, may suddenly malfunction or even disappear, forcing an emergency workaround. A simpleminded, though painful, example of this occurred when several ASPs, providers of remotely accessible, shared software systems, went out of business with little warning. Even when backup was available and transition plans in place, time critical operations like treasury were affected. Software used to be self-contained, but in a web-enabled world that may no longer be the case.

Managing the risk of disappearing providers or of processing disruptions triggered by the failure of some system component involves more than treasury, even in its capacity as risk-manager. The role must be shared with IT and others, though treasury can add great value. In today's complex world of financial services delivery, there may be twenty vendors between the issuance of a check and the ultimate re-delivery of its paid, cleared and canceled image to a corporate client. The process may appear "straight-through"; indeed it will be carefully engineered to function "straight-though," only making problem resolution more difficult. A proactive treasury can play a leadership role on two important fronts. As the company's risk manager, it can establish responsibility for all the important soft spots between check issuance and re-delivery, within the firm and within the external services provider. It can negotiate service level agreements and contingency arrangements where appropriate, and as the company's primary relationship manager with financial services providers, assure that banks have similar arrangements in place in their areas of responsibility.

Eyes and Ears to the Future

Treasury's third role in IT integration should be as forecaster of future events. This should especially include events in the regulatory, legal and financial arenas, but treasurers can also be an important source of technology news, given that banks are usually in the van guard of such developments. Progressive treasurers will remain alert to such events and make certain their inputs are included in IT planning.

Legal and regulatory changes can be especially important. Sarbanes-Oxley is the most discussed piece of legislation having an impact on records retention and reporting financial practices, but it is only the tip of the iceberg. There will undoubtedly be Patriot Act ramifications in segments like education, and legislative agendas covering Homeland Security and audit reform have barely gotten off the ground. These will undoubtedly have implications for treasury, record-keeping in general and IT-integration in particular. Future changes, like Basel II, may even change some banks' appetite for product development, or just as serious, their concept of competitive service pricing.

Commercial codes are changing to accommodate new technologies, especially technologies that reduce or eliminate paper. Treasurers can provide vital input with respect to the substance of such changes; they may also identify opportunities for efficiency improvement and cost reduction. Banks, for instance, have been doing very sophisticated work with document imaging and records retention for their own and client purposes. Their knowledge and facilities may provide attractive alter natives to paper-based records management or in-house archiving and retrieval.

Payment systems are also changing, especially with Americans writing fewer checks. There are several initiatives in the financial community and Congress to (a) further reduce check writing, (b) remove paper checks from clearing and retention processes, (c) electronically capture paper checks, transmit and print them remotely to reduce check-related transportation costs. Some initiatives are already implemented; others are planned for 2003-2004, and they will have an impact on corporate accounting systems, account reconcilement and audit processes and other basic record-keeping functions. Again, treasurers can provide vital guidance to IT and accounting and may identify opportunities to further improve efficiency or reduce costs.

The point, in summary, is this: treasurers have a mission-critical role to play in IT-integration however removed they may be from "core" software selection. Even in the unlikely event treasury operates on a standalone basis, integrating itself with the outside world and building minimal interfaces to internal IT, it has historic and unavoidable responsibilities: for managing their employers' "stores of value," for assessing and managing risks and for providing insights about the outside world.

Richard J. Poje is President of R.J. Poje and Company. He can be reached by calling 847.304.9961, via e-mail at Richard@poje.com or visit www.poje.com.
COPYRIGHT 2004 National Association of Credit Management
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2004 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Selected Topic
Author:Poje, Richard J.
Publication:Business Credit
Geographic Code:1USA
Date:Mar 1, 2004
Words:2800
Previous Article:Rules based credit scoring: make the right decisions fast.
Next Article:Closing the loop: how credit scoring drives performance improvements along the financial value chain.
Topics:

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters