Business analytics integration facilitates the rapid movement from insight to action. This is not usually a single step, but involves many steps, and initial insights gained from data exploration and discovery move on through more formal methods until something actionable is produced – usually some form of business rule or predictive model. Lack of integration will kill many such initiatives in the early stages – a clearly undesirable state of affairs.
Integration has several dimensions associated with it. Obviously it is desirable that the technology environment is integrated, in terms of both tools and infrastructure. But the sharper thorn is business integration. This typically does not happen unless forced, and the adoption of integrated Enterprise Resource Planning suites at the turn of the millennium (to mitigate millennium bug risks) imposed transaction integration on previously fragmented business operations. There are drivers for this in analytical applications, the most important being regulatory requirements. But the simple weight of analytical activities, with proliferating numbers of models, will force some level of integration – the alternative being analytical chaos.
The diagram above shows a simplified schematic of the business analytics cycle. Analytics initiatives should always start with a recognition of business opportunity or threat. The next step is often qualitative in nature, using data exploration and discovery tools that are typically visual in nature. The discovery process gives insights into data, and an understanding that cannot be gained any other way. It allows business users to get a feel for important features in the data and their impact on the business issue at hand. The next phase is more quantitative and involves the use of statistics and/or machine learning methods. This has its own cycle of activities and is iterative in nature, as analysts and data scientists weed out erroneous models, and fine tune the features that have most impact. The next step is crucial, and in most real-world situations often suffers from delays, errors and dislocation. Given a well tested analytical model it is should be fairly straightforward to bring it into production. The obvious mechanisms are a business rules management facility, the creation of libraries of such models which can be accessed as needed, a standard deployment language such as PMML (Predictive Model Markup Language), and possibly an API interface. Most often however the model is handed over to a programming team who might code the model in Java, or whichever language is used for such tasks. This creates a discontinuity which in turn leads to maintenance issues as models are modified, and the very real likelihood of errors. It is also an expensive way of doing things.
Once a model is in production it then becomes necessary to monitor its performance. An environment which allows thresholds to be specified, and alerts to be generated is ideal for this purpose. Should a model fail to perform well, it becomes necessary to revisit the quantitative analysis part of the cycle, and maybe even the qualitative part. Finally, since business performance is directly related to the use of analytical models, there is a need for a business performance monitoring, and ideally a means of correlating performance with the deployment of models.
This is the ideal scenario, and one which represents a ‘Holy Grail” of business analytics. As such it is a goal to be reached, and some organizations will be further down this path than others. And while we have primarily focused on the technology aspects, this ideal involves organizational, cultural, and conceptual changes in management thinking. The technology part of the equation, as always, is the easiest part. Responding to commercial, regulatory, and organizational pressures is difficult because it involves people. Nonetheless, integrated business analytics is where we are all headed, and necessity will be the driver.