Childrens Corner

A common complaint is that BI projects are hard to cost-justify. That can be true if there is no obvious business problem to solve. One of the most difficult aspects in building a business case for a BI application is to show an adequate ROI. Despite the difficulty, you must demonstrate how, by analyzing and mining the information in the BI decision-support environment, the organization can more effectively maneuver and adapt to an increasingly changing marketplace.

Benefits are usually harder to quantify than costs, and it will take many high-valued benefits to offset the costs. A very effective method for justifying the expenditure of a BI application is to tie it directly to a business problem of measurable proportion. For example, let us assume an organization is losing $5 million each year because it cannot curb insurance fraud due to insufficient and unreliable data about its underwriting practices. If the proposed BI application can resolve that specific business problem, it will be relatively easy to justify. Therefore, be as detailed as possible when identifying the benefits, even if it is difficult to quantify a precise ROI. This way you can gain the confidence of business executives and win approval for the BI project.

Note that not all business problems need a BI solution. For example, the types of problems that do not require a BI application because they can be solved in more economical and less complicated ways are:

• Provide easier online access to a flat file

• Archive operational data

• Merge two operational files for operational processing

• Separate the operational reporting function from the operational update function

Sometimes all you need to do to solve an operational problem is to buy a better reporting tool or move the data into a relational database; neither should be interpreted as a need for a BI solution. However, if the business problem hinges on an inability to analyze integrated cross-functional data or to extract from the operational systems hidden intelligence needed to make strategic business decisions, then a BI decision-support initiative is probably the right solution.

The results of the cost-benefit analysis should succinctly state how the BI application would solve a business problem or enable a business opportunity. It should also state what type of information will be available, how that information can be used to make better business decisions, and when and how the information will be presented to the business community (e.g., monthly reports, ad hoc access through online analytical processing [OLAP] tools). Once you have clearly stated the business need and outlined the benefits, the next step is to estimate and compare the detailed costs and benefits so you can produce the projected ROI, which provides the justification for the BI project.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

Merging and standardizing data is usually a requirement of every BI application but one that is not so easy to accomplish. One of the difficulties in merging and standardizing data from different types of data sources is that the data is stored in different file structures on different platforms. What makes the process even more difficult is that the keys for the same objects on different data sources usually do not match, the definitions for the same apparent data are often inconsistent, and the values are often missing or conflicting. In addition, different people in the organization have authority to determine business rules and policies for data from different types of data sources, and resolving data conflicts among them or getting clarification is often all but impossible.

Standardizing data from internal operational data sources is difficult enough, but standardizing data from private and external data sources is a major challenge and could be costly. This cost should be calculated and included in the cost-benefit analysis.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

One of the challenges in building a BI decision-support environment is to merge data from different types of data sources. There are three major types of data sources: operational, private, and external

Operational Data

Online transaction processing (OLTP) and batch systems provide internal operational data about subject areas, such as the following:

• Financial

• Logistics

• Sales

• Order entry

• Personnel

• Billing

• Research and engineering

Private Data

This internal departmental data usually comes from the desktops and workstations of business analysts, knowledge workers, statisticians, and managers. Examples include the following:

• Product analysis spreadsheets

• Regional product usage spreadsheets

• Prospective customer databases

External Data

Organizations often purchase external data from vendors that specialize in collecting industry-specific information available in the public domain, such as the following:

• Health care statistics

• Customer profile information

• Customer catalog-ordering habits

• Customer credit reports

External data is usually clustered around the following categories:

• Sales and marketing data: lists of prospective customers

• Credit data: individual credit ratings, business viability assessments

• Competitive data: products, services, prices, sales promotions, mergers, takeovers

• Industry data: technology trends, marketing trends, management science, trade information

• Economic data: currency fluctuations, political indicators, interest rate movements, stock and bond prices

• Econometric data: income groups, consumer behavior

• Demographic data: age profiles, population density

• Commodity data: raw material prices

• Psychometric data: consumer profiling

• Meteorological data: weather conditions, rainfall, temperature (especially for agricultural and travel industries)

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

In most organizations, business analysis issues usually revolve around unmet information needs from current heterogeneous data sources and poor quality of the source data.

Information Needs

With the help of business analysts, formulate the business issues that need to be resolved by each BI application objective. Determine what results you want to obtain from the business analysis, for example, answers to such questions as, “Why are we losing 50 percent market share to ABC Company in New England?” Then define the information requirements for the business issues at hand. Determine the subject areas, timing, level of detail, granularity of data, and even what external data you need to answer the business questions. Identify the associated business roles (e.g., senior business management, business analyst, and so on) that would be active in the various decision-support functions.

Identify possible data sources where the required information could reside. Data sources can be internal as well as external, and business insights often lie buried in the relationships among the multiple data sources.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

Without strong business drivers and without an alignment with the strategic business goals of the organization, the BI decision-support initiative may falter. For example, let us assume that the organization wants to increase revenue by decreasing time to market. This translates into building BI applications as fast as possible, no matter what other effects this might have (for example, as speed goes up, quality goes down). Further, let us assume that the BI application objective is to decrease operating costs by increasing productivity. This leads to building BI applications that deliver business process improvements no matter what it takes (for example, as quality goes up, speed goes down). In this example, the organization’s strategic goal and the BI application objective are both worthy business drivers for building a BI solution. However, because the strategic goal and the BI application objective are not compatible in terms of speed and quality issues, it will be difficult to get management’s support for this BI application.

This example illustrates the importance of understanding the organization’s strategic business goals as well as the IT strategic plan and ensuring that the BI application objectives support both. This may be more difficult to do than it appears. Even some of the most sophisticated organizations often do not have easily accessible or well-articulated strategic business goals statements. Become a “detective” and review the organization’s annual report, public statements, newspaper coverage, syndicated articles, and internal memos for valuable information.

Substantiate your business justification. Do not invent a business case where one does not exist just to get the BI project approved. Interview senior managers to confirm the organization’s strategic goals, and interview business managers and business analysts to validate the BI application objectives.

Let us discuss an example of a valid business justification. An automobile manufacturer was rated near the bottom of a study on customer satisfaction and product quality. This hurt the manufacturer in two ways.

1. The warranty costs were much higher than those of an average automobile manufacturer. These measurable costs were directly impacting the organization’s bottom line.

2. Unsatisfied customers spread the word about the manufacturer: “I’ll never buy another car from that company—and I’ll tell all my friends.” The costs of damaged customer confidence and lost sales were immense but much more difficult to measure than the costs of warranty.

In this example, the strategic business goals were to retain the customers and to reduce the expenses on warranty costs. In order to achieve these two goals the automobile manufacturer had to be able to communicate the information about malfunctioning parts to the parts makers on a timely basis. If a parts maker did not improve the quality of a part, the automobile manufacturer would have to buy that part from a different parts maker. The automobile manufacturer also needed information about the customers who were returning the malfunctioning cars in order to contact them for “damage control.”

This automobile manufacturer justified building a BI application to measure manufacturing quality and to relate the quality measures to loss of sales, customer complaints, and customer defection. Quality measures were to be captured at the time of assembly as well as from the warranty data. Since a major portion of overall product quality is based on the quality of the parts that go into the automobile, the quality measures were to be provided to the parts makers through secure Web access. By giving the parts makers this information, the automobile manufacturer believed the parts makers would be able to improve the quality of their parts, which, in turn, would improve the overall quality of the assembled automobile. In this case, the BI application objectives directly supported the strategic business goals.

Business justification is an iterative process. As difficult as it might be to justify the business case, realize that business managers are aware of the buzz about BI and would like to take advantage of any competitive benefit they can get. Reiterating the benefits will help crystallize the business justification and make everyone feel comfortable about funding the BI decision-support project.

Once the strategic business goals and BI application objectives are verified and matched, you can define the business analysis requirements for the BI application that will allow the organization to meet its strategic business goals.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

Since it usually costs millions of dollars to create a BI environment, an organization considering such an initiative needs a BI strategy and a business justification to show the balance between the costs involved and the benefits gained. A BI decision-support initiative provides numerous benefits—not only tangible benefits such as increasing the sales volume but also intangible benefits such as enhancing the organization’s reputation. Many of these benefits, especially the intangible ones, are difficult to quantify in terms of monetary value. Nevertheless, you should prepare an itemized and detailed list of benefits in order to measure them against the high cost of a BI implementation. Although the general benefits of BI decision-support initiatives are documented widely, they cannot justify your BI initiative unless you can associate these benefits to your organization’s specific business problems and strategic business goals.

Justification for a BI decision-support initiative must always be business-driven and not technology-driven. It would not be wise to set up an expensive BI decision-support environment only to experiment with new technology. Therefore, each proposed BI application must reduce measurable “business pain” (problems affecting the profitability or efficiency of an organization) in order to justify building the application.

It is best to start the business justification process by identifying the organization’s strategic business goals. The BI decision-support initiative as a whole, and the proposed BI application specifically, should support those strategic business goals. This enables the ongoing viability of the BI decision-support environment. If BI applications are built without a good business justification, management will most likely not support the effort.

The business representative should be primarily responsible for determining the business value of the proposed BI application. The information technology (IT) department can become a solution partner with the business representative and can help explore the business problems and define the potential benefits of the BI application. IT can also help clarify and coordinate the different needs of the varied groups of business people (knowledge workers, business analysts, business executives). For example, there could be different requirements for:

• Ease of use

• Level of data granularity

• Timeliness

• Data quality

• Security

• Amount of external data

• Historical requirements

• Tool capabilities

• Business drivers: Identify the business drivers, strategic business goals, and BI application objectives. Ensure that the BI application objectives support the strategic business goals.

• Business analysis issues: Define the business analysis issues and the information needed to meet the strategic business goals by stating the high-level information requirements for the business.

• Cost-benefit analysis: Estimate costs for building and maintaining a successful BI decision-support environment. Determine the ROI by assigning monetary value to the tangible benefits and highlighting the positive impact the intangible benefits will have on the organization.

• Risk assessment: Assess the risks in terms of technology, complexity, integration, organization, project team, and financial investment.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

It has been said in the industry that “a paper airplane can be constructed with little forethought, but a jet airplane cannot.” Similarly, a stand-alone system that has only a handful of business people using it can get by without a set of carefully planned and executed project activities, but a cross-organizational BI initiative certainly cannot.

As the BI decision-support environment evolves over time, it is imperative that a strong foundation exists to support such expansion. To build a strong foundation, many things have to be considered and many tasks have to be performed by many people. It is irresponsible to casually “make up” who does what and when along the way. That type of ad hoc development approach would put the organization’s large investment at risk and would pose an even bigger risk for losing business opportunities. There are quite a few casualties in the trenches of lost opportunities!

The question is not whether or not a set of formalized guidelines must be used but what type of guidelines to use. A waterfall methodology is not suitable for the iterative releases of BI decision-support applications, but an agile and adaptive development guide specifically geared toward BI decision-support applications is. Business Intelligence Roadmap is such a guide.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

The discussion on roles and responsibilities cannot end without mention of the BI arbitration board. On cross-organizational BI projects, technical as well as business disputes will arise that neither the core team nor the extended team will be able to resolve. A dispute resolution procedure should be established with guidelines for handling these types of disputes. If a resolution cannot be achieved through other prescribed means, the project team must have access to a body of executives with the authority to be the tiebreaker. This body of executives is the BI arbitration board, sometimes known as the BI steering committee.

BI arbitration boards can be organized in a variety of ways. A BI arbitration board can be a newly created group whose members include the business sponsor, the chief technology/information officer (CTO/CIO), IT managers, the chief operating officer (COO), the chief financial officer (CFO), and line-of-business managers. In some smaller organizations, even the chief executive officer (CEO) could be a member of this board.

In other organizations, the BI arbitration board can be an existing committee. Most organizations already have some official or unofficial executive committee. For example, the CTO/CIO typically meets monthly with the employees who report directly to him or her, and the CEO typically meets monthly with line-of-business executives, the CFO, and the COO. If a separate BI arbitration board cannot be established, then the BI project teams must have access to the existing executive committees.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

Every BI project team must have a complementary skill set to perform the necessary activities for the three development tracks. Although each track will have its own subproject team members, from the overall BI project management perspective the BI project team structure contains only two types of teams:

1. The core team

2. The extended team

The Core Team

The core team can be thought of as a SWAT team. A project SWAT team is a self-organizing team—the members redistribute the workload among themselves, peer-review each other’s task deliverables, make decisions together, brainstorm together, and co-lead the project. The core team has permanent project core team members and permanent step core team members.

• Permanent project core team members must be available 100 percent of their time from beginning to end of the BI project to perform project activities applicable to the roles assigned to them. More importantly, they must co-lead the project. The optimum size for this team is four or five people, never exceeding seven people. This team should be staffed with:

  - One project manager (not an administrator)

  - One representative from the business side

  - One business analyst from the information technology (IT) department (either a data administrator or a business liaison)

  - One technical person from the IT department (either a senior systems analyst or a senior programmer)

• Permanent step core team members must be available 100 percent of their time from beginning to end of those development steps that require their full-time involvement. For example, the ETL lead developer must be fully dedicated to lead the activities of the ETL track.

All core team members brainstorm together, assign work to each other, review each other’s deliverables, resolve issues, and make project-related decisions together.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications

BI projects are organized according to the same six stages common to every engineering project. Within each engineering stage, certain steps are carried out to see the engineering project through to its completion. Business Intelligence Roadmap describes 16 development steps within these stages, as outlined below.

The Justification Stage

Step 1: Business Case Assessment

The business problem or business opportunity is defined and a BI solution is proposed. Each BI application release should be cost-justified and should clearly define the benefits of either solving a business problem or taking advantage of a business opportunity.

The Planning Stage

Step 2: Enterprise Infrastructure Evaluation

Since BI applications are cross-organizational initiatives, an enterprise infrastructure must be created to support them. Some infrastructure components may already be in place before the first BI project is launched. Other infrastructure components may have to be developed over time as part of the BI projects. An enterprise infrastructure has two components:

1. Technical infrastructure, which includes hardware, software, middleware, database management systems, operating systems, network components, meta data repositories, utilities, and so on.

2. Nontechnical infrastructure, which includes meta data standards, data-naming standards, the enterprise logical data model (evolving), methodologies, guidelines, testing procedures, change-control processes, procedures for issues management and dispute resolution, and so on.

Step 3: Project Planning

BI decision-support projects are extremely dynamic. Changes to scope, staff, budget, technology, business representatives, and sponsors can severely impact the success of a project. Therefore, project planning must be detailed, and actual progress must be closely watched and reported.

The Business Analysis Stage

Step 4: Project Requirements Definition

Managing project scope is one of the most difficult tasks on BI decision-support projects. The desire to have everything instantly is difficult to curtail, but curtailing that desire is one of the most important aspects of negotiating the requirements for each deliverable. Project teams should expect these requirements to change throughout the development cycle as the business people learn more about the possibilities and the limitations of BI technology during the project.

Step 5: Data Analysis

The biggest challenge to all BI decision-support projects is the quality of the source data. Bad habits developed over decades are difficult to break, and the damages resulting from bad habits are very expensive, time consuming, and tedious to find and correct. In addition, data analysis in the past was confined to the view of one line of business and was never consolidated or reconciled with other views in the organization. This step takes a significant percentage of the time allotted to the entire project schedule.

Step 6: Application Prototyping

Analysis of the functional deliverables, which used to be called system analysis, is best done through prototyping so it can be combined with application design. New tools and programming languages enable developers to relatively quickly prove or disprove a concept or an idea. Prototyping also allows business people to see the potential and the limits of the technology, which gives them an opportunity to adjust their project requirements and their expectations.

Step 7: Meta Data Repository Analysis

Having more tools means having more technical meta data in addition to the business meta data, which is usually captured in a computer-aided software engineering (CASE) modeling tool. The technical meta data needs to be mapped to the business meta data, and all meta data must be stored in a meta data repository. Meta data repositories can be licensed (bought) or built. In either case, the requirements for what type of meta data to capture and store should be documented in a logical meta model. When licensing a meta data repository product, the requirements documented on this logical meta model should be compared to the vendor’s meta model, if one is provided. In addition, the requirements for delivering meta data to the business community have to be analyzed (e.g., online help function).

The Design Stage

Step 8: Database Design

One or more BI target databases will store the business data in detailed or aggregated form, depending on the reporting requirements of the business community. Not all reporting requirements are strategic, and not all of them are multidimensional. The database design schemas must match the information access requirements of the business community.

Step 9: Extract/Transform/Load Design

The ETL process is the most complicated process of the entire BI decision-support project. It is also the least glamorous one. ETL processing windows (batch windows) are typically small, yet the poor quality of the source data usually requires a lot of time to run the transformation and cleansing programs. Finishing the ETL process within the available batch window is a challenge for most organizations.

Step 10: Meta Data Repository Design

If a meta data repository is licensed, it will most likely have to be enhanced with features that were documented on the logical meta model but are not provided by the product. If a meta data repository is being built, the decision must be made whether the meta data repository database design will be entity-relationship based or object oriented. In either case, the design has to meet the requirements of the logical meta model.

The Construction Stage

Step 11: Extract/Transform/Load Development

Many tools are available for the ETL process, some sophisticated and some simple. Depending on the requirements for data cleansing and data transformation developed during Step 5, Data Analysis, and Step 9, ETL Design, an ETL tool may or may not be the best solution. In either case, preprocessing the data and writing extensions to supplement the capabilities of the ETL tool is frequently required.

Step 12: Application Development

Once the prototyping effort has firmed up the functional requirements, true development of the access and analysis application can begin. Developing the application can be a simple matter of finalizing an operational prototype, or it can be a more involved development effort using different, more robust access and analysis tools. In either case, the front-end application development activities are usually performed in parallel with the activities of back-end ETL development and meta data repository development.

Step 13: Data Mining

Many organizations do not use their BI decision-support environment to the fullest extent. BI applications are often limited to prewritten reports, some of which are not even new types of reports but replacements of old reports. The real payback comes from the information hidden in the organization’s data, which can be discovered only with data mining tools.

Step 14: Meta Data Repository Development

If the decision is made to build a meta data repository rather than to license one, a separate team is usually charged with the development process. This becomes a sizable subproject in the overall BI project.

The Deployment Stage

Step 15: Implementation

Once the team has thoroughly tested all components of the BI application, the team rolls out the databases and applications. Training is scheduled for the business staff and other stakeholders who will be using the BI application and the meta data repository. The support functions begin, which includes operating the help desk, maintaining the BI target databases, scheduling and running ETL batch jobs, monitoring performance, and tuning databases.

Step 16: Release Evaluation

With an application release concept, it is very important to benefit from lessons learned from the previous projects. Any missed deadlines, cost overruns, disputes, and dispute resolutions should be examined, and process adjustments should be made before the next release begins. Any tools, techniques, guidelines, and processes that were not helpful should be reevaluated and adjusted, possibly even discarded.

taken from; Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications