Defining Inputs Outputs And Controls

Why this matters

Clear Inputs, Outputs, and Controls (IOC) make your BPMN maps reliable for decisions, automation, and compliance. As a Business Analyst, you will:

• Clarify what triggers a process and what must be ready (Inputs).
• Define what stakeholders receive at the end (Outputs).
• Surface constraints like policies, rules, SLAs, and regulatory needs (Controls).

Real tasks you will handle:

• Documenting upstream data needed before development starts.
• Agreeing on done criteria for deliverables with business owners.
• Capturing rules that govern approvals, deadlines, and compliance checks.

Concept explained simply

Think of any process as a recipe:

• Inputs: ingredients you must have before you start.
• Outputs: the dish that comes out at the end.
• Controls: the rules and constraints (temperature, timings, diet rules) that guide how you cook.

Mental model: I-O-C vs. resources

A helpful mental model comes from IDEF0: Input, Output, Control, Mechanism. In BPMN, we usually capture:

• Inputs: data/materials that flow into tasks (Data Inputs, Data Objects).
• Outputs: deliverables/results (Data Outputs, end events with documentation).
• Controls: policies, rules, deadlines, thresholds, compliance guards. Often shown as annotations, rule tasks, gateways with conditions, or boundary events (timer/error).
• Resources (Mechanisms): people/systems that do the work. These are NOT controls; use Pools/Lanes or task performers.

How to define IOC step-by-step

1. Name the process outcome first. Ask, “What must be true for this to count as done?” This becomes your Output list.
2. Backtrack to prerequisites. For each output, list the minimal data/materials needed before work starts (Inputs). Avoid optional extras.
3. List constraints. Capture rules, approvals, thresholds, SLAs, regulations, and exception handling (Controls).
4. Validate with stakeholders. Confirm that inputs are available, outputs are acceptable, and controls are realistic.
5. Map to BPMN. Represent inputs/outputs as Data Objects or Data Inputs/Outputs; represent controls using gateways, boundary events, rule tasks, and annotations.

• [ ] Output(s) are measurable and acceptance-tested.
• [ ] Inputs are minimal and available at the start (or clearly staged).
• [ ] Controls cover approvals, deadlines, exceptions, and policies.
• [ ] Resources are not mislabeled as controls.
• [ ] Each IOC item is visible in the BPMN diagram.

BPMN notation: where IOC lives

• Inputs/Outputs: use Data Objects (paper icon) and Data Stores; Data Associations to tasks; optional text annotations to specify fields.
• Controls:
  • Gateways with condition expressions (e.g., amount > 5,000).
  • Business Rule tasks/Script tasks to evaluate decision tables.
  • Boundary Timer events for SLAs; Error/Escalation events for exceptions.
  • Text Annotations for policies or regulatory citations.

Worked examples

1) Online order fulfillment

• Output: Confirmed order and dispatch request sent to warehouse.
• Inputs: Customer cart, payment details, shipping address.
• Controls: Fraud check policy, payment authorization, stock availability rule, SLA to confirm within 2 minutes.

Start → Validate Cart → Authorize Payment → Reserve Inventory → Create Order → End
Inputs: Cart, Payment details, Address
Outputs: Order record, Dispatch request
Controls: Fraud score < threshold, Payment = authorized, Stock > 0, Timer < 2 min

2) Employee onboarding

• Output: Active employee profile and access granted.
• Inputs: Signed contract, ID documents, role definition.
• Controls: Compliance (KYC/Right to Work), manager approval, access policy by role.

Receive signed contract → Verify identity → Manager approves access → Create accounts → End
Inputs: Contract, ID docs, Role
Outputs: HR profile, Accounts
Controls: Compliance pass, Approval required, Role-based access rules

3) Supplier invoice approval

• Output: Approved invoice ready for payment run.
• Inputs: Invoice PDF/XML, PO number, goods receipt.
• Controls: 3-way match policy, approval thresholds, payment cutoff time.

Receive invoice → Match to PO and receipt → Approval (if needed) → Queue for payment → End
Inputs: Invoice, PO, Receipt
Outputs: Approved invoice record
Controls: Match = true, Amount threshold for approver, Cutoff 5pm daily

Common mistakes and self-check

• Mistake: Listing team names as controls. Fix: Teams are resources; move them to lanes/pools.
• Mistake: Inputs arrive mid-process. Fix: Stage inputs clearly or split process into phases.
• Mistake: Vague outputs like “done.” Fix: Specify data state (e.g., “Order status = Confirmed with ID”).
• Mistake: Hidden controls. Fix: Add boundary events or annotations for SLAs, approvals, and exceptions.
• Mistake: Too many optional inputs. Fix: Keep a minimal, necessary set; mark optional data explicitly.

Quick self-audit

• Can a new teammate understand when the process starts and ends from IOC alone?
• Can QA test outputs without reading emails or tribal knowledge?
• Would automation still work if a person is absent—are rules explicitly written?

Exercises

These mirror the tasks in the Exercises panel below. Complete them here, then submit in the panel to check yourself. Everyone can take the exercises; only logged-in users will have their progress saved.

1. ex1: Password reset process
   • Define Inputs, Outputs, Controls for a self-service password reset.
   • Sketch how you’d show them in BPMN (data objects, timer/error events, gateways).
2. ex2: Supplier invoice with exceptions
   • Add controls for amount-based approvals and cutoff times to a basic invoice process.
   • Show where boundary events and condition gateways would appear.

• [ ] Inputs minimal and available at start
• [ ] Outputs measurable and testable
• [ ] Controls explicitly represented (rules/SLAs/exceptions)
• [ ] Resources not mislabeled as controls

Practical projects

• Map IOC for a real internal process (e.g., access request). Get sign-off on outputs from a stakeholder.
• Create a decision table for one control (e.g., approval threshold) and reference it in a Business Rule task.
• Instrument one control with a boundary timer event and define the escalation path.

Learning path

• Before this: Basic BPMN notation (events, tasks, gateways, data objects).
• Now: Defining Inputs, Outputs, and Controls with clarity.
• Next: Exception handling (error/escalation events) and decision modeling (DMN).

Who this is for and prerequisites

• Who: Business Analysts, Product Owners, Process/Operations Analysts, QA leads.
• Prerequisites: Basic BPMN shapes; ability to interview stakeholders; familiarity with policies/SLAs in your domain.

Next steps

• Refine one of your current process maps by explicitly adding IOC.
• Run a 15-minute review with a stakeholder to validate outputs and controls.
• Proceed to the Quick Test below to confirm understanding.

Mini challenge

Scenario: A returns process allows customers to return items within 30 days.

• List 3 Inputs, 2 Outputs, and 3 Controls.
• Where would you place a timer or error event? Why?
• Write one condition expression for a gateway.

Example thinking path

Outputs first → find minimal Inputs → add Controls for time, eligibility, and approval thresholds → place Timer boundary on “Await return package.”

Quick Test

This test is available to everyone. Only logged-in users will have their progress saved.