This is a guest post by Myles Arnott from Clarity Consultancy Services – UK.
- Part 1: Introduction & overview
- Part 2: Dynamic Charts
- Part 3: VBA behind the Dynamic Dashboard a simple example
- Part 4: Pulling it all together
Part 1 of dynamic dashboard tutorial introduced the purpose and general functionality of the model. In this post we are going to look at the first 4 charts and see how they work.
Chart 1 and Chart 2 : Flexible pie charts
These are Dynamic pie charts with the option to select the KPI, period and product/salesperson to be analyzed. As both pie charts use the same functionality I will focus on the chart in CH1.
The key to the flexibility of these otherwise simple pie charts is taking a little time to set up the chart source data.
1) Selection criteria
We want to be able to select data by product group and month and be able to choose the key performance indicator to report. We also want to be able to report on all product groups and for all periods.
To ensure that only valid criteria are selected, each selection is driven from a data validation list driven from a named range:
2) The formula
The main formula being used is the SUMIFS(Sum range, Criteria range, criteria,…). This was a new formula in 2007 and provides a simpler solution to the SUMPRODUCT() formula.
So the formula in cell D24 in CH1 is:
=SUMIFS(INDIRECT($C$21),Sales_Per,B24,Product,$C$19,Period,$C$20)
Right, lets break it down for you:
Sum range
To create flexibility around the values returned I have used the INDIRECT formula to reference a named range. The named ranges are Count, Total_sales KPI_1 and Total_GP. I have then referenced these three named ranges within the data validation list.
Criteria range 1 and criteria 1
This matches the sales person in B24 against the list of sales people (named range Sales_Per) in the data tab.
Criteria range 2 and criteria 2
This matches the product in C19 against the list of products (named range Product) in the data tab.
Criteria range 3 and criteria 3
This matches the period in C20 against the list of periods (named range Period) in the data tab.
The result of bringing all of this together is that the value returned is:
- The value range as defined in C21
- The sales person as defined in B24
- The product as defined in C19
- The period as defined in C20
3) The final step – Dealing with “All”
The final element to enable the fully flexibility is to allow “all” to be selected for product and period. This gives you four options:
- Product and period specified
- Product specified, all periods
- All products, period specified
- All products and all periods
To manage this I have created a column for each option with a variation of the formula defined above. Finally I used a column as source data for the chart which pulls though the relevant information based on the selections made. They look like this:
I leave the interpretation of the actual formulas to you.
CH3 and CH4 Flexible line charts
These are dynamic line charts with the option to select the KPI, period and product/salesperson to be analyzed. As both line charts use the same functionality I will focus on the chart in CH3.
1) Selection criteria
This uses the same functionality as used in the pie chart illustration.
2) The formula
Once again the basic formula is the same as in the pie chart illustration.
The additional step is to allow flexibility around the period to display for the trend. This is achieved by selecting a period from a validation list. The following periods are then looked up from the validation list using HLOOKUP and MATCH. First take a look at how it works:
Now the formula is:
=HLOOKUP("YTD",Period_List,MATCH($C$23,Period_List2,0)+2,FALSE)
How this formula works?
C23 contains the first cell from which starting month can be changed. Based on that, we need to increment the month value for subsequent columns by 1, 2 and 3. The above is the formula for first such month. If you look at the downloaded file carefully, you will know why this works. 🙂
3) The final step – Dealing with “All”
As with the pie charts illustration the final step is to enable the user to select all. As the functionality as very similar to that used in the pie charts I will allow you to work through how it works.
Creating other Dynamic Charts in the Dashboard:
Links for how to create the other charts in this report can be found below:
- Boxcharts [Link]
- Scrolling report [Link]
- Competitor analysis [Link]
- Use of camera tool [Link]
- In cell microcharts [Link]
What Next?
We now know how to create the charts for the Dynamic Dashboard. Next week we will look at Part 3 VBA behind the Dynamic Dashboard, by studying a simple example.
Download the complete dashboard
Go ahead and download the dashboard excel file. The dynamic dashboard can be downloaded here [mirror, ZIP Version]
It works on Excel 2007 and above. You need to enable macros and links to make it work.
Added by PHD:
Myles has taken various important concepts like Microcharts, form controls, macros, camera snapshot, formulas etc and combined all these to create a truly outstanding dashboard. I am honored to feature his ideas and implementation here on PHD. I have learned several valuable tricks while exploring his dashboard. I am sure you would too.
If you like this tutorial please say thanks to Myles.
Related Material & Resources
- Excel Dynamic Charts – Tutorials, Examples and Demos
- Excel Dashboards – Tutorials & Templates Section of PHD
- 6 Part Tutorial on Making KPI Dashboards in Excel
This is a guest post by Myles Arnott from Clarity Consultancy Services – UK.
One Response to “SQL vs. Power Query – The Ultimate Comparison”
Enjoyed your SQL / Power Query podcast (A LOT). I've used SQL a little longer than Chandoo. Power Query not so much.
Today I still use SQL & VBA for my "go to" applications. While I don't pull billions of rows, I do pull millions. I agree with Chandoo about Power Query (PQ) lack of performance. I've tried to benchmark PQ to SQL and I find that a well written SQL will work much faster. Like mentioned in the podcast, my similar conclusion is that SQL is doing the filtering on the server while PQ is pulling data into the local computer and then filtering the data. I've heard about PQ query folding but I still prefer SQL.
My typical excel application will use SQL to pull data from an Enterprise DB. I load data into Structured Tables and/or Excel Power Pivot (especially if there's lot of data).
I like to have a Control Worksheet to enter parameters, display error messages and have user buttons to execute VBA. I use VBA to build/edit parameters used in the SQL. Sometimes I use parameter-based SQL. Sometimes I create a custom SQL String in a hidden worksheet that I then pull into VBA code (these may build a string of comma separated values that's used with a SQL include). Another SQL trick I like to do is tag my data with a YY-MM, YY-QTR, or YY-Week field constructed form a Transaction Date.
In an application, I like to create a dashboard(s) that may contain hyperlinks that allow the end-user to drill into data. Sometimes the hyperlink will point to worksheet and sometimes to a supporting workbook. In some cases, I use a double click VBA Macro that will pull additional data and direct the user to a supplemental worksheet or pivot table.
In recent years I like Dynamic Formulas & Lambda Functions. I find this preferable to pivot tales and slicers. I like to use a Lambda in conjunction with a cube formula to pull data from a power pivot data model. I.E. a Lambda using a cube formula to aggregate Accounting Data by a general ledger account and financial period. Rather than present info in a power pivot table, you can use this combination to easily build financial reports in a format that's familiar to Accounting Professionals.
One thing that PQ does very well is consolidating data from separate files. In the old days this was always a pain.
I've found that using SQL can be very trying (even for someone with experience). It's largely an iterative process. Start simple then use Xlookup (old days Match/Index). Once you get the relationships correct you can then use SQL joins to construct a well behaved SQL statement.
Most professional enterprise systems offer a schema that's very valuable for constructing SQL statements. For any given enterprise system there's often a community of users that will share SQL. I.E. MS Great Plains was a great source (but I haven't used them in years).
Hope this long reply has value - keep up the good work.