Part I: Foundations · Business Analysts as Decision Architects
The business analyst has traditionally been asked to document requirements, map processes, clarify rules, and help technology teams understand the business. In the age of AI, that role becomes more consequential.
The analyst is increasingly responsible for making the organisation’s judgement visible enough to support, test, govern, and improve. That is the work of a decision architect.
The judgement hidden inside a requirement
Consider a requirement written for a steel manufacturing application:
“The system should alert the planner when an order is likely to be late.”
It sounds clear until an analyst asks what “likely” means, which order date matters, what counts as late, how much warning is useful, which constraints must be considered, and what the planner should do after receiving the alert.
The requirement is not wrong. It is incomplete because it describes a notification rather than a decision.
The analyst’s deeper contribution is to discover the judgement hidden inside the sentence. What does an experienced planner actually examine? Which exceptions change the answer? Which trade-offs are acceptable? Who may override the recommendation? What should happen when the evidence conflicts?
The central argument
Business analysts in AI-enabled manufacturing should move from documenting system behaviour to designing decision behaviour.
That does not mean analysts become data scientists or make operational decisions on behalf of experts. It means they become translators between lived work, enterprise rules, data, AI capabilities, and accountable action.
A decision architect makes five things explicit:
1. the decision being made;
2. the evidence considered;
3. the choices available;
4. the authority and boundaries involved; and
5. the learning required after the decision.
This is particularly important because AI systems can automate ambiguity just as efficiently as they automate clarity.
The analyst’s fieldwork
A useful analyst does not begin with a requirements workshop alone. They watch the work.
They sit with a planner as the sequence changes. They observe how a shift incharge decides whether to continue a process or call for help. They ask quality why a material that looks complete is not yet releasable. They examine the spreadsheet that exists outside the official workflow. They ask customer service how a promise is communicated when internal confidence is falling.
The objective is not to copy every step. It is to discover the moments where judgement enters:
- a signal is interpreted;
- an exception is classified;
- a rule is bent;
- a person is consulted;
- an option is rejected;
- or a risk is accepted because waiting would be worse.
Those moments are the raw material of decision architecture.
From process map to decision map
A process map shows activities and handoffs. A decision map adds the questions that make the process intelligent.
For each important decision, the analyst should capture:
Decision statement: What must be chosen?
Trigger: What causes attention?
Decision window: By when must a useful choice be made?
Evidence: What is needed to judge the situation?
Alternatives: What can actually be done?
Constraints: What cannot be violated?
Authority: Who may recommend, approve, execute, or stop?
Outcome: How will the quality of the decision be known?
This format helps separate information requirements from decision requirements. A team may discover that it does not need every available data field. It needs six reliable facts at the right moment and a clear way to challenge them.
A practical example: the late-order alert
Suppose a manufacturing team wants AI to predict late orders. A conventional requirements document might specify a probability score, a dashboard, and an email alert.
The decision architect asks more useful questions:
- Is the objective to recover the order, renegotiate the promise, or protect a higher-priority commitment?
- Does “in full” mean total tonnes, all dimensions, quality release, documentation, or a customer-specific bundle?
- Which choices are still available at 72 hours, 48 hours, and 12 hours before dispatch?
- What is the cost of expediting, resequencing, splitting, holding, or communicating a delay?
- Which decisions are reversible, and which create a new commitment?
- What should the system do when the planner knows a constraint that is absent from the data?
The result may not be a better alert. It may be a decision workspace that assembles affected orders, explains the source of risk, compares recovery options, and records the planner’s reasoning.
Requirements for the AI era
AI-related requirements need a richer vocabulary than “accurate,” “real-time,” and “automated.” Analysts should specify:
Explainability requirements
What must the user understand about the recommendation? Which facts, assumptions, and missing data should be shown?
Challenge requirements
How can the user disagree? Can they state why the recommendation is unsuitable? Is the disagreement recorded in a form that can be reviewed later?
Confidence requirements
When should the system recommend, ask for more evidence, or abstain? A refusal to recommend can be the correct behaviour.
Authority requirements
Which actions can the system prepare? Which require approval? Which must remain outside its authority because of safety, quality, legal, or commercial consequence?
Learning requirements
What outcome will be compared with the recommendation? How will overrides, delays, and unexpected consequences become future evidence?
These requirements give the engineering team something testable and give operators something meaningful to trust.
The analyst as interpreter of conflict
Manufacturing decisions often contain legitimate conflicts. Production may value campaign stability. Sales may value customer urgency. Quality may protect evidence integrity. Logistics may protect loading feasibility. Finance may protect margin.
The analyst should not erase these perspectives in pursuit of one “optimal” answer. The job is to expose the trade-off and make the authority behind the choice explicit.
For example, the question may not be “Which order should be scheduled first?” It may be:
“Which customer commitment should receive scarce finishing capacity, given strategic priority, contractual exposure, recovery cost, and the feasibility of completing the full order?”
That question can be discussed, governed, and improved. A vague optimisation objective cannot.
When the decision design is failing
Analysts can use the following diagnostic questions during discovery and testing:
- Are users requesting more data because the decision itself is undefined?
- Does the recommendation produce a technically valid but unusable option?
- Are exceptions handled through personal contacts rather than an explicit rule?
- Do stakeholders agree on the action but disagree on the evidence?
- Can a user explain why they accepted or rejected a recommendation?
- Is the outcome measured at the level of the decision, or only at the level of system activity?
- Does the design reward people for hiding overrides rather than explaining them?
These questions prevent the analyst from becoming a document producer for an unclear operating model.
A decision-architecture artefact set
A practical business analyst can create a small set of artefacts for each AI-enabled decision:
Decision canvas: the decision, owner, trigger, window, and outcome.
Evidence map: source, meaning, freshness, owner, and confidence for each input.
Option catalogue: feasible actions and their consequences.
Authority matrix: recommendation, approval, execution, and stop rights.
Exception register: known situations where the normal logic does not apply.
Override taxonomy: structured reasons people reject a recommendation.
Outcome ledger: what happened, what was expected, and what was learned.
These artefacts create a bridge between business discovery, product design, data engineering, model development, and governance.
Moving from requirements to experiments
Do not wait for a perfect specification. Choose one decision and test the design with historical cases.
For a late-order decision, replay several past orders. Give the team only the information that would have been available at each decision point. Ask whether the proposed evidence was sufficient, whether the options were realistic, and whether the authority was clear.
Then run the capability in shadow mode. Let the system prepare a recommendation without taking action. Compare it with the human decision and record the reason for any disagreement.
The analyst should treat every disagreement as a design question:
- Was the human using valid local knowledge?
- Was the knowledge available anywhere else?
- Is it a durable rule, a temporary exception, or an individual preference?
- Should the system learn it, display it, or leave it outside automation?
This is how tacit expertise becomes responsibly usable without pretending that all judgement can be reduced to a formula.
Questions for business analysts and leaders
- Which operational requirement currently hides the most judgement?
- What decision does the requested dashboard actually support?
- Where do stakeholders use different definitions for the same business term?
- What would a responsible abstention look like?
- Which human workarounds should become explicit evidence?
- What is the smallest decision product that could be tested this quarter?
- How will the organisation know whether the decision improved?
Conclusion: make judgement visible, not disposable
The future business analyst is not simply the person who gathers requirements for an AI system. They are one of the people who decide whether the system understands the work it is entering.
That responsibility requires humility. A process document may be neat while the real work is full of exceptions. A model may be accurate while the recommendation is unusable. A stakeholder may appear resistant while protecting a consequence the project has not represented.
Decision architecture gives the analyst a practical way to work with that complexity. It turns conversations into explicit decisions, decisions into testable evidence, and evidence into bounded capabilities.
The goal is not to remove human judgement from manufacturing. It is to help the organisation recognise where judgement matters, support it with better context, and learn from it without losing the people who developed it.
Disclaimer
Industry situations in this chapter are composite illustrations unless explicitly attributed to a public source. They are not claims about any particular company, plant, vendor, or incident. Implementations must be validated against local safety, quality, cybersecurity, regulatory, contractual, labour, and data-governance requirements.
#BusinessAnalysis #DecisionArchitecture #ManufacturingAI #AIRequirements #BusinessAnalyst #OperationalKnowledge #DecisionIntelligence #SmartManufacturing #DigitalTransformation #FutureOfWork
