După ce în urma publicării ultimelor articole pe teme SAP ni s-a sugerat din partea cititorilor că o scurtă introducere în mediul SAP ar fi foarte bine venită, am hotărât să urmăm acest sfat inițiind o serie de articole cu scopul de a oferi o vedere de ansamblu asupra aspectelor care ţin de specificul SAP.
Astfel, în acest articol ne propunem să analizăm câteva detalii ale produselor respectiv tehnologiei SAP, încercând să răspundem la unele întrebări precum: Ce este SAP de fapt? Care este specificul produselor SAP? Ce anume este "deosebit" la tehnologia SAP şi ce presupune dezvoltarea software în acest domeniu?
SAP este provider-ul de "enterprise business software" numărul 1 la nivel global, având peste 230000 de clienţi şi un portofoliu ce acoperă întreg spectrul de produse, de la soluţii enterprise tipice precum Financial/Accounting, HR, Customer Relationship Management şi până la unele foarte specifice, aşa numitele "Focused Business Solutions".
O problemă interesantă ar fi cu siguranţă identificarea motivelor pentru care un număr atât de mare de clienţi enterprise aleg SAP. Desigur acestea sunt diverse, ceea ce se spune însă de multe ori, este că cel mai bun promotor al unei soluţii informatice îl reprezintă portofoliul de clienţi şi poveştile de succes ale acestora, sau cu alte cuvinte: implementarea unei soluţii IT care reuşeşte să eficientizeze procesele de business ale unei companii, reprezintă o dovadă a calităţii software-ului, fiind adesea și un factor care determină concurenţa din aceeaşi branşă să aleagă la rândul ei această soluţie.
Şi în cazul soluţiilor SAP, acestă afirmaţie este cât se poate de valabilă, cu atât mai mult cu cât portofoliul SAP cuprinde în exclusivitate soluţii informatice dezvoltate nu pentru un anumit client, ci pentru o întreagă branşă. În terminologie SAP (dar nu numai) aceste produse sunt numite soluţii "standard".
Mai mult decât atât, implementarea unei soluţii informatice consacrate în cadrul unui enterprise, spre deosebire de dezvoltarea uneia noi ("from scratch"), poate avea un impact pozitiv şi asupra imaginii companiei respective, putând influenţa până şi ratingul primit de aceasta ca urmare a unui audit.
Având în vedere abordarea SAP, de a nu deservi un anumit client ci mai degrabă o întreagă industrie prin produsele sale, în cele ce urmează vom analiza care sunt provocările de care se loveşte un dezvoltator software atunci când urmăreşte implementarea unei noi soluţii standard, şi mai ales care este aportul pe care îl aduce platforma tehnică SAP în vederea soluţionării acestor provocări.
Din punct de vedere al funcţionalităţii pe care o va pune la dispoziţie, softul standard trebuie proiectat astfel încât să suporte toate procesele de business tipice ale branşei, în acelaşi timp făcând însă abstracţie de orice detaliu care este specific doar anumitor clienţi.
De aceea, faza de specificare funcţională a noii soluţii standard implică adesea colectarea de informaţii de la clienţi multipli din cadrul domeniului respectiv. Această activitate are ca scop final definirea produsului la un nivel de abstractizare suficient de înalt, astfel încât să fie posibilă implementarea acestuia la oricare client din acea branşă.
Prin urmare, specificarea funcţională a produsului reprezintă o activitate de o importanţă majoră, care necesită o foarte bună cunoaştere a business-ului, de ea depinzând în mare parte succesul ulterior al produsului.
Datorită faptului că o soluţie standard nu poate fi specificată până în ultimul detaliu astfel încât ea să poată fi achiziţionată "la cheie" de către un client, orice produs SAP va trece de-a lungul timpului prin două faze distincte: dezvoltarea soluţiei standard și adaptarea soluţiei standard explicit la cerinţele clientului (fază numită de obicei "implementarea" produsului la client)
Cele două faze reprezintă, din punct de vedere al dezvoltării software, două proiecte independente: proiecte de dezvoltare standard şi proiecte client (customer development projects). Prin urmare şi un dezvoltator ABAP poate fi la rândul său implicat în două tipuri diferite de proiecte, fiecare având specificul său, astfel încât şi skill-setul necesar pentru un dezvoltator ABAP diferă de la un tip de proiect la celălalt .
Din punct de vedere tehnic, încă de la design-time software-ul trebuie să fie proiectat în aşa fel încât acesta să permită extinderea proceselor standard acolo unde este cazul, sau definirea acelor detalii care au fost prea specifice pentru a putea fi incluse în soluţia standard, de către fiecare client în parte.
Pentru a putea implementa cerinţele legate de flexibilitate şi extensibilitate ale software-ului, e nevoie ca şi platforma tehnică pe baza căreia se dezvoltă noul produs să vină în ajutorul dezvoltatorului, punând la dispoziţia acestuia mecanisme care să facă posibilă implementarea unui produs nu pentru un client, ci pentru o întreagă industrie. Acest lucru este cât se poate de valabil în cazul soluţiilor SAP, platforma tehnică şi mediul de dezvoltare fiind gândite de la bun început cu aceste ţeluri în minte.
În cele ce urmează vom prezenta succint câteva din conceptele specifice SAP, care vin tocmai în întâmpinarea problemelor ce ţin de flexibilitatea produselor standard.
După cum am menţionat deja, atunci când se dezvoltă o soluţie standard, se vor ivi adesea situaţii în care un anumit proces nu poate fi definit în totalitate în cadrul soluţiei standard, fie pentru că anumite aspecte nu sunt cunoscute de la acel moment, fie pentru că acestea diferă de la client la client neexistând astfel o soluţie "standard" pentru acea situaţie. Astfel apare nevoia pentru un mecanism prin intermediul căruia clientul să aibă posibilitatea de a extinde comportamentul sistemului cu funcţionalităţi specifice propriului său business, funcţionalităţi care ar fi fost prea specifice pentru a fi incluse în soluţia standard.
În cazul tehnologiei SAP, un exemplu pentru un astfel de mecanism sunt aşa numitele "Business Add-Ins". Un Business Add-In (sau BadI) reprezintă un user exit cu o interfaţă predefinită, integrat în flow-ul soluţiei standard. Prin utilizarea de BadI-uri clientul are posibilitatea să îşi definească implementări proprii prin care să extindă comportamentul standard al sistemului, şi mai mult de atât, să specifice condiţiile (numite de obicei "filtre") pentru care o implementare să fie executată.
Astfel se oferă posibilitatea unui client să extindă un produs standard cu propria logică de business, aceasta fiind integrată şi executată la un moment predefinit în cadrul procesului standard.
Utilizarea conceptului de Business Add-in implică întotdeauna două faze distincte:
În timp ce conceptul în sine ar putea fi implementat fără probleme şi utilizând alte tehnologii, ceea ce e deosebit este faptul că limbajul ABAP vine cu un set de instrucţiuni specifice pentru utilizarea BadI-urilor în aplicaţii ABAP, iar mediul de dezvoltare SAP pune la dispoziţie tool-uri care uşurează activităţile ce ţin de gestionarea BadI-urilor: definirea BadI-ului, a interfeţei şi a filtrelor, adăugarea de noi implementări
GET BADI lr_badi
FILTERS
iv_entity = lv_filter_value.
CALL BADI lr_badi->do_checks
EXPORTING
is_key = ls_key
iv_lob_cd = lv_lob_cd
CHANGING
ct_msgtab = lt_msgtab
.Pe lângă Business Add-Ins, platforma SAP mai pune la dispoziţie şi o serie de alte mecanisme (Program Exits, Screen Exits, Menu Exit, Business Transaction Events), toate acestea făcând posibilă dezvoltarea de soluţii standard SAP care mai apoi vor putea fi extinse cu uşurinţă de către fiecare client în parte.
Customizing-ul în terminologie SAP se referă la activitatea prin care un produs SAP este personalizat pentru un anumit client prin ajustarea diverşilor parametri de sistem ai produsului. Customizing-ul este un pas obligatoriu în faza de implementare a unei soluţii SAP la un anumit client.
Procesul de customizare al unei soluţii SAP include o gamă variată de activităţi de nivele de complexitate diferită:
Conceptul de clienţi SAP permite separarea unui sistem SAP într-o serie de subunităţi logice fiecare astfel de subunitate fiind numită un "client".
În condiţiile în care adesea este nevoie ca mai multe subunităţi ale unei organizaţii să se folosească de aceeaşi soluţie SAP, existenţa acestui concept permite reutilizarea aceleaşi infrastructuri hardware, astfel obţinându-se o diminuare a costurilor de instalare, configurare şi întreţinere, ale soluţiei SAP.
Între clienţii unui sistem există posibilitatea de a face o separare atât la nivelul configurării customizării soluţiei SAP de pe sistemul respectiv, dar şi a datelor propriu-zise. Astfel în cadrul unui enterprise, mai multe subunităţi pot folosi aceeaşi soluţie SAP, instalată pe un singur sistem fizic, dar care funcţionează diferit în funcţie de client, customizarea fiind specifică fiecărui client în parte. Mergând pe exemplul configurării TVA-ului, o companie multinaţională având filiale în mai multe ţări poate utiliza un singur sistem SAP, asignând filialele din diverse ţări la clienţi diferiţi ai sistemului, pe fiecare client TVA-ul fiind configurat corespunzător pentru fiecare ţară în parte.
Toate aceste aspecte, împreună cu alte mecanisme şi tool-uri specifice SAP, uşurează în mod simţitor job-ul dezvoltatorilor, atunci când accentul în cadrul dezvoltării software se pune în special pe flexibilitatea şi posibilitatea de extindere a soluţiei informatice implementate.
Enumerarea acestor aspecte nu a avut scopul de a fi una exhaustivă, rolul ei fiind mai degrabă de a face o scurtă introducere în ceea ce poate fi considerat a fi "specificul SAP". În articolele următoare, vom detalia acest subiect, prin abordarea altor aspecte ale dezvoltării software SAP, cu accent în special pe diferenţele faţă de alte limbaje şi tehnologii.
de Ovidiu Mățan
