Oz Analytics

The Size Of The Local Market

I have always wondered how big the Australian BI market was. Even when I was a Research Director of BI and IM at Gartner the market research didn't easily reveal data down at the Australian level. So I was pleased to read about some apparently 'hard' data:

Gartner's prediction for the business intelligence [market] for 2009 through 2012 says that business units, rather than IT, will control at least 40 percent of the total budget for BI. The problem here, Gartner wrote, is that "business users have lost confidence in the ability of [IT] to deliver the information they need to make decisions." 

The report continues to note that the market for business intelligence (BI) platform software in Australia is forecast to reach A$174.8 million in 2009, up 16.8 percent from A$149.6 million in 2008.

This little bit of intelligence is care of local vendor eXant - the local reseller of the reporting and dashboarding business tool eXPorter. This looks like an interesting tool but I don't know what their pricing is like.

I know enough about Gartner's research methods to add a note of caution to their figures. The true size may be very different from this estimate - but at least they try.

Now all I need is my 1% market share ...

10 Signs That You Need Analytics

I live in a world where the majority of my clients have Management Information Systems (MIS) - but not Analytics. The difference? Well, MIS is (my definition):

The people, processes and technologies used by managers of an organisation to answer their questions. Management information systems differ from regular information systems because they are for analysing other information systems used in operating the organisation.

Analytics is a specialised form (or subset of) MIS that I define as:

How an organisation uses modeling (involving extensive computation) to arrive at an optimal or realistic decision based on existing data.

In other words, MIS and Analytics are both intended to support decision making and the difference between the two is that Analytics makes use of more advanced techniques to interpret data.

The above are my practical definitions that I use when creating an analytic capability in an organisation. I can already hear the shouts and objections from my former Gartner analyst colleagues and I leave further academic debate to them. These definitions work for me and maybe you if you want.

I also see that statistical analysis and data mining are closely related - but often those activities do not involve modeling to the same degree. As to Business Intelligence I see it as an umbrella term for analytics and technologies such as reporting, OLAP, data mining, business performance management, decision performance management, benchmarking, scorecarding, dashboarding, text mining, and predictive analytics.

Now that we have that out of the way, here are the top 10 signs that you need to improve your organisation's analytic capability:

1. You have to wait longer than a day for either IT or your business intelligence department to make/change a report for you.
2. Across the organisation there are more than 100 requests pending for reporting /dashboard /scorecard changes waiting for a specialist to deliver them.  
3. When you attend meetings, there are multiple numbers being quoted for the same thing - and you don't know which of them is correct. 
4. When you talk about fundamental things like transaction, account, balance or available stock - and you discover that the person you are talking to is using the same words but means something different to what you mean. 
5. You can't get an instantly understanding when glancing at a report/dashboard/scorecard and what it is telling you. 
6. The commentary is larger than the automatically generated report. 
7. The report is not generated automatically but is a handcrafted labour of love by either yourself or one of your staff, or you spend hours trying to locate the right data and then have to consolidate it manually into Excel. 
8. It takes longer than 5 minutes to view a new report. 
9. You can't access the report when and where you most need it. 
10. There are hundreds of reports available to you but you don't trust them and you spend time trying to manually validate key numbers.  

If these are the signs, then what are the solutions? That, dear readers, I leave to another blog entry ...

Slow Business Intelligence

I hereby declare the foundation of the Slow Business Intelligence movement. Like the slow food movement of Italy and "langsamkeit" management of Germany, Slow BI advocates the slowing of life.

Many years ago, I read the book Die Entdeckung der Langsamkeit (The Discovery of Slowness) by Sten Nadolny. Essentially a fictional but fact-based novel of the life of 19th century British explorer (and former Governor of Tasmania) John Franklin who died while exploring the Northwest Passage in the Arctic. In the novel, Franklin's slowness triumphed in a Napoleonic naval battle when he shot a French sniper by "waiting, without panic, and carefully noting the angle at which the sniper's shots had been discharged." While those around him panic, he locates the sniper and kills him with a single shot.

I can hear the snorts of derision from my colleagues as they read this but bear with me as I think there may be important lessons in repudiating real-time BI (or more accurately, real-time decision making).

Still reading? OK, here's my logic:

The delivery of numbers quickly to decision makers is an often stated key benefit of BI investments. Words used by advocates often include the like of real-time, zero latency, agile and operational. Largely, this is all correct. It's a good capability for an organisation to invest in as it accelerates the speed it takes to get data and then act. Think about Richard Hackathorn's three types of latency:

• Data latency - the time taken to collect, reconcile and store data
• Analysis latency - the time taken to understand data and make it actionable information
• Action latency - the time taken to react to the information and take action.

So what about the middle step of this sequence? I'm talking about taking time to analyse data and arrive at better decisions. Better, quicker numbers are only worth something if they are used to make better decisions - not just any decision.

In the course of implementing analytic capabilities in several organisations I have often heard counter arguments to publishing numbers automatically out of the BI platform. A common one goes something like the following.

'You can't just give the Board figures automatically. They won't understand the context [i.e. I don't get the chance to 'spin' the message]. They will rush around making knee-jerk decisions either without consulting me, or at best causing me to spend valuable time explaining the figures."

I have often argued successfully that you need to develop trust in the numbers and if you achieve this then to only reason you want to prevent automatic (i.e. real-time) publication is because you see the current ability to spin the numbers as an important source of your power. This is a pretty difficult line to argue explicitly with your CEO. After all, most CEO's themselves like the idea of having better access to the numbers - perhaps for the same 'power' reasons? Generally a capable BI manager is able to 'win the day'.

Another counter argument is

"The numbers are too volatile to report hourly/daily/weekly. This volatility can convey misleading impressions about our business."

I have more sympathy for this and volatility can and does work this way in many businesses. For example a sales operation may on average result in $100 million of new business a week on average. The distribution however may feature sudden rises or falls each day. What is a manager to make of significant changes intra-week in this case?

Well I think there are two conclusions you can make that also support Slow BI:

1. Careful consideration needs to be given to how you present decision makers with such numbers. In this example, if you report a daily number then you may also need to give corresponding information such as whether-or-not the number is outside of the usual range of variance.
2. Analytic modeling can be performed to take into account intrinsic variances and give you the ability to predict what sudden changes will mean for the coming period (in this case the end of the week).

So there are circumstances when the delivery of 'raw' numbers can result in poor decisions. Just churning out the numbers as fast as you can each morning can do harm. The solution is to spend time analysing how the numbers will be used by decision makes under a range of scenarios. This is where Slow BI can make an important contribution: If you want to have realtime BI then you need to spend a lot of time analysing how the information will be used. I think that scenario planning can play a big role in ensuring that the right information is delivered to the right people at the right time and in the right form. I know Gartner talks about this as well.

Take your time analysing your business under all circumstances (this is Slow BI) will deliver you the insight necessary to support the predictive models that will cut through the daily 'fog of operations'. When these are in place, you then have the capability necessary to support successful and Fast BI.

So don't rush, but let's all support Slow BI by slowing down the analysis. We can only then develop the models to support Fast BI.

I'm Afraid I Can't Let You Do That Dave

When you've got a hammer the whole world is a nail - so goes the saying.

So I was wondering if this is the case at Google as they continue to grapple with a serious brain drain of their best staff.

The latest reports are that Google has developed an algorithm to predict which of their staff are most likely to quit. Details are very difficult to come by but here are the features of the algorithm that I have read about in various reports:

• it mines employee reviews, promotion and salary histories
• attempts to identify employees who feel 'underused' 
• inputs also include information from surveys and peer reviews

Google's algorithm helps the company "get inside people's heads even before they know they might leave," said Laszlo Bock, who runs human resources for the company. This data crunching supplements more traditional measures like employee training and leadership meetings to evaluate talent.

Is Google using this to categorise employees into other performance groups? Is this another take on the old six sigma (forced) ranking of the bottom 10 percent of employees?

You could easily argue that almost 5 years on from Google's IPO, this drain is normal and expected from a highly successful company. Way back in April 2007 it was reported that:

"Hundreds of the 2,300 Googlers hired before the Internet juggernaut's initial public offering in August 2004 are hitting their fourth anniversary. When they do, they'll be free to cash in the final portions of their pre-IPO options, collectively worth an estimated $2.6 billion before taxes."
San Jose Mercury News

Presumably the employees leaving were all wealthy from their stock grants and options as under Google's vesting rules, employees typically earn the right to cash in 25 percent of their options when they hit their first anniversary, then the rest in monthly chunks over the next three years. So August 2008 was the month many had earned full cash in rights and could leave with no penalty. Add to that the feeling that your personal contribution is diminishing as the company grows and matures. The desire the seek greener pastures in other companies or exciting start-ups is hardly unexpected.

All credit to Google for being proactive however. If you can retain even a handful from leaving then it must be a worthwhile effort. It should be no surprise that Google is a trend setter here. How many companies do you know with a Chief Culture Officer and the 10 Golden Rules for knowledge workers:

1. Hire by committee. Virtually every person who interviews at Google talks to at least half-a-dozen interviewers, drawn from both management and potential colleagues. Everyone's opinion counts, making the hiring process more fair and pushing standards higher. Yes, it takes longer, but we think it's worth it. If you hire great people and involve them intensively in the hiring process, you'll get more great people. We started building this positive feedback loop when the company was founded, and it has had a huge payoff.
2. Cater to their every need. As Drucker says, the goal is to "strip away everything that gets in their way." We provide a standard package of fringe benefits, but on top of that are first-class dining facilities, gyms, laundry rooms, massage rooms, haircuts, carwashes, dry cleaning, commuting buses—just about anything a hardworking engineer might want. Let's face it: programmers want to program, they don't want to do their laundry. So we make it easy for them to do both.
3. Pack them in. Almost every project at Google is a team project, and teams have to communicate. The best way to make communication easy is to put team members within a few feet of each other. The result is that virtually everyone at Google shares an office. This way, when a programmer needs to confer with a colleague, there is immediate access: no telephone tag, no e-mail delay, no waiting for a reply. Of course, there are many conference rooms that people can use for detailed discussion so that they don't disturb their office mates. Even the CEO shared an office at Google for several months after he arrived. Sitting next to a knowledgeable employee was an incredibly effective educational experience.
4. Make coordination easy. Because all members of a team are within a few feet of one another, it is relatively easy to coordinate projects. In addition to physical proximity, each Googler e-mails a snippet once a week to his work group describing what he has done in the last week. This gives everyone an easy way to track what everyone else is up to, making it much easier to monitor progress and synchronize work flow.
5. Eat your own dog food. Google workers use the company's tools intensively. The most obvious tool is the Web, with an internal Web page for virtually every project and every task. They are all indexed and available to project participants on an as-needed basis. We also make extensive use of other information-management tools, some of which are eventually rolled out as products. For example, one of the reasons for Gmail's success is that it was beta tested within the company for many months. The use of e-mail is critical within the organization, so Gmail had to be tuned to satisfy the needs of some of our most demanding customers—our knowledge workers.
6. Encourage creativity. Google engineers can spend up to 20 percent of their time on a project of their choice. There is, of course, an approval process and some oversight, but basically we want to allow creative people to be creative. One of our not-so-secret weapons is our ideas mailing list: a companywide suggestion box where people can post ideas ranging from parking procedures to the next killer app. The software allows for everyone to comment on and rate ideas, permitting the best ideas to percolate to the top.
7. Strive to reach consensus. Modern corporate mythology has the unique decision maker as hero. We adhere to the view that the "many are smarter than the few," and solicit a broad base of views before reaching any decision. At Google, the role of the manager is that of an aggregator of viewpoints, not the dictator of decisions. Building a consensus sometimes takes longer, but always produces a more committed team and better decisions
8. Don't be evil. Much has been written about Google's slogan, but we really try to live by it, particularly in the ranks of management. As in every organization, people are passionate about their views. But nobody throws chairs at Google, unlike management practices used at some other well-known technology companies. We foster to create an atmosphere of tolerance and respect, not a company full of yes men.
9. Data drive decisions. At Google, almost every decision is based on quantitative analysis. We've built systems to manage information, not only on the Internet at large, but also internally. We have dozens of analysts who plow through the data, analyze performance metrics and plot trends to keep us as up to date as possible. We have a raft of online "dashboards" for every business we work in that provide up-to-the-minute snapshots of where we are.
10. Communicate effectively. Every Friday we have an all-hands assembly with announcements, introductions and questions and answers. (Oh, yes, and some food and drink.) This allows management to stay in touch with what our knowledge workers are thinking and vice versa. Google has remarkably broad dissemination of information within the organization and remarkably few serious leaks. Contrary to what some might think, we believe it is the first fact that causes the second: a trusted work force is a loyal work force.

Don't Be Evil is the one that often gets the headline, but the next one down is just as radical in my view: Data Drive Decisions. Here is the whole article from Eric Schmidt, CEO of Google.

What a pity that other companies are not turning to analytics for the same reasons.

Media reactions have been mixed. Some outright hostile. I may be biased but I don't think that using quantitative analysis of 'HR' data is a bad thing. If anything it should help to remove the bias of human interpretation when reviewing performance. We call it 'fact based decision making' everywhere else. What's so special about HR? I'm not saying that it is a universal panacea but used in conjunction with other things like encouraging supportive cultures and inspirational management styles.

It also struck me that Google should perhaps be concentrating more on those employees who are most under-used as an end in itself. Making better use of existing people must have a positive impact on the performance of the company.

A roll call of brain drainers is available here if you are interested. As recently as last week Tom Phillips, the head of Search and Analytics was rumoured to have left Google.