Implementarea Sistemului Informatic Integrat Oracle Ebusiness Suite

Implementarea Sistemului Informatic Integrat ORACLE eBUSINESS SUITE

pentru modulul Contabilitate Furnizori.

Studiu de caz. Analiză.

Cuprins

TEORIE

1. NOȚIUNI INTRODUCTIVE

1.1 CONCEPTUL DE ERP

1.2 SCURTĂ ISTORIE A ERP

1.3 METODOLOGII DE IMPLEMENTARE A UNEI SOLUȚII ERP

1.4 CAT DE PROFITABILÄ ESTE O SOLUȚIE ERP

STUDIU DE CAZ: IMPLEMENTAREA SISTEMULUI INFORMATIC INTEGRAT ORACLE eBUSINESS SUITE LA BUTANGAS ROMÂNIA

2. BUTAN GAS ROMÂNIA, ANALIZA SISTEMULUI EXISTENT

2.1 DESPRE COMPANIE

2.2 FLUXUL DE LUCRU SPECIFIC BUTANGAS AFERENT MODULULUI AP

3. PROIECTAREA SOLUȚIEI

3.1 VIZIUNE DE ANSAMBLU

3.2 ABORDAREA PROIECTULUI

3.2.1 MIGRAREA DATELOR INIȚIALE

3.2.2 METODOLOGIA DE IMPLEMENTARE

4. DERULAREA PROIECTULUI

5. CONCLUZII/BENEFICII, RISCURI

6. BIBLIOGRAFIE

7. ANEXE

NOȚIUNI INTRODUCTIVE

Cantitatea de informație care se vehiculează în prezent, informație obținută, gestionată și manipulată în firme, a crescut în mod semnificativ în ultimul timp. Această tendință clară de creștere este accentuată și de cerințele tot mai mari în ceea ce privește calitatea informației care se dorește a fi tot mai corectă și mai operativă.

Cel mai bun și prompt furnizor de informație cu privire la diverse fenomene și procese economice se dovedește a fi sistemul informatic economic; acesta contribuie în mod decisiv la economisirea resurselor materiale, de energie și de muncă, la perfecționarea relațiilor dintre societățile comerciale și totodată pune la dispoziția oricărui sistem de producție, informații operative asupra condițiilor în care își poate desfășura activitatea. Cu ajutorul sistemelor informatice economice se pot stabili dimensiunile optime privind capacitatea de producție, piețele de aprovizionare, respectiv de desfacere, costuri de producție, rentabilitate, rezultând în cele din urmă activități desfășurate tot mai eficiente.

Când cauți pe web de exemplu după cuvântul cheie ERP, cantitatea de informații care rezultă poate fi de-a dreptul copleșitoare și de multe ori poate crea chiar confuzie. Fiecare sursă de informație pare a avea definiția ei proprie a unui ERP iar o părere despre ceea ce înseamnă implementarea ERP poate fi diferită de o alta. Toate aceste diferențe denotă însă în cele din urmă cât de puternic este un astfel de sistem informatic – instrument de business.

Pentru a înțelege în detaliu cum poate o soluție ERP să îți transforme afacerea ajută bineînțeles să înțelegi ce este ERP-ul și cum lucrează el. Așadar, o scurtă introducere:

CONCEPTUL DE ERP

ERP este acronimul pentru Enterprise Resource Planning, dar nici măcar numele complet nu clarifica foarte mult ce este ERPul și ce face el. Că să înțelegem, ar trebui să facem un pas înapoi și să ne gândim la toate procesele care sunt esențiale unui business: producția și distribuția, partea financiar contabilă, resursele umane și managementul relației cu clienții. La nivelul lui cel mai de baza, softul ERP integrează toate aceste funcții variate într-un sistem complet conferind stabilitate organizației.

Trăsătura centrală a unui ERP este o bază de date comună care încorporează toate informațiile/funcțiile relevante care circulă într-o companie. În practică, asta înseamnă de exemplu că angajații din diferite departamente (să zicem contabilitate și vânzări) se bazează pe un sistem de informații comun pentru nevoile lor specifice.

Utilizatorii au de asemenea posibilitatea de a-și selecta modulele necesare sau de a adauga la nevoie module noi, de a realiza diverse combinații tocmai pentru a îmbunătăți performanța afacerii. Se întâmplă chiar ca modulele integrate să fie furnizate de furnizori diferiți și să fie implementate pentru a funcționa în cele din urmă ca un tot unitar. Baza de date care este unică dă posibilitatea fiecărui utilizator în parte să adauge informații și să obțină informații dorite în timp real și atunci managementul proceselor unei societăți/firme devine deosebit de facil. Fundația unui sistem ERP o constituie Datele, iar cele care realizează legătura între bazele de date și funcționalitățile deservite sunt Programele aplicației. Un alt element conceptual al sistemelor ERP este cel de „fluxuri de procese”, sau „fluxuri de tranzacții – worflow” care reprezintă modul în care aplicația reflectă procesele sau fluxurile de procese economice într-o arie funcțională.

ERP șterge vechile bariere dintre sistemele informatice individuale ale finanțelor, resurselor umane, producției și depozitului, înlocuindu-le cu un program software unic, unificat, împărțit în module software care aproximează, într-un fel, vechile sisteme individuale. Finanțele, producția și depozitul primesc în continuare propriile pachete software, cu excepția că acum tot software-ul este interconectat astfel încât cineva de la financiar poate accesa sistemul de la depozit pentru a verifica dacă o comandă a fost expediată.

Softul ERP oferă de asemenea un anumit grad de raportare sincronizată și automată. În loc să îți pui angajații să gestioneze baze de date separate și situații care trebuie în mod manual să fie unficate în scopul de a genera rapoarte, unele soluții ERP permit generarea de rapoarte dintr-un singur sistem.

Alegerea unui sistem ERP este un proces extrem de greu și complex. Când implementarea unui sistem ERP este făcută corect el poate revitaliza o organizație prin oferirea unei baze decizionale puternice. Când, dimpotrivă, totul este făcut fără focusare și planificare solidă, proiectul de ERP poate avea repercursiuni negative puternice asupra stabilității unei

organizații. Prin urmare, scopul celui care implementează nu poate fi altul decât să se asigure că fiecare implementare de ERP este un succes.

1.2 SCURTĂ ISTORIE A ERP

Termenul de ERP a fost introdus în anii 1990 de către Gartner1, dar își are rădăcinile în anii 1960 de fapt. Până în anii 1960 afacerile se bazau pe concepte tradiționale de management de inventar, dintre care ReOrder Point (ROP) și Economic Order Quantity (EOQ) erau cele mai cunoscute.

În anul 1960 a apărut pentru prima dată conceptul de MRP (Material Resource Planning) și a cuprins doar un mecanism de calcul în avans al necesarului de material; totodată, MRP făcea recomandări cu privire la eliberarea (sau replanificarea) comenzilor pentru materiale. În timp, conceptul a suferit schimbări și a evoluat în sistemul ERP de azi, precum și în sistemele EERP de mîine.

În anii 1980 Manufacturing Resource Planning (MRP-ÎI) a evoluat că o îmbunătățire a lui MRP prin integrarea altor resurse de producție ale companiei precum sectoarele de desfacere, contabilitate sau managementul distribuției. La începutul anilor 1990 MRP-ÎI a fost extins pentru a acoperi domenii legate de tehnologii, finanțe, resurse umane, management de proiecte, etc. și practic toate activitățile din cadrul unei companii.

În prezent ERP-urile se extind pentru a include și supply chain management (SCM), e-business și managementul relațiilor cu clienții (MRC). Clienții cereau produsele lor cînd, unde și cum doreau ei. Companiile erau obligate să dezvolte și să îmbrățișeze ideea ‘just în time’ și pe cea a unei legături strînse cu clienții, toate acestea privite că o cale de a rămîne competitivi. În zilele noastre, companiile au obligația să găsească cele mai bune căi pentru a furniza produse și servicii de cea mai bună calitate.

Noul acronim ERP a apărut pentru a reflecta faptul că aceste sisteme computerizate au evoluat mult peste sistemele originale ce cuprindeau tranzacții de inventar și sisteme de contabilizare a costurilor.

ERP reprezintă generația actuală de sisteme de planificare a resurselor unei întreprinderi, înlocuind “insulele de informație” (MRP-ÎI) cu o soluție software unică și completă ce integrează toate funcțiile tradiționale ale managementului unei întreprinderi. În cei mai simpli termeni, sistemele ERP utilizează tehnologii de baze de date și o interfață unică menită să controleze toate informațiile legate de activitatea de business a companiei. Împreună cu suportul adus pentru managementul de întreprindere și supply chain, ERP este în mod uzual asociat cu folosirea tehnologiilor client/server (recent utilizând și tehnologia ICA – Internet Computing Architecture) de baze de date relaționale în contextul unor sisteme de operare de rețea puternice precum UNIX, Windows NȚ/2000/XP/Vista, AS/400 sau alte sisteme de operare de tip mainframe.

În anii ’90, ERP-ul era dezvoltat că un monolit strâns integrat, dar cei mai mulți producători de astfel de soft au devenit de atunci mai flexibili, astfel încât acum poți instala numai pachetele care te interesează nu mai trebuie să cumperi toate modulele. Multe companii, de exemplu, vor instala mai întâi modulele de finanțe și resurse umane, lăsându-le pe celelalte pentru mai târziu.

1.3 METODOLOGII DE IMPLEMENTARE A UNEI SOLUȚII ERP

Implementarea unui sistem integrat ERP constituie o decizie strategică a top management-ului unei organizații și ea trebuie să fie bine fundamentată și însoțită de un plan coerent de activități, încadrat cu termene și responsabilități, care să permită o facilă urmărire și evaluare. Ciclul de implementare variază între câteva luni și un an și jumătate (uneori chiar și mai mult) în funcție de complexitatea proiectului, dimensiunea companiei, structura organizațională (sediu unic sau mai multe sedii, internațională sau nu), existența unui sistem anterior, numărul de module alese pentru implementare, interoperabilitatea cu alte sisteme, experiența echipei, tipul și calitatea serviciilor asigurate de furnizorul software sau de integrator.

Managerii înțeleg cu ușurință că abordarea unei soluții ERP este o investiție în creșterea eficienței, dar nu toți realizează schimbarea organizațională pe care o implică această implementare, atât la nivelul top-managementului, cât și al departamentelor vitale ale companiei.

Ca și exemplu, metoda tradițională de implementare, dezvoltată la începutul anilor 80 are următoarele faze:

• Planificare: Project managerii ambelor companii se întâlnesc pentru a formă echipa de proiect și pentru a dezvolta planul de implementare pe baza resurselor avute la dispoziție

• Training: Furnizorul face un training unei echipe de key useri din partea clientului

• Configurare/Design: Echipa furnizorului asista key userii în configurarea proceselor de business în sistemul ERP

• Proiect pilot: Echipa de implementare simulează folosirea sistemului ERP în producție. La sfârșitul acestei faze echipa de implementare a înțeles pe deplin noul sistem și acceptă configurările realizate.

• Cut-over plan: În această etapă echipa de implementare realizează training-ul către restul de utilizatori fiind susținuta de consultanții clientului

• Go-live: Noul sistem ERP intră în producție.Echipa de implementare oferta suport real-time pentru orice probleme care apar în acest proces. Consultanții de implementare sunt de asemenea on site ajutând echipa de implementare în rezolvarea problemelor ce depășesc competența acestora

CÂT DE PROFITABILĂ ESTE O SOLUȚIE ERP

Orice companie care investește într-un nou instrument sau echipament va dori să știe că investiția se va amortiza pentru a justifica cheltuielile. Este in mod clar și cazul unui sistem ERP. Return on Investment (ROI) este un factor important care trebuie luat în calcul la alegerea unei soluții pentru orice proiect tehnologic.

Interesul în implementarea unui nou ERP sau înlocuirea celui vechi începe de obicei cu necesitatea de a adresa unele dificultăți operaționale-probleme în atingerea producției planificate, prea mult inventar, costuri ridicate, incapacitatea de a ține pasul cu concurență, neajunsuri ale actualului sistem, sau uneori numai o dorința generală de a îmbunătăți performanța. Odată ce acest interes este recunoscut, se stabilește o echipa de proiect, un buget, se selectează un sistem și se pun laolaltă cu o justificare ROI.

ERP colectează, administrează pentru a justifica cheltuielile. Este in mod clar și cazul unui sistem ERP. Return on Investment (ROI) este un factor important care trebuie luat în calcul la alegerea unei soluții pentru orice proiect tehnologic.

Interesul în implementarea unui nou ERP sau înlocuirea celui vechi începe de obicei cu necesitatea de a adresa unele dificultăți operaționale-probleme în atingerea producției planificate, prea mult inventar, costuri ridicate, incapacitatea de a ține pasul cu concurență, neajunsuri ale actualului sistem, sau uneori numai o dorința generală de a îmbunătăți performanța. Odată ce acest interes este recunoscut, se stabilește o echipa de proiect, un buget, se selectează un sistem și se pun laolaltă cu o justificare ROI.

ERP colectează, administrează și distribuie informații operaționale pentru cooperarea deplină între producție, materiale, planificare, inginerie, finanțe și vânzări/marketing. Rezultate de calitate superioară, timp redus de lansare a produsului pe piață (time-to-market), timp de execuție scurtat, productivitate mai mare și costuri reduse pot ajuta la îmbunătățirea serviciilor oferite clienților și sporirea vânzărilor și cotei de piață, precum și a profiturilor marginale.

Măsurătorile, analiză și capacitățile de simulare pot ajuta companiile să planifice mai bine și să reacționeze mai rapid și mai eficient la schimbările cererii, acțiunile concurențiale și la întreruperile din lanțul de aprovizionare. Sistemele ERP moderne de azi sunt construite pentru lumea internetului, cu capabilități e-commerce și de integrare și colaborare cu lanțul de aprovizionare al partenerilor, cu portalurile clienților.

Multe companii trebuie să țină pasul cu cerințele în continuă schimbare a proceselor de afaceri bazate pe Internet și se găsesc în situația în care sistemul lor ERP curent nu mai este capabil să țină pasul.

Un software ERP oferă o serie de avantaje pentru gestiunea financiară, putând prezența în orice moment o imagine de ansamblu a companiei, în ceea ce privește situația financiară a trezoreriei, a vânzărilor, a debitorilor și a creditorilor, a contractelor în derulare, etc. Principalele beneficii aduse de automatizarea prelucrării datelor din contabilitatea financiară și de gestiune sunt:

• posibilitatea stabilirii unor reguli de contare automată a documentelor de către persoana autorizată (de ex. directorul economic), ceea ce face muncă personalului din subordine mai rapidă, mai ușoară și mai corectă. Aceste reguli prestabilite nu vor putea fi ulterior modificate decât de către persoana/persoanele autorizate în acest sens;

• crearea unui șablon pentru note contabile, care se preiau ori de câte ori este nevoie;

• nota contabilă va fi generată automat de către aplicație, pe baza regulilor predefinite introduse în sistem;

• gruparea automată a notelor contabile pe tipuri de documente, grupe de documente sau jurnale;

• Registrul – Jurnal poate fi listat pe Jurnale de cumpărări, vânzări, diverse, imobilizari, etc, ori centralizat pe unitate;

• Declarațiile Vamale de Import pot fi culese cu repartizare automată pe elemente de valoare;

• consultarea operativă a soldului referitor la facturile furnizorilor și cele ale clienților;

• raportare concomitentă în două monede (ROL și o altă moneda stabilă – EUR sau USD);

• preluarea automată a datelor în situațiile lunare (declarație TVA, declarație de obligații de plată), precum și în situațiile anuale (bilanț, cont de profit și pierdere, situația fluxurilor de trezorerie, note explicative);

• gestionarea mijloacelor fixe, precum și planificarea amortizării acestora în strânsă legătură cu modulul de contabilitate – generarea automată a notelor contabile aferente operațiilor de imobilizari;

• modulul de salarizare în relație de interconectare cu modulul de contabilitate – crearea automată a notelor contabile de salarii pe baza centralizatorului de salarii;

• documentele care în contabilitatea financiară sunt prelucrate în conturi urmărite și în contabilitatea de gestiune, se pot conta în contabilitatea de gestiune pe baza unor reguli predefinite sau manual;

• repartizarea manuală sau pe baza unor reguli prestabilite a costurilor indirecte;

• consultarea operativă a fișei de postcalcul;

• analiza costurilor utilizând tehnici moderne de detaliere a datelor sintetice.

Investiția într-o soluție ERP/CRM tinde să devină o cerință critică atât pentru controlul și managementul profesional al unei afaceri, cât și pentru ocuparea și menținerea unei poziții privilegiate în piață. Beneficiile obținute prin implementarea unei soluții ERP/CRM sunt de cele mai multe ori intangibile necuantificabile în cifre, dar, cu toate acestea, ușor observabile în evoluția companiei.

Pentru a justifica investiția efectuată într-un sistem ERP trebuie luate în calcul următoarele elemente:

• Eficientizarea întreprinderii;

• Standardizarea proceselor economice;

• Eliminarea insulelor informaționale;

• Modularitate și arhitectură deschisă, care facilitează adoptarea tehnologiilor viitoare.

STUDIU DE CAZ: IMPLEMENTAREA SISTEMULUI INFORMATIC INTEGRAT ORACLE eBUSINESS SUITE LA BUTANGAS ROMÂNIA

2. BUTAN GAS ROMÂNIA

2.1 DESPRE BUTANGAS ROMÂNIA

ButanGas este un grup multinațional care își desfășoară activitatea în 7 țări europene, în domeniul transportului, stocării și distribuției de gaz petrolier lichefiat (GPL). Dezvoltarea permanentă, cu cele mai eficiente instrumente, a transformat Grupul ButanGas într-unul dintre liderii europeni în distribuția de GPL atât pentru uz casnic, cât și pentru uz industrial, pe cele trei canale de distribuție: butelii pentru aragaz, propan mic-vrac și GPL auto.

Încă din 1996, ButanGas România este una dintre cele mai mari companii de distribuție de GPL (Gaz Petrolier Lichefiat) de pe piața românească. Gazul petrolier lichefiat (GPL) este un amestec de hidrocarburi menținute în stare lichidă sub presiune care, în stare gazoasă poate fi utilizat drept combustibil. În particular, în acest document prin GPL se înțelege: butan, propan, autogaz.

În România, ButanGas a fost promotorul omologării distribuției de propan mic-vrac și GPL auto. Astfel, primul rezervor mic-vrac a fost montat de echipa ButanGas în august 1996, cu cel puțin un an înaintea altor concurenți, iar skid-ul pentru GPL auto (sistemul de distribuție a GPL) a fost pus în funcțiune în 1999, în București, fiind singura instalație de alimentare autorizată pentru autovehicule din țară, timp de mai bine de 1 an. ButanGas a introdus pe piața din România, pentru prima oară, recipiente stabile pentru stocarea propanului. ButanGas România deține totodată cel mai mare parc de autocisterne care alimentează rezervoarele consumatorilor din întreagă țară.

Astăzi, ButanGas România S.A. are sediul social în București și își desfășoară activitatea prin intermediul a 5 sucursale (Contești, Constanța, Onești, Oradea, Lugoj), 2 centre de îmbuteliere și distribuție (București, Lugoj), 5 depozite de stocare intermediară (Vaslui, Tg. Mureș, Baia Mare, Buzău, Craiova), 1 terminal maritim GPL (Midia-Năvodari).

*

Câteva cuvinte, despre activitatea specifică BGR, cu trimitere în special la partea de achiziții, întrucât lucrarea de față se focusează pe modulul Furnizori, în cele ce urmează:

Din punct de vedere fiscal, pentru că GPL este un produs energetic accizabil, BGR deține calitatea de antrepozitar autorizat și a obținut autorizații de antrepozit fiscal de producție.

În ce privește achiziția de GPL, aceasta se face de la furnizori interni și de la furnizori externi și se asigură prin :

• încheierea de contracte anuale utilizând formula de calcul

• achiziții tip spot încheiate în baza unor contracte pe perioade scurte, comenzi ferme sau oferte acceptate

• în sistem se introduc cotațiile internaționale pentru fiecare produs la contractarea ofertelor (pentru contracte tip spot) și lunar/periodic (pentru stabilirea prețului pentru contractele cu formulă).

Condițiile de livrare pot diferi de la un furnizor la altul, astfel prețul pentru unii furnizori poate să includă și transportul și taxele de manevrare (acestea pot fi evidențiate sau nu). Este important deci, în contextul acestei lucrări, să se poată urmări, dacă informația este disponibilă, prețul pe cele trei componente (preț/tonă GPL + transport + taxe manevrare).

Exemplu de date importante:

• furnizor (cu date complete)

• tipul de GPL achiziționat (butan, propan, autogaz)

• preț/tonă (fix sau variabil cu formulă)

• termen de plata

• modalități de achiziție (cisterne CF, auto, nave)

• cantități contractate pentru fiecare lună

• penalități

• solicitări suplimentare prin act adițional

• cotațiile folosite că reper de preț pentru contractele cu formulă de calcul

Comenziile de achiziție sunt stabilite periodic de Departamentul tehnic pe baza stocurilor zilnice (în rezervoarele de stocaj și pe roți), cantităților fixe stabilite prin contract și în perspectiva unui stoc de siguranță de minim N zile.

Comenziile se întocmesc de către logisticianul gestiune flux în baza deciziei conducerii sau, conform planului de livrare stabilit cu furnizorii, se trimit furnizorilor spre acceptare după care aceștia lansează ordinul de încărcare.

Transportul GPL-ului achiziționat este realizat în cea mai mare proporție prin CF, vagoane închiriate. Logisticianul de achiziție GPL trebuie să știe în orice moment care este starea fiecărui vagon. Intermediar în relația cu CFR există o casă de expediție cu care există un contract de prestări servicii.

În baza acceptarii comenzilor și intrării vagoanelor CF încărcate la furnizor, logisticianul menține legătură cu furnizorul (compartimentele helpdesk, desfacere, logistică, transport intern) până la confirmarea încărcării și predarea vagoanelor din rafinărie la operatorul de trasport și respectiv la casă de expediții. Logisticianul, după analiza zilnică a situației vagoanelor din parcul BGR, stabilește numărul și tipul vagoanelor CF care urmează a fi trimise spre furnizori în vederea achiziționării produselor conform comenzilor sau planurilor de aprovizionare. De la furnizori, produsele GPL sosesc prin intermediul: navelor, cisternelor CF, cisternelor auto. Fiecare rezervor de stocaj constituie o magazie distinctă. Gestiunea de GPL se ține în kg cu cel puțin 3 zecimale. Intrările și ieșirile din stoc se evidențiază cantitativ și valoric, în ordine cronologică. Descărcarea de gestiune se va realizează pe baza metodei FIFO.

Datorită existenței cântarelor CF și auto, intrările și ieșirile de GPL intermediate de cisterne CF și auto se evidențiază în conformitate cu măsurătorile efectuate de cântare.

Importul de GPL se face prin cisterne auto, prin CF și prin vapor. Tot GPL-ul importat pe vapor trece prin depozitul de la Constanța. Din depozitul de la Constanța Marfă pleacă pe auto (către celelalte sucursale BGR, clienți trading, clienți de P/A) sau pe CF (către celelalte sucursale BGR, clienți trading). La sosirea vagonului, se face recepția mărfii. Cantitatea și calitatea trebuie certificate de către o terță parte (recunoscută de vama) și verificată cu actele de însoțire. Pentru importurile non-UE se face DVI-ul (Declarația Vamală de Import), pe cantitatea din factură. DVI-ul trebuie să fie legat în sistem de factură.

*

La începutul lui 2008, Butangas optează pentru implementarea unui un nou sistem ERP, în urmă unei analize a fluxurilor interne din cadrul companiei; la acel moment compania folosea sistemul informatic integrat SIVAPPS de la Siveco Applications, și alte aplicații secundare (ex: Access). Lucrarea de față face o analiză a identificării soluției Oracle EBS, a proiectării și derulării planului de implementare și își propune să atingă în detaliu mai mare modulul Accounts Payables, pentru exemplificări mai concrete.

2.2 FLUXUL DE LUCRU SPECIFIC BUTANGAS AFERENT MODULULUI AP

Abrevieri utilizate :

În cadrul acestui document s-au utilizat următoarele abrevieri:

• AP- Account Payables (modulul Contabilitate Furnizori)

• GL- General Ledger (modulul Cartea Mare)

• TVA- Taxa pe Valoare Adăugată

• BGR- ButanGas România

• NIR-Notă de intrare recepție

• DVI Declarație vamală de import

• CFP- Control Financiar Preventiv

• USD- Moneda dolar american

• EUR- Moneda euro

• GPL – Gaz petrolier lichefiat

Urmează o descriere sumară a Contabilității Financiare a Furnizorilor, în urmă analizei sistemului existent la data demarării proiectului de implementare:

Considerații generale

În aria funcțională AP – Contabilitatea furnizorilor – se includ primirea de facturi de la furnizorii ButanGas România, gestionarea datelor legate de furnizorii și creditorii existenți, gestionarea avansurilor de trezorerie acordate salariaților și plata sumelor către furnizori/ creditori.

Funcțiunile incluse în această arie sunt următoarele:

AP.01 Contabilitate facturi primite în lei

AP.01.001 Facturi de servicii

AP.01.002 Facturi de materiale

AP.01.002.01 Facturi achiziții GPL

AP.01.002.02 Facturi achiziții non-GPL

AP.01.003 Facturi de mijloace fixe

AP.01.004 Facturi nesosite

AP.01.005 Verificare situație facturi cu furnizorii

AP.02 Contabilitate facturi primite în valută

AP.02.001 Facturi primite în valută

AP.03 Contabilitatea deconturilor în lei

AP.03.001 Deconturi deplasări în lei

AP.03.001.01 Acordare avans deplasare în lei

AP.03.001.02 Justificare avans/decont deplasare în lei

AP.03.002 Deconturi achiziții în lei

AP.03.002.01 Acordare avans achiziții în lei

AP.03.002.02 Justificare avans/deccont achiziții în lei

AP.04 Contabilitatea deconturilor în valută

AP.04.001 Deconturi deplasări în valută

AP.04.001.01 Acordare avans deplasare în valută

AP.04.001.02 Justificare avans/decont deplasare în valută

AP.05 Contabilitate plăți în lei

AP.05.001 Plăți facturi

AP.05.001.01 Plăți facturi prin banca

AP.05.001.02 Plăți facturi prin casă

AP.05.002 Plăți diverse

AP.05.002.01 Plăți diverse prin banca

AP.05.002.02 Plăți diverse prin casă

AP.06 Contabilitate plăți în valută

AP.06.001 Plăți facturi prin banca

AP.06.002 Plăți diverse

AP.06.002.01 Plăți diverse prin banca

AP.06.002.02 Plăți diverse prin casă

AP.07 Contabilitate compensări

AP.07.001 Contabilitate compensări

AP.07.001.01 Compensări prin efecte de plată

AP.07.001.02 Compensări furnizor/client

Clasificare furnizori

În urmă analizei efectuate a rezultat următoarea clasificare pentru furnizori și creditori:

Furnizori interni

Furnizori de servicii

Furnizori de materiale

Furnizori de mijloace fixe

Furnizori externi

Furnizori de servicii

Furnizori de materiale

Furnizori de mijloace fixe

Furnizori din avansuri de trezorerie:

Avansuri de deplasare

Avansuri pentru achiziții de materiale

Alți creditori

Exemplu de analiză în acest document, în cadrul:

AP.01 – CONTABILITATE FACTURI PRIMITE ÎN LEI

AP.05 – CONTABILITATE PLĂȚI ÎN LEI

(fluxul general și descrierea pașilor de process pentru plăți se pot consulta în Anexe)

Funcțiuni:

AP.01.002.01 – Facturi achiziții GPL

AP.05.001.01 – Plăți facturi prin bancă

În cadrul funcțiunii “Contabilitatea facturilor primite în lei” s-au discutat următoarele tipuri de facturi:

o Facturi de servicii

o Facturi de materiale

o Facturi de investiții

Fluxul general aferent funcțiunii AP.01.002.01 Facturi achiziții GPL

Descrierea pașilor de proces pentru funcțiunea AP.01.002.01 Facturi achiziții

Notă:

1. Fluxul se aplică pentru toate tipurile de GPL achiziționate (butan, propan, autogaz).

Alte aspecte:

a. Furnizorii emit facturi pe fiecare tip de produs în parte (butan, propan, autogaz).

b. Facturile se primesc la sediul central iar destinațiile de livrare pot fi oricare dintre sucursalele Butangas.

c. Facturile se primesc la un interval de X zile pe parcursul lunii; aceastea pot fi mai multe pentru aceeași comandă, factura va avea atașată nota de greutate pentru fiecare vagon CF în parte.

d. Se evidențiază legătura între facturile primite și NIR-urile aferente în sistem.

e. În cazul în care furnizorul este antrepozit fiscal, facturile primite de către Butangas nu au TVA și nu se plătește acciza.

f. În cazul în care furnizorul nu este antrepozit fiscal, facturile primite au TVA și acciza; plata accizei se face la Trezorerie în avans, înainte că furnizorul să livreze marfă.

g. Costurile de transport menționate pe facturi intră în costul produsului achiziționat. În același mod se tratează costurile cu taxele de transvazare (throughput), chiriile cisternelor CF, etc

h. În cazul în care costurile de transport sunt menționate pe o factură separată (scrisori de trăsură), înregistrarea contabilă este 371=401 (607=371 se înregistrează la consum); în funcție de vânzările lunii respective se vor trece pe cheltuiala – pe filială și produs.

i. În cazul în care există marfă nerecepționată dar pentru care s-a primit factură, înregistrarea contabila este:

% = 401

408 – pentru marfă recepționată

357 – pentru marfă nerecepționată

TVA când este cazul

La recepția mărfii se înregistrează contabil 371=357.

Toate celelalte funcțiuni au fost analizate în mod similar, pentru fiecare în parte s-a elaborat o diagramă de flux general și s-au descris pașii de proces. La finalul analizei s-au constatat și alte aspecte legate de contabilitatea facturilor primite, ca de exemplu:

• Se pot primi facturi de la furnizori la sediul central, plățile făcându-se la sucursale, respectiv se pot primi facturi la sucursale, plățile fiind făcute la sediul central. Contabilizarea acestora se face:

512=481 / 482 respectiv 481/482=512

481/ 482 =411 respectiv 401=481/482

• Facturi de reparații (service) – conțin atât informații referitoare la materiale cât și la serviciile prestate de terți dar valoarea totală se înregistrează doar în conturi de cheltuială.

• Stornarea facturilor primite se înregistrează „în roșu” (aceeași înregistrare cu semn schimbat). Stornarea anulează efectul facturilor introduse greșit sau emise greșit de către furnizor. Nu se utilizează stornări parțiale.

• Există analitice diferite ale conturilor 401 și 404 pentru furnizori interni și externi.

• Tipuri de creditori diverși și înregistrări contabile aferente

o Creditori diverși

461-512/531

o Creditori ambalaje/rez

462-512/531

Precum și documentele implicate:

Ordin de deplasare; Referat; Dispoziție de plata; Dispoziție de încasare; Bon fiscal; Facturi primite și facturi emise (pentru compensări); Documente de plată: Ordin de plata, CEC, Bilet la ordin, Ordin de compensare, Dispoziție de plată; Cerere concediu de odihnă, cerere tip, Foaie de livrare; Ștat de plată salarii; Polița de asigurare; Proces verbal de amendă.

3. PROIECTAREA SOLUȚIEI

3.1 VIZIUNE DE ANSAMBLU

Propunerea furnizorului ERP pentru implementarea Sistemului Informatic Integrat se bazeaz pe Oracle E-Business Suite – produs complet integrat, dezvoltat pe o platforma “Web based”, o suită completă de aplicații pentru întreprinderi, ușor de modelat și pe domeniul de activitate ButanGas. Ciclul industrial “Petrol și Gaz” în viziunea Oracle mai jos:

În prima fază a proiectului se propune implementarea următoarelor componente ale Sistemului Informatic:

1. Sistemul Financiar-Contabilitate

2. Sistemul de Comercial

3. Sistemul de Producție

4. Sistemul de Bugete

5. Sistemul de indicatori economico – financiari

6. Interfețe existente cu sistemul de cântare auto și CF, Multicash și notele

contabile furnizate de firma TotalSoft

7. Oracle Database Enterprise Edition

8. Oracle Internet Applications Server Enterprise Edition

9. Oracle Internet Developer Suite

În fazele ulterioare ale proiectului, Sistemul Informatic Integrat urmează a se completa cu Sistemul de Mentenanță și Sistemul de Investiții și cu noi module, astfel încât să fie asigurată din acest moment unitatea și completitudinea soluției.

În figura de mai jos, viziunea de ansamblu asupra Sistemului Informatic Integrat al BUTANGAS.

Sistemul Financiar-Contabil – cuprinde Contabilitatea Generală, raportările legale și raportările către management, Registrul de Vânzări și Registrul de Cumpărări, Registrele de Mijloace Fixe și Gestiunea Lichidităților. Sistemul trebuie să fie accesibil din toate locațiile unde există activități de contabilitate (generare de note contabile), care au responsabilități legate de gestiunea mijloacelor fixe, activități de facturare – încasare sau facturi furnizori – plăti. Pentru implementarea acestui sistem s-a propus pachetul Oracle Financials, care cuprinde următoarele module:

• Oracle General Ledger (GL) – Contabilitate Generală;

• Oracle Payables (AP) – Contabilitate Furnizori; – pe care se focusează acesta lucrare

• Oracle Receivables (AR) – Contabilitate Clienți;

• Oracle Cash Management (CM) – Gestiunea Lichidităților;

• Oracle Assets (FA) – Mijloace Fixe.

Oracle Account Payables (Modulul Furnizori) permite înregistrarea facturilor primite, managementul plăților către furnizori, managementul furnizorilor, înregistrarea deconturilor de cheltuieli precum și o serie de rapoarte standard care vin în sprijinul unei bune gestionări a furnizorilor.Aplicația permite inregistrarea facturilor manuale, cât și a facturilor împerecheate cu recepția și comanda de aprovizionare aferente, liniile facturii moștenind astfel informațiile preluate din Oracle Purchasing și Oracle Inventory.

Implementarea Oracle Payables permite minimizarea costurilor, controlul cash flowlui, minimizarea erorilor și eliminarea ineficienței utilizând instrumente specializate de plată a facturilor. Se elimina astfel posibilitatea fraudei, posibilitatea înregistrărilor duble sau a plăților neautorizate, prin reguli de securitate și aprobare la nivel de factură.

Notele contabile provenite din înregistrarea facturilor primite și a plăților se exportă automat prin rularea unui proces în modulul General Ledger (Contabilitate generală). Oracle Payables suportă totodată MRC (Multiple Reporting Currencies), permițând translatarea tranzacțiilor într-o moneda de raportare.

3.2 ABORDAREA PROIECTULUI

Pentru acoperirea cerințelor Butangas, aferente activităților specifice financiar contabile vor fi utilizate modulele din cadrul pachetului Oracle Financials. De asemenea, înregistrările contabile aferente vor fi generate automat în cadrul modulelor specifice (prezentate pentru fiecare arie de business) și vor fi preluate automat în modulul de Contabilitate Generală.

Sistemul permite configurarea structurii organizaționale, astfel încît să poată fi obținute raportările solicitate la nivel de societate, sucursală și puncte de lucru. Modul de implementare a structurii organizaționale va fi stabilit în faza de Elaborare a proiectului. Sistemul va fi configurat astfel încât să genereze contări automate (care să nu solicite operare de mâna din partea utilizatorilor) pentru toate tranzacțiile și documentele introduse, indiferent de categoria documentului, de modulul accesat sau de tipul tranzacției (unitate-subunitate, subunitate-subunitate, etc)

Utilizînd funcționalitatea standard a sistemului, vor fi introduse facturile primite, atît aferente comenzilor / contractelor de achiziții, cît și facturi primite diverse.

În faza 1 de implementare a sistemului, vor fi implementate și codurile de buget; Viza de bun de plata va putea fi evidențiată în sistem.

Facturile primite vor fi împerecheate atât cu contractul / comanda cît și cu recepția bunurilor în modulele de stocuri, obiecte de inventar și de mijloace fixe. Avansurile spre decontare vor fi gestionate utilizînd funcționalitățile standard ale sistemului. De asemenea, în sistem vor fi gestionate deconturile salariaților și stingerea de avansuri.

Modulul de furnizori permite gestionarea atât a facturilor de avans cât și a avansurilor fără factură. Încasările și plățile aferente facturilor vor fi gestionate în sistem utilizînd funcționalitățile standard specifice. Împerecherea documentelor de încasare / plata cu extrasele de cont se va realiza în cadrul modulului Gestiune Lichidități. Extrasele de cont vor fi preluate automat, utilizînd interfața cu sistemul Multicash existent. Aferent facturilor primite / emise sunt gestionate în sistem termenele de plata / încasare, existînd posibilitatea urmăririi obligațiilor scadente.

De asemenea, sistemul permite gestiunea încasărilor prin casierie, reevaluare pentru documentele în valută (extrase, clienți, furnizori, registru casă etc.) Dacă rezultă venituri sau cheltuieli, acestea trebuie să se reflecte în buget. Efectele comerciale vor fi configurate în sistem, utilizînd funcționalitățile standard ale acestuia, inclusiv evidența efectelor comerciale girate și tipărirea automată a borderoului de depunere.

3.2.1 MIGRAREA DATELOR INIȚIALE

Nu se vor prelua date istorice, ci numai solduri la data intrării în producție. Preluarea datelor, cu excepția cazului unde Oracle Applications posedă interfață, se va face cu încărcătoare care simulează încărcarea manuală (NCĂ, DLD).

Responsabilitatea pregătirii acestor date din punctul de vedere al coerenței, completitudinii și corectitudinii aparține echipei BUTANGAS. Preluarea acestor date în noul sistem (manual sau prin alte mijloace) este responsabilitatea BUTANGAS și se va realiza sub îndrumarea tehnică a consultanților Oracle, în faza de tranziție a proiectului.

Următoarele date privind liste de valori, tranzacții deschise și valori la data de deschidere ce vor fi convertite inițial prin interfețe standard (sunt prezentate cele identificate în urma discuțiilor avute; pe lângă acestea pot apărea și alte cerințe de migrare care vor fi identificate în faza de analiză):

GL

• Conturi, centre de cost (alte elemente ce vor compune segmentul contabil);

• Rate de schimb istorice (cursuri de schimb istorice acolo unde este cazul) ;

AP

• Facturi rămase în sold la data de deschidere;

• Încărcare date furnizori(furnizori,colaboratori și angajați pentru deconturi de cheltuieli) cu facturi în sold la dată de deschidere;

• Avansuri acordate

PO

• Contracte comenzi de aprovizionare deschise;

Datele vor fi introduse în interfețe (tabele) standard (există cel puțin 1 sau 2 interfețe pentru fiecare modul al aplicației) definite, după care la rularea unor rapoarte de validare în cadrul aplicației acestea vor fi mapate pe structura de tabele corespunzătoare. În cazul în care nu există o interfață standard definită se pot introduce datele folosind Data Loader direct în formele aplicației.

Prin contul de support oferit de Oracle cu acces către My Oracle Support se poate vizualiza structura detaliată a tabelelor de interfață precum și explicații asupra datelor necesare ce trebuiesc

introduse și legături între tabele în cazul în care este o interfață complexă compusă din mai multe tabele. Pe lângă câmpurile standard oferite de sistem, interfața mai pune la dispoziție mai multe coloane denumite „atribute” în care se pot introduce informații adiționale în cazul în care structura interfeței nu acoperă în totalitate cerințele de date cerute (orice interfață are de la 15-30 de atribute).

Programe folosite

În procesul conversiei de date vor fi folosite următoarele instrumente:

• Oracle SQL Loader – unul dintre cele mai puternice instrumente de import al datelor, recunoscut pentru viteza de import al datelor din fișiere de tip csv (comma separated file) și tsv (tab separated file);

• Oraexcel – instrument ce poate fi folosit cu ușurință, nu necesită cunoștințe de programare, pentru intoducerea datelor din fișiere excel în tabele din baza de date Oracle;

• Data Load Classic – instrument ce poate fi folosit (nu necesită cunoștințe de programare) pentru introducerea datelor direct în formele aplicației Oracle E-Business Suite. Datele vor fi aranjate într-un excel după care se va face copy/paște într-un fișier dld, la rulare acesta va introduce datele în forma specificată de utilizator.

3.2.2 METODOLOGIA DE IMPLEMENTARE

Pentru acest proiect se folosesc Metodele de Implementare a Aplicațiilor (Application Implementation Method – AIM). AIM este o metodologie de implementare a aplicațiilor Oracle utilizată cu succes la mii de implementări. Acest proiect este orientat pe Business Flows, modalitatea de abordare va include mai multe CRP-uri (Customer Rooms Pilots) – această reprezintă abordare iterativă.

Caracteristicile cheie ale metodologiei includ:

• Realizarea rapidă a unei aplicații configurate pentru a furniza BUTANGAS un acces rapid la o instanță funcțională pentru familiarizare și pentru realizarea maparii.

• Utilizarea Oracle’s Business Flows standard ca punct de pornire pentru definirea viitorului proces de business al BUTANGAS. Aceasta evita o examinare a business-ului curent cu costuri ridicate și consumatoare de timp, care pot fi sau nu suportate de Oracle Business Suite.

• Concluzionarea fiecărui CRP iterativ, pentru a vedea evoluția sistemului pe parcurul duratei de viață a proiectului, către sistemul care acoperă cel mai bine cerințele BUTANGAS; Se pornește de la premiza că BUTANGAS dorește să adopte standardele procesului de business și al functionalitatiilor Oracle E-Business Suite pentru a-și conduce procesele de business. Orice alte cerință apărută va fi gestionată conform procedurii de control al schimbărilor. Conceptele importante utilizate în abordarea de față sunt:

• Conference Room Pilot (CRP)

• Testarea iterativă și revizuirea ciclurilor de verificare (CRP)

Conference Room Pilot (CRP) presupune executarea de teste pentru verificarea validității setup-ului aplicației, integrarea business flow-urilor în sistemul aplicației țintă, validarea datelor convertite și adaptarea documentației ce conține procedurile pentru utilizatorul final..

Primele 3 etape ale AIM pentru metodologia de Business Flow includ evoluțiile Conference Room Pilot (CRP). În Etapele de Elaborare și Construire un grup similar de operațiuni sunt executate pentru a actualiza livrabilele cheie cu schimbările survenite, pregătirea noii instanțe de lucru, conducerea unui CRP și identificarea oricăror noi excepții sau modificări necesare. Managerul de proiect poate decide repetarea unui grup de operațiuni într-o anumită fază, bazându-se pe specificul proiectului și/sau pe rezultatul primei iterații de CRP.

Cele mai multe, sau chiar toate aceste schimbări trebuie să indentificate în concluziile CRP 2.0. Schimbările care necesită extensii customizate sunt deobicei create și testate în Etapa de Construire și introduse în mediul CRP 3.0 cu scopul Testării Sistemului de Business (Business System Testing).

Etapa de Definire

Are următoarele obiective:

• Atingerea unui conses privind direcția, scopul, obiectivele și abordarea proiectului.

• Familiarizarea utilizatorilor cheie cu Business Flow-urile.

• Realizarea maparii inițiale a Business Flow-urilor la procesele de business.

• Strângerea cerințelor necesare pentru susținerea necesităților funcționale și informaționale ale sistemului.

• Obținerea acceptării manageriale pentru a trece la etapa următoare.

Plan de Proiect

Pentru o implementare cu succes sunt esențiale definirea temeinică a strategiilor, obiectivelor, modalității de abordare, scopului și controlului. Planul de Proiect (PMP) descrie cum se va desfășura proiectul în funcție de scopul definit precum și cum se pot atinge obiectivele stabilite utilizând modalitățile de abordare stabilite. PMP-ul va fi creat chiar la începutul proiectului pentru a asigna întreaga echipă de proiect pe obiective și task-uri de proiect comune.

Planul va acoperi următoarele puncte și se vor aplică întregii echipe de implementare și BUTANGAS.

• Obiective

• Abordare

• Activitățile Proiectului, Livrabile și etape de verificare

• Control și Raportare

• Managementul Activităților

• Managementul Resurselor

• Managementul Calității

• Managementul Configurării

Desfășurarea CRP 1.2 (Procesele Viitoare)

Se va folosi Business Models (OBM) ca punct de pornire, consultanții vor lucra cu utilizatorii cheie pentru a construi modelele proceselor viitoare ale BUTANGAS folosind standardele funcționale ale Oracle.

Etapa de Elaborare

Obiectivele Etapei de Elaborare sunt:

• Validarea Structurii Organizației și a Planului de conturi

• Analizarea nevoilor de învățare a utilizatorilor și dezvoltarea Planului de User Learning

• Desfășurarea CRP 2.0 pentru a rafinarea soluției

• Dezvoltarea design-ului funcțional și tehnic pentru customizările extensiilor, interfețelor și customizarile bazelor de date.

• Dezvoltarea scripturilor de testare

Desfășurarea CRP 2.0

Aplicațiile Oracle vor fi configurate pe baza modelului Proceselor Viitoare. Integratorul va furniza planurile de test pe care utilizatorii cheie le vor folosi pentru a pregăti scenarii de test specifice pentru fiecare proces de business. Consultanții vor conduce Conference Room Pilot (CRP) pentru testarea activității.

Livrabilul pentru această etapă va fi o aplicație configurată care poate susține procesele și cazurile de business identificate. Acesta activitate se va concluziona cu o sesiune de prezentare a rezultatelor testării de către utilizatorii cheie. La sfârșitul acestei activități, utilizatorii cheie vor finaliza Procesul Viitor pentru BUTANGAS. Integratorul va începe pregătirea ghidului pentru utilizatorul final și procedurile de operare folosind de preferat Oracle Tutor, care este legat la OBM. Utilizatorii cheie vor asista Oracle la crearea documentelor, prin reexaminarea și comentarea aceastora pentru actualizarea lor ulterior.

Etapa de Construcție

Obiectivele Etapei de Construcție sunt:

• Pregătirea instanței de dezvoltare (Development Environment)

• Dezvoltarea, testarea și acceptarea extensiilor customizate, a conversiilor de date și integrării subsistemelor.

• Propunerea unei strategii de tranziție de la sistemul curent, manual sau automat, către noul sistem.

• Crearea, testarea și acceptarea extensiilor de baze de date și a rutinelor de instalare.

• Finalizarea soluției pentru pregătirea tranziției la Etapa de producție.

• Utilizatorii cheie ar trebui – că rezultat al creșterii deprinderilor pe parcursul etapelor anterioare – să fie apți să efectueze cel puțin 70% din setup-ul modulului/fluxului lor până la sfârșitul CRP 3.0

• Desfășurarea CRP 3.0 va avea ca obiectiv validarea extensiilor customizate și introducerea manuală de date existente.

Desfășurarea CRP 3.0

BUTANGAS va conduce această activitate. CRP 3.0 include testarea interfetelor, conversia datelor, aducerea de îmbunătățiri și raportarea, utilizând date reale din sistemele existente.

La sfârșitul acestei etape, integratorul, asistat de utilizatorii cheie ai BUTANGAS vor revizui Manualul Utilizatorului și procedurile operaționale.

Etapa de Tranziție

Obiectivele Etapei de Tranziție sunt:

• Pregătirea instanței de producție și configurarea aplicației.

• Instalarea programelor de conversie a datelor , convertirea și verificarea datelor din sistemele existente.

• Executarea unui test de acceptanță.

• Instruirea utilizatorilor cheie care vor face train the trainer

• Verificarea tuturor aspectelor sistemului pentru a vedea dacă acestea sunt pregătite pentru tranziție.

• Începerea utilizării Sistemului de Producție.

Desfășurarea Testului de Acceptanță a Utilizatorului (UAT – User Acceptance Testing)

BUTANGAS va conduce această activitate. În desfășurarea sa, UAT va acoperi toate procesele de business. UAT va utiliza un subset de date reale convertite din sistemul existent al BUTANGAS sau create special pentru test.

La sfârșitul acestei etape, utilizatorii cheie pot face revizuiri la manualul utilizatorului și la procedurile operaționale. Acesta este testul final înainte de trecerea la producție.

Etapa de Producție

Obiectivele Etapei de Producție sunt următoarele:

• Stabilirea și agrearea criteriilor de prioritizare a potențialelor probleme ce pot apărea în faza de producție

• Măsurarea performanțelor sistemului și îmbunătățirea acestuia dacă este necesar.

• Renunțarea la sistemelor existente , dacă este cazul .

• Îmbunătățirea cunoștințelor organizaționale și a deprinderilor pentru noul sistem.

• Acordarea unei atenții sporite aspectelor post-producție că acceptanța, productivitatea și susținerea performanțelor utilizatorilor.

Monitorizarea stării proiectului

Următoarele entități vor funcționa cu scopul de a asigura monitorizarea și controlul proiectului în timpul ciclului de viață al acestuia.

• Comitetul de coordonare

• Echipa de proiect

• Coordonatorii de proiect

Instalare software aplicații

Serviciile de instalare software vor constă în instalarea standard a sistemului Oracle E Business Suite, care conține:

• instalare baza de date enterprise edition

• instalare server de aplicații enterprise edition

• instalare Oracle Applications

Se va realiza o instalare la momentul inițializarii proiectului pentru mașina/ mediul de test, iar în etapa de tranziție se va realiza o instalare pe mașină/mediul de producție. Instalările sunt activități complexe, fiecare instalare poate dura între 5-10 zile funcție de context și necesită implicarea (doar pentru asistență) a unui resurse IT ButanGas.

Serviciile de instalare vor cuprinde următoarele elemente:

• Instalare software

• Configurare

• Creare proceduri de back up

• Testare

• Refacerea mediului după un incident folosind procedurile de back-up

• Documentare instalare/configurare/backup/refacere mediu după incident pentru cele 3 componente ale Oracle eBusiness Suite

Servicii de instruire

În faza de analiză se vor realiza cursuri pentru echipa de implementare cu materiale de curs:

cursuri tehnice pentru personalul IT

cursuri administratori baza de date

cursuri administrare aplicații

cursuri pentru utilizatorii funcționali

cursurile utilizatori funcționali (utilizatori cheie) vor include detalii tehnice (setup-ul modulelor) care au condus la Sistemul Informatic Integrat – BUTANGAS, și vor include: concepte generale, fluxuri de business, maparea fluxurilor pe cerințe, detaliere proiectare sistem, lista funcțiilor și procelor pentru fiecare arie funcțională.

În faza de tranziție se vor realiza cursuri pentru echipa de utilizatori cheie care vor realiza instruirea cu utilizatorii finali în regim de train the trainer.

Tot în faza de tranziție se vor realiza și cursurile de instruire pentru manageri se vor face de către echipa de implementare și vor include utilizarea Sistemului Informatic Integrat și schimbările ce vor apărea în societate odată cu implementarea noului sitem.

Asistență tehnică post-implementare/Serviciul de Help Desk

Asistența tehnică post implementare va fi asigurată, după acceptanța finală a sistemului. Asistență tehnică va avea că obiective asigurarea suportului pentru utilizatorii sistemului și nu va consta în modificarea functionalitatilor implementate sau implementarea de noi funcționalități ale sistemului. Nu există limitare a numărului de incidente care pot fi semnalate în această perioada.

Prin intermediul serviciului de Help desk, furnizorul ERP va asigura asistență tehnică on- line utilizatorilor sistemului. Serviciul de Helpdesk poate fi asigurat la sediul BUTANGAS sau la sediul furnizorului. În cel de al doilea caz, BUTANGAS va asigura accesul de la distanță la sistem, prin intermediul VPN, pentru consultanții care oferă suport utilizatorilor sistemului.

BIBLIOGRAFIE

www.comunitateaerp.ro

www.oracle.com

https://blogs.oracle.com/

Oracle Documentation: Oracle Payables User Guide (version 11.5.10.2)

http://www.trainingclasses.com/programs/00/74/7447_oracle_11i__procure_to_pay_part_2.php

http://www.charisma.ro/solutii-sisteme-erp-implementare-erp/

ERP, Making it happen. Wallace, Kremzar

http://butangas.ro/

BIBLIOGRAFIE

www.comunitateaerp.ro

www.oracle.com

https://blogs.oracle.com/

Oracle Documentation: Oracle Payables User Guide (version 11.5.10.2)

http://www.trainingclasses.com/programs/00/74/7447_oracle_11i__procure_to_pay_part_2.php

http://www.charisma.ro/solutii-sisteme-erp-implementare-erp/

ERP, Making it happen. Wallace, Kremzar

http://butangas.ro/

Similar Posts

  • Securitate Multinivel Pentru Baze de Date

    Lista figurilor Lista tabelelor Lista acronimelor Introducere Am ales să realizez lucrarea de licență cu titlul „Securitate multinivel pentru baze de date” deoarece consider că domeniul securității este unul foarte vast și cu multe implicații în viața reală. Asigurarea unei baze de date e foarte importantă pentru că datele memorate sunt esențiale în desfășurarea unei…

  • Baze de Date Multimedia Orientata pe Aplicatie Imobiliara

    Capitolul I Introducere Lucrarea își propune ca obiectiv dezvoltarea unei aplicații software pentru agențiile imobiliare, având la bază un sistem de baze de date multimedia. Aplicația va trebui să soluționeze problemele cu care se confruntă cel mai des o agenție imobiliară, probleme ce sunt consumatoare de timp și care pot fi automatizate. În orașele mari,…

  • Probleme DE Repartitie In Grafuri Bipartite

    I.Elemente de teoria grafurilor I.1. Grafuri neorientate……………………………………………………………..3 I.1.1. Noțiuni teoretice……………………………………………3 I.2. Grafuri orientate……………………………………………………………….15 I.2.1. Noțiuni teoretice………………………………………….15 II. Fluxuri în rețele de transport II.1. Flux maxim/minim în rețele de transport……………………………23 II.2. Algoritmul Ford-Fulkerson……………………………………………….31 II.3. Algoritmul Edmonds-Karp……………………………………………….42 II.4. Algoritmul Dinic……………………………………………………………..47 III. Cuplaj maxim în grafuri bipartite…………………………………………………53 IV. Problema clasică de transport………………………………………………………64 Aplicație………………………………………………………………….80 Bibliografie…………………………………………………………………………………….83 === PROBLEME DE REPARTITIE…

  • Teoriile Competitivitatii

    CAPITOLUL I. ASPECTE TEORETICE PRIVIND CONȚINUTUL ȘI EVALUAREA COMPETITIVITĂȚII Competitivitatea economică – concept, tipuri, trăsături CAPITOLUL II. TEORIILE COMPETITIVITĂȚII Teoria avantajelor comparative (teoria lui D.Ricardo) 2.2. Teoria competitivității mondiale a țărilor (teoria IMD) 2.3. Teoria determinantelor avantajelor concurențiale a țărilor (teoria lui Michael Porter) 2.3.1. Premisele elaborării teoriei lui Michael Porter 2.3.2. Determinantele avantajului concurențial…

  • Facilitatile Bazelor de Date ale Sistemului Oracle

    FACILITĂȚILE BAZELOR DE DATE ALE SISTEMULUI ORACLE Oracle Database este un sistem de gestiune a bazelor de date,este complet relațional, este extins, și nu în ultimul rând conține numeroase facilități din tehnologia orientată pe obiecte. Oracle este creația firmei Oracle Corporation – înființată în anul 1977 în SUA (California) și acum reprezintă cel mai vast…