Operational improvement · Architecture and Planning

AI-Enabled Business Operations

Improve how the business operates. Use AI where it belongs.

AI can improve how a business operates, but capability alone is not a reason to automate. Nakatomi starts with the business process, establishes how the work actually happens, and determines where simplification, conventional automation, AI or human judgement will produce the better operating outcome.

The problem

AI capability is not an operating model.

Giving people access to capable AI tools can be useful, but it does not by itself change how the business works. Processes may still be unclear, systems may disagree, controls may be implicit, and people may be quietly compensating for broken workflows every day.

Connecting an AI system to that environment does not make those problems disappear. In some cases it can make them harder to see, or give a probabilistic system authority that the process was never designed to delegate.

Nakatomi starts with the business problem and the real process. The question is not only whether AI can perform a task. It is what should change, which technology is appropriate, and where responsibility should remain with people.

A sensible first engagement

Start with one process.

Bring one business process that is slow, expensive, manual, error-prone or difficult to scale. Nakatomi establishes what is actually happening and determines what, if anything, should change.

The answer may involve AI. It may be conventional automation, process simplification or better integration. It may also be that human judgement should remain exactly where it is.

  • Customer onboarding and service administration
  • Quotation and proposal workflows
  • Service triage and operational hand-offs
  • Reporting and document-heavy processes
  • Work that crosses several systems or teams

What we examine

Understand the operation before designing the answer.

A bounded review looks beyond the process diagram and into the way work genuinely happens: the formal steps, the informal workarounds and the points where people, systems and controls meet.

  • Process and purpose
  • People and ownership
  • Systems and systems of record
  • Data and information flows
  • Decisions and approval points
  • Hand-offs and dependencies
  • Exceptions and workarounds
  • Controls and permissions
  • Time, cost and volume
  • Existing automation

What should change?

What should AI do? Sometimes nothing.

Different parts of the same process may need different treatment. AI is one architectural component among several, not the default answer.

  1. 01

    Simplify or remove

    Take unnecessary steps, duplication or avoidable complexity out of the process before adding more technology.

  2. 02

    Conventional automation

    Use deterministic rules, workflow and integration where predictable behaviour is the safer and more efficient answer.

  3. 03

    AI assistance or recommendation

    Use AI to draft, summarise, classify, research or recommend while a person remains responsible for the decision or action.

  4. 04

    Supervised execution

    Allow AI to prepare or perform defined actions only where permissions, approval points and exception handling are explicit.

  5. 05

    Bounded autonomous execution

    Permit limited autonomous action only where evidence, controls, observability and a clearly constrained authority boundary justify it.

  6. 06

    Human-only or do not automate

    Keep work with people where judgement, accountability, risk or context cannot sensibly be delegated.

Human involvement is not failed automation. Approval or judgement may be the correct architecture where responsibility cannot sensibly be delegated.

Architecture and planning

Define how the future process should work before selecting the technology.

Once the operating requirement is clear, Nakatomi designs the practical architecture underneath it. That includes what may read information, what may change authoritative business state, where approval is required, how exceptions are handled, and how the organisation will know whether the design is working.

  • Target process and operating model
  • Systems, integration and systems of record
  • Data authority and information boundaries
  • Identity, permissions and access paths
  • Approval points and autonomy boundaries
  • Exception, failure and recovery handling
  • Observability, audit and evaluation
  • Implementation sequence and transition states

The model is a component of the architecture. It is not the architecture. Platform and model selection follow the workload, environment, controls and economics rather than leading them.

How an engagement works

From one painful process to a controlled implementation route.

The first useful engagement is deliberately bounded. It should create enough evidence to decide what deserves investment without turning an initial conversation into an open-ended transformation programme.

  1. 01

    Understand the process

    Establish how the work genuinely happens: systems, people, data, decisions, hand-offs, exceptions, controls and informal workarounds.

  2. 02

    Identify what should change

    Separate unnecessary complexity, conventional automation opportunities, AI-assisted work, controlled actions and work that should remain human.

  3. 03

    Design the operating and technology architecture

    Define the future process, integration, authority, controls, approval points, failure handling, audit, evaluation and implementation sequence.

  4. 04

    Plan and support implementation

    Select technology only after the requirement is understood. Where specialist engineering is needed, Nakatomi can work with the appropriate delivery partner while remaining independent of the technology selected.

  5. 05

    Measure whether it worked

    Test the implemented process against the business outcome that justified the change, rather than measuring success by AI adoption.

Implementation

Independent architecture can stay client-side while specialists build.

Nakatomi does not need to pretend to be a large software development house. Where specialist engineering is required, we can work with the appropriate delivery partner while remaining independent of the technology selected and close to the architectural and design decisions.

The role is to keep the build connected to the original business outcome: what should be automated, where authority stops, how the solution integrates with existing systems, and whether the controls still reflect the intended design.

AssistRecommendExecute with approvalBounded autonomous execution

Autonomy is earned through evidence and controls. It is not assumed simply because a model is capable of performing the task.

Measure the outcome

Success is an improvement to the business, not an AI adoption number.

The measures depend on the process and the reason for changing it. Appropriate measures may include the following, but no engagement needs all of them.

  • Elapsed process time
  • Human touch time
  • Cost per transaction
  • Error and exception rate
  • Throughput
  • Customer outcome
  • Scalability
  • Control effectiveness

Why Nakatomi

Business improvement first. Technology choice second.

This work extends the same senior technology judgement Nakatomi already brings to architecture, advisory and operational improvement: understand the environment, make the trade-offs visible, design a practical route forward and stay close enough to implementation to protect the intended outcome.

Nakatomi remains vendor- and model-independent. Different workloads may justify different platforms, different models, conventional workflow tooling, bespoke software or no generative model at all.

Nakatomi is an independent UK technology consultancy working with organisations across Surrey, London and the wider UK.

Start with one process

Is there a business process that is slow, manual, expensive, error-prone or difficult to scale?

That is enough to start the conversation. The first step is understanding the process, not choosing an AI product.