Social Gestures and Social Business Intelligence

Social Gestures

If, in the middle of a conversation,  I put my index finger to my lips you would instinctively lower your voice. If I held my hand out flat towards your face whilst you were talking you would stop mid-flow. These social gestures are powerful forms of human communication. They are efficient communication short-cuts.

Cheque Please

One of the most universally useful social gestures is pinching the thumb and forefinger together as if holding a pen followed by a short wave in the air as if writing. Used in restaurants around the world it invariably results in receiving the bill even if your previous attempts at the local language resulted in you getting the wrong dish which you ate whilst wishing you had swallowed your pride rather than what ultimately arrived and pointed clumsily at the menu when ordering. Human social gestures are shaped by culture, history, collective memory and there are are a growing amount of equivalent online social gestures.

The Power of Online Social Gestures

Online Social Gestures are specific and granular interactions supported by social tools. In a single gesture or click it is possible to ‘like’ a document ‘rate’ it’s value or ‘share’ it’s content. Online Gestures in social tools are powerful for two reasons.

Firstly, they simplify interactions. Let’s take another universal human gesture, lifting a single thumb in the air to signify our approval. A single click on a thumbs up icon communicates the same message as adding the comment ‘I like this’ but it’s easier. It’s a single click rather than two clicks and nine key strokes. The difference in ease of use is marginal but it removes a barrier, albeit a low one, to participating in the social discourse.

The second reason though is more significant. In adding a ‘like’ button we have identified a common interaction within the universe of interactions that we can isolate, capture, analyse and make further use of. For example, we can capture and count how individuals rate a document. The availability of that document in searches and lists can be influenced by the rating. The more readers positively rate a document, the more others will become aware of it and the wider and audience for good content as decided by the ‘crowd’.

Decision Making Gestures

There are specific Social Gestures for Social Business Intelligence and the interactions associated with decision making in an organisation. Today, the social interactions are very simple but we should expect these to grow as vendor offerings grow in their levels of sophistication. The following represent social gestures for Business Intelligence. Some exist today, some are inspired by the behaviour of decision makers as we see it so are effectively our suggestions to Social BI vendors;

• Explain. Open a question to explain the real ‘meaning’ of a BI report is identified. This is likely to be a gesture initiated by a Senior Manager
• Resolve. Explore the possible solutions to the issue now identified as a result of the investigation that has taken place.
• Decide. Agree and announce the most suitable solution to the issue
• Approve. Seek approval or challenge from those involved in the decision making discourse
• Action. Execute the solution identified in the resolution discourse.

Capturing Decision Making Gestures

If we simplify and capture these gestures we can start to understand the significance of separating, capturing and analysing each of them;

• Explain. Senior managers can easily delegate the task of discovery to domain experts and analysts until there is consensus on the meaning of a BI report. For example

• Resolve. All considered solutions along with the discourse and debate can be tied back to the issue identified in the BI report

• Decide. The chosen solution can be clearly identified along with all those that were considered

• Approve. Those involved in the decision making process can agree, disagree or register a challenge to the decision either as part of a consensus driven approach or simply ‘for the record’

• Action. The activity decided upon to resolve the issue can be tied back to the decision and it’s outcome as a success or failure recorded so that it can be considered as an option for similar future decisions

So online social gestures, as they relate to decision making are the starting point form which we can begin to understand the decisions in our organisations, how they came about and what they tell us about improving future decisions.

 

If only BI was as efficient as Facebook

BI, Facebook and Decision Loops

I  was at an analysts briefing event with IBM last week who were sharing their thinking on Social Business and what I believe is the inspired and innovative pairing of Connections Collaboration and Cognos Business Intelligence. IBM’s Social Business Leader for Northern Europe, Jon Mell shared a slide that compared the number of operations it takes to share a photo and gather feedback with friends on facebook and  the number of operations it takes to do the same on email.

This set my mind racing. If there are efficiency gains on something simple like sharing and getting feedback on a photo, imagine the productivity gains on sharing critical business information through Business Intelligence reports.

Why do I say this? Because sharing a photo is typically a single ‘sharing loop’ process. Someone publishes the photo, others contribute with their clever and witty observations. Done.

A single loop … Count ‘em … One. (A quote from Muppet Treasure Island, btw)

The out-dated view of BI is that it is shared this way too. That it’s published and the job is done. This just doesn’t hold true any more and I am not sure it ever did. BI requires many sharing or decision loops. Ten, distinct loops to be precise but some of these are repeated which means there can often more decision loops than a bowl full of fruit loops (an all too infrequent guilty pleasure of mine)

1. Meaning Loop. Gain and assign agreement on the meaning of the information
2. Implication Loop. Decide if the implication is neutral or if there is a problem or opportunity
3. Investigation Loop. If there is an issue then it will be rare that the one piece of business intelligence will provide the full story. This loops is about investigating the problem or opportunity is in more detail.
4. Solution Loop. Determine possible solutions to exploit the problem or resolve the problem
5. Decision Loop. To decide on the best possible solution
6. Action Loop. Once the solution is determined it will be broken down into tasks and assigned to individuals to be actioned.
7. Progress Loop. Providing feedback on the progress of the solution
8. Monitoring Loop. To determine if the solution has been successful or if the group need to return to refine the tasks or redo some loops.
9. Conclusion Loop. Closure. Establish agreement that that there are no further actions and that the problem or opportunity is resolved.
10. Celebration Loop. Acknowledge the support and contributions of those involved

That’s ten loops which means that if sharing a photograph on Facebook is more efficient than sharing it in the office using email, the productivity benefits of doing ‘real’ business are tenfold.

There are those that are sceptical about Facebook styled social platforms in the office because they may waste time. I understand this, I really do. However, the opposite is true. Organisations need social platforms, particularly for collaborative decision making. Without them, they are wasting time.

 

BI and Poor Decision making

Good Decision/Bad Decision

This has been something of a preoccupation for me of late. We spend much of our time debating the technologies. We invest valuable time in deciding if we should we go with mega-vendors (IBM, Oracle, SAP) or a challenger? We agonise over should it be cloud or on-premises, mart or warehouse, dimensional or relational? And it is all, frankly academic if the businesses is not making good decisions.

There is no shortage of material that try and make sense of why good people and great businesses make monumentally bad decisions. In the book ‘Thing Again:Why Good Leaders Make Bad Decisions’ by Sydney Finkelstein, Jo Whitehead and Andrew Cambell the focus is on the strategic decisions that have dramatic and highly visible consequences for the organisation.

Good People in Great Organisations Can Make Poor Decisions

An example is one of the UK’s premier retailers Boots which enjoys one of the largest footfalls in the UK. Established in the 19th century, it is now a subsidiary of £20billion Alliance Boots. In September 1998, the Chief Executive, Steve Russell excitedly announced a range of healthcare offerings including dentistry, chiropody and laser hair removal. Five years later, the initiative had lost in the region of £100m and Boots needed to break open the piggy bank and look down the back of the sofa for another £50m just to close down the operation and convert that premier retail space back to being … retail. It almost goes without saying that the changes were implemented by a new CEO, Richard Baker.

Apparently, one of the chief reasons for making the move into Healthcare services was  that a slowdown in the Beauty business ‘had been detected’. However a spokesman was later quoted in the Telegraph as saying that ‘they recognised that these areas are still growing strongly’.

Let’s stop there for a second. Spotting trends in sales and revenue by product category is probably marketing and business 101. And even the most rudimentary business intelligence solution should be trending sales over time. Yet the trend in sales in a key category for Boots was diagnosed as slowdown and only a few months later as growth. Of course, the slowdown may have been a short-term blip but the point of trending is to smooth these out for the purpose of longer-term planning. And, the error in trending might be more understandable had it not been for the fact that the later growth was characterised as ‘strong’.

Of course, I am not on the board of Boots and I have an advantage shared with all those analysts and commentator that put the boot (or should that be Boots) into Mr Russell … hindsight. Indeed, it’s a testimony to the strength of Boots as a high street giant that they can make major booboo’s and still go on to survive and thrive.

The Problem with Decisions …

And organisations are complex systems of individuals and interactions. Large organisations are very complex. This is why organisational decision making doesn’t always stand up to the scrutiny of us as individuals who retrospectively try and apply the logic of rational decision making to such mistakes.

There are a number of problems associated with individuals making decisions. Individuals have bias, self-interest, pre-conceptions. There are also a number of problems with organisational decisions. Groups have to manage conflict, disagreement and there are dynamics that can produce undesirable outcomes like Groupthink.

Today BI’s only Contribution is a Report, Chart or Dashboard

So if we accept that the purpose of Business Intelligence is to help organisations make better decisions (surely there is no debate here?) then Business Intelligence applications have to be more than reports, dashboards and charts.

They need to make decisions easier to collaborate around, they need to link decisions directly to the information that is required to make them. Furthermore decisions need to be open, transparent, accountable not just for the regulators but so that the whole organisation can buy into them.

 

Decision Making Black Holes

 

A Funny Thing Happens at the Forum

Meetings are one of the most common decision making ‘forums’ we are all regularly involved in. In fact one in five company meetings we take is to make a decision. As a way of making decisions though, they can be problematic. Once the meeting has concluded, the connection between information shared, decisions made and actions taken can be weak even lost. It’s as if the meeting itself were a decision making black hole.

Some Decisions are More Equal Than Others

Some decision making meetings are impromptu for making a timely, tactical decision quickly. Others are regular, formal and arranged around the ‘drum beat’ or ‘cadence’ of a business to make more strategic decisions. The more strategic the decisions and longer term the impact the less frequent the forum so a Senior or Executive Management Team may only meet quarterly for a business review (QBR)

How a QBR ‘Rolls’

A typical QBR will see Senior Managers sharing results in PowerPoint, possibly with financial results in spread-sheets which I would hope have at least been extracted from a Business Intelligence application.

If the SMT are reasonably well organised, they will summarise their conclusions and actions in meeting minutes. The meeting minutes will be typed up by an assistant in a word document and then distributed in email.

Throughout, they will all have been keeping individual notes so will walk out with these in their daybooks. The most senior manager in the room might not do this particularly if it’s their assistant who’s taking the minutes.

Later, actions from daybooks and minutes are likely transferred to individuals to-do lists and all follow-up will be conducted in email and phone calls.

An Implosion of Information, Conclusion and Decision

So let’s recap. Critical decisions about how resources are going to be allocated will be discussed in a ‘QBR’ and yet the artefacts of this critical decision making forum are scattered into Word documents, excel spread-sheets, emails and outlook tasks. Tiny fragments of the discussion, information, conclusion, decisions and activities implode around the organisation. To be frank, the team are now only going to make progress because the forum was recent and can be relatively easily recalled.

Of course, once time or people move on so does the corporate memory of the decision. Conversations begin with ‘what did we agree to do about that cost over-run?’ or ‘why did we say we were ok with the revenue performance in Q1?’

Executive Attention Deficit Syndrome

Many executives complain of a syndrome that feels like ADS. This is because the more senior the manager the more things they will probably have to deal with at an increasingly superficial level. A functional head will probably spend no more than 15 minutes on any one thing. To productively make decisions they will need to be able to have the background, status and related information to hand so that they can deal with it quickly and move on to the next thing. Decision making black holes contribute to this feeling of EADS.

CDM and Corporate Memory

Corporate Decision Making platforms will be successful when they connect;

• Decisions
• Information on which the decision was made
• Insight derived from the information
• Actions taken on the decision
• Results of the actions

This means total recall of corporate decisions good and bad so that, over time, decisions can be recalled, evaluated, re-used or improved. A far cry from current decision making forums which whilst functional are inherently flawed, fragmented and are not improving the timeliness and quality of decisions in our organisations.

 

BI Requirements Should not just be Gathered

There are many resources remonstrating with the IT community on the importance of gathering requirements. Failing to gather requirements, they warn, will lead to a poor solution delivered late and over budget. This is largely inarguable.

However, I would warn that simply ‘gathering’ requirement is as big a risk. Fred Brooks, author of ‘The Mytical Man Month’ once said that ‘the hardest part of building a software system is deciding what to build’. And deciding what to build is a two way process rather than the act of listening, nodding and documenting that we all too often see in Business Intelligence projects.

From time to time, I hear someone cry foul on this assertion. They argue that it seems like the tail is wagging the dog or that the business cannot compromise on the requirement. I usually point out that simply building what the user asked for doesn’t happen in any other field of engineering. Architects advise on the cost of materials when planning a major new office building, City officials take advice on the best possible location for a bridge and environmental consultants are actively engaged in deciding exactly if and what should be built in any major civil engineering project.

And this is exactly how we should approach business analytic requirements. As a two-way exploration of what is required, possible solutions and the implications of each. Incidentally, this is particularly difficult to do if business users are asked to gather and document their own requirements without input from their implementation team.

An example of why this is important is rooted in the fact that many BI technologies (including IBM Cognos) are tools not programming languages. They have been built around a model to increase productivity. That is, if you understand and work with the assumptions behind the model reports, dashboards and other BI application objects can be built very quickly. Bend the model and development times increase. Attempting to work completely around the model may result in greatly reduced productivity and therefore vastly increased development time.

So be wary of treating ‘gathering’ and ‘analysis’ as distinct and separate steps. Instead, the process should be an iterative collaboration between users and engineers. Requirements should be understood but so should the implications from a systems perspective. The resulting solution will almost undoubtedly be a better fit and it will significantly increase the chance of it being delivered on time, at the right cost and with an increased understanding between those that need the systems and those that build them.

“We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem”, Russell Ackoff, 1974

 

Single version of the truth, philosophy or reality?

Assuming you want the truth and you can handle it then you will have heard this a lot. The purpose of our new (BI/Analytics/Data Warehouse) project is to deliver ‘a single version of the truth’. In a project we are engaged with right now the expression is one version of reality or 1VOR. For UK boomers that will almost undoubtedly bring to mind a steam engine but I digress.

I have to admit, I find the term jarring whenever I hear it because it implies something simple and  attainable through a single system which is rarely the reality.

In fact it’s rarely attained causing some of our community to ponder on it’s viability or even if it exists. Robin Bloor’s ‘Is there a single version of the Truth’ and  Beyond a single version of the truth in the Obsessive Compulsive Data Quality blog are great examples.

Much, on this subject, has been written by data quality practitioners and speaks to master data management and the desire, for example, for a single and consistent view of a customer. Banks often don’t understand customers, they understand accounts and if the number of (err, for example Hotel Chocolat) home shopping brochures I receive is anything to go by then many retailers don’t get it either. Personally I want my bank and my chocolatier to know when I am interacting with them. I’m a name, not a number, particularly when it comes to chocolate.

This problem is also characterised by the tired and exasperated tone of a Senior Manager asking for (and sometimes begging for) a single version of the truth. This is usually because they had a ‘number’ (probably revenue) and went to speak to one of their Department Head about it (probably because it was unexpectedly low) and rather than spending time on understanding what the number means or what the business should do, they spent 45 minutes comparing the Senior Managers ‘number’ with the Department Heads ‘number’. In trying to reconcile them, they also find some more ‘numbers’ too. It probably passed the time nicely. Make this a monthly meeting or a QBR involving a number of department heads and the 45 minutes will stretch into hours without any real insight from which decisions might have been made.

This is partly about provenance. Ideally it came from a single system of record (Finance, HR) or corporate BI but it most likely came from a spreadsheet or even worse a presentation with a spreadsheet embedded in it.

It’s also about purity (or the addition of impurities, at least) It might have started pure but the department head or an analyst that works in their support and admin team calculated the number based on an extract from the finance system and possibly some other spreadsheets. The numbers were probably adjusted because of some departmental nuance. For example, if it’s a Sales Team, the Sales Manager might include all the sales for a rep that joined part way through the year whilst Finance left the revenue with the previous team.

It will be no comfort (or surprise) to our Senior Manager that it is also a Master Data Management problem too. Revenue by product can only make sense if everyone in the organisation can agree the brands, categories and products that classify the things that are sold. Superficially this sounds simple but even this week I have spoken with a global business that is launching a major initiative, involving hundreds of man hours to resolve just this issue.

It’s also about terminology. We sacrifice precision in language for efficiency. In most organistions we dance dangerously around synonyms and homonyms because it mostly doesn’t catch us out. Net revenue … net of what? And whilst we are on the subject … revenue. Revenue as it was ordered, as it was delivered, as it was invoiced and as it is recognised according to GAAP rules in the finance system. By the way does your number include credit notes? And this is a SIMPLE example. Costs are often centralised, allocated or shared in some way and all dependent on a set of rules that only a handful of people in the finance team really understand.

Finally, it’s about perspective. Departments in an organisation often talk about the same things but mean subtly different things because they have different perspectives. The sales team mean ordered revenue because once someone has signed hard (three copies) their job is done whilst the SMT are probably concerned about the revenue that they share with the markets in their statutory accounts.

So is a single version of the truth philisophy? Can it really be achieved? The answer is probably that there are multiple versions of the truth but they are, in many organisations, all wrong. Many organisations are looking at different things with differing perspectives and they are ALL inaccurate.

A high performing organisations should be trying to unpick these knots, in priority order, one at a time. Eventually they will be able to look at multiple versions of the truth and understand their business from multiple perspectives. Indeed the differences between the truth’s will probably tell them something they didn’t know from what they used to call ‘the single version of the truth’.

 

Traditional IT teams are missing the boat on Social Analytics

Being a natural owl and not a lark, it takes something really important or deeply interesting to get me into the City for a 7.30 am breakfast meeting. Ed Thompson of Gartner speaking on how Sales, Marketing and Customer Services are making use of social media last week more than qualified.

 

The focus was not the usual ‘if facebook were a country’ hype but very much on how ordinary businesses are adapting to the world of social media and getting ahead through practical application of new and innovative solutions. Interestingly, the most common applications are brand monitoring and company watching in the form of B2B CRM and Competitive Intelligence. Sectors already adopting include Retail, Hi-Tech, Media and Consumer Goods businesses.

 

Insight came thick and fast but one thing that stood out was that IT are nowhere to be seen. This is, at least, partially because these are new solutions, usually cloud based and IT involvement isn’t mandatory. However, with the internal department involved in less than 2 out of 10 initiatives, they are getting left behind. It could be argued that they only have themselves to blame. When I work with my customers and they tell me that a new server will take 15 weeks to build or that it will be 8 weeks before a new report will run for the first time then I find it difficult to side with the ‘professionals’. Business cycles are getting shorter and shorter whilst IT surrounds themselves with processes and models designed to reduce risk, increase quality and security but that also kick delivery dates so far over the horizon that the business have stopped asking for help.

 

Those that are involved are busy defining standards, mandating architectures and generally slowing things down. My advice to IT departments, BI teams and competency centres involved in such activity is stop. Just stop.Things are moving quickly and by the time you have updated the version control on your feasibility study, it’s out of date. Now is the time for adoption and execution (Ed’s words not mine, btw) The business needs support in getting information on what their customers are saying about their products or the latest marketing campaign. The sales team want to identify reasons to pick up the phone and sell to their prospects and they want it embedded in their CRM systems and processes. Marketing want to understand what competitors are doing, if they are forming new partnerships, announcing new products and how the market is responding. All of this, delivered regularly and routinely, is becoming as critical as daily sales, fulfilment, basket analysis or the senior management team’s dashboards.

As information professionals we should be helping the business corral the world of social media and on-line content. We should be investing time in understanding the new challenges and opportunities that semantic and content analytics represent.  We should also be embracing, experimenting and learning from the emerging technologies that address them. Most of all we should be adopting and implementing.

The growth of SaaS means that the business has a choice now. When it comes to social analytics the early adopters are looking at a range of vendors with innovative solutions that require no more implementation than adding a new bookmark. Then they are looking at their IT teams who are offering them a four page ‘IT request approval’ form. Where would you go?

 

BI Project Managers and Eyebrows

Like eyebrows, you don’t really notice project managers when they are there but if you are rash enough to let them go you will end up looking startled and stupid.

I point this out because over a period of more than 10 years I have had the opportunity to observe many, many BI projects and one of the most surprising patterns is the scaling back of project management largely because the project is going well!

The openly declared reason is usually cost or some other misdirection but it is invariably preceded with pointed questions about what value the project manager has been adding to a project that is going so well. Perversely, the better the project is doing, the higher the risk that there will be murmurings about things like the overhead of project reporting and that project management activity will ultimately be reduced or even removed altogether. It has become as common and predictable as it is deeply and logically flawed.

Perhaps this is one of the phenomena that explains why the trend for project failure is not getting any better. According to the latest Standish Group report which is covered by Peter Taylor, author of ‘The Lazy Project Manager’, in his blog ‘Are your Project Managers working too hard to be successful?‘ instances of challenged (late, over budget or reduced deliverable) projects continues to rise.

As BI practitioners we often value technical skills, competency in the reporting tool and the deep musing of the data architect and yet have a blind spot when it comes to project management. This may be partly because early BI projects were often departmental in scale. It may also be because many of today’s BI Competency Centres originated as ‘skunk works’ initiatives and see project management as all methodology and meetings but we ignore it at our peril.

It is true that project management can be at its most obviously valuable when priorities need resetting, additional resources have to be secured or controlled management escalation is called for. However, we shouldn’t assume that if a Project Manager is not doing these things that they are not doing anything.

Planned projects with predictable timescales along with accurate project reporting are rewarded with confidence from our business sponsors. A considered set of risks based on real-life experience of BI projects will mitigate against them becoming time sucking issues and properly managed issues will prevent them becoming show-stoppers.

A good Project Manager may make it look easy but don’t take the lack of fire fighting and crisis meetings as an indication that nothing is being done. Look deeper for the benefits of order over chaos or be prepared to invest in an eyebrow pencil for a look that is decidedly a poor second best.

 

Small Children, Energy and Efficient Data Warehousing

Last week, I referred to Peter Thomas, and his article Using multiple BI tools in a BI implementation – Part II, In the article, Peter points out that the way to drive consistency across dimensions and measures is to define as much logic as possible in the data warehouse.

I was musing over this again this weekend (I hear the cries of what an interesting life you have) whilst out for lunch with friends and their small children (ages 9 and 7) On the short walk to the restaurant I was amused by how different their approach at getting from A to B was to the ‘grown ups’. We were focused on getting to the destination in a relatively direct and efficient way. However, the children ran to and fro, stopped, doubled-back, looped a few circles and even randomly waved their arms in the air. They generally spent as much time in a state of motion as possible. Clearly the criteria of small children, when en-route to a destination, is to use the maximum amount of energy possible!

This, if you will go with me on this, is rather like trying to implement data warehouse consistency in the BI tools rather than further downstream in the data warehouse. You do eventually get to the destination, but will probably be exhausted, out of breath and hungry. This is fine if you are two children out for dinner with some stuffy grown-ups but not an efficient use of the somewhat limited time of a BI practitioner.

A typical BI architecture comprises tiers that include;

• Source Systems
• ETL
• Data (Data Warehouse, Data Marts, OLAP Cubes)
• BI Metadata
• BI Application (Reports, Scorecards, Dashboards)

A properly architected data warehouse (more on this in later blogs) should have been built against an enterprise schema and is therefore *the* consistent representation of business information. Common definitions of customers, departments, profit and products live here. If there is one good reason for this (although there are many) then it is simply that there these can all be defined once in the data warehouse but would have to be defined many, many times in what can often be hundreds of reports that comprise a BI solution.

One of the reasons that we fail to do this is that inconsistency is often made visible for the first time by the BI tools. At this point the project momentum is around building metadata models and reports. Inconsistencies are fixed where the resources are focused … in reports. Add to this that revisiting the design may need involvement from the ETL developer, the DW designer and the business analyst and, if there is a lack of clarity, the business users. It is no surprise that the report author is inclined to fix it where they stand. After all, the tools make the fix simple and it is only when the report author has built the same calculation for the tenth time that they become suspicious about starting it in the first place. And of course, the initial build of the BI application is only the beginning. Many more reports will be built over the life of the BI application.

So work hard to establish the correct definitions during the design of the data warehouse and it will reap productivity gains. Leave it to the BI application only if you have the carefree attitude, the free-time and the energy levels of an eight year old.