So here is the question: what is the biggest, most important business requirement for any piece of insurance processing software in the P&C space? It is difficult to define, it is difficult to measure and it is maddeningly everywhere and nowhere all at once. I have never seen this requirement written down anywhere and yet it underlies so much of the rules based, configuration driven software that we are currently (finally!) seeing in the ascendant in our business space.
Here is a hint. P&C insurance is one big exception condition. Even the exception conditions have exception conditions. The Rubics Cube of state/line of business/rates-rules and forms generates an almost infinite set of possible conditions which our core applications must be capable of dealing with. And between the legislators, the regulators, the bureaus and (God bless them) our business users there is a pretty constant stream of new exception conditions coming down the coal chute. So the requirement of all requirements is simply that the systems be capable of dealing with this fact.
So here is one attempt at defining the Uber Requirement:
“The system should be capable, with a minimal if any programming, of responding effectively and in a reasonable timeframe, to any and all unanticipated changes in any part of the definitional, data entry, validation and storage, workflow, transaction processing, reporting or integration aspects of the system at any point in time. The nature and or timing of most of these changes will remain unknown, until of course they are known, at which time they will be (time) critical to the corporate well being”.
Does this sound familiar? Of course it does, but maybe not quite in the way we have stated it here. We are all aware of the requirement. It is why we spend so much time trying to define and measure the flexibility and configurability the software we are assessing. It is why we decry the inability of legacy systems to support change. It is why the majority of our IT budgets are spent on maintenance (and it is why, if the new generation of systems is for real, we will in the future spend a lot less of our IT budgets on maintenance).
Of course, given the general and non-specific nature of the requirement it is hard to test for. It is not one of those concrete, discrete requirements where a single test verifies or scores the outcome. It is not for instance: “Did the state specific coverage form attach correctly?”. The problem with rules and tools and configuration is how much planning and analysis and digging you have to do to establish the boundaries of the capability under scrutiny. Tools are great so long as you want to do what the tool knows how to do. As soon as you want to do something that the tool cannot do you tend to be back in that cold hard world we just came from where code gets written and the implementation slows to a crawl. So the key is to establish the depth and boundaries of the system’s configurability as best you can. Only this exercise will tell you the answer that any given software product has to the Uber Requirement.

Recent Comments