Implementare Salesforce: Cost, Durată Și Eșecuri

O implementare Salesforce se aprobă ca o linie de licență și se livrează ca un program. Linia de licență este publică, pe utilizator, pe lună, și ușor de apărat într-un material pentru consiliu. Tot ce transformă acele licențe într-un sistem pe care cineva chiar îl folosește stă în afara ei, iar aceea este partea care decide dacă cifra din business case supraviețuiește primului trimestru.

Salesforce publică prețurile britanice în lire. Sales Cloud Enterprise costă £140 pe utilizator pe lună cu facturare anuală, iar Unlimited costă £280. Cincizeci de utilizatori Enterprise înseamnă £84.000 pe an înainte ca cineva să fi configurat un singur câmp. Estimarea noastră internă pentru serviciile care duc org-ul acela în producție este de una până la trei ori cheltuiala de licență din primul an, iar poziția în interiorul acelui interval nu este întâmplătoare. Patru lucruri o mișcă și doar unul este tehnic.

Cuvântul care contează cel mai mult în cele ce urmează este adopția, pentru că un sistem corect tehnic pe care nu îl folosește nimeni nu este un succes parțial. Este o pierdere totală cu o factură de mentenanță atașată.

Cât costă o implementare Salesforce? Licența este de obicei jumătatea mai mică. Salesforce listează Sales Cloud Enterprise la £140 pe utilizator pe lună în Marea Britanie, deci cincizeci de utilizatori înseamnă £84.000 pe an, iar estimarea noastră internă pentru serviciile de implementare peste asta este de una până la trei ori cheltuiala de licență din primul an. Multiplicatorul depinde de numărul de sisteme integrate, de starea datelor sursă, de gradul de personalizare a proceselor și de disponibilitatea organizației de a-și adapta procesul la produs.

Ce cuprinde de fapt o implementare Salesforce

Un program Salesforce are șase linii de cost și doar una apare pe o pagină de prețuri.

Prima este licența, pe utilizator și pe lună, publicată. A doua sunt serviciile de implementare: consultanții și dezvoltatorii care configurează org-ul, construiesc ce nu poate face configurarea și conduc proiectul. A treia este migrarea datelor, ofertată ca activitate în interiorul implementării și comportându-se ca un proiect de sine stătător. A patra este integrarea, adică legarea Salesforce de sistemele care vă țin deja datele. A cincea sunt instruirea și managementul schimbării. A șasea este administrarea curentă, care nu apare niciodată într-un business case pentru că începe după ce toate celelalte facturi au fost plătite.

Un business case care numește doar licența nu greșește cu puțin. Greșește de obicei cu un factor de doi până la patru, iar diferența stă aproape integral în liniile trei, cinci și șase.

Licența este numărul mic

Prețurile Sales Cloud ale Salesforce pentru Marea Britanie sunt publice și exprimate în lire.

Starter Suite costă £20 pe utilizator pe lună. Pro Suite costă £80 cu facturare anuală. Enterprise, ediția pe care aterizează majoritatea cumpărătorilor britanici din piața mijlocie pentru că este primul nivel cu API web, costă £140. Unlimited costă £280 și include o sandbox Full și Premier Success Plan. Agentforce 1 Sales stă la £440. Cumpărat separat, Premier Success Plan este tarifat la 30% din taxele nete de licență.

De aici decurg două lucruri. Saltul de la Pro Suite la Enterprise este de £60 pe utilizator pe lună, adică £36.000 pe an pentru 50 de utilizatori, și este impus frecvent de o singură cerință de integrare, nu de vreo funcție cerută de echipa de vânzări. Iar planul de suport este un procent, deci crește odată cu factura de licențe, nu cu suportul pe care îl consumați.

Raportul dintre servicii și licențe și ce îl mișcă

Cifra utilă pentru planificare nu este tariful pe zi. Este raportul dintre serviciile din primul an și cheltuiala de licență din primul an, pentru că raportul acela este suficient de stabil ca să se poată discuta despre el.

Benzile noastre interne, din lucrul pe piața mijlocie britanică, sunt acestea. Un rollout aproape standard pe un singur cloud, cu date curate și fără integrări, ajunge la aproximativ 0,5 până la 1 ori cheltuiala de licență din primul an. O implementare tipică, cu două sau trei integrări și o cantitate moderată de obiecte personalizate și automatizare, ajunge la 1 până la 3 ori. Un program multi cloud cu date vechi, cinci sau mai multe integrări și personalizare grea a proceselor merge la 3 până la 5 ori și uneori dincolo. Acestea sunt estimările noastre, nu cifre publicate, iar unui partener care citează un raport fix de industrie ar trebui să îi cereți sursa.

Pe exemplul de £84.000 asta înseamnă £42.000 la capătul de jos, £84.000 până la £252.000 la mijloc și £252.000 în sus la capătul de sus. Deschiderea este toată povestea. Cumpărătorul care a auzit doar că ar costa cam cât licența s-a ancorat la mijlocul unui interval de zece ori mai larg la margini.

Cele patru variabile care mișcă raportul

Doar patru lucruri mută sigur un proiect Salesforce dintr-o bandă în următoarea, iar orice discuție de scoping ar trebui să le stabilească pe toate patru înainte să producă cineva o cifră.

Primul este numărul de sisteme integrate. Fiecare este un proiect separat, un set separat de credențiale, o cale de eroare separată și încă un lucru care se strică atunci când celălalt furnizor lansează o versiune. Costul integrărilor nu este aditiv, este ușor mai rău decât aditiv, pentru că modurile de defectare se înmulțesc.

Al doilea este calitatea datelor la sursă. Nu volumul. Calitatea. Este tratată pe larg mai jos pentru că este linia cel mai constant subestimată din program.

Al treilea este gradul de personalizare a proceselor, adică cât de departe merge designul țintă față de ce face produsul imediat după instalare.

Al patrulea este dacă organizația își va schimba procesul ca să se potrivească produsului. Acesta este cel mai bun predictor unic atât al costului, cât și al succesului, și aproape nimeni nu îl pune în scope, pentru că este o întrebare despre oameni pusă în timpul unei evaluări tehnice.

Disponibilitatea de a schimba este o întrebare de scoping

O organizație care își adaptează procesul de vânzare la modelul de opportunity al Salesforce primește un sistem ieftin, actualizabil și bine susținut. Una care insistă ca Salesforce să reproducă foaia de calcul existentă primește un sistem scump care se luptă cu fiecare versiune.

Semnul din discovery este limbajul. Când cineva din organizație spune că sistemul trebuie să funcționeze așa cum lucrăm noi, bugetul de personalizare este pe cale să se dubleze. Când spune arătați-mi cum ar trebui să funcționeze și explicați-mi de ce, este pe cale să se înjumătățească. Ambele propoziții sunt rezonabile. Doar una este ieftină.

Modul onest de a trata asta este să îl puneți la preț. Puneți două cifre în propunere, una pentru modelul standard și una pentru cel croit pe comandă, și lăsați diferența să facă argumentul. Cumpărătorul care vede că o convenție de denumire a etapelor costă £18.000 de automatizare personalizată și un risc permanent la fiecare actualizare schimbă de obicei convenția. Cel căruia i se răspunde că se poate face nu o schimbă.

Discovery și ce produce unul bun

Discovery este faza cel mai des tăiată ca să se câștige un contract și cel mai des acuzată după aceea. Un discovery care produce o prezentare a fost un exercițiu de vânzare. Unul care produce patru artefacte a fost un exercițiu de inginerie.

Primul este o hartă de proces: succesiunea reală a pașilor prin care un lead devine venit, cu punctele de decizie și oamenii care le dețin, obținută urmărind munca, nu cerându-le managerilor să o descrie.

Al doilea este un model de date: obiecte, câmpuri, relații, valori de picklist și, pentru fiecare câmp, o persoană numită care îl va întreține. Câmpurile fără proprietar devin câmpurile pe care nu le completează nimeni.

Al treilea este un inventar de integrări: fiecare sistem care trimite date către Salesforce sau primește de acolo, cu sens, volum, frecvență, identificatorul care leagă înregistrările și ce se întâmplă când cade conexiunea.

Al patrulea este o definiție a lucrului terminat care să fie măsurabilă. Nu că echipa de vânzări folosește Salesforce, ci ceva de tipul: 90% dintre oportunitățile închise în trimestru au o dată de închidere, o valoare și o etapă setată de proprietar, iar ședința săptămânală de pipeline se ține din dashboard-ul Salesforce, fără nicio foaie de calcul în încăpere.

Într-o procedură competitivă, ghidul nostru pentru cererea de ofertă software se aplică direct: întrebați fiecare ofertant ce produce discovery-ul lui și eliminați-i pe cei care nu pot numi artefactele.

Migrarea datelor este locul unde se duce calendarul

Migrarea este ofertată ca procent din construcție și consumată ca multiplu al ei, dintr-o singură neînțelegere: echipele estimează după numărul de înregistrări, iar efortul de migrare crește cu calitatea sursei.

Două milioane de rânduri curate dintr-un sistem bine întreținut, cu o cheie primară de încredere, înseamnă o săptămână de muncă atentă. Patruzeci de mii de rânduri împrăștiate într-un CRM vechi, trei foi de calcul regionale și un pachet de contabilitate, fără identificator comun și cu unsprezece ani de text liber în câmpul de note, înseamnă două luni și tot vor fi greșite la go live. A doua lucrare are a cincizecea parte din înregistrări și de opt ori efortul.

Profilați sursa înainte să promiteți ceva

A profila înseamnă a număra lucruri înainte de a accepta o dată. Faceți-o pe fiecare sursă și faceți-o înainte ca linia de migrare din propunere să fie semnată.

Numărați valorile nule pe câmp. Numărați valorile distincte din fiecare câmp pe care intenționați să îl faceți picklist, pentru că o coloană de țară cu 340 de valori distincte nu este un picklist, este un proiect de curățare. Numărați câte înregistrări împart o cheie candidat. Măsurați consecvența de format la date, numere de telefon și coduri poștale. Numărați înregistrările fără proprietar, fără adresă de e-mail și fără activitate de trei ani, pentru că nimeni nu le va apăra atunci când propuneți să le lăsați în urmă.

Profilarea costă două până la cinci zile pe un patrimoniu de dimensiune medie. Este cea mai ieftină reducere de risc din program, iar sărirea peste ea este motivul pentru care estimările de migrare greșesc într-o singură direcție.

Deduplicarea și regulile pe care vi le dă platforma

Salesforce are management nativ al duplicatelor, iar limitele lui modelează designul. Puteți avea până la cinci duplicate rule active per obiect și o matching rule activă per obiect, număr care urcă la cinci matching rule active per obiect atunci când folosiți mai multe duplicate rule, iar fiecare duplicate rule poate referi până la trei matching rule.

Două comportamente contează mai mult decât numerele. Match key-urile îngustează comparația la cele mai probabile 100 de duplicate înainte de aplicarea ecuației de potrivire, deci o înregistrare cu peste 100 de potriviri apropiate reale nu va fi evaluată complet. Iar regulile pur și simplu nu rulează pe mai multe căi obișnuite, printre care Quick Create și conversia de Lead fără Apex lead convert activat, și exact așa apar duplicate într-un org care are duplicate rule pornite.

Deci deduplicarea este o activitate de migrare, făcută în datele de staging înainte de încărcare, nu o funcție de runtime pe care o activați și o uitați. Regulile native sunt a doua linie de apărare.

External ID-urile și de ce upsert bate insert

Fiecare obiect migrat are nevoie de un external ID: un câmp personalizat indexat care ține cheia primară din sistemul sursă. Este decizia cu cea mai mare valoare din designul migrării și nu costă nimic.

Cu un external ID puteți folosi upsert, care se bazează pe acel câmp ca să decidă dacă creează sau actualizează o înregistrare. Dacă valoarea nu este găsită se creează o înregistrare, dacă este găsită o dată înregistrarea se actualizează, iar dacă este găsită de mai multe ori se returnează o eroare în loc de un duplicat. Astfel fiecare încărcare este idempotentă, ceea ce înseamnă că o puteți rula de două ori fără să vă dublați datele, ceea ce înseamnă că puteți repeta.

Două detalii mușcă. Potrivirea după external ID ignoră majusculele doar dacă acel câmp are atributul Unique și opțiunea corespunzătoare bifată, altfel ABC123 și abc123 sunt două înregistrări diferite. Iar dacă acel câmp este un external ID fără index unic, contul care încarcă are nevoie de permisiunea View All Data.

Migrarea istoricului față de migrarea a ceea ce folosește

Cererea implicită este să se aducă tot dincolo. Este aproape întotdeauna greșită și este scumpă în trei feluri distincte.

Costă efort de migrare, pentru că datele cele mai vechi sunt cele mai murdare și consumă timp de curățare disproporționat față de valoarea lor. Costă stocare, iar stocarea este o linie reală: org-urile Enterprise, Professional și Unlimited au alocați 10 GB de stocare de date plus 20 MB per licență de utilizator, deci 50 de utilizatori Enterprise înseamnă 11 GB în total, nu 11 GB per utilizator. Și costă adopție, pentru că un sistem plin de înregistrări moarte îi învață pe utilizatori să nu aibă încredere în rezultatele căutării.

Poziția care se poate apăra este să migrați integral înregistrările deschise și recente, să migrați înregistrările închise pentru perioada despre care raportează efectiv afacerea și să arhivați restul undeva unde se poate citi. Păstrarea de date personale de care nu aveți nevoie este mai degrabă o răspundere decât un activ, deci pentru o dată argumentul stocării și cel al conformității arată în aceeași direcție.

Configurare față de cod

Orice cerință în Salesforce poate fi rezolvată declarativ, cu cod sau printr-un amestec, iar alegerea determină cât costă deținerea sistemului în deceniul care vine. Distincția merită ținută clar chiar dacă nu deschideți niciodată un editor de cod.

Ce ar trebui să fie declarativ

Declarativ înseamnă construit prin configurare: obiecte, câmpuri, page layout-uri, reguli de validare și Flow, constructorul vizual de automatizare al Salesforce. Se schimbă de către un administrator, supraviețuiește actualizărilor de platformă pentru că runtime-ul aparține Salesforce și este vizibil pentru oricine are permisiunea potrivită.

Ghidul de decizie pentru automatizarea declanșată de înregistrare publicat de Salesforce oferă un prag utilizabil. Măsoară densitatea automatizării pe trei dimensiuni: numărul de automatizări care pornesc la o singură schimbare de date, volumul de înregistrări per tranzacție și cât de departe cascadează actualizările în aval către obiectele legate. Densitatea mică, adică sub cincisprezece automatizări, loturi de 1 până la 200 de înregistrări și cel mult o scriere în aval, se face în Flow declanșat de înregistrare.

Același ghid dă o regulă care economisește mai mulți bani decât oricare alta de pe listă: folosiți un singur punct de intrare per obiect. Amestecarea de Flow și triggere Apex pe același obiect este calea prin care erorile de ordonare devin permanente.

Când codul pe comandă este alegerea corectă

Densitatea medie merge la un hibrid, cu Flow care orchestrează și Apex invocabil care duce greul, astfel încât succesiunea rămâne vizibilă, iar calculul stă în ceva testabil. Densitatea mare merge la triggere Apex, pentru că în punctul acela uneltele declarative sunt folosite ca să construiască un sistem pentru care nu au fost gândite.

Codul este potrivit și când logica este cu adevărat complexă, când trebuie testată unitar ca lumea și când aceeași operație este apelată din mai multe puncte de intrare și ar trebui să existe o singură dată. Dacă acea muncă o contractați în loc să o angajați, serviciile noastre de dezvoltare software există exact pentru granița aceasta, acolo unde se oprește platforma și începe ingineria pe comandă.

Terminologia se mută, iar termenii vechi sunt un semnal

Salesforce retrage unelte, iar o propunere scrisă pe unelte retrase spune când a fost redactată de fapt. Salesforce a încetat să mai susțină Workflow Rules și Process Builder la 31 decembrie 2025. Regulile existente continuă să ruleze, dar nu există suport pentru clienți și nici corecții de defecte, iar calea recomandată este migrarea la Flow Builder cu unealta Migrate to Flow.

Costul pe termen lung al fiecărei alegeri

Munca declarativă este mai ieftin de construit și mai ieftin de schimbat, iar costul ei este diluarea: o sută de flow-uri nedocumentate devin un sistem în care nimeni nu poate prezice ce va face salvarea unei înregistrări.

Codul este mai scump de construit și mult mai ieftin de urmărit la scară, pentru că poate fi citit, versionat și testat. Costul lui este că are nevoie de dezvoltatori, iar o organizație fără dezvoltator Salesforce și fără contract de întreținere va ajunge să nu își mai poată schimba propriul sistem.

Eșecul care costă cel mai mult nu este niciunul dintre acestea. Este un sistem construit integral declarativ de un partener care apoi pleacă, într-un org fără documentație și fără proprietar numit. Totul funcționează și nimic nu poate fi schimbat în siguranță, ceea ce este aceeași poziție ca la software-ul pe comandă neîntreținut, descris pe larg în materialul nostru despre cât costă cu adevărat mentenanța software.

Integrarea și de ce limitele schimbă arhitectura

Integrarea are tratarea ei separată în articolul nostru despre limitele de integrare Salesforce și costurile reale. Ce aparține aici este ideea că limitele platformei sunt o intrare de arhitectură, nu un detaliu de exploatare descoperit în săptămâna nouă.

Două limite fac cea mai mare parte a modelării. Alocările totale de cereri API pentru un org de Enterprise Edition sunt 100.000 de apeluri la 24 de ore plus numărul de licențe înmulțit cu apelurile pe care le poartă fiecare tip de licență, adică 1.000 pentru o licență Salesforce, plus eventualele add-on-uri cumpărate. Exemplul calculat chiar de Salesforce este un org Enterprise cu 15 licențe Salesforce care obține 115.000 de cereri. Alocarea este valabilă pentru tot org-ul și nu pe utilizator, iar cererile de intrare concurente care rulează 20 de secunde sau mai mult sunt plafonate la 25 în producție.

A doua sunt limitele governor Apex, impuse per tranzacție: 100 de interogări SOQL sincron și 200 asincron, 50.000 de înregistrări aduse prin SOQL, 150 de instrucțiuni DML, 10.000 de înregistrări procesate prin DML, 6 MB de heap sincron și 12 MB asincron și 10.000 de milisecunde de timp CPU sincron față de 60.000 asincron.

Un design care le ignoră trece recepția pe douăzeci de înregistrări și cade la prima încărcare de noapte reală. Nu este un defect. Este o decizie de arhitectură luată din inerție.

Mediile și ce distruge un refresh de sandbox

Salesforce vă dă patru tipuri de sandbox cu stocare și intervale de refresh diferite, iar alegerea greșită este o eroare de planificare care iese la iveală târziu.

Sandbox-urile Developer țin 200 MB și se reîmprospătează o dată pe zi. Developer Pro ține 1 GB, tot zilnic. Partial Copy ține 5 GB, copiază un eșantion din datele de producție definit printr-un template și se reîmprospătează la fiecare cinci zile. Full este o replică a producției și se reîmprospătează la fiecare 29 de zile. Enterprise Edition include 25 de sandbox-uri Developer și una Partial Copy; cele Full vin cu Unlimited și Performance sau se cumpără ca add-on.

Intervalul de 29 de zile al sandbox-urilor Full este constrângerea în jurul căreia se planifică prea târziu. Singurul vostru mediu realist de repetiție a migrării se reîmprospătează o dată pe lună, deci o repetiție care scoate la iveală o problemă costă o lună până puteți repeta curat. Două repetiții în sandbox Full înseamnă o fereastră de nouă săptămâni, nu de două.

Sandbox-urile Developer și Developer Pro copiază doar metadate, deci tot ce a încărcat un dezvoltator acolo ca să testeze dispare după un refresh. Datele de test trebuie să fie un script care se poate rula din nou, ținut în controlul versiunilor, altfel echipa pierde o zi la fiecare refresh recreându-le manual.

Managementul livrărilor: change set-uri față de o pipeline

Nu puteți dezvolta Apex într-un org de producție, deci fiecare schimbare începe în altă parte și trebuie mutată. Cum se mută este o decizie cu coadă lungă.

Change set-urile sunt mecanismul încorporat. Duc doar ce puteți schimba din Setup, niciodată înregistrări, cer o conexiune de deployment între org-uri afiliate aceluiași org de producție, iar un change set de intrare se instalează întreg, nu componentă cu componentă. Se asamblează prin clicuri, deci nu se pot compara, nu se pot revizui și nu se pot repeta, iar același change set asamblat de două ori de două persoane va ieși diferit.

Asta funcționează pentru un org mic cu un singur administrator și livrări lunare. Încetează să funcționeze în clipa în care două persoane schimbă același org, pentru că nu există merge și nu există istoric, iar evidența a ceea ce a plecat trăiește în memoria cuiva.

Alternativa este o pipeline pornită din sursă: metadate în Git, schimbări revizuite ca diff-uri, deployment-uri rulate dintr-o ramură. Costă câteva zile de pregătit și transformă managementul livrărilor dintr-un exercițiu de memorie într-unul repetabil. Cu mai mult de o persoană care construiește, tratați-o ca parte din construcție, nu ca pe o îmbunătățire de mai târziu.

Regula de 75% acoperire nu este un prag de calitate

Ca să duceți Apex în producție trebuie ca testele unitare să acopere cel puțin 75% din codul vostru Apex și acele teste să treacă. Salesforce spune explicit că acoperirea indică eficacitatea testelor fără să o garanteze și că testele ar trebui să verifice comportament.

Citiți ce înseamnă asta comercial. 75% este o poartă, iar porțile se păcălesc. Clasele de test scrise ca să atingă cifra în loc să verifice ceva vor trece, se vor instala și nu vor prinde nimic. Când revizuiți munca unui partener, nu întrebați care este procentul de acoperire. Cereți să vedeți trei metode de test și numărați aserțiunile.

O implementare Salesforce eșuează la adopție, nu la go live

Sistemul intră în producție, proiectul se închide, factura este plătită, iar opt luni mai târziu directorul de vânzări tot își face forecast-ul dintr-o foaie de calcul. Nu s-a stricat nimic. Acesta este cel mai frecvent deznodământ al unui program Salesforce eșuat și este invizibil pentru orice măsură tehnică.

Economia este brutală pentru că licența costă la fel indiferent. Cincizeci de utilizatori Enterprise la £140 pe lună înseamnă £84.000 pe an, folosit sau nu sistemul, deci o rată de adopție de 40% este aproximativ £50.000 pe an de risipă pură doar pe licență, înainte ca implementarea să fie amortizată pe ceva.

Adopția este și singurul mod de eșec pe care echipa tehnică nu îl poate repara. Un partener poate construi exact ce a fost specificat, poate îndeplini fiecare criteriu de acceptanță și poate lăsa în urmă ceva ce nu deschide nimeni. De aceea definiția lucrului terminat din discovery trebuie să fie despre utilizare și de aceea proiectul nu ar trebui considerat închis la go live.

Practicile care mișcă adopția

Patru lucruri mișcă adopția în mod sigur și niciunul nu este un video de instruire.

Instruire pe roluri, ținută separat. Un reprezentant de vânzări și un manager de vânzări folosesc părți diferite din sistem din motive diferite, iar o sesiune comună îi învață prost pe amândoi. Instruiți fiecare rol pe fluxul lui de lucru și pe nimic altceva.

Un set mic de câmpuri obligatorii. Alegeți cele mai puține câmpuri care fac raportarea să funcționeze, faceți-le obligatorii pe acelea și lăsați tot restul opțional. Fiecare câmp obligatoriu în plus este un motiv de a abandona o înregistrare la jumătate, iar un sistem care pedepsește introducerea de date primește mai puține.

Raportare pentru manageri care depinde de datele acelea. Aceasta este practica ce funcționează. Dacă ședința săptămânală de pipeline se ține dintr-un dashboard Salesforce, fără foaie de calcul în încăpere, datele se introduc, pentru că alternativa este să lipsești din discuție. Dacă managerul ține o foaie de calcul privată, CRM-ul este opțional și toată lumea știe asta.

Un proprietar numit, cu timp alocat în săptămâna lui. Nu un comitet. O persoană care deține org-ul, are permisiunile de administrator, este măsurată pe adopție și are ore alocate pentru asta. Org-urile fără așa ceva se degradează din prima lună.

Modurile de eșec și semnele lor timpurii

Șase moduri de eșec explică cea mai mare parte a eșecurilor de implementare Salesforce pe care ni se cere să le reparăm, iar fiecare arată un semn cu mult înainte de pagubă.

Replicarea unui proces stricat. Semnul de avertizare este un document de cerințe care descrie sistemul actual în loc de rezultatul dorit, cu numele de câmpuri ale sistemului vechi. Automatizarea unui proces prost îl face mai rapid și mai greu de schimbat.

Personalizare nelimitată. Semnul de avertizare este un registru de cereri de schimbare fără nicio respingere în el. Enterprise Edition permite 500 de câmpuri personalizate per obiect și 200 de obiecte personalizate, destul spațiu ca să construiți ceva ce nimeni nu poate întreține cu mult înainte de a atinge o limită de platformă.

Niciun proprietar unic. Semnul de avertizare este că răspunsul la întrebarea cine deține Salesforce conține cuvântul și.

Migrarea a tot. Semnul de avertizare este un scop de migrare definit prin numărul de înregistrări în loc de o decizie de retenție.

Nicio disciplină a mediilor de test. Semnul de avertizare este cineva care spune să faceți schimbarea direct în producție, că doar e o valoare de picklist.

Măsurarea go live-ului în loc de utilizare. Semnul de avertizare este un plan de proiect al cărui ultim jalon este o dată și nu o cifră.

Durate pentru implementări mici, mijlocii și complexe

Durata și efortul sunt întrebări diferite, iar cumpărătorii le confundă. Acestea sunt benzile noastre interne din piața mijlocie britanică, nu cifre publicate.

O implementare mică, până la circa 25 de utilizatori pe un singur cloud, cu cel mult o integrare și o sursă de date curată, durează 6 la 10 săptămâni și 20 la 45 de zile de consultanță. Una mijlocie, 25 la 150 de utilizatori pe unul sau două cloud-uri, cu două până la patru integrări și o migrare reală, durează 4 la 7 luni și 90 la 220 de zile. Un program complex, peste 150 de utilizatori, multi cloud, cinci sau mai multe integrări și mai multe țări, durează 9 la 18 luni și 400 de zile în sus.

În aceste totaluri, discovery înseamnă 10 la 15% din efort, configurarea și construcția 30 la 40%, migrarea datelor 20 la 30% și crește puternic la o sursă slabă, integrarea 10 la 20%, iar testarea, instruirea și hypercare 15 la 20%. Linia care se dilată este de fiecare dată migrarea.

Durata depășește efortul împărțit la mărimea echipei din motive care nu țin de echipă: intervalele de refresh ale sandbox-urilor, disponibilitatea părților interesate pentru recepție și așteptarea terțului care expune API-ul. Cine duce riscul acela se decide prin contract, motiv pentru care alegerea între preț fix și regie contează pe lucrările CRM mai mult decât în alte părți.

Protecția datelor din Marea Britanie într-un program CRM

Un CRM este o bază de date despre oameni, deci UK GDPR se aplică practic la tot ce conține, iar la fiecare implementare apar trei întrebări.

Este nevoie de o DPIA?

Ghidul ICO despre când este necesară o DPIA enunță regula generală din articolul 35(1), potrivit căreia o DPIA este necesară acolo unde prelucrarea poate genera un risc ridicat pentru drepturile și libertățile persoanelor, și listează setul propriu de operațiuni al ICO conform articolului 35(4).

Două dintre ele cad exact pe o migrare CRM tipică. Data matching, definit ca îmbinarea, compararea sau potrivirea de date personale obținute din mai multe surse, este exact ce face o migrare de consolidare. Profilarea la scară largă acoperă scoringul de lead-uri și de conturi. ICO mai notează că în majoritatea cazurilor o combinație de două dintre criteriile europene indică nevoia unei DPIA, deși nu este o regulă strictă. Rețineți că acest ghid este în curs de revizuire din cauza modificărilor aduse de Data (Use and Access) Act, deci verificați-l în loc să vă bazați pe un rezumat.

Unde stau de fapt datele?

Salesforce este o platformă globală, iar instanța pe care rulează org-ul vostru este o chestiune contractuală, nu o presupunere. Ghidul scurt al ICO despre transferurile internaționale, actualizat ultima dată la 15 ianuarie 2026, dă un test în trei pași: se aplică UK GDPR prelucrării, inițiați voi transferul către o organizație din afara Marii Britanii și este destinatarul o entitate juridică separată. Trei da fac din el un transfer restricționat.

Transferurile restricționate au nevoie de reglementări britanice de adecvare, de garanții adecvate precum International Data Transfer Agreement, Addendum-ul sau regulile corporatiste obligatorii, ori de o excepție. Acolo unde vă bazați pe garanții, ICO așteaptă o evaluare a riscului transferului. Aceasta este o revizuire de contract, nu o sarcină de inginerie, și ar trebui să aibă loc înainte de migrare, nu după.

Partenerul vostru de implementare este împuternicit

Când un partener vă configurează org-ul, vă încarcă datele și deține credențiale către el, prelucrează date personale în numele vostru. Ghidul ICO despre operatori și persoane împuternicite arată ce decurge din asta, iar implicațiile practice sunt contractuale.

Aveți nevoie de un acord scris care să acopere instrucțiuni documentate, confidențialitate, securitate, subîmputerniciți, drepturi de audit și ștergerea sau returnarea datelor la finalul colaborării. Ultima este clauza care lipsește cel mai des. Un partener care a ținut unsprezece luni o copie completă a bazei voastre de clienți într-o sandbox Full și al cărui contract nu spune nimic despre ștergerea ei este o răspundere deschisă de partea voastră a liniei, nu de a lui.

Ce să întrebați un posibil partener

Șase întrebări și răspunsurile care ar trebui să încheie discuția.

Întrebați ce produce discovery-ul. Dacă răspunsul este o propunere în loc de o hartă de proces, un model de date, un inventar de integrări și o definiție măsurabilă a lucrului terminat, se vinde, nu se face scoping.

Întrebați cum și când vor profila datele sursă. Dacă profilarea vine după ce estimarea de migrare este agreată, estimarea este o ghiceală.

Întrebați care este opțiunea lor implicită pentru automatizare și ascultați dacă vorbesc despre densitate. Un partener care spune mereu Flow sau mereu Apex are o singură unealtă. Un partener care prevede Process Builder în 2026 nu a citit un anunț de retragere de trei ani.

Întrebați cum trec schimbările din sandbox în producție. Change set-urile sunt acceptabile pentru un org cu un singur administrator și sunt un semnal de alarmă pentru orice este mai mare.

Întrebați cine deține org-ul după go live și câte ore pe săptămână înseamnă asta. Dacă nu pot răspunde, adopția nu este problema nimănui.

Întrebați ce se întâmplă cu datele voastre din sandbox-urile lor când se termină colaborarea și obțineți răspunsul în contract, nu într-un e-mail. Aceeași disciplină din ghidul nostru de due diligence tehnic se aplică și aici: verificați afirmația în loc să acceptați asigurarea.

Când răspunsul nu este Salesforce

Dacă aveți mai puțin de vreo zece utilizatori, nicio cerință de integrare și un proces care încape într-o pipeline cu cinci etape, licența Enterprise și implementarea ei sunt amândouă mai mari decât problema. Un CRM mai ieftin, sau Starter Suite la £20 pe utilizator, face treaba și poate fi înlocuit mai târziu la un cost pe care îl puteți absorbi.

Dacă cerința voastră reală este un flux de lucru pe care nu îl susține niciun produs, iar tot restul este deja rezolvat, cumpărați o platformă ca să găzduiți o singură aplicație. De obicei acesta este un caz pentru un sistem construit anume, iar munca noastră de software pe comandă pleacă de la această premisă. Decizia dintre a construi și a cumpăra se joacă pe faptul că procesul care vă diferențiază este miezul afacerii sau un detaliu din jurul ei.

Dacă nimeni nu va deține sistemul, nu îl cumpărați. Este cel mai greu lucru de spus într-un proces de vânzare și cel mai sigur predictor al risipei. Un CRM fără proprietar nu eșuează zgomotos. Devine în tăcere o copie a foii de calcul pe care trebuia să o înlocuiască, la £140 pe utilizator pe lună.

Iar dacă ținta este un strat de agenți AI în loc de un CRM, acesta stă peste o implementare care funcționează, nu în locul ei. Economia este tratată în materialul nostru despre cât costă de fapt Agentforce.

Ordinea în care se face treaba

Ordinea care funcționează este: profilați datele, faceți discovery până la patru artefacte, agreați modelul standard și puneți preț pe fiecare abatere de la el, construiți cu un singur punct de intrare de automatizare per obiect, repetați migrarea de două ori într-o sandbox Full, instruiți pe roluri și țineți proiectul deschis până se atinge o cifră de utilizare, nu o dată.

Ordinea care eșuează este: semnați, configurați, migrați târziu, instruiți o dată, intrați în producție la termen, închideți proiectul.

Mecanik lucrează la părțile din toate acestea care sunt inginerie, nu administrare de licențe: designul integrărilor față de limitele reale ale platformei, profilarea și uneltele de migrare, dezvoltarea pe comandă acolo unde se termină configurarea și munca de front end care pune datele din CRM în fața clienților. Paginile noastre de servicii de dezvoltare software și de angajare de dezvoltator web arată cum colaborăm. Dacă vreți o a doua opinie despre estimarea unui partener înainte să semnați, puteți angaja un dezvoltator doar pentru acea revizuire.

Întrebări frecvente

Cât costă o implementare Salesforce în Marea Britanie? Salesforce listează Sales Cloud Enterprise la £140 pe utilizator pe lună în Marea Britanie, cu facturare anuală, deci 50 de utilizatori înseamnă £84.000 pe an doar în licențe. Estimarea noastră internă pentru serviciile de implementare peste asta este de 0,5 până la 1 ori cheltuiala de licență din primul an pentru un rollout aproape standard, de 1 până la 3 ori pentru un proiect tipic de piață mijlocie și de 3 până la 5 ori pentru un program multi cloud cu date vechi și personalizare grea.

Cât durează o implementare Salesforce? Benzile noastre interne sunt 6 la 10 săptămâni și 20 la 45 de zile de consultanță pentru până la 25 de utilizatori pe un singur cloud cu date curate, 4 la 7 luni și 90 la 220 de zile pentru 25 la 150 de utilizatori cu două până la patru integrări și 9 la 18 luni și 400 de zile în sus pentru un program multi cloud cu migrare de date vechi. Migrarea datelor este faza care se dilată, pentru că efortul ei crește cu calitatea datelor sursă, nu cu numărul de înregistrări.

De ce eșuează implementările Salesforce? Aproape întotdeauna la adopție, nu la go live. Un sistem corect tehnic pe care nu îl folosește nimeni este o pierdere totală cu o factură de licențe care curge mai departe. Cauzele obișnuite sunt replicarea unui proces stricat, personalizarea nelimitată, lipsa unui proprietar unic numit, migrarea tuturor datelor istorice, lipsa disciplinei mediilor de test și măsurarea go live-ului în loc de utilizare.

Salesforce ar trebui construit prin configurare sau cu cod pe comandă? Ghidul de decizie al Salesforce stabilește pragul după densitatea automatizării. Sub cincisprezece automatizări pe un obiect, loturi de 1 până la 200 de înregistrări și cel mult o scriere în aval se fac în Flow declanșat de înregistrare. Densitatea medie se potrivește cu Flow care orchestrează Apex invocabil. Densitatea mare se potrivește cu triggere Apex. Folosiți un singur punct de intrare per obiect în loc să amestecați Flow și triggere Apex pe același obiect.

Avem nevoie de o DPIA pentru o implementare Salesforce? Adesea da. ICO enumeră data matching, adică îmbinarea sau compararea de date personale din mai multe surse, și profilarea la scară largă printre operațiunile care indică nevoia unei DPIA, iar o migrare de consolidare cu scoring de lead-uri le face pe amândouă. Ghidul este în curs de revizuire după Data (Use and Access) Act, deci verificați poziția actuală a ICO, nu un rezumat al ei.