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 : magento

Czy średni polski sklep znajduje się w piwnicy, czy może stanowi fundament?

pfornalski

Tak wiem, dawno nie pisałem. Bo chociaż wiele miałem do powiedzenia, to zazwyczaj rozładowywałem to w dyskusjach na Facebooku albo ktoś inny napisał to za mnie. Miałem od jakiegoś czasu ochotę opisać jak zmieniło moje życie odinstalowanie appki Facebooka na telefonie, ale uprzedził mnie w tym Michał Górecki. Więc zwyczajnie podaję linka i zaoszczędzony czas poświęcę na napisanie czegoś, czego nikt inny nie napisze.

A tym razem napiszę już o czymś o czym pisałem czy to przy okazji epitafium Hoopla.pl 9 lat temu, czy to w serii o Magento (patrz „O czym należy wiedzieć wdrażając do swojego sklepu internetowego Magento? cz. 2” np. Częśc „Duże sklepy potrzebują dedykowanych rozwiązań” i „O czym należy wiedzieć wdrażając do swojego sklepu internetowego Magento? cz. 3”), czyli o tym jak wygląda faktycznie różnica między tzw. Piwnicą i tzw. NiePiwnicą ehandlu. Dla tych, którzy byli zajęci rozwijaniem swojego sklepu internetowego, wytłumaczę że o piwnicy mówiło się parę lat temu na różnych konferencjach branżuni określając sklepy, które nie szukały inwestora i nie pakowały przynajmniej setek tysięcy w unikalne technologie. Na widowni skromni ludzie, którzy uczyli się od wyjadaczy e-commerce managerów znanych marek takich mądrości jnp. „Jak wydać 1,2,3 (you name it) miliony na zbudowanie unikalnej technologii która wyprowadziła sklep z piwnicy”. I taki skromny człowiek, co to ma sklep internetowy realizujący „tylko 5000 czy tylko 20000 zamówień” jechał do siebie na prowincję i myślał o tym jak z piwnicy wyjść.

2 duże projekty developmentowe jakie w ostatnich latach przez polski e-commerce się przewinęły i bływy synonimami niePiwnicy to „Przepisanie Merlina na nowo” i budowa „CDP.pl”. Aby nie zdradzić za wiele tajemnic, których zdradzić mi nie wypada, ograniczę się tylko do ogólnie znanych informacji, składając je w całość.

Akt 1 Merlin.pl

Zacznijmy od Merlina. Merlin.pl od kilku lat stał w miejscu technologicznie. Wspomnę tylko, że przez długi czas liczony w latach nie wprowadzili mobilności, a zakupy po angielsku w postaci słowniczka polsko-angielskiego, ponieważ sklep nie był wielojęzyczny są moim ulubionym żartem branżowym. IT firmy i sklepem opiekował się kilkuosobowy wewnętrzny dział IT. Pojawił się jednak inwestor, grupa Świtalskich, który nie widząc problemów w technologii, konwersji linków, kosztami itp. po prostu przeniósł firmę na napisany „od zera” system, a do tego aby pokazać że bogatemu nikt nic nie zabroni, przeniesiono firmę z Warszawy do Poznania, przy okazji pozbywając się wielu cennych pracowników. Ile wydano na ten proces w tym development, zdradzić nie mogę. Ale jest to kwota bardzo duża, ogromna.

Nie minęło wiele dni w Warszawie i Poznaniu, gdy w mediach ukazały się takie wiadomości:

Merlin.pl złożył wniosek o ogłoszenie upadłości z możliwością zawarcia układu - poinformowała Czerwona Torebka w komunikacie.

Wniosek złożono 28 grudnia br. w Sądzie Rejonowym w Poznaniu.

Problemy Merlin.pl zaczęły się jednak już jakiś czas temu, kiedy część dużych wydawców i dystrybutorów przestało dostarczać książki do polskiego sklepu internetowego. Wszystko przez ogromne zaległości, które narastały przez kolejne tygodnie. ISB News podało, że w połowie grudnia Virtualo, Dante oraz Sejf Danych, wierzyciele Merlin.pl, złożyli wnioski o ogłoszenie upadłości tej spółki obejmującej likwidację majątku. Wcześniej wnioski o upadłość spółki złożyły: Rekman, Herlitz, Perfect Eye Optic, VOL Solutions, Burda Publishing i TM Toys. Umorzony został natomiast wniosek Exorigo – Upos.” cytat ze strony TVN24BIS z 29 grudnia 2015r.. Jak by ktoś się nie dopatrzył to Exorigo-Upos to firma informatyczna która wykonywała usługi informatyczne dla Grupy Świtalskich ... (ciach;)

Merlin.pl został następnie zakupiony, a właściwie przejęty, gdyż jego głównym aktywem była marka a pasywem dług i to niemały. Cytując dalej TV24BIS „Tymczasem, wsparcie dla jednej z największych i najstarszych marek internetowych zaoferował Topmall.

Polska firma zajmująca się działalnością e-commerce na rynku ukraińskim, która teraz swoją działalność rozszerza na polski rynek i zajmie się odbudową znanej marki.

Maciej Szturemski, prezes spółki Czerwona Torebka, właściciela marki Merlin.pl przyznał, że jego firma prowadziła rozmowy na temat rewitalizacji serwisu z różnymi podmiotami, ale tylko Topmall był w stanie spełnić wszystkie warunki umowy.

Co ciekawe, Topmall z tego co wiem, wyrzucił cały wielomilionowy refactoring kodu, logistykę itp. do śmieci, zastosował engine stworzony dla swojego sklepu ukraińskiego. Więc dla niego miało to sens: wycenił tylko markę, klientów i obroty, płacąc miesięczną dzierżawę. I słusznie zrobił. Koniec końców warto popatrzeć jakie wyniki ma dawny hegemon. Otóż w niedawnym wywiadzie, Łukasz Szczepański pisze „W zeszłym roku zrealizowaliśmy ponad 250 tys. zamówień”. Dużo? Rozłóżmy to na części pierwsze. 250 tysięcy zamówień to nie mniej nie więcej jak 20 tysięcy średnio na miesiąc. A to liczba przy której moi klienci się targują jak muszą zmienić abonament z tego za 2499zł na 3599zł na miesiąc za całą obsłuę IT i argumentują to, że ich sklep jest mały ;) Ale pełny obraz daje porównanie tego z przychodami (cyt. „Przychody wyniosły 18,3 mln zł, strata netto - 9,3 mln zł.”). Czyli średnia wartość koszyka wyniosła 73zł brutto. A więc sprzedawano tylko drobnicę i nie dziwi więc w tych okolicznościach strata.

No dobrze, leżącego się nie kopie. Naprawdę super, że Topmall uratował jedną z najstarszych marek-perełek polskiego e-commerce i marka Merlin.pl nie podzieliła losu Vivid.pl, innego dawnego hegemona.

Akt 2 CDP.pl

Drugim z zapowiedzianych sklepów jest CDP.pl. Dzisiaj rano otrzymałem pozornie niewinny email:

Screen_Shot_20170421_at_17.47.45

Już miałem przeskoczyć do kolejnego emaila (patrz. „Masz minutę na podjęcie decyzji, więc wyłącz emocje i pracuj proaktywnie”), ale coś mi w głowie piknęło. Wirtualną półkę ma każdy sklep internetowy IAI-Shop.com od czerwca 2013r. Więc to raczej nie może być przypadek, że sklep który to miał, robi krok wstecz, a nie w przód. I moja intuicja mnie nie zawiodła. Gdy podłubałem głębiej natrafiłem na przeoczony artykuł „To już oficjalne. Zmartwychwstały Merlin przejął e-sklep CDP.pl”. Myślę sobie. O! To grubo się Merlinowi powodzi skoro kupili taki świetny sklep jak CDP.pl, który jeszcze niedawno przykuł moją uwagę największym oficjalnie wydanym budżetem na zrobienie Magento. A jak budowano CDP.pl można obejrzeć na nagraniu Piotra Karwatki z Divante z Auli #125 w Warszawie:

Jeżeli ktoś potrzebuje streszczenia filmu, to Piotr Karwatka bardzo fajnie opowiada o wszystkim co robili, jak zrobili kilka tysięcy commitów do Gita, ilu programistów (6 przez cały czas) + wiele innych osób realizowało pomysły itp. Oczywiście wszystko co opowiedział ma sens i faktycznie wierzę, że tyle czasu poświęcono, bo robiono mniej więcej wszystko to co mamy w IAI-Shop.com, tylko w prostszym i bardziej customizowanym wymiarze. I my spędzamy nawet więcej czasu na development (mamy już 45 programistów). Mówiąc wprost na koniec projektu stworzono najlepszy sklep dropshippingowy jaki kiedykolwiek powstał. I pewnie najdroższy. Bo zamiast jak inni dropshippingowcy wydawać 100 czy 150zł na miesiąc za SaaS, powstał sklep na miarę możliwości polskiego hitu eksportowego. A ile on kosztował Piotr podsumowuje od 16:30 filmu: np.

  • „16 tygodni poświęciliśmy na analizowanie zadań”
  • „48 tygodni zajęło programowanie, to jest ponad 7000 godzin pracy”
  • „to co mnie zaskoczyło to, że prace frontendowe zajęły bardzo dużo, bo zajęły 1600 godzin i to praktycznie było 5 miesięcy pracy 2 osób”
  • „do tego trzeba doliczyć 30% czasu za całej puli godzin dodatkowe na komunikację, czyli na te wszystkie spotkania ...”
  • „to nigdy nie jest takie proste jak się zakłada na początku, bo nie zakładaliśmy takich estymacji na początku, ale nie dało się tego zrobić szybciej”

Jak by ktoś chciał pogłębić temat to polecam drugi film również obejrzeć https://youtu.be/k_LmjlxEwQw bo skoro już wiemy, że to nie działa, to chyba warto tego co mówią Panowie Darek Nazim i Michał Gembicki unikać.

Ale wróćmy do tych kosztów. Podsumujmy tylko to co Piotr Karwatka podał, nie liczmy tych administratorów serwerów (Divante na stronie nadal podawane jest jako Partner Technologiczny), kilkudziesięciu serwerów w architekturze High Availability i nie pastwmy się nad tym, czy to faktycznie jest potrzebne. Sumujmy tylko koszt developmentu. Jak się zsumuje to wszystko to wychodzi około 12 000 -14 000 godzin jak nic. Liczę tylko największe, podane przez Piotra pozycje. Ile to kosztowało? Divante w tym czasie chwaliło się stawką 40-45€ za godzinę. Jak się to pomnoży to wychodzi jak nic co najmniej 2 miliony złotych za samo napisanie CDP.pl. Nie liczę utrzymania, serwerów, administratorów, kosztów pracowników po stronie CDP.pl.

Mijają 2 lata, wszyscy którzy skromnie siedzieli na widowni i skrupulatnie notowali, mogli przyjąć do wiadomości, jak ja sam, że o to od tej pory koszty sklepów internetowych można liczyć w milionach, bo nasz ecommerce do tego dojrzał. A skoro ktoś to wydał i widzi w tym sens, a jest to znana marka to nic, trzeba wydawać tyle samo, wdrażać Magento, zatrudniać pół tuzina informatyków na rok, dwa, trzy i przekuwać śmiałe wizje unikalnych pomysłów w rzeczywistość. No i wydarza się sprzedaż CDP.pl która ujawnia wartość sklepu CDP.pl. I jak szaty opadły to okazało się, że kolejny król jest nagi. 3 miliony złotych (cyt. „Firmy zakończyły właśnie negocjacje. Kwota przejęcia to 3 mln zł. Transakcją objęte są sklep internetowy, marka CDP.pl, domena, oprogramowanie.”) oznacza, że to im po prostu nic nie dało.

Kod warty 2 miliony zł po kosztach odtworzeniowych Divante, marka na której promocję wydano mnóstwo, klienci, przepływy zamówień itp. zostały kupione za 3 mln złotych. Czy mnie to dziwi? Ani trochę, bo 3 miliony byłby ten sklep warty z taką samą sprzedażą na SaaS. Tylko wtedy wynik finansowy byłby zupełnie inny.

Widzę wiele sensu w tym co robi Topmall, kupując marki, które nie wyszły. Tak, czas to sobie powiedzieć, skoro CDP.pl sprzedano po 2 latach od startu za koszt programu, to określenie „nie wyszedł” może być trafne. Bo nie sprzedaje się dynamicznie rosnącego biznesu. Trudno posądzać CD Projekt o brak środków i potrzebę uwolnienia kapitału, skoro w tym roku wypłacają bardzo dużą dywidendę. Czy zachęcam do robienia tego co robi TopMall? Tak.

Topmall widzi sens w efekcie skali, teraz dokładając do tego swój magazyn i logistykę i pewnie poszukując kolejnych inwestorów i dokładając do tego kilka kolejnych marek. Może Empik? ... A nie, Empik już nie pójdzie do Topmall bo UOKiK widział wielkie zagrożenie dla polskiej gospodarki w połączeniu tych 2 sklepów (patrz tutaj).

Epilog

Kolejne i kolejne historie, ja nazywam „hople”, udowadniają mi, że polska piwnica ecommerce, ludzie którzy korzystają z tego co wymyślili inni, łączą to sprawnie, tanio, systematycznie pracując nad jakością stanowią nie piwnicę, ale fundament polskiego ecommerce. W porównaniu do Merlina, CDP czy wielu innych markach, których w tej chwili nie wymienię, średni klienci IAI wypadają jak imponujący potentaci. W ubiegłym roku to oni wygenerowali ponad 4 miliardy złotych wartej sprzedaży, liczonej w milionach paczek. Co więcej, te firmy często generują zyski. Czasami te zyski są nawet na tyle duże, że właścicielom sklepów odechciewa się je rozwijać dalej (patrz „Zbyt syci aby coś zmienić i rosnąć dalej - coraz częściej mam taką obserwację na temat polskiego e-handlu”). Póki co, to sklepy, których znam wiele i obsługuję na codzień, które wysyłają 5000, 20000, 100 000 zamówień miesięcznie stanowią zdrową tkankę ecommerce, utrzymującą jako fundament blogerów, Google, Facebooka itp. Tak, to ecommerce generujący zyski, utrzymuje cały internet w sensie „darmowych treści”. Więc gdy ktoś po jakiejś konferencji, ma ochotę wydać parę milionów na zrobienie raz jeszcze tego co już inni napisali, zapraszam do mnie. Spotkamy się, część przebalujemy, ale więcej Ci z tego po 2 latach zostanie niż jeżeli zlecisz napisanie sklepu internetowego jakiemuś software house.

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?

 

Czemu duże korporacje wykorzystują systemy pisane na zamówienie?

pfornalski

Czasami dostaję takie pytania:

  1. Czemu teraz Presta jest popularniejsza od Magento? Czy jest lepsza?
  2. Czemu niektóre duże korporacje wybierają systemy pisane na zamówienie? Czy są lepsze?

W branży sklepów internetowych, jestem od 15 lat i obserwowałem najpierw hype na OsCommerce. Potem było Magento, bo podobno było darmowe, ale wiadomo było, że nie będzie bo cały model tak wyglądał, że ewidentnie była to penetracja rynku. Teraz jest Presta, bo nie ma po prostu dalej takich obostrzeń licencyjnych jak Magento ma teraz i wszyscy widzą gdzie to zmierza. Ale za Prestą też stoi firma, która pewnego dnia inwestorom musi przynieść zyski. A jak taka firma będzie zarabiała? Na dokręceniu śrubki z licencjami, modułami (typu akceleracja itp.). Ta historia powtarza się co parę lat. 

Przeanalizujmy mit pt. SaaS jest dobry na start a profesjonaliści używają dedykowanych rozwiązań. Dedykowane rozwiązanie to po prostu gotowy system, za którym stoi sztab ludzi, który robi to samo co robi firma w SaaS, tylko na większą skalę, więc koszty jednostkowe są mniejsze. Dzięki powtarzalności i jednej wersji jest to możliwe. Jeżeli system jest customizowany, to zwyczajnie się nie da robić tego z automatu, więc koszt jest wyższy, jak produkcja samochodu na zamówienie. I jeżeli ktoś się ściga na torze Formuły 1 to potrzebuje dedykowanego bolidu. Ale tak na prawdę typowy sklep potrzebuje furgonetki, możliwie taniej, niezawodej i z dobrym serwisem. A customizacja typu kolor lakieru i nadruk na bok oraz wyposażenie wnętrza, w firmie SaaS z bogatymi możliwościami customizacji zrobi na zamówienie. Czy potrzebuje wydawać miliardy aby zbudować samochód customizowany aby mieć np. uchwyt na faktury na kokpicie? Nie. A jeżeli wyda niewielkie pieniądze, to dostanie samochód gorszej jakości, ot np. bez ABS. Ta sama zasada stosuje się do oprogramowania, którego nie przesyłają kosmici, tylko jacyś ludzie muszą napisać i każdy kto programował w życiu cokolwiek, wie że tak to działa.

No więc, może jak nie cena, to możliwości się liczą? W moim przekonaniu to jest tak, że to kwestia skali. Ostatnio opowiadałem o tym na 2 Kongresie eHandlu (patrz " "). Jak ktoś ma skalę dużą (5000 zamówień i więcej) to niech nie sięga po SaaS lekki i przyjemny typu kilknę i dodaję towar na ilość, tylko weźmie profesjonalny system w WMS, gospodarką magazynową, obsługą masową itp. Ale to nadal jest SaaS. Bo SaaS to nie możliwości, ale idea produkcji masowej (patrz post "Bądźmy poważni - SaaS jest promilem w kosztach sklepu internetowego"). I tak jak w sklepie stacjonarnym używasz komputera, systemu operacyjnego produkowanego na masową skalę, tak i nie potrzebujesz zatrudniać ludzi do tego aby mieć profesjonalny sklep internetowy. A sztab ludzi to po prostu minus w bilansie, który niestety może pociągnąć w dół, zwłaszcza gdy rynek się zmienia (a zmienia się co 3 lata) i wiedzie się gorzej, a trzeba wysupłać np. 200 tys. złotych na update systemu do nowych potrzeb.

Kto zatem potrzebuje systemu dedykowanego? Ten, kto nie chce nauczyć się tego co inni latami wypracowali tylko stwierdza "ja wiem lepiej" i jestem taki ważny, że niech inni piszą dla mnie to co mam w głowie. A kto tak mówi? Prezesi dużych i bogatych korporacji. Może to z tego powodu właśnie duże korporacje, do prostych procesów piszą dedykowane oprogramowanie.

Zakup SaaS czy pisanie własnego systemu sklepu internetowego? Video z I Kongresu eHandlu

pfornalski

W tym roku miałem niewątpliwą przyjemność być prelegentem na I Kongresie eHandlu, organizowanym przy okazji VII Targów eHandlu. Sama impreza była zorganizowana bardzo fajnie, profesjonalnie, do tego dopisała też frekwencja i prelegenci. Takie okoliczności motywują mnie do dania z siebie wszystkiego. Dlatego 30 minutowa prezentacja, jaką wygłosiłem na temat tego kiedy warto pisać swój system sklepu internetowego a kiedy skorzystać z gotowego narzędzia SaaS, była dla mnie samego jedną z lepszych i ważniejszych w mojej dotychczasowej karierze.

To co warto zaznaczyć, to że mnóstwo firm poleca Magento. Rzecz tylko w tym, że ostatnie badania rynku przeprowadzone przez jedną z bardziej znanych firm od wdrożeń Magento, wskazują że mimo iż robi to lekko licząc 100 firm, to istniejących w Polsce sklepów internetowych na Magento jest nieco ponad 1000. Dla porównania sklepów internetowych w IAI-Shop.com jest ponad 2500. Skąd zatem takie opinie, że Magento to „standard”? Przede wszystkim z tego, że kupa ludzi żyje z jego serwisowania, rozpowszechniania i przekonywania, że tak jest. I 100 firm przekonujących do Magento może stwarzać wrażenie, że tak jest, nawet gdy jest inaczej. Moim ulubionym momentem, podczas prezentacji innej firmy na Kongresie na temat nowego Magento 2.0 było pytanie z sali jednego z klientów agencji, która prowadziła prezentację, czy to oznacza, że skoro niedawno zrobili mu sklep na Magento 1.4 to czy zrobią mu migrację, była odpowiedź, że „Nie i w praktyce taniej i prościej napisać wszystko od nowa”.

Dlatego mam nadzieję, że moja prezentacja wniesie sporo świeżego powiewu do dyskusji na temat tego co wybrać, gdy otwiera się sklep internetowy lub chce się zmienić np. Magento 1.4. Komu bardziej zależy na zadowoleniu i rozwoju sklepu? Firmie, która bierze co miesiąc niewielką opłatę, czy firmie, która kasuje pieniądze na początku a później zasłania się tym, że klient może iść do dowolnej innej i sobie rozbudować lub poprawić sklep? O tym wszystkim posłuchasz w mojej prezentacji:

Kongres eHandlu: Paweł Fornalski from Fundacja Polak 2.0 on Vimeo.

 

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