Creating a new claims system should be easy with no legacy, right? Not so fast!
One of the great things about going to work for a start-up insurance company with a lot of venture money is the idea that you can build everything from scratch. No legacy of losses, a clean balance sheet, and no system constraints. The problem was the company did so well right from the start that policies were being written as fast as they could print the paper. The company had made the initial decision to buy an old established (green screen) application to handle back office processing. The thought was it was the most robust system on the market and as such should be able to handle multiple lines of business. Nice thought but we were a specialty lines operation and the thing just couldn’t do everything that it needed to do. Individual departments knew this and started to build their own mini-systems to get the work done. Suddenly the clean legacy free environment developed a legacy problem.
So where did this leave us in claims?
Unlike underwriting or finance, we did not have to worry about a huge influx of claims from the start so time was on our side. Despite the time we had, we were not involved in the underwriting system initiative early on. We would later learn what impact this would have on everyone. There is more to this story, but needless to say involving all key stakeholders potentially impacted by a system implementation is critical early in the design process. Nonetheless, we had a handful of claims and time to decide what type of claims system we were going to use.
Option 1 – License a System From Our Vendors – Sounds like a good idea?
The first suggested claims system solution was that building a system would be too costly and we should just “rent” a system from one of our Third Party Administrators. Another nice idea in principal that proved to be a not so nice in practice. While everything seemed usable during the demo and initial discussion phases, it was not until we started to actually get down to trying to integrate the application that problems arose. The system was really designed for a TPA and not for a carrier. The meant it did not handle policy data well and in turn would be difficult to adopt. At every turn the so called “customizable” options were leading us to create work-around after work-around. Unless we wanted to pay for fields to be customized, this option was not going to work.
Option 1 – Scrapped.
Option 2 – Buy a Comprehensive System – Another nice idea that was not going to happen
Simply put, this option was way to expensive, and with no true policy system in place, an implementation was going to be even more difficult than “renting” a system. Additionally, at the time, robust claims systems did not exist on the market as much as they do now and the ones that did were an all or nothing approach. We had a half a dozen claims and buying a system that could handle more than we would could have needed for lines of business we were never going to write didn’t make any sense either. So, needless to say –
Option 2 – Scrapped.
Option 3 – Build Your Own – more a decision by accident than by design
Now time was not longer on our side. Claims were coming in and we needed to do something. Ah the wonders of excel. With a spreadsheet all we could do was keep a record of claims and money spent, but in no way provide a claims management system. The controls, and making sure various required financial reports could be provided, was a continual problem that got worse the more claims and transactions we had. Like other departments in the organization I decided to build my own system out of necessity. This began with my limited skills in MS Access and then continued with the hiring of a an actual Access developer. I was off to the races now and the claims department could build something it could actually use.
Option 3 – I think we’re on to something…
So now let’s build – It’s time for reality, a plan and a process
Developing is very simple when you have no rules, no team and no plan. It was me and a developer. I told him what I wanted to see and he built it. Life was good. Now claims were coming in faster and we had more users on the system and people now wanted my data. Developing this way was not going to work and I was in for a rude awakening with the assignment of a business analyst. This was all new to me at the time and my days of walking over to the developer’s cubical and telling him to stop what he was doing to add a new feature were over. In walked much needed process and structure. The reality was I did not really think we were going to build a system from scratch – I thought I was building a stop-gap measure. The stop-gap was over and the system was now going to have to go to an entirely new level.
With structure came direction and a strategic plan was developed. We had to get the basics taken care of which included a more stable database that could handle multiple users, and a new front end that would allow us to make changes quickly as well create new features and connections to various parts of the organization. A development plan emerged and a procedure for enhancements, development, testing, and implementation took shape. The system was no longer a department database, but a corporate application.
I had to come up with a name for our new application and so the Claims Processing Administrations System, cPAS, was born. The puzzle pieces were beginning to fit.