The DIY Route Helps Enhance Customer Experience: Yes Bank
Added 22nd Feb 2012Umesh Jain, President and CIO, Yes Bank, shares his insights on what CIOs should watch out for when building their own.
CIO: When does it make business sense to take the do-it-yourself route?
Umesh Jain First, let me explain when it doesn’t make sense. I believe that for applications that are core to business operations or are complicated or standardized, organizations should go for off-the-shelf products. There is no point building your own software for anything that is commoditized and is going to be non-differentiating. You’d be wasting your time, energy, and effort by re-inventing the wheel. Also, it would shift your focus from your core competencies.
But the moment you want to increase your value proposition or add a market differentiator or a feature to enhance customer experience, CIOs could consider building it in-house.
Have you tried your hand at building your own?
Of course, we did. Two years back, when we envisioned our BI deployment, we wanted a very strong reporting platform. We built one based on four guiding principles. First, it was going to be a democratic platform, which means it would empower and enable people across the organization. Second, it was going to be a role-based platform. So, we needed to create dashboards that cater to different roles and requirements.
Third, we wanted an action-oriented BI, which means that I can pump a lot of information that requires action. And fourth, it should provide the right information to the right people at the right time—and in the right form.
These are the four broad guidelines we laid out for our BI vision. There was almost nothing in the market that came even close to what we needed. Some of the products that came a shade close were very expensive. So, we built our own platform called Kaleidoscope. Today, if I have to single out one of our biggest achievements in the last five years then building this platform would be the most significant one.
The moment users assume that their requirements will be taken care of without it being communicated, the time bomb starts ticking.
What benefits did it provide?
One of the major benefits was cost. We rolled out our BI project in 10 percent of the cost of packaged software. Another was competitive edge. Any technology I deploy—off-the-shelf—can be easily replicated by my peers. But the customer experience that I am providing cannot be emulated. So that’s the differentiator in our service and customer experience strategy. And that happens only when you empower your front-line with the right information and customer insights. This is what our BI initiative delivered.
Usually, in D.I.Y. projects CIOs are faced with cost overruns that put competitive advantage on the back burner. Why does this happen?
Cost or schedule overrun is a norm in the industry and there are scientific ways to minimize them. But unfortunately most organizations fail to follow that science or they try to be overtly innovative about it. When you are doing a white canvas development (custom-built), there are different types of stakeholders involved. These are business users, business analysts, designers, architects, developers, testers, etcetera. It’s very important to document even minute details of their needs.
The problem is, at the requirement detailing stage, users assume that developer will read between the lines to write programs that fulfill their needs. Now, what seems obvious to a user might not ring a bell with a developer. This creates a chain of communication gaps. We don’t pay enough attention to all the requirements (control processes, reports required, information security and architecture requirements). So you end up with a very skeletal business requirement document, which then translates to very poor code. This invariably leads to cost and time overruns.
What should CIOs do to address this problem?
There is a way to manage the delivery and supply side of a D.I.Y. project. CIOs should dedicate enough time to testing their product and employing the right amount of skilled people from the time the requirements are stated to the time the project is delivered. The moment users assume that their requirements will be taken care of without it being communicated, the time bomb starts ticking and eventually it explodes when the finished product arrives.
Sneha Jha is senior correspondent. Send feedback on this interview to sneha_jha@idgindia.com
latest Articles
-
CIOs Don't Need to be Business Leaders
Given the complexity of today's applications, it's folly to suggest that the future role of the CIO is less technical and more businesslike, columnist Bernard Golden writes. If anything, it's the opposite -- the business side of the enterprise should embrace technology.
-
10 Steps to Business Process Transformation
Spurred by the recession, CIOs have sharpened their focus on processes, as companies strive for greater efficiency, and transformed business models, believes Coonie Moore Principal Analyst at Forrester Research.
-
Keeping IT Up
How IT business continuity is challenged by four tech megatrends: Social, mobile, virtualization and cloud.
-
5 Things I Have Learned: Alagu Balaraman
Alagu Balaraman, former CIO and current partner and MD India Operations at consultancy firm CGN & Associates, has spent 20 years doing different things and doing things differently.

