Every company runs on routines. Someone needs a new laptop, a new hire needs accounts on day one, a supplier invoice needs a yes before it gets paid. At five people these routines live in one person's head and work fine. At fifty, they live in five heads, three inboxes and a spreadsheet, and they work only when the right person is around.
The symptoms are familiar: requests that disappear, the same "who approves this?" question every week, new people learning the job by asking around, and nobody able to say how long anything actually takes.
Process management is the practice of taking those routines out of people's heads and running them on purpose: written down, owned, measured and improved. It sounds like something only large companies do. It is not. The small-team version fits on one page per process.
Key takeaways
- A process is a routine that repeats, with a clear start, end and owner. Managing it means defining it, running it the same way every time, and improving it with evidence.
- The lifecycle has six steps: identify, document, assign owners, run, measure, improve.
- Four measures cover most needs: volume, cycle time, late steps and rework.
- Most small and mid-sized teams need a few clear, linear processes, not a BPM suite.
What is process management?
Process management is the practice of defining how recurring work gets done, making sure it actually gets done that way, and changing the definition when the results say it should change.
Three words carry most of the meaning:
- Recurring. If it happens once, it is a project. A process is something you will run again next week.
- Defined. Someone new could read the steps and know what to do, who to hand it to, and what "done" means.
- Owned. One person is responsible for the process itself, not just for doing a step in it. That person decides when the rules change.
You will also see the term business process management (BPM), which often refers to a category of software for modeling complex processes. More on that below. For most teams, the useful part is the habit, not the software.
Process vs project vs task
These three words get mixed up all the time, and the mix-up causes real problems.
| Process | Project | Task | |
|---|---|---|---|
| How often | Repeats, often many times a month | Happens once | Done once |
| When it ends | Each run ends, the process continues | When the result is delivered | When it is checked off |
| Example | Vacation request, invoice approval | Office move, new website | "Order chairs for the new hires" |
| Managed with | A fixed sequence of steps and owners | A plan, milestones and a timeline | A to-do list |
| Success looks like | Every run is fast and consistent | Delivered on time and on budget | Done |
The most common mistake is running a process as if it were a project, or a pile of tasks. Onboarding is the classic case: each new hire becomes a fresh set of cards on a board, someone rebuilds the list from memory, and the step that was forgotten last time is forgotten again. A board is great for one-off work. A routine needs a fixed path. We compare the two approaches in detail in Kanban boards vs workflows for internal processes.
The process management lifecycle
Whatever method or tool you use, managing a process comes down to six steps. You go through them once to set the process up, then loop through the last three for as long as the process exists.
1. Identify
List the routines your team runs. Good questions to find them:
- What gets requested over email or chat again and again?
- What breaks when one specific person is on vacation?
- What did your accountant or auditor ask about last year?
Then pick one to start with. The best first candidate happens often and hurts when it goes wrong: purchase requests, time off, onboarding, invoice approval.
2. Document
Write the process down as steps: who does what, with what information, in what order. Document what actually happens today, not the ideal version, then fix it. Our guide on how to document a business process walks through the interview questions and a template.
3. Assign owners
Every process needs two kinds of owners:
- Process owner: accountable for the process as a whole. Decides on changes and watches the numbers.
- Step owners: do the work in each step, such as approving, ordering or setting up accounts.
Write step owners as roles, not names: "requester's manager", "AP clerk", "IT on call". Names change. Roles survive turnover.
4. Run
Run the process the same way every time. This is where a written document stops being enough. A document tells people what to do, but it does not route the request to the next person, remind them when it is late, or record what happened.
Running a process well means one entry point (requests always start the same way, with the same information), clear hand-offs, and a due time for each step with a reminder when it passes.
For a worked example of a routine with many hand-offs, see our employee onboarding checklist.
5. Measure
Collect a few numbers for each run, automatically if possible. See what to measure below.
6. Improve
Look at the numbers on a fixed rhythm (quarterly is enough for most processes), change one thing at a time, and check whether it helped. The best improvements are usually removals: an approval nobody needs, a field nobody reads, a hand-off that could be one step.
Signs a routine needs to become a process
Not everything needs to be formalized. A task that happens twice a year is fine as a checklist in a shared doc. These are the signs that a routine has outgrown that:
- The same request arrives in a different format every time.
- People ask "where is my request?" more than once.
- Only one person knows how it works.
- The same mistakes repeat: wrong approver, missing information, a forgotten step.
- Someone outside the team, such as an auditor, accountant or customer, asks for proof of what happened.
- It happens at least a few times a month.
- It touches money, system access, or employee records.
What to measure
You do not need a dashboard with twenty charts. Four measures, tracked per process, answer almost every question.
| Measure | What it is | What it tells you |
|---|---|---|
| Volume | Runs started per week or month | Where the team's effort goes, and whether a process deserves more attention |
| Cycle time | Time from start to finish, per run | How long requesters wait. Use the median, since one stuck request distorts the average |
| Late steps | Steps that passed their due time, by step | Where the bottleneck is. It is usually one step, not the whole process |
| Rework | Requests sent back for changes, or rejected and resubmitted | Whether the request asks for the right information and the rules are clear |
Two practical tips:
- Measure per step, not just in total. The total tells you there is a problem. The step tells you where. An example: an invoice approval process with a median of six days, four of which are spent waiting at the department head. The fix is a delegate or an approval limit for small invoices, not a new tool.
- Get a baseline before setting targets. See what normal looks like for a few weeks, then decide what "better" means.
Where BPM suites fit, and where they are overkill
BPM suites are platforms for modeling, automating and monitoring processes. Many of them model processes as diagrams in BPMN (Business Process Model and Notation), a standard maintained by the Object Management Group, with gateways, parallel paths, events and integrations with ERP and CRM systems.
They are a good fit when:
- A process has to orchestrate several systems, not just people.
- The exception paths are genuinely complex and regulated.
- There is a dedicated team, IT or process analysts, to build and maintain the models.
They are overkill when:
- Most processes are a handful of steps with an approval in the middle.
- Nobody on the team has time to maintain diagrams.
- The real problem is consistency and visibility, not orchestration.
The warning signs: the diagram takes longer to draw than the process takes to run, only one person can change it, and the team drifts back to email.
Our opinion: most internal routines at companies of 10 to 300 people are linear. Request, review, approve, do, confirm. A condition here and there ("skip the finance review under $500") handles most exceptions. Start linear, and add complexity only when a real, repeated case demands it. A rare exception can be handled with a comment instead of a new branch.
Common mistakes
- Documenting the ideal process instead of the real one. People keep doing the real one.
- Adding approvals "just to be safe". Every approval is a delay. Each one should exist because someone actually checks something.
- No process owner. Without one, nobody fixes the process when it breaks, and everyone works around it.
- Owners as names instead of roles. The process breaks the day that person leaves.
- Formalizing everything at once. Get one process working, then do the next.
- Measuring nothing, or only totals. You cannot improve what you cannot see, and a total hides where the time goes.
- Approving after the fact. If the purchase is made before the approval, the approval is just a notification.
Frequently asked questions
What are the steps of process management?
The usual cycle is identify, document, assign owners, run, measure and improve. The first three set a process up. The last three repeat for as long as the process exists, so the process keeps getting better instead of slowly drifting away from what is written.
What is the difference between process management and project management?
Project management deals with work that happens once and ends, like an office move, with a plan, milestones and a deadline. Process management deals with work that repeats, like expense reports, where the goal is to make every run fast and consistent. Many teams use both, but they need different tools.
Do small businesses need process management software?
Not on day one. A written checklist and a clear owner are a fine start. Software starts paying off when requests get lost, approvals stall, or you need a record of who decided what, which tends to happen once a process runs many times a month across several people.
Running it in Easyflow
Easyflow is built for these routines. Each process is a linear list of steps, where the first step is a form filled in by whoever starts the request. Every step has an owner, such as a person, a group, the requester or the requester's manager, and a deadline with reminders and escalation. Conditions can skip a step or hide a field, and there is no diagram builder, on purpose. Insights shows volumes, lead times and late steps for each process, and every request keeps a full timeline of who did what and when. The gallery has 56 ready-made processes to start from, including Employee onboarding, Purchase request, Vacation request, Access request and Maintenance request.
Approvals are the most common process most teams formalize first. Our approval workflow guide covers the types, examples and how to design one.