Menu

Polski e-commerce i zarządzanie e-firmą

Nazywam się Paweł Fornalski. Jestem założycielem i prezesem IAI S.A., dostawcy rozwiązań e-commerce dla sklepów internetowych i rezerwacji noclegów dla właścicieli apartamentów i hoteli. Na tym blogu piszę, w oderwaniu od oficjalnych poglądów innych właścicieli i pracowników IAI o tym co mnie prywatnie porusza. Gdybyś chciał się skontaktować pisz na pawel(a)fornalski.pl

Wpisy otagowane : Prestashop

O czym należy wiedzieć wdrażając do swojego sklepu internetowego Magento? [Część 3/4]

pfornalski

Czas na kolejną część z serii. Tym razem napiszę więcej o tym, czemu sami właściciele sklepów internetowych potrafią nakręcać tak bardzo na Magento, czemu nie powiedzą o nim źle gdy go wdrożyli i jak to jest z tą niezależnością od jednej firmy? Jeżeli ktoś zaczął czytanie serii od tego odcinka, zapraszam do przeczytania najpierw Części 1, bo ten post jest kontynuacją, a nie niezależnym artykułem.

Aura tajemniczości

Dzisiejsze systemy do prowadzenia sklepu internetowego to ogromnie wydajne, złożone giganty, prowadzące za rękę obsługę sklepu internetowego, który ma np. 10 tys. zamówień w miesiącu (500 dziennie), każde z towarami, z których część trzeba sprowadzić, część przenieść z innego magazynu, każde opłacane, wysyłane inaczej, do kogo innego, opłacane inaczej. Bez systemu e-commerce, stanowiącego mózg sklepu internetowego, nie da się po prostu tego ogarnąć. Ale przez to, że stanowią doskonale przetestowane, szeroko stosowane systemy ich klienci czują się jednymi z wielu. Co bowiem tajemniczego jest w systemie, który każdy mój konkurent może kupić i uważać, że ma to samo? Gdzie seksapil, splendor i luksus? Czy Jeff Bezos do którego mi daleko, używa czegoś gotowego do prowadzenia Amazona?

Wdrożenie Magento pozwala już tę aurę roztaczać. Nawet jeżeli masz gołe Magento z 1 dodatkiem, to pod to hasło można podciągnąć wszystko. Rozmawiając z inwestorem można go przekonać, że ma się to coś unikalnego, tajemniczego, czego nie mają inni.

Wszystko co nieznane pozwala zbudować nawet najodważniejszą legendę. Czy smoki kiedyś istniały? Tego nie udało się nigdy potwierdzić, a mimo to w dawnych czasach ludzie o nich opowiadali jak o czymś co było pewne bardziej niż to, że ziemia jest płaska. Dzisiaj, ktoś kto twierdziłby że smoki istnieją od razu zostałby w najlepszym przypadku fana gier RPG.

I widziałem to już co najmniej kilka razy, jak sklepy internetowe rosły na SaaS 100-200% rocznie, nagle stwierdzając, że czas porzucić to co ich doprowadziło do dużych przychodów, by nagle, stwierdzić że skoro posiadają ogromny biznes, to w czym problem aby wskoczyć w zarządzanie działem IT i poprowadzić swój biznes internetowy. Inwestor ocenia wzrost osiągany na innym rozwiązaniu i rzadko patrzy, że w firmie nie ma kilku zatrudnionych na etacie informatyków, aby sklep internetowy działał sprawnie. Mimo, że to absurdalne, to niestety ma miejsce.

Tylko w Polsce SaaS jest popularny, ale cały świat stoi Magento, Prestą itp.

Ile jest sklepów internetowych na Magento w Polsce? W czerwcu 2014r. ukazała się prezentacja z wynikami badań. Było ich „aż 1027”. W tym czasie tylko IAI S.A. obsługiwało 2500 sklepów internetowych. Kto chce abyś bardzo wierzył, że Magento to standard? Odpowiedź w pierwszej części serii.

Na bazie kompleksu USA, próbuje się wyłączyć klientom racjonalną ocenę sytuacji, co jest dla nich korzystne. Przecież nie od wczoraj wiadomo, że Polak jak słyszy, że tego używa się „za tzw. granicą” to znaczy, że to jest lepsze. Ale wystarczy popatrzeć na liczby, czyli że np. w takim USA, sam Shopify, czyli SaaS obsługuje sam tyle sklepów co Magento ma na całym świecie łącznie. Oczywiście ten jeden gracz skupia się raczej na małych sklepach, ale to pokazuje jak bardzo . W UK takim sporym graczem jest np. Actinic, również SaaS, który ma ponad 10000 klientów. I jest, to liczba większa niż łączna ilość wdrożeń Magento na tym rynku. Magento jest popularnym systemem i porównując go do Actinic, IAI-Shop.com itd. Jest bardziej popularny. Ale na żadnym rynku nie jest numerem 1. W każdym kraju, to dzięki modelowi SaaS lub kompleksowym, pudełkowym rozwiązaniom, w ostatnich latach e-commerce mógł rozwijać się tak dynamicznie i to SaaS napędzi zmiany, które będą oddawane we wdrożeniach Magento za 3-4 lata.

Można mieć dowolnie wyglądający sklep

To, że na Magento można mieć dowolnie wyglądający sklep a na SaaS nie, da się bardzo łatwo obalić. Każdy duży SaaS ma oddzieloną warstwę prezentacji od aplikacji. Dzięki temu, bez zmiany kodu źródłowego da się wdrożyć dowolny template. Np. w IAI-Shop.com można to zrobić na kilka sposobów, jednym z nich jest całościowa edycja HTML i CSS sklepu przez własne template smarty. Różnica jest taka, że sami wdrożyliśmy i obsługujemy 3000 sklepów internetowych, więc wiemy co trzeba zrobić, aby mieć możliwość budowania dowolnie wyglądającego sklepu. Programiści z Magento nie, bo przecież w razie czego dołoży się dodatek który np. doda bramkę AJAX, przerobi kod i jakoś się da. Można dodawać, tylko po co? Czy kupując samochód musimy jechać do elektryka za rogiem, aby dorobił nam gniazdo zapalniczki?

Przy tej okazji warto wspomnieć, że Magento i Prestę polecają też ludzie od SEO. Służy to oprócz uzasadnieniu, czemu lepiej zrobić to po swojemu, skoro ktoś mógł zrobić to lepiej, temu aby uzyskiwać wyższe budżety. I winne jest temu przyzwyczajenie. Za pracę polegającą na pisaniu tekstów, uzupełnieniu formularzy, umiejętnym prowadzeniu fanpage i bloga nie chcemy płacić zbyt wiele. Co innego, gdy ktoś pisze program. Wtedy jesteśmy skłonni płacić dużo więcej. I nic pod tym względem nie zmieniło się od 9 lat, gdy napisałem „Link popularity za wszelką cenę”. Ten tekst oburzył mnóstwo ludzi i oburzy pewnie to co teraz napisałem. Fakt jest jednak taki, że dzisiejsze pozycjonowanie to głównie umiejętne wykorzystywanie gotowców a nie szczyty sztuki programowania.

Magento daje bezpieczeństwo

Spróbuj obronić tezę, że posiadanie zainstalowanego programu na serwerze do którego ma się SSH, daje bezpieczeństwo. Kilka argumentów, że tak nie jest:

Jeżeli nie jesteś człowiekiem orkiestrą, czyli przedsiębiorcą z wykształceniem informatycznym, programistycznym, administratorem i webmasterem w jednym, musisz opierać się o innych ludzi, czytaj podwykonawców lub pracowników. Co jest bardziej prawdopodobne? To, że firma giełdowa dostraczająca SaaS, zatrudniająca 100 ludzi zniknie, czy to, że Twój znajomy „który ogarnia komputery” i ma trochę czasu wieczorami nie będzie chciał z Tobą już współpracować?

Bezpieczeństwo to także odpowiednia polityka backupu, redundancja itp. Tylko firma robiąca to na dużą skalę (patrz post „Bądźmy poważni - SaaS jest promilem w kosztach sklepu internetowego”) może zaoferować w jednym, niskim koszcie coś co kupione indywidualnie będzie kosztowało nawet kilkadziesiąt tysięcy na miesiąc. Przykład? Macierz która pozwala na blokowe, prawie bezkosztowe snapshoty i szybką archiwizację i przywracanie danych w przypadku np. włamania i wykasowania danych to koszt początkowy kilkadziesiąt tysięcy złotych. Jeżeli kupujesz ją dla siebie, musisz wydać od kilkudziesięciu tysięcy. Jeżeli kupisz macierz bardziej skalowalną, dokładając tylko dyski, jesteś w stanie zbliżać się do kosztu podobnego jak przy zwykłym serwerze. To właśnie efekt skali, gdy masz np. 3000 sklepów.. Jeżeli jej nie masz i nie zainwestujesz w takie rozwiązanie, pewnego dnia, ktoś skasuje Twoje wszystkie dane a Twój backup będzie np. sprzed tygodnia i przywrócenie działania sklepu zajmie Ci np. miesiąc. Pomyśl jak będzie funkcjonował po tym zdarzeniu biznesowo Twój sklep internetowy?

Jakość rozwiązania mierzy się m.in. przez współczynnik SLA (dostępności usługi). Ale nie chodzi o mierzenie SLA serwerów, ale dostępnością poprawnie działającego procesu zakupowego (tzw. COP – Check Out Process). Czyli chodzi o to, przez ile czasy w roku, Twoi klienci mogą faktycznie złożyć zamówienie i poprawnie nawigować po sklepie? A takie SLA w dobrym SaaS wynosi średnio od 99,8% w górę i to wliczając codzienne aktualizacje wgrywane wszystkim klientom. Nikt nie mierzy SLA dla projektów Magento razem wziętych. Ale zaglądam i mierzę to dla kilku byłych klientów. I to SLA potrafi nawet nie wynosić 98%. Takie SLA oznacza, że sklep nie umożliwia zamawiania przez 7 dni w roku lub jak kto woli np. 21 przestoje po 8h dziennie, 56 po 4h dziennie. Zazwyczaj to około 40-50 różnych drobniejszych awarii powodujących niemożliwość zamówienia lub opłacenia zamówienia od paru do kilkudziesięciu godzin.

Internet to mnóstwo niebezpieczeństw, czyhających z każdej strony. A nieudolnie zarządzane sklepy internetowe padają regularnie ofiarą nadużyć. Jedna z autentycznych historii z „własnego systemu” który opowiedział mi ją brzmi w skrócie tak: haker włamał się, zmienił numer konta i firma straciła na tym kilkaset tysięcy złotych, bo wpłaty szły na konto słupa. Mało się nie przewróciła i ten klient już w życiu nie pójdzie na swoje, bo wie, że tylko duże zespoły i duże budżety na R&D pozwalają w tej walce przetrwać. Haker to bardzo zdeterminowana i inteligentna osoba, często znacznie lepiej znająca technologię niż Pan Janek, który jest pocieszny, ale wszystko co umie zrobić to klikać „Dalej” w kreatorze instalacji.

Bezpieczeństwo osiąga się tylko przez częste aktualizacje. Jeżeli nie będziesz aktualizował swojego Windowsa i antywirusa, już po paru tygodniach będziesz miał zainfekowany system? A jeżeli używasz popularnego skryptu OpenSource, sprzed paru lat i go nie aktualizowałeś, to uważasz, że jesteś bezpieczny? A jeżeli instalujesz ładki do samego core systemu, to czy testujesz i aktualizujesz także indywidualnie napisany kod?

Kupuję jakość a jak coś się zepsuje, to nie będę zdany na jedną firmę ...

Pójdźmy dalej w ocenie, niż tylko SLA. Producenci SaaS czy „systemów pudełkowych” mają markę i o tę markę walczą każdym możliwym sposobem. Agencja, która wdraża Magento, nie musi mieć marki. Jeżeli zepsuje sobie opinię, zmieni nazwę z X na Y i nikt już przecież nie pozna, że to Ci sami ludzie, bo „Magento to Magento” (patrz wcześniej). Do tego fajnie się kasuje klienta na etapie pisania sklepu, gorzej jak dochodzi do różnicy zdań, kto co uznaje za błąd w ramach gwarancji. Stąd 2-3 osobowa firma, uwikłana w kolejny projekt w których też ma wyznaczony deadline, nie bardzo ma ochotę poprawić Ci coś za co już wzięli pieniądze i to za darmo

Jak w ekosystemie Magento radzi się z tym problemem? Jednym z nich jest certyfikacja wdrożeń, które mają kończyć się rozbudowaną dokumentacją, tak aby inna firma mogła przejąć projekt i nie zaczynać od nowa. W teorii brzmi dobrze, w praktyce nie. Bo jeżeli mówimy o kosztach, to w takim podejściu rosną one parokrotnie. Póki klient płaci parę razy więcej za czas poświęcony na dokumentację to wszystko gra. Ale tylko laik uważa, że mając dokumentację, nowy zespół będzie rozwijał w pierwszych 3 miesiącach projekt tak samo wydajnie, jak ten który to pisał, to się grubo myli.

Jakość w IT to pochodna 4 kwestii:

  1. Planowania (lub długiego ewoluowania)
  2. Doświadczenia zespołu
  3. Ilości wersji, wdrożeń które w praktyce przetestowały kod, przy założeniu że dotychczasowe błędy zostały usunięte.
  4. Kontrola długu technologicznego

Jeżeli obiektywnie na to popatrzeć to tylko firma oferująca system sklepowy w SaaS, pod jedną marką przez kilka lat może gwarantować samą sobą, że zrobi co w mocy, aby marki nie zepsuć (i stracić wiele lat pracy i ogromnych pieniędzy na budowanie systemu). A wdrażanie przy ograniczonym czasie kodu, którego sklep jest jedynym użytkownikiem, oznacza tyle, że nie otrzymasz tak wysokiej jakości jak w systemie masowym. Każdy błąd, jaki się pojawi w przyszłości będzie usuwany na Twój koszt, o ile nie zdarzy się tak, że biznes na skutek problemu upadnie.

Kod mimo zapewnień, nie będzie pisany pod reżimem kontroli długu technologicznego. Bo czemu miałby? Kod jest  pisany tu i teraz, po to aby zmieścić się w wyznaczonym budżecie czasu i pieniędzy, a Ty żebyś podpisał protokół odbioru. Jeżeli wdrażając Magento, myślisz, że mając dokumentację w razie czego pójdziesz do drugiej firmy i oni dorobią Ci nowe opcje, to niestety grubo się mylisz. Idąc do nowej firmy usłyszysz: „Fajnie że jest dokumentacja, ale to jest źle napisane i musimy to przepisać”.

Mam pełen folder maili od różnych dużych sklepów na Magento, przepraszających że np. przez długi weekend nie można było zamawiać na skutek awarii. Ale teraz zapraszają i dają na zachętę kod rabatowy. W szanującym się SaaS nawet dla jednego klienta taka przerwa byłaby nieakceptowalna. W projektach własnych to standard. Bo przecież nikt nie pójdzie na grupę na Facebooku poświęconą e-commerce aby wrzucać na zatrudnionych przez siebie programistów i administratorów.

Aktualizacja 2015-10-21

Jakimś potwierdzeniem tego co napisałem w tym artykule jest dzisiejsze doniesienie z http://silenceonthewire.com/…/magento-zostalo-zainfekowane-…

"Tysiące stron internetowych opartych o Magento została zainfekowana złośliwym oprogramowaniem
Eksperci od bezpieczeństwa odkryli, że tysiące stron internetowych opartych o platformę Magento, wykorzystujących wtyczkę e-commerce serwisu eBay mogły zostać naruszone i służą teraz do rozprzestrzenia złośliwego oprogramowania."

Nie chcę się pastwić, ale sprawa jest bardzo poważna. W interesie branży i ochrony klientów warto share'ować aby ludzie sprawdzili czy nie mają zainfekowanych sklepów: http://silenceonthewire.com/…/magento-zostalo-zainfekowane-… Czemu atak jest groźny? Bo wygląda na to, że daje dostęp przynajmniej do tabeli z userami (przynajmniej wghttp://www.theregister.co.uk/…/neutrino_exploit_kit_attack…/), co umożliwia po kilku chwilach wejście jako user z uprawnieniami admina do panelu zarządzania, celem np. podmiany kont, czy eksportu danych klientów, bez konieczności faktycznego uzyskania pełnych praw do całej bazy. Warto przy tej okazji sprawdzić, jak zareagują firmy, które zrealizowały klientom dotychczas wdrożenia. Czy zrobią to szybko, rzeczowo, bezpłatnie? Kto pokryje straty i czy sklepy internetowe wyciągną z tej lekcji wnioski?

O czym należy wiedzieć wdrażając do swojego sklepu internetowego Magento? [Część 2/4]

pfornalski

Zgodnie z przewidywaniami, poprzednia część, mocno obrazoburcza wzbudziła ogromne zainteresowanie i sądząc po statystykach, mimo publikacji w sobotę, przeczytała go ogromna ilość osób. Sporo ludzi przesłało swoje uwagi, pytania itp. Nie czekam więc tygodnia, tak jak to poprzednio zaplanowałem, tylko już na następny dzień publikuję drugą część, co stanowi około 50% całości materiału. To fajnie, bo nosiłem się z napisaniem tego artykułu ponad rok, układając go w głowie poszczególne jego części i wstępnie weryfikując moje tezy, także w dyskusjach z ludźmi wdrażającymi Magento. Rozumiem, że to co piszę, może się nie podobać wszystkim. Zwłaszcza tym, którzy oczekują naukowych dowodów. Łącznie tekst będzie miał 9 stron maszynopisu, więc i tak całkiem sporo. Staram się też pilnować prostego języka, który zrozumie właściciel biznesu, a nie jego informatyk. Rozwleczenie wszystkiego i wytłumaczenie dokładniej, wymagało by napisania sporej wielkości e-booka. Założyłem też, że dobre rzeczy o Magento powie sam producent i ludzie, którzy sprzedają takie wdrożenia. Dlatego też „O czym należy wiedzieć” odnosi się do tego, czego zazwyczaj klienci nie słyszą. Ale spokojnie. Oddam Magento należną część i będzie trochę dobrych słów. Cierpliwości. Ta seria liczy 4 odcinki :)

Duzi gracze np. Microsoft polecają Magento

Duzi gracze od hostingu polecają Magento. To dlatego, że później sprzedając zasoby w Azure, dopasowane pod Magento, zamiast sprzedać jeden czy dwa serwery, sprzedają ich 10. Wygodnie jest promować hasło, że taniej wynająć serwer niż programistę do optymalizacji kodu. W SaaS jednak zjawisko wygląda inaczej, przy np. 3000 kopii, bardziej opłaca się zatrudnić programistę, niż wynająć 3000 dodatkowych serwerów.

Jakiś czas temu rozważaliśmy w IAI rezygnację z naszej własnej infrastruktury na rzecz Azure i Amazon. To fajne, wysokopoziomowe środowisko, które się wydaje idealne dla takiej firmy jak IAI. Problemem okazuje się być jednak cena. Przy tym samym kodzie, mocno optymalizowanym, wyszło nam i tak, że klient który płaci np. 2999zł abonamentu (to około 40-100Mbit ruchu WWW, czyli całkiem spory sklep) potrzebowałby zakupu instancji i dopłat które by wyniosły około 5000-6000zł (za same serwery). A więc nasza usługa kosztowałaby powiedzmy z 8000zł zamiast 3000zł za to samo. Przy wdrożeniu Magento nie masz wyboru, ale warto przynajmniej wiedzieć za co przepłacasz.

Kolejny aspekt dodatków do Magento (pisałem o nich w poprzedniej części) to sposób ich działania. Po pierwsze, większość pisana jest jako autonomiczna, czyli pobiera komplet informacji, następnie zwraca je do dalszego przetwarzania lub do „jądra”. A ponieważ to jądro to skrypt w PHP, działa to potwornie wolno. Przykład: w Magento jest dodatek do filtrów. Działają bardzo prosto i prymitywnie, więc musisz dokupić kolejne dodatki dodające np. prezentację ilości towarów przy każdym filtrze. To oznacza, że zamiast generując filtry ustalić od razu jednym zapytaniem SQL z bazy danych ile jest towarów (co zadziała nawet kilka tysięcy razy szybciej), wyciągasz te informacje 2 razy, wysoko-poziomowo, stosując iteratory. A to wolne działanie to nie tylko koszty, ale często brak możliwości odpalenia sklepu. W IAI nie raz braliśmy udział w odpalaniu sklepu, który po np. 2 latach wdrażania Magento, wydaniu fortuny, dojściu do 15 serwerów nadal nie mogli odpalić sklepu, bo działał zbyt wolno.

Magento czy Presta dobrze się skalują”

Zastanawiam się, kto jeszcze ma po przeczytaniu tego co napisałem wcześniej, że Magento jest szybsze i bardziej skalowane tak uważa? Wyjaśnię w wielkim uproszczeniu, aby każdy zrozumiał jak budowany jest duży sklep na Magento. A mianowicie, stawia się kilka serwerów na bazę danych i engine, do tego serwery na zapisanie i obsługę obrazów stron. Tzw. worker przegląda każdy URL sklepu i zapisuje obraz jako plik statyczny. Później gdy klient szuka jakiegoś towaru, wyszukuje się zapisany obraz strony i zwraca szybko klientowi. To jeden ze sposobów rozwiązań na problem wolnego działania Magento o którym pisałem wcześniej.

Jeżeli słyszysz od małej agencji lub tzw. „speca-komputerowca”, że Magento się świetnie skaluje (bo używają go duzi) to zwyczajnie nie wierz mu, i sprawdź np. prezentację Divante (jedna z dużych firm wdrażających Magento) pt. „Skalowalność Magento – Teoria i trochę praktyki”. W tej prezentacji bardzo podoba mi się tzw. Nietypowy problem (CRM, ERP, WMS), 37tys. Produktów, 200-250 sesji jednocześnie. A to jest właśnie charakterystyka typowego sklepu internetowego, średniej wielkości. Nie przeczę, że ktoś może z Magento być w stanie zbudować infrastrukturę giganta. Ale to co wymaga już skomplikowanego podejścia, można mieć już do 2000zł na miesiąc za kompletny system, w dużym SaaS.

Wróćmy do technologii workerów. Niektórzy mylnie zakładają, że ta technologia występuje tylko w Magento. Pewnie jest tak dlatego, że bez cache (workerów) na Magento nigdzie się nie zajedzie poza rozwiązanie developerskie. W IAI-Shop.com mamy też funkcjonalność workerów, którą wystarczy włączyć jednym kliknięciem i system działa tak samo (a nawet lepiej o czym za chwilę). Różnica polega na tym, że ta technologia jest niepotrzebna w małym i średnim sklepie, gdyż koszt działania workerów będzie większy niż koszt generowania stron dynamicznie, zwłaszcza że kod jest bardzo mocno zoptymalizowany. Nie trzeba więc kupować Magento aby mieć generator stron statycznych.

Technologia stron statycznych (generowanych przez workery) ma jeszcze jedną dużą wadę. Ogranicza mocno funkcjonalność. Próżno w typowym sklepie Magento szukać takiej funkcjonalności że np. klient wpisuje kod rabatowy i od tego momentu podczas szukania towarów, filtrowania itp. widzi ceny po przeliczeniu rabatu. A przecież brzmi to jak podstawowa funkcjonalność sklepu internetowego typu IAI-Shop.com prawda? No cóż. Jak już się przekonałem, gdy właściciel sklepu internetowego ma zapłacić z własnej kieszeni np. Pareset dodatkowych tysięcy za taką funkcjonalność z własnej kieszeni, nagle przestaje to być takie potrzebne.

To teraz trochę liczb: Największe sklepy internetowe w tzw. standardowych planach abonamentowych na IAI-Shop.com obsługują ruch na poziomie 300Mbit/s i parę tysięcy requestów na sekundę do stron dynamicznych (czyli tylko strona HTML generowana przez skrypt). Do tego potrzeba maszyny 64-rdzeniowej, która z całą opieką i gwarancją mobilności (bo czuwa nad tym duży zespół prawdopodobnie najlepszych adminów), czyli koszt 8999zł/mc. A mamy też w ofercie indywidualnie konfigurowaną infrastrukturę, w której możemy też zastosować parę serwerów.

Jakiś czas temu byłem konsultantem w jednym z 3 najbardziej znanych sklepów internetowych i zdziwiło mnie to, że sklep ten ma 200Mbit/s w okresie świątecznym. Tylko, że koszt IT w tym przypadku wynosił ponad 200 tys. na miesiąc. Wniosek jest taki, że nasi niektórzy klienci mają większy ruch niż jedna z 3 najbardziej znanych marek w polskim e-commerce.

Więc warto patrzeć realnie, jakie liczby będziesz osiągać w swoim sklepie i ile tej skalowalności realnie będziesz potrzebował na najbliższe 3 lata. Bo przecież i tak nie będziesz miał aktualizacji w swoim Magento. Czyli jego cykl życia i tak nie przekroczy 3 lat. Czy potrzebujesz od razu inwestować w system miliony, aby być zabezpieczonym, skoro możesz wybrać SaaS w którym jeżeli biznes wyjdzie, po prostu zapłacisz 8999zł/mc a jak jednak pójdzie trochę słabiej to np. 599Zł/mc?

Duże sklepy potrzebują dedykowanych rozwiązań

Mit o tym, że duże sklepy potrzebują dedykowanych rozwiązań to mój ulubiony mit. Duże sklepy nie potrzebują dedykowanych rozwiązań, tylko dobrego WMSa (system zarządzania procesami magazynowymi), bo inaczej nie da się prowadzić sklepu internetowego, który wysyła już powyżej 10 tys. przesyłek miesięcznie. Czy to oznacza, że sklep musi wdrażać kernel na bazie którego musi wdrażać i przerabiać dodatki do Magento (patrz wcześniej)? Nie, potrzebuje po prostu WMSa, którego w Magento nie ma.

A te WMS które oferują integrację z Magento działają na tej zasadzie, że trzeba w nich umieścić całą bazę towarów, by następnie przez API pobrać informację o zleceniu (dane klienta, ID towarów) i zaimportować to zlecenie do tego WMS. Obsługa całego zamówienia nie odbywa się w Magento tylko w WMS, który to na koniec, po wysłaniu paczki, ustawia przez API status iż zamówienie jest zrealizowane. Czy do tego potrzeba dedykowanego systemu? Każdy, nawet najmniejszy i najtańszy SaaS oferuje taką funkcję, jak udostępnienie przez API informacji o kliencie i ID towarów i pozwala ustawić status, że zamówienie jest wysłane? Czemu więc, sklepy idą na to, wiedzieć że przepłacą? Albo są gotowe to finansować w imię wyższej wyceny przy sprzedaży sklepu, albo zwyczajnie o tym nie wiedzą. I paradoksalnie, częściej po prostu ludzie o tym wszystkim nie wiedzą.

A na koniec rodzynek: Większość WMS, w tym najpopularniejszy polecany do Magento jest oferowany wyłącznie w SaaS. Czyli klient teoretycznie wdraża własny system, by mieć kontrolę nad kodem, tylko po to, aby kluczowa część jego biznesu była i tak w SaaS. Uwielbiam minę ludzi, którym to pokazuję, zwłaszcza tych którzy wydali kilkaset tysięcy na wdrożenie Magento i myśleli że ich dział IT ma pełną kontrolę nad ich biznesem.

Aura tajemniczości

Od tego, dlaczego niektóre tzw. duże sklepy decydują się na Magento i że czasami wcale nie jest to związane z ograniczeniami SaaS czy jego wadami, zaczniemy trzecią część, którą planuję opublikować w przyszły weekend. Jeżeli nie chcesz, jej pominąć i dowiedzieć się tego, czego nikt inny Ci nie powie, dodaj swój e-mail do newslettera. System bloga wyśle Ci wyłącznie informacje o nowych postach, żadnych reklam.

O czym należy wiedzieć wdrażając do swojego sklepu internetowego Magento? [Część 1/4]

pfornalski

Magento to bardzo popularny na świecie system na podstawie którego jak się podaje, pobrano około 220 tys. licencji. W Polsce od 2-3 lat dosyć mocno promują go rozliczne agencje, te małe i te duże. Sporo firm wychwala Magento czy Prestę, a właściciele sklepów internetowych zdają się ulegać ich namowom zbyt często jak na to dla kogo jest to oprogramowanie.

Co kupuję?

Często w rozmowach z prospektami widzę, że nie mają pojęcia na temat tego czym Magento czy Presta jest. Myślą, że kupują kompletny system, dobry na wszystko. Tym czasem Magento można porównać do kernela Linuxa, nawet nie do samego Linuxa. Na jego podstawie developer musi dopiero zbudować środowisko pracy dla sklepu internetowego, czyli zainstalować to na jakimś serwerze, następnie wdrożyć front-end (odpowiednik środowiska graficznego) i zainstalować aplikacje (dodatki z tzw. Magento Connect). I jak w każdym systemie tego rodzaju (patrz Windows, Linux), aplikacje nie do końca ze sobą działają, więc wdrożenie Magento to dzisiaj wyginanie i przyginanie tych dodatków aby uzyskać coś co działa. W praktyce jednak, jak każda robota robiona na szybko (tak szybko, bo klienci płacą w rozliczeniu Time&Material, więc na myślenie o przyszłości nie ma czasu), robiona jest na tu i teraz. Ruszenie jakiegokolwiek dodatku, aktualizacja czegoś sypie cały domek z kart. Naturalnie nie do wszystkiego są gotowe dodatki. Resztę firma musi napisać od zera, czyniąc z Twojego biznesu pierwszego i jedynego beta-testera i sponsora projektu.

Sam przez pewien czas myślałem, że takie Magento to konkurencja do IAI-Shop.com. Ale im bardziej się mu przyglądałem tym bardziej nie mogłem uwierzyć, że to Magento to jest to Magento. Kto nie wierzy, a ma doświadczenie z dużymi systemami SaaS powinien na Youtube pooglądać filmy z panelu Magento. Magento to po prostu sposób budowania sklepu internetowego. Kolejną sprawą jest to, że agencji które wdrażają Magento jest teraz ze 100 (sklepów działających około 1000). A więc 100 agencji (powiedzmy średnio 3 osobowych) mówiących o Magento będzie bardziej słyszane, niż 3 największe firmy od SaaS odpowiadające za około 80-90% rynku i zatrudniające łącznie z 200 pracowników i stanowiące 3 marki.

Wracając do pytania: Co kupuję? Kupujesz licencję (za kilkadziesiąt tysięcy) a na jej podstawie agencja, którą wynajmujesz pisze (wdraża) Twój sklep. A na to już ludzie nie zwracają takiej uwagi, byle by taniej. Bo przecież Magento to Magento. Nikt nie patrzy, że firma, która go wdraża, nie ma pojęcia o e-commerce, jego doświadczenie jest niewielkie, a certyfikat który uzyskali od Magento (o ile go mają) oznacza tyle, że potrafią instalować dodatki i dopisać własny kod, bez destabilizacji jądra. W efekcie klienci lądują z mało wydajnie napisanym systemem, który wymaga nawet (to nie przesada) 10 razy więcej mocy obliczeniowej niż SaaS. Efektem jest to, że same serwery pod tak napisany sklep kosztują niż SaaS z serwerami, systemem, aktualizacjami, supportem i jeszcze aktualizacjami front-endu.

Kupuję swobodę i elastyczność, a kod jest mój...

To jedna z powszechniej powtarzanych bzdur, że w Magento jesteś na własnym. Magento aktualnie to nie pocieszny skrypt, który był następcą OsCommerce. To dzisiaj ogromne pieniądze inwestora, które muszą przynosić firmie zyski. A więc w każdej kolejnej wersji, bez kompatybilności wstecznej pracuje się nad tym, aby nikt, absolutnie nikt niczego w kernelu nie zmienił. Stopniowo przechodzi się na model, w którym certyfikowany developer musi uzyskać certyfikację wdrożenia, która polega na pokazaniu kodu źródłowego projektu, po to aby sprawdzić sumy kontrolne i upewnić się, że jądro nie zostało zmienione. Wszystko to po to, aby później móc sprzedawać jeszcze lepiej dodatki, od których wzorem Apple Appstore Magento wprowadzi zapewne swoją prowizję.

Sprzedaż dodatków to kolejny powód dla którego firmie nie zależy na rozwijaniu funkcjonalności swojego systemu, stopniowo wręcz usuwając wszystko co tylko można. Klient kupuje więc za coraz więcej, coraz mniej.

Kolejne instalowane dodatki, mają jedną wadę. Każdy z nich testowany jest na czystym Magento, a developer musi tylko zachować standardy programowania (np. Aspektowego). W teorii brzmi to dobrze, ale ma 2 wady:

Nie działa przy dużej ilości dodatków, czyli nawet jeżeli certyfikacja zapewnia spójność jądra, to nie da się uniknąć modyfikacji kodu dodatków lub dopisywania indywidualnego kodu

Jest strasznie powolne, gdyż nie sprzyja optymalizacji kodu. Oczywiście Magento widzi ten problem i dokłada kolejne moduły optymalizujące (jak code-generation), ale jeżeli popatrzymy na ilość serwerów jaka jest potrzebna aby Magento działało, to staje się oczywiste, że to bardzo wolny system, wymagający nawet 10-20 razy większej mocy obliczeniowej, często od kilku do kilkunastu serwerów. Połączenie tych serwerów w całość wymaga drogiej serwerowni (bo nie można tego zrobić na zwykłych dedykowanych serwerach w jakiejkolwiek serwerowni, rozproszonych i korzystających z infrastruktury publicznej).

Część 2

Sprawdź drugą część serii w której znajdziesz jeszcze więcej informacji o tym, czemu Microsoft poleca Magento, jak dobrze skaluje się Magento oraz czy duży sklep potrzebuje dedykowanego rozwiązania?

 

© Polski e-commerce i zarządzanie e-firmą
Blox.pl najciekawsze blogi w sieci