Giving Business Intelligence the Business, Part 5

 

It’s the process … again.

This article concludes a series we’ve run on this blog during the past several weeks about Business Intelligence. During that time, topics have been explored that will be built out in a whitepaper I am writing on behalf of Quest with several of its key service and solution providers. The focus has been, and will continue to be, on the Business use of BI technologies rather than upon those technologies themselves.

I was discussing all this yesterday with Bill McGinnis at RapidDecision (http://www.rapiddecision.net/) one of the contributing vendors to that whitepaper series. Bill, by the way, is a familiar face at Quest events and will be at COLLABORATE 10 (About COLLABORATE). We were discussing Business User Adoption, a segment of that whitepaper, in two ways: that (a) business decisions are typically made within the context of a finite, definable process, and that (b) for information (i.e. Business Intelligence) to be effectively used (i.e. Business User Adoption) it needs to be available in the way in which decisions are made within those processes. The result is that BI tools need to be designed, developed, deployed and supported within the context of a decision process. Much too often (most of the time?) information such as Reports, Analytics and Dashboards are used to validate a decision being made rather than to reach the decision in the first place.

What Bill and I realized was that, just as any organization has a finite set of Transaction Processes that ERP systems automate and integrate, it correspondingly has a finite set of key Management Processes that require information from BI systems. By first identifying those Management Processes and the way in which information is used during those processes, BI can become truly relevant.

As an example, consider the Management Process of Sales and Operations Planning (S&OP), which supports the Transaction Process of Plan to Produce. S&OP is the process that any organization uses to balance demand (Sales) with supply (Operations). Yes, every organization has this process (small ‘p’) by nature, although many don’t define it or design it as a Process (large ‘P’). If done well, this process results in an optimal plan. If not done well, it results in a negotiated – or even worse – averaged plan. The key determinant may very well be the way in which information is used. All too often, each constituency enters such a dialogue armed with its own reports or dashboards rather than there being a consolidated set, commonly referred to as a ‘Single Version of the Truth.’

Two needs emerge: (a) BI products need to be tailored to specific Management Processes and (b) prior to BI development or deployment an organization’s BI team needs to engage its functional counterparts around the way in which such processes operate and the way in which supporting decisions are made. This is analogous to the process mapping portion of any ERP deployment.

Of course, this requires two things: (a) that an organization is prepared to define a Management Process in the first place and (b) that a strong I.T./Business Alignment exists within the organization. Both of these items are very hard to accomplish, but it may very well be that improving Business User Adoption may depend upon it. We may be kidding ourselves by continually deploying these systems without them.

The next blog series will take on this issue of Business/I.T. Alignment but will be delayed for a couple of weeks. My wife and I are beginning our move south, and I’ll be preoccupied for a while. The packers arrive in one hour.  

Regards,
Rick

Giving Business Intelligence the Business, Part 4

 

Interlude

“It was not a failure to collect intelligence, it was a failure to integrate and understand the intelligence that we already had”.
– President Barack Obama, January 5, 2010

This is a piece that I have been wanting to write for two weeks, but have been cautious of the direction it would take — until I read a column this morning by Doyle McManus, a columnist for the Los Angeles Times (doyle.mcmanus@latimes). That column focused on the subject of information sharing and the Information Sharing Environment (referenced below). The more I consider all of this, the more comfortable I become of the direction I will take.

Following the failed effort of the Christmas Day Lap Bomber, much has been discussed and debated of the causes and steps that need to be taken. But that’s not the point of this column; it’s the point stressed by President Obama. And as for the aforementioned column by Mr. McManus (and there has been much less publicity of this), it reported on the four year existence of the Information Sharing Environment (ISE), a governmental organization whose goal is to promote “our ability to gather, analyze, and share information and intelligence regarding those who want to attack us … by leveraging existing capabilities and aligning policies, standards and systems to ensure those responsible for combating terrorism have access to timely and accurate information.”

Rodin's Thinker in LEGO® - Copyright © A. Lipson 2001

And yet we still experienced a “systemic breakdown” as egregious as this one. Just yet another example of governmental incompetence, right? 

But wait a minute. Is this truly unique to government? If we think about our own organization, whether it be a business, a non-profit group, a university or, yes, a governmental entity, we can probably recall a recent incident of “systemic failure” of business intelligence. Where a faulty decision, or a lack of one altogether, was the direct result of the correct information not being available when and to whom necessary. Or, if you will, when the single version of the truth was not recognized. (By the way, that term, single version of the truth, is now represented by an acronym: SVOT.)

In thinking about all of this I was reminded of some research that was conducted in 2002 by the Council of Logistics Management (now the Council of Supply Chain Management) on the ‘Shadow Organization in Logistics’ (Shadow Organization). The subject of the research was an organizational dynamic in which the formal business structure is often in conflict with informal power of its culture.

Perhaps intuitive, I agree, but …

Imagine the impact such things have on the effectiveness of BI technologies. And on our natural reaction in the face of such things to add yet more technology with predictable results. In a rather perverse way, the more technology we introduce into such an environment, the more ineffective the outcome becomes. Or the more pixilated our thinking becomes …

Perhaps our responsibility as I.T. professionals is to begin focusing equal energy around the effective use of BI capabilities compared to the energy spent creating and deploying them. Perhaps our responsibility as User Group members is to begin to request such content and dialogue from peers and vendors.

To this end, next week’s blog will end the six-week look at Business Intelligence with a discussion of ways to improve BI’s effectiveness by an improved alignment of BI processes and technology.

Regards,
Rick

Giving Business Intelligence the Business, Part 3

 

End-to-End BI Process Architecture 

Building upon the theme of my last post, Business User Adoption (meaning, the degree to which BI systems are actually being used in the course of real work), business understanding and acceptance of BI would be greatly enhanced if it could be displayed within a Business Process context, rather than a Technical one.

In other words, by defining technology in the language of the business. Not a very novel concept, but one that we have to keep learning. It’s in keeping with the belief that Technology within itself does not deliver Business Value; such value can only be delivered through the way in which Technology is used.

As proposed at the end of my last post, BI can be viewed as an end-to-end business process, starting with the collection of data and ending with the action taken in the use of that data. And herein lies the fundamental difference in this approach when compared to the technical way in which BI is viewed today. In a Technical context, BI ends with the delivery of the information via reports, analytics, alerts, etc. In a Business Process context, BI ends with the action taken (i.e., the business result). While I can find no references to this concept with respect to BI, there has been much written about I.T. being viewed as an end-to-end business process from a transaction systems standpoint. The best I’ve seen was provided three years ago by the preeminent BPM resource, the BPM Institute (What is End to End Anyway?).

A proposed end-to-end BI process is displayed below. Note that it is a linear flow, not a circular one. Linear flows represent both a beginning and an end to a process. This is the language of business. Circular flows are intellectual depictions of interaction and their use in depicting business processes should be stopped. But I digress…

 

Walk into any business manager’s office and explain BI using this process flow, and he/she will get it immediately. Once at the same level of understanding, walls will come down and true collaboration will begin. The business manager will understand what BI is about, and perhaps most importantly, the I.T. professional will send the message that Business Value is the real goal of I.T.

Regards,
Rick