Planning to TM1 using Performance Modeler

[Jorge Rachid]

Hi Everyone!

I will have to do a migration from Cognos Planning to TM1 and I pretend to import the .XML file into Performance Modeler to help me developing the model on TM1.

After doing this, it is possible to use TM1 Architect to build the model or it is necessary to keep using Performance Modeler for that? There is also a different way to import the xml file and use Architect?

Thanks in advance.

JR

[lotsaram]

Hi Everyone!

I will have to do a migration from Cognos Planning to TM1 and I pretend to import the .XML file into Performance Modeler to help me developing the model on TM1.

Yep can do it but I wouldn't necessarily recommend it. A conversion of the dimensions might be a start to get the project rolling but typically things like DLists & ELists don't really translate to TM1 dimensions. In TM1 the dimensions can accurately reflect the business structures without any restrictions like packing multiple structures together or leveling. When it comes to cube design the conversion wizard is even less help as you don't want your TM1 design hampered by cognos planning artifacts. This will just lead to a bad TM1 design (not necessarily one that doesn't work, but certainly one that only works 10% as well as if it were designed properly). Definately start from scratch when it comes to putting cubes together.

So my 2c on the xml export & import: useful for a quick extraction of dimensions to feed into a PoC model, but start from scratch when it comes to the real implementation.

... is necessary to keep using Performance Modeler for that? There is also a different way to import the xml file and use Architect?

Most definitely avoid performance modler. The only useful thing in it is the model transfer, but even that only works reliably on small simple models. Unfortunately none of the traditional TM1 interfaces understand xml.

[Jorge Rachid]

Very nice.

Thanks for you reply! I will do it.

[mvaspal]

Hi
I am 100% with lotsaram; forget the automatic migration, or at very least rethink the model how you can improve it with TM1.

I have done >5 migrations from Planning to TM1, some of these were fairly big models, we redesigned the model every time as Planning models were designed at least so much to meet technical limitations as to meet business needs, while TM1 models can be designed more after business needs. Just one example: 20 Contributor apps in Planning could be replaced by 3-4 cubes in TM1.

[Trevor MacPherson]

I know folks who are quite happy with the model migration tool - for a quick PoC or playground to start building with, but as everyone else indicates, that shouldn't be the basis for the model. I saw 3 different customers in one month recently use the same assumption modeling approach in TM1 as they had in EP, with unpleasant consequences. I made a video just for that problem, but there are many other examples where trying to replicate what was in EP will only lead to issues.

On the specific question of using Architect to develop the model after migrating via PM, there is no specific problem with doing that. While the source is XML, the objects are created via API, and live as any TM1 object would after that - they may have additional decoration based on Performance Modeler's approach to attributes, dimension types, etc..., but that doesn't prevent you using it in Architect, and the only caveat of using both modeling tools on the same model is in TI editing, and you won't get TI's from the migration anyway.

Note well that there are many things you won't get from the migration tool - D-Cube based A-Tables & Access Tables (there is no 1-1 equivalent), Analyst-only models, etc... but I've used it on probably 20 or 30 models with about 70% of objects migrated. It can definitely help get people thinking, and get a project kicked off - just as long as everyone knows it is a project to re-build, not a push button migration.

[tomok]

I've done a lot of TM1 projects over the years and in every single one of them, the time spent actually building dimensions and cubes is dwarfed by time spent analyzing the business requirements, creating a solid design, implementing the model, and tweaking after the fact. Why anyone would use Performance Modeler to "upgrade" a CP system to TM1 is beyond me. All it's going to do is lead you down a less then optimal path all to save a few hours of cube building.

[blackhawk]

I totally agree with "tomok", in fact, there are a lot of things you have to do in your TM1 models to get them to "fit" into the paradigm that contributor operates which go against the natural behavior of a good clean TM1 model. I find many customers appreciate the true TM1 model approach to what comes out of performance modeler. There is too much overhead involved and too much is obfuscated by using the modeler, that when it comes time to turn it over to someone else, they get confused about what PM is doing and how they can incorporate their new business requirements into the system.

When we show them Perspectives/Architect in a clean model design, the lights come on and they get it. They know exactly how things operate, where to go to change them as the business morphs. When they get an error in something they are trying to do, they know exactly where the issue is and then work through the issue. When using PM, they get failures on generating the application and sometimes all it takes is a delete and re-create and the problem goes away. Or they try to create a new application for a parallel release and can't because the approval dimension is already in use by another application.

No offense, but the only thing, in my opinion, that keeps PM alive is that it enables workflow. If workflow could be done in TM1 using Perspectives/Architect I don't think any of our customers would even consider PM. There are definitely some nice bells and whistles in PM, but they don't overcome the reduction in usability for the basic everyday modeling/administration. I also realize Perspectives/Architect is going away with Planning Analytics, I just pray that whatever replaces it, that it does so completely and not partially. It would also be nice not to be in Java (though I don't suspect that it will be otherwise). Java UI just feels clunky and slow. Just my 2c.