Salesforce Bevezetés: Költség, Ütemterv, Buktatók

Egy Salesforce bevezetést licencsorként hagynak jóvá, és programként szállítanak le. A licencsor nyilvános, felhasználónként, havonta, és egy vezetőségi előterjesztésben könnyű megvédeni. Minden, ami ezekből a licencekből olyan rendszert csinál, amelyet valaki tényleg használ, ezen a soron kívül van, és éppen ez a rész dönti el, hogy az üzleti terv száma túléli-e az első negyedévet.

A Salesforce fontban teszi közzé a brit árait. A Sales Cloud Enterprise éves számlázással £140 felhasználónként havonta, az Unlimited pedig £280. Ötven Enterprise felhasználó évi £84 000, még mielőtt bárki egyetlen mezőt is beállított volna. A házon belüli becslésünk azokra a szolgáltatásokra, amelyek az adott orgot élesbe viszik, az első év licenckiadásának egyszerese és háromszorosa között mozog, és a sávon belüli hely nem véletlenszerű. Négy dolog mozgatja, és csak az egyik technikai.

Az itt következőkben az adaptáció a legfontosabb szó, mert egy technikailag helyes rendszer, amelyet senki sem használ, nem részsiker. Teljes veszteség, karbantartási számlával a nyakán.

Mennyibe kerül egy Salesforce bevezetés? A licenc rendszerint a kisebbik fele. A Salesforce az Egyesült Királyságban £140 felhasználónkénti havidíjjal listázza a Sales Cloud Enterprise csomagot, így ötven felhasználó évi £84 000, a bevezetési szolgáltatásokra pedig a házon belüli becslésünk az első év licenckiadásának egyszerese és háromszorosa között mozog. A szorzót az integrált rendszerek száma, a forrásadatok állapota, a folyamattestreszabás mértéke és az szabja meg, hogy a szervezet hajlandó-e a folyamatát a termékhez igazítani.

Mit tartalmaz valójában egy Salesforce bevezetés

Egy Salesforce programnak hat költségsora van, és ezek közül csak egy szerepel egy árlistán.

Az első a licenc, felhasználónként és havonta, nyilvánosan. A második a bevezetési szolgáltatás: a tanácsadók és fejlesztők, akik beállítják az orgot, megépítik azt, amit a konfiguráció nem tud, és viszik a projektet. A harmadik az adatmigráció, amelyet a bevezetésen belüli feladatként áraznak, de önálló projektként viselkedik. A negyedik az integráció, vagyis a Salesforce összekötése azokkal a rendszerekkel, amelyek már őrzik az adataikat. Az ötödik az oktatás és a változáskezelés. A hatodik a folyamatos üzemeltetés, amely soha nem szerepel az üzleti tervben, mert akkor kezdődik, amikor minden más számlát már kifizettek.

Az az üzleti terv, amely csak a licencet nevezi meg, nem kicsivel téved. Rendszerint kettő és négy közötti szorzóval téved, és a különbség szinte teljes egészében a harmadik, az ötödik és a hatodik sorban van.

A licenc a kisebbik szám

A Salesforce brit Sales Cloud árlistája nyilvános, és fontban van megadva.

A Starter Suite £20 felhasználónként havonta. A Pro Suite £80 éves számlázással. Az Enterprise, az a kiadás, amelynél a legtöbb brit középpiaci vevő köt ki, mert ez az első szint webes API-val, £140. Az Unlimited £280, és tartalmaz egy Full sandboxot, valamint a Premier Success Plant. Az Agentforce 1 Sales £440. Külön megvásárolva a Premier Success Plan ára a nettó licencdíjak 30%-a.

Ebből két dolog következik. A Pro Suite és az Enterprise közötti ugrás £60 felhasználónként havonta, ami ötven felhasználónál évi £36 000, és gyakran egyetlen integrációs követelmény kényszeríti ki, nem pedig valamilyen funkció, amelyet az értékesítés kért. A támogatási csomag pedig százalék, tehát a licencszámlával nő, nem azzal a támogatással, amelyet elhasználnak.

A szolgáltatás és a licenc aránya, és ami mozgatja

A tervezéshez használható szám nem a napidíj. Az első év szolgáltatásainak és az első év licenckiadásának aránya az, mert ez az arány elég stabil ahhoz, hogy vitatkozni lehessen róla.

A brit középpiaci munkából származó házon belüli sávjaink a következők. Egy majdnem érintetlen, egyfelhős bevezetés tiszta adatokkal és integráció nélkül nagyjából az első év licenckiadásának 0,5 és 1 közötti szorzójánál landol. Egy tipikus bevezetés két vagy három integrációval, mérsékelt mennyiségű egyedi objektummal és automatizmussal 1 és 3 közötti szorzónál landol. Egy több felhőt érintő program örökölt adatokkal, öt vagy több integrációval és erős folyamattestreszabással 3 és 5 közötti szorzón fut, néha azon túl is. Ezek a mi becsléseink, nem közzétett számok, és attól a partnertől, aki rögzített iparági arányt idéz, kérdezzék meg, honnan való.

A £84 000 példáján ez alul £42 000, középen £84 000 és £252 000 között, a felső végén pedig £252 000 fölött van. A szórás maga a történet. Aki csak annyit hallott, hogy nagyjából annyiba kerül, mint a licenc, egy olyan sáv közepéhez horgonyzott le, amely a széleknél tízszeres eltérést mutat.

A négy változó, amely az arányt mozgatja

Csak négy dolog viszi át megbízhatóan a Salesforce projektet az egyik sávból a másikba, és minden felmérő beszélgetésnek mind a négyet tisztáznia kell, mielőtt bárki számot mondana.

Az első az integrált rendszerek száma. Mindegyik külön tervezés, külön hitelesítő adatok, külön hibaút és még egy dolog, ami elromlik, amikor a másik gyártó kiadást szállít. Az integrációk költsége nem összeadódó, hanem valamivel rosszabb annál, mert a hibamódok szorzódnak.

A második az adatok minősége a forrásban. Nem a mennyiség. A minőség. Lentebb részletesen szerepel, mert ez a program legkövetkezetesebben alábecsült sora.

A harmadik a folyamattestreszabás mértéke, vagyis az, hogy a céltervezés mennyire tér el attól, amit a termék a telepítés után alapból csinál.

A negyedik az, hogy a szervezet hajlandó-e a folyamatát a termékhez igazítani. Ez a költség és a siker legerősebb önálló előrejelzője, és szinte senki sem méri fel, mert ez emberekről szóló kérdés, amelyet egy technikai értékelés közben tesznek fel.

A változtatási hajlandóság felmérési kérdés

Az a szervezet, amely az értékesítési folyamatát a Salesforce opportunity modelljéhez igazítja, olcsó, frissíthető és jól támogatott rendszert kap. Az, amelyik ragaszkodik ahhoz, hogy a Salesforce a meglévő táblázatát másolja le, drága rendszert kap, amely minden kiadással hadakozik.

A felmérés során a nyelvhasználat az árulkodó jel. Amikor egy érintett azt mondja, hogy a rendszernek úgy kell működnie, ahogy mi dolgozunk, a testreszabási keret éppen megduplázódni készül. Amikor azt mondja, mutassák meg, hogyan kellene működnie, és magyarázzák el, miért, akkor éppen feleződni készül. Mindkét mondat ésszerű. Csak az egyik olcsó.

Ezt tisztességesen úgy lehet kezelni, hogy beárazzák. Tegyenek két számot az ajánlatba, egyet a szabványos modellre és egyet az egyedire, és hagyják, hogy a különbség érveljen. Aki látja, hogy egy fázisnévadási szokás £18 000 egyedi automatizmusba és tartós frissítési kockázatba kerül, rendszerint megváltoztatja a szokást. Aki azt a választ kapja, hogy meg tudjuk csinálni, nem változtat rajta.

A felmérés, és amit egy jó felmérés eredményez

A felmérés az a szakasz, amelyet a legtöbbször megvágnak egy üzlet megnyeréséért, és amelyet utólag a legtöbbször hibáztatnak. Az a felmérés, amely diasort eredményez, értékesítési gyakorlat volt. Az, amely négy terméket eredményez, mérnöki gyakorlat volt.

Az első egy folyamattérkép: azoknak a lépéseknek a tényleges sorrendje, amelyek során egy leadből bevétel lesz, a döntési pontokkal és az értük felelős emberekkel, a munka megfigyeléséből származtatva, nem pedig abból, hogy vezetőket kérnek meg a leírására.

A második egy adatmodell: objektumok, mezők, kapcsolatok, picklist értékek, és minden mezőhöz egy megnevezett személy, aki karban fogja tartani. A gazdátlan mezőkből lesznek azok a mezők, amelyeket senki sem tölt ki.

A harmadik egy integrációs leltár: minden rendszer, amely adatot küld a Salesforce felé vagy onnan fogad, iránnyal, mennyiséggel, gyakorisággal, a rekordokat összekötő azonosítóval, és azzal, mi történik, ha a kapcsolat elszáll.

A negyedik egy mérhető készültségi meghatározás. Nem az, hogy az értékesítés használja a Salesforce-t, hanem például az, hogy a negyedévben lezárt lehetőségek 90%-ának van zárási dátuma, összege és a tulajdonos által beállított fázisa, a heti pipeline megbeszélés pedig a Salesforce irányítópultjából megy, táblázat nélkül.

Versenyeztetésnél közvetlenül érvényes a szoftveres ajánlatkérésről szóló útmutatónk: kérdezzék meg minden ajánlattevőtől, mit eredményez a felmérése, és essenek ki azok, akik nem tudják megnevezni a termékeket.

Az adatmigráció az, ahol elfogy a naptár

A migrációt a fejlesztés százalékaként árazzák, és annak többszöröseként fogyasztják el, egyetlen félreértés miatt: a csapatok rekordszám alapján becsülnek, a migrációs ráfordítás viszont a forrás minőségével nő.

Kétmillió tiszta sor egyetlen jól karbantartott rendszerből, megbízható elsődleges kulccsal, egy hét gondos munka. Negyvenezer sor egy régi CRM, három regionális táblázat és egy könyvelőprogram között szétszórva, közös azonosító nélkül, a megjegyzésmezőben tizenegy évnyi szabad szöveggel, két hónap, és az élesítéskor még mindig hibás lesz. A második munkában a rekordoknak az ötvened része van, a ráfordítás pedig nyolcszoros.

Profilozzák a forrást, mielőtt bármit ígérnének

A profilozás annyit tesz, hogy megszámolnak dolgokat, mielőtt dátumot vállalnának. Minden forráson futtassák le, és futtassák le, mielőtt az ajánlat migrációs sorát aláírják.

Számolják meg a null értékeket mezőnként. Számolják meg a különböző értékeket minden olyan mezőben, amelyből picklistet akarnak, mert egy 340 különböző értéket tartalmazó országoszlop nem picklist, hanem tisztítási projekt. Számolják meg, hány rekordon osztozik egy lehetséges kulcs. Mérjék meg a formátumok következetességét a dátumoknál, a telefonszámoknál és az irányítószámoknál. Számolják meg azokat a rekordokat, amelyeknek nincs gazdájuk, nincs e-mail címük, és három éve nincs aktivitásuk, mert ezeket senki sem fogja megvédeni, amikor felvetik, hogy hagyják őket hátra.

A profilozás egy közepes méretű állományon két-öt napba kerül. Ez a program legolcsóbb kockázatcsökkentése, és a kihagyása az oka annak, hogy a migrációs becslések csak egy irányba tévednek.

A deduplikáció, és a szabályok, amelyeket a platform ad

A Salesforce natív duplikátumkezeléssel érkezik, és annak korlátai alakítják a tervezést. Objektumonként legfeljebb öt aktív duplicate rule és egy aktív matching rule lehet, ez objektumonként öt aktív matching rule-ra emelkedik, ha több duplicate rule-t használnak, és minden duplicate rule legfeljebb három matching rule-ra hivatkozhat.

Két viselkedés többet nyom a latban, mint a darabszámok. A match key-ek a 100 legvalószínűbb duplikátumra szűkítik az összehasonlítást, mielőtt az egyeztetési képlet lefutna, tehát egy olyan rekord, amelynek több mint 100 valódi közeli találata van, nem lesz teljesen kiértékelve. A szabályok ráadásul több elterjedt úton egyszerűen nem futnak le, köztük a Quick Create-nél és a Lead konvertálásánál engedélyezett Apex lead convert nélkül, és a duplikátumok pontosan így jelennek meg egy olyan orgban, amelyben be vannak kapcsolva a duplicate rule-ok.

A deduplikáció tehát migrációs tevékenység, amelyet a staging adatokon végeznek betöltés előtt, nem pedig futásidejű funkció, amelyet bekapcsolnak és elfelejtenek. A natív szabályok a második védelmi vonal.

Az external ID-k, és miért jobb az upsert az insertnél

Minden migrált objektumnak szüksége van external ID-ra: egy indexelt egyedi mezőre, amely a forrásrendszer elsődleges kulcsát tartalmazza. Ez a migrációs tervezés legnagyobb értékű döntése, és semmibe sem kerül.

Egy external ID birtokában használhatják az upsertet, amely ez alapján a mező alapján dönti el, hogy létrehoz vagy frissít egy rekordot. Ha az érték nem talál egyezést, rekord jön létre, ha egyszer talál, a rekord frissül, ha pedig többször, akkor hiba érkezik vissza duplikátum helyett. Ettől minden betöltés idempotens lesz, ami azt jelenti, hogy kétszer is lefuttathatják az adatok megduplázása nélkül, ami azt jelenti, hogy próbálhatnak.

Két részlet harap. Az external ID szerinti egyeztetés csak akkor hagyja figyelmen kívül a kis- és nagybetűket, ha a mezőn ott van a Unique jelző és a megfelelő beállítás, különben az ABC123 és az abc123 két külön rekord. Ha pedig a mező egyedi index nélküli external ID, akkor a betöltő fióknak View All Data jogosultság kell.

Az előzmények migrálása vagy annak migrálása, ami hasznos

Az alapértelmezett kérés az, hogy hozzanak át mindent. Ez szinte mindig hibás, és három külön módon drága.

Migrációs ráfordításba kerül, mert a legrégebbi adatok a legpiszkosabbak, és az értékükhöz képest aránytalanul sok tisztítási időt visznek el. Tárhelybe kerül, a tárhely pedig valódi sor: az Enterprise, a Professional és az Unlimited orgok 10 GB adattárhelyet és felhasználói licencenként további 20 MB-ot kapnak, tehát ötven Enterprise felhasználó összesen 11 GB, nem pedig felhasználónként 11 GB. És adaptációba kerül, mert egy halott rekordokkal teli rendszer arra tanítja a felhasználókat, hogy ne bízzanak a keresési találatokban.

A védhető álláspont az, hogy a nyitott és friss rekordokat teljes egészében migrálják, a lezárt rekordokat arra az időszakra migrálják, amelyről az üzlet ténylegesen jelent, a többit pedig valahol olvasható formában archiválják. Olyan személyes adatot megőrizni, amelyre nincs szükségük, inkább kötelezettség, mint vagyon, így a tárhelyérv és a megfelelőségi érv egyszer ugyanabba az irányba mutat.

Konfiguráció vagy kód

A Salesforce-ban minden követelmény teljesíthető deklaratívan, kóddal vagy a kettő keverékével, és ez a választás dönti el, mennyibe kerül a rendszer birtoklása a következő évtizedben. A különbséget akkor is érdemes tisztán tartani, ha soha nem nyitnak meg kódszerkesztőt.

Mi legyen deklaratív

A deklaratív azt jelenti, hogy konfigurációval épült: objektumok, mezők, oldalelrendezések, érvényesítési szabályok és a Flow, a Salesforce vizuális automatizálási eszköze. Adminisztrátor módosítja, túléli a platformfrissítéseket, mert a futtatókörnyezet a Salesforce-é, és látható mindenkinek, akinek megvan hozzá a jogosultsága.

A Salesforce saját döntési útmutatója a rekord által kiváltott automatizálásról használható küszöböt ad. Három dimenzió mentén méri az automatizálási sűrűséget: hány automatizmus indul el egyetlen adatváltozásra, mekkora a tranzakciónkénti rekordmennyiség, és milyen mélyre gyűrűznek a kapcsolódó objektumokat érintő frissítések. Az alacsony sűrűség, vagyis tizenötnél kevesebb automatizmus, 1 és 200 közötti rekordot tartalmazó kötegek és legfeljebb egy továbbgyűrűző írás, rekord által kiváltott Flow-ba való.

Ugyanez az útmutató ad egy szabályt, amely többet spórol minden másnál ezen a listán: objektumonként egyetlen belépési pontot használjanak. A Flow és az Apex triggerek keverése ugyanazon az objektumon az az út, amelyen a sorrendi hibák tartóssá válnak.

Mikor helyes az egyedi kód

A közepes sűrűség hibrid megoldásba való, ahol a Flow vezényel, a nehezét pedig meghívható Apex végzi, így a sorrend látható marad, a számítás viszont valami tesztelhetőben ül. A magas sűrűség egyértelműen Apex triggerekbe való, mert ezen a ponton a deklaratív eszközzel olyan rendszert építenek, amelyre nem tervezték.

A kód akkor is helyes, ha a logika valóban összetett, ha rendesen egységtesztelni kell, és ha ugyanazt a műveletet több belépési pontról hívják, tehát egyszer kellene léteznie. Ha ezt a munkát megrendelik ahelyett, hogy embert vennének fel rá, a szoftverfejlesztési szolgáltatásaink pontosan ezért a határért vannak, ahol a platform véget ér és az egyedi mérnöki munka kezdődik.

A szóhasználat változik, a régi szóhasználat pedig figyelmeztetés

A Salesforce kivezet eszközöket, és egy kivezetett eszközökre írt ajánlat elárulja, mikor készült valójában. A Salesforce 2025. december 31-én megszüntette a Workflow Rules és a Process Builder támogatását. A meglévő szabályok tovább futnak, de nincs ügyféltámogatás és nincs hibajavítás, az ajánlott út pedig a Flow Builderre való átállás a Migrate to Flow eszközzel.

Az egyes választások hosszú távú költsége

A deklaratív munkát olcsóbb megépíteni és olcsóbb megváltoztatni, a költsége pedig a felhígulás: száz dokumentálatlan flow-ból olyan rendszer lesz, amelyben senki sem tudja megjósolni, mit csinál egy rekord mentése.

A kódot drágább megépíteni, és nagy méretben sokkal olcsóbb átlátni, mert olvasható, verziózható és tesztelhető. A költsége az, hogy fejlesztők kellenek hozzá, és az a szervezet, amelynek nincs Salesforce fejlesztője és nincs támogatási szerződése, egy idő után nem tudja majd megváltoztatni a saját rendszerét.

A legdrágább kudarc egyik sem ezek közül. Az egy olyan, teljesen deklaratívan felépített rendszer, amelynek a partnere ezután távozik, egy dokumentáció és megnevezett gazda nélküli orgban. Minden működik, és semmit sem lehet biztonságosan megváltoztatni, ami ugyanaz a helyzet, mint a karbantartás nélküli egyedi szoftvernél, amelyet hosszan tárgyal a cikkünk arról, mennyibe kerül valójában a szoftverkarbantartás.

Az integráció, és miért változtatják meg a korlátok az architektúrát

Az integrációnak külön tárgyalása van a Salesforce integrációs korlátairól és valós költségeiről szóló cikkünkben. Ide az a pont tartozik, hogy a platformkorlátok architekturális bemenetek, nem pedig a kilencedik héten felfedezett üzemeltetési részletek.

Két korlát végzi a formálás nagy részét. Egy Enterprise Edition org teljes API kérési keretei 24 óránként 100 000 hívás, plusz a licencek száma szorozva azzal, amennyi hívást az adott licenctípus hoz, ami Salesforce licencenként 1 000, plusz a megvásárolt kiegészítők. A Salesforce saját számolt példája egy Enterprise org 15 Salesforce licenccel, amely 115 000 kérést kap. A keret az egész orgra vonatkozik, nem felhasználónként, az egyidejű bejövő kérések pedig, amelyek 20 másodpercig vagy tovább futnak, éles környezetben 25-ben vannak korlátozva.

A második az Apex governor korlátok csoportja, amelyeket tranzakciónként tartatnak be: 100 SOQL lekérdezés szinkron és 200 aszinkron módon, SOQL-lel lekért 50 000 rekord, 150 DML utasítás, DML-lel feldolgozott 10 000 rekord, 6 MB heap szinkron és 12 MB aszinkron módon, valamint 10 000 ezredmásodperc processzoridő szinkron módon a 60 000 aszinkronnal szemben.

Az a tervezés, amely ezeket figyelmen kívül hagyja, húsz rekordon átmegy a felhasználói átvételi teszten, és elbukik az első valódi éjszakai betöltésen. Ez nem hiba. Ez alapértelmezésből született architekturális döntés.

Környezetek, és mit pusztít el egy sandbox frissítés

A Salesforce négy sandbox típust ad eltérő tárhellyel és frissítési időközzel, és a rossz készlet kiválasztása olyan ütemezési hiba, amely későn derül ki.

A Developer sandbox 200 MB-ot tárol, és naponta egyszer frissíthető. A Developer Pro 1 GB-ot tárol, szintén naponta. A Partial Copy 5 GB-ot tárol, sablonnal meghatározott mintát másol az éles adatokból, és ötnaponta frissíthető. A Full az éles környezet mása, és 29 naponta frissíthető. Az Enterprise Edition 25 Developer sandboxot és egy Partial Copyt tartalmaz; a Full sandbox az Unlimited és a Performance csomaggal jár, vagy kiegészítőként vásárolható meg.

A Full sandboxok 29 napos időköze az a korlát, amelyre az emberek túl későn terveznek. Az egyetlen valósághű migrációs próbakörnyezetük havonta egyszer frissíthető, tehát egy olyan próba, amely problémát tár fel, egy hónapba kerül, mielőtt tisztán újra lehetne próbálni. Két Full sandbox próba kilenc hetes ablak, nem kettő.

A Developer és a Developer Pro sandbox csak metaadatot másol, tehát minden, amit egy fejlesztő tesztelésre betöltött, eltűnik egy frissítés után. A tesztadatnak verziókövetésben tartott, újrafuttatható szkriptnek kell lennie, különben a csapat frissítésenként egy napot veszít a kézi újraépítéssel.

Kiadáskezelés: change setek vagy pipeline

Éles orgban nem lehet Apexet fejleszteni, tehát minden változás máshol kezdődik, és át kell mozgatni. Az, hogy hogyan mozog, hosszú következményekkel járó döntés.

A change setek a beépített mechanizmus. Csak azt viszik, amit a Setupból meg lehet változtatni, rekordot soha, telepítési kapcsolatot igényelnek az ugyanahhoz az éles orghoz tartozó orgok között, és egy bejövő change set egészben települ, nem komponensenként. Kattintgatással állítják össze őket, tehát nem összehasonlíthatók, nem átnézhetők és nem ismételhetők, és ugyanaz a change set két ember összeállításában más lesz.

Ez működik egy kis orgnál egyetlen adminisztrátorral és havi kiadásokkal. Abban a pillanatban megszűnik működni, amikor ketten módosítják ugyanazt az orgot, mert nincs összefésülés és nincs előzmény, annak a nyilvántartása pedig, hogy mi ment ki, valakinek az emlékezetében él.

Az alternatíva a forrásvezérelt pipeline: metaadat a Gitben, változások diffként átnézve, telepítések ágból futtatva. Néhány napba kerül beállítani, és a kiadáskezelést emlékezetgyakorlatból ismételhető gyakorlattá teszi. Egynél több építő esetén kezeljék a fejlesztés részeként, ne későbbre halasztott javításként.

A 75%-os lefedettség szabálya nem minőségi mérce

Az Apex éles telepítéséhez az kell, hogy az egységtesztek az Apex kód legalább 75%-át lefedjék, és hogy ezek a tesztek lefussanak. A Salesforce kifejezetten kimondja, hogy a lefedettség jelzi a tesztek hatékonyságát, de nem garantálja, és hogy a teszteknek viselkedést kell ellenőrizniük.

Olvassák el, mit jelent ez üzletileg. A 75% kapu, a kapukat pedig kijátsszák. Az a tesztosztály, amelyet a szám elérésére írtak, nem pedig ellenőrzésre, átmegy, települ és nem fog meg semmit. Amikor egy partner munkáját nézik át, ne a lefedettségi százalékot kérdezzék. Kérjenek el három tesztmetódust, és számolják meg az ellenőrzéseket.

Egy Salesforce bevezetés az adaptációnál bukik el, nem az élesítésnél

A rendszer élesedik, a projekt lezárul, a számla ki van fizetve, és nyolc hónappal később az értékesítési igazgató még mindig táblázatból csinálja az előrejelzést. Semmi sem romlott el. Ez egy bukott Salesforce program leggyakoribb kimenetele, és minden technikai mérőszám számára láthatatlan.

A számtan kegyetlen, mert a licencköltség ettől függetlenül fut tovább. Ötven Enterprise felhasználó havi £140-ért évi £84 000, akár használják a rendszert, akár nem, tehát a 40%-os adaptációs arány nagyjából évi £50 000 tiszta pazarlás pusztán a licencen, még mielőtt a bevezetés költségét bármire elosztanák.

Az adaptáció ráadásul az egyetlen hibamód, amelyet a technikai csapat nem tud megjavítani. Egy partner pontosan azt építheti meg, amit előírtak, teljesíthet minden átvételi feltételt, és olyasmit hagyhat maga után, amelyet senki sem nyit meg. Ezért kell a felmérésben a készültségi meghatározásnak a használatról szólnia, és ezért nem szabad a projektet az élesítésnél lezártnak tekinteni.

Azok a gyakorlatok, amelyek mozgatják az adaptációt

Négy dolog mozdítja el megbízhatóan az adaptációt, és egyik sem oktatóvideó.

Szerepkör szerinti oktatás, külön tartva. Egy értékesítő és egy értékesítési vezető más okból a rendszer más részét használja, egy közös alkalom pedig mindkettőt rosszul tanítja meg. Minden szerepkört a saját munkafolyamatára oktassanak, és semmi másra.

Kis kötelező mezőkészlet. Válasszák ki azt a legkevesebb mezőt, amellyel a riportolás működik, tegyék ezeket kötelezővé, és hagyják a többit szabadon. Minden további kötelező mező ok arra, hogy félúton hagyják abba a rekord kitöltését, és az a rendszer, amely bünteti az adatbevitelt, kevesebbet is kap belőle.

Vezetői riportolás, amely az adatokon áll. Ez az, ami működik. Ha a heti pipeline megbeszélés Salesforce irányítópultból megy, táblázat nélkül, az adatot beírják, mert az alternatíva az, hogy hiányoznak a beszélgetésből. Ha a vezető saját táblázatot vezet, a CRM opcionális, és ezt mindenki tudja.

Megnevezett gazda, akinek a hetében van rá idő. Nem bizottság. Egy ember, aki birtokolja az orgot, nála vannak az adminisztrátori jogok, az adaptáción mérik, és órákat kap rá. Az ilyen nélküli orgok az első hónaptól romlani kezdenek.

A hibamódok és a korai figyelmeztető jeleik

Hat hibamód adja annak a Salesforce bevezetési kudarcnak a nagy részét, amelynek javítására felkérnek minket, és mindegyik jóval a kár előtt mutat jelet.

Egy elromlott folyamat lemásolása. A figyelmeztető jel egy olyan követelménydokumentum, amely a jelenlegi rendszert írja le a kívánt eredmény helyett, a régi rendszer mezőneveivel. Egy rossz folyamat automatizálása gyorsabbá és nehezebben változtathatóvá teszi.

Korlátlan testreszabás. A figyelmeztető jel egy olyan változáskérési napló, amelyen egyetlen elutasítás sincs. Az Enterprise Edition objektumonként 500 egyedi mezőt és 200 egyedi objektumot enged, épp elég mozgásteret ahhoz, hogy jóval a platformkorlát elérése előtt fenntarthatatlan dolgot építsenek.

Nincs egyetlen gazda. A figyelmeztető jel az, hogy arra a kérdésre, kié a Salesforce, a válasz tartalmazza az és szót.

Mindent migrálni. A figyelmeztető jel egy olyan migrációs terjedelem, amelyet rekordszám határoz meg, nem pedig megőrzési döntés.

Nincs tesztkörnyezeti fegyelem. A figyelmeztető jel az, ha valaki azt mondja, csinálják meg a változtatást élesben, hiszen csak egy picklist érték.

Az élesítés mérése a használat helyett. A figyelmeztető jel egy olyan projektterv, amelynek az utolsó mérföldköve dátum, nem pedig szám.

Ütemtervek kis, közepes és összetett bevezetésekhez

Az eltelt idő és a ráfordítás két különböző kérdés, a vevők pedig összemossák őket. Ezek a brit középpiaci munkából származó házon belüli sávjaink, nem közzétett számok.

Egy kis bevezetés, körülbelül 25 felhasználóig egyetlen felhőn, legfeljebb egy integrációval és egyetlen tiszta adatforrással, 6 és 10 hét között tart, 20 és 45 tanácsadói nap ráfordítással. Egy közepes, 25 és 150 felhasználó között egy vagy két felhőn, két-négy integrációval és valódi migrációval, 4 és 7 hónap között tart, 90 és 220 nap ráfordítással. Egy összetett program, 150 felhasználótól felfelé, több felhővel, öt vagy több integrációval és egynél több országgal, 9 és 18 hónap között tart, 400 naptól felfelé.

Ezeken a végösszegeken belül a felmérés a ráfordítás 10 és 15%-a, a konfiguráció és a fejlesztés 30 és 40%, az adatmigráció 20 és 30%, rossz forrásminőségnél meredeken emelkedve, az integráció 10 és 20%, a tesztelés, az oktatás és a hypercare pedig 15 és 20%. Az a sor, amely tágul, mindig a migráció.

Az eltelt idő olyan okokból haladja meg a csapatmérettel elosztott ráfordítást, amelyek nem a csapaton múlnak: a sandboxok frissítési időköze, az érintettek rendelkezésre állása az átvételi teszthez, és a várakozás arra a külső félre, akinek az API-ja kell. Hogy ezt a kockázatot ki viseli, a szerződés dönti el, ezért számít a fix ár és az elszámolásos munka kérdése CRM munkánál jobban, mint máshol.

Brit adatvédelem egy CRM programban

A CRM emberekről szóló adatbázis, tehát a UK GDPR lényegében mindenre vonatkozik benne, és minden bevezetésnél három kérdés merül fel.

Kell ehhez DPIA?

Az ICO útmutatója arról, hogy mikor kell DPIA, a 35. cikk (1) bekezdéséből induló általános szabályt rögzíti, vagyis hogy DPIA akkor kell, ha az adatkezelés valószínűleg magas kockázattal jár az emberek jogaira és szabadságaira, és felsorolja az ICO saját műveletlistáját a 35. cikk (4) bekezdése alapján.

Ebből kettő pontosan egy tipikus CRM migrációra esik. Az adategyeztetés, amelyet több forrásból szerzett személyes adatok összevonásaként, összehasonlításaként vagy egyeztetéseként határoznak meg, pontosan az, amit egy konszolidációs migráció csinál. A nagy léptékű profilalkotás lefedi a lead és account pontozást. Az ICO azt is megjegyzi, hogy a legtöbb esetben az európai szempontok közül kettő együttes megléte DPIA szükségességét jelzi, bár ez nem szigorú szabály. Vegyék figyelembe, hogy ez az útmutató jelenleg felülvizsgálat alatt áll a Data (Use and Access) Act által hozott változások miatt, ezért nézzék meg magát az útmutatót, ne egy összefoglalót.

Hol vannak valójában az adatok?

A Salesforce globális platform, és az, hogy az orgjuk melyik példányon fut, szerződéses kérdés, nem feltételezés. Az ICO rövid útmutatója a nemzetközi adattovábbításokról, amelyet utoljára 2026. január 15-én frissítettek, három lépéses tesztet ad: vonatkozik-e az adatkezelésre a UK GDPR, önök kezdeményezik-e a továbbítást egy Egyesült Királyságon kívüli szervezet felé, és önálló jogi személy-e a címzett. Három igen korlátozott adattovábbítássá teszi.

A korlátozott adattovábbításokhoz brit megfelelőségi rendelkezés, megfelelő garanciák, például az International Data Transfer Agreement, az Addendum vagy kötelező erejű vállalati szabályok, illetve valamilyen kivétel kell. Ahol garanciákra támaszkodnak, ott az ICO adattovábbítási kockázatértékelést vár el. Ez szerződéses átvizsgálás, nem mérnöki feladat, és a migráció előtt kell megtörténnie, nem utána.

A bevezetési partnerük adatfeldolgozó

Amikor egy partner beállítja az orgjukat, betölti az adataikat és hozzáférési adatokat tart nála, akkor az önök nevében kezel személyes adatokat. Az ICO útmutatója az adatkezelőkről és adatfeldolgozókról leírja, mi következik ebből, a gyakorlati következmények pedig szerződésesek.

Írásbeli megállapodás kell dokumentált utasításokról, titoktartásról, biztonságról, alvállalkozókról, auditjogokról, valamint az adatok törléséről vagy visszaadásáról a megbízás végén. Az utóbbi az a kikötés, amely a leggyakrabban hiányzik. Az a partner, amely tizenegy hónapja teljes másolatot tart az ügyféladatbázisukról egy Full sandboxban, és amelynek a szerződése semmit sem mond a törlésről, nyitott kockázat az önök oldalán, nem az övén.

Mit kérdezzenek egy lehetséges partnertől

Hat kérdés, és azok a válaszok, amelyeknek le kellene zárniuk a beszélgetést.

Kérdezzék meg, mit eredményez a felmérés. Ha a válasz ajánlat, nem pedig folyamattérkép, adatmodell, integrációs leltár és mérhető készültségi meghatározás, akkor értékesítenek, nem felmérnek.

Kérdezzék meg, hogyan és mikor profilozzák a forrásadatokat. Ha a profilozás a migrációs becslés elfogadása után történik, a becslés találgatás.

Kérdezzék meg, mi az alapértelmezett választásuk automatizálásra, és figyeljék, előkerül-e a sűrűség érve. Az a partner, aki mindig Flow-t vagy mindig Apexet mond, egyetlen eszközzel dolgozik. Aki 2026-ban Process Buildert ír elő, három éve nem olvasott kivezetési bejelentést.

Kérdezzék meg, hogyan jutnak a változások sandboxból élesbe. A change set egyetlen adminisztrátoros orgnál elfogadható, bármi nagyobbnál figyelmeztetés.

Kérdezzék meg, kié az org az élesítés után, és hány órát jelent ez hetente. Ha nem tudnak válaszolni, az adaptáció senkinek sem a gondja.

Kérdezzék meg, mi lesz az adataikkal a partner sandboxaiban a megbízás végén, és a választ szerződésbe kérjék, ne e-mailbe. Ugyanaz a fegyelem érvényes itt is, mint a technikai átvilágítási útmutatónkban: ellenőrizzék az állítást, ne fogadják el a biztosítékot.

Amikor a válasz nem a Salesforce

Ha körülbelül tíznél kevesebb felhasználójuk van, nincs integrációs igény, és a folyamat elfér egy ötfázisú pipeline-ban, akkor az Enterprise licenc és a bevezetése is nagyobb a problémánál. Egy olcsóbb CRM, vagy a Starter Suite £20-ért felhasználónként, megoldja a feladatot, és később elviselhető költséggel lecserélhető.

Ha a valódi igényük egyetlen olyan munkafolyamat, amelyet egyetlen termék sem támogat, minden más pedig már megoldott, akkor platformot vásárolnak egyetlen alkalmazás futtatásához. Ez rendszerint a célra épített rendszer esete, és az egyedi szoftverfejlesztési munkánk ebből a feltevésből indul. A saját fejlesztés és a vásárlás közötti döntés azon múlik, hogy a megkülönböztető folyamat az üzlet magja-e, vagy csak részlet körülötte.

Ha senki sem fogja birtokolni a rendszert, ne vegyék meg. Ezt a legnehezebb kimondani egy értékesítési folyamat közben, és ez a pazarlás legmegbízhatóbb előrejelzője. A gazdátlan CRM nem hangosan bukik el. Csendben azzá a táblázattá válik, amelyet le kellett volna váltania, felhasználónként havi £140-ért.

Ha pedig a cél inkább AI ügynökréteg, mint CRM, az egy működő bevezetés tetején ül, nem a helyén. A gazdaságtanát az a cikkünk tárgyalja, amely arról szól, mennyibe kerül valójában az Agentforce.

A munka sorrendje

A működő sorrend ez: profilozzák az adatokat, vigyék a felmérést négy termékig, egyezzenek meg a szabványos modellben és árazzanak be minden eltérést tőle, építsenek objektumonként egyetlen automatizálási belépési ponttal, próbálják el a migrációt kétszer egy Full sandboxban, oktassanak szerepkör szerint, és tartsák nyitva a projektet, amíg egy használati szám nem teljesül, ne pedig egy dátum.

A bukó sorrend ez: aláírás, konfigurálás, késői migráció, egyszeri oktatás, élesítés a határidőre, projektzárás.

A Mecanik ennek azokon a részein dolgozik, amelyek mérnöki munkák és nem licencadminisztráció: integrációtervezés valós platformkorlátokkal szemben, migrációs profilozás és eszközök, egyedi fejlesztés ott, ahol a konfiguráció elfogy, és az a frontend munka, amely a CRM adatokat az ügyfelek elé teszi. A szoftverfejlesztési szolgáltatásainkat és a webfejlesztő felvételét bemutató oldalaink leírják, hogyan dolgozunk együtt. Ha aláírás előtt második véleményt szeretnének egy partner becsléséről, felvehetnek egy fejlesztőt pusztán erre az átnézésre.

Gyakran ismételt kérdések

Mennyibe kerül egy Salesforce bevezetés az Egyesült Királyságban? A Salesforce az Egyesült Királyságban £140 felhasználónkénti havidíjjal, éves számlázással listázza a Sales Cloud Enterprise csomagot, így ötven felhasználó évi £84 000 pusztán licencben. A bevezetési szolgáltatásokra a házon belüli becslésünk az első év licenckiadásának 0,5 és 1 közötti szorzója egy majdnem érintetlen bevezetésnél, 1 és 3 közötti szorzója egy tipikus középpiaci projektnél, és 3 és 5 közötti szorzója egy örökölt adatokkal és erős testreszabással járó, több felhőt érintő programnál.

Mennyi ideig tart egy Salesforce bevezetés? A házon belüli sávjaink 6 és 10 hét, valamint 20 és 45 tanácsadói nap legfeljebb 25 felhasználóig egyetlen felhőn tiszta adatokkal, 4 és 7 hónap, valamint 90 és 220 nap 25 és 150 felhasználó között két-négy integrációval, és 9 és 18 hónap, valamint 400 naptól felfelé egy örökölt adatok migrálásával járó, több felhőt érintő programnál. Az adatmigráció az a szakasz, amely tágul, mert a ráfordítása a forrásadatok minőségével nő, nem a rekordszámmal.

Miért buknak el a Salesforce bevezetések? Szinte mindig az adaptációnál, nem az élesítésnél. Az a technikailag helyes rendszer, amelyet senki sem használ, teljes veszteség futó licencszámlával. A gyakori okok: egy elromlott folyamat lemásolása, korlátlan testreszabás, megnevezett egyetlen gazda hiánya, minden történeti adat migrálása, a tesztkörnyezeti fegyelem hiánya, és az élesítés mérése a használat helyett.

Konfigurációval vagy egyedi kóddal érdemes megépíteni a Salesforce-t? A Salesforce saját döntési útmutatója az automatizálási sűrűséggel adja meg a küszöböt. Objektumonként tizenötnél kevesebb automatizmus, 1 és 200 közötti rekordot tartalmazó kötegek és legfeljebb egy továbbgyűrűző írás rekord által kiváltott Flow-ba való. A közepes sűrűséghez a meghívható Apexet vezénylő Flow illik. A magas sűrűséghez az Apex triggerek. Objektumonként egyetlen belépési pontot használjanak ahelyett, hogy Flow-t és Apex triggert kevernének ugyanazon.

Kell DPIA egy Salesforce bevezetéshez? Gyakran igen. Az ICO az adategyeztetést, vagyis több forrásból származó személyes adatok összevonását vagy összehasonlítását, és a nagy léptékű profilalkotást is azok között a műveletek között sorolja fel, amelyek DPIA szükségességét jelzik, egy lead pontozással járó konszolidációs migráció pedig mindkettőt csinálja. Az útmutató jelenleg felülvizsgálat alatt áll a Data (Use and Access) Act nyomán, ezért az ICO aktuális álláspontját nézzék meg, ne egy összefoglalót.