Process Elements & Boundaries

Process Elements & Boundaries

Quick Answer: A process transforms inputs into outputs for customers through defined activities, resources, and controls. Green Belts analyze those elements, set start/stop boundaries, and highlight cross-functional handoffs so the project scope is real, measurable, and ownable.

What Counts as a Process

In Six Sigma, a process is a collection of interrelated tasks that convert inputs into outputs that a customer (internal or external) receives. Manufacturing lines, claims adjudication, onboarding, change control, and monthly close are all processes—even when no machine is involved.

If you cannot name:

• What triggers the process to start,
• What must be true when it ends, and
• Who receives the result,

…you do not yet have a process definition strong enough for a DMAIC project.

CSSGB BoK II.A.2 expects you to analyze process components and boundaries—not merely define the word “process.” That means dissecting how work really flows, where authority sits, and which interfaces inject delay or defects.

Process Elements Green Belts Must Identify

Think beyond a simple boxes-and-arrows map. A complete element view includes:

Transformation model (classic):

Suppliers → Inputs → [Process activities + resources + controls] → Outputs → Customers
                              ↑________________ feedback ________________↓

This is the same mental model SIPOC formalizes (next section). Here the focus is element analysis and boundary setting before you fill every SIPOC cell.

Value-adding vs. non-value-adding work

When analyzing steps, classify activities:

• Value-adding (VA): Customer would pay for this transformation
• Required non-value-adding (RNVA / business non-value): Required by regulation or policy but not valued by the end customer
• Non-value-adding (NVA): Pure waste (waiting, rework, excess motion, overproduction)

Element analysis that ignores NVA will later produce weak Improve ideas. Boundaries that hide NVA (for example, excluding “waiting in queue” because “that’s IT’s system”) also hide the real cycle time.

Setting Process Boundaries

A boundary defines where the project process starts and stops, and what is in scope vs. out of scope. Boundaries protect the team from infinite expansion (“while we’re at it…”).

Start and stop points

Write them as observable events:

In-scope vs. out-of-scope

Document both. Examples for an accounts-payable coding project:

• In scope: Domestic vendor invoices for Plant A; coding, approval routing, and first payment proposal
• Out of scope: International tax withholding rules; ERP version upgrade; vendor master data governance owned by Procurement (may be a consequential interface, not the project Y)

Out-of-scope does not mean “ignore.” Interfaces still appear as suppliers/customers; they simply are not where you will implement primary solutions without rechartering.

Vertical and horizontal boundaries

• Horizontal: Along the value stream (which steps from request to fulfillment)
• Vertical: Depth of detail (L2 process map vs. every keystroke) and organizational level (one plant vs. enterprise)

Green Belt projects usually take a horizontal slice that is end-to-end enough to move the Y, but not so wide that no owner exists.

Worked example — boundary for loan underwriting cycle time:

• Start: Complete application package received (all required documents checklist = Yes)
• Stop: Underwriting decision recorded (Approve / Decline / Conditional) in LOS
• In scope: Credit analysis, condition clearing for standard consumer products at Region West
• Out of scope: Marketing lead generation; post-close servicing; pricing policy changes

Without those lines, the team will debate whether slow document collection “counts,” and Measure will never baseline a clean Y.

Cross-Functional Challenges

Most high-pain processes cross departments. CSSGB candidates should anticipate these failure modes:

1. Handoffs and queues

Each functional wall adds batching, waiting, and rework loops. A defect introduced in Sales may only be visible in Operations. Cycle time is often mostly queue time between functions, not touch time inside one step.

2. Conflicting local metrics

Element analysis must surface these metric conflicts; otherwise Improve optimizes one silo.

3. Unclear ownership

If no single process owner spans the boundary, the Champion must either appoint one for the project horizon or split the work into linked projects. “Everyone owns quality” often means nobody owns the control plan.

4. Different systems of record

Cross-functional processes may use CRM + ERP + email + paper. Data availability filters fail when each silo defines “complete” differently. Define operational definitions at the boundary events, not only inside one department’s dashboard.

5. Language and priority gaps

Engineering, operations, and customer service may use different words for the same defect. A shared process vocabulary (and later a data dictionary) is part of boundary work.

Worked example — cross-functional order-to-cash pain:

A manufacturer’s late deliveries look like a warehouse problem. Element analysis shows:

• Sales accepts nonstandard configs (input quality)
• Engineering releases drawings late (resource/control)
• Planning freezes schedule weekly (batch policy)
• Warehouse picks accurately but receives incomplete kits (supplier interface)

If the project boundary is only “warehouse pick,” the true X’s stay outside the fence. A better boundary might be “configure-to-order release through ship confirm” with Sales and Engineering as suppliers and explicit consequential metrics for quote accuracy.

How to Analyze Elements in Practice

1. Walk the process (Gemba) — Observe real work; do not trust the SOP alone.
2. List elements in a table — Suppliers, inputs, steps, outputs, customers, systems, owners.
3. Mark handoffs — Star every time work changes person, team, or system.
4. Draft start/stop events — Observable, timestampable, and aligned to the project Y.
5. Stress-test with “what if” — Rework loops, exceptions, night shift, peak season—do they stay in bounds?
6. Confirm with process owner and Champion — Boundaries are a political and technical agreement.
7. Feed SIPOC and charter scope — Element analysis is the raw material for both.

Exam and Project Pitfalls

• Treating “process” as only manufacturing machines
• Drawing a map with no start/stop or ownership
• Including the entire company because “everything is connected”
• Excluding queues and rework so the process looks cleaner than reality
• Ignoring internal customers at handoffs
• Setting boundaries that make the primary metric unmeasurable

Boundary Quality Checklist

• Start and stop are observable events with data timestamps
• In-scope / out-of-scope lists exist and were reviewed
• Primary Y is fully produced inside the boundary (or boundary was expanded)
• Major suppliers and customers of the process are named
• Cross-functional handoffs are visible on the map
• A process owner can accept accountability for the bounded process
• Exceptions and rework paths are acknowledged, not hidden

Master process elements and boundaries and you turn vague “problems in the business” into scoped systems that DMAIC can actually improve.