What an OpenText VIM health check should put on one page
Evidence, not a brochure
Teams ask for an OpenText VIM health check when something feels off: exceptions are climbing, a release is coming, shared services changed, or nobody can say whether the landscape still matches the business after go-live. McCloy Data already publishes a longer note on the value of a proactive health check. This article is the narrow operating artifact those conversations should leave behind: one page AP and IT share.
If the output is only a sales narrative or a tool dump, you did not finish. The page is the deliverable people will still open in six weeks.
What belongs on the page
Keep it short enough to print. Name evidence, not slogans.
Version pair. SAP S/4HANA (or ECC) release, VIM Foundation, Invoice Solution, Fiori UI path, capture product, archive product. Public upgrade guidance still puts compatibility before preference: confirm the SAP target first, then the VIM row the Note and matrix allow—for S/4HANA 2025, published summaries of SAP Note 3654390 name VIM 25.4. The health check does not choose the upgrade for you; it records what you actually run and whether that pair is still coherent.
Exception top reasons. Not a vanity touchless percentage. The five or ten reasons that consume AP time this month - price, quantity, missing GR, vendor master, tax, duplicate, coding, authority. Volume by reason is enough. Trend direction helps. Invented industry benchmarks do not.
Chart of Authority freshness. Last rebuild date, company codes in scope, open vacancies in approval roles, and whether substitutes were tested. A CoA that still points at leavers is a finding, not a footnote.
Capture ownership. Which inbound channels are live, who owns template or learning changes, and what “good enough” means for field quality without inventing a KPI slide. If BCC/ICC paths were retired and something else is in use, say which product is actually in production.
Archive retrieval sample. Ten recent DP documents: image opened from the workplace AP uses. Note internal vs public Fiori if both are in scope. A repository that stores but does not serve is a health-check finding.
Named owners. Exceptions, capture quality, archive incidents, CoA changes, Basis contact for jobs and notes. Shared inboxes are not owners.
Who carries the page? AP lead and VIM functional lead co-own it. Basis and archive owner contribute their lines. Finance signs the CoA band statement. Nobody “owns the PDF” alone.
How to run the check without theater
Pull facts from the system and the runbook, not from memory in a workshop.
Sample ugly invoices, not only happy-path PO.
Separate document archiving and table / ILM archiving different owners, different pain.
Record open risks as decisions with dates, not as vague “optimize further.”
Schedule a re-check after the next release or shared-services change and not “someday.”
What this is not
This is not a retread of the May value essay. It is not a substitute for the [service engagement](/opentext-vim-health-check) when you need hands-on remediation. It is not a license or SKU conversation. It is not permission to blame a prior SI in the write-up—name the operating gap and the owner who will close it. It is not a competitor comparison. Clean core reading: keep invoice processing in the add-on family you run; use the health check to see whether configuration, master data, and ownership still match that choice.
A one-page template (copy into the SOW appendix)
| Line | Evidence | Owner | Date |
|---|---|---|---|
| Version pair | Releases / add-on levels | Basis + VIM lead | |
| Top exceptions | Reason list + volume | AP lead | |
| CoA freshness | Last rebuild + vacancies | Finance + AP | |
| Capture | Channels + quality owner | Capture owner | |
| Archive sample | 10 retrievals signed | Archive owner; AP signs | |
| Named owners | Roles + backups | AP ops lead |
How the SOW should read
Use language like: “Produce a one-page OpenText VIM health-check evidence sheet covering version pair, top exception reasons, Chart of Authority freshness, capture ownership, archive retrieval sample, and named operating owners; AP lead and VIM functional lead co-sign.” If the paper only says “perform health check,” require this appendix.