This document is intended for authorized Exepron Account Uses only and cannot be distributed or reproduced without the written consent of Dux Global, Inc. and Exepron. ©Copyright Exepron. All Rights Reserved.

Reason Codes

Add custom Reason Codes Account in Settings. #

Optional:  Select a Color for a Reason Code. 
Default:  All Users have access by default. Report, Print, Email and Permissions for adding, editing and deleting Reason Codes in Settings/Reason Codes and Task Details/Reason Codes will be added in a future release. 

Reason Codes can be added to a Task in the “Task Details/Reason Codes” tab. 
Optional:  in addition to adding a Reason Code, Users can add a Secondary Reason Code and/or a Note to display in the Task Details/Reason Codes tab. 

Status of the Reason Code #

Add a Date for the Status Change:

  • Active = Recorded but not resolved;
  • Fixed = Permanently Resolved;
  • Improved = not fully resolved but improved;
  • Urgent = Causing significant damage and needs immediate Attention.

 

The Status, Pareto Chart Summary, and the new status and Date will appear in the Portfolio Dashboard / Reports / Reason Code Report.

 

 

Reason Codes: Primary and Secondary (RC’s) #

Why are there two Reason Codes (RCs) levels – A Primary and Secondary RC list?
RCs are just the beginning of investigating the reasons for delays and disruptions in the workflow. The primary RC provides a ‘rough cut’ direction of analysis, a category of delays.  A deeper analysis of the reason codes is often required to focus attention. Exepron provides a deeper analytical data field, the Secondary Reason Code.

 

Understanding the reasons behind delays is crucial in Engineering, production, or installation services. To facilitate a more comprehensive analysis, our application has introduced a two-tiered Reason Codes (RCs) system: Primary and Secondary.

– Primary Reason Code (Primary RC): This serves as the initial layer of analysis. This broadly categorizes the delay, giving users a general direction for their investigation.

– Secondary Reason Code (Secondary RC): For a more in-depth understanding, the Secondary RC dives deeper into the specifics of the delay. It is a subset to the primary reason, offering a more granular view of the disruption.

Why Use Both Primary and Secondary RCs?

While the Primary RC offers a snapshot of the delay category, it often lacks the detail necessary for a thorough analysis. The Secondary RC fills this gap, allowing users to pinpoint the exact cause of the delay. This dual system ensures that while the primary reason gives a broader perspective, the secondary reason provides the specifics, ensuring a deeper understanding of the delay.

Examples of Primary and Secondary RCs in Action #

Contracted Services:

Primary RC: “Subcontractor Delay”: This generalizes that a subcontractor caused the delay. However, it doesn’t specify which subcontractor was responsible.

Secondary RC: “Billy’s Roofing Services”: Using the Secondary RC, we can determine that “Billy’s Roofing Services” was the subcontractor most frequently associated with delays. This level of detail is invaluable for addressing specific issues and streamlining operations.

Sales Engineering:

Reason Codes (RC) Reference Guide: Using Primary and Secondary Features in Sales Engineering, understanding the reasons behind delays is crucial for ensuring timely project deliveries and client satisfaction. Exepron’s two-tiered system of Reason Codes (RCs) – Primary and Secondary, is designed to provide a comprehensive analysis of such delays.

Example of Sales Engineering Delays Using Primary and Secondary RCs

Primary RC: “Technical Specification Mismatch”: This indicates a discrepancy between the client’s requirements and the technical specifications provided. However, it doesn’t specify the nature or source of the mismatch.

Possible Secondary RCs: 

1. “Client Requirement Changes”

2. “Incomplete Initial Requirement Gathering”

3. “Client not understanding the full required scope”

4. “Miscommunication Between Sales and Engineering Teams”

5. “Updated Product Version Mismatch”

By employing the Secondary RC, we can discern that the delay might have been due to frequent changes in client requirements or a gap in the initial requirement-gathering phase. It could also result from miscommunication between the sales and engineering teams or an inconsistency with an updated product version. This detailed insight is crucial for rectifying specific issues and ensuring smoother operations in the future. Significant lost or misused Capacity can be greater than 50 %, resulting in a 50 % increase in production cost and uncompetitive lead times.

Recommendations for Sales Engineering Teams:

1. Ensure clear communication channels between the sales and engineering teams to minimize specification mismatches.

2. Regularly update technical documentation to reflect the latest product versions and specifications.

3. Conduct thorough requirement-gathering sessions with clients to capture all necessary details.

4. Monitor and update both Primary and Secondary RC lists to ensure they cater to the unique challenges of Sales Engineering.

Conclusion

The dual Reason Code system, with both Primary and Secondary RCs, ensures that users understand the reasons behind delays. By using both codes in tandem, organizations can identify the broader categories of disruptions and delve into the specifics, leading to more effective problem-solving and operational efficiency.

Recommendations for Users #

1. Always start with the Primary RC to get a general understanding of the delay.

2. Utilize the Secondary RC to get a detailed insight into the cause.

3. Review and update both RC lists to remain relevant and comprehensive.

End of Document.

 

What are your Thoughts?
Updated on November 6, 2023