Tag Archives: business
Eighteen months ago, I was sitting in a conference room, nothing remarkable except for the great view down 6th Avenue toward the Empire State Building. The pre-sales consultant sitting across from me had just given a visually appealing demonstration to the CIO of a multinational insurance corporation. There were fancy graphics and colorful charts sharply displayed on an iPad and refreshing every few seconds. The CIO asked how long it had taken to put the presentation together. The consultant excitedly shared that it only took him four to five hours, to which the CIO responded, “Well, if that took you less than five hours, we should be able to get a production version in about two to three weeks, right?”
The facts of the matter were completely different however. The demo, while running with the firm’s own data, had been running from a spreadsheet, housed on the laptop of the consultant and procured after several weeks of scrubbing, formatting, and aggregating data from the CIO’s team; this does not even mention the preceding data procurement process. And so, as the expert in the room, the voice of reason, the CIO turned to me wanting to know how long it would take to implement the solution. At least six months, was my assessment. I had seen their data, and it was a mess. I had seen the flow, not a model architecture and the sheer volume of data was daunting. If it was not architected correctly, the pretty colors and graphs would take much longer to refresh; this was not the answer he wanted to hear.
The advancement of social media, new web experiences and cutting edge mobile technology have driven users to expect more of their applications. As enterprises push to drive value and unlock more potential in their data, insurers of all sizes have attempted to implement analytical and business intelligence systems. But here’s the truth: by and large most insurance enterprises are not in a place with their data to make effective use of the new technologies in BI, mobile or social. The reality is that data cleanliness, fit for purpose, movement and aggregation is being done in a BI when it should be done lower down so that all applications can take advantage of it.
Let’s face it – quality data is important. Movement and shaping of data in the enterprise is important. Identification of master data and metadata in the enterprise is important and data governance is important. It brings to mind episode 165, “The Apology”, of the mega-hit show Seinfeld. Therein George Costanza accuses erstwhile friend Jason Hanky of being a “step skipper”. What I have seen in enterprise data is “step skipping” as users clamor for new and better experiences, but the underlying infrastructure and data is less than ready for consumption. So the enterprise bootstraps, duct tapes and otherwise creates customizations where it doesn’t architecturally belong.
Clearly this calls for a better solution; A more robust and architecturally sustainable data ecosystem, which shepherds the data from acquisition through to consumption and all points in between. It also must be attainable by even modestly sized insurance firms.
First, you need to bring the data under your control. That may mean external data integration, or just moving it from transactional, web, or client-server systems into warehouses, marts or other large data storage schemes and back again. But remember, the data is in various stages of readiness. This means that through out of the box or custom cleansing steps the data needs to be processed, enhanced and stored in a way that is more in line with corporate goals for governing the quality of that data. And this says nothing of the need to change a data normalization factor between source and target. When implemented as a “factory” approach, the ability to bring new data streams online, integrate them quickly and maintain high standards become small incremental changes and not a ground up monumental task. Move your data shaping, cleansing, standardization and aggregation further down in the stack and many applications will benefit from the architecture.
Critical to this process is that insurance enterprises need to ensure the data remains secure, private and is managed in accordance with rules and regulations. They must also govern the archival, retention and other portions of the data lifecycle.
At any point in the life of your information, you are likely sending or receiving data from an agent, broker, MGA or service provider, which needs to be processed using the robust ecosystem, described above. Once an effective data exchange infrastructure is implemented, the steps to process the data can nicely complement your setup as information flows to and from your trading partners.
Finally, as your enterprise determines “how” to implement these solutions, you may look to a cloud based system for speed to market and cost effectiveness compared to on-premises solutions.
And don’t forget to register for Informatica World 2014 in Las Vegas, where you can take part in sessions and networking tailored specifically for insurers.
I was talking to a customer the other day who is about to embark on a data quality quest. He asked me to explain my view of a data quality initiative. I explained to him that data quality is a never ending process. I said it was like dropping a pebble in the water. The initial ring is small but slowly expands outward. The data quality process is similar. You start small, with one application or one subject area, show some success then look to expand the process with additional applications or subject areas. Then expand further to additional business units or business functions until you have encompassed the entire enterprise. Then just when you think you’re done, you need to continue to monitor and repair data because it will degrade over time.
While what I said was true, he said that the business would reject that description out of hand. Business believes that all IT projects are never ending projects. It is this thought process that always pitches Business against IT. Business believes that IT never delivers a finished project. His analogy is that Data Quality is more like building a building. It takes a lot of time and effort to get the foundation right, then you need to add the structure, electrical, water, communication, and finishing work. Then you move in and begin to use the building but you’re not done. (more…)