KScope19 – Thoughts on the EPM Strategy Symposium

I had the great opportunity to head to KScope this year, and had a fantastic time meeting the crème de la crème of the EPM blogging world. My colleagues made some great presentations (and Gui and Lydia actually won an award for theirs!) and it was great engaging with Oracle in the partner forums and the roadmap update sessions.

I focused mainly on EPM and Data Integration, being my two favourites, so here’s the headlines from an interesting week!

EPM Pricing Changes

Huge changes in the EPM Pricing space, with some massive opportunities going forward. The key one is the new SKU, Enterprise EPM Cloud. This offers unlimited applications for any of the EPM Cloud suite, which have been renamed from the acronyms to their actual purpose:

• Planning (EPBCS on steroids)
• Financial Consolidation and Close (FCCS)
• Account Reconciliation (ARCS)
• Narrative Reporting (EPRCS)
• Enterprise Data Management (based on ODI)
• Profitability and Cost Management (NEW!)
• Tax Reporting
• Data Integration (facelift for Data Management based on FDMEE)
• Management Reporting (facelift for Financial Reporting)

Unlimited truly means unlimited here. You can have 10 planning apps with one of each of the others, for example, and each planning app will now support 6 custom BSO and 6 custom ASO cubes, as well as the EPBCS frameworks (now called modules). This is huge for bigger customers who want to leverage the entire cloud who could save a lot of money by moving to this SKU. The only problem is the base price, a whopping $500 per user per month, but Oracle are bound to offer discounts.

The less said about the other offering, Standard EPM Cloud, the better. It’s half the price at $250 per user per month, but each extra app costs $2500, and you’re limited to just one custom BSO and ASO cube. You can leverage the EPBCS modules as well, but these can be clunky and really suppresses the capability to lift-and-shift.

The good news is that existing PBCS and EPBCS customers can renew without changing their deal, and you can also buy PBCS through NetSuite for the usual price, meaning customers who just want a great planning solution can get that for a more reasonable price.

Free Form Planning

Holy smokes this thing looks fantastic. It’s basically Planning with no restrictions on dimensions at all, so you can create whatever crazy cubes you want. Don’t want Version? That’s fine. Want a single time dimension instead of Period/Year? That works too! This is the solution to creating Essbase style cubes on the cloud.

The main benefit is that you can also leverage all the usual great planning functions like forms, business rules and the rest on top, with the caveat that if you don’t have a scenario dimensions, you won’t be able to use workflow. The available features will be automatically assigned based on your dimensionality.

Free Form apps can also be created entirely in Excel templates, and maintains all the great Essbase features like multi-grid on one sheet, aliases in different columns and in-sheet POV’s.

On-Prem Support until 2030

This is a cloud blog, but on-premise is getting a big upgrade to version 11.2 and will continue to receive new features and be supported at least until 2030. 11.2 does require a fresh install however, which could be a pain point for big organisations.

Updates to tired features

Financial Reporting has gotten a facelift and big upgrade, and soon Management Reporting will replace it, with the big bonus that MR can have grids from various sources (ERP/EPM) all in the same report. I didn’t get to play with it too much but I understand key features like batch bursting and report scheduling are coming, and it will be the driving force behind the Narrative Reporting tool.

Machine Learning makes its way into EPM

A module named IPM (Intelligent Performance Management) is being actively developed to add machine learning style predictions to the EPM Cloud. The idea is that Forecasts will be auto-filled with a machine-predicted figure which users can then change if needed. It seems like a great future feature, but it’s not quite up to industry standards just yet.

Finally, some RIPs:

• EPMA has died a death, finally (owners will get a restricted version of DRM to replace it)
• On-Prem Workforce/Capex/Project template are dead
• The FDMEE Fish are dead (in the new Data Integration facelift for Data Management)

I'll be publishing a deeper dive into Planning and Data Integration soon and my thoughts on a bright future for the EPM world!

Until next time,

Mike

FDMEE Automation – Automatically Identifying the process ID

Welcome to the third part of my series on automatically loading data from source systems into PBCS. I promised tips and tricks, so here is another neat way of identifying what can often be a useful variable in your data load, the process ID.

Firstly, what is the process ID? It’s a unique identifier assigned to each FDMEE process that you execute. It’s easy to spot when you check your process details window, but not quite so easy to identify when you're running an automated script.

Why is this number important, I hear you cry? Well, for reasons best known to themselves, there are a few vital operations within FDMEE whose outputs contain the current process ID. A couple of these are crucial – exporting data from PBCS using FDMEE (check my colleague Jaz’s blog out for a full guide coming soon!) and also producing reports in FDMEE as I’ve blogged about here.

I’ve already covered the second one, so what about when you’re exporting data from PBCS using FDMEE. This is an awesome way to move data between cubes when you need to do complex mapping, the inbuilt data maps functionality doesn’t quite cut the mustard for anything more complex than “map everything to No Entity”.

So, the output from exporting data from PBCS unfortunately comes out in this format: Target_Application_ProcessID.dat. An example would be Workflow_Cube_1393.dat using the process ID from above.

Now, if you wanted to automate pulling data from one cube to another, you would need to be able to identify that filename. Thankfully, the Target Application name is constant and so is the .dat extension, but you need to identify the process ID. But how can we do this? 

The answer is to reuse a cheap trick I’ve blogged about before – FDMEE reports are always at the bottom of a listfiles extract. So, if we were to run a dummy FDMEE report directly after our export from PBCS then it can logically be deduced that the process ID of our report will be one greater than the process ID of our export. And we can find out the report process ID using the instructions here.

So, the process would be:

1. Run your FDMEE Export from PBCS rule (rundatarule)
2. Immediately run a FDMEE dummy report (the report itself doesn’t matter, we just need the process ID) (runDMReport)
3. Using my previous blog find the process ID and take off 1 (set /a processID =%ID% - 1 )
4. Run your standard FDMEE load rule with the data file Target_Application_%ProcessID.dat% as the input file(rundatarule again)3)     

And boom! You’ve just loaded data from one cube to another, in a ridiculously roundabout way. But, if you have the requirement to map several dimensions into one for reporting, this is the most elegant way I can piece together to achieve it.

Here’s the setup in action – notice particularly the name of the file being used for process 1326 – you don’t even have to download the data file, just keep it saved in the cloud and point your rule at outbox/TestApp_%processID% in your batch file to achieve the below.

Again, please check this fantastic blog from my colleague to see the missing piece of the puzzle, the export from PBCS via FDMEE (step 1324 in the screenshot above).

Stay tuned to my blog for the final instalment on FDMEE next week, setting up drill-through to Microsoft Dynamics CRM!

Cheers,

Mike