Systems Integration for the Financial Manager: A Practical Approach
Weiner, Jerry, The Journal of Bank Cost & Management Accounting
Technology. There was a time when using technology and being a technician were almost synonymous. In order to understand and manage the growth of automation in a bank's operations and accounting processes, a financial manager would have had to become a systems engineer proficient in the language of bytes, baud rates, and a whole array of other technical terms.
For the most part, this emphasis on the technical has led to the development of good daily operations systems for loans and deposits. As an industry, banks process transactions well. At the same time, they lag in the overall integration of operations systems with financial accounting and management systems. For this weakness they pay dearly. In order to acquire the data needed for good financial analysis, most banks must extract data by hand from one computer and reenter it manually into another. In the process, they spend far too much time and money.
Even worse, most banks enter transactions into their general ledger computer from non-customer subsidiary ledgers such as accounts payable, fixed assets, investments, and inventory. In some cases these subsidiaries operate on completely different computers. These inefficiencies drain even more time and money from other, more productive activities.
But there is some good news. Both in-house systems vendors and service bureaus are integrating financial management tools with their day-today operations processing systems. By taking advantage of this evolving trend, financial managers can simultaneously improve the quality and accuracy of their financial information while increasing overall productivity. As a financial manager, you do not need to be a technician as long as you learn how to use technology effectively. The trick is in knowing how to work with technical experts to get the systems integration you need.
MAINFRAMES AND PCS
At first glance it might seem that this entire integration problem would go away if a bank would simply run all of its applications, operational and financial, on the same computer. All the data would be stored in the same place and could be easily integrated.
The only problem with this concept is that most good day-to-day operations systems have been built by people who understand operations very well. Unfortunately, these are the same people who get weak in the knees whenever words like asset/liability and investment portfolio accounting come up. That's only fair. The people who build financial management systems don't usually appreciate all the day-to-day nuances of a deposit accounting system.
This lack of cross-disciplinary understanding isn't the only reason that banks don't have fully integrated financial management and operations systems. The other major factor in the equation is that these two types of applications have been developed on completely different types of computers.
Operations systems require lots of computing horsepower to drive the on-line transaction networks which account for customer populations measured in thousands and even tens of thousands. These systems have grown up in mainframe or--more recently--minicomputer environments that can support the wide number and variety of terminals, printers and other peripheral devices needed to get the operations job done.
Financial accounting and management systems, on the other hand, have matured on PCs. They are relatively low-volume applications that are often run on an iterative basis. They usually require data from the core operations systems, as well as other externally generated information.
There are, of course, financial systems that run on mainframes or minicomputers, and there are PC-based operations systems designed specifically for banks. General ledger is a good example of a common mainframe-based financial system. It is also a good example of the distinct differences between operations and financial systems.
The general ledger sits at the intersection of these two system types. …