Approval workflow
The defined sequence of people who must review and sign off on a request before it can proceed, such as a new hire, a purchase, or a policy exception. It is sometimes called an approval chain, because each approver is a link the request must pass through in order.
An approval workflow exists to put the right level of scrutiny on a decision without slowing every decision down to the same crawl. A small, routine request might need a single sign off; a significant commitment might need several people in sequence, each looking at it from a different angle, such as cost, policy, and risk.
The design choices that matter most are who sits in the chain, what order they sit in, and what happens when someone is unavailable. A chain with no backup approver is a single point of failure waiting to happen, quietly stalling requests the moment one person goes on leave.
The best approval workflows are proportionate: routine, low risk requests move fast, often without a person even needing to look, while anything unusual or high value gets a genuine, considered review. Treating every request as equally important is what turns approvals into the thing everyone complains slows the business down.
In HarmoniHRM: Flow builds the approval chain from the live org structure, so a request always reaches the right approver for that person’s role, and resolves routine, within policy requests without waiting on a person at all.
Audit trail
A time ordered record of who did what within a process or system, kept so any action can be traced back to its origin later. It turns “we think this is what happened” into something that can actually be verified.
An audit trail exists for the moment something needs to be checked after the fact: an approval is questioned, a figure looks wrong, or someone asks how a decision was actually made. Without a reliable trail, answering that question depends entirely on memory, which fades and disagrees with itself.
A strong audit trail records not just that something happened, but who did it, when, and often why, in a form that cannot easily be altered afterwards. That last property, tamper resistance, is what separates a genuine audit trail from a log someone could quietly edit to tell a more convenient story.
The best audit trails are a side effect of how a system works, not an extra chore someone has to remember to do. When every approval, change, and escalation is captured automatically as it happens, the record is complete by default rather than by discipline, which is the only way it stays reliable under pressure.
Bottleneck
The single step in a process that limits how fast everything else can move, named after the narrow neck of a bottle that slows whatever is poured through it. Speeding up any other step without addressing the bottleneck rarely makes the overall process any faster.
Every process has a slowest step, whether or not anyone has identified it. The bottleneck sets the pace for the entire chain: work can pile up behind it, and the steps after it sit waiting, no matter how efficient they are individually.
The counterintuitive lesson of bottleneck thinking is that improving a non bottleneck step is often close to wasted effort. A faster step earlier in the chain just produces a bigger queue in front of the bottleneck; the overall process still finishes at the same pace.
Bottlenecks also move. Fix the current one and, almost by definition, a different step becomes the new slowest link. Treating this as an ongoing hunt rather than a one off fix is what separates teams that keep genuinely speeding up from teams that solve one constraint and then stop looking.
Business process
A repeatable sequence of steps that turns an input into a useful output, such as onboarding a new hire or closing a sale. Naming and mapping that sequence is what turns “how we do things” from tribal memory into something a business can actually manage.
Every company runs on processes whether or not anyone has written them down. A business process is simply the repeatable path work takes: who does what, in what order, and what triggers the next step. The moment a process is written down rather than carried only in someone’s head, it becomes something the business can improve, delegate, or hand to a new person without starting from scratch.
Processes vary enormously in weight. Some are light and informal, such as how a manager collects feedback before a conversation. Others are heavy and highly structured, such as a hiring chain that must pass through several sign offs before an offer goes out. What makes something a genuine process, rather than just a habit, is that it happens the same way each time regardless of who is running it.
The practical value of thinking in processes shows up when something goes wrong. A team without defined processes treats every failure as a one off mystery. A team that has mapped its processes can usually point to the exact step that broke, fix that step, and trust the rest of the chain to keep working. That is the real payoff: not bureaucracy for its own sake, but a business that gets more predictable as it grows.
Capacity planning
Working out whether the people and resources available can actually deliver the work being asked of them, and where the gaps are. It turns “we are stretched thin” from a feeling into a number that can actually be planned against.
Capacity planning compares two things: the work that needs doing and the real capacity available to do it, accounting for time already spent on existing commitments, planned leave, and the inevitable friction of meetings and admin. The gap between those two figures is where a team is either comfortably placed or quietly heading for trouble.
Done well, it catches overload before it becomes burnout or a missed deadline, rather than after. A team that only discovers it was overcommitted once a deadline is already missed has skipped the planning step entirely and is now managing a crisis instead of a plan.
Capacity planning also has to make trade offs visible. When there genuinely is not enough capacity for everything on the list, the honest options are to add capacity, remove work, or accept a later deadline, and a good capacity plan forces that choice to be made on purpose rather than by whatever quietly slips through the cracks on its own.
In HarmoniHRM: Flow’s Capacity view shows how open work is actually spread across a team, flagging when one person is carrying a disproportionate share before a deadline ends up depending on a single calendar.
Change management
The structured practice of moving people, teams, and processes from an old way of working to a new one, deliberately rather than by hoping it happens on its own. It covers both the practical rollout of a change and the human side of helping people actually adopt it.
Most changes fail not because the new process, system, or structure was wrong, but because the people who had to actually use it were never properly brought along. Change management treats that adoption problem as seriously as the technical one, because a better process nobody follows delivers no benefit at all.
A basic change management approach answers a few plain questions before anything rolls out: who is affected, what exactly changes for them, how will they be told, and what support exists while they adjust. Skipping straight to “here is the new way, please use it” is how well designed changes quietly die at the adoption stage.
Change management also includes planning for what happens if something goes wrong: a clear way to pause, roll back, or adjust course if the new way of working turns out to cause more harm than the problem it was meant to solve. Treating rollback as part of the plan, rather than a sign of failure, is what makes people willing to try the change in the first place.
In HarmoniHRM: Connect can carry a change announcement with acknowledgements and read receipts, so a rollout has evidence of who has actually seen it, not just a hopeful message.
Continuous improvement
The practice of making small, ongoing improvements to how work is done, rather than waiting for a single big redesign. It is often known by its Japanese name, Kaizen, which roughly translates as change for the better.
Continuous improvement treats a process as never quite finished. Instead of accepting “this is just how we do it”, teams that practise it look for small frictions, wasted steps, or repeated errors and fix them as they are found, rather than saving every problem up for an occasional overhaul.
The Kaizen tradition it draws on holds that the people closest to the work, not managers watching from a distance, usually see its flaws most clearly and have the best ideas for fixing them. A culture of continuous improvement actively invites that frontline insight instead of treating process design as something that only happens above people’s heads.
The compounding effect is the real payoff. A single small fix rarely feels significant on its own, but a team that makes many small fixes over time ends up with a fundamentally better process than one waiting for the courage and budget to attempt one giant redesign that may never actually arrive.
Cycle time
The total time it takes a single piece of work to move from start to finish through a process. It measures the experience of one item travelling the whole path, rather than how much a team produces overall.
Cycle time is measured from the perspective of the thing moving through the process, not the person or team doing the work. If a request enters a queue and sits there before anyone looks at it, that waiting time still counts, even though nobody was actively working on it.
This is exactly why cycle time so often surprises people. Most of the elapsed time in a typical process is spent waiting in a queue between steps, not being actively worked on, so shaving time off the active work itself barely moves the total. The bigger gains almost always come from shrinking the gaps between steps.
Shorter cycle times matter beyond tidiness. The longer something takes to move through a process, the longer it sits unfinished, the more it costs to track, and the more likely circumstances change before it is done. A shorter cycle time is, in a real sense, a lower risk process.
Escalation
Raising an issue to someone with more authority, expertise, or urgency than the person currently handling it, because it cannot or should not be resolved at the current level. A clear escalation path stops problems quietly stalling with someone who cannot actually solve them.
Escalation exists because not every problem should be solved by whoever happens to receive it first. Some issues need a decision only a manager can make, some need specialist knowledge, and some are simply too urgent to wait in an ordinary queue.
A healthy escalation path is defined in advance: who gets contacted, after how much delay, and through what channel. Without that clarity, escalation becomes a personal judgement call made under stress, which is exactly when people are worst placed to make it well.
The sign of a mature operation is not the absence of escalations, difficult and unusual things genuinely happen, but how gracefully they are handled once raised. An organisation that treats every escalation as a failure quietly trains people to stop raising them, which is far more dangerous than the original problem ever was.
In HarmoniHRM: Flow watches every request it routes and escalates anything that stalls past where it should have moved, so a delay does not depend on someone remembering to chase it.
Key performance indicator (KPI)
A specific, measurable number a team tracks to know whether an operation is running the way it should. In an operations context, KPIs usually watch things like speed, quality, cost, or reliability rather than any one person’s performance.
A good operational KPI answers a plain question: is this part of the business getting better, worse, or staying the same. Useful examples include how long a process takes from start to finish, how consistently output meets a quality standard, or how reliably a service is delivered.
The discipline in choosing KPIs is restraint. A handful of well chosen indicators, checked often, tells a team more than a long dashboard nobody actually looks at. When everything is measured, nothing is prioritised, and the genuinely important signals get lost in the noise.
KPIs work best paired with a target and a trend line, not just a single snapshot. A number on its own rarely tells you much; a number moving in a clear direction over time, against an agreed goal, tells you whether whatever changed actually worked.
Objectives and key results (OKR)
A goal setting framework, used at company, team, and individual level, that pairs a qualitative ambition with a small set of measurable results proving whether it was achieved. In an operations context, OKRs are often used to align different teams behind the same handful of priorities for a period.
The Objective is the ambition, written in plain, motivating language, something like becoming the easiest supplier to work with. The Key Results are the evidence that would prove it happened, each one specific enough that everyone would agree, at the end of the period, whether it was hit or missed.
Used well across operations, OKRs stop every department quietly optimising for its own convenience at the expense of the whole business. A logistics team and a service team might both contribute key results to the same shared objective, which forces a conversation about trade offs that would otherwise never happen.
The common failure mode is treating OKRs as a task list in disguise, where every key result is really just a project renamed. A genuine key result measures a change in outcome, not merely whether a piece of work got done.
In HarmoniHRM: Perform tracks progress on each objective and flags one that is falling behind well before the review period ends, whichever team or department it belongs to.
Process automation
Using software to carry out steps in a process without a person having to do them manually each time, from routing a request to sending a reminder. The goal is to remove repetitive manual work, not the human judgement the process still genuinely needs.
Process automation works best on the parts of a process that are repetitive, rule based, and rarely need real judgement, such as moving a request to the next approver, sending a reminder, or updating a record once a decision is made. Those steps add delay and error risk when left to a person’s memory, but very little value when a person does them, since the rule was clear either way.
The judgement about what to automate matters more than the technology itself. Automating a genuinely broken process just makes the broken process run faster and with less visibility into why it is failing, which is why the honest first step is usually fixing the process, then automating the fixed version.
Good process automation still leaves a clear seam where human judgement belongs. The routine, predictable cases move without anyone touching them, while anything unusual, high value, or ambiguous is deliberately handed to a person, rather than forced through the same automatic path regardless of how well it actually fits.
RACI
A simple framework for assigning roles on any task or project: who is Responsible for doing the work, who is Accountable for the outcome, who must be Consulted beforehand, and who should be kept Informed afterwards.
A RACI is usually drawn up as a grid, tasks or decisions down one side, people or roles across the top, with each cell marked Responsible, Accountable, Consulted, or Informed. The value is not the grid itself but the conversation it forces before work starts, rather than the argument it prevents after something goes wrong.
The role most often missing, or duplicated, is Accountable. Every task should have exactly one person accountable for the outcome, even when several people are jointly responsible for doing the work. When two people are both marked accountable, in practice nobody is, because each can reasonably assume the other has it covered.
RACI earns its keep most clearly during a handover or a reorganisation, when it is suddenly unclear who owns what. Revisiting the grid at that moment, rather than reconstructing ownership from memory and best guesses, is usually the fastest way back to clarity.
Service level agreement (SLA)
A commitment about how quickly or how well a service will be delivered, most often expressed as a promised response or resolution time. It turns a vague expectation like “get back to me soon” into something both sides can actually hold each other to.
An SLA exists to remove ambiguity from a working relationship, whether that relationship is between a company and an outside supplier or between two internal teams. Instead of an implicit hope that requests get handled quickly, both sides agree in advance what “quickly” actually means and what happens if that promise is missed.
The most useful SLAs are specific about what is being measured, when the clock starts, and what counts as met versus missed. A vague SLA is barely better than no SLA at all, because both sides can quietly disagree about whether it was honoured.
Internally, SLAs are just as valuable between departments as they are with outside vendors. A people team that promises hiring managers a response within an agreed window, for example, is using exactly the same discipline a supplier uses to promise uptime, and it has the same effect: it turns a source of frustration into a measurable, improvable number.
In HarmoniHRM: Flow tracks how long a request has been waiting at each stage, so a team can see whether its own service commitments are actually being met rather than assumed.
Standard operating procedure (SOP)
A written, step by step instruction for carrying out a specific task the same way every time, regardless of who is doing it. It exists so quality and safety do not depend on which person happens to be on shift.
An SOP takes a task that lives in someone’s head and writes it down clearly enough that anyone competent could follow it and get the same result. That sounds simple, but it is one of the highest leverage documents a company can produce, because it turns one person’s experience into an asset the whole team can use.
Good SOPs are specific rather than vague. Instead of “check the equipment is safe”, a strong SOP lists the exact checks, in order, with what to do if any of them fail. The specificity is the point: a vague instruction still leaves room for the very inconsistency the document was written to prevent.
SOPs age. A procedure written for how a team worked at one point quietly becomes wrong as tools, rules, and people change, which is why the best run companies treat SOPs as living documents with a named owner and a habit of periodic review, rather than a folder that gets written once and never opened again.
In HarmoniHRM: Learn can turn a written procedure into a short course and track exactly who has completed it, so a documented way of working and a trained team stay in step.
Throughput
The amount of work a process or team completes in a given period, such as requests closed or units produced. It is the headline measure of how much a process is actually delivering, as distinct from how busy it looks.
Throughput answers a deceptively simple question: how much finished output actually comes out the other end of a process. It is easy to confuse with activity, since a team can look extremely busy while throughput stays flat, because busyness measures motion and throughput measures completed results.
Throughput and cycle time describe the same process from two different angles. Cycle time asks how long one item takes from start to finish; throughput asks how many items get finished across everyone, over a period. A process can have a fast cycle time for one item and still have low throughput if very few items move through it at once.
Raising throughput sustainably almost always means addressing the bottleneck, not asking everyone to simply work faster. Pushing more work into a process ahead of its slowest step tends to create queues and stress rather than more finished output, which is why throughput and capacity planning are close cousins.
Workflow
The path a specific piece of work actually takes through a business process, moving between people and systems until it reaches completion. Where a process is the general blueprint, a workflow is that blueprint in motion for one particular case.
Think of a workflow as a process with a real case running through it right now. The process for approving a request might always follow the same shape, but each individual workflow, this particular request from this particular person, is its own journey through that shape, with its own timing and its own people involved.
Workflows can be manual, where someone has to remember to forward a message or update a record, or automated, where the system itself moves the work along and notifies the next person. The difference matters because manual workflows quietly rely on someone’s memory and goodwill, while automated ones keep moving even when people are busy, on leave, or simply forget.
A healthy workflow has a clear owner at every stage, a visible status, and a defined next step. When any of those three go missing, work tends to stall in a queue nobody is watching, which is usually where the phrase “it fell through the cracks” comes from.
In HarmoniHRM: Flow keeps a workflow moving automatically within policy, so it does not stall just because the person who would normally push it forward is busy, on leave, or simply forgets.