Design Considerations for the model

[arun08]

What are the things you need to consider while making the design of the model? Otherwise how do you approach building the model after the requirements gathering session is over? How many Input cubes or how many calculation cubes etc besides Dlists, Dlinks etc?

I know it will all vary depending on what you are trying to build but how do you approach the design problem? Where do you start? Do you start at the output cube and work back words. Is there a best practice for Cognos Planning model building?

Thanks in advance.

[sascha]

To be honest... I would look for an appropriate consultancy if you are designing a system the first time  ;).

There are far too much things to consider and far too much best practices depending on your specific needs.

Sorry that this answer doesn't give you a satisfying answer but it's the truth.

[arun08]

Thanks Sascha for your quick response. You are right. This is not the response I am looking for. I am looking for a very generic response, kind of a guideline if that is what you meant.

I would really apprceiate if someone as experienced as Ykud or Dermeister or jan.herout replied to my querry.

Thanks,

[adityashah27]

if you have been given excel or existing model (diff tool) as a requirement than it makes your work simpler. you have got base to start with. improvise excel and start building model.

if you have been given req doc than i would suggest to start with the bigger picture and break that into smaller parts and further into the list of  important analyst objects. once you have your design ready, you can use input-calc-output or any other approach for build stage.

There are several approaches for model design. whatever approach you take but always consider two things
- prepare prototype- show it to users and meet every week instead of developing in isolation, more of interactive development. there are several benefits of this approach. I prefer this approach whenever possible.
- follow model building standards put-in-place by client. never ignore it and try be in synch with client's standards as there could be different ways of building model.

based on my exp i tried share one of model building dimensions, the list can go on...

[jan.herout]

Hello,

first of all, you should know answers to the following questions (the problem as you put it is too general). Please take this only as a general guideline, plus i would really appreciate if someone with more experience had something to say to this.

(1) How many users will the model have? what is organization structure of the organization? do you plan to use contributor applications in the project? what business area do you intend to plan using Cognos Planning?

Why :
This has quite big impact to the overall design in terms of model structure - number of libraries, management of dlists etc. Sometimes the business area is that complex that you need to split it somehow into smaller pieces in order not to have problems with contributor sizing.
Aditionally, sometimes you need to push the most complex part of the logic into tool other than Cognos Planning, such as relational database.

How many dimensions will you have in the model? What will be their size? Can you expect sizing problems? What are the most complex operations you will encounter, and is Planning the right tool for them? How will you manage your dlists?


(2) What do you plan to do with the data once they are inputted into your planning application? Do you plan to load it into data warehouse? Do you plan to do "online reporting"?

Why :
You need to know what means you will use to push the data into the database. From my experience, I would say that Analyst publish tends to be too slow to have any real value, plus you can expect problems with local IT (level of access rights you need to do that). So, I believe there are only two feasible ways how to push the data into database - use Publish from Contributor itself (which can work efficiently for reasonable amounts of data) or use Analyst dcube export to prepare flat files to be loaded into database (efficient, however "unclean" technique).

If you plan to use Publish, you need to be aware how published data looks like in terms of structure. For designer of ETL logic, Cognos Planning data can be real nightmare if you do not use "technical" names for dlist items, plus expect questions like "what is the product code for product ABC, how do I join it with sales statistics star schema?"

Watch out for dimensions coding! Think ahead about that!


Honestly, I believe that to design good model, you first need to see one. It is quite possible to do very stupid mistakes while designing the model, which can lead to a situation that you will not be able to administer it in future.


Go to Cognos Support, look out for best practices and design techiques, that will give you some ideas and guidelines for best practices. Look out for performance blueprints, this can give you generic ideas of various design techniques. Find someone who will "punch you in the face" for each mistake you will do in the model, this helps a lot!

http://support.cognos.com/supported/tti/public/index.html
http://www.cognos.com/innovationcenter/blueprint.html


Hope this helps a bit...

[ykud]

Quick tips.

Main questions are:
1) What forms (budgets) are used, with what logic (calculations). Make a full list with all dimensions used in budgets. Start thinking about splitting (joining) budgets into cubes. Get approx. dimensions sizes and calc cube volumes to keep things real.
2) What are submission rules for every form, what's the business process from somebody inputing first draft numbers to final version.
Group forms with similar submission rules (like all these sales and opex budgets are submitted bottom-up, from local store up to HQ). Forms with similar submission rules are potential Contributor applications, since they all share common submission structure (aka elist)
3) What financial structure company has
4) Rules for creating budget versions, when are they created, how and etc
5) Multiple Currency rules
6) Allocation rules. If administrative cost is split to all profit centers to calculate their "clean" P&L, what driver is used? All these important mechanisms
7) Consolidation rules. What are the rules of creating overall company's budgets, how are internal flows detected and eliminated, should there be some special consolidation options like minority interest and etc.

Complete answers to all these questions give you a clear picture of a process. We've created standard templates for those and practise them over 5 years already. Works )

[arun08]

Thanks to adityashah27, jan.herout & Ykud. Wonderful replies. Now I have something to work with. These are some very good points to take care off while doing the design.

Once again thank you very much.


Arun