Varicent will model anything.
Including a decade of accumulated exceptions.
Enterprise ICM with real modelling depth, often carrying history from its IBM ICM years. The build is rarely the hard part. The inherited logic is.
Where Varicent gets hard.
Three things that decide whether a Varicent build stays maintainable.
Inherited estates
Many Varicent instances descend from long-running IBM ICM implementations. The workflows still run, and the people who designed them have usually moved on.
Composer and workflow depth
The pipeline of imports, calculations and workflows is powerful and opaque. Changing one step safely means understanding what the whole chain assumes.
Scale and calculation windows
Large participant counts and long histories make calculation time a design constraint, not an afterthought.
The same Varicent project, two ways.
What usually separates a Varicent build that holds up from one that quietly becomes someone’s problem.
Without specialist support
Inherited IBM ICM logic nobody currently understands
Composer workflows changed by trial and error
Calculation windows quietly growing every quarter
Original designers long gone, decisions undocumented
Upgrades postponed because nobody trusts the regression
Small changes carry disproportionate risk
With OnCentive on the build
Existing estate mapped and documented before anything changes
Workflow changes made against a known dependency chain
Calculation performance treated as a design constraint
Design decisions written down as they are made
A regression path that makes upgrades routine
Changes scoped with their blast radius understood
Tell us what your Varicent has to do.
We will tell you what it takes.
First rollout, a migration on or off Varicent, or a new requirement on a system already paying people. We have done all three for more than ten years.
Start a conversation