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.
Whats in a Name?
End-users focus on company namese.g., Hyperion, Oracle, SAPand 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 datathe 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 dont 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 timemaking 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.
