Warranty Search Application:
Endeca Technologies is promoting a new approach to warranty analytics that allows users to take unscripted journeys through their claims data, asking questions they hadn't anticipated and looking for patterns and anomalies they didn't know were there.
Next year, the Warranty Chain Management Conference returns to San Diego, and we already know who the keynote speaker will be.
Paul Sonderegger, chief strategist at Endeca Technologies Inc., spoke on a panel at this year's event in Los Angeles about "Improving Warranty Revenue & Competitive Advantage." And the reception was so strong, and the feedback was so positive, that he was asked to come back again next year.
"I'm delighted to do it," Sonderegger told Warranty Week by phone this week. Endeca has focused on warranty for only the past three of its 11 years in business, so it's gratifying to receive such a strong endorsement from the industry at this early stage, he said.
"I was optimistic that I would find a warm reception at the conference, but I certainly didn�t expect to be invited to give the keynote next year," he said. "It was a delightful surprise and I�m really looking forward to it."
Strong Positive Reaction
It's not the first time, however, that Endeca's search and discovery products have engendered such a strong response from warranty professionals. Sonderegger said that he has seen Endeca's customers discovering connections in their warranty claims and supplier data, even at an early stage in the sales cycle. "These weren�t even production deployments, and they were already answering questions they couldn�t before," he said.
So this week, we talked with him again, asking him to drill a little deeper into the technology behind the concepts he outlined in Los Angeles. Basically, what he's suggesting is a new approach to root cause analysis that allows non-IT people to go on unscripted explorations of their data to find unexpected patterns that they didn't know were there.
"The larger picture, and the thing that I talked about at the conference, is this idea of discretion as a competitive advantage," Sonderegger said. If everyone else is doing something the same way, then whoever finds a way to do it better, faster, cheaper, etc. has gained a competitive advantage.
The history of IT has revolved around the automation of processes, aimed at cutting costs, raising efficiency, and boosting productivity. "However, it came at a price," Sonderegger said. Most large companies implemented the same software as their competitors, in pretty much the same way. "As a result, while they became more productive, and achieved greater operational effectiveness in those processes, they also became more like their rivals," he said.
Now, they're looking for ways to use software to support their competitive strategy, and to differentiate themselves from their rivals. Sonderegger calls this "improving discretion."
Mapping New York City
In his charismatic presentation at the Warranty Chain Management Conference earlier this month, Sonderegger began with an analogy that looked at the early history of the street layout in New York City. In the colonial era, he said, the city was concentrated on the southern tip of Manhattan Island, and the roads were laid out a bit haphazardly.
New Amsterdam in 1660
Source: New York Historical Society
But then on March 22, 1811, the city filed a plan that laid out a grid system of streets and avenues that continues to be used to this day. A series of 12 avenues were to be laid across the island in a north-south direction, to be crossed by a series of 155 streets running from east to west.
"At the time, nobody knew if this was going to be a good idea or not," Sonderegger noted. "But within two years, they had their answer. It was a stroke of genius that made repurposing the land on Manhattan so much easier -- to sell, to buy, and to develop."
New York City Plan of 1811
Source: Cornell University
The grid plan took note of the commercial patterns of the age. For instance, it placed the avenues closer together near the docks, to increase the availability of street frontage in those neighborhoods. And it made most of the streets and avenues intersect at right angles, because that would make the plots of land rectangular, and rectangular buildings were cheaper to build.
But it also created a rigid structure that left little room for deviation. Every avenue was going to be 100 feet wide, every street was going to be numbered consecutively from 1st to 155th, and every block between the streets was going to be exactly 200 feet wide. Any deviations from the plan required the approval of the state legislature (one major deviation, the addition of Central Park, came in 1853).
Sonderegger said such a high degree of rigidity was fine 200 years ago when the commodity being organized was land. But it's not good now when the commodity being organized is information, and when the principles that are still being used to organize that information were developed 40 years ago. Back then, storage and processing power were scarce and expensive. Now they're not.
"One of the struggles that we have in repurposing information, to answer questions that we did not know ahead of time would matter -- one of the primary obstacles to that is the cost of repurposing information, because it's held in a rigid grid," he said, "which was a great idea for land in Manhattan, but cuts against the grain of the nature of information."
There's always going to be a bit of a tradeoff between standardization and discretion, Sonderegger said. Standardization provides a predictable and routine way to perform a task, while discretion allows for a more spontaneous journey. Standardization provides tools to execute tasks, while discretion provides the tools for exploration. And discretion cannot be automated.
Standardization vs. Discretion
Source: Endeca Technologies
"It's not that one is bad and one is good," Sonderegger added. "They're both absolutely necessary. They just create different kinds of value. So they're fully complementary."
Endeca Technologies, he said, is focused on improving discretion, or as he says it, "We're improving discovery in daily decision making." In contrast, traditional business intelligence systems are focused primarily on the provision of standard reports, analytics and dashboard views, he added.
"Those are great for answering the questions you knew to ask," Sonderegger said. "But then something changes. A competitor comes out with a new product. Or you find out that claims on a particular product line jumped in a certain month in a way that you didn't expect. Or you change suppliers, and find out that quality starts to drop.
"Now you have a whole new set of questions that you need to ask: Why did quality drop? Why did the warranty claims go up? Could there be a root cause in all of this? And these are questions that you didn't know would matter," he said.
Endeca is focused on helping the non-IT expert answer questions like these, using data that was organized by others, for other purposes. "This is what we mean when we say that we're focusing on this whole problem of answering the questions you didn't know would matter," Sonderegger said. "There is a whole set of established technology out there -- from business intelligence to analytical applications with reports on top -- that are all about answering the questions you knew to ask."
Back in the 1970s, when relational databases were first created, there wasn't as much data as there is now, nor as much processing power available to interpret it. And it took a very skilled person to organize the data in an optimum way and to generate the reports that answered specific questions.
Now, there's enough processing power to break documents, records and databases down into their smallest units, and allow them to be analyzed in completely unscripted ways by completely unskilled people. It's the Google effect: type a few words into the search engine and see what it matches.
Endeca in Action
David Caruso, Endeca's vice president of enterprise applications, said that in some of the larger organizations he's seen, it's not uncommon to find multiple SAP or Oracle systems used by different locations and divisions, in addition to numerous custom, purpose-built systems that run locally. It makes warranty analysis an incredibly complex task.
"In our software, [we're trying to] bring together all of these disparate information sources," Caruso said, including text documents, distribution and inventory management systems, process control systems, quality management systems, planning systems, and purchasing/sourcing systems. "Now, as we get that data, we start to find more and more open-ended questions, or as I call them, unframed questions," he said.
In other words, an engineer or a quality manager might want to figure out the root cause of a pattern of failure, but doesn't know which questions to ask or where to look. But they want to be able to discover the root cause without having to form a task force, or perhaps without even having to leave their desk.
Using NHTSA Claims Data
Caruso demonstrated the process built into products such as Endeca's Discovery for Warranty and Support search application. It supports the decision-making process through quick access to all data sources and data types -- structured and unstructured -- by unifying data from multiple sources within a simplified user interface.
He used warranty data compiled by the National Highway Traffic Safety Administration to show how an engineer or a warranty manager could discover the root cause behind a rash of battery failures and replacements in 2006.
First, he found that the batteries were manufactured by two different suppliers. Second, he found that the 2006 tag referred to the production year for the batteries, rather than the year the claims were filed or the model year of the vehicles. Third, he found that while some of the claims were labeled "electrical," others were labeled "electrical system." So he had to choose both.
Then he narrowed the results (there were 76,000 claims and 73,000 vehicles within the data set he used) to show just the battery failures that happened within the first 5,000 miles or the first 90 days of ownership. That reduced the matches to 824 claims.
He looked for a geographic pattern by plotting the claims on a map, organized by the dealer who processed them, but couldn't find one. He found a cluster of claims from May to October 2006, but again couldn't find a pattern beyond the fact that the frequency of battery-related claims was increasing. He found that most of the failed batteries were manufactured by just one of the two suppliers, but that pattern was also true of the non-failed batteries.
Then he noticed something unusual. Eight vehicles had their batteries replaced three times within the first 5,000 miles. Several more had their batteries replaced twice. When he clicked on one of the VIN numbers at the top of the list, he saw that the three battery replacements were followed by an alternator replacement. And then no more claims!
Look Around the Corner
"A lot of times when I'm getting some of my standard reports," Caruso said, "I know what to ask for. I know what I'm looking for. I think I'm looking for battery replacements." But then he uses Endeca to essentially "back away" from the question, and discovers that the problem is really with the alternators, which are not recharging the batteries. Because he could navigate the data in an unstructured manner, he found an unexpected relationship in the data.
"When you have that 'A-ha moment,' which we see our clients do," Caruso said, "that's what they tell you: 'I didn't expect to see that.' It's so rewarding to realize that no pre-canned report would ever have come up with that, because the user didn't anticipate it, and probably would never have suggested to a designer of reports or analytics actually to put it in there."
In other words, Endeca is promoting discretion, and encouraging intuition. It allows an engineer or a quality manager to go on an unscripted exploration, to test out hunches, and to find unexpected results.
"There are four things that characterize the problems that we solve," Sonderegger said. "The first is that the users have no technical expertise. They have expertise in the business, but not in the data. The second is that they have open-ended questions that lead to more open-ended questions, requiring exploration. The third is that these questions demand data and documents together, in order to be answered properly. And the fourth is that the questions and the data are constantly changing."
Warranty Fits the Bill
Root cause analysis fits all four conditions, he said, and warranty claims data, with its mix of structured and unstructured data, is an ideal environment for discovery. In addition, he suggests that the nature of the tools allows for more specific investigations, allowing the investigator to attribute the cause of a claim to a specific component and/or a specific supplier.
"In the past, the company would have to say 'Here are the reports we're going to produce in order to track supplier responsibility for warranty claims,'" Sonderegger said. "And that would limit them to focusing on just a small percentage of the parts, components, and assemblies that go into the vehicles. The big change here is that the company now does not have to decide that ahead of time. Instead, they can react to what they're seeing actually happening in the field, and investigate the problems with much greater freedom."