In putting together an Essbase management book, I'm digging deep into my memory for engagements I had with customers and prospects and recalling specific issues they had towards which we applied our knowhow and technology.
There's a big national insurance company that has some large earthquake proof buildings in Los Angeles. Let's call them City State. I recall a trip I made out to them in my buddy's new Nissan Maxima. We engaged the customer in a use case design session, reviewing their entire FOCUS-based repository. From all of their source systems, they had 36 dimensions and many more which were set for aggregation in FOCUS. They called us to help them understand how Essbase could be employed. The managers at City State were tasked with serving a large number of customers from different areas across the business. Data from all lines of business were represented in the current FOCUS database and more were scheduled to be added. FOCUS could no longer handle adhoc queries. They wanted to be able to query anything at any time using the full set of dimensions which included a great deal of demographic data. In short, they had a data mining problem but did not wish to invest in data mining technology.
My use case analysis revealed that there were different clusters of interest around the data which could be identified by analyst group, and began a process that could be tied to incentives for the analyst groups. His solution considered both data supply and data demand.
On the demand side, the query process was undisciplined. Any user from any group could build ad-hoc queries against the whole of the FOCUS database. Nobody knew exactly what queries were being run or for what purposes. The users had become accustomed to asking for everything. They had no organized way of qualifying their requirements from IT and were not satisfied by the results.
So I held a workshop and through that process we discovered that the Fire LOB analysts knew from their own professional experience that demographic information was not pertinent to the number and severity of claims related to fire. Consequently, the value of demographic dimensional data for that subset of insurance vehicles was de-emphasized and other dimensional attributes, like roofing type & proximity to hydrants were emphasized. We were able to establish a framework through which City State could confidently gather all of the data attributes on all of their lines of business and provide strict guidelines for marting that data to the various user groups.
Once this process of generating requirements was made demonstrated, the path to solving supply and demand issues for City State was made clear. This made blocking and tackling projects a great deal more responsive to the needs of the analyst communities, and gave IT a way to make sense of the backlog and frustrations. Once analysts 'got it' with regard to looking at a set of measures and then associating the most key dimensions to them both sides could see what work was required that could get them through development smartly.
You can follow this kind of guide for your purposes. What are the problem areas that analysts recognize? You can ask this realizing that nobody may have been assigned to solve the problem - that management is busy elsewhere, but the folks in the cubes know that the problem is real. It might start with a very simple metric. How long are people on hold for customer service? Or how about Number of exempt employees with a Masters or Doctorate degrees expressed as a percentage of the total number of exempt employees? It doesn't take too much creativity to realize that any number of business issue can be quantified in this manner.
The next step obviously is to consider within the vast resources of your company's computer generated data, which systems might have information that could credibly generate a dataset worthy of analysis. Certainly any number of operational systems might contain that information. And that would be easy if analysts are struggling to get reports out of the current systems which might provide some insight. HR analysts might know that total number of exempt employees are in one system, but that number of masters or doctorate degrees by employee is in another system. The merging of these two would be the job of the new project manager who requires the assistance of those current data stewards. The analysts can contribute by drawing a reasonable box around the universe of data to be explored, and senior managers can consider what priorities are to be emphasized based upon expectations of what will be found in the data. This insures that the area of inquiry is credible and actionable.
Comments