What an SAP forward deployed engineer does

#The 60-second version

A forward deployed engineer (FDE) is an engineer who works inside the customer's business and owns an outcome, not a deliverable. They do two jobs at once: the consultant's job of finding and framing the real problem, and the engineer's job of building and running the system that solves it.

An SAP FDE does this where the business actually runs: in order-to-cash, procure-to-pay, finance and supply chain processes on SAP. They know enough about AI to build real solutions, and enough about SAP to make those solutions work with the company's data, security and processes.

#Why companies are hiring FDEs now

Most enterprises have run AI pilots. Far fewer have AI running in a core process with measurable results. The gap is rarely the model. It is everything around it: messy data, authorizations, integration, change management and nobody owning the result.

The FDE role exists to close that gap. Two signals from the SAP world make the point:

• Accenture and SAP launched a forward deployed engineering program in June 2026 to identify, build and implement AI use cases on SAP's AI platform faster.
• SAP itself is hiring forward deployed AI engineers, from associate to principal level, to deliver AI solutions for strategic customers across the Americas, Europe and Asia.

#What an SAP FDE actually does

The work follows a loop. Each step has a concrete SAP flavor.

#How this differs from roles you already know

#A day in the life: blocked sales orders

A distributor has hundreds of sales orders a day stuck on credit or delivery blocks. Credit analysts check each one by hand across several screens.

An SAP FDE would spend the first days watching analysts work, then find that most blocks fall into a handful of patterns. They build a prototype that reads blocked orders through SAP's standard APIs, groups them, and drafts a recommended action with the evidence, for example "release, customer paid overdue invoice yesterday". The analyst still decides. Within weeks the question is not "does the AI work?" but "how much faster are orders released, and how often did analysts overrule it?"

#Questions to ask when you hire or staff an FDE

• What business metric will this person own, and how is it measured today?
• Can they show an AI system they built that is running in production, not just a demo?
• How would they decide between a standard SAP AI feature and a custom build?
• How do they handle SAP authorizations when an AI agent acts on a user's behalf?
• How will they know, three months after go-live, that the solution still works?

#Common misconceptions

• "An FDE is a senior developer with a new title." The defining trait is owning a business outcome and doing discovery, not seniority in code.
• "We need an FDE for every AI use case." Many use cases are covered by SAP's embedded AI features. An FDE earns their cost where standard features don't fit or several systems must work together.
• "FDEs replace consultants." They absorb part of the consultant's role, but large programs still need functional, change and project roles.

#Key terms

• Forward deployed engineer (FDE): an engineer embedded with a customer who owns an outcome end to end.
• Clean core: keeping SAP's standard code unmodified and building extensions outside or through released interfaces.
• Agent: an AI system that can take actions through tools, not just answer questions.
• Human in the loop: a design where a person approves or corrects the AI's action before it takes effect.

#Check yourself

#Mental model: an FDE owns a number

Every serious FDE engagement can be written as one sentence: "Move metric M in process P from X to Y by date D, without breaking constraints C." Everything else, including the model, the framework and the SAP product, is a means to that end.

That sentence forces three things most AI pilots skip. There is a baseline (X), so improvement can be proven. There is a process owner who cares about M, so someone will use the result. And there are constraints named up front, so the architecture respects security, clean core and cost from day one.

flowchart LR
  A[Understand the business] --> B[Define the problem and metric]
  B --> C[Design the AI approach]
  C --> D[Build within constraints]
  D --> E[Deploy to production]
  E --> F[Own and improve the outcome]
  F -. new evidence .-> B

The loop matters because the first problem statement is usually wrong. Real usage data after deployment routinely changes what "the problem" is, so an FDE keeps the loop turning instead of handing over a deliverable.

#The first architecture decision: where should the AI live?

For any SAP use case, the most consequential early choice is where the intelligence runs. Roughly from least to most custom:

flowchart TD
  Q{Does a standard SAP AI feature<br/>already cover the need?} -->|Yes| S[Use embedded AI in the SAP application]
  Q -->|No| J{Is it a conversational or agentic task<br/>inside SAP's user experience?}
  J -->|Yes| K[Extend Joule: skills or a Joule agent]
  J -->|No| B{Does it need SAP data and processes<br/>with custom logic or models?}
  B -->|Yes| T[Side-by-side on SAP BTP<br/>with SAP's AI foundation services]
  B -->|No, SAP is one of many systems| O[Build outside SAP,<br/>calling SAP through released APIs]

Later units cover each option in depth: Joule and agents in Unit 9, SAP's AI foundation services in Units 5 and 7, and buy versus build in Unit 12.

#A first prototype in an afternoon: triaging blocked sales orders

FDEs build early, on real or realistic data, to test whether the problem is what everyone thinks it is. In this section you build a small program that does three things:

1. Reads sales orders from SAP. SAP runs a free public test system, the sandbox of the SAP Business Accelerator Hub (api.sap.com). It holds demo sales orders you can read without owning an SAP system.
2. Finds the blocked ones. An order is "blocked" here if it has a delivery block or a billing block.
3. Optionally asks an AI model to draft a note for each blocked order, which a human analyst then reviews.

flowchart LR
  A[Your computer<br/>triage.py] -->|read orders| B[SAP sandbox<br/>Sales Order API]
  B -->|order data| A
  A -->|optional: one order| C[AI model]
  C -->|draft note| A
  A --> D[Analyst reviews]

No prior coding experience is assumed. Follow the steps in order. Plan on about an hour the first time.

#What you need

• A computer with Windows, macOS or Linux, and an internet connection.
• A free SAP account (Step 4 shows how to get one).
• For the optional AI step only: an account with a model provider. The example uses Anthropic's Claude API, which charges a small amount per request. Any provider works.

#Step 1: Install Python and open a terminal

Python is the programming language the script is written in.

1. Install Python:

   • Windows: open the Microsoft Store, search for Python Install Manager and install it. The first time you run python in step 4, it installs the latest Python; if it asks to add a folder to your PATH, answer yes.
   • macOS: download the macOS installer from python.org/downloads and run it with the defaults.

2. That's the only install for now; the rest happens in the terminal.

3. Open a terminal:

   • Windows: press the Windows key, type PowerShell, press Enter.
   • macOS: press Cmd+Space, type Terminal, press Enter.

4. Check that Python works. Type this and press Enter:

   Copy

   python --version

   You should see something like Python 3.14.4. On macOS or Linux, if you get "command not found", use python3 instead of python in every command below.

#Step 2: Make a project folder

A folder keeps the script and its libraries together. A virtual environment is a private copy of Python for this folder, so installs here don't affect anything else.

1. Create the folder and move into it:

   Copy

   mkdir sap-triage
   cd sap-triage

2. Create the virtual environment:

   Copy

   python -m venv .venv

3. Turn it on (you'll do this every time you open a new terminal for this project):

   • Windows (PowerShell): .venv\Scripts\Activate.ps1
   • macOS / Linux: source .venv/bin/activate

   Your prompt now starts with (.venv). That's how you know it's on.

#Step 3: Install the two libraries

Libraries are ready-made code. requests talks to web APIs such as SAP's. anthropic talks to the AI model (only needed for Step 8).

pip install requests anthropic

Wait until you see "Successfully installed".

#Step 4: Get your free SAP sandbox API key

1. Go to api.sap.com and click Log On at the top right. If you have no SAP account, choose to register; it's free.
2. Once logged on, use the search box to find Sales Order (A2X). This is the standard S/4HANA Cloud API for sales orders; its technical name is API_SALES_ORDER_SRV. Open it.
3. Near the top of the API page, click Show API Key.
4. In the pop-up, click Copy Key and Close. Paste the key into a notepad for the next step.

#Step 5: Give the key to your terminal

You store the key in an environment variable, a named value the terminal hands to programs you run. Replace paste-your-key-here with your key, keeping the quotes.

• Windows (PowerShell):

  Copy

  $env:SAP_API_KEY = "paste-your-key-here"

• macOS / Linux:

  Copy

  export SAP_API_KEY="paste-your-key-here"

This lasts until you close the terminal. In a new terminal, repeat Steps 2.3 and 5.

#Step 6: Save the script

1. Open any plain-text editor. Visual Studio Code is free and helpful; Notepad (Windows) or TextEdit in plain-text mode (macOS) also work.
2. Copy the whole script below (the Copy button appears when you hover over it).
3. Save it as triage.py inside your sap-triage folder.

"""Triage blocked sales orders: read from SAP, draft notes with an LLM, keep a human in the loop.

How to run (from the folder that holds this file):
  python triage.py            read orders from the SAP sandbox and count blocked ones
  python triage.py --sample   use three made-up orders instead (no SAP key needed)
  python triage.py --llm      also ask a language model to draft a note per blocked order
"""
import json
import os
import sys

import requests

try:  # read keys from a .env file if you set one up (see "Set up your computer")
    from dotenv import load_dotenv
    load_dotenv()
except ImportError:
    pass  # no python-dotenv: keys come from the terminal (Step 5)

# Where the SAP sandbox lives, and which API and entity we read.
BASE = "https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_SALES_ORDER_SRV"
HOW_MANY = 100  # how many orders to read; raise it if you find no blocked orders

# The sales order header fields we ask SAP for.
FIELDS = [
    "SalesOrder", "SoldToParty", "TotalNetAmount", "TransactionCurrency",
    "RequestedDeliveryDate", "OverallSDProcessStatus", "TotalCreditCheckStatus",
    "OverallTotalDeliveryStatus", "DeliveryBlockReason", "HeaderBillingBlockReason",
]

# Made-up orders for practice. The codes are placeholders, not real SAP meanings.
SAMPLE_ORDERS = [
    {"SalesOrder": "9000001", "SoldToParty": "CUST-A", "TotalNetAmount": "18250.00",
     "TransactionCurrency": "USD", "RequestedDeliveryDate": "2026-10-05",
     "OverallSDProcessStatus": "A", "TotalCreditCheckStatus": "B",
     "OverallTotalDeliveryStatus": "A", "DeliveryBlockReason": "01",
     "HeaderBillingBlockReason": ""},
    {"SalesOrder": "9000002", "SoldToParty": "CUST-B", "TotalNetAmount": "940.00",
     "TransactionCurrency": "USD", "RequestedDeliveryDate": "2026-10-02",
     "OverallSDProcessStatus": "B", "TotalCreditCheckStatus": "",
     "OverallTotalDeliveryStatus": "B", "DeliveryBlockReason": "",
     "HeaderBillingBlockReason": "02"},
    {"SalesOrder": "9000003", "SoldToParty": "CUST-C", "TotalNetAmount": "5100.00",
     "TransactionCurrency": "USD", "RequestedDeliveryDate": "2026-10-09",
     "OverallSDProcessStatus": "C", "TotalCreditCheckStatus": "",
     "OverallTotalDeliveryStatus": "C", "DeliveryBlockReason": "",
     "HeaderBillingBlockReason": ""},
]


def fetch_orders(top: int = HOW_MANY) -> list:
    """Read sales order headers from the SAP sandbox (read-only)."""
    key = os.environ.get("SAP_API_KEY")
    if not key:
        sys.exit("SAP_API_KEY is not set. Go back to Step 5, or run with --sample.")
    headers = {"APIKey": key, "Accept": "application/json"}
    params = {"$top": str(top), "$select": ",".join(FIELDS), "$format": "json"}
    resp = requests.get(f"{BASE}/A_SalesOrder", headers=headers, params=params, timeout=30)
    if resp.status_code in (401, 403):
        sys.exit(f"SAP refused the request (HTTP {resp.status_code}). Copy the key again in Step 4.")
    resp.raise_for_status()  # stop with a clear error on any other failure
    return resp.json()["d"]["results"]  # where OData v2 puts the list of records


def is_blocked(order: dict) -> bool:
    """An order counts as blocked if either block field has a value."""
    return bool(order.get("DeliveryBlockReason") or order.get("HeaderBillingBlockReason"))


SYSTEM = (
    "You help credit and order-management analysts. For the sales order provided, "
    "explain in one or two sentences why it is likely blocked and suggest the next check. "
    "Use only the fields given. Block and status values are codes; do not guess their meaning. "
    "If the data is insufficient, say so. "
    'Reply with JSON only: {"order": str, "likely_cause": str, "next_check": str, '
    '"confidence": "low"|"medium"|"high"}'
)


def call_llm(system: str, user: str) -> str:
    """Send one request to a language model and return its text reply.

    Uses Anthropic's Python SDK. To use another provider, replace only this function.
    """
    import anthropic  # imported here so the SAP-only part runs without it

    client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from the environment
    message = client.messages.create(
        model=os.environ.get("LLM_MODEL", "claude-opus-5-5"),
        max_tokens=400,
        system=system,
        messages=[{"role": "user", "content": user}],
    )
    return "".join(block.text for block in message.content if block.type == "text")


def parse_json(text: str) -> dict:
    """Pull the JSON object out of the model's reply, even if it adds extra words."""
    start, end = text.find("{"), text.rfind("}")
    if start == -1 or end == -1:
        return {"error": "model did not return JSON", "raw": text}
    try:
        return json.loads(text[start:end + 1])
    except json.JSONDecodeError:
        return {"error": "model returned invalid JSON", "raw": text}


def triage(order: dict) -> dict:
    note = parse_json(call_llm(SYSTEM, json.dumps(order)))
    note["status"] = "awaiting_review"  # the analyst decides; the AI only drafts
    return note


def main() -> None:
    args = sys.argv[1:]
    if "--sample" in args:
        orders, source = SAMPLE_ORDERS, "made-up sample orders"
    else:
        orders, source = fetch_orders(), "SAP Business Accelerator Hub sandbox"

    blocked = [o for o in orders if is_blocked(o)]
    print(f"Source: {source}")
    print(f"{len(blocked)} of {len(orders)} orders have a delivery or billing block\n")
    if not blocked:
        print("No blocked orders in this batch. Raise HOW_MANY, or try --sample.")

    for order in blocked[:5]:
        print(json.dumps({k: order.get(k) for k in FIELDS}, indent=2))
        if "--llm" in args:
            print("Draft note for the analyst:")
            print(json.dumps(triage(order), indent=2))
        print("-" * 40)


if __name__ == "__main__":
    main()

#Step 7: Run it against SAP

Make sure your terminal is still in the sap-triage folder with (.venv) showing, then run:

python triage.py

You should see something like this (numbers and orders will differ, because the sandbox is shared and its data changes):

Source: SAP Business Accelerator Hub sandbox
3 of 100 orders have a delivery or billing block

{
  "SalesOrder": "...",
  "SoldToParty": "...",
  ...
  "DeliveryBlockReason": "...",
  "HeaderBillingBlockReason": ""
}
----------------------------------------

That first line is the most important output: a count, from real API data, of how many orders are blocked. It is the start of a baseline.

If you see 0 of 100, that's a valid result, not an error. Change HOW_MANY = 100 near the top of the script to 500, save and run again. To see what the rest of the program does in the meantime, run python triage.py --sample, which uses three made-up orders instead of SAP.

#Step 8 (optional): Draft triage notes with an AI model

1. Create an account in the Claude Console, add a small amount of credit, and create an API key. (Using another provider? Replace only the call_llm function; nothing else changes.)

2. Give the key to your terminal, as in Step 5:

   • Windows: $env:ANTHROPIC_API_KEY = "paste-your-key-here"
   • macOS / Linux: export ANTHROPIC_API_KEY="paste-your-key-here"

3. Run with the --llm option. Add --sample if SAP returned no blocked orders:

   Copy

   python triage.py --llm

Under each blocked order you now get a draft note with a likely cause, a next check, a confidence level and "status": "awaiting_review". The script sends at most five orders to the model, so a run costs very little. The model name is set in the script; you can override it with an LLM_MODEL environment variable.

#What each part of the script does

#If something goes wrong

#Why the script is built this way

Three choices in this small script are deliberate FDE habits:

1. It measures before it predicts. The first output is a count of blocked orders. That count is the start of your baseline.
2. It constrains the model. The prompt limits the model to the fields supplied, tells it not to guess code meanings, asks it to admit when data is insufficient, and fixes an output format you can check.
3. It keeps a human in the loop. Every note starts as awaiting_review. Automation comes later, once evaluation shows where the AI is reliably right.

#From prototype to production

A prototype that impresses in a demo is roughly a fifth of the work. The rest is what makes an SAP FDE different from a hackathon team:

• Authorizations. An agent acting for a credit analyst must see only what that analyst may see. That rules out a shared technical user with broad rights and points toward propagating the end user's identity to SAP (Unit 11).
• Grounding. Real triage needs more than header fields: open items, payment history, customer notes. Getting that data safely is a retrieval and integration problem (Unit 7).
• Evaluation. Build a set of past orders with known correct outcomes and score every change against it, so you can prove improvement and catch regressions (Unit 8).
• Operations. Log every AI decision with its inputs, track cost per order and latency, and have a runbook for when quality drops (Unit 10).
• Clean core. Use released APIs and extension points only, so the customer's next SAP upgrade doesn't break your solution.
• Adoption. Put the output where analysts already work, measure how often they accept or override it, and treat overrides as your most valuable training signal.

#The SAP FDE skills stack

SAP's own FDE job postings describe the target well. The associate role asks for strong Python, a basic understanding of LLMs, prompt engineering, embeddings and RAG, exposure to agent frameworks, and APIs, Git and containers, with SAP BTP, SAP AI Core or Joule listed as a plus. The senior role adds enterprise architecture, knowledge graphs, MCP, tool calling, evaluation and AI observability.

The rare combination, and the reason this curriculum pairs every AI topic with its SAP counterpart, is the middle: people who understand the AI deeply and know how SAP data, security and processes actually behave.

#Pitfalls

• Starting from the technology. "Let's use agents" is not a problem statement. Start from the metric.
• Demo data that hides the hard part. Sandbox data is clean; production has duplicates, missing fields and odd configurations. Get a realistic sample early.
• No baseline. If you didn't measure hold time before go-live, you can't prove the AI helped.
• Automating the decision too early. Draft, then recommend, then automate, each step earned by evaluation results.
• Ignoring the standard feature. Check what SAP already ships before building. A custom build the customer must maintain is a cost.

#Exercise: frame and prototype one use case

Pick one SAP process you know (or use blocked sales orders).

1. Write the one-sentence FDE statement: metric, process, baseline, target, date, constraints.
2. Walk the architecture decision above and write two sentences on why you chose where the AI lives.
3. Follow Steps 1–7 of the prototype and record how many orders are blocked in your sample.
4. Follow Step 8 to draft notes for up to five blocked orders. Judge each note as right, partly right or wrong, and write one sentence on why.

Done when: you have the statement, the decision record, a count from real API data, and five judged triage notes. That small judged set is the seed of your evaluation set in Unit 8.

#Check yourself