When Should You Change Systems?

In blog by Patrick O'NeillLeave a Comment

One of the most challenging technology issues that a risk or claims manager faces is when to change systems. Changing systems can be fraught with many issues ranging from learning new software routines, altering integration points, changing workflows, and getting used to a new vendor service team.  

As independent consultants, we advise our clients to carefully evaluate if their problems with the system and vendor cannot be repaired with an updated business review. Certain conditions may require such a move.

Reasons why a change may be warranted:

Your organization has outgrown the vendor and system.

A good example would be that your company has acquired a new business with different exposures, such as a self-administered worker’s compensation claims unit.  Your current RMIS provider cannot handle this issue; therefore, you need more powerful features. The organization has grown so significant to it requires a lot more service hours than the resources of your current vendor can provide.  

The system has old technology.  

A frequent problem that we have these days is clients with systems utilizing outdated technology.  Either they are older legacy-based systems or home-grown ones that were developed in the 1990s or early 2000s.  

Some vendors have put a more user-friendly interface to make things easier for clients.  Compared to newer systems on neutral, advanced platforms such as Microsoft, Amazon Web Services, or Force.com, they fall short.  As the workforce becomes younger, there is a greater demand for modern technology.  The newer systems are far more able to link into other critical systems via APIs and similar interfaces.  

Suppliers with older technologies sometimes have to make higher investments, which is unreasonable in terms of cost. We have seen the dilemma of proprietary systems supported locally, and this kind of support has become more complex. 

The vendor has issues.

This is the most frequent reason for a client switching systems.  The “issues” are typically poor service or vendor ownership stability.  Sometimes, these two items are linked.  When ownership changes through acquisition, there is a time when some service disruption is to be expected.  It should normalize after some time.  If it does not, a change or a serious negotiation with the existing vendor is probably in order.  

Sometimes a vendor doesn’t have enough resources to help a customer.  There are frequent personnel changes that disrupt the client’s workflow.  System problems remain unfixed.  This fact may be the red flag that prompts a system venue change.

Next Steps:   Deciding on how the change should be implemented. 

The change can be conducted in the following ways:

  • Procurement/RFP
  • Selected system procurement through RFI
  • Direct negotiation with a preferred vendor

The client must also decide how they inform the current vendor that they are making a change.  When to do it?  How to secure their data without an excessive charge to get it?  What are the legal implications?  These are essential questions that have to be considered as part of the change process. 

Redhand Advisors is committed to helping clients achieve maximum success and return with their chosen risk tech solution.

Leave a Comment