See on tõenäoliselt küsimus, millega seisavad silmitsi nii need ettevõtted, kes mõnel põhjusel pole e-poodi veel püsti pannud, kui ka need, kes kaaluvad oma senise platvormi vahetust.
Digitaalse kaubanduse platvormide valik on tohutu, mistõttu nende hulgast optimaalseima valimine võib õige raskeks osutuda.
Kui vaadata BuiltWith.com statistikat Eesti turu kohta, näeme, et levinumad nimed on WooCommerce, PrestaShop, OpenCart, Shopify ja Magento. Antud väljavõtte näol on tegu skaalaga üle kõikide e-poodide, kus tooni annavad pigem väiksemad ettevõtted. Keskmisest suuremate ettevõtete puhul, kus protsesside arv ning üldine keerukuse aste on suurem, on tõenäoline, et valik langeb mõne vähemlevinud ja kitsama fookusega lahenduse kasuks. Näiteks tootmisettevõtete puhul võib kaalukeeleks osutuda D2C (direct-to-customer) fookus.
Kuivõrd sobivaima tehnoloogia valik on samaaegselt oluline, keerukas kui ka märkimisväärseid investeeringuid nõudev, on üsna tavaline, et selles olukorras soovitakse muu hulgas kaasata ka majavälist know-how'd.
Columbus Eesti on üheks selliseks digitaalse kaubanduse kompetentsi omavaks konsultatsiooniettevõtteks. Töötame tihedas koostöös Põhja-Euroopa suurima digitaalsele kaubandusele spetsialiseerunud konsultatsiooniettevõttega Columbus, kus valdkonnaga tegeleb circa 200 eksperti.
Optimaalse tehnoloogia valikul tuleb silmitsi seista paari põhimõttelise küsimusega, allpool on nendest ära toodud paar tehnilisemat laadi. Lisaks on näidatud ka mõned üldised punktid, millest võib erinevaid alternatiive kaaludes abi olla.
SaaS mudel
SaaS (software-as-a-service) mudeli puhul on suurem osa vastutusest, millega ettevõttel muidu endal tuleks tegeleda, teenusepakkuja õlgadel. Ettevõttel pruugib vaid konto registreerida ning seejärel asuda e-poodi seadistama. Töötava e-poe lahenduse saab püsti kiiresti ja ilma IT-osakonda või -spetsialiste kaasamata.
Hinnaskaala on pakutava osas väga lai. Väiksematele ettevõtetele suunatud lahenduste hinnad varieeruvad paarkümnest kuni paarisaja euroni kuus. Suuremate lahendused seevastu võivad maksta kümneid tuhandeid eurosid kuus.
Eelkõige on kallimate lahenduste puhul oodata paremat paindlikkust, samuti rohkem igasuguseid funktsioone out-of-the-box. Seega tuleb meeles pidada, et odavamate platvormide puhul ei saa eeldada, et platvorm on teie ettevõtte jaoks kohandatud, vaid teil tuleb selle asemel platvormiga kohaneda.
Teisest küljest, vähemate võimaluste ja väiksema keerukuse korral on eeliseks võimalus e-pood kiiremini turule tuua (time-to-market).
Plussid
- Ettevõte ei pea ise tegelema süsteemi jõudluse, turvakoopiate, skaleeritavuse jms teemadega;
- Võimalik on e-pood tööle saada suhteliselt väikese eelarvega;
- Vastutus e-poe platvormi tehnilise haldamise (jooksvate paranduste sisseviimine, versiooniuuendused jne) eest on teenusepakkuja õlgadel.
Miinused:
- Funktsionaalsuste osas võib esineda piiranguid, mistõttu ei ole alati võimalik täita mingit hulka ettevõtte poolt kirjeldatud ärinõuetest;
- Probleeme võib tekitada mitmel eri turul tegutsemine (erinevad keeled, valuutad jne).
IaaS ja PaaS mudel
IaaS (infrastructure-as-a-service) või PaaS (platform-as-a-service) lähenemise puhul läheb kindlasti vaja IT-spetsialistide abi. Siin on ettevõttel reeglina konto juba mõne pilveteenuse pakkuja (AWS, Google Cloud, Azure jne) juures olemas ning seal siis tuleb vastav e-poe platvorm installeerida ja konfigureerida. Selline e-poe platvormi kasutusviis on paindlikum ning areneb vastavalt ettevõtte vajadustele.
Plussid
- Ettevõttel on täielik vabadus kohandamaks platvormi oma vajaduste järele;
- Lahendus on paremini kohandatud mitmel eri turul tegutsemiseks (erinevad keeled, valuutad).
Miinused
- Pilvetaristu haldamise eest tuleb ettevõttel ise hoolt kanda;
- Litsentsitasud (juhul, kui ei ole tegu vabavaraga) on sageli pandud sõltuma käibest või tellimuste arvust;
- Ettevõtte vastutada on ka e-poe platvormi versiooniuuendused ning jooksvate paranduste sisseviimine.
E-poe platvormi arhitektuur
Arvestades tulevikuarenguid digitaalse kaubanduse valdkonnas võib see punkt olla kriitilise tähtsusega. Ajalooliselt oleme harjunud nö monoliitsete, kõik ühes platvormidega, milles sisaldub muu hulgas ka lõppkasutajale nähtav ning tema poolt kasutatav front-end kasutajaliides. Viimastel aastatel on aga populaarsust kogunud ka erinevad headless lahendused, kus front-end on back-end’ist eraldatud.
Tuntud platvormid, nagu BigCommerce, WooCommerce, Shopify, Magento jne, kes veel hiljuti olid monoliitsed, on samuti hakanud pakkuma headless alternatiive. Nende kohta öeldakse decoupled seetõttu, et tegu on tagantjärele (retro-fitted, bolted-on) kohandustega, mitte algupäraselt ehitatud API-first headless platvormidega, nagu näiteks Commercetools. Selline tagantjärele ümberehitamine on olnud keeruline ja aeganõudev ning seetõttu on mitmete APIde loomine veel töös.
Hea, ladusalt toimiva terviku kokkupanemine on aga täna veel tõsiseks väljakutseks. Võib tekkida olukord, kus e-poe platvormi töörõõm asendub vigade otsimise ja parandamistega
Arhitektuur, mis iseloomustab aga Commercetools’i, on tuntud kui MACH (Microservices based, API-first, Cloud-native, Headless) ning võimaldab oma e-äri üles ehitada modulaarselt.
Tavaliselt on digitaalse kaubanduse raames vaja mitmeid erinevaid süsteeme (klienditeenindus, tellimuste haldamise, logistika, sisu- ja tootehaldus jne) ning MACH võimaldab valida igast valdkonnast parima (best-of-breed).
Siin aga tuleb meeles pidada, et sellise modulaarse terviku sisse ei satuks nõrku lülisid. Näiteks pole kasu parimast logistika tarkvarast, kui kõiki vajalikke parameetreid ei saa üle kanda majandustarkvarast ja/või e-kaubanduse platvormilt.
Hea, ladusalt toimiva terviku kokkupanemine on aga täna veel tõsiseks väljakutseks. Võib tekkida olukord, kus e-poe platvormi töörõõm asendub vigade otsimise ja parandamistega.
See on põhjuseks, miks selliseid riske minimeerivad ettevõtted eelistavad terviklahendust, nagu näiteks Dynamics 365 Commerce, mis kataks võimalikult suure osa nende vajadustest.
On üldteada tõde, et nii SEO, klientide rahulolu kui ka konversioonimäära seisukohalt oluline tehniline näitaja ükskõik millise veebilehe (toote detailvaade, ostukorv jne) puhul on allalaadimiskiirus. Front-end osas aitab kiirusele palju kaasa Jamstack (JavaScript, API, Markup) arhitektuuri kasutamine.
Pakkuja usaldusväärsus
Endastmõistetavalt on oluline teada lahenduse pakkuja(te) tausta.
Kui tegu on vabavaralise platvormiga, siis peaks arendajate kogukond olema piisavalt suur, et oleks tagatud lahenduse pidev areng ja tulevikuperspektiiv.
Riske minimeerivad ettevõtted eelistavad terviklahendust, nagu näiteks Dynamics 365 Commerce, mis kataks võimalikult suure osa nende vajadustest.
Kui tegu on tasuliste lahendustega, on samamoodi tähtis, et pakkuja investeeriks suuri ressursse platvormi pidevasse edasiarendamisse. Teenusepakkuja majanduslik seis peaks näitama kasvu või püsima vähemalt stabiilne. Halvemal juhul on uute investeeringute kaasamise puudusel pidanud mitmed platvormid uksed sulgema, paremal juhul on need üles ostetud. Sellises tööstusharus nagu e-kaubandus, mille kasv on circa 18% aastas, peaks pakkuja kasvama vähemalt samas tempos.
Referentsid
Viimasena on ära toodud tegelikult kõige olulisem punkt. Et teada saada, kuidas e-poe platvorm praktikas igapäevaelus töötab, soovitan ühendust võtta võimalikult paljude selle lahenduse kasutajatega. See vaev tasub ennast ära, kuna võimaldab saada kinnitust asjaolule, mil määral tegelik kasutajakogemus vastab (või ei vasta) väljalubatule. Lisaks lahendusele tasub uurida ka pakkuja tausta kohta.
Nagu eelneva põhjal juba aimata võib, ei suuda ükski teenusepakkuja olla parim või isegi hea kõiges (B2C, B2B, B2B2C, D2C jne), mida reklaamitakse. Reeglina toimivad veatult küll põhifunktsioonid, kuid igasuguste lisavajaduste osas jääb alati oht, et ettevõttel tuleb oma ärinõudeid hakata kohandama tarkvara järgi, mitte vastupidi.
Kui tunned ennast sellises olukorras ära ja soovid siinkohal nõu pidada, võta julgelt ühendust Columbusega ja arutame, milline võiks olla just sinule sobiv lahendus:
