Start with the work, not the dashboard
Process intelligence is the ability to build a reliable, decision-ready view of how work actually moves through a system. It connects steps, owners, evidence, delays, risks and outcomes so a team can distinguish a local symptom from a structural constraint.
For PMO and R&D teams, that definition must include more than event logs. Technical work contains reviews, assumptions, unresolved decisions and partial evidence. A useful model must make those elements readable too.
The broader AI Process Intelligence method adds AI-assisted interpretation only after the operating context has been structured. AI can summarize and compare evidence; it should not invent the process model it is supposed to analyze.
A practical definition
Process intelligence combines process evidence and operating context to answer four questions:
- What is happening now?
- Where is flow being interrupted or distorted?
- Which risk or decision is responsible for the next meaningful delay?
- What intervention has the highest value relative to effort and uncertainty?
The output is not merely a process map. It is a shared model that can support prioritization, governance and automation decisions.
What evidence does it need?
The minimum useful evidence depends on the process, but a robust starting set includes:
- steps and entry or exit conditions;
- owners and decision rights;
- systems and source records;
- timestamps, queues and waiting time;
- open risks, issues and assumptions;
- outcome metrics and quality criteria;
- exceptions that reveal how work differs from the documented path.
Not every process has clean event data. In an R&D environment, evidence can include design reviews, test results, supplier commitments and unresolved architecture choices. The model should identify confidence and gaps instead of treating every input as equally reliable.
The READ framework
I use a simple four-part framework to test whether a process is ready for analysis.
Record the evidence
Identify the source behind each important claim. A milestone reported as green should point to accepted deliverables, test results or explicit completion criteria.
Explain the context
Capture constraints, dependencies and uncertainty. The same delay can mean a local execution problem or a deliberate response to technical risk.
Align the criteria
Define what ready, blocked, approved and complete mean across functions. Shared labels without shared criteria create false alignment.
Decide the next intervention
Translate the model into one owned action: remove a bottleneck, close an evidence gap, change a rule or automate a stable step.
Example: an engineering change request
Imagine a change request moving between product, hardware, firmware and supply chain. The visible problem is cycle time. The initial reaction might be to automate approvals.
The process-intelligence view reveals something different: requests enter without a common impact assessment, every function uses different severity criteria, and supplier implications are discovered late. Approval automation would accelerate incomplete requests into the same decision bottleneck.
The better sequence is:
- define a shared intake record;
- make impact criteria explicit;
- identify which evidence is mandatory by change type;
- measure waiting and rework;
- automate routing only after the decision model is stable.
That sequence improves the system rather than automating its ambiguity.
Process intelligence is not surveillance
The objective is not to measure individual activity or maximize utilization. Healthy process intelligence focuses on flow, evidence and decision quality. It should expose structural friction without turning every variation into a performance judgment.
This distinction matters in R&D, where exploration and iteration are part of the work. The model should separate productive uncertainty from avoidable opacity.
Where to begin
Choose one process with a visible business consequence and a reachable owner. Avoid beginning with the largest end-to-end transformation. Map a bounded flow, test the evidence and produce one decision that the current system cannot support clearly.
The Process Readiness assessment provides a structured starting point across clarity, ownership, measurability, automation potential and risk control.
If the process crosses several teams and the decision criteria are still disputed, use a short scoping exercise before selecting technology. Bring the process and its evidence to an advisory conversation.