Six critical success factors for a Headcount Planning project in SAP BPC

28 October 2014

Hugh Gledhill

Hugh Gledhill


Headcount planning is one of those processes which is deceptively simple: your company employs people, and those people have costs. Everyone earns a salary, everyone requires an NI contribution, bonuses and allowances apply and pension costs stack up across the board. Where the driver and assumptions that feed revenue or cost of sales planning can be hugely diverse, forecasting people costs should be standardised and consistent.

Except of course we know that working out how much your people are costing the business is never that simple. Whether it's a set of obscure pension schemes that have been closed for 20 years, or different incentives for each line of business, grade or employee: the complications crop up quickly. These difficulties are usually compounded by the fact that headcount planning is a big job! It demands a lot of finance and business input - often too much, in my opinion.

Then we come to the practicalities of producing and capturing a plan. Endless iterations of versions, updates, data streams and manually "re-cutting the plan" will be familiar to many organisations. And Excel is not the only culprit here!

For several of our clients, SAP BPC has been the answer. Over the last three years, SAP BPC 10.0 has enjoyed popularity as the planning and consolidation tool of choice in enterprise level businesses. Headcount planning is one of the key use cases, and many projects look to incorporate it as a component of an implementation. Lately I've experienced a lot of interest around BPC's capabilities in this area, and having recently finished a headcount planning project there a number of learning points which I think are worth sharing.

Critical success factors

Below are six areas which I've observed as having a big impact on the outcome of a headcount planning project. If you’re reading them with a sinking feeling, worry not: I've added suggestions as to how you can progress with what you have whilst still aiming towards these points.

1) Good HR data

The basis of every headcount plan is, of course, the employees. A robust HR system can make all the difference in a headcount plan: get it right, and you save your planning teams hours of effort pulling together HR data from disparate sources. Use incomplete or incorrect information, and you risk seriously undermining the integrity of the plan.

Worry not: if HR data in your organisation isn't in perfect shape (and that's certainly not uncommon), you can make allowances for this in a BPC model. It's perfectly possible to include processes to patch up your source information whilst keeping an audit trail of changes made.

2) A view of the end result

Ultimately you will have a requirement to review and report on your numbers in a certain way. It's easy to focus on the details of generating a bottom up plan (the fun stuff!), and end up neglecting later steps. If your process currently needs a lot of manual workarounds, recharges and cost transfers, then it's important to spend some time understanding why this happens and whether it's really required. If it is, then there needs to be a way of achieving the necessary manipulations in a systemized, controllable way.

Worry not: no one has a clear picture of all of this going into a project. Part of any project design phase should include detailed workshops designed to capture exactly these requirements.

3) A guiding principle of standardisation and consistency

I strongly believe that these kind of projects do not work if everyone gets what they want. It is inevitable that the details of planning methods vary across a business, but in most cases enforcing a single method works just as well. It provides much clearer visibility on how the plan is put together, and user training / knowledge retention is a far easier job. Central hands on participation is a must to make this happen.

Worry not: if introducing standard planning methods is likely to cause waves in your business, use your implementation partner to help. External resources can challenge existing approaches and ask probing questions which might otherwise be difficult to put forward.

4) A decision maker on process

A similar point to the last, but this time on the practical side of planning processes - the who, the what, and the when. It can be taken for granted that people know who does what, and when - but try and write it down, and it’s actually much harder than assumed. Part of the benefit of using a tool like SAP BPC is its process driven nature, so having someone to make the decisions on that process is crucial.

Worry not: my experience is that planning teams are usually willing to follow a process according to guidelines and timelines, as long as it’s well defined and well understood. This provides a certain degree of flexibility. If you don’t currently have a clear picture of the end-state process, take an agile approach during development: create a baseline process and refine through phases of development and testing.

5) Clarity over definitions

Seems like an obvious one, but it’s an ever present danger in large organisations with multiple reporting systems. If “operating costs” means different things to different teams or systems, expect endless (and fruitless) reconciliation efforts to ensue.

Worry not: a natural advantage of SAP BPC is its tight integration with SAP source systems. This mitigates the risk of mismatched definitions across a SAP landscape. Otherwise, take the opportunity presented by a new project to set or confirm standard definitions.

6) Report writing training

This is an area where the approach varies from business to business. Some organisations like to keep reporting capabilities to a small set of core users, but I think that to build user trust it’s essential to make these skills widely available. Reporting in BPC is simple enough that it should be a fundamental part of user training. An added benefit is that you can reduce the report development workload on the project team, and instead leave simple queries for planning teams to create themselves.

Worry not: if the idea of equipping all users with the ability to manipulate reports is a cause for concern, be reassured that you can still exert central control. Core reports are maintained on a server folder which only process administrators can edit. Alternatively if training every user to build reports sounds like a large overhead, consider upskilling key users in each business area and introducing a waterfall approach to pass the knowledge onwards.

Use a SAP BPC project to drive changes across these areas

If someone told me that they’d already faced up to all of these factors going into a project, I would be sceptical. The reality is that it’s going to take some work to tick off each one. Don’t be put off though: through my suggestions I’ve indicated how to leverage a BPC project to provide opportunities for improvement. But keep in mind that, at the end of the day, the tool is just a vehicle, and it needs someone to signpost the destination.


View comments


Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.