Tarkvara loomisel saavad paberil kokkulepitud ideedest toimivad lahendused projekti arendus-, seadistus- ning andmeülekande etapis. Neis etappides on aga oht, et arendusprojekt väljub kontrolli alt või tehakse vigu, mis hiljem segavad tarkvara kasutajate tööd.

Projekti üle kaob kontroll, kui kõik arenduse käigus tekkivad uued mõtted võetakse tööde nimekirja. Samuti peavad tarkvara kasutajad leidma aega, et tegeleda seadistuse ja andmete ülekandmise etapiga. Aja kokkuhoid nendes etappides võib tulevikus tähendada suurt sõltuvust arendaja konsultandist või vigu andmetes, mis üha uuesti ja uuesti välja ilmuvad ning tööd segavad.

ARENDUSETAPP

Majandustarkvara standardlahendused toetavad paljude ettevõtete äritegevust, alustades finantsist ja lõpetades tootmise, logistika jms. Kuid igal ettevõttel on siiski ka oma erisused, mida standardlahendused ei kata. Tarkvaraarendaja abiga saab muuta lahendused ettevõtte vajadustele vastavaks. Kuid seda tehes peab olema ettevaatlik. Muudatuste tegemine standardlahendustes teeb keerukamaks tarkvara hilisema igapäevase halduse. Iga tehtud muudatus võib tulevikus mõjutada tarkvara uute versioonide kasutusele võtmist, kuna ka tarkvaratootja arendab toodet pidevalt edasi. Võib juhtuda, et ettevõtte vajaduste jaoks tehtud eraldi arendused ei pruugi tarkvara versiooni uuendamisel enam hästi majandustarkvara standardlahendustega kokku sobida.

Seega tasub arenduste tegemisel jälgida reeglit: mida vähem, seda parem. Kõik arendused tuleb teha arukalt ja läbimõeldult. Hilisema halduse riski maandab kõigi tehtud muudatuste põhjalik dokumenteerimine. Kindlasti tuleb võrrelda ka esialgset kirjapandud ülesandepüstitust sellega, mis tegelikult tehtud sai. Seejärel tuleb viimane ka kirjalikult vormistada.

Ohtlik on ka olukord, kus arenduste hulk hakkab lumepallina kasvama — mida rohkem lisafunktsioone valmib, seda enam leiavad nendega tutvunud kasutajad, mida kõike on vaja veel juurde tekitada. Kui projekti ajakava ja eelarve ei ole fikseeritud, siis võib selle käigus lahendust jooksvalt kasvatada. Kui aga tegevus- ja ajakava on fikseeritud, siis on oluline, et peakasutaja suudaks tekkivaid soove ohjata. Kindlasti ei tähenda see pakutavate ideede allasurumist või ignoreerimist. Kõik uued mõtted on teretulnud ning need pannakse kirja muudatuste logis.

Kuid tähtis on tõmmata joon paikapandud tegevuskava ja lisanduvate soovide vahele. Mõningase selginemisaja andmine lisasoovidele on kasulik ka tarkvaralahenduse tellijale. Praktika on näidanud, et mõned lisasoovid on tekkinud varem kasutusel olnud tarkvarast või selle puudumisest. Uue tarkvaralahenduse kasutamisel selgub, et vajadus nende lisa arenduste järele kaob. Seega on soovitav vajalikud lisaarendused ellu viia eraldi projektidena pärast põhiprojekti lõppu.

SEADISTAMINE JA VÕTMEKASUTAJATE KOOLITUS

Arendused tehtud, tuleb need seadistuse etapis koos võtmekasutajatega üle vaadata. Õigem olekski seda etappi nimetada koolituseks, sest lisaks seadistustele vaadatakse siin võtmekasutajate ja konsultandi koostöös läbi kogu tulevane tööprotsess tarkvaras ning eelmises etapis tehtud arendused. Kogu tegevus selles etapis peabki toimuma kliendi ja konsultandi pidevas koostöös. Kui jätta konsultant üksi tegutsema, siis on see kahjulik eelkõige tarkvara tulevastele kasutajatele. Nad ei õpi piisavalt hästi tundma kasutatava tarkvaralahenduse hingeelu ja jäävad seetõttu ka pärast arendusprojekti lõppu sõltuma konsultandist. See aga ei ole vajalik. Täna päeva tarkvarades on võimalik protsesse mõjutada vaid mõne pisikese seadistuse muudatusega. Nende muudatustega saaksid küllaldaste teadmiste korral hakkama ka tarkvara võtmekasutajad.

Selleks et võtmekasutajad saaksid konsultandi abiga tarkvara tundma õppida, on vaja aega. Peab tagama, et neil oleks oma põhitöö kõrvalt aega ka tarkvara juurutusprojektiga tegeleda. Seda tuleb varuda nii kohtumisteks konsultandiga kui ka kodutööks. Kodutöö käigus peavad võtmekasutajad lõpetama kohtumistel alustatud seadistused ja valmistama ette andmed järgmisteks kohtumisteks.

Nagu arendusetapis, nii võib ka seadistamise etapis tekkida suur hulk uusi ideid lisaarendusteks. Konsultantide tehtavate koolituste käigus saavad ju võtmekasutajad parema ülevaate tarkvaralahendusest ning on tõenäoline, et rohkem infot omades hakkab tekkima ka rohkem ideid, mida sinna võiks lisada. Siiski ei tasu kohe tormata neid ideid arendama. Kõik head mõtted tuleb kirja panna ja võtta need töösse alles pärast seda, kui uut tarkvara on juba mõnda aega kasutatud. Siis on selge, kas neid arendusi ka tegelikult vaja on.

ANDMEÜLEKANDED

Tarkvaraarenduse projekt ei saa olla edukas, kui puuduvad kvaliteetsed andmed. Täpselt nii korrektsed, nagu on projekti käigus tarkvarasse sisestatavad algandmed, on hiljem ka info, mida uuest lahendusest hakatakse välja võtma. Paraku pööratakse sellele lihtsa loogikaga reeglile liiga vähe tähelepanu. Üldistades on tarkvaras kahte tüüpi andmeid: püsiandmed ning kanded ehk tehingud.

Kui palju ja mis viisil (käsitsi sisestades või importides) mingitest andmetest uude tarkvarasse üle tuuakse, otsustatakse juba disainietapis. Kui andmed otsustatakse importida, siis tuleb ettevalmistusega alustada kohe pärast disainietapi lõppu, paralleelselt arendusetapiga. Konsultant valmistab ette uue tarkvara jaoks sobiva struktuuriga andmeülekannete põhjad (näiteks Excelis). On hea, kui andmed on imporditud juba peakasutajate koolituse ajaks.

Andmete importimise kasuks räägib kiirus, millega on võimalik need vanast tarkvarast uude kanda. Kui aga andmed on väga korrast ära või vana ja uue tarkvara andmestruktuurid on niivõrd erinevad, et nende ühtlustamine Excelis importimiseks võib tekitada vigu, siis on otstarbekam andmeid sisestada käsitsi. Mõned ettevõtted peavadki andmete käsitsi sisestamist paremaks variandiks, kuna seeläbi saavad kasutajad enne igapäevatöö alustamist sellega paremini sõbraks.

Samas ei tohi andmete sisestamise tööd jätta inimestele, kes ei ole nende sisulise poolega kursis. Kui korrast ära andmeid sisestab nende sisulist poolt mittetundev inimene, siis ta korrastab küll kirjapildi, kuid jätab ebavajaliku info endiselt andmetesse. Andmete sisulist korrastamist seega tegelikult ei toimu.

Probleemid tekivad tihti ka seetõttu, et ülekandmise jaoks jäetakse liiga vähe aega. Andmeülekannetega hakatakse tegelema alles tarkvaraarenduse projekti lõpus, kuid siis sunnib juba aeg tähtaegade tõttu peale ja andmete korrastamine jääb väga pealiskaudseks. Tulemuseks on ebakvaliteetsed andmed või info, mida tegelikult ei vajata. Kõik andmeülekande etapis tehtud vead jäävad aga kummitama hiljem majandustarkvaraga tehtavates aruandlustes ja siis on vigade parandamine juba keerulisem. Seega soovitame varuda aega ja alustada andmete ülekandmist uude tarkvarasse piisavalt vara.