Essential Tech Reading: Review of "Rational Guide to Planning with ...PerformancePoint Server" by Downs and Barclay
Adrian Downes and Nick Barclay have written another excellent, even essential, PerformancePoint Server learning guide. If you've already completed "Rational Guide to Monitoring and Analytics with ...PerformancePoint" and want to quickly learn how to add the paradigm-shifting planning, budgeting and forecasting capabilities available from PPS Planning, check out my recent review of "The Rational Guide to Planning with... PerformancePoint Server 2007" by same authors, which deserves your consideration as a learning guide. Here's the link...
http://www.amazon.com/review/R2JKFWVZGGF0UJ/ref=cm_cr_rdp_perm
Performance Management, Business Intelligence and The Role of the New Performance Dashboard
INTRODUCTION
Business intelligence and performance management are related disciplines and technologies that, in combination, empower us to extract maximum insight from integrated data, use that insight to inform better business decisions, take appropriate direct action based on those decisions and, in fact, do all of the above as a matter of our normal work routine.
EXISTING STATE OF BUSINESS INTELLIGENCE
Business Intelligence may be aptly defined as a state – enabled by an optimum data architecture accessible via specific software – wherein business decision makers routinely enjoy fast, direct, user-friendly, continuous and role-appropriate access to a single version of the truth about actual business results, and their relation to standardized metrics, as a foundation for good business decisions. Activities for business intelligence users generally include monitoring data, analyzing it in detail or obtaining on-demand reports. Frequently, business intelligence data is organized multidimensionally -- the way we naturally think -- according to relevant criteria (dimensions) like people, things, products, geography and time.
In that regard, business intelligence represents close to an ideal state of knowledge capture from data. However, business intelligence applications usually do not, within their own sphere of functionality, support the initiation of any actions that may be taken based on decisions made from new insights.
“Performance Management” (PM), which is evolving from a combination of business intelligence and corporate financial planning disciplines, is defined by Wayne Eckerson of The Data Warehouse Institute as… “a series of organizational processes and applications designed to optimize the execution of business strategy”. “Execution” is a key word here and, in performance management, execution typically involves forecasting, planning and budgeting.
INSIGHTFUL ACTION: THE IDEAL STATE
Architecture and applications that blend Business Intelligence and Performance Management features can add high value by allowing now-enlightened decision makers to routinely take appropriate action on those decisions using automated, standardized, and collaborative workflows for contributing to, reviewing or approving the specific execution of forecasting, planning and budgeting activities, thereby “closing the loop” and initiating intended changes based on insight supported by hard facts. Budgeting, in particular, is the activity in most organizations, where plans resolve into changes in resources, tasking and goals.
TWO CHALLENGES
In practice, we often find that not all of the data needed for the desired analyses ever finds its way into a business intelligence application. On the one hand, some data -- which will provide the required real-time key performance indicators for performance management, may not arrive in the business intelligence application until its too late to be valuable. An example of this might be an airline's real-time data each day about late departures. Another reason for this is more generalized: Because of spreadsheets’ (a) continued popularity, (b) ease of use, (c) robust analytic capabilities, and (d) ease of sharing, some high value corporate data continues to remain in spreadsheets, with their traditional weaknesses in terms of version control, accuracy and security. In the past, this reality has amounted to a major compromise to BI’s promise of “a single version of the truth.”
On the performance management side, although some tasks, such as forecasting and "what if" analyses, are best performed using the available analytic muscle of a business intelligence application, other processes, especially more procedural processes like task assignments, progress notifications, draft submittals, reviews, edits, re-work and approvals, while perhaps based on that same business intelligence data, are inherently very different activities and should normally be performed using the most obvious tools. As is the case with business intelligence, the popular medium for these processes has been the informal, arcane combination of e-mails and, yes, more spreadsheets, with the resulting convenience, as well as the potential for unpredictability and error that this combination has traditionally offered.
ENTER PERFORMANCE DASHBOARDS
Performance dashboards are like other dashboards in that they provide busy people with relevent information at a glance. What makes performance dashboards unique is that they deliver business intelligence and/or performance management information and support the related workflows. A good performance dashboard will…
* Provide consumers with an appropriate combination of "at a glance" key performance indicators, scorecards, pivot tables and charts, as well as some in-depth, drill-down reports and advanced data visualizations,.
* Be virtually effortless to deploy to user workstations.
* Flawlessly orchestrate the integration of a wide variety of dissimilar data sources, including OLAP cubes, data warehouse tables, line-of-business databases (for real-time performance data), flat files, web-server lists, survey data, spreadsheets and other format, in order to serve as a final, crucial data integration point prior to user views. All needed data sources should be able to be seamlessly integrated as data sources, so that the end user experiences consistent multi-dimensionality and, of course, accuracy. As an example of flawless orchestration, various examples of time series information (eg. year-to-date, year-over-year, etc) that originate in dissimilar data sources must integrate transparently.
* Coexist with and, in fact, integrate closely with and orchestrate e-mails as the preferred vehicle for notifications related to performance management assignments, progress notifications, reviews and approvals.
* Support the actual performance management analysis work by managing the storage, security, role-based access, and version control over spreadsheet entries for forecasts, what-if analyses and, most importantly, the budgets themselves.
* Orchestrate these spreadsheets’ consumption of data from -- and secured write-back of new data to -- the business intelligence application / data warehouse, such that what-if analyses, forecasts and proposed budgets comfortably exist alongside actual results data in the data warehouse and/or OLAP without danger of losing actual data to inappropriate overwrites.
Performance dashboards that can do all of the above, especially the controlled orchestration of disparate sources and two-way data flows between the data warehouse and spreadsheets, are truly next-generation solutions that will assist in freeing up information workers to overcome organizational paralysis and close the insight-decision-action loop on a routine basis.
NEXT IN SERIES:
* Microsoft Office PerformancePoint Server 2007
* Detailed Feature Comparisons in Leading Performance Dashboards
Praise for "Rational Guide to M&A with ...PerformancePoint Server" by Barclay and Downes
http://www.amazon.com/review/R1RFLK2PF6PLT3/ref=cm_cr_rdp_perm
"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?
Getting BI Skills... To Land The Job... To Build On Those Skills... To Advance On The Job... To...
During a presentation I gave on SQL Analysis Services 2005 in January 2007 to the San Diego SQL Users Group ( www.sdsqlug.org ), one attendee asked me for my opinion on how to go about acquiring BI skills. I'm no guru, but as one who is a ways along the skills continuum, here is my take on just one aspect of this question, which is...
First Off, Exactly What Are The Core BI Technical Skills?
(1) Relational Database and SQL Language Fundamentals:
Although BI is certainly a departure from traditional / transactional RDBMS principles (eg. third normal form), it is still significantly based on, or at least built from, relational DB management systems' concepts. Additionally, most BI applications are built around large data sets, for which solid SQL language skills are essential. Add these two realities together and most will agree that BI is a place for interested database novices to progress towards, but not to start with. On the other hand, business people may continue growing their BI Analysis skills without necessarily spending much time in this topical area.
(2) Dimensional Modeling:
Designing the data warehouse (DW) or data mart (DM) is, I think, the theoretical foundation of BI. Once the business process of interest has been defined, we define the facts (aka measures), which are the (usually numeric) values to be analyzed according to dimensional criteria (to be defined shortly). Examples of facts in a Sales data mart may include quantity of units sold, unit sales price, and unit cost. We then define dimensions and their attributes. To extend the example, a Sales data mart may include a product dimension with attributes of Product ID, Product Name, as well as hierarchic values such as Product Sub-Category and Product Category. A third dimension may be the Date dimension, which may include analytically intuitive attributes such as Date, Day of Week, Holiday, Month, Quarter and Year. Importantly, although an overriding goal of dimensional modeling is to establish a highly-intuitive, refreshingly simple design, the potential potholes and bends in the road are many, and thus Dimensional Modeling requires study. Fortunately, it's fun. Dimensional modeling calls for, and rewards, experience with not only database design but the business subject area itself.
(3) Extraction, Transformation and Loading (ETL):
Once the DW's dimensional design is complete, the hard work of gathering data from multiple sources, cleansing it and transforming it's data types, granularities and/or aggregations, loading it into the DW, and the scheduling much of that to iterate, begins. Many consider ETL to be the 800 Pound gorilla in the DW project planning room. It's specialized work performed by experts, it's difficulty may be under-appreciated by key business-side stakeholders who wonder "How hard could it be...?", and the likelihood of it's on-time, on-budget successful delivery is obviously vulnerable to even subtle changes in project requirements. In my opinion, ETL may be one role in the team cannot afford for the individual to just learn it as she goes.
Although they are often considered as an advanced database skill set, people with the desire and the dedication to master this specialty, will enjoy a strong demand for their work.
(4) Analytics / OLAP Cube Development:
From my viewpoint, this is the most fun part. The only part more fun is showing the analyst / BI user how to go about "finding the money" and then being around for the high fives when she finds really big bucks.
In building a high-functioning OLAP cube on top of the DW as it's data source, we are creating a truly multi-dimensional on-screen data browsing structure with fast (ideally "speed of thought" query performance, rich semantics, calculated fields, key performance indicators (KPI's), pre-calculated aggregates, a realistic variety of hierarchic default drill-paths and a strong foundation for the inevitable collection of hard-copy reports. MS Excel is, of course, a popular OLAP front-end browser. With a sufficient budget, the OLAP application will also benefit greatly from a rich-featured, browser-based, zero-client-footprint, multi-user front-end OLAP web server (that was a mouthful), such as is provided by Applix, Business Objects, Cognos, Hyperion, MicroStrategy, Panorama, ProClarity, Strategy Companion, SAS and others. The user-browsing capabilities of some of these platforms is extensive, and so the work of configuration, customization, user-training and administration with these platforms is no trivial matter.
For analytical business-specialist types like myself, the analytics / OLAP development phase is uniquely exciting insofar as it delves deep into the actual analyses that will be performed and enables them for users.
(5) Data Mining:
I will only deal with this advanced area briefly. Data mining starts, in a sense, where OLAP stops. Whereas OLAP enables analyses according to known factors (dimensions) in order to determine "what did happen and why?", data mining allows the system to detect patterns from "test data", and then apply those patterns to new data sets and thereby furnish potentially insightful answers to questions no user thought to ask. In that context, data mining is often used for predictive analyses of "...in light of all of our data... what will happen?"
Data Mining practitioners, whose expertise is usually built atop a foundation of statistical analysis skills, may often be relatively uninvolved in database engineering per se, but rather are advanced power-user specialists who can generate unprecedented insight from a database. As such, data mining is among the hottest of hot database skills.
(6) Report Development:
Although the aforementioned OLAP on-screen analytics may tend to reduce the sheer number of semi-redundant reports that IT is asked to generate, is does not signal the end of the need for reports per se. Reports retain the role as the hard evidence of information queried and, hopefully, valuable knowledge gained. In my opinion, a reasonably small collection of carefully conceived, uniquely insightful OLAP-based reports, many of which should include an extensive set of user input parameters, are crucial BI assets. Ideally, OLAP-browsing analysts should be able to drill directly and seamlessly from on-screen browsing into a variety of these on-screen reports with their input parameters automatically pre-selected according to the users currently OLAP browsing slice-and-dice positioning. As the analyst successively "finds the money", she should be able not only to bookmark those OLAP browsing locations, but also document each of them with appropriately filtered hard-copy reports. Lastly, these report hard-copies must include automatic documentation (ie. in the report footer) of all input parameters settings, so that the report can be duplicated later.
Personally, I view report development skills as an excellent compliment to RDBMS fundamentals and SQL language skills for novices interested in BI.
(7) Project Lifecycle Process Methodologies:
These competencies, which span skills that are technical, analytical, organizational and interpersonal, may be the single most crucial factor in BI success in light of the sheer complexity of BI development. For an article on the mainstream "Data Warehouse Lifecycle, click on... http://www.businessintelligence.com/ex/asp/code.147/xe/article.htm
For an intriguing book on the "Business Intelligence Lifecycle", click on...
http://www.amazon.com/gp/product/0201784203/ref=wl_it_dp/104-5823156-6544767?ie=UTF8&coliid=I3JFAKDAO7BDG0&colid=266K0ULFTUTZY. Of, if that link breaks, visit Amazon.com and search for the book entitled "Business Intelligence Roadmap" (ISBN-10 0201784203), by Moss and Atre. What's intriguing? They tout Extreme Programming (XP) as an effective BI development process. Although I have not been exposed to XP usage in BI, I must concede that anything that can reliably accelerate progress amid a high degree of complexity needs careful consideration.
In my view, expertise with software lifecycle methods simply comes with experience. Having said that, the topic makes for enlightening, and occasionally enjoyable, reading.
Let's close this blog entry with some open questions...
Question #1: For BI newcomers from a variety of backgrounds, which of the above skills are reasonable to seek and in perhaps what sequence from a career-development standpoint?
Question #2: Under what circumstances can any, or many, of the above roles be wisely placed on a single individual, and what risks do these choices create?
Question #3: To what extent is Agile or Extreme Programming (XP) an appropriate methodology for BI?
What are your thoughts?
...
Questions to Answer When Considering a New BI Initiative
If your organization is considering a BI initiative, but unsure of whether to pull the trigger, rate your answers to the following open questions, with "0" meaning "non-existent" and "10" meaning "extremely high." High cumulative points indicates that BI holds good potential value for you.
(1) To what extent is our information technology a strategic asset and not just a cost of doing business?
(2) To what extent does our success depend on extracting knowledge from a large amount of reasonably complex data?
(3) Just how much existing operational data (GigaBytes, TeraBytes) do we have and how quickly is it growing?
(4) How complex is our operational data? (The more complex it is, the more BI can help us see through it).
(5) Among our existing resources, such as reports, dashboards, spreadsheets, or documents, to what extent are they, and will they remain, inadequate as our foundation for extracting insight from our data?
(6) Do we have an adequate IT infrastructure (staff and systems) to build BI internally?
(7) How ready are we to support outsourced technical work?
(8) Do we have adequate infrastructure to provide ongoing technical support for a delivered BI solution?
(9) How much buy-in can we gain from potential user-stakeholders who currently make decisions without BI?