Data Management Strategies

A Less-Stodgy Enterprise IT

Blogger: Lyn Robison

Enterprise IT isn’t as cool as the Web, and here are some reasons why. The Web allows information to flow, and the Web also allows people to collaborate and build relationships with one another. Enterprise IT generally doesn’t. Enterprise IT is stodgy because IT systems are most often implemented in nonflexible silos that were designed primarily to automate individual business processes. Silos in Enterprise IT are not designed to let information flow, and enterprise IT silos are most often not designed to let people collaborate and build relationships with one another. In short, enterprise IT is not cool because IT doesn’t let information flow or people collaborate.

Enterprise IT is obligated to automate business processes. We gotta do that. The business expects enterprise IT to automate their work. But business process automation should not be all that we do in enterprise IT. The business needs more from enterprise IT than process automation. In fact, if process automation is all that we do in enterprise IT, the business will think we are stodgy, because we are.

To find information about how to let people collaborate and build relationships with one another, see the CCS blog.

Letting information flow in enterprise IT requires two things:
1. Lowering the level of information model pre-agreement
2. Managing identifiers

The Web is a terrific platform for sharing information because the level of information model pre-agreement is low. A web client and a web server need only understand the HTTP protocol and a few basic document types. Typical data integration between enterprise IT systems requires a high degree of information model pre-agreement, and that makes data integration difficult, and that makes enterprise IT stodgy. What many IT professionals fail to realize is that when you are integrating data that is to be consumed by humans, you can use the Web model, and you don’t need to have this high degree of information model pre-agreement.

When identifiers are managed properly, enterprise IT gets less stodgy. For example, UPS and FedEx can easily track parcels, using tracking numbers. People with common names can be removed from terrorist “watch lists”, because of the RFID tags in their passports. Automobiles are easily distinguished using their license plate and/or their VIN. And airplanes can be readily identified using their tail number. When enterprise IT manages identifiers improperly, which sadly is quite common, the business can never get a complete view of their interactions with a particular customer, because that customer is identified differently in different systems. The business can never manage any long-lived and valuable assets through their useful life, because each long-lived asset is identified differently in different systems. And businesspeople cannot find the information they need on a wide variety of vital business topics, because information about those topics is buried deep within silos and is irretrievable because it is misidentified. And this makes enterprise IT stodgy.

Let's fix IT's stodginess by enabling people to collaborate and build relationships, by lowing the level of information model pre-agreement, and by managing identifiers properly.

Spinning your Wheels with BI

Blogger: Lyn Robison

BI system implementations follow a cycle. The cycle starts when businesspeople begin seeing the need for better intelligence. The decision is eventually made to implement a new BI system. The enterprise spends hundreds of thousands of dollars on BI, ETL, and DW tooling. They spin up a project or series of projects to load the data into the DWs and to create the queries and reports that deliver the intelligence to the businesspeople. With the cost of time and labor, development tools, software licenses, and computer hardware, it is quite easy for an enterprise to spend a million dollars or more on a new BI system.

The sophisticated tooling, the complex BI systems, and the cutting edge technology are impressive. It is easy to think of the BI system as a large, highly developed, powerful engine. All that is needed to fire this engine up is some fuel. That fuel, the data, comes from the enterprise’s operational systems. Powerful ETL tools extract the data from the operational systems and transform the data so that its shape conforms to the mold in the DW. The ETL processes load the data the way that barrels of oil or stacks of lumber or bushels of wheat are loaded into warehouses (after all, data is nothing but a fungible commodity that can be easily replicated, aggregated, summarized, sliced and diced, right?). Once the data is loaded, the BI engine does its work beautifully. The engine plows through huge quantities of data, aggregating it, summarizing it, analyzing it, and allowing businesspeople to mine it for gems. Sure, the data is not perfectly accurate, but everyone assumes that the numbers will be close enough. After all, smart people are accustomed to working with uncertainty. And look at that BI system do its work! The complex, powerful BI system is truly a sight to behold, a thing of beauty, and the IT people are justifiably proud of their hard work.

Then the questions start. A few businesspeople ask to see where the BI system’s numbers are coming from. Are the operational systems from which the BI data is pulled the authoritative sources for information on the topic at hand? Did data from all of the relevant data sources get included? Is there any documentation on the BI system’s data handling, such as data models or data flow diagrams that show the data’s lineage? What calculations and processes does the BI system use to produce this information? Do those calculations and processes reflect the corporation’s policies and business rules? Does the information reflect the changes that occurred when that new manufacturing plant came online or when we switched to that other supplier? Were the identifiers reconciled properly between systems? Can anyone say for sure whether or not customer XYZ and customer 47 are actually the same customer? If not, how do we know that the BI system is summarizing the data about each of these customers correctly? If the numbers from the BI system are off, how far off are they? How can we know?

These questions about the reliability of the BI information eventually become a problem. No one can give a satisfactory ROI calculation for any data quality efforts. So data quality issues are never addressed in a systematic way, and as a result, the data quality is consistently neglected and continually deteriorates. Eventually, businesspeople aren’t sure how much they can trust the numbers coming from the new BI system. Businesspeople begin seeing the need for better intelligence. The decision is made to implement a new BI system. Here we go again. Let’s build another BI system!

In this cycle, the enterprise tries in vain to address problems of information reliability and usefulness by creating yet another system. Unfortunately, that does not solve the enterprise’s basic problem. The enterprise does not lack systems. The enterprise lacks reliable, useful business information.

Eventually, the business leadership sees that they are spending millions of dollars on IT, and they begin to look for cheaper ways to get business intelligence, through approaches like IT outsourcing, cloud, and SaaS. If they could peer into the future, they would see that IT externalization will at best give the business the same mess for less.

The fundamental problems that make BI systems ineffective are the mistaken perceptions about data that are harbored by most IT professionals. In truth, data is not merely a fungible commodity that can be moved around and aggregated and summarized to fill up data warehouses the way that crude oil can fill up oil tanks or steel barrels. To be useful for any purpose, data must be an accurate picture of reality.

To be an accurate picture of reality, data must accurately represent individual, non-fungible assets. Barrels of oil might be fungible (interchangeable) – one barrel of oil might be just as good as another, but one customer is not just as good as another. Customers are not interchangeable. Neither are buildings, factories, documents, contracts, decisions, or any number of vital business assets. If the data representing those non-fungible assets is treated merely as a fungible commodity, the data will not accurately represent reality, and the enterprise’s data will be expensive but unreliable for business decisions.

Data Warehouses and non-fungible Assets: a bad Combination

Blogger: Lyn Robison

If you do a Google search on "data warehouse failures", you will get a taste of the hazards of data warehousing. One sure path to failure is to try to do something with a data warehouse that data warehouses are not good at. That would be using a data warehouse to track or manage non-fungible assets.

Fungibility might sound like an obscure concept that has little to do with implementing successful information systems, but fungibility is central to relationships, collaboration, ILM, information security, identity management, and business intelligence. And non-fungible assets are something that data warehouses don't manage well.

Understanding the concept of fungibility can enable IT professionals to avoid a common path to failure when implementing a broad range of information systems. A lack of understanding of fungibility is one reason why data warehouses and business intelligence projects often don’t deliver their promised benefits, why enterprises have had such a difficult time implementing CRM systems, and why few if any large enterprises know how many customers they have. If you don’t know how many customers you have and who they are, you can’t know how much each customer is buying from you, or understand what each customer is asking for, or manage how each customer relates to other customers or to your company’s salespeople. And it’s not just customers. If your information systems cannot give you an accurate picture of the non-fungible assets owned by a typical enterprise, you can’t manage them and you can’t manage anything that relates to them.

Q. What is fungibility?
A. You can find a good definition of fungibility here: http://en.wikipedia.org/wiki/Fungibility. You can also find some thoughts on IT fungibility here: http://it.toolbox.com/blogs/minimalit/fungibility-27324. A few quick examples would be: ¾” sheet metal screws are fungible, kiln-dried douglas fir 8’ 2x4s are fungible, barrels of oil of the same type and grade are fungible, dollar bills are fungible, but buildings are not fungible, employees are not fungible, and customers are not fungible. Fungible commodities have attributes and characteristics, with type and quantity being the most important considerations. Non-fungible assets have identity (in addition to attributes, characteristics, and type), with identity being the most important consideration.

Q. What happens if I treat fungible commodities and non-fungible assets the same way?
A. You will not achieve the results you want. (Click on the Dilbert cartoon below to see an example.)

 

Q. What happens if I treat data about fungible assets and non-fungible assets the same way?
A. Your information systems that are intended to track non-fungible assets will not be successful. Examples abound. Enterprises cannot easily determine which data to archive in an ILM setting because they don’t know which data refers to long-lived, non-fungible assets. A large, multi-national non-profit organization does not know how many buildings it owns. The most sophisticated army in the world does not know how many battle tanks it has. Our friend and colleague Joe Bugajski very nearly died when medical professionals could not keep track of his medical condition and treatment (see Joe’s blog post and my related post).

Q. What is the worst way to treat data about non-fungible assets?
A. In two words, “data warehouses”. Data warehouses are best-suited for aggregating, calculating, and analyzing quantities of fungible commodities. For example, they work well for adding up the dollars of revenue and expense for an income statement. This is because data warehouses shine when working on type and quantity. Unfortunately, data warehouses are often misapplied for use with data about non-fungible assets, and millions of dollars of sad experience have shown that data warehouses are a manifestly poor platform for managing identity, as a Google search on "data warehouse failures" will reveal.

Q. What is the best way to treat data about non-fungible assets?
A. In a word, “registries” (another word might be “directories”). Identity is the most important consideration for managing non-fungible assets. For guidance on registries and identity, see "Delivering Integrated Information from Data Silos Using MODS" and the Identity and Privacy home page.

The Algebra of Data Quality

Blogger: Lyn Robison

A basic algebra formula illustrates the value of data quality. To be sure, it is an illustration or a metaphor more than an actual formula for data quality, but it does demonstrate the need for and the value of information/data quality in enterprises today. The formula is a familiar one:

y = Ax² + Bx + C

In this illustration, "y" is the value that IT contributes to the business. "x" is the degree of data quality, ranging from 0 to 100. "A" is the money that the organization has put into BI systems. "B" is the money that the organization has put into operational systems. "C" is the money that the IT group spends managing complexity and building and running systems.

As you can see, if "x" (data quality) is zero, then the only value that the IT group contributes to the business comes from managing complexity and building and running systems. If x = 0, the value to the business of BI systems and operational systems (represented by "Ax²" and "Bx") are both zero.

You will also notice that when it comes to BI systems, the value is based on the square of the data quality (Ax²). If the data is of high quality, BI systems will yield highly valuable insight to the business. By contrast, if the data is of poor quality, the BI systems will produce nothing but garbage and will therefore be useless to the business.

There are many IT departments out there which are run by IT people who firmly believe that IT’s role is to manage complexity and to build and run systems for the business. In these IT organizations, data quality is not a high priority. As a result, the business derives little or no value from their BI systems and their operational systems. In these situations, the businesspeople are looking for ways to replace their IT groups, by adopting SaaS, cloud computing, and IT outsourcing. Clearly, IT people who believe that IT’s role is merely to manage complexity and to build and run systems are will find themselves competing unsuccessfully against external service providers who can do the job far more efficiently. That is not a good career path for IT people. On the other hand, data quality offers an excellent career path for IT people, because data quality is the key ingredient in the value that any IT group delivers to the business.

I recently read a fascinating article by a senior editor at Securities Industry News that illustrates how data management is no longer optional, especially for financial firms. Here is an excerpt:

… In fact, some firms may eventually decide to designate a chief data officer to manage a team of data specialists, such as data modelers, data stewards and taxonomists. The specialists, in turn, will figure out what data is stored where, verify its accuracy, build data models and create and attach metadata. The data officer and the team would decide who may access what data, integrate databases, and maintain archived data to meet regulatory requirements.

Most firms so far are maintaining the status quo -- keeping different pieces of data in many different databases.

Often, according to Atkin and other data experts, this can amount to as many as 30 different, somewhat redundant databases with discrepancies and errors, as well as 30 or more applications that consume reference data and incoming data feeds from over a dozen data vendors.

Such a hairball for collecting data just won't cut it any more.

"How a firm reacts to the need for accurate, timely, integrated data is now a critical differentiator in a competitive environment," warns Dayle Scher, a senior analyst with Tower Group, a Needham, Mass-based research shop. "Financial firms must be prepared to respond to increased due diligence on the part of investors and certainly more restrictive regulations looming."

After ensuring the data is accurate, says Scher, firms will need to share that data with downstream applications such as order management and portfolio accounting software and staff that need it, in the right formats and in a timely manner…

You can read the full article (entitled “Follow the Data When Tracking Systemic Risk”) here: http://www.information-management.com/news/data_management_risk_grc-10016449-1.html

I have discovered some excellent sources for eye-opening information on the need for data quality, including "Does Your Business Suffer From a Data Quality Reality Gap?", a YouTube "Information Management Fairy Tale", and www.IQTrainWrecks.com, a website dedicated to information/data quality disasters from around the world.

Is BI destined to die like SOA?

Blogger: Lyn Robison

Business Intelligence is a hot topic. Enterprises are spending large sums on BI initiatives. Unfortunately, BI projects are failing more than they are succeeding. BI initiatives typically do not deliver their promised benefits. I just saw a survey that says almost two-thirds of companies that employ BI are being barraged with complaints that the system isn¹t doing what they need it to do. Another survey undertaken by the National Computing Centre found that only 13% of BI projects undertaken in the United Kingdom lived up to expectations. This figure is mirrored by a number of other studies.

We at Burton Group are coming out with some guidance soon that should improve your odds of success on your BI projects. In a few days we will publish a paper entitled, “The BI Iceberg: It’s What’s Beneath the Surface That Matters”. And within the next couple of months we will publish a BI maturity model that will help you evaluate the level of maturity (and by extension, the chances of BI success) in your enterprise. Maturity models are helpful because they are both descriptive and prescriptive. They are descriptive in that they help you see where you are. And they are prescriptive in that they help you see what you need to do next to make progress.

Having said this, however, I am concerned about BI’s future. With these high failure rates, BI seems to be on par with SOA. My friend and colleague Anne Thomas Manes wrote an obituary for SOA (here). I have to wonder, in a few years will someone be writing a similar obituary for BI? From what I can see, if we in enterprise IT don’t find ways to make BI projects more successful more often, BI is likely to die and take the careers of many BI professionals with it.

There is an alternate path: one that leads BI to success and prosperity. This alternative path runs counter to conventional thinking about how to implement BI systems. This alternative path to BI success truly is the road less traveled, and leads beyond business intelligence to reach business insight.

Professionals who embark on this alternate path understand that traditional BI is based on a false notion. The false notion is that it is feasible to take applications that were built to address localized requirements and stitch their data together (using data warehouses) into a larger picture that represents reality at the enterprise level. In the first place, the data from different apps won’t fit together. All of the king’s horses and all of the king’s men can’t put Humpty Dumpty’s data together again, because the data from individual apps was never designed to fit together in the first place. And in the second place, the chronic lack of data quality means that most application data tends to contain garbage anyway -– and garbage in, garbage out. This false notion that all you have to do in BI is pull together data from various apps is no doubt at the root of the high failure rates of BI projects. It usually can’t be done. And as the high failure rates attest, traditional BI simply doesn’t work.

The first step in this alternate path that leads to BI success involves understanding the relevant data. You have to understand what the data means, what it represents, how closely it reflects reality (its data quality), what part of the total enterprise picture it paints, what localized or provincial assumptions mar the data, who governs the data, how does the data and the part of the business it represents relate to other pieces of data and the parts of the business they represent, etc. In short, this alternative path to BI success requires BI professionals to switch from being software implementers to being enterprise data people.

BI systems are not the engine and data merely the fuel. Rather, BI systems are merely the mine shafts and the data is the gold. In this alternate path to BI success, you understand, optimize, and cater to the data, and the data is all but your exclusive focus. When BI professionals focus on building the data instead of on building BI systems, the systems they implement go beyond business intelligence – they yield valuable business insight, and that is BI success.

We at Burton Group have published lots of guidance and will publish further guidance in the future on how to treat enterprise data like gold. My hope is that we can save BI from the painful death that SOA experienced, and turn BI from Business Intelligence into Business Insight.

Is Data Integration Working?

 By Noreen Kendle

The typically approach to data integration has been a bottom-up, data systems, tools/technology approach where a data integration tool is used to merge data columns form various database systems.  This approach has been around for many years.  If it worked, then we would not be in the data disparity mess we are in today. 

The data integration tools and the automation they offer are not the point of failure; the issue is the methodology, how the tools are applied. The tools move and merge the data as directed. It is how they are directed. The decisions on what gets “merged” or “pasted” together are typically based on data field names, content and sometimes relationships within the existing data systems.  Anyone who has worked in the guts of data knows how misleading a column name or even its content is to its meaning. Add to that the fact that most legacy data systems are riddled with data issues and idiosyncrasies.  When they are integrated in this manner, the data abnormalities multiply.

There is also the dimension of time that plays a role in data meaning and integration.  Often data can change its meaning over time as can the business it represents. Even when two data items appear the same, they may be representations of the same thing at different points in time and therefore, not really the same thing. This is a challenge for data systems tool based integration.

Another challenge with this data integration methodology is capturing the data relationships. Data meaning is dependent on it relationships with other data, where the meaning of a data item, a column in a database, is relative to its relationship within the table it resides, as well as its relationship/dependencies to other attributes and tables. When data is looked at individually, as a single column or attribute, void of its relationships, there is a high risk of losing its full meaning, thus compromising its integrity. Many organization’s database systems today, even if they have the capability, do not implement referential integrity (RI) within the database or compensate for the RI.  Much of the data, even well named and defined data has lost its relative meaning. 

Data is not something that can be disassembled and treated linearly, without the risk of compromising its integrity. There is a very good reason why relational logic for data structures works well – data, as is the real world it represents is inter-related. Hierarchies are simple parent-child relationships. This does not necessarily mean data has to be stored or moved in a relational structure; rather its relational or relative meaning must be preserved in some manner in order to maintain its integrity.

Data integration tools can only take a “best guess” in an attempt to derive a data field’s meaning, even if the guess is based on a good quality name, content, and structure/relationships. The real meaning/understanding of data comes from its intended business meaning, how it represents the business.  Without the real business meaning, where the physical data is mapped/justified to a business data model and then used to drive the data integration, it can only ever be a best guess, with or without a tool. 

The Seven Top Data Delusions

By Noreen Kendle

The world of data is full of delusions - false beliefs or ideas about data. These are fueled by the mountains of data related white papers, articles, blogs, and marketing material. If I "google" any data topic, like master data or BI, millions of hits are returned. As I skim through these, nearly all are regurgitations of the last – thus the data delusions continue to grow. It is interesting how much is assumed to be true if we read it in print.

Below are the seven most popular I continue to see:

Data Delusion One

: If the data is there then it must have been deemed good data. There are not secret data police monitoring the data in most organizations. A large percentage of incorrect data lives within the data stores.

Data Delusion Two

: If it looks right then it must be. Typically, data is considered "poor quality" when it obviously looks incorrect or is known to be incorrect. Often data can "look" right, when it is not. How do you know if the answer returned when you ask a question, using a computer system, is correct - you would not need to ask if you knew the correct answer?

Data Delusion Three

: A new tool/technology will fix the data problems. There continues to be a belief that the tools/technology will auto-magically figure out if the data is correct or belongs together. Unfortunately success is always dependant on the quality of what goes in– garbage in, garbage out is still true.

Data Delusion Four

: Data is a computer phenomenon like software or hardware. Many of the definitions support this, but data has existed for longer than before computers were ever imagined. Data is a representation of the real-world organization, its things, people, locations and events. Computers help to automate the processing of data.

Data Delusion Five

: "Cleaning" the data fixes it. There is always a reason data becomes corrupted. It just does not magically happen. Data errors or poor quality data are a symptom of a problem, rarely the problem itself. Fixing a symptom does not fix the problem - it’s like taking an aspirin for a brain tumor.

Data Delusion Six

: The data meaning can be deduced from its name/definition. Even in the rare case when a data store has been diligently modeled from a business standpoint and implemented accordingly, the data system deteriorates over time. Many of the data stores in our organizations have never been designed / modeled in the first place. The data field names and sparse definitions were often the best guess by the programmer at the time. `

Data Delusion Seven

: Data can be managed/integrate/cleaned at an individual attributes/columns level. The data attributes/ columns are intended for description purposes. They are relative to what they are describing, as well as to the relationships/ dependencies of the things they are describing. When data attributes/columns are taken out of this context and treated indiviually, they can lose much of their meaning, and thus integrity.

The Business Intelligence Investment: Context

Blogger: Marcus Collins
In my recent post I detailed the critical success factors for a successful analysis initiative namely:

• Having the right analysis process
• Having access to the right information
• Having the right context
• Having the ability to make decisions at the right time
• Having the right leadership
• Having the right team dynamics
• Having the right people

And finally:

• Choosing the right problem

In this post I’m going to explore the “right context” in more detail. Whilst it is true that “All men are created equal”, the same cannot be said of analysis problems. It is important to determine the context of the problem as this brings with it a set of constraints and implicit assumptions that the analyst must understand and consider as they perform the analysis.The key elements of decision context are the:

• scope
• complexity
• timeliness

Scope – is it an operational decision for example analyzing customer purchases to determine customers with the potential profit; simulate supply chains to reduce overall inventory levels and order-to-delivery times? Or is it strategic in nature for example deciding whether to move into a new market or embark on a strategic acquisition? Strategic and operational decisions have a different set of characteristics:Strategic Decisions

• Long Term
• Historic data
• Internal and External perspective
• Enterprise-wide data focus (information politics)
• Focus on analytics and interpretation/heuristics
• Poor data/information quality medium/high impact on decision
• Long term feedback loop – enterprise’s goals/mission statement

Operational Decisions

• Short Term
• Real-time data
• Internal perspective
• Business unit or function data focus
• Focus on analytics; less focus on interpretation
• Poor data/information quality – high impact on decision
• Short term feedback loop – focus on operational metrics

Complexity – problem can increase in complexity quickly and expand the scope of an analysis that is quantitative and focused on operational data to one that relies on the judgment of the analyst. The key is to be cognizant that the analytics guides the decision making.

Take this sales forecast. The data shows that Q1/Q2 has seen steady growth. A simple “interpretation” might assume that Q3 would also show steady growth. But let’s assume that Q3 shows a marked drop in sales in – will Q4 follow Path A (a return to Q1/Q2 growth) or Path B (a continuation of Q3’s falling sales). To answer this question may require data outside that which is normally available from operational systems. For example, if this was a weather dependent product or service you may need weather data to see if there’s a correlation between sales and temperature. A more complex correlation might be an increase in fuel costs leading to a drop in toll road usage. In both examples the decision required an analysis of the operational data and judgment/intuition on the part of the analyst.The final aspect of context is the Timeliness of the data. I explored this aspect in this blog post – analysis when the business needs it. The traditional view of business intelligence is of operational systems feeding a data warehouse through an Extract, Transform and Load (ETL) data pipeline. Little has changed with this model since it was initially proposed in the 1980’s. Increasingly organizations are realizing that the retrospective view of data this model supports is not sufficient to meet the demands of companies that need to function at internet speed. Rather than following this one speed approach organizations should adopt a tiered approach tailored to the organization’s business requirements, competitive environment and customer demands.

In a document to be published in early June and a series of TeleBriefings on June 2 and 3, Burton Group Senior Analyst Marcus Collins will explore the analysis context and each of the other critical success factors in more detail and provide guidance on how organizations can develop a roadmap for the successful deployment of a fact-based decision making culture.

The Business Intelligence Investment: The Analysis Process

Blogger: Marcus Collins

In my recent post I detailed the critical success factors for a successful analysis initiative namely:

• Having the right analysis process
• Having access to the right information
• Having the right context
• Having the ability to make decisions at the right time
• Having the right leadership
• Having the right team dynamics
• Having the right people

And finally:

• Choosing the right problem

In this post I’m going to explore the “right analysis process” in more detail.

Organizations operate in a high competitive and regulated environment and so efficient and repeatable business processes are integral to an organization’s well being. This applies equally to the analysis process. The analysis process should be tailored to meet the requirements of both the organizational culture and the context of the analysis. For example, a move into or out of a market segment would require a more thorough analysis that a series of experimental what-if scenarios.

The process is shown below:

Frame the problem – requires the analyst to have a clear understanding of the problem with the problem boundaries defined and it decomposed into its constituent parts.

Design the analysis – is the selection of the appropriate technique or framework. For example, to identify the most balanced decision amongst candidates the trade study would be used.

Gather the data – identifying data that is relevant to the problem and determining the source of this information and, importantly, determining what information is not available. Data quality metrics are important as they allow the analyst to evaluating the impact of the quality metrics on the analysis output.

Execute and interpret – two different skills are used here. Execute requires an analytic discipline with a focus on quantitative fact and rule-based logic. Interpretation emphasizes human judgment. Both techniques should be used in this step of the process. The output of this step will either be actionable and the process will move onto the implementation stage or not actionable and the process will move back to the start and refine and/or reframe the original problem statement.

Implement – in context of business intelligence this is the implementation of business change. A key recommendation here is that the analysis is not the act of making decisions; rather it is a single factor in the justification for a decision. The actual decision will be a combination of quantitative information, qualitative information and human judgment.

Measure – the traditional IT view of measurement focuses on efficiency and cost. Within the context of the business intelligence initiative the focus should shift to measuring business value.

Continuous learning – the analysis process is iterative and key to the success of this is culture of continuous learning. Organizations should encourage a culture of learning through both successes and failures.

In a document to be published in early June and a series of TeleBriefings on June 2 and 3, Burton Group Senior Analyst Marcus Collins will explore the analysis process and each of the other critical success factors in more detail and provide guidance on how organizations can develop a roadmap for the successful deployment of a fact-based decision making culture.

The Business Intelligence Investment: Realizing the Benefits

Blogger: Marcus Collins

IBM recently published a report that states that while 75% of organizations recognize the opportunity for analytics only about 15% have a well developed analytic capability. This mirrors the finding of a 2008 report published by Accenture.

The current economic climate and highly competitive nature of today’s business environment requires that the traditional approach of making decision, based solely on intuition and gut instinct, be replaced by one where a rigorous information and fact based analysis process guides the decision making.

Given this landscape, what can organizations do to ensure an effective business intelligence initiative? As we analyzed both the successes and failures of business intelligence projects, a number of critical success factors emerged:

• Having the right analysis process
• Having access to the right information
• Having the right context
• Having the ability to make decisions at the right time
• Having the right leadership
• Having the right team dynamics
• Having the right people

And finally:

• Choosing the right problem

None of these factors involve tool deployment – many organizations have already made the investment in the analysis tools – rather they focus on the softer process and organizational aspects.

The key recommendations are that analysis should follow a clearly defined process with a focus on the reliable delivery of business value; that the analysis initiative should be led by the business, with strong involvement from IT and that organizations should embark on a proof of concept to both refine the internal processes and as a poster child for a wider deployment.

In document to be published in early June and a series of telebriefings on June 2 and 3, Burton Group Senior Analyst Marcus Collins will explore in detail each of these critical success factors and provide guidance on how organizations can develop a roadmap for the successful deployment of a fact-based decision making culture.