Vol. 5: Dawn Period of Offshoring and Outsourcing in the Investment Banking Industry (part three)

Back offices of investment banks have traditionally been run at a high cost, a reflection of intricate and complex information systems and an inefficient paperwork process involving many different carbon copy paper slips. Correcting this requires devising and executing a plan for new information systems strategies. Bolstering the stability of information systems requires a shift from end-user computing with a personal computer environment in user sections to systems development led by IT sections and using a Unix environment. To ensure the success of IT projects, some players began developing hybrid managers.

The structure of back office systems in investment banks is more complicated than in commercial banks, given that the back offices of investment banks engage in cash and securities settlements (Note 1). Usually, the back office system of an investment bank has a three-layer structure, in which the first layer creates financial transaction execution data, the second layer is responsible for position management as well as cash and securities settlements, and the third layer is dedicated to creating regulatory reports, corporate actions, and accounting duties (Note 2). Any party that operates investment banking in Japan must ensure that a huge number of legal documents specified by the Financial Instruments and Exchange Law and its related rules are prepared by the back office (Note 3).

In the period from 1990 to around 1994, a large majority of investment banks had a conventional, paper-based process in their back offices, while only a few banks adopted digital back office processing with innovative information systems. These information systems were characterized by their intricacy, involving external systems, such as online-type and bureau -type systems, and internal systems. This complicated structure is jokingly likened to spaghetti.

Handling a huge volume of financial transaction data, the actual paperwork involved processing many different kinds of slips. These slips include, for instance, order tickets on which the front office describes the details of financial transactions, settlement instructions reflecting an order for cash and securities settlements from the back office, deposit and withdrawal instructions for giving instructions for the movement of physical securities, and accounting slips for paying and receiving cash deposits as well as processing interest and dividends.

These slips are usually made of multi-sheet carbon copy paper. The top sheet serves as the original and is controlled by the section responsible for the safekeeping of legal documents and other critical documents. The second sheet is stored as a copy of the original by the section that prepared it. The third sheet is sent to the data entry section, the fourth to the section responsible for reconciliation, and the fifth to the accounting section. Together, they form a complicated work flow. Far from the ideal style, an inefficient paperwork flow is supported by the spaghetti-like information systems in the back office already noted. A considerable workforce has often been assigned to the section performing data entry into diverse information systems and to the section checking the data output from these systems.

There were a great many cardboard boxes around the desks in the back office. These boxes contained a large number of handwritten notes and computer printouts of output data in a disorderly manner. Whenever necessary, staff members would recheck the documents. This was quite a common sight. Back office workers began calling for a solution that would free them from labor-intensive duties.

One such solution was end-user computing (EUC), based on PCs, and this approach was broadly adopted. In the 1980s, the MS-DOS environment varied subtly among manufacturers, such as IBM, Toshiba, and NEC. There existed what was called a compatible machine, which served as a bridge between different formats. In 1990, Windows 3.0 arrived on the market. Later, in 1992, its successor Windows 3.1 quickly swept the market to standardize most PC environments. The Windows environment helped make programming simpler for users. For example, users can add their own programs to the boot file, spreadsheets, database software, and elsewhere. Many different initiatives to automate the paperwork were made using this approach based on user programming.

In this EUC, a small number of skilled users act also as programmers and perform a wide range of duties, including software programming, administrative work in everyday performance of duties, data backups, and system upgrades. While achieving a dramatic reduction in back office costs, EUC also posed three major risks.

First, EUC is actively performed by a limited number of staff members with advanced expertise in both programming and administrative work. As a result, the dependency on these very skilled workers is liable to become excessive within the corporate organization. If any staff member leaves the company for some reason, the EUC-based administrative work flow may come to a temporary standstill.

Second, these excellent workers may well introduce EUC solely for the purposes of their own duties, as their original duties entail administrative work. Without strategic design from two perspectives, namely the administrative work process and the information system structure, EUC would result in one-off local automation. Consequently, an uneven system structure would emerge, where automation would be in place only in specific sections with top-flight staff, while other sections would continue to rely on manual work.

Third, there exists, without exception, a mainframe system at the heart of every information system in the back office of investment banks. Where administrative work is automated in a one-off and local manner, it becomes essential to transfer data between the automated system and the mainframe system by uploading and downloading it. Should there be any data processing error in the EUC operation process, the implications with a mainframe system are grave. This poses a very serious problem, in which a small operational error made by a EUC-based administrative worker has severe repercussions for the entire organization.

Sun Microsystems' Unix servers with the Solaris operating system very quickly seized significant market share in the early 1990s. Separate from EUC supported by the PC environment, information systems development done by professional computer programmers within the Unix environment gathered momentum.

In comparison with the EUC, in which users do the programming on their own, systems development in the Unix environment stumbled at the stage of grasping user requirements. To invent new systems in the Unix environment, users must as a matter of course provide programmers in the systems development section with their definition of requirements. It is not easy for any programmer in the systems development section with no experience in back office operations to obtain from paper-based descriptions an accurate picture of what the system wanted by users in the back office is like.

If users' requests are not accurately understood because of an inappropriate requirements definition, the resulting system may not meet users' expectations or the IT project may not reach completion as scheduled. The system development cost could eventually be higher than initially planned. In the field of systems development, waterfall, and other management methods are implemented in IT projects. According to the waterfall method, a check is performed by users at each of the different steps that constitute an IT project, such as planning, analysis, design, development, testing, and implementation.

To answer the question of what causes information systems development to fail to meet users' wishes, the schedule, or the budget requirements in IT projects, Dr. Peter Morris of the University College London (UCL) conducted a comparative study between IT projects and non-IT projects, such as those for building roads and bridges, and made some interesting observations (Note 4):

1. It is difficult to reach a consensus within the organization given that there are a wide range of ideas on strategic IT design.
2. IT projects tend to begin without a clear definition of the business model after IT implementation on the part of users in the requirements definition phase at the outset of projects.
3. The initiative in IT projects is chiefly undertaken by those with an engineering turn of mind and it is hard for them to fully understand what business model after IT implementation is envisioned by users.
4. At the stage of planning any IT project, it is difficult to identify all users who will be affected after IT implementation.
5. This makes it difficult to accurately compute the capacity required after IT introduction in the phase of IT project planning.
6. There are violent price fluctuations in the market for IT hardware and software.
7. Given that innovation in IT technology takes place every day, a new technology quite different from the one available at the beginning of an IT project may have reached the market by the end of the project.
8. If any IT solution based on any technology that fails to achieve a major position in the market is pushed, it may become necessary to switch to another technology that has successfully gained major status in the market after the introduction of IT.
9. Given that there are plenty of uncertainties including those discussed above, it is difficult to conduct an accurate analysis of the cost effectiveness of any IT project at the project planning stage.

In consideration of the points listed above, Dr. Morris argues that the requirements definition tends to constantly change throughout the course of an IT project. This phenomenon, he argued, was seen in many cases of system development relating to the back office functions of investment banks.

Back offices face several problems: high costs resulting from the spaghetti-like complexity of the information system structure and the inefficiency of the paper-based administrative process, one-off local EUC introduced by the user section, and the difficulty of achieving collaboration between the user section and the systems development section for Unix-based system development. There is a case in which attention is paid to the idea of using EUC as a prototype to overcome the problematic aspects of the back office.

As mentioned by Dr. Morris, it was widely known that many of the IT projects designed to replace the existing system with a new one were successful. Projects of this kind allow the systems development section to understand basic user wants by analyzing the existing system and to gain an overall picture of user definitions of requirements by checking newly supported features. These factors help the projects succeed. This inspires an approach in which a small model called a prototype is created before embarking on IT development, followed by verification of the requirements definition between the systems development section and the user section with the use of a prototype. This method is believed to be effective for IT projects for developing new systems when there are no existing systems.

In the practice of systems development for investment banks, there are some emerging initiatives in which EUC in the PC environment is perceived as a prototype for systems development in the Unix environment and in which EUC personnel in the back office are trained to become managers responsible for coordination between the systems development section and the back office in IT projects. Human resources in this category are called "hybrid managers" by Dr. Michael John Earl of the University of Oxford and his colleagues. (Note 5)

The next report will offer a further analysis of hybrid managers and discuss the problems of global information system management undertaken by investment banks.