An Actuary’s Perspective on Process Transformation

In the first piece, we focused on starting with information: defining what needs to be produced, diagnosing current capability, and understanding the type of gap involved.

Once that is clear, the question shifts from “what is the problem?” to “what intervention actually works?”

In practice, this typically leads to two types of intervention: automation to remove execution friction, and re-engineering to address structural constraints.

When you're facing a Type 2 gap, the process can deliver the required information, but doing so is challenging or inefficient. In this situation, automation often becomes the next logical step.

Typical targets include extracting policy data and formatting it for models, running reconciliations, populating templates, handling predictable exceptions and manual adjustments. Automation doesn't change what information gets produced. It removes the friction in producing it, takes mechanical execution off the team's plate so capacity shifts toward interpretation and analysis.

There's something else automation does: it creates capacity.

Most actuarial and finance functions operate close to capacity. Even when everyone recognizes deeper architectural work would help, there's no capacity to do it. Automation reduces the immediate pressure, frees up time, stabilizes operations. This creates the breathing space needed for the team to figure out the architecture, rather than just executing through the next deadline.

There is, however, a risk that comes with this:

If automation removes enough pain, motivation for architectural redesign can fade.

Reserve runs complete faster, variance analysis reports generate automatically, errors drop. The push for deeper change loses urgency. At that point, “good enough” may be treated as sufficient in practice, but the underlying issue remains unresolved.

This is why it is important to stay anchored to the information requirements defined at the start and to periodically re-evaluate them. The key question is whether the current capability, even with automation, deliver what decision-makers actually need?

If not, the gap remains.

Automation has natural limits. Eventually you hit constraints that can't be automated away. Some things remain slow because the process architecture itself creates dependencies or structural complexity.

For example:

• Sequential dependencies that could be parallel: Statutory reserves must be completed before management reserves can start because computing resources are shared and constrained.

• Full recalculations when only only specific changes are relevant: The entire model portfolio gets revalued each time something changed due to complex interactions and inability to anticipate interdependent impacts.

• Exception logic that's grown unmaintainable: Manual adjustments accumulated over years, now living in personal spreadsheets. The quarterly close includes 47 "manual adjustments" that three people understand.

• Late upstream inputs create timing constraints: Actual investment returns arrive on day 7, preventing conclusion of actuarial valuation and downstream process from starting before then.

• Loss of interpretability across systems: Data transfers between systems reduce human interpretability, increasing the effort required for validation and slowing the process.

In these situations, automating further does not address the constraint. The process architecture itself needs to change.

Re-engineering is more involved than automation. It requires understanding how the business works: why reserve calculations are sequenced this way or why it is even needed, what edge cases exist, where judgment matters in model validation. This makes it inherently collaborative. External consultants can facilitate and challenge assumptions, but the redesign relies on institutional knowledge.

Re-engineering also requires organizational capacity to absorb change. You are modifying foundational logic, which means temporary instability. Not every organization can take that disruption on while delivering quarterly results.

This is why automation first, re-engineering second: automation creates the space needed to tackle architectural work without destabilizing operations.

Each step in the sequence builds on the previous one:

· Information design establishes the destination 

· Capability diagnosis reveals the gap type 

· Automation addresses execution friction 

· Re-engineering addresses structural limits

Not every situation requires all four steps.
Sometimes the capability exists and the focus is standardization.
Sometimes automation is sufficient to close the gap.
Sometimes the constraint is structural from the outset.

But the logic remains consistent: understand what you're trying to produce, identify what's preventing it, then apply the appropriate intervention.

Used well, this sequence helps direct effort to the right problems at the right time. Used mechanically, it can create blind spots.

In practice, it’s worth watching for situations where regulatory constraints, organizational incentives, or ownership boundaries limit how far a particular intervention can go. Automation may reduce pressure without resolving deeper issues and, in more complex processes, can create distance between people and the mechanics of the work. Architectural redesign may be conceptually sound, but impractical to absorb in the short term.

The aim is not to force the work through a prescribed set of steps, but to remain clear about what problem is being solved and what trade-offs are being made along the way.

Looked at this way, much of what gets labelled “transformation” is ultimately about restoring alignment, between the questions leaders are trying to answer and the processes built to support them.

The value is not in faster processes or cleaner execution for their own sake.

It comes from being able to answer the questions that matter, when they matter, with enough clarity and confidence for decision-makers to act.