Designing and implementing a web-based warranty system

Copyright © 2009 James Taylor. Visit the original article at Designing and implementing a web-based warranty system.Frank Kozlowski of Kohler presentedf on a web-based warranty system. When they set out to develop the system their goals were to move to a start-of-the-art, easy to use system that was web-based so dealers could enter claims directly […]

Copyright © 2009 James Taylor. Visit the original article at Designing and implementing a web-based warranty system.

Frank Kozlowski of Kohler presentedf on a web-based warranty system. When they set out to develop the system their goals were to move to a start-of-the-art, easy to use system that was web-based so dealers could enter claims directly anywhere in the world (they have 12,000 dealers). They wanted to reduce their cycle time from claim to warranty (from 15 days to 1 day) and improve their data accuracy by getting data entered directly. Finally they wanted to prevent fraudulent claims. The system also needed to minimize the use of programmers when administering the system. At the same time it had to handle multiple policies, implement complex payment rules and support multiple languages. Finally it needed to support their short and long term business future – new products that might be implemented. Their solution was to select the Snap-On solution.

Key learnings from the project:

• Understand and document the process you have and the process you want.
  And I would add that you should make sure you will be able to change the process yourself
• You need to focus on data conversion – cleansing, integration, how much history and so on. When to convert, where to store it, how will you use historical data (for quality for instance)
  I would add that rules-based data cleansing and conversion can be very effective.
• New systems have new fields and your historical data will not have values for these fields – you will have to do some intelligent selection of defaults
  Of course you can use rules to set these values too if you don’t want to use the same value everywhere.
• Figure out the kinds of reports you need, and who can produce fixed or ad-hoc reports, and what that means for your data
• Quickly identify your “misses” – because there will be some. Poor communication is the biggest problem
  Of course, if your solution has rules and workflow engines that allow you to make changes then you will be able to rapidly evolve the solution even if you do “miss” originally

I haven’t had a chance to see the Snap-On solution yet but it looks like it uses policy (rule) and workflow engines that allow non-technical users to evolve the product.

Link to original post