Triển Khai Salesforce: Chi Phí, Tiến Độ Và Thất Bại

Dự án Salesforce được duyệt như một dòng giấy phép nhưng được giao như một chương trình. Dòng giấy phép công khai, tính theo người dùng mỗi tháng, dễ bảo vệ trước hội đồng. Mọi thứ biến giấy phép thành hệ thống có người dùng thật đều nằm ngoài dòng ấy, và chính phần đó quyết định con số trong kế hoạch kinh doanh có sống qua quý đầu không.

Salesforce công bố giá tại Anh bằng bảng. Sales Cloud Enterprise là £140 mỗi người dùng mỗi tháng khi trả theo năm còn Unlimited là £280. 50 người dùng Enterprise là £84.000 một năm, trước khi có ai cấu hình một trường nào. Ước tính nội bộ của chúng tôi cho dịch vụ đưa tổ chức đó lên sản xuất là 1 đến 3 lần chi phí giấy phép năm đầu, và vị trí trong khoảng đó không ngẫu nhiên. Bốn thứ đẩy nó, và chỉ một thứ mang tính kỹ thuật.

Từ quan trọng nhất ở phần sau là mức độ sử dụng, vì hệ thống đúng về kỹ thuật mà không ai dùng không phải thành công một nửa. Đó là mất trắng, kèm hóa đơn bảo trì.

Một dự án triển khai Salesforce tốn bao nhiêu? Giấy phép thường là nửa nhỏ hơn. Salesforce niêm yết Sales Cloud Enterprise tại Anh ở £140 mỗi người dùng mỗi tháng, nên 50 người dùng là £84.000 một năm, và ước tính nội bộ của chúng tôi cho dịch vụ triển khai bên trên là 1 đến 3 lần chi phí giấy phép năm đầu. Hệ số phụ thuộc số hệ thống cần nối, tình trạng dữ liệu nguồn, mức độ tùy biến quy trình, và việc tổ chức có chịu đổi quy trình cho hợp sản phẩm không.

Một dự án triển khai Salesforce thực sự gồm những gì

Một chương trình Salesforce có sáu dòng chi phí và chỉ một dòng xuất hiện trên trang báo giá.

Dòng thứ nhất là giấy phép, theo người dùng theo tháng, công khai. Thứ hai là dịch vụ triển khai: các chuyên gia tư vấn và lập trình viên cấu hình tổ chức, xây phần mà cấu hình không làm được, và điều hành dự án. Thứ ba là di chuyển dữ liệu, được ước lượng như một đầu việc bên trong triển khai nhưng cư xử như một dự án riêng. Thứ tư là tích hợp, nối Salesforce với những hệ thống đang giữ dữ liệu của bạn. Thứ năm là đào tạo và quản trị thay đổi. Thứ sáu là quản trị hệ thống lâu dài, thứ không bao giờ xuất hiện trong kế hoạch kinh doanh vì nó bắt đầu sau khi mọi hóa đơn khác đã trả xong.

Một kế hoạch kinh doanh chỉ nêu giấy phép không sai một chút. Nó thường sai từ hai đến bốn lần, và khoảng cách ấy nằm gần như trọn ở dòng thứ ba, thứ năm và thứ sáu.

Giấy phép là con số nhỏ

Giá Sales Cloud tại Anh của Salesforce là công khai và niêm yết bằng bảng.

Starter Suite là £20 mỗi người dùng mỗi tháng. Pro Suite là £80 khi trả theo năm. Enterprise, bản mà phần lớn bên mua tầm trung tại Anh dừng lại, là £140, vì đó là bậc đầu tiên có web API. Unlimited là £280 và kèm một Full sandbox cùng Premier Success Plan. Agentforce 1 Sales ở mức £440. Mua rời, Premier Success Plan có giá bằng 30% phí giấy phép thuần.

Hai điều theo sau. Bước nhảy từ Pro Suite lên Enterprise là £60 mỗi người dùng mỗi tháng, với 50 người là £36.000 một năm, và nó thường bị ép bởi một yêu cầu tích hợp chứ không phải tính năng nào đội bán hàng xin. Và gói hỗ trợ là một tỷ lệ phần trăm, nên nó tăng theo hóa đơn giấy phép chứ không theo lượng hỗ trợ bạn thật sự dùng.

Tỷ lệ dịch vụ trên giấy phép, và thứ làm nó dịch chuyển

Con số hữu ích để lập kế hoạch không phải đơn giá ngày công, mà là tỷ lệ giữa dịch vụ năm đầu và chi phí giấy phép năm đầu, vì tỷ lệ đó đủ ổn định để tranh luận.

Các dải nội bộ của chúng tôi, rút từ công việc tầm trung tại Anh, như sau. Một triển khai gần như nguyên bản trên một cloud, dữ liệu sạch, không tích hợp, rơi vào khoảng 0,5 đến 1 lần chi phí giấy phép năm đầu. Một triển khai điển hình với hai hoặc ba tích hợp cùng lượng đối tượng tùy chỉnh và tự động hóa vừa phải rơi vào 1 đến 3 lần. Một chương trình đa cloud với dữ liệu cũ, từ năm tích hợp trở lên và tùy biến quy trình nặng chạy ở 3 đến 5 lần, đôi khi hơn. Đây là ước tính của chúng tôi, không phải số liệu công bố, và một đối tác nêu tỷ lệ cố định của ngành thì nên bị hỏi nó lấy từ đâu.

Áp vào ví dụ £84.000, đáy là £42.000, giữa là £84.000 đến £252.000, và đỉnh là từ £252.000 trở lên. Chính độ rộng ấy mới là toàn bộ câu chuyện. Người mua chỉ nghe rằng nó xấp xỉ tiền giấy phép đang neo vào giữa một khoảng mà hai đầu chênh nhau mười lần.

Bốn biến số làm dịch chuyển tỷ lệ

Chỉ bốn thứ đẩy được một dự án Salesforce từ dải này sang dải kế, và mọi cuộc bàn phạm vi nên chốt cả bốn trước khi có ai đưa ra con số.

Thứ nhất là số hệ thống cần nối. Mỗi hệ thống là một thiết kế riêng, một bộ thông tin xác thực riêng, một đường lỗi riêng, và một thứ riêng sẽ hỏng khi nhà cung cấp kia phát hành bản mới. Chi phí tích hợp không cộng dồn mà tệ hơn cộng dồn một chút, vì các kiểu hỏng nhân lên với nhau.

Thứ hai là chất lượng dữ liệu ở nguồn. Không phải khối lượng. Chất lượng. Phần dưới bàn kỹ, vì đây là dòng bị đánh giá thấp một cách đều đặn nhất.

Thứ ba là mức độ tùy biến quy trình, tức thiết kế đích lệch bao xa khỏi thứ sản phẩm làm được ngay khi cài.

Thứ tư là tổ chức có chịu đổi quy trình cho hợp sản phẩm không. Đó là biến dự báo mạnh nhất cho cả chi phí lẫn thành công, và gần như không ai đưa nó vào phạm vi, vì đây là câu hỏi về con người lại được đặt trong một buổi đánh giá kỹ thuật.

Sẵn lòng thay đổi là một câu hỏi về phạm vi

Tổ chức chịu chỉnh quy trình bán hàng theo mô hình cơ hội của Salesforce nhận được hệ thống rẻ, nâng cấp được, hỗ trợ tốt. Tổ chức đòi Salesforce tái tạo bảng tính hiện có nhận được hệ thống đắt và đánh nhau với từng bản phát hành.

Dấu hiệu trong giai đoạn khảo sát nằm ở cách nói. Khi một bên liên quan bảo hệ thống phải chạy theo cách chúng tôi đang làm, ngân sách tùy biến sắp gấp đôi. Khi họ bảo cho tôi xem nó vốn phải chạy thế nào và giải thích vì sao, ngân sách sắp giảm một nửa. Cả hai câu đều hợp lý. Chỉ một câu là rẻ.

Cách xử lý trung thực là gắn giá cho nó. Đặt hai con số vào đề xuất, một cho mô hình chuẩn và một cho bản đặt riêng, rồi để phần chênh lệch tự lập luận. Người mua thấy rằng một quy ước đặt tên giai đoạn tốn £18.000 tự động hóa tùy chỉnh cộng rủi ro nâng cấp vĩnh viễn thường sẽ đổi quy ước. Người mua chỉ nghe câu chúng tôi làm được thì không.

Khảo sát, và một buổi khảo sát tốt tạo ra gì

Khảo sát là giai đoạn hay bị cắt nhất để thắng thầu và hay bị đổ lỗi nhất về sau. Một buổi khảo sát đẻ ra bộ slide là một hoạt động bán hàng. Một buổi đẻ ra bốn sản phẩm đầu ra là một hoạt động kỹ thuật.

Thứ nhất là bản đồ quy trình: chuỗi bước thật mà một lead đi qua để thành doanh thu, kèm các điểm ra quyết định và người sở hữu chúng, vẽ từ việc quan sát công việc chứ không từ lời kể của quản lý.

Thứ hai là mô hình dữ liệu: đối tượng, trường, quan hệ, giá trị danh sách chọn, và với mỗi trường là tên một người sẽ duy trì nó. Trường không có chủ sẽ thành trường không ai điền.

Thứ ba là danh mục tích hợp: mọi hệ thống gửi dữ liệu vào Salesforce hoặc nhận từ đó, kèm chiều, khối lượng, tần suất, định danh dùng để nối bản ghi, và chuyện gì xảy ra khi kết nối hỏng.

Thứ tư là một định nghĩa hoàn thành đo được. Không phải đội bán hàng đang dùng Salesforce, mà kiểu như 90% cơ hội chốt trong quý có ngày chốt, giá trị và giai đoạn do người sở hữu đặt, và cuộc họp pipeline hằng tuần chạy từ dashboard Salesforce, không có bảng tính trong phòng.

Trong một cuộc thầu, hướng dẫn RFP phần mềm áp dụng trực tiếp: hỏi từng bên dự thầu khảo sát tạo ra gì và loại những bên không gọi tên được các sản phẩm đầu ra.

Tiến độ biến mất ở khâu di chuyển dữ liệu

Di chuyển được báo giá bằng một phần trăm của phần xây dựng và bị tiêu bằng một bội số của nó, do một hiểu lầm: các đội ước lượng theo số bản ghi, còn công sức di chuyển tỷ lệ với chất lượng nguồn.

2 triệu dòng sạch từ một hệ thống được bảo trì tốt, có khóa chính đáng tin, là một tuần làm việc cẩn thận. 40.000 dòng nằm rải trên một CRM cũ, ba bảng tính vùng và một phần mềm kế toán, không định danh chung, cộng mười một năm chữ tự do trong trường ghi chú, là hai tháng và tới ngày lên sản xuất vẫn còn sai. Việc thứ hai có một phần năm mươi số bản ghi và tám lần công sức.

Hãy khảo sát nguồn trước khi hứa bất cứ điều gì

Khảo sát nguồn là đếm mọi thứ trước khi bạn đồng ý một ngày hẹn. Làm với mọi nguồn, và làm trước khi dòng di chuyển trong đề xuất được ký.

Đếm giá trị rỗng theo từng trường. Đếm số giá trị phân biệt ở mọi trường bạn định biến thành danh sách chọn, vì một cột quốc gia có 340 giá trị phân biệt không phải danh sách chọn mà là một dự án làm sạch. Đếm xem bao nhiêu bản ghi dùng chung một khóa ứng viên. Đo mức nhất quán định dạng của ngày, số điện thoại và mã bưu chính. Đếm các bản ghi không có người sở hữu, không có email và ba năm không hoạt động, vì sẽ không ai bênh chúng khi bạn đề nghị bỏ lại.

Trên một khối dữ liệu cỡ vừa, khảo sát nguồn tốn hai đến năm ngày. Đó là cách giảm rủi ro rẻ nhất trong chương trình, và bỏ qua nó là lý do các ước lượng di chuyển chỉ sai theo một chiều.

Khử trùng lặp, và những luật nền tảng cho bạn

Salesforce có quản lý trùng lặp gốc, và các hạn mức của nó định hình thiết kế. Bạn có thể đặt tối đa năm quy tắc trùng lặp đang bật cho mỗi đối tượng và một quy tắc so khớp đang bật, tăng lên năm quy tắc so khớp cho mỗi đối tượng khi bạn dùng nhiều quy tắc trùng lặp, và mỗi quy tắc trùng lặp tham chiếu được tối đa ba quy tắc so khớp.

Hai hành vi quan trọng hơn các con số. Khóa so khớp thu hẹp phạm vi so sánh xuống 100 bản ghi trùng khả dĩ nhất trước khi áp công thức so khớp, nên một bản ghi có hơn 100 trùng gần thật sự sẽ không được xét hết. Và các quy tắc đơn giản là không chạy trên vài lối đi phổ biến, gồm tạo nhanh và chuyển đổi Lead khi chưa bật Apex lead convert, và đó chính là cách bản ghi trùng xuất hiện trong một tổ chức đã bật quy tắc trùng lặp.

Vậy nên khử trùng lặp là một hoạt động di chuyển, làm trên dữ liệu tạm trước khi nạp, không phải một tính năng lúc chạy bạn bật rồi quên. Quy tắc gốc là tuyến phòng thủ thứ hai.

external ID, và vì sao upsert hơn insert

Mọi đối tượng được chuyển sang đều cần một external ID: một trường tùy chỉnh có chỉ mục, giữ khóa chính từ hệ thống nguồn. Đây là quyết định đơn lẻ giá trị nhất trong thiết kế di chuyển và nó không tốn gì cả.

Có external ID, bạn dùng được upsert, lệnh dựa vào trường đó để quyết định tạo hay cập nhật một bản ghi. Nếu giá trị không khớp, bản ghi được tạo; khớp một lần thì bản ghi được cập nhật; khớp nhiều hơn một lần thì trả về lỗi thay vì một bản trùng. Điều đó khiến mọi lần nạp trở nên bất biến, nghĩa là bạn chạy hai lần mà dữ liệu không nhân đôi, nghĩa là bạn diễn tập được.

Hai chi tiết cắn người. So khớp theo external ID chỉ bỏ qua hoa thường khi trường có thuộc tính duy nhất và tùy chọn bỏ qua hoa thường được bật, ngoài ra ABC123 và abc123 là hai bản ghi khác nhau. Và nếu trường là external ID không có chỉ mục duy nhất, tài khoản chạy nạp cần quyền xem toàn bộ dữ liệu.

Chuyển lịch sử hay chuyển thứ có ích

Yêu cầu mặc định là mang hết sang. Nó gần như luôn sai, và đắt theo ba cách tách biệt.

Nó tốn công di chuyển, vì dữ liệu cũ nhất bẩn nhất và ngốn thời gian làm sạch không tương xứng với giá trị. Nó tốn dung lượng, và dung lượng là một dòng chi phí thật: tổ chức Enterprise, Professional và Unlimited được cấp 10 GB dung lượng dữ liệu cộng 20 MB cho mỗi giấy phép người dùng, nên 50 người dùng Enterprise là 11 GB tổng cộng, không phải 11 GB mỗi người. Và nó tốn mức độ sử dụng, vì một hệ thống đầy bản ghi chết dạy người dùng đừng tin kết quả tìm kiếm.

Lập trường bảo vệ được là chuyển trọn các bản ghi đang mở và gần đây, chuyển bản ghi đã đóng cho đúng giai đoạn doanh nghiệp thật sự báo cáo, và lưu trữ phần còn lại ở đâu đó đọc được. Giữ dữ liệu cá nhân bạn không dùng là nợ chứ không phải tài sản, nên lần này lý lẽ dung lượng và lý lẽ tuân thủ chỉ về cùng một hướng.

Cấu hình hay mã nguồn

Mọi yêu cầu trong Salesforce đều có thể đáp ứng bằng khai báo, bằng mã, hoặc bằng hỗn hợp, và lựa chọn đó quyết định chi phí sở hữu hệ thống trong mười năm tới. Ranh giới này đáng nắm rõ ngay cả khi bạn không bao giờ mở trình soạn mã.

Cái gì nên khai báo

Khai báo nghĩa là dựng bằng cấu hình: đối tượng, trường, bố cục trang, quy tắc kiểm tra và Flow, trình dựng tự động hóa trực quan của Salesforce. Quản trị viên đổi được nó, nó sống sót qua nâng cấp nền tảng vì Salesforce sở hữu môi trường chạy, và ai có quyền phù hợp đều nhìn thấy nó.

Hướng dẫn quyết định về tự động hóa kích hoạt theo bản ghi của chính Salesforce cho một ngưỡng dùng được. Nó đo mật độ tự động hóa theo ba chiều: số tự động hóa cùng chạy khi một dữ liệu đổi, lượng bản ghi mỗi giao dịch, và mức lan của các cập nhật xuống những đối tượng liên quan. Mật độ thấp, tức dưới mười lăm tự động hóa, lô 1 đến 200 bản ghi và nhiều nhất một lượt ghi phía sau, thì nên dùng Flow kích hoạt theo bản ghi.

Cũng hướng dẫn ấy cho một quy tắc tiết kiệm tiền hơn mọi quy tắc khác ở đây: mỗi đối tượng chỉ một điểm vào. Trộn Flow và Apex trigger trên cùng một đối tượng là cách biến lỗi thứ tự thành lỗi vĩnh viễn.

Khi nào mã tùy chỉnh là đúng

Mật độ trung bình thuộc về mô hình lai, Flow điều phối còn invocable Apex gánh phần nặng, nhờ vậy trình tự vẫn nhìn thấy được trong khi phần tính toán nằm ở chỗ kiểm thử được. Mật độ cao thuộc hẳn về Apex trigger, vì tới mức đó thì công cụ khai báo đang bị dùng để dựng một hệ thống nó không được thiết kế để dựng.

Mã cũng đúng khi logic thật sự phức tạp, khi cần kiểm thử đơn vị tử tế, và khi cùng một thao tác được gọi từ nhiều điểm vào nên chỉ được tồn tại một bản. Nếu bạn định đặt hàng phần việc đó thay vì tự tuyển người, dịch vụ phát triển phần mềm của chúng tôi tồn tại đúng cho ranh giới này, nơi nền tảng dừng lại và kỹ thuật đặt riêng bắt đầu.

Thuật ngữ thay đổi, và thuật ngữ cũ là một dấu hiệu

Salesforce khai tử công cụ, và một đề xuất viết theo công cụ đã khai tử sẽ nói cho bạn biết nó thật sự được viết khi nào. Salesforce đã dừng hỗ trợ Workflow Rules và Process Builder vào ngày 31 tháng 12 năm 2025. Quy tắc cũ vẫn chạy, nhưng không có hỗ trợ khách hàng và không có sửa lỗi, còn lối đi được khuyến nghị là chuyển sang Flow Builder bằng công cụ Migrate to Flow.

Chi phí dài hạn của từng lựa chọn

Phần khai báo rẻ hơn để dựng và rẻ hơn để đổi, và cái giá của nó là sự loãng: một trăm flow không tài liệu sẽ thành một hệ thống không ai đoán nổi việc lưu một bản ghi sẽ gây ra gì.

Mã đắt hơn để dựng và rẻ hơn nhiều để lần ra ở quy mô lớn, vì nó đọc được, quản lý phiên bản được, kiểm thử được. Cái giá của nó là cần lập trình viên, và một tổ chức không có lập trình viên Salesforce lẫn hợp đồng bảo trì rốt cuộc sẽ không đổi nổi hệ thống của chính mình.

Thất bại đắt nhất không phải hai thứ trên. Đó là một hệ thống dựng hoàn toàn bằng khai báo bởi một đối tác rồi rời đi, trong một tổ chức không tài liệu và không có người sở hữu được nêu tên. Mọi thứ chạy và không thứ gì đổi được an toàn, đúng vị thế của phần mềm đặt riêng bị bỏ mặc, điều chúng tôi viết kỹ trong bài bảo trì phần mềm thực sự tốn bao nhiêu.

Tích hợp, và vì sao hạn mức đổi kiến trúc

Tích hợp có bài riêng của nó, giới hạn và chi phí thật của tích hợp Salesforce. Điểm thuộc về đây là: hạn mức nền tảng là đầu vào kiến trúc, không phải chi tiết vận hành phát hiện ở tuần thứ chín.

Hai hạn mức làm phần lớn việc định hình. Tổng hạn mức yêu cầu API của một tổ chức Enterprise Edition là 100.000 lệnh gọi mỗi 24 giờ, cộng số giấy phép nhân với số lệnh gọi mà mỗi loại giấy phép mang theo, tức 1.000 với giấy phép Salesforce, cộng phần mua thêm. Ví dụ tính toán của chính Salesforce là một tổ chức Enterprise có 15 giấy phép Salesforce nhận 115.000 yêu cầu. Hạn mức thuộc về cả tổ chức chứ không theo người dùng, và các yêu cầu vào đồng thời chạy từ 20 giây trở lên bị chặn ở 25 trên môi trường sản xuất.

Thứ hai là giới hạn governor của Apex, áp theo từng giao dịch: 100 truy vấn SOQL đồng bộ và 200 bất đồng bộ, 50.000 bản ghi lấy về bằng SOQL, 150 câu lệnh DML, 10.000 bản ghi xử lý bằng DML, 6 MB heap đồng bộ và 12 MB bất đồng bộ, và 10.000 mili giây CPU đồng bộ so với 60.000 bất đồng bộ.

Một thiết kế bỏ qua các con số này sẽ qua kiểm thử chấp nhận trên hai mươi bản ghi rồi gục ở lần nạp đêm thật đầu tiên. Đó không phải lỗi. Đó là một quyết định kiến trúc đưa ra theo mặc định.

Môi trường, và một lần làm mới sandbox phá hủy cái gì

Salesforce cho bạn bốn loại sandbox khác nhau về dung lượng và chu kỳ làm mới, và chọn sai bộ là một lỗi lập lịch lộ ra muộn.

Developer sandbox chứa 200 MB và làm mới mỗi ngày một lần. Developer Pro chứa 1 GB, cũng làm mới hằng ngày. Partial Copy chứa 5 GB, chép một mẫu dữ liệu sản xuất theo mẫu định nghĩa, và làm mới mỗi năm ngày. Full là bản sao của sản xuất và làm mới mỗi 29 ngày. Enterprise Edition gồm 25 Developer sandbox và một Partial Copy; Full sandbox đi kèm Unlimited và Performance hoặc mua thêm.

Chu kỳ 29 ngày của Full sandbox là ràng buộc người ta tính tới quá muộn. Môi trường diễn tập di chuyển thực tế duy nhất chỉ làm mới mỗi tháng một lần, nên một buổi diễn tập lộ ra vấn đề tốn một tháng trước khi diễn tập sạch lại được. Hai buổi diễn tập trên Full sandbox là cửa sổ chín tuần, không phải hai tuần.

Developer và Developer Pro chỉ chép metadata, nên mọi thứ lập trình viên nạp vào để thử đều mất sau khi làm mới. Dữ liệu kiểm thử phải là một script chạy lại được, giữ trong quản lý phiên bản, nếu không cả đội mất một ngày mỗi lần làm mới để dựng lại bằng tay.

Quản lý phát hành: change sets hay một pipeline

Bạn không phát triển Apex trong tổ chức sản xuất, nên mọi thay đổi bắt đầu ở nơi khác và phải được chuyển sang. Chuyển bằng cách nào là một quyết định có đuôi dài.

Change sets là cơ chế có sẵn. Chúng chỉ mang thứ bạn đổi được qua màn hình Setup, không bao giờ mang bản ghi, chúng đòi một kết nối triển khai giữa các tổ chức cùng thuộc một tổ chức sản xuất, và một change set đến được triển khai trọn gói chứ không theo từng thành phần. Chúng được ráp bằng cách bấm chuột, nên không so khác biệt được, không rà soát được, không lặp lại được, và cùng một change set do hai người ráp sẽ khác nhau.

Cách đó ổn với một tổ chức nhỏ có một quản trị viên và phát hành hằng tháng. Nó hết ổn ngay khi hai người cùng đổi một tổ chức, vì không có gộp và không có lịch sử, còn hồ sơ về thứ đã lên sống trong trí nhớ của ai đó.

Lựa chọn thay thế là một pipeline lấy mã nguồn làm gốc: metadata trong Git, thay đổi rà soát dưới dạng khác biệt, triển khai chạy từ một nhánh. Nó tốn vài ngày để dựng và biến quản lý phát hành từ bài tập trí nhớ thành việc lặp lại được. Khi có hơn một người dựng, hãy coi nó là một phần của việc xây chứ không phải cải tiến để sau.

Quy tắc 75% độ phủ không phải một chuẩn chất lượng

Triển khai Apex lên sản xuất đòi hỏi kiểm thử đơn vị phủ ít nhất 75% mã Apex của bạn và các kiểm thử đó phải qua. Salesforce nói rõ rằng độ phủ chỉ báo hiệu hiệu quả kiểm thử chứ không bảo đảm, và rằng kiểm thử phải khẳng định hành vi.

Hãy đọc ý nghĩa thương mại của điều đó. 75% là một cửa ải, và cửa ải thì bị lách. Các lớp kiểm thử viết để chạm con số chứ không để khẳng định điều gì vẫn sẽ qua, vẫn được triển khai, và bắt được số không. Khi rà soát việc của một đối tác, đừng hỏi độ phủ là bao nhiêu. Hãy xin xem ba phương thức kiểm thử rồi đếm số khẳng định.

Một dự án Salesforce hỏng ở mức độ sử dụng, không phải ở ngày lên sản xuất

Hệ thống lên sản xuất, dự án đóng, hóa đơn được trả, và tám tháng sau giám đốc bán hàng vẫn chạy dự báo từ một bảng tính. Không có gì hỏng cả. Đó là kết cục phổ biến nhất của một chương trình Salesforce thất bại và nó vô hình với mọi thước đo kỹ thuật.

Bài toán tiền tàn nhẫn vì chi phí giấy phép cứ tiếp tục bất kể thế nào. 50 người dùng Enterprise ở £140 mỗi tháng là £84.000 một năm dù hệ thống có được dùng hay không, nên tỷ lệ sử dụng 40% là khoảng £50.000 lãng phí thuần mỗi năm chỉ riêng ở giấy phép, trước khi phân bổ chi phí triển khai vào bất cứ đâu.

Mức độ sử dụng cũng là kiểu hỏng duy nhất đội kỹ thuật không sửa được. Một đối tác có thể dựng đúng y đặc tả, đạt mọi tiêu chí nghiệm thu, rồi để lại một thứ không ai mở. Vì vậy định nghĩa hoàn thành trong khảo sát phải nói về việc sử dụng, và vì vậy không nên coi dự án là đã đóng ở ngày lên sản xuất.

Những cách làm thật sự nâng mức độ sử dụng

Bốn thứ nâng được mức độ sử dụng một cách đáng tin, và không thứ nào là video đào tạo.

Đào tạo theo vai trò, tổ chức riêng. Nhân viên bán hàng và quản lý bán hàng dùng những phần khác nhau của hệ thống vì lý do khác nhau, một buổi gộp dạy không tốt cho cả hai. Hãy dạy mỗi vai trò đúng luồng việc của họ và không gì khác.

Một tập trường bắt buộc nhỏ. Chọn số trường ít nhất đủ để báo cáo chạy, bắt buộc đúng chúng, còn lại để tùy chọn. Mỗi trường bắt buộc thêm là thêm một lý do bỏ dở bản ghi giữa chừng, và hệ thống trừng phạt việc nhập liệu sẽ nhận được ít dữ liệu hơn.

Báo cáo của quản lý phụ thuộc vào chính dữ liệu đó. Đây mới là thứ có tác dụng. Nếu cuộc họp pipeline hằng tuần chạy từ dashboard Salesforce và trong phòng không có bảng tính, dữ liệu sẽ được nhập, vì lựa chọn còn lại là vắng mặt khỏi cuộc trò chuyện. Nếu quản lý giữ một bảng tính riêng thì CRM là tùy chọn, và ai cũng biết điều đó.

Một người sở hữu có tên và có giờ trong tuần. Không phải một hội đồng. Một người sở hữu tổ chức, giữ quyền quản trị, được đánh giá theo mức độ sử dụng và được cấp giờ cho việc đó. Tổ chức thiếu điều này mục ruỗng ngay từ tháng đầu.

Các kiểu thất bại và dấu hiệu sớm của chúng

Sáu kiểu thất bại giải thích phần lớn những ca Salesforce hỏng mà chúng tôi được nhờ sửa, và mỗi kiểu đều lộ dấu hiệu rất lâu trước khi thiệt hại lộ ra.

Sao chép một quy trình hỏng. Dấu hiệu là một tài liệu yêu cầu mô tả hệ thống hiện tại thay vì kết quả mong muốn, bằng chính tên trường của hệ thống cũ. Tự động hóa một quy trình tồi chỉ làm nó nhanh hơn và khó đổi hơn.

Tùy biến không giới hạn. Dấu hiệu là một sổ yêu cầu thay đổi không có lấy một lần từ chối. Enterprise Edition cho phép 500 trường tùy chỉnh mỗi đối tượng và 200 đối tượng tùy chỉnh, đủ dư địa để dựng thứ không ai bảo trì nổi từ rất lâu trước khi chạm hạn mức nền tảng.

Không có người sở hữu duy nhất. Dấu hiệu là câu trả lời cho ai sở hữu Salesforce có chứa chữ và.

Chuyển hết mọi thứ. Dấu hiệu là phạm vi di chuyển được định nghĩa theo số bản ghi thay vì theo một quyết định lưu trữ.

Không có kỷ luật môi trường kiểm thử. Dấu hiệu là ai đó nói cứ sửa thẳng trên sản xuất, chỉ là một giá trị danh sách chọn thôi.

Đo ngày lên sản xuất thay vì đo việc sử dụng. Dấu hiệu là một kế hoạch dự án có cột mốc cuối là một ngày chứ không phải một con số.

Tiến độ cho dự án nhỏ, vừa và phức tạp

Thời gian trôi và công sức là hai câu hỏi khác nhau mà bên mua hay gộp làm một. Đây là các dải nội bộ của chúng tôi từ công việc tầm trung tại Anh, không phải số liệu công bố.

Một dự án nhỏ, tối đa khoảng 25 người dùng trên một cloud, nhiều nhất một tích hợp và một nguồn dữ liệu sạch, chạy 6 đến 10 tuần và 20 đến 45 ngày công tư vấn. Một dự án cỡ vừa, 25 đến 150 người dùng trên một hoặc hai cloud, hai đến bốn tích hợp và một cuộc di chuyển thật, chạy 4 đến 7 tháng và 90 đến 220 ngày. Một chương trình phức tạp, từ 150 người dùng trở lên, đa cloud, từ năm tích hợp và hơn một quốc gia, chạy 9 đến 18 tháng và từ 400 ngày.

Trong các tổng đó, khảo sát chiếm 10 đến 15% công sức, cấu hình và xây dựng 30 đến 40%, di chuyển dữ liệu 20 đến 30% và tăng vọt khi nguồn kém, tích hợp 10 đến 20%, còn kiểm thử, đào tạo và hypercare 15 đến 20%. Dòng phình ra luôn là di chuyển.

Thời gian trôi vượt công sức chia cho quy mô đội vì những lý do không phải lỗi của đội: chu kỳ làm mới sandbox, mức sẵn sàng của các bên liên quan cho kiểm thử chấp nhận, và việc chờ bên thứ ba có API bạn cần. Ai gánh rủi ro đó là do hợp đồng quyết, và vì thế câu hỏi giá cố định hay tính công tính vật tư nặng ký với công việc CRM hơn phần lớn công việc khác.

Bảo vệ dữ liệu tại Anh trong một chương trình CRM

CRM là một cơ sở dữ liệu về con người, nên UK GDPR áp dụng cho gần như toàn bộ nó, và ba câu hỏi nổi lên ở mọi dự án.

Việc này có cần DPIA không

Hướng dẫn của ICO về khi nào cần làm DPIA nêu quy tắc chung từ Article 35(1), rằng cần DPIA khi việc xử lý có khả năng gây rủi ro cao cho quyền và tự do của con người, và liệt kê bộ hoạt động riêng của ICO theo Article 35(4).

Hai trong số đó rơi thẳng vào một cuộc di chuyển CRM điển hình. So khớp dữ liệu, định nghĩa là kết hợp, so sánh hoặc đối chiếu dữ liệu cá nhân lấy từ nhiều nguồn, chính là việc một cuộc di chuyển hợp nhất làm. Lập hồ sơ quy mô lớn bao gồm chấm điểm Lead và Account. ICO cũng lưu ý rằng trong đa số trường hợp, hai tiêu chí châu Âu cùng xuất hiện là dấu hiệu cần DPIA, dù đó không phải quy tắc cứng. Lưu ý rằng hướng dẫn này đang được rà soát do các thay đổi của Data (Use and Access) Act, nên hãy kiểm tra nó thay vì dựa vào một bản tóm tắt.

Dữ liệu thực sự nằm ở đâu

Salesforce là nền tảng toàn cầu và việc tổ chức của bạn chạy trên instance nào là chuyện hợp đồng, không phải chuyện giả định. Hướng dẫn ngắn về chuyển dữ liệu quốc tế của ICO, cập nhật lần cuối ngày 15 tháng 1 năm 2026, cho một phép thử ba bước: UK GDPR có áp dụng cho việc xử lý không, bạn có đang khởi tạo việc chuyển tới một tổ chức ngoài Anh không, và bên nhận có là một pháp nhân riêng không. Ba lần có nghĩa đó là một cuộc chuyển bị hạn chế.

Chuyển bị hạn chế cần quy định về mức bảo vệ tương xứng của Anh, các biện pháp bảo đảm phù hợp như International Data Transfer Agreement, Addendum hay quy tắc doanh nghiệp ràng buộc, hoặc một ngoại lệ. Khi bạn dựa vào biện pháp bảo đảm, ICO mong đợi một bản đánh giá rủi ro chuyển dữ liệu. Đây là việc rà soát hợp đồng chứ không phải việc kỹ thuật, và nó nên xảy ra trước cuộc di chuyển chứ không phải sau.

Đối tác triển khai của bạn là một bên xử lý

Khi một đối tác cấu hình tổ chức của bạn, nạp dữ liệu của bạn và giữ thông tin xác thực vào đó, họ đang xử lý dữ liệu cá nhân thay mặt bạn. Hướng dẫn của ICO về bên kiểm soát và bên xử lý nêu những gì theo sau, và hệ quả thực tế nằm ở hợp đồng.

Bạn cần một thỏa thuận bằng văn bản bao gồm chỉ dẫn được ghi thành văn, bảo mật, an ninh, bên xử lý phụ, quyền kiểm toán, và việc xóa hoặc trả lại dữ liệu khi kết thúc hợp tác. Điều cuối cùng là điều khoản hay thiếu nhất. Một đối tác giữ bản sao đầy đủ cơ sở dữ liệu khách hàng của bạn trong một Full sandbox suốt mười một tháng, mà hợp đồng không nói gì về việc xóa nó, là một trách nhiệm để ngỏ nằm ở phía bạn chứ không phải phía họ.

Nên hỏi một đối tác tiềm năng điều gì

Sáu câu hỏi, và những câu trả lời đáng để kết thúc cuộc nói chuyện.

Hỏi khảo sát tạo ra gì. Nếu câu trả lời là một bản đề xuất chứ không phải bản đồ quy trình, mô hình dữ liệu, danh mục tích hợp và một định nghĩa hoàn thành đo được, thì họ đang bán chứ không đang xác định phạm vi.

Hỏi họ sẽ khảo sát dữ liệu nguồn thế nào và khi nào. Nếu việc đó diễn ra sau khi ước lượng di chuyển đã chốt, ước lượng ấy là phỏng đoán.

Hỏi mặc định của họ cho tự động hóa là gì, và nghe xem có lập luận về mật độ không. Đối tác nói luôn dùng Flow hoặc luôn dùng Apex chỉ có một công cụ. Đối tác chỉ định Process Builder vào năm 2026 đã ba năm không đọc một thông báo khai tử nào.

Hỏi thay đổi đi từ sandbox lên sản xuất bằng cách nào. Câu trả lời change sets chấp nhận được với tổ chức một quản trị viên và là cảnh báo với bất cứ thứ gì lớn hơn.

Hỏi ai sở hữu tổ chức sau khi lên sản xuất và mỗi tuần bao nhiêu giờ. Nếu họ không trả lời được, mức độ sử dụng không là việc của ai cả.

Hỏi dữ liệu của bạn trong sandbox của họ sẽ ra sao khi hợp tác kết thúc, và lấy câu trả lời trong hợp đồng chứ không phải trong một email. Đúng kỷ luật chúng tôi nêu ở hướng dẫn thẩm định kỹ thuật cũng áp dụng ở đây: hãy xác minh lời tuyên bố thay vì chấp nhận lời bảo đảm.

Khi câu trả lời không phải Salesforce

Nếu bạn có dưới khoảng mười người dùng, không có yêu cầu tích hợp và một quy trình vừa với đường ống năm giai đoạn, thì giấy phép Enterprise lẫn dự án triển khai đều lớn hơn vấn đề. Một CRM rẻ hơn, hoặc Starter Suite ở £20 mỗi người dùng, làm được việc và sau này thay được với chi phí bạn chịu nổi.

Nếu yêu cầu thật của bạn là một luồng việc không sản phẩm nào hỗ trợ còn mọi thứ khác đã ổn, thì bạn đang mua một nền tảng để chứa đúng một ứng dụng. Đó thường là chỗ cho một hệ thống làm riêng, và công việc phát triển phần mềm đặt riêng của chúng tôi xuất phát từ tiền đề ấy. Quyết định tự xây hay mua xoay quanh việc quy trình tạo khác biệt là lõi của doanh nghiệp hay chỉ là một chi tiết quanh nó.

Nếu không ai chịu sở hữu hệ thống, đừng mua. Đây là điều khó nói nhất trong một quá trình bán hàng và là dự báo lãng phí đáng tin nhất. Một CRM vô chủ không hỏng ầm ĩ. Nó lặng lẽ thành bản sao của chính bảng tính mà nó lẽ ra phải thay thế, với £140 mỗi người dùng mỗi tháng.

Và nếu mục tiêu là một lớp tác nhân AI chứ không phải một CRM, thì nó ngồi trên một dự án đã chạy được chứ không thay thế dự án đó. Bài toán tiền nằm ở bài Agentforce thực sự tốn bao nhiêu của chúng tôi.

Trình tự công việc

Trình tự có hiệu quả là: khảo sát dữ liệu, chạy khảo sát tới bốn sản phẩm đầu ra, chốt mô hình chuẩn và gắn giá cho mọi chỗ đi chệch, xây theo một điểm vào tự động hóa cho mỗi đối tượng, diễn tập di chuyển hai lần trong Full sandbox, đào tạo theo vai trò, và giữ dự án mở cho tới khi đạt một con số sử dụng chứ không phải tới một ngày.

Trình tự thất bại là: ký, cấu hình, di chuyển muộn, đào tạo một lần, lên sản xuất đúng ngày, đóng dự án.

Mecanik làm phần thuộc về kỹ thuật chứ không phải quản trị giấy phép: thiết kế tích hợp đối chiếu hạn mức nền tảng thật, khảo sát và công cụ di chuyển, phát triển đặt riêng ở chỗ cấu hình hết đường, và phần front end đưa dữ liệu CRM ra trước mặt khách hàng. Trang dịch vụ phát triển phần mềm và thuê lập trình viên web của chúng tôi nói rõ cách chúng tôi tham gia. Nếu bạn muốn một ý kiến thứ hai về báo giá của một đối tác trước khi ký, bạn có thể thuê một lập trình viên chỉ cho việc rà soát ấy.

Câu hỏi thường gặp

Một dự án triển khai Salesforce ở Anh tốn bao nhiêu? Salesforce niêm yết Sales Cloud Enterprise tại Anh ở £140 mỗi người dùng mỗi tháng khi trả theo năm, nên 50 người dùng là £84.000 một năm chỉ riêng giấy phép. Ước tính nội bộ của chúng tôi cho dịch vụ triển khai bên trên là 0,5 đến 1 lần chi phí giấy phép năm đầu với một bản triển khai gần như nguyên bản, 1 đến 3 lần với một dự án tầm trung điển hình, và 3 đến 5 lần với một chương trình đa cloud có dữ liệu cũ và tùy biến nặng.

Một dự án Salesforce mất bao lâu? Các dải nội bộ của chúng tôi là 6 đến 10 tuần cùng 20 đến 45 ngày công tư vấn cho tối đa 25 người dùng trên một cloud với dữ liệu sạch, 4 đến 7 tháng cùng 90 đến 220 ngày cho 25 đến 150 người dùng với hai đến bốn tích hợp, và 9 đến 18 tháng cùng từ 400 ngày cho một chương trình đa cloud có di chuyển dữ liệu cũ. Giai đoạn phình ra là di chuyển dữ liệu, vì công sức của nó tỷ lệ với chất lượng dữ liệu nguồn chứ không với số bản ghi.

Vì sao các dự án Salesforce thất bại? Gần như luôn ở mức độ sử dụng chứ không phải ở ngày lên sản xuất. Một hệ thống đúng về kỹ thuật mà không ai dùng là mất trắng kèm hóa đơn giấy phép vẫn chạy. Nguyên nhân thường gặp là sao chép một quy trình hỏng, tùy biến không giới hạn, không có người sở hữu duy nhất được nêu tên, chuyển toàn bộ dữ liệu lịch sử, thiếu kỷ luật môi trường kiểm thử, và đo ngày lên sản xuất thay vì đo việc sử dụng.

Nên dựng Salesforce bằng cấu hình hay bằng mã tùy chỉnh? Hướng dẫn quyết định của chính Salesforce đặt ngưỡng theo mật độ tự động hóa. Dưới mười lăm tự động hóa trên một đối tượng, lô 1 đến 200 bản ghi và nhiều nhất một lượt ghi phía sau thì nên dùng Flow kích hoạt theo bản ghi. Mật độ trung bình hợp với Flow điều phối invocable Apex. Mật độ cao hợp với Apex trigger. Hãy dùng một điểm vào cho mỗi đối tượng thay vì trộn Flow và Apex trigger trên cùng một đối tượng.

Chúng tôi có cần DPIA cho một dự án Salesforce không? Thường là có. ICO liệt kê so khớp dữ liệu, tức kết hợp hoặc so sánh dữ liệu cá nhân từ nhiều nguồn, và lập hồ sơ quy mô lớn nằm trong các hoạt động cho thấy cần DPIA, còn một cuộc di chuyển hợp nhất có chấm điểm lead thì làm cả hai. Hướng dẫn này đang được rà soát sau Data (Use and Access) Act, nên hãy xem lập trường hiện tại của ICO thay vì một bản tóm tắt của nó.