Majandustarkvara vahetamine AS K.G.Knutsson näitel

Priit Sassian, Tallinn 2010

 

Arenevas ettevõttes otsitakse pidevalt võimalusi protsesside efektiivsemaks muutmises ning tootlikkuse kasvuks. Tegevusmahtude kasvuga soovitakse saavutada muuhulgas ka efektiivsuse kasvu, et iga uue müügiühiku kohta peaks kulutama vähem ressursse kui eelmise jaoks. Olgu nendeks ressurssideks aeg, inimtööjõud, energia või muud tegevuskulud. Kuidas tõsta efektiivsust läbi IT lahenduse vahetuse ettevõtte tegevust halvamata?

KG Knutsson AS (KGK) põhitegevusala on sõidukite varuosade ja tarvikute hulgi- ning jaemüük. Pealadu ja peakontor asuvad Tallinnas, jaemüügi kauplusi on üheksas Eesti linnas. Kaubade nomenklatuuris on ligi 200 000 toodet.

Aastal 2005, kui KGK’sse tööle läksin, kasutati majandustarkvarana kahte eri programmi, millest ühe programmi puhul oli kasutusel kaks eri versiooni. Raamatupidamises, peakontori hulgimüügis, ostuprotsessis ja pealaos kasutati Hansa Financial (edaspidi HF) ning enamus kauplustes (jaemüügis, hulgimüügis ja laoarvestuses) kasutati RV Soft (edaspidi RV) nimelist tarkvara. Ühes kaupluses oli kasutusel HF väga vana versioon. Lisaks neile kahele oli juhtimisarvestuse ja analüüsi tegemiseks kasutusel programm QlickView (edaspidi QV), mis töötas andemetel, mida majandustarkvarade andmebaasist sai.

Kahe tarkvara kasutamisest tingituna pidime mitmeid protsesse tegema manuaalselt, mõnda protsessi kahekordselt ning ülevaade igapäevases äris toimuvast oli puudulik. Raamatupidamises sisestati klientidelt tulnud laekumised kahte programmi (kliendilt laekus üks summa, osaliselt RV ja osaliselt HF tehtud arved), krediidilimiidid olid samal kliendil kahes süsteemis, ehk topelt. Klient võis RV limiidi ära kasutada, võlgu jääda ja seejärel HF limiiti kasutama hakata. Pealaost kauba tellimisel pidi kauplus manuaalselt tellimuse sisestama, kauba saamisel manuaalselt sissetuleku vormistama. RV kasutaja ei näinud oma süsteemist pealao kaubaseisu, selleks pidi ta sisenema teise süsteemi. Kaupluse müüja ei saanud olla kindel, et ta saab viimase pealaos oleva ja tema poolt RV kaudu kliendile müüdud kauba omale, sest keegi teine võis selle enne endale võtta – ei toiminud reserveerimise süsteem. Info müügi, ladude ja raha kohta oli killustatud mitme andmebaasi vahel. Nende andmete kokkuvõtmiseks QV kaudu tuli arvestada kahe erineva tarkvara omapäradega. Uuenduste rakendamiseks tuli enamasti investeerida kahte tarkvarasse. Töötaja pidi tööle tulemisel õppima ja töö tegemisel valdama kahte tarkvara, mis võib põhjustada rohkem vigu kui ühe tarkvara puhul. Oma professionaalsete oskuste – autondusega seotus – kõrval pidi töötaja aega kulutama tarkvarade õppimise peale.

Kahe tarkvara kasutamise puudused ning ühele tarkvarale üleminemise vajaduse tõin välja mitmel korral juhatuses ja juhtrühmas (osakondade juhid). Algne reaktsioon oli ainult vastuseis. Esmalt seepärast, et emaettevõttes ja Soome sõsarettevõttes on kasutusel Movex, millele aga Eestis puudub tugiteenus. Öeldi, et kui tahate millegile uuele üle minna, siis olgu selleks ka Movex. See meile aga ei sobinud, kuna on väga kallis, parajalt vanamoodne (kuid siiski väga töökindel) ning tugiteenus Eestis puudus. Teiseks ei nähtud muutuses kasu, sest kõik üksikud funkstioonid toimisid päris ilusti. Tervikpilti (ehk kõikide funktsioonide ja juhtimisprotsesside koostoimimist) kõik juhtkonna liikmed ei vaadanud. Lõpuks siiski suutsime jõuda ühisele arusaamisele, et loobume ühest tarkvarast ning hakkame kasutama ainult HF’i.

Muudatuse sellesse otsusesse tõi HF tugiteenust pakkuva Hansa World Estonia (HWE) tegevus ja tegevusetus. Soovisime mitut uuendust, et ettevõtte protsessid efektiivsemaks muuta. Kolm põhilist olid triipkoodisüsteemi ning elektroonilise kataloogi kasutuselevõtt laos ja müügil ning jaemüügilahenduse väljatöötamine. HWE lubas seda teha, projekti kirjeldasime (sh koostasime analüüsi) me nende eest ära, kuid tulemust ei olnud. Tugiteenus lakkas sisuliselt olemast, meie kirjadele enam ei vastatud. Lisaks sellele hakati peale suruma HF uut versiooni “as it is” tingimustel. Uus versioon ei funktsioneerinud vastavalt meie vajadustele (vana versiooni olime korda teinud erilahendustega), kuid see HWE’d ei huvitanud. KGK tegevuse oleks see halvanud. Teiseks hakkas HWE peale suruma uusi litsentsitingimusi. Olemasolev litsents oli tähtajatu ja ilma lisatingimusteta. Uued tingimused sätestasid iga-aastase lisamaksete ning erinevate tasuliste lisateenuste kohustuse. Olime planeerinud juurde osta ligi 30 uut kasutajalitsentsi.

Samal ajal pakuti meile Microsoft Dynamics NAV nimelist tarkvara (NAV), mille müügifirma (kellest sai hiljem meie lahenduse arendaja ja konsultant) argumenteeris väärtustega, mis meile sobisid. Nendeks olid paljude firmade poolt pakutav tugiteenus, üks tarkvara kõikidele funktsioonidele, sobivus meie sõsarettevõtetele Lätis ja Leedus, kerge ühildamine elektroonilise kataloogiga, kahe tarkvaraga seotud probleemide kõrvaldamine. Litsentside hinnast tehti korralik allahindlus, kuid otsustada tuli sisuliselt ühe kuu jooksul. Selle ajaga pidi saama juhtkonna ühele nõule ja tutvuda tarkvaraga. Juhtkonnaga läks kiiresti, sest koos müüjaga rõhusime just neile väärtustele, mis teistele juhtkonnaliikmetele vajalikud. Tarkvaraga jõudsime ja saime tutvuda väga põgusalt. Külastasime üht firmat, kes programmi kasutas ja lasime NAV müüjal lahendusi endale demonstreerida. NAV müüja profiil sobis meile väga hästi: ei olnud väga suur ettevõte, mis tagas parema klienditeeninduse ning lisaks NAV pädevusele olid selle firma konsultandid väga tugevad ka HF alal (kunagised HF arendajad). Viimane on just seepärast oluline, et kauaaegsete HF kasutajatena rääkisime me n-ö Hansa keelt, kui seletasime oma vajadusi ning protsesse.

Projekti KGK poolses meeskonnas olid kõik osakonnajuhid ja kahe suurema kaupluse juhid, projekti üldkoordinaatoriks olin mina. Iga osakonna juht pidi vastutama oma funktsiooni osa eest NAV protsessis, terviklahenduse funktsionaalsuse, koostoimimise, üleminekukohtade (kahe funkstiooni vaheline koht, protsessi üleandmine-vastuvõtmine) eest vastutas üldkoordinaator.

Projekti jagasime järgmistesse etappidesse: analüüs, seadistamine ja ülesehitamine, koolitus ja testimine, rakendamine, fine tuning. Analüüsi ajal kirjeldasime äriprotsessid, vajalikud muudatused nende haldamisel, olemasolevate programmide head ja vead, erilahenduste vajadused. Sedasi mõtlesime läbi oma protsessid, vajadused ning soovid ja tegime arendajale (konsultant) selgeks, kuidas programm meie põhiäri peaks toetama. Seadistamise ajal pandi paika programmi põhifunktsioonid vastavalt meie vajadustele ning äri omapärale. Arendaja nägi seadistamise käigus, mis funkstioonid saab lahendada standardprogrammiga ja kus on vajadus erilahenduste järele. Erilahendused töötati välja. Koolitused hõlmasid KGK poolsete võtmeisikute väljakoolitamist, kes omakorda viisid teadmised oma meeskondadeni. Testimise käigus pidime kõiki funktsioone proovima ning arendajale tagasisidet andma kasutusmugavuse ja vigade kohta. Rakendamise jaoks organiseerisime meeskonna, kes tegi kõik, mis vaja, et vanad programmid maha jätta, vajalik info uude andmebaasi üle tuua ning enne uue programmi kasutust kogu lahendus veel kord testida. Ülemineku jaoks valisime nädalavahetuse, et oleks rohkem aega ootamatuste lahendamiseks. Üleminek toimus kahes etapis, esmalt peakontor ja kuu aja pärast kauplused. Uue lahenduse täiustamisega alustasime kohe, kui põhifunktsioonid tööle saime. See tähendas täiendavate NAVis olevate standardfunktsioonide kasutuselevõttu ja uute programmeerimist.

NAVile ülemineku projekti juhtides avastasin uut ning leidsin kinnitust juba olemasolevatele teadmistele. Toon välja põhilised tõdemused.
Projekti eelarve läheb lõhki, aega kulub rohkem
Põhifunktsioonide kasutuselevõtuks kulus algselt kavandatuga võrreldes ligi kahekordne eelarve. Juurde tuli väga palju erilahenduste programmeerimist. Litsentside kulu on ainult 25% projekti eelarvest. See näitab, kui toores on standardprogramm.
Algselt lubati meie lahendus teha 6 kuuga (sh koolitus). Tegelikult kulus meil alates litsentside ostust (projekti algus) kuni kasutuselevõtuni 22 kuud.

Muudatuste elluviimiseks tuleb kaasata õiged inimesed (võtmeisikud), tunda jõujooni meeskonnas ja müüa kliendi väärtuste põhjal (mitte toote väärtustele rõhudes)
Muudatused lõhuvad töötajate mugavustsooni, sellele ollakse vastu. Projekt sai alguse ühe inimese peas, ta kaasas erinevate võtetega kogu firma. Võtted, mida kasutati, on lihtsad. Tuleb leida õige moment, mingis mõttes tekitada kriis. Kriisi momendil ollakse uuele ja tundmatule vähem vastu. Esmalt leidsin liitlase KGK juhatuse näol. Teades jõujooni juhtrühmas, oli sellest palju abi. Seejärel lähenesin kõikidele juhtrühma liikmetele eraldi ja just nende huvidest lähtuvalt, nende probleeme lahendades. Nagu selgus, olid vastuseisu põhjused väga erinevad. Põhiliselt siiski infonappus, mille tulemusena tundus uus programm keeruline ning kasutu. Selgus, et IT keelsed selgitused jäid töötajatele arusaamatuks. Peale programmi tutvustamist igapäevases töökeeles vastuseis lõppes. Seejärel tegime juhtrühma ühisel koosolekul otsuse uuele tarkvarale ülemineku kohta, leppisime kokku kohustuste ja vastutuste jagamise. Koosoleku lõpus oli ehe reaktsioon ühe juhtrühma liikme poolt: “Me oleks pidanud juba aasta varem tarkvara ära vahetama!”.

Vastuseis uuendustele on alati olemas, leia viis selle valutuks vähendamiseks, alati leidub virisejaid
Esimene toetus ja liitlased juhtrühma näol olid projektile olemas. Muudatuse edukaks elluviimiseks on vaja, et juhtkond on nendes ühel meelel ja seda ka üheselt väljendatakse. Töötajad ei tohi saada vastakaid arvamusi. KGK’s see saavutati. Järgmisena tuli muudatused maha müüa kogu töötajaskonnale. Arvestasime, et alati jäävad mõned kahtlejad või vastuseisjad, kuid lõpuks peab peavad nad jääma kindlasse vähemusse.
Projekti üldjuhina osalesin kõikidel koosolekutel, kus projekt töötajatele teatavaks tehti. See andis mulle info tulevaste kasutajate kartuste ja ootuste kohta, mida sain hiljem alati arvestada ja kasutada. Vastuseisu põhjuseid oli erinevaid. Näiteks harjumus olemasolevate programmidega, väljakujunenud protsessid (milles inimesed tundsid end kindlalt), IT alased vähesed oskused (uus programm tuleb selgeks õppida), NAVi mõnede protsesside keerulisem haldamine kui HF’s ja RV’s ja lihtsalt soov kõigele vastu olla. Viimasega me ei tegelenud. Teiste põhjuste likvideerimiseks kasutasime põhiliselt kahte võtet: veenmine ja kaasamine. Veenmine käis lihtsate näidetega. Me ei kaasanud IT inimesi, sest IT keel on enamusele mõistmatu. NAV konsultant võib olla küll suurepärane tarkvara tundja, kuid kliendi äri teab klient ikkagi paremini. Kliendi töötajad räägivad kliendi keeles. Läheneda on vaja lihtsate näidetega, töötajate igapäevasest elust. Kaasasime iga funkstiooni töötajatest nn arvamusliidrid. Osaliselt kattus see juhtrühmaga, kuid osakondade sees on veel omakorda teatavat mõjuvõimu omavad isikud. Lõppkokkuvõttes võibki öelda, et projekt ei ole ainult IT alane, 50% on psühholoogia.

Tarkvara ostad nagu “põrsa kotis”, tegelikkus tuleb välja reaalselt kasutades
NAV lahenduse ostmine oli “põrsas kotis”. Otsus omab väga suurt mõju. KGK’s mõjutas see otsus 75 inimest, NAV eelarvet 2,5 mil krooni ja kõiki äri protsesse. Vale otsus tähendaks hinnanguliselt 10-15% vähem müüki, mis on 32 mil krooni. Microsofti tarkvara tutvustus on ilus jutt, kuid sisu sellel ei ole. Sisu tuleb anda endal.
Tuuakse välja vaid NAV head pooled. Kõik peaks olema võimalik, kuid jäetakse mainimata lisainvesteeringute vajadus. Puudusi alguses ei paista, need tulevad majandustarkvara puhul välja alles testimise käigus, mis KGK puhul oli alles 12 kuud peale litsentside ostu. Aus ja eetiline tarkvara müüja ei saa eeldada, et klient tunneb programmi, mille ostab. Programmis on tõesti peaaegu kõik vajalikud funktsioonid olemas, kuid need on nii algelised ja põhimõtteliselt kasutud. Isegi dokumendi saatmine PDF kujul otse programmist ei ole standardfunktsioon. Kiireks ja mugavaks jaemüügiks standardlahendus ei sobi, sest vajalik info on killustatud erinevate moodulite vahel, tuleb teha väga palju mittevajalikke klikke ning müügiprotsessi etappidest puudub selge ülevaade.
Tarkvarakindlustus peaks tagama uuenduste tasuta saamise ja vigade parandamise. Olen leidnud neli tarkvara viga, mida on tunnistanud ka arendaja, kuid kõik on parandatud meie enda kulul, sest Microsofti reageerimise kiirus meid ei oleks rahuldanud. Majandustarkvara nii müüma ega ostma ei peaks.

Külmuta uuenduste protsess enne tarkvara kasutuselevõttu
Projekti käigus tuleb palju uusi ja häid ideid. Vastutav isik peab nendest valiku tegema. Mingil momendil tuleb uuenduste tegemine külmutada, sest vastasel juhul ei jõutagi kasutuselevõtu etappi. Me nimetasime need hiljem tehtavad uuendused fine tuning‘uks. Hea on lasta ideedel laagerduda, sest umbes pooled tõsised “peab olema” ideed kadusid hiljem ära, unustati. Ideed tulid siis, kui ei tundnud veel programmi ja ei teadnud võimalusi. Kui programmi juba kasutati, selgus, et vajalikud asjad on kas olemas või pole vajagi, sest uus programm on teise loogikaga kui eelmine.

Testi ise ja oma meeskonnaga
Testimise osa on ülimalt oluline ja aeganõudev. Projekti käik näitas, et testimisse tuleb kindlasti kaasata vastavat funktsionaalsust hiljem kasutama hakkavad töötajad, sest nemad teavad oma igapäevase töö nüansse kõige paremini. Tarkvaraarendaja ja juhtmeeskond jätsid tihtipeale äriprotsessile olulised teemad tähelepanuta, sest pidasid neid ebaoluliseks või üldteatuks. Näiteks lao korjamise leht. See on väljatrükitav paber, mille alusel komplekteeritakse tellimus. Järjestasime selle alguses kaubakoodide järgi. See tähendanuks laos parajat lisakulu ja korjamise aeglust, sest kaubad on ladustatud lao aadressidele. Korjamine käib aadresside järjekorras, nii ei ole edasi-tagasi käimist ning teekond on kõige optimaalsem.
Testimine on üks kaasamise viis, sest saime nii inimesed programmiga paremini tuttavaks teha, hajutasime nende kartusi. Töötajad said oma küsimused esitada ja neile vastused pika perioodi jooksul, mitte ei sattunud uue ja võõra programmiga kokku kiirustades ning järsku.
Testimine on tüütu ja seda tõdesin kogu projekti käigus. Mitte keegi ei olnud entusiastlik lahendusi testima. Teisel testpäeval, kui pidime kogu firmaga tegema kõik oma tegevused parallelleselt HF ja RV-ga ka NAVis, tehti peamajast üks müügiarve ja raamatupidamine sisestas mõned kanded. Üks kauplus sisestas ühe müügitehingu. Lõpuks pidin seda ikka suuremas osas ise tegema, kuid see andis väga palju infot ja koolitas mind. Tean nüüd kõiki firmas toimivaid äriprotsesse.

Kaasa kõik funktsioonid ja palju inimesi kohe alguses, kuula nende vajadusi ja kogemust. Räägi oma inimestega nende omas keeles
Majandustarkvara muutmise protsessi tuleb kaasata kõik osapooled, keda see puudutab. Arvan, et meil läks projekt edukalt, kuna kuulasime kõikide potentsiaalsete kasutajate arvamusi. Me ei pidanud kedagi dumbuser’iks ja ei ignoreerinud kellegi arvamust. KGK töötajad on need, kes teavad äri ja teevad äri, IT on teenindav ja toetav funktsioon. Sama töötaja, kes ei oska kõige paremini programmi kasutada või olla kõige parem müüja või raamatupidaja. Esmalt töötaja, siis IT.
Protsess on nii nõrk, nagu on selle kõige nõrgem lüli. Ehk me pidime just dumbuser’it kuulama, et kindlustada kõige nõrgemat lüli. Paljud seadistused ja erilahendused, mida praegu kasutame, tulid just meeskonnalt, mitte arendajalt ega juhtkonnalt.
Esmalt oli vaja saavutada töötajate usaldus ning leida ühine keel. Töötajatega suhtlemisel ei ole IT terminitega midagi teha, see tekitab vaid segadust. Rääkisime laomehega lao keeles, müüjaga müüja keeles ja raamatupidajaga finants keeles. Mida rohkem tunnetati, et programmi ei suruta neile peale ja nende arvamust arvestatakse, seda rohkem neelati alla konks. Lükkasime ideid tagasi argumenteeritult ja selgitustega, liigset demokraatiat vältisime. Sellega vältisime kibestumist ja kindlustasime koostööhuvi püsimise.

Õpetamine on ülimalt oluline, pidev ja jätkuv protsess
Uuele tarkvarale üleminekul on väga oluline kasutajate koolitus. Tagamaks selle, et inimesed ikka ise ka tööd teeks, tegime koolituse kahel viisil. Põhifunktsioonide tutvustuse tegin kõikides osakondades ja demonstreerisin NAV kasutust (projektoriga ekraanile). Kõikide vajalike protseduuride jaoks valmistasime ette juhendid, mille arusaadavust katsetasime testgrupi peal. Me ei kasutanud siin arendaja abi, sest olime kindlad, et suudame ise lõppkasutajale arusaadavamad õppematerjalid teha kui nemad. NAV help funktsioon on tehtud filoloogide tõlke alusel (programmis kasutatavad mõisted ka) ning see on päris kohutav.
Peale NAV kasutuselevõttu oleme pidevalt täiendanud juhendmaterjali selle alusel, mida kasutajad on küsinud. Sõbraliku suhtumisega oleme saavutanud olukorra, kus inimesed julgevad küsida ning ettepanekuid teha. Mõnel korral on juhtunud, et keegi viskab õelat nalja mõne äparduse üle või halvustab kedagi nõrgematest kasutajatest. Projekti eest vastutajana ma seda lubada ei saa, sest siis kapselduks töötajad. Põhimõtteliselt need naljavennad ja teiste arvustajad seda enam avalikult ei tee, sest hoopis nemad on saanud üldise hukkamõistu osaliseks.
Koolitus ei lõppe aga kunagi, see on pidev protsess. Uute lahenduste kasutuselevõtul tuleb alati materjalid valmistada ja kasutajatugi firma sees organiseerida. Kui tulevad pidevad küsimused samalt isikult sama asja kohta, siis suuname nad juhendmaterjali juurde.
Tarkvara juures kaotavad IT inimeste poolt väljatoodavad programmi väärtused – uus tehnoloogia, kiirus, väljatöötaja reputatsioon ning suurus, uued funktsioonid – kohe mõtte, kui programmi kasutada ei osata.

Hea partner võib ka vigu teha, ka neile on iga projekt uus. Vead ei tähenda, et valisid vale partneri.
Programmi müüja ja arendaja ei kujutanud ette, et me NAV nii põhjalikult kasutusele võtame. Arendaja sõnul kasutame programmi funkstioone palju hulgalisemalt kui nende teised kliendid. Samuti ei osanud nad ette näha meie andmete mahtu ning äriprotsessi nüansirikkust. Näiteks, kui meil on 200000 erinevat kaupa ja 10 erinevat ladu, siis kokku on meil 10 x 200000 kaubakaarti. NAVis on protsess, nõudelehe arvutamine, mis annab ostuosakonnale varude täiendamiseks kaupade nimekirja ja kogused. Ühe lao nõudelehe arvutamine võtab aega praegu 45 min. Samal ajal on müügiprotsess häiritud.
Arendaja valikust ja temapoolsest klienditeenindajast (arendaja projekti juht) sõltub väga palju. Projektijuhil on vaja saada kliendiga kontakt, mõista tema vajadusi ja keelt. Projektijuhile tuli kasuks HF arendamise oskus, sest ta sai aru, mida me rääkisime. Arendaja kohustuste hulka kuulus meie lahenduse dokumenteerimine. Lahenduse väljatöötamise protsess toimis koostöös, kus arendaja kirjeldas lahenduse, KGK üldkoordinaator ja vastava funktsiooni eest vastutaja vaatasid selle üle, vajadusel täiustasid. Alles seejärel alustati programmeerimisega.

Mis kõigeks sobib, ei ole millegi jaoks väga hea
Majandustarkvara puhul, vähemalt NAV puhul, pean tõdema, et kehtib tarkus “mis on hea kõigeks, ei ole hea millekski”. Tahtsime ühte tarkvara, milles hallata kõik ettevõtte protsessid. NAV ei ole selleks valmis, sest protsessid segavad teineteist. Näiteks ei saa kaupa müüa ja samal ajal tema kohta ostuarvet (kauba omahinna muutmine) sisestada, sest need kaks protsessi kirjutavad andmeid samadesse tabelitesse. Kuid nii raamatupidamine kui ka müük tahaks tööd teha tööajal. Lisame siia ostu, kes tahaks arvutada ostutellimuste koguseid (nõudelehe funktsioon).
Ehitasime oma lahenduse üles terminalide süsteemile. Server on renditud Microlink’ist ja kõik kasutame seda terminalide kaudu. Nii ei ole riski, kui peamajas server ei tööta, siis poed müüja ei saa. Samal ajal on meil peaaegu online infovahetus. Serverit rentides saame sinna alati ressurssi juurde osta kogu serverit ümber vahetamata. Kõikide nende heade juures on aga printimise funktsioon osutunud keeruliseks. Iga printimise korral tuleb manuaalselt valida printer, kuhu dokumendi prindid. Samuti ei tunnista uus Microsofti server millegipärast kõiki HP printerite driver‘eid. Pidime installeerima vanade printerite driver’id, et printida saaks ja kaotasime osaliselt printerite funktsionaalsust.
Aruandlus standard NAVis on üsna kasutu. Enamus aruandeid ei oma kasutajale väärtust. Seepärast otsustasime jätkata analüüsitarkvara QlickView kasutamist.

Planeerimise ja projektijuhimise ajal ununeb ikka midagi
Projekti juhtides peab alati olema valmis, et midagi olulist unustatakse. Meil juhtus seda mitu korda. Ühe suurema ja olulisemana unustasime oma internetipõhise tellimiskeskkonna. Avastasime selle alles 1 kuu enne planeeritavat ülemineku päeva. Kaotus müügis oleks olnud väga suur, sest üle poole tellimustest tuleb meile läbi interneti. Arendasime kiiresti välja uue keskkonna, alguses põhifunktsionaalsusega, hiljem lisasime informatiivsust ja kasutajamugavusi. Kuna tulime turule oma tellimiskeskonna näol uue tootega, pidime pakkuma midagi, mida teised veel ei pakkunud. Saime mitmelt kliendilt tagasisidet, et meie lahendus on parim turul. Kuid me ise sellega veel rahul ei ole.
KGK on kasutanud uut tarkvara nüüdseks pisut vähem kui aasta. See periood on olnud pidev areng ja ka investeerimine. Inimliku poole pealt avaldub juba see, et meelde jäävad ja välja tuuakse enamasti need nüansid, mis on negatiivsed. Unustatakse aga see, mis positiivne. Uus tarkvara võimaldas meil optimeerida müügiprotsessi, ladude varustamist, ostuprotsessi, nõuete haldamist ja juhtimisinfo täpsust ning ostustajateni jõudmise kiirust. Ilma NAVile üleminekuta ei oleks keskonda www.autokataloog.ee. Palju on investeeritud raha ja tööd, kuid viljad on ka magusad.