Implementing Zero-Based Budgeting: The Requirements

A Culture Change and a Centralized System

The first post in this 3-post series – Implementing Zero-Based Budgeting: Benefits, Myths, and Goals – covers the benefits of zero-based budgeting. To summarize, it enables you to achieve long-term savings that result in sustainable growth and holds your financial analysts accountable for the cost figures they approve and how they are managing the overall budget. This allows more effective recognition of any unwanted costs and how you that money can be shifted into other growth areas within the company.

However, to reap the benefits of a zero-based budgeting program, a culture change is needed first at certain levels within the company. The goal is to eventually have the entire company complete this culture shift, but it is best to start small. Along with a change in culture, a centralized reporting system needs to be created as well to provide teams the ability to share real-time numbers with each other to achieve the goals of this new budgeting program.

Better Than a Quick Fix

What exactly is meant by a culture change? This means starting small and fostering this culture change in other departments starting with Finance. To be successful with this new program, other departments will eventually have to jump on board with this new budgeting approach. These departments will need to step up in analyzing their own costs and how they can save more without diminishing their capabilities.

For example, while financial analysts talk to the shop floor to see where costs can be reduced, the HR department should work with Finance to determine how it can become leaner. Moreover, the IT department should take the lead on negotiating with its vendors to find any areas that can be saved. These are just a few examples of how different departments can step up to the plate; implementing a successful zero-based budgeting program will requires team effort.

Changing the culture doesn’t happen overnight. Senior leaders should take the lead in fostering this change. To ensure that everyone is on the same page, managers need advocate the new approach within their respective departments.

Incentives also help teams to buy into this new budgeting approach.  Although incentives for growth metrics may already exist, additional incentives can effectively encourage staff to find ways to reduce costs for the metrics they manage.

Some examples of incentive metrics are the realized ROI based on the requested capital expenditure and the total cost saving dollars resulting from a zero-based budgeting program. For the former, this can mean moving to the Cloud to save money or reducing redundant tasks by introducing centralized software. For the latter, it can be exemplified by achieving a 10% cost reduction per phone.

Best Practice to Achieve Success

A crucial component of the success of a zero-based budgeting program is an officer who governs the entire process from start to finish. This individual (or team) should contain deep knowledge of the budgeting process. Naturally, s/he will not know the ins and outs of each department, so that is why s/he needs to be an ambassador to department leaders. The officer will also provide oversight to ensure that past bad habits of budgeting do not return to plague this new program. And lastly, s/he must be dedicated to the craft of continuous improvement which means seeking outside counsel when needed.

As mentioned earlier in the post, a culture change needs to be accompanied by a centralized reporting system. Alithya has helped clients implement Oracle Planning and Budgeting Cloud Service (PBCS) and Enterprise Planning and Budgeting Cloud Service (EPBCS) and overcome the deficiencies of Excel-based models. These models lose sight of what the true cost numbers are because past budgets are simple anchors of history rather than detailed breakdowns of cost. Moreover, these numbers become siloed within the vast library of Excel models. With Oracle PBCS or EPBCS, budgets can be highly surgical and help leaders in the company pinpoint reductions.

A centralized system allows the capture of all changes in a single location in real-time, and it provides insight into how effectively managers seek cost savings. This can be used as a key indicator to determine if their actions are in line with this new methodology.

Furthermore, centralization not only holds managers more accountable, but it also empowers them to create innovative cost-saving solutions. Driven by incentives, staff will burn with a clear purpose to find new ways to achieve sustainable growth for the company and be rewarded for hard work.

Recapping What It Takes to Achieve ZBB Success

The goal is to create a cost savings culture that allows more capital to be invested into growing parts of the company. To be successful, follow the best practices outlined, starting with a culture change within the company and giving your teams a centralized PBCS and EPBCS system to more clearly see all data points. The hard work does not stop here, though! The next post delves into setting up a zero-based budgeting system.

Implementing Zero-Based Budgeting: Benefits, Myths, and Goals

If you are in the finance world, then you probably have heard of zero-based budgeting. Investopedia defines zero-based budgeting as “a method of budgeting in which all expenses must be justified for each new period. The process…starts from a “zero base,” and every function within an organization is analyzed for its needs and costs.”

There are many reasons that financial professionals decide to use zero-based budgeting. For one thing, it goes hand-in-hand with a centralized system where information can be shared – something at which Excel spreadsheets are terrible. Furthermore, developing a centralized system enables you to scale to your needs as your company grows. Lastly, it enables financial analysts to spend more of their work week analyzing data instead of curating a financial system and worrying if the numbers match.

At Alithya, we have found with our past clients that a successful zero-based budgeting implementation resolves numerous problems. The two main things clients hope to achieve is growth across multiple business units and developing sustained cost reduction. With zero-based budgeting, you can earn long-term savings that can directly translate into sustainable growth.

Earning Long-Term Cost Savings

Zero-based budgeting becomes a daily exercise in cost savings for your financial teams. One method in achieving cost savings is renegotiating costs. For example, instead of taking the run-rate of 3% from last year’s numbers, perhaps you can contact your vendors to bargain for a better deal or switch to a different vendor with a more competitive price. Or how about having your analysts ask the IT department why it costs $38.03 per phone? What makes up that entire $38.08? Don’t assume that there aren’t any negotiable components of a cost.

The reason zero-based budgeting is so effective at long-term savings is that it is not a one-off fix. Many teams tend to implement one-off fixes, and then find that those fixes do not provide sustainable cost savings. A common example is offshoring your call center which might get you an immediate win in the cost column. However, this strategy typically reduces customer service quality while also limiting your ability to evolve with your business as it grows.

When enacting this type of program, you will analyze the costs of your business at every level. This may seem tedious, but what you will find is a clearer understanding of where your money is going. This can mean acquiring a greater understanding of contract labor costs as well as improving purchasing and procurement procedures, just to name a few. Moreover, when properly implemented, zero-based budgeting can reduce SG&A costs by 10 to 25 percent, often within as little as six months,” according to McKinsey & Company.

Debunking Myths Surrounding Zero-Based Budgeting

There are many myths surrounding zero-based budgeting that have sadly created an artificial barrier that CFOs and their teams do not want to cross. Many financial professionals think that it means cutting the budget down to the bare bones, but rather, a zero-based budgeting program analyzes costs from the top-down. Moreover, it is the CFOs’ duty to outline cost-cut targets so that their team’s efforts are focused.

Another misconception is that zero-based budgeting only helps with cutting the costs of SG&A. Actually, it can do much more, such as breaking down the Cost of Goods Sold (COGS) and help teams make investment choices on the capital expenditure with the greatest ROI.

Just because your business is not in decline or stagnating doesn’t mean that you can’t adopt a zero-based budgeting program. If you are already achieving growth, you can use this type of budgeting method to keep the overall business leaner so that you can provide more runway for growing business units.

Do you really start from zero? This is a common question that we are asked, and many people think because of its name that you do always start from zero. Technically, this is true, but this is the core component that drives the cost management culture change that will be introduced in the next post in this series.

However, not all things have to start from zero. At Alithya, we have been through many implementations where parts of the P&L are driver-based or zero-based. This can be achieved with a detailed, structured, and interactive system (like Oracle PBCS/EPBCS) that gives you real-time feedback.

How Does Oracle PBCS and EPBCS Help Achieve ZBB goals?

The main feature you acquire when you implement an Oracle PBCS or EPBCS system with your zero-based budgeting program is deeper analytics. This data enables you to dig into the “why and how” of your P&L.

For example, you could pose the question what driver did they use? Did they just simply take last year’s actuals and add 3%? Did they take a cost-per-head and budget it manually, or did they take the easy way out? All are important questions that force finance teams to be more accountable when it comes to everyday decisions.

Recapping the Benefits of ZBB

By implementing a zero-based budgeting program with a centralized system, you can hold your analysts more accountable to cost figures while making them own up to how the costs are managed. It allows you to recognize any unwanted costs that can be diverted into certain growth areas as well as breed a culture of cost reduction and visibility. The latter requires that you to start a culture change within your team. It is an essential part of having success with a zero-based budgeting program which is why we will cover it in greater detail in the next post.

PCM Micro-Costing, a Framework for Detailed Profitability and Costing

Oracle’s Profitability and Cost Management Cloud Service (PCMCS) provides a powerful service for allocating General Ledger profits and costs.  Recently, we worked with a banking industry client to provide a model that calculates profitability at a Product/Channel level while maintaining Account level detail.  We accomplished this through a framework we refer to as Micro-Costing where detailed profits and costs are calculated in a database using rates developed at the summary level in PCMCS.  Alithya began development of this framework in 2016 to meet a functional gap in PCMCS and provide a common framework that can be used either on-premise or in the Cloud.

To highlight the capabilities of Micro-Costing, I will use the solution deployed at our banking client as a specific example.  The following table describes the two layers where profits and costs are provided:

PCM Micro-Costing, a Framework for Detailed Profitability and Costing - Image 1

 Definitions:

  • Product – a loan or deposit offering. Examples of a loan are an auto loan or credit card; examples of a deposit are a savings account or a checking account.
  • Origination Channel – where the account was originated.
  • Service Channel – where the financial or transactional cost or profit is occurring or assigned to.
  • Customer – a legal entity responsible for accounts; for example, a person with both a home loan and a savings account.
  • Customer Account – a product that is assigned to a customer.
  • Financial Costs and Profits – the cost or profit of servicing a loan or deposit for a customer; for example, interest paid on a savings account.
  • Transactional Costs and Profits – the cost or profit of interacting with a customer; for example, the cost of an ATM transaction.

A simple way of thinking about the client’s business model:

  • Origination channels offer Products
  • Products are assigned to Customers as Customer Accounts
  • Customer Accounts are used by Customers through Service Channels

The generation of an Account level profit or cost is a C = A*B calculation where

  • A is the driver
  • B is the rate of a driven value
  • C is the driven value (profit or cost)

An example is:

ATM Expense = ATM Transaction Count * ATM Expense Rate

Micro-Costing Diagrams

Data Model

This summarizes the data model deployed.

PCM Micro-Costing, a Framework for Detailed Profitability and Costing - Image 2

STAGING – Contains transient data.

OPERATIONAL DATA STORE (ODS) – Persists the operational data with minimal transformation.  Dimensional integrity is not enforced, but validation jobs are available for validating stored data regarding rules and dimensional integrity.

WAREHOUSE-STAR – Persists the drivers, the rates, and the calculated profits and costs at the Customer Account level.  The Driver Lookup and Driven Value Lookup functions are used to define the drivers and driven values so that the addition of a driver or driven value is a configuration activity for an administrator rather than a coding activity.

Data Integration

A high-level summary of the data flows as deployed:

PCM Micro-Costing, a Framework for Detailed Profitability and Costing - Image 3

The source data is broken down into 3 types:

  1. General Ledger
  2. Operational Data
  3. Metadata

Data Integration uses interim flat files to maintain flexibility regarding the source data by establishing an API via the flat files without requiring knowledge of the source systems.  This allows for the introduction of source data that comes from 3rd parties not available for automated extraction from the source.

The operational data includes both Customer Account financial information and transactional activities or fees.  Product and Channel references are provided along with this information:

  • 1 million+ Customer Accounts
  • Approximately 6 million transactions per month

Some transactional drivers represent an activity that cannot be associated with a specific Customer Account; for example, a new loan application.  Proxy Customer Accounts for each product are generated to provide a place for these activities.

Additionally, although not graphically displayed in the above diagram, Branch level drivers are directly fed into the PCM Model, examples of which are Branch square footage and number of branch employees.  These drivers were used for non-Customer Account PCM costs and profits.

All Batch processing is built using SQL Server Integration Services.  This is based upon an agreement with the client regarding the preferred tool sets with the database selected being SQL Server.  Framework is transferable to other integration tools and databases including Hadoop framework, and in-house solutioning by Alithya was performed in preparation for use of the Micro-Costing framework with larger clients.

The data integration is as follows:

  1. Set POV
  2. Update metadata and stage
  3. Stage financial and transactional information
  4. Validate staged data and reprocess as necessary
  5. Load staged data to ODS and then to Star
  6. Upload PCMCS with GL and drivers
  7. Process allocations in PCMCS
  8. Download rates
  9. Run A*B calculations for each Customer Account and populate profit and cost table

Key Design Principles

The following design principles were focused on during development of the Micro-Costing framework.  These principles facilitate an easy-to-use and easy-to-maintain solution as deployed for our client.

  • Dimensional synchronization between the Micro-Costing warehouse and PCM
  • Validation checks as close to the original data as possible
  • Configurable drivers and driven values

Dimensional Synchronization

All dimensional mapping must occur prior to the warehouse star schema.  It is not possible to perform the Micro-Costing A*B calculations to derive profits and costs detail otherwise.  This has an impact on any deployment that uses FDMEE or Cloud Data Manager as they cannot perform additional mappings during upload to the cube.

Dimensional Synchronization includes a Point of View: Year, Period, Scenario, and Version to allow for loading multiple sets of drivers during a month, and for transfer of ‘what-if’ rates back to the Customer Account level, if desired.

Validation Checks

Validation kick-outs and checks occur as early in the data integration process as possible, with a “simple” validation during staging and a “complex” validation during generation of the fact information in the warehouse.  This allows the administrator to catch quality issues with a minimum amount of overall process duration occurring.  The data integration process is broken into a series of steps that allows for validation review and then re-running a step prior to moving on to the next step.  This principle held up in deployment, ensuring that time wasn’t wasted running later processes with invalid data, the result being an improved overall process and a significant reduction in the number of days required to produce profit and cost analysis for a given month.   A lesson learned during the initial roll-out was that our client had not previously required a rigorous validation of the drivers at the Customer Account level and had to develop new techniques for validating the source information to ensure accuracy.

Configurable Driver and Driven Values

A key feature of Oracle’s PCM applications is configurability, and the Micro-Costing framework is built to provide an easy-to-maintain solution that allows for rapid addition of drivers and driven values without the administrator having to manually update the tables and views required to manage the transformation and persistence of data.  This was accomplished by defining the drivers and driven values in tables and providing stored procedures for maintaining the tables and views.

The process for adding a new driver and driven value is very straightforward:

  1. Backup the database and the PCM cube.
  2. Update the source feeds to include the new activity or fee.
  3. Update the activity to Driver Lookup and Driven Value Lookup tables with the new values.  *Note: The driven value record references the driver for the A*B calculation.
  4. Execute the “Update Costing Tables and Views” stored procedure. *Note: removing a driver or driven value does not modify the tables.
  5. Update HPCM Account dimension for the new driver and driven value.
  6. Update HPCM rules to use the new driver and allocate expenses to the new driven value, and calculate the rate for the new driven value.
  7. Run the entire data integration process for the POV, and review results.

Key Benefits

The successful deployment of the solution provides the following key business benefits:

  • An improved ability to provide Product/Channel level costs and profits.
  • Reduced monthly cycle time and effort. The prior data integration process was disjointed and required a large amount of effort to produce results.
  • Drill-through capability to Customer Account level drivers, profits, and costs allows for root cause analysis of Channel and Product Costs.
  • Aggregation along other dimensional paths. Starting at the Customer Account level allows for aggregation along Customer attributes such as zip-code or credit score, providing new insights and enhanced executive decision making.  A follow-on project to use the Customer Account level data in OAC is currently being assessed.

Additionally, the following benefits to the administrative team are realized:

  • Model flexibility. The configuration of an additional driver and driven value in Micro-Costing takes fewer than 15 minutes.
  • Operational Data Store (ODS) and Warehouse. This allows for future projects to use a common curated source of information.  This was a pot sweetener for our client who was dissatisfied with its prior warehouse, but needed a business reason to refresh.  The prior warehouse lacked the following items that were addressed in the new ODS and warehouse:
    • Explicit mappings such as Activity Code to Driver Code that are controlled by the business
    • 3rd party data from partners and industry sources
    • Consolidation of financial and transactional information into Customer Account level facts
    • Hashing of Personally Identifiable Information (PII) for account security
  • Easy troubleshooting, validation, and auditing capabilities with PCM. Errors or mismatches in profit or cost at the Product/Channel level can be reduced to either rule definition mistakes or driver data entry mistakes. Finding out where the issue is and correcting it with a few clicks has a positive impact on the overall analysis and maintenance effort.

Final Thoughts

Alithya has developed a Micro-Costing framework that allows an integrated view of profits and costs at both a summary and detailed level.  This framework is successfully deployed at a banking industry client to provide a superior solution.

Framework is deployable either on-premise or in the Cloud and is available for other industries such as:

  • Patient encounters in Healthcare
  • Claims in Insurance
  • SKUs in Retail
  • Subcomponents in Manufacturing

…or anywhere the allocations occur at a summary level with drivers aggregated from a detail level.

 

Demystify the Balance Dimension in Profitability and Cost Management

Management Ledger models, whether Hyperion Profitability and Cost Management (HPCM) or Profitability and Cost Management Cloud Service (PCMCS), have been around for a few years, but I still receive emails asking for help with figuring out where the results are coming from. This request is often related to a lack of understanding of the Balance dimension. Here are some key pieces of information regarding this system dimension, how it works, how it should be used when defining allocations and integration jobs, and how to leverage it to troubleshoot your allocations.

Before we have a look at each member within this dimension, let’s go over some basic rules that govern the creation of an HPCM or PCMCS Management Ledger (ML) application:

  1. All HPCM or PCMCS ML applications must contain just one dimension named Balance
  2. Members and their properties cannot be edited or removed.
  3. You don’t need to import a file in order to load/setup the Balance dimension; members are created automatically when deploying an application for the first time.
  4. You can choose to rename the Balance dimension (translate it into another language, for example) when you first set up the application in PCMCS.

For the most part, the Balance dimension members are quite easy to follow and understand, but familiarity with usage guidelines helps to avoid issues during development and supports troubleshooting.

Demystifying the Balance Dimension in PCM - Image 1

  • Input — Used to store data input/pre-allocated data sets, whether these are pool or driver data sets. Data is generally loaded against this member in combination with the NoRule member. Input can be populated through custom calculations, but it is generally advised to keep it dedicated to valid data loads/input rather than for storing calculated or allocated results.
  • Adjustment In —Adjustment In can be used for manual adjustments to the Input data prior to running allocations. In this case, the Adjustment In data will be loaded against the NoRule member. Any manually submitted data on the Adjustment member against a Rule ID member may be eliminated during the subsequent data loads and calculations. Adjustment In can also be used during custom calculations to store intermediary values or calculated driver data.
  • Adjustment Out —Same usage as for Adjustment In, but with a negative data value.
  • Allocation In — This member will be populated against the Destination or Target intersection for the allocation rule.
  • Allocation Out —This member will be populated against the Source intersection of the allocation rule and the corresponding Rule ID member, or against a predefined “Offset” intersection that is custom defined for a given rule.
  • Allocation Offset Amount — Displays an amount that further reduces an Allocation In member, if one was used in addition to the Allocation Out. I have provided an example of how this member is populated and used in a lower section of this post.
  • Net Change — represents the total change for a given intersection, regardless of alternate offset actions.
  • Net Balance – sum of Input (initial data loaded) and any Net Changes made to the same intersection.
  • Remainder — Displays the difference between Allocation In and Allocation Out plus Allocation Offset Amount, if any.
  • Balance — The amount resulting when adjustments, allocations, and offsets are considered.

Rules assign funds to destinations based on the way you have defined the allocation logic (member selections, sequencing, concurrency, etc.). “Allocations in” and “allocations out” are being generated upon executing the calculations of the Profitability model. Each pair of adjustments and allocations (the “in” and the “out”) should result in a zero sum in order to balance the transaction. The Input member is affected by each adjustment and allocation. The difference between what was taken from Input and what remains at the end of an allocation will be accounted for in the Remainder.

The Remainder member is the source of your allocations, not the Net Balance member, as most would think.  Remainder takes into consideration alternate offsets and ensures we do not perform a double booking or a double allocation of the same data source, regardless of where the offset was applied.

To further explain the Balance dimension usage, I have used an example from the Bikes default application BksML30, which can be deployed into PCMCS through a few clicks.

The original application had only one adjustment Rule populating the Adjustment In member. I have copied that rule and reused it to demonstrate the same usage for the Adjustment Out member. Remember the adjustment out aggregation operator is still +, so if you want to offset data sets, you must use the appropriate signage for your data; in other words, negate the result either via a multiplication with -1 or by simply adding a – to the formula.

The new ruleset contents will look like this:

Demystifying the Balance Dimension in PCM - Image 2

Our initial data set is loaded on the Input/No Rule combination for the two accounts – Rent and Utilities – on the intersection with Corporate Entity.

The data adjustments are stored against Adjustment In and Adjustment Out.

Demystifying the Balance Dimension in PCM - Image 3

In order to further illustrate how to correctly follow the allocation process, I split the original Reassignment rule into 2 rules, each dedicated to its own account. I also updated the metadata by adding two new Account siblings to Rent and Utilities as offsets for each account.

Alternate offsets are simply intersections of members where you would like to store the offset data point, if it should differ from the source of the allocation.

The Remainder member demonstration is connected to the usage of alternate offsets, and before we go into the details of the numerical example, I would like to list out a few rules for setting up alternate offsets:

  • Alternate offsets are available for selection only in standard allocation rules. For Custom calculations, your Offset custom calc would have to be pointed to the appropriate “alternate” target.
  • All dimensions, including the ones predefined in the rule context, are repeated in the Offset screen as soon as you select “Alternate Offset Location.” You must select a single base level member for at least one dimension.
  • There is no “Same As Source” (SAS) option for offsets. The dimensions that must be offset on the Source intersections can be left blank in the Offset screen selections.
  • If each source member selection has its own offset, you will have to split the rule up into as many granular rules as needed in order to cover the individual offset selection. For example, if you have 6 accounts, each with its own offset account equivalent, you will have to create 6 standard allocation rules to create the individual offset selection for each account.

Going back to the numerical example and the usage of the Offset tab, in the update rule I have selected the below member intersections:

Demystifying the Balance Dimension in PCM - Image 4

The Source account was Rent, target is “Same as Source” (SAS), and the alternate offset account is FACOffset_Rent.

After the rules are executed, we will see the results below; focus on the Allocation Offset Amount member and the Allocation Out Member.

Even though the offset was applied to an alternate account for both Rent and Utilities, the allocation engine correctly identifies the Remainder of these two accounts as being 0.

  1. The first step behind the scenes is for the allocation to correctly distribute the data to the target intersections.
  2. The second step is to perform the offset on the intersection specified by the user, if different from the source intersection.
  3. The third step is to copy the Allocation Out value onto the Source Intersection members, on allocation Offset Amount member. This final step is performed via a custom calculation embedded in the PCMCS generated scripts which ensures there will be no double counting of pool data.

So even though we “moved” data from the Rent account, Corporate Entity, to other Entities, on the same target Account, the offset was performed on an alternate member. This allows us to create a report with Rent (Input), Rent (Allocation In) and FACOffset_Rent (Allocation out).

This is not a typical example of how alternate offsets are used from a functional standpoint, but it helps explain the mechanics behind the scenes. This alternate offset option is mostly used in cases where a Bill Out account and a Chargeback account will differ and allows users to trace which portion of a chargeback account is coming from different source accounts.

The final goal of an allocation is to generate a Remainder member with a value of 0. This ensures the total allocation of a pool data set, whether this was loaded or received from prior allocation steps. If the Remainder member has a positive value, then it is indicating that you have not fully utilized your pool data. If the Remainder member has a negative value, then you have overutilized your pool data which may be, in some cases, intentional.

Demystifying the Balance Dimension in PCM - Image 5

In situations where you will not give access to the PCMCS ML application to users who need to understand the various components of a data point flowing through the allocation steps, due to licensing costs or other considerations, the usage of alternate offsets throughout your allocation flow might be helpful.

When talking about reporting out of PCMCS ML, our clients always emphasize simplicity, and we often get requests to remove the Rule and Balance dimensions from final reporting solutions, to cancel the noise and give finance users solely the core information. In such situations, the usage of alternate offsets has proved beneficial as these finance users can still follow the flow and components of a cost without having to deal with the rule by rule detail. If further investigation is necessary, this can be pursued within the PCMCS ML model itself rather than in the external reporting solution.

If you need further help with figuring out the purpose and usage of the Balance dimension within PCMCS, email us at infosolutions@alithya.com. Our PCM Center of Excellence team is ready to share leading practices and industry-specific solutions that accelerate your ROI and expand the capabilities of your chosen profitability software.