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
- Changing descriptions/aliases/attributes
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.