The Background of Business Intelligence

 < Day Day Up > 



The need to access information is not new. After all, people have always needed data to make informed decisions. As a type of technology, though, business intelligence is relatively young. Howard Dresner of the Gartner Group first coined the term 'business intelligence' in 1989. 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 yet more painful. But it was, and in some organizations, it still is.

In the 1980s, 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.

  • Spreadsheets, which provided a bit more flexibility than printed reports. Unlike today, when users may import data directly from a transaction system or data warehouse into a spreadsheet, in the late 1980s, field personnel would call in their sales figures to one accountant or analyst, who would manually enter the 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.

  • 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, never underestimate the role and 'hold' these legacy reporting systems continue to have over users. If you make BusinessObjects 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. It's a little like crash dieting-everyone hates it and it's rarely successful over the long term.

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 their 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.

click to expand
Figure 1-1: Each function had its own custom-built transaction system.

Decision support systems with their proprietary nature gave way to executive information systems (EISs). 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 Pilot Software, Inc.'s, Lightship; Platinum Technology's Forest and Trees; and Comshare, Inc.'s, Commander Decision 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 needed access to information, but all decision makers. 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.

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.

click to expand
Figure 1-2: The business intelligence explosion

Several factors drove the need for more information, faster. With increased free trade, 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, one needs 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 graphic 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, Oracle Financials, and J.D. Edwards. 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 ERP system, an accountant no longer re-keys the information into a separate system; all reference data is shared across the multiple modules. 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.

click to expand
Figure 1-3: ERP systems ensure data integration and apply process rules.

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 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.

Tip 

If you are deploying BusinessObjects directly against the ERP, you must reeducate users about new data nuances and new business terminology. Use the object descriptions in the universe or a help page in a standard report to ease this transition. You don't want BusinessObjects to take the blame for the confusion an ERP may introduce. Further, if you deploy BusinessObjects against a data warehouse, never underestimate the power of 'promises' made during an ERP implementation. Users will want to know why they shouldn't get all their data from the ERP rather than BusinessObjects or the data warehouse. You may be perceived as the bearer of bad news, forcing them to learn yet another new tool when they were promised the ERP was the ultimate answer to all their information needs.

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.

Data Warehouse Speeds BI Adoption

The data warehouse was the biggest enabler for powerful reporting and BI's rapid 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. 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. As the data is aggregated, data warehouses can contain years of history, allowing users to analyze trends and purchasing patterns; ERP and transaction systems often contain only current data at the most granular level of detail. Table 1-1 compares some of the different purposes and features of a transaction system with those of a data warehouse. Note that in the mid-1990s, you could easily replace the column heading 'Data Warehouse' with 'Business Intelligence.' Now, business intelligence also applies to detailed, operational data, ideally in a data warehouse, but not necessarily.

Table 1-1: Comparison of Transaction Systems with Data Warehouses

ERP/Transaction System

Data Warehouse/Data Mart

Goal is to process orders, post journal entries

Goal is to provide access to information to improve revenues, manage costs, achieve strategic goals

Current information with very little history

Larger amounts of history allow five- to ten-year trend analysis, this year versus last year comparisons

Real-time information

Information extracted on a periodic basis (hourly, daily, weekly, and so on)

Detailed data down to the line item or level of data entry

Aggregated data

Fast inputs, but slow queries

Read-only; tuned for fast queries

Rarely hierarchical groupings

Hierarchical groups of codes give level of time, chart of accounts, product groupings, customer groups, and so on

Fixed reports by one detailed dimension (cost center, plant, document)

Fixed or ad hoc reporting and analysis by multiple dimensions across all business functions

Historically awkward user interface, fixed reports only

Easy-to-use MS Windows or browser interface

With all the promises ERP-vendors and system integrators made about the ERP-providing business insight, Table 1-1 may become a necessary part of your training material, particularly for BusinessObjects users who also are ERP users (see Chapter 3 for more on user segments). Without this clear understanding, business users may rather have a custom, parameterized report against the ERP because they know the data is right (i.e., no transformations have messed it up) and it's real-time.

The Internet Influence

Business intelligence tools gradually grew from basic SQL generators to include advanced report formatting and scheduling, OLAP technology, and enterprise-wide deployment capabilities. However, some of the requirements that existed in the 1980s and early 1990s (refer to Table 1-2, 'Then' column) still were not met. Executives are still looking for the dashboard-like interface, and former DSS users still want to be able to log onto any terminal and see their data at the push of a button (Table 1-2, 'Now' column). I recall intense negotiations between Business Objects and the Fortune 500 company I worked for in 1995 in which we were ready to sign a global licensing agreement; if we could come up with a solution for executives who still wanted a push-button solution (à la the early EIS systems), our number of users would be tripled. Otherwise, we were solving only the problem of custom reports, previously developed by an overwhelmed IT department. At the time, few foresaw the profound impact the Internet would have on all BI tools and continues to have.

Table 1-2: Today's Information Needs Are Extensions of the Same Needs in the Early 1990s

Then

Now

Information for executives only

Information for everyone, including external business partners

Dashboard-like interface

Dashboards and push-button access for key indicators, plus ad hoc access for deeper or different analyses

Fast access to strategic information with dimensions and history

Dimensions and history plus information from third-party data sources

Detailed operational reports via the transaction system / ERP interface

Via a Windows or browser interface, with more flexibility

Generic paper reports with too much information hand-delivered to the executive's desk

Personalized, electronic reports delivered via e-mail, intranet, or mobile device to everyone's desk, wherever their desk may be

With the Internet boom of the late 1990s, the industry has come full circle. In many respects, the latest BI innovations are trying to fulfill the needs of 'Then' that were never met, in addition to fixing some of the problems that client/server computing introduced. With midtier application servers (such as WebIntelligence), companies are returning to a server-centric architecture and look to limit their product base. Initially, most BI vendors became Web-enabled by allowing users to save standard reports in HTML format. Finally, the executives once again had a kind of dashboard via corporate intranets! While client/server architecture lowered computing costs and enabled a better user interface, it presented challenges for broad-scale deployments. Gluing together best of breed products from multiple vendors can get ugly. As BI vendors rearchitected their products to deliver interactive Web-based analysis via plug-ins, applets, or HTML scripts, the Internet promises to fulfill two very diverse needs: on a recurring basis, push-button access to key performance indicators, with the flexibility of interactive, ad hoc access when required. WebIntelligence's architecture enables business intelligence beyond the internal corporation to suppliers and external business partners. As a testimony to the company's profound impact on this type of BI innovation, CEO Bernard Liautaud published the business book e-Business Intelligence: Turning Information into Knowledge into Profit (McGraw-Hill, 2000), which highlights how companies are sharing information beyond traditional boundaries to drive profitability and generate new revenue opportunities.

Users may require much the same functionality they did in the 1990s but demand still more information, flexibility, personalization, and speed. The Internet again allows for ubiquitous deployments via an even easier-to-use interface: a web browser. Portals allow for mixed content and dashboard-like screens. Broadcast and push/pull technologies (such as Broadcast Agent Publisher) allow for highly personalized reports delivered to e-mail and mobile devices both within the corporation and beyond with suppliers and business partners.



 < Day Day Up > 



Business Objects(c) The Complete Reference
Cisco Field Manual: Catalyst Switch Configuration
ISBN: 72262656
EAN: 2147483647
Year: 2005
Pages: 206

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net