Building a supporting system: What every process needs to run effectively

Do we really need to learn about Process Execution? Don’t we just… execute it?

Yes, we do.

Why? Because a process doesn’t execute itself. People execute it. And people are far from reliable.

Execution is frequently treated as automatic. As if, once the process diagram is drawn and the steps are published, the work will just get done.

The overlooked reality: Process design ≠ process success

Imagine launching a beautifully mapped sales onboarding process: every step clearly defined, every role assigned. On paper, it should work flawlessly. Yet somehow, customers get overlooked, tasks go unfinished, and the handover to finance never takes place.

What happened?

• The CRM wasn’t set up for the new team
• The sales reps never got training
• The email notification system wasn't activated
• The approval form was still in the old format

None of these are design flaws. They’re support failures. And they happen far more often than you’d expect.

This article outlines what every organization must put in place before execution can occur reliably, based on the five support pillars suggested in ISO 9001:2015.

The 5 things every process needs to succeed

Resources: People need the means

Anchor question: Do people have what they need to execute the work as defined?

Example: Your SOP says "Submit to CRM," but half the team isn’t onboarded into the system yet. The process didn’t fail due to bad design; it failed due to missing resources.

When a process fails in execution, it's often not due to the design of the steps, but because people weren’t equipped to carry them out. As Clause 7.1 in ISO 9001:2015 has stated, we need to make sure resources are in place before expecting any results.

But what exactly counts as a resource?

In ISO's language, resources are all the inputs – tangible or intangible – that are required to perform a task. In the context of BPM, this means anything the team needs to execute a step exactly as intended.

Common categories of process resources include:

• Human resources – people with the right availability and physical presence
• Tools and equipment – from software platforms to physical tools on a shop floor
• Infrastructure – workstations, machines, internet access, facilities
• Materials – raw inputs or pre-processed goods needed to perform work
• Data and system access – credentials, dashboards, APIs, or reports
• Support services – such as IT support or logistics partners

No matter how simple or complex the process, execution depends on these building blocks. A single missing or misaligned resource like a user not having access to a tool, or a form not being available can stall the entire operation.

How to ensure resources are ready for execution

• Map resource needs at the task level: For every step in the process, list what’s needed to complete it – who, what tool, what material, what access. Don’t assume availability. Write it down.
• Assign responsibility for provisioning: Clarify who is responsible for ensuring each resource is in place. For example, HR might handle tool access for new hires, while IT provisions digital tools.
• Build a readiness checklist before rollout: Before any new or updated process goes live, run a checklist:
  • Are all users onboarded and trained on the required tools?
  • Do they have the correct permissions?
  • Are all forms, templates, and materials available?
  • Is the working environment prepared (e.g. correct devices, workspaces)?
• Link resources directly in your BPM tool: Attach system links, document references, or tool access instructions to each process step. Don’t expect people to search for them.
• Conduct small-scale pilots to reveal hidden gaps: Try running the process with a small group to uncover missing or impractical resource requirements before full rollout.

Competence: People must have the ability

Anchor question: Are the people assigned to the task capable of doing it correctly and consistently?

Quick example: A finance team just updates their invoice approval workflow. Everything is well-mapped: who enters the data, who approves, and when to release the payment. But when the process goes live, trouble arises. Turns out the junior clerk doesn’t know how to match invoices with purchase orders. The approval logic makes sense to the designer, but the doer isn’t trained. This isn’t a process design flaw; it’s a competence gap.

Even the best-designed processes will fall apart if the people assigned to execute them aren’t equipped with the necessary competence.

Competence means more than just having someone in the seat. It’s about ensuring that person has the knowledge, skill, and judgment to carry out their assigned task according to the defined process. This can come from experience, formal training, or hands-on instruction, but it must be intentional and verified.

In process execution, competence failures show up as:

• Repeated errors and rework
• Delays due to hesitation or confusion
• Workarounds that bypass the intended flow
• Staff avoiding tasks they don’t understand

How to build competence into BPM execution

• Define the skill requirements for each task: During process design, don’t just assign steps to departments or roles; specify what skills or training are needed. For example, “Verify pricing against approved rate card” might require familiarity with ERP codes or pricing tiers.
• Validate current competence: Conduct a simple gap analysis:
  • Who is assigned to each task?
  • Have they done this before?
  • Do they have relevant training, certification, or mentoring?
• Integrate learning resources into the process: Attach short how-to guides, tooltips, or quick videos directly into the BPM system. People shouldn’t have to hunt for information.
• Use hands-on walkthroughs before rollout: Simulate the process in real time with real people. Observe where they hesitate or make errors – these are training gaps in disguise.
• Track training as a requirement: For roles tied to regulated or complex processes, include training completion as a precondition. In high-risk environments, no training = no task assignment.

Awareness: People need the alignment

Anchor question: Do people understand the purpose and impact of their task within the process?

Quick example: A warehouse team is tasked with logging returned items into the system within 12 hours. Most returns, however, go unrecorded for days. The team was too busy to make time for the data entry. What they don’t realize is that delayed logs throw off stock accuracy, confuse customer service, and stall refund approvals. The real failure here isn’t workflow; it’s awareness.

Processes don’t fail only because people don’t know what to do. They often fail because people don’t understand why they need to do it or how their actions affect the bigger picture. That’s why we need to ensure that people are aware of the importance of their work and how it contributes to overall objectives.

When someone understands the outcome of their actions – who it helps, who it impacts, what happens if it’s skipped – they approach the task with greater purpose. On the other hand, a task that seems minor or disconnected is often delayed, done carelessly, or dropped entirely.

Awareness is especially crucial in cross-functional processes, where the person doing a task won’t see the end result. It’s easy to overlook how a 2-minute task can create a 2-day delay for someone downstream.

How to embed awareness into your process execution

• Start each process with a purpose statement: In your BPM documentation or workflow tool, include a short summary at the top of the process or within key tasks: “This process ensures...”, “This step is critical because...”.
• Communicate process impacts during rollout: Don’t just train on how to perform tasks – explain what happens if they’re missed. Show the downstream consequences and customer impact in onboarding sessions.
• Reinforce process context in task descriptions: Instead of saying “Log return ID,” say “Log return ID so the refund and restock can proceed without delay.” A simple phrase can change the tone from obligation to ownership.
• Use dashboards to show the ripple effect: If possible, show KPIs that connect one team’s step to outcomes (e.g., “average refund time” or “stock accuracy”). This reinforces that their task matters.
• Cascade messages from leadership: When leadership explains how front-line work supports strategic goals like customer satisfaction, efficiency, and compliance, it boosts clarity and morale.
• Awareness isn’t about long lectures. It’s about small, consistent reminders that your role matters, and that what looks like a routine click or submission is, in fact, part of a chain that keeps the business moving.

Communication: People need clarity

Anchor question: Is the right information reaching the right people at the right time during execution?

Quick example: An approval step in a purchasing process requires sign-off from the finance manager. But nobody sends a notification. The manager doesn’t even know a request is pending. It sits in limbo for five days until someone follows up manually. Everyone did their part — except the process didn’t speak. That’s a communication breakdown.

Processes are sequences of tasks, but they are also sequences of signals. Without proper communication, even the best-designed workflow will stall or go sideways.

Communication failures often appear as silence:

• Someone is waiting for a trigger that never comes
• A handover is assumed but not confirmed
• A change is made to a form or rule, but users aren’t told

Communication isn’t just a support function; it’s part of the process design.

How to build communication into the way your process operates

• Define communication paths explicitly: In your process documentation, don’t assume handoffs will happen. Spell them out:
  • Who needs to be notified?
  • What message or information needs to be shared?
  • Through what channel (email, software alert, verbal handover)?
• Use workflow systems with built-in notifications: Wherever possible, automate the handoffs. Let the system notify the next role when it’s their turn – don’t rely on people remembering to send an update.
• Include escalation rules for delays: If a step isn’t completed within a set timeframe, who should be informed? Build in escalation triggers to prevent bottlenecks from going unnoticed.
• Clarify approval routes: If a step requires sign-off, make sure the responsible person is clearly defined and has visibility. Don’t leave it vague – “manager” isn’t specific enough.
• Enable feedback loops: Create space for questions, clarifications, and corrections. This might be as simple as a comment box in a BPM tool or as structured as a post-execution review session.
• Announce changes clearly and widely: When a process changes, update your documentation and announce it to the people. Not just the frontline team, but anyone affected by or dependent on the change.

If you want execution to be smooth, ensure the process itself communicates at every stage.

Documented Information: People need the structure

Anchor question: Do people have access to the correct, current, and clear instructions they need to perform the task?

Quick example: A staff member uses the old vacation request form because it's bookmarked on their desktop. That form routes to a retired manager and doesn’t include the new approval section. The form wasn’t wrong; it was just outdated.

This supporting element focuses on documented information – not just having it, but ensuring it’s controlled, accessible, and relevant. In BPM, this means connecting your workflows to live, trustworthy instructions that guide action at every step.

A task may be simple. But if the person doing it has to:

• Ask a colleague what version to use
• Dig through folders for the right document
• Guess at formatting or criteria

…then the process is at risk. Misuse of documentation isn’t a user issue; it’s a system issue.

How to make documentation support execution:

Link documentation directly to process steps: In your BPM platform, don’t just mention “refer to SOP.” Attach or embed the actual file. Use clickable links, integrated templates, or hover-over tooltips.

• Use version control with clear naming conventions: Always indicate which document is the current version. Old versions should be archived and inaccessible for day-to-day use. Use date stamps and version numbers clearly on the document itself.
• Keep instructions short and task-specific: Break down large SOPs into modular, step-level guides when possible. A user executing a 5-minute task shouldn’t need to scroll through 12 pages of unrelated instructions.
• Review and update documents regularly: Build review cycles into your process governance. If a tool, policy, or rule changes, check all linked documents. Old documentation is one of the most common hidden causes of execution errors.
• Design documents for usability: Use visual cues: bold step numbers, screenshots, tables for options or thresholds. Don’t expect everyone to read paragraphs – design for quick comprehension in real-time.
• Ensure access control and availability: All performers should be able to access the documents they need when they need them, whether they’re on desktop, mobile, or in the field.

Documented information is often the only tangible connection between process design and execution. Make it easy to find, easy to follow, and impossible to get wrong, and you'll eliminate half the errors that creep into daily operations.

Final thoughts: Prepare to run, then keep it running

Execution isn’t just launching a process. It’s a moment of truth, where intent meets reality. And it only works when the environment is ready: tools are in place, people are capable, information flows clearly, and instructions are usable.

We need to shift the question from “Why didn’t this get done?” to “Did we give them what they needed to succeed?”.

But readiness isn’t everything. Once the process is in motion, we still need structure and control to ensure it's executed as intended. Once again, clause 8 in ISO 9001:2015 gives us a hint on this checklist.

Execution checklist:

Before you press “go,” ask:

• Are process inputs validated before starting? (e.g. confirmed orders, complete forms, required data)
• Is the process being followed exactly as defined? (no skipped steps, no informal workarounds)
• Are outputs checked before they’re released? (e.g. approvals, QC steps, sign-offs)
• Is non-conforming work identified and handled? (errors are flagged, rework is triggered, outcomes are traceable)
• Are changes controlled and documented? (no silent edits to steps, documents, or responsibilities)

Most of this checklist seems obvious, but it’s not about bureaucracy – it’s about reliability. Remember: there is always a gap between planning and reality. While the above 5 elements help your process start strong, this checklist helps you finish right.

In the next article, we’ll start stepping back. This checklist is about the in-process control, while the next Monitoring Stage in our BPM lifecycle is like your rearview mirror and fuel gauge.