Every ERP's real behavior lives in configuration nobody documented — and every AI rollout stalls on "what do we even use it for?" This playbook solves both with one motion: feed config exports and transport logs to an AI to draft living documentation, then package the rollout kit — use-case catalog, prompt library, adoption metrics.
Tier: Foundation · Workflow area: ERP Copilots & Agents · ~30 minutes
ERP documentation rots because writing it is nobody's job and reading config tables is everyone's nightmare. But configuration exports are structured text, and structured text is what LLMs summarize best — with the crucial caveat that the export is the truth and the AI's prose is a draft against it. The second half of the playbook reuses the same muscle outward: documenting for your team becomes enabling your team, in the form of a rollout kit that turns scattered AI experiments into an adopted capability.
Export the configuration that answers real questions. Start where onboarding questions cluster. In SAP: relevant customizing tables via SE16/GUI export (e.g., pricing procedure steps from T683S, order-type config from TVAK), plus transport logs (SE01/E070 lists) for the change history. In Dynamics: solution-export XML and configuration data packages. In Salesforce: metadata retrievals. Flat files — CSV or text — are the ideal input shape.
Draft the document with the export as the only source.
You are documenting ERP configuration for new team members.
Below is the actual configuration export (CSV) for our SD pricing
procedure ZPRICE1, plus the transport log entries touching it
in the last 18 months.
Write a document with sections:
1. Purpose (one paragraph, plain language)
2. Step-by-step logic table: step, condition type, what it does
in business terms, requirement/routine if any
3. Recent changes: date, transport, what changed, likely why
4. Open questions: anything in the export you cannot explain
from the data given — list it, do not guess.
Rules: every statement must trace to a row in the export. Where
business intent is not derivable from config, say "intent not
documented" rather than inventing a rationale.
[paste export + transport log]
The "Open questions" section is where the value concentrates: it converts unknown unknowns into a checklist for the one person who knows.
Review with the owner, then wire the refresh loop. The process owner corrects the draft (expect the AI to have described what perfectly and guessed why wrongly once or twice), answers the open questions, and the corrections go into the doc. Then make it living: re-export on a cadence or after each release, diff against the previous export, and have the AI update only the changed sections — transport logs tell you exactly what moved. Store in your team wiki (Notion, Confluence) with the export date stamped on every page.
Build the role-based use-case catalog from what you just did. Documentation-from-config is itself use case #1. Extend the catalog per role, grounded in your researched inventory rather than brainstormed from zero:
Draft a use-case catalog for AI adoption in our ERP team.
Roles: functional consultant (SD/FI), ABAP developer, basis admin,
business analyst. For each role list 5 use cases with: task,
tool we already license, time saved per occurrence (conservative),
risk level (low/medium/high) and the verification step required.
Mark the two lowest-risk, highest-frequency ones per role as
"start here."
Cut anything you cannot honestly staff a verification step for.
Package the org prompt library. Collect the prompts that already work — this playbook's documentation prompt, pb-47's test-matrix prompt, pb-48's mapping prompt — into a shared library, one page per prompt: purpose, the prompt itself, required inputs, verification step, owner, last-tested date. The library is the difference between one person's productivity and a team's.
Define adoption metrics before launch, and baseline honestly. Three numbers suffice: weekly active users of the licensed tools, use-case coverage (how many catalog entries have at least one regular practitioner), and verified hours saved per month from user-reported, spot-checked samples. Record the pre-rollout baseline now; pb-52's ROI reporting stands on it. Publish the kit — catalog, library, metrics, plus a one-page acceptable-use summary — as a single landing page, and review the numbers monthly.
Config exports can smuggle real data — customer-specific pricing records, user lists, interface credentials in RFC destinations. Review every export for actual business data and secrets before it reaches any external AI tool, and route anything sensitive through your tenant-approved model only.
Start the rollout kit with the documentation use case itself — it is low-risk, its output is visibly useful within a day, and every skeptic on the team has a config area they hate documenting. Nothing recruits adopters like deleting a dreaded task first.