The Accidental Warranty Software Developer:
Manufacturers pressure an electronics testing software vendor to do more to help them avoid warranty costs. As has happened to so many others, they find themselves pulled into an industry they barely noticed was there all along.
It's a story told time and time again in the warranty industry. A company considers itself to be in one corner of the software business, but its customers pull it into the business of avoiding, analyzing, or processing warranty claims. Since the customer is always right, manufacturing software developers instantly find themselves becoming warranty software developers.
The latest to tell this story is Cimtek, a Canadian company with offices in the U.S. and UK. On its Web site, the company describes itself as "the leader in cost reductions through innovative test and design for electronics manufacturers." The key part of that statement of course is cost reduction.
Warranty Week has estimated that warranty expenses are costing U.S.-based manufacturers at least $25 billion a year. For the great majority of manufacturers, warranty costs consume anywhere from 1% to 4% of product revenue. So there's plenty of cost out there to reduce. A certain amount of warranty cost is inevitable -- perhaps even desirable? Several manufacturers have said that customer loyalty actually increases after a successful break/fix episode, above and beyond where it might be were the product to never fail. But most would agree that while standing behind your product with a warranty is a good idea, too much of even a good thing can be bad.
Learning from Warranty Claims
Inevitably, any company that helps its customers reduce the cost of manufacturing finds itself in the warranty business. Warranty costs arise because a company has allowed products containing defects to go to market. If those products are repaired or replaced under warranty, then the manufacturer has a cost. But what if that manufacturer also looks upon a warranty event as a learning experience? What went wrong, and how can it be prevented from happening again?
"The reason they tested the module in the first place was because they didn't want the cost of a failure," Pattenden said. "Our customers' problem is they have a cost of non-performing products. That can range all the way from low yields if they catch it, to warranty costs if they don't."
Sometimes, customers buy a testing suite that does exactly what they want it to do, but still some defects get through to market. The problem isn't the testing software; it's the tests themselves. Products can easily be within spec but still fail. Sometimes it's the interaction of two components, and other times it's environmental conditions. Perhaps the product works fine at the factory but it's shaken around so much in transit that it doesn't work for the consumer. Or perhaps it fails only after it heats up during first use. It's not so much that the answers are wrong as it is that the questions are.
"Some of our customers actually have come to us and said the reason we want you guys to get involved with us is because we did it wrong the first time," Pattenden said, "and we had hundreds of millions of dollars of warranty cost as a result." Cimtek clients include huge manufacturers such as Delphi, Siemens, Visteon, and Saturn Electronics, among others, so warranty events with seven or eight zeros attached are not inconceivable.
Still, Pattenden said he isn't too comfortable being labeled as a warranty software vendor. "Our business is not warranty software," he said. "Our business is test equipment for electronic components and modules." In the past, Cimtek had a very technical approach -- they tested their clients' systems and helped them remove the rejects from production. But now, they're finding more and more often that customers don't want them to stop there.
"We're in the overall cost reduction business," he said. "If they have a warranty issue, that's a big cost, and we can work on that as a subset. But the real issue is how do I minimize my product costs? We see warranty as a subset of the cost of doing business inefficiently."
Of course, it doesn't stop there. When the inevitable warranty claims come in, a company should be in a position to understand what went wrong, and how it happened. That data needs to get from the warranty claims processing center to the engineering, design, and production people who can do something about it. Since Cimtek testing software does nothing in the way of warranty claims processing, anything its customers demand in this area will have to be provided through partnerships.
The Accidental Warranty Vendor
A year ago, Warranty Week began writing about these "accidental" warranty software vendors who started out doing something else and ended up smack in the middle of the warranty industry. In the July 21, 2003 issue, the topic was PolyVista Inc. and how its pattern analysis software started out analyzing supermarket purchases and ended up performing failure analysis for Compaq Computer, later to become the core of the Personal Systems Group of Hewlett-Packard Co.
Initially, PolyVista didn't even approach Compaq with a warranty solution. That wasn't their business at the time. PolyVista's first meeting with the potential client in 2001 was to discuss a customer satisfaction data analysis bid. They started looking at call center records, and then at warranty claims data. Then they started working on creating a dashboard-concept control panel for Compaq executives who needed an instant view of where things stood in the realm of customer care.
Bob Ford, PolyVista's vice president of technology services, began giving tutorials to some of the people at Compaq who'd eventually be using the dashboard. At one session, he noted that the PolyVista software had found an interesting pattern in the warranty data. In one unit, 80% of the time a modem was replaced, so was the keyboard. However, only 30% of the keyboard replacements also involved the modem. How strange.
An engineer in the room said it was obvious that the unit was a laptop, and that therefore the modem was probably under the keyboard. He suspected that the technicians were breaking the keyboards while trying to get to the modem. Some others investigated and found that one particular service provider was doing much of the damage. So they changed the keyboard mounts and sent out some instructions on how to remove the keyboards without breaking them. Suddenly, PolyVista found itself in the warranty cost avoidance business.
A week later, in the July 28, 2003 issue, we featured an article about NinaTek Inc., a company whose purpose was to provide software to engineers that allowed them to access and analyze warranty data. Interestingly, NinaTek's software didn't actually process warranty claims, and NinaTek didn't want to partner with anyone who provided the processing software. All they wanted was access to the claims data after the fact.
Cimtek, on the other hand, wants to be able to go into its electronics accounts and tell them it can reach into both ends of their warranty chains. It wants to be able to help OEMs figure out which component suppliers and/or contract manufacturers are producing the defects, and it wants to be able to help them look for patterns in the warranty claims data coming in from the distribution channel. Plus, it wants to put that analysis to work, using it to suggest better ways to manufacture, assemble, and ship products so they fail less often in the hands of the consumer.
To do this, Cimtek will want to link up with some companies that most definitely call themselves warranty software vendors. The company doesn't want to write all new software. It simply wants to put existing pieces together in a way that builds bridges between the data held by the warranty, production, engineering, and supply chain departments.
Pattenden came all the way from Toronto to New York City to meet with Warranty Week to ask a simple question: who should they be working with? We gave him a short list of companies to contact, and indeed some of those initial meetings have already taken place. But surely the list must be longer than a few names. Who else out there is in a position to plug their warranty software into a non-warranty module in a way that allows the production people to look at failure data both before and after sale? Readers should contact either the editor or Ted Pattenden directly.