TM1 Forum

Morning folks!

Does anyone have any actual practical experience of rolling out AI forecasting in PAW and it's limitations?

I've been experimenting with it for the past half a day and I'm wondering whether it's going to be useable for our situation;

The business has a cube storing KPI information and are keen to adopt an AI forecast approach. The cube stores a number of daily KPI metrics which are defined by dimensions such as country, product, billing cycle etc.

Findings (only limited to univariate forecasts so far);
1 - process works quickly when selecting single combinations of n-level elements
2 - works okay when one dimension element is a consolidation with only 8 children. However - I was hopeful that the consolidation would be the aggregation of 8 separate n-level projections. It isn't - the forecast is generated only at the consolidated level and is then spread downwards to the children
3 - attempting to run the forecast across multiple consolidated elements and I'm hitting major issues with the time taken (I'm just attempting to run a forecast for one KPI and one country with remaining dimensions specified as consolidations.

In summary (putting all of the detail above to the side) - has anyone managed to roll this out for anything other than the smallest use cases?

Note - we are running IBM PA on SaaS. I've checked the version of our TM1 server and we need to get IBM to perfrom an upgrade which will enable some additional Forecast Spreading options - hoping that has a positive impact!

Cheers!!!

Martin

I haven't touched it and from what I am reading above, I should continue that for a little while

Well I am beginning to wonder whether anyone out there actually uses this functionality.

Posted the same questions on a Planning Analytics LinkedIn Group at the same time - viewed by 170 people and no replies!

One my client uses it. Not just users "by themselves", as it is stated in descriptions: you need to provide them a cube with continuous one-dimension timeline, rolling actuals+forecast data, copy and supporting processes.
Many users+many time series: works fine. It's just 9 ES implementations, so they should work super-fast. If not - check your:

1. Rules for actual data - in case that they are calculating too long
2. Feeders from forecast cells - in case that data input itself is slow

It works well for smooth time series, where you do not need to include external factors (eg promotions)

For consolidations - yes, it will make forecast for consolidated element and split it to children ("relative spread" is a must, +"Seasonality" is preferred) - this is best-practice for hierarchical forecasting: https://otexts.com/fpp3/hierarchical.html

The main CON I've faced here - is it's inability to work with our favorite "READ on C: level" setup: it will throw error when it tries to spread forecast of consolidated element to it's children. So you need to either make users make forecasts on N: elements only, or to leave C: level to be WRITE-accessed. And with this, somebody will for sure write manually a number to super-consolidated cell and explode server. We had a related ticket with IBM: they said it's by design. There is a workaround here, I can describe it if somebody needs it.

Elessar wrote: ↑Mon Apr 29, 2024 3:31 pm The main CON I've faced here - is it's inability to work with our favorite "READ on C: level" setup: it will throw error when it tries to spread forecast of consolidated element to it's children. So you need to either make users make forecasts on N: elements only, or to leave C: level to be WRITE-accessed. And with this, somebody will for sure write manually a number to super-consolidated cell and explode server. We had a related ticket with IBM: they said it's by design. There is a workaround here, I can describe it if somebody needs it.

That's really helpful thanks Elessar - wil read through forecasting 'best practice' link.

One question - regarding your '"READ on C: level" comment - just to be clear; Are you saying that you've disabled 'Consolidation TypeIn Spreading', but this needs to be enabled for the forecast spreading function to work for end users?

Thanks!

M

Martin Ingram wrote: ↑Tue Apr 30, 2024 9:21 am One question - regarding your '"READ on C: level" comment - just to be clear; Are you saying that you've disabled 'Consolidation TypeIn Spreading', but this needs to be enabled for the forecast spreading function to work for end users?

Well, any option forbids forecasting on C: elements: ProportionSpreadToZeroCells, 'Consolidation TypeIn Spreading', READ in CellSecurity or ElementSecurity cubes.
In my particular case it is "IF (ISLEAF=0 & DB(cube itself) = 0, READ, continue)" in }CellSecurity