| < Day Day Up > |
|
What is the current situation in your company? Have you just begun implementing BusinessObjects, or has it been available for a while but your implementation efforts have stalled? Are you trying to standardize on BusinessObjects, although you have multiple BI tools? If you have only just begun to implement BusinessObjects, then the current situation may describe the following:
How users currently access information. Is information contained only in the transaction system, or have departments created their own spreadsheets and databases?
How information is shared and distributed throughout the organization
If you develop custom reports, the number of existing reports and the time backlog to fulfill new requests
Attitudes toward the existing information flows. Are users frustrated, or do they think it's generally okay?
If BusinessObjects has been used in the company for a while, the current situation addresses
What data sources are available and which universes are in use
How much users create their own reports or the degree to which standard reports have been used
Typical query response time
System availability
Number of defined, trained, and active users
Product architecture and end-user tools to access the data (BusinessQuery for Excel, WebI, InfoView, BusinessObjects, PDF reports, corporate intranet, Application Foundation, and so on)
The degree to which the universe and standard reports can answer common business questions versus users having to create user-defined objects and report variables
User satisfaction with the current situation
Even if BusinessObjects is the only BI tool in your company, it faces competition. Your job is to identify and understand the competition to articulate why BusinessObjects is better. Recall from Chapter 1 the history of business intelligence. You are trying to change years of decision-making processes within a short time frame. Resistance to change is an automatic barrier. Users may be accustomed to accessing information via paper- based reports, hand-delivered to their desk. When information is difficult to get to, gut-feel decision-making is the competition. If you are deploying BusinessObjects against a data warehouse, then the ERP or transaction system may be the competition. If you are trying to get decision-makers to retrieve their own reports or to access key indicators via a dashboard, the competition is the phone call to a business analyst or to an assistant who can print the reports for them.
A SWOT analysis (strengths, weaknesses, opportunities, and threats) is an effective tool in evaluating the current situation in terms of BusinessObjects' internal competition. It is also a necessary first step in determining what product capabilities you can and should deliver and what benefits you will emphasize in promotions. Tables 4-1 and 4-2 give two sample SWOT analyses. The first one is a for a young data warehouse deployment in which BusinessObjects is not the only BI tool. The second one is for a mature BusinessObjects deployment that has stalled.
SWOT | Analysis |
---|---|
Strengths |
|
Weaknesses |
|
Opportunities |
|
Threats |
|
SWOT | Analysis |
---|---|
Strengths |
|
Weaknesses |
|
Opportunities |
|
Threats |
|
The goal with the situation analysis is to understand where you are today so that you can identify opportunities for improvement over the current situation and/or the competitive information sources. In both SWOT analyses, slow queries are a weakness that has caused a number of threats. Slow queries can be a major barrier for a successful implementation. In DataPro's 1999-2001 Business Intelligence and Data Warehousing User Survey, users rated performance as more important than ease of use when selecting a BI tool. I'm not surprised. Prior to BusinessObjects, users got their reports 'instantaneously' via a DSS or a spreadsheet or a printout. Okay, so the data may have been stale or inaccurate, but users weren't twiddling their thumbs waiting for a query to execute. With the ever greater immediacy the Internet provides, users will want to wait even less time to refresh a query.
While it is true that the majority of response time issues can be blamed on the data warehouse and not specifically on BusinessObjects, failure to fix these problems directly affects the success of BusinessObjects. Users will blame the tool they see, not the technology behind the scenes. Further, while it is up to the DBA to ensure the database is well-tuned with efficient indexes and summary tables, it is up to the universe designer to leverage them. Ensure universe objects frequently used in conditions do not contain advanced SQL commands that cause the index to be bypassed. Report authors must ensure standard reports use condition objects from indexed fields. When you can't improve the data source performance, then use other deployment methods to bypass the problem. Use Broadcast Agent to schedule and distribute reports. Based on the SWOT analysis in Table 4-2, implementing a MOLAP source may be a good approach for response time issues as well as complex calculations. But is the additional BI tool also a right choice, or is it simply an oversight that BusinessObjects or WebIntelligence (WebI) is not being used as the front-end tool to the MOLAP database?
In Table 4-2, one of the identified weaknesses was a large, unwieldy universe. Even IT professionals struggled to know which object to use when. Once the deployment team developed a more targeted universe, offered some standard reports, and promoted the resolutions and enhancements, usage increased significantly within a short period.
| < Day Day Up > |
|