VYTAUTO DIDŢIOJO UNIVERSITETAS. Rolandas Zelionka VERSLO VALDYMO SISTEMOS PASIRINKIMAS IR DIEGIMAS. Magistro baigiamasis darbas

Transcription

1 VYTAUTO DIDŢIOJO UNIVERSITETAS INFORMATIKOS FAKULTETAS TAIKOMOSIOS INFORMATIKOS KATEDRA Rolandas Zelionka VERSLO VALDYMO SISTEMOS PASIRINKIMAS IR DIEGIMAS Magistro baigiamasis darbas Verslo informatikos studijų programa, valstybinis kodas 62609P102 Informatikos studijų kryptis Vadovas (-ė) Doc. dr. Danguolė Janickienė (Moksl. laipsnis, vardas, pavardė) (Parašas) (Data) Apginta Doc. dr. Daiva Vitkutė-Adţgauskienė (Fakultetodekanas) (Parašas) (Data) Kaunas, 2011

2 TURINYS Santrumpų ir terminų ţodynas... 3 Santrauka... 4 Abstract... 5 Įvadas... 6 Analizė... 8 VVS verslo valdymo sistema... 8 VVS moduliai... 8 VVS privalumai VVS trūkumai Kodėl verta įsidiegti VVS Verslo valdymo sistemų diegimo statistika Atvirojo kodo VVS Verslo valdymo sistemų apţvalga OpenERP (Tiny ERP) Compiere OPEN BRAVO Verslo valdymo sistemų palyginimas Verslo valdymo sistemų įdiegimo etapų apţvalga Verslo valdymo sistemų diegimo etapų palyginimas Verslo valdymo sistemų diegimo etapų sudarymas VVS įdiegimo strategijos Didelio smūgio strategija Etapinio diegimo strategija Paralelinio diegimo strategija Diegimo etapų realizavimas Išvados Literatūros šaltiniai Priedai

3 SANTRUMPŲ IR TERMINŲ ŢODYNAS GPL (GNU General Public License) - laisvosios programinės įrangos licencija. etiny TinyERP atvirojo kodo interneto klientas. KDE atvirojo kodo darbastalio aplinka ir programavimo platforma. GUI (graphical user interface) grafinė vartotojo sąsaja. Gantt diagrama diagrama, kurios pagalba iliustruojamas projekto darbo grafikas. BPM (Business process management) verslo procesų valdymas. MVC (Model view control) programinės įrangos architektūra. XML-RPC tai nuotolinių procedūrų iškvietimo (angl. RPC) protokolas, naudojantis XML koduoti savo skambučius ir HTTP, kaip transporto priemonę. OpenOffice nemokamas biuro programų paketas. GTk+ - įrankių komplektas, skirtas grafinėms vartotojo sąsajoms kurti. Fat client kompiuteris kliento- serverio architektūros tinkluose, kuris turi daug funkcionalumų nepriklausomai nuo centrinio serverio. MDA (Model-driven architecture) programinės įrangos projektavimo architektūra. ADD (Active Data Dictionary) metaduomenų saugykla. MDD (Model-driven development) programinės įrangos kūrimo metodologija. Apache interneto serveris. Dojo atviro kodo JavaScript o biblioteka. JavaScript objektinė programavimo kalba. MPL (Mozilla Public License) nemokama atviro kodo programinės įrangos licensija. FreeBSD operacinė sistema, panaši į Unix OS. MRP (Material requirements planning) produkcijos planavimo ir inventoriaus kontroliavimo sistema. POS (Point of sale) vieta, kurioje vyksta sandoriai. Tomcat (Jakarta Tomcar) atviro kodo Java klasės konteineris. Rails web aplikacijų platforma. Ruby objektinio programavimo kalba. Rack Ruby webserverio sąsaja. RubyGems Ruby programavimo kalbai skirtas paketas, skirtas diegimui valdyti. Rake Ruby programavimo kalbai skirta programa, atliekanti make funkciją 3

4 SANTRAUKA Magistro tiriamojo darbo autorius: Rolandas Zelionka Magistro tiriamojo darbo pavadinimas: Verslo valdymo sistemos pasirinkimas ir diegimas Vadovė: doc. dr. Danguolė Janickienė Darbo pristatymas: Vytauto Didţiojo Universitetas, Informatikos fakultetas, Kaunas, Puslapių skaičius: 60 Lentelių skaičius: 10 Paveiksliukų skaičius: 41 Priedų skaičius: 2 Šiandieniniais laikais įmonėms nėra lengva išsilaikyti rinkoje. Kasdien auga klientų poreikiai. Kiekvienai įmonei reikia efektyviai tvarkyti finansus, gamybą, ryšius su klientais. Tam įmonės ryţtasi diegtis verslo valdymo sistemas. Tačiau ne visos įmonės, įsidiegusios verslo valdymo sistemas, yra patenkintos gautais rezultatais. Apklausos rezultatai rodo, kad daugiau kaip pusė vadovų, įdiegusių įmonėse verslo valdymo sistemas, antrą kartą įgyvendindami tokius projektus nemenkai juos keistų, o dalis iš viso jų nevykdytų. Todėl magistriniame darbe siekiama susipaţinti su verslo valdymo sistemomis ir jų diegimu. Darbo metu apţvelgiamaverslo valdymo sistemų diegimo statistika, analizuojamos ir lyginamos verslo valdymo sistemos. Didelis dėmesys skiriamas sistemos diegimui: analizuojami galimi būdai, bei sudaromas diegimo planas, kuris yra realizuojamas. 4

5 ABSTRACT Author of master research report: Rolandas Zelionka Full title of master research report: ERP selection and implementation Supervisor: doc. dr. Danguolė Janickienė Presented at: Vytauto Magnus University, Faculty of informatic, Kaunas 2010, Number of pages: 60 Number of tables: 10 Number of pictures: 41 Number of appendices: 2 Nowadays it s not easy for a company to survive in a market. Clients needs is growing every day. Every company needs to manage their finances, manufacturing and clients relationship effectively. ERP system can help here. But not all companies are happy with their new ERP implementation results. The survey results shows, that more than a half supervisors would do a lot of changes while implementing ERP again and some would not do that anymore. In this master thesis ERP implementation statistics will be reviewed, ERP systems will be analyzed and compared. A lot of attention will be given to implementation: different implementation methods will be analyzed, implementation plan will be created and realized. 5

6 ĮVADAS Klientams tampant vis labiau reiklesniems, atsiranda poreikis atlikti darbus greičiau ir efektyviau. Augant produktyvumui auga ir poreikis sumaţinti atliekamų operacijų kaštus. Pasikartojantys verslo procesai gali būti efektyviai tvarkomi tiesiog juos automatizuojant ir taip sumaţinant naštą ţmogiškiesiems resursams, kurie tuo metu galėtų atlikti kitus darbus [1 šaltinis]. Toks automatizavimas turėtų būti atliktas visose įmonės padaliniuose. Taigi, norint tai atlikti reikia diegti verslo valdymo sistemą. Verslo valdymo sistema (VVS) tai programinė įranga, skirta įmonės valdymui kompiuterizuoti. Ją galima integruoti į visus įmonės verslo procesus. VVS naudojama apskaitos vedimo palengvinimui, efektyviam resursų išnaudojimui, kontaktų valdymui, efektyviam tiekimo grandinės veikimo uţtikrinimui, analitinės įmonės veiklos ataskaitų sudarymui. Verslo valdymo sistemos tikslas yra palengvinti informacijos apsikeitimą organizacijos viduje sujungiant atskiras sistemas į vieną[2]. Šiandien, vis labiau populiarėjant atvirojo kodo standartui, su komercinėmis verslo valdymo sistemomis konkuruoja atvirojo kodo VVS. Jos ypač naudingos nedidelėms ir didelio biudţeto neturinčioms įmonėms, kurios negali įpirkti komercinės VVS, bet siekia moderniai optimizuoti įmonės valdymą. Vis daugiau įmonių investuoja į verslo valdymo sistemas. Verslininkai supranta, kad jeigu bus modernizuotas įmonės išteklių ir veiklos valdymas, tada bus lengviau konkuruoti su Lietuvos ir uţsienio rinkoje esančiomis įmonėmis. Tačiau ne visos įmonės, įsidiegusios verslo valdymo sistemas, yra patenkintos gautais rezultatais [3]. Lietuvoje atliktos apklausos duomenimis, daugiau kaip pusė vadovų ir vadovaujančio personalo, įdiegusių įmonėse verslo valdymo sistemas, antrą kartą įgyvendindami tokius projektus nemenkai juos keistų, o dalis iš viso jų nevykdytų. Panašūs rezultatai pateikiami ir kitose Vidurio ir Rytų Europos šalyse, kur buvo atliktos tokios apklausos [3]. Kadangi verslo valdymo sistema yra ganėtinai brangi investicija, tokie apklausos rezultatai priverčia sunerimti. Keletas prieţasčių, kodėl ţlunga verslo valdymo sistemų įgyvendinimas[4]: Nesuteikiama tinkama svarba projektui. Neadekvatus darbuotojų apmokymas. Tikimasi nerealių lūkesčių. Nesuderinamumas tarp sistemos ir darbinių procedūrų. Vidinis priešinimasis įmonėje naujovėms, nenoras keisti senų procesų naujesniais. Prastas VVS pasirinkimas. 6

7 Viena svarbiausių prieţasčių yra ta, kad per maţai dėmesio yra skiriama pačiam verslo valdymo sistemos diegimo projektui suplanuoti, nustatyti ir parengti funkcinius reikalavimus. Todėl mano magistrinio darbo tikslas yra susipaţinti su verslo valdymo sistemomis, jų diegimu, iškylančiomis problemomis, sudaryti diegimo etapus bei juos realizuoti. Tikslui pasiekti keliami tokie uţdaviniai: VVS svarbos ir struktūros išsiaiškinimas. VVS trūkumų ir privalumų apţvalga. VVS diegimo apţvalga. Mokamos ir nemokamos (atviro kodo) VVS skirtumų apţvalga. Atvirojo kodo VVS tyrinėjimas ir palyginimas. Skirtingų diegimo etapų apţvalga. Diegimo strategijų apţvalga. Apţvelgtų diegimo etapų palyginimas. Diegimo etapų sudarymas. Diegimo etapų realizavimas. 7

8 ANALIZĖ Siekiant patyrinėti verslo valdymo sistemas (VVS) bei jas palyginti iš pradţių reikia apţvelgti teorinę VVS pusę ir išsiaiškinti, ką ji daro, iš ko ji yra sudaryta. Būtina suţinoti, kokius sistema turi privalumus, trūkumus. Taip pat analizuosime, kodėl verta diegti VVS. Galiausiai apţvelgsime, kuo skiriasi atvirojo kodo VVS nuo komercinių VVS. VVS verslo valdymo sistema VVS apima visus verslo aspektus įskaitant planavimą, gamybą, pardavimus ir marketingą. VVS padeda automatizuoti kompanijos verslo procesus. VVS integruoja informaciją, kurią naudoja kompanijos skirtingų funkcijų padaliniai, į vieningą kompiuterinę sistemą. Ji yra sukurta modeliuoti ir automatizuoti verslo organizacijos pagrindinius procesus nuo finansų iki gamybos valdymo su tikslu integruoti informaciją per visą kompaniją ir pašalinti sudėtingus, brangius ryšius tarp kompiuterinių sistemų. VVS moduliai Verslo valdymo sistema susideda iš atskirų modulių, kuriuos įmonė gali pasirinkti pagal konkrečius poreikius. VVS, apjungianti visus organizacijos procesus į vieną, yra sudaryta iš penkių modulių: finansinių resursų, tiekimo grandinės, ţmogiškųjų išteklių, santykių su klientais ir gamybos resursų valdymo. Finansinių išteklių valdymas Gamybos resursų planavimas Verslo valdymo sistema Tiekimo grandinės valdymas Santykių su klientais valdymas Žmogiškųjų resursų valdyms 1 pav. VVS moduliai, apjungiantys visus įmonės procesus 8

9 Finansinių išteklių valdymas. Finansinių išteklių valdymas yra kritinis įmonės sėkmės elementas. Apima biudţeto planavimą ir pinigų srautų operatyvią vadybą [5]. Sekant pajamas, sąnaudas bei kitus finansinius rodiklius įmonė gali pagrįstai priiminėti trumpalaikius ir ilgalaikius finansinius sprendimus, taip skatinant augti verslą. Taigi, finansinių išteklių valdymo tikslas yra gauti pelną iš verslo, kitaip tariant, padidinti savininkų turtą. [6] Finansinių išteklių valdymas Pinigų srautų vadyba Biudžeto planavimas Tiekimo grandinės valdymas. 2 pav. Finansinių išteklių valdymas Tiekimo grandinės valdymas apima visą tiekimo grandinės valdymą nuo ţaliavų iki galutinio pardavimo, gali kontroliuoti sandėliavimo, transportavimo, logistikos sistemas. Leidţia sumaţinti transporto ir operacines išlaidas pagerinant logistikos schemą. Sėkmingai įgyvendinta, leidţia įmonei numatyti paklausą ir pristatyti reikiamą produktą į reikiamą vietą, reikiamu laiku uţ maţiausią galimą kainą ir taip patenkinti klientus. Tiekimo grandinės valdymas Logistikos sistemos Transportavimo kontrolė Sandėliavimo kontrolė Ţmogiškųjų išteklių valdymas. 3 pav. Tiekimo grandinės valdymas Ţmogiškųjų išteklių valdymas yra strateginis ir nuoseklus poţiūris į organizacijos labiausiai vertinamus dalykus joje dirbančius ţmones, kurie individualiai ar kolektyviai prisideda 9

10 prie verslo tikslų [7]. Jis apima ţmonių samdymą, jų kompetencijos ugdymą, paslaugų, susijusių su darbu ir organizaciniais reikalavimais, panaudojimą, rėmimą ir kompensavimą [8]. Ţmogiškųjų išteklių valdymas taip pat padeda sumaţinti popieriaus sunaudojimą sumaţėja popierizmo našta administracijai. Jis siekia valdyti ţmones kaip turtą, kuris yra esminis konkurencinis organizacijos pranašumas. Taip pat siekiama sukurti lanksčią organizaciją, kuri galėtų greičiau reaguoti į greitus pasikeitimus. Žmogiškųjų išteklių valdymas Motyvacija Išlaikymas Verbavimas ir atranka Mokymas ir plėtra 4 pav. Ţmogiškųjų išteklių valdymas Šaltinis: (prof. D. S. Morris) Santykių su klientais valdymas. Ši į klientus orientuota verslo strategija sukurta optimizuoti pajamas, pelningumą bei kliento lojalumą. Ji teikia daugiausia vertės klientams integruojant jų pardavimus, marketingą ir rėmimą. Vienas pagrindinių uţdavinių yra uţtikrinti, kad kiekvienas klientas gautų aukščiausio lygio aptarnavimą ir pardavimo galimybė nebūtų prarasta [9]. Šis valdymas uţtikrina efektyvius ryšius su klientais, kaupia visą su klientu susijusių veiksmų istoriją, automatizuoja pardavimo procesą, rinkodaros kampanijas, valdo klientų nusiskundimus ir incidentus. Bendras santykių su klientais valdymo siekis yra surasti, pritraukti ir uţkariauti naujus klientus, išugdyti ir išlaikyti jau turimus klientus, susigraţinti prarastus klientus, bei sumaţinti marketingo ir aptarnavimo kaštus [10]. Santykių su klientais valdymas Pardavimai Rinkodara Paslaugos 5 pav. Santykių su klientais valdymas 10

11 Gamybos resursų planavimas. Gamybos resursų planavimas kontroliuoja visą gamybos valdymo veiklą ir susideda iš: Technikos valdymo. Paklausos valdymo. Pardavimų uţsakymų valdymo. Produkcijos planavimo ir grafiko tvarkymo. Medţiagų poreikio planavimo. Medţiagų laikymo ir gatavų prekių laikymo valdymo. Veţimo valdymo. Pirkimo valdymo. Kokybės kontrolės. Gamyklos ir įrengimų prieţiūros valdymas. Gamybos resursų planavimo sistema apima visus šiuos modulius, naudoja bendrus duomenis ir laisvai keičiasi informacija tarpusavyje. Taip padidinami gamyklos panaudojimo pajėgumai ir produkcijos apimtys. [9]. Gamybos resursų planavimas Sandėliavimas Planavimas Priežiūra Pardavimai Kokybės kontrolė Pervežimas 6 pav. Gamybos resursų planavimas VVS privalumai VVS teikiamos naudos [11 ir 12]: Pašalina suderinamumo problemą tarp kelių sistemų, nes sujungiamos finansinės, marketingo ir pardavimų, ţmogiškųjų resursų, bei gamybos operacijos. Leidţia kontroliuoti verslo procesus. Informaciją galima valdyti iš bet kurios vietos, bet kuriuo laiku. Sumaţina duomenų praradimo riziką, nes leidimai ir saugumo modeliai yra vienoje struktūroje. Sutrumpėja produkcijos pristatymo laikas. 11

12 Pašalinami nereikalingi duomenys ir procedūrinės operacijos, taip greičiau atliekami darbai. Padidėja efektyvumas, taip sumaţėja bendrovės išlaidos. Uţtikrina greitesnį informacijos apdorojimą ir sumaţina dokumentų tvarkymo naštą. VVS trūkumai VVS trūkumai [11 ir 12]: VVS programinės įrangos pritaikymas yra ribotas. Verslo procesų pritaikymas, kad jie atitiktų standartus, kurių reikalauja VVS, gali privesti įmonę prie konkurencinio pranašumo praradimo. VVS gali būti labai brangi. VVS daţnai per sunku pritaikyti specifininiams verslo procesams kai kuriose kompanijose. Labai didţiulės sukurtos sistemos keitimo išlaidos. Labai brangu maţoms įmonėms. Didelė organizacija gali turėti daug atskirų padalinių su savarankiškais resursais, uţdaviniais ir panašiai, todėl sujungimas į vieną sistemą gali duoti maţai naudos. Kodėl verta įsidiegti VVS. Ugnė Kontarė, UAB "Sonex sistemos" Marketingo vadovė, išskyria penkias prieţastis, dėl kurių įmonės diegiasi VVS[13]: Norėdamos integruoti finansinę informaciją, pvz., finansų skyrius turi savo pajamų skaičiavimo būdus, pardavimų skyrius kitą versiją. Kiekvienas skyrius gali turėti savo versiją to, kiek jie prisidėjo prie pajamų uţdirbimo. VVS sukuria vieningą nediskutuotiną versiją, kadangi kiekvienas skyrius naudoja tą pačią sistemą. Norėdamos integruoti klientų uţsakymų informaciją. VV sistemoje klientų uţsakymai gali būti nuo to momento, kai juos gauna klientų aptarnavimo skyriaus darbuotojas iki tol, kol prekė iškraunama, o finansų skyrius išrašo sąskaitą. Turėdama šią informaciją vienoje sistemoje, o ne keliose skirtingose, negalinčiose komunikuoti tarpusavyje, kompanijos gali lengviau sekti uţsakymo eigą bei koordinuoti gamybą, atsargas bei transportavimą daugelyje skirtingų vietų tuo pačiu metu. Norėdamos standartizuoti ir pagreitinti gamybinius procesus. Gamybinės įmonės ypatingai tos, kurios jungiasi arba įsigyja kitas įmones daţnai pamato, kad įvairūs 12

13 verslo vienetai įmonėje daro tuos pačius dalykus, naudodami skirtingus metodus ir kompiuterines sistemas. VVS turi standartizuotus metodus, kurie padeda automatizuoti tam tikrus gamybos ţingsnius. Taigi, šių procesų standartizavimas ir integruotos bei vieningos kompiuterinės sistemos naudojimas gali sutaupyti laiko, padidinti darbo našumą bei sumaţinti kaštus. Norėdamos sumaţinti atsargas. VVS padeda geriau valdyti gamybos procesą ir padidina uţsakymų įvykdymo proceso aiškumą. Tai gali sąlygoti atsargų kiekio maţėjimą, prekę gaminančių darbuotojų skaičiaus maţėjimą bei padėti darbuotojams geriau planuoti pristatymus klientams, taip sumaţinant pagamintų prekių atsargas sandėliuose bei pakrovimo vietose. Norėdamos standartizuoti personalo informaciją. Personalo skyrius kompanijoje, ypač turinčioje daug verslo vienetų, gali neturėti vieningo, paprasto metodo darbuotojų darbo laikui fiksuoti ar komunikacijai apie įmonės teikiamas naudas bei paslaugas perteikti. VVS gali padėti tai sutvarkyti. Anot MG Baltic, sėkmingai verslo valdymo sistemą įdiegusi įmonė gali tikėtis naudos šiose srityse[14]: sumaţinti personalo bei informacinių technologijų sąnaudas. pasiekti, kad klientai ir partneriai būtų labiau patenkinti įmonės paslaugomis. tiksliau analizuoti turimus duomenis. MG Baltic teigia, kad apklausus VVS sėkmingai įsidiegusias įmones išaiškėjo, jog jose informacinių technologijų sąnaudos sumaţėjo 46%, personalo sąnaudos - 56%, bendradarbiavimas su klientais bei partneriais pagerėjo 19%. 75% apklaustųjų pasakė, kad jų verslo sprendimai pasidarė efektyvesni dėl kokybiškiau analizuojamų verslo procesų ir greičiau randamų problemų[14]. Valerijus Budiakas, UAB Teraneta, priklausiančios Sonex grupei, pardavimo vadovas teigia, kad sistema leidţia išvengti brangiausiai kainuojančių klaidų. Pavyzdţiui, kartais suveikia ţmogiškasis veiksnys ir iš kliento priimama netiksli informacija. Tuomet uţsakovą pasiekia arba ne tos prekės, arba ne tas kiekis, supainiojami pristatymo terminai. VVS tokių klaidų leidţia išvengti. [14] Marijus Strončikas, "MG Baltic" atstovas, sako, kad subalansuota tiekimo grandinė sumaţino tokių atvejų kiekį, kuomet nėra uţsakomų produktų tada, kai jų reikia. 40% sumaţėjo investicijos į atsargas. Taip pat priduriama, kad sumaţėjo sandėliavimo problema, jų paprasčiausiai buvo atsisakyta, nes perpus sutrumpėjo klientų aptarnavimo ciklas. "Prekių pristatymo klientams 13

14 kelionės maršrutų ir automobilių parko pertvarka 20% sumaţino transporto išlaidas" teigė M. Strončikas[14]. Gintas Migonis teigia, kad naudojant VVS nereikia dukart įvedinėti tų pačių pirminių duomenų. "Tarkime, sandėlio ir buhalterijos apskaitai naudojami tie patys duomenys. Be VVS jie įvedami du kartus. Įdiegus verslo valdymo sistemą, pakanka vieną kartą suvesti pirminę informaciją. Tad maţiau darbo lieka buhalteriams", duoda pavyzdį G. Migonis [14]. Verslo valdymo sistemų diegimo statistika Siekiant geriau suprasti diegimo etapų svarbą panagrinėkime VVS diegimo statistiką. Bus apţvelgtos VVS diegimo prieţastys, daromi pakeitimai, diegimo trukmė, biudţetas. Taip pat bus apţvelgti gaunami rezultatai: kiek realizuota nustatytų privalumų ir koks yra pasitenkinimo lygis. Nagrinėjama bus naudojantis Panorama konsultantų grupės apklausos duomenimis, apimančiais apie 1600 įmonių, per pastaruosius ketverius metus įsidiegusių VVS. VVS Diegimo prieţastys 11% 6% 4% 26% Pagerinti verslo efektyvumą Geriau integruoti sistemas Pakeisti seną VVS 13% 18% 22% Standartizuoti verslo operacijas Palengvinti darbuotojų darbą Sumažinti darbinį kapitalą Nes kitos kompanijos turi VVS 7 pav. VVS Diegimo prieţastys Šaltinis: 2010 ERP report organizational change management Aukščiau esančiame 7-tame paveikslėlyje išskiriamos septynios prieţastys, kodėl įmonės diegiasi VVS. Daţniausiai nurodoma prieţastis yra siekis pagerinti verslo efektyvumą. Pagerinus efektyvumą, savaime pagerėja ir darbuotojų kasdieniniai darbai. Taigi, taip pasiekiama dviguba nauda. Kita daţniausiai sutinkama prieţastis yra geriau integruoti sistemas. Tai būdinga daţniausiai didelėms įmonėms, siekiant optimizuoti valdymą tarp skirtingų padalinių. Trečia daţniausiai sutinkama prieţastis senos VVS sistemos pakeitimas nauja. Tai leidţia įmonėms didinti konkurencingumą, lengviau konkuruoti su kitomis įmonėmis [15]. 14

15 Verslo procesų (VP) keitimas Pakeitė VP kad atitikti VVS funkcionalumus Pakeitė, modifikavo VVS funkcionalumus, kad atitiktų esamus VP Pakeitė VP nepriklausomai nuo VVS, tada pasirinko ar konfigūravo įrangą kad atitiktų naujus procesus Pakeitė labai nedaug arba nekeitė VP 9% 22% 42% 27% 8 pav. Verslo procesų (VP) keitimas Šaltinis: 2010 ERP report organizational change management 8 paveikslėlyje pavaizduotas įmonės verslo procesų pritaikymas naujai VVS. Šis aspektas yra labai svarbus, kadangi nuo jo priklauso kaip efektyviai dirbs nauja VVS, kiek ilgiau truks projekto įgyvendinimas, kiek reikės papildomų kaštų. Nors yra rekomenduojama VVS pritaikyti prie įmonės verslo procesų, o ne atvirkščiai, net 42% įmonių keičia savo verslo procesus, kad atitikti VVS funkcionalumus. Tokios įmonės atlieka daug pakeitimų, keičiasi būdas, kaip jie vykdo verslą. Tai įtakoja ir įmonės darbuotojus, kurie turi mokytis. Įmonių, kurios modifikuoja VVS, kad atitiktų esamus verslo procesus, yra ţenkliai maţiau(27%). Tai reikalauja nemaţo kiekio pakeitimų naujoje sistemoje ir gero verslo procesų supratimo. Šis uţdavinys yra itin nelengvas labai didelėse įmonėse, kadangi reikia gerai perprasti, kaip dirba atskiri skyriai bei kaip jie veikia. 1 lentelė. Diegimo trukmė Sritys Diegimo trukmė mėnesiais Gamyba ir paskirstymas 19.2 Turizmas ir pramogos 21.7 Didelės įmonių grupės 25.2 Šaltinis: 2009 ERP report Aerospace and Airlines industry 15

16 Įmonės dydis yra pagrindinis veiksnys, įtakojantis įdiegimo kainą ir trukmę. Nustatyta, kad turizmo ir pramogų srityse VVS įdiegimas vidutiniškai trunka 22, gamyboje ir paskirstyme 19, o kitose apie 20 mėnesių. Į trukmę įeina ir 4-5 mėnesius trunkantis VVS įvertinimas, pasirinkimas ir diegimo planavimas[16]. Pagal Panorama konsultantų grupės studijas nustatyta, kad virš 55% turizmo ir pramogų VVS projektų viršija planuotą įgyvendinimo trukmę 5% ir 57% visų VVS projektų viršija planuotą biudţetą 5%. Planuota įgyvendinimo trukmė Trumpesnė nei tikėtasi Ilgesnė nei tikėtasi Tokia kokios tikėtasi 43% 22% 36% 9 pav. Planuota įgyvendinimo trukmė Šaltinis: 2010 ERP report ERP vendor analysis Iš įmonių planuotos VVS įgyvendinimo trukmės matyti, kad nemaţai įmonių (36%) turi nerealius lūkesčius. Diegimo procesas susideda iš daugybės ţingsnių: projektavimo, reikalavimų sudarymo, konfigūravimo, testavimo, darbuotojų apmokymo ir pan. Kadangi kiekvienas ţingsnis uţtrunka nemaţai laiko, todėl būtina realiai ir kuo tiksliau įvertinti jų trukmę. Blogai nuprognozavus keičiasi bendra projekto įgyvendinimo trukmė. Apie pusė įmonių (43%) teisingai apskaičiuoja projekto trukmę ir penktadaliui (21%) įmonių įgyvendinimas uţtrunka per trumpesnį nei tikėtasi laiką[17]. 16

17 Įmonių kiekis % Biudţeto planavimas Pagal planą Viršytas Neviršytas 9% 40% 51% 10 pav. Planuotas Biudţetas Šaltinis: 2010 ERP report ERP vendor analysis Biudţetas pagrindinis veiksnys, kuris riboja galimybes. Skirtumas tarp planuotų ir gautų išlaidų yra didelė problema įmonėms, kadangi pusė įmonių (51,4%) anot Panorama konsultantų grupės išleido daugiau pinigų nei buvo planuota, 40% tiek, kiek planavo ir 8,6% neviršijo savo biudţeto. Įmonių realizuoti privalumai 30% 25% 20% 15% 10% 62% 38% Realizuoja >50% 5% 0% Nerealizuoja >50% Realizuotų privalumų kiekis % 11 pav. Įmonių realizuoti privalumai procentais Šaltinis: 2010 ERP report ERP vendor analysis 17

18 Iš paveikslėlio galime pastebėti, kad dauguma įmonių (virš 60%) realizuoja maţiau nei pusę privalumų, kurių siekia. Net 55% įmonių realizuoja vos iki 30% privalumų. Daugiau nei pusę privalumų realizuoja apie 40% įmonių, o visus privalumus - 5%. Pasitenkinimo lygis Labai patenkinti 18.90% Patenkinti 3.50% Dalinai patenkinti 49.80% Neutralūs 4.60% Dalinai nepatenkinti 15.40% Nepatenkinti Labai nepatenkinti 1.20% 6.60% 12 pav. Įmonių pasitenkinimo VVS lygis Šaltinis: 2010 ERP report ERP vendor analysis Iš paveikslėlio galima pastebėti, kad beveik pusė įmonių yra ganėtinai patenkinti savo nauja VVS. Antras pagal aukštumą rodiklis yra labai patenkinti. Taigi, virš 70% įmonių yra daugiau ar maţiau patenkintos savo VVS. O tai yra ganėtinai nemaţas rodiklis. Tačiau vien juo vadovautis negalima, kadangi jis gali būti klaidinantis. Vadovai gali būti patenkinti tiesiog kad baigė projektą, sumaţino riziką ar pan. VVS vartotojai aukštą pasitenkinimo lygį pasiekia kai pradeda naudotis paţangesniais veiklos procesais bei geresniu funkcionalumu[18]. Įmonių, toliau tobulinančių verslo procesus po projekto įgyvendinimo % Įmonių, susidūrusių su problemomis iškart po projekto įgyvendinimo % Įgyvendinimo rezultatai Įgyvendinimo rezultatai Įmonių, sumaţinusių darbuotojų skaičių dėl padidėjusio produktyvumo % 18 Darbuotojų, patenkintų nauja VVS % 73% 53% 56% 68% 72% Šaltinis: 2010 ERP report organizational change management Įmonės vadovų, patenkintų rezultatais % 2 lentelė 2 lentelėje apibendrinti daţniausiai gaunami rezultatai po projekto įgyvendinimo. Derėtų pastebėti, kad kuo greičiau darbuotojai pripranta prie naujos sistemos, tuo greičiau realizuojami privalumai verslo procesuose. Iš lentelės matyti, kad virs 70% įmonių tęsia verslo procesų tobulinimą. Pusė įmonių susiduria su problemomis iškart po projekto įgyvendinimo sistemai

19 pradėjus veikti. Iš šių dviejų rodiklių galima spręsti, kad daugiau kaip pusė įmonių nesugeba greitai prisitaikyti prie naujos sistemos. Įdiegus VVS virš 50% įmonių atsisakė tam tikro darbuotojų skaičiaus dėl padidėjusio produktyvumo. 68% darbuotojų ir 72% vadovų buvo bent šiek tiek patenkinti naujos VVS projektu. Taigi, kaip matome iš statistikos, įmonės susiduria su trimis pagrindinėmis problemomis: Diegimo baigimą laiku. Diegimo baigimą neviršijant biudţeto. Privalumų realizavimą. Projektai uţtrunka ilgiau nei planuota, todėl daţnai viršijamas ir jo biudţetas.įgyvendinimo trukmę įtakoja ir keliami nerealūs lūkesčiai. Daţnai reikia daugiau laiko jų įgyvendinimui nei būna planuota. Taip pat yra sudėtinga numatyti darbus, tiesiogiai nesusijusius su programine įranga (veiklos procesų apibrėţimas, sprendimo prototipų įvertinimas, sprendimų priėmimas, organizacinių pokyčių įgyvendinimas). Projektui neretai skiriama nepakankamai resursų: nenumatomi tam tikri vaidmenys komandoje, tuomet į ją skiriami netinkami asmenys, kurie neturi gerų ţinių ir panašiai[19]. Dar vienas veiksnys, įtakojantis biudţetą ir laiko trukmę yra sistemos modifikavimas. Pasitaiko, kad įmonė ketina naudotis standartinėmis sistemos galimybėmis, bet pradėjus vykdyti projektą vistik nutaria sistemą modifikuoti. Sistemos modifikavimas iš esmės nėra blogas dalykas, kadangi jų dėka sistema gali duoti nemaţai naudos ir taip greičiau atsipirkti. Bet per didelis modifikacijų kiekis smarkiai padidina diegimo kaštus, riziką bei trukmę[19]. Atvirojo kodo VVS Paskutiniame dešimtmetyje verslo valdymo sistemos sulaukė didelio susidomėjimo. Vis labiau populiarėjant atvirąjam kodui, susidomėjimo taip pat sulaukė ir atvirojo kodo verslo valdymo sistemos[20]. Jos remiasi bendruomenės, o ne vienos įmonės investicija. Taip vienai programai sutelkiama daugiau investicijų. Atvirojo kodo VVS būdingas lankstumas, patogumas naudotis, greitas augimas, o funkcionalumu daţniausiai neatsiliekama nuo komercinių programų.[21] Rita Petruţytė, VVS konsultantė, teigia, kad į komercinės VVS kaštus įeina licencijos mokesčiai, diegimas, apmokymai, programos priderinimas prie įmonės darbo procesų ir palaikymas. Nustatyta, kad licencijos mokestis sudaro maţdaug trečdalį visų programos diegimo kaštų. Siūlant atvirojo kodo verslo valdymo sistemas, klientams leidţiama sutaupyti, o diegiančios įmonės uţdirba iš palaikymo, mokymų, ar naujo funkcionalumo kūrimo [21]. 19

20 Apţvelkime skirtumus tarp atvirojo kodo ir komercinių VVS. Kaina Komercinis VVS paketas yra brangus ir daţniausiai įkandamas tik didesnėms kompanijoms. Tokie paketai nėra lankstūs ir daţnai sukelia problemų kai yra modifikuojami. Juose taip pat egzistuoja ir daug paslėptų kainų. Didţiausias atvirojo kodo VVS privalumas yra tai, kad ji yra nemokama. Kartu su programos kodu (angl. source code ) yra prieinama ir licencija. Tai uţtikrina, kad mokymosi tvarka yra paprasta.[22] Lankstumas Šios svarbios savybės yra pasigendama komercinėse verslo valdymo sistemose, kadangi yra sudėtinga jas pritaikyti. Atvirojo kodo verslo valdymo sitemose pati kompanija gali atlikti būtinus kodo pakeitimus su maţa pardavėjo pagalba. Taip pat atviro kodo VVS nesutrikdo reguliaraus kompanijos grafiko vykdant įgyvendinimo stadiją. [22] Trukmė, priklausomybė, rezultatai Laikas, skirtas atvirojo kodo VVS įgyvendinimui, yra ţymiai trumpesnis lyginant su komercine VVS. Dėl didelio komercinės VVS sudėtingumo, jos uţtrunka daug laiko ir kiekviename VVS stadijos procese. Kadangi atviras kodas yra savarankiškai kuriamas procesas, įmonės yra maţiau priklausomos nuo pardavėjų ir pačios rūpinasi poreikiais. Atviro kodo VVS produktyvumas yra aukštas ir gedimo rodiklis yra labai ţemas. [22] Apmokymai Komercinės VVS naudojimas reikalauja nemaţai apmokymų. O tai reiškia nemaţas investicijas laiko ir pinigų prasme. Atvirojo kodo VVS atvirkščiai, nereikia didelių apmokymų, kadangi vartotojai mokosi patys analizuodami kodą. Dėl šios prieţasties rezultatai automatiškai yra efektyvūs, taip pat sumaţėja priklausomybė nuo pardavėjo. [22] Saugumas Atvirojo kodo VVS yra saugesnės lygynant su komercinėmis. Pastarosios linkusios pakliūti į spąstus, nepaisant to, kaip grieţtai yra atskirti komponentai. Atviro kodo verslo valdymo sistemose viskas yra vieša, visiem matoma ir prieinama, todėl vartotojai yra perspėjami kai kaţkas blogo nutinka. [22] 20

21 VERSLO VALDYMO SISTEMŲ APŢVALGA Yra sukurta nemaţai atvirojo kodo verslo valdymo sistemų. Šiame darbe aš pasirinkau nagrinėti tris atvirojo kodo verslo valdymo sistemas: Compiere, OpenBravo ir OpenERP. Compiere pasirinkau dėl jos populiarumo 1 (1 lentelė). OpenBravo taip pat yra populiari VVS, sukurta remiantis kitais atvirojo kodo projektais (tame tarpe ir Compiere ). Trečioji VVS yra OpenERP, kuri yra gerai ţinoma ir atitinka Lietuvos buhalterinės apskaitos standartus ir mokesčių sistemą[21]. 3 lentelė Atvirojo kodo VVS atsisiuntimų duomenys Atsisiuntimai Atsisiųsta per metus Projekto pradţia Compiere OpenBravo OpenERP Šaltinis: Open Source Ecosystems: Diverse Communities Interacting [20] Tyrinėjant sistemas bus atsiţvelgiama į šiuos kriterijus: Kokius sistema turi modulius. Kaip sistema konfigūruojama. Koks yra sistemos pritaikymas prie įvairių kalbų. Ar sistema yra draugiška vartotojui. Kokia yra sistemos architektūra. Ar geras sistemos pritaikomumas. Koks sistemos saugumas. Kokias sistema turi sąsajas su kitomis programomis. Operacinės Sistemos nepriklausomumas. Duomenų bazės nepriklausomumas. Programavimo kalba. Dokumentacija. 1 Populiarumas matuotas pagal tai, kiek kartų yra parsisiųsta programinė įranga. Remtasi puslapio duomenimis. 21

22 OpenERP (Tiny ERP) OpenERP (senas pavadinimas Tiny ERP (iki )) tai atvirojo kodo verslo valdymo sistema, sukurta GPL licencijos pagrindu ir atitinkanti Lietuvos buhalterinės apskaitos standartus ir mokesčių sistemą. Ji integruoja visus verslo procesus: finansų valdymą, pardavimus ir pirkimus, santykių su klientais valdymą, sandėlio ir atsargų apskaitą, gamybą, projektų valdymą, verslo įţvalgas (angl. Business Intelligence) bei kitus įmonės procesus. [21][23] OpenERP yra atskirti kliento ir serverio komponentai. Sistema veikia Microsoft Windows, Linux, Mac OS X operacinėse sistemose. Be to, vartotojai gali naudotis interneto sąsaja (etiny, naudojantis Turbogeats interneto sistema). Taip pat yra ir KDE vartotojo sąsaja, Gantt o diagramos, integruotas BPM vaizdas. [24] OpenERP yra pagrįsta stipria MVC architektūra. Turi objektinę duomenų bazę, dinamišką GUI, XML-RPC sąsają ir pritaikomą ataskaitų sistemą su integruotu OpenOffice [24]. Ji yra išversta į daugiau nei 18 kalbų ir turi pasaulinį partnerių ir kūrėjų tinklą. Daugiau nei 800 kūrėjų dalyvauja Tiny Forge bendros sistemos kūrimo projektuose. Stebina ir OpenERP programinės įrangos dydis, įdiegus uţimantis maţiau nei 4 Mb [25]. OpenERP yra paremta modulių sistema, kurių sukurta yra šimtai. Moduliai gali būti integruojami priklausomai nuo poreikių. Keletas galimų modulių [26]: Apskaita ir finansai Pirkimai Ţmogiškieji resursai Gamyba Atsargų valdymas Pardavimai ir marketingas Bei daugybė kitų... Dėl gausybės modulių OpenERP galima pritaikyti įvairiose pramonės ir paslaugų srityse dirbančioms įmonėms. OpenERP vartotojo sąsaja yra patogi bei gerai sukurta. Yra didelė diagramų ir grafikų galimybė. Sistema yra orientuota į labai maţas, nedideles ir vidutinio dydţio įmones, turinčias iki 150 darbuotojų. 22

23 OpenERP OpenERPapţvalga 4 lentelė # Kriterijai Apibūdinimas 1 Konfigūravimas XML 2 Internacionalizacija Daugiau nei 18 kalbų 3 Draugiškumas Geras vartotojui 4 Architektūra 3-eilės, su GUI klientu. MVC 5 Pritaikomumas Geras, apribotas PostgreSQL duombaze 6 Saugumas Rolių, grupių, vartotojų 7 Sąsajos Serveris: XML-RPC, e-commerce Klientas: Excel, CSV, PDF, Open Office 8 OS nepriklausomumas Serveris: Linux, Windows Klientas: Linux, Windows, Mac OS X 9 DB nepriklausomumas PostgreSQL 10 Programavimo kalba Python 11 lock-in efektai Nėra 12 Dokumentacija Gamintojo dokumentacija, forumas Konfigūravimas Šaltinis:Thomas Herzog A Comparison of Open Source ERP Systems Formų, ataskaitų ir darbo eigos kūrimas nereikalauja programavimo įgūdţių. Formos ir darbo eiga konfiguruojama su XML failais. Pati VVS konfiguruojama administratoriaus terpėje. Naujiems moduliams kurti yra padaryta mokymų medţiaga. Kodas yra labai kompaktiškas ir turi didelę atmintį. Taip pat yra forumas, kuriame galima diskutuoti įvairiais rūpimais klausimais bei gauti naudingų patarimų.[27] Internacionalizacija Kalbų vertimas daugiausia tenka serveriui ir tik maţa vertimo dalis būna kliento pusėje. Serverio pusėje galimas vertimas yra ispanų, vengrų, prancūzų, vokiečių, rumunų, italų, portugalų, kiniečių, čekų, albanų, olandų, švedų ir kitomis kalbomis. Iš kliento pusės tik paleidţiamas vertimo mechanizmas.[27] Architektūra OpenERP architektūra sudaryta iš trijų komponentų [28] : PostgreSQL duomenų bazės serverio. Jame laikomos visos duombazės, kuriose laikomi visi duomenys ir dauguma OpenERP sistemos konfiguracijos elementų. OpenERP serverio. Jame yra visa logika. Jis uţtikrina kad OpenERP dirbtų optimaliai. Interneto serverio. Jis leidţia prisijungti prie sistemos iš naršyklės, bet nėra reikalingas, jei jungiamasi naudojantis GTK klientu. 23

24 serveriuose. Visi trys aukščiau pamynėti komponentai gali būti įdiegti tame pačiame arba skirtinguose 13 pav. Open ERP architektūra Šaltinis: Saugumas OpenERP saugumą sudaro trys dalys: [29] Vartotojai identifikuojami pagal prisijungimo vardą ir slaptaţodį, gali priklausyti kelioms grupėms bei turėti keletą vaidmenų. Grupės apibrėţiamos priėjimo teisės (rašymo, skaitymo ir vykdymo). Rolės nustatomos pareigos vartotojams, nusakoma hierarchinė medţio struktūra. Dokumentacija Oficialiame jų puslapyje galima rasti plačią dokumentaciją. Ji susideda iš tokių skilčių kaip funkcinė apţvalga, įdiegimo vadovas, verslo įţvalga, modulių kūrimas ir kitų. Taip pat yra ir diskusijoms skirtas forumas. 24

25 Compiere Compiere Atvirojo kodo verslo valdymo sistema, pagrįsta MPL licencija, skirta maţoms bei vidutinio dydţio įmonėms, paskirstymui, maţmeniniams pardavimams, paslaugoms ir gamybai valdyti. Compiere buvo įsteigta 1999 metais, kompanijos programinė įranga buvo parsisiųsta daugiau nei 1.8 milijoną kartų. Kompanija teikia paslaugas daugiau nei 40-tyje šalių.[30][31] 2009 metais InfoWorld išrinko Compiere viena geriausių atviro kodo VVS. InfoWorld ataskaitoje teigiama, kad Compiere suteikia gerą VVS paketą su pagrindiniu ryšių su klientais valdymo funkcionalumu ir lengvu konfiguravimu nereikalaujant programavimo. [32] Compiere VVS sukurta JAVA EE programavimo kalba bei naudoja MDA architektūrą. Klientai bet kuriuo metu gali keisti informacijos struktūrą, ją pritaikant naujiems poreikiams. Sistema leidţia daugybę verslo informacijos perţiūrių priklausomai nuo tuo metu perţiūrimos operacijos detalių.[31] Compiere yra pagrįsta ADD koncepcija. Sistemos duomenų ţodynas (angl. data dictionary) saugo informaciją apie duomenis (pvz. tipas), informaciją kaip jie turi būti atvaizduoti bei atvaizdavimo taisykles. Kartu saugomos saugumo bei priėjimo (angl. access) taisyklės.[31] Compiere palaiko tokius modulius ir galimybes:[33] Standartinė ataskaita. Verslo perţiūros sluoknis saugus priėjimas prie verslo duomenų per optimizuotas ataskaitų schemas. Analizės įrankiai galimybė panaudoti savo ataskaitų ir analizės įrankius Compiere duomenims analizuoti. Gamyba gamybos proceso kontroliavimas. Sandėlio valdymas. Pirkimas pirkimo ţingsnių automatizavimas. Medţiagų valdymas. Uţsakymų valdymas. Globalus finansų valdymas verslo sprendimų automatizavimas ir finansinių dokumentų valdymas. Pardavimai Ryšių su klientais valdymas. E-Komercija internetinės parduotuvės sukūrimas ir paleidimas. Paslaugos Visų paslaugų pristatymo ciklo valdymas. Kliento istorija visų veiksmų su klientais matymas. Compiere šiuo metu naudojama įvairiose pramonės šakose, tokiose kaip paskirstymas, finansinės paslaugos, sveikatos prieţiūra, gamyba, leidyba, maţmeninis pardavimas. Yra siūlomos 25

26 keturios sistemos versijos: Enterprise Edition, Profferional Edition, Standard Edition ir Community Edition.[34] Compiere Compiereapţvalga # Kriterijai Apibūdinimas 1 Konfigūravimas Metaduomenys 2 Internacionalizacija Daugiau nei 20 kalbų 3 Draugiškumas fat klientas. Nelankstus, nepatogus atvaizdavimas vartotojui 4 Architektūra antros ir trečios eilės architektūrų fat kliento mišinys, MDA, ADD 5 Pritaikomumas Geras, daugiausia priklauso nuo duombazės. 6 Saugumas Rolių, duomenų, audito 7 Sąsajos CSV, PDF 8 OS nepriklausomumas Windows, Linux/Unix, Mac OS X 9 DB nepriklausomumas Oracle, EnterpriseDB 10 Programavimo kalba Java 11 lock-in efektai PDF, migracijos įrankis, Oracle duomenų bazė 12 Dokumentacija Wiki, forumai Konfigūravimas Šaltinis: Thomas Herzog A Comparison of Open Source ERP Systems 5 lentelė Compiere leidţia metaduomenimis pagrįstus konfigūravimus, kuriuos galima atlikti neišjungiant sistemos. Metaduomenys laikomi duomenų bazės lentelėse, pavadintose Application Dictionary ir gali būti modifikuojami su klientu, turint administratoriaus teises. [35] Internacionalizacija Grafinė vartotojo sąsaja bei ataskaitos yra išverstos į anglų, kinų, vokiečių, ispanų, prancūzų, italų ir olandų kalbas. Vertimas atliktas pačios Compiere kompanijos. Internete taip pat galima rasti ir vertimų kitomis kalbomis. Apskaitos schemos prieinamos anglų, ispanų, italų ir vokiečių kalbomis. [35] 26

27 Architektūra 14 pav. Compiere architektūra Šaltinis: Compiere naudoja antros ir trečios eilės architektūrų kliento mišinį. Yra trys lygiai [36]: Kliento. Jame yra padaroma internetinė sąsaja. Aplikacijų serverio. Jame apibrėţiame verslo logika ir operacijų eiga, kuri išskaidoma į tris sluoksnius: pateikimo (angl. presentation), verslo logikos ir duomenų. Duomenų bazės. Apskaitos varikliukas yra Application serveryje. Internetiniai klientai naudojami internetinei parduotuvei bei santykių su klientais valdymo funkcionalumui. [35] Sąsajos Yra galimybė siųsti elektroninius laiškus bei prie jų prisegti dokumentus. CSV duomenų eksportavimas ir importavimas vykdomas komerciniu migracijos įrankiu. Sąsajas galima kurti Java programavimo kalba, tam specialiai yra padarytos dokumentacijos. [35] Saugumas [37] Compiere turi trijų lygių apsaugos sistemą, susidedančią iš: Rolėmis pagrįstos apsaugos. Duomenų apsaugos. Audito. Kiekvienas vartotojas turi po vieną profilį, kuris yra susietas su viena ar keliomis rolėmis, apibrėţiančiomis, kurie duomenys ir funkcijos yra galimi. Rolės gali būti nustatytos bendros visiem, arba tik konkrečiam daliniui ir panašiai. 27

28 Duomenų apsauga naudoja rolėmis pagrįstą informaciją, kuri neleidţia prieiti prie tam tikrų duomenų. Pvz. uţdrausti vartotojui, dirbančiam su pardavimais, perţiūrėti duomenis ne darbe, arba uţdrausti keisti kainas ir panašiai. Audito galimybė leidţia tikrinti bet kokią operaciją sistemoje, įskaitant ir pakeitimus metaduomenyse. DB nepriklausomumas Kaip teigia kompanija, jų programinė įranga veikia su Oracle duomenų baze (Express, Standard, Standard One ir Enterprise versijomis), EnterpriseDB Postgres Plus Advanced Serveriu[38]. Taigi, vartotojas gali rinktis, ar naudoti mokamą Oracle duomenų bazę, ar rinktis nemokamą alternatyvą - EnterpriseDB. Dokumentacija Compiere wiki puslapyje pateikta vaizdi dokumentacija. Galima rasti administratoriaus, vartotojo bei techninį gidą kuriuose viskas vaizdţiai atvaizduojama ir paaiškinama. OPEN BRAVO OpenBravo - Atvirojo kodo verslo valdymo sistema, pagrįsta MPL licencija. Ši VVS orientuota į maţas bei vidutinio dydţio įmones ir yra skirta naudotis internetinėje terpėje. OpenBravo modelis buvo sukurtas kaip alternatyva Compiere 2006 metais, paimant jos privalumus. Taip pat buvo remtasi ir kitais atvirojo kodo projektais tai Apache ir Dojo.[39] OpenBravo buvo nominuotas ispanų ţurnale, Capital in the Innovation kategorijoje. Sistema buvo pripaţinta tokių kompanijų kaip Volkswagen, Acciona ir CINFA[26] metais InfoWorld išrinko OpenBravo geriausia atviro kodo VVS kartu su Compiere. Sistema buvo giriama dėl jos funkcionalumų nemokamoje versijoje lyginant su Compiere.[32] OpenBravo siūlo šiuos modulius ir galimybes [40]: Duomenų valdymas Viešųjų pirkimų valdymas Sandėlio valdymas Projektų ir paslaugų valdymas Gamybos valdymas Pardavimų ir santykių su klientais valdymas Finansų valdymas Verslo įţvalga OpenBravo siūlo platų spektrą funkcionalumų vartotojams. Tai erdvinės ataskaitos, perspėjimo signalai, elektroninis paštas, navigacija naudojantis klaviatūra. Visa tai yra lengva 28

29 konfigūruoti, o norint pridėti funkcionalumų nebūtina programuoti. Tiesiai iš sistemos galima eksportuoti vieną ar grupę failų į Excel į, CSV ar PDF ą. Vartotojai gali įdieginėti savo modulius bei įskiepus. OpenBravo sistema gali būti pritaikyta viename ar keliuose serveriuose ir dirbti su tūkstančiu vartotoju. [40] OpenBravo OpenBravoapţvalga # Kriterijai Apibūdinimas 1 Konfigūravimas Metaduomenys, WAD varikliukas. 2 Internacionalizacija 9 kalbos 3 Draugiškumas vartotojui Geras, internetinė vartotojo sąsaja 4 Architektūra MVC, MDD, internetinė 5 Pritaikomumas Geras, galima pritaikyti bet kokio dydţio įmonei 6 Saugumas Rolės, auditas, saugus prisijungimas per https 7 Sąsajos Dokumentų saugojimas Excel, CSV, PDF formatu 8 OS nepriklausomumas Windows, Linux/Unix, Solaris, FreeBSD 9 DB nepriklausomumas PostgreSQL, Oracle, Apache http Serveris, Tomcat 10 Programavimo kalba Java, JavaScript, PL/SQL 11 lock-in efektai Nėra 12 Dokumentacija Wiki, forumas Konfigūravimas ir architektūra [41] 6 lentelė OpenBravo sukurtas naudojant MVC ir MDD architektūrą bei WAD variklį. Kaskart sistemos administratoriui padarant pakeitimus, WAD varikliukas įvykdo bei sukompiliuoja aplikaciją, kurios metu sukuriami failai skirtingiems MVC modelio komponentams (9 pav.): Model xsql failai su įvykdom SQL uţklausom. View HTML ir XML failuose apibrėţiamos formų išdėstymas ir ryšys su duomenimis. Control apibrėţiami reikalingi atlikti veiksmai, valdomas modelis ir generuojamas vaizdas. 29

30 15 pav. OpenBravo sistemos konfigūravimas Šaltinis: Pagrindiniai OpenBravo architektūros elementai yra: [42] WAD jų pačių sukurtas varikliukas, automatiškai generuojantis MDD ţodyno failus. Sugeneruoti failai yra palaikomi MVC standarto. MDD ţodynas saugo metaduomenis, kurie apibūdina kiekvieną aplikacijos elementą ir elgesį. MVC struktūra. 16 pav. OpenBravo architektūra Šaltinis: Saugumas [40] OpenBravo realizuotas trijų lygių saugumas: Priėjimas prie duomenų vartotojui pagrįstas rolėmis. Kiekvienos atliekamos operacijos auditas. 30

31 Saugaus ryšio palaikymas per https. Dokumentacija OpenBravo turi wiki dokumentacijos svetainę, kuri yra paruošta anglų, vokiečių, ispanų, prancūzų, italų, protugalų, rusų bei kinų kalbomis. Taip pat yra sukurti forumai. Verslo valdymo sistemų palyginimas Apţvelgus verslo valdymo sistemas, sudaryta lyginamoji lentelė. VVS palyginimas Atvirojo kodo VVS Kriterijus OpenERP Compiere OpenBravo Labai maţai įmonei 2 tinka tinka Maţai įmonei 2 tinka tinka tinka Vidutinei įmonei 2 nelabai tinka tinka tinka Didelei įmonei 2 nelabai tinka 7 lentelė e-komercija Yra Yra Nėra Apskaita Yra Yra Yra MRP Yra Yra Yra POS Yra Yra Yra Inventorius ir sandėliavimas Yra Yra Yra Konfigūravimas XML Metaduomenys Metaduomenys, WAD varikliukas Internacionalizacija Yra, >18 kalbų Yra, >20 kalbų Yra, 9 kalbos Draugiškumas vartotojui geras vidutinis geras Architektūra 3 pakopos, su GUI klientu. MVC 2 ir 3 pakopos mišinys, fat klientas, MDA, ADD Pritaikomumas Apribotas PostgreSQL DB geras Saugumas Rolės, grupės,vartotojai Rolės, duomenys, auditas Sąsajos XML-RPC, CSV, PDF, CSV, PDF Excel, OpenOffice MVC, MDD, internetinė Geras, bet kokio dydţio įmonei Rolės, auditas, https Dokumentų saugojimas Excel, CSV, PDF formatu OS nepriklausomumas geras geras geras DB nepriklausomumas Prastas, PostgreSQL Prastas, Oracle ir EnterpriseDB Geras, PostgreSQL, Oracle, Apache http serveris, Tomcat Programavimo kalba Python Java Java, JavaScript, PL/SQL Gera, Wiki ir forumas Dokumentacija Gera, gaminojo ir forumas Gera, Wiki ir forumas lock-in efektai Nėra PDF, migracijos Nėra įrankis, Oracle DB Demo versija internete Yra Nėra Yra Licencija GPL MPL MPL Projekto pradţia Šaltinis: Thomas Herzog. A comparison of Open Source ERP Systems 2 Tinkamumas 31

32 Compiere ir OpenBravo funkcionalumų palyginimas 17 pav. Compiere ir OpenBravo palyginimas Šaltinis: 32

33 VERSLO VALDYMO SISTEMŲ ĮDIEGIMO ETAPŲ APŢVALGA Verslo valdymo sistemos diegimas sudėtingas ir ilgas procesas. VVS diegimų konsultacijų bendrovės yra apskaičiavę, kad jei tinkamai pasiruošiama projektui, tuomet iki 70% jų gali būti įgyvendinama sėkmingai. Taigi, diegimas yra skirstomas į tam tikrus etapus. Kiekviename etape atlikti veiksmai turi įtakos sekantiems etapams ir bendrai projekto sėkmei. Toliau apţvelgsiu keletą įdiegimo etapų pavyzdţių. Vienas iš siūlomų VVS diegimo variantų susideda iš šių etapų[43]: 1. Tikslų nustatymas 2. Specialistų įmonės pasirinkimas 3. Funkcinių reikalavimų dokumento parengimas 4. VVS išrinkimas 5. VVS diegėjo pasirinkimas 18 pav. VVS įdiegimo etapai Pirmas etapas - įmonė nusistato tikslus, kuriuos ketina pasiekti kai bus įdiegta VVS. Taip pat nustato sprendţiamas problemas. Antrame etape pasirenkama specialistų įmonė, kuri konsultuos sistemos pasirinkimo klausimais bei parengs techninius-funkcinius sistemos reikalavimus. Ši specialistų įmonė priţiūrės projekto vykdymą iki pat sistemos diegimo pabaigos. Trečiame etape analizuojami įmonės veiklos procesai, specifiniai poreikiai. Specialistai parengia funkcinių reikalavimų dokumentą. Jis yra patikslinamas su įmonės atsakingais asmenimis. Priešpaskutiniame, ketvirtame etape yra parenkama verslo valdymo sistema pagal numatytus reikalavimus. Penktame etape skelbiamas konkursas (apklausa) ir tuomet pasirenkamas VVS diegėjas. 33

34 Michael Hawksworth, MSS prezidentas išskiria šiuos etapus [44]: 1. Prioritetų nustatymas 2. Pakeitimų vengimas 3. Pasirengimas pokyčiams 4. Vadovų palaikymas 5. Žmonių pasirinkimas 19 pav. Steps to ERP implementation success by Michael Hawksworth, President and CEO, MSS Technologies, Inc. Prioritetų nustatymas. Autorius siūlo nustatyti problemas ir tikslus prioriteto tvarka. Įdiegimas paeiliui gali sumaţinti informacijos perteklių vadovams bei darbuotojams, kuomet jie turės išmokti naujai įdiegtos sistemos procesus. Iš pradţių siūloma įdiegti esminius funkcionalumus, kurie pakeičia esamas sistemas. Kuomet įmonė su jais apsipranta, siūloma diegti likusius. Pakeitimų vengimas. VVS programinio kodo modifikavimas, siekiant pritaikyti ją įmonei yra laikomas blogu sumanymu ir to siūloma vengti. Tai padidina diegimo kaštus keliais būdais: Modifikavimas padidina diegimo kainą nes reikalingas specialus programavimas, kad atitikti specifinius poreikius. Pailgėja projekto įvykdymo trukmė. Pasirengimas pokyčiams. Siekiant, kad įmonė kuo greičiau ir geriau prisitaikytų pokyčiams, ją reikia tam paruošti. Tam yra daugybė efektyvių būdų, bet svarbiausias gera komunikacija. Darbuotojai turi suprasti, kad pasikeitimai duos naudą įmonei. Todėl juos reikia gerai supaţindinti. Vadovų palaikymas. Autorius išskiria vadovų įsitraukimo į diegimą svarbą. Jie yra atsakingi uţ sėkmingos vizijos sukūrimą, projekto komandos motyvavimą, resursų radimą bei sprendimų priėmimą. Ţmonių parinkimas. Yra sunku suplanuoti sėkmingą įdiegimą, kadangi rezultatai ţenkliai priklauso nuo šiam darbui paskirtų ţmonių patirties ir sukauptų ţinių. Todėl svarbu pasirinki tinkamus ţmones. Kiekvienai komandai reikalingas projektų vadovas, tačiau jis nebūtinai turi būti iš tos pačios įmonės. 34

35 Oleg Kovalevskij, UAB Contour Labs direktorius gana išsamiai ir tiksliai išskiria tokius diegimo etapus [45]: 1. Diegimo tikslų ir uždavinių suformulavimas 2. Išorinių konsultantų pasirinkimas ir(arba) projekto darbo grupės suformavimas 3. VVS pasirinkimo darbų grafiko sudarymas 4. Tyrimas ir projekto techninės dokumentacijos sudarymas 5. Projekto biudžeto numatymas 6. Preliminarus programinių produktų sąrašas 7. Tinkamiausios programos pasirinkimas, sutarties pasirašymas 20 pav. VVS diegimo ţingsniai, Oleg Kovalevskij, UAB Contour Lab direktorius Pirmas etapas - diegimo tikslų ir uţdavinių suformulavimas. Tai atlikus, einama prie antro etapo- išorinių konsultantų pasirinkimo ir(arba) projekto darbo grupės suformavimo. Akcentuojamas pagrindinių padalinių vadovų įtraukimas į projekto darbo grupę dėl darbuotojų pasipriešinimo naujovėms sumaţinimo. Trečias etapas - VVS pasirinkimo darbų grafiko sudarymas. Autorius siūlo pasirinkimą skaidyti į etapus, suplanuoti jų terminus bei nustatyti atsakingus darbuotojus. Taip pat reikia atsiţvelgti į projekto grupės darbuotojų uţimtumą, darbo grafiką, nes darbuotojai skiria prioritetą pagrindinėms pareigoms ir tik tuomet atlieka kitus darbus. Ketvirtas etapas atliekamas tyrimas ir sudaroma projekto techninė dokumentacija. Šiame etape paruošiami reikalavimai būsimai verslo valdymo sistemai, formalizuojamas organizacijos vadybos modelis ir pagrindiniai verslo procesai. Penktas etapas - projekto biudţeto numatymas. Tai svarbus etapas, kadangi pinigai yra pagrindinis veiksnys, ribojantis norus ir galimybes. Šeštas etapas preliminarus programinių produktų sąrašas. Egzistuoja daugybė VVS programų. Todėl autorius siūlo jas suskirstyti į grupes ir tuomet analizuoti kiekvienos grupės produktų uţdavinius, funkcijų galimybes, įdiegimo terminus bei kainą. Visa tai palyginus su įmonės keliamais reikalavimais yra nustatoma tinkama grupė, o priklausančios programos preliminarus produktų sąrašas. 35

36 Sudarius preliminarių programinių produktų sąrašą einama prie septinto etapo - tinkamiausios programos pasirinkimo ir sutarties pasirašymo. Tinkamiausia programa laikoma ta, kuri geriausiai atitinka įmonės iškeltus projekto tikslus, uţdavinius, verslo procesus bei paruoštus reikalavimus. Galime pastebėti, kad visi trys siūlomi diegimo etapai turi panašumų. Pirmose vietose visada pabrėţiamas tikslo nustatymas bei projekto komandos suformavimas. Apţvelkime, kodėl taip yra. Tikslo nustatymas ir jo svarba [46] VVS įdiegimo tikslų projekto pradţioje nustatymas yra gyvybiškai svarbus. Keliami tikslai turi atitikti įmonės verslo tikslus. Tik apsibrėţus tikslus galima kurti naujos programinės įrangos reikalavimus ir nustatyti diegimo etapų eiliškumą. Labai svarbu suformuluoti konkrečius tikslus. Taip vėliau yra lengviau nustatyti ar tikslas buvo pasiektas ar ne. Štai keletas suformuluotų konkrečių tikslų pavyzdţių: dvigubai pagreitinti uţsakymų įvykdymo laiką. 35% sumaţinti atsargas. padvigubinti prekes uţsisakančių klientų skaičių. Projekto komandos suformavimas [46] Projekto komandos suformavimas yra svarbus akcentas, nes komanda turės išsirinkti programinę įrangą, ją įdiegti, priţiūrėti ir tobulinti. Įprastai komanda yra sudaroma iš administracijos ir vykdytojų. Čia svarbu pasirinkti tinkamus darbuotojus, turinčius pakankamai gebėjimų ir ţinių. Į projektą rekomenduojama įtraukti ir įmonės padalinių vadovus, nes jie teigiamai įtakoja darbuotojus, todėl sumaţėja pasipriešinimas naujovėms. Diegimo procese turi dalyvauti ir įmonės vadovas. Jis kontroliuoja projekto eigą, perţiūri tarpinius rezultatus, šalina konfliktus, sprendţia iškilusias problemas. Įmonės vadovybės įtaka verslo procesų automatizavimui yra laikoma svarbiausiu veiksniu. Projekto komandos formavimo alternatyva gali būti konsultavimo įmonės samdymas. Diegimo konsultantai turi ţinių vadyboj, finansuose, diegime ir investicijose. Todėl tai labai patogu. Išorės konsultantų privalumai: sumaţėja įmonės darbo krūviai. sutrumpėja darbų atlikimo laikas, VVS įdiegimo trukmė. sumaţėja įdiegimo kaštai. padidėja investicijų grąţa. maţėja pakartotino darbų vykdymo, klaidingų sprendimų priėmimo ir investicijų į IT praradimo rizika. 36

37 VERSLO VALDYMO SISTEMŲ DIEGIMO ETAPŲ PALYGINIMAS Verslo valdymo sistemų diegimo etapų apţvalgoje buvo apţvelgti trys skirtingi diegimo variantai. Svarbu išsiaiškinti, kuris iš jų yra tinkamiausias. Todėl jie bus palyginti. Prisiminkime, kokie yra diegimo variantai (3 lentelė) VVS diegimo variantai ir jų etapai I II III 1. Tikslų nustatymas 1. Prioritetų nustatymas 1. Diegimo tikslų ir uţdavinių suformulavimas 2. Specialistų įmonės pasirinkimas 2. Pakeitimų vengimas 2. Išorinių konsultantų pasirinkimas ir(arba) projekto darbo grupės suformavimas 3. Funkcinių reikalavimų dokumento parengimas 3. Pasirengimas pokyčiams 3. VVS pasirinkimo darbų grafiko sudarymas Ţemiau pateikta palyginamoji lentelė, sudaryta pagal esminius punktus: Skirtingų diegimo variantų palyginimas 8 lentelė 4. VVS išrinkimas 4. Vadovų palaikymas 4. Tyrimas ir projekto techninės dokumentacijos sudarymas 5. VVS diegėjo pasirinkimas 5. Ţmonių pasirinkimas 5. Projekto biudţeto numatymas 6. Preliminarus programinių produktų sąrašas Tikslai Darbo grupė/išoriniai konsultantai Funkciniai reikalavimai 7. Tinkamiausios programos pasirinkimas, sutarties pasirašymas 9 lentelė I diegimo variantas II diegimo variantas III diegimo variantas Apibrėţiami tikslai ir problemos Siūloma specialistų įmonė Apibrėţti tikslai prioritetinami Siūlomas darbo grupės sudarymas Apibrėţiami tikslai ir uţdaviniai Siūloma specialistų įmonė ir/arba darbo grupės sudarymas Akcentuoti Neakcentuoti Akcentuoti VVS pasirinkimas Akcentuotas Neakcentuotas Akcentuoti, siūloma sudaryti preliminarų produktų sąrašą. Pakeitimų vengimas Akcentuotas Akcentuotas Akcentuotas Vadovų palaikymas Neakcentuotas Akcentuotas Akcentuotas 37

38 Iš 9 lentelės matyti, kad diegimo etapai turi panašumų. Visuose juose pirmu numeriu akcentuojami tikslai. Pirmame diegimo variante šalia tikslų siūloma apsibrėţti ir sprendţiamas problemas, o trečiame uţdavinius. Antrame diegimo variante autorius siūlė iškeltus tikslus ir problemas prioritetinti, ir pirma įgyvendinti svarbiausius, o tada likusius tikslus. Derėtų pastebėti, kad yra svarbu suvokti patį diegimo poreikį. Nes galbūt problema nėra susijusi su automatizacijos trūkumu ir VVS yra visai nereikalinga. Pavyzdys gali būti pardavimų sumaţėjimas dėl morališkai pasenusios produkcijos[45]. Darbo grupės formavimas ar išorinių konsultantų samdymas - tai daţnas klausimas įmonėms. Pirmame diegimo variante siūloma tiesiog samdytis specialistų įmonę. Šis sprendimas gana logiškas, kadangi tai turi daug privalumų, sumaţėja krūviai įmonės darbuotojams. Antrame diegimo variante siūloma sudaryti darbo grupę. Čia labiau akcentuojamas tinkamų ţmonių pasirinkimas. Minima, kad nebūtinai visi nariai turi būti iš tos pačios įmonės. Svarbiausia patirtis. Trečiame diegimo variante siūlomi keli variantai: darbo grupės formavimas ir arba išorinių konsultantų samdymas. Manau tai tinkamiausias variantas, kuris leidţia įmonei pačiai pasirinkti kaip elgtis. Pirmame ir trečiame diegimo variante darbo grupės formavimas ar konsultantų samdymas išskiriamas kaip antras pagal svarbą veiksnys po tikslų nustatymo. Antrame diegimo variante šis veiksnys išskiriamas paskutintoje vietoje, o jo vietoje yra pakeitimų vengimas. Funkciniai reikalavimai naujai sistemai neakcentuoti tik antrame diegimo variante. Jų paruošimas yra svarbus veiksnys, kadangi siekiant juos paruošti, reikia išanalizuoti įmonės veiklą. VVS pasirinkimas akcentuojamas pirmame ir trečiame diegimo variantuose. Pirmame diegimo variante siūloma rinktis geriausiai numatytus reikalavimus atitinkančią sistemą. Trečiame diegimo variante siūloma prieštai susidaryti preliminarų produktų sąrašą ir tik tuomet pasirinkti tinkamą programą, kuri atitinka įmonės keltus tikslus, uţdavinius, verslo procesus bei paruoštus reikalavimus. Mano nuomone, preliminaraus produkto sąrašo sudarymas yra labai geras sprendimo variantas, palengvinantis pasirinkimą. Pakeitimų vengimas yra akcentuotas visuose diegimų variantuose. Būtent todėl yra siūloma pasirinkti kuo priimtinesnę VVS, kad nereiktų vykdyti didelių pakeitimų naujoje sistemoje arba, kaip pasitaiko, keisti įmonės verslo procesų, siekiant pritaikyti juos naujai sistemai. VVS turi derintis prie įmonės poreikių, bet ne įmonė prie VVS. Vadovų palaikymas akcentuojamas antrame ir trečiame diegimo variante. Teigiama, kad vadovai teigiamai motyvuoja darbuotojus, todėl maţėja jų pasipriešinimas naujovėms. Jie taip pat atsako uţ sprendimų priėmimą, sėkmingos vizijos sukūrimą. Antras ir trečias diegimo variantas siūlo sistemą diegti etapais. Antrame diegimo variante siūloma viską atlikti pagal iškeltus prioritetus. Iš pradţių įdiegiami pagrindiniai funkcionalumai 38

39 (pakeičiama senoji sistema). O apsipratus su ja kiti funkcionalumai. Trečiame diegimo variante automatizavimą siūloma atlikti kiek kitaip. Siūloma diegti posistemes paeiliui. Pavyzdys gali būti toks: iš pradţių paleidţiami apskaitos moduliai, tuomet pardavimo modulis, vėliau automatizuojama gamyba ir taip toliau[45]. Visi trys diegimo variantai turi panašumų tarpusavyje tam tikruose aspektuose, tačiau yra nemaţai skirtumų. Pirmasis diegimo variantas turi gerą diegimo etapų tvarką, tačiau nėra pakankamai detalus jeigu palygintume su trečiuoju. Antrasis diegimo variantas turi prastus diegimo etapus, daugiau akcentuojama kaip svarbu yra nuteikti, paskirti ţmones diegiant VVS. Visiškai nekalbama apie tai, kaip reiktų pasirinkti sistemą. Trečiasis diegimo variantas yra detaliausias iš visų trijų ir suteikiantis daugiausiai informacijos. Jame geriausiai iš visų trijų mano nagrinėtų diegimo variantų išskirti etapai ir jų eiliškumas. Verslo valdymo sistemų diegimo etapų sudarymas Išanalizavus, palyginus ir pamačius gerąsias bei blogąsias skirtingų diegimo etapų savybes buvo sudarytas diegimo planas su šiais diegimo etapais: 21 pav.vvs diegimo etapai Pirmas etapas - tyrimo atlikimas, poreikių išsiaiškinimas. Šiame etape svarbu suprasti esamą būklę ir ar tikrai yra reikalinga nauja VVS, kokių reiktų siekti tikslų ir rezultatų. Taip pat svarbu suformuluoti aiškius tikslus, uţdavinius ir nustatyti problemas bei įvertinti potencialią 39

40 naudą. Svarbiausia yra išsikelti realistiškus tikslus bei jiems pasiekti skirtus uţdavinius. Kartais skirtingose kompanijos struktūros lygiuose suformuoti tikslai būna nesuderinti. Todėl reikia juos derinti ir suteikti prioritetus[46]. Taip pat svarbu nustatyti problemas, kurias turės pašalinti nauja VVS. Visa tai padarius reikia įvertinti būsimą naudą (palyginti privalumus ir kainą), ar ji tenkins įmonę. Antras etapas - Išorinių konsultantų pasirinkimas ir(arba) projekto darbo grupės suformavimas. Šiame etape svarbu apsispręsti ar įmonė nori pati apsiimti sistemos reikalavimų ruošimu ir projekto vykdymu, ar nori tai patikėti specialistams. Mano nuomone tai priklauso nuo darbuotojų patirties ir uţimtumo. Laiko, norint, tikrai galima rasti, tačiau suburti daug įmonėje šios specifinės patirties turinčių specialistų yra gana sudėtinga, todėl geriau tai palikti daryti specialistams, kurie turi pakankamai daug įgūdţių ir patirties. Pasirenkant išorinius konsultantus taip pat svarbu pasirinkti teisingai, mat daţnai yra taip, kad jie atstovauja kokią nors sistemą, tad gali būti subjektyvūs ir bandyti reikalavimus pritraukti prie konkrečios sistemos. Plačiau apie projekto grupės formavimą ir išorinių konsultantų privalumus minėjau analizės dalyje. Trečias etapas. Šiame etape analizuojami įmonės veiklos procesai, specifiniai poreikiai. paruošiami reikalavimai būsimai verslo valdymo sistemai, planuojamas biudţetas. Ruošiant reikalavimus svarbu viską tikslinti su įmonėje atsakingais asmenimis, kad nebūtų padaryta klaidų. Būtina sukurti darbo grafiką, kuriame atsispindėtų darbai ir jiems atlikti skirtas laikas. Tai padeda projekto komandai geriau susiorientuoti, kada yra įvykdoma uţduotis. Kiekvienai uţduočiai turi būti priskirtas konkretus asmuo, kuris bus uţ ją atsakingas. Uţduočiai skirtas laikas turi būti tinkamai pamatuotas. Siekiant kuo optimaliau tai padaryti, patartina ţiūrėti į seniau vykdytus projektinius planus arba konsultuotis pas ekspertus. Reikia vengti uţduočiai skirti per daug laiko, kadangi tai gali sukelti problemas lygiai taip pat kaip ir vėlavimas įvykdyti[47]. Darbo grafikui kontroliuoti daug padeda kritinio kelio stebėjimas. Jis identifikuoja tas uţduotis, kurios turi būti atliktos laiku siekiant projektą uţbaigti pagal nustatytą grafiką. Taip galima pasiskaičiuoti trumpiausią projekto įgyvendinimo trukmę ir kokioms uţduotims turi būti skirtas prioritetas[47]. Ketvirtas etapas - Preliminarus programinių produktų sąrašas. Šis Olego Kovalevskij pasiūlymas[45] iš tikrųjų pasirodė gana logiškas ir geras. Produktų sąrašo sudarymas padeda greičiau atsirinkti tinkamus produktus, kadangi jie yra sugrupuojami. O tai palengvina VVS pasirinkimą ir sutaupo laiko. Penktas etapas - VVS išrinkimas ir sutarties pasirašymas. Sudarius preliminarų programinių produktų sąrašą reikia išsirinkti labiausiai tinkamą sistemą. Tinkamiausia sistema yra ta, kuri geriausiai atitinka iškeltus tikslus ir uţdavinius, įmonės verslo procesus bei paruoštus reikalavimus[45]. 40

41 Šeštas etapas gali būti sudarytas iš dviejų dalių: modifikavimo ir /arba diegimo. VVS modifikavimas. Galimi šie variantai, kurių kiekvienas turi tam tikrų aspektų[48]: Verslo procesų keitimas nepriklausomai nuo VVS, kuri vėliau parenkama ir modifikuojama. Tai reikalauja daug darbo ir sukuriama rizika, kad reikės daug modifikavimo pasirinkus naują sistemą. Verslo procesų modifikavimas siekiant atitikti VVS funkcionalumus. Tokiu atveju maţėja sistemos modifikavimo poreikis, bet reikia daugiau apmokymų bei lankstumo. VVS modifikavimas, kad atitikti įmonės verslo procesus. Tokiu atveju didėja diegimo kaina ir sudėtingumas. Be to, tai gali apriboti naujos sistemos teikiamus privalumus. Tinkamiausiu laikomas esamos sistemos modifikavimas, kad ji atitiktų įmonės poreikius. VVS įdiegimas. Diegimas gali būti vykdomas keliais būdais[49]: Big Bang diegimas kada sistema įdiegiama vienu kartu ir visi vartotojai prie jos pereina. Etapinis diegimas kada sistema yra diegiama etapais. Vartotojai prie naujos sistemos pereina palaipsniui. Paralelinis diegimas kada nauja sistema įdiegiama šalia senos. Vartotojai mokosi dirbti nauja sistema tuo pat metu dirbdami sena. Dviejuose iš nagrinėtų diegimo variantų buvo siūloma diegimą atlikti etapais iš pradţių įdiegti pagrindinius funkcionalumus ir tuomet palaipsniui diegti papildomus. Tai iš tikrųjų neblogas pasirinkimas, kurį renkasi 40% organizacijų[49]. Tuomet ne taip stipriai juntamas našumo sumaţėjimas, atsirandantis dėl darbuotojams reikalingo laiko apsiprasti prie naujų darbo sąlygų ir išmokti dirbti nauja sistema. Kurį įdiegimo būdą pasirinkti vienareikšmiškai atsakyti negalima, kadangi kiekvienas iš jų turi savų privalumų ir trūkumų, o kiekvienos kompanijos tikslai yra skirtingi. Tačiau nėra būtina apsiriboti konkrečiu diegimo būdu, juos galima ir kombinuoti, atsiţvelgiant į kompanijos profilį ir galimybes. Septintas etapas - pasiektų rezultatų ir pastebėtų trūkumų aptarimas bei įvertinimas. Įdiegus sistemą reikia įvertinti gautus rezultatus ar pasiekti tikslai ir įgyvendinti uţdaviniai. Jeigu rasta trūkumų, juos reikia ištaisyti. Visų etapų metu būtinas vadovų bendravimas su darbuotojais, kad būtų aukštas jų įsitraukimo lygis į projektą. Daţnai darbuotojai susiduria su tam tikromis problemomis, nesklandumais, ţino sistemos spragas, todėl įgyvendinant projektą gali nemaţai prie jo prisidėti. Įmonė tai pat turi efektyviai komunikuoti su VVS diegėju, kad būtų geriau vykdomi darbai. 41

42 VVS ĮDIEGIMO STRATEGIJOS Internete yra plačiai diskutuojama, kaip geriausia įdiegti verslo valdymo sistemą bei kokią strategiją pasirinkti. Houston Neal, Software Advice marketingo direktorius išskiria tris pagrindines strategijas: didelio smūgio (angl. Big Bang), etapinę (angl. Phased) bei paralelinę (angl. Parallel). Panagrinėkime jas.(50) Didelio smūgio strategija Didelio smūgio strategija strategija, kai visi moduliai įdiegiami įmonėje vienu metu pasirinktą dieną. Ji pasiţymi tuo, kad nuo senos sistemos prie naujos yra pereinama ne kaip nors palaipsniui, bet iškarto. Įdiegus naują sistemą senoji yra išjungiama. Dėl tokio sistemos įdiegimo tipo didelio smūgio strategija yra rizikingesnė lyginant ją su kitomis. (50,51) Didelio smūgio diegimo strategijos privalumai: (50,51) Aiškiai ţinoma sistemos diegimo data. Trumpesnė sistemos įdiegimo trukmė. Maţesni įdiegimo kaštai. Darbuotojų apmokymas reikalingas tik naujai sistemai. Pagrindinis šios diegimo strategijos privalumas yra staigus perėjimas prie naujos sistemos. Nauja sistema įdiegiama praktiškai per vieną kartą/dieną. Dėl tokios trumpos įdiegimo trukmės sumaţėja diegimo kaštai. Taip pat dingsta ir sistemos perėjimo iš senos į naują laikotarpis, todėl nereikia atnaujinti vartotojo dokumentacijos. Nereikia kurti specialios sąsajos vartotojams siekiant juos pripratinti prie būsimos sistemos, jie turi būti apmokomi tik paleidus naują sistemą. (50,51) Didelio smūgio diegimo strategijos trūkumai: (50,51) Sudėtinga įdiegti ir paleisti sistemos modulius vienu metu. Sunku sukurti bei įgyvendinti atsarginį planą. Skubant keisti sistemą gali būti praleistos svarbios detalės. Darbuotojai turi maţiau laiko išmokti naudotis nauja sistema. Vienos sistemos dalies ţlugimas gali įtakoti kitas sistemos dalis. Reikia laiko, kad įmonė pasiektų buvusį našumą. Pagrindinis didelio smūgio strategijos trūkumas, dėl kurio kyla problemos yra laikas. Kadangi visi pasiruošimo darbai turi būti atlikti iki diegimui numatytos dienos, galiatsitikti taip, kad per skubėjimą bus praleista svarbi detalė ir taip vėliau sistemoje atsiras klaidų. Įmonė taip pat gali nespėti pasiruošti arba jų informacinė sistema uţlūţti. Didelio smūgio diegimo procesas susideda iš trijų etapų: sistemos konvertavimo, sistemos paleidimo dalimis ir vartotojų apmokymo. 42

43 Sistemos konvertavimas susideda iš šių ţingsnių (51): Esamos sistemos duomenų konvertavimas Duomenų įkėlimas į naują sistemą Duomenų testavimas Sistemos išbandymas Sistemos veikimo patikra 22 pav. Sistemos konvertavimas Sistemos konvertavime pirmiausia perkonvertuojami esami sistemos duomenys į naujus, tinkančius būsimai sistemai. Tuomet vykdomas duomenų įkėlimas į naują sistemą. Toliau reikia pratestuoti duomenis: patikrinti jų efektyvumą bei suprantamumą vartotojams. Todėl sistema yra išbandoma. Bandymo metu aiškinamasi ar sistema gali draugauti su vartotojais, ar ji veikia teisingai. Paskutiniame ţingnyje atliekamas patikrinimas ar sistema su konvertuotais duomenimis veikia teisingai. Jeigu taip, tai ruošiamasi sistemos paleidimui, priešingu atveju vykdomi tam tikri pakeitimai ir ciklas yra kartojamas(51). Sistemos paleidimo dalimis ţingsniai(51): Konvertuotos duombazės paleidimas Sukurtos aplikacijos paleidimas Infrastruktūros paleidimas 23 pav. Sistemos paleidimas dalimis Sėkmingai atlikus sistemos konvertavimą vykdomas sistemos paleidimas. Iš pradţių paleidţiama naujai sukurta duombazė. Taip nauji duomenys tampa prieinami. Tada paleidţiama vartotojams sukurta aplikacija ir infrastruktūra. Jeigu kaţkuri paleidimo dalis ţlunga, tenka vykdyti 43

44 pakeitimus ir viską pradėti iš naujo. Atlikus naujos sistemos paleidimą darbuotojai vis dar dirba su sena sistema, nauja tampa paruošta darbui(51). Vartotojų apmokymo ţingsniai(51): Patyrusių darbuotojų samdymas Vartotojų apmokymas 24 pav. Vartotojų apmokymas Vartotojų apmokymas paskutinis diegimo etapas. Jis susideda iš dviejų etapų. Pirmame etape yra samdomi patyrę, su sistema mokantys dirbti darbuotojai, kurie perima besimokančių darbuotojų darbus. Taip sumaţinamas atsilikimas nuo darbų. Antrame etape darbuotojai apmokomi dirbti su nauja sistema(51). Kada įvykdomi trys aukščiau išvardinti diegimo etapai, sistema galiausiai gali būti paleidţiama. Tai vykdoma iškart po senos sistemos išjungimo. Paleidus naują sistemą darbuotojai dar nėra prie jos gerai pripratę, todėl jų darbas sulėtėja. Toks reiškinys vadinamas pradiniu kritimu. Todėl dar prieš diegiant sistemą reikia suplanuoti kokių veiksmų bus imtasi siekiant išspręsti šia problemą(51). Etapinio diegimo strategija Etapinio diegimo strategija strategija, kada sistema yra diegiama palaipsniui. Iš pradţių ji būna diegiama vienoje, vėliau kitose įmonės dalyse. Etapinė strategija pasiţymi sudėtingumu, todėl ją nelengva įgyvendinti, o vėlesniuose įgyvendinimo etapuose jau nebėra kelio grįţimui atgal(50,52). Etapinio diegimo privalumai(50,52): Yra laiko korekcijoms. Vartotojai turi daugiau laiko adaptuotis prie naujos sistemos. Nėra pasivijimo periodo. Ţinios ir įgyta patirtis pirmame diegimo etape gali būti pritaikytos kituose etapuose. Techninis personalas gali susikoncentruoti į vieną sistemos dalį ar grupę vartotojų. Etapiniame diegime viskas vykdoma paeiliui, o tai turi nemaţai privalumų. Visų pirma, pradţioje iškylantys nesklandumai yra netokie kritiški. Vartotojai turi laiko įprasti dirbti su nauja sistema, todėl nesumaţėja jų našumas ir nėra pasivijimo periodo. Dėl diegimo etapais taip pat galima atlikti korekcijas sistemoje. Etapinio diegimo trūkumai(50,52): 44

45 Projekto įgyvendinimo trukmė ilgesnė uţ Didelio smūgio. Kiekvienas modulis yra priklausomas nuo kitų modulių informacijos, todėl gali trūkti svarbios informacijos. Su kiekvienu įgyvendinimo etapu grįţimas prie senos sistemos tampa vis sudėtingesnis. Duomenų teisingumas turi būti tikrinamas keletą kartų. Nors pasirinkus etapinio diegimo strategiją dingsta prisivijimo periodas, vartotojų apmokymas gali būti gana sudėtingas, nes jiems tenka dirbti su sena ir nauja sistema tuo pačiu metu. Etapinis diegimas gali būti vykdomas keliais būdais(50): diegiant moduliais iš pradţių įdiegiami esminiai sistemos moduliai, o kitose fazėse likę moduliai ir funkcionalumai. diegiant pagal verslo procesus pvz. iš pradţių sistema įdiegiama finansuose, o vėliau tiekimo grandinės valdyme. diegiant pagal geografinę vietą naudojamas diegiant didelėse įmonėse, kurios padaliniai išsidėstę keliose vietose. Paralelinio diegimo strategija Paralelinio diegimo strategija maţiausiai rizikinga strategija, nes vienu metu būna paleistos sena ir nauja sistemos. Tokiu būdu vartotojai gali dirbti su sena sistema, bei mokytis naujos. Sena sistema yra išjungiama kada nauja sistema atitinka visus keliamus kriterijus. Paralelinis diegimas yra brangiausias metodas, kadangi įmonė vienu metu turi dvi veikiančias sistemas, o tai reiškia investavimą į ţmogiškuosius resursus(50,53). Paralelinis diegimas susideda iš šių etapų(53): Pasiruošimas diegimui. Organizacijos pasiruošimas. Konvertavimas. 25 pav. Paralelinio diegimo etapai Pirmame etape sukuriamas diegimo planas, darbų tvarkaraštis, apibrėţiami organizaciniai ir IT reikalavimai. Organizaciniai reikalavimai apima ţmogiškuosius resursus (darbuotojų apmokymus ir pan.). IT reikalavimai labai svarbūs siekiant paleisti dvi sistemas kartu(53). 45

46 Organizacijos pasiruošimas diegimui susideda iš reikalavimų testavimo, atsarginio plano sukūrimo ir konvertavimo testavimo. Įvertinant reikalavimus šiek tiek modifikuojamas diegimo planas. Tada pereinama prie paskutinio etapo konvertavimo. Jo metu, veikiant esamai sistemai yra paleidţiama nauja. Senoji sistema vis dar būna pagrindinė, bet po truputi pereinama prie naujos. Kai nauja sistema atitinka visus kriterijus, ji tampa pagrindine. Tada senoji sistema vis dar veikia saugumo sumetimais iki kol nauja sistema pradeda pilnai funkcionuoti(53). 46

47 DIEGIMO ETAPŲ REALIZAVIMAS Tyrimo atlikimas. Augantis Octopus business management įmonės darbuotojų ir jiems skiriamų uţduočių skaičius verčia automatizuoti įmonės projektų valdymą. Šiuo metu įmonėje nėra įdiegta jokia verslo valdymo sistema, leidţianti fiksuoti darbuotojų nuveiktą darbą, bei galimybę priskirti jiems uţduotis. Todėl darbuotojai turi surašinėti nuveiktus darbus į tekstinį failą ir įkeldinėti jį į serverį. O tai sukelia keblumų: darbuotojai pamiršta tai padaryti, tai nėra patogu. Kita iš to iškylanti problema yra galimybės fiksuoti darbų atlikimo laiką nebuvimas. Taip pat nėra galimybės chronologiškai stebėti konkretaus projekto darbų (nes kiekvienas darbuotojas atliktus darbus surašo į savo tekstinį failą). Prisijungiant prie serverio yra būtinas saugos raktas, todėl tai dar labiau apriboja duomenų pasiekiamumą. Šiam projektui įgyvendinti biudţetas nebus numatomas, todėl bus diegiama atvirojo kodo sistema. Tikslas. Įdiegti projektų valdymo sistemą, kuri automatizuotų projektų, uţduočių paskirstymą darbuotojams taip pagreitinant, palengvinant atliktų darbų fiksavimą bei projektų valdymą. Tikslui pasiekti keliami uţdaviniai: Sistema turi automatizuoti projektų priskyrimą darbuotojams. Sistema turi automatizuoti darbuotojų atliekamų darbų fiksavimą. Sistema turi turėti papildomus funkcionalumus: galimybę valdyti failus, fiksuoti darbų trukmę. Sistema turi būti pasiekiama iš bet kurio kompiuterio be papildomos programinės įrangos įdiegimo. Sistema turi būti atvirojo kodo. Pilnai įgyvendinus uţdavinius bus automatizuotas projektų ir uţduočių valdymas. Taip bus pasiektas tikslas ir išspręstos iškeltos esamos problemos. Projekto darbo grupės sudarymas. Išorinių konsultantų samdymas šiam projektui nėra reikalingas, kadangi tai nėra didelės sistemos diegimas, kuris apjungtų daugelį įmonės procesų.todėl projektų valdymo sistemos įdiegimą gali atlikti įmonės darbuotojai. Darbo grupę sudaro 3 darbuotojai. Vienas darbuotojas ruošia reikalavimus sistemai, atlieka analizės, reikalavimų sudarymo ir sistemos pasirinkimo darbus. Kitas darbuotojas, turintis priėjimą prie serverio, įdiegia sistemą. Trečiasis grupės narys - vadovas, kuris priţiūri projektą. Reikalavimų parengimas. Atsiţvelgiant į iškeltą tikslą bei uţdavinius buvo sudaryti reikalavimai naujai sistemai. Jie taip pat buvo sukonkretizuoti bei papildyti. Naujai sistemai keliami reikalavimai: 47

48 Pagrindiniai: Sistema turi būti atvirojo kodo. Linux operacinės sistemos palaikomumas. Sistema turi būti pasiekiama per internetą (interneto pagrindo). Projektų valdymas. Kelių projektų palaikymo galimybė - darbas su keliais projektais vienu metu. Uţduočių valdymas ir planavimas. Failų valdymas. Specifiniai: Projektų išskaidymo galimybė. Rolių/teisių paskirstymas - skirtingiems darbuotojams skirtingų rolių/teisių priskyrimas. Galimybė paprastam sistemos vartotojui kurti uţduotis. Darbo trukmės fiksavimas. Privalumai: Diagramų sudarymo galimybė. Paprastas dizainas. Nepergrūsta funkcionalumais. Aiškus funkcijų išdėstymas. Darbo grafiko sudarymas. 26 pav. Darbo grafikas 48

49 Preliminaraus programinių produktų sąrašo sudarymas. Pagal nustatytus pagrindinius funkcinius sistemos reikalavimus sudarytas toks galimų produktų sąrašas: Collabtive Dolibarr dotproject Project- Open Redmine Plandora Codendi ProjectPier Achievo ProjectHQ Sąrašas sudarytas atsiţvelgiant į populiarias atvirojo kodo projektų valdymo sistemas[54,55] Sistemos išrinkimas. Siekiant pasirinkti tinkamą sistemą buvo nagrinėjamos ir lyginamos sistemos tarpusavyje. Nagrinėjant atsiţvelgta į specifinius sistemos reikalavimus ir privalumus: Uţduočių sudarymas susidaryta nuomonė apie uţduočių valdymą. Tekstinis redaktorius - funkcionalumas, leidţiantis suteikti skirtingą stilių tekstui: padidinti, paryškinti, pabraukti ir panašiai. Naudingas tuo, kad gali pabrėţti darbo eigos detales. Atlikimo trukmė funkcionalumas, leidţiantis atvaizduoti darbų eigą. Uţduoties baigimo data jeigu ji yra privaloma, tada vartotojas, kuriantis uţduotį, privalo ją įvesti. Diagramų braiţymas diagramų braiţymo funkcijos buvimas sistemoje. Dizainas/funkcionalumų išdėstymas susidaryta nuomonė apie bendrą sistemos išvaizdą: dizaino patrauklumą ir funkcionalumų išdėstymo patogumą. Teisių paskirstymas skirtingų rolių darbuotojams priskyrimo galimybė uţduotyse/projektuose. Projekto išskaidymas projekto išskaidymas į smulkesnes dalis. Pvz. uţduotys, klaidos, palaikymas ir panašiai. 49

50 10 lentelė Skirtingų projektų valdymo sistemų palyginimas Uţduočių valdymas Sistema Uţduočių sudarymas Teksto redaktorius Atlikimo trukmė Uţduoties baigimo data Collabtive nepatogus yra nėra privaloma Dolibarr patogus nėra yra neprivaloma dotproject nepatogus nėra yra privaloma Project-Open nepatogus nėra yra privaloma Redmine patogus yra yra neprivaloma Plandora nepatogus nėra nėra neprivaloma Codendi nepatogus nėra nėra neprivaloma ProjectPier patogus nėra nėra privaloma Achievo nepatogus nėra yra neprivaloma ProjectHQ nepatogus nėra nėra neprivaloma Projektų valdymas Sistema Diagramų braiţymas Funkcionalumų išdėstymas Teisių paskirstymas Projekto išskaidymas Collabtive nėra patogus yra nėra Dolibarr yra nepatogus nėra nėra dotproject yra patogus yra nėra Project-Open yra patogus yra yra Redmine yra patogus yra yra Plandora yra nepatogus nėra nėra Codendi yra nepatogus yra yra ProjectPier nėra patogus yra nėra Achievo yra patogus yra yra ProjectHQ nėra patogus yra nėra Collabtive sistema pasiţymėjo graţiu dizainu. Tačiau uţduočių sudarymas ir redagavimas pasirodė nepatogus (27 pav.). Nėra galimybės nurodyti uţduoties atlikimo trukmės. Negalima projekto išskaidyti į keletą skirtingų dalių. Nėra diagramų braiţymo galimybės. 27 pav. Collabtive sistemos uţduočių valdymas Dolibarr sistema turi ne itinpatrauklų valdymą. Ji yra pergrūsta funkcionalumais. Kuriant uţduotis nėra teksto redaktoriaus (28 pav.). Nėra projekto išskaidymo galimybės. 50

51 28 pav. Dollibar sistemos uţduočių valdymas dotproject sistema turi gan paprastą dizainą. Visi funkcionalumai yra išdėstyti paprastai. Norint sukurti projektą, pirmiausia reikia sukurti kompaniją, o tada būtina projektą prie jos priskirti. Sudarant uţduotis privalu įvesti uţduoties baigimo datą, nėra tekstinio redaktoriaus (29 pav.). Nėra projekto išskaidymo galimybės. 29 pav. DotProject sistemos uţduočių valdymas Project-Open sistema pasirodė turinti gana paprastą dizainą. Kaip minusus galima įvardinti tai, kad kuriant naują projektą apribojama pasirinkimais, kokio tipo tai yra projektas (30 pav.). Taip pat būtina nurodyti projekto uţbaigimo datą, uţsakovą. Nėra tekstinio redaktoriaus. 30 pav. Project-Open sistemos projektų valdymas Plandora sistema pasirodė pergrūsta funkcionalumais beinepatogi. Nėra galimybės fiksuoti kiek yra atlikta uţduoties, nėra projekto išskaidymo galimybės, teisių paskirstymo bei tekstinio redaktoriaus (31 pav.). 51

52 31 pav. Plandora sistemos uţduočių valdymas Codendi sistemos meniu išdėstymas pasirodė nepatogus. Labai nepraktiškas yra uţduočių valdymas, uţimantis labai daug vietos ir neturintis tekstinio redaktoriaus, atlikimo trukmės fiksavimo galimybės (32 pav.). 32 pav. Codendi sistemos uţduočių valdymas ProjectPier sistema atrodė patraukliai ir buvo paprasta. Kaip minusą vertėtų paminėti tekstinio redaktoriaus nebuvimą. Naujų uţduočių kūrimas taip pat yra apribotas uţbaigimo data. Nėra diagramų braiţymo galimybės(33pav.). 52