15 pytań do partnera wdrożeniowego Salesforce, zanim podpiszesz umowę

Referencje się zgadzają. Ściana logotypów robi wrażenie. Liczba certyfikatów imponuje. Tylko że nic z tego nie mówi, kto faktycznie pojawi się przy Twoim projekcie, jak będą zapadały decyzje, gdy wymagania się zmienią, ani czy zdołasz odejść bez wojny. A to właśnie te rzeczy przesądzają, czy wdrożenie wyląduje, czy zacznie dryfować.

Poniższe pytania to te, na które partner pewny jakości swojego dostarczania odpowie bez mrugnięcia okiem. Publikujemy je, bo wolimy, żebyś zadał je nam, niż żebyś poznał odpowiedzi dopiero po podpisaniu statement of work.

O co pytać partnera wdrożeniowego Salesforce?

Pytaj o cztery rzeczy: o ludzi (kto imiennie pracuje przy Twoim projekcie i jaki ma staż), o proces (jak zapadają decyzje architektoniczne i jak obsługiwane są zmiany zakresu), o dowody (porównywalne, dowiezione wdrożenia w Twojej skali) oraz o wyjście (pakiet handoverowy i własność danych). Mocni partnerzy odpowiadają na wszystkie cztery konkretami, nie broszurą.

Większość publikowanych list pytań kończy się na „sprawdź referencje i certyfikaty“. Taki filtr nie odsiewa nikogo. Każdy poważny partner ma referencje i certyfikaty. Pytania, które oddzielają dobre dopasowanie od kosztownej pomyłki, sięgają tam, gdzie prezentacja sprzedażowa nie zagląda: obsada po podpisaniu umowy, odpowiedzialność za decyzje i to, co się dzieje, gdy chcesz odejść.

Czym jest partner wdrożeniowy Salesforce?

Partner wdrożeniowy Salesforce to certyfikowana firma konsultingowa, która projektuje, konfiguruje, integruje i wdraża Salesforce w Twojej organizacji, a następnie przekazuje system Twojemu zespołowi. Partnerzy mają formalny status Salesforce Partner i są klasyfikowani według przychodów, certyfikatów i satysfakcji klientów. Tucario jest partnerem Salesforce i ISV na AppExchange.

Poziom partnerstwa mówi coś o skali i liczbie certyfikatów. Nie mówi nic o tym, kto wykona pracę przy Twoim projekcie ani jak głęboko sięgnie przegląd architektury. Dlatego poziom jest filtrem na start, a nie decyzją. Pytania w tym artykule są skonstruowane tak, żeby zobaczyć, co się za nim kryje.

Jak wybrać właściwego partnera wdrożeniowego Salesforce?

Oceniaj partnerów po predyktorach jakości dostarczenia, nie po sygnałach marketingowych. Największą wagę daj imiennie wskazanym seniorom w projekcie, architektowi obecnemu od projektowania po handover, dowodom z porównywalnej branży, udokumentowanemu procesowi zmian i jasnemu standardowi wyjścia. Ścianę logotypów i surową liczbę certyfikatów potraktuj z dyskontem. Zadaj 15 poniższych pytań i porównaj odpowiedzi obok siebie.

Pełny framework selekcji, razem ze scorecardem i antykryteriami, znajdziesz w naszym przewodniku po wyborze partnera wdrożeniowego Salesforce. Ten artykuł to druga połowa — przesłuchanie: dokładne pytania i to, jak brzmi dobra odpowiedź na każde z nich.

15 pytań, pogrupowanych według tego, co chronią

Pytania układają się w cztery grupy. Pytania o ludzi chronią Cię przed podmianą zespołu po podpisie. Pytania o proces — przed dryfem decyzyjnym i sporami o zakres. Pytania o dowody — przed byciem czyimś pierwszym podejściem do Twojego problemu. Pytania o wyjście — przed vendor lock-inem. Zadaj wszystkie piętnaście i słuchaj, czy padają konkrety.

Ludzie: kto dokładnie wykonuje pracę

1. Kto imiennie będzie pracował przy moim projekcie i jaki ma staż oraz certyfikaty? Dobra odpowiedź wymienia osoby, nie role, i podaje ich lata doświadczenia z Salesforce. Mgliste „przydzielimy zespół“ oznacza, że zespołu jeszcze nie ma albo że będzie juniorski.

2. Czy ludzie z tej prezentacji faktycznie dostarczą pracę? Dobra odpowiedź potwierdza, że architekt i liderzy obecni na spotkaniu zostają w projekcie. Jeśli seniorskie twarze znikają po podpisie, a w ich miejsce przychodzą bezimienne „zasoby“, kupiłeś broszurę.

3. Czy architekt Salesforce uczestniczy w projekcie od designu po dostarczenie, czy tylko robi przegląd? Dobra odpowiedź opisuje architekta z realną władzą projektową, obecnego od pierwszej rozmowy do handoveru. Przelotny przegląd na końcu nie wyłapuje prawie niczego. Właśnie dlatego u nas każdy projekt prowadzi architekt.

4. Co się stanie, jeśli kluczowa osoba odejdzie w trakcie projektu? Dobra odpowiedź opisuje udokumentowane decyzje, współdzielony kontekst i plan ciągłości. Firmy, w których średni staż seniorów przekracza 15 lat, mają mniej rotacji do zarządzenia, ale każdy partner powinien mieć odpowiedź lepszą niż „to się nie zdarzy“.

Proces: jak zapadają decyzje i jak obsługiwane są zmiany

5. Jak podejmowane i rejestrowane są decyzje architektoniczne? Dobra odpowiedź wskazuje pisany rejestr decyzji z kontekstem i trade-offami każdej z nich. Decyzje podjęte z rozpędu, nieudokumentowane, stają się długiem technicznym, który dziedziczysz Ty.

6. Jak wygląda proces zmiany, gdy zakres się przesuwa? Dobra odpowiedź opisuje, jak zmiana jest wyceniana, zatwierdzana i rozliczana, zanim ruszy praca — z bramkami decyzyjnymi, a nie licznikiem bez limitu. Milczenie w tym miejscu zapowiada późniejszy spór.

7. Jak reagujecie na wymaganie, które uważacie za błędne? Dobra odpowiedź zawiera świeży przykład sprzeciwu i jego uzasadnienie. Partner, który w fazie sprzedażowej zgadza się na wszystko, zgodzi się też na wszystko, co potem wywróci się na produkcji.

8. Co powstaje w fazie analizy, zanim ruszy budowa? Dobra odpowiedź wymienia konkretne artefakty: projekt rozwiązania, model danych, kontrakty integracyjne, kryteria akceptacji. „Zaczynamy budować w pierwszym tygodniu“ to ostrzeżenie, nie zaleta.

Dowody: dowiezione, porównywalne wdrożenia

9. Czy możecie pokazać porównywalne wdrożenie w mojej branży i mojej skali? Dobra odpowiedź opisuje podobny model danych, wzorzec integracji albo wymóg compliance, a nie tylko pasujące logo. Pracujemy w 7 branżach, więc dopasowuj wzorzec, nie nazwę.

10. Co zbudowaliście i wydaliście jako własny produkt? Dobra odpowiedź obejmuje produkty, które partner utrzymuje w standardzie AppExchange. Budowanie i utrzymywanie własnych aplikacji dowodzi, że partner żyje z konsekwencjami własnych decyzji architektonicznych. Tucario wydaje na AppExchange FTS i Smarter Files.

11. Czy mogę porozmawiać z klientem, u którego projekt poszedł bokiem? Dobra odpowiedź oferuje taką referencję — razem z tym, co poszło nie tak i jak to odratowano. Zadowoloną referencję dostarczy każdy. Prawdziwym sygnałem jest to, jak partner radzi sobie z trudną.

Wyjście: handover i lock-in

12. Co wchodzi w skład waszego pakietu handoverowego? Dobra odpowiedź wymienia rejestr decyzji architektonicznych, dokumentację konfiguracji i metadanych, runbooki, plan wdrożenia administratorów i rejestr otwartych ryzyk. Jeśli handover jest dodatkiem na doczepkę, ktoś właśnie szykuje Ci retainer.

13. Czy mój wewnętrzny zespół albo inny partner mógłby przejąć projekt w tydzień? Dobra odpowiedź to pewne „tak“, poparte pakietem handoverowym z punktu wyżej. Wiedza trzymana w głowach jednej firmy to lewar na Ciebie, wliczony w cenę każdej przyszłej zmiany.

14. Czy metadane, konfiguracja i IP należą do nas? Dobra odpowiedź jest jednoznaczna: org i wszystko, co w nim zbudowano, należy do Ciebie. Uważaj na sformułowania, które zostawiają prawa, konektory albo dokumentację po stronie partnera.

15. Jak wygląda dalsze wsparcie i czy jest opcjonalne? Dobra odpowiedź oferuje wsparcie jako wybór, a nie zależność, z której nie da się wyplątać. Obowiązkowy retainer, żeby Twój własny org w ogóle działał, to podatek od lock-inu.

Jakie sygnały ostrzegawcze kryją się w odpowiedziach?

Słowa znaczą mniej niż poziom konkretu. „Przydzielimy doświadczony zespół“ ukrywa, że zespołu jeszcze nie ma. „Jesteśmy elastyczni co do zakresu“ często znaczy brak change control — a to staje się Twoim kosztem. „Pełna dokumentacja na zakończenie“ bez nazwanych artefaktów zwykle oznacza cienki eksport, z którego nikt nie skorzysta.

Checklista do wydruku

Zabierz ją na rozmowę z dostawcą i oznacz każdą odpowiedź jako konkretną, mglistą albo wymijającą.

1. Imienna lista osób w projekcie, ze stażem i certyfikatami.
2. Potwierdzenie, że zespół z prezentacji dostarczy pracę.
3. Architekt obecny od designu po handover, nie tylko przy przeglądzie.
4. Plan ciągłości na wypadek odejścia kluczowej osoby.
5. Decyzje architektoniczne rejestrowane na piśmie.
6. Proces zmian z wyceną i zatwierdzeniem przed startem prac.
7. Świeży przykład sprzeciwu wobec wymagania.
8. Nazwane artefakty powstające przed startem budowy.
9. Porównywalne wdrożenie w mojej branży i skali.
10. Produkty, które partner zbudował i utrzymuje.
11. Referencja z projektu, który poszedł bokiem.
12. Zdefiniowany, rozpisany pakiet handoverowy.
13. Pewne „tak“ na test przejęcia w tydzień.
14. Jasna własność metadanych, konfiguracji i IP.
15. Wsparcie jako wybór, nie zależność.

Dziewięć lub więcej odpowiedzi „konkretna“ — partner wart krótkiej listy. Trzy lub więcej „wymijająca“ — partner, od którego odchodzisz, niezależnie od odznaki poziomu partnerstwa.

Jak my byśmy odpowiedzieli — i kiedy nas nie potrzebujesz?

My odpowiedzielibyśmy na wszystkie piętnaście nazwiskami i artefaktami, bo dostarczanie prowadzone przez architekta i opublikowany standard handoveru to sposób, w jaki pracujemy od ponad 50 projektów enterprise, w większości dla firm z UE. Nasz główny architekt ma certyfikat Certified Technical Architect, który na całym świecie posiada mniej niż 500 osób.

A teraz uczciwa część. Jeśli Twój projekt to pojedyncza, dobrze wyskopowana zmiana konfiguracyjna z jasnymi wymaganiami i wewnętrznym adminem, który ją utrzyma, nie potrzebujesz firmy takiej jak nasza — a pytania od 9 do 15 będą znaczyć mniej niż cena. Pełną listę bierz wtedy, gdy praca obejmuje kilka chmur, integracje albo migrację danych — tam pytania o wyjście i decyzje przesądzają o całkowitym koszcie posiadania.

Gdy stawka jest na tym poziomie, porozmawiaj z architektem i rozliczaj nas z każdej odpowiedzi powyżej.

Najczęściej zadawane pytania

Jakie jest najważniejsze pytanie do partnera wdrożeniowego Salesforce?

Zapytaj, kto imiennie będzie pracował przy Twoim projekcie i czy zespół z prezentacji sprzedażowej faktycznie dostarczy pracę. Obsada projektu po podpisaniu umowy przewiduje jakość dostarczenia lepiej niż jakakolwiek liczba certyfikatów. Partner, który wskazuje seniorów z imienia i nazwiska i utrzymuje ich w projekcie, komunikuje, że bierze za tę pracę osobistą odpowiedzialność.

Ilu partnerów wdrożeniowych Salesforce powinienem porównać?

Wybierz od trzech do pięciu partnerów, zadaj wszystkim te same piętnaście pytań i porównaj odpowiedzi obok siebie. Przy mniej niż trzech nie masz punktu odniesienia, by ocenić, czy odpowiedź jest mocna, czy słaba. Przy więcej niż pięciu czas na ewaluację rozmywa się tak, że nie zdążysz porządnie drążyć odpowiedzi.

Czym różni się partner wdrożeniowy od resellera Salesforce?

Partner wdrożeniowy projektuje, konfiguruje, integruje i wdraża Salesforce, a potem przekazuje system Twojemu zespołowi. Reseller koncentruje się na sprzedaży licencji. Wiele firm robi jedno i drugie, więc dopytaj, która kompetencja dotyczy Twojego projektu i kto odpowiada za techniczne dostarczenie, gdy licencje są już kupione.

Czy o handover pytać jeszcze przed startem projektu?

Tak. O pakiet handoverowy i własność danych pytaj przed podpisaniem umowy, nie na końcu projektu. Partner, który planuje czyste wyjście, dokumentuje decyzje i konfigurację na bieżąco. Ten, który traktuje handover po macoszemu, wbudowuje vendor lock-in w projekt od pierwszego dnia.

Czy poziom partnerstwa Salesforce mówi, kto będzie najlepszy dla mojego projektu?

Poziomy partnerstwa sygnalizują skalę, przychody i liczbę certyfikatów — nie to, kto obsadzi Twój projekt ani jak głęboko sięgnie przegląd architektury. Potraktuj poziom jako pierwszy filtr, a potem zadaj piętnaście pytań, żeby zobaczyć, co się za nim kryje. Mniejszy partner z dużym udziałem seniorów często wygrywa z wyższym poziomem przy pracy wymagającej skupienia.