I attended a very good session on June 25, 2019, by Kari Hassebrock of C.H. Robinson & Coen de Steur of KPMG that explained how the team experienced performance issues with respect to consolidation / translation in FCCS and the various options they applied to tackle it.
After attending this session, I could get myself re-validate about some of the options that I would first check on any FCCS application when it comes to performance tuning.
Here are some key takeaways:
- Administrative options
- Restructure the DB
- You could also schedule this on you Day 0 of your close like you would do it on any Essbase app to get the DB restructured.
- However in the session they mentioned they have raised an enhancement request to oracle to include this restructuring task in FCCS as a command in EPM Automate for better scheduling. That was good to know.
- Clear Missing blocks.
- FCCS creates empty blocks during consolidations especially during translations. You can clear these missing blocks and may be add it to the process to improve consolidation timing?
- Restructure the DB
- I learnt from these presenters that they have tried to reorder their dimension by recreating application in new pods to see if that helps but in vain. Recreating application seems to be the only way to reorder dimension in FCCS by recreating apps. Although, In Essbase reordering to follow hour glass model helps with performance improvement – it may or may not help in your FCCS application.
- They had only two custom dimensions and heard that reordering didn’t show any improvement. But In my opinion, this is a good option to try on any other application that has more custom dimensions for tuning. And your applications is always different from what the presenters had. It is worth to try.
- As you know with Essbase any custom dimension that is sparse plays a role in the performance. FCCS’s custom dimension – this team tried to keep them as flat as they could with lesser levels and gained a bit on their consolidation performance.
- Setting parents of Custom dimension to Dynamic vs Never Share
- This was interesting to me as the team who presented the concept suggested that keeping it ‘dynamic’ statistically helped their application whereas oracle recommended it should be ‘Never Share’ for good performance as in all Essbase setup.
- Custom member formulas: Oracle has recommended to check member formulas used and reduce the usage if possible to improve consolidation timing.
- Business rules and ownership module
- Turning off the ownership module showed some improvement for these presenters, However the team presenting mentioned they are still in need to get their ownership module back without getting their performance impacted. They are working on trial and errors to figure out best case that can work for them.
- I learnt from the session that the presenters did some trial and error by turning off/on the out of the box rules that came with FCCS.
- Ratios calculation can be turned off/on
- Multi GAAP adjustment calculations can be turned off/on
- Balance Sheet calculations can be turned off/on
- Make sure consolidation rules are un-deployed even you disable ownership
This was astonishing how such business rules that comes with the module could impact performance drastically in this specific case. I heard from the presenters that turning all of them off helped with their consolidation performance.
In my opinion, with a combination of HFM expertise and Essbase expertise one should be able to identify these options with ease to troubleshoot any performance issue on FCCS. If you have HFM background and new to Essbase concepts some of these options may be new, I suggest you go over necessary oracle documentation before you try these to tune any FCCS application.
I hope the recap helps you come up with some basic steps to tune your FCCS application.