# Planning Analytics

View Only

## IBM Planning Analytics Rules vs TurboIntegrator: which should I use?

#### By Ann-Grete Tan posted Tue June 16, 2020 06:27 PM

In a prior post titled “Modeling your Business with IBM Planning Analytics TurboIntegrator and Rules”, we discussed how the powerful business modeling features of IBM Planning Analytics (powered by TM1!) are underrated as a differentiator.

Here are some general guidelines for building model calculations in Planning Analytics (PA):

 Calculation Type Example(s) – in Rules pseudocode Rules vs TI Recommendation Addition or subtraction – along the same dimension. Weighting, or multiplication by a constant. [All Regions]=[North]+[South]   [Circumference]=[Radius]*6.28318 Always use a dimension aggregation (C: element) anytime you can. It is by far the most performant approach. Any calculation where the relationship between the number of input values and the number of output values is linear. [Amount]=[Rate]*[Volume]   [Price]=[Cost]/[Units] Use a PA Rule. Any calculation where the relationship between the number of input values and the number of output values is uncertain (assumption-driven at a detailed level) or can grow exponentially. [Allocation]=[Cost Pool]*[Driver]/[Driver Total]   Also: See examples below It depends. If the cube is smaller and sparser, try a PA rule. Business logic can be easier to express in PA Rules than TI script, and the real-time calculation makes it easier to test the logic and clarify requirements. Consider writing TurboIntegrator (TI) script for production use if performance becomes a problem, after requirements are understood. Cross-cube calculations, for example to lookup currency exchange (FX) rates or plan assumptions in a separate cube. Another use-case is when there are different sub-models calculating portions of something (like an annual budget), and the totals from each sub-model are summarized to a central reporting cube. [USD]=[Local Currency]*LOOKUP(FX Rate)   [Salary Expense]=LOOKUP(Total Salary Expense in Workforce Planning Model)   Also: See second example below It depends. If the calculation has a linear relationship between inputs and outputs like the first currency translation example, a PA rule is probably the best way to go. In the second example the Total Salary Expense value is being pulled from a separate cube. If the LOOKUP cube has the same dimensionality as the RESULTS cube, a PA rule may be fine. But if the LOOKUP cube has a dimension (for example an Employees dimension) not present in the RESULTS cube, and that dimension I slarge or growing, you will probably only be able to use a PA rule when the model is small without seeing degraded performance. Provide a starting point for people to modify, or to “freeze” a snapshot of a scenario to be compared against other scenarios. Examples: Use an AI-powered predictive demand forecast to generate a baseline units forecast that can be modified. Complete a first version of the annual budget and save all the values, before working on the next version. Use TI script which runs and posts values.

Keep in mind that there is always a trade-off between how easy it is to express and maintain a calculation, and how it performs. Sometimes it is worthwhile to sacrifice a little performance to reduce calculation complexity. It is not unusual for businesspeople (who understand the business requirements better) to feel more comfortable with PA Rules, while programmers (who may not understand the business requirements as well) to feel more comfortable writing TI script. When making design choices, ongoing maintainability, change management and the process of communicating business requirements must be considered. The total cost of ownership matters because business models always evolve and are never static.

Here are two real-world examples of business modeling requirements, and their associated design considerations:

## Example 1: Earned Premium Planning for Insurance industry

Revenue and actuarial modeling for insurance companies typically begins with Written Premium. When you pay your annual auto insurance premium bill, that’s Written Premium. Written Premium is then earned out over the term of the policy as Earned Premium as shown in the example below.

In IBM Planning Analytics you have a choice of doing the Earned Premium calculation using either Rules or TI.

If you do it with Rules, you can play what-if games in real-time with your assumptions, but risk slow performance if your model captures data at a highly granular level of detail, because of the exponential nature of the calculation. At this point you would opt for writing a TI script, or taking a creative hybrid approach. There is a difference between a model that calculates Earned Premium for 100,000 customers, versus one that summarizes customers to 50 Regions.

Things to consider:

• How detailed do you really need your model to be? Sometimes additional detail does not materially improve accuracy for planning or forecasting purposes.
• How will the model be used, and by whom? Do you have many end users playing with assumptions for their slice of the business, or will the model only be used by corporate finance?

In most products that compete with PA, batch scripting would be the only option for this kind of model, regardless of the granularity. This can severely limit real-time interaction with the model and increases the dependence of business users on expert developers. Even if you decide ultimately to use a scripting approach in PA to improve performance, prototyping with rules to clarify requirements has immense value in reducing development time and expense.

 NOTE: Earned Premium modeling is an instance of “triangles” modeling which is common in actuarial models in insurance. Loss Triangles are another common example. The triangle shape comes from the pattern created by the data when the policy period is arranged against the reporting period as shown. In this simple example, imagine selling one auto insurance policy per month starting in May. We therefore report \$100 of Earned Premium in May, \$200 in June, \$300 in July and so on. PA is very well suited to this kind of modeling.

## Example 2: Workforce Planning for any industry

While there are many ways to model labor expenses, this Workforce Planning example refers specifically to by-employee or by-position planning of employee costs such as salary expense, merit increases, bonuses, benefits and payroll taxes. These models typically begin with a data feed from Human Resources that looks something like this:

The Workforce Planning model uses this data as a starting point for the annual plan or a forecast, and projects monthly expense for a variety of employment related expense accounts based on assumptions captured elsewhere in the model. Unlike some competing products, PA allows you to store text (string) value in its cubes, so the data capture and the downstream analytics are seamless. Examples of assumptions used in Workforce Planning models include benefits rates by region, payroll tax rates, merit increase month and average rate, bonus rates and currency exchange rates. As part of the planning process, managers (whose access would usually be restricted to the people they manage using security) may plan for new hires, terminations and transfers. PA’s powerful and granular security model means that all similar data can be stored in a single cube. You do not have to build separate cubes to segment data across different audiences, as you need to do in other products. Once the assumptions are set, the model automatically summarizes employment expenses so they flow directly into the income statement.

In PA, Workforce Planning models are typically built using PA (TM1) Rules, allowing managers to see the impact of the changes they make on their departmental budgets immediately. The summarization process wherein the total expenses (for all the people) flow into the income statement budget can be done using either rules or using a TI batch process, depending on the size of the model. In QueBIT’s experience, TI is usually the better choice for summarization except in the smallest models.

Generally, since PA Rules are often quicker to write and easier for a businessperson to grasp than TI script, we prototype functionality using PA Rules as part of an agile approach. Once the requirements are well understood, expensive rule calculations can be replaced by TI script to improve performance.

 NOTE: Expense allocations, which are a frequent requirement in reporting applications, follow a similar calculation pattern to both Workforce Planning and Earned Premium models, and are therefore subject to the same design considerations.

#pa-home
#pahome