A colleague and I exhibited at the recent Insurance Accounting and Systems Association (IASA) annual conference, and I couldn’t help but remark about the simplicity of our trade show exhibit: pull a few pins, and the wall-size display folded into a neat bundle that dropped into a perfectly sized travel bag. Complex engineering, simple to use.
At that same conference, I spoke of that concept – about making the complex simple for insurance systems – to an industry technology expert. Why is it that it takes over a year to implement a new system in many companies, and three, four or more years for others? What is it that would create that much work, for so many people, at a cost of millions of dollars? My theory is that over the years, systems grew to meet the expectations of users who wanted to make what they did easier. Analysts took those expectations and called them requirements. In the name of consensus, people from every discipline contributed their ‘requirements’, and, lo and behold, within a few years the company ended up with a system that looked very much like a mechanized version of what they’d done before. Then, processes became ingrained, and with growth, coverage innovation, and staff turnover, it became virtually impossible to step back to review the mishmash of workflows, redundant controls, code work-arounds, and six-tier dropdowns for users to get to what they needed. Voila! Self-induced complexity!
A week after the conference, I was talking to someone about our system. “Can you replicate our policy numbering system? It’s very complex, with two letters for the line of business, two for the state, two for the coverage, the year, and then a unique ten-digit number.” “We can, but why would you want to?” “Because that’s how we identify a policy”. I was polite, but I’ve been in the industry long enough to remember that that was how you identified a policy when it was a piece of paper in a manila folder with colored letter and number tabs on the edge so you could read the files as you scanned the filing rack. That’s certainly not necessary to identify a policy within a sophisticated database. In fact, the system will use its own numerical identification behind the scenes. The visible numbering system, then, is just a placebo. Voila! Self-induced complexity.
In my years in the industry, I have yet to see a complex workflow, a legacy policy numbering mechanism, or an industry-unique rating algorithm sell a policy or pay for a claim. I have, however, seen huge training manuals, bug-filled ‘new’ releases, and too many change-management consultants paid to re-train staff on new systems or even ‘improvements’ that bring their own brand-new complexity.
The goal should be to transform complexity into simplicity. Or better yet, to create self-induced simplicity. Now that would be refreshing.