According to the article, Multitasking: Switching costs, “multitasking may seem efficient on the surface but may actually take more time in the end and involve more error. [University of Michigan professor David E.] Meyer has said that even brief mental blocks created by shifting between tasks can cost as much as 40 percent of someone's productive time.” An understanding of these hidden costs can help people select strategies that improve efficiency, “above all, by avoiding multitasking, especially with complex tasks.”
Moving back and forth between legacy systems and spreadsheets in the underwriting process — activities that may have become so routine as to feel like second nature —carries its own switch costs. In this case, the costs come in the form of inefficiency and added risk that impacts both risk pool staff and members.
Data silos contribute to underwriting inefficiencies
As risk pools look to provide better service and increase value for their members, streamlining operations becomes critical. In many cases, these efforts are hampered by data stored in disparate systems or spread across multiple programs, which often means more manual administrative processes.
This can be especially true when it comes to underwriting. In Streamlining Risk Pool Operations, an article that outlines the value of underwriting as a means to deliver customized solutions to members, a PricewaterhouseCoopers study is cited to illustrate just how much time can be spent engaged on administrative endeavors. “Underwriting, claims and finance are littered with low-value transactional processes and wasted costs (in underwriting, for example, up to 80% of the sales time can be spent on administration). These processes often rely on heavy manual workarounds, including re-inputting of information onto multiple systems.”
According to How risk pools can eliminate underwriting inefficiencies and errors, a major part of the problem is that gathering the exposure values, schedules, and any additional information required for calculating contributions relies on a combination of email, spreadsheets, and at least one legacy system. For some pools, this process can drag on for weeks, taking up both staff and members’ time.
Data that lives in separate systems and programs require more manual administrative work and multitasking. This, in turn, leads to a higher switch cost.
Spreadsheets make underwriting riskier
Data errors in spreadsheets are well documented. According to researchers at Carnegie Mellon University, the most common are “inaccurate data (76%), errors inherited from reuse of spreadsheets (49%), model errors (33%), and errors in the use of functions (also 33%).”
The “Why” and “When” of Moving from Spreadsheets to RMIS provides an in-depth examination of the consequences of some of these errors:
- The increased likelihood of errors - An issue in a single formula or a typo when keying schedule data into an individual cell has the potential to affect the accuracy of premium calculations.
- The rapid proliferation of errors - Over time, as a corrupt spreadsheet is shared, edited, and shared again, errors can be exponentially amplified.
- Difficulty in tracing the origin of errors - The lack of a single source of truth makes it impossible to identify the point at which errors were introduced, thus limiting any chance of quickly making corrections.
“Insurers often use spreadsheets for these complex calculations [statistical pricing models and rating factors], as they are well understood and accepted. It’s common practice,” writes Matt Bailey in When 'speed' is missing from a speed-to-market approach. But he questions whether this should continue to be the case.
“Spreadsheets are indispensable for tasks like displaying data, creating formulas and allowing users to update values,” Bailey writes, “but they should not be used to shape data and mimic business rules.
Streamlining and error-proofing underwriting processes
Bailey points out the advantages of using newer technologies to strengthen the process. “Business rules can be placed inside a business rules engine that supports versioning, governance and ease of use. Final factors get married to business rules by version, in turn making re-rating policies as simple as selecting a version and clicking the run button,” he writes. “Finally, a process flow guides data creation, business rules and factor selection. This allows the analyst to make a factor selection without the drudgery of maintaining spreadsheet files.”
A single, integrated system that supports underwriting, as well as member, claims, and policy management, has not only been shown to reduce process inefficiencies and risk, but has also proven useful for more fully engaging risk pool members.
Along with integrated claims and member management functionality, Origami Risk provides risk pools with a cloud-based platform that supports the entirety of the underwriting process, from collecting exposure values to generating quotes and proposals for prospective or current members to securing endorsements to generating invoices and cross-policy analytics.
In Origami, risk pools have complete autonomy over the design of rating tables and formulas for each line of coverage, thus eliminating the need for custom coding. As mentioned in Best Practices Pools: Managing the Renewals Process, having all of this data in the same system as a premium calculation tool also eliminates the need to re-key or convert data from other systems. This introduces greater visibility and transparency into the process, while also providing access to a detailed audit trail.
By removing legacy systems and spreadsheets from the underwriting process, risk pools can eliminate hidden switch costs. In addition to greater efficiency in operations and a reduction in the likelihood of error, making this change also signals to current and prospective members that they can expect a higher level of service.
Using Origami Risk, Washington Schools Risk Management Pool (WSRMP) reduced the annual process of collecting property values from all 92 members participating in the program from over two months to less than two weeks. Read more...