Dashboards and Analytics Overload in CBS?
However, head office still needed staff to run data analytics for top management, and to fine tune reports downloaded from software. This paved the way for development of Analytic and Business Intelligence (BI) tools, and the use of software for data analysis. The tools provided information for decision-making at a few clicks. The BI tool, which resided on a data mart, could use the underlying data for tailoring reports as per demand. Though this was partially automated, there were challenges in providing online data from multiple back-end systems to the tool for further analytics. Some of the big banks used full-fledged data warehousing solutions to collate the data from multiple sources and feed the BI tool. However, smaller banks could neither afford comprehensive data warehousing /BI tools nor the higher vendor charges for support and maintenance.
This drove banks to approach core banking solution providers to develop the necessary dashboards within the module so that they could perform analysis using the large data available within the database. Whereas front-end users created transactions, it was the top management who used the dashboards to analyze data in the form of:
a) Number of transactions processed
b) Number of users processing the transaction
c) Turn Around Time for completing the transaction
d) Turn Around Time per user
e) Transactions above a particular value etc.
f) Data wise/period wise analysis
g) Peak time transactions
The above is only a small sample of possibilities out of a huge list spanning transaction-based/ risk-based/ profitability-based/ regulation-based analyses.
Since all data was processed within the module, presentation and display did not provide many challenges to the software developer.
However, the requirement of dashboards increased in every module/software solution to eventually become a necessity. Increasing demand for graphics/charts of different kinds added a different dimension to analysis. This resulted in complex engineering of software solutions to meet increasing client needs. With competition intensifying within the core banking space, most providers enhanced their solution offerings with dashboard and analytic functionality. Slicing and dicing of data using dashboards and analytics in multiple display dimensions was seen as unique selling points or differentiators for software solutions.
To conclude, core banking solutions, which were developed for centralized accounting, and modules intended for creating customer data or processing transactions were engineered quite a bit to meet analytical demands. Although it is important to evolve software to meet increasing client/market demands, software solution providers should focus on developing key functionality in the modules, rather than analytics, which can always be handled by external software. Demarcation of functionality and analytics for development needs is necessary in order to avoid excessive re-engineering of the software, which often makes it heavier and causes disruption. Though software automation enhances the quality of decisions by improving data accuracy and analytics both, top management might still like to exercise some amount of personal judgment, outside of what machines and technology can enable.