Current-state and future-state process mapping for HR, with examples

Process mapping has a reputation for swim lanes, sticky notes and a diagram nobody opens again. It does not have to be that. For an HR system rollout, a useful map is two lists side by side: the steps as they happen today, and the steps as they should happen in the new system. The differences between the lists are your requirements.

Why map before you configure

• You find the hidden work. Every process has steps that live in someone's head or inbox. A new system will not do them unless you ask it to.
• You choose your process on purpose. Without a future-state map, the vendor's default setup becomes your process.
• You get test cases for free. Each future-state step is something to test.
• You get evidence for the business case. Counted pain points are more convincing than general frustration. See how to build the business case.

How to map the current state

1. Pick one process and give it a clear start and end. "Hire to onboard" starts when an offer is accepted and ends when the new hire is paid correctly for the first time.
2. Talk to the people who do the work. The written procedure may be out of date.
3. Write one step per line. Each step says who does what, using what. "HR re-keys details into the payroll spreadsheet."
4. Write what happens, including the awkward parts. If the step is "someone remembers to tell IT", write that.
5. Flag the pain points. Mark any step with re-keying, a manual check, a wait on someone's inbox, or a risk of getting it wrong.

Keep it to five to ten steps. If you have twenty, you are mapping two processes.

How to map the future state

Write the future steps beside the current ones. Start from each pain point and ask what should happen there instead. Describe the outcome you want and leave out the vendor's screen names. "Record flows to payroll with no re-keying" will still make sense if you change vendors mid-selection.

Example: hire to onboard

Current state	Future state
Recruiter emails the offer letter as a PDF	Offer is accepted and signed in the system
New hire returns signed forms by email (pain point)	New hire completes forms in self-service before day one
HR re-keys details into the payroll spreadsheet (pain point)	Record flows to payroll with no re-keying
IT hears about the start date in a chat message (pain point)	Start date triggers the IT account request
Benefits form is mailed in week two	Benefits enrollment opens on day one

Gaps this raises: the IT account trigger needs an integration with the service desk, and e-signature must cover state tax forms. Neither was obvious until the two lists sat next to each other.

Example: time off request

Current state	Future state
Employee emails their manager	Employee requests time off on their phone
Manager forwards the approval to HR (pain point)	Manager approves in one tap
HR updates the balance in a spreadsheet (pain point)	Balance and payroll update automatically

Gap: accrual rules differ for part-time staff. That one line is worth finding now. Found in testing, it is a configuration change and a retest. Found after go-live, it is a wrong balance for every part-time employee.

Example: payroll run

Current state	Future state
Timesheets collected by email	Approved time flows to payroll
Finance keys hours into the payroll provider (pain point)	Deductions come from benefits elections
Deductions checked by hand against benefits invoices (pain point)	Variance report reviewed before submit
Journal entry typed into accounting	Journal posts to the general ledger

Gap: ledger mapping is needed for new cost centers. This is a Finance task with a lead time, and it is easy to miss if only HR is in the room.

Turning gaps into requirements

A gap is anything the future state needs that you do not have yet. Gaps come in five kinds, and it helps to label each one:

• Configuration. The system can do it, and someone has to set it up. Example: separate accrual rules for part-time staff.
• Integration. Two systems have to exchange data. Example: start date to the service desk.
• Data. Information the new process needs is missing or unreliable today. Example: cost centers on every employee record.
• Policy. The process needs a decision nobody has made. Example: who approves time off when a manager is away.
• Training. People have to do something new. Example: managers approving on their phones.

Then write each gap as a requirement someone can test. A good one names the trigger, the result and the condition:

When a new hire's start date is confirmed, the system creates an IT account request in the service desk at least five working days before the start date.

Give every gap an owner and a due date. A gap without an owner will turn up again in testing as a defect, or after go-live as a complaint.

Getting sign-off

Future-state maps need agreement from the teams they touch. For most HR processes that is HR, IT and Finance. Walk each group through the two lists, ask what is missing, and record that they agreed. Do this before vendor selection finishes, so the maps can shape the scorecard.

Common mistakes

• Mapping the official process. Map what people do.
• Too much detail. Field-level detail belongs in configuration workbooks.
• Skipping the current state. You cannot count what you are fixing, and you will miss the hidden steps.
• Maps that sit apart from the plan. If gaps live in a slide deck and tasks live somewhere else, gaps get lost.
• Never updating them. When a decision changes the future state, change the map.

Where HRjects fits

HRjects has a process maps workspace that works the way this article describes: current-state steps beside future-state steps for each process, pain points flagged on the current steps, and a list of gaps. One click turns a gap into a task on the project board, so it gets an owner and a due date. HR templates start with five processes to fill in: hire to onboard, time off request, payroll run, benefits enrollment and offboarding. The maps are step lists, so there is no diagram drawing. The steps are in the process maps help article.