Oracle CRM On Demand Dashboards- P3

Chia sẻ: Cong Thanh | Ngày: | Loại File: PDF | Số trang:20

Thêm vào BST

Báo xấu

87
lượt xem 14
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Oracle CRM On Demand Dashboards- P3: There are many people I would like to thank as I sit here after having just penned the final chapter of this book. I am sure I will miss many specific people if I tried to list them all, but I am compelled to mention some specific supporters.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Oracle CRM On Demand Dashboards- P3

Chapter 1: Getting Started 17 FiguRe 1-6. Service Dashboard
18 Oracle CRM On Demand Dashboards design of these reports is similar in concept to the reports in the other dashboards. There is a heavy use of the Column Selector view, and the overall design of the reports is simple and quite focused. The elements displayed on the Service Dashboard include a dashboard filter prompt, four reports, and a static text view. Service Dashboard Filter Prompt The Service Dashboard filter prompt contains only three fields: Fiscal Quarter, Fiscal Year, and (Service Request) Status. The Fiscal Quarter and Fiscal Year fields filter all of the reports except for the Current Service Request Aging Analysis report. The Status filter applies to all but the Open Service Request Analysis report, which is already filtered to only include service requests with an open status. Open Service Request Analysis The Open Service Request Analysis report provides a breakdown of the number of open service requests by one of four different groupings. By selecting a value in the column selector, you change how the pie chart segments the closed revenue data. The options are Priority, Source, User Name, and Area. Clicking the chart takes you to the Open Service List report, which is one of the Quick List reports in the Prebuilt Reports library. Current Service Request Aging Analysis The Current Service Request Aging Analysis report draws a horizontal bar chart to analyze the age of your service requests. The metric on this report is the average number of days that service requests have been open. The column selector allows you to analyze the average service request age by priority, area, and source. Clicking the chart here also takes you to the Prebuilt Open Service List report. Team Service Analysis Like the other “Team” reports, this one provides managers a means of examining a number of different metrics for each of their subordinates. In this case, the Column Selector view modifies the metric that is analyzed by the report. Managers are able to see the following reports for each of their subordinates: Average Age of Open Service Requests, Number of Open Service Requests, Number of Closed Service Requests, Number of Pending Service Requests, Number of Cancelled Service Requests, and Number of Service Requests (regardless of status). Number of Service Request Analysis The Number of Service Request Analysis report is almost exactly like the Open Service Request Analysis report, except that the Status column is one of the options in the Column Selector view rather than the report being filtered to include only
Chapter 1: Getting Started 19 open service requests. The other options in the column selector are User Name, Area, Source, and Priority. Clicking the chart takes you to the Service List report, which is one of the Quick List reports in the Prebuilt Reports library. This is different from the Open Service List report linked to the other reports on the dashboard, as the Service List report can contain both open and closed service requests. Marketing effectiveness The Marketing Effectiveness Dashboard, shown in Figure 1-7, analyzes your marketing data. These reports focus primarily on campaign records, but rely on relationships between campaigns and leads and opportunities to determine how effective campaigns are. The elements displayed on the Marketing Effectiveness Dashboard include a dashboard filter prompt, four reports, and a static text view. Marketing effectiveness Dashboard Filter Prompt The Marketing Effectiveness Dashboard filter prompt contains just the Fiscal Year and Fiscal Quarter fields affecting all four of the reports on the dashboard. Completed Campaign Results The Completed Campaign Results report examines all of your completed campaigns and allows you to view several different metrics for those campaigns. The metrics available in the column selector in this report include ROI (Return on Investment), Number of Leads, Number of Opportunities, Number of Wins, Revenue, Closed Revenue, Opportunity Win Rate, Cost Per Closed Sale, Lead Conversion Rate, and Cost Per Lead. This report also takes you to a dashboard containing a number of other campaign reports. This “hidden” dashboard, shown in Figure 1-8, is not featured in the dashboard selector at all, and it would appear that navigating to the dashboard is the only way to access it. This Campaign Details Dashboard (which is what we’ll call it) is filtered on the selected campaign and contains a number of reports with charts analyzing records related to the campaign. At the top of this dashboard is a pivot table with a number of metrics related to the selected campaign. Here you can see campaign cost analysis, conversion rate information, revenue target results, return on investment, and win rates. Each metric is accompanied by a flag based on some conditional formatting in the report. Below the pivot table report are two leads reports. The first, Lead Conversion Metrics, provides the number of accounts, number of contacts, number of leads, and number of opportunities associated with the selected campaign. This report also features some conditional formatting flags. Each metric in the report links to a different Prebuilt Quick List report based on the record type. For example, the # of Accounts for Campaign link takes you to the Account List report.
20 Oracle CRM On Demand Dashboards FiguRe 1-7. Marketing Effectiveness Dashboard
Chapter 1: Getting Started 21 FiguRe 1-8. Marketing Effectiveness Campaign Details Dashboard
22 Oracle CRM On Demand Dashboards To the right of this report is the Campaign Averages report. This report provides some calculation results related to the campaign. Average Days to Convert Lead, Average Days to Close Opportunity, and Average Closed Revenue are shown along with conditionally formatted flags. Moving down the dashboard, the Campaign Activity report provides a line chart showing the number of leads created, number of opportunities created, and number of wins generated each week. These are leads and opportunities associated with the selected campaign record, of course. The Campaign Leads report on this dashboard shows you a breakdown in a vertical bar chart of the number of leads related to the campaign by status. Clicking the chart takes you to the Lead Lists report. The Campaign Opportunities report shows you a breakdown in a vertical bar chart of the number of opportunities associated with the campaign split out by sales stage. Clicking a bar in the chart takes you to the Opportunity List report. The Campaign Revenue report shows you a similar breakdown by opportunity sales stage; only in this report, the metric is opportunity revenue rather than number of opportunities. Clicking a chart in the vertical bar chart will also take you to the Opportunity List report. Finally, the dashboard includes a link that opens the Campaign Performance Summary – Averages report in a new browser window. This report provides the averages across all campaigns for the same metrics featured in the pivot table at the top of the dashboard. Lead Followup Analysis On the Marketing Effectiveness Dashboard, the Lead Followup Analysis report displays the number of leads within each stage by fiscal year, fiscal half year, fiscal quarter and year, fiscal month and year, fiscal week and year, lead owner, or salesperson, based on a selection from the column selector. Clicking one of the horizontal bars takes you to the Lead Lists report. Lead Source Analysis The Lead Source Analysis report displays the number of leads dated within the selected fiscal year and quarter organized by source, lead owner, salesperson, or campaign name. Clicking one of the horizontal bars takes you to the Lead Lists report. Opportunity Source Analysis by Close Date The Opportunity Source Analysis by Close Date report analyzes opportunities that closed in the selected fiscal year and quarter. You are able to see the number of opportunities by lead source, campaign name, owner, or territory. Clicking one of the horizontal bars takes you to the Opportunity List report.
Chapter 1: Getting Started 23 The getting Started with Answers Window Although the focus of this book is dashboards, it is absolutely critical that you be familiar with working with reports in order to successfully build dashboards. This should stand to reason, since dashboards are really just webpages within Oracle CRM On Demand used to display reports. It is from the Getting Started with Answers window, shown in Figure 1-9, that you create, edit, and maintain your custom reports. Notice that there are three sections to this window. The Create New Analysis section contains the subject areas FiguRe 1-9. The Getting Started with Answers window
24 Oracle CRM On Demand Dashboards for creating new custom reports. Before we get into the subject areas, let us look below that section to the Open Existing Analysis and Manage Analysis sections. The Open Existing Analysis section contains the Open Analysis button. Clicking this button allows you to select an existing report to open in the Answers screen for editing. You are able to open and work with existing custom reports from your My Folders directory, the Company Wide Shared Folder directory, or the Pre-built Analysis directory. Opening an existing report and saving it with a different name is a great way to create a new report without starting from a blank slate. The Manage Analyses section contains the Manage Analyses button. Clicking this button allows you to copy, move, rename, and delete reports in the My Folders directory or the Shared Folders directory. You are not able to access the prebuilt reports here. Subject Areas Let us return our attention to the Create New Analysis section. Notice that this section contains two lists. The first list contains the Analytics subject areas. The other list contains the Reporting subject areas. It is important to understand the differences between these two subject area classifications. Choosing the correct subject area for your report is critical to the success of your analytic venture. It is highly preferable to select a subject area from the Analytics subject areas for a number of reasons. You will generally achieve the best performance from reports built from one of these subject areas. Reports based on Analytics subject areas draw data from a data warehouse. The data warehouse is tuned for maximum report performance. You will also find that data from related records are more often available for reporting, as the metadata here exceeds the metadata for real-time subject areas. Data moves daily from the operational database warehouse during an overnight refresh. For this reason, reports built in these subject areas contain data that is current as of the previous day. The subject areas under Reporting draw data from the operational database. The users of On Demand are updating this database through the Siebel CRM On Demand interface. Users are constantly manipulating and updating this data. The operational database is structured for efficient data creation and management. When used for reporting, it will typically be slower than the data warehouse. You will want to use the Reporting subject areas only when real-time data analysis is a requirement of your report. You will notice, too, that the Analytic subject areas offer several more choices of subject areas. The data warehouse allows you to take full advantage of the reporting capabilities of Oracle CRM On Demand with historical analyses, additional metric columns designed to measure key performance indicators, and a more complete library of related data within each subject area.
Chapter 1: Getting Started 25 In addition to building reports, you will use Answers On Demand to create your dashboard filter prompts. In Chapter 7, we will explore the development of dashboard filter prompts in detail, but for now, you should know that you will use Answers On Demand to create them and that they, too, are based on one of the available subject areas here. It is also important to note that dashboard filter prompts must be saved in the Shared folders in order for your users to use a dashboard that contains the filter prompt.
This page intentionally left blank
Chapter 2 Dashboard Design 27
28 Oracle CRM On Demand Dashboards I n my first book, I went to great pains to explain the importance of planning before developing reports in Oracle CRM On Demand. When I teach my Analytics Workshop, I always include planning as a lesson early in the class, even if the workshop participants squirm in their seats, anxious to get to the actual building of reports. It is a critical step in the process, especially if you are building reports and dashboards with a limited amount of time. Yes, I realize how counterintuitive that statement may sound. Have you ever heard the adage “what makes you think you will have time to do it over again if you do not have time to do it right the first time?” While dashboards are, in their simplest definition, not much more than webpages used to display reports, some planning is still involved in their development. And although it is true that most of the work is taking place in the development of reports, and rebuilding a poorly designed dashboard requires less effort than rebuilding reports, this rebuilding is still something we would like to avoid. Also, consider that you will want to design your reports with their involvement in dashboards in mind, so the planning step transcends and is critical to both report and dashboard success. Planning Your Dashboards Like most things, creating great dashboards will require a little planning. The array of features and uses of the dashboard capabilities in Oracle CRM On Demand can be daunting. This book will certainly help you master those features, but knowing how to create dashboard filter prompts, embedded links, collapsible views, and integrated report folders will not guarantee you a dashboard that is informative, useful, or effectively meets the needs of your users and business. This chapter will examine the effort that you should make before beginning your dashboard design work. I encourage you to consider the advice in this chapter carefully. Having built many dashboards, and in teaching others how to design dashboards, I have found that these initial steps pay dividends in time and effort. If you do not take the time to plan your reports and dashboard design effort, you are likely to need time to redesign and rebuild your reports and the dashboards that contain them. Whether you are building reports and dashboards for yourself or at the request of someone else, it is important to have a complete understanding of the business need for the dashboard. Presenting reports in a dashboard without direction or reason is usually a fruitless effort. Reports should answer a business question. The dashboard that delivers those reports to the screen should also have a business purpose. Often, a report can answer a single business question quite well—for example, How much revenue did each sales team generate last month? What is the average service request volume by product type? What percentage of my customers is located in Texas? Having a question in mind and identifying what you need in order to answer that
Chapter 2: Dashboard Design 29 question enable you to build an effective custom analysis using Answers On Demand that meets the unique reporting needs of your company. That’s great! But often, multiple, usually related, questions need to be answered, and users are looking for all of those answers in one place. This is where dashboards become useful. Let us presume that I have a great report that tells me how many leads each of my top salespeople generates each week. I also have a report that gives me a preview of the campaigns that are becoming active soon and the historical lead generation of those campaign types. I like to look at these two reports side by side so I can draw some conclusions about how many leads will be generated in the near future. I could run each report, print them, lay them on my desk, and draw my conclusions. That’s not all that difficult, but there may be a better way. If I have designed the reports to provide the data that I need, and I know that I want to compare these results, then I have the beginnings of a plan for a dashboard. Proper planning leads to validity. This applies to both reports and dashboards, but it has to start with the reports. It is not possible for a dashboard deemed valid to contain invalid reports. There are different types of validity, all of which are affected by planning. A great dashboard has face validity, content validity, construct validity, and predictive validity. A dashboard that has face validity looks like it measures what you intend to measure. The purpose of face validity is to win acceptance among users. Users are likely to reject a dashboard if they do not recognize the reports therein as a valid measurement instrument that answers relevant business questions. The questions that the reports answer should be obvious to the user, the reports should clearly deliver the answer, and the dashboard should bring related reports together. Face validity alone does not make for a valid report or dashboard. After all, a report or dashboard can appear to be valid without actually delivering accurate data. A dashboard achieves content validity when a subject matter expert reviews the reports and certifies that they measure and report the correct data and certifies that the dashboard delivers related reports in such a way that the reports are both independently valid and valid in concert with one another. Someone intimately familiar with the data should review the dashboard and validate the results. Proper planning and consideration of content validity of the reports before building a dashboard helps ensure that the content of your dashboard is correct. Identifying the empirical data to include in the report is, of course, critical. An oft-overlooked element is how your user will use that data to make judgments and draw conclusions. Perhaps you will even find it is possible to automate those decisions within the dashboard based on these criteria. Any time you can transform qualitative information into valid quantitative report data, you add value to your analysis. More than anything else, a dashboard with content validity ties directly to your business question. Construct validity is in the message delivered by the dashboard. A dashboard has construct validity when it is formatted in such a way that it delivers the intended message in as accurate and useful a way as possible. Mooers’ Law, given to us by Calvin Mooer in 1959, well before dashboards or Oracle CRM On Demand, applies
30 Oracle CRM On Demand Dashboards today even as it did back then in other contexts. Mooers’ Law states that “an information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it.” This is the greatest value of dashboards in Oracle CRM On Demand. They make retrieving information easy. You can offer several reports to your users on a single screen that is accessed with only a couple of clicks of the mouse. That is information retrieval that Calvin Mooer could have only dreamed of in his day. The problem, though, is noise. Information retrieval is easy, but so is adding bells and whistles and excessive formatting that tend to get in the way of the information. Great reports need not employ every flashy feature, nor does the dashboard containing those reports. Excessive formatting usually distracts from the data rather than clearly deliver the intended message. As we saw with the prebuilt dashboards, a collection of simple reports containing only the information required can be useful and powerful business tools. In fact, you may have noticed that each of the six prebuilt dashboards followed the same basic design, with a simple text view followed by a dashboard filter prompt affecting the four reports positioned on the dashboard screen. Each of those reports is a simple, focused chart. Several reports, each with a single objective, make for an effective dashboard and lead to construct validity. Construct validity is not just about keeping your dashboard simple. You must also take care to identify the correct data elements. Verifying that you are targeting the most relevant data and the data required to answer the business question is critical to construct validity. If you do not start with the correct data elements (reports), it hardly matters how you format the dashboard. No matter how engaging and well designed your dashboard layouts are, if the reports do not provide an answer to the business questions, it has failed, and is not valid. The pinnacle of validity is predictive validity. When your dashboard of reports provides the ability to accurately predict future results, it is exhibiting predictive validity. This is often the goal of historical reporting. A report on the average win rate versus the win rate over the last few quarters may exhibit an ability to predict the win rate over the next few quarters. Predictive reports are extremely difficult to design. With so many variables affecting business outcomes, to accurately predict results is closer to impossible than we would like to admit. If a predictive quality in your dashboard is a goal, you will do well to include both historical analyses and reports containing current data in your dashboard so that they may be compared and predictive conclusions drawn from them. I hope you are beginning to sense how difficult it would be to build a valid dashboard without a little planning. Before you can design and build a dashboard, you need a plan. This plan begins as a question, or set of questions, that you want to answer using the data in the Oracle CRM On Demand database. First, you need to identify, or build, the reports that answer the targeted business questions. Assuming you have a set of valid reports that you want to deliver on your dashboard, the next step is to figure out why you would want to use a dashboard to deliver those reports.
Chapter 2: Dashboard Design 31 Why Do You Need a Dashboard? This seems like such a simple question, one that someone requesting a dashboard should be able to answer easily. The answer, however, is often not so clear. Performing a simple needs analysis to determine the need for a dashboard will save you the time and effort involved in creating dashboards that will not be used. Custom dashboards is a relatively new feature in Oracle CRM On Demand, and analytics dashboards is a hot topic in the business world, so it is easy to want a dashboard because it seems like you should. Too often, we are asked to create a dashboard because we can, not because there is a real need for one. There are three reasons to create a dashboard: ease of access to information, cater information for a segment of users, and provide additional functionality. These are not mutually exclusive benefits of dashboards. A single dashboard may do all three of these things. Every dashboard should do at least one of these things, and if it does not, you probably do not have a good reason to create that dashboard. Easing Access to Information with a Dashboard Suppose you have six reports that describe the current state of your opportunity pipeline, recent sales success, product statistics of recent sales, and so on. Your sales managers run these six reports several times a week as they manage their respective sales teams. At a minimum, each sales manager will have to perform 20 or more clicks of the mouse to view all six of these reports. This is assuming that the reports are not buried inside of report folders and there is no need to select a variety of options in filter prompts. A more typical estimate would be 30 to 40 clicks to run all six of these reports. In reality, this is not all that bad, and it is actually a lot better than most systems that I am familiar with. That said, it is probably more than your sales managers want to do, or feel they have time to do, just to see the information on these reports. Now consider a dashboard that contains a dashboard filter prompt and these six reports. Suddenly the click count goes from 30 clicks to 5, assuming you opt to select a few values in a filter. This is one of the greatest benefits of the analytics dashboard. Making business intelligence easy to access is a huge asset when it comes to doing business efficiently and effectively. Using a Dashboard to Cater Information to Users Next, let us assume that we have three different sets of users: sales representatives, sales managers, and sales support consultants. To support these three groups, you have a library of 12 reports, from which each group uses six different reports. The sales representatives use reports 1 through 6, the sales managers use reports 7 through 12, and the sales support consultants use reports 3 through 8. Because several of these reports are used by multiple groups, it is not helpful to segment the reports into folders based on group served, since at least one group would have to navigate multiple report folders. You could, I suppose, replicate the
32 Oracle CRM On Demand Dashboards reports and provide a set of reports for each group in a separate folder, but then you run into maintenance issues, as you would need to edit multiple reports rather than a single report if something were to change. Now, consider a few dashboards. A dashboard designed for each of our three user groups could present the appropriate set of reports on a single screen, which would not only make the information more accessible, but also would provide the appropriate reports to the correct users. Providing Additional Functionality with a Dashboard The third use of the dashboard has less to do with classic reporting and more to do with business process automation. The dashboard, like most screens in Oracle CRM On Demand, is a webpage with its own unique URL. This means we can direct users to that URL or embed that URL into other pages, like web tabs. Because it is a webpage that we have the ability to embed reports and images and links on to, we are really limited only a little as to what can be done with that dashboard page. I often use a custom dashboard to create a launch page for users. This type of dashboard might contain a list report showing currently open tasks with links to the task records. It could contain links to other reports that are frequently accessed, so users need not go to the Reports tab to find the reports. Perhaps it would include a list of new leads and new opportunities along with a chart showing current progress against sales quota. All of this is information that a sales representative would like to have at the ready each time he or she logs in. Another thing that can be built with a dashboard and dashboard filter prompt is a custom calculator that your users can use to run different scenarios to see results of different variables. For instance, you might have a number of variables that your sales team is able to adjust to create an estimate for products or services. Using a dashboard filter prompt to collect discount rates, incentive amounts, term lengths, interest rates, and so on, you can put a powerful sales tool in the hands of a sales representative that has nothing to do with reports. The use of reports and dashboards as a software development environment is a topic large enough for another book, but I will touch on it somewhat in a later chapter. How Will the Dashboard Be Used? It is easier to separate this question from the previous one in the pages of a book than it is in reality. One can hardly consider the question of why a dashboard is needed without also considering how that dashboard will be used. The question of how a dashboard is intended to be used can be approached in two ways. With this question, you are considering both the physical use and the cognitive use of the dashboard.
Chapter 2: Dashboard Design 33 The physical use of the dashboard is all about what you intend to do with the dashboard. How do you want to interact with the screen? The cognitive use of the dashboard is all about what you want to learn from the information on the screen. What decisions do you want to make using the dashboard, and what information do you need to make those decisions? Physical Dashboard Implications Viewing dashboards and reports online may seem like an obvious thing to a user of Oracle CRM On Demand. After all, there is some form of analytics on almost every home page and an entire tab dedicated to nothing but reports and another tab for dashboards. While reports are often printed, the dashboard is usually utilized on the screen rather than paper. Many of the features of a dashboard are intended for online usage exclusively. Nearly every available feature on a dashboard in On Demand, outside of displaying reports, is intended for exclusive online use. Links, guided navigation, report folders, and dashboard filter prompts are all interactive dashboard features that obviously only work online. When you are designing a dashboard that is intended for online use only, you do not need to worry too much about paper size and page breaks. A report that stretches beyond the margins of the computer screen will have scroll bars. Of course, many users do not care for scroll bars, so you do need to consider the height and width of your dashboard relative to the average computer screen. The dashboard elements that I mention next are all described in detail in this book. I offer much more detail on their use in future chapters. I also recommend that you review the interactive elements of reports in my earlier book, Oracle CRM On Demand Reporting (McGraw-Hill, 2008), as any interactivity built into your reports will also be available in those reports on the dashboards. Dashboard Filter Prompts Dashboard filter prompts provide a means for filtering the reports on the dashboard or passing values to the reports using presentation variables. These prompts are built using Answers On Demand, the same tool you use to build your reports. In Chapter 7, you can read more about creating and using the dashboard filter prompt on your dashboards. Dashboard Pages Did you know that a dashboard can contain multiple pages (or screens)? I am including this feature in the list of interactive features here simply because the presence of multiple pages in a dashboard creates a tabbed browsing interface on the dashboard. In Chapter 4, you will see more about this feature and learn how multipage dashboards are created and used.
34 Oracle CRM On Demand Dashboards Links and Images Links, more so than images, are another interactive element that may be added to your dashboards. These links may take your user to another report, another dashboard, or any location that can be accessed within a web browser by opening a URL. In Chapter 5, you can learn more about adding links and images to your dashboard layouts. Folders As you know, the reports on the Reports tab are organized into folders. The Shared Folders contains two folders: Pre-built Analysis and Company Wide Shared Folder. You may have created additional folders inside of the Company Wide Shared Folder as well. With the Folders object on the dashboard, you can embed all or part of your report folder hierarchy directly inside of your dashboard. You can read more about this feature in Chapter 5. Guided Navigation Links Guided navigation links are another type of link that you may include on your dashboard. The difference here is that the link will appear or not appear based on some criteria, or the link will go to one location or another location based on some criteria. This is a lot like creating an if-then logic in your dashboard. This functionality is also described in greater detail in Chapter 5. Cognitive Dashboard Implications Now that we know what the users plan to physically do with the dashboard, it is important to know what sort of decisions the dashboard, and its embedded reports, will influence. You may find that well-defined business objectives are helpful with this analysis. When answering the question “why do you need these reports?” it makes perfect sense to put together some measurable objectives. If a user plans to use a report to realign territories based on volume, for instance, it is helpful to express this in some sort of measurable objective. I need to identify the average volume of sales for each territory broken down by state and compare that to the average lead generation volume and the planned marketing campaigns for each state in order to realign territories into five territories, each with 20 percent of the average expected volume. This is a useful objective. Now, I know that I need sales volume data grouped by territory and state within each territory, average lead generation volumes, and the marketing plans for each state. This helps me make the best decisions about which reports to include in the dashboard, how those dashboards should be filtered, and which users will use the information presented in the dashboard. What should you do if it is difficult to write a measurable objective? While it is preferable to work toward a specific and measurable objective, the reality of the
Chapter 2: Dashboard Design 35 business world does not always fall so neatly into place. It is not unusual to receive a dashboard request third- or fourth-hand. It is also quite common to receive a request for a dashboard when a report would do just as well. Often, these requests pass from executives to senior management to middle management to the business intelligence developer. One strategy for addressing ambiguity with your dashboard request is to put together a basic dashboard view using prebuilt reports and existing custom reports that are close to what you think is being asked for. Putting together a simple dashboard design is not time-intensive, and it can usually get the right conversations started to eliminate the ambiguity from the request. The old adage of “I will know what I want when I see it” holds true, and I would offer that “I will know what I don’t want when I see it” is just as true. This will help you expose those expectations that you need, making it possible for you to develop a useful dashboard. Who Will Use the Dashboard? Knowing the users of the dashboard is as important as knowing what they plan to do with it. You will design a dashboard differently for different users. For instance, a dashboard for all users of Oracle CRM On Demand is likely quite different from a dashboard used by senior management. Among the design considerations are level of data access, volume of data based on that access, type of information included, and the detail granularity of that information. Of course, who is viewing the dashboard affects the reports that you choose to include just as much as, if not more than, other design considerations. Unlike report folders, where you can restrict access to specific roles, dashboards are available to all users on the Dashboard tab. If a user has access to the Dashboard tab, he or she technically has access to all dashboards. Report access still controls which reports and what data appears in the dashboard, but the dashboard itself is not made available or unavailable by any sort of access controls. In Chapter 8, I offer some strategies for deploying dashboards outside of the Dashboard tab so that you can better control access to your dashboards.
This page intentionally left blank