Cisco Field Manual: Catalyst Switch Configuration

Although BusinessObjects provides business insight, it is still a tool purchased primarily by the IT organization. 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. The business users are reasonably happy because the 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.

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.

Some users, though, are not satisfied because you can't develop more custom reports fast enough. Your company decides it needs an ad hoc query and reporting tool with the primary goal of reducing the time and cost to develop custom reports. You install BusinessObjects, build a few universes, and train the users on the tool. Users will now be able to create their own reports via BusinessObjects. 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, '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 the deployment effort must include replacing existing OLTP-based reports with standard BusinessObjects reports. IT may still develop these initial 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 with BusinessObjects is a starting point only. It ensures that users do not perceive that BusinessObjects is a step backward: theoretically empowered, but overwhelmed and with no data. At the same time, from the company perspective, it avoids a simple shift of report development costs from IT to the business.

Over time, as both power users and casual users work with the standard BusinessObjects 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, the programmers would still be hardcoding inflexible reports and users would only see a limited amount of data. While the goal to limiting custom report development may not sound as glorious and strategic as 'business performance management,' it is valid, with a measurable benefit of reduced costs. It also helps get BusinessObjects in the door and up and running. Use it, run with it, and soon it will hold strategic value.

Reporting Directly Against a Transaction System

When you replace custom report development with BusinessObjects, you may reduce report development costs, but you do nothing to improve query response time and transaction system performance. In fact, you run a high risk that you will make it significantly worse. 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). Yet many companies still elect to implement BusinessObjects directly against the OLTP for several reasons:

• Timing A data warehouse may be a long-term goal, but in tough economic times, companies need to achieve immediate benefits. They don't have the time or resources to develop an enterprise information strategy. If you just implemented a new OLTP, then you need BusinessObjects reports right now, immediately, not six months from now.

• 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, ETL tools (if not Business Objects' Data Integrator), approach, and design. A data warehouse is a long-term investment, but be careful not to ignore the hidden costs associated with implementing BusinessObjects against the OLTP. Lack of dimensional or cross-functional data may limit the data's usability. 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 In the last couple of years, there has been a lot of hype about real-time BI. Certain technologies allow a data warehouse to be updated in near real time as source data changes. Business Objects Data Integrator uniquely includes real-time BI. For some applications, users may indeed need access to real-time data with data feeds from multiple processes and functions. However, I think real-time BI also touches a nerve with OLTP users who need flexible access to transaction-level data. ERP vendors may excel in business process automation, but they have generally been weak at providing intuitive reporting tools. As long as the transaction processing time does not suffer, it makes perfect sense to integrate BusinessObjects with the OLTP. The vendor provides a number of Rapid Deployment Templates (RDTs) to facilitate this. An RDT is a set of prebuilt universes and reports that understand several leading ERP database schemas. Further, some of BusinessObjects features such as multipass SQL and multiple data providers per report make real-time BI against the OLTP achievable.

Whatever your reason for using BusinessObjects directly against the OLTP, you will need to take some precautions to ensure a successful deployment. Killer queries can cripple a system and prevent orders from being processed. It takes only a few times for this to happen before you will either a) fund a data warehouse or b) limit access to BusinessObjects.

If BusinessObjects is to become a strategic application, you do not want to limit access. However, you do want to deploy in a highly managed way, even more so when you are accessing an OLTP. Pay particular attention to the universe design, ensuring optimal joins and removing the ability to use nonindexed fields as condition objects (see Chapter 8, 'Modify a Dimension'). Ensure the standard reports use prompts to limit the amount of data returned and to guarantee that the conditions are based on indexed fields. With custom OLTP reports, each user executes the query, placing an additional load on the OLTP. With BusinessObjects, use Corporate Documents for users to access one prerun report. Use Broadcast Agent to schedule more intensive reports during nonworking hours and Broadcast Agent Publisher to burst reports to individual users. Finally, ensure you use some tracking mechanism, whether the full-blown Auditor or the audit universe (see Chapter 15) to understand who is using certain reports, universes, or objects, and when.