Banks embarking on Enterprise Data Warehouse (EDW) projects have of late been on the increase. This is an impact of India’s primary regulator the RBI, asking PSU banks to implement a Central Data Repository, which is actually another avatar of a Data Warehouse (DW). While a DW does deliver great benefits, costs have been escalating irrationally. Not so long ago, large banks (in the 3000-5000 branches league) were able to implement an EDW by investing around Rs 50 crores including the cost of about 5 years of post-implementation support. Project costs today for the very same exercise have gone up by a whopping 100%. Besides the cost factor, most banks are dissatisfied with their DW.
This makes one ask: Is it really worth spending an astronomical sum for a DW?
Banks typically expect the EDW to enable reports, dashboards, trend analysis, product gaps and opportunities, analysis of delivery channels, performance tracking v/s budget, cross selling, promotional campaigns, risk management, ALM, AML, social media analytics, etc. Each bank must dispassionately examine its specific requirements and demand only required functionalities. Also, these requirements should be in phases, with each phase not exceeding 6 months. The DW project delivery schedule should be clearly defined. Wish lists and good-to-haves should be excluded in phase one.
While Data ETL should be a combined activity, the phases of data modelling and implementation of application for each of the requirements should be clearly defined in vendor agreements. The licensing fees and implementation charges should be paid accordingly. It does not make sense to pay licensing fees for the applications and database requirements from day one, if the usage comes much later. If necessary activating the processors can be synchronised with the processing requirements.
Agreements and contracts must clearly state that service continuation of the vendors would be subject to satisfactory performance and timely achievement of agreed milestones. This gives banks the freedom to drop the System Integrator (SI) if they fail to deliver on time. Also, the cost of each project leg should be clearly defined so that if the SI exits midway, the dues do not become controversial. Banks must also ensure diligent documentation of deliveries versus payments made to the SI/vendor.
Let’s also examine a traditional anomaly that provides safe haven to most EDW vendors. As a standard practice, almost all core banking vendors refrain from providing the Data Dictionary for their systems. This enables them to continually demand their ‘pound of flesh’ from unsuspecting clients. This issue has to be taken up by the banking fraternity along with the Indian Banks Association (IBA) to ensure that documentation of data, which rightfully belongs to the banks, is provided to them by the core banking vendors and other system vendors at no cost. Interestingly, this is a standard practice the world over. If this practice is not corrected on the home turf, Indian Banks will only continue to bleed.
With requirements defined, what is needed to achieve the desired objective would be a good ETL software, a good data mining software, a good OLAP software and a few other tools (depending on the expectations from the EDW). Apart from these, banks require hardware, that can store up to 10 TB or more of data (for a bank with about 5000 branches; and this can vary depending on the number of applications in a bank) and can address the processing requirements for all applications, the people cost for creating the DW Data Models, applications and support.
Banks must also take care to ensure that the cost of business continuity / disaster recovery planning is kept low. The number of user licenses also must be kept to the minimum. For instance, every branch or regional manager needn’t have a user license and they should only be information dashboard users. They can access reports relating to the other areas from shared folders. Care should be taken to ensure that only data relevant to the required applications defined by the bank are extracted and stored.
A third area, where costs can be controlled, is manpower expenses. Many vendors operating in India do not have high quality manpower to support critical activities such as Data Modelling. So activities take longer and banks keep getting billed. In this scenario, vendors take cover under the ‘unavailability of Data Dictionary’ justification. It would be prudent therefore to go for a fixed cost implementation with a clearly defined and phased delivery schedule. For support, banks must train their own teams to develop and run ad-hoc reports and analytics with limited support. There should be a provision in the RFP to reduce vendor support, if necessary or discontinue support, if found unsatisfactory.
A final word of caution: Vendors, especially some of the prominent ‘ivy league’ ones, are adroit at getting agreements signed, which are generally tilted in their favour. Exceptional care must be taken while signing agreements to ensure the bank’s interest. In fact it may make sense to add the following sentence in vendor agreements: “In the event of a conflict between the RFP, the Purchase Order and the implementation agreement, conditions in the RFP (and responses to the same) will prevail.”
Besides bringing down expenses, these considerations primarily protect the bank’s interests. If the tools are selected prudently, the cost for a bank with 4000-5000 branches can be brought down by at least 50%.
The author currently serves as a Strategic Advisor at iCreate. He was previously the Head of IT at the Central Bank of India from 2009 to 2012. Earlier in his career, he was the Head of IT – Foreign Offices at the State Bank of India, where he was one of the key members spearheading the domestic implementation of B@ncs24 and the implementation of Finacle Core Banking Solution in their foreign offices.
(The views expressed in this article are those of the author and do not necessarily represent the views of, and should not be attributed to, Banking Frontiers)