OpenText VIM business rules after go-live need a living change owner
Rules age in production
OpenText Vendor Invoice Management encodes a lot of AP judgment as rules: park reasons, routing, enrichment, match behavior, coding suggestions, and path-specific exceptions. At go-live those rules feel fresh. Six months later they feel like folklore—unless someone owns change.
“IT can change config” is not a living owner. A living owner can answer four questions without a hallway search: who may propose a rule change, who tests it, who signs business acceptance, and where the change is logged.
This is adjacent to last week’s note on dictionary-based 3-way match ownership, but it is not the same object. Match dictionaries are one rule family. This article is the change-control operating model for VIM business rules after go-live—especially when a transport window is open and the temptation is to “fix everything while we are in.”
The operating choice
Name, in writing:
Who may change a rule. Roles, not heroes. AP process owner proposes business intent; VIM functional lead implements; finance signs when the rule encodes policy (tolerances, authority bands, high-value paths).
Who tests. A regression pack for the paths the rule touches—happy path plus the ugly cases that created the change request. Shared services and AP both sign if both clear the queue.
Who signs. Business acceptance is not a Basis transport approval. Transport approval is necessary; it is not sufficient.
Where the change log lives. Date, reason, requester, tester, signer, transport or change ticket. A chat thread is not a log.
Who carries it? AP process owner owns the business intent and the acceptance signature. VIM functional lead owns configuration and transport readiness. Finance owns policy-encoded rules. Basis owns the transport path only. Security/SoD reviews when routing or approval logic changes. There is no sentence “the project left rules configured” that survives the first vendor-master season.
Do not reopen every rule because a window is open
A release, a landscape move, or a shared-services cutover creates transport windows. Use them for named rule changes with a test pack—not for opportunistic rewrites of every path that someone disliked in hypercare.
Discipline that echoes without retreading prior packs:
One change request, one intent, one test outcome.
Temporary hypercare exemptions get an expiry date or they become permanent debt.
If two pods disagree on a rule, escalate to the living owner—do not maintain two silent variants.
What fails when ownership is missing
Familiar patterns:
The same exception reason returns every month; nobody can say whether a rule was meant to allow it.
A “quick fix” in quality never reaches production; AP invents a spreadsheet workaround.
A transport includes five unrelated rule edits; when something breaks, rollback is guesswork.
New joiners inherit screenshots from the project binder; the change log is empty.
None of that is “VIM rules are too complex.” It is rules without a living change owner.
Clean core reading
Keep rule determination inside the VIM add-on and published extension patterns you standardized. Prefer configuration and documented BAdI/enhancement points over a parallel decision engine outside SAP. Do not promise AI extraction as a substitute for clear rule ownership—extraction proposes fields; rules still decide what happens next. Do not invent touchless targets to justify undocumented rule edits.
What this is not
This is not permission to freeze all rules after go-live. It is not a demand to reopen every rule every release. It is not a retread of Chart of Authority rebuild or dictionary match ownership—those need their own owners and logs. It is not competitor blame. Name the change, the test, and the signer.
A practical checklist
Owner map: proposer, implementer, tester, business signer, SoD reviewer (when needed)—with backups.
Change log location: ticket system or controlled document AP and IT can both open.
Minimum test pack per rule family: approve path, reject/park path, one substitute, one high-value band if in scope.
Expiry list: temporary exemptions from hypercare with dates.
Monthly fifteen-minute scan: rules changed, rules pending, rules that should have been changed given exception volume.
Transport hygiene: no “miscellaneous rules” transports without a line-item list of intents.
How the SOW should read
Prefer language like: “For OpenText VIM business rules after go-live: name living change owners (propose, implement, test, sign); maintain a change log; require a regression pack before transport; do not reopen unrelated rules solely because a transport window is open.” If the paper only says “configure VIM rules,” require the owner map and log.
