Wdrożenie Pimcore PIM – od analizy danych do uruchomienia
Projektujemy i wdrażamy Pimcore jako centralne środowisko zarządzania informacją produktową.
Ustalamy model danych, role zespołów, workflow, integracje oraz zasady publikacji do sklepów, marketplace’ów i pozostałych kanałów.
- model danych
- workflow i uprawnienia
- import i migracja
- architektura integracji
- QA i dokumentacja
Rozproszone dane zaczynają ograniczać sprzedaż i pracę zespołu
Pimcore zaczyna mieć uzasadnienie wtedy, gdy zarządzanie informacją produktową staje się osobnym procesem operacyjnym. Liczba rekordów jest tylko jednym z czynników.
Problem często pojawia się wcześniej niż decyzja o zakupie PIM. Zespół radzi sobie kolejnymi arkuszami, eksportami i ręcznymi kontrolami. Każdy nowy rynek albo kanał zwiększa liczbę wyjątków.
- 01
Ten sam produkt ma kilka wersji danych
Opis, nazwa, parametry albo zdjęcia różnią się między sklepem, marketplace, katalogiem i plikiem partnera.
- 02
Nowy kanał wymaga ponownego przygotowania oferty
Zespół kopiuje informacje, zmienia formaty i ręcznie kontroluje kompletność dla każdego odbiorcy.
- 03
Materiały produktowe nie mają jednego właściciela
Zdjęcia, instrukcje, certyfikaty i tłumaczenia znajdują się w folderach, skrzynkach i systemach różnych działów.
- 04
Akceptacja odbywa się poza systemem
Marketing, sprzedaż, dział produktu i compliance uzgadniają zmiany w wiadomościach albo na spotkaniach.
- 05
Trudno ustalić, która wersja jest aktualna
Zmiana w jednym źródle nie daje pewności, że właściwa informacja trafiła do każdego kanału.
Sama instalacja systemu nie uporządkuje tych sytuacji. Wdrożenie musi określić model danych, odpowiedzialność zespołów i warunki publikacji.
Zobacz, jak Pimcore wspiera e‑commerceProdukt bazowy
- Wariant1:n
- Kategorian:m
- Markan:1
- Kolekcjan:m
- Rynekn:m
- Wersja językowa1:n
- Materiały1:n
- Produkt uzupełniającyn:m
Pola obiektu głównego
- indeks
- nazwa
- opis
- parametry techniczne
- relacje
Model danych w Pimcore – fundament wdrożenia PIM
Pimcore można skonfigurować na wiele sposobów. Docelowa struktura powinna wynikać z rodzaju produktów, zależności między nimi, źródeł danych oraz wymagań kanałów.
Model powstaje przed właściwą migracją i integracją, ponieważ określa docelową strukturę informacji w systemie: migracja mapuje dane źródłowe na ten model, a integracje na nim opierają kontrakty z kolejnymi systemami. Zmiana modelu po zasileniu środowiska oznacza powtórzenie obu prac.
Najpierw ustalamy, które informacje mają być zarządzane w Pimcore, skąd pochodzą i kto może je zmieniać. Oddzielamy dane transakcyjne od opisowych, definiujemy relacje i wskazujemy pola wymagane dla poszczególnych rynków. Model nie powinien kopiować obecnego arkusza kolumna po kolumnie — część problemów może wynikać właśnie z jego struktury.
Decyzje przed developmentem
- 01
Źródło prawdy
Ustalamy, który system odpowiada za cenę, stan, indeks, opis, zdjęcie, tłumaczenie i relacje produktowe.
- 02
Struktura produktu
Opisujemy produkty bazowe, warianty, zestawy, kategorie, kolekcje oraz zależności między rekordami.
- 03
Odpowiedzialność
Każde pole i etap ma właściciela. Uprawnienia wynikają z roli użytkownika oraz zakresu jego pracy.
- 04
Warunki publikacji
Produkt może trafić do kanału po spełnieniu określonych wymagań dotyczących danych, materiałów i akceptacji.
Co opisuje model danych
- Produkty
- Obiekty bazowe: indeks, nazwa, opis, przynależność do marki i dostawcy.
- Warianty
- Wymiary różnicujące ofertę — rozmiar, kolor, wykonanie — i to, co warianty dziedziczą po produkcie.
- Kategorie
- Drzewa i taksonomie, także rozbieżne: własna struktura sklepu obok wymaganej przez marketplace.
- Atrybuty
- Pola opisowe i handlowe, ich typy, słowniki wartości oraz jednostki miary.
- Relacje
- Powiązania między rekordami: zestawy, akcesoria, części zamienne, produkty uzupełniające.
- Dane techniczne
- Parametry, tabele wartości i normy, które w kanałach trafiają do porównań i filtrów.
- Wersje językowe
- Które pola są tłumaczone, które wspólne dla wszystkich rynków, a które lokalne.
- Zasoby DAM
- Zdjęcia, wizualizacje, instrukcje i certyfikaty powiązane z produktem, wariantem i rynkiem.
- Walidacja
- Reguły, które pole musi spełnić: format, zakres, wymagalność, zależność od innego pola.
- Kompletność danych
- Definicja produktu gotowego do publikacji — osobno dla każdego kanału i rynku.
Co obejmuje wdrożenie Pimcore
Zakres jest ustalany po analizie danych, procesów i systemów. Poniższe obszary pokazują pełną logikę projektu. Nie każdy projekt wymaga takiego samego poziomu rozbudowy.
Analiza procesów i źródeł danych
Sprawdzamy, gdzie obecnie powstają informacje, kto je uzupełnia, w jaki sposób są kontrolowane oraz dokąd trafiają.
Powstaje mapa źródeł, odbiorców, odpowiedzialności i problemów wymagających rozwiązania.
Model danych i taksonomia
Projektujemy klasy, pola, warianty, relacje, kategorie i reguły dziedziczenia.
Model uwzględnia wymagania poszczególnych rynków oraz kanałów, ale pozostaje możliwy do obsługi przez zespół.
Przygotowanie importu i migracji
Określamy format danych źródłowych, mapowanie pól, sposób obsługi braków i duplikatów oraz kolejność importu.
Próbna migracja poprzedza zasilenie środowiska produkcyjnego.
Architektura wymiany danych
Opisujemy, które dane wpływają do Pimcore, które są w nim rozwijane oraz jakie informacje trafiają do systemów docelowych.
Dla każdego połączenia ustalamy kierunek, zakres pól i moment, w którym dane mogą opuścić Pimcore.
Workflow, role i uprawnienia
Definiujemy statusy produktu, możliwe przejścia, właścicieli etapów i zasady akceptacji.
Użytkownik widzi zakres odpowiadający jego roli i nie publikuje danych, które nie spełniają ustalonych warunków.
Zarządzanie materiałami
Zdjęcia, instrukcje, certyfikaty i inne pliki zostają powiązane z właściwymi produktami, wersjami i rynkami.
Zakres DAM zależy od rodzaju materiałów oraz sposobu ich późniejszej dystrybucji.
Testy, odbiór i uruchomienie
Sprawdzamy model, uprawnienia, workflow, importy i scenariusze publikacji.
Uruchomienie następuje po przejściu uzgodnionych kryteriów odbioru i przygotowaniu planu przejścia na nowy sposób pracy.
Analiza procesów i źródeł danych
Sprawdzamy, gdzie obecnie powstają informacje, kto je uzupełnia, w jaki sposób są kontrolowane oraz dokąd trafiają.
Powstaje mapa źródeł, odbiorców, odpowiedzialności i problemów wymagających rozwiązania.
Model danych i taksonomia
Projektujemy klasy, pola, warianty, relacje, kategorie i reguły dziedziczenia.
Model uwzględnia wymagania poszczególnych rynków oraz kanałów, ale pozostaje możliwy do obsługi przez zespół.
Przygotowanie importu i migracji
Określamy format danych źródłowych, mapowanie pól, sposób obsługi braków i duplikatów oraz kolejność importu.
Próbna migracja poprzedza zasilenie środowiska produkcyjnego.
Architektura wymiany danych
Opisujemy, które dane wpływają do Pimcore, które są w nim rozwijane oraz jakie informacje trafiają do systemów docelowych.
Dla każdego połączenia ustalamy kierunek, zakres pól i moment, w którym dane mogą opuścić Pimcore.
Workflow, role i uprawnienia
Definiujemy statusy produktu, możliwe przejścia, właścicieli etapów i zasady akceptacji.
Użytkownik widzi zakres odpowiadający jego roli i nie publikuje danych, które nie spełniają ustalonych warunków.
Zarządzanie materiałami
Zdjęcia, instrukcje, certyfikaty i inne pliki zostają powiązane z właściwymi produktami, wersjami i rynkami.
Zakres DAM zależy od rodzaju materiałów oraz sposobu ich późniejszej dystrybucji.
Testy, odbiór i uruchomienie
Sprawdzamy model, uprawnienia, workflow, importy i scenariusze publikacji.
Uruchomienie następuje po przejściu uzgodnionych kryteriów odbioru i przygotowaniu planu przejścia na nowy sposób pracy.
Szczegółowe wykonanie połączeń — API, Data Hub, harmonogramy synchronizacji i obsługa błędów — może być realizowane w ramach usługi Integracja Pimcore.
Migracja danych do Pimcore
Migracja rzadko jest przepisaniem jednego pliku do drugiego. Dane produktowe są zwykle rozproszone między systemami i arkuszami, a ich jakość ujawnia się dopiero przy mapowaniu na docelowy model.
Dlatego pierwszy import jest próbny i wykonujemy go na kopii środowiska. Raport z niego pokazuje, ile rekordów przechodzi bez zastrzeżeń, gdzie brakuje wymaganych pól i które pozycje wymagają decyzji po stronie firmy — dopiero po tym zasilamy środowisko produkcyjne.
Obsługiwane źródła
- XML
- CSV
- Excel
- API
- bazy i systemy zewnętrzne
Co obejmuje migracja
- 01
Źródła danych
Ustalamy, skąd pochodzi każdy rodzaj informacji: z ERP, arkuszy, plików dostawców, obecnego sklepu, katalogu albo poprzedniego systemu PIM. Dla każdego źródła sprawdzamy, kto je utrzymuje i jak często się zmienia.
- 02
Mapowanie pól
Każde pole źródłowe dostaje odpowiednik w docelowym modelu albo regułę przekształcenia — podział wartości, zmianę jednostki, przypisanie do słownika. Pola bez odpowiednika są decyzją, nie pominięciem.
- 03
Oczyszczanie rekordów
Poprawiamy formaty, jednostki, kodowanie znaków i wartości wpisane opisowo tam, gdzie model wymaga słownika. Część reguł zostaje w systemie jako walidacja, żeby te same błędy nie wracały po imporcie.
- 04
Obsługa duplikatów
Ustalamy klucz, po którym rozpoznajemy ten sam produkt w kilku źródłach, oraz zasadę scalania: które źródło wygrywa przy rozbieżności i co dzieje się z pozostałymi wartościami.
- 05
Przeniesienie multimediów
Zdjęcia, wizualizacje, instrukcje i certyfikaty trafiają do DAM razem z powiązaniem do produktu, wariantu i rynku. Pliki bez powiązania i te w kilku wersjach wymagają osobnej decyzji przed importem.
- 06
Kontrola kompletności
Po imporcie sprawdzamy liczbę rekordów, wypełnienie pól wymaganych dla każdego kanału i rynku oraz produkty, które nie przechodzą walidacji. Wynik jest listą zadań dla zespołu, a nie oceną migracji.
Format źródła rzadko jest problemem — decyduje struktura i jakość danych w środku. Jeżeli migracja ma być regularną wymianą, a nie jednorazowym zasileniem, jej zakres opisuje integracja Pimcore.
Jak wygląda wdrożenie Pimcore krok po kroku?
Dziesięć etapów prowadzi od rozproszonych danych do uruchomienia i dalszego rozwoju. Każdy kończy się decyzją, dokumentem albo działającym fragmentem systemu, więc wiadomo, co zostało ustalone i co jest potrzebne do rozpoczęcia kolejnej części prac.
Kolejność etapów jest stała, ale ich długość zależy od jakości danych źródłowych i dostępności osób decyzyjnych. Jeżeli część analizy została już wykonana, zaczynamy od weryfikacji tego materiału, a nie od nowa.
- 01
Analiza obecnych danych i procesów
Zbieramy przykładowe dane, listę systemów, kanały publikacji i role użytkowników. Rozmawiamy z osobami, które tworzą, kontrolują i wykorzystują informacje.
Rezultatmapa obecnego procesu i lista problemów do rozwiązania
- 02
Projekt modelu danych
Opisujemy obiekty, pola, warianty, kategorie, relacje, wersje językowe, reguły walidacji oraz odpowiedzialność systemów. Na tym etapie powstaje też podział zakresu i kolejność realizacji.
Rezultatzaakceptowany model danych, słownik pojęć i backlog
- 03
Konfiguracja Pimcore
Tworzymy klasy, pola, widoki dla zespołu i wymagane rozszerzenia. Kolejne fragmenty są prezentowane i weryfikowane w trakcie projektu, a nie na końcu.
Rezultatdziałające środowisko zgodne z zatwierdzonym modelem
- 04
Migracja danych
Mapujemy pola źródłowe na docelowy model, oczyszczamy rekordy, obsługujemy duplikaty i przenosimy multimedia. Próbna migracja poprzedza zasilenie środowiska produkcyjnego.
Rezultatzaimportowane dane i raport kompletności
- 05
Integracje
Uruchamiamy wymianę danych z systemami źródłowymi i kanałami docelowymi: zakres pól, kierunek, częstotliwość oraz obsługę błędów ustalamy dla każdego połączenia osobno.
Rezultatdziałające przepływy danych i opis kontraktów
- 06
Konfiguracja workflow oraz uprawnień
Definiujemy statusy produktu, przejścia między etapami, właścicieli oraz zakres widoczny dla każdej roli. Użytkownik nie publikuje danych, które nie spełniają ustalonych warunków.
Rezultatworkflow, role i warunki publikacji w systemie
- 07
Testy
Sprawdzamy model, mapowania, walidacje, uprawnienia, integracje i scenariusze pracy użytkowników — razem z przypadkami, w których dane są niekompletne albo źródło nie odpowiada.
Rezultatlista wyników testów, poprawki i gotowość do odbioru
- 08
Szkolenie użytkowników
Zespół pracujący na danych poznaje panel, workflow, zakres własnej roli i sposób zgłaszania problemów. Szkolenie odbywa się na docelowym modelu i na własnych danych firmy.
Rezultatprzeszkolony zespół i instrukcja pracy w systemie
- 09
Uruchomienie
Przenosimy uzgodnione dane produkcyjne, włączamy docelowe procesy i kontrolujemy pierwsze cykle pracy oraz publikacji do kanałów.
Rezultatprodukcyjne środowisko i ustalony sposób obsługi po starcie
- 10
Utrzymanie i dalszy rozwój
Po starcie system wymaga obsługi zgłoszeń, aktualizacji, monitorowania integracji oraz rozwoju modelu, workflow i eksportów wraz ze zmianami w ofercie.
Rezultatuzgodniony zakres utrzymania i backlog rozwoju
Każdy system musi mieć jasno określoną rolę
ERP może pozostać źródłem indeksów, cen albo stanów. Pimcore przejmuje dane wymagające rozwijania, porządkowania, akceptacji i dystrybucji. Sklep oraz pozostałe kanały otrzymują informacje przygotowane dla ich konkretnych potrzeb.
Podział zależy od istniejącej architektury. W jednym projekcie Pimcore zarządza przede wszystkim informacją produktową i materiałami. W innym obejmuje również dane podstawowe dotyczące marek, dostawców, kategorii lub innych obiektów.
Systemy źródłowe
- ERP
- System magazynowy
- Pliki dostawców
- Zespoły wewnętrzne
Pimcore
Kanały i odbiorcy
- Magento 2
- Shopify
- Marketplace
- Portal B2B
- Katalog
- Aplikacje
Co przechodzi przez kolejne warstwy
- Systemy źródłowe przekazują indeksy, dane dostawców i informacje operacyjne, a także ceny oraz stany, gdy taki podział zostanie ustalony.
- Pimcore porządkuje struktury i relacje, treści oraz tłumaczenia, materiały, kompletność i statusy akceptacji.
- Kanały otrzymują wymagany zestaw pól we właściwym języku, odpowiednie materiały i dane po spełnieniu warunków publikacji.
- Diagram pokazuje możliwe role systemów. Nie każdy projekt zawiera wszystkie wymienione elementy.
Pimcore łączy obszary PIM, MDM, DAM, DXP i commerce — opisuje je dokumentacja platformy (otwiera się w nowej karcie) — ale wdrożenie powinno obejmować wyłącznie te części, które mają uzasadnienie w procesach firmy.
Ile kosztuje i ile trwa wdrożenie Pimcore?
Jednej ceny ani jednego terminu dla wszystkich projektów Pimcore nie podajemy — wdrożenie dla jednego katalogu i jednego kanału to inna praca niż model obsługujący kilka marek, rynków i systemów. Poniżej jest osiem rzeczy, które przesuwają wycenę i harmonogram najmocniej.
Co przesuwa wycenę i harmonogram
- Liczba rekordów
- Wpływa mniej na projekt modelu, a więcej na migrację, wydajność i czas przeliczania zmian w katalogu. Kilka milionów wariantów zmienia też sposób pracy zespołu w panelu.
- Złożoność modelu danych
- Liczba klas, pól, poziomów dziedziczenia i relacji między obiektami. Katalog, w którym produkt składa się z części i wariantów w kilku wymiarach, wymaga dłuższej analizy niż płaska lista.
- Migracja
- Liczba źródeł i stan danych w każdym z nich. Czyszczenie, scalanie duplikatów i uzupełnianie braków bywa większą częścią projektu niż konfiguracja systemu.
- Workflow
- Liczba etapów przygotowania produktu, warunki przejścia i to, czy publikacja ma być blokowana przy niekompletnych danych.
- Liczba użytkowników
- Im więcej osób i działów pracuje na danych, tym więcej ról, uprawnień i widoków do zaprojektowania — oraz dłuższe szkolenie i odbiór.
- Integracje
- Liczba systemów, kierunki wymiany, częstotliwość i jakość danych po drugiej stronie. Każdy przepływ potrzebuje obsługi błędów i ponownego przetwarzania.
- Liczba kanałów docelowych
- Każdy kanał odbiera inny zestaw pól, w innym formacie i z inną definicją kompletności. Drugi kanał kosztuje mniej niż pierwszy, ale nie jest darmowy.
- Indywidualny development
- Od konfiguracji na standardowych mechanizmach do własnych widoków, walidacji, automatyzacji i eksportów przygotowanych pod konkretnego odbiorcę.
Estymacja i harmonogram powstają po analizie danych, źródeł i kanałów, czyli po pierwszych dwóch etapach procesu powyżej — dopiero wtedy wiadomo, co jest konfiguracją, a co developmentem. Wdrożenie można podzielić na etapy: pierwszy zwykle obejmuje jeden zestaw danych i jeden kanał, kolejne dodają następne. Koszt pracy po uruchomieniu opisuje utrzymanie Pimcore.
Pimcore nie będzie opłacalny w każdym projekcie
System wymaga zaprojektowania modelu i zmiany sposobu pracy z danymi. Przy małej liczbie produktów, jednym kanale i prostym procesie koszt wdrożenia może przewyższyć korzyści.
Podczas pierwszej rozmowy oddzielamy potrzebę nowego wdrożenia od problemu integracyjnego albo utrzymaniowego. Firma nie powinna rozpoczynać większego projektu, gdy wystarczy mniejszy zakres.
FAQ – wdrożenie Pimcore
Pytania dotyczą kosztu, czasu, analizy, migracji danych, szkolenia, edycji systemu i przejęcia rozpoczętego projektu.
Omówmy wdrożenie PimcoreWdrożenie obejmuje zaprojektowanie modelu danych, ról, workflow oraz sposobu importowania i dystrybuowania informacji. Konfiguracja systemu i development rozpoczynają się po ustaleniu tych założeń.
Najczęściej wtedy, gdy firma zarządza dużą lub złożoną ofertą, wieloma językami, rynkami albo kanałami. Istotna jest również liczba osób uczestniczących w przygotowaniu i akceptacji danych. Porównanie klasy rozwiązań opisujemy w artykule o systemach PIM w e‑commerce (otwiera się w nowej karcie).
Tak. Zakres może obejmować dane produktowe, inne dane podstawowe, relacje między obiektami oraz materiały cyfrowe. Decyzja o wykorzystaniu PIM, MDM lub DAM wynika z potrzeb projektu — platforma rozwija te obszary wspólnie (otwiera się w nowej karcie).
Tak i jest to jeden z typowych elementów architektury PIM. Najpierw ustalamy odpowiedzialność każdego systemu oraz kierunki przepływu danych — ERP zwykle zostaje źródłem indeksów, cen i stanów, a Pimcore przejmuje opisy, atrybuty, relacje i materiały. Później projektujemy importy, eksporty albo integracje API; szczegóły połączeń opisuje usługa Integracja Pimcore.
Dane produktowe, kategorie, atrybuty, relacje, tłumaczenia oraz materiały cyfrowe — z arkuszy, plików dostawców, obecnego sklepu, ERP albo poprzedniego systemu PIM. Źródłem może być XML, CSV, Excel, API oraz bazy i systemy zewnętrzne; sam format rzadko jest problemem, decyduje struktura i jakość danych w środku. Zakres prac opisuje sekcja o migracji danych.
Tak i jest to pierwszy etap procesu, nie dodatek do niego. Bez sprawdzenia, gdzie powstają dane, kto je uzupełnia i czego wymaga każdy kanał, model powstałby na domysłach, a migracja ujawniłaby to dopiero przy imporcie. Jeżeli firma ma już własną analizę, zaczynamy od jej weryfikacji, a nie od nowa.
Tak i najczęściej tak to prowadzimy. Pierwszy etap obejmuje zwykle jeden zestaw danych i jeden kanał — model, migrację i publikację doprowadzone do końca — a kolejne dodają następne kanały, rynki albo obszary, na przykład DAM czy dane podstawowe. Warunkiem jest model, który przewiduje te rozszerzenia od początku.
Tak, szkolenie użytkowników jest osobnym etapem przed uruchomieniem. Odbywa się na docelowym modelu i na własnych danych firmy, a nie na przykładowym katalogu, i obejmuje panel, workflow, zakres każdej roli oraz sposób zgłaszania problemów. Zespół otrzymuje też instrukcję pracy w systemie.
Nie. Pimcore staje obok platformy sprzedażowej i zasila ją danymi — sklep nadal obsługuje koszyk, płatności i zamówienia. Zmiana dotyczy tego, skąd biorą się w nim opisy, atrybuty i materiały: przestają być wprowadzane bezpośrednio w sklepie. Wymiana platformy to osobna decyzja i osobny projekt.
To jeden z głównych powodów, dla których firmy sięgają po PIM. W modelu ustalamy, które pola są tłumaczone, które wspólne dla wszystkich rynków, a które lokalne, oraz osobną definicję kompletności dla każdego rynku — produkt gotowy do publikacji w Polsce nie musi być gotowy w Niemczech. Tłumaczenia i statusy widać w jednym miejscu, zamiast w arkuszu na rynek.
Jednej ceny dla wszystkich projektów nie podajemy. Na wycenę wpływa liczba rekordów, złożoność modelu danych, zakres migracji, workflow, liczba użytkowników, integracje, liczba kanałów docelowych oraz zakres indywidualnego developmentu — wszystkie osiem czynników rozpisaliśmy w sekcji o koszcie i czasie wdrożenia.
Terminu nie podajemy przed analizą. Czas wynika z modelu danych, liczby integracji, jakości źródeł, zakresu workflow i dostępności osób decyzyjnych — harmonogram przygotowujemy po pierwszych dwóch etapach procesu, czyli po analizie i zatwierdzeniu modelu. Etapowe wdrożenie pozwala uruchomić pierwszy kanał, nie czekając na komplet zakresu.
Pimcore działa w modelu open-core i ma kilka edycji. Wybór zależy między innymi od warunków licencyjnych organizacji, potrzebnych modułów i sposobu utrzymania systemu. Aktualne zasady weryfikujemy przed przygotowaniem oferty — porównanie edycji jest w dokumentacji (otwiera się w nowej karcie).
Po starcie system wymaga obsługi błędów, aktualizacji, monitorowania integracji i dalszego rozwoju. Zakres może zostać przejęty w ramach usługi Utrzymanie Pimcore.
Najpierw sprawdzamy kod, konfigurację, model danych, integracje i stan dokumentacji. Po audycie można określić, które elementy da się kontynuować, a które wymagają poprawy lub ponownego zaprojektowania.
Zacznijmy od danych i systemów, które już działają
Nie potrzebujesz gotowej specyfikacji. Opisz źródła danych, kanały i miejsce, w którym obecny proces zaczyna się blokować. Na pierwszej rozmowie ustalimy, czy potrzebne jest nowe wdrożenie, integracja albo praca nad istniejącym Pimcore.
Co warto mieć na pierwszą rozmowę
- przybliżoną liczbę produktów lub rekordów
- listę systemów, z których pochodzą dane
- liczbę rynków i kanałów sprzedaży
- informację, kto odpowiada za dane produktowe
- etap, na którym jest projekt