If you are reading this blog you have either started the journey of implementing your TM1 models in Anaplan or are considering the move. If so, you have come to the right place.
Organizations either love or hate TM1, there is never a middle ground. TM1’s roots and general current architecture date back to the 1990’s, which is the underlying reason organizations hate TM1. With an architecture that is 30 years old TM1 simply can’t keep pace with the competition.
The leading Corporate Performance Management (CPM) solutions are now cloud based; Anaplan, Host Analytics and Vanguard Software all release new functionality (upgrades) 3 – 4 times per year. Upgrades that are seamless, transparent and effortless to clients; TM1 requires significant effort by clients to plan and execute upgrades that may require hardware and operating systems upgrades.
Complexity, another common complaint about TM1 is that it “is complex” and cannot be maintained by business users. Though, particularly when compared to cloud based CPM solutions, building rules in TM1 is complex, it is important to understand the complexity. Cube based architectures are inherently susceptible to exponential growth; the size of a cube is determined by multiplying the number of items in each dimension. For example
- Geography 75 items
- Accounts 100 Items
- Months 39 Items
- Versions 5 Items
- Measures 20 Items
75x100x39x5x20 = 29,250,000 cells
Adding a single item to any dimension results in exponential cube growth, for example if we add 75 items to Geography and 2 additional versions
150x100x39x7x20 = 81,900,000 cells
It is this exponential growth that is the achilles heal of cube based architectures, as cube size grows performance degradation will occur. Further, in memory architectures all have an inherent maximum model size that is dictated by the available RAM.
Exponential growth to cube based architecture is not new. The earliest cube based architectures took different approaches to exponential growth. TM1 was and still is unique and allows users not to manage cube size but to manage cube sparsity. Sparsity is defined as any cell that is either null or zero. All cube based applications advise against large, sparse modules because of the inefficient use of RAM and inherent performance issues. Most cubes have sparsity. Where TM1 differs from other cube based technologies is TM1 allows developers to manage sparsity using TM1 logic. Users can write rules that specifically identify sparsity and “tell” TM1 to ignore sparse cells when executing calculation logic. This approach is the most effective in managing large cubes, and TM1 is the only application that provides this functionality. If your organization has large cubes or models, you may not be able to migrate these to any of the cloud based applications.
Practically, 85% of the use cases do not require large cubes, arguably and based on experience 90% of large cubes are solely for reporting or can be redesigned. If the cube is solely for reporting, consider alternatives better suited for reporting – reporting tools. When migrating from TM1 to Anaplan, taking time upfront to design the Anaplan model is critical. Most, if not all logic in TM1 can be built in Anaplan. The key is to understand how user interaction will be affected when changing the inherent structures of cubes that they are used to interacting with.
Leverage the Strengths of Anaplan
When redesigning your model for Anaplan you should leverage the strengths of this powerful platform. Things like composite hierarchies, numbered lists and built in functions can all aid in the simplification of your new design.
Writing logic in Anaplan is much easier when compared to TM1. There is no concept of a two way rule in Anaplan. Write the rule once and it works, as opposed to TM1, where you write a rule to perform a calculation and then also need to consider the corresponding Feeder statement to ensure you get proper results. Also the syntax in Anaplan is much easier for a user to understand as compared to TM1. TM1 logic is much more difficult for a normal finance user to understand. It almost requires a coding like skill set that most finance people do not possess. The simpler syntax in Anaplan translates to more people (mere mortals!) taking part in the model build process.
Composite hierarchies in Anaplan, give you the ability to have one list act as a parent hierarchy of another list. This allows you to create modules that utilize these lists and cut down on the number of dimensions needed to build each module. It is a different way of thinking about constructing a cube, but once learned it becomes part of the overall approach whenever you consider larger cubes for your model. It also makes data aggregation and reporting much easier to deal with when creating dashboards that are part of the toolset in Anaplan, something that TM1 does not possess.
Using numbered lists is an easy way to get multiple items with the same name in a list. Consider a TM1 dimension. Many times you may have an item that you want repeated in a list with the same description. TM1 does not allow you to reuse a name for an element. Once it is used it cannot be used again. As an example, in a list of products you may have something called 55 inch television. If you had a second item called 55 inch television that needed to be listed because it was unique to a supplier, you could not use it as it already exists. You would need to add a prefix or suffix to that item and know that this new item was the one that was unique to that supplier. Anaplan allows you to have a unique identifier for each element in a list but it can reuse a name as many times as you like. So in our example above we could have two elements named 55 inch television with two completely unique identifiers underneath.
Quite often when speaking to users we will say that “the great thing about Anaplan and TM1 is that you can build anything in them. The bad thing about Anaplan and TM1 is you can build anything in them.” Although that may seem funny it is very true. The thing you want to consider is, just because you can build it, you should ask yourself “Should I build it?” We all jump headfirst into the pool when we are considering building multidimensional cubes and modules. Everyone always wants all the detail no matter how big the cube or module. What you must consider is the useability of the cube or module and what you are asking the user to deal with. Consider a large cube with 6 dimensions. You have rows and columns and then an additional 4 context filters to deal with. Now consider a cube with 7, 8 or 9 dimensions. That is a lot more filters to cope with. It becomes very easy to get lost in a cube quickly. So leveraging some of the strengths of Anaplan can give you a much leaner and more efficient model and an overall better user experience. And after all, isn’t the user experience what it is all about?