There is an issue up for vote this year in my home state of Massachusetts. It’s called “Right to Repair.” The proposed law states that automotive manufacturers can not lock owners and independent repair shops out of vehicles on-board diagnostic computers. These are the arguments on either side of the issue:
Auto manufacturers don’t want independent repair shops completing work on their vehicles with technicians who are not factory trained. They are also concerned about repairs being completed with non-factory parts that could potentially be sub-standard. These manufacturers believe they should have control regarding repairs because they are held responsible when issues occur under warranty. So why is this an issue now?
Many decades ago car warranties often only lasted for half a year. The vehicle hadn’t even gone through an air filter change by the time that period was over. It truly was just a warranty for early quality defects. But as reliability has become more of a competing factor in car sales, manufacturers have had to convince customers that they stand behind their design, not just their manufacturing.
This has resulted in a “commitment to warranty” arms race of sorts between the auto manufacturers. This battle has ratcheted warranties to as high as 10 years/100,000 miles for base model economy cars.
Manufacturers are now warranting vehicles that have gone through many preventative maintenance cycles. Even if they have created a phenomenal reliability program that produced superb maintenance results, they have little control over what actually happens to the vehicle over that decade. That vehicle has most likely been serviced by anyone ranging from the owner whose knowledge may be limited to the content of two Youtube videos, to mechanics of any background. This includes inexperienced mechanics that may be only one year out of school or mechanics close to retirement whose schooling included how to fix an engine hand crank starter.
This is from my personal auto maintenance procedure.
The argument on the other side of the issue is simple. Massachusetts residents who want to protect their “right to repair” feel they have purchased an item,and thus have the right to service it in any way they wish. I don’t really know where I fall between these two camps. As a car owner, I want the right to repair my car the way I like. As an engineer who does detective work with field issues, I don’t want the customer messing up the product. So I empathize with both sides.
So here’s my question for you. How much effort have you put into studying those field issues that ultimately got bucketed as “user error” or “no-fault found?” Yes, we can ultimately clear the names of the innocent, R&D and manufacturing, but this requires a lot of work and doesn’t do anything about the damage done. What damage? Well, the customer doesn’t usually find out that the failure was their fault, and even if they did they would most likely not accept the blame. So we pay out the warranty to keep the peace. In many cases, the most expensive elements are the field investigations themselves. If serious enough these investigations can stall new product programs as technical teams are called back to help with the fires.
Yes, we could just keep on saying “It’s our stupid customers causing these issues.” But does that make us competitive?
Simply put, for many product lines, it is worth studying these user error issues and seeing how we can mitigate or prevent them from ever happening in the first place. It might not be as aggressive as locking customers completely out of interfacing with our products in any manner other than basic use, however there are other strategies.
One strategy is to just reduce the number of times anyone is interacting with the product. In other words, simply change the design requirements to drive for less maintenance. With many products, we often use a strategy of preventative maintenance as a quick fix to a feature that can’t make full use of life. Developing longer lasting features adds time to the product development schedule, R&D cost, and the product bottom line. But are we measuring that added cost correctly? Does it include the increase in cost and loss of time from investigating and solving field issues that are driven by poor or even missed preventative maintenance?
Another alternative strategy is to design our product with ease of maintenance as a requirement. This may improve the ease of access to maintenance areas. Sometimes it’s as simple as creating a design that requires fewer tools and less knowledge to service. This strategy can also result in making modular maintenance systems. The desktop printer, for example, doesn’t require an individual to pick up tools or poor ink into cassettes. It’s designed so that any individual can walk up to it, untrained, and pop a lever to remove the entire sub-system. The new one pops right in the same place and they are back up and running in 60 seconds.
I highly encourage taking a moment early in the product program to truly evaluate what your PM goals and strategy should be. But don’t just cut and paste the old requirements. Complete a comprehensive analysis of field issues related to maintenance before creating a new PM strategy. Then create program and product requirements that reflect the significance of the real cost of user and maintenance-driven failures.
-Adam
Brian Thiel says
This affects off-road as well. An example that has shown up in several reports is that John Deere requires the use of their proprietary service tool (ie laptop with JD software) to diagnose and replace many critical parts. This can incur a significant financial hardship in lost productivity and shipping costs if the equipment breaks down during harvest and has to be hauled back to the dealer. And they are using copyright protection law to justify their stance.
In my opinion there is a middle ground that can satisfy many customers while also securing repair work for service centers and discouraging pirate software. In the current climate this benefit may also drive customer buying decisions! But to do this successfully it needs to be considered early in the design program.
ISZ