BBI: Belgian Business Intelligence, an Oxymoron?

BI lessons from political storytelling.

The Belgian Federal Government is juggling figures to prove to their population they are implementing structural cuts on government spending. Not. It is a known fact that politics and Business Intelligence don’t go together. If nobody in the cockpit shares ideas about the causality of things and nobody shares objectives with the others than you have a political situation where BI can only be abused for the various agendas in the coalition.

Have a look at the stats from the Belgian National Bank:

Year	Revenue	Revenue Index	Spending	Spending Index	Nominal GDP
2009	94.9	100	102.7	100	100
2010	97.9	103.1	109	106.1	104.1
2011	100.5	105.9	115.9	112.9	108.6
2012	109.5	115.6	115.7	112.7	111.1
2013 (budget)	112.1	118.1	122	118.8	113

Table: Federal Government Income and Spending

The explanation from the present coalition is hilarious: we are implementing structural cuts and  only because of the endless government formation talks in 2010 the budget derailed.

It is true that in 2010 spending rose but relative to GDP growth it climbed lower than in 2011 and in 2012, a massive increase in taxes and excises combined with a freeze on spending reduced the gap a bit. But over the entire period –where the same political coalition was at the helm of the Belgian Titanic- expenditures grew with 18.8% compared to GDP growth of 13 % and taxes also exploded with 18.1%. Telling the people and the EU authorities that Belgium is in control of its budget is not quite the truth…

The problem with this story is the Belgian press (excluding the financial press) who is repeating and reprinting this PR message without any critique whatsoever.

This shows that figures need the right story to convey the message to the audience because if people, even trained communication experts like journalists, can choose between a narration or a table filled with figures, they’ll go for the story.

Remember that when you explain the figures to your management.

What is Really “Big” about Big Data

Sometimes it is better to sit still and wait until the dust settles. Slowly but surely, the dust is settling around the Big Data buzz and what I am looking at does not impress me.

There are a lot of sloppy definitions of Big Data about. I have read incredible white papers, books and articles which all boil down to: “We don’t know what it is, but it is coming! Be prepared (to open your wallet).” In this article, I make an attempt to put certain aspects about Big Data in a Business Intelligence perspective and come to a definition that is more formal and truly distinguishes Big Data from just being a bigger database. I have a few challenges for you that will hopefully elicit some response and debate. These are the main challenges, intentionally served as bullet points as it will make bullet holes in some people’s assumptions.

• Three V’s are not enough to describe the phenomenon
• There is a word missing in the phenomenon’s naming
• It has always been around: nihil novi sub sole
• What’s really Big about Big Data

Between all vaguely defined concepts, vendor pushed white papers and publications, three “Vs” are supposed to define Big Data completely.

Gartner, who is always ready to define a new market segment as a target for analysis and studies as a new revenue source introduced these three “Vs” in 2008 or something.

 “Variety”, “Velocity” and “Volume” are supposed to describe the essence of Big Data. Let’s see if this holds any water. “Velocity”, the speed with which data should be processed and “Volume” are relative and subject to technological advances. When I did analysis for a large telecom organisation in 1 the mid-nineties, the main challenge was to respond fast and adequately to potential churn signals, hidden in the massive amounts of call data records (CDRs). Those CDRs were the Big Data of the nineties.

Today with the ever increasing numbers in social, mobile and sensor data the velocity and volumes have increased but so has the speed of massive parallel processing capabilities as well as storage and retrieval. Speed and volume are also an identical challenge for every  player in the competition. If you need to be on par with your competitors, take out your credit card and book some space on AWS or Azure and Bob’s your uncle. The entire Big Data infrastructure is designed to function on cheap hardware.

Two “Vs” that matter: Variety and Volatility

"Variety"

One of the real differentiators is “Variety”: the increased variety of data types that really defines what Big Data is all about.

This “V” you won’t read about in Big Data hype articles, yet this is a serious challenge. From the early EBCDIC and ASCII files to UTF-8, xml, BLOBs, audio, video, sensor and actuator data etc... making sense of all these data types can be a pain. But also the variety within a data type may add to complexity. Think of the various separation marks in weblogs. And it gets worse when analysing unstructured data like natural language where culture and context kicks in: events, subcultures, trends, relationships, etc... Even a simple mood analysis in the US on tweets about the death of Bin Laden was negatively interpreted since a simplistic count of the word “death” was used to parse the tweets on the minus side without taking the context into the equation.

”Volatility”

This is about the variations in sentiment, value and predictive power which is so typical for an important segment in Big Data. A few examples to make it clear.

If I give a “like” to Molson and Stella beers, will this still be valid next week, next month,…?

If I measure  consumer behaviour in its broadest sense: information requests, complaints, e-mails to the customer service, reviews on websites, purchases, returns and payment behaviour and I try to link this to behaviour on social media, will it correlate with the previous measures? Think of predicting election results on the basis of opinion polls ,don’t we often say one thing while we act totally different?

This is the real challenge of Big Data. The rewards are great. The organisation that can exploit data about moods, attitudes and intentions from unstructured data will have better forecasts and respond faster to changes in the market.

This way, Big Data realises a dream from the 1960’s: establishing a relationship between communication input and its impact on sales results. In other words, the DAGMAR [1] model from Russel Colley can materialise by analysing unstructured data from a broad range of sources.

[1] DAGMAR: the abbreviation of Defining Advertising Goals for Measuring Advertising Results.

Feedback on Business Analysis for Business Intelligence

Reconciliation of two separate worlds is a challenge

BA4BI is out since the end of October 2012 and after almost seven months, it is time to give you an overview of the first reactions on the publication. Sure, there are good reviews like these on Amazon.com.

But there is also a general, recurring critique, namely the book is taking too much of a central position between the ICT BI specialists, the business users of the BI products and the strategic decision makers. What this critique means is in fact “you are not choosing our side”.

I am very happy with this general critique because that is what the book meant to do: to create a bridge between the technicians and the strategy designers and executors. The only firm choice it makes is for mutual adjustment! But it also makes me a bit sad. It means that we still have a long way to go in the painful marriage between IT and “the business” as the latter are called by the “nerds” which is a description often heard by the non-technical people…

As every business enterprise today uses or creates an IT component by default this marriage will have to improve. A marketing campaign needs IT to execute, logistics and warehouse management without IT is a dead end, finance? IT has been there for ages,…

More than any other biz or tech hype is this where the true business value is situated: the alignment of the information management with the strategy process. For those who don’t agree: keep optimising your own narrow perspective, take all credits for success and blame the other guys for your failures and one day you will find out you are both sharing the organisation’s loss of market share, efficiency and ultimately the cash that pays your overrated salaries and bonuses.

Have a good day!

What BI Programs and Enterprise Architecture can learn from the European Union

Despite the critiques –be they justified or overly exaggerated nationalist BS- on the European Union, this new organisation form of nations has taught us an important lesson.  It is the lesson of combining economies of scale where this can create extra value for all its citizens with the opposite movement: to leave enough room for local  government to respond to local demands and culture. Keeping local flexibility may incur a cost but it also produces value: keeping a maximum of EU citizens on board of this superstructure and maintain a level of diversity that feeds the evolutionary process.

Take the EU Directive, as the EU[i] defines: A "directive" is a legislative act that sets out a goal that all EU countries must achieve. However, it is up to the individual countries to decide how. On the other hand a regulation is more strict: A "regulation" is a binding legislative act. It must be applied in its entirety across the EU.

What a wonderful metaphor for Business Intelligence Enterprise Architecture (BI EA): directives and regulations based on the subsidiarity principle.

As the EU defines the subsidiarity principle in the Maastricht Treaty and confirms it in the later Treaties as well:

1. The general aim of the principle of subsidiarity is to guarantee a degree of independence for a lower authority in relation to a higher body or for a local authority in respect of a central authority. It therefore involves the sharing of powers between several levels of authority, a principle which forms the institutional basis for federal States.

2. (…).

3. Under the second paragraph of Article 5 of the EC Treaty there are three preconditions for intervention by Community institutions in accordance with the principle of subsidiarity.

a. It must not be an area which comes under the exclusive competence of the Community.

b. The objectives of the proposed action cannot be sufficiently achieved by the Member States.
c. The action can therefore, by reason of its scale or effects, be implemented more successfully by the Community.

 

Replace Community with Corporate Information Management  and Member States  with Business Units,  or line management  or  user groups,…  and there you have it: a sound philosophical and legislative basis for Business Intelligence Enterprise Architecture and program management.

In the 25 years I have been active in BI and CRM, I hear the same discussions over and over: the rigid architecture regulations struggling with local flexibility the business needs to deliver maximum added value. If the BI EA could grasp the essence of subsidiarity and change his regulations into directives, Business Intelligence departments and information management would get more buy in from the business customers without creating chaos.

Gartner’s Research VP Andreas Bitterer[ii] said, “IT leaders should concentrate not only on the technological aspects of BI, but also on the severe lack of analytical skills. Second, they should use a ‘think global, act local’ approach in their BI programmes to provide the right level of autonomy and agility to avoid the bottlenecks that overly centralised BI teams create, while simultaneously establishing enough consistency and standards for enterprise-wide BI adoption.”

There is a lot of truth in this. Let’s hope more and more organisations will heed the warning from Mr. Bitterer and learn from the EU.

---

[i] http://europa.eu/about-eu/basic-information/decision-making/legal-acts/

[ii] Predicts 2012: business intelligence still subject to non-technical challenges by Gartner Research

 

 

 

Statement of BI EA principles

In my book site in support of Business Analysis for Business Intelligence  I have summed up seven principles guiding Business Intelligence Enterprise Architecture. These are the contents of the article:

1. Focus on people, not technology:
2. Perfection is the enemy of the good:
3. Iterative and incremental:
4. Build it first, then talk about it:

5. See the entire picture but use small increments:

6. Make it attractive: user centric and practical, no academic geek[1] gymnastics:

7. These are the deliverables:

·         Customer support for the enterprise architecture

·         A vision and plan to achieve that vision

·         A collection of models and documentation describing the architecture

Whether you agree or disagree, I look forward to reading your comments

My Agile BI Enterprise Architecture Manifesto

I have waited almost a quarter of a century to state these principles, because I kept looking for falsification of the agile paradigm in Business Intelligence architecture. The early gurus in data warehousing all talked about scoping and building the entire data warehouse before delivering any report or analysis to the customer. But  I soon found out that this wasn’t the way to successful BI projects. “Successful” meaning accepted and used by the customers even if the deliverables weren’t complete or 100 %  accurate: as soon as the users experienced significant improvement in the speed and accuracy of the analytics and the reports, they were willing to go along with the BI solutions and applications. So there I learned my first lesson: perfection is the enemy of the good. Later, when I absorbed the theories and practice of Ralph Kimball and his approach with conformed dimensions I learned a second lesson: if you can see the entire picture, you know where to start the first iteration. And you don’t have to worry about costly rework while delivering rapid answers to your customers’ questions. That was one of the reasons why I wrote the book Business Analysis for Business Intelligence: I was sure that BI analysts were not capable of seeing the entire picture: from strategy formation and formulation to a BI system that delivered value in all layers and corners of the organisation.
Later in my career, I worked together with agile software developers and it all became clear: I had grown up into an agile believer without knowing it. Agile Enterprise Architecture is about individuals and interactions, not tools and processes, not 3NF and multidimensional models but ball point sketches and pencil drawings that communicate, convince, align and present a vision for all parties concerned.
So without further ado, here is my agile BI Enterprise Architecture (BI EA) manifesto.

1. Focus on people, not on technology: 

Quality and speed of decision making is the BI EA driver, together with the strategic directions from the Board of Directors. The first argument is a persistent intrinsic motivator, the latter an exogenous hygienic factor, urging management and associates to comply with the strategic vision. Whenever you can use the mission and vision statement to promote BI EA you increase the success rate of your BI EA initiative. Why? Because Business Intelligence Enterprise Architecture is a social construct that can only survive if 80 % of the organisation adopts the construct.

2. Perfection is the enemy of the good: 

Do you throw away the menu if a starter or a main course is no longer available? Of course not. He who wants to wait for a complete picture will have to wait until the cows come home. An enterprise is a living body, adapting and responding to internal and external impulses. No doubt enterprise architecture will follow these movements in a structured and manageable way. It is better to adapt fast to changing technologies via high level design principles and structures to realign with reality  than elaborate the finest details of the architecture. That would be as absurd as an Enterprise Architect writing code. Trust your designers and builders to fill in the details where and when necessary.

3. Iterative and incremental:

The BI EA grows at the rhythm of acceptance and implementation possibilities. If BI EA remains PowerPoint ware, disconnected from everyday practice, its impact will dwindle before the last PPT is projected on the screen. This is also where I apply the 3x over 1/3x rule: for every piece of information you ask somebody, return him three times the value of his input. Demonstrating increased reliability and accuracy of reports and analytics will convince even the staunchest adversary to collaborate with the BI EA initiative. It is all about motivation and acceptance.

4. Build it first, then talk about it:

“I can only respond when I see the picture” is a common remark in BI EA exercises. This is my story of the Inuit and the palm tree. You can describe how a palm tree looks to an Inuit but you will never create a correct image of a palm tree in his mind until you have shown him a few photos of palm trees. If possible, bring along a small palm tree and he will be convinced there are such funny things as palm trees. That’s  why we need the dialectic approach, in small increments as the next principle states.

The clearer you can convey the concept, the more chance of initiating a meaningful dialogue about enterprise architecture.

5. See the entire picture but use small increments:

There is no excuse for creating chaos through wrongly interpreted Agile principles. You have to overview the entire canvass before picking the right increment and working it out in detail. Coherence/Consistency and Agile are two sides of the same coin. It is no coincidence that the Kimball method of conformed dimensions works perfect in all situations. Whether you need to deliver a point solution or an enterprise data warehouse, if you can do it right the first time because you know what is ahead, beyond the point solution, the BI initiative is in good hands.
Margy Ross from the Kimball Group makes a strong plea for the bus matrix as support for agile data warehouse and BI development which you can read here.

Example of a Bus Matrix, an architectural view on all dimensions and facts needed for analysis and reporting (Reprint from Business Analysis for Business Intelligence, CRC Press 2013)

6. Make it attractive: user centric and practical, no academic geek gymnastics:

This is the elevator pitch: better, faster and cheaper decision making because of:
• Consistent data definitions that enable enterprise wide communication
• Manageable architecture of process and related data, process and related decision making and timeliness, accuracy and relevance of the available information
So the first use interview will start with “in an ideal world, what would be the perfect information available for your decision making tasks/processes/bottlenecks?”
Deconstruction of the answers will lead to a user centric approach.

7.Agile BI Enterprise Architecture has three goals:

1. Customer support for the enterprise architecture:
Some professionals ague it can take time before you have convinced the key stakeholders but the alternative can be a lot worse. Think of the energy, time and cost of errors to reduce skunk works, outright dissidence and chaos leading to underperforming  and unmanageable BI infrastructure.
2. A vision and plan to achieve that vision:
Management is about offering perspective and goals that lead people in their everyday actions. But it is also about embedding an ideology, a corporate culture that provides guidance when unforeseen situations occur. That is the value of a BI EA vision, supported by the CEO and his strategic vision as expressed in meetings, documents and publications.
3. A collection of models and documentation describing the architecture:
This is the physical deliverable and its value is determined by the previous two goals and their level of user acceptance.

Better a simple sketch that is understood and accepted by the BI stakeholders than a fancy and comprehensive model and documentation with a sophisticated tool

Tools like ARIS, Enterprise Architect or MEGA will provide maximum added value when the BI stakeholders have contributed to the pencil drawings and accepted the consequences of the drawing.

Be advised that 90% of the work is people management, not just modelling and documentation. Only in extreme cases of dissidence may enforcement work, but “a man convinced against his will is of the same opinion still”.

The ultimate goal is to improve the quality and speed of the decision making process in the organisation allowing for optimum return on investment because alignment between business and information management will tear down the BU walls and departmental silos where local optimization may result in suboptimal group results.

Relevance Lost 2.0

When Robert Kaplan and Thomas Johnson wrote about the fall of management accounting systems and pleaded for new perspectives and approaches to strategic process control they wrote a most relevant statement that still stands today. But as organisations are implementing performance measurement systems as applications of their business intelligence infrastructure, news risks of losing the most relevant part of strategic management arise. There is a clear need for a new, extended approach to the balanced scorecard (BSC). If you wonder what this may be, then read more.
In this article I describe the generic strategy process, compare this with the performance management process, how it is implemented in some organisations and analyze the aspects of this process related to the organization’s leadership style and thus the consequences for the balanced scorecard’s effectiveness.

Read the full article here

The Road to Success in CRM

It has been a while since I stopped to think about what I have been doing in analysing, planning and introducing customer relationship management. What triggered me to write this article is the astonishing observation that after twenty five years in this business nothing has changed. I still keep meeting frustrated sales and marketing people who have a beef with the IT people and vice versa. These misunderstandings have certainly not gone away with the technological developments expanding the sales and marketing process support functionality, the analytical power to categorise contacts, opportunities and threats and the platforms to deliver this functionality. On the contrary, the enormous choice in applications adds to the confusion as business execs believe in the promises made by the demos while the IT people worry about how they can integrate this new application into the existing infrastructure. I have a few ideas about the fundamentals which led to success in the past (as I learned from my own failures) and I decided to share them with you.

For the full story about succesful CRM, click here