Programul de studii [629271]
UNIVERSITATEA „TRANSILVANIA” DIN BRAȘOV
FACULTATEA DE ȘTIINȚE ECONOMICE ȘI ADMINISTRAREA AFACERILOR
Programul de studii
SISTEME INFORMATICE INTEGRATE PENTRU AFACERI
LUCRARE DE DISERTAȚIE
Conducător științific
Prof. univ. dr. Lixăndroiu Dorin
Absolvent: [anonimizat]
2017
UNIVERSITATEA „TRANSILVANIA” DIN BRAȘOV
FACULTATEA DE ȘTIINȚE ECONOMICE ȘI ADMINISTRAREA AFACERILOR
Programul de studii
SISTEME INFORMATICE INTEGRATE PENTRU AFACERI
LUCRARE DE DISERTAȚIE
Implementarea unui Sistem Informatic Integrat în Universitățile
Românești
Conducător științific
Prof. univ. dr. Lixăndroiu Dorin
Absolvent: [anonimizat]
2017
FIȘA LUCRĂRII DE DISERTAȚIE
Universitatea Transilvania din Brașov
Lucrare de disertație nr. ……….
Facultatea Științe Economice și Administrarea
Afacerilor
Departamentul Management și Informatică Economică
Viza facultății
Programul de studii
Sisteme Informatice Integrate pentru Afaceri
Anul universitar 2016 -2017
Candidat: [anonimizat] 2015 -2017
Cadrul didactic îndrumător
Prof. univ. dr. Lixăndroiu Dorin
LUCRARE DE DISERTAȚIE
Titlul lucrării: Implemenatrea unui Sistem Informatic Integrat în Universitățile Românești
Problemele principale tratate:
Cap. 1 Aspecte conceptuale și metodologice cu privire la sistemele informatice de tip ERP
Cap. 2 Microsoft Dyna mics NAV
Cap. 3 Implementarea unui sistem informatic integrat în universitățile Românești
Cap. 4 Arhitectura de bază a sistemului ERP
Cap. 5 Concluzii și propuneri
Locul și durata practicii: SC Axians Infoma SRL
Bibliografie:
1. Fotache D., Hurbean L., Soluții informatice integrate pentru gestiunea afacerilor – ERP, Editura
Economică, București, 2004.
2. Cerruti C., Sistemi informativi e capacità competitiva. L'introduzione dei sistemi ERP nella
grande impresa, Editura G. Giappichelli, Torino .
Aspecte particulare:
(desene, aplicații practice, metode specifice etc.)
Primit tema la data de:
Data predării lucrării:
Director departament, Cadru didactic îndrumător,
(nume, prenume, semnătura)………………………………………………… (nume, prenume, semnătura)
Candidat,
(nume, prenume, semnătura)
Stan Roxana Maria
LUCRARE DE DISERTAȚIE – VIZE
Data vizei Capitole/ problemele analizate Semnătura cadrului
didactic îndrumător
20.11.2016 Cap. 1 Aspecte conceptuale și metodologice cu privire la
sistemele informatice de tip ERP
10.01.2017 Cap. 2 Microsoft Dynamics NAV
20.03.2017 Cap. 3 Implementarea unui sistem informatic integrat în
universitățile Românești
25.04.2017 Cap. 4 Arhitectura de bază a sistemului ERP
25.05.2017 Cap. 5 Concluzii și propuneri
APRECIEREA ȘI AVIZUL CADRULUI DIDACTIC ÎNDRUMĂTOR
Data:
ADMIS pentru susținere/
RESPINS CADRU DIDACTIC ÎNDRUMĂTOR
(nume, prenume, semnătură)
AVIZUL DIRECTORULUI DE DEPARTAMENT
Data:
ADMIS pentru susținere/
RESPINS Director departament
(nume, prenume, semnătură)
SUSȚINEREA LUCRĂRII DE DISERTAȚIE
Sesiunea
Rezultatul
susținerii PROMOVAT cu media:
RESPINS cu refacerea lucrării
RESPINS fără refacerea lucrării
PREȘEDINTE COMISIE
(nume, prenume, semnătura)
1
CUPRINS
INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. …………………… 2
CAP. 1. ASPECTE CONC EPTUALE ȘI METODOLOG ICE CU PRIVIRE LA SI STEMELE INFORMATICE DE TIP ERP …………. 4
1.1. DEFINIREA SISTEMELOR DE PLANIFICARE A RESURSELOR ÎNTREPRINDERII ………………………….. ………………….. 4
1.2. AVANTAJE, DEZAVANTAJE ȘI RISCURI ………………………….. ………………………….. ………………………….. ……………. 5
1.2.1. Avantajele implementării sistemelor ERP ………………………….. ………………………….. ………………………….. .. 5
1.2.2. Dezavantajele implementării sistemelor ERP ………………………….. ………………………….. ………………………. 6
1.2.3. Clasificarea riscurilor ………………………….. ………………………….. ………………………….. ………………………….. . 7
1.3. IMPLEMENTAREA SISTEMELOR ERP ………………………….. ………………………….. ………………………….. ……………. 10
1.3.1. Principalii participanți în dezvoltarea unui sistem informatic ………………………….. ………………………….. . 11
1.3.2. Costul unui sistem ERP ………………………….. ………………………….. ………………………….. ……………………….. 12
1.3.3. Eșuarea implementărilor ………………………….. ………………………….. ………………………….. ……………………. 15
1.4. TENDINȚE ERP ………………………….. ………………………….. ………………………….. ………………………….. ……………… 16
CAP.2. MICROSOFT D YNAMICS NAV ………………………….. ………………………….. ………………………….. ………………. 17
2.1. PREZENTARE GENERALĂ ………………………….. ………………………….. ………………………….. ………………………….. .. 17
2.1.1. Caracteristicile soluției Microsoft Dynamics NAV ………………………….. ………………………….. ……………….. 18
2.2. MICROSOFT DYNAMICS NAV – PREZENTARE ARHITECTURÃ ………………………….. ………………………….. ……….. 19
2.3. SECURITATEA ÎN NAVISION ………………………….. ………………………….. ………………………….. ……………………….. 21
CAP.3 IMPLEMENTAREA UNUI SISTEM INFORMAT IC INTEGRAT ÎN UNIVE RSITĂȚILE ROMÂNEȘTI …………………… 23
3.1. MOTIVAȚII CARE DETERMINĂ IMPLEMNETAREA SISTEMULUI INTEGRAT NAVISION ÎN UNIVERSITĂȚILE DIN
ROMÂNIA ………………………….. ………………………….. ………………………….. ………………………….. …………………………. 24
3.1.1. Analiza SWOT a implementării sistemului ERP – NAV ………………………….. ………………………….. …………. 25
3.1.2. Identificarea riscurilor și a beneficiilor implementării noului sistem în Universități ………………………….. 26
3.1.3. Identificarea echipelor de lucru ………………………….. ………………………….. ………………………….. …………… 28
3.2. INSTRUMENTE FOLOSITE ÎN IMPLEMENTAREA SISTEMULUI INFORMATIC ………………………….. ………………… 33
3.2.1. Microsoft Dynamics Sure Step și Gantt Project ………………………….. ………………………….. ………………….. 33
3.2.2. Metodologia Agile – SCRUM ………………………….. ………………………….. ………………………….. ……………….. 41
3.2.3. Team Foundation Server – TFS ………………………….. ………………………….. ………………………….. ……………. 43
3.3. ELEMENTE CHEIE PRIVIND RELAȚIA FURNIZOR – BENEFICIAR ………………………….. ………………………….. ………. 44
CAP. 4. ARHITECTURA DE BAZĂ A SISTEMULUI ERP ………………………….. ………………………….. ……………………….. 48
4.1. STABILIREA MODULELOR DE BAZĂ A SISTEMULUI ERP ………………………….. ………………………….. ……………….. 48
4.2. IMPLEMENTAREA UNEI SOLUȚII INTEGRATE PILOT ………………………….. ………………………….. ……………………. 56
4.2.1. Funcționalitățile generale ale modulului de Resur se Umane ………………………….. ………………………….. .. 56
4.2.2. Gestionarea modulului ”Resurse umane” – Microsoft Dynamics NAV ………………………….. ……………….. 57
CAP. 5. CONCLUZII ȘI PROPUNERI ………………………….. ………………………….. ………………………….. ……………………. 61
5.1. CONCLUZII ………………………….. ………………………….. ………………………….. ………………………….. ………………….. 61
5.2. PROPUNERI ………………………….. ………………………….. ………………………….. ………………………….. …………………. 62
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. ………………….. 63
2
INTRODUCERE
Lucrarea este o imagine de ansamblu referitoare la sistemele informatice integrate de
tip ERP, cu reliefarea rolului acestora în informatizarea instituțiilor î nvățământului superior
modern. Ideea principală în jurul căreia se construiește nevoia implementării unui sistem
informatic integrat în universități este performanța. Angajații trebuie să se poată concentra
asupra activităților care aduc valoare adăugată universității și mai puțin asupra celor repetitive
și care ocupă prea mult timp.
În universitățile românești există un număr relativ mare de sisteme informatice.
Aproape fiecare facultate/departament utilizează sisteme de operare diferite, baze de date
diferite având propriile aplicațiii, drept urmare nu oferă o imagine de ansamblu as upra
activităților desfășurate într -o universitate. Creșterea calității procesului de învățământ
constituie un obiectiv de bază pentru toate instituțiile de învățământ superior. În era actuală,
îmbunătățirea procesului didactic privind informatizarea într -o măsură cât mai mare prin
integrarea tuturor componentelor de înregistrare a informației și de comunicare internă, în
cadrul unui sistem informatic integrat, face dovada profesionalismului și credibilității instituției
de învățământ și alinierea acesteia la aria eur opeană de învățământ superior.
Lucrarea de disertație este structurată pe patru capitole, concluzii și bibliografie.
Primul capitol este un capitol de prezentare a conceptului de Enterprise Resource
Planning, care cuprinde cele mai cunoscute definiții ale sistemului, modul cum s -a realizat
dezvoltarea sistemului, precum și principalele avantaje de care poate beneficia o firmă care
decide să implementeze un sistem ERP.
Capitolul al doilea cuprinde prezentarea sistemul ui Microsoft Dynamics NAV c u cele mai
importante caracteristici.
În capitolul al treilea sunt prezentate motivațiile care determină implementarea
sistemului integrat Microsoft Dynamics NAV în universitățile din România, identificarea
riscurilor și a beneficiilor implementării noulu i sistem precum și a echipelor de lucru și a
instrumentelor folosite în procesul de derulare a întregii activități de implementare.
Capitolul al patrulea cuprinde modulele de bază existente în sistemul informatic integrat
dedicat învățământului superior , cu reliefarea rolului și modului de extindere a modulului de
Resurse umane.
Lucrarea se încheie cu concluzii și propuneri.
3
Absolvent: Stan Roxana Maria
Promoția: 2015 -2017
Programul de studii: Sisteme Informatice
Integrate pentru Afaceri
Conducător științific: prof. dr. univ. Lixăndroiu Dorin
Tema lucrării: Implemenatrea unui Sistem Informatic Integrat în Universitățile Românești
Rezumatul lucrării: În prezenta lucrare de disertație sunt evidențiate principalele
caracteristici și beneficii ale sistemelor informatice de tip ERP, precum și motivațiile care
determină implementarea sistemului integrat Microsoft Dynamics NAV în universitățile
din România . Ideea principală în jurul căreia se construiește nevoia implementării unui
sistem informatic integrat în universități este performanța. Angajații trebuie să se poată
concentra asupra activităților care aduc valoare adăugată universității și mai puțin asupra
celor repetitive și care ocupă prea mult timp .
Capitolul Nr. Nr. Nr. Nr. referințe
Nr. Denumire pagini figuri tabele bibliografice
1. Aspecte conceptuale și metodologice
cu privire la sistemele informatice de
tip ERP 12 1 5 20
2. Microsoft Dynamics NAV 3 3 – 1
3. Implementarea unui sistem informatic
integrat în universitățile Românești 21 15 7 2
4. Arhitectura de bază a sistemului ERP 9 9 1 –
5. Concluzii și propuneri 2 1 – 1
Sinteza Nr. pagini Nr. figuri Nr. tabele Nr. referințe Anexe
Lucrării de text bibliografice [nr. pag.]
disertație 60 29 13 24 6
4
Cap. 1. ASPECTE CONCEPTUALE ȘI METODOLOGICE CU PRIVIRE LA SISTEMELE
INFORMATICE DE TIP ERP
„Omul nu poate deveni om decât prin educație” afirmă filosoful german, Kant, astfel rolul
unităților de învățământ este unul evident și de importanță maximă în orice societate.
1.1. DEFINIREA SISTEMELOR DE PLANIFICARE A RESURSELOR ÎNTREPRINDERII
Sistemele de planificare a resurselor întreprinderii integrează toate activitățile companiei
într-o manieră transparentă și disponibilă utilizatorului final al sistemului.
Profesorul italian Corrado Cerruti afirmă că “Sistemele ERP sunt pachetele software care
suportă, prin intermediul unor module dedicate, diferitele procese operative și de gestiune ale
firmei, de la ciclul activ al comenzii până la programarea producției, de la administrarea
personalului la reporting -ul direcțional. Este vorba de programe software care au o arhitectură
unitară și permit o gestiune integrată a diferitelor procese din întreprindere (de la logistică la
ciclul comenzii) cu ajutorul a mai multor module aplicative cu interfață între ele, care se referă
la o bază de date unică comună. Configurația lor unitară impulsionează întreprinderea să
impună o schimbare operând modificări radicale la nivelul echilib relor interne și raporturilor cu
piața.”1
Doina Fotache și Luminița Hurbean sunt de parere că “ Enterprise Resource Planning
reprezintă sisteme bazate pe arhitectura client/server dezvoltate pentru prelucrarea
tranzacțiilor și facilitarea integrării tuturor proceselor, începând cu faza planificării și dezvoltării
producției, ajungând până la relațiile cu furnizorii, clienții și alți parteneri.”2
Conform dicționarului APICS planificarea resurselor întreprinderii reprezintă „… un cadru
pentru organizarea, definirea, și standardizarea proceselor de afaceri necesare pentru
planificarea și controlul eficient al organizației, astfel încât organizația să poată utiliza
cunoștințele sale interne în vederea obținerii unor avantaje externe.”3
Mohammad A. Rashid (Massey University , New Zealand), Liaquat Hossain (Syracuse
University, USA) și Jon David Patrick (University of Sydney, Australia ) consideră că sistemele ERP
1Cerruti C., Sistemi informativi e capacità competitiva. L'introduzione dei sistemi ERP nella grande impresa, Editura
G. Giappichelli, Torino, 1999, pag 30.
2Fotache D., Hurbean L., Soluții informatice integrate pentru gestiunea afacerilor – ERP, Editura Economică,
București, 2004.
3http://www.apics.org/dictionary/dictionary -information?ID=1414.0 (Consultat la data de 14.12.2016)
5
„…sunt sisteme software pentru managementul afacerii, care încorporează module ce sprijină
ariile funcționale ale afacerii, precum planificarea, producția, vânzări, marketing, distribuție,
contabilitate, financiar, management ul resurselor umane, managementul proiectului,
managementul inventarului, service și mentenanță, transport și afaceri electronice (e –
business).”4
T.Anderegg prezint ă sistemele ERP într-o definiție scurtă dar cuprinzătoare, ”…o soluție
software completă și atotcuprinzătoare pentru o întreprindere”.5
T.Davenport, arată în lucrarea sa ”Putting the Enterprise into the Enterprise System” că
sistemul ERP este ”…un pachet de aplicații care promite integrarea completă a tuturor fluxurilor
informaționale din cadrul unei organizații *…+”.6
Corelând toate definițiile prezentate anterior concluzion ăm că sistemele de tip ERP –
Enterprise Resource Planning, reprezintă sisteme bazate pe arhitectura client/server
responsabile de datele și cunoștințele interne organiza ționale, facilitând integrarea tuturor
informațiilor dintr -o structură într -o platformă unică.
1.2. AVANTAJE, DEZAVANTAJE ȘI RISCURI
Când vorbim despre ERP trebuie să știm că nu este vorba de un software care ne
răspunde tuturor cerințelor fără ca noi să facem nimic. Folosirea cu success a tuturor
avantajelor unui ERP presupune atât o implemntare corectă cât și o folosire corectă. (nu poți
genera rapoarte corecte, dacă în software s-au introdus date eronate).
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 resur se
(cei 4 M – Man, Money, Machines și Materials).7
1.2.1. Avantajele implementării sistemelor ERP
AVANTAJ MOD DE CONCRETIZARE
Informații de calitate Bază de date unică (date consistente și corecte), rapoarte
îmbunătățite
4Rashid M.A., Hossain L, Patrick J.D, The Evolution of ERP Systems: A historical perspective, Idea Group Publishing,
2002, pag. 2.
5T.Anderegg, ERP: A -Zimplementer `s guide for success, Resource Publishing, 2000, pag.5.
6 T.H. Devanport, ”Putting the Enterp rise into the Enterprise System”, Harvard Business Review, July-August, 1998,
pag. 121
7http://www.cio.com/research/erp/ (Consultat la data de 08.12.2016)
6
Evitarea redundanței
datelor și operațiunilor Bază de date unică, elimină operațiile repetitive de actualizare
(introducere și modificare)
Scăderea timpului de
răspuns Rapoarte și informații ad-hoc oferite de sistem
Adaptabilitate Schimbările în procesele economice se reconfigurează ușor în
sistemul ERP
Scalabilitate Structura modulară a sistemului facilitează adăugarea de noi
componente
Sistem de întreținere
îmbunătățit Contractul de întreținere pe termen lung cu furnizorul ERP nu
este facultativă, ci face parte din proiectul ERP
Dimensiune colaborativă Module precum CRM sau SCM extind și deschid sistemul către
furnizori și clienți
Deschidere către
e-business Arhitectura sistemelor ERP permite integrarea noilor tipuri de
aplicații e-business
Tabelul 1.1. Avantajele sistemelor ERP8
În tabelul 1.1. sunt explicate câteva dintre cele mai importante avantaje ale unui sistem
ERP, iar ca și concluzie generală putem spune că acesta permite accesul instantaneu la orice
informație gestionată în cadrul sistemului, oferă posibilitatea de a avea în orice moment
rapoarte corecte la fiecare arie a business -ului. Totodată permite utilizarea unei singure aplicații
pentru managementul întregii afaceri, eliminându -se astfel inconsistența ce poate apărea în
urma folosirii mai multor sisteme diferite pentru fiecare zonă a afacerii. Cu o singură soluție
integrată informațiile vor fi întotdeauna corecte, reducându -se timpul pierdut cu reorganizarea
cifrelor, care înainte erau extrase din sisteme diferite. Se elimină astfel și administrarea mai
multor baze de date. Utilizatorii au acces la informațiile înmagazinate într-o bază de date unică,
gestionată de un server.
1.2.2. Dezavantajele implementării sistemelor ERP
Deși pentru majoritatea companiilor ce aleg să implementeze un sistem ERP avantajele
depășesc de regulă dezavantajele, acestea există când ne referim la costurile ridicare ale
8Rashid M.A., Hossain L, Patrick J.D,The Evolution o f ERP Systems :A historical perspective, Idea Group Publishing,
2002, pag 5.
7
implementării sau lipsa unui suport tehnic continuu, ori se poate chiar ca unele sisteme ERP să
fie prea rigide pentru anumite companii care sunt fie foarte recente, fie plănuiesc să se dezvolte
într-o direcție diferită în viitorul apropiat. Principalele dezavantaje9 ale sistemelor ERP sunt
prezentate în tabelul 1.2.:
DEZAVANTAJ MOD DE COMBATERE/DIMINUARE
Proiecte consumatoare de
timp Implicarea activă a managementului, obținerea consensului și
acceptului general
Neconformitatea
modulelor Alegerea unui sistem ale cărui arhitectură și componente
corespund proceselor economice, culturii și obiectivelor strategice
ale organizației
Dependența de furnizor Analiza atentă a celor două alternative: furnizor unic sau mai mulți
furnizori
Complexitate Selectarea doar a modulelor care sunt absolut necesare
Necesitatea extinderii și
dezvoltării ulterioare a
sistemului Poate fi eliminată, dar va reduce potențialul sistemului, care va
deveni la un moment dat ineficient.
Tabelul 1.2. Dezavantajele sistemelor ERP
1.2.3 . Clasificarea riscurilor
Având în vedere costurile destul de mari pe care le implică achiziționarea unui ERP, era
firesc să ne întrebăm ce riscuri presupune investiția într -o asemenea soluție, astfel, Valentin
Măzăreanu10 a realizat o sinteză privind clasificarea riscurilor, după cum urmează :
Sursa de risc Clasificare Exemple
Factorul uman -Riscuri provenite din
comportamentul uman ;
-Riscuri provenite din trăsăturile
psihologice ale persoanei;
-Riscuri provenite din activități
individuale; -Incapacitatea de a termina o
sarcină la timp, slaba calitate a
personalului;
-Așteptări nerealiste, accent pe
detalii și pierderea din vedere a
obiectivel or;
9Rashid M.A., Hossain L, Patrick J.D,The Evolution of ERP Systems :A historical perspective, Idea Group Publishing,
2002, pag 6.
10Valentin Măzăreanu,V. -P., Economia și managementul riscurilor, Editura Tehnopress, Iași, 2010, Pag.71 -72
8
-Riscuri provenite din nivelul de
implicare și pregătire al utilizatorului. -Comunicarea neeficientă cu
utilizatorul, training insuficient al
utilizatorului final.
Organizația -Strategice: riscuri legate de strategia
firmei
-Operaționale: riscuri ce afectează
activitatea curentă a companiei;
-Financiare: riscuri care au legătură
directă cu fluxurile financiare ale
firmei;
-De hazard: evenimente imprevizibile
(naturale). -Riscuri care întrețin capitalul
intelectual al firmei, de schimbările
care au loc la nivelul
macroeconomic;
Frauda, resurse insuficiente, eșecuri
în repr oiectarea proceselor de
afaceri;
-Lipsa de lichidități, neachitarea
obligațiilor contractuale ale
partenerilor;
-Catastrofe naturale, incendiile
Stilul de
conducere -Riscuri provenite din inconsistențe în
politica de conducere;
-Riscuri provenite din acțivitățile și
controalele managementului;
-Riscuri la nivel de aptitudini ale
conducerii organizației -Lipsa sprijinului conducerii
executive;
-Schimbări în cerințe, leadership
slab;
-Eșec în atragerea de personal
calificat, cunoștințe insuficiente
Med iul extern
organizației -Riscuri provenite din circumstanțe
economice, sociale, politice și de
mediu -Condiții de piață în schimbare,
acțiuni dăunătoare ale competenței,
aplicații software depășite.
Resursele
tehnologice și
informaționale
ale organizației -Riscuri provenite din probleme
tehnice și tehnologice;
-Riscuri provenite din modul de
proiectare și implementare a
aplicației software;
-Riscuri provenite din modul de
administrare a informației. -Documentare inadecvată, aplicații
implentate fără a înde plini cerințele
inițiale;
-Instabilitatea tehnologiei curente,
imposibilitatea de conectare cu
ststemul mostenit;
-Neînțelegerea cerințelor de
schimbare, neintegrarea sistemelor
9
din organizație.
Relația cu terțe
părți -Riscuri provenite din relațiile legale și
contractuale;
-Riscuri care provin din afectarea
populației. -Performanța inadecvată a terților
părți, protecție inadecvată a
proprietății intelectuale, tensiuni
între clienți și contractori;
-Încălcări sau neconformitate cu
legislația.
Tabelul 1.3. Clasificarea riscurilor
În concluzie, lipsa implicării top managementului în implementare duce la neînțelegerea
dimensiunii proiectului, la neconștientizarea eforturilor umane depuse și a estimării incorecte a
necesarului de resurse. Din dorința de a reduce costurile implementării se ajunge la
suprasolicitarea echipei de implementare, deseori persoanele desemnate ca fiind responsabile
de proiect nu au experiența necesară unei implementari și nu sunt factori de decizie în cadrul
organizației. Definirea deficitară a cerințelor, este de asemenea un factor de risc extrem de
important care afectează procesul de implementare, deoarece în baza cerințelor definite se
selectează sistemul ERP. Daca p rocesul de implementare ERP nu este detaliat într -un plan de
proiect, cu faze de acceptanță și responsabili, cu etape clar definite, cu resurse alocate pe
fiecare faza a proiectului, nu se va putea urmări desfășurarea implementării, timpii rămași până
la finalizare etc. Subestimarea de către ambele părți a necesarului de training, lipsa de atenție
în cadrul sesiunilor de training, sacrificarea acestora în favoarea rezolvării problemelor
operaționale curente, conduc în momentul lansării în producție a sistem ului, la o blocare totală
sau parțială a activității organizației.
Extrem de interesant este și punctul de vedere al furnizorilor de soluții ERP11, o mare
parte din ei considerând că riscurile vin din partea clientului și nu din partea companiilor care se
ocupă de implementare. Aceștia sunt de parere ca principalul risc ține de necunoașterea
domeniului și de neglijarea anumitor criterii de alegere a soluției ERP. 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.
11Furnizori de soluții ERP: SAP, Microsoft, Oracle, Sage, Infor, Kronos, Totvs, Concur etc.
10
1.3. IMPLEMENTAREA SISTEMELOR ERP
Obiectivul principal urmărit prin implementarea unui sistem informatic îl constituie
asigurarea utilizatorilor cu informații reale și în timp util, necesare fundamentării și elaborării
operative a deciziilor.
Prin implementarea unor astfel de sisteme se oferă firmei posibilitatea de a integra în
cadrul noului siste m informatic aplicațiile existente, alături de noile aplicații specifice
domeniului în care își desfășoară activitatea firma respectivă.
Succesul unei implementări este o reușită atât pentru client cât și pentru furnizorul
sistemului informatic, deoarece p rimul va beneficia de avantajele promise la prezentarea
soluției, iar implementatorul se va mândri la următoarele sesiuni de licitații cu rezultatul obținut
și evident, va beneficia de cunoștințele acumulate aspect ce va face ca o eventuala
implementare în tr-o firmă cu profil asemănător să fie mult mai facilă.
De regulă, motivațiile care stau la baza implementării unui sistem ERP12sunt:
Motivații tehnologice Motivații operaționale
Înlocuirea unui sistem informațional
neintegrat (mai multe aplicații, depășite
tehnologic sau nu, î n care se operează
independent);
Înlocuirea unuia sau mai multor sisteme
depăși te tehnologic, integrate sau nu;
Îmbunătățirea calității ș i accesibilității
informațiilor;
Integrarea proceselor de business și a
sistemelor care le susțin;
Achiziția unui sistem capabil să susțină
creșterile prognozate de business;
Simplificarea procesului de integrare a noi
business -uri (achiziția unor alte companii) în
infrastructura tehnologică curentă. Optimizarea procesel or de business ;
Reducerea costurilor structurale;
Îmbunătățirea timpilor de ră spuns la
cererile clienților ;
Simplificarea proceselor de business
complexe, dar ineficiente ;
Implementarea a noi strategii de business ;
Expansiunea masivă a businessului ;
Standa rdizarea proceselor de afaceri la
nivelul companiei.
Tabelul 1.4. Motivațiile care stau la baza implementării unui sistem ERP
12 http://www.seniorerp.ro/resurse_utile/erp -implementarea -erp-riscurile -implementarii -erp-analiza -tipurilor -de-
organizatii -motivatia -implementarii -erp/
11
Implementarea unui sistem informatic integrat de tip ERP este un proces complex și are
influențe directe în rezultatele economice ale firmei. Firma beneficiară va suporta costuri
semnificative legate de procesul de sc himbare a sistemului informatic , atât în timpul pregătirii
implementării, a implementării propriu -zise cât și post -implementare. În timpul implementării,
cele două sisteme vor lucra în paralel, astfel încât încărcarea oamenilor va fi dublă, dar stresul
suportat va fi triplu, datorită faptului că vor lucra într -un sistem nou, pe care atunci îl învață, dar
de la care se așteaptă deja performanță.
1.3.1 . Principalii participanți în dezvoltarea unui sistem informatic
Implem entarea este un proiect comun, î n care sunt implicați atât re prezentanții firmei
furnizoare cât și reprezentanții beneficiarului. Înțelegerea corectă a rolului pe care îl au cele
două echipe cât și dorința de implicare pentru a obține rezultatele scontate, reprezintă cei mai
importanți factori în realizarea unei imp lemetări de succes.
În dezvoltarea sistemelor informatice, fac parte trei tipuri de participanți:
utilizatorul – reprezintă un grup de persoane, care folosesc sistemul pentru a îndeplini
cerințele informaționale;
dezvoltatorul sau furnizorul software -ului aplicativ – este creatorul software -ului aplicativ
ce formează suportul sistemului informatic;
administratorul sistemului – desemnează persoanele sau structurile care asigură condițiile
de funcționare curentă a sistemului și gestionează măsurile de protecție și securitate a acestuia.
În practică, la o implementare vor participa două echipe:
Echipa furnizorului – coordonată de managerul de proiect. Principala îndatorire a acestuia
este să coordoneze întreaga echipă (implementatori, personalul de suport tehnic, care se
ocupă cu preluări de baze de date, teste ri, programatori etc.) astfel încâ t să aibă disponibile
resursele de care are nevoi e iar sarcinile echipei să decurgă conform planificării și să nu sufere
întârzieri;
Echipa beneficiarului – coordonată de responsabilul de implementare. Din echipa
beneficiarului fac parte specialiștii pe domenii, precum și utilizatorii impl icați direct în operarea
software -ului. Responsabilul de implementare, ca manager de proiect, trebuie să aibă putere
de decizie, are responsabilități privind alocarea resurselor, disponibilitatea acestora și
realocarea lor, dacă este necesară.
12
Pentru a se atinge obiectivul scontat, o implementare de succes, trebuie să se țină cont că
cel mai important element este comunicarea. Orice problemă care poate afecta bunul mers al
implementării, indiferent dacă are ca sursă beneficiarul sau furnizorul, trebuie să fie
comunicată și discutată de către managerii de proiect, pentru a se stabili metodele de depășire
a problemei respective . În fig. 1.1. este prezentată baza unui proiect de implementare:
Comunicare
Fig 1.1. Principalii participanți în dezvoltarea unui sistem informatic
Succesul unei implementări, indiferent de tendințele care diferă de la un an la altul,
depinde tot mai mult de calitatea echipelor de implementare (echipa furnizorului și echipa
clientului) și mai puțin de peformanța tehnologică a soluțiilor. Managementul de proiect și
comunicarea eficientă fac de cele mai multe ori diferența în ce privește succesul sau eșecul unei
implementării.
1.3.2 . Costul unui sistem ERP
Adoptarea unui sistem ERP implică cheltuieli uriașe pentru organizații, indiferent de
dimensiunea acest ora: de la zeci de mii de Euro, în cazul întreprinderilor mijlocii , până la
milioane de Euro, în situația marilor companii.
Costul de achiziție este cel mai evident cost. Platforma hardware susține soluția ERP și
reprezintă punctul de plecare în deosebirea costurilor diferitelor sisteme ERP. Există sisteme
ERP care pot rula o bună perioadă de timp pe aceeași platformă și produse software care
solicită actualizarea platformei hardware la apariția oricărei noi versiuni a sistemului.
Costul de suport reprezintă costul pentru suportul sistemului pe durata unui an și în
general, echivalează cu 20-25% din costul inițial de achiziție. Costul de implementare a soluției
include cheltuieli cu instalarea produsului, cu trainingul angajaților, cu preluarea datelor din
PROIECT
IMPLEMENTARE
FURNIZOR
– manager de proiect
– analiști
– personal suport tehnic
– programatori
-consultanți
– teste ri
– traineri
BENEFICIAR
– manager de proiect
– șefi de departamente
– specialiș ti
– operatori
13
vechiul sistem, etc. Costurile de personalizare apar atunci când organizația are nevoie de
customizarea soluției ERP la nevoile sale specifice. Aces te costuri pot fi uriașe, însă organizațiile
pot minimiza aceste costuri: fie se va alege de la bun început o soluție ERP care se pliază cel mai
bine pe nevoile firmei, fie întreprinderea va reproiecta unele dintre procesele sale de afaceri
pentru a se adapta soluției ERP.
Costurile de mentenanță reprezintă o componentă foarte importantă în procesul de
stabilire a cheltuielilor pe care le implică pe termen lung soluția ERP adoptată.
Costul de integrare este dat de nevoia de integrare a soluției ERP proaspăt adoptate cu
toate celelalte sisteme și aplicații existente în organizație și variază în funcție de activitatea
organizației și de dimensiunea sa.
Atunci când o organizație este interesată de adoptarea unei soluții ERP și începe să compare
ofertele mai multor furnizori, nu trebuie să scape din vedere următoarele elemente de cost13:
Echipamentele, evaluarea parcului existent și estimarea necesarului (sunt foarte
importanete performanțele serverului/ serverel or ca și volum de date care este vehiculat în
condiții de maximă necesitate);
Sistemul de operare, evaluarea necesităților de upgrade;
Licențe module ERP, inventarierea numărului de utilizatori de sistem;
Licențe pentru aplicațiile conexe (cele mai importante sunt cele cu baza de date);
Integrarea ERP cu terțele aplicații;
Personalizarea aplicațiilor (costuri de dezvoltare);
Conversia datelor din sistemul existent;
Instruirea managerului și a personalului, pregătirea administratorilor de aplicații;
Pregătirea managerului de proiect;
Consultanță externă, asistență din partea furnizorilor de platforme.
Costurile unui sistem ERP variază în funcție de:
Mărimea intreprinderii;
Numărul de utilizatori ai sistemului;
Numărul de module implementate;
Componentele adăugate și schimbările realizate la cererea beneficiarului
13S. Harwood, ERP: The implementation cycle, Butterworh -Heinemann, Oxford, 2003, pag.54
14
Din categoria costurilor indirecte fac parte de regulă costurile interne, generate de
”perturbarea” activității obișnuite de către proiectul ERP. Între acestea se pot regăsi14:
Costul muncii prestate de angajații care preiau temporar sarcinile celor implicați în
proiect;
Costurile induse de nedesfășurarea unor activități sau costurile suplimentare propuse de
desfășurarea lor în alte condiții;
Costurile prin deplasări legate de proiect (vizite la furnizor/ clienți, instruire);
Costuri suplimentare presupuse de extinderea activității departamentului de IT.
Stuctura costurilor totale ale unui proiect ERP15:
Categorie de cost Costuri inițiale Costuri continue (pe an)
Directe Echipamente 5-10%
Licențe software:
-module ERP
-sistemul de gestiune a bazei de date
-terțe aplicații 25-30%
Integrator Implementare (analiză, configurare,
testare, lansare, întreținere) 20-25% 15-25%
Costuri de dezvoltare,
Customizare aplicații,
Dezvoltare de interfețe 5-10%
Instruire 5%
Indirecte Personalul intern:
-management de proiect
-angajați permanent
-angajați cu jumătate de normă
-contracte temporare de prestări
servicii 10% 5%
Tabelul 1.5. Stuctura costurilor totale ale unui proiect ERP
14Fotache D., Hurbean L., Platforme integrate pentru afaceri – ERP, Editura Economică, București, 2013, pag.109 .
15S. Harwood, ERP: The implementation cycle, Butterworh -Heinemann, Oxford, 2003, pag.56
15
1.3.3 . Eșuarea implementă rilor
Există exemple de implementări eșuate din cauza: alegerii unor sisteme ERP nepotrivite,
lipsei de coordonare și comunicare în cadrul companiei în momentul implementării,
performanței echipei de proiect, ignorării îndelungate a unor neajunsuri ale aplicației în ceea ce
privește anumite nevoi ale companiei, sau a angajaților care nu sunt instruiți corespunzător.
Principalele motive ale eșecului implementării unei soluții ERP sunt:16
Schimbarea obiectivelor implementării ERP – În general necesitățile de business ale
clientului sunt înțelese abia după începerea implementării de aceea cerințele sunt schimbate în
timpul implementării soluției.
Resurse inadecvate – lipsa de experiență a personalului și a project managerului
desem nat.
Planificare și documentare slabă .
Neadaptarea softului la procesele de business – o selecție greșită a soluției poate duce la
pierderi pentru companie și într -un final la schimbarea soluției de ERP aleasă inițial, astfel
costurile companiei cresc pe ntru că problemele nu au fost corect expuse în momentul selecției
sistemului informatic integrat.
Tăierea costurilor – în condițiile în care clientul nu are un plan eficient de acoperire a
proiectului, acest lucru va duce inevitabil la eșecul implementării sistemului ERP.
Deosebit de important este faptul că eșuarea unei implementări nu înseamnă numai
pierderea investiției material e în soluția ERP, e fectele negative se resimt și în deteriorarea
relației cu clienții, cu angajații sau în pierderea cotei de pi ață și de imagine.
De aceea se recomandă alegerea unui partener cu experiență, capabil să prevadă și să combată
aceste riscuri.
În concluzie primul pas pentru o implementare de succes este alegerea unei soluții
performante, apropiată de specificul de activ itate al clientului astfel încât nivelul de configurare
să fie minim, o soluție care să fie confirmată de referințe pe piață. Problemele legate de
implementare pot fi evitate printr -o comunicare adecvată între cele două echipe de proiect.
Chiar dacă exist ă numeroase istori i de implementări eșuate pe piaț a globală de ERP, la
nivelul Romaniei furnizorii de soluții ERP17 consideră, în unanimitate, că aceste cazuri sunt rare.
Aceștia sunt de părere ca o implemen tare eșuată în adevă ratul sens al cuvântului are l oc doar
16http://www.consultantaerp.ro/Articole_ERP/Probleme_in_implementare.html
17Furnizori de soluții ERP: SAP, Microsoft, Oracle, Sage, Infor, Kronos, Totvs, Concur etc.
16
atunci când soluția este complet nepotrivită business -ului. Dar acest lucru se întâmplă extrem
de rar pentru că orice vânzător, nu va vinde o soluție dacă știe că ea este incompa tibilă și nu o
poate implementa.
1.4. TENDINȚE ERP
Sistemele ERP au fost într-o dezvoltare neîncetată, dar odată cu explozia tehnologiei
informației din ultima vreme viteza cu care apar noi trenduri în piață crește de la un an la altul.
Cei mai mari furnizori ERP sunt de părere că tendințele de care se vor bucura sistemele ERP, în
următorii ani sunt:
ERP-ul devine mobil – accesarea unui ERP de pe un dispozitiv mobil (tabletă,
smartphone), este o necesitate, nicidecum un moft, în special pentru utilizatorii care se
deplasează și au nevoie de o modalitate de acces simplă și in timp real la toate datele din cadrul
companiei. Așadar, un sistem ERP care nu va dispune de o asemenea dotare, va avea un serios
handicap.
ERP în cadrul fimelor mici și medii – până nu demult, ERP-urile erau întâlnite doar în
marile companii. Costurile, dar și complexitatea acestor sisteme au ținut departe gândul micilor
întreprinzători de a opta pentru un astfel de produs software. Însă dezvoltatorii de soluții ERP s-
au gândit să ”adopte” și firmele medii și mici prezentând oferte accesibile ca preț. Sistemele
ERP tradiționale acopereau mai mult zona fabricației, stocurilor și distribuției, dar acum ele vin
și cu module dedicate resurselor umane, contabilității, managementului de proiect, etc.
Tehnologia Cloud – de tehnologia Cloud vor beneficia întreprinerile mici și mijlocii
îndeosebi, companiile mari sunt încă reticente. Și nu neapărat datorită unor consi derente de
securitate ci fiindcă, din punct de vedere financiar nu este rentabil să se treacă pe Cloud.
Sistemele ERP vor avea BI încorporat – sistemele informatice integrate asigură coerența
și validitatea datelor, însă lasă de dorit atunci când e vorba de potențialitatea de a extrage
datele din sistem sub forma unor analize care să ajute la luarea deciziilor. Simpla prezență a
câtorva rapoarte în sistem nu mai satisface utilizatorii, aceștia așteaptă de la un ERP să aibă
câteva din funcționalităție oferite de o soluție Business Intelligence (BI).
Integrarea sistemelor ERP cu celelalte sisteme – integrarea cu CRM, schimbul de
documente electronice, integrarea cu platforma Web, toate sunt necesare într-o lume în care
informația este dispersată și e greu să obții o imagine globală asupra afacerii.
17
CAP.2 . MICROSOFT DYNAMICS NAV
Navision a fost achiziționat în anul 2002 de Microsoft, a trecut prin etape succesive de
integrare în portofoliul de soluții Microsoft. De la Navision – The way to grow la Microsoft
Business Solutions Navision și apoi la actualul nume Microsoft Dynamics NAV, acest proces a
însemnat și o aliniere strategică a produsului.
2.1. PREZENTARE GENERALĂ
Microsoft Dynamics NAV este o soluție de tip Enterprise Resource Planning dedicată
companiilor mijlocii, filialelor companiilor multinaționale, cu o poziție importantă pe piață și
care doresc să-și crească avantajul competitiv.
Peste 48.000 de companii se bazează zilnic pe Microsoft Dynamics NAV în derularea
operaț iilor, reușind astfel să-și consolideze afacerile în siguranță utilizând o soluție fiabilă și
adaptabilă nevoilor de business. Utilizarea software -ului poate înlocui exact atât cât ai nevoie
din sistemul tău existent.
Arhitectura deschisă a Microsoft Dynamics NAV, permite partenerilor certificaț i Microsoft
să transforme platforma tehnologică standard într-o soluție adaptată oricărui mod de a face
afaceri. Furnizor de software global din sectorul de piață mijlociu oferă partenerilor locali
libertatea deplină necesară pentru a-și satisface nevoile specifice, având acces la tot codul sursă
pentru logica de business.
Oferă o prezentare generală asupra oricărei afaceri, la toate nivelurile. Informațiile de
business și cele financiare sunt întotdeauna actualizate și integrate complet cu informațiile din
orice alta zonă a aplicației. De fiecare dată când este postată o tranzacție oriunde în sistem
toate informațiile despre clienți, furnizori, conturi și totalurile articolelor vor fi actualizate. Dacă
se produce o greșe ală sau dacă se dorește modificarea informațiilor postate pe parcursul
procesului, se poate derula înapoi postarea, fără a afecta restul conturilor .
Pe baza unor informații exacte furnizate în timp real despre toate contactele, se pot lua
decizii avizate, spre exemplu se va știi care sunt conturile de care trebuie să ne ocupăm urgent
și care sunt conturile care pot fi amânate. De asemenea, pot fi îmbunătățite campaniile de
vânzări și marketing prin planificare eficientă printr -o orientare bazată pe criterii specifice, cum
ar fi vânzările, profilurile contactelor și interacțiunile precedente.
18
Contactele se pot categorisi pe baza întrebărilor de alcătui re a profilului unui client,
realizându -se personalizarea modului de abordare a acestora. De exemplu, un profil personal
poate oferi informații despre frecvența cu care un client dorește să fie facturat și dacă are
persoane și ore de service preferate. Astfel se realizează o mai mare satisfacere a clienților
creând liste de acțiuni în sistem și alocând sarcini altor utilizatori sau echipe de utilizatori.
Cu ajutorul proceselor de prelevare și rezervare se poate îmbunătăți organizarea
depozitelor și scădere a costurilor de manoperă . Notele de rezervare și cele de prelevare pot fi
adăugate la metodele de lucru ale companiei. Numerele de serie și urmărirea loturilor ajută
urmărirea articolelor în orice moment pe parcursul proceselor de vânzări, achiziții sau transfer.
De asemenea se poate urmări stocul de retur pentru a gestiona costurile suplimentare, cum ar
fi comisioanele de reintroducere în stoc.
2.1.1 . Caracteristicile soluției Microsoft Dynamics NAV
Dintre cele mai importante caracteristici18 ale Microsoft Dynamics NAV amintim:
Arhitectură modulară integrată : între diferitele module ale sistemului există o
compatibilitate totală și o comunicare corespunzătoare, astfel încât datele de bază sunt
introduse o singură dată.
Nivele multiple de secu ritate : drepturile de acces legate de documente, rapoarte, bază
de date, etc. pot fi individualizate pe utilizatori sau grupuri de utilizatori ai sistemului, în funcție
de rolurile pe care aceștia le îndeplinesc în cadrul organizației.
Mecanisme performant e de validare a documentelor , garantându -se astfel integritatea
datelor și coerența procesului modelat.
Ușurință în utilizare, accesibilitate : modul de operare este ușor de asimilat, indiferent de
nivelul de pregătire al utilizatorilor sau de poziția lor din cadrul organizației.
În afara rapoartelor standard aferente, există posibilitatea de a defini și genera rapoarte
la cerere în funcție de rolul și drepturile diferiților utilizatori.
Evoluția comparativă a datelor : pe baza datelor din sistem, utilizat orul poate urmări
evoluția diverselor activități desfășurate pe perioade de timp.
Sistemul este capabil să ofere informații în timp real .
Drepturile de acces sunt administrate într -o manieră centralizată de către
administratorul sistemului.
18http://www.qnet.ro/caracteristici -solutie -microsoft -dynamics -nav(Consultat la data de 01.15.2017 )
19
Exploatare facilă a sistemului;
Accesibilitatea sistemului : accesul la oricare dintre funcționalitățile sistemului este
posibil de la orice post de lucru, fiind condiționat doar de drepturile de acces acordate.
Interfața de utilizare (‘help -uri’ integrate și/sau on -line) cât și mesajele, ecranele și
meniurile sunt traduse și în limba română.
Sistemul se bazează pe o tehnologie modernă, stabilă și performantă .
2.2. MICROSOFT DYNAMICS NAV – PREZENTARE ARHITECTURÃ
1. Mediul de dezvoltare C/SIDE
Fig.2.1. Mediul de dezvoltare C/SIDE
Mediul grafic de dezvoltare pentru Microsoft Navison este numit C/SIDE (Client Server
Integrated Development Environment).
Fig.2.2 . Client Server Integrated Development Environment Mediul de dezvoltare C/SIDE Object Designer Tabele
Pagini
Rapoarte
Codeunit
Query
XMLport
MenuSuite
20
Principalele beneficii ale C/SIDE sunt:
aria tuturor aplicațiilor pentru Microsoft Navison este dezvoltată în C/SIDE;
conține uneltele pentru construirea și parametrizarea aplicațiilor;
conține toate fișierele executabile din cadrul directoarelor programului de pe hard
disk;
conține codul necesar interpretăr ii obiectelor aplicației și dezvoltării instrumentelor
de sistem (editoare, depanatoare etc.);
Object Designer
În cadrul Object Designer se pot rula aplicații obiect sau se poate porni designer -ul unei
aplicații obiect. Folosirea designer -ului pentru aplicații obiect se face atunci când se dorește
modificarea unui obiect existent sau crearea unui obiect nou. O aplicație dezv oltată în C/SIDE
se bazează pe ș apte tipuri diferite de obiecte: tabele, pagini, rapoarte, codeu nit-uri, query – uri,
XMLport -uri ș i MenuSuite.
Tabelele – sunt utilizate pentru stocarea datelor. O tabelă se caracterizează prin
proprietăți, câmpuri ,chei, cod C/AL și triggeri. Proprietățile controlează modurile de afișare și
comportare ale unui obiect, fiind utilizate pentru a specifica cum vor fi afișate datele, care sunt
valorile predefinite ale câmpurilor, ce culori vor fi utilizate, ce relații există între tabele. Câmpul
reprezintă cea mai mică unitate de informație dintr -o bază de date. O cheie de finește ordinea
în care datele vor fi stocate în tabele. Se poate mări viteza de căutare în tabele prin definirea
mai multor chei pentru a sorta datele în diferite moduri, însă existența unui număr prea mare
de chei poate duce la scăderea performanței .
Paginile – sunt folosite pentru a accesa datele din tabele, fiind utilizate atât pentru
introducerea datelor cât și p entru vizualizarea lor. O pagină se caracterizează prin proprietăți,
cod C/AL, triggeri și controale. Cont roalele sunt obiecte pe o pagină sau raport prin care se
afișează date sau se declanșează evenimente. Cele mai in tuitive exemple sunt butoanele ș i
textele.
Rapoarte le – sunt utilizate pentru prezentarea datelor. Un raport se caracterizează prin
proprietăți, cod C/AL, controale, dataitem -uri, secțiuni, template -uri și formular de introducere.
Formularul de introducere este un form ular utilizat într -un raport , î nainte de rularea unui
raport utilizatorul poate introdu ce în acest formular filtrări ale datelor sau poate selecta
anumite opțiuni. Un template definește modul de afișare a datelor într -un raport. Un dataitem
este folosit pentru a defini structura unui raport. Un dataitem reprezintă o tabelă. La rularea
21
unui r aport sistemul parcurge toate înregistrările din tabela asociată. Un dataitem poate avea
una sau mai multe secțiuni. O secțiune este o diviziune a unui dataitem în care se inserează
controalele utilizate pentru afișarea datelor.
Codeunit -urile – conțin f uncții definite de utilizator scrise în limbajul C/AL. Aceste funcții
pot fi apelate din alte obiecte ale aplicației. Un codeunit se caracterizează prin cod C/AL.
XMLport – Obiectul de tip port XML este conceptual legat de informații (dataport). De
asemen ea, se folosesc porturi XML pentru a importa și exporta date în format XML. Aceste
obiecte fac ca procesul de schimb al datelor XML dintre sisteme să fie mai simplu și mai rapid.
MenuSuite – Obiectul de tip MenuSuite conține meniurile care sunt a fișate în ferestrele
aplicației Navison. Fiecare meniu este personalizat în funcție de departament.
2. Windows Client
Windows Client este aplicația client de bază, pe care utilizatorii finali o vor utiliza în
tranzacționarea operațiunillor zilnice. Orice modificări realizate în mediul de dezvoltare se vor
reflecta în aplicația client.
Fig.2.3. Windows Client
De asemenea, clientul este responsabil pentru execuția întregii logici a aplicației.
Clientul citește obiecte din baza de date și este responsabil pentru execuția acestora și
controlarea comportamentului lor. Cele mai multe aplicații Navison rulează pe clienți
individuali.
2.3. SECURITATEA ÎN NAVISION
Sistemul de securitate din Navison permite controlul asupra obiectelor pe care fiecare
utilizator le poate accesa în oricare dintre bazele de date. Se poate specifica tipul de acces pe
care utilizatorii îl pot avea asupra fiecărei tabele (citire, modificare, adăugare, ștergere),
22
permisiunea poate fi alocată atât la nivel de tabelă, cât și l a nivel de înregistrare în opțiunea
SQL Server.
Sistemul de securitate Navison poate fi structurat pe patru niveluri de securitate19 :
securitate la nivel de bază de date;
securitate la nivel de companii;
securitate la nivel de obiect;
securitate la nivel d e înregistrare.
1. Securitatea la nivel de bază de date – este primu l nivel de securitate care intră în
funcțiune când se deschide baza de date Navison, moment în care sunt verificate drepturil e de
acces. Navision deține două tipuri de autentificare:
autentificare Windows – se adresează grupurilor de utilizatori din domeniul Windows. În
momentul în care un utilizator încearcă să se conecteze la server și să deschidă o bază de date,
Navison în mod automat interoghează Windows -ul, pentru a i se confirma dacă este sau nu un
utilizator valid. Dacă utilizatorul are acces la server, Navision verifică dacă utilizatorului i s -a
atribuit o autentificare Windows pentru Navision. Dacă utilizatorul are drept de autentificare
Windows, i se va asigura accesul la baza de date.
autentificare la nivel de bază de date – vizează utilizatorii care au acces la baza de date,
în cazul în care posedă un ID și o parolă. Permisiunea pe care o are utilizatorul asupra diferitelor
obiecte din baza de date, este determinată de informațiile conținute în contul pentru acces la
bază de date.
2. Securitate la nivel de companie – o bază de date Navision poate conține una sau mai
multe companii, acestea pot utiliza propriile lor tabele sau pot partaja aceleași tabele.
3. Securitate la nivel de obiect – odată accesată o companie, posibilitatea de a lucra cu
obiectele sale este dată de sistemul de securitate Navision, care conține roluri și permisiuni
atribuite fiecărui utilizator cu drept de acces la companie și care det ermină operațiile ce pot fi
efectuate asupra obiectelor existente în baza de date.
4. Securitatea la nivel de înregistrare – permite limitarea accesului unui utilizator la
datele dintr -o tabelă, specificând faptul că utilizatorul are permisiune de acces do ar pentru
anumite înregistrări din tabelă. Acest tip de securitate este implementată aplicând filtre de
securitate tabelelor și datelor din tabela la care utilizatorii au acces.
19Alex Chow, Getting Started with Dynamics NAV 2013 ApplicationDevelopment ,Publ ished by Packt Publishing Ltd.,
Pag. 123
23
Cap.3 IMPLEMENTAREA UNUI SISTEM INFOR MATIC IN TEGRAT ÎN
UNIVERSITĂȚILE ROMÂNEȘTI
Având în vedere cerințele învățământului superior modern și evoluția către societatea
cunoașterii, creșterea performanțelor tehnice și de exploatare ale calculatoarelor, consider că
implem entarea unui sistem informatic integr at adaptat specific ului activităț ii Managementu lui
Universitar, devine din ce în ce mai necesară în era informaț iei. Tendințele internaționale relevă
deschiderea universităților spre alternativa oferită de noile tehnologii.
Nevoia de schimbare se face tot mai mult simțită, mai ales, în condițiile în care
universitățile tind către, crearea spațiului universitar european , compatibilizarea sistemelor de
învățământ din Europa, etc.
Instituțiile de învățământ superior care vor poseda tehnologia necesară vor putea să
acopere cât mai mult din fluxurile de informație și să valorifice cât mai eficient resursele
disponibile. Utilizarea unui produs informatic performant va permite accesul la informații în
momentele oportune, îndeplinirea obiectivelor strategice, prin gesti onarea optimă a resurselor
umane, financiare și tehnice.
Fig.3.1 . Harta instituțiilor de învățământ superior din Romania20
20http://www.edu.ro/lista -universitatilor -din-romania (Consultat la data de 03.02.2017)
24
3.1. MOTIVAȚII CARE DETERMINĂ IMPLEMNETAREA SISTEMULUI INTEG RAT NAVISION
ÎN UNIVERSITĂȚILE DIN ROMÂNIA
Creșterea calității procesului de învățământ constituie un obiectiv de bază pentru toate
instituțiile de învățământ superior. Î n era actuală, îmb unătățirea procesului didactic privind
informatizarea într -o măsură cât mai mare prin integrarea tuturor componentelor de
înregistrare a informației și de comunicare internă, în cadrul unui sistem informatic integrat,
face dovada profesionalismului și credibilității instituției de învăț ământ și alinierea acesteia la
aria europeană de învățământ superior.
În universitățile românești există un număr relativ mare de sisteme informatice.
Aproape fiecare facultate/departament utilizează sisteme de operare diferite, baze de date
diferite având propriile aplicațiii, drept urmare nu oferă o imagine de ansamblu asupra
activităților desfășurate într -o universitate. Astfel, scăderea nivelului de satisfacție oferit de
sistemele informatice existente, utilizarea unor interfețe ne prietenoase, pre cum și dorința de a
moderniza procesele de afaceri utilizând tehnologii ce facilitează transferul electronic de date
între facultăți sunt aspecte care vor determina universitățile să migreze către sistemele
integrate.
Ideea principală în jurul căreia se co nstruiește nevoia implementării unui sistem
informatic integrat în universități este performanța. Angajații trebuie să se poată concentra
asupra activităților care aduc valoare adăugată universi tății și mai puțin asupra celor repetitive
și care ocupă prea mult timp. Automatizarea proceselor pentru eficientizarea angajaților
trebuie să fie unul dintre obiectivel e principale ale acestei schimbă ri.
Tendința universităților din Europa spre sistemele ERP reflectă faptul că la cârma
universităților europene stau manageri profesioniști, într -o piață globală a educației
universitare, iar managementul unei universități se identifică cu managementul unei mari
afaceri. Această tendință are ca principal obiectiv transformarea calitativă a instituțiilor
universitare româ nești și dezvoltarea unui mediu academic integrat și competitiv cu
standardele europene.
În concluzie implementarea unei soluții informatice dedicate managementului
universitar este astăzi o opțiune esențială pentru marea majoritate a universităților care au
înțeles noile ten dințe și necesități care sunt răspâ ndite la nivel european.
25
3.1.1 . Analiza SWOT a implementării sistemului ERP – NAV
Pentru a avea o viziune de ansamblu, cât mai clară, este important să se colecteze și să se
compare datele din toate d epartamentele unei universități. Astfel se pot identifica punctele tari
pentru a putea învăța din ele, punctele slabe care au nevoie de un efort sporit pentru a fi
depășite/ înțelese, oportunitățile pentru a ști cum putem să ne dezvoltăm și amenințări pent ru
a știi de ce trebuie sa ne ferim.
Analiza SWOT realizată a evidențiat principalele motivații care determină implementarea
unui sistem integrat în universitățile din România:
Puncte TARI
(Strenghts) Puncte SLABE
(Weaknesses)
Comunicarea internă îmbunătățită
Informații de calitate
Rapoarte și informații ad -hoc oferite de
sistem
Reduce sau elimină procesele manuale
Consolidează rapoartele pentru o
perspectivă mai clară
Generează automat situații lunare și alte
raportări obligatorii
Pregătit oricând să integreze noi canale
Optimizează fluxurile de lucru
Facilitează schimbul de informaț ii între
departamente/ facultăț i
Rapoarte îmbunătățite Dependența de furnizor
Cost ridicat
OPORTUNUTĂȚI
(Opportunities) AMENINȚĂRI
(Threats)
Platformă flexibilă
Adăugare de noi module
Noi strategii de îmbunătățire
Probleme de integrare cu aplicațiile
existente
Cultura academică
Securitatea datelor
Costuri ridicate cu mentenanța
Tabelul 3.1 . Analiza SWOT
Ca și concluzie generală putem spune că sistemul ERP permite accesul instantaneu la
orice informație gestionată în cadrul sistemului, oferă posibilitatea de a avea în orice moment
rapoarte corecte și totodată permite utilizarea unei singure aplicații pentru manag ementul
întregii universităț i, eliminându -se astfel inconsistența ce poate apărea în urma folosirii mai
multor sisteme diferite pentru fiecare depart ament/facultate. Cu o singură soluție integrată
26
informațiile vor fi întotdeauna corecte, reducându -se timpul pierdut cu reorganizarea cifrelor,
care înainte erau extrase din sistem e diferite, dar și administrarea mai multor baze de date.
Se poate observa că deși punctele tari le depășesc pe cele slabe, acestea există când ne
referim la costurile ridicare ale implementării sau lipsa unui suport tehnic continuu, ori se poate
chiar ca unele sisteme ERP să fie prea rigide pentru anumite universități.
Trebuie să fie clar evidențiată ideea, încă de la început, cum că nu vorbim despre un
software care ne răspunde tuturor cerințelor fără ca noi să nu facem nimic. Folosirea cu succes
a tuturor avantajelor acestui sistem presupune atât o implemntare corectă cât și o folosire
corectă.
3.1.2 . Identificarea riscurilor și a beneficiilor implementării noului sistem în Universități
Succesul implementării unui sistem integrat depinde în primul rând de identificarea
riscurilor majore și de modalitățile de minimizare a acestor riscuri .
Un proiect de implementare a unui sistem integrat este foarte diferit de proiectele de
implementare a altor sistemelor informatice. Pentru a evita problemele care ar putea limita
beneficiile implementării unui astfel de sistem, acestea trebuie id entificate și el iminate înainte
ca sistemul să i ntre în funcțiune.
De regulă barierele care ar putea să apară în procesul de implementare a unui sistem
integrat se pot grupa în 4 categorii: m anageriale, resursă umană, tehnologie, proiectarea
sistemului. În tabelul 3.2 . sunt prezentate principalele probleme cu care ne -am putea confrunta
în momentul implementării sistemului informatic integrat în universități.
Nivel Probleme
Managerial Schimbarea persoanei de legatură va afecta sprijinul oferit de managem entul
superior al universității
Lipsa unui manager de proiect care să -și poată expune punctul d e vedere,
conduce la eșec în a realiza o colaborare strânsă între membrii echipei de
proiect și consultanți
Comunicare ineficientă
Depășirea termenului de finalizare stabilit
Depășirea bugetului
Training necorespunzător pentru utilizarea sistemului
27
Resursa
umană
Neatenția utilizatorilor atunci când se lucrează cu noul sistem
Slaba pregă tire a membrilor echipelor de implementare
Dezinteres din partea consultanț ilor
Lipsa comunică rii beneficiar -furnizor
Consultanții cheie sunt implicați și în alte proiecte și nu sunt disponibili
Insuficient suport din partea furnizorului
Lipsa disciplinei
Tehnologic
Calitatea necorespunzătoare a suportului de migrare a datelor
Erori de operare în timpul execuției tranzacțiilor
Probleme de conexiune în rețea/Internet
Universitatea întâmpină probleme tehnice în cazul trecerii la o nouă versiune a
sistemului
Proiectarea
sistemului Dezvoltarea de funcții greșite, a unei interfețe greșite
Lipsa de disciplină și standardizare a codului
Lipsa unei metodologii eficiente
Modificări în codul sursă
Tabelul 3.2 . Principalele probleme care pot apărea în momentul implementării sistemului informatic
Modalitățile prin care universitatea ar putea minimiza aceste riscuri sunt în strânsă legătură
cu resura umană, top managementul, buna înțelegere a nevoii unui nou sistem,
responsabilitatea furnizorului și nu în ultimul rând comunicarea eficientă dintre cele două părți
(furnizor – beneficiar). Încă de la început trebuie să se țină cont de faptul ca sprijinul acordat de
managementul de vârf al universităților este considerat unul dintre cei mai importanți factori
de succes pentru implementarea unui sistem integrat în mediul universitar. Implementarea
trebuie să beneficieze de aprobarea managementului de vârf, iar apoi să aibă parte de suportul
acestuia pe toată durata proiectului. Top managementul universității trebuie să gestioneze cu
atenție toate aspect ele ce implică implementarea soluției, mai ales dacă procesul de
implementare este întâmpinat cu rezistență la schimbare de către angajați. Tocmai de aceea
instruirea utilizatorilor sistemului este esențială pentru implementarea cu succes a soluției ERP.
Aceștia trebuie educați pentru a înțelege conceptele soluției ERP adoptate, pentru a se
familiariza cu procesele și practicile de afaceri încorporate în soluție, astfel încât la finalul
implementării ei să accepte în totalitate soluția și să fie apți să o f olosească cu succes. Astfel, cei
mai importanti pași în minimizarea acestor riscuri sunt:
28
Implicarea consultanților;
O strânsă colaborare între consultanți și echipa de proiect;
Suportul top managementului universitar;
Membrii ec hipei de proiect trebuie s a aibă experiență, cunoștințe și să fie dedicați
proiectului;
Specificarea detaliată a cerințelor;
Un plan de implementare detaliat;
Comunicare și colaborare cu utilizatorii cheie;
Training;
Testarea corespunzătoare a sistemului anterior implementării;
Mon itorizare atentă a sistemului după implementare.
3.1.3 . Identificarea echipelor de lucru
În realizarea implementării noului sistem, va fi necesară participarea atât a unui echipe
formată din membrii firmei furnizoare, cât și o echipă formată din membrii universității.
a) Echipa formată din membrii firmei furnizoare
În spatele acestui software se va găsi o echipă de profesioniști, specializați în ceea ce
fac, care muncesc cu pasiune în a crea produse de înaltă calitate. Acest software va fi dezvoltat
în așa f el încât să fie ușor de utilizat și să răspundă nevoilor utilizatorilor întru totul.
Pentru definirea echipei din partea firmei furnizoare, au fost luate în considerare
următoarele structuri de roluri necesare (o persoană poate avea unul sau mai multe roluri):
• manager de proiect;
• o persoană care va păstra legătura cu clientul;
• un QA Manager (persoană responsabilă cu menținerea și controlul calității);
• trei pro gramatori, care se vor ocupa cu instalarea și configurarea aplicației;
• doi analiș ti, care se vor ocupa de analiza proceselor specifice clientului și stabilirea
cerințelor de configurare;
• un tester, care va testa funcționarea corectă a sistemului instalat;
• doi traineri care se vor ocupa de instruirea utili zatorilor beneficiarului.
Managerul de proiect este persoana însărcinată cu coordonarea proiectului.
Echipa de proiect este o grupare temporară de specialiști ce dețin cunoștințele și aptitudinile
necesare pentru realizarea proiectului. Echipa se subordonează managerului de proiect.
Echipa
de
proiect
29
Membrii echipei de pro iect vor fi selecționați în funcție de sarcinile cerute de proiect, iar
numărul acestora va depinde de mărimea și complexitatea proiectului (de cerințele
beneficiarului). Pe lângă competențele de specialitate, este important ca aceștia să aibă
aptitudini p entru munca în echipă, pentru o bună comunicare, să fie creativi. Fiecare membru
trebuie să cunoască care îi sunt atribuțiile și să-și asume responsabilitatea.
Responsabilitățile generale ale echipei de lucru sunt prezentate în tabelul 3.3 ., după
cum urmează:
Membru Responsabilități în cadrul proiectului
Manager de
proiect – coordonează întreaga activitate de implementare;
– întocmește planul de implementare;
– întocmește rapoarte cu privire la stadiul implementării
– stabilirea obiectivelor și a di recțiilor generale de acțiune;
– clarificarea problemelor, gestionarea resurselor, configurarea rolurilor și a
structurilor acestora în cadrul echipei;
– elaborarea de rapoarte interne periodice privind calitatea aplicațiilor;
Persoana de
contact – se ocupă cu întocmirea tuturor documentelor care vor fi încheiate între cele
două părți;
– păstrează legătura între cele două echipe (furnizor – beneficiar);
– poate organiza ședințe cu teme privind stadiul implementării;
QA Manager – întocmește planu l de asigurare a calității implementării;
– definește responsabilități pentr u ambele echipe;
– stabilește modalitățile de monitorizare a evoluției proiectului de
implementare;
– ține evidența atât a realiză rilor, cât și a problemelor apărute.
Programat or – se ocupă cu pregătirea și verificarea tehnică a calculatoarelor beneficiarului:
calculatoare client, calculatoare pentru servere etc;
– instalarea și configurarea aplicațiilor necesare instalării sistemului ;
– instalarea sistemului ;
– configurarea sistemului ;
– verificarea funcționă rii a sistemului instalat;
– încărcarea ș i importul datelor din alte aplicaț ii ale clientului;
30
– întocmirea de rapoarte, pentru fiecare fază terminată .
Analist – discuț ii cu membrii echipei benefici arului pentru a determina cerinț ele
exprese ale acestora;
– ident ificarea particularităților organizaț iei universitare beneficiare;
– reali zarea de rapoarte pe baza discuț iilor purtate cu membrii echipei
beneficiare;
– întocmirea de specificații pentru noile cerințe și /sau particularități găsite sau
cerute de că tre client;
– comunicarea noilor cerințe și a particularităț ilor că tre coordonator ul
proiectului de implementare și că tre programatori;
– discuț ii cu clientul despre modalitatea de rezolvare a funcționalităț ilor
solicitate.
Tester – întocmirea de scenarii de test pentru sistemul abia implementat;
– testarea functionalităț ilor sistemului implementat (client ș i servere);
– teste de performanță a sistemului;
– pregă tirea datelor min imale care vor exista impli cit în sistemul clientului;
– întocmirea de rapoarte cu privire la stadiul de testare .
Trainer – instruirea utilizatorilor ;
– realizarea de scenarii de lucru;
– întocmirea de modalități de evaluare a cunoștiințelor dobâ ndite de
utilizatori;
– evaluarea cunoștiinț elor utilizatorilor (la cerea clientului);
– întocmirea de rapoarte privind stadiul seminariilor de instruire.
Tabelul 3.3 . – Responsabilitățile generale ale echipei de lucru – Furnizor
b) Echipa formată din membrii universității
Pentru implement area cu succes a sistemului informatic integrat în cadrul unei universități,
sprijinul managementului superior al universității este un factor decisiv. Proiectul ERP trebuie să
fie foarte bine organizat, fiind necesar:
• un coordonator al întregului proiec t;
• un reprezentant al conducerii universității;
• un reprezentant care va menține contactul cu firma furnizoare;
31
• un administrator de sistem;
• un responsabil cu raportarea dificultăților apărute în procesul de implementare;
• un reprezentant care va oferi informații despre modul de organizare a uni versităț ii;
• un reprezentant care să poată oferi informații despre sistemul de taxe, condiții de plată a
taxelor etc;
• reprezentan ți din cadrul secretariatelor;
Membru Responsabilități în cadrul proiectului
Coordonator
beneficiar – creează un plan de implementare formal;
– stabilește termene realiste de realizare a proiectului;
– coordonează întreaga echipă implicate în proiect din cadrul universității;
-planifică necesarul de resurse pe întreag a perioadă de desfășurare a
proiectului;
– întocmește rapoarte cu privire la stadiul implementării.
Reprezentant
conducere
universitate – discută cu organele de conducere din cadrul universității despre
necesitatea noului sistem;
– realizează un raport în care va preciza: locațiile în care va fi instalat noul
sistem, persoanele care vor avea acces la noul sistem;
– trebuie să semneze documente cu privire la corectitudinea informațiilor
oferite.
Persoana de contact – întocmește documentele care trebuiesc încheiate între cele două părți;
– asigură o bună comunicare între furnizor și beneficiar;
– organizează ședințe privind stadiul de implementare;
– comunică nemulțumirile/așteptările beneficiarului.
Administrator de
sistem – participă la configurarea noului sistem;
– poartă discuții cu analistul și trainerii;
– ajută la stabilirea locurilor în care va fi instalat noul sistem.
Responsabil cu
raportarea
problemelor curente – verifică calitatea sistemului;
– testează sistemul ;
– discută cu programatorii și analiștii firmei furnizoare;
– raportează evaluările și problemele aparute de -a lungul procesulului de
evaluare;
32
– semnează documente cu privire la corectitudinea informațiilor oferite.
Reprezentant al
departamentului
admini strativ – oferă documentații despre modul de organizare administrativă a
universității;
– discută cu analistul echipei furnizoare;
– poate participa la cursuri de instruire.
Reprezentant al
departamentului de
taxe – poartă discuții cu analistul echipei f urnizoare;
– oferă documentații cu privire la taxele instituite în cadrul universității;
– poate pa rticipa la cursuri de instruire;
– trebuie să semneze documente cu privire la corectitudinea informațiilor
oferite.
Secretara -șefă – poartă discuții cu analistul echipei furnizoare;
– oferă documentații despre modalitatea de organizare academică și
didactică a facultăților;
– trebuie să semneze documente cu privire la corectitudinea informațiilor
oferite.
Tabelul 3.4 . – Responsabil itățile generale al e echipei de lucru – Beneficiar
Utilizatorii aplicației locale pot avea unul dintre următoarele roluri: Responsabil aplicație
locală sau Operator. La instalarea sistemului local va fi creat automat un utilizator cu rolul de
administrator . Câteva dintre drepturile pe care le posedă cei doi utilizatori sunt prezentate în
fig. 3.2 ., după cum urmează:
Fig. 3.2 . Aplicație locală
Actualizare date studenți
Preluare date studenți din
anul anterior
Accesare date an anterior
Deschidere an universitar
nou
Import/Export de date
Administrare utilizatori
Modificare date aferente
unui student
Responsabil
aplicație locală
(La nivel de
universitate)
Opreator
(La nivel de
facultate)
33
3.2. INSTRUMENTE FOLOSITE ÎN IMPLEMENTAREA SISTEMULUI INFORMATIC
Realizarea unui sistem informatic este o activitate ce presupune folosirea unor resurse
financiare, umane ș i materiale . Această acț iune impune parcurgerea unor activităț i precum :
diagnoză, analiză , proiectare , programare, testare și implementare .
Pentru obținerea unui sistem informatic integrat performant este necesară utilizarea
eficientă a resurselor în toate aceste activități, tocmai de aceea este necesară ordonarea
acestui proces complex într -o succesiune bi ne stabilită de etape, subetape și utilizarea unor
metode și tehnici adecvate. Între diversele etape de realizar e a sistemului informatic există o
puternică legătură reflectată și de faptul că, în mod practic și logic, calitatea rezultatelor din
etapele și fazele precedente, influențează în mod direct calitatea activit ăților din următoarele
etape .
Un as pect comun pentru aceste etape este faptul că trecerea de la o etapă la alta se face
numai după o analiză amănunțită a modului de realizare a sar cinilor etapei în cauză . Orice
etapă, parcursă deja, se finalizează cu documentație și cu elaborarea sau actualizarea planului
de lucru privind pregătirea condițiilor de desfăș urare a activităților care urmează .
Pentru evitarea unor obstacole care ar putea sta în calea implementării cu succes a
sistemului informatic și pentru a micșora riscurile de dezvoltare și timpul de execuție prin
implementarea proiectelor în formă foarte flexibilă și interactivă se vor folosi instrumente
precum:
Metodologie de proiect Business Software – Microsoft Dynamics Sure Step;
Gantt Project ;
Metodologia Agile – SCRUM;
TFS (Team Foundation Server).
3.2.1. Microsoft Dynamics Sure Step și Gantt Project
Echipa dezvoltatoare, care implementează soluția Microsoft Dynamics NAV (Navision) în
univers ități, va adoptata o bună parte din instrumentele metodologiei de implementare
Microsoft Dynamics Sure Step, convinsă fiind că bunele practici incluse în aceasta sunt o
garanție a succesului oricărei implementări. Aceasta oferă partene rilor dar și clienților siguranța
realizării unei implementări reușite punând la dispoziția coordonatorilor de proiect instrumente
adecvate pentru planificare, monitorizare și control. Pentru a se obține o imagine clară atât a
34
cerințelor de afaceri cât și a soluțiilor pentru aceste cerințe, fiecare fază a implementării este
documentată.
Fig.3.3 . – Metodologia Sure Step – Prezentarea elementelor chei e din cadrul metodologiei
Metodologia oferă numeroase îndrumări, rodul sintezei celor mai bune practici din
domeniul implementărilor și al managementul de proiect. Diverse modele de documente sunt
disponibile iar managerii de proiect le pot alege funcție de complexitatea proiectului.
Fig.3.4 . – Documente Sure Step
Implementarea unei soluții de tip ERP nu se po ate realiza fără un management de
proiect profesionist și fără un intens efort organizatoric atât din partea furnizorului cât și din
cea a beneficiarului. De aceea, firma Microsoft, care vinde mai multe soluții de tip ERP și CRM,
conștientă de neajunsul im plementarii a decis să ajute partenerii – cei care realizează
implementările soluțiilor, printr -o metodologie de implementare care să ofere sprijin
35
implementatorilor. Această metodologie este cuprinsă într -un pachet software care se poate
instala fie pe o stație de lucru fie în rețea, prin int egrare cu tehnologia SharePoint.
În Fig. 3.5 ., este prezentată Diagrama Gantt21 cu etapele necesare dezvoltării sistemului
software pentru administrarea și gestiunea tuturor activităților din cadrul unei universități,
urmând pașii de implementare din cadrul metodologiei de implementare Microsoft Dynamics
Sure Step.
Fig. 3.5 . Diagrama Gantt
Proiectul se va desfășura pe o perioadă de 248 de zile, mai exact din data de 10.07.2017
până în data de 20.06.2018 . Numă rul de zile se împarte astfel: 19 zile pentru diagnoză, 13 zile
pentru analiză, 15 zile pentru proiectar e, 170 zile p entru dezvoltar e și testare, 1 3 zile pentru
implementare și 1 8 zile pentru etapa de operațional.
1. Diagnoza
Această etapă este o etapă premergătoar e implementării propriu -zise a sistemului, rolul
acesteia fiind de a familiariza echipa de implementare cu Universitatea. Mai mult, finalizarea
corectă a acestei etape va fi un punct de plecare forte pentru următoarele etape. În cadrul
acestei etape se rea lizează acțiuni precum:
Definirea întinderii proiectului;
Îndrumarea clientului către tipul de proiect adecvat nevoilor sale;
Estimarea costurilor, riscurilor și a timpului necesar desfășurării proiectului;
Planificarea resurselor (umane, material, financi are);
Crearea unui Plan de Proiect.
21 Diagrama GANTT este un instrument folosit în planificarea proiectelor, evenimentelor și a muncii, în general.
Urmărește etapele desfășurării unui proiect în funcție de durata acestora.
36
Pentru ca furnizorul sistemului ERP să realizeze o ofertă cât mai apropiată de adevăr, este
necesară o analiză preliminară a nevoilor clientului. Pot avea loc întâlniri între echipă de
consultanță a implementatorului și utilizatorii cheie ai universității pentru a culege date despre
situația actuală. În urmă întâlnirilor vor rezulta niște documente cu rolul de a clarifica cerințele
beneficiarului.
Punctul de plecare în aceată etapă îl reprezintă de f apt organ igrama universității, iar o dată
cu aceasta:
Numărul facultăților existene în universitate;
Direcția general administrativă;
Departamentele din cadrul tututor facultăților;
Numărul angajatilor;
Numărului aproximativ de studenț i care studiază anual în cadrul universități i.
După ce au fost identificate componentele organizatorice, specialiștii firmei furnizoare
vor oferi recomandări și scheme de implementare optime în cadrul universității. Este necesară
prezentarea și cunoașterea tuturor participanților la proiectul de implementare, indiferent de
gradul în care vor fi implicați.
Fig. 3.6 . Diagnoza
2. Analiza
Etapa de analiză reprezintă începutul implementării și este și cea mai importantă. În această
etapă sunt organizate întâlniri între utilizatorii cheie ai universității și consultanții firmei
furnizoare pentru a identifica și documenta cerințele beneficiarului. Metodologia Sure Step
indică pentru această etapă mai multe tipuri de documente ce se pot întocmi însă cele mai
importante sunt :
Documentul Cerințelor Funcționale (Funcțional Requirements Document FRD)
Document de analiza „Gap -Fit” (Gap -Fit Analysis)
37
Documentul Cerințelor Funcționale – Scopul acestui document este să identifice toate
cerințele funcționale ale clientului. Cerința funcțională reprezintă în fapt ce anume așteaptă
clientul ca soluția să realizeze pentru a susține procesele sale de afaceri. De exemplu,
beneficiarul vrea să urmărească parcursul unui cursant în universitate începând cu
înmatricularea și până după absolv ire, sistemul nou implementat să permită calcularea
automată și gestionarea creditelor și punctelor credit pentru fiecare disciplină, administrarea
situației f inanciare, a examenelor finale și a actelor de studii aferente.
Documentul de analiză „Gap -Fit” – se realizează de obicei în Excel și este structurat pe
arii funcționale(Resurse Umane, Academic, Admitere, Finanțe, etc). Rolul acestui document
este de a cla rifica cerințele funcționale care sunt rezolvate prin sistemul standard vizavi de cele
care necesită dezvoltări în sistem.
Fiecare cerință este clasificată din punct de vedere al importanței și totodată
categorisită ca Fit – nu necesită dezvoltări sau ca Gap – necesită dezvoltări.
În fiecare instituție de învățământ superior e xistă caracteristici specific pr ivind
desfășurarea activităților. De accea, înainte de toate este necesară efectuarea unei analize a
proceselor beneficiarului. Această analiză este f acută de către analistul delegat de catre firma
furnizoare, prin intermediul: interviurilor, sedințelor, chestionarelor, etc. Pentru fiecare proces
identificat și discutat, beneficiarul trebuie să semneze cu privire la corectitudinea informațiilor
oferite. Responsabili pentru această etapă sunt: Analistul, ca reprezentant al echipei furnizoare,
Secretarele șefe și/sau secretarele facultăților din cadrul Universității, reprezentatul
Departamentul de Taxe și Directorul Administrativ, ca reprezentanți ai echip ei Universității.
Fig. 3. 7. Analiza cerințelor
38
3. Etapa de Proiectare
Scopul acestei etape este acela de a defini modul în care cerințele funcționale ale clientului
vor fi implementate în noul sistem.
Această etapă include activități precum:
Definirea utilizatorilor și drepturile lor de acces în sistem. Aceste configurări sunt
documentate în „Documentul de Design Funcțional pentru Configurări” (Functional
Design Document for Fits -Configurations).
Designul realizat de către consultant – detali ază dezvolt area din punctul de vedere
funcț ional – de aici rezultă „Documentul de Design Funcțional pentru Dezvoltări
Specifice”(Functional Design Document Customizations).
Designul realizat de către dezvoltator – detaliază dezvoltarea din punct de vedere
tehnic, astfel se obține „Documentul de Design Tehnic” (Technical Design Document).
Deoarece realizarea a trei documente diferite poate împovăra viziuna globală asupra
soluției, se recomadă întocmirea unui singur document care să descrie în ansamblu, înt r-un
limbaj pe înțelesul beneficiarului, soluția pentru cerințele sale, astfel se va obține „Documentul
de Design al Soluției”(Solution Design Document).
Fig. 3. 8. Proiectarea arhitecturii software
4. Etapa de Dezvoltare
În etapa de dezvoltare se realizează adaptările specifice clientului, așa cum au fost ele
definite și aprobate în etapa de design astfel se vor realizeaza activități precum:
Dezvoltăr i și testări ale dezvoltărilor;
Procese de migrare ale datelor;
39
Elabora rea scenariilor de testare pentru utilizatorii finali.
Realizarea unor scenarii de testare (test scri pts) este foarte importantă deo arece în baza
acestora , utilizatorii vor confirma faptul că dezvoltările satisfac cerințele funcționale
documentate în etap ele anterioare.
Fig. 3. 9. Etapa de dezvoltare
Fig. 3.1 0. Etapa de testar e
5. Etapa de I mplementare
Această etapă cuprinde toate activitățile necesare pentru ca sistemul să poate fi instalat iar
clientul să poată lucra efectiv cu acesta. Instalarea se face în baza unui Plan de Instalare
(Deployment Plan) care documentează acțiuni precum:
Migrarea datelor;
Parametrizarea mediului de lucru;
Parametrizare utilizatorilor;
Instruirea utilizatorilor finali;
Strategii de instalare a aplicației.
De asemenea, planul de Instalare prevede un calendar de desfașurare al fiecărei operațiuni
precum și resursele care sunt alocate pe ntru realizarea activităților.
40
Fig. 3.1 1. Implementarea sistemului informatic
6. Etapa de Operațional
Această etapă include acțiunile necesare pentru a închide proiectul și pentru a transfera
atât soluția cât și cunoștințele despre soluție beneficiarului. Presupune realizare a unor activități
precum:
Finalizarea ultimelor probleme;
Acordarea s uport ului utilizatorilor ;
Realizarea unor teste de performan ță și optimizări ale sistemului;
Transferul de cunoștințe dinspre echipa de implementare către utilizatori;
Documentarea unor lecții învățate de -a lungul implementării – pentru a le folosi în
viitor;
În această ultimă etapă se elaborează documentul „Raport Închidere Proiect” (Project
Closeout Report) al cărui scop este acela de a verifica și valida rezultatele proiectului precum și
de a obține accept ul din partea beneficiarului pr ivind realizarea implementării. Conținutul
acestui raport este prezentat în Anexa 1.
Fig. 3.1 2. Etapa de operațional
În derularea proiectului se vor folosi două tipui de dependențe:
1. Finish to Start
– atunci când task -ul predecesor (A) s -a încheiat, task -ul succesor (B) va începe.
41
2. Start to Start
– startul task -ului predecesor (A) declanșează startul task -ului succesor (B), adică task -ul
(B) poate începe după ce a început task -ul (A).
Fig. 3.1 3. Resources Char t
În Fig. 3.13 se prezintă echipa de lucru, fiecare membru având un rol bine stabilit astfel
încât să se atingă obiectivele propuse.
3.2.2. Metodologia Agile – SCRUM
Principiile Metodologiei Agile22:
Prioritatea este satisfacția clientului prin livrarea rapidă și continuă de software valoros.
Schimbarea cerințelor este binevenită chiar și într -o fază avansată a dezvoltării.
Procesele agile valorifică schimbarea în avantajul competitiv al clientului.
Livrarea de softwa re funcțional se face frecvent, de preferință la intervale de timp cât
mai mici, de la câteva săptămâni la câteva luni.
Oamenii de afaceri și dezvoltatorii trebuie să colaboreze zilnic pe parcursul proiectului.
Cea mai eficientă metodă de a transmite infor mații înspre și în interiorul echipei de
dezvoltare este comunicarea față în față.
Software funcțional este principala măsură a progresului.
Procesele agile promovează dezvoltarea durabilă. Sponsorii, dezvoltatorii și utilizatorii
trebuie să poată menține un ritm constant pe termen nedefinit.
La intervale regulate, echipa reflectă la cum să devină mai eficientă, apoi își adaptează și
ajustează comportamentul în consecință.
22 http://agilemanifesto.org/iso/ro/principles.html (Consultat la data 23.05.2017)
42
Metodologii le care derivează din Agile : XP , SCRUM , DSDM, Crystal, Feature Driven, Lean
Development etc. ,folosesc principii de bază ale filozofiei AGILE, dar o implementează în
moduri diferite.
Pentru o bună organizare în dezvoltarea aplicați ei software , pentru livrări ce vor avea loc
frecvent, astfel încât clientul să primească de fi ecare dată o aplicație ce conține un număr tot
mai mare de funcționalități și care se află în perfectă stare de funcționa re se va adopta
metodologia SCRUM.
Această metodă necesită patru tipuri de ședințe :
Ședințele zilnice: echipa se reunește în fiecare zi pentru aproximativ 15 minute, în
picioare, pentru a răspunde la următoarele trei întrebări: Ce am făcut ieri? Ce voi face azi? Cu
ce obstacole mă confrunt azi?
Ședințele de planificare : întreaga echipă se adună, o dată la două săptămâni, pentru a
decide care sunt funcționalitățile care vor alcătui următorul sprint, și pentru a actualiza lista
generală.
Ședințele de revizuire a activității : în timpul acestei ședințe, fiecare membru prezintă
ceea ce a făcut pe durata sprintului. Aceasta este o ședință informală, de două ore, la care
participă toată echipa.
Ședințele retrospective : la finalul fiecărui sprint, echipa analizează aspectele care au
funcționat bine, precum și pe cele care au funcționat mai puțin bine. În timpul acestei ședințe
de 15 –30 de minute, se organizează un vot de încredere pentru a decide ce îmbunătățiri trebuie
implementate.
AVANTAJ MOD DE CONCRETIZARE
Reducerea documentației Sporirea productivității
Evitarea „efectului de
tunel" Rezultatele sunt obține pe întreaga durată a fazei de dezvoltare ,
nu doar la finalul acesteia.
Compunerea secvențială a
conținutului sprint -urilor Permite efectuarea unei modificări sau adăugarea unei
funcționalități care nu era prevăzută inițial. Acest a este principalul
aspect care face ca această metodă să fie „agilă“.
Metodă participativă
Fiecare membru al echipei este invitat să își exprime părerea și
poate contribui la toate deciziile luate în cadrul proiectului, fiind
astfel mai implicat și mai motivat .
43
Facilitarea comunicării Lucrând în aceeași sală de dezvoltare sau fiind conectată prin
intermediul diferitelor mijloace de comunicare, echipa poate
comunica ușor și poate schimba informații despre impedimentele
întâlnite în scopul eliminării cât mai rapide a acestora .
Eficientizarea timpului Timpul de livrare a produsului final se reduce semnificativ.
Tabelul 3.5. Avantajele Metodologiei SCRUM
Metodologia SCRUM implică intervenția a trei protagoniști :
Product owner : responsabilul de produs și coordonatorul echipei clientului.
ScrumMaster : facilitează buna desfășurare a proiectului, are grijă ca fiecare membru să
poată lucra la capacitate maximă eliminând impedimentele și protejând echipa de
perturbările exterioare.
Echipa : fiind de regulă alcătuită din circa 4 -10 persoane, aici se adună la un loc
specialiștii necesari în cadrul unui proiect, și anume: arhitectul, designerul,
programatorul, testerul etc.
3.2.3 . Team Foundation Server – TFS
Team Foundation Server est e o soluție ce poate fi utilizată atât pentru gestionarea
proiectelor, cât și pentru a urmări work -flow -ul în echipe, pentru a gestiona codul sursă și
pentru a compila și testa software -ul. Acest lucru se poate realiza fie cu TFS instalat pe un
server pro priu fie prin utilizarea Visual Studio Online în cloud .
Fig.3.1 4. Team Foundation Server
44
3.3. ELEMENTE CHEIE PRIVIND RELAȚIA FURNIZOR – BENEFICIAR
Confidențialitatea
Îndeplinirea sarcinilor de către firma furnizo are implică accesul la informațiile
confidențiale. Toate informațiile obținute din cadrul universității vor fi tratate de către furnizor
ca fiind confidențiale, nu vor fi utilizate în alte scopuri decât cele legate de îndeplinirea
contractului și nu vor fi dezvăluite unei terțe părți, fără a avea în prealabil acordul scris din
partea beneficiarului. Furnizorul poate împărtăși informațiile confidențiale strict necesare
angajaților săi în vederea îndeplinirii sarcinilor. În fiecare caz de acest gen, furnizorul va
consemna persoanele respective cu privire la obligația de a păstra confidențialitatea acestor
informații și se va asigura că persoanele respective au semnat declarațiile de confidențialitate.
Protejarea informațiilor și sistemele de securitate
Pe întrega durată a implemetării noului sistem informatic, echipa furnizoare va trebui să
respecte standardele privind protecția, securitatea și integritatea informațiilor și să ia toate
măsurile necesare pentru a nu compromite aceste standarde în toate locur ile unde își
desfășoară activitatea. Furnizorul trebuie să garanteze că toate mijloacele de stocare
electronice pe care sunt înregistrate datele beneficiarului sunt în siguranță și că toate aceste
dispozitive nu conțin viruși sau alte elemente ce pot pertu rba funcționarea normală a activi tății
din cadrul universității.
Modificări
Pe parcursul derulării întregii activități de implementare a noului sistem atât
beneficiarul cât și furnizorul vor putea solicita transformarea prevederilor inițiale ale
contractu lui. Părțile, de comun acord, pot renunța la anumite servicii pe durata desfășurării
contractului și pot include alte servicii considerate a fi necesare, în limita valorii contractului,
prin intermediul unui act adițional.
Suport
Echipa dezvoltatoare va sta mereu la î ndemana beneficiarului, oferindu -i suport continuu
prin:
Helpdesk: furnizorul stă la dispoziția clientului atât pentru întrebări urgente cât și
pentru suport operațional. Întrebările pot fi: erori de aplicație, setări, configurare, lipsa
de e xperiență în lucrul cu sistemul ERP etc.
45
Training dedicat: ca în orice companie și în cadrul universității există fluctuații de
personal, schimbări de proceduri sau dezvoltări de noi funcționalități, de aceea este
necesar un training constant.
Dezvoltarea de noi funcționalități: În cazul în care clientul dorește dezvoltarea de noi
funcționalități, sau dezvoltări de rap oarte noi, se pot crea proiecte conform cerințelor
beneficiarului.
Documentație: se va crea un set complet de documentație ș i proceduri .
Administrarea sistemului: în cazul în care se dorește un back up pentru administratorul
de sistem, se pot pune la dispoziția clientului consultanții tehnici ai firmei furnizoare,
pentru a beneficia d e o susținere sigură și continuă .
Asistența tehnică
Furnizorul trebuie să prezinte planul de asistență tehnică și suport beneficiarului. Acest
plan trebuie să conțină detalii despre oferta de asistență și arhitectura de suport a furnizorului.
Caracteristicile minime pe care trebuie să le cuprindă aceast plan s unt următoarele:
Furnizorul trebuie să ofere asistență pentru toate elementele aplicației. În ceea ce
privește componentele software, se va asigura un contract de asistență tehnică cu
producătorul software -ului licențiat pentru clarificarea problemelor ce țin de
infrastructura software.
Furnizorul trebuie să asigure, pe tot parcursul dezvoltării și în perioada de garanție
oferită beneficiarului, asistență tehnică gratuită. Asistența va fi asigurată în toate zilele
calendaristice, fără întrerupere.
Benefic iarul trebuie să fie înștiințat cu privire la disponibilitatea componentelor de
upgrade pentru software (versiuni noi, actualizări, corecții, etc)
Rezolvarea problemelor trebuie să înceapă după raportarea erorii, conform următorului
tabel de gravitate:
Nivel de
gravitate Problemă Reacția
furnizorului
(ore) Timp de
rezolvare a
problemei (ore) Observații
I Eroare de sistem critică 1 8 Sistemul informatic
nu este funcțional
II Unele componente ale
sistemului nu sunt
funcționale 1 24 Anumite module/
submodule nu
funcționează
46
III Unele funcții sunt
reduse, dar
operaționale 1 72 Anumite
componente
funcționează
necorescunzător
IV Probleme minore,
sistemul este
operațional 4 72 Dificultăți
neprevăzute, care nu
împiedică
desfășurarea
normală a activității
V Cerințele clientului
privind optimizarea
unor componente 4 72-168 Timpul de rezolvare
depinde de
importanța/
dificultatea cerinței
Tabelul 3.6. Gravitatea problemelor
Instruire
Se va realiza un plan detaliat al instruirii, pe categorii, mediul de instruire, tipuri de
materiale puse la dispoziție etc. La încheierea fiecărui modul de instruire, participanții vor
completa un formular de feedback cu privire la instruirea primită. Furnizorul va oferi instruire
beneficiarului după cum urmează:
Categorie Durata minimă (zile) Numărul aproximativ de
participanți
Administratori de sistem 12 4
Utilizatori cheie 6 10
Utilizatori finali 2 100
Tabelul 3. 7 Instruire beneficiar
Documentația
Echipa dezvoltatorului sistemului informatic integrat în colaborarea cu grupul de experți
din cadrul universității trebuie să elaboreze numeroase documente necesare activității de
dezvoltare a sistemului. Dintre cele mai importante documente fac parte:
– Document cu privire la gestiunea informațiilor despre studenți ;
– Cerințe funcționale ale sistemului informatic integrat ;
– Raport de începere a proiectului ;
– Raport de analiză și proiectare a sistemului ;
– Raport privind documentația de proiectare ;
47
– Arhitectura bazei de date;
– Raport de testare aferent aplicației de culegere a datelor ;
– Regulament de securitate IT ;
– Plan de recuperare în caz de dezastru ;
– Plan de continuitate a activității ;
– Politică privind clasificarea informațiilor ;
– Descrierea sistemului informatic instalat ;
– Manual de instalare și utilizare;
– Raport de implementare a sistemului ;
– Plan de testare completă a sistemului .
48
CAP. 4 . ARHITECTURA DE BAZĂ A SISTEMULUI ERP
Numarul modulelor din cadrul unui sistem informatic integrat de tip ERP poate fi foarte
mare, însă scopul actual este ce l de a identifica modulele funcționale de bază ale sistemului
ERP, care să permită ulterior dezvoltarea u nei arhitecturi standard de bază utilizată ca
fundament pentru integrare.
4.1. STABILIREA MODULELOR DE BAZĂ A SISTEMULUI ERP
Pentru a asigura succesul implementării sistemului informatic integrat, acesta trebuie
adaptat obiectivelor universității și modalităților de lucru existente la nivelul acesteia. În fig.
4.1., este propus un model de bază pentru implementarea unui sistem ERP în ca drul unei
universități din România. Toate modulele sunt interconectate cu modulul Financiar, iar sistemul
prevede un generator de rapoarte și statistici, pentru fiecare modul al sistemului ERP în parte.
Noul sistem informatic va fi dedicat administrării ac tivităților din procesele educaționale
existente în mediile universitare. Având o structură modulară, sistemul ERP își propune să
trateze următoarele sectoare cu specific academic:
structura organizatorică și componentele specifice universității;
admiter e și sesiuni de admitere;
personal didactic;
studenți;
organizarea academică a fiecărei facultăți din cadrul universității;
planuri de învățământ, sisteme de notație;
taxe universitare;
situații școlare necesare managementului universitar.
Produsul sof tware integrat va răspunde celor mai exigente cerințe, va integra atât aspecte
legate de organizarea academico -didactică, cât și instrumente dedicate managementului
proceselor și documentelor, sau sistemului de învâțământ la distanță, oferind o imagine de
ansamblu managementului universitar. Spre exemplu ciclul de viață al unui student din
momentul în care aplică pentru a fi admis la facultate, până la finalizarea studiilor și parcursul
său ca absolvent. Soluția va oferi în timp real informații de analiză ș i sinteză necesare în
procesul decizional.
49
Fig. 4.1 . Arhitectura de bază a sistemului ERP
MODULUL ADMITERE
MODULUL ACADEMIC
Managementul
programelor
academice
Managementul
programelor
de cercetare
Gestiune
studenți
Examinări
Cazare
Burse
Abonamente
transport
MODULUL FINANCIAR
Contabilitate
te
Taxe
Obiecte de inventar
Casierie
Management Bugete
Management înregistrare studenți
Management Admitere
te
MODULUL ADMINISTRARE
MODULUL RESURSE UMANE
Management personal
Managementul salarizării
Conectat
Conectat
Conectat
Conectat
Conectat
Conectat
Conectat
MODULUL RAPOARTE
Rapoarte
Admitere
Rapoarte
Didactice
Rapoarte
Financiare
Rapoarte
Cazări
Rapoarte
Burse
Exemple
50
Sistemul dispune de o structură modulară, organizată astfel încât să asigure un grad mare
de indepen dență între module. Adă ugarea sau eliminarea unor module devi ne posibilă fără a le
afecta pe celelalte. Varianta standard a sistemului cuprinde 6 module, fiecare dintre acestea
având și submodule, unele fiind opț ionale, astfel pot fi achiziționate ulterior componentei
standard. Modulele opționale nu funcționează fără componenta standard a sistemului.
Modulul Admitere
Modulul Academic
Modulul Resurse Umane
Modulul Finanțe
Modulul Administrare
Modulul Rapoarte
1. Modulul Admitere
Modulul de admit ere permite gestionarea candidaț ilor ce concurează pe locurile scoase la
concurs pentru fiecare ciclu de studii în parte (licență , master, doctorat, etc.). Acesta facilitează
gestionarea datelor personale și a opțiunilor candidatului, realizarea automată a clasamentului,
achitarea taxelor. La dispoziția c andidatului vor sta două metode de introducere a candidaturii
în sistem: candidatul îș i va introduce datele personale sau comisia de admitere introduce datele
candidatului.
Totodată se vor atașa și specializă rile pentru car e optează candidatul, forma de î nvățământ,
forma de finanțare. Pentru situaț iile de egalitate a notei finale sistemul permite definirea de
criterii de departajare : medii obținute în anii de liceu, note obț inute la concursul de admitere
organizat de universitate etc.
Pe baza clasamentelor real izate de sistem, se va realiza înmatricularea candidaț ilor pe unul
din locurile corespunzatoare tipurilor de loc pentru care a optat candidatul sau pe tipul de loc
rezultat conform procedurii de admitere. Sistemul va modifica clasamentul în cazurile în care
anumiți candidați își retrag dosarele, i ar în cazul înmatriculării sistemul permite î ncas area unor
taxe precum, taxa de înmatriculare și vizualizarea încasărilor de că tre comisiile de admitere.
2. Modulul Academic
Modulul prezintă o imagine clară asupra universității, pe facultăți, departamente, pe ani
universitari și specializări.
În cadrul Modulului Academic fac parte următoarele submodule:
Managementul programelor academic e
51
Gestionare studenț i
Examinari
Cazare
Burse
Abonamente Transport
a) Man agementul programelor academic e
În cadrul acestui submodul vor fi gestionate toate facultățile fiind posibilă stabilirea:
specializarilor, formelor de învățămâ nt și a anilor de studiu;
catedrelor didactice existente î n fiecare facultate – este posibilă specificarea mai multor
categorii de ca dre didactice: membri de catedră, șefi de catedră , cadre didactice externe
universității (consultanți, specialiș ti, profesori de la alte universităț i etc). Pentru fiecare cadru
didacti c poate fi precizat titlul ac ademic: Asistent universitar, P rofesor universitar etc.
discipline – pot fi gestionate următoarele informaț ii: categoria (obligatorie/opțională ),
tipul (curs , laborator, seminar etc.), numă rul de credite, semestrul de studiu , cadrele didactice
care asigură predarea disciplinei, forma d e examinare finală a disciplinei (examen, colocviu etc).
planuri de învățământ – modulul asigură întocmirea planurilor de învățămân t pentru
fiecare serie de studenț i, oferind o organizare pe ani universitari;
sesiuni de examinari;
organizare a pe grupe ș i subgrupe de studenți ;
registrelor matricole și a fiș elor matricole.
b) Gestionare studenți
Parcursul unui cursant în universitate este urmărit începând cu înm atriculare și până după
absolvi re. Sistemul informatic integ rat Microsoft Dynamics NAV permite:
gestionarea studenț ilor din fiecare facultate;
evidența datelor personale ale studenț ilor: nume, prenume, cnp, dată naștere, prenume
părinți, locul nașterii, adresa, cetăț enie, religie, date de contact.
administrarea taxelor – cât a plătit și câ t mai are de achitat din taxa de studii, ce fel de
taxe a mai platit (taxă de înmatriculare, taxa pentru cazare, etc), ce penaliză ri a achitat
etc.
Instituțiile de învățămâ nt absolvite: liceu , facultate ;
informaț ii despre stadiul actual al obiectului de studiu: facultate, specia lizare, an de
studiu, forma de învățămân t, limba de studiu;
52
rezultatele la examene;
clasificarea studenț ilor: bu rsieri (pe tipuri de burse), plătitori de taxă (pe tipuri de taxă );
situaț ii deosebite: transfer, î ntrer upere studii, exmatriculare, reî nmatriculare, etc;
evidențierea studenț ilor care au beneficiat de burse ERASMUS avâ nd posibilit atea de
echivalare a notelor obț inute ;
oferirea posibilității de cunoaștere a provenienț ei unui student: admitere, transfer etc;
vizualizarea rapoartelor oficiale s pecifice secretariatelor: Situație școlară, Supliment de
diplomă, Registre, Adeverinț e, etc. ;
sortarea și filtrarea studenților după diferite criteria.
c) Examină ri
Pentru fiecare materie există posibilitatea planificării unuia sau a mai multor tipuri de
examinare. Submodul ul oferă opțiuni pentru gestionarea studenților care au restanțe din anii
anteriori, a măririlor de note dar și a studenților integraliști. Se pot efectua operații legate de
căutare a unui student, pot fi scoase diferite tipuri de rapoarte, se pot modifica stările sau
notele studenților, ordinea materiilor poate fi sortată etc.
d) Cazare
Submo dulul în care se realizează activitatea de acordare a locurilor în căminele
studențești ține evidența studenților, masteranzilor, doctoranzilor din cadrul universității, ce
permite gestionarea centralizată a datelor de școlarizare dar și a celor personale.
Administrarea cazărilor studenților este realizată în funcție de opțiuni și medii. Tot aici se vor
stabili căminele și numărul de locuri repartizate fiecărei facultăți sau departament din
universitate, până la programul și anul de studiu. Sistemul inform atic este alcătuit dintr -o rețea
internă conectată între secretariat și administrația căminelor.
e) Burse
Sistemul lucrează cu toa te tipurile de burse existente într -un mediu universitar: bursă de
performanță, bursă de merit, bursă de studiu, bursă specială, bursă de ajutor social, etc. În plus,
în fiecare an universitar este po sibilă stabilirea fondurilor de burse, în funcție de aprobă rile
primite de la conducerea universității. Conducerea universității poate urmă ri cum sunt
repartizate și distribuite aceste fonduri î n fiecar e an universitar, fiind posibilă realizarea de
previzi uni pe anii universitari următori și compararea evoluț iei fondurilor bursiere. Sistemul
permite:
53
atât gestiunea burselor acordate din venituri proprii cât ș i cele ac ordate din bugetul de
stat;
generarea de corecții î n cazurile speciale care pot aparea pe parcursul distribuirii
burselor;
generarea listelor cu studenții bursieri ș i a valorii afere nte acestora pentru fiecare lună
în parte, pentru fiecare sursă de finanț are;
gestionarea in formaț iilor despre contul bancar al studentului ;
generarea u nor liste ș i cent ralizatoare pentru fiecare bancă în parte astfel încât
conturile studenților să fie alimentate lunar cu suma corespunzatoare bursei.
f) Abonamente Transport
Sistemul permite î nregis trare a cererilor de rambursare totală sau parțială a costuri lor de
transport public local ș i interurban, gestionează diferitele tipuri de abonamente care sunt
decontate în mediul universitar și emiterea listelor cu studenții a bonați. Pe baza acestor cereri
și a aprobă rilor aferente , sistemul permite alimentarea cont urilor studenț ilor cu valorile
aprobate a fi restituite. Valoarea abonamentelor este stabilită anual ținându -se cont de
fondurile alocate și de numărul cursanților.
3. Modulul Resurse Umane
Management personal
o Gestionarea informațiilor despre an gajații universității;
o Obținerea de rapoarte specifice.
Managementul salarizării
4. Modulul Financiar
Modulul de Management Financiar din Dynamics NAV permite gestionarea financiar –
contabilă a universității. Acest modul conține informații despre:
Contabilitate
Obiecte de inventar
Casierie
Taxe
a) Contabilitate
Dintre funcționalitățile acestui submodul enumerăm:
Vizualizarea solduril or pentru o anumită perioadă;
54
Înregistrări contabile;
Definirea bugetelor pentru un semestru, u n an sau orice altă perioadă;
Definirea bugetelor pe facultăți;
Managementul conturilor bancare – permite gestiunea conturilor bancare ale
universității și diverse operațiuni cu conturi bancare.
b) Obiecte de inventar
Acest subm odul permite defin irea ș i urmărirea resurselor material e din cadrul
universității (echipamente , calculatoare, birouri etc.).
c) Casierie
Încas area tuturor taxelor existente în cadrul universităț ii;
În cazul taxe lor de studii sistemul permite încasarea totală sau parțială a obligațiilor de
plată ;
La operarea încasării sistemul generează automat chitanța aferentă ;
Există posibilitatea anulă rii unei chitanț e;
Încasarea de penalități în c azul depășirii datei scadente, ținând cont de valoarea
datorată și de durata întârzierii;
Restituiri ale încasărilor;
Încasarea de taxe pentru examenele pe care un student nu l -a promovat.
d) Taxe
Avantajul real oferit este posibili tatea urmăririi situației achitării/ neachitării taxei de
școlarizare de către studenț i, astfel cunoașterii în orice moment a obliga țiilor financiare ale
acestora. Acest submodul oferă posibilitatea înregistrării oricărui tip de taxă ce poate fi platită
în cadrul unei universități: taxa de î nmatriculare, taxa de studii, taxa pentru restanță, taxa de
cămin etc.
Evident există o strânsă legătură între departamentul taxe ș i secre tariatele universității, .
Însă taxele achitate de către studenți pot fi vizualizate și de către alț i utilizatori care au drepturi
aferente: rector, prorector, decani, prodecani e tc.
Având în vedere că există cazuri în care studenților li se acordă reduceri la plata anumitor
taxe (taxa de studii, taxa de cămin etc), a fost introdus ș i conceptul d e reducere astfel unui
student î i pot fi acordate una sau mai m ulte reduceri. Acest mod ul oferă un grad ridicat de
flexibilit ate, deoarece este posibilă creșterea sau diminuarea valorii taxei, introducerea sau
eliminarea unei taxe, etc.
55
Sistemul permite urmărirea financiară a taxelor și a încasării acestora î n cadrul universităț ii,
cu ajutor ul unor configurări precum:
Definirea tipurilor de taxe: taxa înmatriculare, studii licență , studii master , taxe eliberare
documente, taxă susț inere examene etc.
Definirea taxelor pentru fiecare an universitar, facultate, specializare, forma de învățămân t,
acestea putând fi achitate integral sau în tranșe.
5. Modulul Administrare
Acest modul este dedicat î n exclusivitat e administratorului sistemului ș i echipei de
implementare a sistemului. Prin intermediul acestui modul este posibilă adă ugarea de noi
module, crearea conturilor utilizator ș i acordarea drepturilor acestora, crearea grupurilor de
utilizatori, ștergerea datelor locale etc.
6. Modulul Rapoarte
Modulul are drept scop asigurarea unor rapoarte de calitate privind evol uția princ ipalilor
indicatori ai scolarității. Este posibilă generarea de statistici sau obț inerea de rapoarte curente
de lucru, acestea pot fi listate direct, sau salvate î n diferite formate: pdf, excel, text etc.
Sistemul pune la dispoziț ie o serie de ra poarte necesare atât secretariate lor cât ș i
conducerii universității, ca de exemplu:
Tip raport Destinație
Rapoarte admitere Comisii de admitere
Secretariat
Cadre didactice
Conducerii universităț ii
Rapoarte didactice Cadre didactice
Secretariat
Rapoarte financiare Managementului universitar
Personalului de la departamentul de taxe
Rapoarte cazari
Comisia de cazări
Secretariat
Administratorilor de camine
Rapoarte burse Comisia de burse
Secretariat
Departamentului social
Departamentului financiar
Tabelul 4.1 . Tipuri de rapoarte
56
4.2. IMPLEMENTAREA UNEI SOLUȚII INTEGRATE PILOT
4.2.1 . Funcționalitățile generale ale modulului de Resurse Umane
Departamentul Resurse Umane are ca obiectiv general gestionarea și dezvoltarea resurselor
umane ale universității într -un mediu colegial bazat pe socializare, cooperare, colaborare în
care valoarea și implicarea permanentă în realizarea obiectivelor comune sunt dimensiunile
care stau la baza evoluției carierelor.
Obiectivele generale ale departamentului de resurse umane din cadrul universităților se
regăsesc în funcționalitățile acestui modul și se referă la:
Elaborarea și implementarea de sisteme echitabile de evaluare, remunerare și de
dezvoltare profesională;
Elaborarea, implementarea și monitorizarea proceselor de aplicare a politicilor de
resurse umane, recrutare și selecție, promovare și training;
Calculul și acordarea drepturilor salariale pentru întregul personal angajat al universității
Universității;
Creșterea capacității de inovare, rezolvare a problemelor, creșterea eficienț ei și
eficac ității personalului;
Managementul datelor de personal ale angajaților existenți la un moment dat în
universitate, cu acces imediat la date existente în fișiere istorice;
Elaborarea graficelor evenimentelor profesionale și urmărirea acestora;
Menținerea istoricului privind activitatea fiecărui salariat și a beneficiilor materiale
primite;
Urmărirea eficienței activității angajaților și a progreselor înregistrate de aceștia;
Dosare personale ale angajaților, cu diversitatea de caracteristici din dosarul p ersonal:
stagiu, vârstă, sex, studii, stare civilă, loc de naștere, domiciliu, cetățenie, activitate
anterioară, transferuri în cadrul instituției, etc.;
Angajări, concedieri, evaluări, grade de calificare, deplasări, sancțiuni, distincții etc..
Modulul destinat managamentului resurselor umane va oferi instrumente și soluții software
performante, prin care se va asigura eficientizarea activității de personal desfășurate în cadrul
universității.
Principiul esențial luat în considerare în demersul de informatizare al activităților de
personal este cel care se referă la necesitatea conceperii aplicaților informatice într -o manieră
57
care să permită corelarea cu celelalte module ale sistemului integrat pentru management. De
aceea, se impune constituire a unei baze de date de personal, structurată după criterii
complexe, astfel încât informațiile să poată fi folosite pentru diverse activități precum cele de
promovare, recrutare, selecție a personalului, evaluare, remunerare, dezvoltarea profesională
etc.
Modulul de management al resurselor umane asigură colectarea, administrarea,
prelucrarea și interpretarea datelor prin emiterea de liste, rapoarte text, date statistice, precum
și îmbunătățirea comunicării în cadrul universității printr -o mai bună organiz are a fluxului de
informații dintre departamentul de Resurse Umane și alte subdiviziuni. Sistemul asigură o bună
accesibilitate a datelor și reduce semnificativ timpul necesar activităților administrative pri vind
managementul personalului.
4.2.2. Gestionar ea modulului ”Resurse umane” – Microsoft Dynamics NAV
Utilizând platforma tehnologică standard de la Microsoft Dynamics NAV, modulul de
Resurse Umane este ușor de configurat și adaptat cerințelor beneficiarului. În Fig . 4.2. avem
prezentat un exemplu de pagină cuprinzând cele mai importante date cu privire la un anumit
angajat . Datele de identificare ale unui angajat sunt împărțite în 4 zone: General, Date de
contact, Administrație, Personal.
Fig. 4.2. Pagină Card – Date identificare angajat
Modulul Resurse Umane pune la dispoziție o zonă destinată angajaților, una pentru
rapoarte și una pentru parametrizare. Parametrizarea este destul de intuitivă, în sensul că
58
fiecare denumire sugerează foarte clar care sun t operațiunile care se pot face, ma i mult decât
atât unele câmpuri se completează automat (Ex. ”Oraș” și ”Codul țării”).
Aceleași date le putem vizualiza și dacă exportăm
datele în Excel, fiecare zonă fiind salvată într -o nouă foaie
de lucru.
Fig. 4.3 . Excel – Date
de contact
Fig. 4.4 . Excel – Administrație
Fig. 4.5 . Excel – General
În momentul în care facem export de date dintr -un tabel sau o pagină de tip listă din
Navision, informațiile obținute în Excel vor putea fi filtrate imediat prin specificarea condițiilor.
Fig. 4.6 . Excel – Filtrare date
Dacă data ultimei modifi cări nu mai coincide cu data ultimului export, trebuie doar să
actualizăm fișierul Excel (Excel -> Tab Dynamics NAV -> Refresh) , iar datele vor fi reînnoite .
59
Fig. 4.7 . Excel – Tab Dynamics NAV
Microsoft Dynamics NAV oferă posibilitatea partenerilor să creeze rapoarte, de la cele
simple la cele mai complexe. În primul rând trebuie gândită sursa de înregistrări a raportului.
Indiferent dacă raportul este o simplă listare de înregistrări sau o evidență grupată a
angajaților , trebuie stabilit mai întâi ce câmpuri conțin datele pe care dorim să le vedem în
raport și în ce tabele se află.
Implementarea Microsoft Dynamics NAV permite integrarea informațiilor din surse
multiple chiar dacă acestea se referă la angajați, facultate sau chiar tipuri de absențe și, prin
generarea unor rapoarte inteligente, facilitează formarea unei imagini complete asupra
activității derulate. Informațiile vitale sunt foarte ușor de obținut cu Dynamics NAV, întrucât,
imediat ce un detaliu despre un angajat este înregistrat în sist em, aceasta devine vizibil pentru
orice utilizator cu drepturi și se regăsește în rapoartele corespondente. Astfel, în urma analizei
unui raport, puteam fi siguri că decizia pe care o luăm se bazează pe cele mai noi informații
disponibile.
După rularea raportul,
înainte de a -l vizualiza, ne va
apărea fereastra din fig.4.3. în
care avem diferite opțiuni. Pentru
a deschide raportul privind
absențele unui anumit angajat , se
va selecta numele angajatului
dorit .
Fig. 4.3 Selectarea opțiunilor
60
Fig.4.8 . Raport – Cauză absență
61
Cap. 5. CONCLUZII ȘI PROPUNERI
5.1. CONCLUZII
Concluzia generală este că instituțiile de învățământ superior care vor poseda
tehnologia necesară vor putea să acopere cât mai mult din fluxurile de informație și să valorifice
cât mai eficient resursele disponibile. Utilizarea unui produs informatic performant va permite
accesul l a informații în momentele oportune, îndeplinirea obiectivelor strategice, prin
gestionarea optimă a resurselor umane, financiare și tehnice.
Implementarea unui sistem ERP are un impact major asupra oricărei organizații , ajută în
procesul de luarea a deciziilor prin furnizarea de rapoarte cu un grad foarte ridicat de acuratețe,
timp de raspuns rapid, dar și un mod de organizare relațional al datelor. Decizia finală care
sprijină implementarea unui sistem ERP este o decizie strategică.
Un sistem informa tic integrat de tip ERP ia în considerare toate necesitățile unei
universități și modul de organizare pentru a conduce la atingerea obiectivelor propuse și a uni
funcțiunile acesteia. Acesta are rolul de a gestiona informația și de a oferi intrumentele
necesare automatizării unor operațiuni care, dacă sunt efectuate manual, necesită mult timp și
pot fi afectate de erori. Prin modularitatea unui sistem ERP, fiecare aspect al activității unei
universități este tratat într -un mod specific și adecvat.
Implement area unui sistem ERP presupune operarea într -o singură bază de date
comună tuturor modulelor. Aceasta se actualizeză instantaneu de fiecare dată când informații
noi sunt introduse. Introducerea informațiilor în sistem se face o singură dată. Sistemul permi te
urmărirea evoluției oricărui raport din universitate precum și a persoanelor care lucrează și
realizează modificări în baza de date.
Scopul ERP este să asigure transparența datelor în cadrul unei universități și să ușureze
accesul la orice tip de inform ație utilă în derularea activității. Sistemul ERP asigură un nivel
avansat de securitate, drepturile sau restricțiile utilizatorilor ajungând până la nivelu l
câmpurilor din baza de date.
Soluția integrată care s-a folosit în realizarea sistemului informat ic este Microsoft
Dynamics NAV. Arhitectura deschisă a Microsoft Dynamics NAV, permite partenerilor certificaț i
Microsoft să transforme platforma tehnologică standard într-o soluție adaptată oricărui mod de
a face afaceri. Furnizor de softwar e global din sectorul de piață mijlociu oferă partenerilor locali
62
libertatea deplină necesară pentru a-și satisface nevoile specifice, având acces la tot codul sursă
pentru logica de business.
Numă rul modulelor din cadrul unui sistem informatic integrat de tip ERP poate fi foarte
mare, însă scopul actual a fost cel de a identifica modulele funcționale de bază ale sistemului
ERP, care să permită dezvoltarea u nei arhitecturi standard de bază utilizată ca fundament
pentru integrare.
5.2. PROPUNERI
Ca direcții vi itoare, se dorește analiza datelor cu Power BI. Aceast ă soluție este strâns
integrată cu Microsoft Office, utilizând instrumentele familiare Microsoft, printre care și
aplicația Excel, care permit e utilizatorilor să segmenteze volumele mari de informații ș i să ofere
o vizualizare centralizată asupra tuturor datelor relevante. În acest fel, analizele pot fi efectuate
rapid și ușor. În ceea ce privește legătura cu Dynamics NAV, soluția Power BI stabilește în câteva
minute, o conexiune prin web services , obțin ându -se apoi o multitudine de grafice și indicatori
de performanță.
Fig. 5.1 Raport realizat cu Power BI23
În Power BI, se vor putea crea tablouri de bord, rapoarte, indicatori de performanță,
grafice 3D, analize complexe de previzionare, alerte automate, analizele clasice, studii de
resurse umane, analize de randament, etc ., care să țină utilizatorii la curent cu lucrurile cele mai
importante din interiorul universității.
23 http://ecadvance.com/power -bi/ (Consultat la data 12.05.2017)
63
BIBLIOGRAFIE
[1] Cerruti C., Sistemi informativi e capacità competitiva. L'introduzione dei sistemi ERP nella
grande impresa, Editura G. Giappichelli, Torino, 1999.
[2] Chow A., Getting Started with Dynamics NAV 2013 ApplicationDevelopment, Published by
Packt Publishing Lt d.
[3] Fotache D., Hurbean L., Soluții informatice integrate pentru gestiunea afacerilor – ERP,
Editura Economică, București, 2004.
[4] Rashid M.A., Hossain, L. Patrick J.D, The Evolution of ERP Systems: A historical perspective,
Idea Group Publishing, 200 2.
[5] S. Harwood, ERP: The implementation cycle, Butterworh -Heinemann, Oxford, 2003 .
[6] T.Anderegg, ERP: A -Zimplementer`s guide for suc cess, Resource Publishing, 2000 .
[7]T.H. Dev anport, ”Putting the Enterprise into the Enterprise System”, Harvard Busi ness
Review, July -August, 1998.
[8] Valentin Măzăreanu,V. -P., Economia și managementul riscurilor, Editura Tehnopress, Iași,
2010.
[9] *** http://agilemanifesto.org/iso/ro/principles.html
[10] ***http://www.apics.org/dictionary/dictionary -information?ID=1414.0
[11] ***http://www.cio.com/research/erp/
[12]*** http://www.consultantaerp.ro/Articole_ERP/Probleme_in_implementare.html
[13] *** http://www.edu.ro/lis ta-universitatilor -din-romania
[14] *** http://ecadvance.com/power -bi/
[15]***http://www.seniorerp.ro/resurse_utile/erp -implementarea -erp-riscurile -implementarii –
erp-analiza -tipurilor -de-organizatii -motivatia -implementarii -erp/
[16] *** http://www.soft -erp.ro.html
[17] *** http://www.qnet.ro/caracteristici -solutie -microsoft -dynamics -nav
64
ANEXA 1
Project Closeout Report
Prepared for
[Customer Name]
Project
[Project Name]
Prepared by
Eduardo
Contributors
[Document contributors]
65
Revision and Signoff Sheet
Change Record
Date Author Version Change reference
Client Review
Name Version approved Position Date
66
Table of Contents
1 PROJECT CLOSE -OUT REPORT SUMMARY ………………………….. ………………………….. ………………………….. ….. 67
2 DELIVERY OF VISION ………………………….. ………………………….. ………………………….. ………………………….. ….. 68
3 CHANGE S THAT IMPACTED THE VISION ………………………….. ………………………….. ………………………….. …….. 69
CHANGES IN BUSINESS /ORGANIZATION ………………………….. ………………………….. ………………………….. ……………………… 69
CHANGES IN VISION ………………………….. ………………………….. ………………………….. ………………………….. ………………… 69
CHANGES IN TEAM ………………………….. ………………………….. ………………………….. ………………………….. …………………. 69
CHANGES IN CUSTOMER PROCESS ………………………….. ………………………….. ………………………….. ………………………….. .. 69
CHANGES IN PROJECT PROCESS ………………………….. ………………………….. ………………………….. ………………………….. …… 69
CHANGES IN PLANS ………………………….. ………………………….. ………………………….. ……….. ERROR ! BOOKMARK NOT DEFINED .
CHANGES IN SPECIFICATIONS ………………………….. ………………………….. ………………………… ERROR ! BOOKMARK NOT DEFINED .
CHANGES IN TIMELINES ………………………….. ………………………….. ………………………….. ….. ERROR ! BOOK MARK NOT DEFINED .
4 NEXT STEPS: VISION O F CONTINUING PROJECT EFFORTS, NEXT VERSION ………………………….. ………………… 70
67
1. Project Close -out Report Summary
[Description: Provide an overall summary of the contents of this document.
Justification: Some readers may need to know only the plan’s highlights, and summarizing
creates that user view. It also enables the full reader to know the essence of the document
before they examine the details.]
68
2. Delivery of Vision
[Description : The Deli very of Vision section recaps how the project delivered, nearly delivered,
or failed to deliver on the project’s initial vision. This includes a vision restatement, a strategic
assessment of what was delivered, and a brief explanation of any differences be tween the
vision and the actual deployment.
Justification : This assessment creates accountability by requiring the consulting team and
customer to revisit their original commitment and compare it to what they actually delivered.]
69
3. Changes that Impact ed the Vision
[Description : The Changes that Impacted the Vision section identifies the key events and
conditions that caused significant changes to the project and affected its ability to deliver the
original vision.
Justification : This traceability en ables the consulting team and customer to understand what
caused any alterations to the vision.]
Changes in Business/Organization
[Description : The Changes in Business/Organization section identifies and describes any changes that
may have occurred in the business or organization (merger, reorganization, economic conditions, etc)
and explains the specific impacts those changes had on the project and its ability to deliver the original
vision.]
<<Begin text here>>
Changes in Vision
[Description : The Changes in Vision section identifies any changes that were made to the vision itself.
This would include changes in business requirements, the original solution description, or the project
scope. This should also include a description of the specific impacts thos e changes had on the project
and its ability to deliver the original vision.]
<<Begin text here>>
Changes in Team
[Description : The Changes in Team section describes any changes that occurred in the team(s).
This may include either contraction or addition to teams. It may also include any alterations to
the knowledge and skills necessary to conduct the project. This section should detail what
caused any changes and how those changes impacted the project and its ability to deliver the
original vision.]
<<Beg in text here>>
Changes in Customer Process
[Description : The Changes in Customer Process section describes any changes that occurred to
processes in the customer’s environment. This could include information on business processes
that changed, which would in turn affect functional specifications. This section should detail
what caused any changes and how those changes impacted the project and its ability to deliver
the original vision.]
<<Begin text here>>
Changes in Project Process
[Description : The Change s in Project Process section describes any changes that occurred in the
processes used by the project itself. This could include changes in communication,
development, test, and management. This section should detail what caused any changes and
how those c hanges impacted the project and its ability to deliver the original vision.]
<<Begin text here>>
70
4. Next Steps: Vision of Continuing Project Efforts, Next Version
[Description: The Next Steps section provides a brief statement about the solution’s future
vision of this solution or related solutions. This could include a description of new features, how
the solution will be scaled upwards, or the application of this solution to other functions within
the customer’s environment.
Justification: This informatio n provides a starting place for developing the vision and scope for
the next project and provides continuity between the two.]
<<Begin text here>>
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Programul de studii [629271] (ID: 629271)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.