BusinessObjects XI (Release 2): The Complete Reference

Introduction

Early in this project, the publisher and I thought this book would be based on BusinessObjects XI Release 1. When the vendor accelerated the timeline for XI Release 2, we decided to rewrite the book for this version, initially using a beta version of the software and then revising against the production version of XI Release 2.

Software Modules Covered   Business Objects’ product line is ever expanding, and herein lies a dilemma with the publishing industry: The Complete Reference brand does not imply the complete XI product line. Although I would have been glad if this book were published under a different title (lest you think it covers every module within XI), the reality is that you then would not be able to find the book via major booksellers. To manage expectations, please be aware that the following modules are not covered in-depth in this book: building reports with Crystal Reports (there are numerous other books that cover this topic), Data Integrator, Dashboard Manager, Performance Manager, Planning, and Live Office. As many of you have made excellent suggestions to cover some of these modules, lack of coverage simply became a matter of scope and time.

Sample Data   For the first edition of this book, I tried to make your learning experience more exciting by using BusinessObjects 5i to provide interesting insights about wine prices and ratings (New Zealand Sauvignon Blancs are your best buy!). Because there were so many changes in the product with XI Release 2, I have relied mainly on the familiar, vendor-supplied eFashion and Island Resorts Marketing universes for the current edition of this book. Both use Microsoft Access databases and are part of the standard installation routine. The eFashion universe is based on fictional data from a retail-clothing store. It contains three years of sales and promotion costs for 211 fashion products and 13 stores. The Island Resorts Marketing universe contains reservation and sales information by customer and resort. When I wanted to demonstrate specific Oracle RDBMS or Microsoft SQL Server capabilities, I used sample data installed as part of these RDBMS. For Oracle, I used 9i and predominantly the Sales History (SH) tables. For SQL Server, I used SQL Server 2000 and the Northwind Products database.

What’s Inside

Part I, Getting Ready for BusinessObjects XI, introduces Business Objects (the company), the history of business intelligence, and key aspects of the product line. Project managers in particular will find Part I useful in understanding the people and communication issues that affect a business intelligence implementation. With the myriad product choices and deployment approaches, Part I will help you stay focused on the users and business values of your implementation. For existing customers, Chapter 5 is an essential read in understanding changes in the architecture and planning your migration.

Part II, A Better Universe, covers universe design, maintenance, and securing content through the Central Management Console. As you deploy BusinessObjects XI across the enterprise, there are choices about where to build the intelligence in relational tables, OLAP databases, the universe, and the reports. As well, the larger your company’s deployment, the greater the need for test and production environments, a quality assurance process, and usage monitoring. Part II explains the tools to do this. Even if you are an end-user, you will want to skim Part II to better drive your business requirements into the universe design.

Part III, Reporting and Analysis, covers the end-user tools: InfoView portal, Web Intelligence in depth, and advanced features of Desktop Intelligence. Part III is when you finally get the return on your business intelligence investment as users explore and analyze data in ways never before possible. Part III covers the basics of accessing standard reports and exploring the data, as well as the advanced techniques of creating queries, formatting documents, defining powerful report formulas, and leveraging advanced features.

Conventions

This book uses the following conventions:

PART I

Getting Ready for BusinessObjects XI

CHAPTER 1

Introduction to Business Intelligence

CHAPTER 2

Goals of Deploying BusinessObjects XI

CHAPTER 3

Understanding Your Users

CHAPTER 4

Marketing BusinessObjects XI

CHAPTER 5

Under the Covers: Migrating to a New Architecture

CHAPTER

1

Introduction to Business Intelligence

Study the past if you would divine the future—Confucius

Business intelligence is a way of exploring data to improve business performance, whether to drive profitability or to manage costs. It is not a technology you implement and then put in maintenance mode; it is an approach that evolves, morphs, and starts over again as the business climate changes, the users discover new opportunities to leverage information, and technology changes. When you implement business intelligence tools, the focus of the project is not to finish, but rather to deliver a certain amount of value and functionality within a predefined period. Never has this been more true than now with BusinessObjects XI, as a broader set of functionality, serving diverse user needs, has been brought onto a common platform. As you implement XI, you will need to prioritize which applications and interfaces you will leverage most. Will your project be bottom up: sort out the infrastructure to lower BI costs? Or top down: deliver scorecards to align and measure business performance?

Much of your implementation approach will depend upon where you are on the business intelligence lifecycle and whether or not you are completely new to BusinessObjects XI, a long-time Business Objects customer, or a long-time Crystal customer. The purpose of this chapter is to provide some insight as to how business intelligence evolved and is still evolving, so that you can assess where your company is in the BI lifecycle, where your users are today, and where they are heading. You’ll see how Business Objects, the company and the product, have evolved with their customers and the industry, bringing the dream of business intelligence to more users and beyond traditional corporate boundaries. In many cases, Business Object’s innovations have shaped and redefined the market.

The Background of Business Intelligence

The need to access information is not new. After all, people have always needed data to make informed decisions, although a number of errors in decision-making processes are still prevalent, including gut feel. As a type of technology, though, business intelligence is relatively young and emerged as a distinct market in the early 1990s. Pre–business intelligence, it was expensive and time-consuming to get access to the right data. If you are just starting out on the journey of business intelligence, you may find it hard to believe there was a time when information access was more painful than it is today. There are signs that BI has not quite delivered everything we hoped it would. For example, according to a TDWI survey, less than 20 percent of company employees use a BI tool on a regular basis. As BI technology evolves, and with a number of innovations in BusinessObjects XI, I expect this BI penetration to improve dramatically in the next few years. Customers are equally optimistic, expecting the percentage of active BI users to increase to 40 percent in the next three years.

Prior to business intelligence, decision-makers predominantly relied on the following sources of information:

•  Printed reports, generated on a periodic basis by mainframe-based systems. If a critical measure were missing from the printed report, you had to wait months for IT to create a custom report.

•  Manually populated spreadsheets, which provided a bit more flexibility than printed reports. Unlike today, when users may export data from a report, or better yet, use BusinessObjects Live Office to dynamically import data into a spreadsheet, in the late 1980s, field personnel would call in their sales figures to an analyst, who would manually enter data into a spreadsheet. This allowed for some form of analysis on monthly data at best. With manual data entry, there was enormous room for human error and a higher degree of data discrepancies, as rarely did the manually populated spreadsheet match the source system.

•  Gut feel still provided the best form of decision-making, as managers were close to the markets and the customers, and markets did not change at the pace they do today. If a manager had access to quantitative numbers, there was a high degree of distrust of the numbers, and rightly so. After all, the data was stale and the manual collection processes fallible.

CAUTION   As you deploy BusinessObjects XI, never underestimate the role and hold these legacy reporting systems continue to have over users. If you make BusinessObjects XI appear any more difficult than legacy reporting systems, your project risks failure. You are trying to change in a matter of months decision-making processes that have existed for decades.

Custom-developed decision support systems (DSSs) and executive information systems (EISs) attempted to overcome some of the limitations of these original information sources. Decision support systems took the data from mainframe-based transaction systems and presented the results to users in a parameterized form. Users would enter a couple of parameters, such as time period, customer, country, and product. The DSS then displayed results in a tabular format. The beauty of this was that it was easy to use, significantly more so than wading through pages of paper-based reports. If you wanted to graph something, however, you had to re-key the data into a spreadsheet.

If you wanted to view a different data subject, this was generally not possible. Decision support systems generally provided insight into only one subject of data at a time. Each function generally had its own custom transaction system (see Figure 1-1), making it almost impossible to share information across functions. When a customer placed an order, the order entry system maintained its own customer codes. To generate an invoice, the accounts receivable department would have to reenter the order into its own accounting system, which most likely used a different set of customer codes. If you wanted to combine actual sales data (accounts receivable) with shipment dates (orders), it was generally not possible.

FIGURE 1-1   Each function had its own custom-built transaction system and corresponding DSS.

Early decision support systems with their proprietary nature gave way to executive information systems (EISs) in the late 1980s. Executive information systems were expensive to implement but provided graphical dashboards based on a broader set of information, sometimes with feeds from external data sources. At the time, products such as Lightship by Pilot Software, Inc., Forest and Trees by Platinum Technology, and Commander Decision by Comshare, Incs, were breakthrough applications and in high demand.

The fundamental problem with EIS systems was that E stood for executive. Companies soon realized that not only executives but all decision-makers needed access to information. Some savvy marketing companies later would tout their products as everyone’s information system. However, until organizations fixed the back-end data, the stale, silo-based information could not be actionable, regardless of how pretty it looked in a dashboard or a briefing book. At the time, data warehousing was not a generally accepted technology, so moving beyond silo-based information systems was mission impossible. What surprises me is that even today, the most often cited barrier to a successful enterprise BI deployment is lack of an integrated data architecture. Fail to address the back-end systems, and your BusinessObjects XI implementation will fail.

Potentially, the latest approaches to dashboards (and other innovations) make the concept of everyone’s information system a greater reality. I find Business Objects’ recent advertising campaign both appropriate and amusing, since it highlights some of the historical mistakes in the BI industry. One ad shows a warehouse employee with a tag line Meet the CEO of shocks and spokes. The ad emphasizes that BI belongs in the hands of every employee in an organization, not just in the hands of a few executives.

Business Intelligence Is Born

In the early 1990s, a number of business and technological factors merged to drive and enable the creation of a new breed of tools, business intelligence, as shown in Figure 1-2.

FIGURE 1-2   The business intelligence explosion

Several factors drove the need for more information, faster. With the fall of the Berlin wall, the signing of NAFTA, the endless possibility of emerging markets, and economic prosperity, growth and globalization were the mantra for many organizations. However, to operate a global company, companies need access to global or multiregional data. The function- and region-based DSSs could no longer satisfy users’ needs. Silo-based EISs broke. At the same time, PCs were becoming common office tools. Users were increasingly analyzing data via spreadsheets or PC-based graphics programs. With this limited data analysis, users put pressure on IT to deliver more robust reports. IT could not keep pace with the demand. Personal computing both drove business intelligence and enabled client/server computing.

A number of technological advances became enablers for business intelligence. First, large corporations began implementing enterprise resource planning (ERP) systems, such as SAP, PeopleSoft, and Oracle Financials. With these implementations, companies hoped to: (1) reduce the number and complexity of custom transaction systems, (2) meet the business demands for growth and globalization, and (3) derive the productivity and cost benefits of business process reengineering. With ERP systems (Figure 1-3), companies implement modules that share common business data. Each module includes rules that ensure a company is following its intended business processes. For example, in generating a customer order, the shipment is not scheduled until a price has been agreed upon and inventory is available. Modules share information with one another. The same customer information used to process the order is used to invoice the customer. When a customer places the order and the product is shipped, this information is integrated with the accounts receivable module to generate an invoice. With the proprietary transaction systems shown in Figure 1-1, data was double-entered, and customer IDs were specific to each system. With an integrated ERP system, an accountant no longer re-keys the information into a separate system; all reference data is shared across the multiple modules. (See Figure 1-3.) If the productivity and business process reengineering savings were not enough to incite a company to replace their legacy systems with an ERP, then the threats of year 2000 issues were.

FIGURE 1-3   ERP systems ensure data integration and adherence to standard processes.

Initially, ERP vendors promised they would provide insight into a company’s business. It was a false promise. ERP systems provide the infrastructure that makes the insight possible, but the insight comes only when business intelligence tools and a data architecture are implemented in conjunction with the ERP system. System integrators and consultants, eager to assist with ERP implementations, only fueled this misconception. Some companies recognized that the newly implemented ERP system would not be able to replace all the information requirements that custom reports and DSS systems provided. Although ERPs helped streamline operations and eliminate duplicate data entry, they did nothing to simplify data access.

The second key enabler to business intelligence was client/server computing. With PCs on many users’ desktops, companies could shift much of the processing power from mainframes to PCs, at a significantly lower cost. All of the sexy charts that made EISs so appealing could easily be rendered on an MS Windows or Apple desktop. The user interface was much more intuitive than mainframe-based reports and programming languages. For the first time, companies could purchase best-of-breed products and the components worked together. Okay, so they needed some brute force and perhaps some aggressive vendor sessions, but they did work, a shock for many who previously had single-vendor solutions.

While client/server computing placed greater demands on BI, the Web has brought BI to even more users. In some respects, the client/server computing that was once a catalyst for BI can now be an obstacle (that and a general resistance to change). With client/server computing, BI software and database connectivity had to be installed on every user’s desktop. With the Web, BI users only need access to a browser. Customers have been rethinking their corporate intranets and BI infrastructure to better leverage the Web. In some circumstances, the Web has both expedited and hindered broader BI adoption. Because many Crystal Report consumers required little report-based interactivity, the Web became the perfect delivery vehicle for those reports. Meanwhile, the huge installed base of BusinessObjects classic users has slowed the adoption of Web Intelligence. Also, prior to XI Release 2, there was significantly more functionality in the BusinessObjects desktop interface than in Web Intelligence. Despite some strong selling points of the Web-based interface, few BusinessObjects classic report users were willing to give up the familiarity and robustness of the desktop tool.

Data Warehouse Speeds BI Adoption

The data warehouse was the biggest enabler for powerful reporting and BI’s initial wave of success. A data warehouse extracts information from the ERP and aggregates it to allow for fast analysis of vast amounts of data. Some initial data warehouse projects were deemed failures, costing millions of dollars and producing no measurable benefits after years of effort. Fortunately, industry consultants quickly remedied the data warehouse approach, proposing subject-oriented data marts that can be built in smaller time frames. Ideally, a central data warehouse still acts as the platform to populate the data marts. As a technology, data marts and data warehousing allow IT to safely isolate the transaction system from the reporting system. A slow query does not halt order processing. As a business application, data warehousing allows users to analyze broader sets of data with dimensional hierarchies. When analyzing data in either an ERP or a proprietary transaction system, the queries are still limited to a particular module or set of tables. I suspect that one reason that BusinessObjects is so widely deployed without a data warehouse is that it provides unique capabilities to report authors to circumvent these constraints. With BusinessObjects, report authors can query multiple subject areas and stitch the results together seamlessly, locally. Synchronized multiple data providers is probably the single most anticipated feature in Web Intelligence XI Release 2.

With a data warehouse, the data is combined into one subject area or business view, allowing users to perform analyses that cut across multiple business processes. This approach puts significantly less strain on the BI application and is more scalable than attempting to put so much logic within one report. As the data is aggregated, data warehouses can contain years of history, allowing users to analyze trends; ERP and transaction systems often contain only current data at the most granular level of detail preventing any kind of trend analysis. Table 1-1 compares some of the different purposes and features of a transaction system with those of a data warehouse.

TABLE 1-1   Comparison of Transaction Systems with Data Warehouses

The Internet Influence

With the Internet boom of the late 1990s, the Web has had a dramatic impact on BI. A large deployment in a client/server deployment may have been in the thousands; in a Web deployment, it’s tens of thousands. What once was viewed as a departmental application is now considered an enterprise resource. In some cases, the corporate intranet is no longer the deployment boundary, as customers and suppliers can also access rich BI content from a browser.

To leverage the Web, many BI vendors have re-architected their products. The industry still hotly debates Web delivery and authoring approaches. A browser interface is not always as intuitive as a Windows environment and lacks the maturity and consistent design of Windows-based applications. For this reason, Business Objects is continuing to provide a desktop authoring tool, Crystal Reports, for high-fidelity production-style reports, developed by professional report authors. Web Intelligence, meanwhile, is a purely Web-based authoring tool, ideally for business users who may not need all the advanced design tools that an IT developer requires. Yet to provide a certain amount of intuitiveness, Web Intelligence has two interfaces: an applet that has a richer design experience and a zero-footprint HTML version that is more wizard-like for basic reports. Desktop Intelligence, formerly called BusinessObjects classic, allows long-time customers to preserve their report development investments while offering a migration strategy.

The user interface is only one aspect of a Web-based BI deployment that the industry and customers alike need to rethink. The other is clearly the architecture. BusinessObjects XI Release 1 (released December 2004) certainly was about integrating the Crystal and BusinessObjects product lines, but it was also about providing a scalable architecture for Web-based BI. As deployments grow increasingly larger, with 24 by 7 access, and no downtime, the architecture must be more fault-tolerant and use shared services (discussed more in Chapter 5).

A Broader BI Suite

Since its inception, the BI market has been highly fragmented. In the last couple of years, many vendors, including Business Objects, have offered innovations or acquisitions to span multiple BI market segments. While customers may be willing to integrate a database from one vendor with a query tool from a different vendor, they may not be willing to do the same for, say, a dashboard tool and query tool. Customers have moved from departmental, à la carte purchases of multiple BI components to centralized purchases of tightly integrated suites. The degree to which you must understand individual BI market segments is dependent upon the stage of your implementation and your company’s philosophy of seeking best-of-breed solutions versus an integrated solution. It’s also important to understand the vendor’s partnership strategy for those segments in which Business Objects is less of a market leader.

The sections that follow describe some of the main BI market segments. Figure 1-4 shows how some of the market segments relate to components of a BusinessObjects XI architecture.

FIGURE 1-4   Components of a BusinessObjects XI deployment

Data Integration

Data integration or extract, transform, and load (ETL) tools used to be distinct from the BI suite, and with some vendors, they still are. Their job is to take the data from the source ERP or transaction system and then to cleanse and aggregate it to load in a data warehouse or data mart. Simply getting the data into an OLAP database or RDBMS does not in itself provide business value. As business users attempt to answer questions with the data, the ETL process often changes to extract more data, clean the data, or transform it to add robust business calculations.

In 2002, Business Objects acquired Acta Technology, a leading ETL vendor, and rebranded the product as BusinessObjects Data Integrator. The company increasingly views data quality and integrity as key to the success of any BI or EPM deployment and a component of its Enterprise Information Management (EIM) strategy. With any BI implementation, much of the success rests with the information architecture. Provide users with bad data, and the BI tool that is the window to this bad data will take the blame; provide users with good data, and the BI tool will enjoy the credit. In the company’s official product line diagram, EIM is central (see Figure 1-5). To this end, the company continues to enhance Data Integrator, acquiring EII vendor Medience (Q4 2005) as a way of providing access to distributed data sources in real time, and launched Data Federator in Q2 2006. In April 2006, Business Objects acquired privately held Firstlogic as a way of improving data quality.

FIGURE 1-5   BusinessObjects XI product line diagram. Reproduced with permission of Business Objects.

As of 2004, sales from Data Integrator accounted for less than 5 percent of Business Objects’ total license revenues, but this increased to roughly 10 percent in 2005. Data Integrator is one of the company’s fastest growing segments, with sales increasing 51 percent year-over-year.

As an ETL solution, Data Integrator continues to compete with pure-play ETL vendors such as Informatica as well as ETL solutions from RDBMS vendors such as Oracle Warehouse Builder or Microsoft Integration Services (formerly DTS). It’s perfectly reasonable to use a third-party ETL solution as part of your BusinessObjects XI deployment. However, because Business Objects also owns not just the ETL piece of the BI architecture shown in Figure 1-4 but also the front-end pieces, the vendor has extended the ETL integration to the business users. In this regard, while viewing any report, a business user can see the data lineage, transformations, and business descriptions. This information is taken directly from Data Integrator and populated into the universe. This integration allows for a broader type of impact analysis. When the source information changes, an administrator can identify which data warehouse table columns, which universes, and ultimately which business reports are affected. In cases in which Crystal Report instances have been used for maintaining historical data, Data Integrator can access these report instances to populate a data warehouse.

Query and Reporting

Query and reporting is the process of querying a database and then formatting it for readability and analysis. This is the segment in which BusinessObjects initially was launched in the early 1990s, and its origins help explain why its SQL generation is so robust. Over the years, the prevalence of query and reporting tools has led this market segment to become synonymous with business intelligence, even though business intelligence encompasses so much more. With query and reporting, users may query a data mart or a data warehouse, or they may query a transaction system.

Some define reporting as the process of formatting a report to enable analysis, while others define reporting as the delivery and distribution of standard reports throughout an organization. In 2003, Business Objects acquired Crystal Decisions, traditionally considered an enterprise reporting vendor. Hmmm, but wasn’t BusinessObjects used for reporting as well? Yes, and herein lies a potential source of confusion that you must manage as part of your deployment. For sake of clarity, I’ll refer to Crystal Reports as a production reporting tool and Web Intelligence as a management reporting tool. But don’t pigeonhole these tools as reserved for certain users or data sources. As I’ll explain next, while there are some clear differentiators between the two, there also is potential for overlap.

The needs within production reporting are often different than the needs within management reporting. Yet sometimes, the needs blur and the lines cross—and just as you can use a hammer to get a screw into the wall, you can use a production reporting tool for management reporting. The converse, however, is not true: rarely can you use a management-style query and reporting tool to develop production-style reports. The tool may not support the pixel-perfect layouts, normalized data sources, or programmability that IT developers demand.

With management-style query and reporting, the source is more often a data warehouse (though not always). Whereas IT develops production reports, power users and casual business users develop their own reports. The following table compares some additional characteristics that help distinguish production-style reports from management-style reports. These characteristics are by no means absolutes. Neither of these segments is precise. For example, Web Intelligence reports can be used individually, departmentally, or enterprise-wide. Crystal Reports would rarely be developed for an individual user and are more often enterprise-wide. Similarly, bursting a report and pushing it to numerous recipients is often considered a strong point of Crystal Reports, yet this is also possible with Web Intelligence reports (although it requires different processes and server resources).

(Source: BIScorecard.com)

Production-style query and reporting is the process of querying an OLTP database and then formatting it to create a document, perhaps an invoice, a bank statement, a check, a list of open orders, or a fixed report consumed by thousands of users. In creating these reports, developers often require dynamic and programmatic control over the layout. These are some reasons that Crystal Reports is embedded in so many applications, with native connectivity to dozens of data sources. When the reporting is not against the transaction system, it may be against an operational data store or detailed data within a data warehouse. An invoice looks the same month to month; users have little desire to tailor its appearance (unlike a management report). This is Crystal Reports’ sweet spot.

Management-style query and reporting is intended for users who want to author their own reports. They are less concerned with the precise layout (since they aren’t trying to generate an invoice) but do want charts and tables quickly and intuitively. This is Web Intelligence’s sweet spot.

Most organizations have the need for both types of tools, although in smaller organizations, you may choose one or the other.

Analysis

BusinessObjects XI provides query, reporting, and analysis in one interface, Web Intelligence, that generates a dynamic microcube based on the query results. Online Analytical Processing (OLAP) has historically been a distinct market segment of BI. OLAP databases were often implemented as separate solutions from a query and reporting tool. With OLAP-aware universes (new in XI Release 2), Web Intelligence users can analyze data in OLAP databases such as Hyperion Essbase, Microsoft Analysis Services, IBM DB2 Cube Views, or SAP BW. Crystal Reports can also access OLAP databases natively for richer report design against these data sources. OLAP Intelligence offers users access to OLAP databases as well.

In its broadest sense, OLAP provides multidimensional analysis with different dimensions and different levels of detail. Capabilities such as drill-down, rotate, and swap are OLAP features. OLAP, though, has some clear definitions set forth by E.F. Codd (the father of the RDBMS) in 1993. OLAP itself can be further divided into different approaches: relational (ROLAP), multidimensional (MOLAP), hybrid (HOLAP), or dynamic (DOLAP).

NOTE   DOLAP used to be an acronym for Desktop OLAP because the processing initially occurred on the desktop. However, Dynamic OLAP is a more appropriate acronym, as the processing can occur in either a desktop environment or a mid-tier application server, but in either case, the cache is built dynamically without any explicit user or administrative tasks.

These approaches differ in where the aggregations, calculations, and processing are performed. The following table compares some of the vendors and their different approaches to OLAP:

Given these traditional OLAP architectures, it’s not surprising that many customers are not sure where to classify Web Intelligence or Desktop Intelligence. I often call it a DOLAP solution because the cache is built dynamically, either on the desktop in the case of Desktop Intelligence or on the Enterprise Server in the case of Web Intelligence. However, it is also a ROLAP approach because it provides automatically drill-through to detail, server-based ranking, aggregate navigation, and other capabilities while leveraging the data storage of the RDBMS. The only architecture you can say it is not is MOLAP. You might deploy BusinessObjects XI instead of a MOLAP solution or in addition to a MOLAP solution.

Analytic Applications

Henry Morris of International Data Corporation (IDC) coined the term analytic application. For software to be considered an analytic application, IDC says it must have the following characteristics:

•  It must function independently of the transaction or source systems.

•  It must extract, transform, and integrate data from multiple sources and allow for time-based analysis.

•  It must automate a group of tasks related to optimizing particular business processes.

At one point, analytic applications seemed to be the next big wave of BI, and yet many vendors who dove headfirst into the segment later retrenched. Business Objects has always had a much stronger build than buy mentality. I hesitate to use the term build, as it is reminiscent of developing an application from scratch, coding in a programming language. The build approach with analytic applications is more appropriately described as customize, in which developers and users assemble objects and templates to deliver an application.

With Application Foundation (initially released in 1999), Business Objects provided a development platform for companies to build their own analytic applications and management dashboards, specifying their own process rules and best practices. The initial product met with mixed success and was largely constrained by the full-client BusinessObjects. With the release of XI, the company rebranded its analytic applications as Performance Management Applications. This solution has a number of prebuilt applications such as Customer Intelligence, Finance Intelligence, and Supply Chain Intelligence, to name a few, all rewritten leveraging Web Intelligence XI. Analytic Solutions are prepackaged data models built with Data Integrator that are available for retail, CPG, and finance.

One of the larger segments of analytic applications involves budgeting, planning, and financial consolidation software. In the past, Business Objects preferred to partner with vendors of such solutions even as part of its Performance Manager product. In August 2005, the company acquired SRC software. SRC uses relational storage for planning data, allowing customers to readily integrate SRC within a BusinessObjects XI deployment. The vendor plans to provide prebuilt planning universes and greater security integration in the future. Business Objects continues to partner with other vendors in this segment, including Geac Computer and Cartesis.

Dashboards and Scorecards

The terms dashboard and scorecard are often used interchangeably, although there is a difference. In its simplest terms, a dashboard is a collection of information, similar to a dashboard in your car. It might include

•  A map that color codes where sales are performing well or poorly

•  A gauge chart that shows if expenses are over/under budget

•  A trend line that tracks stock outs

Whereas dashboards present multiple numbers in different ways, a scorecard focuses on a given metric and compares it to a target. In analyzing performance versus the target, a scorecard may provide a strategy map (see Figure 1-6) and track accountability. Scorecard products are often certified by the Balanced Scorecard Collaborative.

FIGURE 1-6   Strategy map within Performance Manager

Business Objects offers Dashboard Manager as a dashboarding solution and Performance Manager as a scorecard solution (not to be confused with Performance Management Applications! ). Across the industry, a dashboard solution can be anything, including a complex document you create in Web Intelligence or Crystal Reports, a customized portal such as My InfoView, or a more robust solution such as Dashboard Manager (see Figure 1-7). Where Dashboard Manager is most different from a complex document is that it has several integrated analytic engines (Segmentation, Metrics, Rules and Alerts, Predictive, and Statistical Process Control) that allow for more sophisticated analysis. It has built-in analytics or controls to facilitate visual analysis and interaction with the dashboard. For example, a map analytic allows you to display data geographically. A thermometer analytic allows you to display a metric against a target value.

FIGURE 1-7   Dashboard Manager

Data Mining

Data mining is a particular kind of analysis that discovers patterns in data using specific algorithms such as decision trees, neural networks, clustering, and so on. Data mining is used for predictive analytics and is forward-looking, whereas query and reporting tools are more typically used for analyzing historical data. Another difference is that, whereas standard query and reporting tools require you to ask a specific question, data mining does not. For example, an interesting data mining discovery is that beer and diaper sales are closely correlated (one theory: a quick stop to the store to pick up more diapers is a good time to pick up more beer); a standard query tool would force a user to ask a more precise question such as, What do beer consumers purchase in the same store visit? With a data mining solution, users only need to say, Here is some data, now show me what’s related. Okay, I’m simplifying it. The truth is that building models and interpreting them is a sophisticated task demanding a highly skilled statistician.

Business Objects does not compete in the data mining space that is dominated by SAS, SPSS, IBM, Fair Issac, and others. Business Objects does, however, provide OEM data mining capabilities from KXEN as part of its Performance Management, Predictive Analytics module. Models from other data mining packages, such as SAS and IBM, can also be passed via Predictive Markup Modeling Language (PMML) to Performance Management.

The History of Business Objects the Company

Bernard Liautaud cofounded Business Objects in France in 1990. In Q3 2005, Liautaud assumed the role of Chief Strategy Officer. John Schwarz, previously President of Symantec, became CEO. Business Objects has dual headquarters in both Paris, France, and San Jose, California. While such a multicultural split in headquarters can create a not invented here attitude, Business Objects sees its transnational identity as a competitive advantage in a global marketplace.

At one point in BI history, Business Objects might have been viewed as a niche player or underdog. Today, it is considered the industry leader on a number of fronts. Its revenues, once in the millions, reached the one billion dollar mark in 2005. Part of what has helped it reach this mark has been its acquisition of Crystal Decisions, but clearly, the other aspect has been a history of innovation.

Product Innovation

It’s difficult to say whether XI Release 2 or XI Release 1 is the company’s biggest release to date as they both contain significant innovations. Many observers predicted that XI Release 1 would never happen. The key innovation in XI Release 1 was the integration and re-architecting of the product line to leverage the service-oriented, proven architecture of Crystal Enterprise. This re-architecting allows for open and more fine-grained security, greater scalability, and a broader suite of capabilities on a common platform.

In XI Release 2, there are numerous innovations, but the one that will have the biggest impact on long-time customers is support for Desktop Intelligence (or full client documents) within the new platform. As well, Web Intelligence now provides a richness in authoring, analysis, and report consumption that will make it the preferred interface going forward. Customers can optionally convert documents to Web Intelligence (see Chapter 24 for a comparison of capabilities).

Figure 1-8 provides a timeline of some of the company’s major product innovations and key acquisitions.

•  1990   Patented semantic layer allows users to generate SQL using familiar business terminology.

•  1995   BusinessQuery for Excel (now discontinued) allowed users to launch a query directly from a spreadsheet and analyze the results in the spreadsheet. Live Office replaces this product in XI Release 2, supporting content from both Crystal Reports and Web Intelligence.

•  1996   BusinessObjects is rearchitected as a 32-bit application and introduces the microcube technology for Dynamic OLAP.

•  1997   Web Intelligence thin client is first introduced.

•  2000   InfoView Portal is released, along with BusinessObjects 5i, which offers full-client capabilities in three-tier mode.

•  2001   Auditor is launched, allowing administrators to track use of documents, universes, and objects by users and groups.

•  2001   Application Foundation and BusinessObjects Analytics are launched, providing companies with prebuilt applications as well as a development environment for analytic applications. These products are later rebranded Dashboard Manager and Performance Management Applications.

•  2002   Acta is acquired to provide ETL capabilities and packaged data marts, later rebranded as Data Integrator and Rapid Marts.

•  2003   Crystal Decisions is acquired for its pixel-perfect reporting solution, enterprise architecture, and huge base of OEM partners and customers.

•  2004   BusinessObjects XI Release 1 provides a new architecture that integrates Crystal Enterprise and the classic BusinessObjects suite. The product includes several major enhancements such as collaboration and guided analysis through the Encyclopedia.

•  2005   BusinessObjects XI Release 2 closes the parity gap between Web Intelligence and Desktop Intelligence. It includes a new patented interface Intelligent Question to garner more casual users.

•  2005   SRC Software is acquired as part of the company’s performance management strategy, providing budgeting, planning, and financial consolidation software.

•  2006   FirstLogic is acquired to embed data quality capabilities in Data Integrator.

FIGURE 1-8   Major product innovations

The Future

At the time of this writing, Business Objects is considered the leading BI vendor in terms of revenues, product capabilities, and market presence as defined by a number of analyst firms, including IDC, Forrester, and Gartner. Although there has been recent consolidation, the market remains relatively fragmented, and competition is fierce. While nobody can predict the future, it’s relevant to consider some of the vendor’s strategies that will shape future product directions and determine continued success:

•  SMB and Enterprise Customers   While many BI vendors (including Business Objects) continue to pursue enterprise customers and expand the footprints in these accounts, Business Objects further extends its reach to small to medium-sized businesses. In the last year, it has released special versions of Crystal Reports to provide a complete entry-level reporting solution. Also, the release of Crystal Xcelsius gives these customers highly visual, Excel-based dashboards.

•  Enterprise Information Management   As discussed elsewhere in this chapter, lack of a robust data architecture can lead a business intelligence implementation to fail. While other BI vendors have largely left these issues to be addressed by database vendors, Business Objects has made information management a core part of its strategy.

•  Enterprise Performance Management   Business intelligence is about empowering users to access the information they need to do their jobs effectively; enterprise performance management is about ensuring the company focuses on those things that most determine business performance. It provides the tools and processes to enable individual business units to measure progress toward goals that are aligned with strategic objectives of the company as a whole. An effective EPM solution requires an enterprise business intelligence platform and robust data architecture.

Beyond these strategies, the momentum of the BI market clearly contributes to Business Objects’ success. Business intelligence spending continues to be cited as the number one or two IT investment for companies in 2006. Product innovations, including the easy interactivity of Web Intelligence, the intuitive power of Dashboard Manager, and the integration of spreadsheet-based BI in Live Office, together extend the reach of BI.

Summary

To borrow a phrase from a data warehouse vendor, business intelligence is not a destination but a journey. While this book focuses on the company’s core query and analysis products, Business Objects now offers much more, extending its capabilities into ETL on the back end and analytic applications on the front end.

A business intelligence implementation is a project that you will never finish and is one in which the best you can do is to provide a starting point for users to make more informed decisions and discover opportunities. With so much product capability, you must stay focused on the business value of BusinessObjects XI. Your challenge will be to understand how the history of business intelligence in your company influences your users’ attitudes, understanding, and receptiveness toward BusinessObjects XI. Perhaps you are still fighting some of the battles of just having implemented a new ERP. Perhaps your initial goal is a modest one of simply weaning users from printed reports to online reports. Perhaps your company will be one of the industry innovators which many aspire to be, using BusinessObjects XI in ways never before anticipated and directly contributing to your firm’s market position and profitability. Enjoy the journey!

CHAPTER

2

Goals of Deploying BusinessObjects XI

Whether you are first implementing BusinessObjects XI or expanding an existing implementation, it’s important to be clear about the goals of your deployment. You may be implementing BusinessObjects XI as part of an IT effort or as part of a specific business initiative. The goals of these two groups can be quite different. The goals may be driven by the following:

•  IT to reduce infrastructure costs, limit custom report development, or replace a legacy reporting system

•  A business unit to provide access to data to manage and measure the day-to-day business activities

•  The corporation as part of a larger enterprise performance management initiative, as a strategic tool that provides competitive advantage

The goals of different stakeholders may collide and impede progress or merge to make the implementation more successful. You may start out on the implementation with one set of goals only to discover a more important goal as you proceed. In some cases, good scope management will help the project stay on track. In other cases, recognize that business intelligence is not as exact as other technology projects and requires a degree of flexibility. Capabilities are delivered on an iterative basis rather than a traditional waterfall project lifecycle. Often, you may feel that a BI project never ends, and in fact, it doesn’t and shouldn’t. However, focusing on the goals of the project will help minimize the risk that the technology and latest product innovations become all-consuming (as fun as they may be!) and ensure resources are aligned to deliver value within a defined timeframe.

DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.

IT Goals

Although BusinessObjects XI provides business insight, it is still a tool purchased primarily by the IT organization as the enabler to information access. IT controls the source systems and the data warehouse. The challenge here is in making sure the IT goals are a starting point and not an end point. For example, let’s assume that your current approach to reports is for a custom programmer to develop them against the source system. Crystal Reports may be the tool of choice for creating such custom reports. The business users are reasonably happy because each report is customized with their view of the data; it’s easy (no training required), and it’s correct because the data came directly from the transaction system/ERP.

However, this approach to information access poses several problems:

•  The report developer generally has to know the detailed ERP/OLTP schema and programming language.

•  The cost to develop and maintain one report is high. Because the report developer is several steps removed from the business, it may take multiple iterations to get the report right. By the time it is right, however, the user requirements change.

•  Reporting directly against the OLTP can affect response time both for inputting transactions and for executing a report.

•  Without a data warehouse, a significant amount of business logic is built into each individual report.

Some users, though, are not satisfied, because IT can’t develop custom reports fast enough. IT has become a bottleneck. Your company decides it needs to complement the Crystal Reports deployment with Web Intelligence as an ad hoc query and reporting tool with the primary goal of reducing the time and cost to develop custom reports and ideally providing end users with more flexibility. You enable the Web Intelligence module, build a few universes, and train the users on the tool. Users will now be able to create their own reports, and the IT department can focus on a smaller set of canned, enterprise-wide reports. Goal accomplished?

No. First, the skill set to build a BusinessObjects universe is often quite different than the programming skills to develop an ERP-based custom report. The roles of the existing report developers must be redefined, or they will impede implementation (see Chapter 3, under the heading Influencers). Is there still a need for custom reports against the ERP? Probably, yes, but ideally for a much smaller number. Second, you just went from a business user’s having access to a fixed report (easy to use) to the user’s starting at a blank query panel with no data. Part of such a deployment effort must include an evaluation of which reports should remain as fixed reports, which should be eliminated, and which should be re-developed as standard Web Intelligence reports. IT may still develop these initial Web Intelligence reports, since they know the data and current reporting requirements, or power users within the business may become the initial report authors. Don’t let this step discourage you—providing standard reports is a starting point only. With all the Web-based interactivity in Web Intelligence, end users (not IT developers) can easily fine-tune a report to resort, format, filter, and drill. Creating a set of standard reports ensures that users do not perceive Web Intelligence as a step backward: theoretically empowered, but overwhelmed and with no data and certainly no business insight.

Author and researcher Jeremy Hope suggests in his book, Reinventing the CFO, that IT is a culprit in CFOs being increasingly overwhelmed. He suggests that IT has provided finance users with so much unfiltered data that CFOs should be more wary of implementing new tools and IT systems that soak up valuable time and money but fail to provide reasonable value. At first blush, his case seems to put unfair blame on IT. IT often provides users with more unfettered access to data, because they ask for it … or because the users don’t and can’t adequately define their requirements. Users must accept some culpability in the overwhelming amount of data (but little business insight) that many data warehouse and business intelligence implementations provide. Yet in support of Hope’s contention, IT can do much more to ensure value is provided. Standard reports are certainly a way of accomplishing this. Dashboards are yet another. In this regard, IT knows what is possible and needs to work in concert with the business to ensure both constituents achieve their goals.

Over time, as both power users and casual users work with the standard Web Intelligence reports, they can move on to modify, customize, and finally, create their own reports. It is this phase of the implementation in which IT realizes the cost benefit, and the business gains a lot of other benefits. Had you stayed in custom development mode with only a handful of Crystal Report experts, the programmers would still be hard-coding inflexible reports and users would see only a limited amount of data. While the goal to limiting custom report development may not sound as glorious and strategic as enterprise performance management, it is valid, with a measurable benefit of reduced costs and overtime, along with improved business insight.

Reporting Directly Against a Transaction System

When you implement an ad hoc query tool, you may reduce report development costs, but you do nothing to improve query response time or provide meaningful context to the data. In fact, you run a high risk that you will make response time significantly worse for both the end user queries and transaction system inputs. The simple answer is to build a data warehouse or a data mart. After all, the fundamental difference between these two platforms is their sole purpose in life: automating a process versus providing business insight (see Table 1-1 in Chapter 1). Yet many companies still elect to implement BusinessObjects XI directly against the OLTP (or a copy of it) for several reasons:

•  Timing   A data warehouse may be a long-term goal, but under budget constraints, companies need to achieve immediate benefits. They don’t have the time or resources to develop an enterprise information strategy. If you recently implemented a new OLTP, then you need reports right now, immediately, not six months from now. This kind of approach also gives you a relatively quick way of communicating the value of deploying a business intelligence solution.

•  Lack of sponsorship   A successful data warehouse project requires strong business sponsorship and agreement across departments and functions. In contrast, OLTP-based reporting is often deemed an IT responsibility, since IT programs the reports. IT can implement and control reporting in this environment, without having to gain the buy-in necessary for a data warehouse; the politics of a data warehouse project are deferred.

•  Cost and complexity   Data warehouse implementations range in price from $50,000 to millions of dollars. Poorly managed projects can take years to achieve measurable benefits, and even well-managed ones will take several months. In addition to selecting a BI tool, you will face a number of other choices in terms of architecture, servers, databases, data integration and ETL tools, approach, and design. A data warehouse is a long-term investment, but be careful not to ignore the hidden costs associated with implementing Web Intelligence against the OLTP. Lack of dimensional or cross-functional data may limit the data’s usability; data will remain just data and not information. The universes will be significantly more complex and take longer to develop, as transformations normally done in the ETL process must be performed to a degree in the universe.

•  Real-time access   Real-time BI continues to generate a fair bit of hype, and new buzzwords such as Operational BI add to both hype and confusion. The real-time debate is both a technology issue and a business requirements issue: what do users need, and what technology can best meet those needs. Certain