Roles and Tasks around Essbase

Question

Hi, Everyone,
Currently in our company our controllers are the users of Essbase and the administrators of this products as well. Unfortunately, they are facing some performance problems and other administrative problems. In the future the idea will be, IT department should take over some of the tasks from Controllers.
My question is, what are the tasks for ITs and what can be done by controllers? I can think of these tasks:
System upgrade
Server Performance
System Performance
System administration
Application configuration
Database configuration
Maybe further details, CALC scripts, automatic calculation etc.,
I am not familiar with Essbase at all. Could anyone tell me what the situation looks like in your company? Or, what is your suggestion?
Thanks and looking forward to your replay.
Linda

Answer 1

I Agree with this, of course.
The IT department is there to run the "process", while the business units have a functional perspective. This is not as clean a division within Essbase as with traditional relational databases, but it's getting closer all the time.
Things like automation, data transformation/loading/calculations and such are more of an IT thing than a functional unit thing. Same with backups, dissaster recovery, and such.
Where I have a slightly different perspective is on the outline maintenance -- I believe the IT group should handle the outline management and the functional unit should handle the hierarchy definition itself. For instance, while finance and accounting dictates the account and organizational hierarchies, IT uses the tools and techniques to transfer this into the database structures. The reason for this separation is fairly clear in my mind, and is based on the distinction between business knowledge and technical knowledge (both sides need a bit of both, but each maintains their respective areas of expertise). I wouldn't expect finance or accounting to determine which members can/should be dynamically calculated, or which hierarchies should be shared vs. stored, for instance.
The biggest risk of not using both skill sets is that you just let the functional groups do everything, and end up with a loss of infrastructure support (like invalid or insufficient backup and D/R support). The other side also exists, giving it all to IT runs the risk of the functional units becoming disengaged with the management of hierarchies or confusion on data content/meaning. I have seen both conditions exist, and it's more common than it should be.
That said, there is a lot of room for flexibility in terms of who does what, and allowing the functional units to manage things directly is not necessarilly a bad thing. It's just better to have the subject matter experts handling the tasks they do best. IT is better at infrastructure support, and the overhead associated with it is better off not taking up the business units' time.