Integrarea AI cu ERP-ul: SAP Business One și altele, ce verifici înainte să conectezi

Acest ghid tratează integrarea AI cu ERP-ul: SAP Business One și altele, adică momentul în care un asistent precum Claude primește acces la sistemul în care îți ții stocurile, achizițiile și contabilitatea. Înainte de orice conexiune, trei întrebări contează. Ce date poate citi asistentul, ce acțiuni poate declanșa și unde aprobă un om.

Întâi, câțiva termeni. SAP definește ERP-ul (planificarea resurselor întreprinderii) drept un sistem software care ajută firma să își eficientizeze procesele de bază: finanțe, resurse umane, producție, lanț de aprovizionare, vânzări și achiziții. Integrarea ERP este metoda prin care conectezi ERP-ul cu alte aplicații și procese din firmă.

SAP Business One este ERP-ul SAP gândit pentru companii mici și mijlocii. Acoperă zonele de financiar, vânzări, producție, relația cu clienții, inventar și operațiuni. Regulile din acest ghid pot fi folosite la fel pentru orice alt ERP. Se schimbă doar calea tehnică prin care asistentul ajunge la date.

Subiectul nu mai e teoretic. SAP notează că sistemele ERP de azi includ deja inteligență artificială, inclusiv agenți și asistenți. Discuția reală nu e dacă AI-ul ajunge la datele tale. Discuția e cu ce reguli ajunge acolo și cine răspunde pentru ce face.

O integrare între un asistent AI și ERP are nevoie de trei piese. Fără ele, ai doar un chat cu acces larg la date, iar asta e un risc, nu un proiect.

• Un model de citire. Lista exactă de module, tabele și câmpuri pe care asistentul le poate vedea. Tot ce nu e pe listă rămâne închis.
• Un pas de aprobare. Locul în care un om cu drepturi în ERP confirmă orice modificare. Asistentul propune, omul semnează.
• O pistă de audit. Un jurnal care arată cine a cerut ce, ce a citit asistentul, ce a propus și cine a aprobat. Fără jurnal nu poți explica după trei luni de ce a apărut o comandă.

La Svennis, pe fiecare sistem asistat de AI începem cu aceste trei liste scrise pe o singură pagină, înainte de primul prompt: ce citește asistentul, ce poate propune și cine aprobă. Dacă una dintre ele lipsește, nu conectăm nimic la ERP.

Ordinea contează. Mai întâi procesul, apoi tehnologia. Dacă nu știi încă ce pas din achiziții vrei să ușurezi, citește întâi ghidul despre cum proiectezi procesul înainte de model. Abia după aceea are sens să alegi cum se conectează asistentul.

Primul reflex e să îi dai asistentului acces la tot, ca să răspundă la orice. E alegerea greșită, și din motive de cost, nu doar de securitate. Ghidul Anthropic pentru asistenți de suport spune că, dacă pui toate informațiile în prompt, ajungi la costuri mari, răspunsuri mai lente și la limita ferestrei de context.

Mai e o distincție importantă. Unele date se schimbă rar, cum ar fi condițiile de livrare sau fișele de produs. Altele se schimbă de la oră la oră: stocul, comenzile deschise, soldurile. Același ghid Anthropic spune clar că abordările bazate pe căutare în documente indexate nu sunt suficiente pentru informații în timp real, precum soldurile de cont. Pentru stoc și comenzi, asistentul trebuie să interogheze ERP-ul direct, în momentul întrebării.

Cum stabilești lista de citire

• Pornește de la întrebările reale ale oamenilor, nu de la structura bazei de date.
• Scoate din start modulele sensibile: salarii, date bancare, declarații fiscale.
• Creează în ERP un utilizator tehnic dedicat asistentului, cu drepturi doar de citire pe modulele alese.

Utilizatorul tehnic separat are un avantaj practic. Orice interogare a asistentului apare în ERP sub numele lui, deci o poți urmări și o poți opri fără să atingi conturile colegilor.

Acțiunile pot fi împărțite în trei trepte. Pe prima, asistentul doar răspunde, fără să scrie nimic în ERP. Pe a doua, pregătește un document nefinal pe care un om îl verifică. Pe a treia, emite documente finale singur. Pentru un ERP, a treia treaptă nu e un punct de plecare rezonabil.

Motivul e concret. Documentația Anthropic spune că, în anumite situații, Claude poate urma comenzi găsite în conținut, chiar dacă ele contrazic instrucțiunile tale. În achiziții, conținutul înseamnă emailuri de la furnizori, oferte în PDF, facturi scanate. Un text ascuns într-o ofertă poate cere asistentului să schimbe un preț sau un cont bancar.

De aceea aprobarea trebuie să stea în afara modelului. Nu îi ceri asistentului să „fie atent”. Construiești fluxul astfel încât documentul să nu devină final fără clicul unui om cu drepturi în ERP.

Unde poate sta aprobarea

• În ERP, ca document în așteptare pe care cumpărătorul sau managerul îl aprobă.
• În instrumentul de chat al echipei, cu un buton de confirmare care apoi scrie în ERP.

A doua variantă e descrisă în ghidul despre asistentul AI în instrumentele pe care le folosești deja. Indiferent unde apare butonul, regula e aceeași: omul aprobă, iar aprobarea lui ajunge în jurnal.

SAP numește API-ul „interfață de programare a aplicațiilor”, adică software care permite sistemelor să comunice între ele. Aproape orice cale de integrare trece, până la urmă, printr-un API. Diferența e cine scrie și cine întreține legătura.

API direct

Un dezvoltator scrie codul care leagă asistentul de ERP. Controlul e maxim, dar SAP avertizează că integrarea punct-la-punct e manuală și se bazează pe codare umană, ceea ce poate fi lent și greu de întreținut. Când legăturile se înmulțesc, apare ce SAP numește „spaghetti de cod”.

Server MCP

Un server MCP este un conector standard prin care Claude folosește un sistem extern: citește date sau apelează funcții. În Claude, conectorii pot veni la pachet în pluginuri, alături de skilluri și subagenți. Avantajul e că definești o singură dată ce operații sunt permise.

Platformă de integrare (iPaaS)

SAP descrie iPaaS ca soluții de tip platformă-ca-serviciu, cu conectori și reguli de business predefinite, și le consideră standardul actual față de metodele mai vechi. Aceeași pagină notează însă că iPaaS e un cost suplimentar inițial. SAP mai spune că există peste 800 de instrumente de integrare, deci alegerea nu e trivială.

Computer use, ca ultimă variantă

Anthropic oferă și un set de unelte prin care Claude face capturi de ecran și folosește mouse-ul și tastatura. Fiecare captură costă aproximativ 1.000-1.800 de tokeni de intrare, iar riscul de comenzi ascunse în conținut rămâne. Pentru un ERP, e o soluție de avarie, nu o arhitectură.

SAP Business One poate rula în două feluri: on-premise, adică instalat pe serverul tău, sau în cloud. Licențierea urmează aceeași logică, SaaS sau on premises. Alegerea asta decide, practic, cât de ușor ajunge un asistent AI la date.

Fișa de produs publicată de Softlead spune că integrarea cu alte sisteme se face „prin dezvoltare la cerere”. Tradus: nu există un buton gata făcut care leagă Claude de SAP Business One. Cineva construiește legătura, de obicei peste interfața REST a sistemului, numită Service Layer, care a înlocuit în majoritatea proiectelor noi vechiul DI API.

Atenție la serverul din birou

Aici apare o capcană pentru varianta on-premise. Documentația despre pluginurile din Claude spune că, în Cowork, conectorii ajung la serviciile externe prin cloud-ul Anthropic, nu prin rețeaua ta locală. Un conector personalizat trebuie să indice un server accesibil din internetul public.

Dacă SAP Business One stă pe un server în birou, nu îl expui direct. Pui între el și asistent un strat controlat, care expune doar operațiile din lista ta de citire și din lista de acțiuni aprobate.

Mai e un detaliu. Aceeași documentație spune că pluginurile pot include servere MCP locale care rulează pe calculator cu aceleași permisiuni ca orice alt program. Un plugin instalat pe laptopul unui contabil vede, deci, tot ce vede contabilul. Verifică ce pluginuri instalează oamenii înainte să le dai acces la ERP.

Să luăm un caz obișnuit într-o firmă de distribuție care folosește SAP Business One. Cumpărătorul pierde timp în fiecare dimineață verificând ce articole trebuie recomandate. Scopul nu e să înlocuiești cumpărătorul, ci să îi pregătești propunerea.

1. Întrebarea. Cumpărătorul scrie în chat: „Ce articole sunt sub stocul minim în depozitul principal și ce comenzi de achiziție avem deja deschise pentru ele?”
2. Citirea. Asistentul interoghează live SAP Business One prin utilizatorul tehnic cu drepturi de citire. Citește stocul, stocul minim, comenzile de achiziție deschise și furnizorul obișnuit. Nimic altceva.
3. Propunerea. Asistentul face un tabel: articol, stoc actual, cantitate deja comandată, cantitate propusă, furnizor. Explică pe scurt de unde vine fiecare cifră.
4. Documentul nefinal. Dacă cumpărătorul cere, asistentul creează în ERP un document de comandă în așteptare, nu o comandă trimisă furnizorului.
5. Aprobarea. Cumpărătorul deschide documentul în SAP Business One cu propriul utilizator, corectează cantitățile și îl aprobă. Doar acum comanda devine reală.
6. Jurnalul. Rămân înregistrate întrebarea, datele citite, propunerea și numele celui care a aprobat.

Observă ce nu face asistentul. Nu trimite emailuri furnizorilor, nu modifică prețuri și nu atinge contabilitatea. Poți adăuga oricare dintre acestea mai târziu, câte una, după ce jurnalul arată că propunerile sunt corecte.

Tabelul de mai jos adună verificările într-un singur loc. Coloana din dreapta arată un punct de plecare prudent, pe care îl poți relaxa după ce ai date din utilizare reală.

Pentru rândul despre acces, ajutorul Claude spune că autentificarea unică (SSO) e disponibilă pe planurile Team și Enterprise și în organizațiile Console. Modul implicit de adăugare a utilizatorilor este doar pe bază de invitație, ceea ce e un început bun pentru un ERP.

Pentru o firmă românească, ERP-ul ține și partea fiscală. Modulul financiar-contabil din SAP Business One include jurnale de TVA și declarațiile 300, 390 și 394, plus importul automat al cursurilor BNR. Toate acestea stau în afara listei de acțiuni a asistentului. Le poate citi, dacă ai un motiv clar, dar nu le generează și nu le modifică.

A doua realitate e că datele nu stau doar în ERP. SAP observă că multe firme mici pornesc cu instrumente simple, ca foile Excel, înainte de un ERP, iar angajații continuă să instaleze aplicații fără să anunțe echipa IT. Aceste aplicații nu sunt integrate cu ERP-ul. Dacă asistentul citește dintr-un Excel paralel, îți poate da un stoc care nu mai e adevărat.

Problema nu e doar locală. Într-un sondaj Deloitte citat de SAP, aproape jumătate dintre directorii de achiziții au trecut integrarea deficitară între aplicații printre primele trei probleme. Un asistent AI nu rezolvă asta singur. Mai întâi faci din ERP singura sursă pentru datele pe care le citește asistentul.

Mai rămâne cadrul legal. Pentru obligațiile care pot apărea când folosești AI în procese de business, vezi textul adnotat al AI Act în română și pagina despre cadrul legal AI în România. Pista de audit din acest ghid te ajută și aici, pentru că poți arăta ce a făcut sistemul și cine a decis.

Nu ai nevoie de un proiect mare ca să începi. Ai nevoie de un proces bine ales și de trei liste scrise. Ordinea de mai jos poate fi folosită pentru SAP Business One sau pentru orice alt ERP.

1. Alege un singur proces. Comenzile de achiziție sunt un candidat bun, pentru că au un om clar care aprobă și un document clar la final.
2. Scrie cele trei liste. Ce citește asistentul, ce poate propune, cine aprobă. Pe o pagină, semnată de cel care răspunde de proces.
3. Creează utilizatorul tehnic. Cont dedicat în ERP, cu drepturi doar de citire pe modulele de pe listă.
4. Pornește doar cu citire. Lasă cumpărătorul să pună întrebări o perioadă și verifică în jurnal dacă răspunsurile corespund cu ERP-ul.
5. Adaugă documentele nefinale. Abia apoi permite crearea de comenzi în așteptare, cu aprobare obligatorie.
6. Alege calea tehnică la final. API, server MCP sau platformă de integrare, după ce știi exact ce operații trebuie expuse.

Dacă nu știi încă ce proces să alegi sau dacă datele din ERP sunt destul de curate, pornește de la evaluarea pregătirii companiei tale pentru AI. Îți arată unde stai înainte să conectezi ceva la sistemul care îți ține firma în funcțiune.