RTBI Implementation strategy

Martin (2010) reveals that being successful has to do with understanding all the elements of success embodied in your organization. That is, a firm should understand first what will determine its success, before embarking on means to make itself successful. In this endeavour, Martin (2010) alluded to the fact that a business has to come up with metrics for performance measurement which would in turn be used to determine its success levels. Vesset and McDonough (2009) give credence to Martin (2010)’s claims by giving out that a strategy should allow a business enterprise to come up with key performance indicators (KPI), which subsequently guide the information needs towards business success. Fast response to business events is achieved by firms that have managed to perfectly knit their corporate strategies to KPIs (Pang, 2009).

Business intelligence (BI) is the very instrument with which an enterprise is enabled to juxtapose corporate strategy and actual performance of business processes (Quinn, n.d.). Adding agility to the latter, BI then morphs into real-time business intelligence (RTBI). Thus RTBI would then be that instrument which indicates the difference in strategy and actual performance as soon as this discrepancy is detected (Gravic, Inc., 2010) – assuming that the firm in question has managed to entirely convert its strategy into KPI. If an event can be found to be non-conforming to predefined business norm, then one of two things happens. Either, the RTBI automatically engages in mending the gone amiss transaction or, an instantaneous incident is logged to a relevant person for appropriate measures to be taken.

Drawing from conventional BI designs, which treat operational and analytical environments as purely separate and independent from each other, instantaneity in decision making cannot be achieved at all times (Gravic, Inc., 2010) – solely because event occurrence and event detection are separated by a significant measure of time. This is the one thing that marries RTBI to success according to Gathibandhe, Deogirikar and Gupta (2010). Gathibandhe et al. (2010) state that the value of data is directly proportional to how fast a business acts, upon receiving it. Meaning, instant action on any supplied data might spawn high business value while late action, might engender reduced or entirely lost value.

In this section the architecture of RTBI is developed, followed by the description of an information architecture that could be suitable for a robust RTBI solution. Since RTBI is viewed as an improvement from traditional BI (Azvine et al. (n.d.) & Lehman, Watson, Wixom and Hoffer (n.d)), it makes sense for the beginning point to be the architecture of the latter (see figure 1 below).


Figure 1. Conventional BI architecture (adapted from Gravic, Inc., (2010) & Azvine, Cui, Nauck and Majeed (n.d.)).

Figure 1 above depicts a common architecture or model that drives implementation of most BI systems, according to Gravic, Inc., (2010). Companies usually define several applications which are meant to support the various adopted business functions (such as human resource management, customer relation management etc.) (Watson, Wixom, Hoffer, Lehman and Reynolds, 2000). According to Gathibandhe et al. (2010), a BI would be partly, a system defined for collating data from the myriad data sources backing these applications into a common data store, called a data warehouse, via the extraction, transform and load processes (as depicted in figure 1). From this common data store, various techniques can be applied to manipulate the data into forms that are deemed intelligible to business users. Business intelligence is thus based on how the presented data is converted into business value. This value relies mainly on how the users interpret and combine these data into intelligence, moreover, on how these interpretations are discretionally applied to business activities.

Pang (2009) advices against a BI that presents users with data & information reports that are hardly linked to business goals, desired performance or governance. In such cases, only discretion determines whether business is performing towards a favourable direction or not. One might ask if the BI configured in such a way (that is, to process data for actually no clearly defined goal) really adds value to business performance? This would truly remain a mystery for businesses that view BI as a tool only endowed with the capability to refine, process and report on operational data, without the concern about the deeper revelations corollary to such data presentation. Data presentation (the analytical layer shown in figure 1) should be done on purpose, that is, reporting should be directly linked to what a business is trying to achieve, which is surely inscribed in the corporate strategy (Quinn, n.d.), and not on what decision makers guess based on intuition or ill-informed structures.

All in all, the model in figure 1 depicts a BI solution that locks out of the domain of its existence, business activity monitoring, the very essence which galvanizes the need for a BI solution within an organization (Azvine, et al. n.d.). In an attempt to further one of the previously covered topics (namely, The nexus between RTBI and business objectives), the following section explicates a could-be desirable RTBI model. This is performed by expanding figure 1 and discussing the added layers in a piecemeal fashion.

The RTBI architecture

In line with Raden (2008) who says decisions are made to solve problems, BI provides the platform to make and substantiate taken decisions so that problems can be better solved. But still, a business needs to know the priority and value of solving these identified problems. The added business performance management (BPM) layer (in figure 2 below) serves exactly that purpose. For real time intelligence generation to occur, prioritizing according to business needs becomes a necessity. That is, a business enterprise should know the cost and benefits proportional to the time taken to react to a business event. For example, if costs of business operation are escalating within a specific business unit, this event could be unveiled by the analytical layer, and confirmed in the BI layer as a business threatening observation. The BPM layer should expose the cost escalation before the waste runs for too long. This could prompt visitation to business activities in time. In addition, if costs are escalating because of known and expected causes, which for instance might be courtesy calls by call centre agents to promote new products or services to clients. The BPM could enable a decision maker to align this detected event with a predefined performance measure, and curb unnecessary panic to try and fix unbroken business operations.

Following the same way of processing, detected anomalies are sent to the real time response router (RTRR), which serves to decide the destination that is intended by the message originator (that is, is it a query for more information? A business process fix etc). Note should be taken that for traditional BI, reaction to events is purely manual (Azvine et al. n.d.). Analysts detect problems and manually engage in attempts to carve possible resolutions. RTBI is not meant to replace manual processing, as human action is immutable towards effective decision taking, but to supplement manual decision taking. Only in cases where remedy to given events is known that automatic processing can occur. What RTBI should aim for then is to streamline and refine business rules such that emerging events are spontaneously and automatically connected to business value. Therefore automation of correctional actions should be an adjunct task, and not the main driver of an RTBI solution.


Figure 2. RTBI architecture.

The RTRR deserves more attention since it is the heart of an RTBI-artifact. Pells (2009) gives out that current BI lacks the much needed interactive response between what is output from BI and what is antecedent to the output. This suggests that there has to be communication between both ends of a BI architecture. Murray (n.d.) ascertains the need for this communication layer by saying that BI solutions should embrace flexibility. The flexibility referred to here is three fold: one, the BI solution has to flexibly supply the information needs of all information consumers according their varying levels; two, the BI has to be endowed with a learning capability such that it builds up functionality as it is used to solve problems (Murray, n.d. & Azvine et al. n.d.), lastly, it has to be able to send tactical corrective measures back to the operational IT applications for speedy resolution to occur.

From figure 2, the BPM layer gauges overall business performance by contrasting actual business performance as drawn from BI, and the expected business performance as stipulated by trends that are embedded in the BPM layer. Also, from figure 2 above the interconnectedness of an enterprise’s information systems influences the pace at with instructions flow between the BPM and the preceding layers (Gravic, Inc., 2010; Gathibandhe et al. 2010). Thus for a firm operating on independent systems, the beginning point might be to establish robust and reliable communication among the disparate systems, followed by procuring and configuring capable hardware to support efficient live data movement between systems.

References:

1. Azvine, B., Cui, Z., Nauck, D.D. and Majeed, B. (n.d.). Real time business intelligence for the adaptive enterprise. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.194&rep=rep1&type=pdf (Accessed 14 June 2010).
2. Gathibandhe, H., Deogirikar, S. and Gupta, A.K. (2010). How smart is Real-Time BI? Available from: http://www.information-management.com/infodirect/2009_152/real_time_business_intelligence-10017057-1.html?pg=1 (Accessed 14 June 2010).
3. Gravic, Inc. (2010). The evolution of real-time business intelligence. Available from: http://www.gravic.com/shadowbase/whitepapers.html (Accessed 24 May 2010)
4. Langkamp, J. (2010). Business intelligence and performance management not very mature. http://www.information-management.com/news/BI_performance_management_maturity-10017885-1.html?ET=informationmgmt:e1526:2230379a:&st=email&utm_source=editorial&utm_medium=email&utm_campaign=IM_Daily_051710 (Accessed 06 Jul 2010).
5. Martin, W. (2009). Agile corporate management. http://www.wolfgang-martin-team.net/research-notes.php (Accessed 15 June 2010).
6. Murray, D. (n.d.). 7 principles for implementing high value business intelligence on a budget. http://www.tableausoftware.com/files/TS_Budget_BI.pdf (Accessed 15 June 2010).
7. Pells, D.L. (2009). Global business intelligence for managers of programs, projects and project oriented organizations. http://www.pmforum.org/library/editorials/2009/PDFs/june/Editorial-Pells-BI-for-PM.pdf (Accessed 09 July 2010).
8. Watson, J.H., Wixom, B.H., Hoffer, J.A., Lehman, R.A. and Reynolds, A. (2000). Real-Time business intelligence: Best practices at Continental Airlines. Information Systems Management 23(1):7:18.