ANONYMIZED CASE · CPG
Every change knows what it touches: applications, processes, risks and controls
A leading mass consumer goods organization validated an impact-analysis layer over its operational graph, connecting each change with applications, processes, data, integrations, risks, controls and vendors before approving and executing it.
The validation made it possible to move from decisions based on forms, meetings and manual context reconstruction to decisions backed by traceable evidence and operational context.
The challenge
In mass consumer goods organizations with multiple plants, applications, vendors and critical processes, a change can affect more than what shows up on a form. The problem isn't recording the change: it's understanding what it touches before approving it —which applications are involved, which processes depend on them, which integrations are affected, which risks are triggered and which controls must be reviewed. When that context is reconstructed in meetings, spreadsheets or cross-team conversations, the decision arrives late and traceability stays incomplete.
- Changes are approved without a shared view of what they touch: an application, its interfaces, the processes that depend on it, the risks triggered and the controls to review.
- Impact is estimated by declared urgency, not by the real reach over connected applications, processes and integrations.
- Architecture context —applications, processes, capabilities, vendors, risks, controls— does not live in the system where the change is approved.
- Decision evidence is reassembled before each audit: who approved, with what quorum, what was analyzed and what was concluded.
Change governance is not sustained by an approval form. It is sustained by traceable impact analysis over the applications, processes, data, integrations, risks, controls and vendors a change actually affects.
The EAFlow solution
The solution operated as a cross-cutting impact-analysis layer over the Operational Graph, connecting change requests with the business and technology context they could affect. Instead of evaluating each change as an isolated form, the team could review relationships between applications, processes, data, integrations, risks, controls, vendors and owners. The scope did not replace existing change-management tools: EAFlow acted as a layer of context, traceability and analysis to improve decision quality.
- Every change connected to what it touches. A change request triggers impact analysis over the graph: affected applications, inbound and outbound interfaces, processes, data, risks, controls, vendor and history —in a single read, not in meetings or spreadsheets.
- Configurable impact analysis. The scope and depth of the graph traversal (direct, transitive or full) and the scoring weights adjust per organization, without redeployment.
- Traceable change-governance cycle with cataloged states, transitions, types and scopes, signed by the correct role, with activity traceability.
- Change committee with governed quorum: votes advance the state on reaching the threshold, with an auditable record of each decision.
- Post-implementation review: root cause and lessons learned with corrective and preventive actions, connected to the change that originated them.
- Governed evidence and attachments with antivirus scanning, categories, versioning and traceability, retrievable without manual reconstruction.
- Change reporting: cycle times, compliance by state, rejection and rollback rates, and most-affected applications.
Scope connects to the graph by agreed discovery scope. The impact-analysis layer operates on top of the operational context, without replacing existing change-management tools.
What was validated
The engagement validated the ability to analyze changes over an operational graph, connecting entities that are normally reviewed separately: applications, processes, data, integrations, risks, controls, vendors and owners. The goal was to verify whether a change's impact could be assessed before approving it, with a shared view for architecture, operations, risk and governance teams.
Demonstrated capabilities
- Operational Graph as a shared context base.
- Impact analysis over applications, processes, data, integrations, risks and controls.
- Impact traversal configurable to the scope of the change.
- Change-governance cycle with states, owners and traceability.
- Querying change context without manual reconstruction.
- Reporting for review, approval and follow-up.
Observed outcome
The organization could move from explaining changes with forms and scattered conversations to reviewing them over a connected operational context.
The validation confirmed that a change can be assessed not only by its declared urgency, but by the impact it generates over applications, processes, integrations, risks, controls and owners.
The observed value was reducing pre-approval uncertainty and leaving a traceable basis to explain why a change was advanced, adjusted or postponed.
Why it matters for other organizations
The pattern repeats in organizations that have matured their IT management: the change process exists, but the change is approved without context. Connecting each change to the applications, processes, data, integrations, risks and controls it touches —without replacing existing tools— reduces the risk of approving blind and turns audit evidence into a continuous state.
Starting with change-impact analysis is also a low-risk entry point: the same Operational Graph that sustains impact later sustains processes, risk and service operations.
How it scales — related solutions
The analyzed change impact is reused over the same Operational Graph:
- Toward processes Process Knowledge
A change is assessed against the modernized process corpus; a change shows which processes and documents get updated.
- Toward the inventory Live IT Inventory
The applications, integrations and vendors a change touches connect to the portfolio catalog.
- Toward risk and control Risk & Control Assurance
Impact on risks and controls is no longer estimated by hand; it is assessed over the graph.
- Toward service operations Operational Graph for Service Operations
An incident can escalate to a change with traceability, and the change knows the business capability it affects.