Tarkvara kohandamine firma järgi võib minna kalliks

On väga vähe äritarkvara pakette, mis hakkavad kohe tööle, kui nad n-ö karbist välja võtta, alati on vajalik mingisugune kohandamine. Tihti tuleb ette võtta äritarkvara täiendav modifitseerimine juhul, kui äritarkvara soovitakse integreerida juba olemasolevate tarkvaralahendustega või kui tarkvara funktsionaalsus pole ettevõtte tarbeks piisav. Kiirelt tarkvara loogika kallale asudes kiputakse tegema rohkem kahju kui kasu, sest igal asjal on alati põhjus ja tagajärg. Tarkvara on kirjutatud selleks, et ta suudaks ühtse tervikuna pakkuda võimalikult suurt kasutegurit. Asendades terasketis ühe lüli jämeda niidiga, on terve kett täpselt nii tugev kui asendatud lüli.

Kas on lihtsam, odavam ja nutikam muuta tarkvara vastavalt ettevõttele või ettevõtet vastavalt tarkvarale? Kuna inimeste harjumusi on raske muuta, kiputakse üldiselt vaatamata hoiatustele rutakalt valima esimest lahendust. Kallile tarkvarale asetatakse palju ootusi ning miskipärast on levinud seisukoht, et kui juba kallis tarkvara sai ostetud, peab see painduma vastavaks ettevõtte äriprotsessidele. Samas unustatakse, et tarkvara tootjal on tavaliselt rohkem kogemusi protsesside osas, kuna nende toodet kasutab suur arv erinevaid ettevõtteid.

Seega aktsepteerides tarkvara poolt ette kirjutatud äriprotsessi, võib ettevõte palju võita, sest protsess on loodud mitmete ettevõtete kogemuste alusel. Tarkvara näiliselt lihtne kohandamine firmale omaseks saanud põhiprotsessidega võib peita endas suuri riske.

Kui kohe muutuste läbiviimise algul võtta aluseks juhendid, mis samm-sammult nõustavad kohandusprotsessi etappe, võib tarkvaraloogika muutmisest isegi asja saada. Väga kliendispetsiifilise lahenduse korral ja ka siis, kui on tugevalt kaldutud kõrvale tarkvara standardlahendusest, võivad aga ettevõtte riskid osutuda vägagi kõrgeks.

Enne kui valida tarkvara või äriprotsessi muutmise kasuks, tuleks silmas pidada järgmist:

- tarkvara kohandamine muudab juurutamisprotsessi kallimaks ja riskantsemaks,- tarkvara kohandamine tähendab edaspidi suuremaid hoolduskulusid,- suuremahuline kohandamine võib tähendada tulevikus loobumist tarkvara uutest versioonidest,- võib jääda sõltuvaks konkreetsest teenusepakkujast,- uue tarkavara kasutusele võtmine tähendab alati ka kasutajate koolitamist. Kas koolitada neid kasutama uut tarkvara või samas ka järgima uut protsessi, ei oma ajaliselt ega rahaliselt suurt vahet.

Majandustarkvara on keeruline moodulitest koosnev kompleksne süsteem, milles ühe osa muutmine mõjutab teist ning enne iga muudatust peaks tehtavaid kohandusi analüüsima. Nõutav on töö käigus tehtud muutused piinliku täpsusega dokumenteerida. Juhul kui tekib komplikatsioone, on vähemalt mingi võimalus, et muudatuste arhiivist leiab kohanduse käigus tekkinud kitsaskoha ning saab selle parandada. Muudatusi dokumenteerimata ei jää teile ühtegi jälge tehtud tööst ning hilisem vigade parandus tuleb valuline.

Kokkuvõttes läheb kallimaks uurida ja koostada tagantjärele kohanduse dokumentatsioon kui kaasata see kohanduse tellimise hetkel kogutöö maksumusse. Sageli ei suuda puudulikust dokumentatsioonist johtuvalt ettevõtte oma inimesed kohandust üle viia, mistõttu tuleb töö iga kord tellida firmaväliselt kallilt konsultandilt.

Alati saab aluseks võtta juba tehtud töö. Teiste vigade või õnnestumiste pealt õppides hoiab kokku raha ja aega, mis on kalli tarkvara muutmise puhul oluline väärtus. Kui äritarkvara pole just testimisjärgus prototüüp, leiab alati dokumenteeritud näidisjuhtumeid, mida juurutamisel aluseks võtta. Samas, kui levinud muudatuste sisseviimisel saab end välise abi kaudu riskidest vabastada, siis unikaalse kohanduse korral ei kao risk kuskile, sest tulemusi on raske ennustada.

Firma vajaduste jaoks modifitseeritud äritarkvara tekitab probleeme olukorras, kus tarkvarapakkuja soovitab minna üle uuele versioonile. Klient on nõus, kuid füüsiliselt pole võimalik muudetud tarkvara uuendada. Kliendi kohandused on tarkvara algversiooni oluliselt moonutanud ning uuendusprotsessist saab keerukas väljakutse. Taolises olukorras peab täpselt välja selgitama kohanduste ulatuse, viima need vastavusse uue versiooniga ja lõpuks kõik veel üle testima. Isegi kui on olemas töövahendid, mis jälgivad ja võrdlevad tehtavaid muudatusi, on suuremahuliste kohanduste korral üleviimine uuele versioonile ajamahukas protsess.

Kohandustega kaasnev suur töömaht versioonivahetuse korral võib võrduda uue tarkvaralahenduse juurutamise mahuga. Maht ja raha on oluline argument, miks edaspidi uute versioonide kasuks ei otsustata. Sellega loobutakse aga uutest paranenud versioonidest, paremast funktsionaalsusest. Kurva näitena võiks siin välja tuua ühe maailma juhtiva turva- ja päästeteenust osutava ettevõtte, kus umbes kümme aastat äritarkvara juurutades muudeti tarkvara sarnaseks ettevõtte ning varem kasutuses olnud tarkvaraga. Täna on nad sunnitud kasutama sama eelmist versiooni, mis on nüüdseks täielikult vananenud ilma igasuguse versioonivärskenduse võimaluseta. Selleks et enda käsutusse saada antud tarkvara uusimad võimalused, on nad sunnitud kogu juurutusprotsessi uuesti teostama, mis aga pole odav lõbu. Dokumenteerimata kohandus või väga mahukad kohandused seovad tarkvarakasutaja konkreetse teenusepakkujaga ning hilisem teenusepakkuja vahetus on keeruline. Sageli ei soovi keegi teenusepakkuja mahukate kohandustega klienti üle võtta, kuna sellega kaasneb rohkem probleeme, kui asi on väärt.

Lihtsam on kohandada oma äriprotsesse tarkvara võimalustele, kui hakata väänama tarkvara vastavaks firma äriprotsessidega. See võib olla ebameeldivam tarkvara kasutajale, kuid märksa mugavam tarkvara administreerijatele. Hea tarkvara sisaldab võimalust seadistada see sobivaks programmi ümber kirjutamata. Inimesed õpivad pidevalt uusi käitumuslikke protsesse ning ka muutunud loogikaga äriprotsesse, mida varem kasutati hoopis teisiti, kiputakse kergelt omandama. Raske uskuda, kuid tihti on standardvahenditega palju lihtsam asju teha ? läheb vaid vaja tarkvara ja väheke loovat mõtlemist. Ei taha väita, et kohanduste tegemine on paha ja riskiderohke, kuid kohandusi tuleb planeerida mõistlikult ja teadvustada üles kerkivaid probleeme enne töö kallale asumist.