AI readiness assessment: map your business processes first

Before adopting AI, understand how your business actually works. That means tracing a real piece of work through the people, systems, decisions and exceptions needed to complete it.

A useful AI readiness assessment asks whether a particular workflow can be improved, what information the improvement would require, and how the organisation would operate it safely. A company-wide maturity score cannot answer those questions on its own.

For an operations or transformation leader, the practical starting point is one process that matters enough to investigate. The aim is to leave with a clear problem, an evidence baseline and a justified next step.

Choose a process with a clear beginning and end

“Improve customer service” is too broad to assess. “Handle an existing customer's order-change request, from receipt to confirmed update” gives the team something specific to examine.

Record the trigger, the finished outcome and the person accountable for that outcome. Agree which locations, customer groups and request types are included. In a larger organisation, the same process name may cover several different ways of working.

Bring together people who perform the work, someone who receives the output, the process owner and the relevant system or data owner. Start with existing documentation, then check it against recent examples. Ask people to show the work rather than describe only the intended procedure.

Map the current state with a simple record

For each step, capture these fields:

• Action: what happens, expressed as a verb and an object.
• Owner: who does it and who can make the decision.
• Input: the information required and where it comes from.
• System: the application, document, spreadsheet or inbox used.
• Rule: what determines the next action.
• Time: hands-on effort separately from waiting.
• Exception: what causes rework, escalation or a different path.
• Output: what passes to the next person and how they know it is ready.

Use a diagram if it helps, but keep the supporting details. A box labelled “check order” hides the difference between confirming a product code, applying a discount policy and asking a warehouse whether dispatch can still be stopped.

Trace ordinary cases and exceptions. Where evidence is missing, write “unknown” and name someone to investigate it. Do not turn workshop estimates into established facts.

Find the cause of the friction

Consider a fictional industrial distributor handling order changes. A request arrives by email, a coordinator checks the order, a warehouse supervisor confirms its status, and a service representative replies to the customer.

The initial suggestion is an AI tool to draft replies. The map reveals that the largest delay is waiting for dispatch status, while inconsistent request details cause repeated clarification emails.

Several improvements are now worth comparing: a clearer intake form, better visibility of dispatch status, an agreed escalation rule, and AI-assisted extraction of order details for a coordinator to verify.

The mapping has changed the question. The team can investigate which intervention addresses the delay instead of assuming that faster writing will improve the whole process. This is an illustrative scenario, not a Hyperius client result.

For each friction point, ask: is the underlying issue missing information, an unclear rule, duplicated work, a system limitation or a decision that genuinely needs judgement?

Establish a baseline before estimating benefits

Pick a small set of measures that describe the process outcome:

• Elapsed time from the agreed start to finish.
• Total handling time across everyone involved.
• Rework or correction rate, using a consistent definition.
• Volume and types of exceptions.
• A relevant service or quality measure.

Use timestamps and records where available, supplemented by observation. Record the period covered and any unusual conditions. Include busy periods and difficult cases before assuming that a typical example represents the whole workflow.

If a proposed tool reduces drafting time, measure what happens to checking, corrections and downstream work too. A local task improvement should not be counted as an end-to-end benefit until the wider process supports that conclusion.

Check readiness for the specific workflow

Use the following questions as a discussion aid. Mark each one “evidence available”, “gap to resolve” or “unknown”, and record the evidence or next action beside it.

1. Purpose: is the business outcome clear, and is there a baseline?
2. Process: do we understand the main path, variations and exceptions?
3. Information: can the proposed solution access sufficiently relevant, reliable and current inputs through approved routes?
4. Authority: who owns the process, and who approves changes to its rules?
5. Controls: what could go wrong, who would be affected, and how would the team detect and recover from it?
6. People: who will use, review and support the solution, and do they have capacity?
7. Evaluation: can knowledgeable reviewers judge outputs against agreed examples and acceptance criteria?

Do not average these answers into permission to proceed. An unresolved access restriction or an unacceptable failure consequence can block a use case regardless of strengths elsewhere.

This context-first approach is consistent with the NIST AI Risk Management Framework's emphasis on understanding the use setting and potential impacts before measuring and managing risk. The questions here are a practical starting point, not a substitute for a full risk assessment. NIST AI RMF Core.

Choose the next step the evidence supports

The assessment should end with a decision and an owner. That might be to clarify a policy, improve a handover, investigate data access, test a conventional automation or shape an AI-assisted pilot.

For a pilot candidate, specify the task AI would assist, the inputs it may use, the actions it may take and the decisions that remain with people. Define how work continues when the system is unavailable or its output cannot be trusted. Then use the evidence to prioritise it against other opportunities.

You do not need to document the entire organisation before making progress. You do need enough detail to explain what will change, why it matters and how you will know whether it helped.

Hyperius helps organisations connect process discovery with practical AI adoption and implementation. If you need a clearer starting point, discuss a process discovery engagement and bring one workflow you want to improve.