This article about how to design dashboard for 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.
Step One: Identify the Roles of Your Target Audience
we've embraced CRM fully, so I have users from many different roles in the tool every single day: the Executive Team, Sales, Marketing, Customer Support, Account Management, Partner Management, Field Services, Project Management, Manufacturing, Software Engineering, Hardware Engineering, Technical Documentation, and Product Training.
Phew! That's a lot of different user groups!
For each department, I assigned a Data Owner -- usually the department/division manager, or someone they specifically assigned to work with me. Next, I had a group meeting with all of the data owners to outline the project objectives. I then scheduled follow-up one-on-one meetings with each of them individually.
Step Two: Define Key Result Areas for each Role
At the 1:1 meetings, I asked each Data Owner what their Key Result Areas (KRA) were -- what were they hired to accomplish?
Each job can be broken down into about five to seven key result areas, seldom more. These are the results that you absolutely, positively have to get to fulfill your responsibilities and make your maximum contribution to your organization. Your failure to perform in a critical result area of your work can lead to failure at your job. There is essential knowledge and skill that you must have for your job. These demands are constantly changing. There are core competencies that you have developed that make it possible for you to do your job in the first place. But there are always key results that are central to your work and which determine your success or failure in your job.
A key result area is defined as something for which you are completely responsible. This means that if you don't do it, it doesn't get done. A key result area is an activity that is under your control. It is an output of your work that becomes an input or a contributing factor to the work of others.
With Dashboards focused around KRA, business unit managers would be able to see, at a glance, how their teams were performing. Each Role / Dashboard Owner would see where their team excelled and what areas needed more attention. The goal was to create Dashboards that influenced process changes within the organization.
No comments:
Post a Comment