Posts on Applied Dimensionality

Planning analytics modeling - Allocations

Mon, 24 Nov 2025 01:59:54 +0000

Another one of the ‘what do a I think about when doing X in PA’ posts (see the previous one on General Ledger), this time covering everyone’s favourite topic: Allocations!

I rarely encounter a planning system without an allocation component in it, it’s such a fundamental step to understanding profitability or ’true costs including overheads’ for a product / cost centre / project / process or any other object.

A few design considerations I usually think of when discussing allocations:

What is the ‘grain’ / ‘dimensionality’ of the allocation? Are we allocating cost centre expenses to a product or, say, freight costs across different products? What are the source / target dimensions?
Are we talking about multi step allocations (i.e. Cost Centre A allocates to B and then B transfers the full cost to C)? Ideally you don’t want multiple steps, but they can be required, especially anywhere around manufacturing
Who is initiating the allocation process (sender, receiver, schedule?) and whether there’s a workflow required to notify / approve by receivers? The more complicated approval process is, the harder you need to think about overrides you need to build-in to circumvent it (think people being on holiday / in a meeting when change needs to be made, last minute board meeting adjustments, etc). It’s worth having a separate ‘sandpit’ scenario if the approval process is fairly stringent to allow for quicker modeling. Notification + tracking of allocations is my default suggest and I push-back on building an approval process, as it almost always gets removed or disabled later.

Here’s how I see an allocation model blueprint:

No rule based allocations :) Everyone starts with allocating via rules (rules are powerfull and traceable, yay, processes are complex, boo), but it’s never going to be fast
Allocation is based on the input of % of from / to – even if it’s driver based (for example, rent is allocated proportionally to area occupied, or based on, say, revenue). I always start with building with % input and upload and any driver based allocation is added on top by prepopulating the %s
Aim to create a full record of to and from allocation details. It’s a lot of data, but totally invaluable for reconciling the results and building trust in the system. So, for example, if we’re doing a cost centre to cost centre there would be a cube with cost centre from, account from, cost centre to, account to breakdown. Allocation step is another dimension in the multi-step allocation scenario. No rules in such cubes.
It’s worth to discuss the threshold of significance with the end users and build some logic to stop allocating below this threshold. Having 0.0000001$ allocations only slows things down and brings no real value.
I’m trying to make allocation process to run as fast as possible (performance is my quirk, maybe because it’s the easiest to measure), which is mainly by limiting the amount of source data read and ’tighten’ the allocation loops (by pre-populating ‘possible’ intersection subsets), all the tips from the performance post apply. Running a process for allocating each source ‘record’ is an anti-pattern I unfortunately see way too often, the overheads of starting a process adds up fast.

Planning analytics modeling - General Ledger and surrounds

Wed, 23 Jul 2025 01:59:54 +0000

“I’ve had this post in draft for years, and it’s a format I haven’t tried before: a set of notes on how I approach designing General Ledger (GL) and Finance models. This isn’t a ‘how-to guide,’ but rather a collection of my personal considerations. I hope some of you find these insights useful.

When starting a project with the Office of Finance, it’s often best to begin with the objects like the General Ledger (GL), P&L, or Trial Balance. Because these are so closely tied to actuals, you can learn a great deal by examining how the financial module is structured within the ERP system. It’s a really good starting point, because you can get to a production ready result in days, show value by enabling finance office to capture forecast and provide consolidated results, get everybody onboard overall journey and go onto harder / more interesting bits.

My overaching philosophy these days is that I’m trying to build the systems that ’last’, so they won’t be used by the people I’m currently working with and won’t be supported by our team :) This means that things have to be as simple as possible so that they’re easy to understand and have fewer points of failure.

Main GL cube

With this in mind, the main cube in finance module always closely mimics the actual GL object in ERP, typically with the following dimensions:

Version - surely we want multiple scenarios
GL Account - more on it below
Currency - this is one exception to the main ‘keep it very simple’ rule. Even if you don’t need multi-currency now, add it with everything being ‘Local Currency’ as adding it in future is a lot more cumbersome. I’ve personally had to work around the absence of a currency dimension in these cubes multiple times just this year :)
Cost Centre - or any other dimension(s) that identify the actual posting in your source system (e.g., Company, Profit Centre, or Cost Centre). These can often be multiple dimensions.
Measure - this is the most interesting dimension, I try to make it meaningfull by having a separate element for every data ‘source’ that we have (e.g. an ‘HR’ element if there’s a HR portion of the model, capex, revenue planning, etc). The goal of having separate elements is to be able to quickly identify source of data and allow reconciliations. Having an additional Adjustment (or multiple such elements) allows overlays on top of the other modules data for the last minute changes or future postings in a month-end reporting process. TM1’s greatest strength is the ability to create a purpose-built model for a part of revenue and expenses components and this dimension is where all these models ‘plug in’.
Time dimension - single year and month or week dimension with virtual hierarchies to provide different time consolidations for reporting

Planning / forecasting is often done on a more aggregated level of data than actuals. For example chart of accounts has 20 accounts under Office supplies, and nobody has the time to forecast pens and pencils separately (or same story around cost centres). This leads to a few potential solutions:

Selecting a ‘placeholder’ account to house forecast data (e.g., all forecasts are recorded on the ‘pens’ account, while actuals are assigned correctly).
Creating dedicated ‘forecasting’ accounts within the chart of accounts specifically for forecast data (e.g., Office Supplies - Forecasting).
Allocating consolidated input based on an actuals profile (e.g., last month, last year) to distribute data among the more granular accounts under ‘Office Supplies’.

I prefer to:

have actuals at the granularity that allows easy reconciliation and limits the number of trips to the ERP system for reporting. For example: if we agree that Office supplies is the forecasting level and limit the Account dimension in TM1 to this level and it means that actuals vs forecast reporting will require people to pull detailed by account actual breakdowns from ERP – that’s a design fail in my book.
capture all user input ‘unmodified’ to allow to trace ‘who input what’, which rules out allocating on input option. I like the ‘forecasting’ accounts approach a lot and advocate for it as it allows to create a ’lowest’ granularity forecast vs actuals reporting and is easy to trace / reason about.

GL breakdown

And another cube that I always put it in is a ‘Line-Item’ breakdown for any GL cube cell, that would normally have a slightly reduced set of dimensions (reducing the number of dimensions is the only reason to separate if from the main cube), for example:

Version
Cost centre or anything else identifying the actual posting in your source (can be multiple dimensions, i.e. a company and a Profit centre or Cost centre)
Line item - 1, 2, 3, you got it
Time + inputs dimension - a set of picklist inputs (for example Account dropdown) to populate in GL cube, comments, descriptions + all the months / weeks as in the usual time dimension

This cube allows capturing all the extra details that you want for a single account in GL cube, for example, specific trips for travel budget or different projects for the consultancy costs in a very simple way. The data from this cube will populate GL cube (in a special ‘breakdown’ measure element), so you can tie them beack together.

It’s important to note that this cube typically does not contain actuals, as line items generally cannot be directly linked to actual data items. While loading actuals might be feasible if one of the dropdowns acts as a project code or similar identifier, at that point, it would likely be more efficient to create a dedicated dimension and a separate cube for that purpose.

If the main cube we’re building involves balance movements, you can easily integrate debit/credit dropdowns to generate movements based on a single line of input.

This breakdown cube is incredibly powerful. You can literally start with only this cube and then analyze the inputs from your initial forecast to identify which accounts or areas are most frequently used or carry the largest monetary values, these are the prime candidates for more detailed modules.

Cognos Analytics - Everyone has an Admin license?

Thu, 03 Jul 2025 01:59:54 +0000

To everyone’s surprise all users were flagged up as Administrators based on the assigned capabilities in the last couple Cognos Analytics license audits I was part of, so I’d thought I’d write this up.

It’s as easy (or as obscure) as 1,2,3:

An obscure Specification Execution capability is treated as an Administrator-level capability although it’s not under Administration group of capabilities:

Specification Execution

This secured function allows a user or Software Development Kit application to use an inline specification. The Specification Execution secured function is counted as an Analytics Administrators licence role.

A built-in Cognos Role called Data Manager Authors is granted access to this capability by default.
Data Manager Authors includes All Authenticated Users role by default

Hey presto, All Authenticated Users are counted as Administrators.

I doubt it’s intentional, more likely that this capability was required to run the Data Manager ETL jobs and this setup was never removed, even though Data Manager is long gone (I did like it, btw, a very simple tool). But nonetheless: please check your capability assigments and disable all the roles you don’t use (like this Data Manager Users) to make your audits boring.

While we’re at it, the built-in License usage report report is very usefull, bearing in mind that:

it records the user license based on the capabilities based on the time they last logged in, so capabilities adjustment wouldn’t be reflected in this report untill users re-login
if a user is no longer active – the only way to reset the license count is to remove their user profile from Cognos Analytics, which will remove all personal objects / schedules
whispers content_store.CMOBJPROPS33

Simple planning analytics benchmarking model - tm1bench

Tue, 29 Apr 2025 01:59:54 +0000

Been playing lately with understanding some performance aspects of PA (obviously comparing v11 vs v12, but this post won’t be about this).

Ideally you should be always be comparing your specific TM1 model on different software versions, hardware, etc, but sometimes it’s worth having a very simple model that doesn’t contain any sensitive data, but is ’larger’ than the sample models.

So that’s exactly what tm1bench is: a very simple model that can have a lot of data.

It’s a very simple model with just 3 cubes:

Sales by Customer, Product, Month, Version with some rule based calculations
Price by Product, Month, Version
Discount by Customer, Month, Version

The number of elements in dimensions and amount of data is parametrised in tm1bench Setup process, so you can set up a sample model with 10m, 50m, 100m or more cells in Sales cube to run your tests against.

There’s a couple of tests included:

loading data single threaded - tm1bench Test sales data load
loading data in multiple threads - tm1bench Test sales data load parallel
reading data from Sales cube to check how fast rule calculations work - tm1bench Test sales data read

Notes on security setup in Planning Analytics

Thu, 27 Feb 2025 01:59:54 +0000

I’ve been tweaking a few security models in PA recently, so it’s a good opportunity to jot down some thoughts. Here’s a list of ideas in no particular order.

Testing security

First of security is very boring and quite hard to test & verify, so it often gets overlooked. You need an ability to ‘see’ things as a user and PAW has no built-in impersonation feature (although there’s a REST API call for it, so it’s possible), so having a few dummy accounts you can login to is a must. A simple process of copying groups from a target user to a dummy user is very helpful.

TM1 security groups

Data vs object groups

I usually separate secuirty groups in TM1 into 2 categories:

groups that define access to TM1 objects (cube, dimension, process security) – used to call them “application” groups, sometimes “functional roles”, sometimes “object” ones.
groups that define access to TM1 data (element security) - something along the lines of “data groups”

This split allows you to keep security definitions contextually split and you can sync the type 1 groups between different environments, whereas type 2 groups are environment specific.

PAW groups usually map quite nicely to ‘application’ or ‘functional’ ones, as they define books that people have access to. So you have ‘Revenue forecasting’ PAW group that will translate into a set of ‘what objects should they see in TM1’ group. Syncing PAW groups to TM1 streamlines this step (still waiting for PAW security API, sigh).

Groups by user or groups by object?

I try to keep number of groups in TM1 to some reasonable amount, so if I’m looking at a design that entails thousands of groups, I’m starting to question whether it’s easier to pivot it around and have a group by user and assign security that way. A large number of groups makes everything security related slow(er), so it’s better to keep it low. If you end up with groups by user approach – include a process to delete old groups as they will accumulate.

You should try to have a group per some entity (cost centre, project) and avoid creating combination groups, like CC_X_Account_Y – that’s usually a sign of some odd assumptions.

Cell security

I still run into ‘Cell security rules make things slow’ concept every now and then. Overall CellSecurity make things slow in 2 cases:

when you’re using input data to define cell security – this drives extra calculations in PAW as I wrote about here
when you have users with a lot of groups as PA server needs to evaluate Cell Security for every group before calculating the final level of access that user will have. This is where those ‘object/functional/application’ security groups come to help again – writing rules against only this group (['Revenue forecasting']=S:...) will make the rules very specific and fast.

Avoiding SecurityRefresh

I try to avoid SecurityRefresh as much as I can, especially if there’s a chance it’ll be ran during the normal hours (e.g. users assigning security). SecurityRefresh is a global locking operation (it’s quite bad when the system takes an unexpected breather for all users without any clear reason - it erodes trust) and it will get slower over time, so having a system without it just alleviates the need ot think about it.

The common reasons for needing a SecurityRefresh:

Using rules for Element Security – you can and should use the TI with ElementSecurityPut instead, there’s rarely anything that dynamic in the security that requires rules and moreover they won’t update until someone presses a button that triggers a SecurityRefresh. This button might as well do ElementSecurityPut instead :)
You’re populating ElementSecurity or ClientGroups via a TI and want to be able to handle ‘removal’ of security. E.g. say user A is in a group G now, but in your security source this blank intersection. This is commonly done by doing a ViewZerout of a security cube, writing data to it (or doing AssignClient’s / ElementSecurityPut’s) and then running a SecurityRefresh. SecurityRefresh is required because otherwise PA server wouldn’t ‘see’ that security was removed during ZeroOut.

An alternative approach (only if you really need refreshes during the day), can be to create a cube that would calculate the required changes (including removals) and use it a source for applying security. Using }ClientGroups as an example, you’d create a

cube like ClientGroupsDetectChanges with dimensions like:
- }Clients
- }Groups
- Measure
  - Apply changes - consolidation with +1 / -1 weights to define whether to add or remove user
    - Current - write from }ClientGroups
    - Future - write from your security source

And then a TI using Apply changes measure as source to AssignClientToGroup or RemoveClientFromGroup

Other

SecurityOverlays

I haven’t used SecurityOverlays until a recent project, where they were used to improve CellSecurity performance. Overlays were used to define security on some dimensions and therefore allow a reduced number of dimensions in CellSecurity. Rewriting those CellSecurity rules made it Overlays redundant, so we removed the overlays :)

I do see the potential use cases for Overlays, but it’s adding another thing to think of in regards to security and it’s hard enough as it is in most cases.

DataReservation

I had a lot of fun with DataReservation functions on every model that was using TM1 Applications / Contributor and never had a use for it outside of TM1 Applications. Despite most people thinking that they need ’exclusive’ access to data, they almost never do and having it creates an extra layer of complexity whilst transferring data ownership (e.g. handling people being on leave, last minute changes, etc). Having a transaction log is enough to trace ‘who changed my data’ in most cases. This opens up a whole ‘how complicated your worklow really needs to be’ topic, but this post is way too long already :)