Quality Best Practices

Structured Approach to Inventory Scrapping with Integrated Traceability

Objective

Establish a standardized and auditable process for scrapping inventory that ensures operational transparency, traceability, and regulatory compliance.

Strategic Rationale

• Enables data-backed decision-making when scrapping inventory
• Improves end-to-end traceability and accountability across the value chain
• Aligns with compliance mandates and audit-readiness standards

Recommended Workflow

1. Inventory Identification
   • You must first encounter a process in which scrapping is applicable.
   • For example:
     • Cycle count discrepancy
     • Non-conformance management

2. Issue Ticket Creation
   • Avoid ad hoc scrapping; instead, log a structured issue
   • Define a clear rationale (e.g., "damaged components found on floor")
   • Incorporate relevant metadata (e.g., defect codes such as "electrical")

3. Assign Disposition
   • Apply your organizations standardized “Scrapped” disposition category.
     • An automation that allows for this functionality will need to be configured with this same disposition or list of dispositions that are intended to scrap inventory.
   • Specify downstream handling or review protocols (e.g., hazardous waste removal requirements) within the disposition notes

4. Issue Review and Resolution
   • Route the issue through a review and approval gate
   • Upon approval, mark the issue as "Resolved"

5. Automated Inventory Adjustment
   • Leverage automation to reflect scrapped quantity in inventory records
   • Maintain synchronized records of actions taken and materials impacted

Automation Enablement

• Deploy the automation: “Scrap Inventory on Scrapped Disposition” via ION Marketplace in the navigation sidebar. Follow the prompts during setup to specify what dispositions result in scrap inventory.
• Ensures consistency, eliminates manual errors, and maintains a centralized audit trail

Deployment Recommendation

• Ensure clear articulation of scrapping rationale in every issue
• Maintain comprehensive attribute tagging for data segmentation and reporting
• Periodically review automation efficacy and process adherence

Best Practices for Documenting Redline Rationale

Objective

Establish a robust methodology for capturing and surfacing rationale behind procedural redlines to ensure downstream clarity, traceability, and continuous improvement.

Strategic Rationale

• Ensures procedural edits are contextually informed and reviewable
• Supports closed-loop change management by tying redlines to root cause or issue feedback
• Increases visibility and accountability across procedure evolution

Recommended Workflow

1. Option 1: Document Rationale Directly in the Redline
   • Upon creating a redline, embed a clear and concise rationale within the redline itself
   • Enables future users and procedure owners to understand the intent behind the change

2. Link to Issues Where Applicable
   • If the redline resolves a specific issue, associate it with the relevant issue ID or description
   • Ensures direct traceability between operational issues and procedural changes

3. Review Redline History & Merge
   • Once you have approved the redline, use the redline history interface to validate modifications
   • Click “Merge to Procedure” to transfer validated redlines into the procedural draft

4. Validate Integration into Procedure Draft
   • Confirm that merged steps and associated rationale appear in the draft version of the procedure

5. Option 2: Use Procedure Feedback Panel for Additional Context
   • Navigate to the procedure feedback panel to leave contextual comments related to the redline or its impact
   • This feedback becomes visible at the procedure level and includes traceability to the specific step and run

6. Examples of Rationale to Capture
   • Material availability
   • Process instability
   • Safety compliance
   • Training or documentation gaps

Deployment Recommendation

• Mandate rationale documentation for all redline changes
• Regularly review unresolved feedback and related issues prior to procedural release

Associating Inventory To Issues

Overview

When logging issues in the workflow, it’s important to accurately link related parts to maintain clear traceability and context. This section outlines best practices and behaviors within the system when associating parts with an issue.

Logging Issues Against Parts

• Primary Guideline: Always log the issue against the part where the issue was first found.
• These parts appear under the section labeled “Part the issue occurred on,” this section should be used to attach any part inventories that are relevant to the issue.

Adding More Parts

• As the investigation progresses, additional parts may be linked to the same "Part the issue occurred on" field if further discoveries reveal contributing or root causes.
• Best Practice: Capture all parts relevant to the issue — there is no limit to the number of parts that can be added.
• This ensures comprehensive traceability, especially during disposition and root-cause analysis.

Parent/Child Relationships

The system provides enhanced visibility when related parts share a parent/child relationship through their aBOM (assembly Bill of Materials).

Interface Behavior

• When two parts linked in the “Issue was found on part” section are connected via their aBOM:
  • The interface visually distinguishes which part is the parent and which is the child.
  • This helps clarify actions such as:
    • Determining which part requires disassembly from another
    • Identifying which part should be held before proceeding with an integration run

Offending Part Label

• The child part in the parent/child relationship is automatically tagged with an “OP - Offending Part” label when both inventories are associated with the same issue.
• This is a UI-only feature and does not affect or tag inventory in any physical or database sense.
  • For example, if the child part is uninstalled from the parent, the relationship no longer applies and the label is removed.

Installation Context

• Any part attached to the issue displays its installation context if it fulfills an aBOM requirement, providing additional situational awareness.

Flow Diagram

1. We'd recommend creating issues in the following manner for best traceability throughout your production line. This will empower your supply chain and manufacturing teams with the highest quality data to drive change at your organization.

2. You can always understand the history of a part through its transaction history report in the inventory view. This is especially powerful when dealing with issues involving a component removed from an assembly and resolved separately. By following the best practice process outlined above, you can still see the original aBOM that the component was a part of through the transaction history view.

Future Improvements

We recognize that issue-to-part relationships provide valuable context when analyzing and resolving issues. To enhance this, our roadmap includes plans for expanding and formalizing these relationships across the platform and data products in 2026.

Planned relationship types include:

• Found on – where the issue was discovered
• Caused by – part identified as the root cause
• Fixed by – part or action that resolves the issue
• Must contain – dependencies or required relationships

These improvements aim to make relationships more meaningful, searchable, and insightful throughout the system.