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
Practical experience of PAW AI forecasting / performance
-
- Posts: 55
- Joined: Thu May 15, 2008 9:11 am
- OLAP Product: Planning Analytics
- Version: IBM SaaS - Digital Pack
- Excel Version: Office 365
- Location: Reading / London
- Contact:
-
- MVP
- Posts: 3126
- Joined: Mon Dec 29, 2008 6:26 pm
- OLAP Product: TM1, Jedox
- Version: PAL 2.0.9.18
- Excel Version: Microsoft 365
- Location: Brussels, Belgium
- Contact:
Re: Practical experience of PAW AI forecasting / performance
I haven't touched it and from what I am reading above, I should continue that for a little while
Best regards,
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
-
- Posts: 55
- Joined: Thu May 15, 2008 9:11 am
- OLAP Product: Planning Analytics
- Version: IBM SaaS - Digital Pack
- Excel Version: Office 365
- Location: Reading / London
- Contact:
Re: Practical experience of PAW AI forecasting / performance
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!
Posted the same questions on a Planning Analytics LinkedIn Group at the same time - viewed by 170 people and no replies!
- Elessar
- Community Contributor
- Posts: 350
- Joined: Mon Nov 21, 2011 12:33 pm
- OLAP Product: PA 2
- Version: 2.0.9
- Excel Version: 2016
- Contact:
Re: Practical experience of PAW AI forecasting / performance
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:
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.
Many users+many time series: works fine. It's just 9 ES implementations, so they should work super-fast. If not - check your:
- Rules for actual data - in case that they are calculating too long
- Feeders from forecast cells - in case that data input itself is slow
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.
-
- Posts: 55
- Joined: Thu May 15, 2008 9:11 am
- OLAP Product: Planning Analytics
- Version: IBM SaaS - Digital Pack
- Excel Version: Office 365
- Location: Reading / London
- Contact:
Re: Practical experience of PAW AI forecasting / performance
That's really helpful thanks Elessar - wil read through forecasting 'best practice' link.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.
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
- Elessar
- Community Contributor
- Posts: 350
- Joined: Mon Nov 21, 2011 12:33 pm
- OLAP Product: PA 2
- Version: 2.0.9
- Excel Version: 2016
- Contact:
Re: Practical experience of PAW AI forecasting / performance
Well, any option forbids forecasting on C: elements: ProportionSpreadToZeroCells, 'Consolidation TypeIn Spreading', READ in CellSecurity or ElementSecurity cubes.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?
In my particular case it is "IF (ISLEAF=0 & DB(cube itself) = 0, READ, continue)" in }CellSecurity