What is a Process Scope (or IGOE) Diagram?
A Process Scope diagram is a one-page way to scope a business process by mapping five elements: the process itself, plus its four interfaces, Inputs, Guides, Outputs, and Enablers (or IGOE).
You put the process you care about (the "process-in-scope") in a box in the middle. Then you surround it:
Inputs on the left
Outputs on the right
Guides across the top
Enablers along the bottom
That's it. One box, four sides.
It's deliberately simple, because its job is to get a room full of people agreeing on what a process actually touches before anyone argues about how to fix it.
You'll also see it called an IGOE Diagram. Same thing.
The reason it earns its place (and has outlived a lot of flashier frameworks) is that it’s easy to understand, easy to use and creates clarity very quickly.
The Five Elements (with a procurement example)
Let's scope a sourcing event, because that's a process every procurement team recognizes.
Process is the thing in the middle: "run a sourcing event." Everything else is defined relative to it, so name it before you fill in a single interface. The same item can be a Guide for one process and an Output of another, which is exactly why the center has to be nailed down first. It's the element that makes the other four mean anything.
Inputs are the things a process consumes and transforms into something else. They get changed. In our sourcing event, the inputs are the intake request, the requirements/scope, and the budget. They go in raw and come out as a sourcing decision.
Guides are the things that constrain how the process runs but don't get consumed. They're the rules of the road. Here: your procurement policy, approval thresholds, the category strategy, compliance and regulatory requirements, your contract templates. Nobody "uses up" the approval threshold. It just governs.
Outputs are the outcomes the process produces. The awarded supplier, the signed contract, the PO, etc.
Enablers are the reusable resources (people, other processes, systems and data) that make the work possible. They show up again and again across many runs of the process. Your sourcing team, your S2P or e-sourcing platform, your ERP, your spend data. The team doesn't get "consumed" by one event (most days), so it's an Enabler, not an Input.
Here's the discipline in one line: if it gets transformed, it's an Input. If it constrains, it's a Guide. If it's produced, it's an Output. If it's a resource you reuse, it's an Enabler.
Sorting a process this way surfaces things people gloss over. "Wait, how does the category strategy interact with this process?" "Who owns the contract templates?" "Is the risk tool an Enabler here, or is it a separate process feeding us an Input?" Those questions are the whole point.
Where the IGOE Came From (and When)
The IGOE was created by Roger T. Burlton and folded into the BPTrends methodology he built with Paul Harmon.
But he didn't invent the shape. He adapted it from IDEF0, a function-modeling standard from the U.S. Air Force's 1970s manufacturing program, which used the same four-sided layout under different labels (Input, Control, Output, Mechanism). Burlton's move was translation: he renamed Control to Guide and Mechanism to Enabler so the tool fit business processes, not factories. "Enabler" comfortably covers a person, a policy team, a platform (and, as we'll get to, an AI agent). That's what turned a defense-manufacturing standard into a whiteboard tool a procurement team can use to continuously improve the function.
As for when: IDEF0 traces to the 1970s and early 1980s; Burlton developed the IGOE variation through the 1990s and documented it in his 2001 book, Business Process Management: Profiting from Process. A 1990s tool, built on 1970s foundations, still in active use in 2026 (which is the part worth paying attention to).
What Purpose Does an IGOE Diagram Serve?
Three jobs, mostly.
Scoping. Before you redesign, automate, or buy software for a process, you need agreement on where that process starts and stops and what it depends on. The IGOE draws that boundary in a way a mixed room (procurement, finance, IT, legal) can all read.
Problem Analysis. In Burlton's method you don't just list the interfaces. You rate them. Each exchange gets a quick "is this working?" gut check (green if fine, flagged if not), and pairing that with root-cause analysis turns a static picture into a to-do list. It's common to discover the real problem lives outside your original scope box (a broken input from another team, a guide nobody's enforcing).
Shared language. IGOEs are often drawn on a whiteboard with the actual people who run the process, precisely so the analysis happens in the room. The diagram is the artifact, but the conversation is the deliverable.
Notice what it deliberately does not do: it doesn't show sequence or flow. There are no Swimlanes, no "step 1 → step 2." That's a feature.
Flow diagrams answer how. The IGOE answers what does this process touch, and is any of it broken? Get that wrong and your beautiful flowchart is just a fast route to the wrong destination.
Why the IGOE Diagram Still Matters in the Era of AI
Every ProcureTech software vendor deck promises to automate your procurement processes with agentic AI. Autonomous sourcing. AI that runs your intake. Copilots that "handle" your P2P. And the instinct in a lot of teams is to treat process-mapping tools like the IGOE as quaint. Old-school. Something you did before the robots showed up.
That's backwards. You cannot orchestrate, automate, or hand to an agent a process you have not scoped. And scoping is exactly the thing an IGOE does. It's the same reason most procurement AI agent builds stall before they ship: the team starts with the tool ("we'll build it on Claude") instead of the process, and the agent inherits every gap the scoping would have caught.
Two of the four interfaces get more important once AI enters the picture, not less:
Enablers now include your AI agents. A Large Language Model, or LLM, is an Enabler. They're reusable resources that execute work, sitting on the bottom edge of the box next to your team and your S2P suite. Writing an agent into the Enabler slot forces the uncomfortable, useful question: what is this thing actually doing, and to which Inputs? What’s the desired outcomes? "We added AI" is not an answer. "The agent drafts the RFP scope from the intake request" is.
Guides are where your guardrails live. Policies, spend thresholds, data-handling rules, system permissions, the boundaries of what an agent is allowed to decide on its own (these are Guides). In the AI era, the top edge of the diagram is your control surface. Skip it, and you've deployed an "autonomous" agent with nothing constraining it. An IGOE makes the empty Guide box impossible to ignore.
So Process Scope Diagrams don't just survive the AI shift…. They get sharper. They quietly separate the two things everyone conflates: the resource doing the work (Enabler) and the rules governing it (Guide). Most bad AI-automation stories are really just one of those two boxes left blank.
There's a buyer-protective use here too, and we'd encourage it. Next time a vendor tells you their AI "automates" a procurement process, ask them to fill in the IGOE for that exact process. Name the Inputs the agent transforms. Name the Guides it respects. Name the Outputs it's accountable for. If they can't (or if the demo only works because a human quietly supplies half the Inputs), you're not looking at automation. You're looking at orchestrated guesswork with a slick UI.
And this is the deeper reason a 1990s whiteboard tool belongs in an AI-era procurement stack: the IGOE is technology-agnostic.
It describes a process the same way whether a person, a workflow engine, or an agent executes it. It doesn't care what's in the Enabler box. That neutrality is exactly what lets it outlast every hype cycle, including this one. Automate the mess without scoping it first, and all you've bought is a faster mess.
How to Draw an IGOE (the 20-minute version)
Put the process-in-scope in the center box (element one, the thing everything else hangs off). Name it as a verb ("Run a sourcing event," not "Sourcing").
List the Inputs (left): what gets transformed? Outputs from a previous process? A data set? A manual input from a user?
List the Guides (top): what rules and permissions constrain it? (Include AI and data-handling policy.)
List the Outputs (right): what does it produce? What outcome are we looking for? (Don't forget the audit trail.)
List the Enablers (bottom): what resources run it? (Team, systems, data, large language models, etc.)
Rate each one: working, or not? Mature or needs work? Flag the broken exchanges.
Follow the flags. That's your improvement backlog to get to a scalable AI agent.
Whiteboard it with the people who actually run the process. The sorting argument is the value.
Frequently Asked Questions
What does IGOE stand for?
Input, Guide, Output, Enabler. Those are the four interfaces of any business process: what it consumes, what constrains it, what it produces, and what resources run it. The diagram itself has five elements, because the process being scoped sits at the center holding the four interfaces together.
Who invented the IGOE diagram?
Roger T. Burlton and his firm, Process Renewal Group (PRG). Burlton incorporated it into the BPTrends methodology he developed with Paul Harmon.
What's the difference between IGOE and IDEF0?
IGOE is Burlton's business-friendly adaptation of IDEF0, a function-modeling standard from the U.S. Air Force's ICAM program. IDEF0's four arrows are Input, Control, Output, and Mechanism (ICOM). Burlton renamed Control to Guide and Mechanism to Enabler so the tool fits service and business processes rather than manufacturing.
Is an IGOE the same as a SIPOC?
They're cousins, not twins. SIPOC (Supplier, Input, Process, Output, Customer) is a Six Sigma scoping tool that emphasizes suppliers and customers. IGOE emphasizes the constraints on a process (Guides) and the resources that run it (Enablers), which makes it better at surfacing policy and system dependencies (useful when you're evaluating software or AI).
What's the difference between an IGOE and a process flow diagram?
An IGOE shows what a process touches (its interfaces) and whether those exchanges work. It does not show sequence. A flow diagram shows the step-by-step order. It details the middle of the box in the IGOE diagram. You scope with an IGOE first, then flow the parts that need it.
Is IGOE still relevant with AI and automation?
More than ever. AI agents are Enablers and AI guardrails are Guides, so the framework maps cleanly onto agentic procurement. You can't safely automate a process you haven't scoped, and an IGOE is the fastest way to scope one.
The Bottom Line
Process Scope (or IGOE) Diagrams are a great, simple way to:
Identify the elements that influence the execution of a business process
Align a set of stakeholders on the above elements
Carry out high level business process (and/or AI Agent) design
This article is part of ProcureTech Foundations, a series from Pure Procurement breaking down core procurement technology concepts for practitioners. Vendor-independent, built from hands-on implementation experience.