Table of Contents:
Anaplan has had challenges getting our finance, human resources, and sales teams on the same page of what our headcount is and what our headcount is forecasted to be in order to hit our revenue targets. We struggled to understand where requisitions were in the cycle and how many were currently open. As a result, we built a connected Anaplan dashboard to help transform conversations between teams to focus on understanding the different forecasts and strategic planning across those forecasts.
As a hypergrowth software-as-a-service (SaaS) company, the ability to hire quality candidates and stay on track with hiring targets is critical to our success. We had been consistently falling behind our sales force’s net headcount due to not hitting hiring targets, as well as having wrong assumptions on our ability to hire, generating non-achievable net headcount numbers.
Non-subject-matter experts were responsible for entering in information regarding open headcount requisitions. This resulted in recruiters having to exceed finance’s budgeted compensation forecasts to hire quality candidates, roles taking longer to staff than forecasted, and perhaps most importantly, a lack of transparency for key stakeholders (i.e. hiring managers had little visibility into how close they were to getting a new hire, the recruiter did not know when they would be getting a batch of new jobs to recruit against, and finance could not see where recruiting was in terms of staffing active requisitions).
Our finance team was required to do hours of time-consuming manual reconciliation to make sure that each to-be-hired requisition was “deactivated” upon an employee filling that role, rather than focus on value-add activities and analysis.
Between Anaplan, our human capital management (Workday), application tracking system (Greenhouse), and customer relationship management (Salesforce), there were myriad discrepancies for attributes tagged to to-be-hired requisitions. Which office would someone sit in? Which territory would a new sales rep cover? These are questions that oftentimes could not garner a single answer when different teams and systems were asked. We needed a single source of truth, less prone to human error.
The proposed solution to address the above pain points was to bring the entire headcount requisition planning process into Anaplan. This would allow finance, sales, hiring managers, and recruiting to share data freely and provide full transparency into the hiring process while allowing subject-matter experts to provide inputs where needed.
We have broken our workflow down into six different stages:
Stage 1: Finance works with their partners in the business to plan and create new to-be-hired people requisitions in their planning, budgeting & forecasting (PBF) model. Using a numbered list, a unique, immutable code is assigned to the requisition, which will follow it through the rest of the below steps (REQ #XXXXXX). A requisition is then created in the PBF model, and either manually "released" by the finance manager overseeing that requisition, or if it is a certain number of days to the forecasted start date, the requisition is automatically "released" into the process.
Stage 1.5: If the requisition is for sales, it is then imported into our sales planning management model (SPM) where our sales ops team tags the relevant assignment data (geography, territory, etc.) based on their planning and forecasting needs.
Stage 2: After that step (and after stage 1, if the requisition is not for a sales rep) the requisition is then imported into the new hiring manager model (HIRE). At this stage, the hiring manager tagged to the requisition tags additional attributes to the requisition that they are best equipped to answer such as the job type, job level, and location of the requisition. Layering in the mappings imported from our Compensation model allows for a nuanced view of the total compensation that supports the req being developed. The hiring manager then clicks a Boolean line item indicating they sign off, and the requisition is "released" to the next stage.
Stage 3: Once the hiring manager signs off, the requisition is imported into our recruiting management model (RECRUIT). This model contains a dashboard for recruiters to go in and enter in the final set of data necessary for the requisition to be written into our applicant tracking system (ATS): information such as the legal entity the requisition will be hired into, a template job to use to make the requisition in our ATS, etc. A series of logic determines if a requisition is ready to be created in our ATS. If all mandatory fields are filled in, as well as finance/hiring manager/recruiting sign-off has been provided, the requisition becomes unfiltered on a saved view that an integration with our ATS picks up, which runs every hour.
Stage 4: Recruiting then goes through their normal hiring activities in our ATS, and eventually a candidate is hired in the requisition position.
Stage 5: We have another integration running from our ATS to our Headcount Management Software (HCM) so that when a candidate is hired, they immediately have an employee profile created in our HCM. One of the attributes is the unique requisition ID mentioned in step one. We have scheduled loads of employee data from our HCM into our Anaplan Data Hub model, as well as the planning, budgeting & forecasting model. When PBF detects an open requisition ID on an employee profile line, the formulas are built to "turn off" the requisition from the forecast, and "turn on" the new employee, creating a seamless, automatic cutover from a to-be-hired to an actual employee.
Anaplan headcount planning model structure and data flow.
Five separate models are involved in the facilitation of this process that all sit in separate workspaces:
Why did we decide to use multiple models instead of one large model?
We take advantage of each user-provisioning functionality Anaplan provides. We use model roles to segment users by their job role in the model and pair that with selective access and Dynamic Cell Access (DCA):
This project spanned multiple departments and stakeholder groups. At a high level, the teams involved:
Description of the type of activities, if applicable:
|Finance Partner||Sales Ops Partner||Hiring Manager||Recruiter||3oA|
|Create New Requisition||R||C|
|Approve New Requisition||R||R (if applicable)||R||
|Assigned Territory to Requisition (if applicable)||C||R||I||I|
|Fill in Data Re: Requisition||R||R||R||R||C|
R = Responsible, A = Accountable, C = Consulted, I = Informed
|Source System||Target System||Description|
|Salesforce||Anaplan||Account and Opportunity Data|
|Anaplan>Anaplan||Multiple Models||Model data syncs across involved models|
Besides Workday employee data, the above integrations are scheduled via HyperConnect to run every hour. Data created in each model is shared between the models via scheduled model-to-model imports using HyperConnect. Greenhouse to Workday is configured as an event-based webhook, so when a new candidate is hired the candidate’s information is immediately sent to Workday to create a new employee.
As information is updated in each model, part of the hourly sync cadence is to sync all requisition data between each model. This is done by running an import process in each model that imports data from the other models. These processes run sequentially before the integration to Greenhouse runs. This allows groups to layer in their own data checks at each part of the process and share those checks with each model. They are consolidated in the recruiting management model where our “master” checks reside. It looks for data completeness, as well as all other models signing off on their own checks. For example, if a hiring manager pushes through data with a salary of $100K and last second decides to change it to $200K after finance and recruiter signs off, the logic finance has built into their checks to flag out of budget compensation would be triggered ahead of the integration. This flag would pull the saved view out of the final staging view and the requisition would not be picked up.
When a requisition was released by finance, it would take over a week (if not weeks) to be created. Now with this new process created, our average time from when finance releases a requisition to when recruiting begins recruiting against it is less than six days. In fact, once recruiting gets the information from finance and the hiring manager, the average time to begin recruiting is less than a day! The decreased time allows recruiters to do what they do best: get a quality candidate hired. With more time to have a job posted, candidates interviewed, and offer negotiations completed, they can focus on hiring quality candidates while still hitting the company-wide hiring targets.
Now that each stakeholder group has its own Anaplan model and dashboards, there is no ambiguity for whose court the ball is in (i.e. what part of the process is the requisition stuck in?). Hiring managers can quickly see where each of their hires is along the process, and recruiting can proactively reach out to stakeholders to guide them along in filling out their information.
With a single source of truth for requisition ID numbers, and integrations automatically flowing data between systems, our finance team no longer has to spend hours reconciling which requisitions have been hired. In our planning models, a requisition is automatically “turned off” and converted to an FTE when a new hire fills an open requisition.
Prior to this process, a requisition could be released from finance, have its compensation profile drastically changed, or its sales territory altered, etc., without any indication or notification. Only after an offer approval came through to finance and sales ops did they find out that something was wrong, which led to last-minute scrambling and process hang-ups when they mattered most (trying to lock in a quality hire). Now that each group is responsible for and has visibility into the attributes they care about, those problems are brought to light and rectified early on, far before they become issues in crunch time.
It’s clear to see the benefits that moving Anaplan’s headcount planning process into the Anaplan platform has. Those benefits were made possible by the partnership and hard work of the finance, talent acquisition, human resources, and sales teams. If you want to learn more about how Anaplan does headcount planning, reach out to your account representative for more information and a demonstration.