We currently have a Problem-Reason-Resolution structure, with dependencies between the Problem & Resolution picklist fields. Wondering how others are capturing this data in different industries. Combo code list? (I've seen this in the appliance industry)
Hi Dan, we use three fields called Sector, Cause and Action. They are dependent and we have validation rules to ensure they are populated when trying to move a work order status to 'done'. This is based on the order type, so when cancelling its not required.
We have a dependent picklist (3 levels deep, hard to report on what possibilities all exist until they have been used) Problem Found Code - Level 1, 2 and 3 and a separate field Action Taken Code. The Problem Found Code - Level 1 starts with the group of Equipment being serviced (or some general options like Work Not Possible). Level 2 is the area of the Equipment (or further detail for the general options) and Level 3 is down to the kind of Component (or further detail for the general options). Have to be careful that we don't get too many options and selections though.
Example could look like this:
I've seen this solution implemented a couple of ways, one of them is using picklist fields as already mentioned above - this is useful for cases where you have a simple structure.
Another way is creating a custom object, that is a child of the Work Order object and adding the picklist fields to the child object. Then using an SFM on the Work Order screen to add the child object record entry (or entries). This is useful for cases where there are multiple failure reasons on a single Work Order and you are looking to capture all failure reasons.
There isn't one right answer for this, the important thing is to understand the business requirements and implementing the solution that best fits the requirement. Each solution has its pro/con.
I use a custom object which is a child object of the WO. Our tech's enters this detail at the end of their service via an SFM "Close Work Order". I also have a dependent fields set-up, per the example below depending on the "Category" selected, they only have a set of options to choose from, based in the Component selecting, only a specific set of Failure codes apply...these are set-up using Field Dependencies/Controlling fields.
The data from the Custom Object is shown as a Related List on the Work Order as well.
I'd be happy to show you this set-up via a GTM if you're interested.
Question for all on defining the Problem Code (or what prompted the service call). If the Problem code were taken away and replaced with high level categories would you have sufficient detail to properly analyze work orders?
We currently use a simple model where we have a dependent picklist set as follows:
1. Model Code
1.1 Problem Code
1.1.2 Solution code
We have a project in place would remove our current Problem/Solution codes and be reason replaced by Case Codes and WLD codes on parts that were replaced (reason replaced). The Case Codes (transfer to the WO) have a high level category that does not show any malfunctions. So the only thing left would be the descriptions typed in by tech support and Service Engineers on the problem and what they did. Note fields are not really reportable...
I'm thinking I still need the Problem code as a way to define why the Case/WO is opened for break fix calls.
It sounds like you're moving from specific codes with a defined, dependent structure (your current Model-Problem-Solution structure) to an over-arching/general "Case Reason" code to a granular "Part Replaced Reason" code, and then free form text? Is that correct?
Dan Schiess Yes, that's a good summary of the intent. In my mind I think losing the specifics of the reason (failure) we'll lose certain trending data and the ability to point corrective actions back to a problem seen by the customers.
HI John Welisevich, I think you are right there. Maybe making a chart with your business teams of each way of reporting might help to determine which is best for you. Pros and Cons style?
I absolutely agree. By not having the specific reason and failure data, and therefore not able to analyze or pareto, one would not be able to accurately determine root cause and/or prioritize corrective actions. Without that, reports become what we call here a "so what?" report.
Another question to all: how does your company take action on the trend reports built from these codes?
Do they feed back to QA, Engineering, build a knowledge base?
Hi John Welisevich, we have a product lifecycle group who report on these codes and take action in the development of our products based on the feedback. They are also responsible for the codes and changes to them.
Hi @John Welisevich, we have a daily mgmt huddle and the Service portion includes reporting on previous days "exceptions" as well as status/resolution on the prior day's exceptions. Exception criteria was agreed upon by Service, Engineering, and Quality and we have Case/Work Order field logic that will categorize it as an escalation if certain criteria are met. Typically it focuses on New Product/Warranty problems or "fixes" that have been put in place (tracking to make sure the fixes are robust). If further Engineering support is required (like the analysis of a returned defective component), we fill out an ESR (Engineering Support Request) through BP Logix - and this is posted and tracked to root cause/resolution on daily/weekly mgmt huddles. We try our best to align on quality goals across departments, so there is collective "skin in the game" to 1) Accurately define a problem 2) Determine Root Cause(s) 3) Determine Fix & Execute. Very similar to DMAIC methodology.