Yesterday I was contacted by a large car manufacturing company asking how to approach the building of dashboards and how to get the ‘right’ requirements. They asked if ASAP was the best methodology for this work. The answer is ‘not normally’. In this blog I will provide a real example of a customer dashboard project that I am working on in California and show how Rapid Application Development (RAD) is often a better alternative.
The First Step – Data Scope
First step is to examine the data fields available. There is no point in creating pie-in-the-sky dashboards that are not tied to reality.
Last fall, I was executing a brainstorming session in Singapore for the Asian operation of a large company. The first thing we did was providing our User Acceptance Team (UAT) a list of available fields that was considered ‘in-scope’. This helped keeping the brainstorming session grounded in reality of what could be delivered, and also clarified to the participants what type of data we were considering. In this blog example, I am working on Account Receivables data.
The Second Step – Whiteboarding
Functional specs are not useful at all when users do not even know what they want. We strongly prefer the RAD approach of interactive prototyping. This means having a group of 3-5 people in a room with markers and a whiteboard, drawing images and graphs of what they want to see, and how that want to interact with the dashboards.
In my California example, we simply created four whiteboard dashboards: Two for AR summary and details and two for billing disputes and details (all in 5 hours on the first day). We also avoided long reports of more than 100 items. These belong in WebI and such reports can be linked to from the dashboards. The key to dashboard success is: speed, speed, and speed.
The Third Step – Query mockup
The next step is to define how a query result may look like in Excel and what data is needed to support the whiteboard dashboards.
The benefit of the query mockup is that you can do this before the BW system is even built. It also provides a reality-check on what the query needs to be able to provide to support the mockups. This was done at the end of day-one.
The Fourth Step – Excel Prototyping
Based on the query in step three, we now created a mockup of the dashboard in Excel, using standard Excel functionality. There is no need for a BOBJ system, licensing or to consider of tool limitation. The idea goes as follows: If I can mock it up in Excel, I can probably also make it in Xcelsius.
The benefit of this approach is that you can get some reality check on layout, space management, font-sizes, colors, navigation items and can create a quick story-board with minimal technology dependencies. It can be done on any PC with MS Office. At our project this was done on day-two.
The Fifth Step – Feedback
Now you have something to show them. In this example, we brought the Excel mockup dashboards back to the user group for feedback and made changed to the mockups in the room while they were there. We also used the whiteboard for additional feedback and story boarding. This was day-three.
The Sixth Step – Mockup in Xcelsius
Now we were ready to use our Excel data to create mockups in Xcelsius. This creates a better feel for how the dashboards would look like in the BOBJ tool suite. It also uncovered limitations in the tool and specific formatting options. This was day-four.
The Last step – Management Feedback
The next day we showed the four Xcelsius mockup dashboards to the director for the AR groups and the VP of finance for their input. A meeting was also conducted with the core team for finalized feedback. After these sessions, you have 90% of the dashboards requirements. Now the last step is to write the functional specs with pictures and storyboards. This is day-five and we have most of the requirements and can start the development work.
Don’t go into analysis paralysis with dashboarding. The fact is that few know what they want, and the real requirements will materialize six months after go-live J.
It is better to use a RAD approach to requirements gathering and set aside time for a second enhancement after the users have started using the dashboards. Also, don’t forget that WebI should be used for detailed reporting – don’t cram in high volumes of data into Xcelsius. Speed is king to adaptation.
Next time I will cover some of exiting items we will include in the BOBJ Xcelsius SAP Insider Seminars this fall. The dates and locations are:
September 19-21 (Chicago)
October 3-5 (Philadelphia)
November 2-4 (Las Vegas)
December 7- 9 (Copenhagen)
Hope to see you at these events….