Spec automat pentru modificări SAP cu agenți AI

Într-un proiect SAP, o modificare mică trece prin mai mulți oameni decât pare. Cineva din business cere o schimbare, un consultant funcțional o transformă în specificație, un dezvoltator ABAP scrie specificația tehnică și codul, altcineva testează, iar un comitet aprobă transportul spre producție. Specificația funcțională e documentul pe care se sprijină toți ceilalți pași. Tot ea e, de obicei, partea scrisă cel mai în grabă.

Articolul ăsta descrie cum pot agenți AI să preia partea mecanică a acestei munci: să adune contextul din sistem, să scrie un prim draft de specificație pentru o modificare SAP și să verifice un draft scris de un om. Tratăm ECC și S/4HANA, felul în care procesul se leagă de change management și limitele pe care le punem ca să nu ajungă în producție o specificație pe care n-a citit-o nimeni. Pentru contextul general al integrării Claude cu SAP, vezi articolul nostru despre automatizare SAP cu AI.

De ce specificația e gâtul de sticlă

O specificație funcțională bună cere două lucruri diferite. Primul e judecata: ce vrea de fapt business-ul, ce reguli se aplică, ce excepții contează. Al doilea e documentarea stării actuale: ce configurare există, ce tabele și câmpuri sunt implicate, ce obiecte custom ating deja procesul, ce s-a mai modificat în zonă în ultimii ani.

A doua parte consumă cel mai mult timp și e cea mai ușor de sărit. Un consultant cu experiență știe unde să caute, dar caută manual: SPRO, SE11, SE16N, lista de transporturi, specificațiile vechi din SharePoint sau Confluence, dacă mai există. Când proiectul are zeci de cereri deschise, secțiunea despre starea actuală ajunge să fie copiată din template și completată pe jumătate.

Consecințele apar mai târziu și costă mai mult. Dezvoltatorul descoperă un user exit pe care nu-l menționa nimeni. Testarea găsește un impact în alt modul. Modificarea se întoarce la analiză după ce trecuse deja de aprobare.

Ce înseamnă concret un spec automat

„Spec automat” poate însemna lucruri foarte diferite. În materialele în engleză apare des ca automated SAP change spec și acoperă orice, de la un template completat de un chatbot până la generare de cod. Noi folosim termenul pentru două sarcini precise:

1. Draft de specificație. Pornind de la o cerere de modificare (ticket, e-mail, notițe dintr-un workshop), agentul adună contextul tehnic din sistem și din documentația existentă și produce un draft structurat după template-ul echipei. Fiecare afirmație despre starea actuală are o sursă: un tabel, un obiect, un transport, un document.
2. Review de specificație. Pornind de la o specificație scrisă de un consultant, agentul o verifică pe o listă de control și o compară cu sistemul. Obiectele menționate există? Lipsesc impacturi evidente? Sunt definite criteriile de acceptanță?

În niciunul dintre cazuri agentul nu aprobă nimic, nu creează transporturi și nu scrie în sistem. Produce un document și o listă de observații pe care le citește un om.

Ce citește agentul

Calitatea draftului depinde aproape integral de contextul pe care agentul îl poate citi. Un model care primește doar textul cererii scrie o specificație plauzibilă și generică, adică exact ce nu vrei. Sursele utile, în ordinea în care le conectăm de obicei:

• Cererea de modificare din sistemul de ticketing (ServiceNow, Jira, ChaRM din Solution Manager sau SAP Cloud ALM), cu istoricul comentariilor.
• Dicționarul de date: definițiile tabelelor și câmpurilor (DD02L, DD03L), ca agentul să numească structuri care există pe sistem.
• Directorul de obiecte și istoricul transporturilor: TADIR pentru obiectele custom din pachetele relevante, E070 și E071 pentru ce s-a mai modificat în zonă și când.
• Configurarea relevantă, citită din tabelele de customizing ale procesului atins.
• Specificațiile anterioare și documentația de proces, indexate pentru căutare semantică. Aici se aplică tot ce am scris în ghidul RAG enterprise: respectarea permisiunilor, citarea sursei, evaluare pe întrebări reale.
• Codul custom din zona atinsă (programe Z, enhancement-uri, implementări de BAdI), citit ca text, ca să se vadă unde intervine modificarea.

Toate aceste surse sunt metadate și configurare. Agentul are nevoie să știe că pe comanda de vânzare există câmpul pentru condițiile de plată; nu are nevoie să citească comenzile clienților. Distincția contează pentru securitate și pentru GDPR, și revenim la ea mai jos.

Tehnic, accesul se face prin tool-uri care împachetează apeluri RFC sau servicii OData, la fel ca în pattern-ul de extracție descris în articolul despre SAP. Aceeași lecție se aplică și aici: verifică numele de funcții și de tabele pe sistemul țintă. Modelele cunosc bine SAP-ul în general, dar confundă ușor nume apropiate. O specificație care citează un BAPI inexistent e mai periculoasă decât una care spune „de verificat”.

ECC și S/4HANA: ce se schimbă

Pattern-ul e același pe ambele. Conținutul specificației diferă.

Pe ECC, majoritatea sistemelor au ani de dezvoltări custom: user exits, modificări în codul standard, rapoarte Z scrise de echipe diferite. Valoarea cea mai mare a agentului e aici inventarul. Găsește codul custom care atinge deja procesul și îl pune în specificație înainte ca dezvoltatorul să-l descopere singur. Dacă firma pregătește migrarea, e util ca fiecare specificație nouă să marcheze dacă modificarea adaugă cod care va trebui adaptat la trecerea pe S/4HANA.

Pe S/4HANA, întrebarea centrală e unde se face extensia. Principiul clean core împinge extensiile spre API-uri eliberate, CDS views, extensibilitate key-user sau ABAP Cloud, și departe de modificările în codul standard. O specificație bună pentru S/4HANA spune explicit ce tip de extensie propune și de ce. Agentul poate verifica dacă obiectele pe care se bazează propunerea sunt eliberate pentru uz și poate semnala când draftul presupune tabele sau funcții care s-au schimbat față de ECC. Aici apar des greșelile moștenite: specificații copiate din proiecte ECC care referă structuri simplificate sau înlocuite în S/4HANA.

În proiectele de migrare cele două lumi se întâlnesc. Pe pagina principală descriem, anonimizat, un asistent de migrare construit pe Claude care citește landscape-ul SAP al clientului și produce documente de mapping, planuri de cutover și scaffold-uri de test. Generarea de specificații folosește aceeași fundație: conectori care citesc sistemul, un strat de cunoaștere comun și un template pe care echipa îl recunoaște.

Arhitectura: un autor și un recenzent

Cele mai bune rezultate le obținem cu doi agenți separați, după pattern-ul coordonator plus specialiști descris în articolul despre sisteme multi-agent.

Agentul autor primește cererea, cheamă tool-urile de citire și completează template-ul. Are instrucțiuni stricte: fiecare afirmație despre starea actuală are o referință, iar ce nu poate verifica marchează ca întrebare deschisă.

Agentul recenzent nu vede raționamentul autorului. Primește doar documentul final și aceleași tool-uri de citire, verifică draftul pe o listă de control și returnează observații, fără să rescrie documentul. Separarea contează: un singur agent care se verifică pe sine tinde să-și confirme propriile presupuneri.

Lista de control a recenzentului pornește de la întrebările pe care un consultant senior le pune oricum:

• Obiectele, tabelele și câmpurile menționate există pe sistem cu numele din document?
• Ce alte procese sau module citesc datele modificate?
• Modificarea cere roluri sau autorizări noi? Apare vreun conflict de segregare a sarcinilor?
• Sunt atinse date personale (angajați, clienți persoane fizice)?
• Există impact de volum sau de performanță (joburi batch, rapoarte pe tabele mari)?
• Sunt definite criteriile de acceptanță și cazurile de test, inclusiv cele negative?
• Cum se face rollback-ul dacă modificarea trebuie scoasă?
• Pentru S/4HANA: extensia respectă regulile de clean core stabilite în proiect?

Ca structură, un draft produs de agentul autor arată cam așa:

1. Cerere și context de business      [sursă: ticket CR-xxxx]
2. Starea actuală
   2.1 Configurare                     [sursă: tabel de customizing, valori citite]
   2.2 Obiecte custom existente        [sursă: TADIR, pachet Z...]
   2.3 Modificări anterioare în zonă   [sursă: E070/E071, transporturi]
3. Soluție propusă                     [marcat: DE VALIDAT de consultant]
4. Impact pe alte procese și module
5. Autorizări și date personale
6. Criterii de acceptanță și cazuri de test
7. Întrebări deschise                  [ce agentul nu a putut verifica]

Secțiunea 7 e cea mai importantă din document. Un draft fără nicio întrebare deschisă e aproape sigur un draft care a ghicit ceva.

Unde intră în change management

Agentul se atașează fluxului de change management existent. Nu creează unul paralel. Punctele de legătură sunt patru:

1. La preluarea cererii. Când un ticket trece în analiză, agentul autor produce draftul și îl atașează ticketului. Consultantul pornește de la un document în care starea actuală e deja documentată.
2. Înainte de aprobare. Agentul recenzent rulează pe versiunea finală a specificației, iar observațiile lui intră în ticket înainte ca cererea să ajungă la comitetul de aprobare.
3. După dezvoltare. Agentul compară obiectele din transport cu cele din specificație și semnalează diferențele: un obiect modificat care nu apare în document sau un obiect din document care n-a fost atins.
4. Înainte de mutarea în producție. Verifică dacă specificația, cazurile de test și rezultatele testelor sunt complete și atașate.

În toate cele patru puncte, agentul scrie comentarii și atașamente în ticket. Nu schimbă statusul cererii, nu eliberează transporturi și nu aprobă. Dacă folosiți ChaRM sau Cloud ALM, integrarea rămâne la nivel de document și comentariu, iar workflow-ul de aprobare rămâne neatins.

Guardrails

Specificațiile ajung să ghideze modificări în sistemul care ține contabilitatea și stocurile firmei. De aceea regulile de mai jos nu sunt opționale în implementările noastre.

Acces doar de citire, pe sistemele potrivite. Contul tehnic al agentului citește din dezvoltare sau din calitate, cu un rol construit exact pentru tabelele și funcțiile de care are nevoie. Nu scrie nicăieri în SAP. Nu primește SAP_ALL și nici acces la datele de business din producție.

Metadate, nu date de business. Tool-urile sunt proiectate să returneze structuri, configurare și cod. Când e nevoie de un exemplu de date, de pildă pentru a înțelege un format, se folosesc date de test sau pseudonimizate. Pentru organizațiile care nu vor ca numele de sisteme sau de parteneri să ajungă la model, un gateway de pseudonimizare precum Semantic Firewall le înlocuiește înainte de apel și le restaurează în răspuns.

Sursă pentru fiecare afirmație. Orice rând din secțiunea de stare actuală are o referință verificabilă. Recenzentul uman poate deschide tabelul sau obiectul și confirma în câteva secunde.

„Nu știu” e un răspuns valid. Promptul sistem și evaluările penalizează explicit ghicitul. Un câmp necompletat, însoțit de o întrebare deschisă, e preferabil unui câmp completat plauzibil.

Jurnal complet. Se păstrează ce a cerut utilizatorul, ce tool-uri a apelat agentul, ce a returnat SAP-ul și ce a produs modelul. Jurnalul servește la audit și la depanare, când trebuie înțeles de ce draftul a afirmat un anumit lucru.

Evaluare pe cereri reale. Înainte de a folosi agentul pe cereri noi, îl rulezi pe cereri închise, pentru care există deja specificația finală aprobată, și compari. Setul de evaluare se păstrează și se rulează din nou la fiecare schimbare de prompt sau de model.

Ce rămâne la oameni

Agentul preia documentarea. Deciziile rămân la oamenii care răspund pentru ele:

• Dacă modificarea merită făcută. Prioritizarea și costul de oportunitate sunt decizii de business.
• Regulile de business. Agentul poate descrie ce face sistemul azi. Ce ar trebui să facă mâine hotărăște proprietarul procesului.
• Alegerea soluției. Agentul poate propune variante. Consultantul funcțional și arhitectul aleg și semnează.
• Autorizările și segregarea sarcinilor. Agentul semnalează impactul. Decizia rămâne la echipa de securitate SAP.
• Estimarea și angajamentul de livrare.
• Aprobarea în comitetul de modificări și acceptanța testelor.

Un test simplu: dacă o semnătură pe document înseamnă că cineva își asumă o răspundere, acea semnătură nu se automatizează.

Ce nu funcționează încă bine

Din ce am văzut până acum:

• Cererile vagi rămân vagi. Dacă ticketul spune „raportul nu merge bine”, agentul poate documenta raportul, dar nu poate ghici ce înseamnă „bine”. Aici e util mai ales ca să formuleze întrebările pentru business.
• Logica din cod foarte vechi. Programele Z lungi, fără comentarii, cu logică împrăștiată în include-uri, sunt greu de rezumat corect. Rezumatul agentului e un punct de plecare pentru dezvoltator. Codul tot trebuie citit.
• Impactul indirect pe landscape-uri mari. Agentul găsește dependențele directe. Efectele prin interfețe către alte sisteme sau prin joburi care citesc aceleași tabele cer încă ochiul cuiva care cunoaște landscape-ul.
• Template-uri inconsistente. Dacă echipa are trei template-uri de specificație, agentul le va produce pe toate trei. Standardizarea template-ului vine înainte de automatizare.

Cum începi

1. Alege un tip de modificare frecvent și bine delimitat, de exemplu extinderea unui raport existent sau o validare nouă pe un document. Lasă cererile complexe pentru mai târziu.
2. Standardizează template-ul de specificație pentru acel tip și scrie lista de control a recenzentului împreună cu consultanții care fac azi munca.
3. Strânge un set de cereri închise care au specificații finale aprobate. Ele devin setul de evaluare.
4. Construiește tool-urile de citire pe sistemul de dezvoltare, cu un cont tehnic cu drepturi minime, și verifică fiecare nume de tabel și de funcție pe sistem.
5. Rulează autorul și recenzentul pe setul de evaluare și compară cu specificațiile reale, secțiune cu secțiune. Ajustează promptul și sursele până când diferențele sunt acceptabile pentru echipă.
6. Conectează agentul la ticketing doar pentru comentarii și atașamente, apoi folosește-l pe cereri noi cu un grup mic de consultanți.

Dacă vrei să afli dacă pattern-ul are sens pe procesele și sistemele voastre, analiza AI de două săptămâni pornește exact de la o astfel de întrebare: ce proces alegem, ce date sunt accesibile și ce construim primul. Pentru automatizări dincolo de specificații, vezi și pagina despre agenți AI și automatizare de procese.