Automatizare SAP cu AI: patterns reale pentru S/4HANA și SuccessFactors

SAP e arhitectura pe care merge o parte semnificativă din economia României, dar rămâne unul dintre sistemele cu cea mai mare distanță între datele pe care le conține și ușurința cu care un om de business le poate accesa. Combinarea cu Claude e aproape evidentă odată ce înțelegi pattern-urile.

Articolul ăsta tratează automatizările reale (nu demo-uri) pe care le construim la Ran·AI: cum integrezi Claude cu SAP ECC, S/4HANA, și SuccessFactors, ce arhitecturi funcționează, și ce am învățat construind un POC de extracție master data condus de un agent conversațional.

De unde vine valoarea

Echipele SAP din organizațiile mari petrec un volum disproporționat de timp pe sarcini cu valoare scăzută: căutarea unei tranzacții potrivite în SE93, citirea documentației SAP Help pentru parametri de BAPI, exportul unei liste de materiale pentru un raport ad-hoc, traducerea unei cerințe de business în SQL pe SAP HANA Studio. Asta nu cere expertiza unui consultant SAP senior. Cere răbdarea de a parcurge o mulțime de ferestre similare.

Claude integrat cu SAP nu înlocuiește consultantul senior. Înlocuiește pașii de navigare. Consultantul senior scrie regulile, definește tool-urile, validează rezultatele. Claude execută secvența pe care un junior ar executa-o în două ore.

Cele trei pattern-uri principale

Din ce am construit până acum, automatizările SAP × AI se încadrează în trei pattern-uri principale. Diferența dintre ele e cine inițiază interacțiunea și cât de mult se deleagă.

Pattern 1: Extracție conversațională condusă de agent. Utilizatorul descrie ce vrea în limbaj natural. Claude folosește un set de tool-uri care wrappează BAPI-uri pentru a descoperi structura organizațională, a construi criteriile de selecție, a estima volumele, și a executa extracția cu confirmarea utilizatorului. Acesta e pattern-ul folosit în ECC Extractor, POC-ul nostru intern.

Pattern 2: Agent care navighează tranzacții cu confirmare umană. Utilizatorul descrie o operație ("transferă materialul X de la depozitul A la depozitul B, cu motivul Y"). Claude propune tranzacția SAP relevantă (MIGO, MB1B, sau echivalent), completează câmpurile din date pe care le citește din alte surse (master data, documente sursă), și prezintă pe ecran ce ar urma să se întâmple. Utilizatorul confirmă, agentul execută. Niciodată fără confirmare pentru acțiuni cu efect.

Pattern 3: Conversational front pentru sisteme HR și self-service. Aplicabil la SuccessFactors, ServiceNow, Workday. Angajatul întreabă "câte zile de concediu mai am și cum aplic pentru două săptămâni în august?" și agentul folosește API-ul HR pentru a răspunde și a iniția procesul. Citește politici de pe Confluence sau SharePoint, completează formularul, prezintă draft-ul pentru confirmare.

Pattern 1 în detaliu: extracție conversațională din ECC

ECC Extractor e POC-ul intern pe care l-am construit la Ran·AI pentru a valida ideea că un agent Claude poate înlocui munca repetitivă de extracție master data din SAP ECC. În loc de batch extraction oarbă, agentul descoperă structura organizațională, ajută să încadrezi criteriile de extracție, și execută cu confirmare.

Arhitectura simplificată:

Browser (React)               Spring Boot                   SAP ECC
+--------------+              +----------------+              +-------+
| Chat panel   |              | AgentLoop      |              |       |
| Org tree     |---SSE--------|   Claude API   |              |       |
| Job dashboard|              |   ToolExecutor |---RFC--JCo-->| BAPIs |
| Login screen |---POST------>| RfcService     |              |       |
+--------------+              +----------------+              +-------+
                                     |
                                     v
                              H2 / PostgreSQL
                              (extracted data)

Componentele cheie:

• 8 tool-uri definite pentru Claude, fiecare wrappând una sau mai multe BAPI: test_connection, discover_org_structure, list_data, get_detail, count_records, start_extraction, get_extraction_status, preview_extracted_data.
• System prompt cu BAPI reference: Claude primește în promptul sistem documentația pentru BAPI-urile relevante, structura câmpurilor lor și exemple de criterii de selecție.
• Sesiune per utilizator: utilizatorul își aduce propriile credențiale SAP la runtime. Niciodată hardcodat. JCo destination e creat dinamic per sesiune.
• Mock mode pentru dezvoltare: o implementare paralelă a serviciului RFC care răspunde din fișiere JSON locale. Permite dezvoltarea fără un sistem SAP la dispoziție.
• Streaming SSE pentru chat: răspunsurile Claude vin în timp real în interfață, inclusiv pașii intermediari de tool use.

Utilizatorul tipic deschide aplicația, introduce credențialele SAP, întreabă "câte materiale tip ROH avem în plant 1000?". Claude apelează count_records, răspunde cu un ordin de mărime, propune criteriile de selecție pentru extracție, întreabă confirmare. La OK, pornește start_extraction, care rulează în fundal cu un job ID pe care utilizatorul îl poate verifica.

Lecții reale construind acest POC

Câteva lucruri specifice pe care le-am învățat și pe care le vei întâlni dacă faci ceva similar:

Verifică semnăturile BAPI înainte de a coda. Documentația comunității și unele rezumate AI-generated conțin nume greșite sau parametri inexistenți. Exemplu real pe care l-am întâlnit: BAPI-ul corect pentru lista de conturi GL e BAPI_GL_ACC_GETLIST, nu BAPI_GL_ACCOUNT_GETLIST cum apare în unele surse. La fel, parametrii MAXROWS, GLACCTRANGE, GLACCTGROUPRANGE nu există pentru acest BAPI. Verifică pe sapdatasheet.org sau în SE37 pe sistemul țintă.

Mock mode poate crea încredere falsă. Dacă mock-ul tău folosește numele greșit de BAPI și răspunde cu fișierul corespunzător, codul tău va părea că merge perfect până când lovești sistemul real. Lecția: numește fișierele mock cu numele real al BAPI, nu cu ce presupune codul tău.

Spring @Async self-invocation e silențios. Apelarea unei metode marcate @Async din interiorul aceluiași bean ocolește proxy-ul Spring și rulează sincron, fără niciun warning. Pentru un job de extracție de minute, asta înseamnă că thread-ul HTTP blochează până la final. Soluția e simplă: pune metoda async într-un bean separat. Bug-ul nu e: documentat în Spring de mai bine de un deceniu, dar ușor de ratat.

SseEmitter nu e thread-safe. Documentația Spring nu spune asta clar dar e un issue deschis (#17815). Dacă mai multe thread-uri trimit simultan pe același emitter, datele se pot intercala. Sincronizează send-urile.

Tool use cu Claude are reguli stricte de ordonare. Fiecare bloc tool_use trebuie să aibă un tool_result corespondent în următorul mesaj user. Toate tool_result-urile pentru apeluri paralele trebuie să fie într-un singur mesaj user. Trimming-ul istoricului trebuie să păstreze perechi tool_use + tool_result. Flag-ul is_error: true pe rezultatele eșuate ajută modelul să înțeleagă ce s-a întâmplat și să decidă ce să facă în continuare.

BAPI-urile de listare nu returnează numărul total de înregistrări. Cel mai bun pe care îl poți face e MAXROWS=1 și o estimare. Pentru un agent care vrea să întrebe "câte sunt?" înainte de a extrage, trebuie să fii explicit că răspunsul e un ordin de mărime, nu o cifră exactă.

Pattern 2: agent care propune tranzacții cu confirmare

Următorul pas dincolo de extracție e agentul care propune acțiuni care modifică sistemul: creează un material nou, înregistrează o mișcare de stoc, postează un document financiar. Aici riscul crește. Câteva principii pe care le respectăm:

Niciodată acțiune fără confirmare umană. Agentul construiește payload-ul, îl prezintă ca diff sau ca preview, așteaptă confirmare explicită. Pentru BAPI care suportă TEST_RUN = 'X', rulează simularea înainte și prezintă rezultatul.

Roluri SAP minime pentru agent. Contul de service al agentului are doar permisiunile necesare pentru tranzacțiile aprobate. Niciodată SAP_ALL pe un cont care primește input dintr-un LLM.

Audit log al fiecărui apel. Cine a întrebat, ce a întrebat, ce a propus Claude, ce a confirmat utilizatorul, ce s-a executat efectiv, ce a returnat SAP-ul. La nevoie pentru compliance, pentru debugging, și pentru evaluarea calității.

Idempotență pe cât posibil. Dacă utilizatorul confirmă de două ori accidental, sistemul tău trebuie să detecteze și să nu execute de două ori. Un ID idempotent generat pe client funcționează bine.

Pattern 3: conversational HR și self-service

Aici Microsoft 365 Copilot și soluțiile vendor-locked sunt competiție serioasă. Avantajul unui agent custom e că poate citi politici de pe Confluence, întreba HR în background, și completa formularul în SuccessFactors într-un singur flux conversațional, ceea ce soluțiile out-of-the-box nu fac bine la nivel de personalizare.

Pattern-ul tehnic e similar cu pattern 2: agentul are tool-uri pentru API-uri (Graph, SuccessFactors OData, ServiceNow Table API), un retrieval peste politicile de companie, și un flow de confirmare înainte de orice acțiune cu efect.

Lecția cea mai importantă pentru HR: utilizatorul final nu e tehnic. Răspunsurile trebuie să fie scurte, citările trebuie să fie clare, formularele propuse trebuie să fie pe limba utilizatorului. Promptul sistem face mult.

Ce încă nu funcționează bine

Onestitate tehnică pentru cititorii care evaluează ce să implementeze în 2026:

Agenți complet autonomi pe tranzacții cu efect financiar. Nu suntem acolo. Riscul de greșeli sistematice e prea mare. Pattern-ul "confirmare la fiecare pas" rămâne necesar pentru orice operație care creează documente contabile sau modifică stocuri.

Analiză peste tot peisajul de date SAP simultan. Un agent care răspunde cross-module (FI + MM + SD într-o singură întrebare) tinde să se piardă în volume mari de date. Soluția curentă: agenții specializați per modul, cu un coordonator care orchestreză.

SAP GUI clasic și Web Dynpro vechi. Există tools de tip browser automation care pot click prin SAP GUI, dar fiabilitatea e scăzută. Preferă BAPI și OData oriunde există. Pentru tranzacții fără API, ridică o cerere de wrapping la echipa ABAP.

Unde se duce asta în următoarele 12 luni

Câteva direcții pe care le urmărim și pe care le construim la Ran·AI:

Pipeline de transformare extracție → migrare. După ce agentul extrage master data, pasul logic următor e generarea fișierelor LTMC sau LSMW pentru migrare în S/4HANA. Asta e pe roadmap-ul ECC Extractor după ce POC-ul e stabil.

Delta extraction. În loc să re-extragi totul, agentul detectează ce s-a schimbat și actualizează doar delta. Mecanism util pentru integrări continue.

Multi-agent pe procese complete. Un agent care orchestreză agenți specializați (FI agent, MM agent, HR agent) și care coordonează un proces business complet (de exemplu month-end close) cu confirmări la pașii cheie.

MCP servers pentru sisteme SAP complete. Cea mai elegantă formă de wrapping. Un MCP server expune tranzacțiile, BAPI-urile, query-urile peste o aplicație SAP, și orice client compatibil (Claude Desktop, Claude Code, alt agent) îl folosește uniform. La Ran·AI am construit MCP servers care dau Claude control complet de aplicații custom, iar pattern-ul se transferă natural către SAP.

Același acces de citire la sistem poate documenta starea actuală pentru o cerere de modificare și poate scrie un prim draft de specificație, pattern pe care l-am descris în articolul despre spec automat pentru modificări SAP cu agenți AI.

Cum începi practic

1. Alege o operație repetitivă concretă care consumă timp astăzi (de exemplu, extragerea unui raport săptămânal de materiale active pe plant).
2. Identifică BAPI-urile sau OData services-urile care răspund la întrebare. Validează semnăturile pe sapdatasheet.org sau în SE37.
3. Construiește un prototip de o săptămână cu mock mode. Verifică că agentul produce output-ul corect pe scenarii cunoscute.
4. Conectează la sistemul de dev. Validează că tool use-ul cu BAPI-uri reale produce aceleași rezultate ca varianta mock.
5. Adaugă confirmări, audit log, gestionarea erorilor. Apoi un grup pilot.

Dacă vrei o discuție concretă despre integrarea Claude cu sistemul tău SAP, scrie-ne la contact@ranresults.com. Mulți dintre noi am lucrat ani de zile pe SAP înainte de era LLM, ceea ce ne diferențiază de echipele care vin doar din partea AI și nu înțeleg particularitățile sistemelor pe care vor să le integreze.