COGNOS planning limitations

[Finplanner2009]

Hi, Experts!

Our company consider buying Cognos EP for our budgeting process automation. As far as I know Cognos Planning 7 had some limitations as follows:
1) the lengths of D-list member name can’t exceed 50 symbols
2) it is not recommended to create large D-cubes (size > 20 mln cells) in Analyst
3) it is not recommended to create cubes with more than 2 mln cells for one e-list item in Contributor

Could smb tell do these limitations still remain in version 8?

One more question concerning hierarchies: how many levels can be created in one hierarchy and does D-list maintain more than one hierarchy version?

Thanks very much in advance!

[ykud]

No big changes in engine, so it's still
1) yes
2) yes
3) yes

Didn't see any hierarchy level restrictions (made up to 5-10), only one hierarchy.

[ScottW]

Cognos does now have a product in its planning stack in TM1 that does not suffer from any of the limitations which you mention  :-X

[Finplanner2009]

As far as I know TM1 is an application that doesn't have Cognos Planning significant features like powerful break back calculations, built-in functions library that help business users work independently with minimum supervision from IT department.

[Finplanner2009]

No big changes in engine, so it's still
1) yes
2) yes
3) yes

Didn't see any hierarchy level restrictions (made up to 5-10), only one hierarchy.

ykud, thank you very much for your reply! Very useful information

[dusherwo]

To backup scottw, and fully recognising the strengths of EP:
a    TM1 has spreading, which was built as a 'response' to Adaytum breakback. It's pretty good though perhaps not as user friendly as breakback. There is also (and would be my preference) the rules engine, which allows you to formalise allocation calculations and the like.
b    The TM1 rules engine has a fair number of business functions (though I could do with more, or with extensibility). I would say EP has more, but knowledgeable TM1-ers can normally build what's needed (eg IRR, STDEV) from first principles.
c    TM1 is _almost always_ run by users with minimal involvement from IT. Of course the users need to know what they are doing, but we find that people who have built fairly complex systems in Excel find moving to TM1 easy.
HTH
David

[ScottW]

As far as I know TM1 is an application that doesn't have Cognos Planning significant features like powerful break back calculations, built-in functions library that help business users work independently with minimum supervision from IT department.

EP and TM1 both have their own place in IBM's portfolio but you may have been misinformed (hopefully not deliberately mislead) as to TM1's capabilities. TM1 does have break back, it is just called "data spreading". It has at least as many methods as EP break back (proportional, relative proportional, equal, percent change, growth, straight line) with the ability to hold consolidations or leaves at any level. Perhaps the main point of difference is that a top-down breakback in EP on an empty region will result in an even spread of data to underlying leaves. In TM1 an empty region must first be populated with some data before it can accept a top down spread (there has to first be a data pattern before input can be proportionally spread). Generally this isn't an issue as data can be very easily moved or seeded in TM1.

Although TM1 doesn't have BIFs like EP, TM1's business rules engine is very flexible, powerful and capable. Virtually any business calculation can be modelled.  Although the lack of a BIF library does mean that most calculations have to be written from scratch this is generally no more onerous than writing the equivalent calculation in Analyst.  TM1 rules do however have the advantage of being true multi-dimensional calculations.

In the majority of installations TM1 is owned and operated by users with minimal involvement from IT. From what I have seen TM1 is generally a lot less IT dependent and technical than EP.  For one it is a lot less hungry hardware and infrastructure, everything runs on one box! :) With the noted exception of the rules engine, the architecture is also a whole lot simpler as all dimensions are equal. There is no grappling with E Lists and D lists etc.  TM1 cubes also deal with data sparsity extremely well - there are (practically!) no maximum cube size or dimension size limitations.  Often the single greatest pain in an EP implementation is the mapping exercise to compact/concatenate several "business dimensions" into a single E List in order to limit data explosion/cube size. In a TM1 model this isn't necessary - the cube can contain the dimensions separately without the need to combine into an E List, this allows power users to quite intuitively browse cubes as they would in PowerPlay or other OLAP tools.  This also means no limitation in number of versions, number of years of data, etc, etc.

TM1 also offers a lot more flexibility in front end than the Contributor/Analyst combination (... can be both a good and a bad thing).

Areas where EP is certainly better than TM1:
- Workflow in TM1 is not out of the box as it is with EP (although once set up it can be a true business process "workflow" i.e. more than a visual representation of access privileges and data entry status.)
- TM1 is server/client based, it has no off-line data entry capability (something I'm sure Cognos are working on ...)

... although it has been around 18 months since Cognos acquired Applix there is still plenty of confusion as to what EP does (and is best at) and what TM1 does (and is best at).  As there is a large amount of functionality cross-over that confusion is understandable and isn't about to dissipate.  However it certainly pays to evaluate each product in light of solution requirements on a case by case basis.

HTH

[SomeClown]

EP and TM1 both have their own place in IBM's portfolio but you may have been misinformed (hopefully not deliberately mislead) as to TM1's capabilities. TM1 does have break back....

Although TM1 doesn't have BIFs like EP, TM1's business rules engine is very flexible, powerful and capable. Virtually any business calculation can be modelled.  Although the lack of a BIF library does mean that most calculations have to be written from scratch this is generally no more onerous than writing the equivalent calculation in Analyst.  TM1 rules do however have the advantage of being true multi-dimensional calculations.

In the majority of installations TM1 is owned and operated by users with minimal involvement from IT. From what I have seen TM1 is generally a lot less IT dependent and technical than EP.  For one it is a lot less hungry hardware and infrastructure, everything runs on one box! There is no grappling with E Lists and D lists etc.  TM1 cubes also deal with data sparsity extremely well - there are (practically!) no maximum cube size or dimension size limitations.  Often the single greatest pain in an EP implementation is the mapping exercise to compact/concatenate several "business dimensions" into a single E List in order to limit data explosion/cube size. In a TM1 model this isn't necessary - the cube can contain the dimensions separately without the need to combine into an E List, this allows power users to quite intuitively browse cubes as they would in PowerPlay or other OLAP tools.  This also means no limitation in number of versions, number of years of data, etc, etc.

TM1 also offers a lot more flexibility in front end than the Contributor/Analyst combination (... can be both a good and a bad thing).

Areas where EP is certainly better than TM1:
- Workflow in TM1 is not out of the box as it is with EP (although once set up it can be a true business process "workflow" i.e. more than a visual representation of access privileges and data entry status.)
- TM1 is server/client based, it has no off-line data entry capability (something I'm sure Cognos are working on ...)

... although it has been around 18 months since Cognos acquired Applix there is still plenty of confusion as to what EP does (and is best at) and what TM1 does (and is best at).  As there is a large amount of functionality cross-over that confusion is understandable and isn't about to dissipate.  However it certainly pays to evaluate each product in light of solution requirements on a case by case basis.

Some of the confusion is that the Applix management took over most of the leadership functions at the Planning division at Cognos, with the intent (conscious or not) of eliminating the Planning products (Adaytum).  For the nine months or so, there was no support for understanding product distinctions and strengths.  Once it slowly became apparent that there were places where EP could provide solutions that TM1 couldn't and the userbase was not moving away from EP, the efforts to eliminate Planning diminished.

Other things to note: TM1 runs on one box because it's very challenging to create a system that runs on more than one box.  TM1 scales up nicely, EP scales out nicely.  TM1 struggles with lots of users (more than 100-200), where EP can manage thousands of users in their systems. 

TM1 is less IT dependent once it's implemented, perhaps.  Key to the point above, unless you're a power calc builder (like Excel guru or ex IT), writing rules is not something easily done -- it can be quite a challenge.  Changing dimensions and model definitions in EP can be very straightforward and simple (syncs/GTPs).  I would be more interested in seeing the skillsets of the model builders for the construction phase of any project rather the the skillset for the administrators for ongoing.

Point is, neither product family is a clear winner over the other.  Unless you are diligent about understanding how your requirements would be met by either product, you risk a good chance of picking the wrong product.

And, last point, the myth about the convoluted efforts to collapse dimensions to fit an Elist is bogus.    Most elists fall naturally out of the business definitions.  If you find you are spending a lot of time trying to force something into an EP model, you are probably using the wrong product and should be seriously looking at TM1.

[Gerald Donovan]

Clarification on (3) -

It is not recommended to create models with more than 2mln (or so) cells per e-list item in Contributor. (A Contributor model can comprise many cubes.)

Having said that, I'm going to be blunt here and state that if you end up with a model that requires significantly above that sort of number of cells per e-list item, then there is something very wrong with the design of the model, and quite possibly even the requirement specification itself.

I've had experience on both sides (customer and vendor, particularly vendor) of the selection process, and additionally significant exposure to many customer implementations. I can honestly say that sizing "limitations" of Analyst & Contributor have never been the root cause of any issues.

Feel free to get in contact via PM if you want a totally objective appraisal of whether EP is a good fit to your requirements.

Regards,

Gerald.

Hi, Experts!

Our company consider buying Cognos EP for our budgeting process automation. As far as I know Cognos Planning 7 had some limitations as follows:
1) the lengths of D-list member name can’t exceed 50 symbols
2) it is not recommended to create large D-cubes (size > 20 mln cells) in Analyst
3) it is not recommended to create cubes with more than 2 mln cells for one e-list item in Contributor

Could smb tell do these limitations still remain in version 8?

One more question concerning hierarchies: how many levels can be created in one hierarchy and does D-list maintain more than one hierarchy version?

Thanks very much in advance!

[Gerald Donovan]

Hi Scott -

Will be interesting to see where this conversation leads to, but I would like to take this opportunity to drill a little more into your response by asking a couple of questions if I may -

You mention "Often the single greatest pain in an EP implementation is the mapping exercise to compact/concatenate several "business dimensions" into a single E List in order to limit data explosion/cube size."

Would you mind sharing with us what your experience of EP implementations is?

With regards "In the majority of installations TM1 is owned and operated by users with minimal involvement from IT."

It's certainly true that for many years both products were pitched to the Finance department, and that the minimal requirement of involvement of IT was sold as a positive. However, increasingly over the last 5 years or so, I am finding that IT departments see this a negative.

It would be interesting to hear what your experience of the IT department's perspective is on Finance taking ownership of the solution is - particularly in large corporations where IT typically take a more strategic perspective on the ownership and support of operational solutions.

Finally, with regards your last paragraph, a comment.

It really shouldn't be down to a customer or prospect to have to evaluate different technology (even if it is competing technology) from the same company.

The customer/prospect should take the time to document what their requirements are, and work with the vendor to ensure these requirements are communicated and fully understood.

It is then the vendor's responsibility to propose to the customer the selection of their products that they - the vendor - believe are necessary to fulfill the customer's requirements.

Quite honestly, if anyone from IBM/Cognos or one of their partners asks you, as a customer, to evaluate TM1 against EP, then show them the door, and tell them to send you another sales team. Preferably one that understands the strengths and weaknesses of their own products with regards their capability to deliver to your requirements.

EP and TM1 both have their own place in IBM's portfolio but you may have been misinformed (hopefully not deliberately mislead) as to TM1's capabilities. TM1 does have break back, it is just called "data spreading". It has at least as many methods as EP break back (proportional, relative proportional, equal, percent change, growth, straight line) with the ability to hold consolidations or leaves at any level. Perhaps the main point of difference is that a top-down breakback in EP on an empty region will result in an even spread of data to underlying leaves. In TM1 an empty region must first be populated with some data before it can accept a top down spread (there has to first be a data pattern before input can be proportionally spread). Generally this isn't an issue as data can be very easily moved or seeded in TM1.

Although TM1 doesn't have BIFs like EP, TM1's business rules engine is very flexible, powerful and capable. Virtually any business calculation can be modelled.  Although the lack of a BIF library does mean that most calculations have to be written from scratch this is generally no more onerous than writing the equivalent calculation in Analyst.  TM1 rules do however have the advantage of being true multi-dimensional calculations.

In the majority of installations TM1 is owned and operated by users with minimal involvement from IT. From what I have seen TM1 is generally a lot less IT dependent and technical than EP.  For one it is a lot less hungry hardware and infrastructure, everything runs on one box! :) With the noted exception of the rules engine, the architecture is also a whole lot simpler as all dimensions are equal. There is no grappling with E Lists and D lists etc.  TM1 cubes also deal with data sparsity extremely well - there are (practically!) no maximum cube size or dimension size limitations.  Often the single greatest pain in an EP implementation is the mapping exercise to compact/concatenate several "business dimensions" into a single E List in order to limit data explosion/cube size. In a TM1 model this isn't necessary - the cube can contain the dimensions separately without the need to combine into an E List, this allows power users to quite intuitively browse cubes as they would in PowerPlay or other OLAP tools.  This also means no limitation in number of versions, number of years of data, etc, etc.

TM1 also offers a lot more flexibility in front end than the Contributor/Analyst combination (... can be both a good and a bad thing).

Areas where EP is certainly better than TM1:
- Workflow in TM1 is not out of the box as it is with EP (although once set up it can be a true business process "workflow" i.e. more than a visual representation of access privileges and data entry status.)
- TM1 is server/client based, it has no off-line data entry capability (something I'm sure Cognos are working on ...)

... although it has been around 18 months since Cognos acquired Applix there is still plenty of confusion as to what EP does (and is best at) and what TM1 does (and is best at).  As there is a large amount of functionality cross-over that confusion is understandable and isn't about to dissipate.  However it certainly pays to evaluate each product in light of solution requirements on a case by case basis.

HTH

[dusherwo]

Gerald and SomeClown:
Your questions are to Scott and he can reply. He and I are competitors within the TM1 market, albeit in different hemispheres. However, my 2m Zim$ herewith.

Like you, I had heard that TM1 was getting attention over EP - in _North America_. In Europe (where I am) it seems the exact reverse. Gossip put that down to the fact that Adaytum was a European company and Applix was a North American company.

I do agree with you (and have said earlier in this thread) that both products have their relative strengths and weaknesses. The workplan is to put the TM1 engine under EP. I support this but I am also _very_ wary of how this will be done and will work. That's quite distinct from my equal wariness of how good the first 2 or 3 builds will be - I've been burnt too often in the past.

Yes, TM1 is normally done as a 1 box solution. I agree (and have been saying for many years) that TM1's inter server communication should be far better than it is. Replication is offered but this is hard to control and some versions have not been reliable. Most multi server implementations use flat files. This works but is fiddly and rather old fashioned. But with the arrival of 64 bit it is quite manageable to adopt a centralised approach, with all the maintenance benefits which that brings, and the new locking approach in 9.1+ should allow scaling to far more users on a single server than (as you say) has been viable in the past.

(I should add in here - because I haven't yet - the sheer speed of TM1. OLAP is about speed and TM1 delivers it.)

On IT involvement/support - yes, very little of this is required either during an implementation or afterwards, with production systems. Mostly, the 'power users' who run the system, and also senior financial management, think this this is an entirely good thing. Not surprisingly, IT don't, either because it takes them (mostly) out of the loop or because their 'strategic perspective' is not given sufficient weight. I think I'd give more weight to the latter if I could see some evidence that their strategic perspective actually added long term shareholder value. Too often it comes down to 'we are going MS/SAP/Oracle so that's what we have to do'. (Fine, of course, if it's IBM/Cognos - I probably need to adjust my own point of view to fit within a large vendor mindset.)

On skillsets - yes, you need some power users to get going (that's what Scott and I do for a living). But we do find quite a large set of these power users in our clients who have been building massive spreadsheet systems for years and make the migration to TM1 with surprising ease.

Gerald, on your passage about IBM/Cognos or their partners asking a customer to evaluate TM1 vs EP -  at present we have communities both within and outside the IBM payroll
who know one or the other product, and have been selling and/or implementing it successfully for years. Don't expect them to change overnight. A good customer will be evaluating several solutions anyway. Let's be honest about what's good for what. Both have their sweet spots. Let's hope Engineering do a good job of putting the two together.

I'll be interested to see what comes back from this....

[SomeClown]

I do agree with you (and have said earlier in this thread) that both products have their relative strengths and weaknesses. The workplan is to put the TM1 engine under EP. I support this but I am also _very_ wary of how this will be done and will work. That's quite distinct from my equal wariness of how good the first 2 or 3 builds will be - I've been burnt too often in the past.

.... Let's be honest about what's good for what. Both have their sweet spots. Let's hope Engineering do a good job of putting the two together.

I share that hope but I doubt that it will happen: Cognos has a long history of a "buy and die" strategy for its acquisitions.  I really don't understand what magic bullet management is looking for, but it's obvious they've not known what to do with their prior attempts.  Their silo'd approach to products, both from a marketing and management perspective, does not inspire any confidence that they'll achieve much success in gluing them together.  (And no, the CPM positioning doesn't count: that's just frosting on a cake)

[Gerald Donovan]

Hi dusherwo -

Some very insightful and intelligent points there. I'm just going to pick up on the couple responding to my post.

Firstly, with regards IT strategy, I wasn't really referring to an all encompassing "one vendor fits all" strategy, more the strategy for IT departments to own and control all systems. To me, this is the key issue.

If you're looking to sell solutions that will be hitting the desktops of 1,000's of employees, I very much doubt there is a single IT department anywhere that would be happy to leave the ownership and administration of those systems within the finance department. The "little to no IT involvement required" sales pitch was fine 5-10 years ago, but things have moved on since then.

On the second point - the TM1/Planning community issue - you are of course absolutely correct in your observations. That doesn't make it right though.

Cognos bought Applix almost a year and a half ago. If there remains a lack of clarity within the IBM payroll as to which best fits a customer's requirements, then that, to put it bluntly, is a disgrace.

It's hardly a good message to be sending out to your prospects and customers that, depending on who turns up on your doorstep, you're going to recommend differing products to fulfill the same requirements. It's actually a pretty poor message to be sending out to your shareholders too.

Off the IBM payroll - i.e. within the partner network - I guess there's a little more leeway for a divergence of opinion as to which would be the right product, as it wasn't the partners who chose to bring the two into the same family.

I don't doubt that, given time, the situation will be resolved, but right now, it's a bit of a mess, and a mess that customers & prospects shouldn't be required to evaluate for themselves.

Gerald and SomeClown:
Your questions are to Scott and he can reply. He and I are competitors within the TM1 market, albeit in different hemispheres. However, my 2m Zim$ herewith.

Like you, I had heard that TM1 was getting attention over EP - in _North America_. In Europe (where I am) it seems the exact reverse. Gossip put that down to the fact that Adaytum was a European company and Applix was a North American company.

I do agree with you (and have said earlier in this thread) that both products have their relative strengths and weaknesses. The workplan is to put the TM1 engine under EP. I support this but I am also _very_ wary of how this will be done and will work. That's quite distinct from my equal wariness of how good the first 2 or 3 builds will be - I've been burnt too often in the past.

Yes, TM1 is normally done as a 1 box solution. I agree (and have been saying for many years) that TM1's inter server communication should be far better than it is. Replication is offered but this is hard to control and some versions have not been reliable. Most multi server implementations use flat files. This works but is fiddly and rather old fashioned. But with the arrival of 64 bit it is quite manageable to adopt a centralised approach, with all the maintenance benefits which that brings, and the new locking approach in 9.1+ should allow scaling to far more users on a single server than (as you say) has been viable in the past.

(I should add in here - because I haven't yet - the sheer speed of TM1. OLAP is about speed and TM1 delivers it.)

On IT involvement/support - yes, very little of this is required either during an implementation or afterwards, with production systems. Mostly, the 'power users' who run the system, and also senior financial management, think this this is an entirely good thing. Not surprisingly, IT don't, either because it takes them (mostly) out of the loop or because their 'strategic perspective' is not given sufficient weight. I think I'd give more weight to the latter if I could see some evidence that their strategic perspective actually added long term shareholder value. Too often it comes down to 'we are going MS/SAP/Oracle so that's what we have to do'. (Fine, of course, if it's IBM/Cognos - I probably need to adjust my own point of view to fit within a large vendor mindset.)

On skillsets - yes, you need some power users to get going (that's what Scott and I do for a living). But we do find quite a large set of these power users in our clients who have been building massive spreadsheet systems for years and make the migration to TM1 with surprising ease.

Gerald, on your passage about IBM/Cognos or their partners asking a customer to evaluate TM1 vs EP -  at present we have communities both within and outside the IBM payroll
who know one or the other product, and have been selling and/or implementing it successfully for years. Don't expect them to change overnight. A good customer will be evaluating several solutions anyway. Let's be honest about what's good for what. Both have their sweet spots. Let's hope Engineering do a good job of putting the two together.

I'll be interested to see what comes back from this....

[Jurii]

As far as I know Cognos Planning 7 had some limitations as follows:
1) the lengths of D-list member name can’t exceed 50 symbols
2) it is not recommended to create large D-cubes (size > 20 mln cells) in Analyst
3) it is not recommended to create cubes with more than 2 mln cells for one e-list item in Contributor
One more question concerning hierarchies: how many levels can be created in one hierarchy and does D-list maintain more than one hierarchy version?

Sometimes I also face some limitations of Cognos Planning. For example, some users want to have a lot of dimensions in P&L budget with high level of detail (for splitting Revenue by thousands of products, Salary - by thousands of employees, Depreciation - by thousands of Fixed asset items, ets.) of plan and actual data, with a lot of versions of data. In the same time, the users of P&L budger don't need break-back functionality. The solution I use is to build Cognos PowerCubes not having limitations in number of dimensions and cells.
This approach assumes that PowerPlay Transformer loads plan data from operational budgets of Cognos Planning, and actual data is taken from ERP system or from Data Warehouse.
When I have to conduct MRP calculations (for planning purchases and production), I also don't use Cognos Planning cubes. I load sales forecasts from Sales budget of Cognos Planning into Data Warehouse, load additional parameters (current stock levels, purchasing and production lead times, Bill of materials, lists of open purchase and work orders, ets.), run MRP procedure within Data Warehouse, get the results (recommendations of what items and when should be purchased or produced), aggregate the results and load them from Data Warehouse into Purchasing and Production cubes of Cognos Planning.

In other words, I suppose it is worth to use all modules of Cognos (not only Cognos Planning, but also Cognos BI) based on a powerful Data Warehouse.

[blackadder]

I suppose it is worth to use all modules of Cognos (not only Cognos Planning, but also Cognos BI) based on a powerful Data Warehouse.

If only more people understood that ....although I'd get a lot less audit work if they did!

In my experience there are plenty of people out there trying to shoe-horn Reporting functionality into their Planning tools, and ending up with solutions which they find to be unsatisfying. I have seen Cognos Planning applications where the data entry portion is <5% of the overall application size...all that additional build and reconcile overhead, just to fit in some reporting cubes, which PowerPlay could have built in seconds (or Report/Analysis Studio in near-realtime).

Reporting is an important part of many planning apps, and whether you use Cognos Planning or TM1 it can be achieved within the toolset, but it always seems to be a bit of a compromise compared with 'the real thing'.

I'd also point out that you also don't really need a 'powerful' data warehouse...the data generated by the biggest planning models is relatively tiny in DW terms, and a breeze for PowerPlay or Cognos 8. Plus the planning data can integrate with data from external sources without having to load them into the planning model.

Alternatively if you can't afford Cognos (or other) BI there are ways to achieve it a little more elegantly within EP using two models, incremental publishes and a bit of thought...

[Jurii]

2 blackadder:

I'd also point out that you also don't really need a 'powerful' data warehouse...the data generated by the biggest planning models is relatively tiny in DW terms, and a breeze for PowerPlay or Cognos 8

If you don't dave a Data warehouse, how will you calculate the purchasing and production requirements within planning model? I don't think it is realistic to conduct MRP calculations within Cognos Planning...

[dusherwo]

I'm glad to see the route this thread is now taking.

I believe I have been fairminded in earlier posts discussing EP vs TM1 for planning - both have their good and not so good points. But where TM1 really comes into its own is where other functions need to be handled.

TM1 is used now for forecasting, production planning, resource scheduling, fund and revenue modelling, stock ageing, financial consolidation, airline route profitability, daily cash flow, unearned premium calculation, banking covenant compliance, sales target negotiations, and I'm sure others can think of many more. It's being implemented by experts in their specialist fields who have got their head round the calculations and the business requirement. I don't consider myself to be an expert in any of these fields (I'm a UK qualified accountant, former systems auditor who has worked with these kinds of tools for 22 years) but when working with the experts this kind of model is very doable. I would assert that TM1 will have a considerable edge over a traditional warehouse approach from the point of view of build time, performance and accessibility of output.

Yes, TM1 experts are not that common - a relatively rare combination of knowledge, experience (both business and technical) and analytic capability is required. But I have come across many people at our clients who have these but hadn't had the tool to make it happen. When they get up to speed we fade out of the picture and they become self supporting.

Reporting - interesting issue. Up to now TM1 users have mostly used Excel and been very happy with it. From 9.4 onwards TM1 is now a C8 source. I'm not aware of this being used much yet but it's early days. One issue holding it back may be that (in our experience) 9.1 and 9.4 have a number of issues and we are currently recommending 9.0SP3U9 for clients.

I'd love to take part in a competitive trial of TM1 vs a warehouse approach to this kind of problem. I'm pretty confident that on a level playing field we would walk it.

(Not that I'm against warehouses - they are a great place to lift data from for TM1. And there is the whole data quality issue as well.)

[blackadder]

Ah, this takes me back to the happy days at Adaytum just after the Cognos takeover  8)

I have quite a background in this area, both at Cognos and independently. I spent 12 years working with Cognos BI then 6 years with Adaytum/Cognos/IBM EP. As a result of my background, after the acquisition I became 'the EP/BI integration guy', and a fair portion of the official product documentation on Reporting from Planning was originally authored by me.

One of the things that always amused me in that role was how protective people were of 'their' products. The integration of Cognos and Adaytum opened up some fantastic opportunities, yet people who used BI were sometimes dismissive of EP (“Its just Excel on steroids”) and EP people often struggled to fully embrace BI (“its too technical ...whats wrong with Excel or our own integrated reporting tools?”). The real truth was of course somewhere inbetween.

So now it seems that history could be repeating itself with the TM1 acquisition, as a whole new group of finance people start to come to terms with everything which is possible in a BI environment. The TM1 demo I was given at a conference last year enforced this feeling - the chap gave a great demo but hadn't quite latched onto the synergies, only showing the reporting tools which come in the TM1 box. It reminded me of some of the Adaytum Analyst Manager demos I saw being given to Cognos people after their acquisition - nicely integrated and not bad for an independent vendor, but a little embarrassing when compared with what Cognos was capable of (and its moved on even more since then).

In my opinion, we should be embracing the integration and stop trying to compete. All the things in dusherwo’s well-worded post described his preferred toolset (TM1), but if you substitute 'TM1' with 'Cognos Planning' the post would still have been entirely correct. The products aren't that different in concept or in the applications they can address, although there are undoubtably some that each can address better.

On the 'warehouse' discussion, both TM1 and Cognos Planning offer Excel reporting, and inevitably Cognos8 BI supports direct live access to Cognos Planning models, so in theory you don’t need a reporting database/warehouse. But in the real world most people end up realising that any other solution is a compromise for a whole host of reasons. Its so easy with the latest incarnation of EP/BI integration that it doesn't usually make much sense to do it any other way.
...and theres enough material in those last two statements to justify another post some other time when I'm a little less busy!   
In the meantime, get your local partner in for some advice from seasoned professionals who have done it before.

Having used rules-based OLAP tools before I’m quite excited about what TM1 could eventually bring to the table in the IBM/Cognos Planning world, although based on past experience it could be a few years before we see any serious integration. I sincerely hope that there will be a place in the IBM stack going forwards for the best parts of both product sets. The next few years are going to be very interesting.

[SomeClown]

Nice summary.

The TM1/Planning jostling for position is exactly the same process as the Finance/Adaytum jostling after the Adaytum acquisition.  To CF's credit, multiple attempts to kill it outright failed (it's a great product).  The same will likely occur with Planning (and in my opinion, already has, in some degree).

It seems that who is ever is running the show (and it's musical chairs, so it's never one individual), cannot get their head around the idea that products have strengths and weaknesses.  There will never be a one-size-fits-all, despite their every wish that it would be so.  Clients will have greater success if they receive accurate assessments of tool fit for the solution they wish to receive, rather than a religious/marketing slant based on personal bias or experience.   It's not easy to ramp up to be able to deliver this assessment, yet it's critical in a competitive sales situation.

[Gunes]

Mr Blackadder - spot on! I couldn't agree more. Next few years are certainly going to be interesting.

[deneme]

Hi All,

I initially wanted to write as a reply to this topic, but later I decided to make it a new topic to discuss more with collegues. Please find my reply here and I would appreciate your responses.

http://www.cognoise.com/community/index.php/topic,6525.0.html

The topic is "Licensing Model on Acquisition/Merge of Competing Products"

Best regards,

[jan.herout]

Problem is that sometimes you need to have "reporting capability" in order to prepare plan. This can hardly be replaced by publish & reporting functionality - or, better to say, such replacement is VERY frustrating for end user.

This leads to hybrid data input & reporting models in Cognos Planning.

In my point of view, technology should follow functionality requirements, not the other way around...

[OLAPBPMguy]

I'm not sure whether this deserves a new thread but this existing one seemed the most relevant ...

I'm interested that there has been so little debate on EP vs. TM1 here, perhaps it is due to the TM1 community being elsewhere?

To me the announcement of "Cognos TM1 Planning" for release later this year seems to be a game changer, it's not theoretical anymore, the writing is on the wall.  My understanding is this is basically the 8.4 Contributor front end with TM1 as opposed to Analyst as the modelling engine, does anyone understand differently?  This would seem to mean that the current EP product line has reached the end of it's life?  So what do people think about that?  Enough people must have played with both tools by now to have some relatively informed opinions on the merits of each product, it has been more than 2 years after all.

If this does mean what I think it does, it also means a problematic upgrade path after 8.4 for current EP customers.  Unsurprisingly IBM have been quiet about this.  I have seen EP models converted directly to TM1 and heard talk of IBM Engineering working on an automated model conversion tool.  However from everything I have seen a direct conversion may get you a working model in TM1 but it will be a pretty lame one that fails to benefit from the product's strengths.  To get the full benefits "upgrade" probably means "re-implementation" and that's going to be scary for most customers.  Anyone else's thoughts on that?

[JaromirSeps]

Hello,

I've seen some information about the next-gen plannig product and was looking at some TM1 demos and documentation. And you are right about the TM1 as the calculation engine and Contributor as data collection tool.

I think a re-implementation on most of models will be necessary. Maybe we will be able to use the converted model as a base, but I doubt that. Planning was not able to combine more dimensions in the calculations & there are size limitations. So we were bypassing this by redundancy in the calculations, merging or splitting of dimensions, etc. Now, if I would like to get a good TM1 model, I think the best way will be to start from scratch. Which means a lot of work.

I also doubt, the product will be ready for deployment in the first versions, so we will delay any upgrade for at least a year or more after the first release. There is still a lot to do on the merging side, from what I understand. The TM1 does not have some features of planning, like fancy workflow, d-links, admin links, manager, scalability on the server side, BIFs,...  I think v. 8.4 is the ideal for now.

But if everything goes all right, there are interesting times ahead :)
Jaromir