Practical Prompt Engineering for ERP Consultants

Most "prompt engineering" advice is either useless trivia or pitched at people building chatbots. Here's the practitioner cut: five patterns that earn their keep on actual ERP and CAFM project work, and three anti-patterns to avoid.

When to reach for an LLM

The meta-rule: LLMs are good at restructuring text, drafting from outlines, summarising long documents, translating between formats (notes → structured doc, structured doc → client-facing slide), and pattern-spotting in semi-structured data. They're bad at exact arithmetic, recalling specific configurations from your last project, and making decisions on data they haven't seen.

Set the boundary up front. The patterns below all play to the strengths and avoid the weaknesses. Anything you'd send to an LLM, ask first: am I asking it to shape or am I asking it to know? Shaping is what they're for. Knowing is where they hurt you.

Pattern 1: Requirements scaffolding from interview notes

The problem: you've spent two hours interviewing a finance lead about their month-end close. You have six pages of bullet-point notes. Tomorrow you need a structured BRD section.

The prompt skeleton:

Below are interview notes from a discovery session with [role] at [client].
Restructure them as user stories with acceptance criteria, grouped by functional area.

For each user story:
- Title (one line)
- As a [role], I want to [action], so that [outcome]
- Acceptance criteria (3-5 bullets)
- Open questions (anything ambiguous from the notes)

Notes:
[paste notes]

What you get back: a structured first draft you'd have spent ninety minutes writing. What you still have to do: read it carefully, fix where the LLM has filled in plausible-sounding details that weren't in the notes, and rewrite the open questions list (this is the most valuable output and the one most worth your editorial attention).

Pattern 2: RFP response framing

The problem: a 60-page RFP lands. You have eight days. The first hour is always spent reading and re-reading to figure out what they actually want.

The prompt skeleton:

This is a request for proposal from [client] for [scope].
Please extract:
1. The 10-15 questions they actually want answered (not the boilerplate sections; the questions where their decision will hinge).
2. The 3-5 win-themes I should hit (their stated priorities, in their words).
3. What's missing from the brief (questions I should ask before responding).
4. Compliance requirements I cannot skip.

RFP text: [paste RFP]

This typically saves two to three hours on every RFP triage. Treat the output as a starting point for your own read — the LLM occasionally infers a "win-theme" from a single sentence and over-weights it. But the framing it produces lets you skim the document with a structure rather than reading it cold.

Pattern 3: Gap analysis from a system demo

The problem: a vendor's just demoed their CAFM module. You have a list of client requirements (from Pattern 1). You need a fit/gap document by Friday.

The prompt skeleton:

Given these client requirements [paste requirements]
and this vendor's standard module list / capability matrix [paste vendor description],
classify each requirement as one of: Standard fit / Configuration / Customisation / Gap / Integration.
For each, provide a one-line justification.
Output as a table.

Useful as a starting point, not a finishing one. Every classification needs your verification — the LLM doesn't know that "the vendor's reporting module" doesn't actually do the multi-currency consolidation the requirement implies. But it gets you 70% of the way to a draft, and the 30% you correct is where your judgment adds value.

Pattern 4: First-draft training material

The problem: you've configured a feature. The training session is in two days. You need a script.

The prompt skeleton:

I've configured [feature] in [system].
Draft a 30-minute training session for [audience].

Include:
- Learning objectives (3-5)
- Step-by-step walkthrough (numbered)
- Two practical exercises participants can do
- Three common mistakes new users make and how to avoid them
- A one-page handout summary at the end

Saves the blank-page problem. You'll rewrite half of the walkthrough (the LLM doesn't actually know your specific configuration), but the structure, objectives, and "common mistakes" framing carries through to the final version. The handout in particular often goes through with light edits.

Pattern 5: Config sanity check

The problem: your client has just signed off on a chart of accounts, an approval matrix, and a workflow definition. You're about to deploy. You have a nagging feeling something's off but can't put your finger on it.

The prompt skeleton:

Below is a [chart of accounts / approval matrix / workflow definition].
Review it as a peer reviewer would. Flag:
- Inconsistencies (something that doesn't match the rest)
- Missing elements (categories, roles, transitions you'd expect)
- Things that would surprise an external auditor
- Risks I should call out to the client

[paste config]

The LLM is fast at pattern-spotting across a structured document — faster than you, in fact, when it comes to "this approval threshold seems out of line with the others." It's not infallible; treat its output as a peer review, not an audit. But it has caught configuration mistakes for me twice in the last year that I'd have shipped, and that's enough to keep using it.

Anti-patterns to avoid

• Asking for exact figures. LLMs hallucinate numbers convincingly. If the answer requires arithmetic, do the arithmetic yourself or use a tool. Don't trust an LLM to add up your project budget.
• Pasting client confidential data into public models. See AI Governance for Enterprise Operators. The prompts above all assume you're using a tool with appropriate confidentiality posture for the data class involved.
• Trusting the first draft. Always read the output before sending it. Always. The LLM will occasionally produce something that's plausible but wrong in a way that costs you credibility with the client. Editorial discipline is the difference between using these tools well and using them badly.

Related reading: for the policy framing that wraps all of this, AI Governance for Enterprise Operators. For document-heavy automation, Document AI in Procurement.