A key pillar of insurance data modernization is migrating reports from the old to the new. We’ve been doing these migrations for quite some time, and here are some recommendations for expediting these projects and leveraging them to elevate analytics in your company.
The simple truth is that in most insurance companies, there are many reports on the same subject – premiums, losses, exposures, retention, etc. – often with inconsistent answers. So, our recommendation is to elevate a “report migration” to a “report rationalization” that helps move your company toward a “single version of the truth,” where parsimony and clarity are fundamentals.
1. Think conversion and elimination over "conversion". “Forklift” and code converters are not the answer. Three hundred legacy reports are likely condensable to 30-50, and many of these target reports are likely to exist already. The best code ever written is the code that never got written because it’s bug-free and maintenance-free. Most of our clients complain that there are too many versions of premium, claim, retention, and other reports, so why create more?
2. Success occurs when the legacy stuff is no longer running, not when the new analytics are promoted to Prod. This needs to be addressed, resulting in even more technical debt. So, task someone on the team with sticking-handling users to the new reports and turning off the legacy stuff.
3. Create awareness among the business communities that the conversion is not optional. Migrations can achieve an excellent cadence or linger forever. Business users and developers need to be rowing together. Business user engagement is indispensable at the front and back ends of report development for each report. Plan and schedule sensibly.
4. Don’t be shocked when numbers don’t match; be disciplined in resolving discrepancies. Bug fixes are the easy part! More tricky are business rule discrepancies, and conversions expose long-hidden business rule nuances.
5. Track and resolve discrepancies. Data discrepancies must be resolved, or the word will spread that the new reports can’t be trusted. An effective issue-resolution process is a critical success factor.
6. Expect lots of change requests for new reports and equip the team to respond quickly to changes. Development teams that delay change requests sour conversions.
7. Measure and communicate project status to the business community. There are engaging ways to show percent complete, upcoming milestones, and critical blockers. It’s crucial to show momentum or, when things are stuck, communicate that, too.
8. Plan for changes to the target data products, warehouses, or lakes. Often, it’s thought that “the data is all in there.” Well, that may be the beginning. Target analytic jobs require new tables, views, transformations, and data. The data engineering team must dedicate hours to the analytics conversion.
9. Create a repeatable, scalable operating model for the migration. This includes defining the responsibilities of the BAs, data engineers, analytics authors, and testers; defining environments and gates for promotion from Dev to QA to Prod; and defining milestones for each stage, e.g., wireframes, source-to-target maps and dashboards. First crawl, then walk, and then you should find that after a couple of months, you’re running.
10. Publish usage reports weekly that show usage by report by user. If you monitor usage this way, chances are you’ll see plenty of users dragging their feet when using the new analytics. Only by knowing this will you get the root cause of why this is happening so that you can fix the problem(s).
In our experience, report migration projects can be surprisingly energizing when the migration team uses the project to move toward fewer conflicting answers while delighting business users with new reports and dashboards that provide more data, more search, more ways to drill down and filter, more ways to time travel, etc. than they are accustomed to.
By Mike Lamble
Partner and Founder, PremiumIQ
Comments