How do we identify all relevant processes in our organization?

In regulated industrial environments, you will not get a complete list of relevant processes from any single source. You need a structured, cross-functional approach that triangulates between systems, people, and actual shop-floor behavior.

1. Start from obligations and outcomes, not just org charts

Identify which processes matter by asking two questions:

• What are we obligated to do? Review contracts, quality manuals, customer requirements, and regulatory standards (e.g. AS9100, AS9102, internal QMS procedures). Each requirement implies processes that must exist, be controlled, and be auditable.
• What outcomes must we reliably achieve? On-time delivery, conformance to spec, traceability, configuration control, data integrity, cybersecurity, and safe operation. Any repeatable set of activities that materially affects these outcomes should be treated as a process, even if it is informal today.

This top-down lens helps you identify which parts of the organization you cannot afford to leave as “tribal” or undocumented.

2. Build a high-level process architecture

Create a simple, end-to-end view before diving into details. Typical categories for an aerospace or similar regulated manufacturer include:

• Core value stream processes: order capture, design/engineering, planning, procurement, manufacturing, inspection, test, packaging, shipping, maintenance/overhaul, and returns/repair.
• Supporting operational processes: document control, training and qualification, tooling and gaging management, calibration, production scheduling, inventory management, IT/OT support.
• Quality and compliance processes: FAI/AS9102, in-process inspection, final inspection, nonconformance management, MRB, CAPA, internal audits, supplier quality management.
• Management and improvement processes: management review, risk assessment, KPI review, continuous improvement, change control.

This architecture will be imperfect, but it gives you a framework to slot in detailed processes later and to see where you may be missing entire classes of activity.

3. Use existing systems as partial process maps

In brownfield environments, some processes are embedded in legacy systems, while others live on paper or in people’s heads. Use each major system as a clue, not a source of truth:

• ERP: order-to-cash, purchasing, inventory movements, MRP, cost tracking. Each major transaction type usually corresponds to a process (e.g. PO creation, receiving, WIP completion, shipping).
• MES / travelers: routing, operation sequences, data collection points, rework flows, holds. Operations that appear repeatedly across routings are processes to document and standardize.
• PLM / PDM: engineering release, BOM management, ECN/ECO workflows, configuration management.
• QMS: nonconformance, CAPA, audit, training, document control workflows. Each template or form often represents a missing or incomplete process description.
• Other tools: maintenance systems, calibration databases, supplier portals, MRO/field-service tools.

Expect gaps: many critical activities, especially handoffs and checks, occur outside these systems via email, spreadsheets, and informal approvals.

4. Walk the floor and follow a real job end to end

System maps are not enough. To uncover actual processes, select a representative work order or repair and:

• Follow it from order entry through shipment (or tear-down through re-delivery in MRO).
• Observe where work pauses, waits for decisions, uses manual logs, or depends on a specific person’s knowledge.
• Note any deviations from documented procedures: alternate paths, workarounds, and side agreements with customers or suppliers.

Every repeatable activity you see that affects quality, cost, delivery, safety, or compliance is a candidate process. Many of these steps will never appear explicitly in ERP/MES but still need to be identified and controlled.

5. Run cross-functional process discovery sessions

Bring together people from operations, quality, engineering, supply chain, IT, and maintenance to review your draft process list:

• Validate the architecture: Ask, “What do we actually do that is not on this list, but if it stopped tomorrow, we would fail an audit, delay shipments, or ship nonconforming product?”
• Surface shadow processes: Excel trackers, shared drive checklists, informal sign-offs, ad-hoc inspection steps, manual label creation, tribal troubleshooting sequences.
• Clarify ownership: Identify a process owner for each major process, even if today it is fragmented.

Be explicit that the goal is not blame or standardization yet, but visibility. Otherwise people will conceal workarounds that are critical to meeting today’s commitments.

6. Prioritize what “relevant” means for your context

In a regulated environment you cannot fully ignore low-impact processes, but you can phase your effort. A practical definition of “relevant” usually includes processes that:

• Directly affect product conformity or airworthiness,
• Impact traceability, genealogy, or configuration control,
• Are required or referenced in your QMS, contracts, or customer supplements,
• Introduce significant risk if they fail (safety, regulatory exposure, major delivery impact), or
• Control core data flows between ERP, MES, PLM, QMS, or external partners.

Start by classifying processes into tiers (e.g. critical, important, supporting). Focus documentation and improvement first on the critical and important tiers, while still logging the rest for future work.

7. Explicitly map brownfield integration and handoffs

Many of the most consequential “processes” are actually handoffs across systems or organizations, for example:

• Engineering releasing revisions in PLM that must be reflected correctly in ERP routings and MES travelers.
• Supplier inspection data or AS9102 packages feeding into receiving and source inspection.
• Nonconformance raised in MES being resolved through QMS and then reflected in updated standard work or part programs.

These cross-system flows are often undocumented and depend on people remembering which files to update or which emails to send. Treat them as processes in their own right, with clear triggers, inputs, outputs, and owners.

8. Expect iteration and incomplete coverage at first

It is unrealistic to “identify all processes” in one pass, especially in multi-plant or multi-program organizations with long equipment lifecycles. Common constraints and failure modes include:

• Legacy equipment and software that cannot easily be instrumented, so parts of the process remain opaque.
• Inconsistent documentation maturity across sites or programs, leaving some processes implicit.
• Integration debt where data is manually re-entered, masking hidden subprocesses and rework loops.
• Change fatigue that makes teams reluctant to surface unofficial but essential steps.

Plan for a living process inventory that is refined as you implement changes, digitize steps, or prepare for audits, rather than assuming a one-time exhaustive mapping.

9. Link process identification to validation and change control

In regulated and aerospace-grade environments, each identified process has implications for validation and change control:

• If a process is critical to quality or compliance, future changes may require formal validation, documented risk assessment, and controlled rollout.
• Processes tightly coupled to equipment or software with long lifecycles will be harder to change, increasing the importance of accurately identifying them upfront.
• Recognizing the full process (including manual and workaround steps) avoids surprise validation scope when you later upgrade ERP/MES/PLM or introduce new tooling.

This is also why full “rip-and-replace” of systems often fails: unrecognized processes and hidden dependencies surface late, making downtime, requalification, and retraining more disruptive than planned. Having a robust process inventory reduces that risk.

10. Minimal practical approach you can start this quarter

If you need a concrete starting plan:

1. Define scope: Pick one value stream (e.g. a product family or MRO line) instead of the entire enterprise.
2. Draft an end-to-end map of that value stream using existing procedures, travelers, and system flows.
3. Walk two or three real jobs through that value stream and document every distinct, repeatable activity.
4. Run a cross-functional review to validate and add missing activities, especially at handoffs and exception paths.
5. Classify and prioritize processes into critical / important / supporting, and assign clear owners for the critical set.
6. Create and maintain a process inventory (even a spreadsheet) listing name, owner, systems used, and criticality. Use this as a baseline for audits, improvement, and future digital projects.

Over time, extend this approach to adjacent value streams and shared support processes. The goal is not perfection but a traceable, defensible understanding of how work actually gets done in your environment.