Setting up a new Cognos 10 support organziation

[ted]

hello. our company is in the process of implementing Cognos 10 as a reporting tool for a very specific function of the orgnaziation. We are trying to determine the best way to create a support structure once we have implemeted the project.  The orgainzation has a large IT department with spefic areas that handel infrastruture and others that handle supporting specfic business applications.  there are also general busienss funcational areas like accounting, hr, etc.

the thing that we are struggling with is the "grey" area needed for support something that isnt purely IT issue and not purely a business issue and requires knowledge of the tool.

I would love to spur some discussion to see how others have defined roles and where these roles live within the orgainzations.  I would also love to hear of issues people have faced with the lack of support and how they would like thier reporting environment supported better.

Cheers,
Ted

[cognostechie]

The post-implementation support will depend on whether or not Cognos has been implementated successfully. Sadly, more than 50% implementations have been done in a way which makes the solution very expensive to maintain and gives birth to extensive support. Most consultants know less than 50% of the technical side and lack vision which results in an un-user friendly solution. With a proper solution, the support required would be minimal.

There are some things that apply to everyone but some things that are specific. Most companies make the mistake of hiring developers to maintain and support after the implementation is done by consultants. They should start with hiring an Architect instead of a developer and hire developers later on in the process. Without looking at your infrastructure, it is not possible to suggest the support structure.     

[SomeClown]

Who paid for the product?  Whichever group that paid and is paying (maintenance) should own the application support (or Center of Excellence, or Competentency Center, or whatever you need to call it).  It's about the only way I've seen successful deployments go.  Otherwise, you end up manifesting the organizational conflicts into sub-par application support and processes.