Architektura Composable w praktyce / Marketplace B2B w branży medycznej  

Architektura Composable jest często polecana firmom, ale właściwie dlaczego? Zamiast mówić o niejasnych korzyściach z „kompozycyjności”, skupmy się na konkretach. To, że system jest „composable” pozwala na wdrażanie nowych kanałów, korzystając z istniejącej infrastruktury i podstawowych zasobów, jednocześnie zachowując wysoką wydajność. 

Na przykład firma sprzedająca przez swoje platformy e-commerce może stworzyć własny marketplace, co pomoże jej umocnić pozycję na rynku, rozszerzyć kanały sprzedaży i oferować szerszy asortyment obecnym klientom. To szczególnie atrakcyjne, gdy takie dedykowane opcje nie są jeszcze dostępne na rynku – wówczas istnieje realna szansa na zostanie liderem. 

Wraz z rosnącą popularnością marketplace’ów i większą świadomością na temat branżowych platform handlowych, a także szybką cyfryzacją dotychczas analogowych sektorów, takich jak opieka zdrowotna, ten obszar działalności staje się coraz bardziej wart uwagi. 

Aby lepiej to zilustrować, postanowiliśmy przeanalizować rzeczywiste case study. Dzięki temu chcemy pokazać nasze myślenie, zwłaszcza w kontekście dostępnych opcji technologicznych, procesu podejmowania decyzji i wdrożenia ostatecznego rozwiązania. 

Nasz przykład: rynek farmaceutyczny 

Istnieje wiele sektorów, w których firmy muszą kupować towary od dedykowanych dostawców, wybierając spośród szerokiej gamy partnerów. Postanowiliśmy skupić się na sektorze farmaceutycznym, choć podobny scenariusz z powodzeniem można zaaplikować także do innych sektorów B2B.  

W omawianej branży wiele się dzieje: 

• Typowa apteka musi kupować setki, a nawet tysiące artykułów medycznych od konkretnych dostawców. 
• Ci dostawcy z kolei sprzedają swoje produkty różnym aptekom. 
• Jak w każdej branży B2B, często istnieje unikalna strategia cenowa dla każdego kontrahenta. Większa skala zamówień pozwala dostawcom zaoferować lepsze warunki.  

Dlatego pojawia się wyraźna potrzeba stworzenia platformy marketplace, która umożliwi wykonanie wszystkich tych operacji w jednym miejscu, jednocześnie zaspokajając indywidualne potrzeby każdego dostawcy i klienta. 

Zamiast zakładać nowy biznes, wyobraźmy sobie, że jeden z dostawców farmaceutycznych chce podjąć tę inicjatywę. To częsty scenariusz przy marketplace, ponieważ niesie ze sobą wiele korzyści: 

• Jako właściciel marketplace można ustalać marże cenowe i czerpać zyski nawet ze sprzedaży produktów spoza własnego asortymentu. 
• Przyciągając innych dostawców, w tym konkurentów, na swój marketplace, zwiększa się ogólna widoczność oferty i penetracja rynku. 
• Szerszy asortyment produktów sprawia, że marketplace jest bardziej atrakcyjny dla potencjalnych klientów, co zwiększa widoczność wszystkich dostawców. 
• Specjalistyczne katalogi mogą obejmować także produkty niemedyczne, co poszerza ofertę. 
• Rozszerzając ofertę na obszary niemedyczne, właściciel marketplace może sprzedawać swoje produkty klientom z innych branż, na przykład weterynarzom, zwiększając sprzedaż. 
• Większy wybór produktów daje platformie marketplace przewagę nad sklepami oferującymi asortyment tylko jednej marki, stawiając jej właściciela na strategicznej pozycji.  

Cele projektu 

Mając na uwadze opisany scenariusz, ustaliliśmy następujące kluczowe cele i zadania: 

• Stworzenie platformy umożliwiającej farmaceutom zakup nie tylko artykułów medycznych, ale także innych niezbędnych towarów. 
• Opracowanie platformy, która może zwiększyć zasięg sprzedaży aptek i stać się główną platformą na rynku. 
• Utrzymanie elastycznej i skalowalnej technologii, z uwzględnieniem przyszłych celów. 

W zakresie funkcjonalności platformy zidentyfikowaliśmy następujące elementy: 

• Indywidualne katalogi produktów i ceny dostosowane do potrzeb każdego klienta w ramach marketplace’u. 
• Wdrożenie logiki automatycznego obliczania marż cenowych, umożliwiające aptekom składanie zamówień z przypisaną marżą, a nie z pierwotną ceną od dostawcy. 
• Dodatkowy panel dla dostawców do zarządzania katalogiem produktów i zamówieniami. 
• Dostęp do API zarówno dla dostawców, jak i nabywców, co umożliwi zarządzanie danymi w ich wewnętrznych systemach. 

Oczywiście, klient ma także przyszłe cele, które obejmują: 

• Rozszerzenie marketplace o dodatkowe produkty, takie jak chusteczki, rękawice, maseczki i środki czystości, które choć niemedyczne, są niezbędne dla funkcjonowania aptek. 
• Rozważenie uwzględnienia w rynku firm o mniejszym asortymencie farmaceutycznym, np. sklepów ortopedycznych czy gabinetów weterynaryjnych, co pozwoli na dalsze poszerzenie możliwości sprzedaży. 
• Rozważenie zastosowania ogólnej architektury dla innych firm, co wymaga elastyczności w dostosowywaniu się do przyszłych celów biznesowych lub nowych kanałów sprzedaży, bez zakłócania wydajności.  

Wyzwania projektowe 

Na podstawie powyższych celów zidentyfikowaliśmy kluczowe wyzwania projektowe, które należy zaadresować: 

• Indywidualny katalog produktów: nie wszystkie apteki mają dostęp do wszystkich produktów farmaceutycznych, więc to wymaga usprawnienia. 
• Indywidualny katalog cenowy: firma musi mieć możliwość ustalania indywidualnych cen dla każdej apteki, z logiką automatycznie obliczającą marże cenowe w systemie ERP. 
• Elastyczna architektura: każde wdrożone rozwiązanie musi być elastyczne, wspierając skalowanie i przyszły rozwój. 
• Krótki czas na wprowadzenie na rynek: preferowany jest krótki czas realizacji wersji MVP. 
• Panel dostawców: dostawcy potrzebują panelu do zarządzania produktami, cenami, stanami magazynowymi i zamówieniami w jednym miejscu. Najlepiej, aby takie dane były dostępne za pośrednictwem API. 
• Obliczanie marż: chociaż dostawcy ustalają ceny, właściciel marketplace powinien mieć możliwość ustalania marż na produkty określonych dostawców i/lub konkretnych aptek. Ta logika różni się od tradycyjnej sprzedaży i większości rozwiązań na platformach marketplace, które pozwalają dostawcom ustalać ceny, a właścicielowi rynku zarabiać procent od sprzedaży. Dlatego większość gotowych paneli marketplace, takich jak Mirakl, nie działa w ten sposób. 

Jak to osiągnąć? 

Po dokładnej analizie potrzeb i celów naszym zadaniem było wskazanie najlepszego rozwiązania. Wśród platform e-commerce dostępnych na rynku, takich jak Spryker, Shopware i Adobe Commerce, skupiliśmy się na dwóch potencjalnych kierunkach. Magento jest bardziej przystępną opcją, ale z tym wyborem wiążą się pewnie wyzwania, podczas gdy commercetools oferuje modułowe podejście lepiej odpowiadające potrzebie skalowalności, choć z wyższym kosztem licencji. 

Rozważaliśmy cztery opcje oparte na tych dwóch platformach oraz kilka narzędzi wspomagających, takich jak Mirakl (jako niezawodny marketplace dla dostawców) i Pimcore (jako PIM). 

Rozpoczęliśmy od analizy najprostszych i najtańszych opcji, z którymi jednak wiążą się pewne ograniczenia. Jeśli dane rozwiązanie nie spełniało głównych celów, przechodziliśmy do bardziej zaawansowanych możliwości. W końcu znaleźliśmy rozwiązanie, które spełnia zarówno wymagania biznesowe, jak i technologiczne.  

Opcja 1 / Standardowe Magento + Mirakl 

Jako pierwszą opcję rozważaliśmy użycie Magento zarówno do frontendu, jak i backendu oraz Mirakl do zarządzania dostawcami. Magento, jako kompleksowe rozwiązanie all-in-one, miało duży potencjał, dlatego postanowiliśmy je przetestować.  

Zalety 

• Czas: to podejście oferuje najkrótszy czas wdrożenia ze wszystkich trzech scenariuszy. 
• Niskie koszty licencji: w tym podejściu inwestor płaci tylko za licencję Mirakl, bez konieczności płacenia za Magento (zakładając, że używamy darmowej, otwartej wersji). 

Wady 

• Brak indywidualnego katalogu cenowego i katalogu produktów: ani Magento, ani Mirakl tego nie zapewniają. 
• Brak obliczeń marż: w tym podejściu inwestor nie jest w stanie wdrożyć logiki niezbędnej do indywidualnego obliczania marży.  

Ogólnie uznaliśmy, że ta konfiguracja nie spełnia wymogów zarządzania zindywidualizowanymi katalogami produktów i strategii cenowych. Chociaż była najtańszą opcją, nie realizowała kluczowych celów poza szybkim czasem wprowadzenia na rynek i nie zapewniała inwestorowi przyszłościowej ani elastycznej architektury. 

Opcja 2 / Personalizowane Magento + Mirakl 

Następnie rozważyliśmy bardziej personalizowane podejście, dostosowując Magento, aby spełnić więcej specyficznych wymagań dla poszczególnych katalogów produktów. 

Plusy 

• Indywidualny katalog: w tym podejściu możemy rozwiązać niektóre problemy z poprzedniego scenariusza. 
• Niskie koszty licencji: zakładając, że ponownie użyjemy wersji open source Magento, inwestor płaci tylko za licencję Mirakl. 

Wady 

• Brak indywidualnych cen dla każdej apteki: z powodu ograniczeń Mirakl i ścisłej integracji między Magento a Mirakl, nie jest możliwe oferowanie aptekom indywidualnie dostosowanych cen. 
• Wyższe koszty wdrożenia: ze względu na większe wymagania dotyczące dostosowania, wdrożenie tego scenariusza zajmie więcej czasu i będzie droższe. 
• Mniej elastyczna architektura: modyfikując Magento, architektura staje się znacznie mniej elastyczna i trudniejsza do przyszłych zmian. 
• Brak obliczeń marż: inwestor ponownie nie będzie mógł wdrożyć logiki potrzebnej do indywidualnych obliczeń marż. 

Ogólnie rzecz biorąc, choć ta metoda pozwalałaby nam wdrożyć katalog, nadal napotykaliśmy na znaczące ograniczenia. Dodatkowo, oprócz wyższych kosztów i dłuższego czasu wdrożenia, ta architektura jest mniej elastyczna z powodu koniecznych, rozbudowanych dostosowań. 

Opcja 3 / Commercetools + Mirakl 

Po przeanalizowaniu potencjału Magento, przyjrzyjmy się teraz elastycznemu, modułowemu rozwiązaniu, które może zapewnić przewagę dzięki architekturze headless.

Zalety 

• Indywidualny katalog cenowy: Commercetools umożliwia wdrożenie spersonalizowanego katalogu cenowego. 
• Większa elastyczność architektury: dzięki mikroserwisowej architekturze Commercetools oraz separacji frontendu i backendu, możemy zapewnić większą elastyczność architektury.  

Wady 

• Brak możliwości obliczania marży: na pierwszy rzut oka wydaje się to niemożliwe. Można wprawdzie wdrożyć logikę marż poza Mirakl, zanim zamówienie zostanie wysłane, ale wiązałoby się to z komplikacjami przy obliczaniu cen, podatków i rozliczeniach z dostawcami.  
• Koszty licencji: w tej opcji inwestor płaci nie tylko za Mirakl, ale także za Commercetools. 
• Wyższe koszty wdrożenia: włączenie Commercetools zwiększa koszty wdrożenia.  

Kluczową zaletą Commercetools jest jego modułowość. Oznacza to, że możemy zacząć od niezbędnej podstawy, zamiast próbować rozbijać monolit i dodawać mikro aplikacje oraz funkcjonalności, których potrzebujemy, zgodnie z zasadami MACH. To rozwiązanie będzie łatwo skalowalne i znacznie bardziej przyszłościowe. 

Oczywiście wadą tego podejścia jest to, że pewna kluczowa logika nie jest wdrożona od razu. Zamiast tworzyć ją od podstaw, możemy nadal korzystać z Mirakl, który został stworzony z uwzględnieniem wielu naszych potrzeb. 

Opcja 4 / Commercetools + Pimcore  

Ostatecznie rozważaliśmy użycie Commercetools i Pimcore. Wdrożenie systemu zarządzania informacjami o produktach (PIM), w połączeniu z Commercetools, spełniałoby więcej celów. Wprowadzane stopniowo, pozwoliłoby inwestorowi na elastyczność, przechodząc od minimalnej wersji produktu (MVP) do pełniejszej funkcjonalności w miarę upływu czasu. 

Zalety:  

• Koszty licencji: w tej opcji, szczególnie w porównaniu z poprzednią, płacimy tylko za licencję Commercetools. Jeśli nie korzystamy z wersji Community Edition Pimcore, musimy również dodać dodatkową licencję. Jednakże, nasze zamierzone cele są osiągalne na darmowej licencji freemium. 
• Indywidualne katalogi produktów i katalogi cenowe: jest to jedyna propozycja, która zapewnia zarówno indywidualne potrzeby produktowe, jak i cenowe. 
• Kalkulacje marż: dzięki wykorzystaniu Commercetools w backendzie, w końcu możemy obliczać marże na indywidualnym poziomie. Dostawcy mają możliwość dodawania konkretnych cen w panelu Commercetools, ale to mikrousługi logiki marketplace obliczą odpowiednie ceny końcowe na podstawie skonfigurowanej marży przez operatora marketplace. Commercetools umożliwia tworzenie i zarządzanie elastycznymi zasadami cenowymi, co umożliwia precyzyjne dostosowanie marż dla konkretnych dostawców i klientów, zapewniając większą kontrolę i możliwość personalizacji oferty. 
• Wdrożenie etapowe: ponieważ Commercetools jest modułowy, nie musimy wdrażać całego systemu od razu. Możemy skupić się na funkcjonalnościach MVP, a następnie rozszerzyć je o dodatkowe funkcje w późniejszym czasie, jeśli będzie to konieczne. 

Wady:  

• Wysokie koszty wdrożenia: ze względu na charakter tego scenariusza, wiąże się on z najwyższymi kosztami ze wszystkich trzech opcji. Możemy jednak je złagodzić, dzieląc wdrożenie na etapy, w oparciu o priorytet funkcjonalności.  
• Wymagana unikalna logika: to podejście wymaga od nas napisania unikalnej logiki dla Panelu Dostawcy na poziomie różnych systemów, a także procesu rozliczeniowego między inwestorem marketplace a dostawcami. 
• Pracownicy dostawców pracują na 2 systemach: dostawcy ostatecznie będą korzystać z dwóch systemów, ale zawsze możemy rozważyć opcję osadzenia panelu jednego systemu w drugim oraz dalsze wykorzystanie funkcjonalności Single Sign-On (SSO), aby dostawcy mogli korzystać z tych samych danych logowania do dostępu do obu systemów. 

W przypadku opcji 3 doszliśmy do wniosku, że Commercetools i Mirakl pozwolą na szybkie wdrożenie i zaspokoją kluczowe potrzeby MVP, ale mogą pojawić się trudności z obliczeniami marży, jednocześnie zwiększając koszty licencji. Wybór Pimcore’a może pomóc w zminimalizowaniu tych problemów: jest to oprogramowanie typu open-source, co pozwala na korzystanie z wersji freemium. Szacujemy, że będziemy mogli korzystać z wersji Community Pimcore’a, co pomoże uniknąć dodatkowych opłat licencyjnych. 

Commercetools w większym szczególe  

Po pewnym namyśle zdecydowaliśmy się na czwarty scenariusz, korzystając z Commercetools i Pimcore.  

Architektura Composable 

Jedną z największych zalet Commercetools i podejścia do architektury composable jest możliwość najpierw dostarczenia podstawowej infrastruktury, a potem stopniowego jej rozwijania. To przeciwieństwo platform monolitycznych, które wymagają wdrożenia od razu całego systemu. 

PIM  

Narzędzie PIM pomaga dostarczać odpowiednie dane produktowe tam, gdzie są potrzebne. Dzięki interfejsom API idealnie wpisuje się w podejście composable, umożliwiając importowanie i eksportowanie danych. To zapewnia kluczową korzyść dla sprzedawców, a także pomaga klientowi mieć dane zarówno na marketplace, jak i na własnej platformie e-commerce, bez niepotrzebnego dublowania pracy. Jak wspomnieliśmy już wcześniej, ten czwarty scenariusz wiąże się z nieco wyższymi kosztami w porównaniu z poprzednimi opcjami. Aby je zmniejszyć i zapewnić szybsze wdrożenie, a także skutecznie zaimplementować unikalną logikę, zalecamy podzielenie projektu na trzy fazy. Umożliwi to szybsze uruchomienie platformy marketplace – i generowanie zysków – choć z ograniczonymi funkcjonalnościami, które będą stopniowo rozszerzane. 

Faza 1  

Pierwsza faza ma na celu dostarczenie podstawowej wersji marketplace, zarządzanej w pełni po stronie klienta. Wdrożymy platformę e-commerce – Commercetools – i podłączymy ją bezpośrednio do istniejącego systemu ERP firmy. Choć będzie to wymagać pewnej integracji, możemy wykorzystać istniejące dane z ERP, takie jak stan magazynu, ceny i zamówienia do uruchomienia marketplace. Oznacza to, że wszystko będzie zarządzane przez właściciela platformy, a nie poszczególnych handlowców. Celem jest uzyskanie funkcjonalnego MVP, a następnie szybkie dodawanie funkcjonalności w kolejnych fazach. Wydaje się to skomplikowane, ale w praktyce wygląda następująco: tworzymy nowy marketplace, więc jego właściciel może starannie wybierać pierwszych dostawców.  

Ponieważ integrujemy marketplace Commercetools za pomocą API, istniejąca platforma e-commerce klienta nadal będzie działać bez zakłóceń. 

Korzyści tego rozwiązania to: 

• Szybsze wdrożenie funkcjonalnego marketplace, co pozwoli zdobyć przewagę w sektorze. 
• Natychmiastowe korzyści z podejścia headless oferowanego przez Commercetools. 

Faza 2  

W drugiej fazie musimy wdrożyć więcej funkcjonalności. Zrobimy to, integrując Pimcore, który pobierze dane z ERP i wraz z nowymi danymi przekaże je do platformy marketplace. Kluczowym dodatkiem będzie narzędzie Pimcore, które umożliwi handlowcom zarządzanie swoimi produktami. Ceny i stany magazynowe mogą być modyfikowane w panelu Commercetools. W ten sposób więcej szczegółowych danych zostanie przesłanych do Commercetools, gdzie stworzymy panel dla dostawców. Dzięki temu handlowcy będą mogli zarządzać swoimi zapasami, cenami i zamówieniami.   

Korzyści to: 

• Zwiększenie swobody i dostępności dla handlowców. 
• Zapewnienie precyzyjnych informacji o stanach magazynowych i szczegółowych danych dla wszystkich produktów na platformie marketplace, niezależnie od handlowca. 
• Dostarczenie funkcjonalności dla dostawców, właściciela marketplace i użytkowników końcowych. 

Faza 3  

W trzecim i ostatnim kroku możemy zintegrować platformę e-commerce i marketplace w jedno. Dzięki temu produkty własne właściciela marketplace będą bezpośrednio wdrażane na platformę, co znacznie przyśpieszy cały proces.  

Zarówno platforma e-commerce, jak i marketplace otrzymują dane bezpośrednio z panelu Commercetools.  

Korzyści to: 

• Własna platforma e-commerce klienta i marketplace są w pełni zintegrowane, dzięki czemu nie trzeba utrzymywać oddzielnych zestawów produktów i danych. 
• W rezultacie pracownicy oszczędzają znaczną ilość czasu, jednocześnie czerpiąc korzyści z nowej platformy marketplace.  
• Przejście z dwóch oddzielnych platform (e-commerce i rynek) na jedną, która spełnia obie potrzeby, pozwala na redukcję kosztów operacyjnych.  

Wnioski  

Mamy nadzieję, że teraz lepiej rozumiesz, jak różne technologie mogą wspierać Twoje cele związane z transformacją cyfrową. Zarówno Commercetools, jak i Magento mają swoje mocne strony i możemy spełnić najpilniejsze potrzeby, korzystając z obu tych platform. 

Jednak, patrząc na długoterminowe potrzeby, jeden z kierunków stał się zdecydowanie bardziej odpowiedni. Doradzając klientom, musimy uwzględniać zarówno krótko-, jak i długoterminowe cele, prezentując wszystkie opcje. Dlatego wybór technologii ma strategiczne znaczenie dla każdej organizacji. Kiedy rozwijamy tak zaawansowany system, ten wybór będzie miał faktyczny wpływ na przyszły rozwój. Na przykład wybór Magento w tym przypadku spełniłby obecne potrzeby, ale mógłby prowadzić do przyszłych problemów i wolniejszego tempa wzrostu z powodu jego mniejszej elastyczności. 

To jedno z największych wyzwań w planowaniu projektów o  tak dużym zakresie. Nie chcemy spędzać zbyt dużo czasu na planowaniu, ale musimy brać pod uwagę to, gdzie Twoja firma będzie za 10 lat, a to sporo kwestii do rozważenia 😉  

Podsumujmy wszystkie cztery opcje.  

Chcesz dowiedzieć się więcej?  

Nasze analizy zapewniają ogólny przegląd dostępnych opcji architektury. Jednak w przypadku ostatniego rozwiązania zamieściliśmy dodatkowe informacje, które są dostępne tutaj. Jeśli masz jakiekolwiek pytania, jesteśmy tutaj, aby Ci pomóc!