AI chatbotSAP ECC 6.0 Agent view

How to add an AI chatbot to SAP ECC 6.0

Short answer

An ECC chatbot is a chat interface that answers from live SAP data and your documents, respecting each user's role. You connect it to ECC through RFC or OData tools, ground it with retrieval over manuals and SOPs, and embed it in the intranet, a Teams tab or a customer portal. An open-weight model can run it entirely inside your plant network.

ECC users know the pain of finding a number: which transaction, which selection screen, which variant, and then which column. New planners and customer service reps need weeks to learn this. A chatbot that understands "what is the status of order 4500012345" or "show open POs for vendor 10045" removes a lot of that friction.

The hard part is trust. A chatbot that guesses is worse than no chatbot. It has to pull answers from the system rather than from model memory, show where the number came from, and refuse when it does not know.

This page is about the chatbot as a user-facing product. For the tool layer underneath, see the MCP server and AI agents pages for this system.

What teams use it for

Internal planner assistant

Planners ask about stock, supply, demand and open orders in plain language and get a table plus a link to the matching SAP transaction (MD04, MB52, ME2N).

Customer order status portal chat

External customers authenticate to a portal and ask about their own orders and shipments. The bot reads from a restricted order status service, never from open tables.

How do I do this in SAP? helper

Retrieval over your own SOPs and transaction guides answers questions such as how to post a scrap in MIGO or release a production order, in your company's own words.

Supplier self-service

Suppliers ask when a PO is needed, what the open quantities are or where to send an ASN, with answers limited to their vendor number.

Maintenance and spare parts help

Technicians ask for the part number, stock location and open reservation for a piece of equipment from PM and MM data.

SAP ECC 6.0 integration surface

  • RFC-enabled BAPIs and Z function modules called from a chatbot back end, with PyRFC or node-rfc, for live lookups under a restricted technical user.
  • SAP Gateway OData services (SEGW) if you want a REST-style surface for a web chatbot, hosted on the Gateway server with SICF nodes activated.
  • Role information from ECC: user master (SU01), role assignments (AGR_USERS) and organizational data, used to decide what each chatbot user may ask. Many sites instead map from Active Directory groups.
  • SAP GUI for HTML or SAP Fiori launchpad (where installed on ECC with a front-end server) as places to link back to, so the chatbot can open the right transaction.
  • Document stores: SAP DMS (CV01N, CV03N), SharePoint, or a file share, indexed for retrieval separately from live data.

How it works

  1. 1

    Define who the first audience is

    Pick internal planners or customer service first. An external chatbot has a very different threat model than an internal one.

  2. 2

    Separate live data from knowledge

    Live facts (stock, status) come from tools. Policies and how-to content come from retrieval over indexed documents. Do not mix them in one vector store.

  3. 3

    Map users to permissions

    Authenticate with SSO, map the user to allowed plants, vendors or customers, and enforce those filters in the tool layer, not in the prompt.

  4. 4

    Build answers that cite

    Return the figure, the unit, the as-of time and the source (for example, "from ECC, plant 1000, read at 09:12"). Offer a deep link to the SAP transaction.

  5. 5

    Add a hand-off path

    When the bot cannot answer, route to a human with the conversation attached, so the question does not die.

  6. 6

    Choose the front end

    Embed in an intranet, a Teams tab, a customer portal or the SAP Fiori launchpad where available. Keep the same back end for all of them.

  7. 7

    Review transcripts weekly

    Read failed and corrected conversations to improve tool descriptions, glossary terms and retrieval content.

Example flows

Customer asks about a delivery

Trigger: A customer types "Where is my shipment for PO 7788?" in the portal.

  1. The bot resolves the customer from the login and the PO number from the message.
  2. It calls the order status tool, which checks the customer's ownership of the order.
  3. It reads delivery and goods issue status and the carrier tracking reference if available.
  4. It answers with status and expected date, offering to email the packing list.

Result: The customer gets an immediate answer; customer service sees fewer status-only emails.

New planner asks how to expedite

Trigger: A new MRP controller asks "How do I move out a planned order?"

  1. The bot searches indexed SOPs for the relevant procedure.
  2. It answers with the company's steps and the transaction (for example MD04 or MD05 context) to use.
  3. It offers to look up the specific material the user mentions.

Result: Faster onboarding and fewer interruptions to senior planners.

Keeping data on-prem

A chatbot over ECC is a natural on-prem build. Run the chat front end, the tool back end and an open-weight model (Llama, Qwen, Mistral, Gemma or gpt-oss class) on your own servers using vLLM or Ollama, in the same network zone as the application server. Retrieval content stays in a local vector database and nothing about your orders, vendors or drawings leaves the plant. For external customer or supplier chat, place only the front end in a DMZ and keep the model and ERP connection internal, passing narrow, pre-authorized requests. Expect to size GPU capacity for peak concurrent users, and plan for a smaller model on routine lookups with a larger one reserved for harder questions.

Security checklist

  • Enforce data scope (plant, customer, vendor) in the tool layer using the authenticated identity, never by instructing the model.
  • Do not let the bot answer pricing, margin or contract questions unless the user's role clearly allows it.
  • Defend against prompt injection from free-text fields such as vendor notes and PO texts.
  • Log conversations and tool calls; define retention and who may review them.
  • For external chat, rate-limit, add bot protection and keep a separate narrow service account.

Ways to get it done

Vendor assistant (Joule or a portal chat tool)

Effort: Low to medium plus licensing.

If most of your processes are already in SAP's cloud products; limited reach into ECC custom objects.

Build with an open-source chat UI and your tools

Effort: Three to six weeks for a pilot with SSO and retrieval.

In-house teams comfortable with a Python or TypeScript stack and an LLM server.

Netray on-prem assistant

Effort: A scoped pilot, then expand by department.

When you need role-aware answers grounded in ECC and documents with a private model and a pilot with real users.

Pitfalls

  • !Letting the bot answer from memory when the tool fails. It must say it could not retrieve the data.
  • !Ignoring multilingual users; plant staff may ask in Spanish, German or Hindi while master data is in English.
  • !Not handling material number formats and plant-specific descriptions, so searches miss.
  • !Over-promising. Start with five question types and widen based on real usage.
  • !No feedback button, so wrong answers are never reported.

Frequently asked questions

Can a chatbot read live data from SAP ECC?

Yes, through RFC-enabled BAPIs or OData services under a restricted technical user. The chatbot should call these as tools and show the source and time, rather than relying on exported or cached data that may be stale.

Can it run without sending data to the cloud?

Yes. An open-weight model on your own GPUs can power it, with the ERP connection and document index also local. Quality is good for lookup and summarization; very complex reasoning may need a larger model.

How do we keep users from seeing other plants' data?

Map each user to permitted plants or customers at login and apply those filters inside the tool functions. Also keep ECC authorizations on the technical user as a second layer.

Is the vendor's built-in assistant enough?

If you are on S/4HANA with SAP's cloud services, it may cover standard processes. For ECC 6.0 with custom Z-transactions and mixed document sources, a custom chatbot usually answers more of the real questions.

What does a pilot look like?

Typically one department, five to ten question types, read-only tools, SSO, and a feedback button. Run it for a few weeks, review transcripts, and decide what to add based on actual use.

Want AI chatbot working on your SAP ECC 6.0?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment