Domeniul INGINERIE ȘI MANAGEMENT [604047]

Universitatea din Pitești
Facultatea de Mecanică și Tehnologie
Domeniul INGINERIE ȘI MANAGEMENT
Programul de masterat MANAGEMENTUL LOGISTICII

LUCRARE DE DISERTA ȚIE

Absolvent: [anonimizat] : ș.l. dr. ing. Ana GAVRILU ȚĂ

Anul uni versitar
2017 -2018

2
Universitatea din Pitești
Facultatea de Mecanică și Tehnologie
Domeniul INGINERIE ȘI MANAGEMENT
Programul de masterat MANAGEMENTUL LOGISTICII

STUDIU PRIVINID ÎMBUNĂTĂ ȚIREA
MODULUI DE REALIZARE A
COMENZII DE APROVIZIONARE PRIN
IMPLEMENTAREA UNUI SISTEM
INTEGRAT

Absolvent: [anonimizat] : ș.l. dr. ing. Ana GAVRILU ȚĂ

Anul universitar
2017 -2018

3

CUPRINS

INTRODUCERE ………………………….. ………………………….. ………………………….. …………………. 4
PARTEA I STUDIU BIBLIOGRAFIC ………………………….. ………………………….. …………….. 5
CAPITOLUL 1.CONCEPTUL ERP ………………………….. ………………………….. …………………. 5
1.1 Defini ția si evolu ția sistemelor informatice ………………………….. ……………………….. 5
1.2 Defini ție, avantaje și dezavantaje ale unui sistem ERP ………………………….. ……… 7
1.3 Arhitectura și component ele principale ale unui sistem ERP ………………………… 9
1.4 Strategiile, costurile și riscurile implementării unui sistem ERP ………………….. 11
1.5 Solu ții de sist eme ERP existente pe pia ță ………………………….. ………………………… 14
PARTEA A II -A STUDIU DE CAZ ………………………….. ………………………….. ………………… 19
CAPITOLUL 2. PREZENTAREA LOCULUI DE REALIZARE A STAGIULUI ȘI
OBIECTIV UL STUDIULUI ………………………….. ………………………….. ………………………….. . 19
2.1 Locul desfă șurării stagiului ………………………….. ………………………….. ……………….. 19
2.2 Obiectivul studiului ………………………….. ………………………….. ………………………….. . 21
CAPITOLUL 3. PREZENTAREA MODULUI DE REALIZARE A PROCESULUI DE
APROVIZIONARE ÎN SITUA ȚIA INI ȚIALĂ ………………………….. ………………………….. .. 22
3.1 Prezentarea sistemelor informatice integrate în situa ția ini țială …………………… 22
3.2 Modul de realizare a procesului de aprovizionare ini țial ………………………….. …. 24
3.2.1 Pentru furnizori interni ………………………….. ………………………….. ………………………….. … 24
3.2.2 Pentru furnizori externi ………………………….. ………………………….. ………………………….. .. 27
3.3 Analiza modului de realizare a comenzii de aprovizionare în situa ția ini țială . 38
CAPITOLUL 4. ÎMBUNĂTĂ ȚIREA MODULUI DE REALIZARE A COMENZII DE
APROVIZIONARE PRIN IMPLEMENTAREA UNUI SISTEM INTEGRAT ………….. 39
PARTEA A III -A CONCLUZII FINALE ȘI CONTRIBU ȚII PROPRII ……………………. 46
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ……………….. 50

4
INTRODUCERE

Proiectul de diplomă a fost realizat pe durata stagiului de practică în cadrul companiei
S.C. RENAULT TEHNOLOGIES ROUMAN IE S.A., în Departamentul Logistică Prototipuri,
fiind colaborator al acestei companii.
Studiul are ca obiective principale:
 Analiza modului de realizare a comenzilor de aprovizionare în situa ția ini țială
 Îmbunătă țirea modului de realizare a comenzilor de aprovizionare prin implementarea
unui sistem integrat
Pentru realizarea obiectivelor am efectuat o analiză împreună cu îndrumătorul de la
Renault asupra modului de realizare a comenzilor de aprovizionare către furnizori interni și
externi ce implică docume ntarea datelor în două sisteme și transferarea datelor dintr -un sistem
în altul ce necesita un timp de douăzeci și patru de ore.
În ceea ce prive ște structura lucrării, aceasta este formată din trei păr ți:
 Partea I: Studiu bibliografic;
 Partea a II -a: Stud iu de caz;
 Partea a III -a: Concluzii finale și contribu ții proprii
În partea I s -a urmărit dezvoltarea subiectului temei abordate din punct de vedere teoreti c.
În primul capitol intitulat Conceputul ERP , am prezentat câteva no țiuni legate de conceptul
sistemelor integrate, descriere și principii, sisteme integrate utilizate.
Partea a II -a, studiu de caz, cuprinde trei capitole în care au fost descrise etapele realizării
studiului.
Capitolul doi al lucrării Prezentarea locului de realizare a st agiului si ob iectivul
studiului , cuprinde prezentarea locului de stagiu, unde mi -am desfă șurat activitatea , obiectivul
principal al studiului și activită țile pe care le -am realizat pentru atingerea obiectivelor.
Capitolul trei al lucrării denumit Prezentarea modului de realizare a comenzii de
aprovizionare în situa ția ini țială, cuprinde descrierea generală a modului ini țial de realizare a
comenzilor.
Capitolul patru intitulat Îmbunătă țirea modului de realizare a comenzii de aprovizionare
prin implementarea unui sistem i ntegrat , prezintă metodele de ameliorare aduse prin
implementarea noului sistem integrat.
Partea a III -a, cuprinde concluziile finale ale întregului studiu și contribu țiile mele în
cadrul acestuia.
Realizarea proiectului de diplomă s-a desfă șurat sub îndru marea doamnei ș.l.dr.ing.
Cornelia – Ana GAVRILU ȚĂ, căreia vreau să îi mul țumesc pentru implicarea și ajutorul
acordat pe tot parcursul realizării proiectului.
Doresc să îi mul țumesc de asemenea și îndrumătoarei mele din Renault, doamnei inginer
Georgeta I ORDACHE, de la care am avut multe lucruri de învă țat și care s -a implicat în buna
desfă șurare a realizării studiului. De asemenea, vreau să mul țumesc tuturor persoanelor din
departament alături de care am col aborat și pentru sprijinul acordat pe toată peri oada studiului.

5
PARTEA I STUDIU BIBLIOGRAFIC
CAPITOLUL 1.CONCEPTUL ERP
1.1 Defini ția și evolu ția sistemelor informatice

Sistemele informatice integrate sunt sisteme complexe prin intermediul cărora sunt
desfă șurate diverse procese de afaceri, transform ări structurale și organizare a cuno ștințelor și
informa țiilor. Pentru orice companie care are nevoie de un sistem informatic modern, pentru
automa tizarea proceselor interne sau/ și externe, relațiile cu clien ții și furnizorii este nevoie de
un sistem de aplica ții integrate.
O serie de avantaje pe care aplica țiile integrate le oferă beneficiarilor sunt :
Costurile se reduc pe termen lung ;
Eficien ța opera țională suferă o creștere semnificativa ;
Investi țiile în IT se pot recupera rapid ;
Trecerea către modele le e-business se face rapid .
Așadar, pentru înțelegerea importantă unui sistem informatic integrat într-o întreprindere
este necesar să cunoa ștem modelul general de organizare a unei afaceri, conform căruia orice
companie este formată din patru zone:
1. Zona back office;
2. Zona front office;
3. Zona middle office;
4. Zona web office.
1. Zona back office
Această zonă se poate caracteriza prin:
Rolul fundamental al bazei de date ce poate fi centralizată pe un singur server, sau, de
asemenea, poate fi structurată fizic pe mai multe servere;
Întreaga activitate a companiei depinde de importan ța critică a prelucrărilor realizate;
Capacitatea de centralizare pe un număr de servere mai mic unde rulează sisteme de
operare speciale.
Calitatea sistemului Back Office este reprezent ată de integritatea și coeren ța
informa țiilor. Totodată, caracteristici apreciate ale aplica ției Back Office sunt continuitatea
serviciilor chiar și când sunt depanaje sau defec țiuni dar și disponibilitatea continuă.
Aplica țiile Back Office pot garanta funcționarea companiei, așadar este impusă existen ța
unei aplica ții de înaltă securitate a informa țiilor la nivelul fizic și drepturilor de acces.
2. Zona Front Office
Produsele oferite clien ților de către companie pentru a asigura servicii rapide reprezintă
aplicațiile Front Office. Cerin țele esențiale la care o aplica ție Front Office trebuie să răspundă
sunt:
Gestiunea relațiilor pe care întreprinderea le are cu clien ții (Customer Relationship
Management, CRM) – conține instrumente de administrare a clien ților (culegerea datelor cu
privire la activită țile efectuate de clien ți pentru a le trimite spre procesare aplica țiilor Back
Office), dar și instrumente de asistare a clien ților (evaluarea realizată în funcție de anumite
criterii, asisten ță în ceea ce prive ște configurarea cererii).
Gestionarea agen ților ce se ocupă cu vânzările – ce are ca scop gestionarea agen ților din
mai multe perspective: performan țe, obținerea de rezultate consolidate, cota de vânzări totale.

6

Gestionarea clien ților – se utilizează tehnolog ii de integrare cu rețeaua telefonică și face
parte din sistemul Front Office ce sunt puse la dispozi ția centrelor de asisten ță.
Zona Middle Office
Reprezintă o zonă ce a primit două accep țiuni diferite datorită faptului că este greu de
definit la nivel fi zic:
În primă fază, în cadrul fiecărui centru de vânzări există zona de Back Office ce
îndepline ște funcții specifice acestei zone, însă este situată fizic în Front Office.
În cea de -a doua etapă, componentele intermediare ce au rol de comunicare între Fro nt
Office și Back Office pentru gestionare rețelei și transmiterea informa țiilor către aplica țiile
centrale.
3. Zona Web Office
Reprezintă o zona dezvoltată de tehnologia World Wide Web, care completează celelalte
zone și oferă accesul la sistemul in formatic al unei firme oriunde și la orice oră. Aceasta zonă
integrează diverse aplica ții:
Interne, la care au acces doar angaja ții companiei, accesul din exterior fiind blocat prin
aplica ții firewall. Serviciile furnizate de aceste tipuri de aplica ții sunt divers e: mesagerie
internă , gestiunea proiectelor, videoconferin ța, agenda de grup etc. Toate acestea folosesc ca și
tehnologie Intranet -ul menit să blocheze accesul neautorizat din exterior .
Accesibile partenerilor (furnizori, clien ți, consultan ți, etc.), simi lare celor interne dar la
care au acces si parteneri ai companiei, prin intermediul unor servere Extranet.
Accesibile publicului larg, la care are acces întreg publi cul prin serverele de Internet și
unde se pot găsi cataloage on -line cu imagini ale produse lor.
Complexitatea activită ților din cadrul unei întreprinderi și schimbările care se fac din
ce în ce mai rapid în mediul de afaceri determină o adaptare permanenta, punând la încercare
capacitatea de analiză a angaja ților. Fiind capabile să lucreze cu un volum mare de informa ții
și date, sistemele ERP vin ca soluție să gestioneze aceste provocări . Aceste sisteme au apărut
în anii 1960 și în următorii ani au continuat să se dezvolte atât din punct de ve dere software,
cat si hardware.

Fig.1 .1. Evolu ția aplica țiilor integrate de gestiune a firmelor

În anii ’60, majoritatea companiilor aveau aplica ții centralizate și realizate prin for țe
proprii, adică proiectarea și implementarea lor se făcea "in-house" și se b azau pe gestionarea
automatizată a stocur ilor. Foloseau ca limb aje de programare COBOL, ALGOL și FORTRAN.
Anii '60
•Aplicatii
pentru
controlul
stocurilor
Anii '70
•Material
Requirements
Planning
(MRP )
Anii '80
•Material
Resources
Planning
(MRP II)
Anii '90
•Enterprise
Resource
Planning ( ERP)
Anii 2000
•Extended ERP
(ERP II), BPI,
EAI, ENS

7
În anii ’70 au apărut și s-au dezvoltat sistemele Material Requirements Planning (MRP) ,
considerate ca fiind un set de tehnici care, pentru determi narea necesarului de materiale și
lansarea c omenzilor, utilizează dat ele despre stocuri, inventarul și programul de produc ție.
Așadar, prin sistemele MRP se realizează controlul sto curilor electronic, iar eficien ța se
îmbunătă țește.
Anii ’80 marcau evolu ția MRP -ului și apari ția unei versiuni îmbunăt ățite MRP II
(Manufacturing Resource Planning) prin care se sincronizau cerin țele produc ției cu necesarul
de materiale ce trebuia comandat. Aceste sisteme au cun oscut o dezvoltare semnificativă și în
domenii precum: financiar, resurse umane, vânzare , gest iunea proiectelor. Î n fabrica ție, aceste
sisteme se ocupau de planificarea produc ției, a necesarului de materiale, planului de vânzări ,
plan de aprovizionare, proiec ții pe stocuri, buget de expedi ție și transport etc.
Astfel, MRP II, pe lâ ngă funcțiile pe care le îndeplinea a constituit și baza pentru dezvoltarea
unui sistem mult mai complex numit ERP (Enterprise Resource Planning) î n anii ’80-’90.
În anii 2000, dezvoltarea și evolu ția implementărilor Enterprise Resourc e Planning
depindeau de modul î n care suitele tradiționale pot integra module din categoria Customer
Relationship Management (CRM) – soluții e-business pe zona relațiilor cu clien ții, Supply
Chain Management (SCM) – soluții pe zona furnizori -aprovizionare, sau alte aplica ții software
specific e Internet. De asemenea, au apărut și sisteme noi, precum: BPI (Business Process
Integration), EAI (Enterprise Application Integration), ENS (Enterprise Nervous System ).

1.2 Defini ție, avantaje și dezavantaje ale unui sistem ERP

Enterprise Resource Plan ning, pe scurt ERP, este o soluție software complexă, bazată pe
arhitectura client -server , prin intermediul căreia se face schimb de informa ții între angaja ți,
prin utilizar ea unei baze de date integrate într -o platformă comună . Astfel, sunt eliminate
granițele dintre departamente, prin implementarea unei singure surse de informare accesibile
oricărui angajat, la orice oră și în orice loc. Pentru fiecare industrie, fiecare pachet ERP este
diferit. Prin ERP sunt sprijinite, automatizate toate ariile funcționale :
planificare ;
produc ție;
vânzare ;
marketing ;
distribu ție;
contabilitate ;
financiar ;
resurse umane ;
gestiunea proiectelor ;
stocuri ;
service ;
întreținere ;
logistica ;
e-business.

8

Fig.1.2. Reprezentare sistem ERP

De asemenea, ERP reprezintă o meto dă eficientă de a planifica și a controla resursele
care sunt necesare pentru a prelua, a realiza, a expedia și a contabiliza comenzilor clien ților în
întreprinderi . Principala provocare a sistemelor ERP este integrare a tuturor proceselor
economice și opti mizarea resurselor.
Avantajele folosirii unui sistem ERP sunt:
Baza de date unică și complexă;
Creșterea eficien ței întreprinderii ;
Se pot face planificări pe termen îndelungat ;
Poate fi personalizată î n funcție de cerin țele companiei ;
Folose ște o structur ă fiabilă de fișiere;
Sistemele ERP permit integrarea unor soluții de tip "best business practices" ;
Schimbările care se fac î n procesele economice se actualizează ușor în sistem.
Cu ajutorul sistemelor ERP sunt integrate toate funcțiile de conducere ale u nei
întreprinderi , și anume: planificări , asig urarea stocurilor de materiale și materii prime,
coordonarea produc ției, dezvoltarea și menținerea relațiilor cu furnizorii și clien ții. Deci, prin
intermediul acestor sisteme, într -o companie se pot face previ ziuni, planificări , analize
calitative, se poate comunica on -line. Platformele de baze de date cel mai des folosite pentru
implementarea Enterprise Resource Planning sunt:
Oracle ;
DB2 ;
Informix ;
MS SQL Server ;
SQL Base ;
Sybase .
Principalele probleme care pot apare în legătură cu implementarea unui ERP sunt
generate de următorii factori:
Baza de date
Raport ări și
analize
Financiar &
Contabilitate
Produc ție
Logistic ă&
Stocuri
Resurse
umane
Service &
Întreținere
Vânzări &
Distribu ție

9

Neconformitatea modulelor achizi ționate . Această situa ție este generată , în principal, de
alegerea unui sistem ERP ale cărui arhitectură și componente nu su nt adecvate și nu corespund
deplin proceselor economice, culturii și obiec tivelor strategice ale organiza ției.
Dependen ța de furnizori, apare atunci când implementarea sist emului s -a realizat prin
achizi ționarea unor componente și module de la furnizori d iferiți și nu s-a mers pe un singur
furnizor care înseamnă și implicarea acestuia pe termen lung.
Complexitate prea mare, a pare atunci când au fost achizi ționate și implementate module
care nu sunt absolute necesare sau nu sunt deplin adecvate profilului și proceselor o rganiza ției.
Necesitatea extinderii și dezvoltării sistemului ulte rior implementării este o cerin ță
importantă de care trebuie să se țină cont, aceasta putând apărea ca urmare a unor modificări
ale obiec tului de activitate al organiza ției sau schimbări le gislative.
Pe scurt, ERP poate f i definit din perspectiva a două proprietă ți principale:
funcționalitatea și integrarea. Func ționalitatea se referă la faptul că î ntr-o companie sunt mai
multe module funcționale (debit ori, salarii, stocuri, logistică , comen zi, aprovizionare etc.), iar
prin intermediul ERP -ului sunt asigurate fluxurile de procese economice. Pe de altă parte,
integrarea trebuie să asigure eficien ța legăturii dintre fluxur ile de procese economice, o bună
comunicare î ntre rețele de calculatoare.

1.3 Arhitectura și componentele principale ale unui sistem ERP

Într-o întreprindere, sistemele ERP sunt integrate pe o arhitectura de tip client -server cu
trei straturi : nivelul prezentare, nivelul aplica ție, nivelul bazei date, per mițând o prelucrare a
datelor cât mai bună .

Fig.1.3. Arhitectura client -server a unui sistem ERP

10
Dacă caracteriză m cele trei niveluri ale unui arhitecturi, putem spune că :
Nivelul prezentare reprezintă interfa ța pentru accesarea diverselor func ții ale sistemului;
Nivelu l aplica ție este constituit din logica siste mului, regulile întreprinderii și
programele necesare pentru transferul de date ;
Nivelul bazei de dat e gestionează datele companiei și aici regăsim și modulul SQL.
Principalele componente ale unui sistem Enterpr ise Resource Planning sunt:
1. Fișierele de bază (nomenclatoare) care con țin toate datele clien ților, furnizorilor,
angaja ților într -o manieră u șoară și accesibil ă.
2. Contabilitate genera lă, componenta care se ocupă cu gestiunea financiară , sistemul ERP
asigurâ nd automatizarea înregistrării datelor financiar -contabile, ob ținerea unor documente
contabile conform legisla ției în vigoare care pot fi completate cu performan țele firmei.
3. Încasări -plăți. Această componentă se ocupă cu datoriile și crean țele companiei.
4. Salarizare, component a care automatizează: calculul și eviden ța salariilor, taxelor,
asigurărilor sociale.
5. Resurse umane – automatizarea activită ților de recrutare a personalului.
6. Planificare -produc ție vi zează termenul, cel care execută , costurile, detaliil e tehnice,
produsul ce urmează a fi realizat.
7. Urmărirea produc ției pentru analiza comenzilor lansate, rapoarte complexe ale
produc ției pe faze, costuri.
8. Planificare necesar de materiale, componenta pri n care sunt determinate cantită țile
necesare de materia le.
9. Managementul proiectelor se refera la toate lucrările efectuate pentru realizarea unui
proiect (bugetarea, finan țarea și urmărirea acestuia) .
10. Stocuri – gestionarea stocurilor și a depozitelor, tipuri de inventar, modul de localizare
al stocurilor
11. Aprovizionare (Furnizori) asigură optimizarea aprovizionării în vederea realizării de
economii .
12. Vânzări – gestionarea procesului de vânzare .
13. Mentenan ța echipamentelor urmăre ște modul de utilizare al echipamentelor , costul
lucrărilor de repara ție și întreținere .
14. Logistica (Transport) – gestionează activită țile logistic e din procesele de distribu ție și
vânzare.
15. Business Intelligence realizează analize multidimensionale (OLAP), simulări ,
prognoze, scenarii.
16. Servicii post -vânzare .
17. Soluții specifice fiecărei industri i.
18. Generatorul de rapoarte, componenta ce permite realizarea unor rapoarte folosind datele
din baza de date.

11

Fig.1.4. Componentele sistemului ERP

1.4 Strategiile, costurile și riscurile implementării unui sistem ERP

Pentru implementarea unui sistem ERP într-o întreprindere trebuie să se țină cont ca
soluția adoptată sa fie cea mai adecvată specificului companiei, să se resp ecte cadrul legal al
fiecărei țări, legisla ția și normele europene, posibilitatea operării cu diverse valute, sa se facă
prelucrări în timp real, să se minimizeze riscurile și să fie posibilă justificarea clara a investi ției.
De asemenea integrarea trebuie sa asigure colaborarea î ntre angaja ți prin instrumente specifice.
Alegerea cel ei mai bune solu ții nu se desfă șoară u șor, fiind nev oie să se țină cont de câtev a
criterii: amploarea afacerii și a proiectelor viitoare, necesarul de investi ții, specificul activită ți
desfă șurate , structura aplica țiilor existente etc.
Principalele activită ți care trebuie urmate pentru im plementarea ERP sun t: educarea și
formarea managerilor, echipei proiectului, analiza cerin țelor și stabilirea obiectivelor, studiul
soluțiilor similare de sisteme ERP, rata de recuperarea a investi ției, evaluarea sistemelor
hardware, înțelegerea modului de funcționare a soluțiilor software etc. Odată implementată o
soluție de sistem ERP, configurate aplica țiile încep activită țile de instruire a angaja ților.
Instruirea continuă și întreținerea sunt necesare pentru a proteja investi ția, dar și bazele de date
gestionate de ERP:
Există trei m otive de care fiecare companie ține cont pentru implementarea unui sistem
Enterprise Resource Planning:
Tehnice – aplica țiile vechi sunt învechite și mai greu de întreținut;
Opera ționale – reducerea costurilor, accesibilitatea informa țiilor;
Strategice – relațiile cu clien ții se îmbună tățesc, asigurarea unor avantaje competitive
etc.
Implementarea sistem elor ERP a cunoscut ini țial două modalită ți de abordare: strategia
"Big Bang" și strategia pe faze, urmând ca în timp să mai apăra și alte ti puri de strategii:
strategia riscurilor mi nime pentru proiecte de anvergură , strategia de buget când buget ul este
redus, strategia cu for țe proprii care folose ște echipe proprii de speciali ști, strategia de
parteneriat, strategia „la cheie” .

12
De exemp lu, strategia "Big Bang" implică doar elementele de bază , iar co nversia datelor
se face manual în vederea reducerii costurilor și a timpului de i mplementare. Se practica această
strategie când timpul este limitat și se dorește o implementare rapidă .
Strategia „la cheie” se deosebe ște de alte strategii prin faptul că planificarea și derularea
activită ților sunt realizate cu resurse din exterior, există probleme la funcționare . Pentru
parcurgerea tuturor pașilor și activită ților de implementare sunt necesari apro ximativ 2 ani.
Într-un proiect ERP, din ce î n ce mai mult se vorbe ște de care este cea mai eficientă metodă de
înlocuire a sistemului existent cu unul nou, îmbunătă țit. Trecerea de la vec hi la nou se poate
realiza î n patru moduri: integrala, pe faze, paral ela sau hibrida și se face ținându -se seama de 3
factori: procesele, tehnologia și oamenii.
Strategia integrală se referă la înlocuirea completă cu un sistem nou și se aplică cu
succes î n companiile mici, permi țând o mai buna supraveghere a activită ților.
Strategia pe faze/ secven țiala/modulară asigură implementarea modulelor î n mai multe
faze. Se vor utiliza mici programe care umplu golurile dintre cele două sisteme până când
sistemul nou intră î n funcțiune complet. De exemplu, un modul este înlocuit (Cont abilitate), iar
celelalte funcționează după sistemul vechi, urmând ca rând pe rând sa fie înlocuite . Cele mai
multe companii adoptă această strategie ca fiind cea mai sigură și lipsită de riscuri cu toate că
perioada de tranzi ție este îndelungată .
Strategi a paralelă permite funcționarea în paralel a amb elor sisteme o perioada mai mică
sau mai mare de timp. Astfel, activitatea întrep rinderii nu poate fi periclitată din cauza unor
defec țiuni în noul ERP. Cu toate acestea, pot apărea erori din cauza confuziei angaja ților. De
aceea, se recomandă companiilor î n care defec țiunile sistemului ERP ar opri desfă șurarea
activită ților.
Deseori apar depă șiri ale bugetelor ini țiale necesare pentru implementarea unui sis tem
ERP cauzate de neconcordan ța dintre cer ințele cl ientului la negociere și cele din timpul
implementării. Aceste costuri suplimentare se numesc “hidden fees”. Daca î n timpul negocierii
clientul nu are multe solicitări și dore ște scăderea pre țului de achizi ție, atunci când se realizează
implementarea siste mului cerin țele clientului cresc și se pune problema unor costuri de
personalizare a sistemului, pentru obținerea licen ței unor module, pentru întreținerea aplica ției,
pentru suportul tehnic al acesteia. De aceea, de la primele discu ții, furnizorii de ERP ar trebui
să le explice clien ților toate aceste costuri suplimentare TCO (Total Cost of Ownership).
Pe de altă parte, furnizorii ERP nu consideră că serviciile de configurare ale sistemului,
respectiv costul licen țelor și necesită țile de actualizare ale hardware -ului nu fac parte din prețul
de achizi ție ale unui sistem ERP , aceste costuri fiind suportate suplimentar de către client. De
asemenea, mai pot apărea diverse costuri legate de apari ție unor noi necesita ți în timpul
implementării aplica ției.
Ținându-se seama de aceste aspecte, aplica țiile ERP sunt scumpe, ajungând să coste î ntre
400.000 $ și 300 milioane $ (conform unui studiu Meta Group). Diferen țele de preț apar î n
funcție de: mărimea și specifi cul firmei, tehnologia utilizată și gradul de disper sare geografică .
Totu și, costurile implementării pot fi supraevaluate în compara ție cu alte activită ți care
cumulate sunt adevărate "devoratoare" de buget, precum:
Instruirea angaja ților care trebuie să învețe un nou set de pro cese, o nouă interfa ța de
lucru. De c ele mai multe ori, aceasta etapă este neglijată și costurile nu sunt estimate
corespunzător .

13

Integrarea și testarea compatibilită ții sistemului ERP cu alte aplica ții generează costuri
suplimentare care nu sunt prevăzute în procesul de implementare.
Convers ia datelor din vechile sisteme î n cele ERP este subestimată din pun ct de vedere
costuri cu toate că se fac opera țiuni costisitoare precum transferul de date ale clien ților și
furnizorilor, designul produselor etc.
Analiza datelor. Într -o companie se fac î n fiecare zi actualizări selective ale datelor ERP,
iar persoanele ca re fac aceste analize trebuie să țină cont de bugetul necesar implementării ERP-
ului și depozitului de date.
Speciali știi și echipele de implementare. Implementarea unui si stem ERP este destul de
dificilă și necesită o echipă de speciali ști care să se ocupe. După ce programul a fost instalat
participan ții la acest proiect nu se pot întoarce pe vechile posturi, deținând mult mai multe
informa ții necesare pentru derularea î n bune condiții a proiectului. De exemplu, pentru a extrage
niște informa ții din no ul sistem sunt create rapoarte î n timpul unui an de zile. Toate acestea nu
se regăsesc în planificarea inițială a bugetului implementării .
Așteptarea beneficiilor. Beneficiile aduse de implementarea unui sistem de tipul ERP
pot fi observate după o perioada mai lungă , amortizarea investi ției făcându -se în timp.
Depresia post -ERP. Î n una din patru întreprinderi, după implementarea noului sistem,
angaja ții încep să se panicheze ca nu ma i înțeleg cu ce lucrează , iar performan ța companiei
începe sa scadă .
Din punct de vedere al riscurilor sau al depă șirii bugetelor , aproximativ 40% din
proiectele de implementare a unui sistem ERP e șuează, nereu șind sa fie atinse obiectivele
propuse ori depășindu-se excesiv bugetul. Companii celebre care au riscat, da r au ratat
obiectivele pe care și le-au propus sunt: Boeing, Panasonic sau Siemens. Aceste eșecuri au
apărut ca rezultat al unor probleme organiza ționale precum:
implicarea insuficienta a manag erilor și a utilizatorilor;
pregătirea necorespunzătoare a proiectului, buget insuficient, așteptarea unor beneficii
imediate după implementare;
utilizatori nepregă tiți din punct de vedere psihologic;
lipsa comunicării în echipa de proiect;
implement area s istemului a fost realizată de către speciali ști externi;
confundarea sistemului ERP cu un soft obișnuit.
Principalele dezavantaje ale implementării unui sistem ERP sunt:
prețuri mari de cost;
timp îndelungat de integrare și testare;
dependen ța față de furn izorul de servicii ERP ;
complexitatea sistemului (trebuie instalate doar modulele necesare) ;
necesitatea actualizării și dezvoltării sistemului.
Astfel cunoscându -se care sunt principalele costuri și riscurile care apar la implementarea
unui sistem ERP, es te interesant să cunoa ștem punctul de vedere al unor furnizori. Nu
întotde auna clientul este de vină pentru e șuarea implement ării unui ERP, o parte din culpă o au
și furnizorii de servicii.
De exemplu, compania germană SAP consideră că principalele problem e care apar sunt
datorate neglijării unor criterii de alegerii ale soluției optime de ERP și a lipsei comunicării
între furnizori și clien ți. În primul rând, pentru o implemen tare de succes trebuie sa aibă î n
vedere comunicarea dintre cele două echipe de p roiect, cu cât aceasta este mai bună, cu atât

14
soluția de ERP aleasă este mai apropiat ă de specificul firmei, iar problemele apărute la
integrarea sistemulu i pot fi evitate. S -a constat că pe parcursul implementării apar câteva puncte
critice legate de atenția insuficientă acordată procesului de analiza a nevoilor, iresponsabilitat ea
utilizatorilor care consideră că implementatorul trebuie să verifice rezultatele, incapacitatea
clien ților de a renun ța la aplica țiile vechi după maximum două luni de zile, nefi ind indicat să
se lucreze în paralel cu cele două sisteme.
Efectele negative eșuării implementării unui sistem ERP (Enterprise Resource Planning)
nu sunt resim țite doar prin pierderea investi ției materiale î n ERP, ci prin deteriorarea relației cu
angaja ții, clien ții, prin pierderea imaginii firmei, a cotei de piață. De aceea tre buie să se țină
seama alegerii unui partener cu experien ța, care să analizeze și să combată riscurile și să fie
compatibil cu specificul companiei.

1.5 Solu ții de sisteme ERP existe nte pe pia ță

Principalele solu ții de sisteme ERP existente pe pia ță sunt :
1. SAP SE
2. ABAS
3. MFG / PRO
4. SYSCON CRONUS

1. SAP SE este unul dintre cei mai mari furnizori de sisteme ERP (Enterprise Resource
Planning). Sistemul SAP permite clien ților săi să î și desfă șoare procesele de afaceri, inclusiv
contabilitatea, vânzările, produc ția, resursele umane și finan țele, într -un mediu integrat. De
asemenea, facilitează utilizarea eficientă a resurselor, inclusiv a for ței de muncă, a ma șinilor și
a capacită ților de produc ție.

Fig.1.5. Sigla SAP

În 2016, SAP deservea peste 335.000 de clien ți în 190 de țări, dintre care 80% erau
întreprinderi mici și mijlocii (SMB). Compania oferă modele de implementare locală, cloud și
hibrid, cu op țiunile de cloud computing. SAP a fos t construit pe baza fostului software SAP
R/3 lansat la 6 iulie 1992. Toate aplica țiile au fost construite având ca baza SAP Web
Application Server. O schimbare completă a arhitecturii a avut loc odată cu introducerea ERP –
ului mySAP în 2004. SAP R/3 a fost înlocuită cu introducerea componentei centrale SAP ECC.
SAP Business Warehouse, SAP Strategic Enterprise Management și Internet Transaction
Server au fost, de asemenea, îmbinate în SAP ECC.
Cea mai recentă versiune, SAP E RP 6.0, a fost lansată în 2006 și a fost actualizată , cel
mai recent pachet de îmbun ătățire fiind SAP 8 pentru SAP 6.0 î n 2016. SAP ERP include mai
multe module, inclusiv:
Financial Acc ounting (FI);

15

Controlling (CO);
Asset Accounting (AA) ;
Sales & Distribution (SD);
Material Management (MM);
Product Planning (PP);
Quality Management (QM) ;
Project System (PS) ;
Plant Maintenance (PM);
Human Resources (HR).
Implementarea sistemelor SAP aduce clien ților următoarele beneficii:
interfa ța cu utilizato rul este complet personalizabilă ;
oferă inf orma ții în timp real;
actualizările se fac o singura dată pentru a fi implementate î n întreaga companie;
îmbunătă țirea eficien ței produc ției, reducerea la minim lipsurile și întreruperile;
reducerea costului for ței de muncă ;
creșterea veniturilor din vânză ri;
costuri administrative reduse etc.

Fig.1.6. Interfa ța SAP

2. ABAS este o aplica ție ERP (Enterprise Resource Planning) și de e -business dezvoltată
de compania germană Abas Software AG in 1981 pentru IMM -uri. Abas Business Suite include
produ sele Abas ERP pentru produc ție și Abas Distribution pentru companiile de distribu ție.
Modulele sistemul Abas includ cumpărarea și vânzările, produc ția, gestionarea materialelor,
contabilitatea financiară și multe altele. Sistemul este utilizat în ingineria mecanic ă și a
instala țiilor, în industria automobilelor și în companiile comerciale și de servicii. Sistemul

16
utilizează un set de caractere Unicode pentru a permite utilizarea în întreaga lume și este operat
în 28 de limbi.

Fig.1.7. Sigla ABAS

Fig.1.8. Interfața ABAS

3. MFG / PRO este o aplica ție de bază pentru întreprinderi extrem de reu șită, deoarece
crește semnificativ eficien ța internă a opera țiunilor în decurs de câteva luni de la achizi ționare.
Software -ul este cuprinzător, deschis, flexibil, scalabil, interactiv și conceput pentru a răspunde
cerin țelor de operare ale producătorilor de astăzi. Aplica ția în MFG / PRO este compatibilă
începând cu anul 2000 și acceptă mai multe valute, inclusiv euro.

Fig.1.9. Sigla MFG / PRO

MFG / PRO include un set ext ins de componente de solu ții pentru produc ție, distribu ție
și financiar. Foarte configurabil și interoperabil, este deschis pentru aplica ții de cea mai bună
calitate, utilizează baze de date Oracle sau Progress și rulează în sisteme de operare precum
Unix , Windows și Windows NT.

17

Fig.1.10. Interfa ța MFG / PRO

Modulele ce conferă MFG / PRO atuuri evidente din perspe ctivele managementului
activită ții de produc ție sunt:
Stocuri;
Comenzi de lucru;
Produc ție în sistem repetitive/advanced repetitive;
Urmărire produc ție;
Lean manufacturing;
Managementul calită ții.
4. SYSCON CRONUS este softw are-ul ERP, cel mai cuprinzător software ERP al
Syscon, concentrat pentru întreprinderile de fabrica ție și mari comerciale, timp de peste două
decenii.
În afară de vânzările, achizi țiile, inventar ul și contabilitatea standard, i ndustriile caută
funcții avansate precum Multi -location, CRM, Supply Chain Management (SCM), Servicii,
BOM multi -nivel (control versiune) MRP, Batch / Route -card, Process, WIP (consum și
respingeri), pla nificare, costuri, QC, între ținere și salarizare pentru luarea de decizii inteligente
și rapide.

18

Fig.1.11. Interfa ța CRONUS

Syscon Cronus este un software ERP, foarte potrivit pentru companii de produc ție și
comercializare. De -a lungul ultimelor două decenii a crescut în ceea ce prive ște tehnologia și
funcționalitatea, cu multiple implementări, ceea ce face produsul foarte robust. Este atât de
cuprinzător încât nu necesită nici o personalizare, care să ajute la lansarea rapidă și reușită.

Fig.1.12. Sigla SYSCON CRONUS

Avantajele sistemului Syscon Cronus sunt:
două decade de experien ța în cadrul sistemelor ERP;
sistem ERP ieftin;
simplu și ușor de implementat;
asigurarea asisten ței pe termen lung;
funcționalită ți bogate;
actualizări gratuite pentru toți clien ții;
implementarea î n 4-6 săptămâni;
o singură versiune ERP pentru to ți clien ții.

19
PARTEA A II -A STUDIU DE CAZ
CAPITOLUL 2. PREZENTAREA LOCULUI DE REALIZARE A STAGIU LUI ȘI
OBIECTIVUL STUDIULUI
2.1 Locul desfă șurării stagiului

În vederea rea lizării lucrării de dizerta ție, prezentul stagiu a fost efectuat în departamentul
PE-FP-M din cadrul Centrului Tehnic Titu (CTT ) al companiei franceze de automobile
RENAULT .

Fig.2.1 . Sigla companiei Renault

Renault este un producător de autovehicule fondat in 1898 de cei trei frați Renault: Louis,
Marcel si Fernand. Compania s-a făcut remarcata prin nu meroasele progrese tehnologice î n
ceea ce prive ște siguran ța pasagerilor, pietonilor, prin construc ția motoarelor folosite î n
competi țiile sportive și nu în ultimul rând prin designul revolu ționar . În urma alian ței cu grupul
japonez Nissan în 1999 și cu Mitsubishi î n 2017, a devenit unul din primii trei mari constructori
de autovehicule din lume.
Renault Româ nia
În Româ nia, producătorul francez de automo bile Renault î și face simțită prezen ța încă din
1966, când ia naștere la Coliba și (astăzi Mioveni), î n județul Arge ș, compania Dacia . Aceasta
avea la bază un acord între autorită țile comuniste și Renault ce prevedea asamblarea unui model
Renault sub marca Dacia. Construc ția Uzinei de Autoturisme Mioveni a început în 1966 și s-a
încheiat într -un timp record de doar un an și jumătate. La 20 august 1968 se începe produc ția
modelului Dacia 1100, un model sub licen ța Renault R8. Conform contractului, Renault fur niza
toate păr țile componente ale modelului, urmând ca cei de la Dacia să le asambleze. După Dacia
1100, a urmat Dacia 1300, care a intrat în produc ție în august 1969, un model sub licen ța R12,
fiind prezentată la saloanele auto de la Bucure ști și Paris. La 10 ani după revolu ția din România,
în 1999, Renault revine pe ntru a cumpără de la Statul Româ n uzinele Dacia și pentru a produce
aici autoturisme low -cost.
Necesitatea unui centru regional de inginerie determină compania Renault să înfiin țeze
la Bucure ști, în 2007, centrul RTR (Renault Technologie Roumanie), unde vor fi concepute
proiectele pentru platforme le tehnice și automobile le comercializate în Europa Centrala și de
Est, Africa de Nord, Turcia și Rusia. Renault Technologie Roumanie face parte din Renault
Engineering și se ocupă î n principal de design, achizi ție, testare, management, IT și resurse
umane. Inginerii din cadrul RTR î și desfă șoară activit atea î n trei loca ții diferite:
1. Bucure ști (North Gate și West Gate): birourile de design
2. Pitești: probleme legate de asamblare și tren de rulare
3. Titu (CTT): centru de testare construit între anii 2008 -2010 și cuprinde zeci de
bancuri de teste și 32 de km de piste.

20

Fig.2.2. Centrul Tehnic Titu

În primul deceniu de existen ță, RTR a scris istorie în ingi neria vehicule și mecanică pentru
prima genera ție a mo delelor din gama Dacia, precum și pentr u actuala gamă. Dezvoltarea vie ții-
serie, prin proiectare, testare și industrializare, a modelelor Logan, Logan MCV, Sandero,
Sandero Stepway, Duster, Lodgy și Dok ker Logan (inclu siv Serii Limitate) poartă și semnătura
inginerilor români de la RTR.
Renault Technologie Roumanie contribuie la dezvoltarea și industrializarea la nivel
mondial a uneia dintre cele mai complexe și de succes game ale Grupului Renault, Globa l
Access, inclus iv pentru via ța serie a motoarelor pe benzină, și a cutiilor de viteză.
Pentru a contribui la formarea viitorilor ingineri, RTR continuă parten eriatele cu cele 15
universită ți tehnice din țară, sus ținând astfel si stemul de educa ție din Rom ânia. Compania o feră,
în continuare, oportunită ți de carieră inginerilor pasiona ți de domeniul automobilelor.
Departamentul PE -FP-M
În cadrul Centrului Tehnic Titu î și desfă șoară activitatea Departamentul Production
Engineering -Fabrication Prototypes -Mech anical (PE -FP-M) care se ocupa cu:
Pilotarea aprovizionă rii cu piese prototip sau serie pentr u organe mecanice in
dezvoltare;
Realizarea cercetă rii în privin ța termenelor de livrare și a pr ețurilor cu furnizorii
prototip;
Inițializarea procedurii de cumpă rare: l ansarea comenzilor;
Asigurarea traiectoriei cheltuielilor în raport cu bugetele acordate ;
Realizarea compozi țiilor prototip, în conformitate cu nomenclatorul de referin ță al
biroului de studii, tabelul de diversitate și în func ție de planificarea pr oiectului.

21

Fig.2.3 . Componentele unui motor

2.2 Obiectivul studiului

Scopul studiului este îmbunătă țirea modului de realizare a comenzii de aprovizionare
prin analiza sisteme lor actual e, SAGESSE și SAP , utilizat e pentru comenzile de piese î n
depar tamentul de Logistica prototip și necesitatea implementării unui nou sistem SAP -Racine.
Pe scurt, pentru efectuarea unei comenzi, pilotul logistică lansează î n SAGESSE comanda. A
doua zi se generează un număr de coma ndă, iar pilotul de la costuri î n baza numă rului generat
de SAGESSE , prelucr ează în SAP detaliile comenzii și o trimite furnizorului. Astfel,
dezavantajul cel mai mare al aces tui sistem este timpul pierdut între generarea unei comenzi și
efectuarea ei. Noul sistem ce urmează a fi implementat are me nirea de a reduce acest timp.
Pentru atingerea obiectivului propus s -au avut în vedere următoarele activită ți:
– am analizat stocul și am î ntocmit necesarul de piese ;
– am fă cut analiza asupra furnizorilor de piese ;
-am studiat modul de realizare a unei comenzi de aprovizionare că tre furnizori interni (Carton
Lancement) ;
-am studiat modul de realizare a unei comenzi de aprovi zionare că tre furnizori externi
(Demande d’Achat) ;
-am făcut o analiza în ceea ce prive ște lansarea comenzilor în sistemul actual ;
-am studiat modul de lansare a unei c omenzi de aprovizionare prin implementarea unui sistem
integrat .

22
CAPITOLUL 3. PREZENTAREA MODULUI DE REALIZA RE A PROCESULUI DE
APROVIZIONARE ÎN SITUA ȚIA INI ȚIALĂ
3.1 Prezentarea sistemelor informatice integrate î n situa ția ini țială

La realizarea comenzilor de aprovizionare sunt necesare doua sisteme: SAGESSE și SAP.
SAGESSE este un sistem integrat folosit în Grupul Renault atât p entru lansarea comenzilor, cât
și pentru a verifica stocul de piese, pentru a re aliza fabricația prototip. În ceea ce priveș te stocul
de piese, folosind acelaș i program cu centrele de cercetare din Franț a se poate verifica stocul
pieselor acelor magazii ș i se pot face comenzi de aprovizionare pentru piesele aflate în condiț ie
apro. SAP est e un sistem utilizat la scara largă având module specifice pentru fiecare tip de
activita te, precum: planificarea producț iei, resurse umane, contabilitate, vânzări și distribuție,
mentenanț a fabricii, management -ul materialelor și al calităț ii. În caz ul de față SAP este folosit
pentru finalizarea c omenzilor realizate în SAGESSE ș i trimiterea lor către furnizori, în urma
căreia se începe fabricarea pieselor.

Fig. 3.1. Sigla SAGESSE

Sagesse conț ine 2 module specifice RTR (fig. 3.2) și anume:
Modulul pentr u realizarea comenzilor și lansarea în fabricație prototip a cerinț elor
clientului: T4300 00;
Modulul pentru recepționarea pieselor ș i colectarea pieselor pentru fabricaț ia prototip:
T4300 20.

Fig. 3.2. Module SAGESSE

SAP este un sistem utilizat la s cara largă având module specifice pentru fiecare tip de
activitate, precum: planificarea produc ției, resurse umane, contabilitate, vânzări și distribu ție,
mentenan ța fabricii, management -ul materialelor și al calită ții. În cazul de fa ță SAP este folosit
pentru finalizarea comenzilor realizate în SAGESSE și trimiterea lor către furnizori, în urma
căreia se începe fabricarea pieselor.

23

Fig. 3.3 . Module SAP

Comenzile sunt de două tipuri:
Către furnizori interni (Automobile DACIA, Cleon, Flins) se lansează c omenzi de tip
Carton Lancement (CL) care se prelucrează în SAGESSE;
Către furnizori externi (MGI Coutier, Nobel Automotive) se lansează comenzi de tip
Demande d’Achat (DA) care se prelucrează în SAGESSE și SAP.
Etapele realiză rii unei comenzi de aprovizi onare către furnizori interni sunt:
Înregistrare comandă SAGESSE
Date cumpărător
Date furnizor
Validare comanda
Imprimare comandă
Pentru a realiza o comandă către furnizori externi se parcurg etapele următoare:
Prelucrare comanda SAGESSE
Transfer date într e SAGESSE și SAP
Prelucrarea datelor comenzii în SAP
Validare comandă
Imprimare comandă

Fig. 3.4 . Etape SAGESSE și SAP
SAGESSE
•Înregistrare comandă
SAGESSE
•Date cumpărător
•Date furnizor
•Validare pret
•Imprimare
SAP
•Prelucrare comandă
SAP
•Validare comandă
•Imprimare comandăTransfer date între
SAGESSE și SAP

24
3.2 Modul de realizare a procesului de aprovizionare ini țial
3.2.1 Pentru furnizori interni

Odată cu semnarea bugetului pentru proie ct se poate începe procedura de contactare a
furnizor ilor, prin e -mail sau telefon, î n vederea stabilirii detaliilor pentru lansarea comenzilor :
Datele bancare și factura proformă ;
Prețul pe piesă ;
Termenul de livrare .
Datele bancare și factura proformă sunt necesare pentru actualiza rea bazei de date a
sistemului î n vederea plă ții facturilor trimise de furnizori. Co mpania Renault fiind împăr țită în
mai mu lte site -uri, au fost situa ții în care furnizorii nu în țelegeau de ce li se solicita încă odată
aceste documente, în condi țiile în care mai onoraseră comenzi către această companie. Această
situa ție se datora faptului că se crea confuzie î ntre Centrul Tehnic Lardy si Centrul Tehnic Titu,
care funcționează ca două entită ți separate.
Piesele pot fi de două tipuri: serie sau prototip.
În cazul pieselor prototip, pre țul pe piesă îl stabile ște fiecare furnizor în func ție de
costurile de fabrica ție care implică achiziția materialelor speciale, aplicarea tratamentelor
specifice. Pe lâ ngă pre țul pe piesă furnizorul poate solicita un cost suplimentar pentru
achizi ționarea dispozitivelor prototip.
Pentru piesele serie, pre țul pe piesă este mult mai mic în compara ție cu cele pro totip
deoarece acestea se afla în faza de fabrica ție la scara larga.
În afară de pre țul pieselor, furnizorul poate solicita costuri suplimentare cum ar fi: pentru
pregă tirea comenzii, ambalarea co letelor, transportul pieselor. În privin ța costului de transport
daca acesta este prea mare se poate solicita furnizorului ca trans portul sa fie organ izat de
cumpără tor.
Termenul de livrare diferă de la un furnizor la altul î n funcție de planificarea produc ției
acestuia , dar și de comp lexitatea piesei. Spre exemplu î n cazul turbinei motorului termenul
standard de l ivrare a piesei este de zece săptămâni. În cele mai multe cazuri , la piesele prototip
termenul de livrare nu se respectă datorită utilaje lor prototip care necesită recalibrări, astfel
realizâ ndu-se pies e care nu primesc acordul calită ții pentru livrare.
Ofertele de preț , în general sunt sub for ma unui deviz ata șat în e-mail, dar din cauza lipsei
de timp sunt furnizori care oferă detaliile cerute î n mesajul e -mail-ului.
După ob ținerea informa țiilor de la furnizor se lansează comenzile în sisteme .
Pentru a realiza o comandă de aprovizionare că tre furnizori interni se lansează o comandă
de tip Carton Lancement , care presupune urmă toarele etape.

25

Fig. 3.5. Etape comandă furnizori interni

Se consultă fi șierul cu pre țuri, apoi se lansează comanda:
GSE HA02S9082R – PIGNON ARBRE CAME
Se complete ază proiectul pentru care se face comanda, tipul comenzii CL, se bifează
acordul pentru plată din bugetul proiectului, apoi se completează C pentru creare (fig. 3.6 ).
Comenzile de tip Carton Lancement nu se vor prelucra în SAP și ca urmare se pune N de la
NON. Se adaugă referin ța și codul magaziei, iar mai jos cantitatea și data de li vrare, care este
exprimată în săptămâ nă / an.

Fig. 3.6 . Creare comandă către furnizori interni

La pasul următor se confirma crearea Carton Lancement, i se atribuie un num ăr de
înregistrare și pentru verificare este afi șată și denumirea piesei (fig. 3.7 ).

Înregistrare
comandă
Date
cumpărător
Date
furnizor
Validare
preț
Imprimare
CL

26

Fig. 3.7 . Înregistrare comandă către furnizori interni

Se completează numele solicitantului, furnizorul și persoana de contact, moneda și
prețul pentru piesa (fig. 3.8).

Fig. 3.8 . Adăugare furnizor intern

ATOMOBILE DACIA S.A. este un furnizor intern important pentru Centrul Tehnic
Titu, nu numai în privin ța costului redus a pieselor, dar și în privin ța transportului, având în
vedere că o dată pe s ăptămâ nă există un tra nsport î ntre cele două societă ți. În ziua î n care ajunge
transportul cu piese, acesta este încărcat cu marfă având ca destina ție Dacia.
După confirmarea mesajului va fi afi șat numele persoanei de contact și costul total, iar in
acest moment va f i printat C arton Lancement .
Pentru ca furn izorul să poată fi plă tit, comanda de tip Carton Lancement trebuie să ajungă
în statut 4 (fig. 3.9), iar ca piesele să fie recep ționate trebuie sa aibă statut 5 (fig. 3.10).

Fig. 3.9 . Schim bare statut comandă

27

Fig. 3.10. Finalizare comandă

3.2.2 Pentru furnizori externi

Pentru a realiza o comandă de aprovizionare că tre furnizori externi se lansează o comandă
de tip Demande d’Achat care implică mai mul ți pași, spre deosebire de Carton Lancement, și
preluc rarea comenzii î n SAP.

Fig. 3.11. Etape comandă furnizori externi
Înregistrare
comandă
Date
cumpărător
Date
furnizor
Validare
preț
Imprimare
DA
Prelucrare
comandă
Validare
comandă
Imprimare
comandă

28
GSE 13RT5KY36R – COUVERCLE CULASSE
Primul pas este asemănător comenzii de aprovizionare Carton Lancement, numai că se
schimba tipul comenzii, și anume DA, și, fiind piesă prototip s e bifează CTA pentru ca piesa
să fie verificată de calitate la recep ționarea acesteia . De asemenea, pentru ca datele să fie
transmise spre prelucrare în SAP, trebuie aprobat Envoi SAER și adăugat Code Acheteur.
Se atribuie numărul de înregistrare al comenz ii de aprovizionare Demande d’Achat și se
verifică concordan ța dintre referin ță și denumire (fig. 3.12).

Fig. 3.12 . Înregistrare comandă către furnizori externi

La pasul următor se completează numele cumpărătorului (fig. 3.13).

Fig. 3.13 . Nume cu mpărător

În următoarea etapă se completează codul furnizorului și prețul pe piesă . Codul furnizor
se consulta în baza de date a SAGESSE -ului în func ție de detaliile oferite de furnizor, precum
codul contabil sau adresa uzinei de fabrica ție a pieselor. Î n majoritatea cazurilor moneda
folosita de furnizori este EURO.
Pentru verificare apare numele furnizorului și de asemenea pre țul pentru toată cantitatea
de piese (fig. 3.14 ).

29

Fig. 3.14 . Furnizor extern

După verificare, pre țul se validează și nu se ma i poate modifica (fig. 3.15).

Fig. 3.15 . Validare pre ț

În sectorul logistic, odată completat codul persoanei de contact trebuie confirmat . În baza
de date SAGESSE, fiecare furnizor are o persoană de contact căreia ii este atribuit un cod de
identifi care în sistem. Pentru a identifica codul persoanei de contact este necesar codul furn izor
din etapa precedentă. Pentru siguran ță, se verifică coresponden ța codului interlocutor cu numele
persoanei de contact.
După validarea datelor furnizorului (3.16) , comanda de ti p Demande d’Achat este
imprimată , în acest moment aflându -se în statut 3 (fig. 3.17).

30

Fig. 3.16 . Validare cod interlocutor furnizor

Fig. 3.1 7. Statut comandă

Pentru a se putea prelucra comanda î n SAP trebuie ca DA -ul să treacă î n statu t 4 (fig.
3.18) și să fie semnat de către Inginerul sinteza tehnică, pentru a putea fi prelucrat de pilotul
costuri.

Fig. 3.18 . Finalizare comandă SAGESSE

Pentru a continua procesul de realizare a comenzii aprovizionare că tre furnizori externi
trebui e ca î ntre SAGESSE și SAP să existe un transfer de date. Datele transferate sunt vizibile
într-un timp de douăzeci și patru de ore , când î n SAGESSE , pe lângă numărul de î nregistrare
al DA -ului se at ribuie și un număr de comandă (fig. 3 .19) pentru ca datele să poată fi prelucrate
in SAP.

31

Fig. 3.19 . Finalizare comandă SAGESSE

După ce comanda de aproviz ionare de tip DA a fost semnată, este transmisă pilotului
costuri pentru prelucrarea în SAP . Pentru a prelucra o comandă de aprovizionare î n SAP se
folosesc trei module (fig. 3.20 ) și patru etape importante:
1. Modulul ME23N – prelucrarea datelor comenzii ;
2. Modulul ZME28 – validarea comenzii ( necesita dubla validare) ;
3. Modulul ME9F – imprimarea comenzii .

Fig. 3. 20. Module prelucrare comandă

1. În Modulul ME 23N se prelucrează informa țiile descă rcate din SAGESSE accesând
urmă toarele ferestre:
Se completează numărul de comandă generat de SAGESSE pentru a se descarcă
informa țiile (fig. 3.21 ).

Fig. 3.21 . Descărcare date comandă

Prima etapă este de ver ificare a informa țiilor și se poate observa faptul că apare referin ța,
numele piese i, cantita tea, data de livrare, pre țul, moneda, loca ția de unde a fost lansată
comanda, precum și numărul de î nregistrare al Demande d’Achat.
În fereastra Livrare/factura se compl etează termenul de plata al facturii și modalitatea de
livrare a pieselor (fig. 3.22 ).

32

Fig. 3.22 . Termen de plată și livrare

În următoarea fereastră, Texte, se completează informa ții suplimentare despre pilotul
logistica (fig. 3.23 ).

Fig. 3.23 . Date cumpărător

În continuare, s e accesează fereastra Comunica ție unde se compl etează datele persoanei
de contact a furnizorului (fig. 3 .24).

Fig. 3.2 4. Date furnizor

La Date suplimentare se adaugă numărul ofertei de pre ț trimise de furnizor (fig. 3.2 5)
sau în cazul în care informa țiile pentru cumpă rare au fost transmise prin e -mail, se specifica e –
mail.

33

Fig. 3.25 . Date oferta pre ț

În fereastra Date de organiz are se completează codul persoanei care preluc rează datele
comenzii (fig. 3.26 ), pilot costuri, iar mai jos se adaugă adresa de livrare a pieselor (fig. 3.27 ).

Fig. 3.26 . Date pilot costuri

Fig. 3.27 . Adresa de livrare

2. Modulul ZME28 cuprinde două etape ale validă rii :
a. Validarea pilotului costuri ;
b. Validarea S uperior Achat .

34

Fig. 3.28 . Modul validare comandă

a. Validarea pilot costur i (fig. 3.29 ) se face prin completarea numărului de
comandă și a codului cheie de validare (MV) , urmat de apă sarea butonului de executare.

Fig. 3.29 . Cod pilot costuri

Se afi șează o fereastră ce con ține inf orma ții cheie de verificare (fig. 3.30 ), și se activează
fereastra urmată de apă sarea butonului de validare.

Fig. 3.30 . Validare coma ndă

În aces t moment comanda a fost validată din punct de vedere al pilotului costuri (fig.
3.31) și va merge pentru val idarea finala la Superior Achat.

35

Fig. 3.31 . Verificare validare coma ndă

b. Validarea Superior Achat (fig. 3.32 ) se face respectând pa șii de la validare pilot
costuri, singura diferen ță fiind codul cheie de validare .

Fig. 3.32 . Modul validare Superior Achat

Codul cheie de validare S uperior Achat (fig. 3.33 ) este de trei tipuri în func ție de
valoarea comenzii:
V0: 0 – 10000€ ;
V1: 10001 – 30000€ ;
V2: 30001 – 75000€ .

Fig. 3.33 . Cod Superior Achat

Comanda pe ntru care s -a făcut studiul se încadrează la codul cheie de validare V0.
Accesâ nd meniul ME23N se observă statusul celor două coduri cheie de validare (fig.
3.34).

36

Fig. 3.34 . Verificare validare coma ndă

3. Modulul ME9F se folose ște pentru imprimarea comen zii, respectiv pentru salvarea î n
format e lectronic (fig. 3.35 ).

Fig. 3.3 5. Modul imprimare comandă

Se adaugă numărul de comandă, urmat de butonul executare (fig. 3.36 ).

Fig. 3.36 . Adăugare număr comandă

Se selectează comanda (fig. 3.37 ) și se optează pentru pre -vizualizare înainte de
imprimare (fig. 3.38 ).

Fig. 3.37 . Vizualizare comenzi

37

Fig. 3.38 . Previzualizare comandă

După verificare se apasă butonul mesaj de ie șire, iar comanda este transmisa că tre
imprimantă .
După finalizarea comenzii, aceasta este transmisă î n format elect ronic prin e -mail
furnizorului pentru a î ncepe fabricarea pieselor.

38
3.3 Analiza modului de realiza re a comenzii de aprovizionare în situa ția ini țială

În urma stud iului efectuat asupra celor două moduri de realizare a comenzilor de
aprovizionare s -a făcut o analiza pentru a se observa ceea ce trebuie îmbunătă țit în proces.
Realizarea comenzilor este un proces deoarece implică mai multe etape, și ca orice proces se
dorește a se îmbunătă ți continuu și a se elimina pierderile.
În cazul re aliză rii comenz ilor de aprovizionare către furnizori interni se folose ște un
sistem î n care se parcurg patru etape și este nevoie de o singură persoană. Pe când , în cazul
comenzilor că tre furnizori externi se folosesc două sisteme î n care parcurg mai mult e etape,
este necesară interven ția mai mult or persoane asupra procesului, și necesită un timp de douăzeci
și patru de ore pentru finalizarea comenzii, datorită transferului de date d intr-un sistem în
celălalt.
Etapele realizării comenzii de aprovizionare c ătre furnizori externi:
1. consultarea furnizorului în vederea sta bilirii ofertei de pre ț;
2. actualizarea coordonatelor bancare ale furnizorului ;
3. identificarea codului furnizor și a perso anei de contact ;
4. realizarea comenzii î n SAGESSE ;
5. aprobarea DA -ului;
6. transf erul datelor din SAGESSE î n SAP ;
7. prelucrarea comenzii î n SAP;
8. validarea comenzii ;
9. salvarea com enzii î n format electronic ;
10. trimiterea comenzii la furnizor ;

Din punct de vedere al timpului de realizare a co menzii sunt necesare două zile pent ru ca
o comandă sa fie transmisă furnizorului.
Factorii de risc ce pot împiedica realizarea comenzilor de aprovizionare sunt:
1. lipsa generării numărului de comandă a doua zi în SAGESSE
2. transferarea eronată a datelor comenzii de aprovizionare în SAP
Fiind două sisteme exist ă multe dezavantaje:
durată mare de realizare a comenzii de aprovizionare pentru transmiterea datelor ;
sunt implicate mai multe persoane pentru a se realiza o comandă de aprovizionare ;
pentru pregătirea personalului nou sunt necesare formări ce necesită ti mp și costuri ;
mentenan ța sistemelor ce implică costuri suplimentare.
Ca orice proces se dore ște îmbunătă țire continuă ș i reducere de costuri și timp, s -a luat
hotărârea implement ării unui sistem menit să îmbunătățească procesul de aprovizionare, prin
inclusiv a costului de mentenanță asociat acestuia, timpul de realizare a comenzii și numărul de
persoane de persoane implicate .

39
CAPITOLUL 4. ÎMBUNĂTĂ ȚIREA MODULUI DE REALIZARE A COMENZII DE
APROVIZIONARE PRIN IMPLEMENTAREA UNUI SISTEM INTEGRAT

SAP-Racine este un sistem integrat men it să înlocuiască cele două sisteme actuale și
pentru a face posibilă realizarea mult mai rapidă a comenzilor de achizi ții. Astfel prin
implementarea noului sis tem integrat s -a renunțat la realizarea comenzilor de achiziții în cele
două moduri, atât pentru furnizori interni (Carton Lancement), cât și pentru furnizori externi
(Demande d’Achat), folosindu -se un singur tip de formular de comandă. Pentru îmbunătă țirea
modului de realizare a comenzilor noul sistem integra t implica un proces mai simplu și implicit
un numă r mai mic de persoane.
Pentru a realiza o comandă de achizi ție în noul sistem integrat este necesar parcurgerea
următoarelor etape:
1. Lista contactelor furnizorului
2. Clasificarea solicitărilor de cumpărare
3. Documenta ția fișelor factuale Info -Buy
4. Solicitare de cumpărare
5. Realizare comandă
6. Validare comandă
7. Relansarea furnizorului
Înainte de a realiza o comandă de achizi ție, trebuie să se respecte etapele pregătitoare de
mai jos:
1. Lista contactelor furnizorului
Datele gen erale ale furnizorilor Proto sunt actualiz ate auto mat în Racine, cum se
procedează la momentul actu al în SAP (cont, adresa, incoterms …).
Pe de altă pa rte, este necesar să se actualizeze în mod regulat directorul contactelor
furni zorilor pentru contacte le Proto . Există 3 tipuri de contacte pentru Proto :
contacte de tip Z8 sunt c ontacte achizi ție pentru care numele, prenumele și e-mail sunt
incluse automat, comanda de aproviz ionare t rimisă automat după validare , la adresa de e -mail
documentată . Contactul poate fi valabil pentru to ți cumpărătorii sau este posibil să existe un
contact diferit prin codul cumpărătorului. Adresa de e -mail a furnizorului poate fi o adresă
generică pentru plasarea comenzilor sau poate fi cea a persoanei căreia îi este trimis ă comanda.
Contactele Z9 sunt contacte contabile ale furnizorului
Tipurile de contacte Z10 sunt contactele logistice ale furnizorului.
Indiferent de contact, este posibilă documentarea unei cantită ți mari de informa ții pentru
un contact, inclusiv un cod referit or la proiectele pentru care lucrează.
2. Clasificarea solicitărilor de cumpărare
Sistemul consolidează nevoile rezultate din nomenclatură și compara cu stocul în timp
real pentru a genera automat cereri de cumpărare dacă stocurile nu sunt suficiente. Aces te
solicitări de cumpărare sunt dinamice, ceea ce înseamnă că acestea sunt recalculate în fiecare
zi în func ție de nevoile în schimbare.
Primul pas în procesarea cererilor de cumpărare este de a le clasifica. Pent ru aceasta, vom
documenta codul tipului de piesă care trebuie achizi ționat . Acest cod face posibilă gestionarea
portofoliilor diferitelor persoane responsabile cu furnizarea. Dacă este o componentă nouă,
indiferent dacă provine din configurator sau nu, sistemul va atribui un cod tip piesă = IND,

40
pentru Nedefinit. Este posibil să fie exportată lista de articole cu acest cod tip piesă pentru a le
modifica în masă . Celelalte valori stabilite pentru Proto sunt prezentate mai jos.
Aici este posibilă interogarea inventarelor din fabrică pentru a vedea dac ă piesele pot fi
livrate din fabrică.
Prin urmare, dacă se decide clasificarea portofoliilor după alte criterii, este posibil să se
atribuie un nou cod manager care momentan este liber și se regăse ște sub denumirea de GFE .
Codul Managerului este păstrat la nivelul elementului, ceea ce î nseamnă că nu este nevoie să
fie redefinit de fiecare dată când elementul este pus în aceea și ordine.

Tabel 4.1. Clasificare Cod tip piesă

După documentarea informa țiilor logistice ale furnizorului se încep etapele realizării
comenzii de aprovizionare în noul sistem integrat.

Fig. 4.1. Etape realizare comandă SAP -Racine

Fișa Info –
AchizițiiSolicitare de
cumpărareRealizare
comandăValidare
comandăCOD NUME COD
IND NEDEFINIT
USN UZINAJ
AFF PIESA AFECT ATĂ
NAF PIESA NEAFECTATĂ
CHI PRODUS CHIMIC
VBQ ȘURUBURI, BOL ȚURI,
FERONERIE
CON CONECTICĂ
INS INSTRUMENTARE
PHF PRODUS IN EXTERIORUL UZINEI
ADA PIESA DE ADAPTARE
G11 GFE 11
G12 GFE 12
G13 GFE 13
G14 GFE 15

41
3. Documenta ția fișelor Info-Achizi ții
Fișa cu informa ții despre cum părături este un obiect care permite conectarea unui furnizor
la un articol și documentarea unei anumite canti tăți de informa ții, cum ar fi pre țul articolului
sau codul cumpărătorului, de exemplu. Mai multe înregistrări pot fi documentate pentru un
element dacă există mai mul ți furniz ori posibili.
Fișa Info Achizi ții poate fi importată direct în Racine dintr -un fișier Excel

Fig. 4.2 . Fișa Info -Achizi ții

Fișa cu informa ții despre achizi ții poate fi documentată par țial atunci când este creată,
astfel încât să se poată importa mai înt âi conturile de plată și, mai târziu, pre țurile ulterioare, de
exemplu.
Informa țiile în aceste forme vor fi predominante în raport cu alte informa ții documentate
despre cererile de cumpărare până la transformarea într -o comandă.
Dacă sunt documentate mai m ulte fi șe cu informa ții despre cumpăr ături pentru acela și
articol, se poate alege care dintre ele să fie luate în considerare în cererea de achizi ție curentă.
Fișele cu informa ții despre cumpărături sunt specifice departamentului, ceea ce înseamnă
că fieca re departament va trebui să definească toate conturile furnizorilor și pre țurile pentru
toate componentele sale.
În ceea ce prive ște func ționarea, în cazul în care mai multe valuri se urmează unul pe
celălalt, fi șele cu informa ții despre cumpărături trebui e să fie actualizate pentru a indica
prețurile care trebuie luate sub valul înainte de transformarea cererilor de cumpărare în comenzi.
Odată ce conversia a fost finalizată, pre țul poate fi mod ificat direct pentru a transmite comanda
fără a modifica fi șa cu informa ții despre cumpărături.
4. Solicitare de cumpărare
Cererile de cumpăr are care au fost create și depus e sub c odul de manager sunt dinamice,
ceea ce înseamnă că toate cantită țile și datele de livrare sunt recalculate în fiecare zi, în func ție
de act ualizări în GPS și în ale configuratorul ui .
În momentul în care informa țiile complete ale Fișei Info -Achizi ții sunt complete, se vor
regrupa cererile de achizi ție.
Gruparea constă în crearea unei cereri de cumpărare a grupării în imaginea ordinii
viitoare , adică cu toate elementele comenzii.
Dacă se lucre ază confo rm programului pentru componentă , Racine va crea cât mai multe
solicitări de cumpărare, deoarece există termene limită, iar solicitarea de cumpărare de grup se
va grupa împreună cu celelalte .
Oper ațiunea de grupare este manuală și logistica sau managerul de portofoliu care,
cunoscând furnizorii, vor face această grupare. Opera țiunea se face ca și cum se selectează
solicitările de cumpărare și le pune ți într -un co ș de cumpărături reprezentând solici tarea de
cumpărare a grupului.

42

Fig. 4.3 . Creare Demande d’Achat

Fig. 4.4 . Finalizare Demande d’Achat

De asemenea, Codul Cumpărător al tuturor componentelor este necesar să fie acela și, în
caz contrar, sistemul va aloca ordinului codul cumpărătorul ui din primul element al comenzii.
De asemenea, în acest moment, indicăm tipul cererii de achizi ție:
Comenzi de aprovizionare de tip ZCRP pentru o comandă de achizi ție externă de la un
furnizor
Comenzi de aprovizionare de tip ZPOI pentru un ordin de transf er de la o fabrică
Comenzi de aprovizionare de tip ZUB pentru un ordin de transfer între entită țile proto;
acestea sunt, în mare parte, generate automat de interfa ța configuratorul ui pentru schimbul
motorului sau vehiculului .
După ce gruparea a fost termin ată, acest pas este completat de atribuirea furnizorului.
Această opera țiune constă în transferarea informa țiilor din contul furnizorului din fi șa cu
informa ții despre cumpărări la solicitarea de cumpărare regrupată. În acest moment se poate
schimba un fur nizor implicit pentru a -l selecta pe cel care este re ținut pentru comandă
Odată ce a fost înghe țată cererea de achizi ție, cantită țile și datele de livrare nu vor mai fi
actualizate automat.

43

5. Realizare comandă
Odată ce a fost creată solicitarea de achizi ție și furnizorul a fost asociat solicitării
respective , se poate trece la pasul următor pentru transformarea solicitării de cumpărare într -o
comandă.

Fig. 4.5 . Num ăr comandă

În acest moment, Racine nu va lua in considerare comenzile cu prețurilor com ponentelor
din Fi șele de informa ții privind achizi țiile.
În cazul în care comenzile au fost deja plasate sub val, trebuie verificat ca cererile de
cumpărare noi să fie aprobate . În acest sens, trebuie să se creeze aprobări pentru noile solicitări
existente .
Apoi, toate solicitările de cumpărare rămase sunt transformate automat în comenzi noi.
Odată ce comanda de achizi ție a fost creată, poate fi modificată dacă este necesar:
Schimbarea adresei de livrare pentru a înlocui adresa implicită, cea a depozitului logistic
Adăugarea contactul ui logistic al furnizorului
Modificarea datei livrării
Adăugarea elementelor de cumpărare pe posturi precum sta ții de scule, servicii etc.
După ce comanda a fost prelucrată se pre -vizualizează pentru a se verifica detaliile
prelucrate înainte de trimitere spre validare.
6. Validare comandă
Validarea comenzilor este configurabilă pentru fiecare departament. Primul nivel este cel
al solicitantului care validează faptul că ordinul este pregătit. Se pot configura unul sau două
nivelu ri de validare. Există un pas de semnare, variabil în funcție de valoarea ordinului și, în
final, o copie automată a ordinului în SAP înainte de trimiterea prin e -mail către Furnizor.
Principiul de validare este după cum urmează: se asociază cheile la fiec are nivel și se
atribuie codul persoanelor respective și cheia sau cheile care corespund. Apoi validatorii și
semnatarii merg la Racine și validează ordinele în așteptare ale departamentului pentru care
sunt declarate. Dacă o persoană este absentă, un alt validator de același rang poate valida în
locul său. Validarea primului element al unei comenzi validează întreaga comandă.

44

Fig. 4.6 . Proces validare comandă

Ultima etapă a procesului de realizare a comenzii de aprovizionare este de imprimare a
formula rului de comandă si expedierea acestuia în format electronic către furnizor.

Fig. 4.7 . Formular comandă

45
7. Relansarea furnizorului
Sistemul distinge două no țiuni: memento -ul care poate fi trimis ÎNAINTE de data de
livrare preconizată și memento -ul trim is în caz de întârziere, DUPĂ data livrării preconizate.
Cele două tipuri de "callback" și "restart" sunt configurabile pentru crearea automată a
mesajelor.
Setarea constă în definirea unei "chei" cu 3 valori maxime care indică numărul de zile
între data c elor 3 mementouri și data livrării. Valorile implicite sunt documentate în
departament .
Setarea se aplică la fiecare termen limită al ordinului.
În fiecare zi, Racine generează un tabel de mem entouri calculate, iar logisticianul îl
selectează pe cel pe car e îl trimite. Aceste mesaje parametrizate sunt trimise în mod automat de
către solicitant contactului logistic al furnizorul ui documentat în comandă.

Fig. 4.8 . Relansare furni zori

Apoi, în func ție de întârzierile anun țate de Furnizor, logisticianul are posibilitatea de a
actualiza manual data livrării a ordinului, păstrând în acela și timp data inițială de livrare .
Această dată este apoi luată în considerare de Racine în calculul disponibilită ții planificării.

46
PARTEA A III -A CONCLUZII FINA LE ȘI CONTRIBU ȚII PROPRII

Prin acest studiu s -a urmărit o îmbunătă țire a procesului de realizare a comenzilor de
aprovizionare atât către furnizorii interni, cât și către furnizorii externi.
Astfel au fost îmbunătă țite două sisteme complexe:
SAP ce con ține module atât în domeniul logistic, cât și în cel al contabilită ții dar și al
resurselor umane;
SAGESSE ce con ține module în domeniul logistic și al fabrica ției

Fig. 5.1 . Module sistem ini țial

Sisteme au fost îmbunătă țite prin unirea într -unul singur și astfel rezultând sistemul
integrat SAR -Racine, cu module mai pu ține și mai simple.

Fig. 5.2 . Module sistem actual

47
Pe lângă reducerea numărului de module se observă faptul ca s -au redus at ât numărul de
persoane implicate în realizarea procesului de aprovizionare (fig. 5.3), cât și numărul de etape
specifice procesului de aprovizionare (5.4). Prin implementarea noului sistem integrat se poate
observa o reducere a personalului cu 50%, dar și a etapelor procesului cu 50%.

Fig. 5.3 . Grafic personal i mpactat

Fig. 5.4 . Grafic etape proces

În urma studiului comparativ, implementarea noului sistem a adus beneficii din
următoarele puncte de vedere:
Tabel 5.1 Studiu comparativ
Sistem inițial Sistem îmbunătățit
Costuri  
Timp  
Personal  
Număr sisteme  
Mentenanță   00,511,522,533,544,5Num ăr persoane
Tip ProcesGrafic personal imp licat
Proces initial
Proces actual
0123456789
8Num ăr Etape proces
Tip ProcesEtape proces
Proces initial
Proces actual

48
O altă contribu ție proprie a fost cea a adăugării mai mult or informații pe formularul de
comanda de aprovizionare pentru a avea o mai buna trasabilitate asupra livrării pieselor. Au
fost adăugate următoarele contacte:
Datele persoanei care validează;
Datele persoanei din cadrul departamentului cumpără ri al furnizorului;
Datele persoanei logistice al furnizorului.
Formularul de comandă
Formularul de comandă este similar cu forma curentă generată de S AP.

Fig. 5.5 . Formular de comandă

Principalele informații care sunt cuprinse într -un formular de comandă sunt:
1. Datele de contact ale cumpără torului;
2. Datele de contact ale persoanei care validează comanda;
3. Datele de contact ale persoanei din cadrul departamentului cumpără ri al furnizorului;
4. Datele de contact ale persoa nei care a trimis oferta de pre ț;
5. Datele de contact ale persoanei logistica a furnizorului.
Totodată se oferă posibilitatea livrării pieselor eșalonat și pentru aceasta a fost adăugat
un program de livrare sub forma unui tabel de sinteză la sfâr șitul comenzii .

49

Fig. 5.6 . Livrarea pieselor e șalonat

Contribuț iile personale în cadrul lucrării au constat în:
Studiu bibliografic ;
Centralizarea informațiilor asupra procesului de realizarea a comenzilor de
aprovizionare;
Participarea la realizarea comenzilor de aprovizionare în sistemel e inițial e;
Analiza procesului inițial de realizare a comenzilor de aprovizionare;
Participarea la realiza rea comenzilor de aprovi zionare î n sistemul implementat;
Identificarea posibilităților de îmbunătățire și propunerea soluțiilor;
Analiza soluțiilor propuse.

50
BIBLIOGRAFIE

1. https://en.wikipedia.org/wiki/Enterprise_resource_planning
2. https://ro.wikipedia.org/wiki/Planificarea_resurselor_%C3%AEntreprinderii
3. http://www.quadrans.fr/index.php/fr/savoir -faire/prestation -a-la-carte/erp
4. http://www.rasfoiesc.com/educatie/ informatica/calculatoare/Navigarea -in-sistemul –
informat15.php
5. https://abas -erp.com/fr/products
6. Notițe curs, Gestiunea integrată a produc ției, ș. l. dr. ing. GAVRILU ȚĂ Ana
7. https://www.logisticsonline.com/doc/mfgpro -software -0001
8. https://public -supportcenter.qad.com/list/ -/asset_publisher/QkwqJKGnHsh5/content/
customer -assessment -program -for-version -eb2-1-and-below -standard -edition -se-and-below –
and-below -on-progres s?inheritRedirect=false
9. https://www.techjockey.com/detail/syscon -cronus -enterprise -erp
10. https://mibuso.com/downloads/microsoft -dynamics -nav-w1-2016 -cumulative -update –
3-build -44365
11. http://www.gruprenau lt.ro/presa/comunicate -de-presa/2016/renault -technologie –
roumanie -la-10-ani-de-activitate
12. http://wikimapia.org/630769/ro/Centrul -Tehnic -Titu-al-Renault -Technologie –
Roumanie