Mind if I get something off my chest? I'd like to clear up a misconception that I've heard circulated in our industry. I might get a bit technical, but don't worry: I'll stay out of the weeds and if you stick with me to the end, you'll be a more enlightened consumer of analytics (and software in general).
Some people around the industry are saying, "you need to have your data in a SQL database in order to get analytics." Sounds simple and true. So why does that burn me up? Because it's often used to promote a logical fallacy: The suggestion is that, "if your data is in a SQL database, then you can get analytics." Not necessarily true. And certainly limiting.
Let me show you the pitfalls.
Pitfall number one: You have a persistence database.
Structured Query Language (SQL) databases are powerful tools that we use to store information. To work properly, a given database must be designed to match its purpose. When a software system is using a SQL database to store your data, then it is a persistence database. (Such databases might also be called transactional databases, because they're tracking the transactions that individual users perform over time.) A well-designed persistence database allows you to retrieve, modify and share your information quickly and easily.
You may also be able to create some analytics from your software system's persistence/transactional database. But you may not. Likely you could get some simple analytics, like lists of records and such. But sophisticated analytics are a different story.
Pitfall number two: You don’t know what questions you’re trying to answer.
Developers need to design the database for analytics. Before they can do that, they need to know what questions you're trying to answer. Sometimes, a different question requires a different database. So, your data might need to be copied many times, into multiple analytics databases of different designs, to answer all the questions you want to ask.
Pitfall number three: Your data is scattered.
You may need to bring in data from other sources (your accounting system; your call logs; your website traffic; and all the other systems in your business) to get a comprehensive view. Analytics tools are often very good at aggregating data from many places. They can draw from SQL databases, Excel spreadsheets, XML data stores and the other various places that businesses store their information. You certainly wouldn't modify the persistence database of one system to aggregate these other information sources: it might break your system. So, you extract the data from all these sources to create one or more purpose-built analytics databases.
There are other reasons why an effective and powerful analytics system must be designed from the ground up, like performance, not retrofitted onto an existing system. But my point is, ask some tough questions if you hear somebody making ideological claims about their technology. And if someone suggests that you can create analytics from their system, just because they use SQL, find out what kind of questions their "analytics database" was designed to answer. Or was it even designed for that purpose at all?
Commercial Lines Analytics Overview
Policy Works introduces the first out-of-the-box suite of commercial lines analytics that incorporates policy and workflow data.