| Eric's profileEric's spaceBlogLists | Help |
Eric's space |
|||||
|
April 06 Selecting the right measure and chart type - part 1With a little practice, it's quite easy to create professional-looking charts and graphs using the BI tool of your choice. It's another matter entirely, however, to create a chart that utilizes proper design principles and answers the business questions relevant to the information consumer. In this post I'll walk you through a chart-design scenario, highlighting various decision points and considerations at each step. For this example, let's say we have a request to create one or more visualizations around monthly sales, including a breakdown by salesperson. The first visualization we might use isn't a chart at all, rather it is tabular data with graphical indicators. This is better known as a scorecard, and in this case, we'll create a scorecard with a Sales ($) KPI. KPI stands for Key Performance Indicator, and within the context of a BI scorecard it is simply a measure or metric with a defined target or goal value. (A more formal definition of a KPI exists in the business strategy domain, in which a KPI represents the measurement of particular strategic business objective or initiative.) Our very basic scorecard with the single Sales ($) KPI might look like this: Figure 1: Sales Scorecard, Sales KPI So what is this scorecard telling us? First, let's examine the layout and content of the scorecard to better understand that data we're presenting. We have the Sales ($) KPI with six numeric values. The first column is "Actual." This is the actual sales ($) value for the month of Dec-09. That is followed by a target (remember our definition of KPI above), in this case, "Plan." This is our sales target for the month. Next we have the variance of actual and plan as a percentage. Here is where we introduce the visual stoplight indicator which communicates KPI performance at-a-glance. We've established thresholds of performance for this target (>100% is on target (green), >90% is slightly off target (yellow) and <90% is off target (green)). Next we have the measure value for "Last Yr" which represents performance for this period last year. Finally, we have "Last Yr Var %" which represents current performance compared to performance last year as a percentage. What insight can be gained from the data in the scorecard? The up arrow indicator draws our attention to our performance versus last year, which is good (up 6%), and the yellow indicator draws our attention to performance versus plan, where we're missing (only 90% of target). What's the next question that our information consumer might ask? Probably something like, "which salesperson had a particularly good/bad month?" or "which products were strong/week this month?" We'll answer that question with one or more charts... Let's focus on the salesperson perspective. So we know that our total sales for the month were $90,000. How was that distributed across our team of five salespeople? Here's a chart that answers that question: Figure 2: Sales by Salesperson Displaying the data graphically, sorted from highest to lowest, illustrates very quickly our top and bottom performers as well as a sense of the variation across the team. Can we enhance this chart to to provide additional insight? Looking back at our scorecard example, we know that adding context often enhances insight. Look at this next chart. Figure 3: Sales and Plan by Salesperson We've added the sales plan measure to enable visual comparison of each salesperson's actual to plan performance. We've preserved the insight around top/bottom performers, the variation/range of data, while adding context with the plan measure to facilitate yet another level of insight. It's useful to know that Mary was the top salesperson for the month, but even more useful to know that she exceeded her plan. On the other hand, Rosa was the bottom salesperson, and she missed her plan. With this example we've illustrated how basic charts, simply designed, reveal multiple insights in a common business scenario. In the next post, we'll look at charting some calculated measures to further enhance the message in the data.... February 25 Developing a DW/BI StrategyThis week I'm attending the TDWI World Conference in Las Vegas, NV. In this post I'll share some of my key takeaways from the Tuesday morning session I attended on the topic of developing a DW/BI Strategy. The course was led by instructor, Michael L. Gonzales, from Claraview. Here's the course abstract: Here are some highlights: Terminology The terms 'data warehousing' and 'business intelligence' are gradually moving toward the term 'information management.' Frankly, I like the latter better because it describes the domain more broadly, highlighting both the problem and solution we're addressing with DW/BI technology solutions. Related to the above, the term 'information repository' is gaining popularity over Data Warehouse, Data Mart, etc. With regard to moving data from point A to point B, in DW/BI solutions the term we frequently use is 'ETL' (Extract, Transform, Load) which explicitly describes the 3-step process of moving data from a data source (operational system database, spreadsheet, etc.) to a different, target data source (data warehouse). The instructor used the term 'data propagation' which addresses the same issue (moving data) but more broadly encompasses additional data movement methods (messaging, etc.). Concepts BI is broader than DW. Often times this is described the other way around due to the historical emergence of DW followed by BI. The instructor's point was that BI is about meeting a business need for making information accessible and DW is only one of many possible data sources to achieve that objective. Write the BI strategy for the project sponsor. The intended audience of the strategy document is the project sponsor. It should be written so that both business and technical readers can understand it. Technical details that are absolutely required may be moved to the appendix and referenced as such. Additional technical details are addressed in other documents with other team members in mind (technical architects, data modelers, data developers). Draw a line between strategy definition and phase 1 implementation. Be careful not to blend the strategy exercise with a phase 1 implementation project. While these should/will happen in sequence, the nature and focus of each effort is very different. Re-shuffle your requirements deck twice a year. Planning an entire year's worth of development does not provide enough agility to meet changing business needs. Develop DW/BI solutions iteratively. Analytic applications are evolutionary in nature and require an iterative development approach. In traditional software development (automating a business process) the task of explicitly and comprehensively defining requirements up front is a bit easier (but still probably doomed to failure in my opinion), whereas with BI solutions, often times the users can't articulate what they need until they start interacting with the data. This activity leads to additional understanding and the identification of new requirements. Also, whereas a particular business process may remain largely static, the measures with which we measure business performance often change (as we measure something, it often improves), requiring change in the DW/BI solution. BI strategy must support the business strategy. This one sounds simple, but I bet most BI projects don't explicitly articulate their relationship and impact to the organization's business strategy Common business strategies include a) improve quality b) improve efficiency/reduce expenses c) grow revenue or market share. Explicitly link your BI strategy to the business strategy adopted by your organization. Deliver on the promise of BI. The value proposition of BI is often presented as a a solution to improve decision-making leading to improved business performance. Most BI solutions fall short of delivering on this value proposition because while they directly address foundational elements of aggregating data and presenting information, they don't directly address the specific actions and outcomes that result. You need to build processes/methods/approaches to facilitate this 'crossing of the chasm' to achieve real business value. Consider a 'big beast and mini-me' approach. Create a smaller version of your DW by extracting a stratified statistical sample from your existing DW. Use this to test new theories before applying them at the enterprise level. It's quicker, cheaper, and less risky to use this approach. As you identify something in your smaller sand-box environment, you can test it on the DW for validation before implementing it in production. This is particularly useful for data mining efforts. Utilize Proof-of-Concept servers to augment your production environment. Having a set of POC servers provides two benefits - 1) it allows you to test new concepts in a clean, predictable environment, and 2) it functions as an enterprise pressure-valve in the case when a high priority business need requires a 'quick fix' which would be too risky to attempt in the production environment. Summary I quite liked this course - the instructor had many interesting experiences to bring the material to life. Also, we left with a nice template for documenting BI strategy, as well as links to a number of additional resources. Stay tuned for a brain dump of my next course.... September 26 From Insight to ActionI found an interesting article this morning on User-Centric Dashboard Design. The author describes his approach this way: "The user-centric approach requires a keen understanding of the user’s needs and the ability to design around them. This can be reduced to two fundamental questions:
I like it. Simple, but effective. Focusing on user needs helps to ensure that we build the right solution. Too often, we (those of us in the business of designing and building Business Intelligence solutions) focus on the details of the data at the expense of user needs. It's easier to build a solution by ignoring users and instead focusing on the data. "Show me your data and I'll build you a solution." After all, those pesky users don't really know what they want, and when they finally tell us, they'll just change their mind later, right? To mitigate that risk, we often include everything we can think of in the solution and hope something sticks. Not very efficient, huh? Taking the approach to focus on user needs takes some additional investment up front, but the payoff is in a more focused data development effort, and more satisfied users who are engaged throughout the development process and beyond. At BlueGranite, we take the user-centric dashboard design concept one step further. We talk with our customers about the process of moving "from insight to action." It starts with an effective dashboard design that facilitates understanding, and continues with the support structures of a collaboration tool which allows individuals create and implement a plan of action. Once you've gained valuable insight into the root cause of your business performance, what are you going to do about it? What are the possible courses of action? Once you've made a decision, how do you implement the change? Who needs to be informed? Who should be on the team to implement the change? How will the change initiative be measured? These are just a few of the many considerations one encounters when "completing the loop" in moving from insight to action. The recipe for success is information plus collaboration; your BI solution should do both. September 05 Introducing the Microsoft Business Intelligence "Stack"There are a number of vendors and toolsets available to the IT professional tasked with creating BI applications for organizations. At BlueGranite, we've developed expertise in delivering solutions with the Microsoft BI platform or "stack." We find the Microsoft tools to be both powerful and easy-to-use, and the price to value equation is very compelling for most organizations. The guys over at Microsoft BI Blog linked to the latest Gartner report which positions Microsoft in the leaders quadrant, ahead of many of the other major vendors such as IBM/Cognos, and SAP/Business Objects, specifically in the "ability to execute" area. The graphic below illustrates the primary components in the Microsoft stack. As you can see, it includes three widely-adopted Microsoft Server technologies (SharePoint, Office, and SQL Server), with the addition of the new flagship BI product, PerformancePoint. The Microsoft BI public site explains the capabilities of each of these products in more detail. The purpose of presenting this overview is to provide a frame of reference for subsequent posts where I'll explore the capabilities of these products in producing effective data visualizations. September 03 A review of Xcelsius Present 2008 (Business Objects)Check out this scathing review from Stephen Few of the new Business Objects product, Xcelsius Present 2008...http://www.perceptualedge.com/blog/?p=266
|
|
|||
|
|