Table of Contents:
- Problem Statement
- Proposed Solution
- Stakeholders & Responsibilities
- Data Sources & Integration
- Return on Investment
- Conclusion
Problem Statement
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.
Inconsistency in hitting hiring targets outlined in operating plans
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.
Misalignment of roles and responsibilities between the stakeholder group and those closest to the requisition due to lack of transparency and interaction in the process
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).
Time-consuming and error-prone process in closing out requisition when converting a to-be-hired to an employee
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.
Inconsistent data across enterprise systems
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.
Proposed Solution
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.
Overall Workflow
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.
Model Structure
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:
- Data Hub
- Planning, budgeting, and forecasting (PBF)
- Sales planning management (SPM)
- Hiring manager model (HIRE)
- Recruiting management (RECRUIT)
Why did we decide to use multiple models instead of one large model?
- The first reason was the ease of user management. Since several of these models are core planning models, they contain sensitive financial and employee data. Breaking up the models mitigates the risk that someone accidentally was given inappropriate access by keeping finance partners in their own planning model (PBF), hiring managers in their own model (this is the largest user base in the process), and human resources and recruiting planning in their existing recruiting management model. That way, for example, a hiring manager has no risk of mistakenly being able to see our financial projects in the PBF model.
- The second reason is that smaller use-case-specific models greatly reduce the recalculation time of the imports required given the integration and scheduling requirements (hourly loads from our HCM and ATS systems). It also allows us to be more tactical with what data is imported into each model, as each model has its own unique data requirements. We have saved views set up for each part of the sign-off process, which only pick up requisitions that have been recently approved and need to be synced, which also helps with the load times between models.
- Smaller models also allow for less complex and simpler transition plans in the event a model owner leaves. By breaking up use cases, the models they live in are easier to understand and can be transitioned individually versus needing to transition all 10 use cases together.
User Access Management
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):
- Selective access: Some requisitions are so sensitive that even their existence is confidential. To deal with this, we use selective access to make sure that only the proper people can see that a requisition the finance team tags as “confidential” even exists.
- Dynamic Cell Access: For everything else, we leverage DCA paired with formula drivers to make sure that each role can see only their relevant data. Only hiring managers can view data for requisitions they are tagged to, finance can only view data for requisitions in cost centers under their purview and recruiters can only view data for requisitions they are recruiting on. We prefer to use DCA where applicable, because formulas are easier to audit and tweak than trying to figure out which import actions are automating selective access.
Stakeholders & Responsibilities
Key Stakeholder Groups
This project spanned multiple departments and stakeholder groups. At a high level, the teams involved:
- Finance partner
- Hiring manager of new to-be-hired requisition
- Recruiter
- Anaplan on Anaplan partner
- Sales operations partner
Key Activities
Description of the type of activities, if applicable:
- Finance creates requisition and fills in basic date
- Within their PBF model, the finance partners work with their business partners to create new headcount requisitions. They fill in basic information about the requisition in order to be able to generate a forecast (cost center, comp estimate, location, etc.).
- Finance-approved requisition
- When ready, finance clicks a Boolean line item on the requisition to “release” it into the broader process. It’s at this point that it becomes exposed to the next group of stakeholders. We’ve put in time gates here to auto-release requisitions that are a quarter out from their forecasted start date. This helps us hit our hiring targets, so requisitions do not “slip through the cracks” and we make sure that recruiting is given enough time to recruit against.
- Sales ops team assigns territory
- The sales ops team concurrently works with the requisition list (both unapproved and approved) to tag appropriate territories to each requisition based on their sales planning model’s outputs. This allows sales ops to directly manage the data they care about and know best about each requisition.
- Hiring manager fills in data
- Once finance approves the requisitions and sales ops fills in their data (if it’s a sales requisition), the requisition is then passed to the hiring manager model where the hiring manager of the requisition goes into their own dashboard and fills in information like job level, location, and job type. With this information, the model uses lookups to generate a refined compensation range for the requisition. This not only helps cut down on back-and-forth with recruiting but also helps finance refine their forecast by receiving more accurate compensation data.
- Hiring manager approves requisition
- After the hiring manager is done with their inputs and is happy with the compensation range generated (which is also validated against finance’s initial estimate), they approve the requisition by clicking their own Boolean. This reduces the number of emails and back-and-forth trying to get a requisition approved.
- Recruiter fills in data
- After the hiring manager approves, the requisition is then made available on the recruiter’s Anaplan dashboard. They fill in the remaining information needed to populate a new job in our applicant tracking system. This allows recruiting to automate the Greenhouse (ATS) job creation process by only having to enter in fields they need to create the job, and the integration does the rest!
- Recruiter approves requisition
- Once the recruiter is done with their inputs, they click their own Boolean line item and the requisition is then made available via a saved view to be written into our applicant tracking system.
- Anaplan on Anaplan (AoA)
- The AoA team, as our internal Center of Excellence, served as technical architect advisors, as well as project managers. In order to free up time for the business groups to do their own modeling, the AoA team worked cross-functionally to make sure that all groups were heard and hit their deliverable milestones.
Responsibility Matrix
| Finance Partner | Sales Ops Partner | Hiring Manager | Recruiter | 3oA | |
| Create New Requisition | R | C | |||
| Approve New Requisition | R | R (if applicable) | R |
R
|
I |
| 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
Data Sources & Integration
| Source System | Target System | Description |
| Greenhouse | Anaplan/Workday | Job/Applicant/Activities/Hired Candidates |
| Workday | Anaplan | Employee Information |
| Salesforce | Anaplan | Account and Opportunity Data |
| Anaplan>Anaplan | Multiple Models | Model data syncs across involved models |
Synchronization Cadence
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.
Checks and Balances
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.
Return on Investment
Increased Speed to Begin Recruiting
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.
Increased Transparency
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.
Automated Conversion of To-Be-Hired to Employee
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.
Refined Forecasts and More Accurate Data (Within Anaplan and Across Systems)
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.
Conclusion
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.
