"KPI Street Cred" ...You heard it here first!
Why should you care about who "owns" the KPI's in your organization? If you're into Business Intelligence, you probably care how well the KPI's are received and respected. From a technology perspective, the issue of ownership also says a lot about how the KPI's should be managed and where authoritatively stored, perhaps in the context of a Business Intelligence or Performance Management application By "ownership", by the way, I mean a sufficient amount of the actual, or at least perceived, control over something, without which a person may not feel fully responsible when things go well, and will almost certainly try to avoid blame when things don't. On that note, let's consider the pros and cons of two opposing perspectives. If you are involved in BI, you will care!
Technology-Centric Perspective:
Although KPI "target result values" should be delivered to the technology side by non-IT stakeholders, the KPI rules themselves should be embedded within the BI application, so that any application pulling data from it can enjoy the KPIs. A common way to do this is to use use scheduled data extraction, transformation and loading processes to merge the various target result values from their own data source into fields alongside the actuals and then create KPI's within the OLAP cube environment. One unfortunate business result of this approach is that the "ownership", or at a minimum, the perceived ownership, of the each individual KPI has now essentially been split at least three ways - between the business stakeholders, the ETL developer and the OLAP application developer (report developer, etc.) As such, not any one of the 3+ parties (for each individual KPI) truly perceives that she owns it, and each can point the finger at others when results are questioned. Such questioning, whether truly justified or not, tends to seriously limit credibility in business units.
"KPI Street Cred" anyone? ...You heard it here first!
Anyhow, one big advantage of this approach is that KPI's are now available to all users and applications downstream from the OLAP cube. Another might be that, in a specific organization, perhaps due to lack of available time or buy-in on the business side, nobody exists to take ownership away from IT.
Business-Centric Perspective:
Although, admittedly, actual business results should be stored in the data warehouse and/or OLAP cube, the KPI rules themselves should be wholly owned, and controlled by, by the respective business stakeholders, because their people will be evaluated or compensated with respect to how well their actual performance stacks up to targets. So, the KPI's usage in a Business Intelligence or Performance Management application must not obscure this ownership. To support this approach, we would have all of the KPI target metrics stored in a single, standardized, well-secured spreadsheet, controlled by a sufficiently objective, high-level authority on the business side. This spreadsheet would include all metrics for each KPI, including type ("increasing is better vs. decreasing is better" vs "closest to target is better"), theoretical maximums (where applicable), minimums, any rules about appropriate visual image (stoplights, arrows), and how a child KPI mathematically roles up, in relation to it's sibliings, to a parent KPI.
If we agree so far that this perspective improves the "ownership" issue, we can now ask ourselves, "What must occur — in addition to the non-trivial matter of serious buy-in from the business side — in order to make this business-side spreadsheet approach, which is justifiably scary to IT people, successful?" We will need a Performance Dashboard development environment, like MS PerformancePoint Server's (PPS) Dashboard Designer, with two characteristics: First off, for each KPI it must have the sophistication to accurately, consistently merge actuals results from the data warehouse and/or cube with target results from the KPI spreadsheet. Secondly, in keeping with the business-side ownership philosophy, it should be sufficiently user-friendly, as is PerformancePoint, so that specific analysts working for the business-side (not just BI developers) can, with minimal training, do the actual design work of completing the design of the KPIs themselves and perhaps also placing them into scorecards in the dashboard, too. Any downside to this approach? Perhaps only that this represents an increased comitment to the Performance Dashboard platform as the source of merged KPIs, rather than the cube itself. However, perhaps the greatest challenge is the cultural/process shift wherein the business-side now controls data that directly feeds into an enterprise application.
Being a bit of a paradigm changer myself, I'm in favor of the Business Perspective, and I encourage IT people to consider the benefit when the business side owns more of their own data.
What are your thoughts?
Good post - right to the point and easy to understand. We use a construct that is essentially a logical representation of the business (sort of a domain-level model with some attribution that makes sense to the client) as a basis for data management (we call it a Topology). Have you done any associations of KPI's at the business level for data management? I think that KPI's can be "rolled up" from a management perspective so that an enterprise board can govern them. Rollups, as you rightly point out, happen then at the "dashboard level" up to this domain level. Whaddya think?
thanks.
Ernst
Reply to this
Interesting comments, Ernst. If you can clarify your comments' usage of the terms "domain-level" and "topology" in BI terms, I will reply to that more specifically.
Meanwhile, yes, we've rolled up sets of KPI's into single "critical success factors" (aka "objectives), as part of a board-level balanced scorecard. We've also done the same for manager and worker-level KPI collection's and their relationship to a single roll-up objective. As you may know, the higher-level (eg. board vs. worker) the scorecard, the more challenging, yet more crucial, it becomes to identify KPI's that are truly actionable. Just in case you want more on that topic, I recommend the book, "Key Performance Indicators..." by David Parmenter. Click here to review it on Amazon
I have found that MS PerformancePoint Server (M&A module) provides a sufficiently flexible set of KPI target metrics (min, max, % of target, higher-is-better, lower-is-better, closer-to-target-is better), and KPI-rollup (to objectives) algorithms (raw average, weighted average, worst-child, "show-all"), and with PerformancePoint, that can be accomplished downstream from an OLAP cube, thus reducing the resource constraint associated with MDX hand-scripting of KPIs. In PPS, KPI's are built in a "scorecard" object, which is then dropped onto, and configured for, a deployable dashboard.
Thanks again for your comments, Ernst.
-- Daniel
Reply to this