Four obstacles to change
- Banks have rarely taken a hard look at their procedures. Enabling growth or launching new products has traditionally been their priority, achieved by adding new layers of product features and procedural requirements. This lack of procedural rigor has yielded highly complex business processes that prove very hard to automate.
- Mergers and acquisitions, product launches, and regulatory changes have left many banks with a complicated IT architecture. Redesigning entrenched systems can take up to five years and cost hundreds of millions of dollars. Banks must invest substantial capital and run the risk that, should the solution miss the mark or take too long to implement, the market may have moved on before the new system goes live.
- IT departments may have different agendas and lack the necessary understanding of business priorities. They typically discuss IT changes in a “black box” of architectural conversation and therefore fail to grasp the full spectrum of integration options. IT architects and solution designers, for example, may be inclined to use legacy techniques or to select the most technically exciting solutions, while IT vendors and system integrators have no incentive to reduce the complexity of the integration or the effort it requires.
- Banks often lack the internal capabilities to introduce more automated processes. IT departments have historically been trained to use waterfall methodologies1 when developing big projects. These methodologies1 are appropriate for developing and maintaining the traditional mainframe environments in which banks still run their core banking systems, but they are not optimally suited to automating business processes rapidly.
A new way to IT-enable banking operations
- Consider business priorities to simplify the process. Automating inefficiencies or unnecessary product features embedded in historical processes is pointless. By first defining the best processes from customer, business, and risk perspectives—taking a lean approach to process design—banks can significantly reduce what actually needs to be automated, which in turn lessens the cost, risk, and implementation time. A truly cross-functional team consisting of operations, IT, and business experts, as well as strong project governance, is required to design and enforce such optimal end-to-end solutions. The involvement of top management across multiple functions—operations, retail, and IT, for instance—is also essential.
- Use multiple integration technologies and approaches. The right mix of integration solutions, backed by a solid evaluation of each solution’s time to market and contribution to architectural complexity, enables banks to automate most of their manual interventions without rewriting or substituting legacy architectural building blocks. For example, banks are successfully creating work flow systems by overlaying business-process-management tools that connect separate legacy systems, which in turn eliminates manual data entry and related errors across end-to-end processes. This evaluation is not straightforward, however, and requires a thorough understanding of what the market for integration solutions has to offer.
- Prepare the IT shop for agile-development methods. To achieve rapid development cycles and use off-the-shelf solutions successfully, IT departments must build skills beyond their traditional capabilities. In particular, they should hire or train people who can assess the software market and apply the right solutions, as well as develop systems in-house; who can run agile or iterative development projects; and who are capable of working seamlessly with business and operations counterparts.
- It decided which processes would be fully automated, partially automated, or fully manual, based on four key tests. The tests determined whether a process was too complex to automate (for example, deal origination and structuring), whether regulation required human intervention (for instance, the financial-review process), whether or not the process was self-contained (that is, dependent on multiple customer or third-party interactions), and whether manual touch points added value to the customer relationship (for example, product inquiries).
- It designed the building blocks of the target application architecture, which consisted of legacy systems and off-the-shelf applications, as well as the IT infrastructure requirements, to provide timely and necessary computing and storage.
- It derived a design-based holistic business case for the automation program and defined the rollout plan.