Paljudes ettevõtetes kipub uue ärisüsteemi (nt majandustarkvarapaketi) juurutusega lõppema ka mõttetegevus suunal, kuidas oma infosüsteemi jätkuvalt paremaks muuta. Veidral kombel on vähegi suuremate majandustarkvara hangete üks olulisemaid nõudeid, et pakutav tarkvara oleks avatud, kohandatav ja edasi arendatav, kuid praktikas osutuvad juurutuse käigus tehtud muudatused pahatihti viimasteks.

Esmalt tuleb endale selgeks teha, milliste parenduste tegemine võib anda maksimaalset efekti. Keerukamate juurutusprojektide käigus on kindlasti ajaliste või eelarve piirangute tõttu mõni konkreetne alamprojekt edasi lükatud ning selliste juhtumite analüüsist tulebki alustada. Kui aga ärisüsteem on olnud aastaid käigus muutumatuna, tasub võtta korraks aeg maha ja vaadata, kuidas see vastab ettevõtte tänastele äriprotsessidele ja kas on valdkondi, kus ärisüsteemi uuendamisest või parendamisest tõuseks kasu.

Sageli võib osutuda otstarbekaks teha jooksvaid pisiparandusi (nt lisada mõni uus funktsioon, uus aruanne) või lihtsalt asendada ärisüsteemi aluseks olev majandustarkvara vanem versioon uuega. Sisuliselt võibki parendused liigitada järgnevalt: tarkvara versiooniuuendused, tarkvara funktsionaalne täiendamine, tarkvara sidumine mõne teise rakendusega, tarkvara liidestamine infoteenustega.

Versiooniuuendused on kujunenud paljudes ettevõtetes problemaatiliseks teemaks, kuna sageli ei nähta tarkvaraversiooni järjepidevas vahetuses piisavalt konkreetset kasu ning seetõttu kiputakse kergekäeliselt loobuma ka tarkvaratootjatele arendustasu maksmisest. Vähegi suurema ja kallima tarkvaralitsentsi puhul räägime siin üsna kopsakatest summadest. Samas on infotehnoloogia areng niivõrd kiire, et tänu uute võimaluste tekkimisele ja ärakasutamisele on tüüpiliseks majandustarkvara baasversiooni elutsükliks kujunenud 5?6 aastat.

Kuigi praktikas on võimalik kasutada ka mitu põlvkonda vanu tarkvaralahendusi, võib tarkvarakasutaja ennast üsna lihtsalt leida ühel päeval olukorrast, kus ta on oma murega üksi ? vana versiooni tundvaid spetsialiste ei ole ja tarkvara loonud firmal puudub igasugune huvi ning kohustus teda aidata.

Versioonivahetuste puhul on kahjuks paljude programmide puhul tavaline, et esineb probleeme nii oma kohanduste kui isegi andmete ümbertõstmisega. Põhjuseks on nii tarkvaraarendajate kohati liialt tormaka arendustegevuse käigus läbi mõtlemata jäänud tehnilised detailid kui ka mitte just kõige paremate tavade järgi tehtud oma ärisüsteemi kohandused.

Tarkvaraliste probleemide kiireks lahendamiseks on ainus läbiproovitud ja toimiv tee aktiivsemates tarkvara kasutavates firmades erinevate test- ja pilootprojektide läbiviimine. Testkliendina kulutatud aeg tasub ennast sageli ära tänu esimesena saadavale uuele funktsionaalsusele või soodsamale teeninduspoliitikale.

Samalaadselt tuleb toimida ka oma kohanduste olemasolu korral ? uuele versioonile ülemineku testimise käigus kontrollige hoolikalt, kas kohandused ikka toimivad.

Üks äärmiselt oluline aspekt on see, et kõik tehtud kohandused oleksid põhjalikult dokumenteeritud. Kui mingil põhjusel ei peaks kohandused uue versiooniga sobima, saab spetsifikatsiooni põhjal palju kiiremini tuvastada võimalikud muutmist vajavad programmilõigud, selle asemel et püüda dokumenteerimata kohandustes orienteeruda.

Et arendustöö ei tekitaks taolisi probleeme, on alati rangelt soovitatav arenduse käigus lähtuda tarkvaratootja juhistest ning keerukamatel juhtudel tuleb kasuks, kui tarkvaratootja või tema esindaja vaatab kohandused üle.

Oma ärisüsteemi arendamine eeldab head tarkvara arendusvõimaluste ja -vahendite tundmist ning põhilisi süsteemidisaini ja programmeerimise oskusi. Tavaliselt väiksemas ja keskmises ettevõttes selliseid inimesi ei ole ning tööd tellitakse vajadusel tarkvara tarnijalt. Kui aga vastav ressurss on olemas, on täiesti võimalik luua oma kätega firma spetsiifikale vastavaid lisarakendusi. Enamasti piirdutakse tarkvara olemasoleva funktsionaalsuse laiendamisega või mõningatel juhtudel hoopis kitsendamisega ? kui räägime näiteks kitsalt kasutajarolli vajadustest lähtuvalt ümber disainitud lihtsustatud sisestusvormidest või piiratud päringuvõimalustest.

Tüüpilised valdkonnad, kus ettevõttel on mõtet midagi parendada, on seotud otseselt tema äriprotsesside spetsiifikaga. Näiteks teenindussfääris teenindusprotsessi kliendikeskseks ja võimalikult efektiivseks muutmine. Sageli käib selline arendus käsikäes kvaliteedisüsteemi loomisega, sest praktikas on kvaliteedinõuete kehtestamiseks ja nendest kinnipidamiseks vaja omada suhteliselt suurt hulka andmeid.

Levinud valmislahendustes võivad olla elementaarsed võimalused seda teha, kuid kahtlemata ei saa ükski valmislahendus võtta ilma kohandamata arvesse konkreetse ettevõtte äriprotsesside nüansse. Kvaliteedisüsteemi alusdokumentatsioon on enamasti infosüsteemi arendusprojekti spetsifikatsiooni koostamisel väga heaks lähtebaasiks.

Klassikaline parendusteema on majandusinfosüsteemi sidumine mõne teise infosüsteemiga. Kuna seniajani ei ole selle keerukuse tõttu loodud ühtset tarkvara, mis kataks absoluutselt kõik ettevõtte infotöötlusvajadused, on ettevõtetes kasutusel rida erinevaid IT-lahendusi. Näiteks elementaarne e-posti lahendus, mis on enamasti eraldi rakendus. E-kirjade sidumine majandustarkvaras oleva kliendiinfoga eeldab kahe tarkvara vahel infovahetusliidese loomist.

Keskmistes ja suuremates firmades on mõne ettevõttespetsiifilise valdkonna jaoks loodud individuaalrakendus, mis võiks samuti olla seotud majandusarvestusega. Hea, kui rakenduse saaks realiseerida olemasoleva tarkvara laiendusena, siis on integreerimisteemat kergem lahendada. Selliseid võimalusi pakub paraku suurem ja kallim majandustarkvara. Kuid lööge kokku tarkvara soetamis- ja arenduskulud pikemal perioodil. Võib juhtuda, et püüdes oma terviklahenduseni jõuda eraldiseisvaid ?juppe treides?, kulutatakse rohkem raha kui algselt suuremat süsteemi valides.

Julgustan mõtlema, mida ja kuidas juba täna mis tahes tarkvaralahendustele tuginevas ärisüsteemis paremaks muuta. Enamasti on lahenduseks vertikaalrakendused, millest paljud on piisavalt odavad, et tasuda end ära ka väikestes firmades.

Autor: Margus Tammeraja