September | 2014
Since the financial crisis of 2008, financial institutions have shifted from a business development model focused on building client capabilities to one determined to extract savings. These savings are derived from operational efficiencies both on the process side as well as the technology side. Revenue growth has been challenged due to depressed markets and renegotiated commercial arrangements. In this continued low interest rate environment, cost takeout has established itself as the overwhelming driver of change.
The transformation environment for many firms has been one of long standing structured controls and procedures designed to provide as much risk mitigation as possible. The reality is that these status quo organizational structures are not only failing to mitigate enough risk but are also stifling a creative solution to today’s servicing problems.
An all too common approach to business transformation is to recycle old ideas through a repetitive analysis phase, often in a siloed manner, without consideration for the overall ecosystem. The best ideas are “green lighted” based on estimated benefits rooted in a plethora of assumptions; this is the “Art” approach to transformation. When the expected cost savings benefits are not attained, the fallback solution all too often is to force operations to make do with less by decreasing headcount. The current approach has a risky decision model since estimates are based on educated guesses, instead of empirical data. Most large firms lack a “Scientific” way to prove the usefulness, efficiency gained, or impact of transformative changes to the organization. The benefits gained (or lost) due to particular system or process changes are typically not measured until after the transformative change is made. This imposes unnecessary costs and risks that could be avoided if a firm could measure these impacts before they were introduced in production.
A traditional development cycle starts with a business solution document (BSD) detailing a system development need and requirements from a user’s perspective. If senior management approves this development based on the Return on Investment (ROI), the BSD goes on a prioritized development list awaiting a functional system requirements (FSR) write up. Once finalized, the FSR becomes the working document for the development team to begin coding. At the conclusion of the coding, all types of testing takes place such as regression testing, scenario testing and business user acceptance testing (BUAT). With the successful conclusion of testing, enhancements are rolled out from the test environment to the business users in the production environment. All of this is done without knowing:
In the next series of this blog I will put forth a solution to this conundrum. This is my perspective; I look forward to hearing yours.
Brad Payne joined Wipro in October 2011 with 23 years financial services experience focused on Fund Accounting and Custody for Mutual Funds, Pension Funds, Offshore Pension Funds, Bank Commingled Funds, Collective Trust Funds and Multi-Managed Funds. As an SVP Brad had responsibility for a team of 200 overseeing operational service delivery, client relationship management, business development, cross selling, fees/contract negotiations and P&L management, for several significant State Street Customers.
© 2021 Wipro Limited |
|
© 2021 Wipro Limited |
Digital Operations and Platforms
Engineering, Construction & Operations
Pharmaceutical & Life Sciences