Fluxuri de Afaceri Electronice B2b

Cuprins

Introducere

Tema lucrarii  mele de licenta se intituleaza ”Customizarea sistemului ERP – SAP Business Program pentru integrarea fluxurilor de afaceri B2B” ale carei baze au fost cladite ca urmare a unui internship realizat in cadul companiei Pirelli in urma cu mai bine de un an, prin Proiectul Praxis organizat de Universitatea din Craiova.

Desi initial a fost vorba de satisfacerea unei curiozități intelectuale, ulterior a devenit o provocare concretizata intr-un loc de munca.

Asadar, motivul alegerii acestei teme derivǎ din cunoasterea indeaproape a modului de functionare al unui sistem integrat, de intelegere a complexitatii fluxurilor de afaceri si a necesitatii existentei unei astfel de aplicatii in cadrul unei intreprinderi.

Fiind vorba de o companie multinationala, imbinarea culturilor organizationale si a modului de perceptie al fiecarui popor, precum si existenta in cadrul fiecarei organizatii autonome care face parte din din familia Pirelli a unei logici de functionare diferita, utilizarea unui singur sistem poate fi un obiectiv destul de greu de indeplinit.

Astfel ca, posibilitatea de customizare a sistemului infunctie de cerintele utilizatorilor din toata lumea, adica activitati de mentenanta/ intretinere, how-to-do, activitati corective si mici enhasmenturi/imbunatatiri in diferite sisteme SAP atat pentru clientii interni cat si externi pe modulele Material Management, Production Planning, Advanced Planning Optimization, E-Bussiness Procurement, Sales and Distribution, Financial Accounting, Controlling, Warehouse, CCS – servere etc, este o cerinta esentiala intr-un business de mare anvergura, asa cum este Pirelli.

Noțiunile dobândite in cadrul companiei pe parcursul ultimului an, m-au ajutat sa ma apropii si sa inteleg din ce in ce mai mult de conceptele de module integrate, sistem informatic, aplicatii de business, SGBDR, securitatea informatiilor, s.a., concepte ale caror baze au fost puse inca de la inceperea facultatii.

Activitatea desfasurata ca angajat al entitatii economice Sistemi Informativiti Craiova, imbina cu succes cunostiintele IT de proiectare a bazelor de date, de securitate a datelor, de programare orientata obiect, retele, precum si cele economice, intrucat serviciile oferite clientilor din intreaga lume au ca scop mentinerea agentului economic Pirelli pe primul loc in lume in productia Premium, si pe locul 5 la vanzari.

La acest nivel concurential, securitatea informatiei este un aspect foarte sensibil de care trebuie sa se tina cont in gestionarea fluxurilor de afaceri. Mergând de la general către particular, de la proiectarea sistemului informatic si pana la customizarea fiecarui modul in parte, trebuie sa se tina seama de elementele de protectie a valorilor interne ale companiei. Pornind de la conceptul de B2B (Bisiness to Business), se poate observa faptul ca sistemul informatic al Pirelli conlucreaza cu sistemele partenerilor acestuia, o conditie esetiala fiind cea de corespondeta a datelor pentru a se putea realiza comunicarea intre aceste.

Baza de date comuna a mai multor societati autonome este nucleu in jurul caruia se invarte intreaga activitate a societatii. Este foarte important sa se asigure accesul rapid si permanent la aceste date, updatate in timp reala si disponibile oricarui utilizator autorizat in acest sens, pentru realizarea cu succes a continuitatii proceselor de business. Disponibilitatea informatiei in momentul in care este solicitata si in formatul dorit, este una dintre cerintele care cad in sarcina echipei de la Craiova.

Prelucrarea si gruparea datelor de la fiecare nivel ierahic, urmata de prezentarea lor intr-un format cat mai usor de inteles, sub forma unor grafice si statistici, ajuta la luarea deciziilor operationale, tactice si strategice din cadrul fiermei. Este esential ca aceste date sa prezinte cat mai precis situatia actula a intreprinderii, pentru a se putea lua decizii cat mai bune cu privire la sutuatia de moemnt a firmei, precum si la cea viitoare.

Dupa cum este bine cunoscut, Pirelli a investit peste 450 milioane de euro de la venirea in Romania, urmand ca in perioada 2013 – 2017 sa mai realizeze investitii de peste 105 milioane euro. Aceste decizii de investitii sunt rezulatul activitatii previzionale realizata pe baza rezultatelor economice.

Prezenta economica a companiei Pirelli in Romania a avut o serie de beneficii : asigurarea de locuri de munca, contributia platita la stat de companiei, sponsorizarea spitalelor din Slatina plus multe alte activitati sociale oferite angajatilor, precum si prestigiul adus tarii prin faptul ca fabrica din Romania a devenit, de anul acesta, backup pentru F1.

Pe baza acestor considerente, m-am hotarat sa întreprind o cercetare conform normelor universitare asupra rolului, locului și importanței sistemului ERP – SAP Business Program in gestiunea fluxurilor de afaceri din cadrul companiei Pirelli.

Captolul I – Prezentarea solutiei integrate SAP la nivelul companiei Pirelli SA

. Prezentarea Pirelli Tyres Romania. Prezenta economica in Romania

Aspecte generale

Pirelli & C. Spa este o companie multinațională cu sediul central în Milano, Italia. Compania, este al 5-lea cel mai mare producător de anvelope, și este present în peste 160 de țări, are 20 de fabrici de producție prin toată lumea și o rețea de aproximativ 10.000 distribuitori și retaileri.

Pirelli a fost fondat în 1872 la Milano de Giovanni Battista Pirelli. Inițial, Pirelli era specializată în cauciuc și procese derivate. În prezent, activitățile companiei încă sunt bazate, în principal, pe producția de anvelope și cabluri (pentru anvelope, energie și telecomunicații). În 2005, Pirelli a vândut divizia de cabluri firmei de investiții Goldman Sachs, care a schimbat numele noului grup în “Prysmian”.

Astăzi, pneurile late Pirelli, reprezintă un standard pentru automobile sport și cursele de mașini din Europa.

Prezenta economica in Romania

Situată în sud-estul României, Pirelli Tyres România este prezentă pe piața de profil (auto) prin intermediul celor trei fabrici: Fabrica de Anvelope, Fabrica de Cabluri Metalice și Filtre antiparticule pentru motoare diesel. Toae aceste trei fabrici reprezintă Proiecte Greenfield.

Fig. 1.1 Pozitionarea filialelor Pirelli in Romania

Compania Pirelli Tyres Romania face parte din Grupul de firme Pirelli & C Spa și este prezentă în Romania din anul 2006 cu fabrica de anvelope de la Slatina, Olt.

Întregul Pol Industrial are în prezent circa 2 400 de angajați.

În ultimii 9 ani (prioada 2005 – 2014) Grupul Pirelli a investit în România aproximativ 450 milioane de euro pentru a crea un important pol industrial compus din fabrica de la Slatina de producere a anvelopelor pentru autoturisme și SUV-uri performante, fabrică de cabluri metalice tot în Slatina care produce steelcord, element ce face parte din structura anvelopelor radiale. De curand insa, Pirelli a renuntat la fabrica de Cord metalic, Prysmian, externalizandu-si aceasta activitate.

In urmatorii ani, 2013-2017, Pirelli va investi in Romania suma de 105 milioane de euro, din care 35 de milioane de euro acordate de catre Guvernul Romaniei, in cresterea capacitatii de productie a anvelopelor pentru autovehicule, segmentul Premium, in cadrul Polului Industrial din Slatina.

Polul Industrial este completat din anul 2008 de Fabrica de filtre antiparticule pentru motoare diesel la Bumbești- Gorj.

Fabrica de anvelope din Slatina, una dintre cele mai moderne din lume pentru producerea de anvelope, este dotată cu cele mai înalte tehnologii productive non-robotizate și a fost concepută pentru producția de anvelope perfomante, în care Pirelli este leader și din care fac parte gamele: Winter, High-Performance, Ultra-High-Performance și SUV.

Fig. 1.2 Centrul IT Craiova

Potrivit tradiției sale, Pirelli are in vedere promovarea in județul Olt a unei serii de inițiative care saƒ contribuie la pregătirea și buna starea angajaților și familiilor acestora și, în general, a comunității locale.

Cadru general. Companie si solutie informatica

Pirelli este o companie multinationala care, pentru gestiunea tuturor resurselor si relatiilor cu tertii, foloseste o solutie integrata de business, numita SAP – System Applications Productsl, realizata cu ajutorul limbajului de programare ABAP – Advanced Business Application Programming. ABAP – este un limbaj de programare de nivel inalt creat de compania germana SAP. In pozitia sa curenta, alaturi de cea mai noua versiune de Java, a introdus ca limbaj de programare SAP Application Server, ca parte a platformei NetWeaver pentru construirea de aplicatii de afaceri. Sintaxa folosita in ABAP este oarecum similara cu COBOL. Limbajul de programare ABAP a fost initial folosit de programatori pentru a dezvolta platforma SAP R/3. S-a intentionat a se folosi de catre clientii SAP pentru a imbunatatii aplicatia SAP – clientii pot dezvolta rapoarte customizate si interfete prin programarea ABAP. Limbajul este usor de invatat pentru programatori, dar nu este un instrument pentru uzul direct al non-programatorilor. Cunoasterea designului bazelor de date relatonate si de preferat al conceptului programarii orientate obiect sunt necesare pentru a crea programe ABAP.

Toate programele ABAP rezida din interiorul unei baze de date SAP. Ele nu sunt stocate in fisiere externe separate, cum este cazul Java sau C++. In bazele de date, codul ABAP exista in doua forme :

cod sursa – care poate fi vazut si editat cu instrumentele ABAP Workbench ;

cod generat – o reprezentare binara, oarecum comparabila cu cea din Java.

Programele ABAP se executa sub controlul sistemelor de rulare, care sunt o componenta a nucleului SAP. Sistemul de rulare este responsabil pentru procesarea rapoartelor ABAP, controland fluxul logic al ecranelor si raspunzand la evenimente (cum este un clic al userului pe un buton de pe ecran).

O componeta cheie a sitemului de rulare ABAP o reprezinta Interfata de baze de date, care transforma Rapoartele independente ABAP (Open SQL) in rapoarte intelese de DBMS – Database Management System (Native SQL). Interfata de baze de date manevreaza toate comunicatiile cu bazele de date relationale in folosul programelor ABAP; contine deasemenea caracteristici extra cum ar fi: tabele tampon si date accesate frecvent in memoria locala a serverului de aplicatii.

SAP Basis – abstractizarea dintre aplicatiile de afaceri, sistemul de operare si bazele de date. Aceasta asigura faptul ca aplicatiile nu depind in mod direct de o platforma de baze de date sau de un server specific, si pot fi portate cu usurinta de pe o platforma pe alta.

Definirea conceptului de modul integrat

O aplicatie ERP (Enterprise Resource Planning) reprezinta o infrastructura software ce ofera suport de gestiune si coordonare a diferitelor structuri, procese si fluxuri din companie, in vederea realizarii obiectivelor de afaceri.

Fig. 1.3 ERP

O aplicatie ERP reprezinta o imbinare a practicilor de management al afacerilor cu tehnologia informatiilor, prin intermediul carora procesele de afaceri ale unei companii sunt integrate in cadrul sistemului informatic, in vederea atingerii unor obiective de business specifice.

De-a lungul timpului, tehnicile si practicile de management au evoluat intr-un set de regului general acceptate (best practices) specifice fiecarei verticale de business. Cu toate ca sunt rezultatul unui proces fundamentat intr-o lunga perioada de timp, aceste “best practices” sunt si ele supuse necesitatii continue de resincronizare cu modificarile structurale ale mediului de afaceri. Rolul unei aplicatii ERP este acela de a facilita incorporarea si actualizarea acestora in cadrul proceselor de business ale companiei.

IT – Tehnologia informationala reprezinta infrastructura hardware, software, retelistica si comunicatii necesara implementarii unui sistem ERP. Se recomanda implementarea unui sistem ERP pe o infrastructura IT optima, astfel incat procesele de afaceri sa opereze la un eze la un randament care sa permita atingerea obiectivelor de business prestabilite.

Particularitatile unui ERP ca sistem informatic integrat

Gestionarea activitatilor unei companii este o problematica complexa, a carei rezolvare poate duce la utilizarea simultana a mai multor produse software in acelsi timp. Acest lucru presupune folosirea unor sisteme informatice diferite , in functie de natura activitatilor desfasurate : financiar – contabil, productie, logistica, etc. In aceste conditii, transparenta datelor si accesul la informatii in timp util intr-o companie pot deveni o provocare. De aici rezida necesitatea existentei unei platforme integrate in care sa se regaseasca toate informatiile necesare pentru derularea corecta si eficienta a business-ului.

Astfel de sisteme informatice integrate detin o serie de particularitati care diferentiaza sistemul ERP de alte tipuri de sisteme informatice:

Un ERP este un sistem informatic care centralizeaza toate informatiile dintr-o companie pe o platforma unica, oferind accesul la orice tip de informatie, coordonare si comunicare.

Alegerea unui sistem ERP adecvat necesita o analiza de business, care implica cunoasterea si stabilirea fluxului de activitati si documente specifice companiei, identificarea necesitatilor clientului si a customizarilor necesare pentru desfasurarea la parametrii optimi a activitatii.

Un ERP nu este o „solutie standard”, ci este insotit permanent de servicii de analiza, implementare, training, suport, tehnologie de ultima generatie etc. si implica resurse specializate: implementatori, dezvoltatori, analisti de business.

Un sistem ERP acopera toate tipurile de activitati ale unei companii, precum productie, gestiune, contabilitate, centre de cost, bugete, logistica, etc.

Flexibilitatea este un atribut specific unei solutii ERP, acesta permitand customizarea sistemului pe specificul clientului.

Scalabilitatea ERP-ului presupune capacitatea de a folosi acele functionalitati care iti sunt necesare intr-un anumit moment din evolutia unui business. Pe masura ce compania se dezvolta se pot implementa alte componente avansate precum logistica, controlling, se pot reorganiza fluxurile de business, redimensiona restrictiile si permisiunile etc. Practic, un ERP reprezinta o platforma de dezvoltare pe termen lung.

Dezvoltarea sistemului ERP pe tehnologie de ultima generatie permite functionarea acestuia la parametrii optimi.

Acoperirea unei arii largi de activitati ofera ERP-ului caracterul de software orientat spre fluxuri si procese de business si optimizarea acestora, si nu orientat spre documente si munca repetitiva.

ERP-ul este un instrument de luare de decizii. Pe langa integrarea proceselor de business, managerii au la indemana instrumente de analiza a profitabilitatii, vanzarii, costurilor.

1.2.3. Avantajele sistemelor ERP

Valoarea adusă de un ERP este îmbunătățirea modalității prin care comanda unui client se transforma într-un venit pentru companie, pe scurt optimizarea procesului de onorare a unei comenzi prin automatizarea pașilor necesari. Când utilizatorul introduce o cerere într-un sistem ERP el are toate informațiile necesare pentru a duce comanda la bun sfârșit inclusiv bonitatea clientului, notele de inventar ale gestionarilor, chiar și programul mașinilor ce transportă produsele.

Orice persoană cu acces la informații le poate actualiza păstrând astfel reale datele cu privire la procese. Pentru a vizualiza starea unei comenzi e necesară o simpă logare în sistemul ERP. Onorarea comenzilor devine astfel mai sigură, mai rapidă, mai satisfăcătoare pentru clienți. Un ERP are astfel de avantaje indiferent că vorbim de un domeniu precum producția, distribuția sau serviciile.

Un ERP rămâne însă un simplu software dacă informațiile nu sunt updatate la timp de către personalul din modulele implicate în procesele companiei. Însă atunci când tehnologia și personalul conlucrează spre crșsterea profitabilității companiei, putem vorbi despre adevaratul unui ERP: creșterea profitabilității companiei.

Pentru ca un ERP să îmbunătățească perfomanțele unei companii, primul pas îl reprezintă alegerea și implementarea unei soluții perfomante, apropiată de specificul de activitate al companiei, astfel încât nivelul de configurare să fie minim, o soluție care să fie confirmată de referințe.

Principalele avantaje ale folosirii unui sintem ERP sunt urmatoarele :

Reducerea costurilor de operare – Sistemul ERP este compus dintr-o serie de module care sunt destinate diverselor departamente precum productie, financiar-contabil, achizitii, vanzari etc. Chiar daca are o natura extrem de variata, informatia este operata o singura data si este accesibila oricarui modul ii este necesara. Astfel se economisesc resurse, se diminueaza probabilitatea de a comite erori de operare, se faciliteaza accesul la informatie de ultim moment. In plus, ERP permite automatizarea activitatilor repetitive, precum emiterea facturilor si a documentelor anexe, generarea de comenzi de reaprovizionare sau transfer din alte depozite pe baza comenzilor de vanzare si multe altele.

Imbunatatirea proceselor de vanzare – Modulul de vanzari din sistemul ERP permite unei companii sa-si (re)organizeze si urmareasca procesul de vanzare intr-un mod eficient, datorita optiunilor multiple de configurare si urmarire a canalelor de vanzare acoperite. Agenti comerciali, divizii de vanzari, distribuitori, Key accounts, retail, legatura cu portalul online sunt doar cateva dintre facilitatile oferite.

In functie de complexitatea procesului comercial si/sau a dimensiunii companiei, poti opta atat pentru componentele ERP-ului dedicate optimizarii si gestionarii diviziilor si zonelor de vanzare, comenzilor de client, facturilor etc., dar ai la dispozitie si add-onuri specializate pe fiecare canal de vanzare in parte: agenti de teren, magazine, online, IKA sau de tip CRM, dedicate managementului relatiilor cu clientii efectivi si potentiali si partenerii de afaceri.

Cresterea nivelului de onorare a comenzilor – Prin automatizarea lantului de preluare a comenzilor, achizitie, management stocuri, depozit, logistica, se elimina marea majoritate a potentialelor disfunctionalitati care conduc la neonorarea cererilor sau la livrarea de bunuri necomandate. Modulul Logistica din sistemul ERP permite planificarea si fluidizarea proceselor de aprovizionare, stocare, redistributie a bunurilor in interiorul unei companii sau livrare de bunuri catre clienti.

Imbunatatirea cash-flow-lui – Prin implementarea de politici comerciale coerente si prin usurinta cu care se pot obtine indicatorii specifici, compania isi controleaza mult mai strict fluxurile monetare si perioadele de recuperare a banilor, impunand o disciplina financiara tuturor factorilor implicati. Modulul Controlling din ERP permite planificarea parametrilor financiari si ofera atat capabilitati proactive pentru avertizarea din timp in cazul depasirii negative a acestora cat si instrumente de analiza complexe in vederea determinarii factorilor de influenta.

Optimizarea stocurilor – In multe cazuri s-au semnalat reduceri majore ale valorilor imobilizate in stocuri, in conditiile in care satisfactia clientilor a crescut. Acest lucru se datoreaza instrumentelor de management operational si decizional care permit controlul proceselor de aprovizionare, productie, picking,  livrare etc. De asemenea, sunt tinute sub control stocurile care au termene scurte de expirare, rotatie lenta etc. In cazul firmelor care lucreaza cu stocuri pentru mii de produse si au procese de aprovizionare complexe si mari consumatoare de timp si resurse, add-onul SeniorInventory este extrem de util pentru optimizarea avansata a acestor procese, rezultand in reducerea cu pana la 85% a timpului de planificare a aprovizionarii.

Gestionarea eficienta a activitatii de productie – Responsabilii din cadrul departamentului de productie au la dispozitie o serie de instrumente prin intermediul carora sa isi gestioneze activitatea: retete de productie, bonuri de intrare, de consum, wizard-uri de generare automata a documentelor, rapoarte de stoc in functie de reteta aferenta produsului etc. Astfel, se obtin o serie de beneficii, cum ar fi:

Automatizarea fluxurilor specifice activitatii de productie;

Posibilitatea de a urmari trasabilitatea de la materiile prime la produsul finit;

Transparenta costurilor de productie;

Echilibru intre productia previzionata si cea efectiva.

Faciliteaza procesul decizional – Deciziile de zi cu zi sunt luate pe baza informatiilor disponibile pe moment. Pentru analiza datelor, sistemul ERP ofera o serie de rapoarte pentru indicatorii de business, grupate pe categorii: vanzari, achizitii, stocuri etc. Sistemul BI ofera simplitatea in utilizare – doar drag&drop – si capabilitati avansate de analiza si raportare.

Fiind un singur sistem, exista o singura viziune a rezultatelor. Se elimina astfel problema “adevarurilor multiple”, in care fiecare departament are propriul set de rezultate, analize si concluzii, adesea contradictorii.

Sistemele ERP actuale realizeaza integrarea tuturor functiilor de conducere ale unei companii, plecand de la planificare, asigurarea stocului de materii prime si materiale, definirea tehnologiilor, coordonarea proceselor de productie si, nu in ultimul rand, la realizarea gestiunii financiar contabile, a resurselor umane, a stocurilor de produse finite si terminand cu dezvoltarea si mentinerea relatiilor cu clientii si partenerii de afaceri.

O astfel de aplicatie ERP permite factorilor de decizie realizarea unor analize complete asupra realizarii planului de afaceri. Prin optiunile de simulare a activitatilor si prin caracterul flexibil si dinamic al aplicatiilor se pot realiza planuri de previziune, evaluari si predefiniri ale tendintelor de evolutie ale industriei din care face parte compania, analize calitative, integrarea cu noile tehnologii e-business si comunicare online.

1.3. Fluxuri de afaceri electronice B2B

1.3.1. Comerțul electronic – definire

Comerțul electronic, cunoscut in mod normal ca E-Commerce (Electronic Commerce), reprezinta activitatea de cumpărare sau vânzare prin intermediul retelelor de internet. Presupune transmiterea de date la distanță printr-un sistem de comunicatii (de exemplu, Electronic data interchange – EDI), care permite dezvoltarea unei relații de servicii și schimb de mărfuri între ofertant și viitorul cumpărător.

Comertul electronic este considerat, in general, ca fiind modulul de vanzari al afacerilor electronice (e-business). Consta, de asemenea, in schimbul de date care faciliteaza aspectele legate de plati din cadrul tranzactiilor de afaceri. Acesta reprezinta o cale eficienta si eficace de comunicare intre organizatii si una dintre cele mai eficace si folositoare moduri de conducere a unei afaceri. Reprezinta o strategie de marketing unde intreprinderea poate sau nu avea o prezenta fizica.

Stabilirea unei prezențe on-line ar trebui să fie privita ca parte a unei strategii de creștere pe termen lung și de bază pentru orice ofertă cu adevărat multicanal. Ce necesită acest lucru însă, este o platforma de comert electronic adecvata, care sa-i permite clientului o experiență eficientă și placuta in acelasi timp.

Utilizarea tuturor mijloacelor electronice pentru participarea la o activitate de comerț electronic poartă denumirea de tranzacție electronică.

Din studiile de specialitate ale economiștilor a rezultat ca e-commerce ar trebui să conducă la o concurență de preț intensificat, deoarece sporește posibilitatea consumatorilor de a aduna informații despre produse și prețuri. În general, firmele mari sunt capabili de a utiliza economii de scară și de a oferi prețuri mai mici.

Indivizii sau organizatiile implicate în e-commerce, fie ei cumpărători sau vânzători, se bazează pe tehnologia bazata pe Internet, în scopul de a realiza tranzacțiile lor. E-commerce este recunoscut pentru capacitatea sa de a permite diferitelor organizatii sa comunice și de a realiza tranzacții în orice moment și oriunde. Puterea e-commerce-ului permite barierelor geofizice să dispară, făcând toti consumatorii și toate întreprinderilor de pe pământ potențiali clienți și furnizori.

1.3.2. Categorii de comerț electronic

Comerțul electronic permite participarea atât a persoanelor fizice și juridice, cât și a statului sau a instituțiilor acestuia. În funcție de relațiile dintre acești participanți au luat naștere mai multe categorii de comerț electronic.Utilizarea tuturor mijloacelor electronice pentru participarea la o activitate de comerț electronic poartă denumirea de tranzacție electronică.

B2B (business-to-business) – Este un model de comerț electronic în care toți participanții sunt companii sau alte organizații

B2C (business-to-consumer) – Model de comerț electronic în care companiile vând la cumpăratori individuali – persoane fizice.

C2B (consumer-to-business) – Acest model de comerț electronic se referă la persoanele fizice (consumatori) care utilizează Internetul pentru a-și vinde produsele sau serviciile firmelor și pentru a căuta vânzători care să liciteze pentru produsele sau serviciile de care au nevoie.

C2C (consumer-to-consumer) – Acest model se referă la consumatorii care vând direct la alți consumatori. Un exemplu din acest domeniu care are un succes enorm în întreaga lume este sistemuleBay.

E-government – Această formă de comerț electronic este întâlnită în următoarele forme: B2G (business to government), G2B (government to business), G2C (government-to-consumer)

1.3.3. Conceptul de B2B (business-to-business)

Notiunea de Business to Business se refera in principal la tranzactiile comerciale dintre organizatii, persoane juridice, fiind opusul tranzactiilor Business to Consumers (B2C) care implica consumatorul final. Termenul poate descrie, de asemenea, o companie care furnizeaza produse sau servicii sltei companii. Exemple din aceasta categorie pot fi relatiile dintre producatori si angrosisti sau dintre comercianți cu amănuntul si angrosisti.

Volumul total al tranzacțiilor B2B (Business-to-Business) este mult mai mare decât volumul de tranzacții B2C. Principalul motiv pentru aceasta este faptul că într-un lanț tipic de aprovizionare vor exista mai multe tranzacții B2B ce implică subcomponente sau materii prime, și numai o tranzacție B2C, în special vânzarea produsului finit la clientul final. De exemplu, un producător de automobile face mai multe tranzacții B2B, cum ar fi cumpărarea de anvelope, de sticlă pentru parbrize, și furtunuri de cauciuc pentru vehiculele sale. Tranzacția finală, un vehicul terminat vândut consumatorului, este o singura tranzacție (B2C).

B2B este, de asemenea, utilizat în contextul de comunicare și colaborare. Multe companii folosesc acum mediul social pentru a se conecta cu consumatorii lor (B2C); cu toate acestea, ele folosesc acum instrumente similare ca cele din afaceri astfel încât angajații se pot conecta unul cu altul. Atunci când comunicarea are loc în rândul angajaților, acest lucru poate fi mentionat ca comunicare "B2B".

1.3.4. Beneficiile comerțului electronic

Beneficiile duse de comertul electronic sunt considerabile, atat pentru afaceri cat și pentru consumatorii obișnuiți, ambele entitati având aceleași așteptări înalte in momentul achiziționării de bunuri, amintindu-și de experiențele bune și rele. O platforma online eficienta pentru comert electronic permite, de asemenea, companiilor să integreze canalele de distribuție și partenerii, oferind campanii de marketing orientate si promotii, oferind clientilor acces la disponibilitatea stocurilor și statusul comenzilor.

Această experiență completă, cu toate acestea, este posibilă numai prin integrarea unei platforme de comert electronic adecvata întregii afaceri, folosind tehnologia adecvată de back office, cum ar fi managementul relatiilor cu clientii (CRM), sisteme de inventar și management sistemelor de gestiune a bazelor de date (MDM). Acest proces ar putea fi gestionate manual, prin modificarea produselor, adăugarea și îndepărtarea de pe foile de calcul tabelar, dar aceasta actvitate consuma mult timp și bani. Lasă datele deschise la erori umane, precum și posibilitatea de duplicare. Aceasta va duce la un serviciu slab din punct de vedere calitativ, cu produse gresit detaliate și clienții care nu a primit bunurile pe care le așteptau.

O soluție MDM servește ca un depozit central pentru toate informațiile cu privire la produsele deținute, ceea ce usureaza procesul de modificare și actualizare și asigurarea că există consistență in afaceri.

Având ca suport rețeaua Internet și eventual și utilizarea unor pachete de programe software specifice, comerțul electronic a avut și are avantaje și beneficii pentru firme, consumatori individuali și societate.

Pentru companii

1. Extinderea pe piețele internaționale prin asigurarea de servicii și performanță;

2. Asigurarea unei deschideri totale în privința relațiilor cu clienții: aceștia pot căpăta o imagine aproape completă asupra tuturor angajaților, ofertanților și partenerilor lor.

3. Scăderea costului de creare, procesare, distribuire, păstrare și regăsire a informației, până acum bazată pe hârtie, prin crearea unui sit web atractiv cu funcția unui magazin virtual. Siturile web personalizate, sugestiile pentru cumpărare și ofertele speciale personalizate pot într-o oarecare măsură substitui interacțiunile de tip față în față, de tip tradițional;

4. Creează posibilitatea modelării produselor și serviciilor după nevoile cumpărătorilor și simplificarea procedurilor;

5. Costuri de comunicație mai mici.

6. Seriozitate și siguranță. Serverele paralele, redundanța hardware-ului, tehnologia fail-safe, încriptarea informației și firewall-urile pot îndeplini această cerință;

7. Creșterea competitivității și raționalizarea proceselor de afaceri, prin restructurări interne și prin tehnologii ale informației.

8. Construirea unui lanț valoric electronic, în care se pune accentul pe un număr limitat de competențe-cheie – opusul unui magazin "cu o singură oprire". (Magazinele electronice pot fi atât speciale cât și generale, dacă sunt programate corect.)

Pentru consumatori

1. Posibilitatea consumatorilor să cumpere sau să facă tranzacții la orice oră din zi, în tot timpul anului, din aproape orice locație;

2. Acordă consumatorilor mai multe posibilități de alegere a produselor și prețurilor;

3. Consumatorilor li se dă siguranță asupra valorii. Vânzătorii pot realiza acest lucru oferind un produs sau o linie de produse care atrage potențialii clienți prin prețuri competitive, la fel ca și în comerțul ne-electronic;

4. Permite o livrare rapidă a produselor și/sau serviciilor (în anumite cazuri);

5. Consumatorii pot să primească informații relevante în decursul câtorva secunde, și nu zile sau săptămâni;

6. Asigurarea motivației consumatorilor de a cumpăra și, la nevoie, de a și returna. Vânzările promoționale pot implica cupoane, oferte speciale sau reduceri. Linkurile de pe alte situri web și programele afiliate de reclame pot fi de asemenea de ajutor;

7. Face posibilă participarea în licitații virtuale;

8. Îndemnarea consumatorilor la consum. Comercianții din Internet pot asigura acest tip de ajutor printr-o amplă informare comparativă și prin facilități bune de căutare;

9. Permite consumatorilor să interacționeze cu alți cumpărători în comunități electronice și să compare experiențele;

10. Lăsând clienții să se ajute singuri. Asigurând funcționarea unui sit de autoservire, ușor de folosit fără asistență, poate fi de ajutor în acest sens;

11. Facilitează competiția, ceea ce rezultă în scăderea prețurilor.

12. Familiarizează consumatorii cu tehnologia și îi ține pe aceștia în pas cu ultimele noutăți.

Pentru societate

1. Crearea unui "simț comun" al comunității comerciale, de exemplu prin chaturi, foruri ce solicită implicarea clientului, scheme de loialitate și programe de afinitate;

2. Dă posibilitatea mai multor persoane să lucreze / să cumpere de acasă, ceea ce micșorează traficul rutier și poluarea aerului;

3. Permite ca anumite mărfuri să fie vândute la prețuri mai scăzute, cu avanateje pentru cei cu venituri mai mici;

4. Crește eficiența și/sau îmbunătățesc calitatea;

5. Pune la dispoziție o organizare suficient de atentă și agilă pentru a răspunde rapid la orice schimbări din mediul economic, social și fizic.

1.4. PREZENTAREA SOLUȚIEI INFORMATICE – SAP – System Applications Products

Un Sistem de gestiune al Resurselor Întreprinderii (ERP – Enterprise resource planning) este un sistem informatic integrat, de obicei structurat în module, care permite managementul complet al funcțiilor de business din companie.

Multe aplicații de business cheie sunt acum implemetate folosind software ERP complexe si cuprinzătoare.

Programele ERP facilitează fluxul de informații de-a lungul tuturor proceselor unui lanț de aprovizionare al organizației, de la vanzări la cumpărări, incluzand contabilitate și resurse umane.

Programele ERP elimină problema comună a mai multor software-uri și baze de date incompatibile din diferite compartimente funcționale ale multor corporații.

Cu un sistem integrat cuprinzător (care poate fi distribuit internațional) cu o bază de date, procesele functionează mai usor cu informații la zi disponibile în corporație.

SAP (System Aplications Products) este unul din cele mai folosite sisteme ERP pentru companiile medii și mari.

Sistemele R/3 de la SAP sunt aplicații în timp-real pentru o gamă completă de activități comerciale.

SAP R/3 este soluția software integrată pentru client/server și sisteme distribuite deschise.

Programul este foarte personalizabil folosind propriul limbaj de programare, ABAP/4.

1.4.1. Cine/Ce este SAP-ul? Cât de popular este?

Compania SAP, ia naștere în anul 1972 în Germania, la inițiativa a 5 fosti ingineri IBM. O traducere a prescurtării SAP (System Aplications Products) ar fi „Sisteme, Aplicații, Produse în procesarea de date“.

Numele intreg al societatii germane este SAP AG și este localizată în Walldorf-Germania, în apropierea orașului Heidelberg. Filiale ale societății au fost deschise în mai mult de 50 de țări din toată lumea, din Argentina în Venezuela, Australia, Africa și binențeles în Europa.

Fondatorii societății, au avut atât de mult succes încât, numarul lor s-a înmulțit, societatea SAP AG devenind a 3-a producătoare de software din lume, cu mai mult de 17.500 de clienți ( printre care mai mult de jumatate din primele 500 de companii din lume).

În momentul de față, în lume există peste 44.500 de licențe SAP, în 120 de țări, și în jur de 10 milioane de utilizatori.

De ce a avut un asemenea succes această companie? Daca ne întoarcem în trecut, mai precis în anul 1979, prima variantă a programului, SAP R/2 a fost lansată pe piața germană cu un imens succes, fiind primul program ce oferea suport total unei companii. Timp de câțiva ani, programul rămâne doar în interiorul Germaniei, fiind adoptat de toate marile companii. Dorind și o mai mare expansiune, în anii 80, programul depășește granițele Germaniei și în 1992 este lansată o alta versiune a programului, R/3, aceasta dovedindu-se a fi o și mai buna versiune de SAP, mai ales în America de Nord.

În 5 ani, piața nord americană a crescut de la 0 la 44% din totalul mondial de vânzări. SAP America are în jur de 3.000 de angajați, din lista lor de clienți făcând parte primele 8 companii de semiconductoare și primele 7 companii farmaceutice.

În momentul de față, programul SAP ofera versiuni specifice pentru 46 de țări, incorporand 28 de limbaje.

SAP R / 3 este livrat unui client cu un proces standard pornit, și multe alte procese opționale și funcții dezactivate. SAP R/3 se bazeaza pe aproximativ 10.000 de tabele care controlează modul în care procesele sunt executate.

Configurare este procesul de ajustare a setărilor acestor tabele pentru a obține modul de funcționare dorit al programului SAP.

Ofera suport pentru: contabilitatea financiară ( FI –clienți, furnizori, conturi), management-ul contabilității (CO-centre de cost, analiza profitabilității ), vânzări și distribuție (SD), producție, aprovizionare, salarizare, resurse umane, planificarea producției. Toate aceste module sunt bine integrate.

1.4.2. Cui este adresat? De ce ai nevoie de el?

Toate marile și foarte marile companii au “adoptat” acest program, dar se observă o creștere a numarului de companii “mici” care folosesc programul.

Există multe motive pentru o companie de a selecta și implementa SAP-ul, unele bune (inlocuirea unei arhitecturi IT invechite si ineficiente, obtinerea unui avantaj competitiv) dar și unele nefavorabile (costul ridicat și intrebarea “De ce suntem singura companie de materiale semiconductoare fără SAP ? ”).

Mai multe avantaje ale utilizării de SAP:

Înlocuirea unei structuri IT învechite și ineficiente:

La început, sisteme de calculatoare au fost dezvoltate de către departamentele individuale pentru a satisface cerințele nivelului respectiv. Când s-a constatat că integrarea acestor sisteme ar aduce multe avantaje, s-a decis corelarea lor într-un sistem unic integrat.

Există foarte multe companii, cu mii de interfețe, fiecare necesitând întreținere. Înlaturând toate aceste interfețe și înlocuindu-le cu SAP, se pot economisii foarte mulți bani.

Activarea schimbării procesului de bussines: de la început, SAP-ul a fost construit pe o fundație bazată pe cele mai bune practici. Desi sună absurd, este probabil mai usor și relativ mai ieftin să adaptezi procesele companiei tale la SAP decât în sens invers.

1.4.3. Cât costă? De ce este nevoie pentru implementare?

Există un moment de răscruce în calatoria oricarei companii pe drumul spre Nirvana SAP. Acest moment vine doar după ce compania a ajuns la concluzia ca vrea SAP, are nevoie de SAP, trebuie să aibă SAP … apoi vine întrebarea:

de ce este nevoie pentru a implementa SAP?

În centrul fiecarei afaceri de succes, se afla o analiză cost-beneficiu. Dacă analiza nu are un rezultat pozitiv, inițiativa (oricare ar fi ea ), nu ar trebui lansată. Același lucru este valabil și pentru implementarea SAP.

Implementarea SAP este scumpă, fără nicio îndoială dar potențialele recompense pot reduce substanțial costurile.

SAP vinde R/3 la “un preț/utilizator”. Prețul real, este deci, negociat cu fiecare client, și prin urmare depinde de foarte multi factori printre care: număr de utilizatori, număr de module etc. Pentru a vă face o idee, costul poate să înceapă de la 4.000$/utilizator. Există de asemenea, un cost pentru suport anual, de aproximativ 10%, care include anumite up-grade-uri.

Mai există apoi, costul implementarii. Principalii factori din costul total de punere în practică:

timpul : cea mai rapida implementare a fost făcută în 45 de zile, însă aceasta a fost făcută asupra unei firme mici, cu puțini utilizatori și nu a fost nevoie de modificări aduse proceselor livrate standard. La polul opus, se afla multinaționalele care implementează programul într-un interval de la 5-10 ani. Acest lucru însă, nu este considerat un eșec. În mod normal, implementarea SAP într-o companie, durează între 9-18 luni.

Resursele umane: cea mai mica implementare, se poate face part-time, fără ajutor din afară. Cea mai mare implementare, poate să înghită sute de persoane, uneori mii, și include o armată de consultanți.

Resursele hardware : cea mai mică implementare utilizeaza în jur de 3 instanțe, câte una pentru sistemul de: producție, test și dezvoltare.

Cele mai mari implementări, au mai mult de 100 de instanțe, mai ales în cazul în care sunt implementate proiecte paralele.

Adăugând toate acestea la costul inițial, un proiect SAP poate costa între 400.000 $ până la sute de milioane de dolari.

1.5. Arhitectura si functionalitatea solutiei integrate SAP in cadrul Pirelli

SAP R/3 are o arhitecura client/server pe 3 nivele. Configurația clasică conține 3 nivele de aplicații: prezentare, aplicații și baza de date.

Figura 1.4 Prezentarea nivelelor de aplicații

1. Nivelul prezentare. Cuprinde componentele software instalate pe computerul utilizatorului și care realizează interfața grafică. Este un program numit ‘sapgui.exe’. Primește date și le trimite serverului de aplicații și primește date pe care le afișează pe ecran.

2. Nivelul aplicație. Este format din una sau mai multe aplicații de server și un serviciu de mesagerie. Aplicația de server este locul unde funcționează programele ABAP. Acesta este definit ca un set de executabile care interpretează programele ABAP/4 și gestioneaza intrările și ieșirile din ele. Serverul de aplicație comunică cu componentele de prezentare, baza de date și celelalte prin intermediul serviciului de mesagerie. Serviciul de mesagerie trimite cererile de la o aplicație la alta în cadrul sistemului. De asemenea ține evidența echilibrării încărcării în interiorul grupului de servare de aplicații. Folosind aceste informații va alege un server potrivit cand un utilizator se conectează la sistem. Un calculator central funcționează ca server de baze de date – procesele reprezentând baza de date ce rulează aici. Un număr de aplicții de server diferite pot fi conectate într-o rețea, ditribuite geografic, în server-ele bazei de date. Aceste servere de aplicații pot rula pe sistemele Windows NT, majoritatea sistemelor UNIX, etc.

3. Nivelul basei de date. Este format dintr-o bază de date centrală care conține toate informațiile din sistemul R/3, format dintr-un sistem de gestiune al bazelor de date (DBMS) și baza de date care conține toate datele din R/3. SAP nu are o bază de date proprie dar poate utiliza baze de date diverse (ORACLE, INFORMIX, Microsoft SQL Server, DB2/Common Server etc). Este folosit limbajul SQL pentru a definii și manipula toate datele. Aplicațiile sunt preluate din baza de date, încărcate în nivelul aplicație și rulate de acolo.

1.5.1 Descrierea principalelor module

Figura 1.5 Module SAP

Material Management

Sales and Distribution

Financial Accounting

Production Planing

Controlling

Human Resources (Resurse umane)

Customer Relationship Management CRM – managementul relațiilor cu clienți

Supplier Relationship Management – Managementul relațiilor cu furnizorii

Product Lifecycle Management – Managementul ciclului de viață al produsului

Supply Chain Management – Managementul lanțului de aprovizionare

Business Intelligence

Principalele module SAP si functionalitatile acestora:

MM ( materials management – managementul materialelor ) stă la baza lanțului de aprovizionare, inclusiv:

Rechiziții

Ordinele de cumpărare

Marfă

Conturi de plătit

Inventar de management

Master data pentru materii prime, produse finite etc

SD ( sales and distribution – vânzări și distribuție )

Ordine de vânzare

Stabilirea prețurilor

Culesul (și alte procese de depozit)

Ambalarea

Transportul

FI ( financial accounting – contabilitate finaciară):

Cartea Mare

Fiscalitate

Contabilitate clienți

Contabilitate furnizori

Active

CO (controlling – contabilitatea de gestiune) conține:

Elemente de cost

Centre de cost

Centre de profit

Comenzi interne

Activitate pe baza costurilor

Costul produsului

Din toate aceste module specifice diferitelor departamente functionale are intreprinderii, am sa ma opresc la prezentarea modulului SD ( Sales and Distribution) – Vanzarile.

Aplicația SD, integreaza toate cerințele internaționale care trebuiesc a fi îndeplinite de departamentul de vanzari al unei societăți.

Caracteristici :

Managementul și reprezentarea tuturor datelor logistice si comerciale (toate tranzacționările sunt înregistrate în conformitate cu principalul document, care oferă o pistă de audit neîntrerupt din situațiile financiare).

Este deschisă și integrată fluxului de date: fluxul de date între SD și celelalte componente ale sistemului SAP, este asigurat prin actualizări automate. Datele sunt disponibile în timp real în SD.

Integrarea SD cu alte componente

Toate operațiunile relevante, efectuate în Logistică ( LO ) sunt înregistrate în SD, în timp real. Acest lucru, asigură faptul că mișcările de bunuri în logistică se reflectă cu exactitate în contabilitate.

Fluxul de date/ documente este urmatorul: de la departamentul de Achizitii (MM – Material Management) – informatiile ajung in SD unde se efectueaza o inregistrare a acestora in conformitate cu legislatia si conditiile impuse de clienti – date care ulterior ajung la departamentul de Contabilitate (FI – Financial). Acesta din urma transmite datele prelucrare la nivel contabil catre departamentul de Controlling (COPA) – de unde rapoartele finale cu privire la intreaga activitate a firmei pe anumite perioade este transmisa catre diferitele niveluri decizionale.

1.5.2. Unitati organizaționale

Unitatea organizațională este un element de structură logică, importantă pentru vanzari. Sunt folosite pentru a structura funcțiile de afaceri și pentru raportare.

Company code – entitate legala si independent din punct de vedere contabil pentru care, trebuie creat un set de conturi. Aceasta include crearea tuturor elementelor legale cum ar fi Balance Sheet (bilanț), Profit and Loss Statement (balanța de profit și pierdere). Tranzacțiile relevante pentru contabilitate sunt salvate, înregistrate și evaluate la nivel de company code. La nivel de client, se pot crea mai multe company code, acestea pot sa difere prin locul de origine (țări diferite), valută, taxe și specificații legale. Pentru a putea folosi și alte module ale SAP, trebuie neapărat făcută legătura între unitățile organizaționale ale modulului SAP și celelalte module, aceasta fiind necesară la transferul datelor între module.

Sales Area. formata din Sales Organization, Distribution Chanel, Division.

Sales Area – Este responsabila pentru distribuirea bunurilor si serviciilor, negocierea conditiilor de vanzare, raspunderea pentru produsele vandute si drepturile clientilor asupra resurselor etc. Organizatia de vanzari este o unitate organizationala din logistica care grupeaqza intreprinderile in functie de cerintele regionale de vanzare. Poate fi gandita ca o subdiviziune a pietei regionale, nationale sau internationale.

Distribution Chanel – canalul de distributie, caracterizeaza modul in care bunurile ajung la client.

Division – divizia, se refera la tipul produsului/serviciului oferit ajutand la gruparea cestora: anvelope pentru autoturisme, autocamioane, garantii etc.

Plant – reprezinta locatia unde materialele sunt pastrate, si poate fi un deposit sau o fabrica.

Storage location – depozitul (care poate fi intern sau extern) unde este depozitata marfa intre activitatile de productie si vanzare.

Shipping Point – este o parte integrate a modului de vanzari. Shipping Point-ul sau puncul de incarcare si plecare a marfii este o unitate organizationala de nivel inalt care controleaza activitatile de tranport. Unul sau mai multe punct ede placare poate fi asignat unui Plant.

Setările de bază în SD, sunt setări particulare ce trebuiesc făcute pentru a se putea desfășura procesele de vanzari. Se poate crea o structură organizațională specifică unei companii, definindu-i unitățile functionale și realizându-i setările de bază.

În SAP, este obligatoriu să se defineasca unitatea funcțională pentru fiecare componentă ce trebuie implementată.

Astfel:

Pentru a face transferul între componente diferite, trebuie să se asigneze fiecare unitate funcțională la toate celelalte unități funcționale (de exemplu, documente înregistrate în SD sunt transferate și în FI, în sens invers nu se procedează ). Această asignare se face o singură dată, transferul datelor fiind apoi făcut în automat.

CAPITOLUL II – Studiu privind customizarea Modului Vanzari si Distributie din cadrul sistemului SAP

Prezentare Modul SD – Baza se studiu

2.1.1. Prezentarea interfeței SAP

Din complexitatea intregii solutii informatice folosite in cadrul Pirelli m-am oprit asupra modulului Sales and Distribution. Facand parte dintr-un sistem integrat, toate modulele se regasesc pe aceeasi platforma, diferentele intre activitatile diferitelor departamente regasindu-se in tranzactiile si pragoramele cu care se lucreaza.

Asadar, interfata cu care se lucreaza este aceesi, indiferente de functia sau departamentul in care lucreaza o persoana.

Fig. 2.1 Interfața de logare SAP

Clientul reprezinta firma pentru care se face logarea in sistem. Un anumit utilizator poate avea acces sau nu la vizualizarea, modificarea sau stergerea datelor despre o anumita companie gestionata de SAP.

Userul si parola sunt datele necesare logarii in sistem si verificari autorizatiilor si rolurilor definite pentru o anumita persoana sau grup de persoane. Aceste date sunt confidentiale, dezvaluirea acestora putand duce la distrugeri, furturi si alte pagube semnificative.

Limba de logare este un aspect foarte important de care trebuie sa se tina cont in definirea cerintelor de creare a unui sistem informatic de mare anvergura folosit de companiile multinationale, asa cum este SAP. Fiind in mare parte utilizat de companiile mari si foarte mari, acest lucru implica existenta mai multor nationalitati, deci, implicit, este absolut necesar a fi creat cel putin in limbile de circulatie internationala : Germana, Engleza, Franceza, Italiana, Spaniola etc.

In cazul in care logarea se face cu un user de grup, care poate fi folosit de mai multe persoane in acelasi timp (de exemplu un departament, sau un grup de persoane cu aceleasi drepturi), exsita trei posibilitati :

Sa se inchida sesiunile de lucru ale celorlati utilizatri logati, si sa se continuie activitatea numai cu conexiunea curenta (neindicat, deoarece modificarile facute de ceilalti useri vor fi pierdute)

Sa se continuie activitatea celorlarte persoane deja logate in sistem cu userul de grup, in paralel cu conexiunea curenta – RECOMANDAT

Sa nu se mai realizeze conexiunea la sistem

Fig. 2.2 Optiuni logare

Interfata standard dupa logare, este urmatoarea :

Fig. 2. 3 SAP – Easy Access – Standard

Dupa cum se poate vedea, meniuri regasite, sunt structurate in functie de principalele activitati intreprinse in cadrul firmei : Contabilitate, Logistica, Resurse umane si alte instrumente folosite in gestiunea unei companii. In meniul de favorite se regasesc cele mai utilizare tranzactii, de unde pot fi rulate fara a fi nevoie sa se tasteze codul comenzii in Bara de comanda.

Binenteles, exista setari particulare, in functie de autorizatiile atribuite fiecarui utilizator, de a putea vedea si respectiv, folosi, doar o parte din acestea. De exemplu, unui angajat de la departamentul de Resurse umana nu ii sunt necesare tranzactiile folosite in cadrul Logisticii, si nici invers.

Fig 2.4 Prezentarea butoanelor din bara de stare

2.1.2. Prezentarea Meniului de Logistica

Modulul de Vanzari – Sales and Distribution este o componenta SAP ale carei actiuni sunt reflectate se gestionale in logistica firmei.

Fig. 2.5 Meniuri Logistica

Desi vanzarile sunt descrise ca o subdiviziune a logisticii, activitatea departamentul de SD se intrepatrunde cu managmentul materialelor (deschidere materiale noi, gestiune celor existente, caracteristicile acestora, piata de deschidere pentru fiecare dintre ele etc), definirea logica a reprezentarilor fizice (organizatii, fabrici, depozite, puncte de incarcare si de plecare etc), intretinerea bazei de date a clientilor si a altor parteneri (crearea clientilor in functie de zona, caracteristici, produse si pretur, precum si update-ul acestora – posibilitatea de cumparare a unui produs nous au dintr-o alta tara etc), gestionarea documentelor generate de fluxul de vanzare, a formatului acestora (tipul de output : printare, email, Idoc) etc.

Fig. 2.6 Meniuri SD

Fig. 2.7 Vanzari – legaturi functionale

2.1.3. Prezentarea tranzacțiilor în SAP

In momentul implementarii unui sistem informatic, acesta detine in mod implicit anumite facilitati (Programme, tranzactii, meniuri etc), insa ulterior acestiu proces, poate fi solicitata crearea si inserarea altora noi, in functie de nevoile actuale si viitoare ale clientului. Tinand cont de faptul ca organizatia Pirelli si toate companiile terte care folosesc SAP-ul ca solutie informatica, au nevoi diferite, cerintele de customizare sunt numeroase si eterogene.

Astfel ca, din multitudinea de tranzactii standard si customizate existente in SAP, am ales sa ma axez pe urmatoarele, ca fiind cele mai representative pentru modulul de SD.

În SAP, unele tranzacții conțin un șir de 2 cifre, cea de doua cifra : 1, 2 sau 3 semnifică dacă este o comandă de creare, modificare sau vizualizare. Pentru a introduce altă tranzacție fără a mai fi nevoie să te reîntorci în ecranul principal se adaugă înainte de comanda ” /n”, exemplu /nva03 pentru a vizualiza un ordin de vanzare, iar pentru a deschide în altă fereastră se folosește ”/o” înaintea comenzii. Comenzile nu sunt case-senzitive.

Exemple de tranzacții:

SE16 – vizualizare tabele (Fig. 2.8)

SM30 – modificare tabele

Fig. 2.8 Introducere nume table pentru navigare

Exemple de tabele:

VBAK – afișează conținutul antetului ordinului de vanzare (header)

VBAP – afișează conținutul line item-urilor de pe ordin

ZICI_DEST_PERS – tabela de gestiune a persoanelor de contact pentru ordinele aflate in erore.

ZICI_LINK_SO_PO – tabela de aliniare a ordinelor de achizitie cu ordinele de vanzare. De retinut este faptul ca atat clientii cat si furnizorii sunt entitati Pirelli, fie ca e vorba de tranzactii intre 2 depozite Pirelli, sau intre un depozit si un dealer Pirelli.

KNA1 – nomenclatorul de clienți cu date de nivel general

KNB1 – afișează clienții la nivel de company code

KNVV – afișează date particulare despre clienți

LFA1 – nomenclatorul de furizori cu date de nivel general

MVKE – contine date despre materiale la nivel de Sales Area

MARC – contine date despre materiale in functie de plantul/depozitul producator

MARA – nomenclatorul cu date generale despre material (denumire, data la care a fost creat in sistem, de catre cine, caracteristicile tehnice ale acestuia etc.)

LFA1 – tabelă furnizori

SU53 – Tabela de gestiune a utilizatorilor si a rolurilor atribuite acestora

VA01, VA02, VA02 – creare, modificare, vizualizare ordin de vanzare

VL01N, VL02N, VL03N – creare, modificare, vizualizare document de livrare

SM36, SM37 – tranzactii de creare, respectiv gestionare Joburi (progareme sau seturi de programe setate sa ruleze automat la anumite prioade de timp, sau la declansarea unor evenimente stabilite initial). Acestea pot avea ca rezultat extragerea unor rapoarte, update-ul unor tabele, trimiterea automata de documente la adresele tertilor (clienti, furnizor) etc.

ZOPT – Optimizator al operatiilor cu fluxul de documente. In cadrul acestei tranzactii, se poate monitoriza circuitul documentelor, in functie de documentele de referinta si documentele viitoare, materialele existente pe documente, depozitul de plecare si depozitul destinatie, clientii care au facut comanda si clientii la care ajunge marfa (subdivizuni ale clientilor initiali) etc. De exemplu, pornind de la un ordin de vanzare (de obicei vizualizat cu tranzactia VA03), se pot crea documentele de livrare si factura fara a mai fi necesara folosirea tranzactiilor (VL01N – creare livrare si VF01 – creare factura, precum si inserarea, din nou, a tuturor datelor existente pe ordin)

ZVDD05_KE si ZVDD06_KE – sunt tranzactii folosite de producator si client pentru confirmarea existei marfii in stoc – disponibila pentru livrare in conformitate cu cerintele clientului, respectiv confirmarea primirii marfii de catre client, in cadrul fluxurilor de Directe.

FBL1N – sold furnizor – evidentiaza, pentru un furnizor intern Pirelli, raportul dintre platile si incasarile efectuale pentru7 anumite produse sau servicii.

FBL5N – sold client

FB01, FB02, FB03 – creare, modificare, afișare document contabil – factura contabila

OBB08 – gestioneaza termenele de plata in functie de anumite criterii (metode, date limită, discount)

SUIM – tranzactie de gestiune a utilizatorrilor, acordarea de autorizati si definirea de roluri

A. SQ01 – tranzactie creare si executare query-uri (mici programe care interogheaza sau modifica baza de date), in fuctie de user group (grupul de prsoane autorizare pentru folosirea lor). Acestea pot avea ca rezultat rapoarte necesare personalului de pe nivelurile decizionale (rapoarte statistice), updatarea nomenclatoarelor de documente etc.

B. SQ03 – tranzactie info set (setul de reguli si autorizatii asignate unui query)

C. SQ02 – tranzactie de asignare info set la query

Prezentare studiu de caz pe un flux informational – Ordine Directe

2.2.1. Scurta prezentare flux directe

Datorita cresterii integrarii unitatilor de business localizate in diferite tari si urmand trendul in continua crestere de focusare asupra reducerii costurilor, numarul de « fluxuri directe » (de la producator direct la client) a crescut semnificativ.

Având în vedere aceste considerații Pirelli si-a intreptat atentia pe creșterea eficienței și eficacitatii în procesul de livrare directă în termeni de planificare, executa și monitoriza.

Fig. 2.9 Fluxul de bunuri si informatii

Principalele domenii care au fost imbunatatite prin trecerea la ordinele directe sunt :

Creșterea volumului fluxurilor de livrări directe în termeni de piese și numărul de transporturi

Crește nivelului serviciilor oferite clienților in ceea ce priveste eficacitatea procesului de planificare și execuție și de îmbunătățire transparentei procesului

Reducerea activităților neaducatoare de valoare adăugată efectuate de către diferiți actori în timpul procesului

Îmbunătățirea eficienței fluxului de comunicare între diferite funcții ale țările implicate

Pentru a completa procesul de Livrari Directe (Direct Deliveries – DD), a fost necesar ca acesta sa se imparta in trei subprocese separate :

Ordinul de intrare: introducerea unui model comun pentru livrările directe începând de la Fast Order Entry (Ordin Rapid) – tranzactia ZVOR, utilizata in locul tranzactiei standard VA03. Tranzactia ZVOR presupune completarea automata a documentului cu date predefinite din nomenclatorul de clienti. Sistem efectuează o primă alocare, propunand un producător, în funcție de Market (localizarea clientului)/ codul materialului identificand disponibilitatea din cursul unei luni a marfii dintr-un Plant (Depozit).

Planificarea transporturilor: activitate realizată la nivel de sector de departamentul de aprovizionare pentru a confirma producătorului care face aprovizionare și pentru a planifica transportul. A rezultat astfel o noua functionalitate in SAP (Load Optimizer Functionality) – optimizarea încărcarilor pentru a sprijini activitățile de planificare.

Executarea tranportului: activitate realizată de către departamentul de logistica local pentru a perfectiona transporturile și de a efectua activități de transport spre clientul final.

Scenariul astfel conceput prevede utilizarea SAP Intercompany Billing Procedure – procedura de facturare intre companiile afiliate.

Procedura este declanșată prin documentul unic SAP – Ordinul de vânzare de la Market (piața de desfacere) la clientul final – facand livrarea din depozitul producătorul. Producator va declanșa operațiunile de expediere și emite, cu referinta la ordinul de vânzare.

Acest tip de ordin de vânzare va conduce două proceduri de facturare : de la market la clientul final și de la producător la market.

Termenul de « market » caracterizeaza de fapt un client Pirelli, persoana juridica. Acesta primeste o comanda de la un client extern Pirelli, pe care nu o poate onora din stocul disponibil. Astfel ca apeleaza la o alta unitate de business (in cazul nostru, producatoru) pentru a-i oferii clientului sau produsele solicitate, el devenind un intermediar.

Fig. 2.10 Comunicatiile ICP

Factura de la producător la market va crea în mod automat un ordin de achizitie (Intercompany Purchase Order) și postarea in monitor (raport de gestiune a ordinelor directe) a factura ulterior.

Soluția se bazează pe funcționalitatea SAP prin care sistemul verifică Company code-ul organizației de vânzări și al depozitului din care se face livrarea și efectuează în mod automat procesarele de facturare Intercompany pentru diferitele venituri.

Prezentarea grafica a acestui flux este urmatoarea :

Fig. 2.11 Scenariul Fluxurilor de Directe

Un nou meniu a fost dezvoltat in SAP – ZVDD_KE – pentru a putea manevra cu usurinta toate tranzactiile relevante in termeni de configurare, executie si monitorizare a fluxurilor de directe :

Fig. 2.12 Meniu DD

Pasii cheie ai procesului sunt :

Se creeaza un ordin de vanzare cu un depozit de aprovizionare din alt Company code decat cel al organizatiei de vanzari.

Livrarea catre client se face direct din plantul de aprovizionare

Se emite factura catre clientul din organizatia de vanzari initiala

Se emite factura intercompany de la organizatia de vanzari a depozitului de aprovizionare

Principalul beneficiu adus de Fluxul de Directe in cadrul companiei Pirelli este: livrarile intercompany se pot realiza direct de la producator la client, chiar daca unitatilei organizationale si depozitele de aprovizionare se afla in Company Code-uri diferite (tari diferite).

Fig. 2.13 Entitati implicate in fluxul DD si documentele intalnite

2.2.2. Tranzactia Z_ICI_MONITOR

Fig. 2.14 Z_ICI_MONITOR

Aceasta tranzactie a fost creata pentru a putea fi monitorizat exclusiv si indeaproape fluxul de Livrari Directe (DD), pentru depistarea eroarilor in diferitele puncte cheie are circuitului documentelor.

Dupa cum am mentionat anterior, in cadrul unui circuit DD dintre tari ale Uniunii Europene, din afara UE sau o tara UE si alta Non UE, exista trei facturi : una de la Producator la PPI (Italia – legatura tari UE) / PTBS (legatura tari Non UE), de la PPI / PTBS la Market (intermediar), si alta de la Market la Clientul final (cel care a facut comanda).

In imaginea de mai jos am capturat screen-ul principal al trenzactiei ce contine criteriile de selectie pentru documentelele ce se doresc a fi verificate, fie la cererea unui utilizator care nu primeste un anumit document (din cauza unei erori care a blocat fluxul), fie ca urmare a unei activitati periodice de monitorizare a erorilor.

Fig. 2.15 Criterii de selectie Z_ICI_MONITOR

Primul criteriu de selectie a documentelor este actorul pentru care se verifica existenta eventualor probleme in cadrul fluxului. Acesta poate fi :

Market-ul, ce nu poate, din diferite motive sa emita factura catre Clientul final

Producatorul, ce nu poate emite factura catre Market, sau alte documente necesare continuarii fluxului

PPI si PTBS, ca puncte de legatura intre tarile UE si Non UE, pentru alinierea taxelor percepute pentru export

Alte entitati implicate in circuite definite particular, la cererea clientilor.

Fig. 2.16 Actorii participanti la flux

Al doilea criteriu de selectie este data facturarii, data sau interval necesare atunci cand nu se stie cu exactitate numarul documentului de monitorizat aflta in eroare.

Al treilea criteriu este documentul exact ce se doreste a fi verificat, sau un interval alocat unei anumite tari.

Urmatoarele criterii dupa care se poate face selectia sunt legate de codul alocat producatorului sau clientului care a facut comanda (Sold-to party), precum si date despre fluxul monitorizat.

Nu doar facturilor din cadrul unui flux DD pot fi in eroare, ci si Ordinele de vanzare, documentele de livrare, iesirile de marfa si alte documente ce fac parte din circuit. Acest lucru poate fi specificat in campul : Categoria Documentului.

In Z_ICI_MONITOR rezulta raportul din imaginea de mai jos ce prezinta situatia fluxului de DD pentru intervalul 01.06.2014 – 10.06.2014.

Se pot regasii : documentele aflate in eroare, cele realizate manual, cele ce asteapta ca Job-urile corespunzatoare (programe ce ruleaza automat la un interval de timp) sa trimita Idoc-uri in diferitele parti ale sistemului pentru a continua mersul normal al circuitului, documentele complete, precum si cele ce sunt procesate in momentul respectiv. Dupa cum am spus, indiferent din ce parte a globului se face o modificare in sistem, acesta apare in timp real la orice punct de lucru autorizat.

In partea de jos a ferestrei raportului, ca urmare a unui clic pe documentul dorit, apar date referitoare la acesta : de unde a plecat si unde trebuie sa ajunga (UE -> UE), tipul fluxului (ICP – intre companii afiliate), si scenariul (dintre cele trei existente : PPI -> Market).

In cazul nostru, eroare intalnita este la ultimul nivel al scenariului, lipsind factura pentru Market. Aceasta a fost emisa de Producator (Nr. Factura 7390112240), transmisa prin PPI (Nr. Factura corespondenta 2710405162) la Market, insa nu a for primita de Market, din cauza unei erori din nomenclatorul de produse al acestuia.

Pentru a rezolva aceasta problema, trebuie sa se introduca date noi cu referire la materialul in cauza.

Fig. 2.17 Exemplu eroare

In tab-ul de fluxuri complete, se regasesc documentele care, pe tot parcursul circuitului nu au intampinat probleme, sau ale caror probleme au fost rezolvate intre timp.

Aceasta fereastra are implementata si posibilitatea cautarii unui document particular, prin optiunea « Jump to », tinand cont de numarul mare de documente relizate intr-o perioada relativ scurta de timp.

Dupa cum se poate vedea, in lista cu documente ale fluxului, factura cu numarul 1174067716 emisa de Producator a fost primita cu succes de catre Market, statusul documentului nemaifiind «In eroare », ci «OK », urmat de numarul facturii corespondente (105022801). 

Fig. 2.18 Exemplu flux DD complet

2.3. Customizarea modului SD pentru Procesarea fluxului informational de Ordine Directe

2.3.1. Crearea unui QUERY si definirera parametrilor acestuia

Crearea unui query în SAP (interogarea bazelor de date) se realizeaza cu ajutorul tranzacției standard SQ01.

Fiecare query se realizeaza într-un Grup de utilizatori (User Group) care au dreptul de a vizualiza si folosi interogarea respectiva. Daca un utilizator nu este autorizat astfel incat sa aiba acces la unh anumit User Group, acesta nu poate accesa query-ul.

La baza fiecarui query sta un Info Set care reprezinta setul de informații, de exemplu, tabelele care vor fi utilizate în query. Un Info Set se creeaza cu ajutorul tranzacției standard SQ02, și apoi este asignat unui query. Acest query va putea utiliza doar câmpurile tabelelor cu ajutorul carora am facut Info Set-ul. Câmpurile din query pot fi utilizate în doua moduri: de selectie și de listare. Câmpurile de selectie sunt filtrele pe care le introducem în cautarea noastra în tabele, iat câmpurile de listare reprezinta informațiile returnate în urma rularii query-ului.

Un câmp de selectie poate să fie și câmp de listare.

Pașii în crearea unui query în SAP:

Creare InfoSet – Tranzacție SQ02

Inseram un nume pentru info set-ul pe care dorim sa-l cream (PL_DD_FLOW_NEW) și alegem optiunea “Create”.

Fig. 2.19 Creare InfoSet

Query-ul ce urmeaza a fi creat pa baza InfoSet-ului va necesita date din tabelele VBAK și VBAP, tabele cu date regasite in antetul (header) și pozitiile (item) din Ordinul de vânzare. Inseram numele InfoSet-ului, numele tabelei de baza și apasăm “ok”.

Fig. 2.20 Creare InfoSet – specificare tabele

Pentru adaugarea unei noi tabele in interogare, in cazul de fata – VBAP – apasam butonul “Add table”, tastam sau alegem din meniu numele tabelei si pasam “ok”:

Fig. 2.21 Creare InfoSet – adaugare tabele

In acest moment, exista doua posibilitati:

Tabelele intre care se face join au un camp comun de legatura (primary key intr-o tabela si foreign key in cealalta tabela) – caz in care se face lagatura in mod automat

Tabelele au un camp comun, dar nu este cheie primara sau externa pentru tabelele in cauza; in acest caz, legatura se face manual.

Fig. 2.23 Creare InfoSet – legaturi între tabele

Avand in vedere ca acest query este destinat folosirii de catre unul sau mai multi utilizatori ale caror cerinte pot varia in functie de diferitele schimbari ale mediului economic, trebuie sa luam in considerare posibilitatea modificarii ulterioare a raportului generat de aceasta interogare. Astfel ca, in InfoSet vom adauga toate campurile tabelelor folosite. Acest lucru se face urmand pasii: Click pe butonul “InfoSet” din stanga-sus a ferestrei si alegem varianta “Include all table fields”:

Fig. 2.24 Creare InfoSet – includere câmpuri

Urmatorul screen va afisa tabelele intre care s-a realizat join-ul si denumirile acestora, tabele ce pot fi expandate pentru a li se vedea continutul (campurile). Se apasa butonul Generate, pentru a genera InfoSet-ul creat.

Fig. 2.25 Activare InfoSet

Pe ecram va aparea un mesaj care ne informeaza ca s-a creat InfoSet-ul sau un mesaj de eroare, in cazul in care crearea sa nu a fost posibila: .

Query-ul creat este unul corect, dar incapabil sa ofere toate datele necesare referitoare la fluxul de directe, astfel ca, pe langa join-ul dintre tabele si selectia campurilor tinta, mai sunt necesare anumite specificatii ce pot fi facute doar din cod (ABAP).

Se apasa, deci, butonul “Code”:

Fig. 2.26 Modificare InfoSet

Prin aceasta actiune, ajungem in fereastra de cod unde, folosind instructiuni din limbajul de programare ABAP, putem definii cerinte suplimentare pentru completarea query-ului.

Fig. 2.27 Inserare cod

Code selection: Data

*****************************************

*Sales Order – Delivery- Invoice – Producer Invoice

*delivery

data v_delivery like likp-vbeln.

data v_posnn like lips-posnr.

data v_delivery_date like vbfa-erdat.

*fattura cliente

data v_fattura_cliente like vbrk-vbeln.

data v_fatt_pos_cliente like vbrp-posnr.

data v_fatt_client_date like vbfa-erdat.

*fattura produttore

data v_fattura_produttore like vbrk-vbeln.

data v_fatt_pos_produttore like vbrp-posnr.

data v_fatt_prod_date like vbfa-erdat.

*Producer Invoice – PPI Invoice – PTBS Invoice

*fattura PPI

data v_fatt_ppi like vbrk-vbeln.

data v_fatt_ppi_date like vbfa-erdat.

*fattura PTBS

data v_fatt_ptbs like vbrk-vbeln.

data v_fatt_ptbs_date like vbfa-erdat.

*****************************************

Code selection: Record Procesing

****************************************

*iniatializzation

clear v_delivery.

clear v_delivery_date.

clear v_posnn.

* client

clear v_fattura_cliente.

clear v_fatt_client_date.

clear v_fatt_pos_cliente.

* ppi

clear v_fatt_ppi.

clear v_fatt_ppi_date.

*ptbs

clear v_fatt_ptbs.

clear v_fatt_ptbs_date.

*producer

clear v_fattura_produttore.

clear v_fatt_prod_date.

clear v_fatt_pos_produttore.

*Sales Order – Delivery- Invoice – Producer Invoice

*Delivery:

select vbeln posnn erdat into (v_delivery, v_posnn, v_delivery_date)

from VBFA

where vbelv = vbap-vbeln

and posnv = vbap-posnr

and vbtyp_n = 'J'.

endselect.

*Fattura cliente:

select vbeln posnn erdat into (v_fattura_cliente, v_fatt_pos_cliente, v_fatt_client_date)

from VBFA

where vbelv = v_delivery

and posnv = v_posnn

and vbtyp_n = 'M'.

endselect.

*Fattura produttore:

select vbeln posnn erdat into (v_fattura_produttore, v_fatt_pos_produttore, v_fatt_prod_date)

from VBFA

where vbelv = v_delivery

and posnv = v_posnn

and vbtyp_n = '5'.

endselect.

*Producer Invoice – PPI Invoice – PTBS Invoice

*PPI Invoice

select zicivbfa~vbeln into v_fatt_ppi

from zicivbfa join vbrk

on vbrk~vbeln = zicivbfa~vbeln

where zicivbfa~vbeln_prod = v_fattura_produttore

and vbrk~bukrs = '0114'

and vbrk~vkorg = '0080'.

endselect.

**Data PPI Invoice *

select erdat into v_fatt_ppi_date

from vbrk

where vbeln = v_fatt_ppi.

endselect.

*PTBS Invoice

select zicivbfa~vbeln into v_fatt_ptbs

from zicivbfa join vbrk

on vbrk~vbeln = zicivbfa~vbeln

where zicivbfa~vbeln_prod = v_fattura_produttore

and vbrk~bukrs = '0114'

and vbrk~vkorg = '0117'.

endselect.

**Data PTBS Invoice *

select erdat into v_fatt_ptbs_date

from vbrk

where vbeln = v_fatt_ptbs.

endselect.

****************************************

Fig. 2.28 Date extrase prin codul inserat

Dupa salvarea InfoSetlui, urmatorul pas consta in asignarea acestuia grupului tinta.

Fig. 2.29 Asignare InfoSet la User Group

Fig. 2.30 Asignare InfoSet la User Group

Tranzacția SQ01 – asignare InfoSet la un query.

Primul pas consta in intrarea in grupul de utilizatori pentru care se doreste crearea query-ului (de exemplu, grupul AMS).

Fig. 2.31 Asignare InfoSet la User Group

In campul “Query” inseram numele dorit pentru noul query și apasăm butonul “Create”.

Fig. 2.32 Creare Query

Dupa selectarea optiunii de creare, apare o fereastra din care trebuie sa alegem InfoSet-ul creat anterior.

Fig. 2.33 Creare Query – alegere InfoSet din lista

Scriem o descriere scurta si sugentiva despre query-ul ce urmaza a fi creat și apasăm optiunea “Basic List”.

Fig. 2.34 Creare Query – Descriere

În stanga ferestrei rezultate avem tabelele din care trebuie să alegem câmpurile, fie pentru selectie, fie pentru afisare in raport, fie in ambele cazuri.

Fig. 2.35 Creare Query – selectie câmpuri de selectie sau afisare

Verificam, pentru a vedea ca este totul ok, cu butonul “Test”, dupa care salvam.

3. Tranzacția SQ03 – Tranzactie folosita pentru gestionarea User Group-urilor la care este autorizat un anumit user.

Asignarea utilizatorului la un User Group se face prin modificarea acestuia (butonul Change).

2.3.2. Executie query PL_DD_FLOW_NEW

Pentru rularea unei interogari, se foloseste tranzactia SQ01, inserand in campul « Query », numele acestuia : PL_DD_FLOW_NEW si apasand butonul de executie: .

Fig. 2.36 Executare Query

Rezultatul acestei actiuni este o fereastra cu o lista de criterii de selectie, definite anterior. Inseram parametri de cautare doriti (Conditiile de transport, Documentul de vanzare, punctul de incarcare/ descarcare, Depozitul, Organizatia de vanzari, Clientul, data emiterii documentului etc.) si apasam butonul de executie: .

Fig. 2.37 Criterii de selectie

Raportul rezultat este urmatorul : pentru documentul 8500086697, cu clientul ICP TS04122, avem materialele si itemii corespunzatori acestora, precum si punctele de incarcare, respectiv descarcare a marfii :

Fig. 2.38 Rezultat raport

Concluzii

Principalul rol al sistemelor informatice integrate este de a asigura disponibilitatea in timp real a resurselor informationale actualizate, lucrul posibil doar prin intermediul automatizarii proceselor. Automatizarea se refera la declansarea unui eveniment in momentul indeplinirii unor cerinte stabilite initial sau la intervale prestabilite de timp, se fara ca resursa umana sa intervina. Aceste doua cazuri au fost rezolvate astfel :

declansarea unui eveniment in momentul indeplinirii unor cerinte stabilite initial : anumite pachete de date (numite Idoc-uri), sunt trimise in mod automat in diferite parti ale sistemului sau in afara acestuia cand anumite cerinte cheie au fost indeplinite si fac anumite modificari sau declanseaza, la randul lor, alte evenimente. Aceste Idoc-uri sunt concepute, din punct de vedere al cauzelor care le determina, al formatului si al efectelor pe care le au in conformitate cu cerintele de business.

Un exemplu de astfel de Idoc este cel de pe factura contabila, care, in momentul crearii acesteia, se trimite in mod automat un e-mail/fax la client in format standard cu documentul respectiv, eliminand intarzierile cauzate de compunerea acestuia de catre un angajat, care poate amana sau chiar uita sa faca aceasta activitate intr-un timp rezonabil. Datele legate de e-mail-ul sau numarul de fax sunt luate de program din baza de date a clientului de pe factura.

Alte exemple de Idoc-uri declansate de evenimente sunt cele care asigura comunicarea intre departamentul de vanzari si depozitl de marfa. La cererea clientului, se creeaza un ordinul de vanzare cu diferitele produse si cantitati solicitate de acesta. Un Idoc pleaca de pe ordin, interogand stocul materialelor in cauza si disponibilitatea acestora. In functie de rezultat, un Idoc porneste automat catre ordin pentru a confirma disponibilitatea livrarii la data solicita sau, propunand o alta data in cazul in care nu exista suficient stoc.

declansarea unui eveniment la intervale stabilite de timp : aceasta facilitate a fost rezolvata cu ajutorul unor Job-uri, concept care defineste un program sau o succesiune de programe care se pot lansa la anumite date planificate, sau în fucție de apelarea anumitor evenimente. Tranzacția cu care sunt accesate job-urile este SM37, iar pentru activarea unui job se foloseste SM36. Un Job poate fi setat sa ruleze la anumite ore – de mai multe ori pe zi, zilnic, saptamanal, lunar.

Un job poatea avea mai multe statusuri:

Scheduled: job-ul a fost planificat dar nu a fost activat;

Released: job-ul a fost setat și activat pentru a fi rulat la o anumită ora sau la declansarea unui anumit event;

Ready: job-ul a fost activat dar din anumite motive înca nu a început executia lui (poate fi o intarziere cauzata de supraincarcarea sistemului sau suprapunerea cu un alt job);

Active: job-ul este în execuție;

Finished: job-ul a terminat de rulat cu succes;

Canceled: job-ul a fost oprit în timpul rulării din anumite motive (ex. Probleme legate de baze de date, probleme de network, legate de executarea efectivă a programului, întreruperea forțată de către un utilizator);

Acesatea au fost cazurile cele mai importante in care actualizarea sistemului se face in mod automat, insa nu toate procesele pot fi automatizate, din diferite considerente.

Exista astfel cazuri de activitati in care interventia umana este iminenta si care necesita foarte mult timp, ca de exemplu : schimbarea tuturor preturilor oferite de o anumita organizatie de vanzari pentru ofertele din sezonul de vara, modificari de promotii doar pentru clientii care indeplinesc anumite criterii s.a., modificari in masa ale datelor despre clientii unei societati etc. Pana aici, nu exista aparent nicio problema ce nu poate fi rezolvata cu rabdare si timp, dar fiind cazul unei intreprinderi multinationale, pot aparea nenumarate cereri de acest gen, de la diferitele companii afiliate din intreaga lume.

Cum se poate rezolva aceasta avalansa de cereri intr-un timp util?

Variante posibile de automatizare :

Facilitatea LSMW – Legacy System Migration Workbench

Ce este LSM workbench?

LSMW este un instrument bazat pe software-ul SAP care sustine transferuri singulare sau periodice de date de la sisteme non-SAP (externe) la sisteme SAP, avand anumite restrictii si in carul transferurilor interne SAP.

Funcțiile sale principale sunt:

Importul datelor moștenite din foile de calcul (excel) sau fișiere secvențiale (notepad) salvate in calculator ;

Conversia datelor din formatul original (sistem de moștenire) a format (SAP) țintă;

Importul datelor utilizând interfețele standard de SAP (prelucrare de intrare IDOC, Batch Input, intrare directa)

Ce datele pot fi migrate folosind LSMW?

Prin intermediul programelor de transfer standard: o gamă largă de baze de date (de exemplu, conturile contabile, nomenclatorul de clienti si furnizori, nmenclatorul de materiale, liste de materiale) și date despre tranzacțiile efectuate (de exemplu, documente financiare, ordinele de vânzare)

Prin înregistrarea tranzacțiilor: alte obiecte de date ,în cazul în care tranzacția poate fi rulata în modul Batch Input

Sunt datele importate consistente ?

Da. Datele sunt încărcate prin interfețele standard ale aplicatiilor. Aceastea vor include toate controalele care sunt rulate pentru tranzacțiile online. Datele invalide vor fi response (exemplu: modificarea unor entitati necreate inca, inserarea de valori alfanumerice in campuri definite numerice etc.)

Este necesara o cunoaștere mai vasta a limbajului ABAP pentru a utiliza LSMW?

Nu. LSMW oferă principalele tehnici de conversie la simpla apăsare a unui buton. Pentru conversii complexe, poate fi adăugat cod ABAP individual

Trebuie sa modific tabela cu tabela ?

Nu. Obiectele de business, ca nomenclatoarele de clienti, cele de materiale sau documente contabile, sunt migrate in sistem, realizandu-se modificarea in cascada a acestora.

Pot transfera date aflate pe calculatorul meu?

Da. LSMW poate citi datele direct de la PC. Numai atunci când se utilizează interfața periodică, datele trebuie să fie pe un server de sistem SAP.

Este LSMW parte a sistemului SAP standard?

Depinde de versiunea sistemui SAP :

Pentru versiunile mai noi decat SAP Web Application Server Release 6.20, LSMW este integrat în sistemul SAP. Prin urmare, dacă utilizați un sistem SAP de aceasta versiune sau mai nou, utilizați sistem-integrat LSMW "din cutie".

Pentru versiunile mai vechi de SAP, trebuie instalat aditional modulul de sine statator LSMW.

De retinut este faptul ca nu se percep costuri suplimentare pentru a beneficia de acet modul.

Pot migra de date din sistemul SAP pentru sistemul SAP, prin intermediul LSMW?

În general, LSMW este folosit pentru a transfera date din sisteme non-SAP în sistemele SAP. Cu toate acestea, cu câteva restricții, este de asemenea posibil de a migra de la sistemul SAP la sistemul SAP:

Exportul trebuie sa fie programat.

Structurile sursă trebuie să fie definite. Campurile din structurile sursa pot fi incarcate din dicționar.

Maparea automată a campurilor este posibilă.

Importul poate dura destul de mult, deoarece cantitatea de date care migrează de la sistemul SAP la sistemul SAP este cea mai mare parte mai mare decât pentru migrarea de la sisteme externe.

Datele istorice, de cele mai multe ori, nu poate fi construite.

Asadar, indiferent de modul de actualizare a datelor din sistem, acestea ajung la destinatar intr-un timp util, proprietate obligatori a sistemelor informatice in conditiile concurentiale actuale.

Bibliografie

Mehedințu Anca – Gestiunea Bazelor de Date , curs – material didactic

Buse Razvan, Mehedintu Anca,Soava Georgeta, – Sisteme Informatice Economice, Editura Universitaria, Craiova, 2008

Popa Sorin – Protectia si securitatea informatiei in sistemele informatice, curs – material didactic

Buse Razvan – Proiectarea sistemelor informatice , curs – material didactic

H.G. 843/1999 privind incadrarea pe tipuri a unitatilor de alimentative publica neincluse in tructurile de primire turisti.

Raghu Ramakrishnan, Johannes Gehrke – Database Management Sistem, 2nd Edition

Vasilciuc Bogdan Gabriel – Tehnologii informatice utilizate in mediul decizional I, curs master – Univeritatea Titu Maiorescu, Facultatea de Stiinte Economice.

http://ro.wikipedia.org/wiki/Comert_electronic

http://en.wikipedia.org/wiki/Business-to-business

http://saphelp.hpage.co.in/sap-inter-company-sales_3426901.html

http://sapsdhelpcentre.blogspot.it/2011/08/inter-company-sales-process.html

http://help.sap.com/saphelp_46c/helpdata/en/d1/49cc7cbf3311d18c9d080009d10d9a/content.htm

http://wiki.scn.sap.com/wiki/display/profile/Intercompany+Business+Processing

http://scn.sap.com/docs/DOC-26159

Bibliografie

Mehedințu Anca – Gestiunea Bazelor de Date , curs – material didactic

Buse Razvan, Mehedintu Anca,Soava Georgeta, – Sisteme Informatice Economice, Editura Universitaria, Craiova, 2008

Popa Sorin – Protectia si securitatea informatiei in sistemele informatice, curs – material didactic

Buse Razvan – Proiectarea sistemelor informatice , curs – material didactic

H.G. 843/1999 privind incadrarea pe tipuri a unitatilor de alimentative publica neincluse in tructurile de primire turisti.

Raghu Ramakrishnan, Johannes Gehrke – Database Management Sistem, 2nd Edition

Vasilciuc Bogdan Gabriel – Tehnologii informatice utilizate in mediul decizional I, curs master – Univeritatea Titu Maiorescu, Facultatea de Stiinte Economice.

http://ro.wikipedia.org/wiki/Comert_electronic

http://en.wikipedia.org/wiki/Business-to-business

http://saphelp.hpage.co.in/sap-inter-company-sales_3426901.html

http://sapsdhelpcentre.blogspot.it/2011/08/inter-company-sales-process.html

http://help.sap.com/saphelp_46c/helpdata/en/d1/49cc7cbf3311d18c9d080009d10d9a/content.htm

http://wiki.scn.sap.com/wiki/display/profile/Intercompany+Business+Processing

http://scn.sap.com/docs/DOC-26159