Oracle CloudWorld returns to Las Vegas September 18-21, 2023 and promises to be bigger and better than ever. Be a part of the global Oracle community and gather with other customers and partners to network and learn. Oracle has more than 1,100 sessions planned and more than 100 hands-on labs. Meet us at CloudWorld Hub in the Venetian to connect with subject matter experts and thought leaders and learn how we’ve leveraged our extensive expertise in Enterprise Resource Planning (ERP), Supply Chain Management, Human Capital Management, Enterprise Performance Management (EPM), Business Analytics, and Oil and Gas to drive digital transformation for our customers.

An Oracle Partner with 20+ years of experience, we are proud to be a sponsor of this pivotal show, and are committed to partnering with our clients to tackle complex business challenges and accelerate transformative growth.  We have two can’t miss sessions at this year’s conference, both proudly showcase customer success stories. Build your agenda and make sure to add these sessions to your schedule:

Move to the Cloud – Customer Sessions

Iron Mountain Streamlines Procurement Processes with Oracle Cloud [PAN3438]  | Content Area: Move to the Cloud

Iron Mountain, a $5 billion information management services company operating in over 70 countries, was looking to enhance its ERP platforms and strengthen its global business process standards and operating efficiencies in finance, accounting, procurement, and supply chain management. The company wanted to decommission more than 20 disparate platforms, including Oracle E-Business Suite, and consolidate its operations into a single global instance of Oracle Cloud ERP, including Financials, Procurement, Inventory Management, Risk Controls, Project Accounting, and Tax in the Asia, LATAM, and EMEA regions. Oracle Cloud set global operating efficiencies and process standards and reduced IT spend. See how Iron Mountain is executing this transformation.

How Allegis Group Moved to the Cloud for Planning, Consolidation, Master Data, and Tax [THR2948]  | Content Area: Move to the Cloud

Allegis Group is a large multinational talent management firm with over 19,000 employees and $13.4 billion in revenue. They were operating on-premises versions of Oracle Hyperion Planning, Oracle Hyperion Financial Management, Oracle Data Relationship Management, and Oracle Hyperion Tax Provision when they began migrating them all to Oracle Cloud. We discuss their approach as well as the plan to support ongoing operations during the migration. Learn how they approached multiple application migrations, including phased by application, phased by business units, or a “big bang approach.” We review the procedures, tools, and teams involved in the migration as well as what went right, what could have been done better, and the lessons learned.

If you haven’t yet made the decision to attend Oracle CloudWorld, here are some compelling reasons to help you Justify Your Trip.
CloudWorld is by far the largest gathering of the global Oracle community. Where else can you network and build relationship with your peers? Over the course of three days, you’ll learn from experts at Oracle as well as numerous partners and current customers leaving you inspired about the endless possibilities you can achieve with Oracle Cloud.

Did you know that a full conference pass includes access to Oracle University digital training through November 21, 2023 at no cost — a program that lists at $4,995 annually?

We are looking forward to exhibiting and speaking at Oracle CloudWorld and hope to see you there!

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.

With support for Oracle Hyperion Financial Management (HFM) coming to an end in 2021, organizations have a big decision to make this year as Hyperion Financial Management (HFM) has been the main resource for many businesses to automate their financial consolidation and close processes.

As organizations may hesitate to make the jump to Oracle’s Financial Consolidation & Close (FCC) our team is here to debunk the myths about this new cloud service. Built upon aspects from HFM, FCC can offer your organization more functionality and an expansion on HFM applications.

In this webinar, Don Ford and Matt Hopkins, both subject matters experts in our EPM Practice at Perficient, demystified the move from HFM to Oracle Financial Consolidation and Close. They also discussed how Perficient’s methodology has helped lead clients through successful consolidation and close processes.

Click to experience the full webinar and hear the following myths debunked:

1. It’s difficult to implement
2. FCC is not as ‘flexible’ as hyperion financial management
3. It will result in poor performance/degraded end user experience
4. It requires significant effort to retain/empower end users

Hyperion Financial Management (HFM) has long been the application used by organizations all over the globe to streamline and automate their financial consolidation and close processes. However, those days are coming to an end. With the onset of the cloud, now is the time to adopt best practices and streamline your consolidation process.

Oracle’s Financial Consolidation & Close (FCC) cloud service has been built upon “tried and true” aspects from HFM, ensuring that customers retain all of the features that legacy HFM customers have relied upon. But FCC does more…FCC offers next-generation functionality that standardizes, replaces, and expands upon many of the custom solutions common across HFM applications.

Join us as my colleague and I demystify the move from HFM to Oracle Financial Consolidation and Close. We will explain how our clients have leveraged Perficient’s methodology to successfully improve consolidation and close processes, empower business users, and reduce risk common to legacy environments.

In this session you will learn:

• Key Considerations for Cloud Consolidation Implementations
• Common Misconceptions Debunked  — You’ve heard it, we disprove it
• Perficient’s HFM to FCC Framework
• Dimensionality – Better in the cloud
• Data Integrations Simplified
• Reporting – Not Your Grandpa’s Reports
• Empowering the Consolidation User & Ensuring Success– Perficient’s Change Management Strategy
• It’s Been Done Before, Successfully! – Success Stories You Need to Hear

Come prepared with your questions for Perficient’s team. We’d love to have you attend our live event. But if you’re unable to make it, all registrants will receive links to the presentation materials and a recording of the on-demand webinar post-event.

Register:  April 21, 2021   |    11:00AM – 12:00PM CT

There is always very much confusion surrounding the topic of currency translation in Oracle Hyperion Financial Management (HFM). I will focus here on one of its more challenging aspects – translation of equity/capital accounts, aka historical translation. I will be arguing that:

• “Override accounts”, the traditional design for historical translations, is not the best fit for applications where consolidation structures call for multi-layer translations, or where journals or custom detail are in active use; the design also scales poorly
• The primary reason is that override accounts work around, but do not address directly the problem of periodic translation for capital accounts as required by GAAP
• A better alternative is to leverage the HFM built-in TransPeriodic function to:
  • Streamline periodic translation for capital accounts with the end-of-month rate
  • Book the resulting exchange differences to Cumulative Translation Adjustment accounts
  • Build a manual adjustments interface for users to fine-tune the streamlined result

Traditional design and why it’s bad

From my experience, in the HFM world equity translation is most commonly handled through a set of so-called “override” accounts. This override set, which comprises duplicates for all accounts that require historical translation, is a rollup placed somewhere outside the balance sheet and used for tracking foreign currency balances and maybe also for entering pre-translated amounts. This tracking and entering occurs at <Entity Currency> level; once HFM gets to process a foreign currency, it pulls those balances from <Entity Currency> to replace (i.e. override) the results of the HFM default translation – hence the name “override accounts”.

Consider the following example:

1. Opening balances are pulled from the prior year
2. There might be variations in the process here:
   • Sometimes calculation rules would pick up the local currency number and apply an exchange rate to it: ending, average or some blended rate entered by the user;
   • And sometimes it is the users’ responsibility to enter manually translated amounts directly into override accounts.
3. The ending balance rolls forward, that is, it gets calculated as the opening balance plus activity.
4. The numbers calculated above are pulled from <Entity Currency> to <Parent Currency>.

I note in passing a certain degree of pain in the HFM administrator’s neck implicit in this design: he/she has to keep duplicate override accounts for each reporting currency, maintain a less readable code with lots of nested ifs and counterintuitive status impacts (impact from <Parent Currency> in the last period to the next year’s <Entity Currency>, for example), and deal with accommodating periodic input for override numbers (because most likely users won’t appreciate entering them in a year-to-date (YTD) manner). But this is all tolerable compared to the flaws that might arguably be perceived as deal breakers when considering translation setup:

• First, there is this apparent problem that pre-staging (at <Entity Currency>) takes place before processing journals (found at <Entity Curr Adjs>). It’s relevant to compare this to how native translation happens in HFM: it first reads local numbers from <Entity Curr Total>, and then translates and writes the result to <Parent Currency>. Of course, the pre-staging calc will retrieve local numbers for translation from <Entity Curr Total> too – in attempt to fetch journal adjustments posted to equity accounts or the income statement. But the problem is that at this point any calculation logic assigned to the <Entity Curr Adjs> layer has not yet happened, <Entity Curr Adjs> is in CH (data has CHanged) state, and so is <Entity Curr Total>. Ultimately, it results in:
  • Reading numbers from CH cells, i.e. from an unreliable source.
  • Missing out on HFM built-in calculation optimization (coming with the Consolidate option as opposed to Consolidate All With Data or Consolidate All) as users always need to start calculations from the bottom layer (<Entity Currency>) even though it might be in OK status. For example, consider the situation where users update their journals, but the data loaded to <Entity Currency> was calculated long ago.
• Second, this design poorly scales up for multi-staged translations, which are the situations where data is translated more than once as it travels up the consolidation hierarchy. The issue here is with pushing the overriding numbers up. Because these numbers are ultimately destined to replace data, the pre-staging logic must now tap into entities originally not intended for use in overriding at all (think for example of USD entities found at the bottom of different hierarchies, all of which ultimately end up in USD) or intended only partially, and incorporate all consolidation adjustments encountered along the way in several currencies. Most likely the resulting solution will be tailored to specific translation paths and require metadata and calculation updates as new currencies are added to the application. As a side note, it also proves to be surprisingly hard to seed opening balances for new currencies or new parent entities.
• Third, this pre-staging, rendered normally through a set of HS.Exp statements, almost invariably results in some loss of custom detail upon translation – particularly intercompany and roll-forward detail, which are extremely important for elimination of intercompany equity. This happens either because HS.Exp syntax calls for refining the POV resolution, or, if users in addition enter some override data manually, because it’s not feasible to make users override every existing intersection. And because of this it also poorly scales up for new custom detail added to the application.

My personal experience with struggling through scalability issues during HFM updates suggests that all these flaws are but the effect of forcing the periodic translation logic (normally applied to the income statement accounts) into the resisting year-to-date perspective. Once the right tool for manipulating periodic data has been adopted, the logic will fit in, and the above concerns will no longer exist.

Periodic translation in GAAP requirements

To make my point about periodic translation I start by taking a closer look at how capital accounts are supposed to be translated according to the rules of accounting. Both US GAAP and IFRS imply translation of any change to equity balances (i.e. equity activity comprising capital transactions) at the rate on the date of the corresponding transaction (the transaction rate). I stress the word “imply” because the issue is not addressed anywhere in the foreign currency topics directly (ASC 830, IAS 21). The idea implied here is to be able to reconcile capital transactions and resulting balances within the group as required explicitly by the consolidation topics (ASC 810, IAS 27). That is, investment accounts on the parent books and equity on subsidiary’s must match in reporting currency to properly eliminate, and rolling ending balances forward through transaction rates ensures just that. The resulting exchange differences are booked to the Cumulative Translation Adjustment (CTA) account in US GAAP, or Translation Reserve under Other Comprehensive Income in IFRS.

From the HFM standpoint two aspects appear challenging here: 1) use of transaction rates (as HFM applications normally don’t track daily activity), and 2) the way the ending balance is not translated at the ending rate (as balance sheet accounts are out of the box), but rather accumulates each change to the balance, duly translated at the appropriate rate.

The former challenge normally draws attention away from the second one. Instead of coming up with creative solutions in this regard though, I suggest employing the approximation trick I learned from clients doing their consolidations in Excel workbooks: to speed things up during month-close processes, they would routinely use the end-of-month rate as a convenient stand-in for all transactions happened in the period. The approximation usually works fine for quick month-end reporting and can be fine-tuned in audited reports. In HFM this would mean to have a special tool to do that, and I will get back to fine-tuning translation results through foreign currency adjustments in the next blogpost.

So much for transaction rates then. We can now re-consider the second challenge and put it this way: equity/capital balances accumulate each change to the balance translated at the end-of-month rate.

Now that this formulation is in place, I would like to highlight the fact that HFM is well aware of this translation method. The PVAforBalance checkbox under application settings, once checked, forces all accounts of asset and liability type to translate exactly in this manner. Now in HFM this translation is called PVA (Periodic Value Added) translation. The translation method being in place when the box is unchecked – i.e. when numbers are translated in the YTD view instead – is referred to in the admin guide as VAL (VALue at Exchange Rate) translation. We can say that in the typical HFM setup the balance sheet accounts are VAL translated, and the income statement and cash flow accounts are PVA translated (in accordance with what GAAP refers to as the current rate method).

Perhaps we can better appreciate this PVA-VAL opposition if we put it into the broader context of the periodic-YTD opposition, found at the very core of HFM. This opposition is best pictured in terms of data flowing up through consolidation layers and becoming subject to the corresponding HFM settings:

There is much to say about this diagram and about periodic-YTD interaction in general, but for now I simply point out that:

• Starting with data entry at the bottom, at each level HFM makes the administrator pick up the master view – that is, between Periodic and YTD. The other view will be derived, i.e. calculated by HFM based on the master view. For example, at the bottom layer the master view is the view in which HFM will expect users to load data.
• While it might appear obvious, it is important to add here that at any given layer the master view is also the view in which HFM will expect calculation rules to calculate data.
• At the translation level, the <parent currency> level, the PVA settings give the administrator some control over what to consider periodic and what to consider YTD. For PVA translation Periodic is the master view. That is, translated data is considered periodic, and YTD is then derived by HFM. And for VAL translation YTD is the master view and Periodic is derived.

HS.TransPeriodic

With this quick introduction in place we can again consider the PVAforBalance setting for equity translation purposes. It feels like the right place to look, but unfortunately, it seems to be an all-or-nothing thing – once turned on, it will become the default translation mode for all balance sheet accounts. It helps to know though that the HFM calculation engine comes equipped with a related set of functions – namely, HS.DefaultTranslate and HS.Trans/TransPeriodic.

The former lets you override translation settings – that is, translation rates and translation methods (PVA or VAL), – for a specific calculation unit: say, some particular scenario or scenario/entity combo. But it is the latter function, which gives you the same control over a particular POV within the calculation unit, that looks really promising. Indeed, we’d like to restrict this behavior to certain accounts – that of equity type only.

The screenshot above is from HFM Admin Guide (https://docs.oracle.com/cd/E57185_01/OHFMA/transperiodic.htm). TransPeriodic is the function that calculates the exchange difference between Rate1 and Rate2 on the periodic portion of the source POV and writes the result into the periodic portion of the target POV[1]. The source POV may differ from the target, but if the source is omitted in the function call, the same POV is used.

Apparently, if Rate2 is omitted, the result is simply PVA translation of the source POV at Rate1. For example, the below line tells HFM to PVA-translate the Share Capital account at the end-of-month (EOM) rate (aka closing rate aka ending rate):

There is no need for specific mention of custom detail or ICP for the account; the new translation method is simply applied to all valid intersections.

Streamlined translation of equity roll-forward

Below is a sample vbscript code that leverages HS.TransPeriodic to switch equity accounts into the PVA mode. In this example equity accounts come with roll-forward detail attached:

Line 199: The account list looped through here (“PVAatEOM”) is UD-based – it’s the list of accounts that have “PVAatEOM” typed into their UD1 property. This is the list historical translation will be restricted to.

Line 200: The preferred design for the roll-forward dimension (referred to throughout the code by its short name “RF”) is with the “true” ending balance sitting at the top, always representing as such the sum of the opening balance and all activity members. In the grid below this relationship is indicated with blue lines.
For activity members SwitchTypeForFlow=Y.

Lines 201-202: Here we assume that elsewhere in the rules opening balances get pulled from the prior year. The only piece left thus is to PVA-translate activity members at the EOM rate found at A#EOMRate. This is what happens at line 202: TransPeriodic PVA-translates all combinations of the accounts captured in the PVAatEOM member list and base roll-forward members that represent equity activity (that is, those members where SwitchTypeForFlow is true – line 201).
The ending balance then comes together as the top member aggregating the opening balance and all PVA-translated activity members. The red lines below illustrate this process – activity is translated in the periodic view by TransPeriodic and then the YTD number is derived (shown by red dashed lines).

This design also comes with low maintenance cost: no additional action on the admin side needed to attach a new currency, roll-forward member or equity account. Furthermore, all custom detail including the vital ICP detail is subject to the same translation approach and is preserved during translation and subsequent contribution to the parent.

Streamlined translation of equity balances

The ending balance set up as the parent of properly translated pieces of roll-forward is the preferred design, but it is not at all uncommon to see the ending balance as loaded from the general ledger to roll up instead. Compare it to the roll-forward hierarchy discussed above:

Two differences worth highlighting: first, this time the cell we wish to translate is not a flow, but a balance (because SwitchTypeForFlow property reads No). In HFM, flow cells support the Periodic-YTD concept, and balance cells do not. As we are about to see though, TransPeriodic does the same great job translating balance type cells as it does flow type. Second, even though TransPeriodic can “see” the periodic portion of activity, in the first period this activity is lumped together with the opening balance.

We can further generalize this case as the situation where there is no roll-forward attached at all, i.e. where equity accounts are simply balances:

Lines 149-151: Accounts in the PVAatEOM list get PVA-translated at the ending rate. No additional action is needed – TransPeriodic works the same way with balance type cells.

Lines 153-172: In the first period during the above PVA translation we can distinct two portions within the ending balance: Ending Balance @ EOM rate = Activity @ EOM rate + Opening Balance @ EOM rate. What’s in fact expected in the first period is Ending Balance = Activity @ EOM rate + Opening Balance @ Historical Rate (the blended rate as of the end of the prior year). The difference between the two is Opening Balance @ Historical Rate – Opening Balance @ EOM Rate = Opening Balance @ (Historical Rate – Opening Rate). A little awkwardly, this is what is accomplished at line 169. The historical blended rate is calculated individually for each ending balance intersection existing in the prior year – the list of intersections is retrieved by the OpenDataUnit call at line 154.

So these above are two very basic designs (with and without roll-forward) to build a historical translation solution upon. In the next post I will show how TransPeriodic also comes in handy when developing complementary solutions for the historical translation impact on CTA and translation adjustment

[1] That is, “write” from the calculation engine perspective. From the HFM database perspective data is always stored YTD, and periodic data is calculated on the fly, so of course any “writes” to the database will be in YTD.

From my latest post (Post 2), we talked about starting the process to identify your needs, the importance of a partner and the value of planning ahead.  We will continue down that path in this post.  I’m trying not to spend too much time on gathering project requirements in these posts; however, they are a building block for selecting the right product and I will give them the time they deserve here.

Whether you are planning ahead or have an emergency need, first you have to understand what you currently have.  I am a huge fan of integration schema’s and data flow diagrams.  These help you get the “big picture” of what your data inputs are, the existing processes and current outputs.  Outputs can include any data that is used by end users, including reports and queries.  If you don’t have a schema or data flow now, you should make one.  It is hard to get where you want to go if you don’t know where you are coming from.  Many times when creating one of these schemas, you will be surprised that there are additional inputs that are not documented (many times via cumbersome processes), exceptions to the processing performed and unknown users of your end data.  Existing applications have a tendency to evolve over the years and putting it on paper is a way to capture what you really have and subsequently, need to replace or update.

I was in a design session once where we were reviewing data inputs for HFM.  The most common input being Trial Balances that were being loaded via FDM.  We asked if there were any other inputs and were told “No”.  Pressing further, we asked about manually entered Trial Balances, adjustments, statistical data, supplemental data or operations data.  The response was “Oh, now that you mention it, yes we do some of that”.  We went person by person and about half of the people knew of some “little bit of information” that was an input to HFM.

When you are gaining an understanding of what you have, you will need to talk to a lot of people – inputters, processors, end users, analysts, administrators, report writers, etc.  These are the people that know what is going in, work that is being done and what data is coming out.  These are also the same people who should be driving your requirements.  Be inclusive and keep the lines of communication open with these stakeholders.  Getting everyone on the same “requirements page” ensures all are aware of your goals and how they will be achieved.  In my HFM input example above, we had to expand our “user group” included in the discussions to ensure we had all the input details for HFM.

Document and Prioritize.  Once you have identified what is required, document it!  Putting the requirements on paper ensures everyone can literally see what is needed.  This will drive the scope of your project and what Hyperion applications you will need.  Also, you should have your stakeholders approve the requirements.  This ensures there are no miscommunications.  List the requirement, who wants it and the real priority of the item.  I say “real” priority, because for some people, everything is a Critical priority.  Also, make sure you understand why it is a priority.  Just because “that is the way we have always done it” does not cut it!  A reporting requirement from five years ago may not exist now.

OK.  Now we have a list of what we want. Consider your timeline – are certain priorities needed sooner?  Can some wait?  The immediate needs should be driving the timeline; however, don’t ignore the other needs that will come later.  Put them on your timeline too, even if it is a year or more later.  This serves several purposes including ensuring you are looking at your application ecosystem holistically and it helps you manage expectations for your stakeholders.

In the next post we will begin looking at the available products.  Fair warning here and now – I’m not going to go into excruciating details about each product.  There are volumes that I could write if that were the case.  I’ll cover major functionality, available tools and what you should consider.  Also, no Cloud vs. On Premise debate in these posts.  That deserves its own discussion and I won’t be tackling that one here.  Instead, we will focus on major functionality that you should be looking at to meet your needs.

From my earlier post (Post 1), we talked about what EPM is and how it can help organizations.  This post will focus on starting the process to determine what the organizational needs are.  This is the first step in determining which applications to select and implement.  If at all possible, do not buy your new solution without first vetting what you need!  I realize this is not always possible, but I have seen it multiple times where companies try to fit round pegs into square holes.  If you have already selected a new application, or are upgrading an existing application, you still need to focus on your needs – then determine how the application can, or in some cases, cannot meet your needs.

Here is where I will make a suggestion for finding an implementation partner to assist in this process.  Some companies perform software selections and implementations frequently and know how to identify their needs and vet the potential solutions and tools.  Some companies, not so much.  Bottom line – “projects” are just that and many companies perform them rarely and only when they have to.  They typically don’t have project staff on hand, nor keep up to date on the latest innovations.  However, this is what consulting firms do – help identify requirements and assist with the right tools to meet their customer needs.  They can help navigate project pitfalls and traps as well as assisting with timelines to ensure the ball keeps rolling.

There is always a reason to consider implementing a new solution or application.  You are either being reactive to an existing need that requires attention, usually IMMEDIATELY, or you are being proactive based on an existing long term roadmap or you see the immediate need coming.  The organization that is being proactive has a higher probability of a smooth project and better success because they are not being “rushed” to fix an existing problem.  The main point here is to plan ahead for what you will need.  It is much easier to vet solutions and create realistic timelines when there is not an immediate need.

In my next post, we will cover some of the structure you need to put around your requirements gathering and then we will get into the actual applications.

Constant pressure from shareholders and upper management to improve the bottom line are driving factors to business leaders searching for new ways to be more effective and efficient. One of the many tools available to them is Enterprise Performance Management.

Broadly defined, Enterprise Performance Management (EPM) is managing the profitability and performance of your business operations and results. It is typically a suite of software applications that help you:

• Create and manage plans across the business and/or business lines
• Track and analyze profits and expenses from plans
• Provide tools for end user queries and formal external and management reporting of results
• Streamline and manage certain close and planning processes
• Standardize key Master Data (e.g., Accounts, Customers, Suppliers, etc.) to facilitate comparative analysis and management

Oracle Hyperion’s suite of Products provides multiple applications that do all of these things and more. The key for many organizations is selecting the right applications that they need to be successful.

The old adage is that “There is a right tool for every job”. The key is making sure you have the right tool and then know how to use it. As an example, I could probably pound a nail into a piece of wood with the flat side of a wrench, but I’d have better results if I used a hammer. However, do I need a claw hammer or a ball peen hammer?  Does it really matter?  The same principle applies to selecting the applications and solutions for your business needs. Sometimes you need the specialized hammer, other times, all you need is a hammer, it does not matter what type!

So how do you pick the right tools?  The organization needs to identify, and prioritize, their needs. A U.S. based manufacturer on one ERP system, with 75,000 inventory items, 45,000 customers, and using only U.S. Dollar has distinctly different needs than a global service provider that has offices in 45 countries, deals in 40 different currencies and has multiple regulatory reporting requirements.

In my next post, we’ll go down the path of how to identify and prioritize the needs of your organization and then how to select the right tools.

As I look back on 2017, Perficient delivered some webinars that seemed to strike a chord with attendees. Subject matter experts across EPM, ERP, BI, and CX all contributed to content rich events that really packed the virtual house! We were fortunate to have customers from Orthofix, Group Voyagers, and Mercer Advisors co-present with us on various topics. In addition, Rajesh Bhatia, VP of Product Development at Oracle, joined the Q&A session for one of our events.

If you missed any of our top webinars from 2017, you can catch up now and binge watch all you want! No form fill outs required, just grab a cup of coffee enjoy! I hope you’ll learn a thing or two you didn’t know. Feel free to reach out to us if you have any questions about what you heard. We look forward to hearing from you.

Deep Dive: Oracle FCCS and HFM

Top honors go to this record-breaking event delivered by Tony Coffman, a director in our Enterprise Performance Management practice. Tony gave a side-by-side review of Oracle Financial Consolidation and Close Cloud Service (FCCS) and Hyperion Financial Management (HFM). This is a must-see on-demand event for anyone using HFM that is considering FCCS. View Recording

Build a 360-degree View of Customers with Oracle BI Cloud Service

We started off the year strong with a great event delivered by Shiv Bharti, the director of our Oracle Business Analytics practice, and Tom Munley, vice president of the Oracle practice. In this event, we learned how Oracle BI Cloud Service (BICS) gives companies the ability to consolidate disparate marketing, CRM, sales, billing, and external data into an Oracle Cloud database providing users with actionable information for a comprehensive view of customers. View Recording

Orthofix Improves Its Financial Close and Consolidations with Oracle Cloud (ARCS & FCCS)

It’s no surprise to find this event, which featured a customer success story involving Account Reconciliation Cloud Service (ARCS) and FCCS, in the Top 5 List. Featured speakers from Orthofix included Lon Snook, VP U.S. Accounting and Consolidations as well as Scott Rodney, Hyperion Financial Management Admin. Lon walked attendees through challenges with their existing legacy process, project scope and timeline, as well as outcomes and success metrics. It’s a rare opportunity to hear direct from a customer, so what are you waiting for? View Recording

Oracle Essbase in the Cloud: A Mercer Advisors Success Story

Perficient’s EPM team finished the year in style with another winning event. Once again, a customer-driven success story really resonates with audience members. Doug Maxwell, Chief Financial Officer for Mercer Advisors, took us on his company’s journey to the cloud. He discussed the Oracle Analytics Cloud (OAC) implementation including lessons learned and how OAC can benefit organizations. View Recording

A Customer’s Take on Moving from Discoverer to Oracle Business Analytics

I have to admit, I was hesitant at first when the director brought this topic to my attention. I wasn’t sure there would be an audience for a webinar focused on moving off Discoverer. Happily, I was wrong! An event in which a customer, Gary Aragon, Accounting Manager with Group Voyagers, co-presented rounds out the top five. Although Group Voyagers chose Oracle Business Intelligence Enterprise Edition (OBIEE), other replacement options were discussed such as Oracle Analytics Cloud. If you’re still running Discoverer, carve out some time to watch this replay. View Recording

If you didn’t have an opportunity to attend the webinar, HFM to FCCS – A Customer Success Story, presented by Doga Pamir, Solutions Architect at Perficient, you might want to check it out on ODTUG’s website as part of their educational webinar series. This event was originally presented at Kscope17 and was so well received, that ODTUG wanted to extend the reach of this award-winning event to the greater membership. In part one of this blog post series, I shared excerpts from the Q&A part of the event. Let’s pick up where we left off with more Q&A.

Did you face any challenge by not having contribution adjust and/or entity currency adjust?
No, we did not. We were not adjusting any contributions in this app. This was a straightforward app. Everything is owned 100 percent. Entity currency adjust is not there yet, but the journal module still works similar to HFM. It’s just fixing it on a specific member. We did put higher-level journals, but we didn’t run into any issues, and we didn’t necessarily have the need for the contribution adjust bucket. I know that Oracle is working on enhancing the application, especially when it comes to the consolidation dimension, custom consolidations. It’s just not available yet. I’ve seen some models, but like I said, in this particular case, we didn’t need it. It was a smaller application. It fit the box, and it worked.  

How do you implement security so that a novice user doesn’t accidentally make drastic changes to the metadata and Smart View?
Especially when it comes to the metadata, security follows the planning, if you are familiar with the planning security structure. We create user groups, and then we assign them to dimensions. We either give them write access to certain parts of the metadata or the hierarchy, or we give them read access. That would be the way to limit their security. You can go to any level, just like in planning and apply security to different levels, based versus parent to get around it.  

Does the application have any equity pickup calculations such as in HFM? 
Currently, it does not. When we were implementing, it didn’t. Equity pickups is in the roadmap and Oracle is saying it should be in the next release, but Oracle is not providing specific dates.  I believe it will have the calculation manager, and Oracle will open up some parts of the calculation routine for developers to go in and write some logic to it, but as of today, that’s not there. 

Regarding the backend of FCCS, is it Essbase BSO behind the scenes, and how is performance?
Yes, correct. The back engine is Essbase, and it’s a BSO cube today. With this type of application, 15 entities, less than 1,000 accounts, custom dimensions are not more than a couple hundred. That’s one reason we identified CPI as a FCCS candidate back when we started.  

Now, the application’s evolving. There’s actually big demand from enterprise customers. Once Oracle rolls out additional custom dimensions for FCCS, the backend will be different, and they’re going to be using a hybrid approach, which is going to be an ASO plus BSO cube. It should improve the performance as well. With this particular app, it was not an issue. There are some recommended numbers when it comes to entities and accounts and customs when you’re building your application. 

Can only admins be dimensions editors? Our company has another group, non-HFM admin that maintains metadata for all our applications in our company.
I believe today, there are four main roles: system admin, power user, user, and view. Today, system admins do manage the metadata.  

How do the actuals integrate with the planning module?
When we did the FCCS implementation, we didn’t do that part of the integration. That was going to be phase two. We currently don’t have in this particular app PBCS to FCCS or vice versa type integration using Data Management or anything like that.  

There is not a direct connection between FCCS and EPBCS. You can do a file-based export from FCCS and load that into EPBCS using either the direct import feature within the browser, or using EPM automate to load the data so that then you can pick it up with Data Management. The tools are there in both subscriptions to do the integration, but it just wasn’t a requirement for our customer.  

Are there any training courses for FCCS, either with Oracle or your firm? 
Not currently. I know that Oracle is working on this, but I’m not sure if they rolled out. Our approach is to train while we do on-site implementations, basically, side by side. You’re shadowing us, that’s how we implement these products. To date, formal training through Oracle education or Perficient is not yet available.  

There is a subscription that you can buy from Oracle that provides cloud training. It covers three products. FCCS is not one of them yet, but it’s on the roadmap. The three that are available are Enterprise Planning Cloud. The duration is about 25 hours worth of training. There is the Enterprise Performance Reporting Cloud, and about 10 hours of that. Then, Profitability and Cost Management Cloud has about four hours of training. We don’t know exactly when FCCS and ARCS and some of these other products would come out, but I know that it’s under development. If you want any more information about this particular subscription, you can reach out to us.  

These are not live instructor classes. In addition to this new subscription, just know that also, when you subscribe to FCCS, there is what is called the Academy, which is an icon which has prerecorded videos already in the subscription. They are very short, but they give you a high-level intro to different features and different ways of implementing the product. There’s always that, and that’s included with your subscription. If you want training beyond that, your option today for FCCS is custom training developed by a partner and possibly in the near future, a subscription with several hours of training provided by Oracle.   

What are the purposes of changing the data source dimension? 
FCCS comes with this data source dimension out of the box, and it provides some pre-seated members. Some of those members are designated like FCCS elimination, FCCS journal input. One of them is for the journal module. The other one is used when the system does intercompany eliminations out of the box. There are a couple more. One of them is a default option when you set up your data management, the data input one. That can be modified. In addition, if you have in your current HFM system a data source or a source type dimension and have additional members because you’re tracking more than what FCCS provides out of the box, you can enhance dimension, add your own members in there to track different type of data loads into the system. That would be the reason or the purpose of enhancing the dimension. 

Oracle Financial Consolidation and Close Cloud Service (FCCS) is one of the latest cloud solutions offered by Oracle.  Doga Pamir, Solutions Architect at Perficient, was selected by ODTUG to present at Kscope17 on this topic. His session, HFM to FCCS – A Customer Success Story, landed Doga not one, but two awards! The session was so well received that he recently presented the same topic for ODTUG as part of their educational webinar series. In this two-part blog post, I’ll share the questions asked by webinar attendees. If you would like to watch the on-demand event, it’s available for download for ODTUG members.

Why not use Data Management for mapping of the historical data? 
We did try to go the Data Management route to load historical data. We noticed there were many mapping changes over the past five years. We did a few sample loads to see how the data would look with the existing mappings that we had in Data Management, and noticed there were a lot of reclasses of differences in mappings, and we were going to spend more time than we would like to fix these mapping issues. That’s when we decided to use Smart View templates instead of Data Management mappings.  

In the customer example you highlighted, there were three custom dimensions in HFM, but only two in FCCS.  Why is that?
As of today, FCCS has two custom dimensions if the multi-GAAP dimension is not enabled. In HFM right now, we have unlimited custom dimensions, and our customer had three. I listed three on purpose, but one of the custom dimensions they were using for the data type became a system dimension in FCCS. We were left with cost center and division. They fit that box when we were doing our implementation. Again, I don’t want to comment on the roadmap, but I think Oracle’s goal is to add more dimensions, and I believe FCCS will have up to six along with the multi-GAAP dimension is not enabled. If it is enabled, it’s going to go down to five, but as of today, it is just two custom dimensions in FCCS when the multi-GAAP dimension is not enabled. 

In the model, did any entity have non-controlling interest?
No, all the entities were owned 100% in this particular case.

We are implementing DRM. Does that work for FCCS? 
There are several different ways to manage metadata in FCCS. DRM is going to be released on the cloud as a separate product. I believe it’s called DRCS, and essentially will replicate the metadata management features of DRM and probably over time build integrations directly into the cloud applications such as EPBCS and FCCS and so on. Today, there is no DRM on the cloud yet. The integrations haven’t been built to FCCS. Your only option when implementing FCCS now is to use either Smart View to manage your metadata, the actual web browser itself, or imported file. 

Did you use a conversion utility to convert HFM metadata to FCCS?  If so, how long did this take? 
In our case, everything was basically one-to-one like accounts. We were bringing as one-to-one all the entities, the call centers, divisions. We took the extracts out of HFM and we put them—we first used web files, but then we also utilized Smart View metadata management feature. Building the members and the hierarchies didn’t take too much time at all. However, setting up the properties for each, because we were also fairly new. The back engine is Essbase, so the properties will look different. Setting those up took a little bit more time, but not more than couple days, to be honest. But building the hierarchies, that was not an issue because everything was basically one-to-one from HFM to FCCS 

Did you try the reporting currency triangulation? Did it work?
We did not need the triangulation, so I did not personally test it. We had one reporting currency, which was USD, so everything was directly going into USD, and that worked. They did not have a need for GBP entity reporting, or Canadian dollars.

A recent Perficient webinar, Oracle FCCS: A Deep Dive, held a captive audience for the Q&A session well beyond the top of the hour. In the second of a two-part blog post, I share the highlights of questions asked by attendees and answered by both Tony Coffman, Oracle EPM Practice Director at Perficient, and Rajesh Bhatia, VP of Product Development at Oracle.

Missed Part 1? Read it here.

There is a rate for Euro to U.S. dollars that exists. There’s a rate from GBP to USD that exists. Can FCCS translate to Euro from GBP without a direct rate?
Tony – Yes, absolutely. Just like in HFM, it will triangulate the rate without having a direct rate. In fact, it goes beyond that, that all reporting currencies are translated at the same time and available to pull into reports.

Do other dimensions such as customs impact consolidation time?
Rajesh – Yes, today they do because underlying it, if you know the Essbase technology, there’s a single cube today. We’re introducing this concept of hybrid. Those will not impact, then the performance of the consolidation, because those will be dynamically calculated.

Will users have the ability to build their own personal reports, or will you need developers to build reports for you in FCCS?
Tony – In the presentation, we showed financial reporting web studio. That is how you develop new print quality reports, very similar to the financial report client today for HFM. From our perspective, with a minimum amount of training, business users can use this tool to create their own reports. They do not need developers. There’s no coding involved. It’s literally drag and drop and highlight, format, create some formulas. Very much in the purview of business users to be able to develop their own reports. Now, the system does come with some dashboards and reports built in, but nothing preventing you from creating more.

Rajesh – And Tony, if I could just add to that point. One of the differences between, and I own the development of HFM as well, one of the differences that we have on our on-premises solutions is, though we have the same reporting solution even on our on-premises and on the cloud, it varies how you design a form, how you design a dashboard, etc. It’s different between planning and HFM on premises. One of our design principles when going to the cloud is to get consistency across that. Not only the reporting solutions are the same, like the financial reports, Smart View, etc. On the cloud, the way you design a form in PBCS, then tax in FCCS, etc. are exactly the same. The way you administer your PBCS, FCCS, TRCS, etc., exactly the same. It’s really built on the same EPM cloud foundation infrastructure.

Is there any kind of migration utility available to move HFM to FCCS?
Tony – Today, no. I think there’s been a difference of opinion on this. First, it was, we don’t need a migration utility, and I think Oracle has come around to seeing some of the value in it. It’s, again, farther out than the current R&D that’s planned for September. From an implementation partner perspective, it’s a tough thing to do. There’s a lot of nuance to creating a migration utility for a product as different as HFM and FCCS. I’m not saying that Rajesh and his team can’t pull it off. They’ve got some pretty bright people on the task, I’m sure. Maybe consider the results of a migration utility very similar to how it was for enterprise to HFM. Yes, it could create some HFM dimensions and an HFM rule file and so on, but you would never probably stop there and consider that best practice. It’s good for prototyping, but we’ll see.

Rajesh – Tony, I agree with what you said. It’s a tough problem and as Tony mentioned we had the same issue when we went from Enterprise to HFM. We created a migration utility for Enterprise to HFM. I think it was for Enterprise 6.5, a wizard/ migration utility. You know how many people used it? Very low number of people. The thing is, it’s an opportunity to redesign, to really see what I have in Enterprise, does that really make sense in HFM? And the same thing I would urge for you, I’ve looked at many HFM applications and there’s a lot of stuff that’s built in over the years. In FCCS we’ve done a lot of out of box. You may not want to take the same kind of rules or same kind of data that you have in HFM into a new implementation. It’s a consideration that you may want to rethink how you design that application. Having said that, we will still make some tools available to at least do maybe the metadata migration, but a rules one would be much more difficult because a lot of rules are built out of box in FCCS and you don’t need to customize FCCS, you really just need to configure it to meet your consolidation requirements.

Safe Harbor Disclaimer: Statements in this blog post relating to Oracle’s future plans, expectations, beliefs, intentions, and prospects, including statements regarding expectations of future release functionality, are “forward-looking statements” and are subject to material risks and uncertainties. Many factors could affect Oracle’s current expectations and actual results, and could cause actual results to differ materially. A discussion of such factors and other risks that affect Oracle’s business is contained in Oracle’s Securities and Exchange Commission (SEC) filings, including Oracle’s most recent reports on Form 10-K and Form 10-Q under the heading “Risk Factors.” These filings are available on the SEC’s website or on Oracle’s website at http://www.oracle.com/investor. All information in this blog post is current as of July 26, 2017, and Oracle undertakes no duty to update any statement in light of new information or future events.