Maintenance & Change Management
Change Requests and Versioning
Deploying an automation is not the end of the project — it is the beginning of an operational commitment. Every automated process will eventually need to change: a regulation is updated, a business rule is revised, an exception pattern emerges that the original design did not anticipate. How an organisation manages those changes — and the incidents that occur when they are not managed well — determines whether automation delivers sustained value or quietly degrades over time.The Six Most Common Drivers of Change Requests
Change requests are not a sign that the original automation was poorly built. They are a sign that it is being used. A programme that receives no change requests after go-live is either perfect — or unmonitored. The goal is not to prevent change, but to manage it in a way that is controlled, documented, and reversible.
A regulator updates a rule, threshold, or reporting requirement. The automation must reflect the new requirement before the effective date — not after the next audit. This is the highest-priority change category in banking.
Internal policy changes — approval thresholds, product eligibility criteria, fee structures, or SLA definitions. Rules encoded at go-live become outdated as the business evolves. Without a change process, the automation enforces yesterday’s policy.
An error in the original automation logic is discovered — a condition not handled correctly, an edge case that produces a wrong output, or an integration that behaves unexpectedly under certain data conditions. Bugs must be fixed through the same change process as any other update.
Performance data, exception patterns, or process mining reveals an opportunity to redesign a step, reduce friction, or handle an exception type more efficiently. Improvements are planned changes — distinct from incident-driven fixes.
An upstream or downstream system is updated — a new API version, a changed field name, a modified data format. The automation must be updated to remain compatible. These changes are often triggered by IT rather than the business.
The automation is extended to cover additional transaction types, additional entities, or additional exception paths that were deferred at go-live. Scope expansion should be treated as a mini-project — not informally added to a running automation.
The Change Request Process
No change to automation logic should be deployed directly to production without test environment validation and process owner sign-off. Emergency changes follow an expedited version of the same process — never an informal one.
Why Every Change Must Be Versioned
In a regulated environment, the ability to answer “what rule was applied to this transaction on this date?” is not optional — it is an audit requirement. Version control is what makes that question answerable. Without it, every change to automation logic creates a compliance blind spot.
- Every change to automation logic has a version number, a date, and a named author
- Change log documents what changed, why, and who approved it
- Previous version retained and restorable for rollback
- No direct production changes — all updates go through test environment first
- Versioned logic links to the process documentation version it implements
- An incident occurs and nobody knows what changed or when
- A compliance audit asks which rule applied in March — nobody can answer
- A fix creates a new problem and rollback to the previous version is not possible
- Two team members make conflicting changes and one overwrites the other
- A regulatory change is deployed inconsistently across entities
Every production automation must have: a current version number, a change log with at least the last five changes, and a restorable previous version. If your automation platform does not support this natively, the change log must be maintained manually — it is not optional in any regulated environment.