EEPOHS Consulting

E-poe loomises on juba kokku lepitud ning potentsiaalsetelt tarnijatelt pakkumisedki kokku korjatud. Pakkumisi vaadates torkab kohe silma, et osa pakub lahendust toetudes mõnele tarkvarapaketile ning osa on valmis tarkvara looma ise. Mõlema poole argumendid tunduvad päris veenvatena, olles samas teineteist välistavad. Kumb variant on siis ikkagi parem?

Algteadmised.

Rätsepatöö valmistatakse kliendi spetsifikatsioonide kohaselt. See seab algteadmistele väga kõrge läve kuna tellija peab peensusteni teadma kõiki oma vajadusi, ka ülitehnilisi ning suutma need tarnijale edasi anda. Kuigi alati jääb alles võimalus tarnijat täielikult usaldada, suurendab selline variant oluliselt lõpptulemuse hinda ning suures plaanis jääb domineerima tarkvara tootja visioon. Valmistarkvara arendatakse juba eksisteerivate klientide vajadustest lähtuvalt; unikaalseid nõudmisi on piiratud hulk ning enamus neist on juba kellegi poolt läbi töötatud. Näiteks Magento nimelist lahendust kasutab hetkel ligi 60000 e-kauplust ning selle funktsionaalsus peegeldab nende kollektiivseid vajadusi ja kompetentsi.

Paindlikus.

Esimese ja suurima argumendina tuuakse rätsepatöö puhul välja selle paindlikus — programmeerijatel on täielik kontroll enda kirjutatud koodi üle ning võimatuid probleeme pole. Praktikas on asi mõnevõrra keerulisem, sest mängu tulevad ka sellised argumendid nagu reaalsed vajadused, tarnijalukk ning eelmises punktis toodud tellija kompetents. Mida see tähendab? Tavaliselt tähendab see seda, et ka valmistarkavara on reeglina sama hõlpsalt laiendatav, sisaldades tihtipeale juba ette seda funktsionaalsust, mille jaoks seda paindlikust vaja on. Sellal kui rätsepatöö puhul on ülevaade koodist ja arendusest vaid ühel firmal, on valmislahenduse puhul võimalik vajaduse korral tarnijat vahetada, lisada projekti teine tarnija või kasutada välist kompetentsi. Siiski ei saa asja nii lihtsustatult võtta, sest eksisteerib projekte ja vajadusi, mille puhul on tõepoolest lihtsam nullist alustada; lihtsalt valdava enamuste projektide puhul pole see põhjendatud.

Hind.

Hinnaga on asi lihtne. Kui tarkvara on loodud vaid ühele kliendile maksab klient kinni kogu arenduskulu. Mida rohkem on sama platvormi kasutajaid, seda odavam on tellijale tüki hind. Enamkasutatavatel lahendustel läheb lõviosa investeeringust mitte tarkvara arendamisesse, vaid hoopis juurutamisesse ning kujundusse. Tegemist on muide väljaminekuga, mida tuleb teha ka rätsepatöö puhul.

Aeg.

Valmistarkvara saab kasutama hakata kohe pärast selle paigaldamist. Praktiliselt kõikidel poepakettidel on mingid vaikeväärtused ja vaikekujundused ning pärast testkeskkonna loomist on juba võimalik sinna sisestada tooteid, mida töö lõppedes on võimalik importida “päris” poodi. Tootekataloogi sisestamine võib võtta kuid ning valmistarkvara puhul ei pea ootama millal arendaja on oma tööga nii kaugele jõudnud, et süsteemi oleks võimalik kasutada.

Risk.

Valmistarkavara puhul on tundmatuid suuruseid oluliselt vähem. Tarkvara valitakse oma vajadustest lähtuvalt, mis tähendab seda, et täpne funktsionaalsus ja juurutamiseks kuluv aeg on selgelt prognoositav. Olukorras, kus tarnija ühel või teisel põhjusel alt veab või lihtsalt ei sobi, on võimalik ta loetud päevade jooksul välja vahetada. Rätsepatöö puhul tuleb halvimatel puhkudel kogu protsessi otsast alustada ning isegi juba lõpetatud komponente kasutades võib ree peale saamine uuel tegijal aega võtta.

Nagu näha on valmislahenduste kasutamisel selged eelised. Kahtlemata on olukordi, kus rätsepatöö kasutamine on põhjendatud. näiteks süvaintegratsioonide puhul olemasolevate lahendustega või puhkudel, kus eksisteerivad rakendused juba pakuvad osaliselt poe funtksionaalsust. Ometigi on sellised olukorrad harvad ning tavaliselt eeldab tellija poolt väga kõrget pädevust antud valdkonnas.