Plan key performance indicators
Updated: February 26, 2009
Applies To: Office SharePoint Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
In this article:
Key performance indicators (KPIs) are simple graphical scorecards that can be used to evaluate business data against business goals.
As part of planning your initial deployment of Microsoft Office SharePoint Server 2007, you should understand the data sources used in KPIs, how to configure those data sources and evaluate the status of indicators, and how to display KPIs in sites used by your organization. You can use these plans during initial deployment.
KPIs are a central way of presenting business intelligence for an organization. Also known as status indicators or scorecards, KPIs evaluate business data against business goals and display current status by using easy-to-understand graphical indicators.
For example, a KPI can use traffic light icons to indicate that customer satisfaction is exceeding, meeting, or failing to meet goals. If customer satisfaction exceeds a preset goal, calculated by counting the percentage of positive satisfaction ratings across your organization, the customer satisfaction KPI is displayed with a green traffic light icon. If customer satisfaction is failing to meet minimum goals, the customer satisfaction KPI is displayed with a red traffic light icon. Otherwise, it is displayed with a yellow traffic light icon.
KPIs increase the speed and efficiency of evaluating progress against key business goals. Without KPIs, employees and business managers would have to painstakingly extract performance data and evaluate that data against goals, and then spend the time to present that data in a separate report for business decision makers. It is difficult to get timely status without a way to quickly and automatically evaluate live data. With KPIs, users who want to find out current performance can look quickly at a report in their business site, or even see relevant indicators in their personal sites.
KPIs connect to business data from various sources, and then use Web Parts that display that information in a list of KPIs or in a detailed view for a single KPI. Those Web Parts can be added to reports in the Report Center site, or displayed in other lists and sites.
Each KPI gets a single value from a data source, either from a single property or by calculating averages across the selected data, and then compares that value against a preselected value. Because values are calculated across a range of data rather than displaying data in list form, KPIs tend to be more useful when measuring performance across groups or projects. However, by calculating a range of data for a specific person, such as a list of sales for a single employee, a KPI can evaluate individual performance.
To use KPIs, you must first create a KPI list. KPI lists are created from a template that enables you to add KPIs based on any of the data sources described in the following table.
The data comes from a SharePoint list that might include business data from the Business Data Catalog or Microsoft SQL Server 2005.
Microsoft Office Excel 2007 workbooks
The data comes from an Excel workbook.
SQL Server 2005 Analysis Services
The data comes from database stores known as cubes, for connections in a data connection library.
Manually entered information
The data comes from a static list, rather than based on underlying data sources. This is used less frequently, for test purposes prior to deployment or on occasions when regular data sources are unavailable but you still want to provide performance indicators.
After creating a KPI list, you create a Web Part that is bound to that KPI list. The KPI data is displayed in one of the following Web Parts:
KPI List Web Part
KPI Details Web Part
The KPI List Web Part shows a list of KPIs that correspond to the bound KPI list. The KPI Details Web Part shows detailed properties for a single KPI.
After you create a KPI Web Part, you can deploy that Web Part in several ways:
In a KPI list page report in the Report Center site or a secondary Report Center site, or in a reports library on another site.
In a multi-report summary page, or dashboard.
In a personalization site.
The KPI list page is a type of report built around a KPI List Web Part, and related summary, and possibly other Web Parts depending on the purpose of the report. When you create a KPI list page report, a KPI List Web Part is included by default. Each KPI in the list must still be added. You can also highlight a single KPI in a report by using a KPI Details Web Part.
KPIs are often used as part of a multi-report summary page, or dashboard. Dashboards use filter Web Parts to filter the data displayed in Web Parts based on certain values. Filter KPIs can be applied dynamically, which enables a business decision maker to quickly compare performance over different periods of time. Dashboards can also filter by other properties.
KPIs in dashboards are more than a single view into data. KPIs are calculated across broad categories, such as total or average sales for employees in an organization. When you plan for KPIs and the lists and Web Parts used to display them, ensure that you know how each KPI will be evaluated during initial deployment and that you identify the data source and calculation method for each KPI.
Each KPI in a KPI list is based on a data source. When you plan for KPIs in your sites, you also plan for data sources.
If a KPI is based on a SharePoint list, you must plan for the list, including its properties. Often, KPI lists are based on business data lists that use columns that are linked to business data applications. The values for those columns are updated as the underlying data is updated. You must plan to register these applications in the Business Data Catalog and import the properties that will be used for KPIs.
SharePoint lists used by KPIs must also be created before you can create the corresponding KPIs. Include every list necessary for KPI deployment in your planning for each site in each site collection.
If a KPI is based on an Office Excel 2007 workbook, ensure that the correct workbooks exist to display meaningful information. Sometimes workbooks are poorly organized or missing information that could be used by KPIs, and this is an opportunity to improve them. Those improvements will help when viewing that same data in an Excel Web Access Web Part, or working directly within the Office Excel 2007 application window.
For data in a SQL Server 2005 Analysis Services cube, plan to include that data in a data connection library.
For SharePoint lists, Excel workbooks, and SQL Server 2005 Analysis Services cubes used as KPI sources, you should consider where the lists, workbooks, and data connection libraries reside. It is usually a good idea to store this content in the site where it is being used. If you are putting a KPI on the home page of the portal site, it makes sense to create a KPI list on the home page. If you are putting a KPI in a report in the Report Center site, it is a good idea to put the lists, workbooks, and data connection libraries for the KPIs in the KPI list, and the KPI list itself in the reports library. If you are putting a KPI in a personalization site, it helps to put the related data sources there. The following figure shows a KPI in relation to other data sources.
It is possible to use data sources stored in document libraries and data connection libraries of other sites, which encourages collaboration and the reuse of valuable KPI lists. However, during initial deployment, it is good to keep your information organized simply and logically. This also simplifies security planning, because you can assume that a site and its content are stored in the same place and not scattered throughout the site collection.
Manually entered values are typically used for testing or temporary purposes, so you will probably only use them in planning and initial deployment to test KPI functionality before you begin a full-scale deployment.
Regardless of the data source for each KPI, you must decide on an appropriate set of values to use when indicating performance. Think about how you will calculate a comparative value from the data source. Which columns of data will you use? Will you calculate a value from a total, an average, a maximum, a minimum, or by some other means?
By planning ahead, you can avoid delays when you realize that an Excel workbook, for example, does not contain the actual set of data that you want to display performance for in the KPI. Plan ahead, select different data sources if you realize the sources you initially select will not provide the information you need for useful KPIs, and then record the plan so that you can finish deployment as quickly and effectively as possible.
Use the Business data worksheet (http://go.microsoft.com/fwlink/?LinkID=798133&clcid=0x409) to record your KPI planning decisions.
KPIs are common features of reports in the Report Center site and other sites that contain report libraries. One of the three main types of reports is a KPI list page report. This report includes a KPI List Web Part to which you can add KPIs for a particular business process, along with a summary of the related processes and any related content and Web Parts.
When planning KPI list pages, focus on the key business processes for each site collection, and combine as many KPIs on each list as you can for related processes. Continue until you have KPIs planned for each business process related to the central purpose of the site collection. This produces a manageable number of KPI list pages, for which you can plan KPI lists and KPIs, in addition to the SharePoint lists, Excel workbooks, and SQL Server 2005 Analysis Services cubes used by each KPI.
You will also want to decide which KPI list pages are important enough to include in the home page of the Report Center site and which should be linked from the page.
You will also want to consider which KPIs work together in dashboards. For large site collections that serve a large number of business applications and business processes, you will want to consider whether to plan more than one Report Center page. For more information about reports, see Plan reports.
Dashboards, also known as multi-report summary pages, allow you to filter Web Parts at the page level so that every Web Part shows only filtered results. This can be useful for creating pages for monthly or weekly results, results for a team, or results filtered by several other criteria.
KPIs are often a key part of dashboards. KPIs cannot be connected to every kind of filter, but they can be connected to many of them. When deciding whether to include a KPI in a dashboard, consider how closely it relates to the other parts on the page. For more information about dashboards, see Plan dashboards and filters.
Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the KPIs, KPI lists, and data sources used for dashboard pages and other key sites that use KPIs.
KPIs tend to be more useful in reports and dashboards than in the personalization sites, personal sites, and the public profile page that make up each My Site. However, you might still want to add KPI Web Parts to these sites.
For personalization sites, which are built by using a current user filter Web Part that can be connected to Web Parts on the page, KPIs are not connected but show information across the group of people that uses the personalization site to supplement the Web Parts that are connected and filtered. On a personalization site for a call center team, a KPI List Web Part that shows customer satisfaction, average call time, and number of resolved issues for the entire team supplements an Excel Web Access Web Part personalized to display data for the specific customer service representative who is viewing the page.
You cannot filter a KPI Web Part directly by using the current user filter on a personalization site. The reason for this is that the data in a KPI is often not meaningful when it is calculated across a filtered subset of its original data. A Web Part that tracks the number of sales for the group and the number of sales for one person will produce widely different values, and the KPI can only evaluate against one of the sets of values. Therefore, filtering the KPI that way is not possible.
You can target KPIs so that they appear only in personalization sites when the current viewer is a member of the correct audience. This allows you to target the whole list of KPIs or each individual KPI in the list depending on the scope of the KPI, just as you target the items in any list. If the KPI is of interest only to some users, such as those in the same work group, you can target it to an audience defined to include only the users in the work group. Using the example of a sales team, you might only show the results in the New York sales office to associates in the New York office.
You can use the KPI List Web Part to display several status indicators within one Web Part, such as sales records across the last few quarters. You can also use a KPI that shows sales volume, total value of sales, and improvement compared to the previous quarter in one Web Part.
You might decide during planning to modify the personal site template to include one or more KPI Web Parts, perhaps connected to prepopulated lists. This might be worthwhile for KPIs that you want to display more prominently, even though users might remove the KPI from their personal sites later on.
KPIs are less useful on public profile pages, which show information about a person rather than business processes. Planning for initial deployment is probably not a good time to consider adding KPIs to the public profile.
Consider the KPIs for each personalization site to ensure that they reflect the purpose of the site and the overall site collection. If the site collection is a team site for a sales team, sales data KPIs in a personalization site are appropriate. If it is a site collection intended for collaboration across a larger organization, the KPI will have to be targeted if it is included at all. If it is a site for human resources information, which is not used by any group in the organization to meet its goals but instead simply provides policies and business applications, it is inappropriate to use a KPI.
Use the Site creation worksheet (http://go.microsoft.com/fwlink/?LinkId=73138&clcid=0x409) to record the KPIs, KPI lists, and data sources used in personalization sites and other personalized sites that use KPIs.