Modernizing And Advancing Info Magagement

White Paper

MODERNIZING AND ADVANCING INFORMATION MANAGEMENT ACROSS THE ENTERPRISE

INTRODUCTION Information management is key to business growth. It is a competitive advantage with the same merit as product knowledge and inventory availability. These once-held corporate competitive advantages are now considered “tickets to entry” and rather indistinguishable. Regulatory protections are largely gone, and when comparing your company’s features and functions, “demo parity” is the norm, especially within the larger industries. Today, even government entities occasionally act with a perspective resembling the private sector.

If differentiation is not going to occur based on what you do, it’s about how well you do it – and that’s about smart decisions. Decisions occur not only by humans, but also by systems.1 What is now evidently available for the taking is information leadership – the funneling and transforming of homegrown, third-party, and any other available data into interesting nuggets in digestible form for a productive use.

However, it’s only a start to understand this. You have to organize and architect effectively. This white paper from Business Objects, an SAP company, attempts to elevate and label information worldviews and to suggest a more holistic viewpoint along with the skills necessary to meet the modern challenge of information management. It also attempts to provide the information management professional some basis for justifying and budgeting.

Business units – and the systems they utilize for real-time decisioning – need high quality, well-performing, and corporately arbitrated information in real-time. Not only that, but for competitive parity, it is imperative for the information management function to not only respond to business needs, but also to put possibilities on the table that the business is unexposed and unaccustomed to.

1 Systems using information that is

Contents:

1 Introduction

3 Trends and Organization for Information Management Leadership

5 The Organization Checklist

6 Information Architecture: The Data Warehouse

8 The Data Warehouse Checklist

9 Information Architecture: Analytic Access

11 The Analytic Checklist

12 Information Architecture: The Operational World

14 The Operations Checklist

15 In Closing

16 Appendix 1: Keys to Data Mart Consolidation Successes

17 Appendix 2: Dashboard Best Practices

Author: William McKnight

President, McKnight Consulting Group

2 Business Objects. Modernizing and Advancing Information Management Across the Enterprise

White Paper

This information leadership comes from numerous routes being taken today. For many, the worldview begins with a trusted, proven, and favorite artifact of information architecture – such as the enterprise resource planning (ERP) environment, the customer relationship management (CRM) system, or the data warehouse – and it branches out from there to include selective modern components of information architecture. These can include master data management (MDM), operational business intelligence (BI), and predictive analytics.

To be sure, there is no cookie-cutter approach. There are also only pockets of standards emerging. We could see more architectures and methodologies rise to that level – eventually, as the new behemoths of information management settle in after digesting the acquisitions of 2007 (and more likely to come). However, that is expected to take a few important years and, to be certain, each company will require its own information standards.


White Paper

Despite the challenges, information has been serving businesses well. Consider these examples made possible through the power of information management:

Effective, information-based, in-store and call-center cross-selling and up-selling

Credit card fraud detection that has reduced fraud dramatically

Individualized Web experiences

Supply chain efficiencies and just-in-time production capabilities

Reduction of out-of-stock conditions

Predictive churn management

Customer-specific pricing

Effective claims condition pattern determination

To accomplish these kinds of successes, information has been made to permeate all major systems – pre- and post-data warehouse in the data lifecycle. The biggest factor driving the need for change is the real-time nature of the new needs. Information cannot be out of date. Out-of-stock conditions, customer complaints, fraud, and so on, are not most optimally solved with reporting. For a Fortune company, fortunes are gained and lost by suboptimal business decision timing. Data validations are another major area where the timing needs to be immediate.

This creates a distinct challenge for many data warehouses, necessitating the need to spread some of its formerly closely held functions around.

There is also an information explosion, which inundates a data warehouse’s intake capabilities and renders manual analysis to the most basic of levels. In a real-time business world, suboptimally timed decisions can mean the difference between success and failure. The necessary timing of much intelligence gathering is intraday or during the immediate occurrence of a trigger event. We live in a Web 2.0 world where we are always plugged in. Our business decision-making capabilities likewise need immediacy. Analytics must be embedded in our processes.

Google has elevated the expectation level of our users. They enjoy its rudimentary interface and bland result sets. Why? It’s fast. It’s current. It has massive content available, and it doesn’t force the user to ask the perfect question – it facilitates iterative use. No installation or training is necessary. Then, these same users have an IT-developed user interface foisted upon them and, unless done very well, the users may grit their teeth and bear it or they may rebel. The dichotomy of Google versus some of the interfaces and their long development cycles represents the need to move on.

For a Fortune company, fortunes are gained and lost by suboptimal business decision timing.

TRENDS AND ORGANIZATION FOR INFORMATION MANAGEMENT LEADERSHIP


White Paper

As many data quality efforts still focus on quality within a single system, the quality of information remains a challenge. Organizational data ownership and forging a shared business vocabulary remain elusive, when they are inappropriately housed fully within IT, or something is too broadly assigned to one business individual, or too under-assigned and treated with “best efforts.” To begin the process of improving organizational data quality, data ownership is necessary.

Now that sponsorship, governance, and stewardship are experiencing the wide acceptance they deserve, they still need guidance for effectiveness. Most sponsorship, governance, and stewardship efforts are focused on a singular implementation, such as the data warehouse, the ERP system, or the MDM hub. However, now is the time that CIOs need to form another level of governance for their projects – a higher level, architecturally speaking. That level is information management governance. Though the individual projects still require governance, information management overall requires governance to ensure coordination and efficiency of all the information management projects.

Governance is the CIO’s advocate. CIOs generally do not have the bandwidth to do the coordination tasks necessary across the projects alone. Technology leadership is a ticket to entry for the CIO today. So is being a solution provider to the business and getting kudos for doing what the business asks of IT. Many of today’s CIOs need to effect dramatic culture change in order to accede to the responsibilities of information leadership.

Furthermore, at a technical level, organizational efforts to ensure information leadership need to go beyond technology governance, which, at most, recommends technology purchases and high-level technology standards. While technology governance is still necessary, an Information Management Competency Center (IMCC) should be created to help you make sensible and wide-ranging decisions about the locations of corporate data, its movements, and methods of movement. This complements, but does not replace, the emerging Business Intelligence Competency Center2 (BICC), which focuses on user experiences with the information. Incidentally, most BICCs needs to be de-coupled from considering the data warehouse as the sole source of reportable and query-ready information. See Figure 1.

2 The BICC is described nicely at http://www.b-eye-network.com/view/4310

An Information Management Competency Center should be created to make sensible and wide-ranging decisions about the locations of corporate data, its movements, and methods of movement.

http://www.b-eye-network.com/view/4310


White Paper

Figure 1: Information Management Competency Center

Once leadership is organized in this fashion, it is time to skillfully architect for the information explosion the need for real-time data and the need for easy user access and system access to high-quality information.

The Organization Checklist

How much does my business understand about the importance of its information assets?

Do I have subject areas assigned to business data stewards?

Do they accept responsibility, including for data quality?

Do I have an IMCC for overseeing how data is organized and integrated?

Do my various information management structures operate in silos or are they considered part of a cohesive whole?

Have I established a BICC to give attention to our information management technical strategy, in addition to providing a tactical response to users?


White Paper

The data warehouse3 faces a conundrum and companies really need to make a decision about it. One approach is to make the data warehouse real-time, loading it in concert with operational structures and minimizing operational BI.4 This is simple in concept. However, making data warehouses real-time can be an extremely complex challenge. Operational systems need to cooperate with this vision by not being so fragile that they break with intraday extracts. The data warehouse environment needs to be efficient to the point where the requested extracts are kept to a minimum. This is not always the case, so real-time remains a challenge. Service-oriented architecture has increasingly helped allow operational queries, but extracts remain a challenge.

Sometimes, however, the simplicity and value-add of a real-time data warehouse can prove to be so enormous that a company can choose to actually replace its operational system with one that is more “real-time data warehouse friendly.” Generally, these are systems that can tolerate extracts while also performing real-time operations. The irony is that many of these modern ERP systems provide much more analytics than previous ones and also control many of the functions that previously were the domain of the data warehouse. Consequently, some companies have found themselves in the enviable position – but still at an intersection – of having analytical abilities both in operations as well as in a real-time enabled data warehouse.

Putting that aside for the moment, most shops need to choose generally where analytics and BI will prevail, and give the appropriate attention to operational BI as a result. I do not believe a shop can ignore operational BI any longer. However, the emphasis of where the majority of BI occurs is in question – in the data warehouse or in the operational arena.

A lot of corporate merger and acquisition (M&A) activity has occurred in the past few years as well as “virtual” M&A within organizations finally ascribing a sense of need and value to looking at the overall business. This includes a need to look at customers, products, parts, and the like across the organization. As a result, information leadership is increasingly going to look suspiciously at their multiple data warehouses.5 Should there be a consolidation effort? If the warehouses pass the sniff test for unwanted redundancy – especially inconsistent, redundant data (such as two versions of gross profit) – the answer is probably yes.

3 I am using the term “data warehouse” as representative of the data store(s) for post operational data

4 In the data flow in Figure 2, I define operations as pre-data warehouse’

5 Or multiple data marts, as the terminology may go within an organization

INFORMATION ARCHITECTURE: THE DATA WAREHOUSE


White Paper

If there is little to no redundancy (that is, there is a sales-focused data warehouse and a supply chain-focused data warehouse), there is still much benefit from analytical views of the data in both or all data warehouses, and it’s likely that these needs are going to require physical cohabitation. While the detail data can be left alone in the warehouses, a federated layer may need to be added in the extraction, transformation, and load (ETL) that physically meets those needs. See Figure 2.

Figure 2: Federated Layer for ETL

If consolidation projects are needed, they need to be justified on the basis of system cost savings or on the additional business benefit the consolidated data provides – like a consolidated view of customer transactions across all touch points. Keys to so-called “data mart consolidation” success are found in Appendix 1.

About half or more of third-party data brought into an information environment has, or could have, multiple or widespread uses in an organization – for example, D&B demographic information on customers and prospects. Most third-party data is analytic in nature and won’t act in real-time with customer demographics. However, third-party data needs to interact with detailed transaction data, so you can determine detailed customer and prospect profiles for operational and analytical use.

Much third-party data is added for its value proposition to post-operational analytics, and the data warehouse is a good leverage point for these analytics. Aside from being the only environment where attention is realistically going to be given to modeling for access,6 data quality, metadata, and multiuse in general, the data warehouse should be the launch point for all post-operational information.

6 And not insert, update, and delete


White Paper

So, at the least, the data warehouse becomes both the historical data store for regulatory-required data (high volume, low operational use, infrequent query) and the place where those exceptional and infrequent queries (a) need all the data and (b) cannot be satisfied in earlier phases of the information lifecycle. The data warehouse is also the place where the summary data required for operational BI can be generated from the detail and provided back to the operational environment.

At query time, this warehouse has terabytes of information at its disposal but should not have high concurrency needs. This paradigm is fit for one of the data warehouse appliances. In the Information Architecture: Analytic Access section, I delve into some of the needed uses of data warehouse data.

At the most, the data warehouse goes operational, receiving real-time feeds from its sources and directly supporting BI in a near real-time manner. One major benefit to this approach is that all the data is available for analysis without needing summarization and “ETL in reverse” from the data warehouse to the operational system.

Most database management system (DBMS) technology does not cooperate with this strategy. Most are appliance-like7 and not built for heavy interaction with other systems. This will slowly change. However, the market will prefer something that provides short-term lowest total cost of ownership (TCO) and a smooth path into that approach. With the continued average tenures of CIOs two years or less, getting operational data warehouses up and running is an ongoing challenge.

Most companies will settle in between these two approaches to data warehousing, but all should be aware of the possibilities of both approaches.

THE DATA WAREHOUSE CHECKLIST

Is my data warehouse able to receive real-time data from its source systems?

Are my operational systems prepared to give real-time feeds to the data warehouse?

How deep do I need to get into operational BI?

What data marts and warehouses do I need to consolidate versus pursuing a federated layer?

Do I bring my third-party data into the data warehouse?

7 “Give me the data and I’ll do the analysis”


White Paper

The face of analytic data access, wherever it may occur – operations or with a batch-loaded data warehouse, is also changing. Investments in the OLAP paradigm give way to embedded and machine-driven forms of BI, allowing business analysts to accede to higher functions of the business.8 Information leadership drives power to the business and power to the programmer.

However, it’s also true that many more organizational strategies, and consequently people within those organizations, are coming online with more complete utilization of information. Increasingly, users comprise diverse business interests and perspectives relative to the company business, such as vendors, supply chain partners, and customers. Advanced analytics will not happen by rolling out the same reports to these nontraditional users. Users, new and old, demand customization, prefer that customization be under their control, and expect more truly user-friendly, Google-like access to information. They require a wider range of information and analytical styles.

It is important to note that BI tools are not as easy to use, or as interesting, as the BI community tends to think. This is partly why spreadsheets are where the bulk of analytic access work continues to take place. Limitations and all, users know the spreadsheet. However, users repeatedly show that when given simple tools to perform useful functions, they utilize the tools.

The role of information leadership in an organization must go beyond making the raw data available. Front-line users need the data to graphically and visually fit their skills and preferred delivery mechanisms, which are increasingly wireless (email and SMS) and exception-based.

Getting the right information into operations can mean utilizing the data warehouse to collect detail, and process, summarize, and feed selective results to the operational environment for utilization in the real-time environment (see Figure 3). The necessary latency between a data warehouse’s batch load and the batch process that occurs on the data before feeding it back to the operational systems usually means this data arrives a day later – not in real-time. For example, the contact center operator updates a customer profile with whatever new segments the customer belongs to, based on today’s activities. However, she typically is working with day-old activities, so the segmenting lags behind the real-time environment.

8 Think “push” instead of “pull”

Advanced analytics will not happen by rolling out the same reports to these nontraditional users

INFORMATION ARCHITECTURE: ANALYTIC ACCESS


White Paper

Figure 3: Using the Data Warehouse

Consequently, more shops are beginning to cleanse, lightly integrate and hold information operationally and do the processes and summarization necessary on the spot in the operational environment.

However, limitations on data volume and processing cycles in operational environments continue to force some operational workload into the data warehouse. If highly processed, the data warehouse may share its data back to

However, limitations on data volume and processing cycles in operational environments continue to force some operational workload into the data warehouse. If highly processed, the data warehouse may share its data back to operations as XML or formatted HTML. It’s almost as if the data warehouse becomes decision-support middleware when performing this function. For analysts, dashboards and portals are a better step in the right direction than reports, and they can be placed in either the operational or data warehouse environment. See Figure 4. The technology largely doesn’t care. See Appendix 2 for dashboard best practices.

Figure 4: Dashboards and Portals

Perhaps the trend best reflecting the required interface, however, comes in the many forms of “enterprise search” that are already manifesting themselves in toolsets. Enterprise search provides an extensive body of data for the search – at best, all corporate data, giving rise to data virtualization. The search mechanisms are also simplified. In some cases, from few keywords entered, formerly complex queries can be assembled.


White Paper

This model of self-sufficiency is also evident in the area of data mining, which has long been the domain of a special breed of expert, often holding a Ph.D. in a statistics, mathematics, or scientific discipline. The mining process currently deployed in many organizations is not only time consuming due to the challenge of the tools and the semantic gap between the front line and the statisticians, it is also noniterative in nature. Discovered nuggets are only selectively interesting and actionable.

Mining tools that are interactive, visual, understandable, well-performing, and work directly on the data warehouse or mart9 of the organization can be used by front-line workers for immediate and lasting business benefit.

The techniques deployed in earlier generations of tools are generally well beyond the understanding of the average business analyst or knowledge worker. This is because tools have been generally designed for expert statisticians involved in the detailed science of predictive modeling. If this advanced level of analysis is reserved for the few, instead of the masses, the full value of data mining in the organization cannot be realized. For those with average analytical capabilities, mining is not nearly as effective as it could be.

There are, however, numerous accessible mining techniques that are more effective than most, simply because they are used by so many within an organization. With little investment, these techniques can draw attention to significant anomalies that deserve further investigation.

THE ANALYTICS CHECKLIST

How do I introduce enterprise search into my organization?

How do I provide value that exceeds the value of individual spreadsheets?

What summaries of data warehouse data are needed operationally?

How much clean information can be saved and integrated operationally?

Where should I place my dashboards?

Should I make data mining accessible to my end users directly?

9 Information leadership should begin to eliminate the need for post-data warehouse data marts, such as those historically associated with data

mining and analytical applications


White Paper

The biggest trend in business intelligence is the movement of BI “back” into the operational arena. That is, those processes that were primarily considered to need to go against the data warehouse are now being moved back into operational systems themselves, or new systems are being established in operations. However, unlike previously, when ERP vendors were slow to acknowledge the need for anything beyond what they provided, ERPs today tend to work as members of an information ecosystem. It’s like back to the days before data warehousing, only this time with an operational environment increasingly able to keep up with corporate demands.

Today’s ERP environments are well aware of the real-time and up-to-date need for information and facilitate much of the analysis needed in three ways:

By providing the analysis within the ERP system

By flexibly allowing for data warehouse feeds

By enabling enterprise application integration (EAI) and enterprise information integration (EII) for interchange with other operational systems and cross-system queries

When a stock price changes, when a customer is in the store, when fraud is being perpetrated, when monitoring purchase orders, and when a contact center operator has the client on the phone are all examples of when reactions need to be immediate with the most up-to-date information possible.

EAI and EII are support mechanisms for operational BI. Data can be made to appear in the same data store as the data warehouse, if desired – one-stop shopping for corporate information. EII is useful when connecting structured to unstructured data and when immediate data change in response to the data view is desired (that is, when changing a copy of the data will not suffice). EII has utility when the data transformation is relatively light or nonexistent, and just getting the data together for integrated query is the biggest challenge.

EII query performance needs to be considered and the relatively-worse performance (versus the obvious advantages of physical cohabitation) must be acceptable. However, query performance has for too long been considered a “knock-out” issue, while manageability and maintainability, which I would argue is more important overall than top-percentile performance, never seem to gain such status. I suggest they should.

Operational business intelligence is really a mindset

Data quality is the absence of intolerable defects

INFORMATION ARCHITECTURE: THE OPERATIONAL WORLD


White Paper

Operational BI is really a mindset. It’s utilizing the best of the ERP environment, EAI and EII, triggers, Web services, file transfer protocol (FTP), message queue middleware, complex event processing, and even database mirroring to build real-time data integration and drive all data latencies out of the organization. Web services is an idea for application communication that is growing by providing smaller and more independent self-contained processes.

Operational BI also has come to mean certain levels of dashboarding and scorecarding in the operational world where integrated data and analytics are needed. That definition also extends to include event-driven business actions, such as automated agents and guided workflows.

One of the primary considerations in operational BI, and all information management, is data quality. Data quality is the absence of intolerable defects.

Data quality is an elusive subject that can defy measurement and yet be critical enough to derail any single IT project, strategic initiative, or even a company as a whole. The data layer of an organization is a critical component because it is so easy to ignore the quality of that data or to make overly optimistic assumptions about its efficacy. Having data quality as a focus is a business philosophy that aligns strategy, business culture, company information, and technology in order to manage data to the benefit of the enterprise.

Increasingly, companies are realizing the importance of data quality and tending to it earlier in the cycle through preventive measures at the source of most data quality issues – data entry. Specifically, freeform data entry – long the bane of the information management practitioner’s existence – is being restricted. Where it is still necessary, as in manually entering a name for a new customer, there can be matching to third-party sources.

Preventing the data quality defect here at entry saves a phenomenal amount of work downstream, as well as increases the confidence in data for its many uses Now that data is used more for operational BI, we cannot wait for the data to come together “with quality” and be cleansed in the data warehouse.

Another major operational possibility today includes master data calculation. The operational environment is the optimal place to leverage for bringing together master records. Making master data available is optimally done through a common approach in operational BI – the publish-subscribe model. A master data hub collects information on the dimensions of the business, like customer, product, parts, employee, stores, and so on, from their respective operational origins, cleanses that data, and provides it to any system that wishes to subscribe to that “subject area.” This includes the data warehouse and, especially in the event where there is limited cleansing, back to the system of origin of that data.




White Paper

Few have solved the problem of making the “clean” data warehouse available to the operational environment – in other words, making the data warehouse part of a closed-loop system with operations. Several challenges, mainly operational and span-of-control in nature, have seen to it that data warehouses provide post-operational analytic functions only. The MDM hub is built with this in mind. It’s very operational in nature, providing (and sourcing) clean master data to operational and data warehouse systems.10

Data stewardship should be assigned at the subject area level, and the master data in the MDM hub is a primary manifestation of the work of data stewardship.

At some point even further down the road, the hub may be the data store for data entry, with separate systems subscribing directly to the entry at the moment of entry (and cleansing.) This consolidates data quality efforts and provides an even better ability to analyze data in real-time as it enters an organization.

THE OPERATIONS CHECKLIST

How much of my operational BI needs will be met by my ERP system(s)?

What native interfaces do my operational systems provide for data interchange?

What subject areas need mastering in an operational master data hub?

What is my data quality score?

How do I prevent my data quality defects at the point of entry?

Is it time to add an EII server to my operational environment?

How do I cost justify MDM?

10

From “Why you need Master Data Management” by William McKnight, DM Review, February 2008


White Paper

Information leadership going forward requires refocusing efforts. It means new organizations within the corporation, largely comprised of business functions, in order to support needed change. It means taking the data warehouse into some new directions and possibly accepting the notion of a federated layer. It means the data warehouse will have to find ways to “close the loop” with operations and share its information there. Leadership means learning about and leveraging information advances in current and upcoming ERP environments.

Modern information leadership means mastering organizational master data operationally. It means probably including third-party data into the environment for the value that it brings. Leadership dictates more efforts at ensuring data quality at the point of origin and learning how to fix the defects as soon as possible in the cycle thereafter. Finally, distributing the data as information will take on new forms of, temporarily, dashboards, and ultimately event-driven business intelligence.

The rewards are there for those who take on the challenges successfully. Information leadership is business leadership.

IN CLOSING


White Paper

1. Get top-down support.

2. Fix a problem. Whether you justify on cost savings or a business benefit (or both), the data mart consolidation (DMC) should fix a major, known problem that can be quantified in business terms.

3. Have data standards and a sound data model.

4. Pick the right tools and platform. Put DMC on a scalable platform. Managed within a single database, your data volume will instantaneously explode with DMC. Future efforts will be continuing to grow the environment. Also note that in addition, many take this opportunity of changing platforms to also change data access and ETL tools.

5. Set expectations and communicate with users. There is no such thing as over communication in a DMC project. This is about the users, and care needs to be taken to migrate users without disrupting their ability to access data.

6. Don’t just re-host, re-architect. This time of transition is also an opportunity to reevaluate the data warehouse program according to established best practices – a time to evaluate what is and isn’t working and fully take advantage of the new platform and the migration process.

7. Starve the pre-consolidated marts of attention and resources. Negotiate the condition for user signoff prior to DMC. Make sure all utility is removed from the marts.

8. Justify on either platform cost savings, business benefits, or both. The larger the project, the more DMC is a difficult technical challenge and the platform cost savings more evident. It is always easiest to justify on cost savings but business benefit based on delivering new capabilities can be significant.

9. Expect and plan for cultural resistance. Ownership, as a concept in the former environment, may now be designated at a subject area level as opposed to a data mart level. Carry forward security and stewardship designations and responsibilities to the consolidated data warehouse. This may even be a time to improve these programs.

10. Consolidate ETL and access tools too. Part of the re-gathering of requirements that should be gathered for a DMC necessitates taking the opportunity to ensure tools are still compatible with the new platform and the most fit-for-purpose.

11

11

from “Why you need Master Data Management” by William McKnight, DM Review, February 2008

APPENDIX 1: KEYS TO DATA MART CONSOLIDATION SUCCSS

11


White Paper

Always target the highest-leverage metrics not on the dashboard

Define critical performance metrics

Understand the cause-and-effect linkages behind the metrics

Track metrics over time to identify trends and exceptions

Understand how the metrics relate to the actions to improve performance

Avoid surprises and manage exceptions with advanced alerts

Leverage interactive dashboarding to understand root cause

Make end users part of the process

APPENDIX 2: DASHBOARD BEST PRACTICES


White Paper

William McKnight functions as strategist, lead enterprise information architect, and program manager for complex, high-volume full life-cycle implementations worldwide utilizing the disciplines of data warehousing, master data management, business intelligence, data quality, and operational business intelligence. Many of his clients have gone public with their success story. McKnight is a Southwest Entrepreneur of the Year Finalist, a frequent best practices judge, and author of more than 150 articles and white papers. He has given over 150 international keynotes and public seminars. His team’s implementations from both IT and consultant positions have won best practices awards. McKnight is a former IT vice president of a Fortune company, a former engineer of DB2 at IBM, and he holds an MBA. He is president at McKnight

ABOUT THE AUTHOR

Consulting Group (www.mcknightcg.com).


White Paper

NOTES


White Paper

© 2008 Business Objects. All rights reserved. Business Objects owns the following U.S. patents, which may cover products that are offered and licensed by Business Objects: 5,555,403; 5,857,205; 6,289,352; 6,247,008; 6,490,593; 6,578,027; 6,831,668; 6,768,986; 6,772,409; 6,882,998; 7,139,766; 7,299,419; 7,194,465; 7,222,130; 7,181,440 and 7,181,435. Business Objects and the Business Objects logo, BusinessObjects, Business Objects Crystal Vision, Business Process On Demand, BusinessQuery, Crystal Analysis, Crystal Applications, Crystal Decisions, Crystal Enterprise, Crystal Insider, Crystal Reports, Desktop Intelligence, Inxight, the Inxight Logo, LinguistX, Star Tree, Table Lens, ThingFinder, Timewall, Let there be light, Metify, NSite, Rapid Marts, RapidMarts, the Spectrum Design, Web Intelligence, Workmail and Xcelsius are trademarks or registered trademarks in the United States and/or other countries of Business Objects and/or

affiliated companies. All other names mentioned herein may be trademarks of their respective owners. Part # WP3129-A

businessobjects.com

http://www.businessobjects.com/

Documents

Modernizing And Advancing Info Magagement