A rolling forecast, in simple terms, is a continuous planning process that often looks beyond a single financial year. I have not personally worked with many clients who use this methodology, as it’s still considered to be somewhat of a “modern” concept. Those few clients who have implemented this method often do a 12-month or 18-month rolling forecast. This means that every month or quarter the company re-forecasts the 12 or 18 month timeline at a month, quarter, annual, or mixed period level. Companies often abandon an annual plan in favor of a rolling forecast due to the common challenges with yearly cycles: stale numbers after just a few weeks or months, long preparation and execution cycles, the inability to plan far out, and lack of flexibility, just to name a few.

In my work with Enterprise Planning Cloud: EPBCS over the past couple of weeks, my team and I have found ourselves in a conundrum when it comes to designing and implementing rolling forecasts with this solution.

But first, let’s examine this feature in PBCS, which EPBCS is closely aligned to. In PBCS, Oracle’s concept of rolling forecasts includes some time-saving features that mostly focus around subvars:

• Auto-generated subvars (substitution variables) – 1 for each period and 1 for each period’s corresponding year
• The addition of those subvars automatically to newly created forms – the variables stack and auto-populate in the columns. (Note that this is both a blessing and a curse. If you have 18 rolling periods and you decide that you don’t want these in your new form, you now have to delete 18 columns. It’s best to create a master form as a base and Save As.)
• A mechanism to shift the values of those subvars easily

In PBCS, there are also options for when to enable this feature. You can choose to enable it upon application creation. If you don’t and decide to enable it after the fact, you can do that too and through a web form. You can also shift the rolling forecast periods through a web form.

Now let’s talk about EPBCS. EPBCS has the PBCS concept of rolling forecasts built in. Great, right? Well…we’ll get to that shortly.

First, let’s cover the basics of this same feature in EPBCS. In EPBCS, you can enable the PBCS concept of “rolling forecast” during application creation:

Or, if you decide to enable this after the fact, you can do this through a form:

Enabling the feature will auto-generate a list of rolling forecast subvars:

You can shift the values of those subvars through a web form:

And all new forms will populate the rolling forecast variables in their columns automatically:

Just like PBCS, right? Given all this fantastic functionality and familiar handling…what’s the problem then? If you’re using EPBCS in a standard “PBCS” way (i.e. using the Lite or Standard application types), then you’re fine and there is no difference. However, if you bought EPBCS to take advantage of the new pre-built frameworks (i.e. the Enterprise application type), then you will find yourself in a quandary if you desire a rolling forecast solution.Why?

Ask any Oracle EPBCS person and they will tell you that rolling forecasts are not supported for out of the box frameworks. What does this mean?

In EPBCS, there are 4 pre-built frameworks that can be enabled:

1. Financials
2. Workforce
3. Capital
4. Projects

And there are a number of pre-configured components that come out of the box with these frameworks. At a minimum, the list of components includes:

• Dimensions
• Forms
• Dashboards (which use the pre-built forms)
• Member formulas
• Calc Manager rules
• Navigation flows
• User variables
• Valid intersections (well, I’ve seen one generic one so far)
• Smart lists

In order for Oracle to have created all of this awesome pre-built stuff, they had to pick a direction on how to design calculations and forms and how subvars would be integrated into that design. So what they chose (and for very good reasons) was that the pre-built content wouldn’t use the rolling forecast subvars…like, at all. I won’t go into all the reasons why Oracle had to make this decision, but you’ll understand once you get in and see how the driver-based calculations work and the flexibility allowed by the pre-built planning processes. There’s room for improvement in their design, so it will be interesting to see how this evolves over time.

Going back…so the PBCS concept of “rolling forecast” does exist in EPBCS and it works, but as the Oracle team will tell you, it’s not truly supported by the pre-configured objects.

Believe it or not, there’s a separate set of subvars that gets created for each framework. For instance, take a look at the subvars that were generated when I configured the Financials framework:

Notice some similarities? You can see that these subvars are also related to the period and year dimensions. (Note that our team has found that the 3 variables that don’t start with “OEP_” are leftover code and aren’t being used by anything.)

This list of subvars works a bit differently from the rolling forecast subvars. They aren’t carved out by both period and year. In addition, you can’t remove these. Since they are tied so tightly to the framework objects, EPBCS grays out the option to delete them.

These subvars are controlled by the configuration area of Financials called Planning and Forecast Preparation. In this area you control what your Plan and Forecast look like: how many years out you’ll perform each planning process, when the Plan starts, the start period and year, and the period breakdown for each year and planning process. Here are what the Plan and Forecast sections look like in Planning and Forecast Preparation:

Note that the settings on the left-hand side are global. The settings on the right-hand side are customizable by planning process – “Plan” or “Forecast”.

In a frameworks world, it is this area that drives the period and year members used by business rules, member formulas, forms, associated subvars, and other pre-configured objects. You can see how the settings above affected the Forecast (“OEP_Forecast) and Plan (“OEP_Plan”) scenario start period and year settings below:

And this happened auto-magically behind the scenes once the Planning and Forecast Preparation settings were modified. Nice, huh?

So if the pre-built frameworks are all using one set of subvars, what does that mean for the rolling forecast subvars? Well, they just kind of…co-exist. You maintain each set separately.

Confused? We were too. So we started thinking through what would be the best solution for our clients. You really need the best of both worlds to execute on a rolling forecast. However, the calculations aren’t built to use the rolling forecast variables. And the forms become somewhat bipolar when you use both. The pre-configured forms continue to use the pre-configured subvars, while any new form reverts directly to the rolling forecast subvars. There are also many other disparities. What’s a developer to do?

For now, this means that custom work will be necessary to get the framework subvars and the rolling forecast subvars to play nicely together. In my opinion, this additional effort is still better than “rolling forecast is not supported”, but it does come at a cost and requires a learning curve. Your developers will need to understand how the frameworks work under the covers in order to make the rolling forecast fit. Oracle understood that their customers might need specializations inside the frameworks, so they put some governance in place. There are a number of framework components that can’t be deleted or modified. Luckily, they gave you the ability to take an existing object and Save As so you can make your own modifications.

In addition, there is an opportunity here, too. With the advent of Oracle EPM cloud, Oracle has proposed this idea of “crowd surfing” the industry for ideas and sharing development objects. They’ve created a portal called Customer Connect where customers who are invited can participate in forums with other customers, talk directly with the Oracle development team, and share objects.

So if you find yourself in the situation where you really need a rolling forecast and you also want to leverage the frameworks in EPBCS, consider having both. It will take more time, but this will also save you time in the long run.

November 2016 Update: In the November update, Oracle added a feature that offers a new option to rolling forecast: “Planning applications now support the ability to set scenario and period suppression by column segment. This new feature allows you to create rolling forecast at a quarterly level leveraging the custom members that you add into the Period dimension. If the option to suppress invalid scenario/period is enabled, custom members are not displayed in rolling forecasts.“

In tomorrow’s 7th and final daily post for this week (more series posts to come in the future…post-Kscope16), I’ll cover the new feature called Navigation Flows.