Aplicatie Pentru Gestionarea Resurselor Activitatilor de Tip Hotline

Hotline Management System –

Aplicație pentru gestionarea resurselor activitaților de tip hotline

I. Enterprise Resource Planning (ERP)

I.1 Introducere

I.2 Definiție

II. Funcționarea ERP

III. Cele mai cunoscute sisteme ERP din lume

IV. Tehnologii și instrumente folosite în dezvoltarea aplicației

IV.1 Oracle Application Express

IV.1.1 Scurtă istorie a versiunilor APEX și funcționalităților introduse

IV.1.2 Tipuri de arhitecturi și concepte cheie ce trebuie știute la instalarea/folosirea Oracle Application Express

IV.2 Oracle Database

IV.2.1 Descrierea a unui server de baze de date Oracle

IV.2.2 Istoric al versiunilor bazelor de date Oracle

V. Studiu de caz – Dezvoltarea Aplicației

V.1 Arhitectura folosită la implementarea aplicației la firma Hotline Software Solutions S.R.L

V.2 Structura bazei de date

V.2.1 Diagrama entitate relație

V.2.2 Descrierea tabelelor

V.2.3 Vizualizări (vederi)

V.2.4 Declanșatoare

VI. Implementarea produsului software Hotline Management System la firma Hotline Software Solutions S.R.L.

VI.1 Utilizarea aplicației

VI.1.1 Pagina login

VI.1.2 Utilizarea aplicației – Rolul USER

VI.1.3 Utilizarea aplicației – Rolul MGR

VI.1.4 Utilizarea aplicației – Rolul ADMIN

VII. Concluzii

VIII. Bibliografie

IX. Anexa 1

Introducere

Compania Hotline Software Solutions S.R.L. este o companie care livrează soluții software pentru diferite domenii de activitate (financiar, contabil, producție de materii prime etc…). O dată cu vânzarea produselor software, a apărut și necesitatea dezvoltării serviciilor de suport pentru aceste produse software. Principalul mod de lucru pentru livrarea acestor servicii este de a asigura suport la distanță folosind internetul și telefonul dar și prin prezentarea la sediul firmelor în caz de necesitate.

Datorită creșterii numărului clienților care folosesc aplicațiile produse de compania Hotline Software Solutions S.R.L. în regim nonstop (24 ore pe zi, 7 zile din 7 pe săptămână), au crescut cererile de mentenanță și suport pentru aceste produse software, necesitând astfel dorința creării și implementării unei aplicații software care să poată oferi în mod centralizat și unitar posibilitatea gestionării unor astfel de servicii. Astfel a apărut necesitatea proiectării și creeri aplicației „Hotline Management System” – aplicație pentru gestionarea resurselor activitaților de tip hotline.

Aplicația permite următoarele funcționalități:

Managementul resurselor (umane) alocate strict acestor servicii – nu din punct de vedere general “Resurse umane”, reprezentând cărți de muncă, salarii și alte date specifice despre angajați

Evidența clienților – persoană de contact, data începerii contractului, data terminării contractului, particularități etc.…

Crearea și menținerea unui program de lucru în regim standby (rota), a persoanelor și echipelor implicate

Gestionarea timpului alocat pe proiectele clienților

Posibilitatea monitorizării activității în vederea luării unor decizii precum angajări noi, reducere de costuri.

Am implementat Aplicația Hotline Management Systems pentru a deservi cerințele de mai sus, creând astfel un mod unitar de gestionare și vizualizare a resurselor, modului de lucru, încasărilor, eliminând pierderea datelor și chiar riscul de a avea date greșite/neactualizate între utilizatori dacă aceste informații ar fi fost menținute folosind diferite aplicații de calcul tabelar, precum Microsoft Excel, așa cum a fost inițial.

Pentru realizarea aplicației am folosit Oracle Application Express și baza de date Oracle iar pentru a accesa aplicația este nevoie doar de un browser Web.

Enterprise Resource Planning (ERP)

Introducere

Dezvoltarea fără precedent a Tehnologiei Informației și Telecomunicațiilor datorate dezvoltării și inovării în microelectronică, în componente hardware pentru calculatoare, a dus la dezvoltarea din ce în ce mai mult a programelor software influențând toate aspectele aplicațiilor în organizații. În același timp s-a dezvoltat foarte mult și mediului de afaceri care a devenit din ce în ce mai complex, cu unități funcționale care necesitau din ce în ce mai mult inter-comunicarea funcțională între ele pentru luarea deciziilor la nivel de organizație, procurarea eficientă a materiilor prime, managementul stocurilor, contabilitate, resurse umane, distribuția de bunuri și servicii. În acest context, managementul organizațiilor avea nevoie de un sistem informatic eficient.

Începând cu sfârșitul anilor 1980 și începutul anilor 1990, un nou software cunoscut sub denumirea de “Enterprise Resource Planning” (ERP) a apărut pe piață având ca țintă în special companiile cu un model de organizare și afaceri foarte complex. Aceste sisteme foarte complexe și puternice, dar și foarte scumpe au fost de cele mai multe ori sisteme proprietare, necesitând consultanți pentru implementarea cerințelor companiei. În multe cazuri ele au forțat companiile să regândească procesele de efectuare a afacerilor pentru a se alinia la logica aplicațiilor software pentru buna direcționare a fluxului de date din cadrul organizației. Aceste soluții software, spre deosebire de cele vechi, tradiționale, proiectate și dezvoltate conform propriilor specificații, sunt sisteme integrate “multi-module” adecvate pentru dezvoltarea și adăugarea “add-on”-urilor după cum este nevoie.

De la începuturi, scopul sistemelor ERP a fost: “1) să integreze toate tranzacțiile din mai multe sisteme în același sistem; 2) să partajeze datele și practicile în cadrul întreprinderilor și 3) să producă informații relevante pentru a se putea lua decizii în timp real”.

Definiție

Prin Enterprise Resource Planning (ERP) se înțelege o platformă comună de aplicații software integrate care formează un sistem coerent de management al afacerilor. ERP elimină limitările existente între diferite departamente într-o companie iar datele la nivel de organizație sunt ușor de accesat

American Production and Inventory Control Society (2001) a definit ERP ca “o metoda de planificare și control efectiva a tuturor resurselor necesare sa preia, efectueze, livreze și contabilizeze comenzile clienților intr-o companie de producție, distribuție sau servicii. Citam câteva definiții din literatura de specialitate:

“ERP (sistem de planificare a resurselor pentru întreprindere) este compus dintr-un pachet comercial care promite integrarea perfecta a tuturor informațiilor dintr-o companie – financiare, contabile, resurse umane, aprovizionări și clienți”(Davenport, 1998).

“Sistemele ERP sunt sisteme informatice configurabile care integrează informația și procesele bazate pe informație în interiorul și de-a lungul zonelor funcționale într-o organizație” (Kumar & Van Hillsgersberg, 2000).

“O bază de date, o aplicație și o interfață unificata în toata întreprinderea” (Tadjer, 1998)

“Sistemele ERP sunt sisteme informatice proiectate sa proceseze tranzacțiile unei organizații și să faciliteze integrarea și planificarea în timp real, producția și răspunsul clienților” (O’Leary, 2001).

Conceptul de sistem ERP poate fi ilustrat, după Davenport (1998), prin diagrama din figura următoare:

Figura I-1 – Diagrama ERP

(Davenport, T. H. (1998). Putting the enterprise into the enterprise system)

In anii 1960, majoritatea organizațiilor proiectau, dezvoltau și implementau sisteme centralizate de calcul, în principal pentru automatizarea sistemelor de control al inventarului, folosind pachete de control al inventarului (IC). În anii ’70 s-au dezvoltat sistemele MRP – Material Requirements Planning – sisteme care presupuneau planificarea necesarului de produse sau piese în funcție de planificarea principala a producției. Urmând acest trend, în anii 80 au apărut noi produse software, numite Manufacturing Resource Planning (MRP II), cu accent pe optimizarea procesului de producție, prin sincronizarea materialelor cu necesitățile de producție. Sistemele ERP au apărut prima dată în anii la sfârșitul anilor ’80, începutul anilor ’90 având marele avantaj coordonarea și integrarea inter-funcțională la nivel de întreprindere. Având la baza tehnologiile MRP și MRPII, sistemele ERP integrează procesele de activitate într-o organizație, incluzând producția, managementul proiectelor, distribuție, contabilitatea, financiar și resurse umane, service și mentenanță având posibilitatea vizibilității la nivel de întreprindere. În anii ’90, furnizorii de sisteme ERP au adăugat noi module și funcționalități sub forma de “add-on”, apărând astfel noțiunea de sisteme ERP extinse – “extended ERP”. Aceste extensiile ERP includ planificarea avansată și programare (APS), soluții e-business cum ar fi managementul relațiilor cu clienții (CRM) și de managementul lanțului de aprovizionare (SCM – supply chain management).

Figura următoare rezumă evoluția istorică a sistemelor ERP.

Figura I-2 – Evoluția istorică a sistemelor ERP

(The Evolution of ERP Systems: A Historical Perspective)

Sistemele ERP permit companiilor să centralizeze foarte multe date importante în activitatea de producție, creând un model de lucru mai productiv și mai rentabil din punct de vederea al costurilor.

Soluțiile ERP din zilele noastre ajută foarte mult și adaugă valoare companiilor de diferite mărimi prin operarea și monitorizarea activităților de zi cu zi într-un mod eficient. De asemenea, sistemele ERP reduc timpul petrecut pentru activități care se suprapun sau sunt repetitive datorită centralizării datelor într-o bază de date comună care coordonează activitățile și alocările de resurse interdepartamentale.

Funcționarea ERP

Definirea proceselor

Un proces trebuie să conțină o intrare (care în cazul unui ERP este o informație) și să producă o ieșire. Acea ieșire poate fi un produs, un serviciu sa poate fi o informație. Procesele sunt definite ca o acțiune completă singulară și nu trebuie confundate cu stadiile intermediare din cadrul unui proces.

Stadiile intermediare

Fluxurile proceselor se divid în mai multe stadii intermediare. Un anumit stadiu poate sau nu să modifice datele, dar trebuie sa adauge valoare procesului cum ar fi revizuirea unor date care poate genera aprobarea tranzacțiilor. Stadiile trebuie să fie într-o ordine logică, astfel încât la un anumit moment să nu fie nevoie de date care se vor cunoaște la un stadiu ulterior.

Date

Fiecare stadiu într-un proces trebuie să adauge informații necesare stadiilor următoare. În cazul unui stadiu în care se revizuiesc datele și se aprobă sau nu o tranzacție, informația adăugată trebuie sa indice statusul, motivul și cine a realizat acest stadiu

Roluri

Un rol este o persoană sau un grup de persoane care realizează un stadiu într-un proces, cum ar fi de exemplu cel care a creat procesul, cel care aprobă, administratorul sau supervizorul. Rolurile nu trebuiesc confundate cu funcția persoanei – ele trebuie denumite după funcția necesară în aplicație.

Timp

Fluxul unui proces se produce într-o anumită perioadă de timp. Diagrama fluxurilor trebuie sa reflecte timpii în care apar evenimentele sau pașii intermediari. Acești timpi trebuie să scoată în evidență că nu este necesar ca stadiile intermediare sa apară în același moment.

Cele mai cunoscute sisteme ERP din lume

În continuare prezentăm funcționalitățile cheie/cele mai importante ale unui sistem ERP însoțite de pictograme concludente, pentru a putea fi mai ușor folosite în compararea sistemelor ERP:

Platforma SaaS (Software as a Service) – acesta este un model în care se oferă și serviciul de a găzdui sistemele hardware în cadrul companiei care livrează software-ul ERP. S e mai numește și “Cloud ERP”

Soluție ERP în cadrul firmei: soluție de instalare a ERP în cadrul companiei care cumpără produsul, folosind sistemele și personalul propriu

Disponibil și în varianta pentru telefoane mobile (Mobile ERP)

suport pentru clienți 24/7

pentru afaceri/firme mici

pentru companii medii și mari

modul raportări si funcții analitice

modul Management Financiar

posibilitatea adăugării modulelor tip add-on

Compararea celor mai mari 20 ERP din lume în 2015, după Business-Software.com (companie recunoscută în lume pentru revizuirea aplicațiilor software):

* doar 3 funcționalități enumerate, ele fiind mai multe pentru fiecare sistem

Tabela 1 – Cele mai cunoscute 20 sisteme ERP din lume în anul 2015

(„Top 20 ERP Software”, http://www.Business-Software.com)

Conform companiei de analiză de piață Pierre Audoin Consultant, în România cel mai dezvoltat sistem ERP la momentul actual este “Charisma ERP 2015”, dezvoltat de firma TotalSoft.

Charisma ERP 2015 poate fi folosit pentru managementul resurselor companiilor, indiferent de dimensiunea acestora. Potrivit producătorului, “Charisma ERP se bazează pe o arhitectură modulară, extrem de flexibilă și scalabilă, special proiectată pentru a optimiza și simplifica gestiunea resurselor unor organizații complexe, indiferent de dimensiune.”

Printre cele mai importante module implementate de Charisma ERP, amintim:

Contabilitate

Financiar

Vânzări

Achiziții

Imobilizări

Managementul bugetului

Cash flow

Gestiune Stocuri

Sistemului ERP produs de compania Oracle este Oracle E-Business Suite este unul dintre cele mai cuprinzătoare sisteme integrate pentru aplicații de afaceri globale care permite organizațiilor să ia cele mai bune decizii, sa reducă costurile mărindu-și în același timp performanțele.

Oracle E-Business Suite este o aplicație ERP foarte complexă, cu sute de facilități și poate fi folosită pentru orice companie indiferent de mărime.

Cele mai importante aplicații incluse în Oracle E-Business Suite sunt:

Customer Relationship Management

Cu modulele:

Oracle Channel Revenue Management

Oracle Marketing

Oracle Order Management

Oracle Service

Service Management

Cu modulele:

Advanced Inbound Telephony

Advanced Outbound Telephony

Advanced Scheduler

Depot Repair

Email Center

Field Service

Interaction Center

iSupport

Mobile Field Service

Scripting

Service Contracts

Spares Management

TeleService

Financial Management

Cu modulele:

Asset Lifecycle Management

Cash & Treasury Management

Credit-To-Cash

Financial Control & Reporting

Financial Analytics

Governance, Risk, and Compliance

Lease and Finance Management

Procure-To-Pay

Travel and Expense Management

Human Capital Management

Cu modulele:

Global Core Human Capital Management

Workforce Management

Workforce Service Delivery

Talent Management

HR Analytics

Project Portfolio Management

Cu modulele:

Project Analytics

Project Billing

Project Contracts

Project Collaboration

Project Costing

Project Management

Project Resource Management

Project Portfolio Analysis

Advanced Procurement

Cu modulele:

iProcurement

iSupplier Portal

Oracle Procurement & Spend Analytics

Oracle Spend Classification

Oracle Supplier Network

Oracle Supplier Hub

Landed Cost Management

Procurement Contracts

Purchasing

Services Procurement

Sourcing

Supplier Lifecycle Management

Oracle Contract Lifecycle Management for Public Sector

Supply Chain Management

Cu modulele:

Advanced Procurement

Value Chain Execution

Order Orchestration and Fulfillment

Asset Lifecycle Management

Manufacturing

Product Value Chain Management

Value Chain Planning

Business Intelligence and Analytics

Value Chain Planning

Cu modulele:

Advanced Planning Command Center

Advanced Supply Chain Planning

Collaborative Planning

Demand Management

Demand Signal Repository

Global Order Promising

Inventory Optimization

Predictive Trade Planning and Optimization

Production Scheduling

Rapid Planning

Real-Time Sales and Operations Planning

Service Parts Planning

Strategic Network Optimization

Value Chain Planning for JD Edwards EnterpriseOne Customers (PDF)

Value Chain Execution

Cu modulele:

Transportation Management

Landed Cost Management

Warehouse Management

Global Trade Management

Mobile Supply Chain

Inventory Management

Tehnologii și instrumente folosite în dezvoltarea aplicației

Oracle Application Express

Oracle Application Express, cunoscuta ca APEX sau Oracle APEX, este o aplicație de dezvoltare software ușor de folosit, construita pe baza tehnologiilor Oracle. Apex face parte din familia de aplicații RAD – Rapid Application Development.

In funcționarea de zi cu zi a unei întreprinderi, este necesar să se răspundă nevoilor utilizatorilor de a avea la dispoziție diferite aplicații software pentru a ține diferite evidențe. De-a lungul anilor au fost foarte folosite (și încă sunt) aplicațiile Microsoft (Excel, Access), aplicații intuitive, ușor de folosit și cu posibilități de a dezvolta aplicații foarte rapid. Problemele au început să apară datorită limitării funcționalității și a scalabilității acestor aplicații și, datorită acestora, multe companii mari dețineau sute de aplicații și zeci de surse de date, aceasta ducând la un enorm efort de mentenanță care a creat în plus o alta încărcare, și implicit costuri . Acest tip sistem fragmentat putea duce la posibilitatea ca datorită nerespectării unor standarde de funcționare, unele date critice și/sau confidențiale să rămână neprotejate. Valoarea datelor creștea în același timp cu creșterea efectiva a datelor, prin continua utilizare și prin integrarea cu alte date adiționale necesare pentru a crea o vedere generala a organizației.

Un lucru este sigur: nu trebuie sacrificat avantajul dezvoltării de aplicații folosind produse RAD într-un mediu de producție.

Compania Oracle este cunoscută în toata lumea pentru puterea bazei de date produsă de companie, bază de date cu multe funcționalități ce permit dezvoltarea unor sisteme robuste și scalabile. De la funcții analitice la soluții de cluster, tehnologiile Oracle au toate funcționalitățile de care o organizație ar avea nevoie, indiferent cat de exigente sunt cerințele.

Pentru a putea utiliza baza de date Oracle cu toate funcționalitățile ei, Oracle a dezvoltat Oracle Application Express, aplicație practic integrata în baza de date fără nici un cost suplimentar – tot ceea ce este necesar este un browser WEB și nu necesită instalat nici un alt software (de exemplu Oracle Client). Aplicațiile se dezvoltă intr-un mediu browser-based și sunt folosite tot intr-un mediu browser-based. în plus, Oracle oferă posibilitatea de creare de aplicații în Cloud (https://apex.oracle.com), oferind posibilitatea de dezvoltare a unor aplicații fără nici un cost, aplicații care nu necesita totuși foarte mult spațiu, dar cu toate funcționalitățile disponibile în ultimele versiuni ale Oracle APEX și Oracle Database (am putea spune în special SQL și PL/SQL).

Scurtă istorie a versiunilor APEX și funcționalităților introduse

Prima lansare a fost în Februarie 2004, ca o nouă funcționalitate în Oracle Database 10g și a fost inițial denumită “HTML DB”. Aproximativ în fiecare an, apare o noua versiune Application Express.

Figura următoare reprezintă succint istoria versiunilor APEX și a noilor funcționalități adăugate cu fiecare versiune:

Figura IV-1 – Evoluția Oracle Application Express

In acest moment, APEX este folosit în general, în dezvoltarea următoarelor tipuri de aplicații:

Rapoarte pentru analiza datelor

Sisteme mari și scalabile

Înlocuitor al Microsoft Access

Înlocuitor pentru Oracle Forms

Site-uri web

Sisteme de urmărire

Soluții pentru telefoane mobile

Tipuri de arhitecturi și concepte cheie ce trebuie știute la instalarea/folosirea Oracle Application Express

Baza de date

Oracle APEX este o opțiune a bazei de date și nu necesita costuri suplimentare. Poate fi instalata în orice versiune a bazei de date Oracle mai mare decât 10.2.0.4 pentru toate tipurile de ediții: Enterprise Edition, Standard Edition, Standard Edition One și Express Edition (XE – o distribuție gratuită a Oracle Database). Începând cu Oracle Database 11.1, APEX este instalata ca parte a Bazei de Date și este necesar sa se upgradeze la ultima versiune APEX.

La instalarea Application Express se creează o schema separata (APEX_040200 pentru APEX 4.2) pentru a stoca procedurile care compun motorul Application Express cat și descrierea tabelelor necesare (metadata).

Este indicat sa se instaleze Oracle APEX într-o bază de date existentă, unde există deja toate obiectele necesare dezvoltării aplicației (tabele, proceduri stocate etc.…). Se pot utiliza Database Links pentru a integra aplicația cu alte servicii Web, alte baze de date, alte aplicații.

Figura – Arhitectura APEX

(Application Express Architecture)

Web Listener

Oracle Application Express utilizează o arhitectură simplă în care paginile sunt generate dinamic folosind metadate stocate în baza de date Oracle. Nu există nici o generare de cod sau fișiere de compilat. Odată instalat, Uniform Resource Locator (URL) va fi definit atât pentru dezvoltatori cât și utilizatorii finali pentru a accesa Application Express. Utilizatorii au nevoie doar de un browser Web și URL-ul necesar. Nu este necesară instalarea unui software suplimentar la client.

Figura IV-3 – APEX Web Listener

(Application Express Architecture)

Listener-ul Web funcționată ca un intermediar de comunicare între browser-ul web și obiectele Oracle Application Express în baza de date Oracle prin asocierea cererile browser-ul cu proceduri stocate în baza de date.

Exista următoarele opțiuni de a alege tipul de Listener:

Oracle REST Data Services (cunoscut ca și APEX Listener) – Este scris în Java și poate fi instalat pe orice server compatibil J2EE. Ca și celelalte componente APEX, este o opțiune gratuita care poate fi instalată împreuna cu Oracle WebLogic, Apache Tomcat și Oracle Glassfish Server. Oracle REST Data Services este o parte de referință a arhitecturi Oracle Database Cloud Service.

Această arhitectură este prezentată în figura următoare:

Figura IV-4 – REST Data Services

(Oracle Application Express Deployment )

Oracle HTTP Server  – acesta folosește un server Apache cu plug-in-un mod_plsql și poate fi instalat pe același server hardware ca și baza de date

Figura IV-5 – Oracle APEX folosind HTTP Server

(Application Express Architecture)

Embedded PL/SQL Gateway este o funcționalitate al Serverului de Baze de date Oracle. EPG pune la dispoziția bazei de date un server Web și de asemenea infrastructura necesară creării de aplicații dinamice. EPG rulează într-o a bazei de date numită “XML Database HTTP Server”, și include funcționalitățile de bază de la mod_plsql, dar nu necesită un web server separat

Figura IV-6 – Embeded PL/SQL Gateway

(Application Express Architecture)

Multi-Tenancy

Oracle APEX permite un număr mare de dezvoltatori sa creeze diferite aplicații folosind o singură bază de date. Aceasta este posibil deoarece dezvoltatorii pot lucra în medii de lucru dedicate (numite “work-area”) și pot dezvolta aplicații folosind mai multe scheme din baza de date. Aceasta arhitectură flexibilă face posibil ca baza de date sa lucreze ca “Platform as a Service” (PaaS).

Figura IV-7 – APEX Multy-Tenancy

(Database 2 Day + Application Express Developer's Guide)

Roluri și responsabilități

Există diferite roluri, responsabilități și privilegii. Cele mai importante sunt:

Administratorul Instanței – responsabil pentru configurări și monitorizare.

Administratorul workspace-ului – responsabil pentru monitorizarea și administrarea dezvoltatorilor aplicațiilor. în general este tot un dezvoltator

Dezvoltatorul – persoana care dezvoltă efectiv aplicația

Utilizatorul final – utilizatorii aplicației

Oracle Database

Baza de date Oracle este un puternic și flexibil Sistem de Management al Bazelor de Date Relaționale (RDBMS). Bazele de date Oracle sunt portabile peste un număr mare de stații de lucru și sisteme de operare, de la calculatoare personale simple la servere multi procesor.

Proprietăți ale bazelor de date relaționale

O baza de date relațională apare ca o colecție de relații(tabele) către utilizator.

Formatul coloanei/rândului este familiar și ușor pentru vizualizarea datelor .

Exista o mulțime de operatori pentru partiționarea și combinarea relațiilor(selecția,proiecția,produsul,joinul,uniunea, intersecția, diferența).

Nu sunt pointeri expliciți;conexiunile sunt făcute numai pe baza datelor.

Limbajul utilizat pentru interogarea bazei de date este non-procedural și similar limbii engleze.

Utilizatorul nu specifica calea de acces și nu are nevoie să știe cum este informația aranjata fizic.

Comenzile pentru refacerea datelor și acelea pentru realizarea schimbărilor în baza de date sunt incluse intr-un singur limbaj SQL.

Exista o independenta totala a datelor.

Serverul Oracle cuprinde un RDBMS care controlează:

mediul client / server (procesare distribuită) – pentru a avea toate avantajele unui sistem dat sau a unei rețele, Oracle permite ca procesarea să fie împărțită între serverul de baze de date și programul client.

Stocarea de date în sfera bazelor de date dedicate

Recuperarea de date pentru aplicații utilizând tehnici de optimizare adecvate

Securitatea bazelor de date și a taskurilor permise pentru anumiți utilizatori

mai mulți utilizatori concurenți ai bazei de date, asigurând integritatea și accesul concurent la date

Oracle poate fi configurat să funcționeze 24 ore pe zi fără limitarea utilizării bazei de date. Căderea parțiala a sistemului nu întrerupe utilizarea bazei de date, sau întreruperile sunt minime

Consistența, integritatea și protecția datelor,incluzând arhivări și mecanisme de căutare.

Comunicarea și integritatea informațiilor, când bazele de date sunt distribuite intr-o rețea.

deschidere, standard industrial – Oracle folosește standardele industriale acceptate pentru limbajul de acces la date, sistemul de operare, interfața utilizator, protocoalele de comunicație în rețea. Este un sistem deschis care protejează investiția comparatorului. Oracle satisface toate cerințele standardelor American National Standard Institute (ANSI), International Standards Organization (ISO standard 9075) și US Governement Federal Information Processing Standard FIPS-127).

Descrierea a unui server de baze de date Oracle

Un server Oracle consta dintr-o baza de date Oracle și o instanța Oracle.

In figura următoare este schematizata sumar structura unui server de baze de date Oracle:

Figura IV-8 structura unui server de baze de date Oracle

(Database Concepts)

Baza de date

Baza de date Oracle reprezintă o colecție de date tratate unitar, având ca scop salvarea/memorarea datelor precum în același timp cu citirea lor având mecanisme complexe pentru a împiedica accesul neautorizat la date dar și soluții eficiente de restaurare în caz de avarii.

Baza de date este formata din structuri fizice și logice. Deoarece acestea sunt separate, structurile fizice pot fi accesate fără a afecta accesul la structurile logice.

Structura fizică – o baza de date Oracle are o structura fizica determinata de fișierele sistemului de operare care constituie baza de date. Fiecare baza de date este constituita din trei tipuri de fișiere:

unul sau mai multe fișiere de date (data files) și temporare

Un fișier de date (data file) este un fișier fizic pe disk, care conține structuri de date cum sunt tabele sau indexi. De asemenea tot fișiere de date sunt numite fișierele sistem, unde sunt menținute date despre structura bazei de date (metadate), proceduri stocate, privilegii etc.….

Un fișier temporar este un fișier care conține date de tip temporar necesare funcționarii bazei de date.

Informațiile scrise în aceste fișiere sunt proprietare Oracle și nu pot fi citite de alte aplicații.

doua sau mai multe fișiere redo-log (redo log files) – conțin înregistrări cu modificările făcute asupra datelor. Aceste fișiere sunt necesare în primul rând pentru a asigura consistenta datelor în caz de avarii bruște.

unul sau mai multe fișiere de control (control files) – fișiere ce mențin modificările structurii fizice a bazei de date

Structura logică stabilește modul în care este utilizat spațiul fizic al bazei de date. Structura logica a bazei de date este determinata de:

unul sau mai multe spatii pentru tabele (tablespace). Spațiul pentru tabele (tablespace) este o zona logica de memorare a obiectelor schemei bazei de date.

Obiectele schemei sunt structuri logice care refera direct datele din baza de date. Schema include structuri cum at fi tabele, indexi, vizualizări, secvențe, funcții și proceduri stocate, sinonime și altele. Schema obiectelor și relațiile dintre ele formează designul relațional al bazei de date.

Instanța Oracle

Instanța reprezintă structurile de memorie și procesele folosite pentru a accesa datele (din structura fizica a bazei de date). La pornirea bazei de date, este alocata o zona de memorie sistem numita System Global Area (SGA) și sunt pornite procesele de background. SGA este zona de memorie folosita pentru partajarea informațiilor bazei de date intre utilizatori, având mecanisme clare și complexe de acces concurent la structuri de memorie, prevenind coruperea datelor.

O instanța Oracle are doua tipuri de procese: procese utilizator și procese Oracle. Un proces utilizator executa codul unui program de aplicație (cum ar fi sqlplus) . Procesul Oracle este procesul server (sau procesul foreground) care efectuează lucrul pentru procesele utilizator și procesele background care efectuează lucrul de întreținere pentru serverul Oracle.

O reprezentare schematică a unei instanțe Oracle poate fi considerată figura următoare:

Figura – – Reprezentare schematică a unei instanțe Oracle

(Database Concepts)

Structurile de memorie de bază:

System Global Area (SGA) – memorie partajată de procesele server și de background

Program Global Area (PGA) – memorie privată fiecărui proces (exista cate o memorie PGA pentru fiecare proces).

Principalele structuri de memorie în SGA sunt:

Database buffer cache: zona de memorie unde sunt ținute blocurile de date extrase din structura fizică (fișiere)

Redo log buffer: zonă de memorie unde sunt ținute informațiile redo înainte de a fi scrise pe disc

Shared pool: zonă de memorie unde sunt prezente diferite informații ce trebuie partajate intre utilizatori

Large pool: zonă de memorie opțională folosita pentru operații I/O mari

Java pool: zonă de memorie folosită de toate sesiunile care folosesc con Java și date din cadrul Java Virtual Machine (JVM)

Streams pool: zonă de memorie folosita de Oracle Streams

O reprezentare schematică a memoriei SGA este prezentată în figura următoare.

Figura – – Oracle SGA

Structured Query Language (SQL)

Pentru interogarea și manipularea datelor, Oracle folosește SQL – Structured Query Language – un limbaj de programare care definește și manipulează bazele de date. Se pot defini următoarele tipuri de comenzi

DDL – Data Definition Language – comenzi pentru definirea datelor (de ex.: CREATE TABLE …)

DML – Data Manipulation Language – comenzi pentru manipularea datelor (citire/inserare/modificare/ștergere).

Transaction Control Statements – comenzi care controlează schimbările făcute de comenzile DML (de ex.: COMMIT, ROLLBACK)

Session Control Statements – comenzi pentru managementul proprietarilor unei sesiuni (de ex.: ALTER SESSION …)

In plus fata de comenzile SQL, serverul Oracle are un limbaj procedural numit PL/SQL. Exceptând Session Control Statements și a unor forme speciale de COMMIT și ROLLBACK, toate celelalte tipuri de comenzi sunt posibile și în PL/SQL.

Istoric al versiunilor bazelor de date Oracle

1978 – versiunea 1

Scris în limbaj de asamblare

Cod separat pentru Oracle și pentru utilizatori

Rulează doar pe minicomputere PDP-11 (16-bit) în sistemul de operare RSX, având 128 Kb

Aceasta versiune de Oracle nu a fost niciodată disponibila oficial

1979 – versiunea 2

In vara anului 1979, Relational Software Link (cum s-a numit compania Oracle la început) a lansat versiunea 2, mai mult din motive de marketing, considerând ca în general clienții nu cumpăra prima versiune a unui software

Scrisa în limbajul de asamblare PDP-11. Rula pe sisteme de operare VAX/VMS

Aceasta versiune nu suporta tranzacții dar implementa funcționalități de baza ale limbajului SQL, precum interogări și join-uri

1980 – versiunea 3

Scrisa în limbajul C – limbaj portabil – ceea ce a făcut posibilă utilizarea Oracle pe sistemul de operare UNIX

Introduce tranzacțiile și execuția atomica a instrucțiunilor SQL

Începând cu aceasta versiune, compania își schimba numele din RSI în Oracle.

1980 – versiunea 4

Introduce consistența datelor la citire (read consistency)

Este portată pe desktop PC. Poate fi folosită pe sistemul de operare MS-DOS cu 64 kb memorie

1986 – Versiunea 5

Arhitectura client-server (mai multe stații client conectate la un singur server de baze de date)

Suport pentru VAX-cluster

Introduce interogări distribuite – permițând unei interogări să citească date din mai multe locații din rețea

1989 – Versiunea 6

Kernelul este aproape în întregime rescris

Îmbunătățiri pentru aplicațiile OLTP

Șalvari timpul funcționarii bazei de date (online backup and recovery)

Introduce blocaje la nivel de rând pentru a asigura integritatea tranzacțiilor

proceduri PL/SQL în Oracle Forms

Oracle Parallel Server – disponibil doar pe clustere VAX și nCube

1993 – Versiunea 7

Referințe de integritate

Proceduri PL/SQL stocate și trigere

Interogări executate în paralel, interogări împărțite în mai multe parți folosind cat mai mult puterea sistemelor cu procesoare multiple (SMP – Symmetric Multiprocessor Processing)

Partajarea cursoarelor SQL intre utilizatori

Advanced replication

Începând cu 1996 Oracle poate rula și pe Windows NT

1997 – Versiunea 8

Introduce paradigma internet and network computing – arhitectura pe trei niveluri

Suport pentru dezvoltarea orientata pe obiect

Facilități de a suporta un număr mare de utilizatori concurenți și date foarte mari, cum ar fi partiționarea tabelelor și indexilor

1999 – Oracle 8i (i – Internet)

Stocare cod Java în baza de date

Îmbunătățiri majore pentru partiționare

Îmbunătățiri pentru Data Warehouse

Suport XML

Oracle 8 și 8i sunt portate pe Linux

2001 – Oracle 9i

Introduce în total aproximativ 400 funcționalități noi

Apariția Real Application Clusters RAC ca înlocuitor al Oracle Parallel Server (OPS) – probabil cea mai importanta funcționalitate nou apărut , care, cu tehnologia “cache fusion” a permis scalabilitatea pe orizontală

Managementul Automat al Spațiului – Automatic Segment Space management

Îmbunătățiri de securitate pentru operarea în internet

Integrarea unor funcționalități de Business Inteligence

Data Guard

OMF – Oracle Managed Files

Suport pentru globalizare

2003 – Oracle 10g (g – Grid Computing)

Apariția Automatic Storage Management (ASM) – probabil ce mai importanta funcționalitate introdusă – permițând managementul disk-urilor și mărind performantele I/O

Automatic Workload Repository (AWR) – colectarea automata a datelor pentru managementul performantei bazei de date

Includerea Oracle Application Express (APEX ) în baza de date

2007 – Oracle 11g

Introduce Database Replay – un utilitar nou care permite capturarea statement-urilor SQL executate și rularea lor în alte condiții – utilitar foarte important și util în special în cazul upgrade-urilor (de aplicație, sistem de operare sau versiune Oracle)

Edition-Based Redefinition –cea mai revoluționară funcționalitate noua – permite modificarea aplicației fără a întrerupe funcționarea ei

Invisible Indexes – indexi care nu sunt văzuți/utilizați de aplicație, decât după ce s-a făcut testarea ca într-adevar ajută la îmbunătățirea performanțelor

2013 – Oracle 12c (c – Cloud computing)

Multitenant Architecture – permite bazei de date Oracle sa funcționeze ca un container de baze de date (CDB-Container Database) care include zero, una sau mai multe baze de date create de utilizatori (PDB-Plugable Database)

In-Memory database – o singură baza de date poate suporta încărcări mixte, livrând cu o performanța ridicată tranzacții de tip OLTP în același timp suportând calcule analitice și rapoarte în timp real

Studiu de caz – Dezvoltarea Aplicației

Arhitectura folosită la implementarea aplicației la firma Hotline Software Solutions S.R.L

Pentru implementarea aplicației am ales o arhitectură pe 2 niveluri (2-Tier) și configurarea APEX pentru a folosi “Embedded PL/SQL Gateway (EPG)” ca mod de conectare la baza de date

Versiunea Oracle Application Express folosită este APEX 4.2

Sistemul de Operare: Red Hat Enterprise Linux Server release 6.3 – 64 bit – 2 noduri în cluster

Server de baze de Date: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 – 64bit – 2 noduri în RAC

Am folosit Oracle Dataguard ca soluție “Disaster Recovery” și am instalat și configurat Oracle Dataguard Primary RAC 2 noduri și Standby Database RAC 2 noduri, după cum se poate vedea în figura următoare:

Figura V-1 – Schema arhitecturală a aplicației HMS

În figura de mai sus, „Primary site” reprezintă centrul de calcul unde se conectează și funcționează aplicația. Acesta este format dintr-un Real Application Cluster (RAC) cu doua noduri (două instanțe Oracle) și un storage comun ce conține fișiere bazei de date. Datele sunt replicate către centrul de calcul „Standby site” folosing tehnologia Oracle Dataguard. „Standby site” este situat în altă cladire, la o distanță de 2 km iar în situația în care centrul de calcul „Primary” este complet nefuncțional, se declanșează procedura „fail-over” – situația în care aplicația se conecteză la „Standby”, care în felul acesta devine „Primary” pană la repunerea în funcțiune al vechiului „Primary site”. Tot acest proces este transparent aplicației, care nu necesita nici o schimbare.

Structura bazei de date

Diagrama entitate relație

Figura V-2 – Diagrama Entitate Relație

În diagrama entitate relație putem distinge:

O relație de unul-la mai mulți între:

Tabela CLIENTS și tabela REACTIVE_CLIENTS – ceea ce înseamnă că un client poate fi activ în același timp de mai multe ori (echipe diferite, contracte diferite etc…)

Tabela TEAMS și tabela REACTIVE_CLIENTS – ceea ce înseamnă că pot exista mai mulți clienți activi la o echipă

Tabela TEAMS și tabela INCIDENT_LOG – ceea ce înseamnă că pot exista mai multe incidente raportate pentru o echipă

Tabela TEAMS și tabela TEAM_MEMBERS – ceea ce înseamnă că o echipă este compusă din mai mulți membri și de asemenea ca un inginer poate face parte din mai multe echipe simultan

Tabela TEAMS și tabela PROJECT_ACCOUNTING – ceea ce înseamnă că o echipă poate ponta pe mai multe proiecte

Tabela ENGINEERS și tabela PROJECT_ACCOUNTING – ceea ce înseamnă că un inginer poate ponta pe mai multe proiecte

Tabela ROTE și tabela ENGINEERS – ceea ce înseamnă că un inginer poate fi parte din mai multe rote

Tabela TEAMS și tabela ROTE – ceea ce înseamnă că o echipă poate fi prezentă în programări de mai multe ori

Tabela DAILY_RATE nu are definită nici o cheie străină către alte tabele. Ea este folosință doar pentru a putea defini valoarea unei zile de lucru și pentru istoricul acesteia.

Descrierea tabelelor

Baza de date este formată din următoarele tabele:

CLIENTS – tabela cu numele clienților

DAILY_RATE – tabela cu valoarea în moneda a unei zile de lucru

REACTIVE_CLIENTS

– PROJECT_ACCOUNTING

INCIDENT_LOG – tabela pentru a tine evidenta orelor pontate pentru fiecare incident

ROTE – tabela cu programarea activității pentru on-call

ENGINEERS – tabela cu inginerii disponibili

TEAMS – tabela cu numele echipelor

TEAM_MEMBERS – tabela cu membrii echipelor

Vizualizări (vederi)

MONTH_YEAR_VW

Această vedere este folosită pentru a vizualiza evoluția pe luni a clienților activi. Este necesară crearea acestei vederi deoarece în tabela REACTIVE_CLIENTS sunt stocate DATA_START și DATA_STOP reprezentând data începerii contractului respectiv data terminării.

Această vizualizare folosește următorul cod SQL:

Rezultatul fiind detalierea pe fiecare lună, de exemplu:

Declanșatoare

Declanșatoarele sunt proceduri PL/SQL atașate unei tabele care se execută automat în cazul unui eveniment (adăugare/ștergere/modificare).

În această aplicație, toate tabelele au câte o cheie primară definită, ce permite identificarea unică a fiecărui rând. Pentru a menține automat această cheie unică, s-au folosit declanșatoare de tipul „BEFORE INSERT” – înainte de adăugare, împreuna cu obiecte secvență ce asigură unicitatea numerelor

Codul general al unui declanșator este:

Exemplificăm aici doar pentru tabela INCIDENT_LOG:

Definiția secvenței incident_log_seq este:

Implementarea produsului software Hotline Management System la firma Hotline Software Solutions S.R.L.

Hotline Software Solutions S.R.L. este o companie care are ca principal obiectiv de activitate producerea de software precum și servicii de mentenanță și suport pentru produsele proprii.

Hotline Software Solutions SRL folosește la nivel de organizație Oracle E-Business Suite, un ERP având implementate și funcționale următoarele aplicații:

Oracle Financials – un set de aplicații financiare folosite în lume pentru afaceri

Oracle HRMS (Human Resource Management System) – aplicații pentru management al resurselor umane

Oracle SCM (Supply Chain Management) – aplicații pentru managementul aprovizionărilor

Oracle Projects – aplicații pentru managementul proiectelor

Oracle CRM (Customers Relationship Management – aplicație pentru managementul relațiilor cu clienții

Oracle Procurement – aplicație pentru controlul și managementul achizițiilor

Figura următoare reprezintă integrarea aplicației cu aplicațiile deja existente, folosind o bază de date comună la nivel de organizație.

Figura VI-1 – Integrarea aplicației în sistemul ERP al companiei

Utilizarea aplicației

Înainte de a prezenta funcționarea aplicației am sa prezint unele tipuri de obiecte des întâlnite, pentru a înțelege mai bine funcționarea lor.

Rapoarte interactive – sunt rapoarte care permit căutare, filtrare, ordonare și multe alte funcționalități.

Pentru exemplificare, luăm raportul “Active Clients” simplificat, prezent în secțiunea User-»Active Clients:

In căsuța specială pentru căutare, se poate introduce orice text (în exemplul de mai sus ‘300424192’ pe care vrem sa-l căutam în raport (în tot raportul, indiferent câte linii are, nu doar în pagina curentă), și se apăsa butonul . Implicit se va face căutare în toate coloanele. în cazul unui raport mai mare, cu multe linii și multe coloane, pentru a mări performanța căutării, prin apăsarea lupei din stânga căsuței de căutare, se poate alege coloana în care dorim să facem căutarea:

Prin “click” pe o coloana, se poate ordona crescător sau descrescător raportul în funcție de valorile text din coloană, se poate ascunde o coloană pentru a nu mai fi afișată și, prin apăsarea butonul “Control-Break” se pot face grupări. De exemplu, raportul grupat pe nume echipă ar arăta în felul următor:

Revenind la forma inițiala a raportului, prin apăsarea butonul se deschide un meniu interactiv :

Acest meniu permite:

Selectarea coloanelor dorite pentru afișare

Filtrarea datelor în funcție de anumite criterii: valori egale cu un număr, valori diferite de un număr, text care sa conțină anumite caractere, text care nu conține anumite caractere

Se poate modifica numărul inițial de rânduri per pagină (inițial 15)

Din submeniul “Format” se pot face

Sortări pe mai multe coloane, se pot evidenția prin culori diferite anumite rânduri, în funcție de anumite criterii (de exemplu toate liniile pentru echipa “RDBMS” pot fi colorate în galben, cele pentru echipa “FMW” colorate în roșu etc.…)

Calcule simple sau complexe pe numere, șiruri de caractere

Calcule agregate: media, număr total, suma, minim, maxim

Se pot crea grafice

Se pot face grupări mai complexe, pe mai multe coloane

Prin alegerea meniului se pot vizualiza datele exact așa cum erau în trecut, chiar daca au fost intre timp modificate sau șterse. Aceasta este o funcționalitate a bazei de date Oracle (Flashback Query), care este implementată aici.

Salvarea tuturor modificărilor făcute asupra raportului. Acesta va fi vizibil doar pentru utilizatorul care l-a creat, permițând astfel fiecărui utilizator să-și particularizeze propriul raport.

Resetarea tuturor modificărilor și aducerea raportului la forma inițială

Ajutor interactiv pentru utilizarea acestor tipuri de rapoarte

Salvarea/exportarea datelor pe calculatorul local în format CSV sau HTML. Această facilitate de a salva rapoartele în format CSV este uneori foarte utilă deoarece acest format este universal acceptat și foarte multe aplicații permit importul datelor în baza de date din fișiere în format CSV. De asemenea, raportul se poate trimite direct în căsuța poștală

Rapoarte simple – sunt rapoartele care permit doar vizualizarea în datelor foră a putea face nici un fel de manipulare a lor: căutări, ordonări, filtrări etc.…, având active doar butoanele pentru vizualizarea datelor (pagina următoare și pagina precedentă).

Formulare interactive – oferă aceleași funcționalități ca și rapoartele interactive și în plus permit manipularea datelor: modificare/ștergere/adăugare rând. Pentru a adăuga un rând, se apăsa butonul , fapt ce deschide un formular nou, pentru a putea crea rânduri noi. Pentru a modifica/șterge un rând, se apasă pictograma .

Liste de valori – folosite la completarea anumitor date cu valori dintr-o lista. Sunt folosite pentru: Clienți, Echipe, Ingineri. De exemplu, pentru clienți, lista arată în felul următor:

Pagina login

Accesul în aplicație se face cu un nume de utilizator și o parolă. Pentru a minimiza/elimina posibilitatea folosirii frauduloase, dacă parola nu este știută, nu este permisă introducerea din nou a parolei decât după un număr de secunde care crește din 5 în 5 pentru fiecare încercare eșuată

Figura VI-2 – Încercare eșuata de acces în aplicație

Fiecărui utilizator îi este asociat un rol. În funcție de acest rol, utilizatorul poate avea acces la diferite funcționalități/opțiuni de meniu.

Rolurile disponibile sunt:

ADMIN – poate adăuga clienți, angajați (ingineri), forma echipe, activa și inactiva proiecte și clienți, monitoriza și modifica istoricul intervențiilor, vizualiza graficele și statisticile din secțiunea “Management”

USER – acces de a vizualiza persoanele de serviciu la data curentă, vizualizare clienți activi , vizualizare echipe, modificare istoric intervenții

MGR – ceea ce conține rolul USER și în plus acces la grafice privind evoluția numărului de clienți, încărcarea pe echipe și veniturile realizate din activitatea de asistență 24×7

Utilizarea aplicației – Rolul USER

După autentificarea în aplicație, utilizatorul care are definit rolul USER are posibilitatea selectării următoarelor opțiuni de meniu: Home, Active Client, Team Members, Incident Log.

Meniul “Home” – utilizatorul poate vedea cine este de serviciu în ziua curentă:

Figura VI-3 – Vizualizare ingineri OnCall și numere de telefon hotline

In acest tabel, OC înseamnă OnCall (cel care se ocupa inițial de incident) iar BK – Backup (cel care ajută, în caz de nevoie).

Meniul “Active Clients”, utilizatorul poate vizualiza clienții activi, inițial intr-un mod simplificat având doar coloanele “Echipa”, “Nume Client” și “Număr proiect”, precum și un grafic în format “apple-pie”, conținând numărul de clienți pentru fiecare echipă în parte:

Figura VI-4 – Vizualizare clienți activi

Inițial este afișată o variantă simplificată, conținând numele echipei, numele clientului ți numărul proiectului. S-a ales această formă deoarece inginerii trebuie să afle la orice moment ce clienți sunt activi pentru echipa lor dar și proiectul pe care trebuie să ponteze în caz de nevoie.

Utilizatorul poate apăsa pe butonul pentru a vizualiza toate informațiile despre clienți, informații care includ: echipa la care este arondat clientul, țara de proveniență, numărul proiectului pe care sa vor face decontările activității prestate, data de început și de sfârșit a contractului, persoana de contact, tipul de asistență (8×5 sau 27×7) precum și alte însemnări particulare fiecărui client/contract.

Figura VI-5 – Vizualizare și interogare clienți activi

Prin apăsarea butonului se revine la pagina precedentă, în care se poate vedea și graficul “Active Clients per Team”, grafic util pentru a face o predicție a numărului viitor de incidente și eventualitatea folosirii a 2 ingineri de serviciu, rotindu-se între ei în funcție de încărcare.

Meniul “Team Members” permite vizualizarea componenței echipelor, a numărul de telefon și adresei de e-mail, după cum se poate vedea în figura următoare:

Figura VI-6 – Componența Echipelor, date de contact

Vizualizarea acestor informații este necesară deoarece există situații în care incidentul raportat de client este multidisciplinar, necesitând intervenție din mai multe domenii.

Meniul “Incident Log” permite inginerilor sa raporteze orele petrecute, și pontate pe un anumit proiect. Aceste adăugări și eventuale modificări de date se fac cu ajutorul unui formular interactiv :

Figura VI-7 – Formular Incidente

Acest formular este bazat pe tabela INCIDENT_LOG. Explicația coloanelor:

Month: Luna incidentului

Year: Anul incidentului

Engineer: persoana care a participat, care a pontat ore pe proiect

Client: numele clientului

Pa: – numărul proiectului activ pentru perechea client,echipă

Task: numele/numărul task-ului raportat de client

Duty Hrs: ore pontate în timpul programului de lucru

Ooh Hrs: ore pontate în afara orelor de program (Out of Office Hours)

Team: echipa pentru care s-a raportat incidentul

În această pagină este disponibil și un link, către aplicația Oracle Time and Labor (OTL), aplicație folosită la nivel de organizație pentru salarizare, plați, evidență concedii etc…

Figura VI-8 – Transferul pontajelor în OTL

Datele pot fi introduse manual eventual prin copiere-lipire a numărului de proiect. Dacă sunt multe incidente/date se poate filtra lista conținând date doar pentru un anumit utilizator și salva datele în format CSV. Acest fișier poate fi ulterior importat în aplicația „Projects Accounting&Payroll”.

Utilizarea aplicației – Rolul MGR

Meniul “Active Clients History”

Figura VI-9 – Evoluție Număr Clienți Activi

In acest grafic se poate observa în perioada 01-Mai-2014 – 01-Dec-2014 un maxim de 46 de clienți activi, iar după această perioadă numărul începe să scadă ceea ce trage un semnal de alarmă in vederea atragerii de clienți noi sau reînnoirii contractelor celor care au expirat.

Meniul „Workload” avem evidența încărcării echipelor (orelor efectiv muncite).

Figura VI-10 – Istoric activitate

Se poate observa creșterea activității pe toate echipele, începând cu Februarie 2015.

Pentru a avea o imagine de ansamblu, un manager (utilizator din grupul MGR), poate vizualiza și situația numărului de clienți activi pe echipă, apăsând butonul „Active Clients”:

Figura VI-11 – Număr Clienți activi pe echipe

Deasemenea, se pot vizualiza și următoarele informații:

Încărcarea pe fiecare inginer (numărul de ore lucrate)

Figura VI-12 – Încărcare pe ingineri

Cel mai activ client – clientul cu cele mai multe incidente, deci care produce venituri mai mari.

Figura VI-13 – Încărcare pe clienți

De menționat că în general acești clienți sunt clienți foarte mari, cu un număr mare de sisteme instalate, ceea ce crește probabilitatea incidentelor, indiferent de ce tip.

În graficul Teams Workload, se observă o creștere a incidentelor și în consecință a orelor de muncă.

Meniul “Income Standby&Incidents”

Figura VI-14 – Venituri pe tip de activitate: standby și call-out

In graficul Income, se observă o scădere a veniturilor datorate activității de standby datorită faptului ca a scăzut numărul de clienți și în același timp se observă o creștere a veniturilor datorată incidentelor, cel mai probabil pentru faptul ca a fost o perioadă în care foarte mulți clienți au upgradat aplicațiile la versiuni și sisteme noi. În acest context, este de așteptat ca veniturile din acest tip de activitate să scadă, după stabilizarea sistemelor. în consecință, este nevoie de mai mulți clienți pentru a crește din nou componenta standby.

Utilizarea aplicației – Rolul ADMIN

„După autentificarea în aplicație, utilizatorul care are definit rolul ADMIN are acces la toate opțiunile utilizatorilor cu rolurile USER și MGR și în plus are acces la meniul principal Admin, care oferă acces la următoarele secțiuni din meniul secundar: „Active Clients”, „Projects Accounting”, „Teams”, „Engineers”, „Teams&Engineers”, „Clients”.

Meniul „Active Clients” – permite gestionarea informațiilor legate de clienți, activarea și inactivarea lor folosind un formular interactiv

Figura VI-15 – Formular clienți activi

În plus față de un formular standard, la apăsarea pictogramei , pe lângă butoanele comune precum , avem și butonul care are aceeași funcționalitate ca și butonul , cu deosebirea că, în plus, câmpurile sunt deja completate cu datele aferente liniei respective:

Figura VI-16 – Adăugare/modificare/ștergere clienți activi

Descrierea coloanelor:

Client:numele clientului

Status: Activ (A) sau Inactiv (I). Inactiv poate fi un client căruia i-a expirat contractul de mentenanță.

Team – Numele echipei la care este asignat clientul

Country: țara clientului

CSI – numai de identificare al clientului – este unic pentru fiecare client

PA – proiectul asociat contractului

At – Task-ul asignat (Assignable Task) – prin acest număr, se poate face legătura cu o alta aplicație din ERP – Service Infrastucture (aplicație ce gestionează toate serviciile la nivel de organizație)

Data Start – Data la care a început contractul

Data Stop – Data la cere se termina contractul. Contractele sunt pe perioada determinată, în general pe 6 sau 12 luni.

Contact: persoana de contact de la client

OC Type – tipul de standby, poate avea 2 valori:

8×5 – 8 ore pe zi, 5 zile pe săptămâna (în timpul orelor de program, nu și sărbători legale)

24-7 – 24 ore pe zi, 7 zile pe săptămâna (non-stop)

Days per month: zile de pontat conform contractului, pentru activitatea de standby

Reason Not Renew – Motivul pentru care nu a fost reînnoit un contract (necesar pentru referințe ulterioare, informație eventual necesară pentru departamentul vânzări).

Meniul „Projects Accounting” – în acest meniu se ține evidența orelor pontate în fiecare lună pentru activitatea de standby (on-call).

Pentru o mai bună înțelegere a acestor pontaje, definiția a ce înseamnă activitate de standby și call-out este următoarea:

activitate de standby – înseamnă ca cineva (un inginer în cazul nostru) este disponibil la orice oră să răspundă la telefon și sa intervină în caz de nevoie. în cazul în care nu apare nici un incident, tipul se pontează ca „on-call”.

call-out – dacă este semnalat un incident, inginerul pontează pe proiect numărul de ore lucrate, având ca tip de pontaj call-out.

Valoare unei ore de muncă on-call sau call-out este calculată ca procent din valoare unei ore normale de lucru, procentele fiind diferite și stabilite la nivel de organizație, în aplicația „Projects Accounting&Payroll” .

La încheierea contractului, este stabilită o anumită sumă pentru activitatea de standby, sumă care se transformată în ore, pentru a se putea realiza pontajul. În funcție de client, activitatea de standby poate fi intre 8 și 32 ore (1-4 zile). Aceste ore sunt pontate de membrii echipelor iar administratorul aplicației trebuie să țină evidența pentru a nu se depăși (overbooking) sau ponta mai puțin (underbooking).

Figura VI-17 – Evidența pontaj activitate standby

În partea stângă, cu ajutorul unui formular interactiv, se introduc orele pontate de fiecare inginer pe proiecte. Această activitate se poate considera finalizată în momentul în care în partea dreapta, în tabelul „Standby not booked” nu mai rămâne nici o linie – semn că toate activitățile de standby au fost pontate. Ca și la secțiunea „Incident Log” din meniul „User” (unde se ține evidența orelor call-out), și aici exista un link către aplicația „Projects Accounting&Payroll” din organizație.

Datele se introduc după cum sunt selectate luna și anul din partea stânga sus. Modificând aceste date, se pot vizualiza datele din trecut, după cum putem vedea în figura următoare, pentru luna precedentă:

Figura VI-18 – Exemplu vizualizare pontaje în trecut

După cum se poate vedea, în tabelul din dreapta nu există nici o linie, doar informarea că toate proiectele au fost pontate.

Meniul „Teams”

Figura VI-19 – Definire echipe

Meniul „Engineers”

Figura VI-20 – Angajații disponibili pentru alcătuirea echipelor

Meniul „Teams&Engineers”

Figura VI-21 – Formare echipe

O echipă trebuie sa fie formată din minimum 2 ingineri, iar, în funcție de competențe, un inginer poate fi în mai multe echipe.

Meniul Clients

Figura VI-22 – Definire Clienți

In acest formular se gestionează doar numele clienților, care trebuie sa fie unic. Celelalte informații precum persoana de contact sunt gestionate în meniul Admin-»Active Clients

Meniul “Standby Rota” – permite programarea echipelor standby, astfel încât oricine sa știe programările din trecut dar în special din viitor:

Figura VI-23 – Rote on-call

Această pagină este creată cu ajutorul unui raport interactiv, rândurile fiind grupate pe echipe iar raportul este salvat astfel încât este comun tuturor utilizatorilor (care bineînțeles ca pot schimba). Coloanele din tabel reprezintă numărul săptămânii iar culorile reprezintă: Roșu – înseamnă OnCall (cel care se ocupa inițial de incident) iar Galben reprezintă Backup (cel care ajută, în caz de nevoie).

Modificările în acest raport se fac prin apăsarea celulei în dreptul unde se dorește modificare, caz în care va fi disponibil următorul formular de modificare a datelor:

Figura VI-24 – Formular modificare rota

Concluzii

Dezvoltarea și implementarea aplicației Hotline Management System în cadrul firmei Hotline Software Solutions S.R.L. va permite o gestionare, programare și monitorizare a serviciilor de suport de tip hotline. Deasemenea, va permite factorilor de decizie să vizualizeze și să analizeze activitatea curentă, raportată la numărul de angajați, numărul de clienți activi și încărcarea propriuzisă.

Dezvoltări ulterioare ale aplicației:

Cu puțin timp înainte de expirarea contractului, de trimis un e-mail automat către Account Manager, care să conțină numărul de ore pontate și atenționarea expirării contractului;

Cerere feedback de la clienți pentru serviciul livrat, în vederea îmbunătățirii serviciilor. Posibilitatea vizualizării lor de către manageri în vederea evaluării anuale a perfornamțelor angajaților;

E-mail automat către ingineri, în momentul în care se modifică ceva important: de exemplu Numărul Proiectului, Adăugare client, modificare stare client activ-inactiv etc.;

E-mail automat către manager în situația în care veniturile scad sub o anumită valoare definită în sistem;

Crearea unui serviciu de noutăți ce va conține informații noi necesare în desfășurarea activității (de exemplu modificări în componența echipelor, informații noi despre un client etc…);

Crearea unei versiuni pentru telefoane mobile – în acest mod, utilizatorii aplicației pot verifica de pe un telefon mobil cine este de servici la un anumit moment, numere de telefon, starea contractului (activ/inactiv), se pot efectua pontaje pe proiecte, care, în anumite situații este urgent, dacă nu s-a efectuat la timp (de exemplu înainte de închidera de lună).

Bibliografie

Davenport, T. H., „Putting the enterprise into the enterprise system”, Harvard Business Review, 1998

Johansson, Björn; „Bjørn-Andersen, Identifying Requirements for Future ERP Systems” (2007)

Liaquat Hossain, Jon David Patrick, Mohammad A. Rashid , „The Evolution of ERP Systems: A Historical Perspective”

Rick Greenwald, „Beginning Oracle Application Express”, Wiley Publishing Inc.,Indianapolis, Indiana

APICS (2001). American Production and Inventory Control Society (APICS),

http://www.apics.org.

„Charisma ERP 2015” , http://www.charisma.ro

„Top 20 ERP Software”, http://www.Business-Software.com

http://www.oracle.com

Anexa 1

Figura I-1 – Diagrama ERP 5

Figura I-2 – Evoluția istorică a sistemelor ERP 6

Figura IV-1 – Evoluția Oracle Application Express 19

Figura IV-2 Arhitectura APEX 21

Figura IV-3 – APEX Web Listener 22

Figura IV-4 – REST Data Services 23

Figura IV-5 – Oracle APEX folosind HTTP Server 24

Figura IV-6 – Embeded PL/SQL Gateway 24

Figura IV-7 – APEX Multy-Tenancy 25

Figura IV-8 structura unui server de baze de date Oracle 27

Figura IV-9 – Reprezentare schematică a unei instanțe Oracle 30

Figura IV-10 – Oracle SGA 31

Figura V-1 – Schema arhitecturală a aplicației HMS 37

Figura V-2 – Diagrama Entitate Relație 38

Figura VI-1 – Integrarea aplicației în sistemul ERP al companiei 46

Figura VI-2 – Încercare eșuata de acces în aplicație 52

Figura VI-3 – Vizualizare ingineri OnCall și numere de telefon hotline 53

Figura VI-4 – Vizualizare clienți activi 54

Figura VI-5 – Vizualizare și interogare clienți activi 55

Figura VI-6 – Componența Echipelor, date de contact 56

Figura VI-7 – Formular Incidente 57

Figura VI-8 – Transferul pontajelor în OTL 58

Figura VI-9 – Evoluție Număr Clienți Activi 59

Figura VI-10 – Istoric activitate 60

Figura VI-11 – Număr Clienți activi pe echipe 60

Figura VI-12 – Încărcare pe ingineri 61

Figura VI-13 – Încărcare pe clienți 61

Figura VI-14 – Venituri pe tip de activitate: standby și call-out 62

Figura VI-15 – Formular clienți activi 63

Figura VI-16 – Adăugare/modificare/ștergere clienți activi 64

Figura VI-17 – Evidența pontaj activitate standby 66

Figura VI-18 – Exemplu vizualizare pontaje în trecut 67

Figura VI-19 – Definire echipe 67

Figura VI-20 – Angajații disponibili pentru alcătuirea echipelor 68

Figura VI-21 – Formare echipe 68

Figura VI-22 – Definire Clienți 69

Figura VI-23 – Rote on-call 70

Figura VI-24 – Formular modificare rota 70