HomeDownloadable ResourcesContact Me
Archive Older

Wednesday, October 8, 2008

IT vs. Business Role in Essbase

The Business units have a functional perspective while the IT department will focus on the technical processes.  This is rarely disputed but also rarely analyzed as to how well they complement each other.  In regards to Essbase, the line that separates these two elements is a bit blurry, although less so with each new version.  Sometimes, however, this is *not* for the better.

While IT has the focus, knowledge, and understanding of things like data extraction, transformation, data loading, automation, backups, disaster recovery, and so on; the business units are often still tasked with maintaining different hierarchy elements.  The reason is simple enough, because it is much more of a business issue than a technical one.  With Essbase, however, the tool that manages hierarchies natively is the same as the tool that manages all the other technical items.  Is this a bad thing?  No, not really.  What is needed, and what has been provided, is a tool making this process more of an enterprise managed resource.  This is good, as long as you are in a big company that can afford the relatively large cost of taking this route.


For the rest of us (and by now you should know I tend to represent the little guy more than the big groups), I would like to talk about the logical separation of this process.  It's rather like a "Doh!" moment at first, but the more thought applied to this, the more clearly you might see how it really shouldn't cost an arm and a leg to manage something so far from the company's bottom line.

Okay, the obvious: let IT handle the update, and the Finance/Accounting/whatever group handle the definition.  So far, so good.  But how best to supply the definition in a way that is actively managed without excessive cost?  Should you really have to go out and pay tens or hundreds of thousands of dollars to control your chart of accounts or regional structures in essbase?!?

The answer: No, it should be inexpensive and easy.  Easy enough so the business unit is comfortable without learning new skills, at least.  Don't let IT pull your business units into a techno-jargon filled environment and make it into the hierarchy equivalent of a scientific graphing calculator with mode buttons and function keys.  Instead, realize that together, IT and the controlling department must arrive at a working solution that is easy on everyone.

Step 1: ensure that EACH AND EVERY hierarchy element has a person assigned to be responsible for it.  For me, this includes giving each element a formal name.  The #1 best way to eliminate confusion is to provide a unique, fully understood name to every process, object, event, trigger, or other conceptual entity that requires any form of control.  You should end up with a table of elements and points of contact that can be agreed upon by everyone.


Step 2: determine how hierarchy elements are to be dealt with for the following aspects:

  • Adding new members
  • Validating data issues related to them
  • Changing descriptions/aliases/attributes
  • Deletions

Step 3: determine the frequency for which updates will occur and how they are logged or documented.  While often the new elements could be added whenever the data is loaded, it is this kind of assumption that should be explicitly turned into a policy.  Not all IT people would understand why it's a bad thing to update a regional structure in the middle of a budget process, for instance.

Step 4: Package the details into a policy.  This doesn't have to be complicated, and in fact, could be nothing more than a text file (yes, written in notepad!), that includes a simple list of named events, event triggers (i.e. key dates, data loads, phone calls, email, etc...), contacts, processes to be completed (and by who), and any other relevant details.  It doesn't have to be a book, just be complete enough to guide the process at the highest levels.  For instance, if each process had it's own process document, the policy should only have to refer to the process documents.  The goal for this document is to be short and succinct enough to be a one or two page "daily reference" or at most, a turn over document cover sheet.  I call mine the "change control master", and it has enough detail to act as a checklist.

The overall concept is that both IT and the business unit work "their side of the fence" in a neighborly fashion, respecting the need for the other side to stay informed.  A formal policy is not designed to add bureaucracy, but to help illuminate the process so everyone can navigate more effectively when odd-ball events occur.

6:49 pm est


Archive Older
DougWare was a name given to me by a former boss that kind of stuck.  I purchased the domain back in 1992 and have had it idle almost all the time (except for email).  At first it was because I tended to handle everything that was *not* hardware or software, and dougware was the "in-between" stuff.  Lately though, it's been software only and focussed on tools for Hyperion Essbase developers.

Ask the Expert!

For free email business advice, send your questions, comments or ideas to dougb@dougware.com. For issues that are of particular interest to the Essbase community, we may publish your questions along with our answers on this web site.  Since there are so many forums that deal with general essbase issues, I will specifically be addressing VBA/VB API issues where the code shows no overt signs of problems and needs an indepth review.

Join Our Mailing List!
By joining our mailing list, you will be the first to know about:
 
  • Breaking news about our business
  • Helpful tips
  • Exclusive special offers
 
To join, type your email address below and then click the Go button.

DougWare_Background.jpg

This site  The Web