Nedavno smo preuzeli webshop koji generira više od 10 milijuna eura godišnjeg prometa.
Webshop je radio. Kupci su kupovali. Narudžbe su uredno dolazile.
Na prvi pogled nije postojao veliki problem.
Ali kada smo krenuli s preuzimanjem sustava, prva pitanja nisu bila vezana uz nove funkcionalnosti ili razvoj.
Bila su puno jednostavnija:
- Gdje se nalazi aktualni source code?
- Tko ima pristup repositoryju?
- Tko upravlja domenama i DNS zapisima?
- Gdje se nalazi produkcija, a gdje testni sustavi?
- Kako izgleda backup strategija?
- Kako se radi restore?
- Tko reagira ako webshop prestane raditi?
- Postoji li ugovoren 24/7 SLA?
Kod webshopa koji generira više milijuna eura godišnje to nisu samo tehnička pitanja.
To su pitanja kontinuiteta poslovanja.
I vrlo brzo vode do još jednog, možda najvažnijeg pitanja:
Možete li sutra promijeniti partnera koji vam održava webshop?
Što zapravo znači vendor lock-in?
Suradnja s istim ecommerce partnerom pet ili deset godina sama po sebi nije problem.
Dapače, dugoročna suradnja može biti velika prednost jer partner dobro poznaje poslovanje, sustav i procese.
Problem nastaje kada kompanija više nema realnu mogućnost izbora.
Ako promjena partnera znači da je teško doći do source codea, da samo postojeći vendor zna kako sustav radi, da nije jasno gdje se što nalazi ili da bi drugi partner morao praktički ponovno izgraditi velik dio sustava – kompanija se nalazi u vendor lock-inu.
Drugim riječima, problem nije u tome što ne želite promijeniti partnera.
Problem je ako ga ne možete promijeniti bez velikog troška i rizika.
Vendor lock-in obično ne nastane preko noći
Rijetko postoji trenutak u kojem netko donese odluku: "Napravimo sustav koji će biti nemoguće predati drugom partneru."
Lock-in češće nastaje postupno.
Webshop se razvija godinama.
Dodaju se nove funkcionalnosti. Povezuje se ERP. Dodaje se logistika. Otvara se novo tržište. Radi se nova integracija. Negdje se napravi privremeno tehničko rješenje koje nakon nekoliko godina više nije privremeno.
Dok sve radi, nema velikog razloga da se takve stvari preispituju.
Problem postane vidljiv tek kada treba napraviti veću promjenu.
U sustavu koji smo preuzeli, primjerice, dio custom razvoja bio je napravljen direktno u core dijelovima nopCommerce platforme.
To je godinama moglo funkcionirati.
Ali posljedica je bila da je svaki ozbiljniji upgrade platforme postao izuzetno zahtjevan.
A platformu je potrebno nadograđivati zbog sigurnosti, kompatibilnosti, performansi i novih funkcionalnosti.
Ako svaki upgrade postane zaseban veliki development projekt, tehnički dug raste – a s njim raste i ovisnost o ljudima koji znaju zašto je sustav napravljen upravo tako.
Source code je samo jedan dio problema
Kada se govori o vendor lock-inu, često se prvo pomisli na vlasništvo nad source codeom.
To je važno, ali nije dovoljno.
Možete imati source code i svejedno imati sustav koji je drugom partneru izuzetno teško preuzeti.
Potrebno je znati i:
- kako se aplikacija deploya,
- gdje se nalaze pojedini sustavi,
- koje aplikacije međusobno komuniciraju,
- tko ima administrativne pristupe,
- kako funkcioniraju integracije,
- kako se radi backup i restore,
- koje komponente su dio produkcije,
- što će se dogoditi ako se određeni server ili servis ugasi.
Kod našeg projekta jedno od zanimljivijih otkrića bilo je da su se na serverima koji su se smatrali testnim nalazile aplikacije koje su zapravo bile dio produkcijskog procesa.
Takve situacije obično ne nastanu jednom velikom pogrešnom odlukom.
Nastanu postupno.
Nešto se privremeno instalira. Privremeno rješenje ostane. Nakon nekoliko godina više nitko nije potpuno siguran što se smije ugasiti i o čemu što ovisi.
Dok sustav radi, to možda nije vidljivo.
Kada ga treba preuzeti netko drugi, postaje veliki problem.
Pravi trošak vendor lock-ina pojavljuje se kada želite nešto promijeniti
Vendor lock-in ne mora nužno stvarati vidljiv problem u svakodnevnom poslovanju.
Webshop može raditi godinama.
Trošak se najčešće pojavi kada kompanija poželi napraviti nešto novo.
Primjerice:
Želite otvoriti novo tržište.
U našem slučaju postojala su dva zasebna webshopa za dva tržišta, s dva zasebna codebasea.
To znači dvije aplikacije koje treba održavati, dvostruko implementiranje određenih promjena, složenije testiranje i deployment te veći rizik da se funkcionalnosti između tržišta počnu razlikovati.
Platforma je već podržavala multistore koncept, pa smo dva odvojena sustava konsolidirali u jednu aplikaciju s dva storea.
Želite promijeniti način upravljanja produktnim podacima.
Webshop je bio direktno povezan s ERP-om, koji nije služio samo kao ERP.
Bio je i izvor podataka o proizvodima, svojevrsni PIM te dio logističkog procesa.
Takva arhitektura može dugo funkcionirati.
Problem nastaje kada želite novi prodajni kanal, marketplace, novo tržište, novi logistički sustav, pravi PIM ili jednog dana promijeniti ERP.
Tada nešto što je godinama izgledalo kao praktično rješenje može postati ozbiljno ograničenje.
Želite promijeniti development partnera.
Tada prvi put postaje stvarno važno koliko je sustav dokumentiran, tko kontrolira infrastrukturu, koliko je development napravljen prema pravilima platforme i može li novi tim razumjeti sustav bez višemjesečne "analize i istraživanja".
Vendor lock-in zato nije samo pitanje IT-a.
On direktno utječe na cijenu i brzinu budućih poslovnih promjena.
Izlazak iz vendor lock-ina ne znači da morate napraviti novi webshop
Kada se otkrije velika količina tehničkog duga, jedna od prvih ideja često je:
"Najbolje je sve napraviti ispočetka."
Mi se s tim pristupom ne slažemo automatski.
Posebno kada postojeći webshop generira više od 10 milijuna eura godišnjeg prometa.
Izgradnja novog ecommerce sustava ili prelazak na drugu platformu znači veliki projekt, značajan trošak i novi poslovni rizik.
Zato smo u ovom slučaju odabrali postupnu modernizaciju.
Kada se radila određena poslovna dorada, paralelno smo popravljali dio postojeće arhitekture.
Kada smo mijenjali funkcionalnost koja je bila implementirana u coreu, izdvajali smo je u plugin.
Kada su bile potrebne promjene na oba tržišta, dva webshopa konsolidirali smo u multistore arhitekturu.
Kada smo radili na infrastrukturi, razdvojili smo produkcijske i testne sustave te uklanjali stare i nepotrebne komponente.
Tehnički dug tako nije rješavan jednim velikim i skupim projektom.
Rješavan je korak po korak, zajedno s razvojem funkcionalnosti koje su poslovanju ionako bile potrebne.
Kako sustav izgleda danas?
Nakon preuzimanja situacija je bitno drugačija:
- vlasništvo i lokacija source codea su jasni,
- development proces je kontroliran,
- customizacije su izdvojene u pluginove,
- platforma je ponovno pripremljena za buduće upgradeove,
- dva odvojena webshopa konsolidirana su u jedan multistore sustav,
- produkcijska i testna infrastruktura su razdvojene,
- odgovornosti za ključne dijelove sustava transparentnije su,
- identificirane su preostale arhitekturne ovisnosti koje treba postupno uklanjati.
Posao time nije završen.
Jedan od sljedećih koraka je postupno odvajanje odgovornosti PIM-a, logistike i ERP-a.
Ali postoji velika razlika.
Kompanija sada zna što ima, kako sustav funkcionira i kojim ga redoslijedom može modernizirati bez zaustavljanja poslovanja.
Jednostavan test: jeste li u vendor lock-inu?
Postavite si jedno pitanje:
Ako sutra odlučimo promijeniti ecommerce partnera, možemo li mu bez problema predati sustav?
Možete li mu dati pristup aktualnom source codeu i repositoryju?
Znate li tko kontrolira domene, DNS i infrastrukturu?
Postoji li dokumentacija ključnih integracija?
Znate li kako se sustav deploya?
Postoji li dokumentirana backup i restore procedura?
Znate li točno koji sustavi čine produkcijsko ecommerce okruženje?
Može li drugi tim nadograđivati platformu bez potrebe da prvo mjesecima otkriva kako je sustav napravljen?
Ako na nekoliko tih pitanja odgovor glasi "nisam siguran", to ne znači nužno da imate loš webshop.
Ali znači da možda nemate onoliko kontrole nad njim koliko mislite.
Dobar ecommerce partner trebao bi biti zamjenjiv
Možda zvuči paradoksalno, ali jedan od znakova kvalitetnog tehnološkog partnerstva upravo je mogućnost da partnera možete promijeniti.
Source code, infrastruktura, dokumentacija i ključni pristupi trebali bi biti pod kontrolom kompanije.
Development bi trebao slijediti arhitekturu platforme.
Integracije bi trebale imati jasne odgovornosti.
A znanje o sustavu ne bi smjelo postojati isključivo u glavama nekoliko ljudi kod jednog vendora.
Cilj nije imati tehnički savršen webshop.
Cilj je imati ecommerce platformu nad kojom kompanija ima kontrolu i koja joj omogućuje da se razvija sljedećih pet ili deset godina.
Bez obzira na to tko će je tada razvijati i održavati.
Imate webshop koji godinama radi, ali niste potpuno sigurni tko kontrolira source code, infrastrukturu, backup, integracije ili upgrade proces?
To ne znači nužno da vam treba novi webshop.
Možda prvo trebate utvrditi koliko stvarne kontrole nad postojećim sustavom imate, ukloniti najveće rizike i napraviti realan plan njegove postupne modernizacije.
Preuzeli smo webshop s više od 10 milijuna € godišnjeg prometa. Prvi problem nije bio kod.
Webshop može generirati više od 10 milijuna eura godišnjeg prometa, uredno zaprimati narudžbe i prema van izgledati kao potpuno funkcionalan ecommerce sustav.
A da njegov vlasnik pritom ne zna gdje se nalazi source code.
Ne zna tko upravlja DNS-ovima.
Ne zna kakav je backup plan.
I nije siguran ima li ugovoren 24/7 SLA ili podršku samo tijekom radnog vremena.
Upravo s takvom situacijom susreli smo se prilikom preuzimanja jednog postojećeg ecommerce sustava razvijenog na nopCommerce platformi.
Webshop je radio. Kupci su kupovali. Promet se generirao.
Ali ispod površine postojalo je mnogo tehničkog i operativnog duga koji je s vremenom postajao sve veći poslovni rizik.
Problem nije bio samo u tehnologiji
Prvi korak kod preuzimanja nije bio razvoj novih funkcionalnosti.
Bio je odgovoriti na osnovna pitanja:
- Gdje se nalazi aktualni source code?
- Tko ima pristup repozitoriju?
- Tko upravlja domenama i DNS zapisima?
- Gdje se nalazi produkcija, a gdje testni sustavi?
- Kako izgleda backup strategija?
- Kako se radi restore?
- Tko reagira u slučaju incidenta?
- Postoji li 24/7 SLA?
- Koji sustavi ovise jedan o drugome?
Kod sustava koji generira više milijuna eura godišnje to nisu tehnička pitanja.
To su pitanja kontinuiteta poslovanja.
Ako webshop prestane raditi u subotu navečer, nije dovoljno znati ime development agencije. Potrebno je unaprijed znati tko reagira, u kojem roku, s kojim pristupima i prema kojem postupku.
Godine razvoja bez jasnih pravila
Nakon što smo dobili pregled nad infrastrukturom i source codeom, pojavio se drugi problem.
Velik dio prethodnih dorada nije bio napravljen u skladu s preporučenim načinom proširivanja nopCommerce platforme.
Custom izmjene bile su napravljene direktno u core dijelovima sustava.
Rezultat?
Svaki ozbiljniji upgrade platforme postao je izuzetno težak.
Kod ecommerce platformi to je posebno problematično. Platforma se mora moći nadograđivati zbog sigurnosti, kompatibilnosti, performansi i novih funkcionalnosti.
Ako je svaki upgrade praktički novi development projekt, tehnološki dug samo nastavlja rasti.
Zato smo postojeće customizacije postupno izdvojili iz corea i prebacili u pluginove.
Time nismo samo "počistili kod".
Omogućili smo da se platforma ponovno može razvijati i nadograđivati na kontroliran način.
Dvije države, dva webshopa, dva codebasea
Kupac posluje na dva tržišta.
Logično bi bilo očekivati jedan ecommerce sustav koji upravlja s dva storea.
Ali zatečeno stanje bilo je drugačije.
Postojala su dva zasebna webshopa i dva zasebna codebasea.
To znači:
- dvije aplikacije koje treba održavati,
- dvostruko implementiranje pojedinih promjena,
- veći rizik da se funkcionalnosti između tržišta počnu razlikovati,
- složeniji deployment,
- složenije testiranje,
- veći trošak budućeg razvoja.
nopCommerce već podržava multistore koncept.
Zato smo dva odvojena sustava konsolidirali u jednu aplikaciju s dva storea.
Jedan codebase.
Jedno mjesto za razvoj.
Jednostavnije održavanje.
Manji operativni rizik.
I znatno bolja osnova za buduće širenje na dodatna tržišta.
Produkcija na testnim serverima
Jedno od zanimljivijih otkrića tijekom preuzimanja bilo je da su se na serverima koji su se smatrali testnim nalazile i aplikacije koje su zapravo bile dio produkcijskog procesa.
Takve situacije obično ne nastanu jednom velikom pogrešnom odlukom.
Nastanu postupno.
Privremeno se nešto instalira.
Zatim to postane trajno.
Nakon nekoliko godina više nitko nije potpuno siguran što se smije ugasiti, što se koristi i o čemu što ovisi.
Zato je dio preuzimanja bio i infrastrukturni cleanup.
Produkcijski, testni i razvojni sustavi ponovno su jasno razdvojeni, dokumentirani su servisi i njihove odgovornosti te je definirano što čini stvarni produkcijski ecommerce sustav.
ERP je bio ERP, PIM i logistička platforma
Sljedeći izazov nije bilo potrebno riješiti odmah, ali ga je bilo potrebno jasno identificirati.
Webshop je bio direktno povezan s ERP sustavom.
ERP nije služio samo za financije i poslovne procese.
Koristio se i kao:
- izvor produktnih podataka,
- svojevrsni PIM,
- dio procesa za logistiku,
- sustav preko kojeg se upravljalo informacijama potrebnim za slanje paketa.
Drugim riječima, arhitektura praktički nije bila decoupled.
Promjena u jednom sustavu mogla je imati posljedice na više drugih procesa.
Takva arhitektura može godinama funkcionirati.
Problem nastaje kada poslovanje želi brže uvoditi promjene.
Novi prodajni kanal.
Marketplace.
Treće tržište.
Novi logistički partner.
Novi PIM.
Promjenu ERP-a.
Tada čvrste integracije vrlo brzo postanu ograničenje.
Zato sljedeća faza modernizacije uključuje postupno odvajanje odgovornosti:
ERP treba raditi posao ERP-a.
Produktnim podacima treba upravljati sustav specijaliziran za produktne podatke.
Logistički proces treba imati jasno definirano integracijsko sučelje.
A ecommerce platforma ne smije ovisiti o detaljima implementacije svakog pojedinog sustava u pozadini.
Najvažnije: nismo radili veliki rewrite
Kod ovakvih sustava često se pojavljuje ideja:
"Najbolje je sve napraviti ispočetka."
Mi se s tim pristupom ne slažemo automatski.
Pogotovo kada postojeći webshop generira više od 10 milijuna eura godišnjeg prometa.
Veliki rewrite znači veliki projekt, veliki rizik i vrlo često vrlo veliki trošak.
Umjesto toga odabrali smo postupnu modernizaciju.
Kada se radila određena poslovna dorada, paralelno smo popravljali dio postojeće arhitekture.
Kada se mijenjala funkcionalnost koja je bila implementirana u coreu, prebacivali smo je u plugin.
Kada je bilo potrebno raditi promjene vezane uz oba tržišta, konsolidirali smo dva webshopa u multistore arhitekturu.
Kada se radilo na infrastrukturi, uklanjali smo stare i nepotrebne produkcijske komponente s testnih servera.
Drugim riječima, tehnički dug nije riješen jednim velikim i skupim projektom.
Rješavan je planski, korak po korak, zajedno s razvojem poslovno potrebnih funkcionalnosti.
Zbog toga kupac nije bio izložen ekstremnim troškovima modernizacije niti velikom "big bang" projektu.
Kako sustav izgleda danas
Nakon preuzimanja:
- vlasništvo i lokacija source codea su jasni,
- development proces je kontroliran,
- customizacije su izdvojene u pluginove,
- platforma je ponovno pripremljena za buduće upgradeove,
- dva odvojena webshopa konsolidirana su u jedan multistore sustav,
- produkcijska i testna infrastruktura su razdvojene,
- odgovornosti za ključne dijelove sustava postale su transparentnije,
- identificirane su preostale arhitekturne ovisnosti koje treba postupno ukloniti.
Posao još nije završen.
Sljedeći veliki korak je decoupling PIM-a, logistike i ERP-a.
Ali razlika je u tome što danas postoji jasan roadmap kako to napraviti bez zaustavljanja poslovanja.
Webshop ne treba zamijeniti samo zato što ima tehnički dug
Ovaj projekt pokazao je nešto što često vidimo kod postojećih ecommerce sustava.
Problem nije nužno platforma.
Problem je način na koji je sustav tijekom godina razvijan i održavan.
nopCommerce može biti kvalitetna osnova za ozbiljan ecommerce sustav.
Ali samo ako:
- postoji kontrola nad source codeom,
- custom development prati arhitekturu platforme,
- postoji jasna infrastruktura,
- odgovornosti su definirane,
- sustav se redovito može nadograđivati,
- integracije nisu nepotrebno čvrsto povezane.
Zato preuzimanje postojećeg webshopa za nas ne znači automatski njegovu zamjenu.
Prvo utvrđujemo što vrijedi zadržati.
Zatim uklanjamo najveće rizike.
I tek nakon toga postupno moderniziramo arhitekturu tamo gdje za to postoji poslovno opravdanje.
Jer cilj nije imati tehnički savršen webshop.
Cilj je imati ecommerce platformu nad kojom kompanija ima kontrolu i koja joj omogućuje da se razvija sljedećih pet ili deset godina — bez ponovnog vendor lock-ina i bez potrebe da svakih nekoliko godina sve gradi ispočetka.
Imate webshop koji godinama radi, ali niste potpuno sigurni tko kontrolira source code, infrastrukturu, backup, integracije ili upgrade proces?
To ne znači nužno da vam treba novi webshop.
Možda vam prvo treba netko tko može postojeći sustav preuzeti, stabilizirati i napraviti plan njegove postupne modernizacije.
Za mnoge tvrtke, ecommerce platforma počinje kao projekt: izgraditi web trgovinu, lansirati je i održavati kad nešto treba popraviti. No kad ecommerce postane važan prodajni kanal, taj model više nije dovoljan.
Platformi trebaju hosting, monitoring, releasi, sigurnosna ažuriranja, integracije, kontinuirani razvoj i netko tko preuzima odgovornost kad nešto krene po zlu.
To je ideja iza Managed Ecommercea.
Više od održavanja
Tradicionalno održavanje često je reaktivno: nešto se pokvari, otvori se ticket, netko to popravi. Managed Ecommerce je širi pristup.
Xiphias preuzima kontinuiranu odgovornost za rad i kontinuirani razvoj ecommerce platforme.
Ovisno o postavi kupca, to može uključivati:
- hosting i infrastrukturu
- backupove i monitoring
- DevOps i CI/CD
- deployment i upravljanje releasima
- ažuriranja platforme i sigurnosti
- upravljanje incidentima i SLA
- operativnu podršku
- kontinuirani razvoj
- tehnički roadmap i periodične ecommerce revizije
Umjesto koordiniranja nekoliko dobavljača, kupac ima jednog tehnološkog partnera odgovornog za rad i daljnji razvoj ecommerce platforme.
Razvojni kapacitet već je uključen
Ecommerce platforma nikad zapravo nije gotova. Poslovni procesi se mijenjaju, potrebne su nove integracije, kupci očekuju nove funkcionalnosti, a manja poboljšanja stalno se pojavljuju.
Zbog toga mjesečna Managed Ecommerce naknada uključuje unaprijed definiran broj razvojnih sati. Ti sati mogu se koristiti za ispravke grešaka, manje značajke, optimizacije i kontinuirana poboljšanja.
Ako se u određenom mjesecu ne iskoriste u potpunosti, preostali sati mogu se prenijeti u sljedeći mjesec.
Ovo kupcima daje predvidljive mjesečne troškove uz zadržavanje fleksibilnosti korištenja razvojnog kapaciteta kad je zaista potreban.
Prelazak ne bi trebao značiti kretanje od nule
Tvrtke često ostaju uz postojeću ecommerce platformu ili dobavljača jednostavno zato što prelazak izgleda preskupo. Čak i kad postoje dobri razlozi za promjenu — zastarjela tehnologija, spor razvoj, ovisnost o dobavljaču ili ograničena fleksibilnost — još jedan velik početni ecommerce projekt teško je opravdati.
Naš pristup je drugačiji.
Za kupce koji ulaze u višegodišnje Managed Ecommerce partnerstvo, Xiphias može značajno smanjiti početni trošak migracije, modernizacije ili ponovne izgradnje. To možemo napraviti jer promatramo ekonomiku cjelokupnog dugoročnog odnosa, ne samo početnog implementacijskog projekta.
Cilj je sniziti prag za promjenu ecommerce postave koja više ne podržava poslovanje.
Dugoročno partnerstvo bez tehnološke zaključanosti
Dugoročan poslovni odnos ne bi trebao značiti trajnu tehnološku ovisnost. Kupci bi trebali zadržati kontrolu nad svojom ecommerce platformom.
Izvorni kod i repozitorij ostaju pod kontrolom kupca, a gdje god je prikladno koristimo etablirane tehnologije koje mogu održavati i drugi implementacijski partneri.
Princip je jednostavan: želimo da kupci ostanu jer partnerstvo stvara vrijednost — ne zato što je promjena partnera tehnički nemoguća.
Krenite s procjenom prelaska na drugi ecommerce sustav
Promjena ecommerce partnera ne bi trebala automatski značiti zamjenu svega. Prvi korak je razumijevanje trenutne postave.
Procjena prelaska (Ecommerce Switch Assessment) može pregledati:
- postojeću platformu
- vlasništvo nad izvornim kodom i repozitorijem
- ovisnosti o dobavljačima
- hosting i infrastrukturu
- integracije
- operativne rizike
- trenutne bolne točke
- kompleksnost migracije
Ponekad zaključak može biti da prelazak trenutno nema poslovnog smisla. Ako ga ima, procjena daje temelj za definiranje pristupa migraciji i Managed Ecommerce modela.
Platforma koja može rasti s poslovanjem
Managed Ecommerce također je osmišljen kao temelj za budući razvoj. Kad je osnovna ecommerce platforma stabilna, dodatne mogućnosti mogu se uvesti kad stvaraju poslovnu vrijednost.
Na primjer:
PIM i podaci o proizvodima
Informacije o proizvodima mogu se odvojiti od ERP-a i ecommercea korištenjem Pimcorea, čime se stvara centralni izvor za opise, atribute, slike, jezike i kanale.
Automatizacija sadržaja proizvoda
Veliki katalozi mogu imati koristi od automatiziranih opisa proizvoda, obogaćivanja, kategorizacije i prijevoda.
B2B ecommerce
Ručne narudžbe primljene putem e-maila ili telefona mogu postupno prijeći na digitalno samoposluživanje kupaca.
Međunarodna ekspanzija
Platforma se može pripremiti za dodatne jezike, tržišta i web trgovine.
Upravljačko izvještavanje
BladeFX može pružiti ecommerce KPI-jeve, operativne izvještaje i upravljačke dashboarde bez potrebe za velikim BI projektom od prvog dana.
Ove mogućnosti mogu se dodavati postupno umjesto pokušaja rješavanja svega u jednom velikom transformacijskom projektu.
Ključne poruke
Managed Ecommerce nije jednostavno ugovor o održavanju.
To je dugoročni operativni model za ecommerce koji kombinira:
- Infrastrukturu, DevOps i operacije
- SLA, monitoring i operativnu odgovornost
- Mjesečni razvojni kapacitet s prenošenjem neiskorištenih sati
- Kontinuirano poboljšanje i tehnički roadmap
- Niže početne troškove prelaska za dugoročna partnerstva
- Vlasništvo kupca nad izvornim kodom i repozitorijem
- Temelj za PIM, automatizaciju, B2B, izvještavanje i međunarodni rast
Za tvrtke koje su prerasle svoju trenutnu web trgovinu ili ecommerce dobavljača, pitanje ne mora nužno glasiti:
"Koliko će koštati još jedna nova web trgovina?"
Bolje pitanje moglo bi biti:
"Što je potrebno za prelazak na ecommerce model koji se može kontinuirano voditi, poboljšavati i širiti?"