I'm working at a small Brasil-based insurance company and one of the main pain points is implementing a new insurance product. I'm a relatively new internal project manager and really new to business to be honest, and I'd like to improve the whole thing but not sure where to start yet.

The main problem is the complexity of an insurance product that consists of multiple structurally very different things. It all starts with the terms & conditions - basically just a long text. Based on that someone will develop the product's pricing, claims departments will figure out a process how to deal with claims and might request changes to the terms & conditions; finance department has to figure out how to do accounting for this product, etc. At the end, all of this must be implemented by producing document templates, process documentations, figuring out interfaces to external service providers, etc. Eventually, some of those things are implemented in various the IT systems, other artifacts like process flows just stay documented somewhere - or worse - in peoples heads.

Regularly, stuff gets forgotten, product decisions are made that are incompatible with the IT-systems, etc. But the worst part is, when starting to work on a new product/adjusting existing products, no one really knows all the questions that should be asked and product development just kind of happens within all the departments - like entering a maze and running around mindlessly until you find the exit - but you never know when. It's frustrating. As far as I understand, people say this is quite a common process in insurance companies.

We've introduced project management a while ago which made it all more structured, we're using process documentation, etc., but still the whole process relies too much on cognitive capabilities of people to identify problems along the way ("the IT system doesn't support that", "if we do this, we'll need to add appendix C to the service provider's contract", etc.).

So ... I really wonder, how do you deal with that, where to start? I'm looking for a way to document the whole data model of an insurance product together with validations that match it against a data model of our capabilities. We'd know all/most questions that need to be asked in advance and departments would simple "fill out" the data model. We'd have a nice, uniform documentation and validations would point out the stuff that doesn't work (e.g. due to IT limitations and we'd either extend the IT system or change something in the product).

I've been looking into data modelling tools but those seem very technical and designed for database design and I don't understand how departments would "fill it out" and figure out the problems early on.

Sorry for the long read and sorry if my question is naive? How do you guys approach that?

2 Answers 2


I'm a relatively new internal project manager and really new to business to be honest, and I'd like to improve the whole thing but not sure where to start yet.

You need to start by understanding the business. You can't begin to make changes to something you don't fully understand or you don't know a lot about how it works, otherwise you'll just create a formula for failure. The things you are looking for fall under the umbrella of Business Process Modeling (BPM) and Business Process Management (unfortunately, still abbreviated as BPM - I'm referring to the larger discipline when mentioning BPM in the answer). You mention you've introduced project management a while ago to make things more structured. This will help, but only indirectly, to manage things. The real tools and techniques that will help make sense of things are those found in BPM.

I want to be really clear here: tools and techniques from BPM; ideas, practices, approaches, etc. I'm not suggesting to jump on full blown BPM software to create workflows, forms, and automate everything you can get your hands on. That will only cause another problem, which you pointed out in your question...

The main problem is the complexity of an insurance product that consists of multiple structurally very different things.

BPM solutions have their limits. They work best when you have a repetitive process, with the same steps, performed in the same way, by the same people. If you have such a process then you can create an automatic flow that will engage everyone that needs to participate in the process, at the right time, in the right order, with proper validations, gateways for work to proceed, events, etc. The problem with insurance products is that many of them are unique. There is some kind of routine to create a new product, and some repetition, but you can't automate the differences. Unfortunately, with BPM you will be forced into the habit of trying to do so. You will end up with an inappropriate and rigid workflow that will constrain people in their actions. Basically, people can't do their job because the tool won't allow it: they will have to look at the specifics of the situation and the larger context, and make some informed decisions, but the workflow will only allow them predefined options A, B or C.

So full blown automated BPM workflows help you deal with one problem but then they create another one. You get a structure with well defined steps, but you may loose the things that can actually make a good insurance product if you could just add something different than what that structure imposes on you and tells people what they can and cannot do. You risk spending a lot of time on process analysis, automation, improvements and building workflows, but then end up with a negative return on investment because you notice that automation of repetitions and routine don't allow you to build the products you want.

This is for example a problem in healthcare where doctors try to use the same workflows for all patients. The problem is that each patient case is different, so you can't fully document and diagnose things when the tools that are used limit the way you can build and document the patient case in the system. A new discipline appeared as a response to this, and it's called Adaptive Case Management. This recognizes there is some common structure in place for things, and some common steps, but allow you to break out of the workflow if your case is different. These solutions are even more complex than BPM. You hit this point also in your question, with this statement:

but still the whole process relies too much on cognitive capabilities of people to identify problems along the way

This is true. There will be experience involved, domain knowledge, collaboration, communication, even gut feeling, a lot of things that people can do and can never be captured in a process workflow.

As far as I understand, people say this is quite a common process in insurance companies.

Not really. I think people just got used to that way of working and find it normal. I've seen situations (not for insurance products, but similar products) where companies had well defined processes in place and ways to keep track of everything, and companies where people were winging it (in other words, chaos). You just need to find the right balance of things.

My solution for you would be the following:

  • start to visualize the creation process of an insurance product. If you are familiar with Kanban, you can create a Kanban board with states in which your product is at any given time, who is in charge of each step, what they do, etc. Don't try to change anything (like I said, you first need to understand what's going on before you mess with it), just document what's happening (the As-Is state, you'll think later about the To-Be state).
  • your board will just have one item going through it which is your insurance product as it is taking shape. It's basically like a baton that gets passed from one department to the other.
  • every day (or often enough) look at the board to try to understand the big picture. Is there some place where the baton gets stuck? Does the baton move back because some department rejects it for lacking things? Where does it go next? Who approves things? Who are the actors? What is their contribution?
  • when you want to create another product, can you use the same steps? What are the similarities to products you created already? What are the differences? Does each actor treat this product the same way as other products?
  • once you visualize this process and figure out where the problems are, or where the chain breaks, you can take a closer look at those things and fix them or improve them. You might even be able to create some automatic workflows out of that. Even if you can't automate the actual work being done, you might be able to automate how the baton is passed from one department to the other, to make sure nothings gets forgotten or lost.

Finally, one word of warning: this will take time. It's not something you can change, improve or fix overnight. So be patient and try to keep things simple.


I expect you'll benefit from getting a data modeller with insurance industry experience to help with this. Some use-case and process modelling expertise will help too.

However, I don't think you should expect to achieve process improvement and software change through a data model. I suggest you identify some key opportunities / pain points and turn them into user stories that you can work through in priority order. Story mapping is a popular way to construct a vision for products and processes. Don't try to accommodate every possible situation up front because that approach can only lead to paralysis. Ultimately, prioritisation and being able to respond to changing needs are much more important. If you put the right team in place and adopt an approach of continual improvement then your data model and process model should evolve over time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.