BI Questions Blog

Sales Manager: "I have an urgent request! We have a sales training next week, and want to show the reps which products our retail customers have been purchasing from that company we just bought."

Strategy Person: "OK, I'm sure we'll have that somewhere [copy to BI people in US, Europe], but note that the raw numbers will need interpretation: some products have low revenue but are big competitive differentiators, and since our customers look nothing like theirs, what was sold in the past and what will sell in the future are likely to be very different. The retail expert [copy Retail person] is probably the best person to turn to for real insight into which products are the most important going forward."

Retail Person: "I've attempted to get this information specifically for retail many times -- it's not available".

Sales Manager: "The idea is to show the reps which products sold most in the past, since those are probably the ones that will sell most in the future".

Strategy Person: "That's exactly the problem! It's not at all clear that's true... In any case I can tell you now what the top products are are -- it's the required base platform followed by the top three options X, Y, Z..."

Retail Person: "Maybe customer assurance has something?"

BI Person US: "Did you want number of customers, or revenue?"

Sales Manager: "... Both?"

BI Person US: "Here's the number of customers per product, attached. For revenue, how far back do you want? I'm assuming you only want people still on maintenance, who have probably installed the software? Note that the data will be incomplete, since it won't include software sold through the channel, nor where they sold an enterprise deal for the whole product set "

Sales Manager: "Can I have it for the last twelve months, for North America, by tonight?"

BI Person: "Junior BI person, please get this out of the data warehouse"

Junior BI Person US (next day): "Sorry for the delay -- the systems were slow... I've prepared an Excel file, but it has over 50,000 lines, and at 12Mb, it's too big to send via email -- can somebody get it to the sales manager?"

Strategy Person: "Sales manager, once I zip the file, it's only 4Mb, attached -- but maybe you should specify the chart you want, and the BI person could give it to you directly?"

Retail Person: "And do we have this data just for retail?"

BI Person Europe: "Sorry I didn't reply earlier.. here's a chart using our other BI tool -- is this what you want?"

Sales Manager: "Yes!! Thank you!!"

Strategy Person (to himself): "Oh look... the base platform followed by X, Y, and Z..."

------------------------

Summary

• People don't know what tools are available to access data
• People don't know who is available to help them
• People don't really know exactly what information they want
• People don't really know how to describe clearly what they want
• People don't really know exactly what they will do with the information
• People are happy to use incomplete data that may not be relevant
• People prefer to have other people get data for them
• People responsible for getting the data don't try to understand the need and may be junior (or simply incompetent)

Note that none of these issues are (at least directly) about technology, and so are resistant to technology fixes (despite all the white papers out there that claim that "magic wands" can fix everything, such as software-as-a-service, memory-resident analysis, BI appliances, column databases, or intuitive new visualizations...)

Ultimately, BI success is about a long and typically hard struggle to create an information culture where people are trained how to access information and rewarded for using it to create business advantage. Typical BI projects spent too much time on technology and platforms, and not nearly enough on people and culture.  Why? Basically because of reward systems and role definitions -- but that's another post...

Posted by Timo Elliott at 10:13 AM | Permalink | Comments (0) | TrackBacks (0)

Business intelligence standardization (which I define as "pragmatically reducing the number of overlapping tools in order to reduce costs and maximize the benefits of business intelligence") seems to be on the rise, at least in my neck of the woods.

Several large customers are looking for external validation of how many BI users they "should" have, and of what profiles (simple reporting, interactive reporting, ad-hoc reporting, OLAP analysis, etc.), in order to have a basis for negotiating an enterprise-wide BI platform deal.

Despite the best efforts of a bunch of very smart people, I haven't yet found anything like this. Obviously it's hard to have a definitive "answer" when organizations differ widely in their information use, BI penetration is a moving target, technology is improving, etc., but it is something that many organizations are increasingly interested in....

Does anybody out there know of something relevant? If so, please let me know, (telliott@timoelliott.com) and many thanks in advance!

Posted by Timo Elliott at 12:14 PM | Permalink | Comments (0) | TrackBacks (0)

Here's another presentation from Sapphire in Berlin. The overview was:

"Learn how to avoid the mistakes that other companies have made implementing business intelligence solutions and ensure success for your own projects. Discover the major assumptions and pitfalls that can lead to project failure and learn what other companies have done to avoid these problems and ensure long-term success."

One participant came up to me afterwards and told me enthusiastically that "you've just described the last six months of my life"! -- I hope things have gone better since...

Link to a PDF version of the presentation

Link to the PPT file (15mb)

Posted by Timo Elliott at 09:00 PM | Permalink | Comments (0) | TrackBacks (0)

Here's one of the presentations I gave at Sapphire last month. It is a high-level, introductory overview that covers key business intelligence themes and how to overcome the major barriers to successful deployments: data integration, ease of use, and cost of deployment. It is illustrated (inevitably) with examples of Business Objects technology.

Link to a PDF version of the presentation

Link to the PPT file (15mb)

Posted by Timo Elliott at 08:31 PM | Permalink | Comments (0) | TrackBacks (0)

If you are in charge of a business intelligence project, your job is not to implement software. It is not to "keep the business happy". It is to use your expertise to help the company transform the way it does business. BI is useless unless something changes as a result of the data that you're providing.

It's not about "working with the business". You should assume that the business people are there to help you in your transformation mission.

That's probably not what you've been asked to do. The business people, justifiably, think it's their job to transform the business.

But having the mind-set that you are ultimately responsible for the success or failure of the system will help the project stay on track. It will encourage you to understand the business needs, ask the right questions, and make the right tradeoffs.

I believe that leading a BI project has the potential to bring more value than any other job in the organization today, and requires a breathtakingly wide range of skills, from deep technical knowledge, to extreme project management, to advanced diplomacy.

Helping organizations transform their business is a heroic undertaking, and I wish everybody out there trying to do it the very best of luck.

Posted by Timo Elliott at 08:26 PM | Permalink | Comments (0) | TrackBacks (0)

I've recently had the opportunity to discuss profitability analysis with a series of companies as diverse as Alcoa (Aluminum products), Otto Group (German multi-channel retailer), La Poste (the French postal service), and Heineken (surely no explanation needed?)

I've come away convinced not only that profitability analysis is not only an asset for all these organizations, but also that it may even be a "magic bullet" that helps promote enduring BI success.

Measuring what's important

Is selling more and maximizing revenue a good idea? Is your best customer the one who brings in the most money? That's certainly how most companies are organized -- the sales people and regions that bring in the most money typically get the biggest bonuses.

But imagine that you're losing money on each product -- maximizing sales suddenly means maximizing your losses. To make the right decisions in your business, you have to measure the right things -- and that means profits, not revenue.

The 80/20 rule vs the whale curve

Everybody has heard of the 80/20 rule. But profitability is different -- call it the "80/140 rule": 80% of your customers or products make up more than 100% of the profits, and the remaining customers reduce the profit back down to 100%. Charting cumulative profit by customer or product typically results in what's called a "whale curve".

If you can generate a whale curve by customer, by product, by channel, etc, you're well on your way to being able to make intelligent decisions about your business. 

Measuring profitability -- activity-based costing (ABC)

Measuring real profitability can be difficult, but new activity-based costing tools are making it much easier to build models that efficiently allocate revenue and costs according to cost drivers. For example, the cost of IT resources can be ascribed to different departments by measuring how many support calls they generate, percentage of server load, etc. Once those costs have been passed on to customer-facing departments, they can in turn be allocated according to number of transactions, deliveries, etc.

Note that things can quickly get complicated -- for example, you have to allocate IT costs to the personnel department, who in turn provide services to the IT department. The best products on the market make this relatively easy, resolving this type of problem automatically through iteration.

Perhaps the biggest difficulty of implementing such systems is knowing what depth of detail and complexity is required to provide "robust" numbers. In general, companies using these solutions reported that they had initially implemented models that were too complex. But by first going "deep" they were able to reassure themselves that the simpler, more useable models they ended up using provided similar results.

Exploiting the whale curve

Profitability analysis is really about determining what drives your business. For example, Heineken can now generate detailed profit and loss statements by brand, SKU, channel, customer, segment -- or any combination of these. This information is used widely throughout the company, for example to determine at what point it becomes profitable to install a more complex "cellar beer" installation instead of a normal draught installation.

After implementing these solutions, company managers typically find that at least some of the the rules of thumb that they have using to run their businesses were incorrect. In many cases, their "best customers" turned out not to be the most profitable, because they demanded more time and attention and generated higher costs.

By determining profitability by customer segment, organizations can adapt their services accordingly. For example, banks can target marketing campaigns at the types of customers which provide them with the highest profitability, and try to encourage higher-cost customers to move to cheaper telephone or online ebanking services.

In extreme cases, companies like Sprint and UK's online bank, Egg, have even attempted to "fire" their least-profitable customers -- a good example of why human beings remain essential to all performance management systems, since a good accounting decision can be a very bad PR decision.

The foundation of strategic BI?

As the BI industry has matured over the last two decades, it has become increasingly important to organizations.

But my experience has been that BI and performance management projects designed for the executive team tend to be "brittle" -- even when they have clearly provided great value, they often fall victim to the next big corporate reorganization and management reshuffle.

Partly this has been because of technology issues -- there are still improvements to be made in how easy it is to update BI systems as goals change -- but I believe it mainly comes down to more human factors.

It's taken as gospel within our industry that strong executive leadership is essential for strategic BI. But the danger is that the project becomes strongly associated with a particular leader. And when that person leaves (and executive turnover has been increasing), their successor instinctively reaches for a different system and different metrics to mark the departure from the "old way of doing things".

This is where profitability shines as a "magic bullet". Simply put: nobody messes with profitability. A new executive is coming in and wants to see a different set of metrics? No problem: since nobody can argue with the importance of profitability, people don't even try.

It appears that profitability can provide a strong foundation on which to build an enduring BI system. The hope is that the new executives will have an incentive to make their mark by acting on the different drivers of profitability, and extending and improving the existing performance systems, rather than dismantling them and starting again.

In conclusion, if organizations really care about implementing strategic BI and performance management projects, they should consider starting with a core foundation of profitability analysis.

Posted by Timo Elliott at 09:32 PM | Permalink | Comments (1) | TrackBacks (0)

The third and final web seminar presentation on BI Maturity that I did last week with Wayne Eckerson: how to make BI a strategic asset for the organization. As I joked with Wayne on the call, I think the maturity model probably needs extending with an additional "canyon", because many organizations have managed to deploy BI enterprise-wide, but still haven't managed to connect it with the strategy and finances of the organization. Click here to listen to the recording. 

Posted by Timo Elliott at 09:36 PM | Permalink | Comments (0) | TrackBacks (0)

Here's a presentation Wayne Eckerson and I did last week as part of a series on BI Maturity. Click here to listen to the recording.

Posted by Timo Elliott at 06:00 PM | Permalink | Comments (0) | TrackBacks (0)

The Need for Informed Decisions

The results of a survey analyzing the current status of corporate decision-making were announced today, called "In search of clarity: unraveling the complexities of executive decision-making"

The survey of 154 global C-level executives, conducted by the Economist Intelligence Unit (EIU) and commissioned by Business Objects, found that more than nine out of 10 corporate executives admit they are making important decisions on the basis of inadequate information. 

More than half of these senior executives are concerned that they may be making poor decisions as a result of missing information. And a quarter believe that management frequently or always gets its decisions wrong.

These are sobering statistics. We are talking about business decisions that can cost an organization millions of dollars, either through costly errors or through the failure to grasp a competitive advantage.

Despite eight out of ten respondents indicating that data is the most important factor in making decisions, ranking it much higher than the opinion of others, personal intuition, or external consultancy, the research showed that more than half of respondents said that decision-making in their organizations was largely informal and ad hoc, and the the report concludes that:

"Decision-making is at the core of all business activity, as executives set strategy and manage operations by weighing a vast array of factors to arrive at the desired balance of risk and reward. It is cause for alarm, then, that executives themselves perceive the quality of decision-making at their companies as mixed at best."

At a time when the economists are predicting that the current credit squeeze is likely to impact the business environment, it is important to wring out every advantage amidst intense and global competitive pressures.

The simple fact is that executive decision makers are not getting the data they value and need, and most executives, like ourselves, are relying more on "gut instinct" than metrics.

But, why would gut feel override our desire for proof? For fact?

What is failing us? Is fact-based decision-making too difficult to sustain?

Five Ingredients of Good Decision-Making

The report's authors identify five ingredients of good decision-making. Obviously, supporting good decisions requires a lot more than technology, but I believe BI can help with each of these...

• High-quality data
• Access to advanced systems and training
• Sound judgment
• Trust
• Flexibility

High-Quality Data

High-quality data is obviously a prerequisite for consistently sound decision-making. The better the data, the less time you'll spend debating the data rather than the decisions that have to be made, and the greater your understanding of your company, your competitors and your environment, the more you can move from guesswork to making strategic choices.

Here are some of the difficulties organizations typically face getting high-quality data, and what can be done to resolve them:

• Data integration. Executive decisions typically require information from several different computer systems, and organizations frequently underestimate the integration challenges involved. Organizations typically address data integration on a project-by-project basis rather than with a more strategy approach. The result is massive redundancy and poor quality. For faster integration and lower costs over the long term, organizations should invest in a robust data integration platform.
• Data quality. There isn't an organization on the planet that doesn't have a data quality problem, but where do you start? The latest data quality technologies can help you answer questions such as "which systems have the worst data quality?" and "where could I get the most value from fixing poor quality data?" To improve executive decision-making, organizations should invest in systems to evaluate, monitor and fix data quality.
• Shared definitions. Effective decision-making requires a shared vocabulary. Investing in "metadata management" technology can help you define and maintain the definitions associated with your key business indicators -- and reduce the number of board-room arguments.
• Timeliness. Faster decisions mean higher profits. In particular, organizations are starting to realize the big benefits that can come from investing in integrated financial systems that help them close their books faster. And rather than managing by "looking out of the rear-view mirror", organizations are investing in predictive analytics.
• Unstructured data. Executives need to be use data from all sources, not just from certain types of databases. It's increasingly important to be able to extract intelligence from non-structured data sources such as documents or emails.
• Benchmarking and external data. Your own systems will rarely contain all the information you need to make decisions. In order to determine your real performance, and make the right decisions, you need to be able to compare your numbers with the economy, the market, or your competitors. New "information on demand" technology is making this as simple as a click of the mouse.
• Governance, compliance, and risk. Decisions can't be made without considering risk, and without considering your regulatory environments. Organizations should invest in risk management systems that are tightly integrated with the rest of their financial applications.
• Transparency. Information transparency is key to maintaining high data standards. Executives need to be able to see exactly where the data came from, how reliable it is, how it was defined or manipulated, and when it was last updated.

Access to Advanced Systems... and Training

Access to advanced information systems is crucial to improved decision-making, as is training in helping employees to make full use of these tools. There is no point in spending on new technology if people do not use it.

• Ease of use. The easier the technology, the more people will use it. The latest BI innovations bring information to the users' fingertips by making it a seamless part of their existing environments, whether it's email, a standard productivity application like Microsoft Word or Excel, or a cell phone. In the future, BI will be "ambient" -- like ambient lighting, it will bring illumination without calling attention to itself.
• User adoption. The implementation of BI technology should be considered the start of a project, not the end. Better access to data doesn't provide any benefits -- that only happens when business processes change based on the new information. Training must be more than a one-off activity, and encompass all aspects of business change management.
• Standardization. Having a standard BI environment across the organization helps provide economies of scale on all aspects of training and user adoption, and makes it easier to create a community of users that can support less experienced users.
• Competency centers. Organizations should invest in a BI competency center: a team that is dedicated to making the best use of the organization's information assets, ensuring the right trade-offs between the needs of each department/project and the company as a whole.

Sound Judgment

Decision-making processes, whether formal or not, need to leverage the strengths of human intuition. Data does not run companies; people do.

• Collaboration. Intuition is very important, but it needs safeguards -- and one of the best is other people. It must be easy to share data, different interpretations of what data means, and proposed plans to improve the situation. The more information is shared, the more likely it is that bad decisions are avoided.
• Guided analysis and best practice applications. Many decisions have to be made on a regular basis by lots of different employees. Organizations should propose a consistent set of analysis steps in order to help every user make decisions as well as the best analyst.
• Links to financial planning. Business decisions have to be backed up by appropriate business changes, including budgets. Your business intelligence systems should be closely linked to your organization's financial systems.
• Profitability analysis. Make sure that decisions are being made based on what's important: profit. After all, there's no point in maximizing revenue if you’re making a loss on each product.
• Sharing with the business ecosystem. It's no longer just about your organization. You increasingly need to make decisions based on the operations of the "business ecosystem" of customers, partners, and suppliers. For example, to make sound decisions about quality you may have to share and collect warranty information from your distributors.

Trust

To gain employees' confidence in management decisions, establishing transparency and trust is at least as essential as a good track record.

• Shared vision. The more widely information is shared across the organization, the easier it is for employees to understand and carry out executive decisions -- and to provide critical front-line feedback.
• Linking strategy to execution. Nine out of ten organizations struggle to execute their strategy. One thing that can help is clear scorecards and dashboards that cascade high-level goals into key performance indicators that are tracked for teams and individuals. In particular, this helps make the inevitable tradeoffs between different decisions more explicit and transparent.
• Compensation management. People must not only understand the strategy, but understand why they should follow it. There are few things that are more likely to make employees resist and mistrust decisions than misaligned incentives. Applications exist that help organizations plan and implement optimal compensation management strategies -- and track if they're actually achieving the desired goals.

Flexibility -- One Size Does Not Fit All

Approaches to decision-making, and even to the use of data, need to reflect the fact that the world is a diverse place, and one size does not always fit all.

• Standard platform. Letting every individual or group look after its own information needs is a recipe for disaster. A BI competency center should be given the mandate to make the necessary trade-offs between flexibility and standards. In today's fast-changing business environments, flexibility is achieved most easily with a standard platform but a variety of different techniques and interfaces appropriate for different users and situations.
• Collaboration. Organizations increasingly realize that decision-making is an activity that needs to be opened up to more people in the organization. Top-down execution of fixed strategies is giving way to more flexible, collaborative approaches, and a common "information infrastructure" is an essential enabling technology.
• Service-oriented architectures. Computer systems are moving from monolithic suites to more modular, "services-oriented" architectures. As business intelligence becomes more process-oriented, organizations need the ability to easily share and consume information services that can be adapted by business users without further IT assistance.
• Independence. The more volatile the environment, the more companies need to be able to access critical information fast. Your information systems should be maintained separately from your underlying operational systems, and support any and every environment, and be ready to accept information from new systems -- you never know when you might merge with another organization, for example.

Conclusion

Technology is necessary but insufficient condition for good decision-making and performance excellence. Without a solid information infrastructure, and support for financial planning, the best decisions and strategy in the world is unlikely to succeed.

Posted by Timo Elliott at 03:51 PM | Permalink | Comments (0) | TrackBacks (0)

Wayne Eckerson and I will be presenting two web seminars this week on the subject of putting TDWI's BI Maturity Model to Practice:

Recording - Benchmarking Your BI Maturity Overview
Provides an overview of the five stages of the BI Maturity model and the two major obstacles - the Gulf & Chasm. The goal is to demonstrate how the model can be used to help assess and evolve any BI/DW program.

September 25 at 12:00 pm Eastern
Spanning the Gulf: Getting Traction for Your BI Solution
Explains the symptoms of the Gulf and provides prescriptions for making a clean crossing into a BI environment that delivers tangible business value. If you're having difficulty getting traction for your BI solution, you're probably stuck in the Gulf - a confluence of obstacles and challenges that affect early-stage BI projects.

September 27 at 12 pm Eastern
Crossing the Chasm: Delivering a Strategic, Enterprise BI Solution
Reviews the key challenges facing more mature BI programs and provides tips for creating an agile architecture and organizational structure that can help you cross the chasm to deliver high-value strategic solutions across the enterprise. If you are struggling with reconciling the different BI/DW deployments in your organization and dealing with issues of scalability in terms of people and processes, this webinar is for you

We're going to try to make it as interactive as possible. Please join us, and ask difficult questions!

Posted by Timo Elliott at 02:39 PM | Permalink | Comments (0) | TrackBacks (0)

Despite some people dismissing it as a myth, BI standardization is alive and well in organizations around the world. Here's a quick primer on what, why, and how.

What is BI Standardization?

The phrase "BI standardization" often gets a negative reaction, because people equate it with choosing only one tool to the exclusion of all others, and taking away existing products from happy business users.

My definition is this:

Pragmatically implementing BI standards to reduce overlapping tools, lower costs, and maximize the benefits of BI.

The definition explained:

• Pragmatically. It's not about architectural elegance, it's about business benefits
• Reduce overlapping tools -- it's about having a rational portfolio strategy, not a single product from a single vendor.
• Lower costs. This is the reason organizations start talking about standardization
• Maximize the benefits of BI: This is why reasons should be looking at implementing BI standards

Other terms that could be used include "BI rationalization," "BI consolidation," or "preferred BI vendors" -- whatever the language used, there are clear benefits.

Why BI Standardization?

Why do organizations implement BI standards?

• To save money. The first, clearest, and most obvious benefit of standardization is that you can save money in every area of implementing BI projects. You can avoid unnecessarily duplication of the costs of evaluating, purchasing, implementing, and maintaining multiple overlapping BI tools.
• To increase business insight and alignment. The more BI tools you have, the harder it is to get a full understanding of  the business. A single standard makes it easier to establish common definitions of your key performance indicators. You can spend less time arguing over the data, and more time arguing over what to do.
• To reduce risk and confusion. Implementing standards makes it easier to ensure that you're following data and compliance rules. Having the same tools for financial reporting, risk management, and budget tracking make it easier to spot anomalies.

For more detail, see my 2005 white paper on "Benefits of Business Intelligence Standardization".

How to Implement Standards?

All organizations have explicit or implicit tiers of IT standards, running the continuum from "we don't care" all the way through to "don't even think of using something else". As business intelligence has matured and become more widespread in organizations, it has slowly climbed the ladder.

BI standards are typically initiated by procurement teams. Noting that the organization is purchasing the same products across multiple departments, they step in to purchase in greater volume for the organization as a whole, driving down the average per-user purchase price.

Note that this only directly saves money on software license costs -- typically a tiny proportion of the overall costs of implementing BI. Getting the full benefits of standards requires a team that can persuade various different BI projects to work together for the greater good of all: a BI competency center (see "fixing the BI tragedy of the commons").

Note that most organizations will never reach their standard, because there are inevitable trade-offs between efficiency and local flexibility -- but heading for a standard is obviously better than accepting chaos.

For more information, see my 2005 white paper on "Implementing BI standards -- a Field Guide".

What's the Future of BI Standardization?

There will always be procurement benefits of buying products in greater volume, but the hard part is standardized metadata and semantics across the breadth of data sources that real-life users are interested in, including personal and non-structured data.

As the business intelligence industry adapts to a services-oriented world, there may be the potential for organizations to be able to mix-and-match different solutions and still retain a coordinated overview of the business as a whole. See "Will BI Sparql Thanks to the Semantic Web".

Posted by Timo Elliott at 09:04 PM | Permalink | Comments (1) | TrackBacks (1)

From Frank Buytendijk's blog, and Andries Bottema:

"BI is deploying information as a factor of production."

In other words, BI makes information the fifth factor of production, next to labor, capital, materials, and facilities.

Quite simply: Yes!  Information is the last great underdeveloped asset in today's organizations. And unlike other assets, it can be used by multiple people and processes, and it's also a natural by-product of production. These two characteristics lead to the "network effects" or "increasing returns" of better information.

I immediately wondered if such an apposite description had been used before, and turned to Google. The general opinion seems to be that the "new factor of production" is "intellectual capital", an umbrella term that includes information, but also "knowledge, collaboration, process-engagement, and time quality". 

So maybe the definition should be "BI is deploying intellectual capital as a factor of production"? Not quite as snappy, but it might be a better fit for BI 2.0 -- BI that is not only about "information", but also about knowledge management and collaboration?

In any case,  "BI is deploying information as a factor of production" strikes me as an excellent way for IT and BI organizations to explain the importance of their role to the organization, and I'm sure I'll use it in a presentation soon -- thanks Frank and Andries!

Finally, while looking at the articles, I dimly remembered a presentation by Dave Kellogg that had mentioned factors of production, and thanks to the wonders of the Windows Search Deskbar, I was able to find it buried deep in my PC. It was called "Future Shock: Crisis or Opportunity", presented in 1998, and it included the slide below, with information as the "bottom line"...

Posted by Timo Elliott at 09:48 PM | Permalink | Comments (0) | TrackBacks (0)

Cindi Howson talks about the "BI Tragedy of the Commons" in her latest Intelligent Enterprise post.

The "tragedy of the commons" is a well-known issue in economics, involving a conflict between what's good for the individual and what's good for a group as a whole. Cindi uses it to describe the problem of departmental BI silos when it would make more sense to use a more enterprise-wide approach.

One problem with this example is that once you take all the variables into account, it's not clear that silos are necessarily a bad choice, at least in the short term. My experience is that trying to take an enterprise approach too early is rarely a good solution in the real world, where it's typically better to develop a series of departmental projects first, and only then go back and develop a more information infrastructure approach.

But I agree 100% that the "tragedy of the commons" does indeed plague business intelligence deployments. Luckily, the potential remedies are as well known as the problem -- although they can be difficult to apply.

Put simply, economics is the study of incentives -- and my experience is that misaligned incentives are one of the biggest issues facing business intelligence today (see related post on who "owns" BI issues)

To fix the problem, you have to assign ownership rights to the assets in question. For example, you can "enclose the commons", and force people pay if they want to let their animals graze. The land doesn't get over-grazed because people aren't willing to pay to get access to land that no longer provides any nourishment.

By default, most organizations give ownership of their BI projects to the department that implements them -- i.e. they have the "right" to create silos. This is the equivalent of farmers having the right to let their animals graze, and the opposite of the example above.

So one possible solution to our problem is to reassign ownership rights to a special body designed to get the best use of the organization's assets -- such as a BI competency center. If a department wants to build a silo application, they would have to "pay" the competency center for the right to build a silo -- or at least explain why it was the best course for the business as a whole, rather than just their department. Note that this could still result in some silos being built, but only when the circumstances made sense.

However, having a central, "ivory tower" body controlling departmental activity is the inverse of today's trends in decentralization. More and more organizations are pushing decision-making out to the organizations on the front-line, recognizing that the increased ability to react fast to new situations typically trumps the increased efficiencies of more centralized structures.

Luckily, in classical economic theory, you get optimal use of resources whoever gets ownership rights. So we can address the problem differently: departments can retain the "right" to make silos, and the BI competency center can "pay" the departments to do the right thing for the organization as a whole.

This solution is much better aligned with the way organizations typically work. The BI competency center get funding through a "tax" (e.g. the "IT infrastructure" line in the annual budgeting cycle) and provides expertise and resources to departments that agree to take a more enterprise approach.

Note that this situation allows for an "optimal" mix of silos and enterprise-wide solutions -- if a department considers that they can build a valuable silo without the central resources, they're still free to do so. By controlling the level of "tax", organizations can exert more or less centralized control.

The problem is typically that organizations don't think in terms of ownership rules, and fudge an incomplete and confusing mix of the two approaches, with some centralized control battling against the departments desire for autonomy, and disagreement about "what's best for the company". This in turn results in tension between IT and the business, further decreasing the likelihood of long-term BI success.

To summarize; First, it's essential that organizations have a body that has the authority to represent the "common good" of integrated information -- such as a BI competency center. Second, it has to be clear where "ownership" lies, and what mechanisms exist to "pay" the owner to do the right thing for the organization as a whole.

Posted by Timo Elliott at 06:18 PM | Permalink | Comments (1) | TrackBacks (0)

I'm finally getting around to posting materials from the Business Objects Insight User Conference in Berlin, 21-23 May 2007.

You can find my photos from the event here -- mainly from the main stage, including the inxight purchase announcement and keynotes by John Schwarz, Bernard Liautaud, and the climber Reinhold Messner.

I did a presentation on the "five fatal flaws of BI projects" -- you can get a ppt version of the slides here. I try and keep text on slides to a minimum, so they may be a little hard to follow, but there's some basic comments in the "notes" section and I covered the same material in a previous post. When I have time, I hope to develop the themes into more complete blog postings...

As usual, any comments and feedback very welcome -- as one person mentioned in their review: "It's real-life-stuff :-( It's exactly how it works in my company"...

Posted by Timo Elliott at 05:19 PM | Permalink | Comments (0) | TrackBacks (0)

Over the last eighteen years, I've been associated with a large number of BI projects and have been able to see first-hand what behaviors correlate most closely with success and failure.

In particular, there are five main erroneous assumptions about implementing BI that can lead to failure. This list is condensed and a little simplistic: every single one of these bullets could be a blog posting on its own -- and I hope to get around to doing just that one day...

1. BI isn't about technology, it's about people.

80% of the time and effort that goes into implementing BI is typically devoted to the technology and the data. But BI success is determined primarily by people, process, organization, culture, expectation setting, and leadership.

• User adoption. Giving somebody a pencil won't make them Picasso. Organizations typically under-invest in training and culture changes necessary to make the best use of BI. It's easy to over-deliver to a small number of vocal, technical users that can clearly articulate their needs, and miss the greater value of a broad deployment to less technical users.
• The IT/Business relationship. BI is meeting point between the tens of millions of dollars invested in IT and the business strategy it is supposed to support. There has to be an equal partnership between IT and the business. A "tough-love" approach that mixes firmness with diplomacy and establishes clear areas of control is the most likely to be successful.
• Marketing the solution. Successful BI requires not just "promotion," but an ongoing effort to match the "product" to the real needs of the users. Internal prizes for the best business use of BI can provide a win/win/win situation for IT, users, and executives.
• Self-awareness. Many BI leaders have a background in technology. If they are uncomfortable with the people-intensive roles needed to make BI successful, these should be delegated to those who delight in them.

2. BI is a process, not a one-off project

• There is no finish line. This is true of all IT projects to some extent, but especially for BI, because by definition as the organization uses it, you'll discover new questions and new BI needs. An organization that doesn't have constantly changing BI needs is an organization that isn't using BI effectively.
• BI is part of every solution, not an add-on. BI is dominated by architecture thinking: I'll build the foundation (operational application) first, and then I'll think about how to get the data out. But in real-life, the BI needs will determine the operational application deployments, and should be considered at the same time.
• BI Methodology. Organizations should have a formal methodology with interlocking business and IT development cycles. What goes wrong: (a) business users aren't on the hook for BI success, (b) the two cycles disengage, with IT incrementally adding to infrastructure that nobody uses while the business users turn to home-made solutions.
• BI competency centers. A team dedicated to ensuring that the organization is prioritizing its investments in BI correctly and making the best use of the "information assets." The ideal team is like Starship Enterprise: Scotty handling the engineering, Spock for data analysis, Bones for the relationship with the business users and Kirk for strong leadership. What typically goes wrong: (a) incentives: it's clear that the business would benefit from the BICC, but no manager is incented to give up his or her resources to make it successful, (b) ivory tower syndrome: the group concentrates on technology instead of the users' needs, and gets disconnected from business reality.

3. BI isn't about cost, it's about value

• BI shows very high ROI -- retrospectively. But because you don't know what you don't know, it can be hard to justify the ROI in advance. And because every computer layer that has ever been sold has promised the same thing: better access to information for the business. Suggested approaches: (a) use history to show what BI has done in the past, (b) link the need to minimizing risks, and give real-life examples, (c) link it to the speed of business, and give real-life examples, (d) explain the need for BI in relationship to the overall strategic goals of the organization, (e) play on the universal executive fear of having somebody say "what? you don't know?", (f) align BI along a key business process, (g) implement dashboards with your best guess about KPIs, and use them to lead discussion on what the organization should be measuring.
• BI Extranets to customers, partners, and suppliers. These are perhaps the highest-ROI BI projects of all, but often the last to get implemented.

4. BI isn't about data, it's about insight

• Nobody needs more "data". We're drowning in it, and things are getting worse. The cost and time for data integration and quality is systematically underestimated in BI implementations (the iceberg problem). Walking the CFO/CEO/COO through a big piece of paper showing the real-life mess that generates the figures they report to Wall Street can help generate awareness and funding.
• Fragmentation. Fragmented data sources are the norm, not a temporary state of affaires. It will ALWAYS be necessary to integrate information from multiple sources in order to get a global viewpoint.
• Benchmarking. What executives really care about is benchmarking against external data sources. Make sure this is part of the implementation. SOA architectures and "information on demand" is making this easier.
• Trust. Business people don't trust the data they are provided. Poor data quality is a given, but most organizations don't know where or how much they are suffering -- you need to shine a flashlight into the dark corners. And cleansing the data isn't enough -- the process and results must be transparent to the users (you trust Fedex to deliver, right? So why do you care about tracking?)
• Poor Analysis Skills. Studies show that business people are not very good at analyzing data -- more data can actually lead to worse decisions. A BICC with analysts on staff can help avoid problems, as can greater collaboration. (Did you know that 99% of teenage suicides had listened to rock music in the week before their death?)

5. BI isn't about perfect planning, it's about being pragmatic.

Planning is essential, but plans are useless. It's not about doing it right in theory, it's about dealing with real-life changes.

• Executive sponsorship. This is essential, but you have the responsibility to get on the shortlist of things they care about. This requires (a) successful prior projects, (b) marketing and promotion, (c) linkage to company goals, (d) linkage to his or her personal goals/career.
• Performance management. When implementing BI, there's a tendency to try and measure the wrong things, in the wrong ways, and measure too much. People are not pigeons -- i.e. it's more complicated than giving simple treats for pecking in the right place. A great body of research shows that the way typical managers expect people to react to rewards and KPIs is just flat-out wrong.
• Budgeting and planning. Successful strategy implementation requires performance management and BI, and that often passes by the budgeting process. The "budgeting game" can result in deeply dysfunctional behavior in companies. "Beyond Budgeting" is an alternate approach that essentially uses BI and benchmarking to run the organization.
• Getting the time to do it right. (a) standardization and simplification, (b) do "less", more successfully, (b) BICC efficiencies, (c) using BI and dashboards for IT, (d) software as a service
• Other tips: (a) keep the project up to speed -- if you get "tired out", hand over to new blood, (b) small projects towards a strategic whole, (c) the ONLY cardinal sin is to be out of alignment with the business users, (d) admit problems fast.

Finally: successful BI requires a incredible diversity and level of general skills: mastery of technology, marketing and communications, diplomacy, project planning, deep business knowledge, leadership and people skills. Folks that implement BI are my heros. Good luck!

Posted by Timo Elliott at 10:39 AM | Permalink | Comments (2) | TrackBacks (1)

Computerworld has an interesting article about the difference between trust and security. A county coroner gave out his logon information to a confidential police 911 system so that newspaper reporters wouldn't bother him each time they needed information. This resulted in, for example, a drug informant being badly beaten up when his name was revealed.

The information only came to light after one of the reporters complained that he didn't have access to the site, but could have been revealed much earlier through better reporting:

"Eventually, an IT staffer checked Web site logs and discovered that the site was accessed more than 50 times in two weeks from computers at a newspaper office."

Of all the departments in the organization, IT should be able to implement retrospective network security analysis relatively easily -- there are typically existing tools, it would only require a single user license, they have the expertise, etc.

So do organizations do this? Why not?

Posted by Timo Elliott at 02:31 PM | Permalink | Comments (0) | TrackBacks (1)

Computerworld has an interesting article about the difference between trust and security. A county coroner gave out his logon information to a confidential police 911 system so that newspaper reporters wouldn't bother him each time they needed information. This resulted in, for example, a drug informant being badly beaten up when his name was revealed.

The information only came to light after one of the reporters complained that he didn't have access to the site, but could have been revealed much earlier through better reporting:

"Eventually, an IT staffer checked Web site logs and discovered that the site was accessed more than 50 times in two weeks from computers at a newspaper office."

Of all the departments in the organization, IT should be able to implement retrospective network security analysis relatively easily -- there are typically existing tools, it would only require a single user license, they have the expertise, etc.

So do organizations do this? Why not?

Posted by Timo Elliott at 02:31 PM | Permalink | Comments (0) | TrackBacks (1)

Your organization has a travel and expense policy. It's probably long and complicated, with lots of rules that your employees roll their eyes at, and your financial controllers probably struggle to implement it. Why? Because the role of finance includes controls, and because "control" is too often translated into "rules."

A BI approach to expense controls

But rather than trying to control every situation (an attempt to list everything that an employee can't expense, for example), a travel and expense policy should be a statement of general principles: "spend money as if it were your own", "book your travel directly over the web if it's >30% cheaper." Given human nature, some will always ignore the principles -- which is where business intelligence comes in.

Expect what you inspect

With BI, transparency replaces controls. Effective management reports can flag exceptional expenses and compare them against averages -- showing, for example:

• A marketing director wants to buy an air ticket that costs double the company average for the route.
• An Eastern sales manager spends twice as much on hotels as his western counterpart.
• A certain department spent more this quarter on entertainment than they did in the whole of last year.
• France spends more 10% on travel than the UK, but generates 20% more sales per trip.

The benefits

Controlling all expenses is advance wastes time and money each time the expense is legitimate -- i.e. in the vast majority of cases. And policies and rules can only limit costs -- following the rules is no guarantee of lowest costs. For example, if an employee really wants to travel on his or her favorite airline, he or she could book later than strictly necessary, hoping that the lower-cost options at other airlines will no longer be available. In a rules-based system, this type of behavior is almost impossible to detect and prevent.

In theory, BI has the potential to allow finance to prevent abuses and optimize expenditure, while allowing managers and employees more flexibility, at a lower administration cost to the organization.

So why don't organizations do this?

One reason for prior controls is the surge in compliance regulations. But I believe those regulations emphasize having effective systems in place rather than laying out in detail exactly how the controls should be carried out. And the same regulations also typically require greater transparency, which implies improved BI.

Of course, carrying out BI requires that the data is available in a suitable system. But increasingly, this is provided automatically as part of web-based expense systems. 

BI is almost always considered as an add-on to the "real" project, to be implemented months or years after control systems are operational, if ever. But why is this? There is a cost associated with BI, of course -- but implementing BI can save of the costs associated with rules-based systems, by concentrating resources more effectively on abuses or areas where costs can be reduced.

So why isn't BI considered as part of an optimal system at implementation, rather than something to potentially be added on at a later date?

Posted by Timo Elliott at 02:24 PM | Permalink | Comments (0) | TrackBacks (0)