Architektura danych klienta w Data 360 – jedna platforma, by rządzić wszystkimi systemami

Przy kilku systemach źródłowych wszystko wygląda jeszcze na „ogarnięte”. CRM ma swoje kontakty, e-commerce swoje zamówienia, support swoje sprawy. Problem zaczyna się, gdy wolumen rośnie do setek rekordów dziennie, a do tego dochodzą różne identyfikatory, różne opóźnienia i sprzeczne definicje klienta. Fragmentacja przestaje być tylko problemem raportowym, a zaczyna wpływać na automatyzacje i doświadczenie użytkownika. W takim otoczeniu pytanie nie brzmi już „czy dane są zsynchronizowane”, ale „które dane w danym momencie są uznawane za prawdę”.

To ma znaczenie teraz, bo coraz więcej procesów w Salesforce działa na danych w sposób operacyjny. Segmenty uruchamiają flow, profile klientów sterują priorytetami obsługi, a automatyzacje podejmują decyzje niemal natychmiast po zdarzeniu. Jeśli dane klienta są spóźnione, zdublowane albo niespójne, system zaczyna reagować na historię, a nie na rzeczywistość. Przy większej skali nie da się tego naprawić kolejną integracją point-to-point – potrzebna jest zmiana sposobu myślenia o architekturze danych.

Od integracji CRM do warstwowej architektury Data 360

Tradycyjne podejście w Salesforce opierało się na założeniu, że CRM jest centrum świata. Inne systemy miały się do niego „dopasować” przez integracje, synchronizacje i okresowe batche. To działało, dopóki liczba źródeł była ograniczona, a opóźnienia akceptowalne. Przy większej skali integracje zaczynają jednak pełnić zbyt wiele ról naraz: transport danych, mapowanie modeli, rozstrzyganie konfliktów i czasem nawet logikę biznesową. Każda zmiana w jednym systemie rozlewa się po całym krajobrazie.

Data 360 wprowadza inny porządek. Zamiast jednej osi CRM-owej pojawia się architektura warstwowa: ingest danych, modelowanie i harmonizacja, unifikacja tożsamości, a na końcu konsumpcja przez segmenty i aktywacje. To nie jest tylko „nowe miejsce na dane”, ale decyzja architektoniczna, gdzie rozdziela się odpowiedzialności. Dane mogą być wciągane lub federowane, model danych staje się wspólnym językiem, a CRM przestaje być jedynym systemem prawdy. Dla administratora czy konsultanta oznacza to mniej „szybkich synchronizacji”, a więcej świadomych wyborów, gdzie i kiedy dane są materializowane.

Najtrudniejszy problem: identity resolution kontra świeżość profilu 

Największą obietnicą Data 360 jest zunifikowany profil klienta. Identity resolution faktycznie rozwiązuje klasyczny problem duplikatów i rozproszonych identyfikatorów. Im bardziej agresywne reguły dopasowania, tym pełniejszy obraz klienta. Tu jednak pojawia się koszt uboczny: czas. Unifikacja to proces, który nie zawsze dzieje się natychmiast po ingestion danych. Przy większych wolumenach między zapisem zdarzenia a aktualizacją unified profile pojawia się luka.

To napięcie ma realne konsekwencje. Automatyzacja może uruchomić się na profilu, który jeszcze „nie widzi” najnowszego zamówienia albo zgłoszenia serwisowego. Segment może pominąć klienta, który powinien do niego trafić kilka minut później. Rozwiązując problem tożsamości, wprowadzasz więc problem świeżości. Architektura musi to uwzględniać, zamiast udawać, że wszystko jest synchroniczne. Pomagają tu świadome decyzje: które dane mogą być liczone batchowo, a które muszą być dostępne szybciej, nawet kosztem prostszej logiki. To nie kwestia konfiguracji, tylko oczekiwań wobec systemu.

Skala wymusza myślenie o danych jako produkcie 

Gdy dane klienta zaczynają zasilać wiele procesów jednocześnie, przestają być „efektem ubocznym integracji”. Ten sam profil trafia do segmentacji, aktywacji w CRM i raportowania. Każdy z tych konsumentów ma inne wymagania co do kompletności, świeżości i relacji między obiektami. W Data 360 widać to szczególnie w Data Model Objects i ich relacjach. Kardynalność relacji trzeba wybrać raz, a jej konsekwencje ciągną się przez segmenty i aktywacje. To sprawia, że model danych staje się kontraktem, a nie tylko strukturą techniczną.

Przy większej skali rośnie też znaczenie metadanych i governance. Nie da się ręcznie pilnować, które źródło jest preferowane i gdzie dana relacja jest używana. Data 360 wymusza bardziej produktowe podejście: jasne definicje, odpowiedzialność za jakość i świadomość, kto konsumuje dane. Dla praktyków Salesforce to duża zmiana mentalna. Zamiast „jak szybko podłączyć kolejny system”, pojawia się pytanie „czy nasz model danych wytrzyma kolejnego konsumenta bez łamania istniejących procesów”. To właśnie skala zmusza do tej refleksji.

Co naprawdę decyduje o jakości 

Najważniejszy wniosek z pracy z Data 360 jest prosty, choć niewygodny: prawdziwym problemem nie jest brak danych ani brak integracji, ale brak świadomej architektury między ingestem, unifikacją i aktywacją. Unified profile bez jasnych założeń co do świeżości prowadzi do błędnych decyzji automatyzacji, a szybkie reakcje bez spójnej tożsamości prowadzą do chaosu. Data 360 daje narzędzia, ale nie zdejmuje odpowiedzialności z zespołów.

Jeśli jedna platforma ma „rządzić wszystkimi systemami”, jak w pewnej znanej sadze, to nie zrobi tego sama. To architektura, a nie magia, decyduje, czy dane klienta będą wsparciem dla procesów, czy ich najsłabszym ogniwem. Pytanie, które warto sobie zadać na koniec, brzmi: czy wiesz, na jakiej wersji profilu klienta działają dziś twoje segmenty i automatyzacje – i czy jesteś gotów wziąć za to odpowiedzialność?