Introducing the process vocabulary

Here is an intro text about the lesson. Remember to include the excerpt and add the Course reference in the sidebar.

Lesson resources

• Want to learn more key terminology? Visit our BPM Glossary
• Why your project is really a process (article)

Key learnings

• A process is a repeatable chain of activities where each output becomes the next input; a project is one-off and unique.
• Use the output-to-input convention to keep flows unbroken and measurable.
• Rule of thumb: if you do it >3 times/year, define it as a process (and aim for stability where others can run it three times with no changes).
• Understand the building blocks: roles, activities, events, decisions, work instructions, cases.
• Know your process types (operational, management, support) and connect them into E2E flows across the value chain.
• Align to maximum five levels in your process hierarchy (Category → Process group → Process → Activity → Task/Instruction) and name processes in imperative form with clear outputs for shared understanding.

Video transcript

In the next few minutes, we’ll start building a shared language for how work flows in a company. I hope this will inspire you to ease communications with colleagues and make the path to process success shorter.

Why does it matter? Processes give us a helicopter view of work. Shared words make that view usable: people align faster, we measure the same things, and improvements stick.

So what is a business process? A process describes how we work: what’s done, by whom, and to what outcome. It’s a chain of activities where the output of one becomes the input to the next, supported by clear work instructions.

Known as the father of the quality movement, William Edwards Deming said it well, when he said: ”If you can’t describe what you are doing as a process,
you don’t know what you are doing.”

Today, with AI at the top of the hype curve, his point seems more relevant than ever. If we don’t know what we are doing in our organisations then how can we use AI effectively? – and how can keep it from hallucinating?
Documented processes keep people in control.

Unlike a project, a process is repeatable. So, let’s summarize:

• Process: a repeatable group activity that aims to deliver a standard output.
• Project: a one-time group activity designed to deliver a unique outcome.

If you catch yourself running the the same “project” again and again, it’s probably a process—and should be managed like one .

The benefit of treating projects that are not unique as processes is that you allow learning to be carried over from one to the next. Documenting how you do them make it easier to involve more junior colleagues and AI.

So when should you define something as a process?

If you do a reasonably similar task more than 3 times in a year, define it as a process.

And in Gluu we say a process is “stable” when others can run it three times with no changes needed.

Now let’s talk about the basic parts of a process.

It all starts with name and outcome, or output. This scopes the process.

Use imperative names that signal action (“Handle complaint,” “Run online campaign”), avoid department labels (“Marketing”), and always pair a process with a clear output. This improves understanding and keeps the scope tight.

A process normally stats with an Event: a trigger outside the process that initiates it or changes its path.

It can also start or end with another process.

Activity is within the responsibility of roles.

Role: the accountable “who” (often functional roles, not job titles) that performs an activity.

An Activity: is “what” a role does to produce an output. They become especially useful if they link to Work instructions (SOP): so where a process map explains the what and who then a work instruction can explain the “how” for an activity (steps, links, tools).

An Output: the concrete result a process or activity must deliver. Good outputs are specific and verifiable.

A Decision: an approval/branch that directs or splits the flow.

These are the basics – I suggest you master them before diving into more advanced process mapping notations such as BPMN 2.0 which has more than 55 shapes.

To standardize, many organizations align to APQC’s 5 process levels:

1. Level 1 — Category (e.g., “Operate the business”)
2. Level 2 — Process group (e.g., “Order-to-Cash”)
3. Level 3 — Process (e.g., “Process sales order”)
4. Level 4 — Activity (e.g., “Confirm order”)
5. Level 5 — Task/Work instruction (step-by-step how-to)

In Gluu, E2E views link sub-processes for context, while activities and tasks are combined to hold the “how” at the instruction level. By combining levels 4 and 5 the process becomes a practical guide for doing the work.

So which are the most important? I would say the E2E processes.

An E2E process crosses departments—from the first customer touch to fulfillment and beyond. It links sub-processes into one coherent flow that leaders can own and improve.

Processes most often go wrong in the handovers between roles – and especially departments – so this is why an E2E view is particularly important.

A well known example is the Order-to-cash process. This covers all the processes involved from a customer’s initial acceptance until their final payment.

If this takes too long then liquidity suffers.

This brings us to the next topic: Types of processes.

They are often related to a company’s value stream and can be divided into:

• Operational (core): how we design, sell, make, deliver.
• Management: how we steer—governance, audits, performance.
• Support: how we enable—HR, Finance, IT.

This lens helps catalog all recurring work across the business.

Pick one recurring flow you run often. Name it well, define its output, list the roles, sketch the activities, and write the first work instructions. That’s your blue print for a process that can set the standard for the next ones.

End of lesson