When to Analyze Segments

< Day Day Up >

When to Analyze Segments

Ideally, the market segments should be identified early in the development process. As you will see in Chapter 4, market segments help you tailor deployment choices. Failure to agree on the target users or segment can quickly derail your project. As an example, a midsized maintenance supply company started out with a very clear scope: to enable senior marketing people to track monthly gross margin and sales by product, time, and region. They wanted a highly graphical tool with a dashboard. They selected a leading MOLAP and visualization tool, at the time a good decision for this user segment. At some point, field sellers voiced their information requirements. Field sellers needed a different level of detail than the senior marketing people, requiring daily sales figures down to the customer and order number. They didn't want graphics; they needed the detail numbers in a tabular report. Field sellers are a different user segment than senior marketing people, with different needs. Unfortunately, the scope of this project was not well managed. The project manager wanted to be responsive to all users and tried to cram a significant amount of detail into one big cube. Neither user segment was satisfied with the end product. Although the project had strong business sponsorship and was driven by business goals, it failed because the target user group was not well understood .

If the market segments had been clearly defined at the project scoping stage, the project manager would have recognized the diverse needs and could have either declared the requirements out of scope or more appropriately matched the solution with each user segment.

< Day Day Up >

Project Roles

To deliver BusinessObjects functionality, the project team should include both IT and business personnel. As discussed in Chapter 1, business intelligence never ends. Therefore, many of these roles will continue beyond the project completion to provide ongoing support.

Sponsor When business goals drive the BusinessObjects implementation, the sponsor is usually from the business. It may be the CFO if you are trying to measure financial performance, or the VP of Marketing if you are trying to improve customer retention. If the goals of your implementation are IT- related (see Chapter 2), then the sponsor may be a senior person in the IT organization, such as the CIO, ERP manager, or data warehouse manager. The sponsor provides the funding for the project and resolves any scope issues the project team cannot resolve themselves .
Program manager The program manager ensures that BusinessObjects is deployed consistently across multiple projects and applications. The program manager sets the priorities for projects that vie for the same resources.
Project manager The project manager controls the budget, resources, and time to implement BusinessObjects. The project manager ensures that the deliverables are within the agreed-upon scope of the project and that the project stays focused on the intended goals.
Supervisor A supervisor defines users to BusinessObjects and grants access to the BusinessObjects universes, document domains, and software modules. It is primarily a security function that can be centralized or decentralized to allow one supervisor for each department or function. The supervisor must understand the data sources and software modules available, as well as staying informed about personnel changes to revoke or add access when employees change departments. The Supervisor module of BusinessObjects enables you to create profiles to add or remove functionality. These profiles should correspond to the different user segments you've identified.
Universe designer The universe designer provides the business view to the relational data in a transaction system or a data warehouse. The designer must understand SQL from a query and analysis viewpoint, database performance issues, and business requirements. It can be a challenge to find one person with these diverse skill sets. Some companies will train business analysts or power users in the more technical skills, finding this an easier approach than trying to teach an IT developer the business skills. The technical aspects required to build a universe sometimes lead a DBA to become the universe designer. The role of universe designer can also be split between two people, one who physically develops the universe and another who ensures the universe fulfills the business requirements. With larger deployments, there may be several designers across the organization, one for each business unit or function. In these circumstances, it's important to have an 'ultimate' designer or quality assurance process to ensure the universes are deployed consistently (see Chapter 15, 'Quality Assurance Check List').
Report author/pilot user A report author is typically a power user who both understands the data and is computer literate. Report authors may be business analysts who require ad hoc access to information or who previously created and maintained departmental data sources. Administrative assistants who are computer literate and who provide printed reports or compiled spreadsheets may also become report authors. When first deploying a new universe, pilot the universe with report authors. Not all users will be report authors.
Report readers Report readers access fixed reports that may include prompts to filter the data; report authors may prepare and distribute reports to readers via e-mail, the intranet, and so on. Report readers may not have a high degree of computer or data literacy , or the job type may have minimal information requirements.
BusinessObjects expert BusinessObjects experts know the end-user tool set and the different modules available, but they do not necessarily understand the data. They are good with software. Report authors may become BusinessObjects experts as they work more with the tool.
Data expert A data expert may be a business analyst, data modeler, or source system expert who knows where the data comes from, the quality of the data, and its different meanings. The data expert may not necessarily use BusinessObjects but can help resolve data discrepancies that are discovered when users start analyzing it with BusinessObjects. A data modeler designs the underlying star or snowflake schema in a data warehouse or data mart. That person can provide expertise on advanced business calculations and certain universe components such as aliases and shortcut joins. When you introduce aggregate awareness into the universe, the data modeler provides the dimensions by which to aggregate.
Database administrator (DBA) A DBA may be the universe designer or may review the universe for optimal SQL. DBAs resolve query performance problems, build aggregate tables, or correct password synchronization problems between different data sources. The DBA will also help decide the technical deployment of the BusinessObjects repository.
Administrator You may have a BusinessObjects administrator who installs and maintains the software applications (WebIntelligence, BusinessObjects, Broadcast Agent, Application Foundation, and so on). In small deployments, the BusinessObjects administrator and the designer are one and the same. In larger deployments, there may be multiple administrators. Whereas universe designers require a business background and SQL skills, administrators require more technical skills and may be systems engineers . In addition to software issues, the administrator deals with server performance and load balancing.
Trainer The BusinessObjects trainer knows both the software and the data to a degree. Often, two people may provide the training to cover these two different aspects. Internal BusinessObjects experts may train end users, or they may use a Business Objects training partner.
Communication/marketing specialist This person provides expertise on effective ways to communicate project plans, deliverables, and goals to the different user segments. He or she may write or review articles for company newsletters, coordinate internal user conferences, design logos used in project gifts or application screens, and help ensure that key messages are stated in terms of business benefits rather than technical features.