Often we live with a problem until we can implement what we perceive is the full solution – No Half Measures Allowed! If you examine the problem closer, half measures may be all that is required. The following half measure eliminated a problem that plagued a company for years.
My department created applications for automating machines. These machines could be 25-50 years old and made productive with our automated control system. We created applications on continuous bases. Some shipped every year and others could be a onetime deal. Some repeat orders were years apart. There was no way to tell if we would ever have a repeat order until it arrived.
We never built prototypes except for new designs (vs. applications). The applications were created primarily from field surveys. Obtaining accurate measurements during machine downtime was a difficult task. The field engineers often had to make modification on site during installation.
We ran a lean shop and the design engineers released one application after another. Engineers either were in the field doing a survey or at their CAD station creating a new application. There were always orders for new applications and management did not want the field fixes incorporated at the expense of new work. "We may never get another order."
We had a system for filing modifications made in the field but no method to retrieve them when a repeat order arrived. As you may have guessed, 1 to 5 years later the same stuff would go out with the same problems.
Orders for new applications automatically came to Engineering. Repeat orders were placed into the MRP system by Operations who knew with amazing accuracy, which was the correct product. The problem was the product was not always correct. Though, I had no role in Operations all eyes turned to me when field modifications were required - so I made myself responsible.
When a design experienced problems instead of filing the markups as was done for years, I would review the field reports and create a set of detailed notes that described the problem and the preferred Engineering solution vs. the field fix. My written directions were filed with notes from the field engineers. How to remember to make the corrections the next time the application was ordered was still an open question. I was not familiar with the MRP system but others were. I told them what I wanted to accomplish and they found a method for flagging existing applications that required modification.
When an application experienced an installation problem Engineering notified Operations. Within the MRP system, Operations would set an attribute, which prevented the application from being placed into the production schedule. No one had to rely on memory. When an order arrived for a flagged application, Operations would inform Engineering. The new order provided justification for work added to the Engineering schedule. Until Engineering released the revised drawings, the application was not loaded into the MRP schedule.
Creating the notes and directions when the problem was fresh was simple and fast. The notes and directions were clear instructions the design engineer could follow. The work proceeded faster because the design engineer no longer had to play detective trying to interpret 3-year-old drawing markups from the field engineers. Management was satisfied. Resources used efficiently and repeat errors eliminated.
This relatively simple and nearly zero-cost half-measure (closer to 1/20 measure) appears so obvious in retrospect but alluded the company for several years. Management only thought of the time to do the entire incorporation real time. Rethinking the situation allowed a very small expenditure of resources to avoid repeating very costly field modifications.
My department created applications for automating machines. These machines could be 25-50 years old and made productive with our automated control system. We created applications on continuous bases. Some shipped every year and others could be a onetime deal. Some repeat orders were years apart. There was no way to tell if we would ever have a repeat order until it arrived.
We never built prototypes except for new designs (vs. applications). The applications were created primarily from field surveys. Obtaining accurate measurements during machine downtime was a difficult task. The field engineers often had to make modification on site during installation.
We ran a lean shop and the design engineers released one application after another. Engineers either were in the field doing a survey or at their CAD station creating a new application. There were always orders for new applications and management did not want the field fixes incorporated at the expense of new work. "We may never get another order."
We had a system for filing modifications made in the field but no method to retrieve them when a repeat order arrived. As you may have guessed, 1 to 5 years later the same stuff would go out with the same problems.
Orders for new applications automatically came to Engineering. Repeat orders were placed into the MRP system by Operations who knew with amazing accuracy, which was the correct product. The problem was the product was not always correct. Though, I had no role in Operations all eyes turned to me when field modifications were required - so I made myself responsible.
When a design experienced problems instead of filing the markups as was done for years, I would review the field reports and create a set of detailed notes that described the problem and the preferred Engineering solution vs. the field fix. My written directions were filed with notes from the field engineers. How to remember to make the corrections the next time the application was ordered was still an open question. I was not familiar with the MRP system but others were. I told them what I wanted to accomplish and they found a method for flagging existing applications that required modification.
When an application experienced an installation problem Engineering notified Operations. Within the MRP system, Operations would set an attribute, which prevented the application from being placed into the production schedule. No one had to rely on memory. When an order arrived for a flagged application, Operations would inform Engineering. The new order provided justification for work added to the Engineering schedule. Until Engineering released the revised drawings, the application was not loaded into the MRP schedule.
Creating the notes and directions when the problem was fresh was simple and fast. The notes and directions were clear instructions the design engineer could follow. The work proceeded faster because the design engineer no longer had to play detective trying to interpret 3-year-old drawing markups from the field engineers. Management was satisfied. Resources used efficiently and repeat errors eliminated.
This relatively simple and nearly zero-cost half-measure (closer to 1/20 measure) appears so obvious in retrospect but alluded the company for several years. Management only thought of the time to do the entire incorporation real time. Rethinking the situation allowed a very small expenditure of resources to avoid repeating very costly field modifications.