I just came back from a two week, around-the-world training engagement where I was part of a team that presented a class on how to use SmartView and Financial Reports to retrieve information from Essbase. The class was a success, and the users all appeared to understand the material we covered. However, as I listened to the questions the users asked, I realized there is a gap between the things we developers tend to focus on and what the business analysts and managers want to learn.

Developers look at Essbase as a tool to build applications and databases. We focus on the parts of the software that can help us do a better job in building a more efficient solution.

End-users look at Essbase as a tool to help them do their job. Their job is to provide analysis on data, understand what their company is doing, and anticipate what their manager is going to ask next. For them, Essbase is just another tool, like Excel, Word, PowerPoint, and email; and all they need is to feel comfortable that the data in Essbase is accurate and timely.

So, where is the gap?

The gap between developers and end-users is found when it comes to naming conventions, data location, refresh timing, and use of the power of Excel.

What’s in a Name?

End-users focus on company names—e.g., Hyperion, Oracle, SAP—and these names become synonymous with the data. Left unchecked, company names become the names of the data source. "Is this Oracle data?" or "I pull data from Hyperion," are common sayings among end users. For them, the focus is on the data—the name of the software or application is secondary. Developers, on the other hand, focus on the custom Essbase application and database names. Since we use Hyperion for multiple data sources, we don’t think about it as the data source. Rather, it is a tool we use to develop databases.

One of the first things we had to do during training was to explain the difference between ‘Hyperion,’ ‘Essbase’ and ‘SmartView,’ and the application and database names we created in Essbase. Establishing a baseline of the names we used to describe the different systems, applications and databases became the cornerstone of the training. Once we got that out of the way, both developers and end users were able to communicate clearly.

Where is the Data?

End-users are all about data; developers are all about metadata. End-users want to know where the data is and what it represents. This is crucial to the way they do their job. They tend to focus on the specific slices of the database that relate to their area of responsibility. Developers focus on hierarchies, shared members, dimension structure, calc scripts, and load rules. This is where they spend their time—making the cubes work better and faster.

So when developers teach classes, they naturally tend to pay lots of attention to the metadata. Of course, the users follow the instructions of the developers and learn all about the dimension structure and the like, but what they really crave for is detail on where the data is.

Timing is Everything

End-users are very concerned with the timing of data refreshes. For them, the ‘when data appears in the database’ is just as important as the ‘where the data is.’ Their analysis is always time sensitive. The timing of data refreshes becomes a dimension in its own right when it comes to their ability to present data to management. For developers, the timing of refreshes is just another detail in the process of developing the cube. From the developer’s prospective, timing can be changed to fit the user’s needs.

During training, the users look for definitive answers on the refresh schedule. Developers should make sure to come to training with a clear schedule of data refresh. The users will appreciate having a clear idea of how they can schedule their time-sensitive work.

Excel vs. SmartView

It is remarkable to see how people forget what they know when they are put in a classroom. When teaching a class on SmartView, users tend to focus completely on the new features they are learning about. While they do this, they tend to forget that they are working in Excel, the most powerful analysis tool in the known universe. Of course, after they work with SmartView for a while, they will start to incorporate their knowledge of Excel into their newfound knowledge of SmartView. However, as a trainer, it is important to remind the end-users right from the start that they are working in the tool they use every day, and they should take advantage of the features they have. For example, teach the users how to pivot rows and columns manually instead of through SmartView to retain formatting. Another example is to create a template with pre-defined POV members in Excel and saving the file to make ad-hoc analysis faster. These simple things will remind the user that they can take advantage of powerful features in Excel while still learning the new features of SmartView.

Can’t We All Just Get Along…?

At the end of training, everyone was on the same page. The end-users left class knowing what they needed, and the developers left feeling good about teaching the class. The gaps I listed above were bridged, but I cannot escape the feeling that we were again caught by surprise by what the users were looking for as opposed to what we (the developers) had prepared for them. As developers, we should anticipate the needs of the audience, not just our own objectives. Doing so will make the training easier and impress the users that we ‘get it.’