Business Goals | Cisco Field Manual: Catalyst Switch Configuration

< Day Day Up >

Regardless whether you are starting out with a departmental implementation or with the simple goal of automating a legacy report process, the sweet spot of business intelligence is when it is aligned with the business goals. This is when BusinessObjects is not merely a productivity tool (for example, to get the same data faster) but a strategic tool that measurably affects company profitability, competitiveness, and market share. Even if you start out implementing BusinessObjects to fulfill IT goals, the road does not end there, as shown next. As long as users access BusinessObjects, its uses will evolve. It may take some heated discussions and a few reiterations of the universes, reports, and implementation approach for the goals to become realigned with the business, but eventually they must. That users will discover the value and all the opportunities to use BusinessObjects is not a sure thing. If its implementation is aligned with business goals, there is a higher chance users will be motivated to use it to its fullest potential. If not, then IT or a business champion must continually promote and educate users on its effective uses (see Chapter 4).

click to expand

Okay, if you are a project manager or sponsor, then it's easier for you to keep the project aligned with the business goals. If you are a lone power user or universe developer, you may be thinking, 'not me, that's for the higher-ups to do!' Perhaps. However, as the BusinessObjects expert, you are best suited to understand how the tool can be leveraged to fulfill the business goals. So often there is a disconnect between the opportunities and the technical capabilities. Keep your ear to the ground, and you will discover the opportunities. Read the company newsletters, and you will discern the company goals and come up with new ideas on how BusinessObjects can help achieve those goals. Most business units have individual business plans. Take a look at them. Which reports can you design to measure implementation of the business plan? Don't forget that some of the world's greatest innovations have come from the rank and file, not the executives!

Given the volume and breadth of data needed to fulfill broad company goals, BusinessObjects is often implemented in conjunction with a data warehouse or data mart. If the data warehouse is being implemented at the same time, many of the business goals in implementing and justifying the warehouse will be the same for implementing BusinessObjects.

The business goals may be fairly broad, such as:

Stopping blind management without direct access to the data that shows the health of the day-to-day business
Gaining insight into what was previously a black hole, caused by a closed transaction system that lacks robust reporting capabilities
Providing data to support company-wide initiatives such as enterprise performance management, business process reengineering, and Six Sigma

Even when the goals are this broad, to achieve measurable benefits, you need to develop more precise goals and tie them in with the BusinessObjects development and implementation. Table 2-1 provides some typical goals by process. With each broad goal, as you implement BusinessObjects, identify what information elements help achieve or measure the goal. If the elements are in the data warehouse, then ensure these elements are exposed in the universe along with the necessary dimensions to provide context to the data.

Table 2-1: BusinessObjects Helps Measure Progress Toward Business Goals
Process	Goals	Measures
Sales and Marketing	Improve customer loyalty	Customer sales over time Customers who buy both products A and B Customer purchases by channel
	Manage prices	Price trend over time Price versus manufacturing costs
	Increase market share	Revenue versus competitors Revenue trend versus industry trend
Supply Chain	On-time delivery	Number/volume shipments shipped by requested data Number of early, on-time, late orders over time Inventory levels for top-selling products
Supply Chain	Low freight costs	Orders fulfilled from most cost-effective shipping point Freight costs Volumes and discounts with freight suppliers
Finance	Reduce aging of accounts receivable Reduce budget variance	Accounts receivable over time Actual expense versus budget
Human Resources	Reduce employee turnover Competitive pay	Employee turnover over time Salary versus job level, job history, market salaries

While the goals in Table 1-1 are company-oriented, other business goals may be more narrowly defined yet still provide a measurable benefit. As you implement BusinessObjects in phases or by departments, look to align the implementation with achieving these specific business goals. For example, an oil and gas company wanted to reduce the number of days it took to invoice a customer. As invoicing is a transactional process, the manager never thought to use BusinessObjects to achieve this goal. The BusinessObjects development team modified the universe and created standard reports to provide the department a way of measuring the current number of days between product shipment and invoicing and monitoring that interval over time, by product and plant. In another case, a physical therapy office wanted to understand why it took longer to treat some patients than others. With flexible reports, they explored how multiple diagnosis or injuries affected the number of visits to recover and could better understand which treatments led to the fastest recovery.

In some cases, the elements may not be in the data warehouse, but you can still provide them with BusinessObjects. In this respect, implementing a data warehouse and BusinessObjects simultaneously poses a challenge for the data warehouse not to become a constraint that limits your ability to leverage BusinessObjects functionality. Just because data isn't in the data warehouse doesn't mean you can't and shouldn't deliver data to users. If it helps achieve a business goal, do it. For example, many companies need access to external market data for benchmarking. Unless the data can be coded to conform to existing dimensions, third-party data often cannot be stored in the data warehouse. BusinessObjects, on the other hand, is much more flexible. It provides a number of ways to incorporate structured or unstructured external data:

The document domain in the repository allows users to store non-BusinessObjects documents, so if the data comes in the form of an Excel spreadsheet, it can be stored in the repository.
The microcube architecture allows users to merge corporate data with external data and display the results via one report or chart.
Universe designers or report authors can embed HTML and web site addresses into standard reports, providing navigation through a thought or problem- resolution process.
BusinessObjects version 6.0 allows XML as a new data provider.

Designing and building the dimensional models, ETL process, and warehouse infrastructure is resource intensive and complex. Short-staffed and nearing (or past) a project milestone, it's easy to devote 90 percent of the time to delivering the star schemas and only 10 percent of the time delivering BusinessObjects universes and reports. For the business, though, the universe and standard reports are the primary window to the data warehouse. Make it unwieldy and the business will not be able to focus on analyzing data for business benefit; they'll spend an inordinate amount of time figuring out how to use the tool. Fail to provide standard reports or dashboards, and the business may feel nothing was delivered. For each of the business goals, you must develop a corresponding standard report as part of the deployment effort. This standard report may act as a template that users then refresh with their own view of the data, or it may be automatically refreshed and sent to them. Even if you do not purchase BusinessObjects' Dashboard Manager, customizing the portal, My InfoView, can go a long way to providing users a pseudo-dashboard with their standard reports. If you are using the full client, you can leverage categories within Corporate Documents to help users track key indicators.

This all sounds pretty obvious, doesn't it? It should be! The issue is that while these business goals are often used to get project funding, with all the technological and organizational issues involved in delivering BusinessObjects, it's easy to forget why you started on this endeavor. The project team gets so focused on setting up the infrastructure, they leave it for the users to figure out what to do with these newfangled tools. In some rare organizations, where computer and data literacy is high, it may be a valid approach simply to deliver the tools. The business runs with it and exploits the value. Usually, though, users accustomed to no data or to inflexible, custom-developed reports do not immediately know how to approach a flexible BI tool. It's up to you as the BusinessObjects project manager, team leader, power user, or internal expert to show them the possibilities!

< Day Day Up >