Planning Analytics

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):

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.

When you build an Earned Premium model, you start with Written Premium data about your existing customer base broken out by Renewal Month, product, geography etc. Then you apply assumptions about renewal rates (cancellations), new business and term length (which may vary, for example, by product). Your model takes all this and projects future Earned Premium for you, by month. If you have sold ten thousand 12-month policies, and are modeling at the policy level, the calculation shown above takes place 10,000 times, and projects 120,000 Earned Premium values. And keep in mind that Earned Premium is but one line-item in your plan.

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.

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.