Rebranding w dużych organizacjach wykorzystujących systemy takie jak Salesforce jest procesem znacznie bardziej złożonym niż mogłoby się wydawać na pierwszy rzut oka. Nie jest to wyłącznie zmiana nazwy firmy, logotypu czy kolorystyki interfejsu, lecz szeroko zakrojona operacja obejmująca zarówno warstwę technologiczną jak i biznesową oraz komunikacyjną.
W praktyce oznacza to konieczność przeanalizowania niemal każdego elementu funkcjonowania organizacji – od kodu, przez integracje, aż po sposób komunikacji z użytkownikami końcowymi.
Pierwszym i jednym z najważniejszych etapów jest dokładna analiza wszystkich miejsc, w których występują stara nazwa firmy, domena, identyfikacja wizualna czy powiązane wartości. W ekosystemie Salesforce oznacza to nie tylko konfigurację systemu, ale również:
- metadane,
- klasy Apex,
- komponenty Lightning,
- zasoby statyczne (ang. static resources),
- szablony mailowe,
- Experience Cloud
- oraz wszelkie integracje zewnętrzne.
Często tworzone są specjalne skrypty lub narzędzia wspomagające wyszukiwanie zależności – identyfikujące użycie nazw w rekordach, kodzie, endpointach czy konfiguracjach takich jak Named Credentials, Connected Apps, Auth Providers, Trusted URLs czy ustawieniach CORS. Bez takiej analizy łatwo przeoczyć elementy, które po zmianie przestaną działać.
Zmiany technologiczne i ograniczenia systemowe
Jednym z większych wyzwań podczas rebrandingu jest to, że nie wszystkie elementy można zmienić w prosty sposób. W Salesforce część nazw – szczególnie tych używanych w API lub głęboko zakorzenionych w architekturze systemu – może być trudna do modyfikacji lub wręcz niemożliwa bez ryzyka przerwania działania istniejących procesów. Dotyczy to np. nazw obiektów, pól czy endpointów integracyjnych, które są wykorzystywane przez inne systemy.
Dodatkowo zmiana domeny (np. My Domain) musi zostać przeprowadzona w sposób skoordynowany z pozostałymi systemami. Nie może dojść do sytuacji, w której domena zostanie zmieniona tylko w jednym miejscu – wszystkie integracje, systemy zewnętrzne, procesy ETL oraz mechanizmy logowania (np. Single Sign-On, w tym integracje z Entra ID) muszą zostać odpowiednio dostosowane równolegle. W przeciwnym razie może dojść do przerwania komunikacji między systemami.
Często pojawia się również problem starszych systemów, które nie są w pełni skalowalne lub nie przyjmują nowych wartości (np. zmienionych nazw w bazie danych). W takich przypadkach konieczne jest tworzenie batchy lub jobów, które etapowo aktualizują dane lub wysyłają odpowiednie komunikaty do systemów zewnętrznych, wymuszając synchronizację.
Znaczenie okna wdrożeniowego i testów
Rebranding w systemach takich jak Salesforce powinien być przeprowadzany w odpowiednim oknie wdrożeniowym – najczęściej poza godzinami pracy użytkowników. Wynika to z faktu, że zmiany mogą chwilowo wpłynąć na dostępność systemu, logowanie użytkowników czy działanie procesów automatycznych.
Testy odgrywają tutaj kluczową rolę. Przed wdrożeniem produkcyjnym konieczne jest przygotowanie środowiska regresyjnego, w którym zostaną przeprowadzone testy funkcjonalne, integracyjne oraz walidacyjne. Często angażowani są testerzy, analitycy biznesowi oraz użytkownicy końcowi, którzy weryfikują poprawność ich działania. Dodatkowo po wdrożeniu wykonywane są walidacje nocne – sprawdzające, czy wszystkie joby, batche i integracje działają poprawnie.
Nie można również zapominać o manualnych krokach wdrożeniowych. W Salesforce ich dokładne opisanie jest absolutnie kluczowe – checklisty deploymentowe często zawierają dziesiątki punktów, od zmiany konfiguracji systemowej, przez aktualizację haseł i loginów, do procesów ETL, aż po ręczne przeprocesowanie wniosków czy restart integracji.
Komunikacja i zmiany po stronie użytkowników
Rebranding to nie tylko zmiany w systemie, ale również szeroka komunikacja kierowana do użytkowników. Obejmuje ona m.in.:
- informowanie o zmianie nazw użytkowników,
- nowych domenach logowania,
- konieczności ponownej aktywacji kont (np. poprzez linki aktywacyjne wysyłane co kilka godzin).
W dużych organizacjach kluczowe jest także poinformowanie zespołów korzystających z integracji – często wymaga to wystawienia ticketów do innych systemów, które muszą dostosować swoje konfiguracje.
Zmianie ulegają również elementy wizualne – kolory, czcionki, logo – zarówno w samym systemie jak i w Experience Cloud, szablonach mailowych oraz w komunikacji z klientem. To istotne, ponieważ rebranding musi być spójny zarówno wewnętrznie, jak i zewnętrznie.
Wpływ na procesy biznesowe i organizacyjne
W niektórych przypadkach rebranding wiąże się z większymi zmianami organizacyjnymi, np. podziałem firmy. Może to prowadzić do konieczności „odpięcia” części instancji Salesforce i stworzenia nowego środowiska dla wydzielonego biznesu. Taki scenariusz wymaga szybkiego developmentu, migracji danych oraz zapewnienia ciągłości działania procesów biznesowych.
Zmiany mogą również wpływać na istniejące procesy automatyczne, integracje oraz raportowanie. Nawet drobna zmiana nazwy może spowodować błędy w logice biznesowej, jeśli była ona używana w warunkach, walidacjach lub kodzie.
Proces powdrożeniowy i stabilizacja systemu
Po wdrożeniu rebrandingu rozpoczyna się równie ważny etap stabilizacji. Monitorowane są błędy produkcyjne, zgłoszenia użytkowników oraz działanie integracji. W tym czasie zespoły IT często pracują w trybie podwyższonej gotowości, szybko reagując na pojawiające się problemy.
Tworzone są również dodatkowe testy oraz poprawki, a wszelkie nieprawidłowości są rejestrowane jako bugi lub incydenty. Ważnym elementem jest także aktualizacja dokumentacji systemowej oraz procedur operacyjnych.
Podsumowanie
Rebranding w dużych organizacjach wykorzystujących Salesforce to proces wielowymiarowy, obejmujący zarówno aspekty techniczne, jak i biznesowe. Wymaga precyzyjnego planowania, szerokiej analizy zależności oraz ścisłej współpracy wielu zespołów. To nie tylko zmiana wizualna, ale transformacja całego ekosystemu – od kodu i integracji, przez procesy biznesowe, aż po doświadczenie użytkownika końcowego.
Ostatecznie sukces rebrandingu zależy nie tylko od prawidłowego wdrożenia zmian, ale również od ich stabilności oraz akceptacji przez użytkowników. W środowiskach tak złożonych jak Salesforce nawet najmniejszy szczegół może mieć znaczenie, dlatego każdy etap tego procesu musi być realizowany z najwyższą dokładnością.
Zostaw komentarz