I have been thinking about what happens when we take the changing role of the Business Analyst (BA) I discussed in Part 3, and how it applies to business process analysis. The automation decision was reasonably straightforward, a process step was performed by a person, or it was automated. That made sense, up to a point. AI now gives us another way to deal with process steps that involve language, interpretation, incomplete information and some degree of judgement.

The question is no longer simply, Can this step be automated? It is now, What kind of automation does this step require, how much variability can we tolerate, and what should remain under human control?

What is it?

Understanding and improving business processes is well-established BA work. The IIBA BABOK Guide describes process analysis as assessing a process for efficiency and effectiveness and identifying opportunities for change. It describes process modelling as a way of showing how work is carried out and as a foundation for that analysis.

Whether someone uses BPMN, swimlane diagrams, a flowchart or a simple ordered list. The goal is the same to understand what happens, who or what performs each activity, what information is required, what decisions are made and what the activity produces.

A typical process-improvement flow looks something like this:

• Understand the work: Establish what actually happens today, including workarounds, delays, handoffs and exceptions.
• Simplify the workflow: Remove unnecessary steps, duplicate approvals, repeated data entry and activities that no longer add value.
• Identify automation opportunities: Decide which remaining activities could be performed or supported by technology.
• Understand the interfaces: Determine how people, systems and automated components exchange information, decisions are made, including where data comes from and how it can be accessed.

AI does not remove any of this work. In fact, it makes the work more important because the range of activities that could potentially be automated has expanded. Automation was strongest where the rules could be stated clearly - a system could check whether a required field had been completed, calculate a value, compare a date, route a request based on a category or apply a financial threshold. These are deterministic activities (given the same inputs and the same rules, we expect the same output).

AI introduces the possibility of automating more probabilistic activities. These are activities where the system interprets information and produces an answer that may vary.

For example, AI might:

• classify a vaguely worded service request
• summarise an incident report
• extract obligations from a contract
• compare a proposal against evaluation criteria
• identify possible risks in a project document
• draft a response using organisational knowledge
• determine the likely intent behind a request

These were traditionally human activities because they involve language, context and ambiguity. AI can now perform parts of them, but it does not make them deterministic - the output can be useful without being guaranteed to be identical or correct every time.

This creates a new decision flow for each process step.

• First, should the step exist at all? Not an new choice - there is little value in automating work that should have been removed. Automating a badly designed approval process usually gives you a faster badly designed approval process.
• Second, should the step remain human or become an automation candidate? Some activities should remain human because they involve increased levels of risk, accountability, negotiation, empathy, sensitive communication, conflicting interests or decisions that the organisation is not prepared to delegate. Others may remain human because the volume is too low to justify the investment in automation or because the process changes too frequently to support it properly.
• Third, if it is an automation candidate, is it deterministic or probabilistic? If the activity follows stable, explainable rules, conventional automation is usually the better choice. A lookup, calculation, database query, workflow rule or API call will normally be cheaper, faster and more predictable than asking an AI model to work out the answer. AI becomes relevant when interpretation is genuinely part of the work.
• Fourth, if AI is appropriate, how should it be implemented? Should this be a no-code, low-code or code based solution.

AI Implementation Choices

• A no-code implementation may be appropriate for a relatively contained workflow using standard connectors, approved data sources, configurable prompts and a clear human review step.
• A low-code solution becomes more relevant when the process needs richer orchestration, API calls, some complex branching, structured data transformations or custom actions.
• A coded solution may be necessary when the organisation needs bespoke integrations, higher transaction volumes, custom security controls, detailed evaluation, observability, version control, sophisticated orchestration or simply greater control over how the system behaves over time as the underlying systems change (or simply even a preference for code based solutions)

The choice between implementation type is not quite straightforward - code is not automatically better and no-code is not automatically simpler. The right question is which approach provides enough control, supportability and flexibility for the process being designed.

This is also where the interface between the Business Analyst and the Solution Architect gets a little more complicated. The BA does not need to become the Solution Architect. However, it seems that it is increasingly difficult to define the process properly without understanding something about the available implementation choices. Similarly, the Solution Architect cannot make a good technical decision without understanding the business context, exceptions, consequences of errors, required evidence and tolerance for variability.

The boundary becomes more collaborative.

What does it mean from a business perspective?

The automation opportunity is becoming larger. AI can address document-heavy and language-heavy activities that previously sat outside conventional workflow automation. That does not mean the entire process should become an AI process and most solutions will combine people, deterministic automation and probabilistic AI.

Consider the intake of an internal service request.

• A deterministic component might confirm that mandatory information is present, retrieve the requester’s department and apply routing rules.
• An AI component might summarise the request, suggest a category and identify its likely urgency.
• A person might review unusual, sensitive or high-impact cases before work begins.

The value comes from how these parts work together, not from whether the organisation can say it has deployed an AI agent or an Agentic/AI Workflow (these phrases are getting used so interchangeably). The simplest reliable technology should perform each step. If a rule, lookup or calculation can produce the answer, use it. AI should not be inserted merely because it is available.

The opposite is also risky. Expressing highly interpretive work as an increasingly complex ruleset can result in a fragile decision tree containing hundreds of conditions, frequent exceptions and significant maintenance effort.

At some point, the low-code or no-code workflow becomes more complicated than a coded solution, or the deterministic rule set becomes a poor imitation of the judgement the process really requires.

• Quality control becomes a design issue. With conventional automation, testing often asks whether the system followed the specified rule and produced the expected output. With AI, we also need to ask whether the answer is sufficiently accurate, relevant, grounded, complete and appropriate for its intended use. That may require example datasets, expected answer ranges, confidence thresholds, human review rules and defined escalation paths. “Works most of the time” is not a complete requirement.
• The required level of performance depends on the consequence of failure. An imperfect summary used to prepare for a meeting may be acceptable because the user can review the source material. An imperfect eligibility decision, financial approval or public communication is a different matter.
• Risk tolerance has to be considered at the process-step level. Human review also needs to be specific, saying that a solution will be “human in the loop” is not enough. Which human? What are they reviewing? What information will they see? Do they have enough time and knowledge to identify an error? Can they override the recommendation? Is their decision recorded?
• The business case matters. The organisation needs to decide whether it is trying to reduce effort, improve service speed, handle more volume, improve consistency, reduce backlog or strengthen compliance.
• The implementation choice also becomes an operating-model decision. A no-code prototype may be developed quickly by someone close to the process, that can be a real advantage, but if the workflow becomes operationally important, someone still needs to manage access, test changes, monitor performance, handle incidents, update integrations and support users. A solution that takes two days to build can still create years of operational responsibility. This is why the no-code, low-code and code decision cannot be based only on development speed.

The organisation needs to understand where information is processed, what models are being used, how data is retained, what audit information is available and what happens when the vendor changes the service. They affect whether the process can be operated responsibly.

What do I do with it?

The practical starting point is not to redraw every process in the organisation or turn every BA into an AI engineer, or vice-versa. Start with a real workflow where the value is understandable and the consequences of an error can be managed.

• Understand the work before discussing tools. Observe how the process actually operates. Identify the informal decisions, workarounds, exceptions and information sources that may not appear in the documented procedure.
• Simplify before automating. Remove unnecessary handoffs, duplicate checks and approvals that exist only because of previous system limitations. AI should not become another layer added to an already cluttered process.
• Decompose the process far enough to see the different types of work. “Review application” is too broad. It may contain data validation, document classification, information extraction, eligibility checks, risk assessment and a final accountable decision. Those activities may require different solutions.
• Bring the Solution Architect in before the process design is treated as finished. The BA should bring the business context, value, rules, exceptions, risk and accountability requirements. The architect should help test the feasibility, integration approach and appropriate delivery model. This should be an iterative and collaborative conversation, not a handoff.
• Design the interfaces explicitly. Identify where information comes from, whether it is structured or unstructured, how access will be granted and what the automated component is allowed to do. An AI assistant that reads a policy library has a different risk profile from an agent that changes a customer record or sends a message externally.
• Prototype using real examples and difficult cases. A polished demonstration using three clean documents proves very little. Test incomplete information, conflicting documents, unusual terminology and the exceptions that experienced staff know will eventually appear.
• Define the human control points. Decide where review, approval, override and escalation are required. Make accountability visible in the workflow rather than leaving it implied.
• Measure operational outcomes. Establish a baseline and measure process cycle time, avoided effort, rework, quality, consistency, backlog, user adoption and exception rates. For an AI component, also track how often people accept, modify or reject its output.

Once you’ve identified a likely automation step, a lightweight review can use the following questions.

Is it a good automation candidate?

• Is the activity repeated often enough to justify automation?
• Are the inputs, outputs and purpose reasonably clear?
• Can success be measured?
• Is the process stable enough to support?
• Can common exceptions be identified?
• Does automating it improve effort, duration, consistency, capacity or quality?
• Is the data accessible by a system?

A “no” does not necessarily rule out automation, but it signals that the process may need more analysis first.

Is it deterministic or probabilistic?

• Can the decision be expressed as a stable rule?
• Should identical inputs always produce identical outputs?
• Is exactness more important than interpretation?
• Does the activity depend on understanding language, context or incomplete information?
• Are several answers potentially reasonable?
• Can the organisation tolerate, detect and correct an incorrect result?

Where a rule or calculation can do the job, use it, where interpretation is genuinely part of the work, AI may be appropriate. Many steps will be hybrid where AI extracts or recommends and deterministic logic validates the result with a person approving consequential decisions.

Is no-code, low-code or code the right implementation approach?

• No-code may fit when: The workflow is contained, standard connectors are available, volumes are manageable, human review is straightforward and the platform provides enough security and monitoring.
• Low-code may fit when: The process needs more complex branching, API integration, custom actions, structured transformations or extensions beyond standard platform features.
• Code may fit when: The solution is operationally critical, highly integrated, high-volume or technically complex, or when it requires custom controls, testing, evaluation, security, observability and lifecycle management.

The implementation path should reflect the expected life of the solution, not just the speed of the first demonstration. The point here is not that every human activity should become an AI activity. It is that Business Analysts now have more options when designing how work should be performed.

The previous distinction between human work and automated work is no longer enough. We need to distinguish between human judgement, deterministic automation and probabilistic AI, then decide how those elements should work together. That adds complexity, but it also gives organisations an opportunity to redesign processes that conventional automation could only partially address.

The role of the BA is not to choose the model or write all the code. It is to make the decisions, assumptions, trade-offs and accountabilities within the process clear enough that the organisation can build the right solution.