Capacity, flow and service options | CBAP: requirements, decisions, and business value

Start with the decision and the unit

Imagine an analysis team evaluating the next design for receiving fund instructions. “We need more capacity” does not yet specify the decision: completing more instructions daily, meeting urgent deadlines, reducing customer effort or freeing APS time may favor different options. Write the intended outcome, horizon, constraints and selection criterion before calculating. A useful recommendation explains the need it addresses and what it sacrifices. Distinguish a unique request, a visit to a task, a minute of resource occupancy, a completed output and elapsed time. An instruction can visit one team twice; an operator can perform two stages; a batch can finish several instructions together. These facts change the model. Record the boundary too: application, complete process or service including suppliers. This lesson’s figures are fictional and deterministic. Simplification exposes decisions; it does not automatically estimate real waiting times, availability or service levels.

Count work that returns

In a separate example, 80 requests need four minutes of initial review. Twelve return exactly once for a three-minute review, with no later returns. Workload is 80×4+12×3=356 minutes. Request count remains 80. The 92 visits explain workload, not 92 customer outcomes. Do not subtract corrected requests: they already occupied the resource on their first visit. If the team only says “15% return,” details are missing. Is the percentage of original requests or all visits? Does the return take the same time? Can a second return occur? The answers can change the design of training, source validation or review capacity. Use traceable counts and state the model’s boundary. Use indefinite repetition only if that mechanism is defined; a more sophisticated formula can be less faithful than a table of actually observed visits.

Diagram boxes are not additional resources

A preparation stage takes two minutes and confirmation takes four. If one person performs both without overlap, each request uses six minutes of that person’s time. In 60 minutes, theoretical capacity is ten requests. Taking the smaller of 30 preparations/hour and 15 confirmations/hour would give 15 and ignore that both rates compete for the same time. With two dedicated people, one per stage, the model changes: as sustained capacity under the stated conditions, confirmation limits the chain to 15. Add resources, qualifications, schedules and actual concurrency to the design. Resource occupancy need not equal an instruction’s elapsed time, which may include waiting. These examples exclude breaks, variability, buffer blocking and failures. In a real analysis, investigate those conditions before treating calculated capacity as a commercial commitment.

Recalculate the limit after each option

In a simple chain with independent resources, no losses and no rework, every output requires one visit to every stage. A lower-capacity stage prevents the others from converting all their capacity into output. Demand can also limit actual production. For example, with demand 90 and stage capacities 100, 70 and 85 per hour, output is bounded at 70. Raising the second stage to 95 moves the limit to 85; it does not create 25 additional outputs per hour. Compare every option with the same reference. If raising the second stage to 85 costs less than raising it to 95 and the only objective is this model’s output, the extra capacity delivers no additional benefit. Other reasons, such as later growth, may justify buying it, but need their own horizon and evidence. Also record that restricting input can contain work in progress without increasing output. Queue control and capacity growth are different effects.

Translate demand into effort and allocation

One hundred requests do not define one hundred equal units of effort. If 70 standard requests need two minutes and 30 specialist requests seven, workload is 350 minutes. At 50 of each, it becomes 450 without increasing request count. Compare automation proposals in the class they actually change and retain required controls. Removing one minute from a rare class can release less capacity than a modest improvement in a frequent class. Nominal capacity is not interchangeable by default either. If only one person can perform a specialist task, another person’s spare time does not remove that constraint. Build a small person–task matrix and try feasible assignments. An additional objective, such as preserving a training block, belongs in the criterion. Do not assign work through equal request counts when times, qualifications or required continuity differ.

Compare setup economy with delivery deadlines

A batch can reduce setup work per instruction while increasing time to the first released response. Define whether outputs become available per instruction or only at batch completion. On a machine requiring four setup minutes plus one minute per instruction, a batch of eight finishes in 12 minutes. Two batches of four finish at eight and 16 minutes: they consume more total time but release the first four responses sooner. The choice depends on deadlines and order. Draw a timeline showing request availability, setup start, processing and result release. Do not use average capacity or total duration alone. In these exercises, setup occupies the same machine and batches cannot overlap. If a supplier can prepare the next batch in parallel, that is a new assumption to model and demonstrate, not an implicit benefit.

Compare value while retaining commitments

An option with higher value per request can consume so much resource that total value is lower. Where the model permits comparison, calculate value per unit of the limiting resource. First retain mandatory minima, dependencies and other conditions. If one service takes three minutes per request and yields nine points, while another takes six and yields 12, the first yields three points per minute and the second two. This can guide remaining capacity only when points are comparable and additive and demand exists. Do not generalize this rule to every portfolio. Indivisible requests, customer minima, different resources and overlapping benefits may require enumerating feasible sets. Here, points are fictional preferences, not revenue or financial return. Deliver the criterion, mix, resource use and retained commitments with the recommendation; an isolated ranking does not establish feasibility.

Retain dependency between scenarios

A forecast may provide an interval without probabilities. Do not automatically turn its midpoint into an expected value. Ask which decision the interval must support: best case, a commitment covering every admitted case or investigation to reduce uncertainty. The criterion is a management choice that the model should expose. If two request types always total 100, increasing one reduces the other. Adding their separate maxima creates an impossible mix. Write the relationship, such as standard=100−specialist, and calculate each scenario using compatible values. A reservation covering the interval maximum is sufficient only for the stated assumptions: constant times, no additional work and the supplied availability. It does not cover occurrences omitted from the interval. Distinguish an explicitly required margin from extra capacity purchased without defined benefit.

Design the sequence of commitment and learning

A staged strategy benefits from new information only if a decision remains that the information can change. Distinguish reserving capacity, activating it and paying for use. A contract can give each step a different deadline and cost. If reservation closes before demand becomes known, “wait and decide later” can destroy the very alternative intended to be preserved. Original example: a reservation costs one unit today; activation tomorrow costs three more. Tomorrow’s information can avoid activation under low demand. With equivalent fixed capacity costing five units, the reserved option costs one or four and is cheaper in both scenarios if it meets the same requirements. But if activation were also required today, that benefit from waiting disappears. Represent intermediate states and deadlines instead of treating “staged” as a guarantee of flexibility. Do not invent probabilities to compare an option already dominating in every supplied scenario.

Relate the error unit to the business outcome

A rejection can have a broader boundary than necessary. If the contract permits independent instruction decisions and requires individual outcomes, rejecting a whole batch for an isolated error prevents valid results. More CPU does not change that behavior. Analysis should specify which units are independent, which depend on each other and which response accompanies each decision. Partial acceptance does not mean hiding invalid instructions or accepting them without controls. The design should retain an outcome for every received instruction and identify those needing correction. If a genuine all-or-nothing obligation exists, such as an explicitly indivisible set, separating instructions can violate the requirement. This lesson does not prescribe universal partial acceptance: it teaches comparing the implemented boundary with the business boundary before choosing a technical solution.

Identify who receives work and compare future costs

A local improvement can transfer effort. Show before/after by stakeholder and resource instead of calling every observed reduction a saving. If customers save six minutes but the processing team adds four, total effort falls by two while team spare capacity decreases. Both conclusions can be true. The solution boundary helps classify the limitation and involve those controlling the external process, without assuming the whole organization is inside the application. When recommending retention, replacement or retirement, compare costs and outcomes that can still change within the horizon. An unrecoverable investment belongs to both options’ history, but migration, exit and future operation still count. A cheaper alternative is comparable only if it retains relevant capabilities and obligations. Recognizing past costs is not a shortcut around transition analysis. Financial criteria and operational sufficiency both need to be explicit.

Guided exercise: retain the design and change assumptions

Use a spreadsheet or paper. A fictional day has 90 requests. Each needs three minutes of initial review. Eighteen require one additional two-minute review. The team has 300 minutes; all other stages have sufficient capacity. Option P reduces returns to nine requests while keeping times. Option Q reduces initial review to 2.8 minutes while keeping 18 returns. Both cost the same and retain controls. Calculate current workload and each option’s workload, then recommend the one leaving most spare capacity in this model. Solution: current=90×3+18×2=306; P=270+18=288; Q=252+36=288. It is a tie, with 12 spare minutes. Do not invent a numerical preference: record the tie and identify a relevant additional criterion. Variant A: returns become 30 and P halves them; current=330, P=300 and Q=312. Only P fits. Variant B: returns revert to 18 but each additional review takes four minutes; current=342, P=306 and Q=324. Neither option fits 300. Explain why the initial recommendation cannot simply be copied into the variants. Results depend on visit count and duration. These bounded calculations check consistency of assumptions; they are neither a production capacity test nor evidence that controls are effective.

Exercise files

Original Python exercise with editable data, instructions and explained results. Requires Python 3.10 or later; no network or production data is used.

Download the capacity and decision exercise

IN PRACTICE

A smaller batch can release urgent results earlier while consuming more setup. The right option depends on the output contract and each group’s deadlines.

Common pitfalls

Counting instructions instead of visits; duplicating one person’s capacity; buying beyond the next limit without benefit; adding incompatible maxima; optimizing total duration while ignoring deadlines; awaiting information after losing the option; confusing transferred work with eliminated work.

Related topics: Current-state analysis · Design options and value · Solution and enterprise limitations

Take this idea with you

A sound recommendation connects the desired outcome to the right unit, actual resources and each option’s conditions. Recalculate when assumptions change and communicate what the model can and cannot establish.

Create account

References

Analyze Potential Value and Recommend Solution: public task card · v2.0, copyright 2025
Specify and Model Requirements and Designs: public task card · v2.0, copyright 2025
Recommend Actions to Increase Solution Value: public task card · v2.0, copyright 2025
15.S07 GlobalHealth Lab: Lecture 4: Process Improvement · Spring 2013; historical conceptual source, not an updated CBAP specification