Finance leaders from Cardtronics and Allegis Group with more than three years of combined experience using Oracle Financial Consolidation and Close joined Perficient and Oracle for a panel discussion regarding their cloud journey.
Richard Ng, Director, Financial Systems, Cardtronics, and John Oliphant, Financial Developer Lead Allegis Group, shared the stories of their organizations’ migration from Hyperion Financial Management (HFM) to Oracle Financial Consolidation and Close. In the first blog post of a four-part series, Richard and John discuss Oracle Cloud Benefits from a Customer’s Point of View. In this second blog post, Richard and John cover consolidation times, a topic that’s of high interest to Oracle customers considering a move to FCC.
To view the spotlight video on this topic, click on the link below. To view the entire webinar, click here.
Compared to HFM, what do you think of FCC and performance is in terms of consolidations?
[Richard Ng] I think it’s better than HFM just from a time perspective but have to get a fair share to HFM.
I think we saw 20 minutes consolidation time, (25-30 minutes) depends on the amount of changes to the data. At this point we are starting to see some deterioration, if there’s a lot of changes to the data cell, it sometimes get to 40 minutes, but we haven’t seen anything more than 45 minutes or so. Once in a while there may be a hiccup that will slow things down. We may see little longer times, but on average it’s about 30 minutes consolidation time and, it’s about on par with HFM.
[John Oliphant] Consolidation timewise it’s almost identical. And it actually has gone up a little bit, but that really has to do with our design and our lift and shift move. But our journey was like this, we started the process of migrating the data in, and we immediately saw an issue with the data set size, using four custom dimensions and having all that data. It’s a heavy, heavy application, so we ended up having to use the consolidate by view process. So we had to both reload data and also re-consolidate data. We brought in three years, then finally, right after we went live, within a half a year, we moved to the DSO cube, not because of consolidation times as you pointed out, because again, they stayed roughly the same as HFM.
Our HFM cube was highly tuned, I think I lived in that HFM performance optimization guide. I know DBAs personally that I would call right on their cell phones because we figured out a way to tune the database that we could get this done and get it done well and during close be able to load 6, 7, 9 times a day. We are expecting the same performance with FCC. We got it, but only after kind of a long road. Then when it comes to the application size, that’s where we, as I mentioned that a year and a half in, we moved to DSO as soon as we could. It was a large project we knew we had to do because the size of our database was so large that it was impacting things like just a restructure.
So if you wanted to add an account, because as that was the dense dimensions you had to fire off dense restructure and it took some time. We saw a 70% reduction, 60-65% reduction in timing on the restructure. That was amazing as well as the maintenance window, went from 1 hour 45 minutes or two hours down to 45 minutes – where we hoped to have it. Having a global application, we couldn’t tell folks in APAC, “Hey, you have a two-hour window where the application’s down.” We could say, “At the lunch hour, it’s down.’. Consolidation times have remained roughly the same as what we would expect from HFM, if not a little bit more. But our maintenance window and our restructure or refresh and restructure times have come down. Like I said, 60% since moving to DSO.
Perficient’s Perspective
Oracle introduced Dense Sparse Optimization (DSO) in August of 2021. To quote Richard Wilke, VP Product Development, “We put a whole bunch of smart people into a room and basically said, you guys figure out how we can optimize performance. What are the ways that we can make things better? How can we, … like everything John said, how can we make, maintenance quicker? How can we make consolidations quicker? How can we do all of these things, shrink application size? So backups are quicker. And the outcome of that was the DSO.”
According to Richard, all of the applications now are at, or faster than HFM. Performance is really good and is only going to get better with new and improved processes as they get rolled out over during monthly patching cycles.
What is Dense Sparse Optimization?
All new Financial Consolidations applications are setup with Period and Movement as Dense dimensions instead of the Account dimension being designated as the only Dense dimension.
The biggest benefit comes in a way of consolidation performance and reduced application size. Upon thorough testing of this new feature Oracle and select partners, Perficient included, noted that consolidation time was reduced drastically, in some instances database size and consolidation time was reduced by 75%. Another obvious benefit of the new model is that Movement and Period dimensions typically do not update as often as accounts do. You are no longer forced to run dense restructures whenever new accounts are added which can save precious hours during monthly pre-close/maintenance cycle.
As we do more of these implementations and migrations, we are seeing the immense benefits of dense sparse optimized cubes. All the new applications we are building are all DSO-enabled. From an implementation partner’s perspective, it’s a clear choice.
As with most implementations custom calculations / rules are almost always needed in the consolidation processes, with the DSO application, we can build custom rules with less impact on the overall performance.
There are other things must be considered when moving to DSO application from legacy FCC applications, solve orders, formulas etc. These artifacts may need to be updated as the DSO application behaves differently than single dense dimension application. The migration itself is automated and pretty straight-forward. As in any such migration activity ample amount of time and effort should be directed at testing all customized artifacts of the application and update / modify these artifacts as needed.
