Chapter 3: Segmenting Your Users | Cisco Field Manual: Catalyst Switch Configuration

< Day Day Up >

Different types of users will access BusinessObjects. One user may be logged into the system 90 percent of the workday and will actively ask for more data, more resources, faster query time, and more functionality. Another user may never directly log into BusinessObjects yet will make decisions from data delivered through BusinessObjects. Both users are your customers, yet they will have very different needs that affect how you develop, promote, and deploy the various products. Using the marketing concept of customer segmentation will help you determine who your user segments are and how they affect your deployment strategy. Chapter 3 defines possible segments, and Chapter 4 describes what you customize per segment.

What Is Segmentation?

Segmentation is a way of looking at one large user base-let's say, all employees in a company-and dividing it into smaller groups. Each segment, or smaller group, has similar characteristics, needs, or benefits. In different chapters in this book, I refer to two common segments, report authors and report readers. Your company may have more than these two segments. Segmentation provides you a way of better understanding your users and why their requirements are different. It will help you prioritize target user groups and provide the appropriate information and functionality to achieve the highest return on investment. As you define different segments, you will want to tailor your product offering, promotion, implementation schedule, and training for each segment. You also may use the segments to define groups and profiles in Supervisor. Following are some characteristics that will help you segment potential BusinessObjects users.

Computer Literacy Level Potential users who have worked with personal computers since their inception will greet BusinessObjects differently than someone who only recently received a PC. Users who primarily surf the Web but do not use spreadsheets and other PC-based programs fall somewhere in the middle. With this characteristic, also evaluate a user's attitude toward computers. A user eager to learn but still a novice belongs in a different segment than an unwilling user who sees PCs as a waste of time and evil, and who would rather throw the ?@#!!*** thing out the window.

Primary vs. Secondary Some users log into BusinessObjects to develop their own reports, refresh queries, and interactively analyze the data. These are primary users whom you will define in Supervisor and grant access to BusinessObjects resources and software modules. However, you will also have a secondary segment of users who consume the information provided by report authors and analysts. These secondary users may never log directly into BusinessObjects; in fact, they may not even know BusinessObjects exists (unless you do some positive promotion, covered in Chapter 4). They know only that they get a number or a report via e-mail or a corporate intranet. For all they know, the data came directly out of one ERP screen. It will be hard for you to estimate the size of this 'secondary' user segment, but in many instances, some of your most important customers are in this secondary user segment. Let's say the VP of Marketing receives BusinessObjects-generated PDF files via e-mail on a regular basis. These standard reports are critical for the VP. The VP's administrative assistant is the one who developed the initial reports and scheduled them via Broadcast Agent. The assistant makes sure the reports are generated and delivered as needed. Meanwhile, as more users come onto the system, the Broadcast Agent server is getting overloaded. Some reports run much later than requested; some fail to execute. The primary user, the administrative assistant, may be the one to shout, but it is the secondary user, the VP of Marketing, that can most likely approve funding for an additional server. Also, it is this secondary customer-who has never logged directly into BusinessObjects-who will most likely see the business potential of products you have not yet implemented, such as one-to-one marketing with Broadcast Agent Publisher.

Job Level A user's job level will affect the breadth of data the user wants to access (number of reports and universes) and the level of detail. Executive-level jobs may need a broad set of data but without a lot of detail. Analyzing the data is a minor part of these jobs, so these may be the people for whom you want to develop a dashboard with key performance indicators. Midlevel jobs may still need a broad set of data but with more detail. The combination of broad data requirements and more detailed data may make it hard to deliver one dashboard. They may need multiple documents and ad hoc access. Entry-level accounts payable clerks or customer service representatives may want to see only very detailed data. As their information requirements are narrow, these users may need one standard report with interactive prompts; they may access BusinessObjects often, constantly refreshing a document for a particular account, customer, date range, and so on.

Job Function Supply chain users will all have similar information needs, which will be different from the information needs of users in the finance department. Administrative assistants may not be decision makers, but in many companies, their exceptional computer literacy and multitasking skills have led them to become pivotal users of BusinessObjects.

Degree of Analytic Job Content Some jobs require a significant amount of data analysis. The analytic component also may relate to either the job level or the job function, or sometimes to both. For example, financial analysts may be fairly senior in a business; these jobs have a high analytic component. These are the number crunchers who will pound the system. They understand the different data nuances and even the potential data sources. It's easy to assume that these people are your only users, since they may have solutions implemented first, complain loudest when something is wrong, live and die by access to information, and control the information flow to secondary users. This may in fact be you! With all your demands for access to information, the company rewarded you with being the universe designer, report author, or BusinessObjects subject matter expert. Congratulations! Remember, though, that not everyone can spend all day collecting, manipulating, and exploring data. Some users need access to standard reports simply to know what is going on. They log into BusinessObjects for ten minutes a day (or week) just to make sure the business is running smoothly. If it's not, they call the business or financial analyst to figure out why not. Users whose job content requires a fair bit of data analysis may use more report variables, user-defined objects, drill by, and ad hoc queries; on the other hand, users with jobs with minimal analytic content may only refresh a standard query on a periodic basis.

ERP or Source System Use Some of your BusinessObjects users may also enter data into the transaction or ERP system. Regardless whether you use BusinessObjects directly against the transaction system or an ERP-populated data warehouse, these users will be more familiar with the precise meanings of individual objects. At the same time, dimensional groupings and hierarchies that don't exist in the source system may be a completely new concept. These users may need additional explanation as to why there is a data warehouse and how the data has been transformed.

Level of Data Literacy Source system users and users whose jobs have a high analytic content may understand the data well and have a high level of data literacy. However, you cannot assume that users with high levels of data literacy have equally high computer literacy. A transaction system user may know the data but be comfortably entering data only by following the exact same screens every time. Change the user interface and they are lost. Conversely, you cannot assume that users with high computer literacy understand the data well. Although these users may be comfortably learning a new software package, you will still need to devote an appropriate amount of time explaining the dimensions and measures.

Level of Spreadsheet Usage Spreadsheet users deserve their own segment. They are loyal to the spreadsheet and think everything should be delivered in a spreadsheet. I used to underestimate the importance of this but was cured of my oversight in the early 1990s. After spending months developing a DSS system for a new transaction system, I waited with bated breath finally to train the users. The users balked at these inflexible, ugly mainframe-based reports and asked 'Why do we need these reports? Just dump all the data into Excel.' Indeed! Fortunately, BusinessObjects has a couple of solutions for these users. New in Version 6.0 is the ability to save a report directly to Excel; the save nicely preserves the charts, formatting, and breaks. BusinessQuery for Excel allows users to execute queries directly from a spreadsheet; it has some built-in features to handle formulas when the number of rows returned changes. If you use MS Analysis Services as an OLAP database, BusinessQuery MD provides the ability not only to retrieve data, but to create calculations and perform server-based rankings. However, running a query from BusinessQuery for Excel can be slower than running a query from BusinessObjects; the issue isn't the SQL, it's the overhead Excel introduces and the additional data/file format conversion. Further, what do users do when they have more than 64,000 rows of data? Is it better to teach these users how to export data or to get them to feel as passionate about BusinessObjects as they do about spreadsheets? Spreadsheet users can't take advantage of breaks; and while Excel may have some good pivot table capabilities, they bear no comparison to BusinessObjects functionality, which automatically adapts when the dimensions and rows change. Even though BusinessObjects offers a number of advantages over a spreadsheet, the issue is simply to recognize that regardless of those advantages, spreadsheet loyalists will want to do their analysis in a spreadsheet. The challenge for you is to recognize this user segment and figure out how best to meet their needs while simultaneously ensuring that the spreadsheets do not get out of hand and become alternative data sources.

Amount of Travel Certain job types require more travel than others. Some BusinessObjects users may access the system only from their desktop; users who travel may want access via a palm pilot, a notebook computer, or if they travel to other offices, any web browser. They may want information broadcast to them or may want to work in offline mode, exploring previously refreshed queries and drilling in local microcubes.

Implementation Phase As you ramp up your BusinessObjects implementation, you will offer different users access to the system at different points in time.

Internal vs. External Users Consider the different needs of employees of the company and customers that you may provide information to via an extranet. Internal employees may be allowed to access whatever software module you have licensed, whereas external customers may not allow applets to cross the firewall, thus encouraging you to publish standard reports to InfoView and view them via HTML. Internal employees may have access to more data, whereas external users will only be allowed to see their data. For these users, you may use the row restrictions and object security levels in Supervisor.

< Day Day Up >