Thanks for your comments, not sure that we need another Bx acronym, but I think I see where you are coming from. I 100% agree that it’s not about the tools – see A bad workman blames his [Business Intelligence] tools

Peter

Yeah, I think we’re winding down. But I am surprised that you disagree with points 1 and 3, which are truisms.

1. SMEs have spent their entire careers learning the theoretical and practical aspects of their profession…finance, marketing, nursing, HR, supply chain, whatever. Of course an IT worker, who’s spent his career studying different topics and performing different tasks would have different knowledge.

3. IT managers support the organization as a whole. They have a personal stake in the success of the group. They never can have a personal stake in the success of *each* operating department. So of course a system controlled by the manager of one operating department will be more responsive to the needs of that particular department.

Finally, with regard to Excel…

My conclusion always will be in support of the knowledge, creativity, and curiosity of the individual SME. Large BI systems can provide a basic level of performance, which is a good thing. But those big systems necessarily impose group behavior, limit creativity, and delay needed change.

(I read the other day that new antibiotics are failing during the testing phase because bacteria now can adapt so quickly to new threats. Businesses need a similar ability to adapt instantly to a changing environment. This is an ability that big systems don’t support, and probably never will.)

Excel is the only tool I know that gives people with brains the ability to discover new insights and develop new information using any data and virtually any analytical technique. It allows them to do so quickly and inexpensively. And on their own schedule.

Honestly, I wish Excel had some strong competition, because there’s a lot about the program that I don’t like. But I doubt that will happen any time soon. So we’re stuck with it for at least the next decade.

This is fun, Peter. We need to do it again sometime!

All the best,

Charley

We have been round this loop before. Your conclusion is always going to be Excel, and mine is going to be a business-focussed BI team in true collaboration with the ultimate consumers of information. We have both seen our respective approaches work and so will both stick with them.

I disagree with most of what you say in your three bullet points (particularly 1. and 3.), but perhaps we just have to agree to differ.

Peter

I guess the technical term for my primary concern is “hysteresis.” In plain English…

Even if the best prospectors in the world are involved in the planning of a railroad, one would never prospect for gold from the observation car of a passenger train. Instead, one would use a Jeep.

With a train, when a prospector decides to explore somewhere else, the manager of the Operations department shrugs and says, “We can’t take users where they want to go if they don’t know where they want to go.” But with a Jeep, users can follow hunches, explore hidden canyons, and reverse course as often as necessary.

IT-controlled BI systems are much like a railroad train, and Excel is much like a Jeep. Both are needed. But where agility (low hysteresis) is needed, Excel is the obvious solution.

For data support, Excel-friendly OLAP systems like TM1 and PowerOLAP offer the best technology I know for giving Excel users the data they need. However, these tools usually work best when they’re controlled by users, not IT. In IT’s hands, these systems typically cost more, do less, and take longer than otherwise. (But even in IT’s hands, these tools are more successful for agile analytics than alternative technolgies.)

Typically, there are at least three significant reasons that IT control of the analytical process is a problem:

1. IT workers don’t have the same technical and practical knowledge that the Subject Matter Experts do.

2. They’re not doing the work that the SMEs are doing.

3. They work for a different boss, who has no personal stake in the success of the SME’s analytical efforts.

As a consequence of these problems, users and programmers must hold too many meetings and fill out too many forms…rather than doing real work.

Charley

Good points, but as always words in IT and words in normal usage often mean different things.

If your BI team is split into 100% technical and 100% non-technical people then you get the result of which you speak above.

What I have tried to do is to make sure that even the ETL programmers have a reasonable understanding of the business needs that they are serving and that the BAs are essentially collaborators with business people.

In turn the whole design of the warehouse and the content of the associated cubes/reports need to be established with the business as a true partner (not just paying lip-service to this concept).

I covered part of my approach to this in Scaling-up Performance Management, but also touch on it in many other places on this blog.

The results of this approach may be viewed here.

Peter

“‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone,’ it means just what I choose it to mean, neither more nor less.’”

Both SAS and the Wikipedia author that you quote in “Business Analytics vs Business Intelligence” used Humpty’s strategy to narrow the meaning of “analytics.” And in this piece, you boiled down to mean merely “statistics.”

In my experience, a business “analysis” is an exploration of business data by a Subject Matter Expert. Analyses rely upon a wide variety of techniques that can include statistics, but usually don’t. And frequently, analyses also involve the use of data from old and new sources looked at in new ways.

In plain English, the practice of performing business analysis could be termed “business analytics.”

The market leader in the plain-English type of business analytics clearly is Excel.

But SAS and most others in the BI field probably would say that Excel doesn’t do “real analytics,” where “real analytics” is shorthand for “analytics narrowly defined to mean what we want it to mean so we can exclude whatever it is that users do with Excel.”

Every BI installation I’ve ever heard of downloads their data to Excel where the actual analyses are performed. Therefore, if Scott’s “analytics” stands for the plain-English type of analytics then he’s right on point.

The fundamental problem is that analysis MUST be controlled by Subject Matter Experts, not by programmers. But in most BI systems, SMEs are not in control, programmers are.

This arrangement makes as much sense as having a blind mechanic act as a chauffeur in heavy traffic. When the inevitable wreck occurs, the chauffeur will insist that it’s the passenger’s fault because the passenger didn’t define the trip’s requirements so that even a blind man could follow them.

The fault lies not with the mechanic nor with the passenger. It lies with a system that forces SMEs to rely on the work product of people who are blind to the subject of the analysis.

Several years ago, I reviewed a whitepaper by a well-known proponent of BI-type analytics. I insisted that imposing such rigid systems on a firm’s SMEs would make the firm’s (plain-English) analytics as nimble as a freight train. I concluded that I wish I knew which companies would follow that path most rigorously so that I could sell their stock short.

Now I wish I had followed through on that threat.

Charley Kyd

Astounding that so much time is spent on semantics though, but I suppose that is the nature of our profession!

Peter