Cognos Controller & TM1

[AWILDE]

Hi,

I am looking at putting in Cognos controller to improve our statutory reporting function.

We currently use TM1 which is linked directly to our accounting system, can anyone tell me how cognos controller works with TM1? We currently do all our currency conversion in TM1 however I think we may be better off using Controller for statutory reporting due to having report IFRS local GAAP etc for this then pulling direct from controller into TM1. Tm1 is linked to other systems other than the accounting system.

Has anyone got any experiances on this?

[appleglaze28]

As for my opinion Controller is best used for companies using multiple currencies as well as with different ownership stake at different companies. This would make consolidations of your financial reports easier and better. Then from here, you can use the data from Controller to TM1, BI and such.

[AWILDE]

Hi Thanks for your response.

At the moment all our consolidation is done in TM1 which can be refeshed and reported on in a matter of seconds. Will controller take longer to consolidate the results?

[Steve Rowe]

Hi AWILDE,

I'll just qualify this by saying I've no experience of Controller.
There's nothing that apple glaze mentions in his post that TM1 doesn't handle well. Since you already have a system that's working well in pure TM1 perhaps it would be worth you mentioning some specific areas where you would like to improve what TM1 does for you now?
Then people can give you some good views on Controller vs pure TM1 to deliver those improvements?

The one area I do know of where TM1 can have issues is the restatement of history when a dimension structure is changed. So If account 1001 moves from sales to costs, then all the prior sales and costs that have been reported get changed. This can be a problem from a statutory reporting point of view. These issues can be resolved but it can be tricky when you want to stop TM1 being dynamic.

Not sure how Controller deals with this situation, anyone else want to chip in?

You might try a Controller forum to ask this question as here is mostly TM1 people who like yourself are beginning to use Controller.

Cheers,

[lotsaram]

It has taken a while to respond to this topic but here's my 2c ...

The "integration" between Controller and TM1 is a very welcome addition and hopefully in the future it will become a true integration however at this point it is stuttering baby steps. However I am sure that as evidenced by CX and C8 TM1 integration it will improve but some changes would not go astray.

With Controller 8.5 you get an inbuilt x86 9.4 TM1 service called FAP (which I think stands for "finance application publisher"). After configuring the FAP publisher to push summarized data from controller to TM1 you get a server with one absolutely non-configurable cube called "COG8CTRL". There is a measures dimension with 2 elements "YTD Balance" and "Monthly Movement." All data is loaded as YTD balance with monthly movements calculated via a rule.

I haven't really lifted the hood so I'm not sure whether the publish is a custom app via API calls or whether temporary TI is registered via API for the import and then destroyed. No matter there are several issues with the current implementation which I hope are addressed in future releases, if not the model has some severe limitations.

1/ With every publish the COG8CTRL cube is destroyed and recreated as opposed to zeroed out. Unfortunately this means that users are unable to create views to report off the COG8CTRL cube as they are destroyed at cube rebuild.
2/ Element naming conventions contain non alpha-numeric characters reserved as TM1 operators. Eg. the top node of dimensions with hierarchies is called "@Aggr_@TOT - Total" (except thankfully for company, account and period) and the default element for blank or no identifier is "@None". Unfortunately it seems the lessons that should have been learned from Workflow have not been (but at least the @ symbol only appears in element names and not dimension names...)
3/ Consolidation naming conventions in the company (and "additional") dimensions make the principal element name for what would usually be hierarchies in an OLAP member rollup flattened with a new rollup with Controller naming created above. This makes sense from the perspective of allowing the true "hierarchies" to accept data entry in the TM1 cube for non-posting level elimination and adjustment journals etc. However it would be a much better design to maintain naming conventions as per the source GL system and what would usually be done in a TM1 model and create adjustment entities under the consolidations with a defined prefix or suffix. This would be much better for reporting

The end result? Yes there is "integration" but it is difficult to do anything with it. To get anything useful quite a bit of additional TI development is needed to create additional "clone" dimensions and cubes which can be populated via rule from COG8CTRL. Once this is done you can get some fairly good GL reporting out of FAP but it isn't out of the box.

To get back to your question, yes Controller does have some very nice out of the box features in terms of control, eliminations and close that are difficult to achieve with just TM1. The ability of a relational system to time stamp hierarchies and built in OOTB currency conversion is good from a statutory and IFRS perspective. However what you won't get is any improvement in the ability to report on your GL versus what you currently have with TM1. If you have in-house expertise in TM1 then you could probably do a much better job of "integrating" TM1 with Controller than what comes OOTB but not without effort. So if you are evaluating Controller as an option then you really need to think hard about why you need it and what aspects are the ones that really matter to you.

[AWILDE]

Thanks for your response on this - Its been very useful.

[Herman Moller]

A side thought on Controller & TM1.

You can create a linkage between Controller and TM1 if you are working with Controller 8.4 or less.

How is this done........

1) Write a number of Views in SQL to extract the Controller Tables to specific views that can be used in 2).
2) Uses these views to a) Build your controller structures dimensions and b) Load your controller data to a TM1 cube.

As mentioned by Lots the actual data will be published in YTD and your can either write a rule to change the data to monthly or do this in a TI process.

Herman

[JamesM]

Hi,

There now appears to be two branches of this question. How does the new TM1 integration work with Controller and also when and why would you use Controller instead of TM1.

On the question of how the new integration of Controller & TM1 works is that it is controlled by a new service the “Financial Analytics Publisher” (FAP). The FAP client allows you to specify how regularly the cube is updated allowing for it to be updated in a near real time basis. This means that reports created in TM1 or BI could be used for the first time as part as the close process rather than just for the final reporting.

This takes away the need to write complex SQL & TI processes to extract data from the Controller database. A lot of manipulation is done to ensure complex multiple ownership is correctly stated and that the figures are correctly stated under the different configurations.

You can create as many cubes as required specifying their names in the FAP client (they do not have to be called “COG8CTRL” as specified in the previous post). The cubes are designed for reporting so holds the main dimensions required for reporting. In addition their has been some work to create a best practice document + TM1 application that creates further cube that reads the FAP cube using rules but has additional dimensions, manipulations on existing dimensions and calculated measures to allow for ease of use and for more complex reporting requirements.

If Budgeting and Forecasting is required then making a copy of the dimensions and cubes via replication or TI is recommended. Automation can be set up to push Budget and Forecast data back into Controller using TI + Controller Staging tables.

When it comes to the question of why you would use Controller over TM1 this would depend on the complexity of your requirements. Controller is a Financial Consolidation Solution, As a result it deals with the following:
1. Workflow based on the Close, Consolidate & Reporting (CCR) Process
2. Acquisition Calculations
3. Inter Company Balances
4. Inter Company Profits
5. Currency Conversion
6. Allocations
7. Entity & Group Journals
The key when it comes to organisations already using an OLAP solution is how much are the finance department still doing outside of the cubes and in spreadsheets because some of the above is outside the ability of their present set up. For example most OLAP solutions have Currency Conversion but not at a detailed enough level to automate Cash flow statements, as this has complex calculations for accounts such as investments in subsidiaries.

So if the requirement warrants some or all of this functionality the next question is do you build it into their OLAP solution or Buy Controller (the age old Buy over Build question). The answer will depend on the complexity of the Organisation however Controller has all the functionality listed above out of the box with hundreds of pre built reports available from day 1. There is a considerable development resource put into covering just this specialist requirement and in addition there are blueprints to help organisations deploy best practices (Some of the Blueprints have been developed by Deloittes). In addition all the reporting can now be done using the FAP TM1 OLAP environment effectively giving customers the best of both worlds.