A process interaction matrix shows selected relationships between processes. It can help an organisation identify dependencies and handover questions that are difficult to see in separate descriptions. Its usefulness depends on explaining what the relationship means, not merely placing a mark wherever two processes might be connected.
The process management guide describes the wider architecture. A matrix is an optional representation. It does not replace operational arrangements or prove that a handover works in practice.
Define the purpose and level
Decide whether the matrix is intended to show information flow, material transfer, resource dependence or another relationship. Mixing those meanings in identical symbols can make the table look comprehensive while leaving users uncertain.
Use processes at a consistent level. A matrix that compares a whole business function with one small task can obscure the boundaries. Link to more detailed views where necessary rather than force every level into one grid.
Select the significant relationships for the question being examined. Not every conceivable connection deserves an entry, and a completely filled matrix may reveal little about priorities.
Make direction explicit
Define whether rows supply to columns or the reverse. An interaction can be directional: order review supplies accepted requirements to planning, while planning may return a feasibility issue through another route.
A two-way relationship should not automatically be represented as one unexplained mark. The information, criteria and responsibility can differ in each direction.
The inputs and outputs article explains why a transfer needs a usable result for its recipient. The matrix should help identify that need rather than stop at the existence of an arrow or symbol.
Build a small original example
In the following fictional example, the row process supplies the column process. A blank cell means that no direct relationship is being described in this simplified view, not that the processes can never interact.
| Supplier process | Planning | Purchasing | Release |
|---|---|---|---|
| Order review | Accepted requirements and constraints | Relevant supply conditions | Agreed acceptance commitments |
| Planning | Not shown | Required materials and timing | Identified work and status |
| Inspection | Relevant adverse-result information | Supplier-related discrepancy information | Check results against applicable criteria |
The entries identify content instead of using unexplained crosses. A real matrix should fit actual processes and avoid implying that this example is a prescribed QMS architecture.
Examine acceptance and responsibility
For an important entry, ask who provides the information, who receives it and what makes it suitable. A specification sent on time may still be incomplete or obsolete.
Identify the route for uncertainty. If the receiving process silently repairs every input, upstream measures may conceal the problem. If neither side owns the decision, work can wait indefinitely or proceed on an assumption.
A matrix can point to detailed controls without containing them all. Use reliable references where the acceptance rule or authority needs more explanation.
Validate the relationships with real cases
Bring together people from both sides of significant interfaces. Trace an ordinary case and a relevant exception. Check whether the described input arrives, retains context and supports the next decision.
Disagreement can be informative. A supplying team may regard transmission as completion while the recipient needs confirmation or missing detail. Resolve the operational question using evidence and applicable arrangements.
Do not treat a workshop’s agreed table as proof of implementation. It describes the relationship the team understands; actual work provides evidence of whether it operates.
Use the matrix for changes and review
A proposed process change can affect several recipients. The matrix can help identify who needs to evaluate the impact, which information may change and where controls or measures need adjustment.
A faster local route can remove context needed elsewhere. An automated transfer can preserve values while losing approval or version information. Examine those effects before declaring the change beneficial.
The process owner article explains the need for practical coordination when the relationship crosses line-management boundaries.
Maintain clarity rather than complexity
Assign ownership and review relevant entries when processes, systems or responsibilities change. Remove obsolete assumptions through controlled decisions and preserve necessary context about earlier arrangements.
If users cannot explain the symbols or identify a meaningful recipient need, simplify or revise the matrix. More relationships do not automatically create a better model.
A useful interaction matrix turns a vague claim that everything is connected into identifiable dependencies and management questions. Its value lies in supporting reliable handovers and impact assessment, with actual evidence available to evaluate whether the relationships work.
Where a relationship depends on another system or an external provider, identify the accountable internal contact. A blank organisational boundary should not make the dependency disappear from management. The matrix can point to the relevant arrangement without reproducing all contractual or technical detail.
A matrix used in a change review should identify its version and coverage. Decisions based on an outdated relationship view can miss affected recipients even when the review meeting itself is well organised.