Logo TucarioThe Tucario Blog

Duży SI czy butik Salesforce: szczere porównanie

Duży SI czy butik do Twojego programu Salesforce? Szczere porównanie skali, gęstości seniorów, szybkości, kosztu i ryzyka — i kiedy wygrywa model hybrydowy.

Michał Bajdek

Współzałożyciel, Tucario

9 min czytania

Udostępnij artykuł

Kluczowe wnioski

  • Duży SI ma rację bytu w programach, które są najpierw duże, a dopiero potem złożone: szybkie obsadzenie setek ludzi, machina zakupowa i logistyka globalnych wdrożeń.
  • Narzut dużego SI nie kupuje gęstości seniorów. Typowy obrazek: principals rozciągnięci na wiele kont, a budowa w rękach rotującej piramidy juniorów.
  • Butik wygrywa, gdy program jest najpierw złożony, a dopiero potem duży — bo architekci zostają przy samej robocie, a zmiany zakresu załatwia jedna rozmowa.
  • W programach średnich i dużych często wygrywa hybryda: butikowy autorytet projektowy nad skalowalnym zespołem wdrożeniowym łączy odpowiedzialność z większą liczbą rąk.

Duży SI sprawdzi się w dużych, międzynarodowych programach Salesforce, gdzie potrzebna jest machina zakupowa i setki ludzi do pracy. Butik sprawdzi się tam, gdzie o wyniku decydują gęstość seniorów, szybkość i odpowiedzialność. Co wybrać, zależy od wielkości programu, geografii i apetytu na ryzyko — nie od prestiżu marki.

Wpisz to pytanie w Google, a trafisz niemal wyłącznie na teksty o karierze: kto lepiej płaci, co lepiej wygląda w CV, jak przeskoczyć z jednej strony na drugą. Pytanie klienta — kto powinien dowieźć mój program — zostaje bez odpowiedzi. Odpowiadamy na nie jako partner, który bez problemu przyznaje, kiedy duży SI nas pokonuje.

Duża piramida wielu małych figurek i mały, zgrany zespół stojące na równi na wadze szalkowej

Czym różni się duży SI od butikowej firmy konsultingowej Salesforce?

Duży SI (integrator systemów w skali Accenture, Deloitte czy IBM) ma setki konsultantów w biurach na całym świecie, sformalizowane procedury zakupowe, własne metodyki wdrożeniowe i bench, z którego obsadza projekty. Butikowa firma konsultingowa Salesforce to małe, seniorskie zespoły, w których architekt sam pracuje przy projekcie. Pierwszy sprzedaje skalę. Drugi — głębię i ciągłość.

Z tej różnicy wynika wszystko dalsze: kto pojawi się na Twoich warsztatach projektowych, jak zapadają decyzje, jak szybko pochłaniane są zmiany zakresu i kto odpowiada za wynik, gdy release się opóźni. Żaden z modeli nie jest lepszy sam w sobie. Każdy pasuje do innego typu programu.

W czym duże SI są naprawdę dobre

Duże SI mają rację bytu w programach, które są najpierw duże, a dopiero potem złożone. Gdy od następnego kwartału potrzebujesz 120 osób w pięciu krajach, butik tego nie obsadzi — i nie powinien udawać, że potrafi. Ta sama ekonomia bencha, przez którą duży SI jest drogi przy małych projektach, przy bardzo dużych czyni go jedyną realną opcją.

Duży SI ma też sens tam, gdzie najtrudniejsze są formalności. Ramowe umowy (MSA), ankiety bezpieczeństwa, certyfikaty ubezpieczeniowe i wzorce prawne ma gotowe pod dział zarządzania dostawcami firmy z Fortune 500. Jeśli program nie może ruszyć, dopóki dokumenty nie przejdą przez globalny proces zakupowy, ta machina jest realnie warta swojej ceny.

Trzeci przypadek to globalne wdrożenia. Koordynowanie lokalnych integratorów, regionalnych zasad rezydencji danych i wsparcia follow-the-sun w kilkunastu krajach to tak samo problem logistyczny jak salesforce’owy. Duże SI przerabiały to już wielokrotnie — i za ten playbook warto zapłacić.

Oddajmy im tu sprawiedliwość. We właściwym programie to właśnie skala jest celem, a narzut — jej ceną.

Co kupuje narzut dużego SI — a czego nie

Narzut w stawce dużego SI kupuje infrastrukturę sprzedaży, metodykę, globalne pokrycie i przejęcie ryzyka na poziomie korporacji. Część z tego działa na Twoją korzyść: partner, który nie zbankrutuje w połowie programu, to przy wieloletnim zobowiązaniu prawdziwe ubezpieczenie.

Czego ten narzut nie kupuje? Gęstości seniorów na Twoim projekcie. Ci, którzy wygrali zlecenie, często nie są tymi, którzy je dowiozą. Zwykle wygląda to tak: garstka principals rozciągnięta na wiele kont, a codzienna budowa w rękach rotującej piramidy juniorów. Decyzje podjęte domyślnie przez kogoś, kto uczy się Salesforce za Twoje pieniądze, trzeba później odkręcać — i kosztuje to więcej, niż wyniosły oszczędności na stawce dziennej.

Piramida dokłada jeszcze podatek od ciągłości. Ludzie rotują, wiedza odchodzi razem z nimi, a architektura trzymana w czyjejś głowie wychodzi przez drzwi na koniec rotacji. Jeśli co kilka miesięcy te same decyzje toczą się od nowa, bo nikt seniorski nie został, stawka, którą tak długo negocjowałeś, okazuje się najmniejszą pozycją w całkowitym koszcie.

Kiedy butikowa firma konsultingowa Salesforce jest lepszym wyborem?

Butik wygrywa tam, gdzie o wyniku decydują gęstość seniorów, szybkość i odpowiedzialność. W małym zespole architekt pracuje przy samej budowie, więc decyzje projektowe zapadają raz — i podejmuje je ktoś, kto bierze za nie odpowiedzialność. Nie ma bencha do wykarmienia, więc nie ma też pokusy, żeby pompować zespół albo rozciągać harmonogram. Jedna osoba, którą możesz pociągnąć do odpowiedzialności, to zaleta, nie ograniczenie.

Butiki pasują do programów, które są najpierw złożone, a dopiero potem duże: trudna integracja, model danych, który ma przetrwać Agentforce, migracja, w której przypadki brzegowe to cała robota. Tutaj liczy się głębia, nie liczba głów. Dziesięciu juniorów nie zastąpi jednego architekta, który już widział, jak to się wywraca.

Szybkość to drugi atut. Zmianę zakresu, która u dużego SI uruchomiłaby cykl change requestów i rozmowy o re-staffingu, w butiku załatwia jedna rozmowa. Gdy wymagania wciąż się zmieniają, ta przewaga narasta z każdym tygodniem.

Jest też granica, o której trzeba mówić wprost: butik nie wystawi 120 osób od następnego kwartału, nie zawsze odhaczy globalną checklistę zakupową i bardziej ryzykuje przy odejściu kluczowego seniora. Zapytaj więc każdy butik, jak zabezpiecza ryzyko kluczowej osoby. Ogólnikowa odpowiedź to poważna czerwona flaga.

Big 4 czy butik Salesforce: jakie są wady i zalety?

Duże SI wygrywają skalą, dopasowaniem do procedur zakupowych i przejęciem ryzyka — kosztem wyższej ceny i rozwodnionej uwagi seniorów. Butiki wygrywają gęstością seniorów, szybkością i odpowiedzialnością — nie obsadzą jednak bardzo dużych programów i niosą ryzyko kluczowej osoby. Tabela poniżej zestawia te kompromisy jeden przy drugim, żebyś mógł zważyć je pod swój program.

Wymiar Duży SI Butik
Gęstość seniorów na Twoim projekcie Niska: principals rozciągnięci, budowa głównie na juniorach Wysoka: architekci przy samej robocie
Skala (ile osób i jak szybko) Bardzo wysoka: bench liczący setki Ograniczona: małe seniorskie zespoły
Szybkość zmiany zakresu Wolniejsza: cykle change requestów i re-staffingu Szybka: załatwiana jedną rozmową
Dopasowanie do procedur zakupowych i compliance Mocne: MSA i dokumenty bezpieczeństwa gotowe Różne: sprawdź, zanim się zwiążesz
Logistyka globalnych wdrożeń Mocna: sprawdzone playbooki na wiele rynków Ograniczona: najlepiej działa w jednym regionie lub wąskim zakresie
Odpowiedzialność Rozproszona po piramidzie Skoncentrowana: jeden właściciel
Ryzyko kluczowej osoby / bus factor Niskie: głęboki bench Wyższe: zapytaj, jak jest zabezpieczone
Ciągłość w trakcie programu Podatek od rotacji: wiedza odchodzi z ludźmi Ci sami seniorzy od pierwszej rozmowy po przekazanie
Koszt w przeliczeniu na rezultat Wysoki narzut, ryzyko rozwodnienia Niższy narzut, praca na seniorskich stawkach
Wyjście i lock-in Częsty lock-in na framework Przekazanie priorytetem, jeśli tak zapisane w umowie

Czytaj tabelę pod swój program, nie pod markę. Co rozstrzyga sprawę w jednym projekcie, w innym nie ma znaczenia.

Kiedy zatrudnić dużego SI do programu Salesforce?

Duży SI ma sens wtedy, gdy najtrudniejsza jest skala, procedury zakupowe albo globalna koordynacja. Jeśli potrzebujesz szybko setek osób, musisz przejść proces zarządzania dostawcami w firmie z Fortune 500 albo koordynujesz wdrożenie w wielu krajach z lokalnymi integratorami — machina dużego SI zwraca się z nawiązką. Przy bardzo dużych programach żaden butik nie jest w stanie uczciwie konkurować.

Poniższa tabela decyzyjna zamienia te uogólnienia na konkretne sytuacje.

Twoja sytuacja Lepsze dopasowanie Dlaczego
Wdrożenie w wielu krajach, 100+ osób, ciasny termin startu Duży SI Obsadzi to tylko bench liczący setki
Globalny proces zakupowy do przejścia przed kickoffem Duży SI Wartością jest machina formalności
Jedna chmura albo wąskie multi-cloud, złożona integracja Butik Tu głębia bije liczbę głów
Wymagania wciąż się zmieniają, liczy się szybkość Butik Zmiana załatwiana, nie renegocjowana
Jeden region, priorytetem odpowiedzialność seniora Butik Architekt zostaje przy robocie
Dane regulowane, trudne przypadki brzegowe w jakości danych lub migracji Butik Przypadki brzegowe nagradzają doświadczenie
Bardzo duży budżet, niska tolerancja na ryzyko dostawcy Duży SI Ryzyko przejmuje korporacja
Program, który potem ma przejąć mały zespół wewnętrzny Butik Wdrożenie nastawione na przekazanie, bez lock-inu

Rozwidlenie decyzyjne, w którym jedna ścieżka rozlewa się w szeroką siatkę wielu węzłów, a druga zwęża do kilku gęsto połączonych

Kto powinien dowieźć Twój program Salesforce?

Dopasuj model do kształtu programu — i zanim założysz, że to albo-albo, rozważ hybrydę. W programach średnich i dużych często wygrywa układ, w którym butikowy autorytet projektowy stoi nad skalowalnym zespołem wdrożeniowym: seniorski architekt odpowiada za projekt rozwiązania i decyzje, a większy integrator lub zespół nearshore daje ręce do budowy pod jego kierownictwem.

Dzięki temu seniorska odpowiedzialność zostaje tam, gdzie jest najważniejsza — przy projekcie i trudnych decyzjach — a Ty masz ludzi do masowej części prac, która nie wymaga architekta przy każdej linii. To sposób na rygor dużego SI bez płacenia za jego rozwodnienie. Czego unikać? Odwrotnego układu: skalowalnego zespołu bez autorytetu projektowego, w którym piramida podejmuje decyzje domyślnie i nikt seniorski nie odpowiada za wynik. Właśnie po to istnieje model wdrożeń pod wodzą architekta — żeby temu zapobiegać.

Tucario świadomie jest po stronie butikowej. Każde zlecenie prowadzi u nas architekt, a za zespołem stoi Salesforce Certified Technical Architect (jeden z mniej niż 500 na świecie) i dorobek ponad 50 wdrożeń klasy enterprise w 7 branżach, dla firm z UE. Wydajemy własne aplikacje na AgentExchange (dawniej AppExchange) — Flexible Team Share i Smarter Files — i to jest ta sama dyscyplina, którą wnosimy w Twój projekt. Jeśli Twój program naprawdę wymaga globalnego bencha liczącego setki, powiemy Ci to wprost — i pomożemy dobrze zbriefować SI, zamiast udawać, że nim jesteśmy.

Jeśli Twój program jest najpierw złożony, a dopiero potem duży, i chcesz, żeby architekt, który go projektuje, dotrwał z Tobą do przekazania, porozmawiaj z architektem o swoim programie Salesforce. A jeśli wciąż porównujesz modele, porównanie: freelancer, firma konsultingowa czy SI obejmuje mniejszą skalę tej samej decyzji.

Najczęściej zadawane pytania

Co jest tańsze w Salesforce: duży SI czy butikowa firma konsultingowa?

Butiki zwykle wychodzą taniej w przeliczeniu na rezultat, bo nie mają bencha do utrzymania i mniej rozwadniają seniorów — choć same stawki dzienne potrafią wyglądać podobnie. Duże SI mają wyższy narzut. Przy bardzo dużych programach duży SI bywa jedyną opcją, która jest w stanie obsadzić robotę — i to całkowicie zmienia porównanie.

Co uznajemy za butikową firmę konsultingową Salesforce?

Butik to małe, seniorskie zespoły, w których architekci zostają przy wdrożeniu — a nie model, w którym zlecenie wygrywają principals, a buduje piramida juniorów. Poznasz go po kilku sygnałach: seniorzy wskazani z imienia na Twoim projekcie, wydane produkty takie jak aplikacje na AgentExchange, ludzie po review board i uczciwa wycena zakresu. Nie o rozmiar tu chodzi, tylko o gęstość seniorów.

Czy można łączyć dużego SI i butik?

Tak — i w programach średnich i dużych hybryda często wygrywa. Autorytet projektowy i trudne decyzje należą do architekta z butika, a większy integrator lub zespół nearshore dostarcza moc wdrożeniową pod jego kierownictwem. Seniorska odpowiedzialność zostaje nietknięta, a Ty masz ręce do masowej części prac.

Jak sprawdzić ryzyko kluczowej osoby u butika?

Zapytaj wprost, jak zabezpieczają utratę głównego architekta: udokumentowane decyzje, więcej niż jeden senior na koncie i standard przekazania od pierwszego dnia. Ogólnikowa odpowiedź to czerwona flaga. Butik pewny swojego zabezpieczenia bus factor opisze je konkretnie, a nie ogólnikowymi zapewnieniami.

Czy mniejsza firma konsultingowa oznacza mniejszą wiedzę o Salesforce?

Nie. Wiedza koncentruje się w gęstości seniorów, nie w liczbie głów. Butik zbudowany wokół Certified Technical Architect i seniorów z wieloletnim stażem ma często więcej konkretnej głębi w przeliczeniu na osobę niż duża piramida. Weryfikujesz to tak samo w obu modelach: ludzie wskazani z imienia, ludzie po review board i wydane produkty, które możesz obejrzeć.

Michał Bajdek

Współzałożyciel, Tucario

Współzałożyciel Tucario — firmy konsultingowo-produktowej Salesforce. Pracuje przy enterprise’owych wdrożeniach Salesforce — architektura, integracje i produkty AppExchange — i pisze o tym, co sprawdza się w środowiskach produkcyjnych.

Odkryj powiązane treści według tematu