BISM1201 Chap.3 Business Processes and Organisational Change
Business Processes and Organisational Change
A business process is a repeatable sequence that turns an input into an outcome. It often crosses functions, so the customer experiences one promise while work passes through several teams. A useful process map names the trigger, tasks, gateways, hand-offs, outcomes and owners. It includes exceptions, not only the happy path.
Diagnosis looks for waiting, rework, duplicate capture, unclear decision rules and bottlenecks. Redesign should improve the end-to-end result instead of accelerating one task and moving the queue. Adoption is part of the system: training, incentives, trust, feedback and exception responsibilities determine whether the new process becomes normal work.
What this chapter covers
- 01
Process triggers, tasks, gateways and outcomes
- 02
Swimlanes, ownership and hand-offs
- 03
Cycle time, waiting, rework and bottlenecks
- 04
Process redesign and proportionate controls
- 05
Adoption, incentives, training and feedback
Redesigning a returns process
- +1Map store and postal triggers through validation, approval, refund and closure.
- +1Locate duplicate capture and the finance hand-off queue as the main causes.
- +1Capture the order and reason once, then route only material exceptions for approval.
- +1Assign ownership for damaged, missing and high-value exceptions.
- +1Pilot and measure refund cycle time, error rate, rework and exception volume.
Key terms
- Business process
- A repeatable flow of related activities that transforms an input into a defined outcome for a recipient.
- Process trigger
- The event or condition that begins a process and establishes the case that subsequent work follows.
- Process gateway
- A decision point whose explicit rule directs a case along one of several possible routes.
- Process handoff
- The transfer of work and information between roles, teams or systems, often creating delay or ambiguity.
- Process bottleneck
- The constrained step or resource that limits the throughput or cycle time of the entire process.
- Process control
- A rule, check or responsibility that prevents, detects or corrects an unacceptable process outcome.
Business Processes and Organisational Change FAQ
What belongs on a process map?
Show the start event, tasks, decision points, responsible roles, information hand-offs, exception routes and end outcome. The map should be detailed enough to test rules and ownership without becoming a screen-by-screen manual.
How do I identify a bottleneck?
Look for the step where work accumulates, capacity is most constrained or required information arrives late. Confirm it with waiting and throughput evidence because the busiest-looking activity is not always the system constraint.
Why can automation make a process worse?
Automation can repeat a poor rule faster, increase the queue after an upstream task or scale weak data. Map and validate the process first, then automate a justified flow with exception handling and monitoring.
What makes organisational change part of system design?
The system depends on new roles, trusted information and consistent behaviour. Training, incentives, communication and feedback therefore shape data quality and adoption just as directly as technical configuration does.
Exam move
Take a familiar service and draw it in three lanes. Mark every hand-off, wait and exception, then choose one end-to-end measure. Redesign only after identifying the constraint. In written practice, explain why the proposed change improves the process and what control prevents a speed improvement from creating quality or risk problems.
Begin with observation rather than an ideal diagram.
Follow one case from trigger to outcome and record work time, waiting time, rework and information transferred at each step. Mark where a participant must search, re-enter or clarify. Then draw the current state and ask a second person whether the map matches the written business rules.
Differences between the performed and documented process are evidence, not drawing errors to conceal.
Practise redesign through three distinct moves. First remove an activity only when it adds neither customer value nor necessary control. Second simplify or standardise an ambiguous rule. Third automate a stable, justified step with an exception path. Predict what happens to the next queue after each move.
Add adoption tasks such as training, role clarification and feedback, because a future-state map without behavioural support is incomplete.
For timed answers, use the structure trigger, issue, cause, redesign, control and measure. Include one end-to-end measure and one balancing quality or risk measure. If the prompt celebrates faster processing, challenge whether cases are being reopened or errors shifted downstream.
Conclude by naming the process owner and review point. This closing line shows that improvement is governed after launch rather than assumed from a diagram.
Run an exception audit after drawing the normal path. Introduce a missing approval, an unavailable staff member, incorrect customer data and a request that must be reversed.
For each case, show where work waits, who receives the exception and which record preserves the decision. Compare local task efficiency with end-to-end time. This prevents a redesign from moving delay or rework into another lane while appearing successful inside one team.
