Operational intelligence in ERPs and processes

01

The ERP holds part of the state. The complete operation usually lives outside it.

A request may start in an email, a conversation, a document or an incident. To resolve it, a person consults several screens, interprets a rule, looks for a datum in another system, asks for an authorisation, waits for a response, updates the ERP and afterwards checks whether the change produced the expected effect.

That journey contains knowledge that is rarely found in a single place. Part of it is in the ERP’s data and configurations; part in code, procedures, spreadsheets and documents; and part in the experience of the people who know the exceptions.

We build systems that gather that context and coordinate the work around the enterprise applications that already exist. The conversational interface connects with a system able to preserve state, apply policies, execute tools and verify the result, so that a request advances in a way that is comprehensible, controlled and verifiable.

02

From language to a controlled operation

A conversational interface can make entry easier: “create this supplier”, “check why the order has not been served”, “prepare the adjustment” or “tell me what is missing to close the file”.

The conversation, however, is only one of the entry points. Behind it there must be a system able to:

• recognise the intent and ask for the missing data;
• identify the right entities and files;
• reconstruct the current state and the related operations;
• consult the applicable logic, policies and permissions;
• prepare a proposal or a preview before a sensitive action;
• request authorisation with the context needed to decide;
• execute through the appropriate tool;
• preserve the work if it has to wait or continue later;
• check the effect and record whatever remains open.

The useful capability consists of reducing the effort of reconstructing, coordinating and following a case, while keeping visible how it was decided and who holds the authority.

03

Common use cases

The architecture can be applied, among others, to paths such as:

• creation and modification of master data with documentary checks;
• preparation and follow-up of orders, purchasing, inventory or invoicing;
• reconciliations, adjustments and pre-closing controls;
• classification and enrichment of incidents or internal requests;
• collection of documentation and follow-up of incomplete files;
• coordination of approvals across areas and applications;
• investigation of why an operation became blocked;
• generation of alerts, tasks and actions from changes of state;
• coherent updating of several systems after a single decision.

Whether it is worth automating each step depends on the impact, the reversibility, the quality of the information, the stability of the rule and the authority it requires.

04

Human intervention is designed with a defined function, a defined context and a defined authority

The human in the loop is a function of knowledge and decision: the person receives the case prepared and acts within an explicit authority.

We design different human interventions according to the function they serve:

• completing context when information the system cannot obtain is missing;
• validating an inference when the logic has been reconstructed from incomplete evidence;
• choosing between trade-offs when time, cost, quality or risk compete;
• authorising an action because of its impact, irreversibility or accountability;
• resolving an exception that does not yet have an accepted path;
• stopping or correcting the process when the observed situation contradicts its assumptions;
• reviewing the rule when the exceptions show that the design no longer represents the work.

The person must receive the case prepared: current situation, information used, proposed alternative, reason for the handover, foreseeable consequences and permitted options. Asking for human intervention without that context merely shifts the work.

05

From automating tasks to optimising the operation

Once the process preserves state and leaves comparable traces, it can be observed as a system and not as a sum of tasks.

Optimisation may seek, depending on the case, to:

• reduce the complete time from the request to the result;
• distinguish working time from waiting time;
• decrease repeated gathering of the same information;
• avoid handovers that lose context;
• reduce rework, duplicates and incomplete cases;
• improve the percentage of operations resolved correctly first time;
• reserve human attention for decisions where it contributes judgement or authority;
• shorten the recovery time after a failure;
• choose between tools, models or paths according to cost, risk and quality;
• detect recurring exceptions that ought to become a rule or trigger a redesign of the process.

Optimising consists of improving the complete system and preserving the important trade-offs between time, cost, quality, human load and risk. A faster process may produce more errors; one with fewer escalations may be hiding uncertainty; a more automated one may shift work to a later phase. That is why every objective must be accompanied by constraints and by metrics of quality, risk and result.

06

Hyperautomation, defined precisely

We use “hyperautomation” to describe the coordination of several kinds of capability around a process that crosses systems and does not fit into a linear automation.

It may combine:

• deterministic rules and calculations;
• classification, prediction or language models;
• optimisation;
• agents that choose among permitted tools or paths;
• durable workflows;
• APIs, events and bots;
• documents and operational knowledge;
• human decisions, authorisations and exceptions;
• traces, evaluation and result signals.

The value lies in using only the necessary pieces, giving each of them a clear function and orchestrating them so that the work can be understood, recovered and improved.

07

What an organisation should be able to examine

An operational system must make visible, at the very least:

• the current state of each case;
• the information it used and the information that was missing;
• the rule, policy or model that influenced a decision;
• the tool and the identity with which it acted;
• who reviewed or authorised, and with what context;
• what waits, retries or errors occurred;
• what signal allowed the result to be declared complete;
• which cases remain open and who is responsible for them;
• which exceptions recur and which part of the design should be reviewed.

This visibility serves to operate, audit, learn and optimise. It also keeps the automation examinable by the people who operate and govern the ERP.

08

ERP-Bots, DocuLogic and continuous improvement of the path

ERP-Bots is our line of operational bots and agents: they complete work inside ERPs and business applications under explicit policies, preserving the state of the case and checking the effect in the source. DocuLogic supplies the reconstruction and validation of the logic those paths need, separating observed behaviour, inference, validation and organisational decision.

Once the path preserves state and comparable traces, optimisation can remove a step, ask for a piece of information sooner, change an interface, formalise a rule, replace a model, add or withdraw an agent, move a decision closer to the source, modify a threshold, parallelise tasks, prepare a human intervention better or redesign the completion criterion.

This page applies operational intelligence to the ERP and to business processes. The complete framework — representation of the objective, context, logic, distribution of work, orchestration, durability, human intervention, execution under contract, recovery and verification — lives in Operational intelligence.