Did you know that America had almost 18,000 automotive dealers prior to the pandemic? Or that automotive sales account for nearly $1 trillion in economic activity and provides 2.3 million jobs? That’s just a couple of interesting data points gleaned from this year’s 105th National Automobile Dealers Association conference.
8.8 Million Cars Sold Annually Pre-Pandemic
Though sales volumes dropped by up to 50% during the pandemic, post pandemic, sales volumes have returned to normal, though constrained sharply by supply chain issues with the numerous computer chips cars require.
EVs vs ICE Chip Requirements
All modern automobiles require computer chips, with the average Cadillac needing 50+ chips for everything from seat controllers to exhaust gas recirculation sensor data output handling. EVs or electric vehicles often require twice as many chips, even though they are theoretically simpler. This is because of their battery management systems and numerous other components that are all tightly integrated.
Many Business Transactions Happening
With 2.3 million people executing hundreds of thousands of business transactions just within the 18,000 or so automobile dealers, there is a tremendous need to properly handle all transactions, including warranty transactions.
Warranty Transaction Execution Requires Many Rules to Work
These warranty transaction rules, which can be vast in number and often interact with each other, require the use of a business rules framework. These are often referred to as Business Rules Management Engines (BRMS). A business rules management system contains one or more business rules engines, and each business rule engine contains various business rule engine tools. Business rule engines can be open source or vendor specific.
Many BRMS Engines Exist
Many types of COTS software and coding languages have a BRMS, such as: Appian, Avia, Azure, AWS, IBM, .net, python, PEGA, SQL service, SAP, and Oracle. Each of these have their plus' and minus’ and the Gartner Business Rules Engine Magic Quadrant does a good job of comparing them.
SAP ACS Warranty Management VSR Engine
The SAP Warranty Management system comes with such a rules engine, which is called the VSR or Validation and Substitution Rules engine. The SAP ACS Warranty Management VSR framework enhances this framework with typical warranty checks, needed by most customers, such as
- Duplicate claim check
- Date comparison
- Mandatory fields, and others.
Though very flexible and highly extendable, prepackaged rules never suffice for our customers.
Customers Have Very Specific Requirements
Because SAP users typically have more specific warranty claims requirements, they often have very complex business rules that go beyond the out-of-the-box VSR and ACS framework capabilities. For example, an OEM may want to protect the warranty claims system by ensuring a dealer cannot accidentally misuse the system, or be able to file a false claim, which might automatically go through.
Fine Balance Between Automation and Manual Processing Required
The SAP ACS Warranty Claim Management Processing System is set up in order to allow processing huge claim volumes with minimal human interaction. When manual warranty claim processing is required, the VSR business rules engine has to keep the claim system performing watertight. For example, perhaps every claim needs to pass a set of 30 different checks for validation purposes. The VSR framework must be able to handle all of the different combinations of inputs and output messages required contained within this set of 30 different checks.
Differentiated Severity Level Handling Required
The VSR engine must also be able to differentiate between claims severity levels and route the notifications to the appropriate organizational level.
Internal Message Handling vs. External Message Handling
Some messages are for internal purposes only and must not be displayed externally.
Therefore, the VSR system provides filtering such that different message types can be routed to different users’ work queues, each of which can be customized. Specific claims will be tagged with those message types, allowing for track and trace capability of message communications.
Handling Customer Disputes
Sometimes, a customer may dispute the outcome of a warranty claim. A typical example might be that the claim was rejected for reasons the customer disagrees with. This could be as basic as the particular item was not actually covered in the first place all the way to a disagreement as to how a customer had used the item. The VSR can be extended to help smoothly handle these sensitive situations.
VSR Requires Dynamic Programming Logic
Most of the time, warranty claim validations are performed based on data objects, such as,
Master Data:
- Customer
- Vendor
- VIN No.
- Equipment Record
- Part
- Labor
- Labor Codes
- Failure and Cause Codes
- Flat-Rate
- Pricing Setup, et al
And transactional documents:
- Sales order
- Service order
- Service notifications
- PO, others
We can and do extend the ACS framework so that the warranty claims system also takes into account many other rules and conditions. For example, we can have the system consider, in the middle of a claim, what is master data and should we refer to it to validate claim data?
How This is Done Today
Today, if a business rule goes beyond data available on the claim, we write User Extensions using SAP ABAP code to perform claim validation, or bring the data into the claim object to validate inside the claim.
Looking Toward the Future of the VSR
In the future, we are developing a dynamic VSR validation engine upgrade, that will provide unlimited validation capabilities. For instance, with it, we will be able to check whether the customer is active/inactive, has credit blocks, or falls under trade restrictions. This is actually very hard for many businesses to determine. By using a table-driven configuration approach of the dynamic engine, we can provide robust validation capabilities.
Configurations via Configuration Tables
With this approach, we can easily setup and handle 40-50 interrelated validations, all configured through configuration tables. It is an advanced business rules engine sitting on top of SAP's engine. This approach has already been rolled out at other automotive OEMs successfully. Thus greatly reducing the project risk and development time.
Best kept secret: Change Management in Real-Time
Also, with this approach we avoid having to import SAP transports into the productive SAP system, every time a business rule changes. This is huge as it can take some time to move a transport from development to production.
Migrating Off of Legacy Systems – AS400
We often work on legacy system migration projects where we are tasked with moving a client’s AS400 based warranty claims management system to the SAP ACS Warranty Claims Management System. This is where the VSR framework is an especially valuable addition to our tool set.
30 Years of Legacy Knowledge to Be Migrated
If there is one truism of projects, it is that change is hard, and change management is critical. However, with the SAP VSR rules engine, we can often move almost all of the rules and knowledge embedded in these ancient, unsupported and unsupportable systems, to SAP. This drastically minimizes the scope of change the end user will have to deal with. This helps them quickly achieve and exceed their previous legacy system level of warranty claims processing efficiency and effectiveness.
Detering On-Going Development Support
We strive to capture all of the existing functionality embodied within a customer’s legacy system, as long as the customer still requires it. Often, a good system cleanup is called for during this migration process. Once migrated, our team then works on developing and implementing the requirements within the VSR framework. Like all such processes, change will often require additional development efforts down the road, which we are glad to offer.
Exploring New Possibilities
Aside from ensuring all of your business rule requirements are captured, validated, and migrated to the new SAP ACS Warranty Management System, most clients are also looking for new ways to obtain additional value from the system. What we often find is that due to a variety of reasons, including limited budget or lack of development capacity, requirements were discovered in the past, but simply shelved. You may know this as technical debt.
In other cases, for clients already on SAP, who may have done their implementation long ago, we find they have developed solutions that are now available as standard out-of-the-box functionality from SAP. Many times, developments can be completely replaced by simply ‘turning on’ newly released SAP functionality. This is true at all levels of your SAP ECC and S/4Hana systems, not just within the SAP Warranty Management system.
Ready to Take Your System to the Next Level?
SAP HANA and SAP ACS Warranty Management represent the path to the future of your advanced warranty claims management solution. The VSR Framework, a business rules engine embedded within the system, provides you with the ability to implement very complex warranty claims business rules. Detering Consulting can help you design and implement the solution today. Just use the button the book a meeting.
