Business intelligence basics

Business intelligence is defined as,

The process of gathering information about a business or industry matter; a broad range of applications and technologies for gathering, storing, analyzing, and providing access to data to help make business decisions.

While I am not an expert in this field I do have a fundamental understanding of the key concepts. The picture below shows a high level view of a simple business intelligence configuration.There are:

1. Source systems which gather the information that will be analyzed.
2. Information from the source systems are stored in their native databases or other data sources. Typically the database are configured for speed of processing. This is good for processing transactions quickly but bad for analyzing them.
3. Information from the data sources goes through a process known as ETL where the data is extracted from the source system, transformed (to meet business needs) and loaded into a data warehouse. Many different data sources can be consolidated.
   
4. Information from the data warehouse is made available to end-users in the form of data marts where the data is organized to answer specific types of business questions (e.g., sales data can be cross referenced by product, region, time, sales representative, etc...)
5. Finally, reporting and analytic tools are used to analyze the information in the data marts. This genre of reporting tools are known collectively as on-line analytical processing (OLAP for short.) There are a few different variations of OLAP tools: MOLAP or multi-dimensional OLAP and relational OLAP or ROLAP. Each has its advantages and disadvantages. For more information on OLAP I suggest going to the OLAP report.
   

Considerations

• Do you need real-time reporting? Is it important to understand what is going on right now? By nature, most business intelligence configurations update their information at a frequency insufficient for real-time reporting.
• Are there standard reporting needs or are reporting needs of a more ad-hoc nature? The answer to this question my mean that one of MOLAP or ROLAP may be more relevant.
  

Webinar: Requirements-driven testing

There's a webinar offered by Compuware called, Requirements-driven testing—The journey from business needs to test and user acceptance. The event will occur on February 6, 2007 @2:00 pm EST (11:00 am PST.) Here's a brief description of the event.

IDC’s research indicates that 70-80 percent of IT project failures result directly from poor requirements gathering, management and analysis. With a requirements-driven testing approach, you can improve the quality of your requirements, involve QA earlier in the life cycle and maximize the ability of your projects to deliver on all of their objectives.

Decisions and consequences

Early last year I wrote a post called, Thoughts on decision-making, where I outlined some decision-making techniques and myths. One item I would like to add to that topic is to understand the consequences and ramifications of the decisions you make.
Let's step back and examine this from a business context. Suppose we are working on a project and one of the requirements is simply, "to be able to process transactions from external sources." The design team proposes two solutions:

• Processing batch files
• Processing individual transactions (real-time)
  

Based on cost estimates, the batch file solution seems more appealing. One should consider whether, in the foreseeable future, real-time processing is desirable and whether the benefits of that approach will outweigh the increase in costs. It may turn out that the batch file design still wins out but the ramifications of the decision are fully understood and can be communicated.

You may think the consequences of a decision will be minor and short-lived, but they may become temporary like income taxes.

Ode to preparation

There's a short but interesting post on Mark Cuban's blog, Blogmaverick. He paraphrases former Indiana Hoosiers coach, Bobby Knight, "Everyone has got the will to win, it's only those with the will to prepare, that do win."
When you are working on business requirements, presentations or anything at all, good preparation will improve your performance. Words to live by.

Tips for end-user acceptance

Any solution, no matter how well it has been conceived will not be successful unless it is embraced by its intended end-users. Here are some quick tips to help promote acceptance (though I don't guarantee it.)

1. Understand how end-users work: Find out why they do the things they do. If you show an interest in them, they will be more comfortable with what you're trying to accomplish.
2. Provide opportunities for feedback: This is particularly important when there are user interfaces involved. At regular intervals, let people see the development and direction and be willing to listen to suggestions and feedback.
   
3. Manage change: If something has to change let your customer understand the rationale. "Because it has too..." is not a useful response. If the change is meant to make things better explain how.
   
4. Make it seem familiar: People by nature are resistant to change. Perhaps there is opportunity to gradually phase in changes (smaller changes are easier to digest) or provide an interface that is similar to an existing one.
   
5. Enlist champions: End-users that can teach other end-users are a great way to provide support. It also gives the champions a sense of ownership for the adoption. Early adopters are good individuals to use as champions.
   
6. Teach don't point: When someone asks for help one of the worst things you can do is point them to a manual. Spend time to teach them how it works. Show them they're important.
   
7. Measure & report: If the new solution is meant to improve productivity, show them the gains that have been made over time as the end-users become more familiar and move up the adoption curve. This type of information shouldn't just be provided to the project sponsors and management.
   

Projects are usually justified quantitatively based on achieving benefit targets (e.g., gains in efficiency or increases in sales.) Maximum benefits will not be achieved if the end-users do not embrace the solution wholeheartedly.

Why we do things - ROI

Long ago, one of my professor's told me, "The purpose of education is to increase pleasure enjoyment." I've yet to fully grasp exactly what he meant (he was a professor of philosophy and often spoke in riddle), but I think it was something along the lines of, "Knowledge allows us to improve our station in life." It may take the form of allowing us to obtain better jobs, improve our ability to appreciate things or allow us to take better advantage of the opportunities presented to us.

Let's examine a familiar concept - investing. Whether it is because we want to be able to make a large purchase (a house or car), enjoy a comfortable retirement, or live out some of our dreams, most of us are putting money aside. This money is invested based on our individual risk / reward preferences. If you lie awake at night worrying about your investments, you may be outside of your risk / reward sweet spot.
Individuals who want to be safe, invest in financial instruments such as money market mutual funds, treasury bills or other assets where the risk of losing the investment is small (note that small risk generally implies small potential return.) Individuals with a higher risk tolerance purchase financial assets with higher potential returns.

The prudent investor analyzes their assets periodically to ensure a suitable return on investment (ROI) is being realized. There is a good guide on ROI available on SearchCIO.com explaining basic ROI concepts from a business perspective.

I want to introduce another concept - opportunity cost. Opportunity cost is defined as:

The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.

In business, all else being equal, you fund projects that have better rates of return for your company. Businesses use capital from their shareholders and money they've borrowed to fund their projects. Furthermore, a company is expected to invest in projects with ROI that exceeds their opportunity costs (e.g., projects that make them grow!) From the perspective of an individual investor you probably wouldn't be willing to purchase shares in a company that wasn't trying to increase its future earnings. Would you?

Thus, in business the ultimate goal is to increase profitability. A business does this by undertaking projects that are expected to yield a return above their opportunity cost. These projects have specific goals and objectives that support the business' strategy. This is why it is important to tie requirements back to business goals and objectives. As well as business goals and objectives back to strategy.In business and in our personal life, we do things to improve, to grow, and as my old philosophy professor would say, "...To increase pleasure enjoyment."

Webinars: PPM & ITIL

Here are some webinars that may be of interest. Note that you may need to sign-up to get access to them.

Project Portfolio Management for the Skeptical IT Organization
You want to run IT like a business; you know Project Portfolio Management (PPM) can get you there, but you are worried about long implementations, high price tags, and consultants taking residence in your shop. In this webcast you'll learn how a web-based model with the right level of functionality has helped organizations like yours get a PPM solution up and running in two weeks and producing value right away.

Part I: Introduction to ITIL for the IT Executive - Podcast - Expert Podcast
Based on a practical approach to addressing real-world challenges of IT service management, ITIL allows organizations to better package and deliver IT services to their customers. ITIL enables IT organizations to align their capabilities with business requirements.

Leadership styles

I remember taking a course developed by the Leadership Research Institute on leadership styles. The purpose of the course was to help identify the most appropriate way to interact with an employee given an understanding of an individual's:

1. Ability to perform a task.
2. Motivation level to perform a task.
   

Using these two factors to create a simple matrix you get a picture similar to the one below. For each quadrant a different approach is warranted for handling an employee.

1. High ability to perform the job but low motivation to do it. Convince the employee to persevere and outline the task's importance.
   
2. High ability to perform the job and motivated. Allow the employee to perform the task unhindered. There is no need to provide direct support or exert control.
   
3. Not able to perform the job and not motivated either. Basically you need to tell the employee exactly what to do to complete the task and monitor his (or her) progress.
   
4. Not able to perform the job but motivated to try. Provide support, feedback and guidance to help the employee complete the task.

These guidelines assume that you are able to determine the competence and motivation level of an individual.

Intuitively, this framework makes sense. When you understand how to perform a job well and are highly motivated to do it, you don't really appreciate someone looking over your shoulder, telling you what to do and asking for constant status updates.

The purpose of the course was to improve managing employees, however, I feel that these fairly simple guidelines can be used in any situation where you need a task performed by someone other than yourself.

Tips for Business Intelligence

There was a short set of slides posted on BaselineMag.com outlining 6 Tips for Business Intelligence Success. Make sure you check it out. The tips are:

1. Understand your enterprise
2. Involve key users
3. Make sure components of a BI system work together
4. Be mindful that different employee groups will want different interfaces
5. Consider making applications broadly available
6. Create a competency center

Some of these tips are applicable to normal business analyst engagements as well.

Knowing when it's good enough

A business uses cost-benefit analysis as one of its evaluation criteria when deciding whether to pursue an opportunity or not. One concept central to this is the assessment of potential risks. To me there are a few components to risk assessment:

1. Likelihood of the risk materializing. What's the probability of the risk becoming a problem?
2. Potential cost (monetary, compliance or reputation) to mitigate the risk. How much is it going to cost you? This also includes implementing any mitigation strategies.
   

Combined, these factors provide a value to each risk. Risk assessment can be applied in many different areas:

• Managing the risks encountered in a project.
• Understanding the importance of a defect or bug in a system.
• Managing financial assets.
  

For the purposes of this post I'm only going to write about the second item.

What do you do if you find a defect or bug in a system? You evaluate it to determine whether it's a show stopper or whether you can proceed despite it. Creating bug-free software is the ultimate goal but it has cost and time implications. Here's a quote from an article, They Write The Right Stuff, from Fast Company about a specific software system.

This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.

The piece of software in question runs the NASA space shuttle. The consequences of failure could result in the deaths of the astronauts, the loss of a multi-billion dollar piece of hardware and many years of setbacks to the space program. Many of the systems we deal with in the business world do not have this level of criticality. In my past jobs I have worked with time sensitive trading systems where 1/2 second delays mean losses in the $10,000's of dollars. On other projects, variances in marketing and market research data were explainable ("Yes, someone did purchase 50 rolls of toilet paper and it skewed the numbers.") We need to understand when something is good enough as it is instead of always trying to be perfect.