prior posts in this series: 8 Signs You Might Need a New Actuarial Modeling System (Part 1) (Part 2)
Once you realize that you may be in the market for a modern actuarial system, it’s time to start building a case for conversion. Because, realistically, you’re probably going to need to do some work in order to convince others to support you in this effort.
This is generally not going to be as easy as updating your driver’s license, or even adding a new desktop software system that converts Word documents to PDF. Those are simple decisions, for small amounts of money, and readily standardized.
Converting to a new actuarial modeling system is an investment in the future. As such, it’s going to require some weighing of costs and benefits.
This article will guide you towards figuring out what some of those costs and benefits actually are. Plus we offer some ways to help make your case more palatable to those who might be hesitant to make this investment without some kind of guarantee.
As such, here’s a TL;DR:
- show the current and future state
- make a comprehensive cost/benefit analysis
- provide some options
- paint a picture of a better future using real-world examples.
1. Determine the current and future state of your actuarial function
Let’s face it, if you were completely satisfied with your current modeling system, you wouldn’t even be considering a new one. Which means that there are some red flags in your relationship with your current software.
The first step then is going to be figuring out what you want to do, but can’t.
This may come out as “I’d really like to stop running that one extract program every month-end. It just doesn’t feel like we’re adding any value with all those steps.”
Or, it could be aspirations of a beneficial future state: “We’ve been asked to consider building out GAAP reporting as an internal management tool, so we need some help in understanding our needs.” Maybe, “We’d really like nested stochastic capabilities for our annuity hedging program.”
However (as our therapists tell us), It’s only fair if you’re looking at the negatives to also consider the positives. What does your current system do well for you? What don’t you want to lose if you shift systems? What is going right?
A comprehensive view of your current status will take into consideration both the negatives and the positives. Otherwise you’re introducing bias into the discussion before you even get it off the ground, which isn’t going to be good for inspiring buy-in later on.
Next, it’s time to figure out how much your current software system (and some potential replacements) actually costs.
2. Quantify the total cost of your actuarial system
Direct costs
License Fees: The most visible component of any actuarial modeling system is going to be the price tag. This usually covers access to the base system and may include an annual fee. There may also be per-user license fees. These are the standard idea of “costs” of your license system, but that’s not all that exists.
Support hardware: You may have already built out an internal set of distributed processing servers. You may have licensed some time on a public or private external cloud. Or you may have upgraded your own desktops, laptops, and accessories. These physical, tangible stuff that build your infrastructure cost money, both to maintain and to prepare for when they fail. Don’t forget to include these fees (upfront as well as depreciation) in your analysis of your overall cost.
Accessory software: If your actuarial software doesn’t provide all the capability you need, you might have to supplement with some ancillary support. For example, perhaps you currently have an admin system that can only produce output in .txt formats. So you license another quick tool for maybe $30 a month that allows you to create standard ETL processes to get admin output from that .txt format into your actuarial system’s proprietary format. That’s a cost that you’re currently paying, and should be included.
Alternatively, suppose your system doesn’t have any kind of results evaluation tool, or maybe you need better visualization than can be provided in Excel or with pivot tables. Again, you buy a license for a commercial viz software that costs $15 a month. This is the kind of thing you should include in your “how much does my software cost?” analysis.
Consultant fees: If you already have consultants engaged to either run your models, or review, or sign-off, or you’ve outsourced this to a business partner, you want to include that in the all-in costs.
Now, that doesn’t mean all of this will go away after a conversion. You might still need consultants for a while on an ongoing or even ad-hoc basis.
But you definitely shouldn’t be ignoring these costs, because they are related to your current setup.
Indirect costs (people costs)
This a big one that some evaluations overlook. Many analysts will do just fine quantifying anything that comes with a price tag, because there’s a check involved and the accountant know where everything is recorded. But we suspect that indirect costs of your software system are just as large, if not larger, than your direct costs.
Indirect costs arise when your professionals aren’t doing professional work. We’re not talking about HR meetings, or performance reviews, or team-building exercises. Those are valid and worthy.
We’re talking about all the wasted time that your actuaries and others spend managing systems or dealing with non-actuarial tasks just to get to do the actuarial stuff.
Remember from above, we talked about ETL processes? Yeah, that takes time. Even if it’s just 5 minutes a week, that five minutes adds up. Because how many little tasks do you do in a day that aren’t related to your actual job, but relate only to getting you to do your job?
Maybe it’s waiting for a program to open or close. (We have direct experience waiting more than 30 minutes for a program to save, for Pete’s sake.)
Maybe it’s that your computer is tied up while your model is running, and you can’t do other work that you could do
Maybe it’s just having to waste your own time installing upgrades to your system (to support the software) or the software itself.
Don’t forget about your non-actuaries, too. There’s often a big chunk of IT professional time dedicated to that hardware you identified above: managing server infrastructure, keeping permissions recorded and modifying as necessary, disaster recovery planning, etc.
When considering how much your software really costs, this is an important component. Five minutes a week on each of ten different tasks is about an hour. Add in two or three hours each quarter during reporting time, and five or ten hours on a once-a-year project, and now you’re looking at a serious chunk of time that’s unproductive.
And because it’s unproductive, you’re not working as an actuary. Which means it’s a cost, not a benefit, when you’re doing those tasks, instead of finding ways to make machines do them. Or, even better, eliminating them from your workflow.
3. Attempt to measure business costs
Now we get into the squishy part of this, and discuss “business costs”. By this we mean the maybe-not-so-quantifiable, but still real, costs of having your old system in place.
Is your old system giving you the information you need to make effective, in-depth risk analyses? Do you even know what you don’t know? This is a risk management issue. Maybe you quantify this as an extra fudge factor on your hedge costs. If your current hedge costs are, say, $500,000 per year, and could be cut down by 10% with better information, then your system is costing you an additional $50,000.
Is your old system keeping you from developing products as fast as you would like? Or do you not have targeted capital deployment because you’re hesitant that your models adequately capture the various risk profiles of your potential business? This is a speed to market issue, and it costs you, too.
Again, suppose your new business ROE benchmark is 12%. Because you can’t introduce new rates or new products as fast as your producers are asking for them, you only achieve 10% ROE, because by the time you’re ready to go you’ve lost the status as leader and innovator. Is your system contributing to that 2% gap? Could a new system allow you to speed this up, and get you to the benchmark? That lost profit you’re missing out on is a cost of your system, too. Don’t overlook it.
Finally, here’s an intangible that’s not related to actuarial practice, but instead is a function of your actuarial talent pool. If you’re asking actuaries to devote five, eight, or even ten years to their education, but giving them substandard software, are they going to feel valued? Might they, instead, think that you don’t see them as worthy of having the appropriate tools to work at the top of their certification?
This shows up in actuaries leaving for competitors, because there they can actually be actuaries. They’re not tied up with all the mundane data details that slow them down (see above). As such, your costs in this area are related to actuarial turnover. Your good people leave too fast, you have trouble attracting talent, and in the end you get a lower quality work product out of your team.
How you quantify that is up to you, but one way might be to assume that there’s a small percentage of your actuarial salary allocation that’s wasted or inefficient – 1%? 3%? 8.75% Pick a number, and see what comes out.
Regardless of what elements you choose, we encourage you to think through what might be impacting your current business practice, and how those costs relate to your actuarial system.
We suspect you’ll be surprised at how it’s so much more than just license fees.
4. Measure the time and estimate the cost of conversion
It would be ridiculous to assume that you’re going to switch over to a new system overnight. We just don’t have that magic wand. (Still!)
The fact is, during your conversion you’re going to have a fair amount of time in which you’re supporting both your old modeling system and your new one.
This is due to the fact that you’re probably going to have to compare results and processes between the two. You’ll want to look at calculations side-by-side to make sure you’re not missing something. You’ll want to know where the deviations are, and why. You are actuaries, after all.
But it won’t be there forever. Eventually (if you’re doing it right), you’ll be able to end your existing contracts with your current vendor and have just the “new normal” to deal with.
During that parallel time, though, you need to consider that you’re going to have to pay for both sets of licenses. You may have consulting fees involved with building new models, and you might still have to pay for some of that extraneous hardware or software that are intended to go away (or at least reduce their footprint) after you complete your conversion.
Which is why we don’t offer any illusions that it’s an instantaneous cost-saver to switch systems.
Good actuarial consultants and vendors will tell you the same thing. They’ll tell you to plan for a time of conversion, and then probably double it. Because you’re going to learn a lot that you don’t know as you get started, and that’s going to change what you do in later conversion and development sprints.
If you don’t consider some of this transition cost as part of your case for switching, you’ll be left looking unprepared when you ask for the decision.
Plus, having some kind of benchmarks for planning the conversion also give you a chance to relate, afterwards, to the plan, and learn just how wildly inaccurate those initial guesses were. Then you can use that to inform future transition projects, either to this same new system or for future conversions in another decade, when the next generation of new tech arrives and it’s time to do it all over again.
5. Consider ramping-up to reduce resistance
One of the challenges of implementing new modeling systems is just getting your head around the fact that you’re going to have to transition a number of models from what you currently have to what you want in the future.
That seems like a lot of work, and it is. You run the risk of getting very far into that conversion process, sinking a lot of costs into it, and then realizing you’ve made a terrible mistake.
A way to minimize some of that risk is to consider a ramp-up to the new system. You don’t have to transition all of your processes all at once, adding a huge surge of “model conversion” people and overhead and then a subsequent drop-off of work.
Instead, you could consider a phased transition, or a trial product. Instead of converting everything (pricing, valuation, forecasting) all at once, consider a phase-in.
First do everything you need for one product, and then make a go/no-go decision on the rest. Maybe you start with the most difficult one, in order to test the capabilities of the new system, and the vendor, too. Maybe you start with an easy one to learn quickly and adapt the process afterwards.
The point is, you don’t have to consider this an all-or-nothing gamble on a new system.
Modern actuarial systems should have the flexibility to allow you to scale up or down your usage in accordance with your needs. If you decide you want to start with a pricing team, just a few users, and then build out functionality across the policy life cycle, you should be able to do so.
That way, your early adopters can also become internal experts on the new system, helping those who are later in the process with your company-specific understanding.
If you want that kind of ramp-up, but your current system (or one that you’re considering moving to) doesn’t allow for this kind of flexibility, maybe it’s not the best thing for your business.
6. Show Concrete Value
A great way to make a case for conversion is to show examples of others that have found success in similar projects. This might be your peers, or even your competitors, who have been able to find success and now brag about it.
Your best bet is going to be looking for public information. Maybe you’ll go back out to your connections on LinkedIn and ask for examples. Maybe you’ll browse a few websites and see if you can find concrete details about what changed, and how it worked.
Look for blogs, white papers, and even case studies. They will often show a before-and-after, and sometimes the muddy middle parts of the process too.
A very important part of this, though, is not to promise specific results. You don’t want to say , “Hey, this guy reduced his run time from 2 weeks to 2 hours. We can get the same thing by buying System X.” Those results are specific to that company, to that process, and even to that vendor. What you want to do, though, is to tell the story of your better actuarial future by implementing a new system..
You can do this by combining all the information you’ve been collating above about the wasted time, the better functionality, and the “better future state” into a compelling narrative. One that inspires your audience (maybe your Chief Actuary, maybe the CFO, maybe a risk management committee) to actually take action and approve your request for initiating this kind of project.
Conclusion
Making the business case for conversion isn’t easy. This structure should help:
- Show the current and future states
- Show the costs of the current and future systems. Don’t forget “indirect” costs, such as inefficient risk management.
- Demonstrate the business costs, which may relate to inefficient capital allocation, pricing frictions, or lost opportunities.
- Create a break-even analysis and understand the total time to payoff.
- Provide options, like ramping up or a phased introduction, rather than assuming cliffs in the work.
- Show examples from outside your organization and use this to paint the picture of a better future within.
What specific format you use will be up to you. It could be a memo, a white paper, a series of emails, or a fancy presentation complete with Excel workbooks of various costs and benefits laid out side-by-side.
Regardless, making your case for conversion with a structure in place is much more likely to produce the positive results you’re asking for: Approval to purchase a software system. And then you can get on to vetting your candidates!
P.S. If you’d like some help structuring your evaluation of the total cost of your current software, we’ve prepared an Excel workbook with many of these categories of expense already defined. Just send an email to stephan.mathys@slopesoftware.com, and request the “Cost of Software” Excel tool.
Next Time:
Essential criteria in the evaluation of modern actuarial systems