Aplicatii Informatice Comerciale

LUCRARE DE DISERTAȚIE

APLICAȚII INFORMATICE COMERCIALE

Cuprins

1. INTRODUCERE

1.1. APLICAȚIA INFORMATICĂ – DEFINIȚIE

1.2. EVOLUȚIA INTEGRĂRII APLICAȚIILOR INFORMATICE

1.3. DEFINIȚIA ȘI ROLUL SISTEMELOR INFORMATICE INTEGRATE

1.3.1. Zona Back Office

1.3.2. Zona Front Office

1.3.3. Zona Middle Office

1.3.4. Zona Web Office

2. PROBLEMELE INTEGRĂRII APLICAȚIILOR INFORMATICE

2.1. Probleme tehnice

2.2. Probleme informaționale

3. INFRASTRUCTURA DE INTEGRARE A APLICAȚIILOR INFORMATICE

3.1. Definirea scopului integrării

3.2. Definirea strategiei de integrare

4. EVOLUȚIA APLICAȚIILOR INTEGRATE DE GESTIUNE A FIRMELOR

4.1. Schema conceptuală a unui sistem ERP

4.2. Reprezentarea simplificată a unui sistem ERP

4.3. Arhitectura cu trei niveluri a unui sistem ERP

4.4. Componentele principale ale unui sistem ERP

4.5. Implementarea unui sistem ERP

4.6. Modelarea deciziei de selecție

4.7. Configurația unei echipe ERP

5. AVANTAJELE UTILIZĂRII UNUI SISTEM ERP

5.1. Integrarea informațiilor financiare

5.2. Integrarea informațiilor corespunzătoare comenzii clientului

5.3. Standardizarea și eficientizarea procesului de producție

5.4. Reducerea inventarului

5.5. Standardizarea informațiilor din Departamentul de resurse umane

5.6. Factorii de risc

6. STUDIU DE CAZ

6.1. APLICAȚIA WEB KOLLECTO

6.1.1. Logarea utilizatorilor în sistem

6.1.2. Schimbare parolă

6.2. MENIUL HOME

6.3. MENIUL INFO CLIENT

6.4. MENIUL CĂUTARE

6.5. PROCEDURA DE LUCRU A CAZURILOR IN WEB KOLLECTO

6.5.1. Ierarhia Web Kollecto

6.5.2. Fereastra Detalii Caz

6.6. ZONA STATICĂ

6.6.1. Operații în secțiunea superioară a zonei statice

6.6.2. Adăugarea unui comentariu

6.6.3. Crearea unui angajament de plată (PA)

6.6.4. Crearea unei acțiuni recurente

6.6.5. Secțiunea Cozi

6.6.6. Tabul Comentarii

6.6.7. Tabul Strategie

6.6.8. Secțiunea PA

6.7. ZONA DINAMICĂ

6.7.1. Nivelul Collection Entity

6.7.2. Nivelul Account

6.7.3. Nivelul Persoană

6.8. MENIUL COZI

6.9. MENIUL SCRISORI

6.10. MENIUL RAPOARTE

6.11. MENIUL CERERI

6.12. MENIUL OPȚIUNI

CONCLUZII

WEBGRAFIE

1. INTRODUCERE

Apariția și dezvoltarea calculatoarelor electronice a reprezentat o adevărată revoluție în societatea umană, având ca principală consecință tranziția de la societatea industrială la societatea informațională. Calculatorul a devenit o componentă normală a activității noastre zilnice, iar tehnologia comunicațiilor și posibilitățile oferite de Internet au produs transformări în întreaga societate, pătrunzând în toate aspectele vieții economice, sociale și culturale. Datorită potențialului mare de eficientizare a muncii, calculatorul a fost introdus pe scară largă în toate domeniile activității productive, începând de la munca de birou și până la activitățile din halele de producție.

Astfel, calculatorul a devenit o componentă indispensabilă în cele mai multe dintre domeniile în care oamenii activează, printre care se pot enumera:

Activități productive: birotică, logistică, administrarea depozitelor, aprovizionare, producție, planificare, activități de creație, circulația banilor, comerț electronic, dispozitive comandate de calculator;

Munca de birou: întocmirea corespondenței, întocmirea formularelor de lucru, întocmirea prezentărilor, contabilitatea, calculul costurilor, statistica și verificarea, administrarea clienților, adreselor, urmărirea termenelor;

Educație și informare: programe de învățare, e-learning, programe de prezentare, enciclopedii (pe CD, on-line), dicționare, info-kiosk-uri, info-terminale;

Uz personal: informare, divertisment, plata on-line de diferite produse și servicii, navigare Internet, editare și partajare fotografii, muzică;

Alte domenii: medicină, știință, transporturi, comunicații.

Lista continuă, noua tehnologie împreună cu aplicațiile și programele sale găsindu-și utilitatea în fiecare dintre domenii, de la secretariat și gestiune, la modalități științifice de calcul, de predicție sau concepere, căutare și verificare de date și informații.

Deoarece sistemele informatice moderne oferă toate datele și informațiile relevante din cadrul unei instituții, folosirea lor nu este limitată numai la sarcinile de rutină. Există programe utilizate în realizarea de prezentări sau în procesul de predare, dar există și programe utilizate în procesele de decizie (management information systems), de exemplu în domeniul financiar sau al planificării proiectelor.

Mai mult, în ceea ce privește munca de birou, calculatoarele împreună cu rețelele interne și externe oferă posibilitatea comunicării și colaborării mai ușoare între angajați, oferind totodată posibilitatea conducerii de a urmării mult mai ușor fluxul activităților, iar datele, documentele și informațiile din interiorul unei companii și nu numai pot fi transmise, primite și prelucrate într-un interval de timp nesemnificativ din punctul de vedere al timpului de așteptare.

Bineînțeles, unul dintre domeniile în care avansarea tehnologiei a avut un rol foarte important este domeniul educației și formării, învățământul și cursurile la distanță fiind o realitate comună, iar numeroase cursuri on-line fiind prezentate și oferite în prezent de către diverse instituții, acoperind o paletă foarte variată de sectoare de activități, și anume: management, strategie, comunicare, marketing, limbi străine, finanțe, comerț, jurnalism, resurse umane, etc.

Însă, toate facilitățile enumerate mai sus nu pot aduce beneficii fără aplicațiile informatice special create pentru diferitele tipuri de activități întreprinse în diferite domenii.

În epoca în care trăim, între întreprinderi există o competiție al cărei nivel nu ar fi fost niciodată atât de înalt dacă arhitectura de aplicații de care se folosesc nu ar fi fost eficientă, și nu ar fi reușit să îmbunătățească atât performanțele firmei cât și nevoile clienților.

Fenomenul informatizării și digitizării întreprinderilor a fost îndelung analizat, aducându-se în discuție teme precum ce fel ar putea noua tehnologie să crească productivitatea și eficacitatea în afaceri, sau cum ar putea aceasta contribui la creșterea nivelului de importanță al organizației.

Motivația principală pe care am avut-o în analizarea procesului de integrare a aplicațiilor informatice la nivelul unei companii este dificultatea cu care acest proces se implementează, deși la suprafață totul pare foarte simplu.

Este foarte important să conștientizăm importanța tehnologiei în viața noastră, din moment ce nu mai există domeniu în care să nu se folosească aplicațiile informatice care, de câteva decenii încoace, ne fac viața din ce în ce mai ușoară.

1.1. APLICAȚIA INFORMATICĂ – DEFINIȚIE

În informatică, prin aplicație se înțelege un program sau ansamblu de programe care se utilizează pentru rezolvarea unei probleme practice.

De exemplu, în multe unități economice se utilizează o aplicație numită „Personal”. Ea este alcătuită din mai multe programe care au rolul de a ține evidența personalului, de a calcula automat salariile etc.

Realizarea unei aplicații presupune existența unui personal specializat alcătuit din:

analiști de sistem – persoane capabile să proiecteze logic aplicația și care predau programatorilor o documentație după care aceștia realizează programele. Analistul de sistem are cunoștințe serioase de informatică, dar, de regulă, calificarea sa de bază este din domeniul în care se realizează aplicația. De exemplu, pentru aplicația „Personal” analistul de sistem este economist.

programatori – aceștia scriu programele conform documentației primite. Colaborează cu analiștii de sistem și cu inginerii de sistem.

ingineri de sistem – persoane cu pregătire de excepție în informatică atât hard, cât și soft, care au rolul de a întreține rețeaua de calculatoare utilizată, de a acorda consultanță tehnică programatorilor;

specialiști în testarea programelor (testers).

Prin noțiunea de software se înțelege produsul intelectual ce constă din programe, proceduri, reguli și documentația asociată pentru funcționarea unui sistem de prelucrare a datelor. Componentele software-ului sunt produsele program.

Produsul program reprezintă un ansamblu de programe corelate și interdependente având ca scop rezolvarea unor aplicații utilizator.

Programul este format dintr-o secvența de instrucțiuni care, transpuse într-un limbaj de programare și pe un suport accesibil unui calculator, poate realiza o funcție de tratare a datelor sau a informațiilor.

Modulul (la nivel de program) este un element de structură al programului, rezultat din divizarea acestuia în părți disjuncte, astfel încât fiecare parte să aibă independența funcțională, iar interacțiunea dintre părți să fie minimă. Modulul este caracterizat de următoarele elemente: funcția, logica, interfața și ponderea / tăria modulului. Termenul de modul este utilizat la orice nivel în ierarhia sistem informatic – subsistem – aplicație – program, modulele unui sistem fiind subsistemele, ale unui subsistem fiind aplicațiile, ale unei aplicații fiind programele. Modularitatea la nivel de programe se numește micromodularitate.

Pachetul / sistemul de programe reprezintă o mulțime de programe / module, constituită într-o structură de tip liniar, arborescent sau rețea, care rezolvă izolat sau împreună probleme de un anumit tip, aparținând unei aceleași clase de probleme.

Pachetele / bibliotecile de subprograme sunt colecții de subprograme care rezolvă probleme dintr-o anumită clasă și sunt folosite de programatori ca instrumente de dezvoltare de programe, obținând astfel un înalt grad de standardizare și modularizare. Subprogramele nu efectuează operații de intrare / ieșire, datele și rezultatele fiind transmise prin listă de parametrii sau zonă comună.

1.2. EVOLUȚIA INTEGRĂRII APLICAȚIILOR INFORMATICE

Integrarea aplicațiilor informatice în interiorul unei instituții este un procedeu ce reunește echipament tehnologic, personal, programe, dar și implicare managerială. Integrarea aplicațiilor reprezintă o strategie de a uni mai multe sisteme informatice, la nivel de informații și servicii, astfel încât sistemele să fie capabile să facă schimb de informații și să asigure o bună funcționare a tuturor proceselor în cadrul cărora sunt implicate.

Integrarea aplicațiilor informatice în interiorul unei companii sau între mai multe companii care colaborează între ele este un subiect de mare actualitate. Integrarea aplicațiilor informatice comerciale permite coordonarea și sincronizarea mai multor aplicații atât în interiorul (integrarea aplicațiilor la nivel de companie), cât si în afara acestora (integrarea aplicațiilor Business-to-Business – B2B).

Denumită în limbajul de specialitate EAI (Enterprise Application Integration), integrarea aplicațiilor la nivel de companie reprezintă, de fapt, noul stil de lucru în domeniul software. Întreprinderile au din ce în ce mai puțini informaticieni care concep și scriu aplicații și din ce în ce mai mulți care integrează aplicații. Entitatea ce trebuie integrată nu mai este un obiect sau o componentă software, ci este o aplicație software. Prin EAI, sistemele informatice ale întreprinderilor se mulează din ce în ce mai bine pe structura procesului de afaceri.

Într-o întreprindere virtuală, gradul complexității problemelor legate de infrastructura informatică tinde să crească. În funcție de specificul domeniului de activitate și de posibilitățile de organizare ale unei întreprinderi, granulatitatea modulelor poate varia foarte mult.

Integrarea sistemelor informatice într-o companie crește ca importanță astăzi, informația fiind văzută mai mult ca o resursă strategică. Prin aceste sisteme este făcută posibilă circulația în companie a datelor și utilizarea lor de către mai multe persoane în acelși timp.

Studiile realizate în jurul anului 1999 arată că peste o treime din bugetul industriei IT s-a cheltuit pe proiectarea, realizarea și întreținerea de soluții pentru integrarea sistemelor informatice. Majoritatea acestora însă s-a dovedit a fi mai costisitoare strategie de a uni mai multe sisteme informatice, la nivel de informații și servicii, astfel încât sistemele să fie capabile să facă schimb de informații și să asigure o bună funcționare a tuturor proceselor în cadrul cărora sunt implicate.

Integrarea aplicațiilor informatice în interiorul unei companii sau între mai multe companii care colaborează între ele este un subiect de mare actualitate. Integrarea aplicațiilor informatice comerciale permite coordonarea și sincronizarea mai multor aplicații atât în interiorul (integrarea aplicațiilor la nivel de companie), cât si în afara acestora (integrarea aplicațiilor Business-to-Business – B2B).

Denumită în limbajul de specialitate EAI (Enterprise Application Integration), integrarea aplicațiilor la nivel de companie reprezintă, de fapt, noul stil de lucru în domeniul software. Întreprinderile au din ce în ce mai puțini informaticieni care concep și scriu aplicații și din ce în ce mai mulți care integrează aplicații. Entitatea ce trebuie integrată nu mai este un obiect sau o componentă software, ci este o aplicație software. Prin EAI, sistemele informatice ale întreprinderilor se mulează din ce în ce mai bine pe structura procesului de afaceri.

Într-o întreprindere virtuală, gradul complexității problemelor legate de infrastructura informatică tinde să crească. În funcție de specificul domeniului de activitate și de posibilitățile de organizare ale unei întreprinderi, granulatitatea modulelor poate varia foarte mult.

Integrarea sistemelor informatice într-o companie crește ca importanță astăzi, informația fiind văzută mai mult ca o resursă strategică. Prin aceste sisteme este făcută posibilă circulația în companie a datelor și utilizarea lor de către mai multe persoane în acelși timp.

Studiile realizate în jurul anului 1999 arată că peste o treime din bugetul industriei IT s-a cheltuit pe proiectarea, realizarea și întreținerea de soluții pentru integrarea sistemelor informatice. Majoritatea acestora însă s-a dovedit a fi mai costisitoare, optând pentru varianta de integrare “punct la punct”.

În domeniul IT, managerii încearcă să dezvolte strategii eficiente de integrare a sistemelor informatice în cadrul companiei. Însă uneori poate deveni o problemă, dacă aplicațiile sunt dezvoltate fără a se lua în calcul o strategie de dezvoltare sau o anumită arhitectură a sistemelor informatice.

Anul 1959 este caracterizat de o explozie a evoluției domeniului IT, marcat de apariția circuitului integrat și alte descoperiri precum tranzistorii, rezistențele și capacitorii pe un singur chip de silicon. Șase ani mai târziu Gordon Moore face o prezicere interesantă, valabilă și în momentul de față, și anume că numărul de tranzistori pe un microchip se va dubla la fiecare 18 luni.

Pentru a nu exista probleme în cazul unei complexități crescute a aplicațiilor date în folosință, este necesară integrarea aplicațiilor în organizație. În acest context, trebuie reamintite principiile de bază ale managementului complexității: împărțirea modulelor aplicațiilor în părți mai mici și ușor de modificat, construirea ununi model standard al părților funcționale pentru ca aceste părți să poată comunica și apoi se vor pune bazele pentru dezvoltarea unei structuri ierarhice unde datele și informațiile sunt din ce în ce mai abstractizate odată cu urcarea în ierarhie.

Începutul secolului XXI aduce cu el o dezvoltare și mai accentuată a economiei globale și a informatizării. În acest context devine necesară organizarea sistemelor informaționale în modele mult mai complexe. Odată cu complexitatea sistemelor crește și calitatea lor, datorită adăugării componentelor evolutive și emergente, dar și diversitatea lor. Evoluția ciclică și progresivă a mixului de tehnologii are ca efect integrarea sprijinită de expertiza și performanțele experților în domeniu.

Integrarea aplicațiilor poate fi internă (la nivel de companie) sau externă (aplicațiile Business-to-Business).

Strategia IT trebuie să țină seama de toți factorii care influențează deciziile de integrare a proceselor economice, ca de exemplu configurarea proceselor economice, frontierele acestora și locul în care schimbarea este cel mai probabil a se produce. Înțelegerea scopurilor economice, cum ar fi strategiile de fuzionare și de achiziție sau cost și creșterea eficienței, apare ca o cheie fundamentală. Trebuie stabilită o perspectivă internă și externă comună a nucleului economic, de informație și de procese, pentru a înțelege relațiile și interfețele între unitățile economice, sau între partenerii comerciali.

Stabilirea proprietății aplicațiilor, componentelor, infrastructurii integratoare și interfețelor externe poate fi o sarcină destul de dificilă. Secvențierea activităților trebuie să identifice ierarhia importanței serviciilor într-o organizație pentru eficientizarea activităților. Se vor stabili astfel care sunt serviciile care trebuie realizate cu prioritate și care servicii trebuie utilizate pe un model standard cu restul întreprinderii și când anume.

În prezent, se dorește integrarea sistemelor bazate pe servicii, nu cele bazate pe informații. Cu toate că ultima este mai puțin costisitoare deoarece nu este necesară modificarea aplicației, integrarea bazată pe servicii oferă mai multă consistență pe un termen mai lung.

1.3. DEFINIȚIA ȘI ROLUL SISTEMELOR INFORMATICE INTEGRATE

Sistemele informatice integrate sunt sisteme complexe, prin care se pot desfașura transformări de structură și de management al cunoștințelor, modele de practică managerială, diferite interacțiuni organizaționale, și procese de afaceri.

Sistemul de aplicații integrat trebuie să reprezinte soluția oricărei companii moderne, care are nevoie de un sistem informatic actual, care să poată automatiza procesele interne, relația cu furnizorii, partenerii, și bineînțeles cu partea cea mai importantă a unei organizații, clienții. Pentru a nu fragmenta informația, și pentru a nu întâmpina probleme în ceea ce privește dezvoltarea și actualizarea ulterioară a aplicațiilor și sistemelor, nu se recomandă adoptarea aplicațiilor disparate, care rezolvă problemele punctual, și sunt de cele mai multe ori doar soluții de moment, ci a pachetelor de aplicații care vor reuși cu ușurință să colaboreze între ele.

O mare atenție trebuie acordată pachetelor de soluții oferite de către producătorii de software, pentru a nu se primii false pachete de aplicații, deoarece acestea rulează pe mai multe surse de date, fragmentează informația și poate duce la costuri ulterioare foarte mari atunci când se va pune problema de consolidarea informațiilor. Astfel se ridică problema continuității sistemului, deoarece managerul unei companii care nu deține in interiorul acesteia un sistem informatic integrat, ci doar un pachet de aplicații care funcționează mai mult departamental, nu va avea la dispoziția sa niciodată un raport complet și holistic al activității firmei, ci un număr de rapoarte direct proporțional cu numărul de departamente sau activități din cadrul organizației, care sunt mult mai dificil de urmărit și interpretat.

Realul pachet integrat de aplicații este acela în cadrul căruia aplicațiile sunt concepute, scrise și construite de la început pentru a colabora cât mai bine între ele, și care sunt standardizate din punct de vedere al informațiilor pe care le partajează și al modului de structurare si retransmitere a informației.

Avantaje precum recuperarea rapidă a investițiilor in IT, reducerea costurilor pe termen lung, migrarea mai rapidă spre modelul e-business, și creșterea eficienței operaționale sunt unele dintre avantajele pe care pachetele de aplicații trebuie să le ofere companiilor beneficiare.

Pentru a se putea înțelege mai bine rolul sistemului informatic integrat într-o companie, trebuie în primul rând urmărit modelul organizațional al întreprinderilor care, indiferent de zona din care provin (financiar-bancar, comerț, producție, sevicii) au de obicei patru obiective principale atunci când vine vorba de implementarea unor noi aplicații:

reducerea costurilor pe termen lung;

creșterea eficienței operaționale;

recuperarea rapidă a investițiilor în IT;

migrarea mai rapidă la modele de e-business.

Pentru a înțelege rolul jucat de un sistem informatic integrat în funcționarea unei întreprinderi, este necesar să se pornească de la modelul general de organizare a unei afaceri, corespunzător majorității întreprinderilor de producție, comerț, servicii sau a unora din sectorul financiar-bancar.

Conform acestui model, orice întreprindere este constituită din patru zone:

1.3.1. Zona Back Office

Putem caracteriza această zonă din punct de vedere informatic astfel:

Baza de date are o importanță fundamentală, aceasta putând fi situată atât pe mai multe servere, cât și pe un singur server.

Aplicațiile utilizate în această zonă trebuie să fie capabile să lucreze datele “bulk” (un exemplu ar fi ca toate tranzacțiile unei zile de lucru să poată fi tratate toate în același timp), sau să poată fi capabile de a gestiona simultan mai multe cereri provenite din partea unui număr mai mare de utilizatori.

Prelucrările realizate au o importanță foarte mare, întreaga activitate a întreprinderii depinzând de datele prelucrate în această zonă.

Sistemele de operare dedicate rulează pe un număr redus de servere

În practică, una dintre cele mai apreciate calități ale unui sistem de Back Office este reprezentată de integritatea și coerența datelor, iar alte caracteristici esențiale ale unei aplicații utilizate în zona Back Office sunt continuitatea serviciilor și disponibilitatea permanentă a sistemului.

Astfel, atunci când vorbim despre întreprinderile moderne, aplicațiile din această zonă garantează buna funcționare a întreprinderii, iar din acest motiv este absolut necesară existența unor aplicații care pot garanta securitatea datelor la toate nivelele (fizice și drepturi de acces).

1.3.2. Zona Front Office

Aplicațiile din această zonă sunt acelea pe care compania le pune la dispoziția clienților săi pentru a le putea asigura acestora servicii rapide. Din aceste motive, cerințele pe care trebuie să le îndeplinească o aplicație din această zonă sunt:

Gestionarea relațiilor cu clienții – trebuie să cuprindă instrumente de management al clienților, pe care trebuie să le transmită mai apoi spre procesare aplicațiilor din Zona Back Office, cum ar fi informațiile despre operațiile efectuate de clienți și consultarea dosarelor acestora, și instrumente care să vină în ajutorul clienților atunci când au nevoie de asistență (atunci când un client este îndreptat automat către un anumit departament în urma completării unei cereri sau selectarea anumitor criterii), dar și aplicații de evaluare a clienților, care pot stabili, în funcție de criterii clar stabilite, gradul în care clientul se încadrează în condițiile prevăzute, iar aici putem da exemplu o aplicație care este utilizată pentru calcularea unui credit acordat.

Gestionarea agenților de vânzări – această aplicație are ca scop gestionarea persoanelor care se ocupă de vânzări urmărindu-le performanțele, realizarea targeturilor individuale și colective, urmărirea vânzărilor totale, centralizarea rezultatelor, etc.

Gestionarea clienților – în acest caz sunt folosite aplicațiile integratoare a rețelelor de telecomunicații.

Instrumentele de asistare a deciziei – adică aplicațiile de căutare și extragere de date.

Gestionarea rețelelor de agenții – de obicei sunt aplicații complementare, apărute ca răspuns la nevoia companiilor multiteritoriale.

1.3.3. Zona Middle Office

La nivel fizic, aceasta este o zonă greu de definit, care a primit două terminologii diferite, și anume:

O primă accepțiune ar fi că această zonă reprezintă de fapt Zona de Back Office din cadrul agențiilor teritoriale care îndeplinește de fapt atribuții de Front Office;

O a doua accepțiune ar fi că această zonă se comportă ca o zonă intermediară, și cu rol de interfață între zona Front Office și Back Office în ceea ce privește transmiterea informațiilor către aplicațiile centrale și pentru gestionarea rețelei.

1.3.4. Zona Web Office

Zona Web Office a fost introdusă odată cu tehnologia World Wide Web, care are rolul de a completa zonele de Front și Back Office, și care oferă posibilitatea conectării la sistemul informatic al companiei din orice punct de pe glob, ceea ce înseamnă că, dacă în urmă cu câțiva ani tranzacțiile financiare la distanță erau procesate separat de restul sistemului, acum tehnologia permite ca tranzacțiile să fie procesate din interiorul întreprinderii si înregistrate automat în sistem.

Această zonă cuprinde mai multe aplicații, dintre care putem enumera:

Aplicațiile interne ale companiei, care sunt destinate in mod exclusiv angajaților, și care pot furniza servicii multiple precum coordonarea și gestionarea proiectelor, videoconferințe, mesagerie internă, plasarea activităților de grup, urmărirea la distanță a activităților. În acest caz se folosește tehnologia Intranet, care se va utiliza în mod obligatoriu cu aplicațiile de securitate de tip firewall, pentru a se putea bloca accesul neautorizat atât din exterior cât și din interior.

Aplicațiile create pentru parteneri – sunt acele produse care au ca utilizator final clientul, furnizorul sau consultantul companiei. În acest caz se folosesc serverele de Extranet , iar serviciile sunt echivalente celor interne, exceptând faptul că sunt destinate utilizatorilor externi, iar aplicațiile de securitate folosite sunt diferite.

Aplicațiile accesibile publicului – această aplicație este concepută pentru a asigura accesul publicului la produsele și serviciile oferite de companie. In acest caz se folosește tehnologia Internet, serverele conectate extinzându-și activitatea spre serverele de lucru către cele ale partenerilor, oferindu-le cataloage on–line și posibilitatea de a efectua comenzi și plăti electronic.

Așa cum am amintit și mai sus, nivelul de securitate între componentele Internet, Intranet și Extranet este diferit, și deși deține aplicații separate de apărare, nu trebuie neglijată niciuna din aceste părți. Deziderabil ar fi să se poată identifică în orice moment persoanele care navighează, iar acest lucru poate fi realizat prin restricțiile impuse de către întreprindere.

2. PROBLEMELE INTEGRĂRII APLICAȚIILOR INFORMATICE

Formalizarea sistemelor informatice existente în cadrul unei companii, este greu de realizat deoarece acestea pornesc de la situații diferite. De obicei, atunci când vorbim despre integrarea sistemelor informatice, problemele apărute se pot împărții în două mari categorii:

2.1. Probleme tehnice

Problemele tehnice se datorează eterogenității produselor hardware și software, diversității tehnologiilor folosite de diversele sisteme informatice din cadrul întreprinderii. Din cauza problemelor tehnice, se produce o discontinuitate de comunicare între sistemele informatice.

Soluția pentru rezolvarea acestei probleme sunt companiile furnizoare de produse hardware și software, deoarece acestea sunt în egală măsură interesate de succesul integrării aplicațiilor pe care le furnizează ca și companiile care comandă și achiziționează aceste produse.

2.2. Probleme informaționale

În principal, inconsistența datelor duce la probleme informaționale, iar această inconsistență este rezultatul felului în care au fost dezvoltate aplicațiile informatice, greșeala provenind în principal din faptul că în momentul în care s-au realizat aplicațiile s-a omis faptul că la un moment dat ar putea exista și alte aplicații care să necesite acces la aceleași date, sau din faptul că nu există o standardizare în ceea ce privește procesul de data entry, iar în interiorul companiei încă mai sunt folosite tehnologiile vechi, care din motive de securitate nu permit accesul niciunei alte aplicații la datele pe care le conțin.

Inconsistența datelor poate fi soluționată în felul următor:

Identificarea conflictelor și a posibilelor discrepanțe

Discrepanțele din date apar datorită reprezentării în mod diferit a unor date similare în sisteme diferite, lucru care poate conduce la conflicte. Aceste diferențe pot fi de domeniu, de natură, de dimensiune, de nume sau structurale.

Cum se pot soluționa aceste discrepanțe

Se poate utiliza, fără avertizarea în prealabil a utilizatorului, una dintre valorile inconsistente;

Indicând sursa informației, se pot prezenta toate valorile inconsistente utilizatorului, acesta putând alege calea cea mai convenabila de rezolvare a problemei;

Utilizând o marcă de timp care să poată indica ultima valoare de actualizare a informației, se poate indica cea mai recentă valoare a informației;

Pe baza unei evaluări în prealabil a sistemului cel mai de încredere, se poate utiliza informația din cel mai bine gradat sistem;

În funcție de media aritmetică, se poate utiliza mărimea agreată pe baza valorilor inconsistente

O alternativă ar fi utilizarea tabelelor de corespondență și a formulelor de conversie, precum și a mecanismelor de implementare a politicilor de soluționare mai sus menționate.

3. INFRASTRUCTURA DE INTEGRARE A APLICAȚIILOR INFORMATICE

Modelul conceptual al unei organizații cuprinde:

arhitectura sistemului de afaceri (operațional și strategic),

arhitectura sistemului informațional și

arhitectura sistemului informatic.

Lipsa unei arhitecturi de integrare a sistemelor informatice a făcut ca adesea cerințele de integrare să fie rezolvate prin stabilirea unor interfețe individuale între două sisteme (integrare “punct la punct”). Deoarece numărul de aplicații care necesită integrare este în permanentă creștere, se va ajunge inevitabil la o foarte dificil de dezvoltat și întreținut rețea de conexiuni.

Deoarece nu este necesară o abstractizare a datelor și proceselor, soluția mai sus menționată este ușor de implementat, minusul fiind că pe termen lung aceast model de integrare va fi neflexibil în ceea ce privește noile cerințe care pot apărea, deoarece soluțiile punctuale rezolvă situații punctuale, însă pe o perioadă mai lungă de timp conduc la rigididatea la adaptare din cauza complexității soluției care va deveni dificil de implementat și gestionat.

Pentru ca dezvoltarea aplicațiilor să se poată efectua eficient, este absolut necesară dezvoltarea la nivel de companie a unei infrastructuri de integrare a aplicațiilor. În principal, infrastructura trebuie să promoveze metode care să permită partajarea informațiilor fără să mai fie nevoie ca fiecare aplicație să mai fie conectată la alta, ci doar sistemul în sine să dețină o bază de date comună.

Astfel, pentru reducerea efortului de realizare și întreținere a sistemelor informatice este de preferat a se evita utilizarea integrării “punct la punct”, iar pentru a se asigura un management centralizat al integrării, soluția cea mai bună este de a se asigura un cadru scalabil și ușor gestionabil în cadrul procesului de integrare, care să fie independent de caracteristicile bazelor de date, ale sistemelor de operare și de tehnologia mai mult sau mai puțin învechită a aplicațiilor. Doar în acest mod infrastructura de integrare va putea să adapteze și să imbunătățească aplicațiile informatice, să reducă costurile implicate de întreținerea infrastructurii și să gestioneze sisteme informatice din ce în ce mai complexe.

În cazul în care metodologia de elaborare lipsește, respectarea urmatoarelor etape poate fi o cerință obligatorie:

3.1. Definirea scopului integrării

Motivul pentru care se dorește integrarea sistemelor informatice trebuie definit la nivelul companiei, nu la nivel de sistem individual. În realizarea planului în funcție de care va avea loc procesul de integrare trebuie să se țină cont de cele două puncte principale ale discuției, și anume obiectivele afacerii și prioritatea acestora. Planul de integrare cel mai eficient va ține cont de o strategie de update pe termen lung, precum modificările sistemelor sau dezvoltarea tehnologică.

3.2. Definirea strategiei de integrare

Definirea strategiei de integrare a sistemelor informatice la nivelul întreprinderii trebuie să aibă în vedere necesitatea flexibilității în momentul în care una dintre aplicațiile integrate va trebui să fie modificată, sau asupra căreia vor trebui să se facă modificări sau eliminări. De asemenea, o mare importanță și atenție trebuie dată aplicațiilor deja existente, mai ales dacă vorbim despre aplicații cu necesități speciale de siguranță și performanță.

Soluția completă și ideală de integrare a sistemelor informatice la nivelul unei companii este cea care include atat tehnologii de integrare la nivelul datelor cât și la nivelul proceselor de afaceri.

Datorită utilizării unei infrastructuri strategice de integrare a sistemelor informatice, întreprinderea poate beneficia de o viziune completă asupra datelor operaționale sau suport de decizie din toate bazele de date, aplicațiile și sistemele incluse, doar o arhitectură de integrare putâns să ofere scalabilitatea necesară, controlul intefețelor și puterea de transformare fără de care nu se pot elimina problemele din rețeaua de interfațare și nu se poate oferi flexibilitatea reală în ceea ce privește implementarea proceselor în afaceri.

4. EVOLUȚIA APLICAȚIILOR INTEGRATE DE GESTIUNE A FIRMELOR

Datorită evoluției mediului de afaceri și a creșterii în complexitate a activităților din cadrul unei companii, adaptarea la noile sisteme informatice devine o necesitate. Se întamplă însă ca această adaptare într-un ritm alert sa fie o provocare majoră pentru factorul uman, punând la încercare capacitățile de efort și analiză. Pentru a se putea face față provocărilor, au fost create sistemele ERP (Enterprise Resource Planning), sisteme care pot procesa un volum extraordinar de date și informații agregate în scopul optimizării și eficientizării proceselor.

În anii ’60 încep să se dezvolte aplicațiile pentru întreprinderi, evoluând timp de patru decenii până la sistemele ERP. Datorită caracterului evolutiv, aplicațiile s-au dezvoltat urmând îndeaproape evoluția sistemelor hardware și software. În această perioadă de început, o mulțime de organizații realizau aplicații centralizate care erau proiectate, dezvoltate și implementate în interiorul companiei. De la aplicațiile axate pe controlul stocurilor și automatizarea gestiunii se încerca realizarea aplicațiilor pentru calculul automat al salariilor și pentru contabilitate generală, folosind limbaje de programare precum COBOL (Common Business Oriented Language), ALGOL (Algoritmic Language) și FORTRAN (Formula Translating Sistem).

În anii ’70, se conturează sistemele Material Requirements Planning (MRP), definite în literatura de specialitate ca un set de tehnici care utilizează ca instrumente pricipale datele despre stocuri, inventarul, și programul de producție pentru calcularea necesarului de materiale, executarea comenzii de aprovizionare și asigurarea materialelor pe timpul procesului de fabricare. Privite din prisma trecerii timpului și a evoluției de la aplicațiile simple de verificare al stocurilor, sistemele MRP au reprezentat punctul de schimbare al sistemului de control al stocurilor de materiale sub influența calculatorului și a aplicațiilor din componența acestuia.

În următorul deceniu se dezvoltă MRP II sau Manufacturing Resource Planning, care are la început ca idee sincronizarea necesarului de materiale cu cerințele producției pentru optimizarea proceselor de fabricație. În timp, aceste sisteme ajung să fie funcționale si în alte departamente, depășind zona de producție. Departamente ca resurse umane, distribuție, vânzare, financiar, sunt numai câteva dintre ele. Întreprinderile reușesc prin acest sistem să își planifice resursele într-un mod mult mai eficient decât până atunci, asigurând planificarea materialelor care susțin procesele de producție, elaborarea de scenarii anticipative și planificarea financiară. Funcțiile integrate ale acestor sisteme aveau în vedere: planificarea necesarului de materiale, planul de vânzări, programarea producției, planificarea producției, planificarea capacităților de producție, și urmărirea execuției – aprovizionare, fabricație, vânzare. La fel de importante sunt și ieșirile date de aceste sisteme: proiecții de stocuri, rapoarte financiare, plan de aprovizionare, plan de vânzări, buget de expediție și transport.

Odată cu trecerea timpului, înbunătățirea acestui sistem, oricât de eficient și complex, devine inevitabilă. Enterprise Resource Planning, la început denumit Business Resource Planning, este mai mult decât un sistem care se ocupă doar de urmărirea și eficientizarea procesului de producției. Conceptul de ERP a fost introdus de Gartner Group potrivit site-ului www.technologyevaluation.com.

Datorită caracterului evolutiv al sistemelor, la sfârșitul anilor ’80 și în următorul deceniu se dezvoltă și se impun sistemele ERP, acestea fiind rezultatul extinderii funcționalității pachetelor MRPII. Fundamentate pe sistemele MRP II, sistemele ERP integrează toate procesele economice, cum ar fi producția, distribuția, contabilitata, părțile financiare, personalul, stocurile, service-ul și întreținerea, logistica și gestiunea de proiecte, asigurând continuitatea și consistența informațiilor, accesul și transparența în întreaga întreprindere.Menținând caracterul evolutiv, producătorii de soluții ERP, au adăugat suitelor lor, noi module și funcționalități, și s-a produs astfel trecerea la o nouă etapă în evoluția sistemelor ERP și anume “ERP extins”. Anii 2000 sunt caracterizați prin aplicații precum APS (Advanced Planning and Scheduling), soluții e-business pe zona relațiilor cu clienții – CRM (Customer Relationship Management) sau pe furnizori-aprovizionare – SCM (Supply Chain Management). Tot în această perioadă au apărut și concepte noi, cum sunt BPI (Business Process Integration), EAI (Enterprise Application Integration), ENS (Enterprise Nervous System) și ERP (ENTERPRISE RESOURCE PLANNING).

Un ERP, „considerat expresia cea mai fidelă a interdependenței dintre economic și tehnologia informațională, reprezintă o infrastructură software, multi-modulară ce oferă suport de gestiune și coordonare a diferitelor structuri și procese din companie, în vederea realizării obiectivelor de afaceri” . Scopul unui sistem ERP (sistem de gestiune integrată a proceselor de afaceri) este realizarea unei mai bune comunicări în companie, îmbunătățirea cooperării și interacțiunii dintre diferite departamente precum cele de planificare a producției, achiziții, producție, vânzări și relații cu clienții. Pe scurt, un sistem de gestiune a companiei de tip ERP reprezintă planificarea celor 4 factori determinanți pentru o afacere de succes: factorul uman, financiar, tehnic și de resurse (cei 4 M – Man, Money, Machines și Materials), după sursa http://www.cio.com/research/erp/.

Davenport T.H., specialist de renume în domeniile de management și sisteme informaționale pentu afaceri propune ca definiție pentru ERP: ”un pachet care promite integrarea completă a tuturor informațiilor din cadrul unei organizații .

4.1. Schema conceptuală a unui sistem ERP

ERP este un sistem inegrator al tuturor proceselor economice: personal, producție, logistică, financiar, distribuție, sevice și mantenață, contabilitate și gestiune de proiecte care poate oferi în întreaga organizație consistență informațională și transparență. ERP poate fi descris ca un sistem integrator de nivel global care poate acoperi toate procesele interconectate care concretizează activitatea întreprinderilor și elimină granițele și delimitările funcționale la nivel de organizație, oferind posibilitatea de lucru multiscop, multiutilizator și multispațiu.

Putem defini sistemele de tip ERP ca niște soluții sofware complexe, bazate pe o arhitectură client-server și integrate pe o platformă comună, pentru asigurarea gestiunii resurselor companiei, care facilitează integrarea proceselor prin centralizare, împarțirea datelor și eliminând redundanța. Desigur că pentru fiecare tip de industrie, pachetul ERP va avea funcționalități diferite.

În principal, cea mai dificilă sarcină este optimizarea resurselor disponibile și integrarea proceselor economice.

În momentul de față, sistemele ERP integrează funcțiile de conducere ale companiei pornind de la:

Menținerea și dezvoltarea relațiilor cu partenerii de afaceri și clienții;

Gestiunea stocurilor, financiar contabilă și a resurselor umane;

Planificarea resurselor și producției;

Definirea tehnicilor și tehnologiilor;

Asigurarea stocului de materiale și materii prime;

Coordonarea proceselor de producție.

Acest sistem permite managementului să realizeze analize complete și holistice asupra planului de afaceri care se va pune în aplicare în perioada următoare. Deasemenea, prin caracterul flexibil și dinamic, sistemul are în componența sa opțiuni de simulare a activităților, care pot fi:

Grafice de evoluție ale industriei din care face parte compania;

Planuri de previziune în ceea ce privește integrarea noilor tehnologii e-business în companie;

Analize calitative;

Analize ale resurselor care se proconizează a fi folosite în viitor.

Odată cu implementarea acestora, sistemele ERP vin cu o serie de caracteristici incluse, acestea instalându-se pe sistemul de gestiune a bazelor de date. Platformele de baze de date cele mai frecvent folosite sunt: Oracle, SQL Base, Sybase, Informix, DB2 și MS SQL Server.

Ca și caracteristică principală, baza de date aleasă de către companie trebuie să dețină, în funcție de tipul de activitate al întreprinderii și al sistemului ERP achiziționat, o setare inițială care, la fel ca o bază de date unică, să permită tuturor membrilor organizației accesul direct și în timp real la toate informațiile deținute acolo. Datele se vor introduce la finalizarea instalării, iar prin intermediul modulelor, informațiile vor fi transferate prin intermediul proceselor. Ca un element de încheiere, sistemele ERP trebuie să includă instrumente care realizează rapoarte atât la cerere, cât și periodice.

Ca să simplificăm, putem defini sistemul ERP din prisma a doi termeni fundamentali: integrarea și funcționalitatea.

4.2. Reprezentarea simplificată a unui sistem ERP

Aceste două părți se condiționează reciproc.

Gândită ca o tehnică de comunicare, integrarea trebuie să asigure conectivitatea între fluxurile de procese economice funcționale. Câteva exemple prin care are loc comunicarea pentru și prin integrare sunt: e-mail, rețele extinse și locale de calculatoare, workflow, Internet, protocoale, instrumente de configurare automată, baze de date, și codul sursă. În concluzie, putem afirma că integrarea se realizează prin comunicare, iar comunicarea se realizează prin integrare.

Deoarece partea funcțională a unui sistem ERP este responsabilă cu asigurarea fluxurilor proceselor economice din cadrul fiecărei funcțiuni, în cadrul acestui sistem se vor găsi, în funcție de activitatea companiei, o multitudine de module care vor face referință la stocuri, planificarea producției, contabilitate generală, aprovizionare, comenzi și vânzare, salarii, logistică sau debitori.

4.3. Arhitectura cu trei niveluri a unui sistem ERP

Cele trei niveluri de funcțiuni sunt:

Nivelul prezentare, care este reprezentat de programul de navigare folosit la accesarea funcțiilor din sistem și care constă în interfața grafică cu care utilizatorul ia contact.

Nivelul aplicație, care asigură transferarea datelor de la severele de baze de date și vice versa, și care cuprinde procedurile interne ale întreprinderii, precum și funcțiunile și logica sistemului.

Nivelul bazei de date, unde putem indentifica funcțiunile care se ocupă de gestionarea datelor și metadatelor organizației. De obicei vom regăsesi aici un sistem SGBD (Sistemul de Gestiune a Bazelor de Date) relațional dintre cele standardizate industrial, care include și modulul SQL (Structured Query Language – Limbaj Structurat de Interogare).

Structurarea logică arătată mai sus va permite ca interfața sistemului integrat să ruleze pe toate calulatoarele utilizatorilor, iar prelucrarea datelor să se realizeze pe nivelul de mijloc al serverelor care conțin aplicațiile, iar bazele de date și sistemele aferente să funcționeze pe cel de-al treila strat, cel al serverelor specializate.

4.4. Componentele principale ale unui sistem ERP

Dacă vom analiza sistemele ERP dezvoltate până în momentul de față, putem evidenția multitudinea de componente care intră în alcătuirea lor:

Nomenclatoarele sunt fișierele de bază care reunesc toate datele despre clienți, furnizori și personal, și care pot interfața cu orice modul care se folosește de aceste date.

Componenta financiar contabilă sau de contabilitate, care asigură evidența contabilă și gestiunea financiară. Această componentă dorește ca informațiile financiar contabile preluate din documente să fie procesate și înregistrate automat în sistem, la fel ca celelalte date aflate în sistemul ERP, iar impreună să poată realiza o evidență contabilă completă, care va putea fi îmbunătățită ulterior prin adăugarea unor componente de analiză, și care va avea ca target final generarea de rapoarte privind performanțele firmei.

Încasările și plățile sunt componente importante fără de care nu se pot gestiona și nici înregistra creanțele și datoriile organizației.

Salarizarea este componenta care înregistrează și gestionează evidența și calculul salariilor. Astfel se pot automatiza calcularea taxelor, și a contribuțiilor la stat, precum și asigurările sau impozitelor plătite pentru angajați.

Partea de resurse umane. Este componenta care se ocupă de procesul de recrutare și selecție a personalului, și de înregistrarea documentelor necesare la instituțiile statului în ceea ce privește adăugarea persoanelor în tabelele de contribuabili.

Imobilizările. Atât obiectele de inventar, cât și activele necorporale sau mijloacele fixe, trebuiesc gestionate. Deținând această componentă, se va putea verifica în orice moment durata de utilizare și starea activului, precum și starea și operațiile efectuate asupra sa: data de intrare, modificare, modernizare, reevaluare, scoaterea din funcțiune, casarea.

Furnizorii și aprovizionarea. Această componentă poate determina producerea de economii la nivel de consumabile, deoarece prin caracteristica sa de instrument optimizator al aprovizionării, va depăsi atribuțiile unei simple aplicații de gestiune. Mai mult, această componentă poate gestiona și activitățile care intră în procesul de vânzare, și se află în strânsă legătură cu componenta Stocuri.

Stocuri. Este componenta care gestionează automat documente contabile, și permite gestiunea calitativă și cantitativă a stocurilor de produse.

Necesarul de materiale. Pe baza inventarului inițial și al celui actual, al planului de producție și consum aprobat, această componentă poate determina automat cantitățile de materiale necesare.

Planificarea. Are în vedere detaliile tehnice, termenul, executantul, costul programat și articolele de realizat.

Managementul proiectelor. Componenta are ca obiectiv finanțarea, planificarea și urmărirea stadiului de executare ale proiectelor de investiții și lucrările sau activitățile pe care terții le efectuează.

Urmărire. Înregistrează rapoartele de lucru și preluarea notelor de predare, compară și analizează comenzile plasate și oferă rapoarte detaliate sau cumulate ale producției și ale costurilor.

Gestiunea depozitelor este componenta care, din punct de vedere organizatoric, definește unitățile de stocare, adică magaziile, locațiile, inventarele, modalitatea de localizare a stocurilor și depozitele.

Urmărirea și planificarea costurilor și consumului. Această componentă are ca obiectiv întocmirea bonurilor și facturilor de consum, preia datele de consum de la sediile din regiuni, centralizează datele înregistrate pentru a calcula costurile, și generează rapoartele privitoare la consumurile realizate în comparație cu cele planificate.

Servicii/Service. Este componenta care se ocupă cu urmărirea serviciilor deja achiziționate și a garanțiilor.

Gestiune date tehnice. Această componentă înregistrează datele tehnice din fabricație ale tehnologiilor și produselor cumparate sau care urmează a fi achiziționate.

Logistică și transport. Componenta se ocupă cu planificarea și gestionarea părții de logistică din activitatea de distribuție și vânzare.

Analiza (Business Intelligence). Acest modul, în funcție de forma și cerințele utilizatorului, preia informațiile din baza de date și se ocupă cu realizarea a diverse analize. Scenariile, prognozele și simulările multidimensionale OLAP (Online Analytical Processing) sunt cele mai puternice opțiuni.

Mentenața (întrținerea echipamentelor). Acest modul simplifică modul de urmărire a felului în care sunt utilizate echipamentele și permite planificarea costului lucrărilor și a lucrărilor. Importanța acestei componente este dată de faptul că poate genera rapoarte în ceea ce privește istoricul activităților de reparație și întreținere.

Generatorul de rapoarte. Dacă există instalat acest modul, se vor putea obține rapoarte din fiecare componentă funcțională, sistemul folosindu-se de datele înregistrate și procesate în cadrul sistemului ERP.

4.5. Implementarea unui sistem ERP

Implementarea unui sistem ERP nu este o decizie facilă pentru nicio organizație. Deoarece planificarea resurselor, instruirea personalului și alegerea soluției cea mai potrivită pentru fiecare tip de organizație în parte sunt trei dintre condițiile principale în reușita implementării și implicit pentru folosirea sistemului la eficiență maximă, succesul în implementarea unui sistem de tip ERP nu este o șansă.

A. Decizia de adoptare a unui sistem ERP trebuie să fie bazată pe un set de criterii de analiză comparativă și selecție foarte precise a mai multor feluri de aplicații care pot fi puse la dipoziția companiilor, cum ar fi:

obigativitatea de a se respecta cadrul legal al fiecărui stat, precum și legislația europeană;

posibilitatea operărilor cu diverse valute, adică sistemul sa poată recunoaște plățile atât în moneda națională, cât și în monedele de circulație a altor state;

prelucrarea informațiilor trebuie sa fie în timp real;

software-ul aplicativ trebuie să aibă o structură modulară, și să permită atât extinderea ulterioară a ariei funcționale acoperite cât și să permită implementarea etapizată;

nu trebuie să fie dependente nici de o singură, nici de o anume platformă hardware;

trebuie să dețină atât caracteristici funcționale, cât și elemente ajutătoare;

securitatea și integritatea datelor trebuie sa fie asigurată în permanență;

investiția trebuie justificată clar, riscurile trebuie să fie minime, iar avantajele trebuie să fie cât mai rapid vizibile cu putință.

Integrarea este principalul deziderat al unui proiect ERP. În teoria organizațională,”integrarea definește nivelul de colaborare între indivizi, ca și între entități. Într-o organizație, indivizii își formează un mod particular de abordare, gândire și rezolvare a sarcinilor de lucru, corespunzător educației și experienței fiecăruia. Abordările pot fi uneori conflictuale, de aceea se așteaptă ca integrarea să asigure coordonarea și colaborarea între indivizi prin instrumente specifice.”

B. În urma deciziei de implementare a unui sistem ERP, urmează selecția soluției cea mai potrivită, prezentată sub forma unei schițe logice. Cea mai potrivită decizie pe care o poate lua o organizație este una semi-structurată, deoarece din totalul problemelor numai o parte pot fi tratate prin intermediul unei proceduri clar definite, restul trebuind tratate punctual, deoarece nu există o procedură unanim acceptată în ceea ce privește acest proces decizional. O altă problemă ar fi determinarea celor mai adecvate criterii de selecție, care se pot impărții în câteva categorii principale:

Mărimea organizației și amploarea proiectelor pe care le are în plan;

Investițiile necesare demarării, executării și finalizării proiectului;

Domeniul de activitate al firmei este considerat unul dintre cele mai importante criterii. În acest caz, se impune studiul cazurilor asemănătoare de pe piață. Aplicațiile dedicate sau verticale au fost create în mod special pentru un anumit domeniu de activitate, iar acest lucru nu trebuie neglijat. De menționat este faptul că aceste aplicații dedicate vor veni împreună cu tot bagajul de cunoștințe din spatele companiilor de pe același profil, și au implementat sistemul cu succes;

Gradul de dispersie geografică. Dacă la un moment dat în procesul de implementare investiția se dovedește a fi costisitoare, se poate opta pentru implementarea step by step, moment în care se va discuta despre o structurare ERP pe două niveluri. Acest model de structură va oferi avantajul mecanismului perfect de funcționare al întreprinderilor care au caracter transnațional. Astfel, filialelor mari și sediului principal li se vor oferi un nivel superior acoperit de aplicații ERP mai puternice (ex. SAP R/3 Systems, Oracle Applications) iar filialelor mai mici li se va oferi un nivel inferior acoperit de aplicații care pot oferi garanția competitivității la costuri mult mai scăzute, cum ar fi Scala sau Siveco.

Structura aplicațiilor care există deja vor implica automat probleme cum ar fi inconsistența și redundanța datelor, modul greoi de actualizare a datelor, inflexibilitatea și uneori chiar imposibilitatea modificărilor datelor, producerea fenomenului de izolare a datelor, accesul dificil la baza de date, și nu în ultimul rând problemele de integritate și securitate a datelor.

4.6. Modelarea deciziei de selecție

C. Activitatea de implementare și selectare a unui sistem ERP se realizează în funcție de valorile organizației. În mod obligatoriu, în urma implementării sistemului ERP, trebuie avute în vedere următoarele activități:

Pregătirea acționarilor și managerilor, deoarece aceștia trebuie să cunoască fenomenele tehnologice, să cunoască avantajele sistemelor de tip ERP, și să le fie alocat timpul necesar pentru a avea o atitudine pozitivă față de proiect;

Formarea echipei care se va ocupa de proiect, activitate care, în cazul unui buget limitat al firmei, se poate combina între experții IT și personalul care poate fi recalificat din cadrul firmei.

4.7. Configurația unei echipe ERP

Analiza cerințelor este procesul care va determina cerințele informaționale ale întreprinderii, acesta având în vedere toate caracteristicile funcționale majore.

Planul de integrare al afacerii va fi realizat în mai multe ședințe de lucru, unind cerințele informaționale prestabilite cu specificațiile strategiei de afaceri. Echipa care se va ocupa de proiect va gândi și va stabili căt poate și cum poate software-ul să rezolve.

Stabilirea obiectivelor proiectului este partea în care se prezintă așteptările întreprinderii, și se compară cu ceea ce poate pachetul ERP să ofere.

Instruirea și pregătirea echipei care se va ocupa de proiect. În această fază, echipei îi este prezentat planul detaliat al proiectului, nefiind altceva decât etapa premergătoare activității de oferire a informațiilor complete asupra proiectului.

Studierea ofertelor de soluții ERP oferite este etapa în care se vor solicita și căuta informații atât despre ofertele de pachete ERP disponibile pe piață cât și despre firmele care se ocupă cu crearea și implementarea de pachete software.

Fezabilitatea economică a implementării unui astfel de pachet rezultă în principal din (ROI-Return On Investment), adică timpul și procentul de recuperare al investiției.

Cererea de ofertă a unui sistem de tip ERP va reuni cerințele esențiale ale companiei, iar în funcție de aceste cerințe, firma furnizoare va putea face oferta.

Evaluarea resurselor hardware este procesul prin care firma furnizoare de soluții ERP va putea inventaria tehnologia deja existentă, tot în ideea de a mai reduce costurile de achiziție.

Vizitele de lucru ale furnizorilor ERP – constituie o oportunitate pentru ca aceștia să înțeleagă modul de desfășurare a activității economice a firmei.

Demonstrații ale soluțiilor software – permit managerilor și acționarilor firmei să-și formeze opinii mai clare, să pună întrebări și să înțeleagă modul de funcționare a soluțiilor.

Sesiunile de planificare anticipată – Stabilesc informații detaliate despre domeniul acoperit, timpul și resursele necesare pentru a implementa soluția unui anume furnizor ERP. Sunt alese modulele de implementare și se discută timpul și resursele necesare.

Procesul de luare a deciziei – implică managerii și acționarii firmei care evaluează informațiile adunate. Decizia poate fi luată în unanimitate, dacă toată lumea votează aceeași soluție sau poate fi controversată, dacă sunt susținute două sau mai multe soluții.

Întocmirea și semnarea contractului între firma beneficiară și furnizorul ERP – semnarea contractului (pot fi contracte individuale pentru resurse hardware, software și service sau un singur contract ce reglementează situația tuturor resurselor) legiferează acordul formal între cele două părti de implementare a noului sistem .

Planificarea proiectului – punctul de pornire este planul întocmit în sesiunea de planificare anticipată, acesta fiind acum reevaluat, extins și completat. Rezultatul acestei faze se constituie în intrare pentru faza următoare.

Planificarea de detaliu – planul descrie modulele funcționale și planul de instalare, cu termene de realizare concrete. După detalierea tuturor componetelor, planul poate fi transpus în format electronic, cu ajutorul unei aplicații de management al proiectelor. Cel mai adesea se obține o Diagrama Gantt ce ilustrează calendarul proiectului.

Activitățile de instruire ERP – orele de instruire ERP au ca scop înțelegerea specificului unui sistem ERP de către membrii echipei din punct de vedere funcțional și modul concret în care interacționează cu funcțiunile economice.

Configurarea aplicațiilor – este sarcina furnizorului ERP, care se informează asupra modului de desfășurare a activității. Administrarea întrebărilor se poate face în trei moduri: manuală, semiautomată și automată. Pentru succesul implementării este esențial ca echipa proiectului și utilizatorii să fie edificați asupra soluției ERP, iar furnizorii asupra specificului firmei și activităților economice.

Stabilirea politicii de proiect – urmărește crearea unui cadru director pentru tratarea conflictelor, într-un document sunt specificate toate procedurile formale(regulile).

Discutarea rapoartelor – se concretizează în comparații între rapoartele curente și cele generate de noul sistem, din trei puncte de vedere: selecția datelor, ordonarea și afișarea lor. În cazul reproiectării proceselor economice, modificările de fluxuri generează schimbări în partea de raportare . Sunt discutate modificările și este stabilit noul format.

Maparea funcțională – au loc activități cu un caracter interactiv și presupun mai multe discuții; este necesară vizualizarea modificărilor și a rezultatelor pe parcurs prin reprezentarea grafică a fluxurilor.

Prototipizare și testare- sunt preluate rezultatele fazei de mapare funcțională pentru a stabili dacă pachetul de programe acoperă harta funcțională schițată.

Modificarea și adaptarea cerintelor – asigură extinderea caracteristicilor funcționale ERP. Modificările sunt operate după ce maparea funcțională și prototipizarea au demonstrat că aplicația nu poate realiza funcția respectivă.

Conversia datelor – este una dintre cele mai “sensibile” faze ale proiectului, datorită dificultății de a prelua datele din bazele de date curente în noul sistem. Se operează, de regulă, cu două modalitați de conversie: introducerea manuala (deși consumatoare de timp, are avantajul asigurării integrității datelor prin testare, ceea ce nu se întâmplă la conversia electronică) și introducerea automată (conversia automată). Se pot folosi utilitare de conversie a bazelor de date dacă este certă integritatea datelor din baza de date a firmei. Asigurarea integrității este foarte importantă deoarece absența ei poate compromite funcționalitatea aplicației, iar haosul din bazele de date poate dura luni de zile (ținând cont de numărul mare de elemente interdependente ale bazei de date).

Planurile de urgență – se referă la situațiile de criză (coruperea bazei de date în faza de lansare a sistemului, pierderea suportului conducerii executive ori a sprijinului financiar, apariția de probleme tehnice insurmontabile în faza de prototipizare etc.). O importanță deosebită este acordată erorilor din partea finală a proiectului.

Documentația proiectului – este unul dintre cele mai importante mijloace de comunicare. Documentarea fazelor temperează elanul membrilor echipei, care trebuie să gândească și să exprime în scris activitățile derulate.

Instruirea utilizatorilor finali – se realizează în funcție de zona funcțională acoperită, fiecare învățând funcționalitățile pe care le va utiliza. Sunt oferite utilizatorilor manuale de instruire.

Auditarea – este activitatea desfășurată în paralel cu proiectul. Scopul său este asigurarea derulării proiectului conform planurilor, respectarea termenelor și încadrarea în buget. Există câteva momente cheie, importante pentru auditare: preimplementare, implementarea si postimplementare. De obicei, responsabilitatea auditului cade în sarcina echipei proiectului, chiar dacă furnizorul ERP și consultanții externi oferă asistentă.

Suportul postimplementare – include toate activitățile care susțin exploatarea noului sistem. Asistența este necesară datorită erorilor sau nesincronizărilor care apar în funcționalitatea aplicațiilor (adesea generate de programele de conversie a datelor).

Instruirea continuă și întreținerea –sunt menite să protejeze investiția în noul sistem. Întreținerea continuă este o concretizare a suportului postimplementare. Instruirea are loc, în primul rând în cadrul firmei, prin instruire încrucișată și chiar rotația cadrelor.

Motivația fiecărei organizații pentru alegerea ERP influențează strategia de implementare și pune în evidență trei mari categorii de motive:

Tehnice – aplicații izolate, platforme învechite față de prezentul tehnologic (vechile aplicații din ce în ce mai greu de întreținut, mai ales datorită costurilor mari, trebuie înlocuite cu o platforma IT comună, care asigură integrarea sistemului).

Operaționale – îmbunățirea proceselor, vizibilitea informațională, reducerea costurilor operaționale (adoptate de către organizațiile care sunt dispuse să opereze modificări ale proceselor economice).

Strategice – îmbunătățirea relațiilor cu clienții, restructurarea afacerii, standardizarea multilocație, nevoia de eficiență și integrare (această abordare poate asigura organizației obținerea de avantaje competitive, care îi îmbunătațesc poziția pe piață).

Primele studii privind implementarea proiectelor ERP au delimitat două tipuri inițiale de abordări: strategia ,,Big Bang" și strategia pe faze, iar ulterior s-au conturat alte strategii. În continuare sunt prezentate, pe scurt, câteva strategii de implementare ale sistemelor ERP:

1. Proiectele de avengură aleg, de regulă, strategia cu riscuri minime. Presupune parcurgerea tuturor pașilor și activităților descrise pe parcursul unei perioade de timp extinse (aproximativ 2 ani).

2. Strategia de buget urmărește implementarea noului sistem cu un buget cât mai mic, numărul activităților fiind redus datorită faptului că sunt eliminate activitățile consumatoare de resurse. Nu constituie o prioritate implementarea rapidă, ci încadrarea într-un anumit buget.

3. Strategia „Big Bang” este o metodologie rapidă, ușoară și presupune costuri minime. Reunește doar elementele de bază, eliminând multe activități din dorința de a reduce timpul de implementare și costurile. Conversia datelor se face de obicei manual, pentru a nu se pierde timpul cu elaborarea de programe de conversie electronică. Această strategie este aleasă atunci când se au în vedere implementări rapide.

4. Strategia cu forțe proprii presupune folosirea echipei proprii de specialiști (analiști și programatori) pentru a dezvolta un sistem ERP de „la zero”. Numărul de activități este mic, dar se regăsesc activitățile specifice dezvoltării sistemelor ERP: cele de analiză, mapare funcțională, prototipizare și modificare a aplicațiilor. Succesul depinde în mare măsură de priceperea și cunoștințele echipei de specialiști.

5. Strategia „la cheie” are aceeași structură și secvență de activități ca și strategia riscurilor minime. Diferența apare la planificarea și derularea propriu-zisă a activităților care sunt realizate cu resurse externe. Apar probleme la punerea în funcțiune și preluarea sistemului de către utilizatori.

6. Strategia de parteneriat se deosebește de alte strategii prin faptul că responsabilitățile proiectului sunt partajate de beneficiar și de către partenerii săi. Proiectul beneficiază astfel de cunoașterea și experiența acumulate de firmele partenere de implementare, iar pe de altă parte, organizația beneficiară este implicată activ în activitățile proiectului.

Obiectivul major ale unui pachet ERP este înlocuirea concretă a vechiului sistem cu cel nou. Astfel s-au luat în calcul 3 etape de tranziție: integrală, pe faze, paralelă sau hibridă.

a. Strategia integrală înseamnă că, la un moment dat, vechiul sistem va fi înlocuit complet cu noul sistem, iar funcțiunile care până în acel moment erau în sarcina vechilor aplicații, vor trece în totalitate în sarcina noului sistem. Această strategie nu este recomandată de furnizorii de pachete ERP, și este cea mai puțin utilizată, deoarece implică foarte multe resurse care trebuie planificate până la cel mai mic detaliu, chiar dacă de remarcat este faptul că această strategie nu implică și costurile aplicațiilor de legătură între noul și vechiul sistem. Ca o concluzie, putem spune că această strategie este viabilă doar în cazul proiectelor mici, unde informația se poate ține ușor sub control, iar proiectul are un termen limită restrâns.

b. Strategia pe faze care poate fi numită și secvențială sau modulară, schimbă aplicațiile și modulele pe rând. Modul acesta de tranziție impune și folosirea aplicațiilor de interfață, până în momentul în care noile module devin complet funcționale.

Proiectul începe prin alegerea unui prim modul care va fi integrat (de exemplu, aplicația care se ocupă de transport și logistică) restul funcțiunilor fiind în continuare rulate de vechile aplicații. Pe urmă, în ordinea hotărâtă de beneficiar, urmează celelalte module, care vor fi instalate în mod secvențial.

Cele mai multe dintre întreprinderi consideră această strategie ca cea mai lipsită de riscuri, dar această abordare are și dezavantaje, cum ar fi o perioadă considerabilă de timp în efectuarea tranziției, sau achiziționarea aplicațiilor de conversie, trantiție și de preluare a datelor.

c. Strategia paralelă este abordarea care implementează noul pachet software în același timp în care organizația încă funcționează pe vechiul pachet. Principalele avantaje ale acestei strategii este perioada scurtă de implementare, care poate avea o minimă de o zi, și faptul că, în cazul eșecului noului sistem, datele nu se vor pierde sau altera. Astfel, dacă cele doua sisteme lucrează într-un mod paralel, până la validarea noului sistem, niciuna dintre activitățile întreprinderii nu va fi afectată. Dezavantajul major îl reprezintă volumul mare de resurse necesare, erorile datorate utilizatorilor nefamiliarizați cu sistemul, și suprasolicitarea bazei de date, care va fi nevoită să ofere asistență ambelor pachete software. În concluzie, această strategie este recomandată în principal firmelor mari, și ale căror bugete le permit să abordeze o astfel de strategie.

5. AVANTAJELE UTILIZĂRII UNUI SISTEM ERP

Principаlele аvаntаje аle folosirii unui ERP în cаdrul unei compаnii sunt :

Informаțiа este introdusă în sistem o singură dаtă într-o bаză de dаte foаrte complexă;

Obligă lа folosireа "celor mаi bune prаctici" din industrie;

Permite personаlizări;

Funcționeаză pe o structură fiаbilă de fișiere;

Furnizeаză funcționаlități pentru interаcțiuneа cu аlte module;

Furnizeаză instrumente pentru interogări și rаpoаrte аd-hoc.

Sistemele ERP furnizeаză informаții pentru conducere și аnаlize pentru orgаnizаții, iаr cele cinci beneficii mаjore аle sistemelor ERP sunt:

informаții on-line/în timp reаl pentru toаte аriile funcționаle аle unei orgаnizаții;

stаndаrdizаreа dаtelor și аcurаtețe lа nivel de întreprindere;

аplicаțiile includ cele mаi bune prаctici din industriа respectivă;

eficiențа pe cаre o înregistreаză compаniа;

аnаlizele și rаpoаrtele ce pot fi folosite lа plаnificări pe termen lung.

Conform sursei http://www.cio.com/reseаrch/erp/edit/erpbаsics.html#erp_аbc sunt cinci motive mаjore pentru cаre compаniile doresc să preiа ERP-ul:

5.1. Integrarea informațiilor financiare

În timp ce mаnаgerii înceаrcă să înțeleagă performаnțа globаlă а compаniei, se pot găsi diferite versiuni аle reаlității. Depаrtаmentul Finаnciаr аre un set de vаlori reprezentând venitul, Depаrtаmentul Vânzări un cu totul аltul și аlte diferite depаrtаmente pot аveа fiecаre o versiune diferită despre propriа contribuție lа venitul totаl аl compаniei. Sistemul ERP creeаză o singură versiune а reаlității pe cаre nimeni nu o poаte contestа pentru că toți folosesc аcelаși sistem.

5.2. Integrarea informațiilor corespunzătoare comenzii clientului

Sistemul EPR poаte deveni locul unde comаndа clientului este înregistrаtă, trimisă de la CSR (Customer Service Representаtive) lа Depаrtаmentele Finаnciаr și Comerciаl, generând emitereа unei fаcturi corespunzătoаre cаre vа аjunge în finаl lа CSR. Având аceаstă informаție într-un singur sistem, în loc să fie căutаtă în diferite аlte sisteme cаre nu pot comunicа între ele, compаniile pot ține evidențа și urmări stаdiul unei comezi mult mаi ușor, putând coordonа producțiа, inventаrul și direcționаreа informаției către mаi multe depаrtаmente în аcelаși timp.

5.3. Standardizarea și eficientizarea procesului de producție

Compаniile de producție se аflă de multe ori în situаțiа cа diferitele depаrtаmente аle compаniei să аjungă lа rezultаte diferite folosind sisteme și metode computerizаte diferite. Sistemele ERP implică un sistem cаre conține metode stаndаrdizаte pentru аutomаtizаreа unorа dintre pаșii efectuаți în procesul de producție. Stаndаrdizаreа аcestor procese și folosireа unui singur sistem integrаt poаte conduce lа o utilizаre mаi eficientă а timpului, creștereа productivității și reducereа erorilor umаne.

5.4. Reducerea inventarului

Un sistem ERP аjută cа desfășurаreа unui proces de producție să se fаcă mult mаi ușor. Acestа poаte conduce lа diminuаreа inventаrului corespunzător personаlului folosit în procesul de producție (inventаr аl muncii în proces) și poаte аjutа utilizаtorii sistemului să plаnifice mаi bine îndeplinireа comenzilor, reducând inventаrul bunurilor cаre аu trecut prin întreg stаdiul producției, аflându-se în cаdrul stocurilor existente. Pentru а îmbunătăți cu аdevărаt flexibilitаteа rețelei de аprovizionаre și distribuire, este nevoie de un softwаre “rețeа”, iаr ERP-ul аjută lа аcest lucru.

5.5. Standardizarea informațiilor din Departamentul de resurse umane

Mаi аles în interаcțiunile cu аlte diferite depаrtаmente din cаdrul compаniei, Depаrtаmentul de Resurse Umаne poаte să nu аibă o metodа simplă pentru găsireа аngаjаților și pentru а comunicа cu ei despre servicii și beneficii. Sistemul ERP poаte îmbunătăți аcest lucru.

Producțiа este cel mаi importаnt proces în lаnțul vаlorii într-o întreprindere producătoаre, iаr cаlitаteа și competitivitаteа pe piаță а produselor rezultаte din procesul de producție este esențiаlă. Pentru îndeplinireа аcestor deziderаte este esențiаlă eficiențа sistemului informаtic de gestiune а аctivității. Numаi implementаreа unei soluții informаtice perfect modelаte pe specificul аctivităților unei întreprinderi producătoаre poаte аsigurа premisele competitivității аcesteiа.

Avаntаjul cel mаi importаnt аl unui sistem informаtic integrаt (ERP) constă în gestionаreа în mod unic а tuturor cаtegoriilor de dаte și а informаțiilor specifice beneficiаrului.

5.6. Factorii de risc

În privința riscurilor, se întâmplă adesea ca bugetele alocate și/sau termenele prevăzute să fie cu mult depăsite – unii analiști apreciază că aproximativ jumătate din proiectele ERP nu reușesc să atingă obiectivele propuse.

În majoritatea cazurilor, eșecul implementării unui pachet de aplicații integrate s-a datorat problemelor organizaționale. Într-un top al motivelor se regăsesc:

tratarea ERP ca pe un sistem software;

lipsa implicării managerilor executivi (top-manageri);

concentrarea eforturilor pe instalarea software-ului și pe “invățarea” acestuia;

așteptări nerealiste în privința duratei de implementare;

utilizarea sistemelor ERP pentru colectarea, prelucrarea datelor și obținerea informațiilor;

neimplicare și neacceptare din partea utilizatorilor;

implementări realizate de consultanți și specialiști externi;

lipsa pregătirii psihologice corespunzătoare a utilizatorilor;

comunicare defectuoasă între membrii echipelor de proiect;

proiectul nu a fost pregătit corespunzător ori resursele necesare dezvoltării sale au fost insuficiente.

Factori de risc în proiecte ERP

Având în vedere costurile destul de mari pe care le implică achiziționarea unui ERP, era firesc să întrebăm ce riscuri presupune investiția într-o asemenea soluție. Extrem de interesant este punctul de vedere al furnizorilor, aproape toți considerând că riscurile vin din partea clientului și nu din partea companiilor care se ocupă de implementare.

SAP este de părere, de exemplu, că principalul risc ține de necunoașterea domeniului și de neglijarea anumitor criterii de alegere a soluției ERP. Mulți manageri urmăresc exclusiv prețul de achiziție, fără să țină seama de alți factori. De aceea, există riscul de a alege o soluție nepotrivită necesităților companiei, o soluție care nu poate susține, pe termen lung, creșterea afacerii, o soluție insuficient testată care poate genera probleme de stabilitate, funcționalitate sau extindere.

Primul pas pentru o implementare de succes este alegerea unei soluții performante, apropiată de specificul de activitate al clientului astfel încât nivelul de configurare să fie minim, o soluție care să fie confirmată de referințe pe piața românească. Printr-o comunicare adecvată între cele două echipe de proiect, problemele legate de implementare pot fi evitate.

Pe lângă situațiile în care managementul companiei-client nu susține proiectul sau șefii de compartimente nu se implică suficient în implementarea și utilizarea soluției sau personalul nu cunoaște și nu înțelege necesitatea și beneficiile trecerii de la aplicațiile individuale la soluțiile integrate, au fost identificate și o serie de puncte critice care apar pe parcursul implementării unei soluții ERP:

în primul rând nu se acordă suficientă atenție procesului de analiză a nevoilor, adevăratele necesități apărând mult mai târziu, pe parcursul implementării.

în al doilea rând, se așteaptă ca verificarea rezultatelor să se facă de către implementator, ceea ce este complet greșit; fiecare utilizator final trebuie să verifice rezultatele activității de care răspunde.

nu în ultimul rând, tergiversarea renunțării la aplicațiile vechi: deși nu este indicat să se lucreze în paralel mai mult de două luni de zile, clienții continuă această practică până la jumătate de an.

Deosebit de important este faptul că eșuarea unei implementări nu înseamnă numai pierderea investiției materiale în soluția ERP. Efectele negative se resimt în deteriorarea relației cu clienții, cu angajații sau în pierderea cotei de piața și de imagine. De aceea se recomandă alegerea unui partener cu experiență, capabil să prevadă și să combată aceste riscuri.

Reticența clientului la sugestiile furnizorului de ERP constituie un risc deloc de neglijat. Se presupune că o companie serioasă deține un backgroud solid pentru a putea propune practici eficiente de afaceri și modalități de îmbunătățire a mediului de lucru. Însă, în condițiile în care clientul nu este deschis la propunerile furnizorului, există riscul ca practicile greoaie utilizate până în acel moment să se perpetueze în noul sistem, scăzându-i valoarea.

6. STUDIU DE CAZ

În continuare vom detalia principala aplicație de urmărire a cazurilor dintr-o companie multinațională, care deține un număr de aproximativ 10000 de angajați, cu filiale în 25 de țări și o cifră de afaceri de 672,7 milioane de euro. Și niciodată nu s-ar fi ajuns la aceste cifre dacă tehnologia împreună cu sistemul informatic folosit nu ar fi fost proiectate și apoi implementate urmându-se cele mai înalte standarde.

Deoarece pune foarte mare preț pe tehnologie, comapania a investit și investește constant în crearea de noi aplicații care să îmbunătățească fluxul proiectelor și al documentelor aflate în circulație, dar are grijă în același timp ca aplicațiile deja aflate în uz să fie updatate în permanență, urmărindu-se cu foarte mare atenție standardizarea continuă a fiecărui pas din activitățile angajaților.

Bineînțeles că înafară de aplicația de care vom vorbi in paginile ce urmează, compania mai deține un numar impresionant de alte aplicații care sunt dezvoltate pentru fiecare departament în parte, și care sunt interconectate între ele, culegând date și creând rapoarte constante despre activitățile zilnic efectuate de către persoanele responsabile din departament.

În continuare voi enumara câteva dintre aplicațiile care, din punctul meu de vedere, sunt indispensabile pentru a crea și menține un bun management în companie, prin administrarea în cel mai eficient mod posibil a resurselor umane, financiare și de timp.

Charisma – această aplicație este folosită în egală măsură atât de către personalul din departamentul de Resurse Umane, care este direct responsabil de updatarea și corectitudinea datelor conținute, cât și de angajații companiei, care o folosesc pentru înregistrarea cererilor de concediu, obținerea fluturașului de salariu și verificarea numarului de bonuri de masă pe care le vor primi, urmărirea evidenței soldului de concediu, analizarea beneficiilor medicale folosite și rămase, obținerea unei copii ale oricărui document cu care angajatul este înregistrat în companie (C.I., diplomele aduse, contractele și actele adiționale semnate), precum și a posturilor vacante. De menționat este că această aplicație este utilizată și ca mijloc de comunicare între angajați și departamentul de Resurse Umane, cei dintâi putând să înregistreze tot aici cererile pentru eliberarea de diferite adeverințe, sau cererile de învoire atunci când este cazul, iar cei din urmă putând să transmită angajaților diverse cupoane promoționale, avantaje contractate la diferite companii farmaceutice, bănci, sau chiar telecomunicații, concursurile care vor avea loc la nivel de companie, și diverse alte anunțuri atât interne cât și externe.

CA (Current Activities) este aplicația care ține cu o exactitate de ceas elvețian evidența orelor lucrate și a pauzelor luate de către angajați, oferă superiorilor rapoarte despre activitatea acestora și este conectată în permanență la batch-urile de deblocare a ușilor din interiorul companiei pentru o indentificare ușoară a locului exact în care se află angajatul atunci când nu se regăsește la birou. De asemenea, această aplicație mai oferă datele și către urmatoarea aplicație:

Schedduling – această aplicație este folosită de personalul departamentului Financiar, care calculează salariile lunare, bonusurile obținute și face plata către compania care se ocupă cu virarea bonurilor de masă.

AnyTimeCRM – este aplicația de care se pot folosi atât angajații care dețin cel puțin o funcție de răspundere pentru a putea solicita diverse lucruri de care au nevoie, cat și cei care rezolvă aceste taskuri. Astfel, dacă există o problemă tehnică, se va pune task la departamentul IT, și se va aștepta venirea unui specialist pentru a rezolva problema; dacă există informații de importat în sistem, se va indica sursa și se va pune task; dacă există documente de indexat și inventariat, se va pune task, iar departamentul responsabil va asigna o persoană care va veni să ridice, scaneze, inventarieze și să indexeze cazurile, pentru ca mai apoi să revină cu documentele; și la fel se va proceda și în cazul în care se dorește generarea unui raport, extragerea sau corectarea informațiilor și documentelor, montarea și demontarea de echipamente, generarea de analize și prezentări, sau chiar și pentru transportul angajaților către diferite locații externe firmei. De menționat este faptul că aplicația este gândită în așa fel încăt să administreze în cel mai eficace mod toate necesitățile angajaților companiei, având capacitatea de a calcula singură gradul de prioritate a cazurilor, folosindu-se de 3 module: gradul de urgentă al taskului (critical, urgent, major, day time, nul), principiul “primul venit, primul servit” și timpul aproximativ acordat rezolvării problemei.

Kollecto – este aplicația în jurul căreia se învărte întreaga activitate de profil a firmei în discuție, aceasta cumulănd toate informațiile despre cazurile companiei la nivel de persoană sau societate, poate genera rapoarte, calcula rate și retrimite cazurile în lucru atunci când se îndeplinesc termenele aplicate. De această aplicație se folosesc toate departamentele companiei, cu preponderență departamentul Legal și Collection, a căror principală activitate este de a urmări și lucra cazurile cu debite restante, dar și departamentul de Data Entry, care este responsabil de adăugarea datelor și documentelor în sistem pentru fiecare debitor în parte. Astfel, o dată accesat un caz, tot în această aplicație se vor putea verifica și toate documentele aferente cazului, de la documentele de indentificare, până la declarații și plăți efectuate. Acest lucru se realizează cu corelarea acestei aplicații la cea de care vom vorbi în rândurile ce urmează:

ELO – este aplicația folosită pentru indexarea documentelor electronice în sistem. Această aplicație este în permanență conectată la aplicația Kollecto, deoarece este semnificativ mai simplu să putem avea toate informațiile și documentele într-o singură aplicație. Această aplicație este capabilă să indexeze automat documentele într-un mod foarte simplu, folosindu-se doar de un fisier tip CSV în care se vor indica două chei unice de căutare aferente numelui documentului pe care dorim să îl indexam.

Kokpit – este aplicația de care se folosesc în exclusivitate persoanele cu funcție de conducere, care au obligația de a realiza rapoarte trimestiale despre activitățile și productivitatea angajaților de care sunt responsabili. Astfel, aceasta aplicatie se va afla instalată pe calculatorul fiecărui angajat, iar in funcție de departamentul în care se desfășoară activitatea, va supraveghea timpul alocat muncii. Mai exact, instalat pe calculatorul unui angajat din departamentul Collection, unde activitatea sa principală este apelul către debitor, aplicația va contoriza timpul acordat fiecărui apel în parte, va urmări existența cuvintelor cheie precum nume de localități, numere de telefon și decibelii până la care s-a ridicat tonul, și va efectua apeluri aleatorii debitorilor pentru oferirea de feedback. În cazul în care activitatea se desfășoară în departamentul legal, această aplicație va urmări numarul de clicuri date, de apeluri efectuate și raportul mailuri primite – mailuri date, pentru a putea calcula promptitudinea cu care se raspunde la solicitări. În acest mod, superiorii vor putea avea sub supraveghere un numar foarte mare de angajați fără a-i avea în permanență în raza vizuala și îi va scuti de discuții lungi cu acestia, aceste lucruri putând fi înlocuite cu scoaterea imediată a unui raport.

6.1. APLICAȚIA WEB KOLLECTO

Aplicația Web Kollecto reprezintă interfața de relaționare între societate și clienții acesteia.

6.1.1. Logarea utilizatorilor în sistem (Figura 1)

Se accesează din Internet Explorer pagina online.

Se vor completa câmpurile:

Utilizator – numele de utilizator

Parola – parola utilizatorului.

Conturile și parolele pentru utilizatorii aplicației Web Kollecto sunt identice cu cele din aplicația Kollecto.

La apăsarea butonului Inregistrare, utilizatorul este logat în sistem.

Figura 1 Interfața Web Kollecto

6.1.2. Schimbare parolă

Utilizatorul poate să își schimbe parola în orice moment prin adresarea unei cereri către departamentul IT.

6.2. MENIUL HOME

În acest meniu utilizatorului îi este prezentat scopul pentru care a fost creat WEB Kollecto. În plus sunt punctate principalele funcționalități ale portalului. (Figura 2)

Figura 2 Prima pagină

În principal, sistemul Web Kollecto reprezintă soluția pe care compania o oferă pentru a se avea acces direct la situația cazurilor fiecărui client în parte.

Portalul oferă informații referitoare la cazurile propuse de EOS KSI pentru recuperare pe teren sau în instanță.

În același timp, Web Kollecto asigură fluxurile necesare de informații privind problemele operaționale care trebuie soluționate și oferă posibilitatea de generare a rapoartelor de activitate.

6.3. MENIUL INFO CLIENT

Meniul cuprinde date referitoare la contul clientului în sistem și modalitatea de a lua legătura cu reprezentanții EOS KSI România. În plus apar detalii referitoare la numărul total de cazuri trimise, numarul de cazuri deschise și valoarea acestora.

Detaliile afișate în acest meniu sunt urmatoarele:

1. Persoana de contact EOS KSI România:

Nume

Telefon

Email

2. Detalii Client:

Nr. Registru

CUI

Atribut Fiscal

Adresa

Industrie

3. Persoana de Contact:

Prenume

Nume

Oraș

Telefon

Fax

4. Detalii Bancare:

Banca

Cont

5. Detalii Cazuri:

Cazuri trimise și valoare (RON)

Cazuri active și valoare (RON)

Utilizatorii de legal/ field nu vor avea acces la acest tab.

6.4. MENIUL CĂUTARE

În secțiunea Căutare Caz (Figura 3), utilizatorul poate căuta date precise referitoare la cazurile aflate în lucru, după mai multe criterii. Aceste criterii sunt:

CEID

Vechime Caz (<, <=, =, >=, >)

Balanță Totală (<, <=, =, >=, >) exprimată în moneda funcțională

Cod Fiscal/CNP

Client (cu posibilitatea de alegere dintr-un combo box)

Adresa

Număr client

Nume și Prenume

Nr. Contract

Zona (cu posibilitatea de alegere dintr-un combo box)

Sistemul va lista toate cazurile găsite în baza de date ce corespund criteriilor de căutare introduse de utilizator. Dacă rezultatele găsite depășesc 20 de cazuri, acestea vor fi afișate pe mai multe pagini. Toate rândurile găsite se pot vizualiza prin intermediul butoaneler de navigare între pagini: butonul Anterior si butonul Următor.

Figura 3 Meniul Căutare

Informațiile afișate în urma unei căutări sunt:

CEID

Account ID

Subscriber ID

Balanță Totală

Vechime Caz

Nume și prenume

Adresă

Client

Customer ID

Nr. Contract

Tip Debitor

Responsabil caz

Utilizatorul are posibilitatea de a sorta în ordine crescătoare sau descrescătoare, rândurile afișate în urma unei căutări în funcție de câmpurile din capul de tabel. Pentru a deschide un anumit caz din lista găsită, utilizatorul trebuie să apese butonul Vizualizare, corespunzător liniei dorite (prima coloană din stânga).

Sistemul va deschide o nouă fereastra Detalii Caz.

6.5. PROCEDURA DE LUCRU A CAZURILOR IN WEB KOLLECTO

6.5.1. Ierarhia Web Kollecto (Figura 4)

În Web Kollecto, din punct de vedere ierarhic, un caz este structurat pe 3 nivele:

Collection Entity

Account

Persoană

Figura 4 Ierahia la nivel de persoană

Collection Entity (CE) reprezintă entitatea la care se face colectarea în sistemul de collection. Consolidarea reprezintă aducerea cazurilor sub un CE dupa diverse criterii de consolidare, creându-se astfel un CE cu account-urile care îndeplinesc regulile stabilite.

Account (ACC) reprezintă entitatea la nivelul căreia apar informațiile legate de debite.

Persoana reprezintă entitatea care conține informații legate de datele cu caracter personal ale debitorilor. La acest nivel pot exista mai multe persoane atașate aceluiași caz, în dreptul fiecăreia specificându-se între paranteze tipul persoanei: titular sau girant.

De un caz este obligatoriu să fie atașată o singură persoană de tip titular și pot fi atașate mai multe persoane de tip girant. Persoana de tip girant nu este obligatoriu să existe într-un caz.

Indiferent de criteriul de căutare, la deschiderea unui caz se va afișa nivelul Persoană. Dacă cel puțin una din persoanele cazului (titular sau girant) este atașata la mai multe cazuri (CEID-uri), în ierarhie se vor vedea toate cazurile legate de persoana respectivă (Figura 5).

Figura 5 Ierarhia la nivel de CEID

Atunci când un caz este căutat după CEID, modul de afișare a rezultatelor depinde de numărul entităților de tip Account și Persoane legate de acel CEID.

CEID cu 1 Account și 1 Persoană întoarce un singur rând cu urmatoarea combinație CEID – Account – Persoană.

CEID cu 2 Account-uri și 1 Persoană întoarce 2 rânduri pentru urmatoarea combinație: CEID – Account 1 – Persoană și CEID – Account 2 – Persoană. Aceeași regulă se urmează dacă sunt mai multe Accounturi și o singură Persoană.

CEID cu 1 Account și 2 Persoane întoarce 2 rânduri cu urmatoarea combinație CEID – Account – Persoana 1 si CEID – Account – Persoana 2. Aceeași regulă se urmează dacă există un singur Account și mai multe Persoane.

CEID cu 2 Accounturi și 2 Persoane întoarce 4 rânduri după urmatoarea combinație CEID – Account 1 – Persoana 1, CEID – Account 1 – Persoana 2, CEID – Account 2 – Persoana 1, CEID – Account 2 – Persoana 2.

6.5.2. Fereastra Detalii Caz

Această fereastră este împărțită în două zone:

Zona statică

Zona dinamică.

6.6. ZONA STATICĂ

În această zonă structura taburilor, a câmpurilor și butoanelor nu se modifică nici dacă se trece de la un nivel la altul. Aceasta este împărțită în două secțiuni:

Secțiunea superioară care conține:

Ierarhia unui caz;

Câmpurile statice:

Suma (valoarea de colectat la data încărcării în Kollecto),

Status (utilizatorul de Legal/ Field poate vizualiza statusurile specifice procedurii de colectare Legal/ Field)

Data Status,

Responsabil caz,

Client,

Balanța (suma rămasă de colectat la momentul deschiderii cazului),

TO Prelegal (data încărcării cazului pentru prima dată în sistem),

TO Field (data trecerii cazului în zona Field),

TO Legal (data trecerii cazului în zona Legal),

Zona (starea în care se află cazul – Prelegal, S04, Wait Legal, Field, Legal, Black);

Butoanele pentru adăugarea de acțiuni, comentarii, PA-uri și acțiuni recurente;

Lista de cozi și rezoluții;

Butonul Înapoi al cărui rol este de a închide fereastra Detalii Caz fără ca vreo rezoluție să fie salvată în caz.

Secțiunea inferioară care conține doua taburi:

Tabul de Comentarii pentru toate nivelele;

Tabul Strategie cu acțiunile trecute, acțiunile viitoare și detaliile referitoare la angajamentele de plată create pe cazul respectiv.

6.6.1. Operații în secțiunea superioară a zonei statice

Acțiuni în zona statică:

se apasă butonul Acțiune, ce are ca efect deschiderea ferestrei Generare Acțiune (Figura 6);

se selectează acțiunea dorită din combo-box-ul Acțiune;

se apasă butonul Generează;

în cazul în care se dorește anularea operației de adăugare a acțiunii, se apasă butonul Anulează.

Figura 6 Generarea unei acțiuni în zona statică

6.6.2. Adăugarea unui comentariu

se apasă butonul Comentariu, ce are ca efect deschiderea ferestrei Add new comment (Figura 7);

se alege din combo-box-ul Clasa comentariu, tipul clasei din care face parte comentariul care se dorește a se adăuga;

se selectează numele comentariului care urmează a se introduce din combo-box-ul Cod;

se selectează data calendaristică (zi.luna.an) pentru realizarea efectivă a comentariului (în mod implicit se afișează data curentă; dacă se dorește introducerea unei date calendaristice din trecut, se modifică);

în caseta Comentariu utilizator se introduce comentariul dorit;

se apasă butonul Generează;

în cazul în care se dorește anularea operației de adăugare a unui comentariu, se apasă butonul Anulează.

Figura 7 Adăugarea unui comentariu

6.6.3. Crearea unui angajament de plată (PA) (Figura 8)

PA-ul (Payment Agreement) reprezintă un aranjament de plată stabilit de responsabilul de caz în urma unei negocieri cu debitorul.

Butonul PA este inactiv dacă la momentul deschiderii cazului există un PA în curs de desfășurare (PA cu status Pending).

Se apasă butonul PA, care are ca efect deschiderea ferestrei Creare Angajament de Plată Nou ce contine două secțiuni: PA Info și Rate PA.

Sectiunea PA Info

În secțiunea PA Info se bifează tipul Pa-ului: parțial sau total. Dacă se creează un PA total, se vor activa câmpurile Motiv Reducere și Valoare Reducere, existând astfel posibilitatea creării unui PA cu reducere din diverse motive.

La deschiderea ferestrei Creare Angajament de Plata Nou, câmpul Sumă este completat automat de sistem cu valoarea balanței cazului la momentul respectiv. Dacă PA-ul este de tip total, atunci câmpul Sumă nu trebuie modificat. Dacă PA-ul este de tip parțial, atunci câmpul Sumă se completează manual de către utilizator cu o valoare mai mică decât balanța.

Se selectează din combo-box-ul Tip PA, tipul angajamentului de plată; în funcție de tipul PA-ul selectat, înainte sau după data scadentă a ratelor se vor executa diverse acțiuni (spre ex. cu 2 zile înainte de data scadenței sistemul va executa automat acțiunea de Outbound).

În funcție de tipul PA-ului selectat de către utilizator, în mod automat sistemul va selecta Comentariu PA.

În caseta Comentariu se pot introduce diverse observații ale utilizatorului.

Secțiunea Rate PA

Se completează câmpul Număr rate care determină în mod automat completarea câmpului Propunere valoare rată (valoarea rotunjită a ratei);

Se selectează tipul ratelor din combo-box-ul Tip care poate avea urmatoarele valori: lunar, bilunar, săptămânal (monthly, bymonthly și weekley);

Se selectează ziua de scadență a ratelor din combo-box-ul Ziua. Pentru ratele bilunare trebuie completate zilele de scadență din combo-box-urile Ziua și Ziua2;

În câmpul Data începere se selectează din butonul Calendar data calendaristică după care să se înceapă generarea ratelor (spre ex. dacă se selectează ca zi de scadență data de 25, iar ca dată de începere 01.09.2008, prima rată generată va avea scadența pe 25.09.2008).

Se apasă butonul Generate care are ca rezultat afișarea în stânga jos a ferestrei, a rândurilor corespunzătoare fiecărei rate în parte, cu detaliile legate de data scadentă și valoarea acesteia. În dreptul fiecărui rând de rate afișate, apar butoanele: Editare și Ștergere. La apăsarea butonului Editare corespunzător unei rate, se deschide fereastra Editare Rate PA care oferă posibilitatea modificării datei scadente și valorii unei rate. Dacă se modifică valoarea unei rate, trebuie modificate și valorile celorlalte rate astfel încât suma tuturor ratelor să fie egală cu suma inițială a PA-ului.

La final, după ce se completează toate detaliile PA-ului se apasă butonul Creare din dreapta sus a ferestrei Creare Angajament de Plată Nou. Dacă vreunul dintre câmpurile completate nu are valori valide, la apăsarea butonului Creare se va afișa un mesaj de eroare și nu i se va permite utilizatorului crearea PA-ului (spre ex. dacă suma ratelor stabilite nu este egală cu suma inițială a PA-ului).

Figura 8 Crearea unui angajament de plată

6.6.4. Crearea unei acțiuni recurente (Figura 9)

se apasă butonul Recurență, ce are ca efect deschiderea ferestrei Adăugare acțiune recurentă;

se selectează din combo-box-ul Acțiune, acțiunea dorită a se executa în viitor;

se completează în câmpul Data Execuție, data calendaristică la care se dorește să se execute acțiunea;

se apasă butonul Generează;

în cazul în care se dorește anularea operației de creare a acțiunii recurente, se apasă butonul Anulează.

Figura 9 Adăugarea unei acțiuni recurente

În cazul în care se dorește adăugarea mai multor acțiuni recurente, se repetă pașii enumerați anterior.

6.6.5. Secțiunea Cozi

Coada reprezintă o listă de cazuri care trebuie lucrate. În funcție de anumite criterii, cazurile pot fi în cozi diferite. Denumirea cozii este relevantă pentru modul în care vor fi lucrate cazurile care se află într-o anumită coada (spre ex. in coada Review Return Mail&Documents utilizatorii vor verifica ce documente s-au primit în cazuri și în funcție de aceste documente vor decide cum vor lucra cazurile în continuare).

În partea dreaptă din zona statică a ferestrei Detalii Caz (Figura 10) se află secțiunea Cozi. În această secțiune sunt afișate cozile în care se află cazul respectiv în momentul vizualizării acestuia.

Figura 10 Fereastra “Detalii Caz” din secțiunea “Cozi”

În dreptul fiecărei cozi se află un check-box, la apăsarea căruia se deschide fereastra Rezoluții. Din această fereastră utilizatorul bifează rezoluția pe care decide să o dea cozii respective.

Efectele celor 4 rezoluții care se pot da unei cozi sunt:

Move to Emergency – scoate cazul din coada în care se află și este trimis în coada de Emergency a responsabilului de caz;

Not Worked – cazul este scos din coada în care se află;

Postpone – cazul rămâne în acceași coadă, dar când va fi deschis din meniul Cozi va fi afișat cu culoarea albastră; când se selectează această rezoluție este necesar să se selecteze data, ora și minutul la care se dă rezoluția.

Worked – cazul este scos din coada în care se află.

Pentru ca rezoluția să se înregistreze se apasă butonul OK. Dacă se dorește abandonarea înregistrării rezoluției se apasă butonul Anulează sau se închide fereastra Rezoluții (Figura 11).

Figura 11 Fereastra “Rezoluții”

6.6.6. Tabul Comentarii (Figura 12)

Aici sunt afișate urmatoarele:

Comentarii introduse manual de către utilizatori;

Comentarii generate de execuția acțiunilor și recurentelor;

Comentarii generate de execuția acțiunilor de pe strategia cazului;

Comentarii generate de sistem.

În acest tab se afișează urmatoarele detalii ale comentariilor:

Data acțiune

Utilizator

Nume acțiune

Comentariu utilizator

Zona în care se află cazul la momentul introducerii comentariului

Data realizării

Figura 12 Tabul “Comentarii”

În acest tab, comentariile sunt afișate în ordinea invers cronologică a datelor acțiunilor. În cazul în care sunt mai mult de 10 comentarii înregistrate, atunci acestea vor fi afișate pe mai multe pagini. Toate rândurile de comentarii se pot vizualiza prin intermediul butoaneler de navigare între pagini: butonul Anterior și butonul Următor.

6.6.7. Tabul Strategie (Figura 13)

Tabul Strategie conține 3 secțiuni în care utilizatorul poate vizualiza detalii referitoare la cazul pe care l-a deschis. Acestea sunt:

acțiunile din trecut care s-au executat până la momentul deschiderii cazului;

acțiunile din viitor care urmează să se execute;

numărul de angajamente de plată care s-au creat în cazul respectiv indiferent de statusul acestora; de asemenea, se pot vizualiza detaliile ultimului angajament de plată, numai dacă acesta se află în curs de desfășurare (statusul PA-ului este pending);

Secțiunile Acțiuni Trecute și Acțiuni Viitoare sunt afisate sub forma unor tabele care conțin urmatoarele coloane:

Sursa acțiunii care poate fi:

Strategia (pentru acțiunile care au fost programate din timeline);

PA (pentru acțiunile prestabilite în cadrul unui angajament de plată);

Recurența (pentru acțiunile recurente stabilite de către utilizatori);

Ad-hoc.

Acțiune

Data acțiune

În secțiunea Acțiuni Trecute, acțiunile sunt afișate în ordine invers cronologică, iar în secțiunea Acțiuni Viitoare acțiunile sunt afișate în ordine cronologică. Acțiunile care sunt suspendate sunt colorate cu gri, iar acțiunile inactivate sunt colorate cu roșu.

Figura 13 Tabul Strategie

Utilizatorul poate modifica detalii referitoare la acțiunile viitoare astfel:

Se apasă iconița Editare care se află în dreapta pe fiecare rând al unei acțiuni din tabelul Acțiuni Viitoare; acest lucru are ca efect deschiderea ferestrei Modificare acțiune (Figura 14).

Pentru a modifica data de execuție a unei actiuni viitoare, se selectează din calendar noua dată și apoi se apasă butonul Modifică;

Pentru a inactiva acțiunea respectivă se apasă butonul Inactivare;

Pentru a șterge acțiunea respectivă de pe strategie se apasă butonul Șterge.

Se apasă butonul Anulează în cazul în care se dorește a se renunța la modificarea acțiunii viitoare.

Figura 14 Modificarea unei acțiuni

6.6.8. Secțiunea PA (Figura 15)

În cazul în care există un PA pending în cazul respectiv, în secțiunea PA sunt afișate valorile ratelor și datele scadente ale acestora.

Figura 15 Secțiunea PA

Tot aici, utilizatorul poate vizualiza istoricul cu toate PA-urile create pe cazul respectiv prin apăsarea butonului Vizualizează istoric PA (Figura 16). Acest istoric este afișat sub forma unui tabel care conține urmatoarele coloane:

Data PA – data la care a fost creat PA-ul de către utilizator;

Data scadentă – data scadentă a ultimei rate stabilite;

Semnat – este coloana care poate avea valoarea adevăr, dacă PA-ul respectiv a fost semnat și de către debitor sau valoarea fals dacă PA-ul respectiv nu a fost semnat de debitor;

Utilizator – este numele utilizatorului de sistem care a creat PA-ul;

Tip PA

Status PA poate fi:

status kept = PA respectat;

status broken = PA încălcat;

status pending = PA în curs de desfășurare;

status cancelled = PA anulat de către utilizator.

Suma – este valoarea sumei pentru care s-a stabilit PA-ul;

Reducere – în cazul în care s-a creat un PA cu reducere aici va apărea suma pentru care se acordă reducere;

Motiv reducere – în cazul în care s-a creat un PA cu reducere aici va apărea motivul acordării reducerii;

Comentariu utilizator;

Figura 16 Vizualizare istoric PA

Utilizatorul poate vizualiza detaliile referitoare la oricare din PA-urile create pe caz prin accesarea iconiței Vizualizare PA care se află în dreapta fiecărui rând al fiecărui PA creat în caz și afișat în tabelul PA. Astfel se afișează sub tabelul PA, un tabel care conține istoricul ratelor PA-ului selectat. Acest istoric al ratelor unui PA conține urmatoarele coloane:

Data scadentă – scadența fiecărei rate stabilite;

Suma – valoarea stabilită pentru fiecare rată;

Sold – reprezintă diferența dintre valoarea ratei și valoarea plății care afectează rata respectivă (dacă rata s-a achitat integral, soldul va fi nul);

Confirmare – bifa este pusă de utilizator în momentul în care debitorul confirmă achitarea ratei respective (telefonic, fax, alte metode) ; dacă bifa nu este pusă, înseamnă că debitorul n-a confirmat achitarea ratei.

În situația în care se bifează flagul Confirmare, nu se vor mai executa acțiunile care erau setate după data scadentă și se va aștepta confirmarea plății. Dacă expiră prima perioadă de grație și plata nu a fost confirmată, PA-ul rămâne în curs de desfășurare (PA pending) și va intra în perioada de grație 2. Dacă la expirarea celei de-a doua perioade de grație, plata nu este alocată atunci PA-ul devine nerespectat (PA broken).

Dacă la expirarea perioadei de grație 1, flagul Confirmare nu este bifat și nici plata nu a fost alocată în caz, atunci PA-ul devine nerespectat (PA broken).

6.7. ZONA DINAMICĂ

Zona dinamică este specifică fiecărui nivel ierarhic: Persoană, Account, Collection entitiy. Această zonă se actualizează în funcție de nivelul ierarhic selectat.

Indiferent de criteriul de căutare, la deschiderea unui caz, în zona dinamică se va afișa nivelul Persoană. Dacă una din persoanele cazului (titular sau girant) este atașat la mai multe cazuri, ierarhia va afișa toate cazurile legate de persoanele cazului indiferent de zona cazurilor. Se pot selecta oricare dintre cele 3 nivele, întreaga pagină actualizându-se în funcție de nivelul selectat.

6.7.1. Nivelul Collection Entity

Nivelul Collection Entity conține 4 taburi:

Info debite și plăți

Flag

Cereri client

Detalii

6.7.1.1. Tabul Info debite și plăți

Acest tab conține 2 secțiuni cu informații care nu pot fi modifcate de către utilizator: debite și plăți.

Secțiunea Debite este afișată sub forma unui tabel care conține urmatoarele coloane:

Clasa de debit – debitele sunt afișate pe clase. Cele 6 clase de debit sunt:

Main debt = Debit principal;

Interest = Dobândă;

Penalties = Penalizări;

Cancellation Fee = Taxă reziliere;

Administration fee = Taxă de administrare și comisioane;

Cheltuieli cu procedura legală.

Suma inițială – reprezintă valoarea clasei de debit la momentul încărcării cazului (data preluării = take over date).

Moneda – este exprimată doar în moneda curentă RON

Balanța – reprezintă valoarea clasei de debit de recuperat la data curentă.

Secțiunea Plăți (Figura 17) este afișată sub forma unui tabel care conține următoarele coloane:

Data plății

Moneda – este exprimată doar în moneda curentă RON

Suma plată

Tip plată – plățile pot fi de tip:

Prelegal;

Legal;

Before.

Aici sunt afișate toate plățile încărcate pe cazul respectiv de la momentul take over până la data curentă.

Figura 17 Secțiunea Plăți

6.7.1.2. Tabul Flag (Figura 18)

Pentru a marca diverse observații standard la nivel de CE, s-a introdus noțiunea de flag. Aceste flaguri sunt informative și nu au ca urmări inițierea de acțiuni. Astfel, dacă se dorește marcarea unui CE cu un astfel de flag, utilizatorul trebuie să bifeze check-box-ul aferent flag-ului dorit. Dacă utilizatorul bifează un flag, sistemul va adăuga automat un comentariu în acest sens.

Figura 18 Tabul “Flag”

Aceste flaguri sunt:

Morning call – se bifează atunci când colectorul consideră că probabilitatea de a lua legătura telefonic cu debitorul este mai mare în prima parte a zilei.

Evening call – se bifează atunci când colectorul consideră că probabilitatea de a lua legătura telefonic cu debitorul este mai mare în ultima parte a zilei.

No Payment – este bifat implicit în momentul încărcării cazului în sistem și se debifează automat de către sistem, peste noapte, atunci când se alocă cel puțin o plată pe cazul respectiv.

No Contact – este bifat implicit în momentul încărcării cazului în sistem și se debifează automat de către sistem, peste noapte, atunci când se înregistrează în caz un comentariu de tip Apel către debitor, Mesaj către debitor sau Apel de la debitor.

Refuse to pay – se bifează manual de către utilizator în condițiile în care acesta ajunge la concluzia că debitorul refuză să plătească datoria.

PA Broken – este bifat automat de sistem în momentul în care un PA devine broken.

Fraud Flag – se bifează manual de către utilizator în condițiile în care acesta ajunge la concluzia că în dosarul respectiv este vorba despre o fraudă.

6.7.1.3. Tabul Cereri client (Figura 19)

În acest tab clientul poate adăuga în sistem diverse cereri.

Utilizatorul poate introduce și el cereri către client prin accesarea butonului Adaugă, ce are ca efect deschiderea ferestrei Adaugă cerere în care utilizatorul trebuie să completeze cele 3 câmpuri:

Titlu

Motiv cerere (se selectează din combo-box)

Întrebare

Pentru a înregistra cererea sa, utilizatorul trebuie să apese butonul Modifică. În cazul în care se dorește anularea operației, se apasă butonul Anulează sau se închide fereastra.

Figura 19 Tabul Cereri Client

Răspunsurile la aceste cereri se vor putea introduce de către un responsabil de client din Meniul Cereri.

Vor exista două mecanisme de înregistrare a întrebărilor și răspunsurilor din Web Kollecto și Kollecto Prelegal, astfel:

1. Mecanismul de întrebări și răspunsuri dinspre Web Kollecto catre Kollecto Prelegal:

Utilizatorul înregistrează o întrebare către client la nivel de CE in Web Kollecto în tabul Cereri client;

Cererea va putea fi vizualizată în meniul Cereri din Web Kollecto, dar în același timp se va transmite și în sistemul Kollecto Prelegal;

Persoana responsabilă de client va înregistra răspunsul în Kollecto Prelegal, răspuns care va putea fi vizualizat și în Web Kollecto în meniul Cereri;

În concluzie, întrebările și răspunsurile vor fi afișate pe Web Kollecto în meniul Cereri sub forma unui tabel cu urmatoarele coloane:

Nr. Curent;

Inițiator;

Întrebare;

Data întrebării;

Respondent;

Data răspuns.

2. Mecanismul de întrebări și răspunsuri dinspre Kollecto Prelegal spre Kollecto Web: un utilizator de Kollecto Prelegal va înregistra o întrebare în Kollecto Prelegal, iar utilizatorul de Web Kollecto o va putea vizualiza în meniul Cereri de unde va avea posibilitatea să adauge și răspunsul, care se va transmite și către Kollecto Prelegal.

6.7.1.4. Tabul Detalii (Figura 20)

Acest tab conține informații legate de responsabilul de caz și anume:

Titlu

Nume și prenume

Cabinet

Adresa 1

Oraș 1

Judet 1

Număr telefon 1

Adresa 2

Oraș 2

Județ 2

Număr telefon 2

Figura 20 Tabul Detalii

6.7.2. Nivelul Account

Conține 4 taburi:

Info debite și plăți

Proprietăți account

Documente account

Info account

6.7.2.1. Tabul Info debite și plăți (Figura 21)

Acest tab conține următoarele 3 secțiuni:

1. Secțiunea Debite conține urmatoarele coloane:

Subclasa debit

Nr. document

Data

Suma inițiala

Moneda

Balanța

Suma cerută

Suma aprobată

Figura 21 Tabul Info debite și plăți

Primele 6 câmpuri nu sunt editabile. Utilizatorul are drept de editare doar pentru câmpurile suma ceruta și suma aprobată. În funcție de etapa procedurii legale în care se află cazul în instanță, utilizatorul poate completa ultimele două câmpuri: suma cerută și suma aprobată. În urma completării acestor două câmpuri, la nivel de Account vor fi adăugate automat, în sistem, comentariile corespunzatoare.

În noaptea urmatoare introducerii sumei aprobate de către utilizator, prin procesele de noapte, sistemul va modifica automat balanța cazului astfel încăt valoarea de pe câmpul Suma Aprobată va deveni noua balanță a cazului.

Figura 22 Secțiunea “Cerere sumă”

Odată ce au fost completate, utilizatorul nu mai poate modifica cele două câmpuri: suma cerută și suma aprobată (Figura 22), dar poate vizualiza istoricul actualizărilor care au fost făcute pe fiecare subclasă de debit prin accesarea iconiței Details (Figura 23).

Acest istoric conține urmatoarele câmpuri care nu sunt editabile:

ID Account

Balanța anterioară

Balanța actualizată

Data update

Suma cerută

Data sumă cerută

Suma aprobată

Data suma aprobată

Creat de

Actualizat de

Figura 23 Fereastra “Details”

2. Secțiunea Plăți (Figura 24) afișează plățile alocate pe acount-ul respectiv într-un tabel care conține următoarele coloane:

Data plății

Moneda

Suma inițială

Tip plată care poate avea urmatoarele valori:

Prelegal (când zona în care se află cazul este diferită de zonele Legal și Field);

Field (când cazul se află în zona Field);

Legal (când cazul se află în zona Legal);

Before (când plata a fost făcută înainte de data preluării cazului în sistem).

Figura 24 Secțiunea Plăți

3. În secțiunea Confirmare plată (Figura 25), utilizatorul poate introduce manual confirmările de plată transmise prin telefon sau fax ale debitorilor. Acest lucru se face prin apăsarea butonului Adaugă, ce are ca efect deschiderea ferestrei Adăugare confirmare plată, în care se completează urmatoarele câmpuri:

Data plății – se selectează din butonul Calendar;

Suma;

Moneda – se selectează din combo-box;

Status – se selectează din combo-box și poate avea următoarele valori:

N = neconfirmată de către departamenul financiar;

C = confirmată de către departamentul financiar (plata este alocată pe caz).

Tip document – poate fi verbal când debitorul confirmă plata telefonic sau document când debitorul trimite chitanța;

Bank – numele băncii în contul căreia s-au virat banii;

Cont bancar – numărul de cont în care s-au virat banii;

Plătitor – persoana care a efectuat plata;

Debitor – persoana care figurează cu datorie în caz;

Număr document – numărul de chitanță/ordin de plată etc.

Sucursala – numele sucursalei băncii la care s-a efectuat plata.

Figura 25 Secțiunea “Confirmare Plată”

Utilizatorul poate modifica toate detaliile unei confirmări de plată prin apăsarea butonului Editare din dreapta rândului care conține confirmarea de plată care se dorește a se modifica. La apăsarea butonului de Editare se deschide fereastra Modificare confirmare plată care conține aceleași câmpuri editabile ca și fereastra Adăugare confirmare plată (Figura 26).

Secțiunea Confirmare plată afișează urmatoarele detalii:

Data plății

Suma inițială

Status

Moneda

Tip document

Figura 26 Adăugare confirmare de plată

6.7.2.2. Tabul Proprietati account (Figura 27)

În acest tab se afișează detalii despre:

contractele încheiate de debitori;

data preluării;

numele executorului;

rangul executorului.

Un exemplu de rând afișat în tabelul corespunzător acestui tab este urmatorul:

Figura 27 Tabul Proprietăți account

Informațiile sunt afișate în ordinea cronologică a datei de creare. Utilizatorul poate introduce aceste informații prin apăsarea butonului Adaugă, ce are ca efect deschiderea ferestrei Adăugare proprietate account (Figura 28) în care se selectează câmpurile Categorie și Proprietate și se completează câmpul Value (Figura 29), după care se apasă butonul Adaugă. Utilizatorul are, de asemenea, posibilitatea de a modifica o proprietate prin accesarea iconiței Editare, ce are ca efect deschiderea ferestrei Modificare proprietate.

Figura 28 Fereastra “Adăugare Proprietate”

Figura 29 “Evaluare Proprietate Adăugată”

6.7.2.3. Tabul Documente Account (Figura 30)

Aici utilizatorul are posibilitatea de a vizualiza sub forma unei liste, diverse documente care se afla în arhivă legate de cazul respectiv.

Aceasta listă conține următoarele informații:

Tip document

Descriere

Data creare

Figura 30 Tabul Documente Account

6.7.2.4. Tabul Info Account (Figura 31)

Acesta afișează informațiile cuprinse în tabul Industry Info din Kollecto Prelegal (informații detaliate despre contractele încheiate, despre datorie). Indiferent de clienții cărora aparțin cazurile, aceste câmpuri afișate sunt aceleași după cum sunt prezentate și în imaginea urmatoare:

Figura 31 Tabul Info Account

6.7.3. Nivelul Persoană

Este alcătuit din trei taburi:

Info

Proprietăți persoană

Flag și scrisori

6.7.3.1. Tabul Info (Figura 32)

În partea din stânga a tabului, utilizatorul poate vizualiza un tabel în care sunt afișate informații generale despre debitor (titular/girant). Dintre câmpurile afișate în acest tabel, două dintre ele sunt editabile prin accesarea butonului Modifică. Acestea sunt: locul de muncă și profesia debitorului.

Figura 32 Tabul Info

În partea din dreapta a tabului sunt cele 3 secțiuni:

Adresa

Numere telefon

Contacte

Utilizatorul poate adăuga adrese, numere de telefon și contacte pentru fiecare din persoanele asociate cazului, prin accesarea butoanelor Adaugă (Figura 33) din secțiunile corespunzătoare. De asemenea, utilizatorul poate modifica detalii referitoare la adresele, numerele de telefon sau persoanele de contact prin accesarea butoanelor de Editare din fiecare secțiune. În ferestrele de adăugare și editare adrese, numere de telefon și contacte, câmpurile marcate cu steluță sunt obligatoriu de completat.

Figura 33 Fereastra pentru editarea și confirmarea informațiilor

În cazul în care există mai mult de o adresă în secțiunea Adrese, prioritizarea de afisare a acestora se face în primul rând după câmpul Principal și apoi în funcție de valorile de pe câmpul Valid după cum urmează:

adresele care au bifat câmpul Principal

adresele care au YES-Private property la câmpul Valid

adresele care au YES la câmpul Valid

adresele care au Unknown la câmpul Valid

adresele care au Yes – NC la câmpul Valid

adresele care au No la câmpul Valid

Notificarile pentru debitori se trimit numai pe adresele care au câmpul Principal (Figura 34) bifat. Dacă utilizatorul dorește să trimită notificări pe altă adresă, trebuie să bifeze câmpul Principal pe adresa pe care dorește să trimită notificări. Dacă o adresă care are bifat câmpul Principal se invalidează, atunci sistemul debifează automat câmpul Principal. În această situație, utilizatorul trebuie să bifeze flagul de Principal pe o altă adresă (dacă există) astfel încât să se poată trimite notificări către debitori.

Figura 34 Fereastra de setare a adresei principale

În cazul în care există mai mult de un numar de telefon în secțiunea Numere telefon (Figura 35), prioritizarea de afișare a acestora se face în primul rând după câmpul Principal și apoi în funcție de valorile de pe câmpul Valid (Figura 36) după cum urmează:

numere de telefon care au bifat câmpul Principal

numere de telefon care au YES la câmpul Valid

numere de telefon care au Unknown la câmpul Valid

numere de telefon care au Yes-NC la câmpul Valid

numere de telefon care au No la câmpul Valid

Figura 35 Fereastra pentru adăugarea de contacte

În secțiunea Contacte, unde sunt prezentate persoanele de contact, prioritizarea de afișare se face după aceleași criterii ca și la secțiunea Numere telefon. Adresele și numerele de telefon pentru persoanele de contact se întroduc la fel ca și cele pentru debitori, cu condiția de a se introduce mai întăi persoana de contact ca să poată apărea în combo-box-urile Persoană din cele două ferestre de adăugare adrese și telefoane.

Figura 36 Validarea datelor de contact

6.7.3.2. Tabul Proprietăți Persoană (Figura 37)

Tabul afișează detalii despre:

bunuri imobiliare;

bunuri mobiliare.

Un exemplu de rând afișat în tabelul corespunzator acestui tab este urmatorul:

Figura 37 Tabul Proprietăți Persoană

Informațiile sunt afișate în ordinea cronologică a datei de creare. Utilizatorul poate introduce aceste informații prin apăsarea butonului Adaugă, ce are ca efect deschiderea ferestrei Adăugare proprietate subscriber în care se selecteaza câmpurile Categorie si Proprietate și se completează câmpul Value, după care se apasă butonul Adaugă. Utilizatorul are, de asemenea, posibilitatea de a modifica o proprietate prin accesarea iconiței Editare, ce are ca efect deschiderea ferestrei Modificare proprietate.

6.7.3.3. Tabul Flag & Scrisori (Figura 38)

În acest tab sunt afișate toate detaliile referitoare la notificările care s-au trimis pe parcursul procedurii de colectare către persoana din caz. În acest tab, utilizatorul nu poate modifica nicio informație.

Detaliile notificărilor se referă la următoarele câmpuri:

Scrisoare – denumirea notificării

Confirmare – dacă notificarile s-au trimis cu confirmare de primire, acest câmp apare bifat

Dată creare – data când utilizatorul a generat acțiunea pentru a trimite o notificare

Creat de – utilizatorul care a generat acțiunea

Data generare – data când se generează fișierul de scrisori pentru a fi printat

Data imprimare – data când a fost printată notificarea pentru a fi trimisă

Motiv întoarcere – este completat atunci când notificarea s-a întors către destinatar

Dată întoarcere – data când notificarea s-a întors la destinatar

Account Id – dacă acceași persoană este legată de mai multe Account-uri din cazuri diferite (CEID-uri diferite), utilizatorul poate vizualiza toate notificările care au fost trimise persoanei respective în toate cazurile.

Figura 38 Tabul Flag & Scrisori

6.8. MENIUL COZI

Acest meniu este format din 3 secțiuni. Primele două secțiuni: Cozi Personale și Cozi de Grup (Figura 39) sunt afișate sub forma unor tabele care conțin aceleași informații:

Acțiuni – denumirea cozii în care se află cazul;

Client – denumirea clientului căruia aparține cazul;

Număr – numărul de cazuri care se află pe coada respectivă.

În dreapta fiecărui rând de cozi din cele două secțiuni, se află iconița Vizualizare, prin intermediul căreia utilizatorul poate vizualiza toate cazurile care se află pe coada pe care o selectează. Cazurile din coada selectată vor fi afișate în secțiunea Cases sub forma unui tabel cu urmatoarele câmpuri:

CEID

Apel dimineața – dacă este bifat, înseamnă că flagul Morning Call de la nivel de CE este bifat în cazul respectiv;

Apel seară – dacă este bifat, înseamnă ca flagul Evening Call de la nivel de CE este bifat în cazul respectiv;

Balanța totală

Responsabil caz

Cod loturi caz

Ieșire din coadă – numărul de zile cât are de stat cazul în coada respectivă (TTL = time to leave)

Tip debitor – dacă debitorul este persoană fizică sau persoană juridică

Lucrat – in acest camp apare rezolutia care se da cazului de catre utilizator

Din secțiunea Cases, utilizatorul poate deschide un caz prin apăsarea iconiței Vizualizare. Cazul se va deschide la nivelul Persoană. Dacă sunt mai multe persoane atașate cazului, sistemul va deschide nivelul Persoană al titularului din primul caz găsit. Când utilizatorul dorește să închidă cazul pe care l-a vizualizat, el selectează o rezoluție pentru coada în care se află cazul respectiv.

Figura 39 Secțiunea Cozi Personale și Cozi de Grup

6.9. MENIUL SCRISORI (Figura 40)

Utilizatorul are posibilitatea de a genera notificări în vederea printării și trimiterii acestora către debitori.

Pentru a realiza acest lucru este necesar ca utilizatorul să facă următorii pași:

selectarea clientului din primul combo-box și selectarea scrisorii pe care vrea să o genereze din al doilea combo-box;

accesarea butonului Caută, ce are ca efect afișarea în secțiunea Cases a tuturor cazurilor pe care s-a dat acțiunea corespunzătoare scrisorii selectate;

bifarea check-box-ul Toate dacă dorește să genereze toate scrisorile afișate sau selectarea numai a celor pe care dorește să le genereze;

accesarea butonului Generează, care are ca efect generarea fișierelor de scrisori într-un director de pe server alocat utilizatorului (Fișierele cu scrisorile generate vor avea extensia rtf, iar denumirea lor va respecta urmatoarea formulă: (nume client_nume scrisoare_data generare_cod fisier_scrisori.rtf). Fișierele cu confirmările de primire vor avea aceeași extensie rtf, iar denumirea lor va respecta urmatoarea formulă: (nume client_ nume scrisoare_data generare_confirmari.rtf);

după accesarea butonului Generează, sistemul va deschide automat fereastra Scrisori generate în care utilizatorul poate vizualiza toate fișierele generate sub forma unui tabel ce conține urmatoarele coloane: cod fișier, data generării, numele scrisorii, numele clientului, numarul de scrisori (în tabel se poate face sortare în ordine crescătoare sau descrescătoare după câmpurile din capul de tabel);

descărcarea pe computerul personal al utilizatorului a fișierelor de scrisori și confirmări prin accesarea iconițelor specifice de pe fiecare rând de fișiere (aici utilizatorul are posibilitatea de a deschide, salva sau anula operația);

data generării și data printării vor avea aceeași valoare;

Figura 40 Generarea Scrisorilor

Utilizatorul poate să genereze scrisori numai pentru cazurile de care este responsabil.

În orice moment utilizatorul are posibilitatea de a vizualiza și descărca fișierele de scrisori prin apăsarea directă a butonului Scrisori generate. Nu este obligatoriu ca utilizatorul să descarce fișierele de scrisori în momentul în care este redirecționat automat de către sistem spre fereastra Scrisori generate (Figura 41).

Figura 41 Fereastra “Scrisori Generate”

Pentru scrisorile care au fost trimise către debitori și care s-au întors din diverse motive, există posibilitatea de a fi înregistrate în sistem astfel:

se apasă butonul Scrisori Întoarse (Figura 42), ce are ca efect deschiderea unei ferestre cu același nume;

utilizatorul va completa câmpul Letter Queue Id cu valoarea acestuia, care se preia de pe fiecare scrisoare care s-a întors;

se apasă butonul Caută, ce are ca efect reîmprospătarea paginii prin afișarea în caseta de sub câmpul ID scrisoare (letter queue id), a unei serii de detalii referitoare la scrisoarea respectivă și anume: numele și prenumele persoanei către care s-a trimis scrisoarea, clientul căruia îi aparținea cazul respectiv, adresa la care s-a trimis scrisoarea, numele scrisorii trimise și data generării acesteia;

se selectează din combo-box-ul Motiv valoarea dorită de către utilizator;

dacă utilizatorul accesează butonul Persoană, atunci pagina cu datele personale ale debitorului va fi afișată și utilizatorul va avea posibilitatea verificării informațiilor;

se apasă butonul Confirmă, ce are ca efect înregistrarea în sistem a motivului de întoarcere pentru scrisoarea respectivă.

Figura 42 Înregistrarea scrisorilor întoarse

Pentru situațiile în care există o singură adresă în caz și s-au întors scrisori cu oricare din motivele:

adresă incompletă/gresită;

mutat de la adresă;

necunoscut la adresa;

casă demolată,

sistemul va invalida adresa principală din caz și va trimite cazul în coada Return_Mail_SKT_Adresa (o coada în care se va căuta o nouă adresă pentru persoana din caz).

Pentru restul motivelor de întoarcere (avizat/reavizat, debitor decedat, destinatar în penitenciar, destinatar plecat din țară/localitate, destinatar refuză primirea, mai multe persoane cu același nume, societate desființată) sistemul va trimite cazurile în coada de Review Return Mail & Documents.

6.10. MENIUL RAPOARTE

Din acest meniu se vor putea accesa rapoartele de activitate pentru clienți.

Figura 43 Meniul Rapoarte

6.11. MENIUL CERERI

În acest meniu sunt centralizate toate cererile din cazuri pe fiecare client. Acestea sunt afișate sub forma unui tabel cu urmatoarele coloane:

CEID

Întrebare

Data întrebării

Răspuns

Data răspunsului

Utilizatorul poate sorta rândurile afișate în ordine crescătoare sau descrescătoare după oricare din coloanele din capul de tabel.

Figura 44 Meniul Cereri

6.12. MENIUL OPȚIUNI

În acest meniu se întroduc informații legate de responsabilul de caz și anume:

Nume și prenume

Tip

Adresa

Oraș

Județ

Număr telefon

Cabinet

După ce completează detaliile, utilizatorul trebuie să apese butonul Modifică pentru ca înregistrările să se salveze. Utilizatorul poate oricând să actualizeze aceste informații.

Toate aceste detalii se pot vizualiza și la nivel de CE în tabul Detalii (Figura 45).

Figura 45 Tabul “Detalii” din meniul Opțiuni

CONCLUZII

Schimbările tehnologice care au avut loc în ultimii ani au condus la o nouă gândire privind întreprinderea și activitatea sa, cu implicații majore la nivel organizațional și în ceea ce privește managementul. Dezvoltarea și utilizarea sistemelor inteligente în cadrul unei organizații permite managerilor să folosească cunoașterea depozitată pentru rezolvarea problemelor complexe din cadrul organizației și pentru luarea deciziilor strategice.

Existența rețelelor Intranet și Extranet și a altor rețele de telecomunicații permite interconectivitatea globală și deci manifestarea organizațiilor la nivel planetar. În condițiile globalizării, întreprinderea modernă trebuie să satisfacă necesitățile globale de afaceri într-o societate informațională globală astfel încât aplicații din orice punct de pe glob să poată accesa și prelucra datele și cunoștințele necesare desfășurării activității muncitorului cunoașterii.

Utilizarea sistemelor inteligente care sunt permanente, nu fac grevă, nu solicită concediu, pot memora, consulta și prelucra volume considerabile de date și cunoștințe și pot funcționa 24 de ore din 24, asigură o independență a managementului salariaților și pune la dispoziția managerilor toate cunoștințele acumulate asistându-i în soluționarea problemelor complexe și luarea deciziilor. Sistemele inteligente oferă posibilitatea exploatării cunoașterii prin combinarea potențialului tehnologiei bazelor de date cu tehnologia bazelor de cunoștințe și a sistemelor expert, remarcându-se în acest sens tehnologia bazelor de date inteligente.

Având în vedere că prin aceste aspecte s-a definit întreprinderea inteligentă, întreprinderea expert, întreprinderea bazată pe cunoștințe, ca fiind acea organizație în care se utilizează în mod curent sistemele inteligente pentru soluționarea tuturor problemelor dificile, putem spune că organizația care lucrează inteligent este organizația care captează cunoașterea de la experții umani, o depozitează într-o formă acceptată de către calculator și o folosește cu ajutorul unor programe specializate în soluționarea problemelor.

WEBGRAFIE

http://www.adcodevelopment.ro/index.php/solutii-crm/48-implementarea-crm-erp

http://www.seniorsoftware.ro/erp/ce-inseamna-erp/

http://www.soft-erp.ro/functionalitati_erp.html

http://www.cio.com/research/erp/

http://theredpoint.ro/solutii-software-integrate?lang=en

http://www.scrigroup.com/calculatoare/STUDIUL-TEHNOLOGIILOR-INFORMAT54452.php

http://informatica.ase.ro/site/A140212/clasificarea_aplicatiilor_de_eb.htm

http://www.cct.ro/ro/servicii/consultanta-it-c-si-hi-tech/integrare-solutii-it-c/integrarea-solutiilor-informatice.html

http://sinf.ase.ro/curs.html

sinf.ase.ro/cursuri/integrare/Curs%201-2.doc

http://www.comunitateaerp.ro/utile/14

http://www.businesscomputingworld.co.uk/the-advantages-of-using-an-erp-system-in-business/

https://sites.google.com/site/utilizareacalculatoruluifeg/programa-bac-2011/4-concepte-de-baza-ale-tehnologiei-informatiei/utilizarea-aplicatiilor-in-activitati-din-diferite-domenii

Institutul pentru Tehnica de Calcul SA, “Evoluția industriei IT în România, 1997-2000”, septembrie 2001

ro.wikipedia.org/wiki/Gordon_Moore

http://m.business24.ro/companii/ce-reprezinta-angajamentul-organizational-si-de-ce-este-important-pentru-companie-1545668

http://www.developer.com/lang/other/article.php/943371/Integration-Infrastructure-and-Technologies.htm

http://c2.com/cgi/wiki?PointToPointIntegration

http://manjamba.tripod.com/thesis/chapter2.html

xa.yimg.com/kq/groups/22606974/…/suport+de+curs+final+-+TO.doc

WEBGRAFIE

http://www.adcodevelopment.ro/index.php/solutii-crm/48-implementarea-crm-erp

http://www.seniorsoftware.ro/erp/ce-inseamna-erp/

http://www.soft-erp.ro/functionalitati_erp.html

http://www.cio.com/research/erp/

http://theredpoint.ro/solutii-software-integrate?lang=en

http://www.scrigroup.com/calculatoare/STUDIUL-TEHNOLOGIILOR-INFORMAT54452.php

http://informatica.ase.ro/site/A140212/clasificarea_aplicatiilor_de_eb.htm

http://www.cct.ro/ro/servicii/consultanta-it-c-si-hi-tech/integrare-solutii-it-c/integrarea-solutiilor-informatice.html

http://sinf.ase.ro/curs.html

sinf.ase.ro/cursuri/integrare/Curs%201-2.doc

http://www.comunitateaerp.ro/utile/14

http://www.businesscomputingworld.co.uk/the-advantages-of-using-an-erp-system-in-business/

https://sites.google.com/site/utilizareacalculatoruluifeg/programa-bac-2011/4-concepte-de-baza-ale-tehnologiei-informatiei/utilizarea-aplicatiilor-in-activitati-din-diferite-domenii

Institutul pentru Tehnica de Calcul SA, “Evoluția industriei IT în România, 1997-2000”, septembrie 2001

ro.wikipedia.org/wiki/Gordon_Moore

http://m.business24.ro/companii/ce-reprezinta-angajamentul-organizational-si-de-ce-este-important-pentru-companie-1545668

http://www.developer.com/lang/other/article.php/943371/Integration-Infrastructure-and-Technologies.htm

http://c2.com/cgi/wiki?PointToPointIntegration

http://manjamba.tripod.com/thesis/chapter2.html

xa.yimg.com/kq/groups/22606974/…/suport+de+curs+final+-+TO.doc