OpenText xECM for SAP: name who owns the business workspace

Workspaces need stewards, not only templates

OpenText Extended ECM (xECM) for SAP Solutions connects SAP business objects to content in Content Server through business workspaces, templates, classifications, and permissions. Projects often celebrate the first workspace type that opens from a SAP transaction. After go-live, the harder question appears: who owns that workspace as living operating work - create, classify, retain, and retire - when the project binder is closed.

Marketing’s gap list still shows weak public coverage for practical xECM-for-engineering / Extended ECM on SAP themes. This article stays in stewardship, not product brochure language. It is named ownership of the business workspace per process.

The operating choice

Write five lines business and content teams can both sign:

  1. Workspace per process. Which SAP object / process owns which workspace type (for example equipment, project, vendor, engineering change) - named in a one-page inventory.

  2. Who may create. End users, power users, or system/technical user for automated creation—stated per workspace type. “Anyone with a SAP role” is not a policy.

  3. Who classifies. Which categories, document types, and mandatory attributes apply; who may change the template vs who only adds documents.

  4. Who retains and disposes. Records or retention rules tied to the process owner and legal/compliance—not only to the Content Server admin.

  5. What is forbidden. A parallel file share or personal library that becomes the real system of record beside the workspace.

Who carries it? Business process owner (engineering, AP, procurement, maintenance - as applicable) owns workspace purpose and acceptance of the template. Content / information steward owns classification, permissions pattern, and retention alignment. xECM / Content Server technical lead owns integrations, templates technically, and system users used for automated creation. SAP functional lead owns the business-object side of the link. Security confirms role-to-group mapping. There is no durable sentence “IT owns all workspaces.”

Drift looks quiet

You do not need a sensational breach story. You need patterns like:

  • Automated jobs create workspaces owned by a technical user; nobody accepts orphaned folders when the project ends.

  • Two plants invent different folder habits inside the same workspace type; search and retention both suffer.

  • Engineering drawings or vendor documents land in email and shared drives because the workspace feels “IT’s.”

  • Permissions were copied from a template once; group replacement and SAP-role mapping were never reviewed after a reorganization.

None of that is “xECM cannot work with SAP.” It is go-live without workspace stewardship.

Clean core reading

Keep process content in the xECM business workspace tied to the SAP object—not in a second unstructured island that bypasses classification and retention. Prefer template-driven structure and published permissions patterns over ad-hoc folder creation as the default. Do not treat ArchiveLink invoice images and xECM workspaces as interchangeable without saying which process uses which. Do not invent adoption percentages to declare success.

What this is not

This is not a full xECM implementation guide. It is not a demand to move every attachment type this quarter. It is not a SharePoint intranet governance piece (that adjacency is out of scope here). It is not competitor blame. Name the process, the workspace type, and the content owner.

A practical checklist

  • Inventory: workspace types in production; SAP object; business owner; content steward; technical owner.

  • Create policy: interactive vs automated creation; system user named where automation exists.

  • Classification: mandatory attributes; who may change templates; quarterly review of drift.

  • Permissions: SAP-role / group mapping reviewed after org changes; no “everyone full control” temporary leftovers.

  • Retention: dispose/retain rules named per workspace type with compliance contact.

  • Anti-island rule: where the official document must live; what happens to file-share copies.

How the SOW should read

Prefer language like: “For OpenText xECM for SAP business workspaces after go-live: inventory workspace types by process; name business owner and content steward per type; document who may create, classify, and retain; forbid parallel document islands as the system of record; technical lead owns templates and integration users.” If the paper only says “deploy business workspaces,” require the ownership lines.

McCloy Data

Thought leadership on OpenText, SAP, and practical content and finance automation - from the McCloy Data team.

https://www.mccloydata.com
Next
Next

SharePoint search after the move: tuning, ownership, and when to build