The higher up you serve clients on the value stream, the more regulatory compliance you need to deal with. There are also more client flowdowns, quality requirements, standards, etc. you need to track, analyze, digest and understand. It can easily add up to many hundreds of pages of documentation – an enormous task to digest what actually matters for the orders you’re processing. It’s important for the organization to research and communicate just the relevant parts of those documents to your team. Without a process for handling all those requirements, things can easily get missed, causing major issues with scrap, rework, rejections from clients, schedule impacts, etc. – all very expensive mistakes that can significantly affect company profitability and unhappy customers. It can get ugly in a hurry! Another byproduct of not having a good system is an overcorrection and well intentioned people spending way too much time reviewing the same documents over and over, trying to ensure things get handled correctly.
Requirements come in from all sorts of different areas including: 1. RFP/RFIs 2. Customer Purchase Orders 3. Drawings/Engineering Data 4. Contracts 5. Regulatory Standards 6. Customer Flowdown Documents
Anytime that a document or requirement is referenced in the course of executing on a scope of work for a customer, it’s essential to distill the requirements down to the most essential things that people must know and understand. And to exclude things that don’t apply. Then, to ensure that solutions for every requirement will be implemented at the point in the process where it makes the most sense.
EXAMPLE The customer drawing that references a workmanship standard document published by the customer such as this:
Note: Surface A is cosmetic per current revision of Acme Workmanship Standard AM-4212 Clause 13.
Of course you need to make sure you always have the latest revision of AM-4212 and ensure it’s available to your staff. However the most effective solution would be to have one person review AM-4212 Clause 13 and summarize the requirements in a very accessible place (like on the drawing, or an attached page) so that other team members can easily see that without having to look up AM-4212 every time they need to confirm how to meet that requirement, such as during planning, programming, in-process inspection, final inspection, etc. The cosmetic requirement should then be added to the inspection plan, and the work instructions that might affect surface A or downstream of it.
Back in our shop, we called this the Requirements Distillation Process (RDP). It was a formal process that happened with every new PN and order we received. While it took a bit of time for each new order, it saved vast amounts of time further down the process, and virtually ensured that we wouldn’t get bit by a requirement that slipped through the cracks. Sometimes a summary was added as a supplementary page to the approved drawing that was easily accessible by everyone, and had ALL and ONLY the pertinent information for the order that was pulled from all the related requirements and documents. It was also important to note that we didn’t summarize requirements that would automatically be handled through our standard procedures. That would be overkill.
Here is a summary of the process we used. Note, we used our Process Development feature to document all the requirements:
1) Establish Requirements:
Review all relevant documents (Customer PO including all referenced documents, Sales Tie-In, WO Notes, Part Notes, Customer Contact page requirements, Statutory and Regulatory requirements, Client Flowdowns) in order to distill each requirement down to a summary of only the pertinent information.
2) Document Requirements:
Note: Documenting requirements is only necessary if items cannot be addressed and completely “Implemented” IMMEDIATELY. If requirement is already documented within the part level itself, Process Development is not required.
List each requirement (1 per row) in the Description box Under Process Development for the part#. Consider adding the Spec # the requirement is from.
List the action that must be taken to ensure there is a plan to deal with this requirement and that the requirement will be verified during the process. When multiple actions are necessary for a given requirement, each action should have its own Solution row.
Resolve with Sales/Estimating any requirement that does not fit the estimate within “reasonable limits” (i.e. extra costs, extra processes, additional resources, etc). Document the action/resolution in the Solution box.
Check off RDP in Section 1 on PP Checklist when all requirements have been Documented.
3) Update the “Process Dev Status” as actions are completed.
Once the Process Development was completed, it was certain that all the requirements would be handled by the right person down the line, and we wouldn’t get bitten by an oversight. It helped us perform at a very high level for our clients such as Northrop Grumman, General Dynamics, Boeing and others. I’m not sure how we could have managed life without it!
How Does ProShop Help?
Besides the aforementioned Process Development feature, it’s very simple to link all required documents in the correct place depending on the type of document. It could be linked to the client record, in the Documents Module, the Standards Module, at the Part Module as an inspection requirement, or any number of other places. Because ProShop was built in a Tier 1 and 2 aerospace and defense contractor, it was essential that we had extremely robust systems for managing the significant complexity of the design engineering and manufacturing processes we engaged in every day!
