So, you went out and bought that new, big, shiny underwriting, new-business, or policy admin system and finally implemented it last year. You had to do it; all of the pre-existing systems and supporting workflow processes were really outdated and using obsolete technology. In fact, things were so archaic you were starting to feel like you had to check your system’s pulse each morning!
However, the shine is quickly fading, and worse yet, the new system and workflow is not living up to your operations expectations by a longshot. Don’t feel alone or embarrassed. This conundrum is very common, but it’s also very avoidable. Here are a few key rules of thumb to follow before, during, and after any back office insurance system decision-making and selection process.
- Identify and articulate the business problem – What happens so much of the time is that back office insurance operations just chug along and then “all of a sudden” get overwhelmed. As examples, inbound application pipelines get clogged; there are far too many manual handoffs; certain tasks are being unnecessarily repeated by different team members or groups. It is tempting to dream that a new shiny system will fix all of your problems. Unfortunately, the system may not because the list of grievances typically represents symptoms of a larger problem. Break down your problem by asking necessary questions such as: Why are application pipelines getting clogged? Why are so many manual handoffs occurring and tasks being needlessly repeated? The rule of thumb is to take a step back and look at the bigger picture. Is it that policies are taking too long to produce and get out to the client? Yes?? Ah! Now we have identified the overarching problem, and you can start to attack the issues in order of priority. If you were to focus on the parts and not the whole, you’d be applying a costly Band-Aid (aka shiny, new system) to a recurring problem. This Band-Aid would cover the wound but not let it heal.
- Bite off only what you can chew – Now that you’ve started to identify the larger problem(s), your organization needs to tackle the quantifiable underlying issues that go with each. I know the desire is to solve everything right away, but the reality is that you will need to implement solutions carefully, and over time. That is, if you want to see resolutions and results within your career – or possibly lifetime! The rule of thumb here is to PRIORITIZE. Remember the “big picture?” What are your organization’s three and five-year strategic goals? Make sure to crosscheck your ambitions (problem resolution planning) against them and ensure both are in alignment. This exercise will help you and your team set priorities and establish reasonable timelines for achievement. Prioritized lists obviously go top-down relative to level of importance, so whatever is found to not be achievable within a targeted time frame should be demoted to the bottom of the list, and tackled later on.
- Don’t fall into the “IT project” trap – Remember the first rule of thumb? It was defining the “business” problem. Many projects involving big, shiny, new systems that don’t end up delivering what the business anticipated because the business somehow lost control or became detached. Don’t let your business organization fall into the trap of thinking that this is now an IT project. If systems are involved, and they most generally are, there must always be collaboration with your IT partners. However, the reason this started out with defining the business problem to solve is because the business needs to buy into and own whatever the solution is, from beginning to end. If a system solution turns out to be in the picture, have your IT partners at your side, but don’t just hand over the keys and walk away; stay in the car until you arrive at your destination.
- Put in some elbow grease – If, after careful consideration, a shiny, new system turns out to be the solution the business chooses to resolve its problem(s), be sure to maintain the system’s shine by periodically measuring its performance. Is it meeting, or better yet, exceeding the businesses expectations six months, a year, or two years after implementation? In order to do this, you will have had to establish measurement criteria before launch. Look back at your original problem statement, which in this example was that policies were taking too long to produce and get out to the client. What did that break down into? Was there a strategic objective linked to this? Example: “We need to reduce application production time for specific policy types and certain products from 5 business days to two.” That is very measurable. If the system and underlying process workflow is meeting/exceeding that performance mark ‘x’ percent of the time, it’s maintaining its shine. If not, it needs some polishing up in that area.
It’s easy to get mesmerized and lured into buying the shiny new system because you think it’s going to solve all of your businesses problems. But buyer beware. It may not be the perfect solution you are seeking. By taking these rules of thumb under advisement, being thorough, and doing your homework, you and your business will delight in the enduring “bling”, and your customers will benefit too!