Ok, I’ll admit it: I created a monster. This post is my confessional, and also my pledge to atone.
Very early in our implementation of Salesforce.com, I wanted to show the power of Dashboards to my users. I downloaded the AppExchange Dashboard Pack 1.0. The application is free, and installs all of the many dashboards published by Salesforce Labs. The package had dashboards for every conceivable use: lead flow, marketing campaign metrics, sales forecasting, support KPI, sales / support rep performance tracking, document tab tracking, user adoption, data quality analytics … everything.
I downloaded the app, did a little tweaking (very little), and then published the dashboards to my users. When Summer’08 Release gave us the ability to email dashboards (as an HTML page) directly to users, I enabled that functionality for a few key managers and user groups, too.
Soon after, I saw copies of dashboards distributed at various meetings and screenshots of dashboard components included in PowerPoint presentations. Managers and executives looked forward to their daily, weekly and/or monthly Dashboard emails, and talked animatedly about them in the halls or at company meetings. I felt good.
Yet something was wrong. I couldn’t quite place my finger on what it was, but the monster was there, elusive. The users asked for more dashboards, more pretty graphs, charts, tables, and I appeased them. Today, we have more than 50 different dashboards and hundreds of reports feeding those dashboards. It's an absolute glut of information. And this monster I created now has a name: Data Admiration.
They come to the CRM tool, very excited about the volumes of data and information captured in our Salesforce Dashboards. They drink deep from the kool-aid. But none of these dashboards seem to drive any real change in the organization. Why not?
Reflecting on that question during my morning commute, I realized it's not the people, it's not the tool ... it's the dashboards. Those original dashboards that I pulled down from the AppExchange were developed as a proof-of-concept, a way of showing report and dashboard writers all of the graphical components and different techniques for using them. They were a learning tool, but I had implemented them as a business solution. And that’s the root of the problem. I have dashboards, but no real business intelligence architected behind them. The dashboards are colorful, they certainly detail a ton of information, but they aren’t oriented around the specific business intelligence needs of my user communities.
Understanding a problem is the first step in dealing with it! I chatted about the problem with the Big Cheese, and got the green light to focus on a complete overhaul of our existing dashboards. In the next few posts, I’ll walk through the process of this Great Dashboard Clean-up Project. Stay tuned!
How about you? How did you implement your Salesforce Dashboards? Are they telling you everything you need to know about your business / organization? We’d love to hear your comments!
The way I was taught, and the way I now do a new Salesforce.com implementation works well and your post validates my method, I think.
ReplyDelete- Disable or delete all dummy data, reports, dashboards.
- Perfect (or at least get functional) the tools using our own test data.
- Review reporting requirements and confirm that the system will support getting that data out.
- Setup views
- Go-Live - use real data, start using the system
- Tweak the views and begin to create reports
- Refine the reports
- Begin to build dashboards.
The critical piece is that reporting and dashboards come last. If the organization is cool with riding a couple weeks without over-engineered dashboards and reports, they will be better for it. Too many times the real data doesn't support the reporting and unwinding reports and dashboards can be a pain.
There may be requirements to have reporting done right out of the gates, but through some nice views, reporting can usually be delayed.
Good luck with your dashboard cleanup project. I'll be interested to hear how it goes.
I agree with Rp. Dashboards do seem to naturally progress last. I also envy your success with dashboard adoption, but I am thankful for the perspective that this post offers. It helps me not to be so discouraged that I am not generating that kind of Data Admiration.
ReplyDeleteCan't wait to hear what else you have to share.
I'm not really in to reports and dashboards, but I'd just like to share some horrifying numbers with you: Before our large cleanup project started 6 months ago we had roughly 6000 reports feeding little over 1000 dashboards, all thrown out in folders without any naming convention of any kind.
ReplyDeleteNow we're a bit better off, especially because the folders have been organized by area and we have a central team handling everything that has to do with reports.
JP, didn't mean to talk down on your numbers, but felt I had to share. Good luck cleaning!
JP, I found this very insightful and timely. At Juice Analytics, we've recently been having some pretty in depth discussions about the right information to display on a sales dashboard. We've done a bit of investigating to see what others have done in this area and have found the available examples to be discouragingly inadequate for helping sales and marketing teams actually perform better. As you point out, there's lots of data, but the available _information_ upon which to drive change is thin. It's the quality and focus that makes the big impact - and in many cases, "less is more", so to speak.
ReplyDeleteAs we've gone through our process (we're focussing on the sales management) I think there are a few key points to keep in mind:
* Deal progress within a stage is fundamentally difficult to quantitatively measure, but it probably the single most important factor to revenue predictability. Qualitative indicators work just fine in cases like this.
* Any information that you show needs to lead to some sort of action. And let's face it, for a sales team that's getting "dollars in the door." If you don't focus on driving deal closure, you'll end up just where you are now, with no real organizational change. This is what I call the "so what??" factor. When folks tell me "we have 23 deals in the negotiation stage" my response is "So what? What do I _do_ to make that better."
* The visual layout is as important as the data for making the information digestible by the users. As the eye moves through the display does it tell a story about how the deals are heading to close?
I'd be curious to hear some of the hurdles you're clearing as you go through your thought process in this area, so feel free to drop me a line at ken at juiceanalytics dot com if you're willing to share. And if not, I anxiously await your next post!
Thanks in advance!
I missed this post JP. Your readers might find some of the metrics outlined in this series to be useful. The focus is on sales pipeline, people, and process analytics.
ReplyDeleteSales Analytics to Optimize the Sales Process