Không phải doanh nghiệp nào có cả CRM và ERP cũng cần nối hai hệ thống lại. Việc tích hợp có chi phí, có rủi ro dữ liệu và cần người bảo trì — nên nó chỉ đáng làm khi việc thiếu kết nối đang thực sự cản trở công việc hằng ngày.
Bài viết này nói về cách nhận ra thời điểm đó, và những gì cần làm rõ trước khi bắt đầu.
CRM và ERP quản lý hai phần khác nhau
Đây là điểm hay bị nhầm, và nhầm ở đây dẫn tới những kỳ vọng sai về phạm vi dự án.
| Thường thuộc về CRM | Thường thuộc về ERP / kế toán / kho | |
|---|---|---|
| Đối tượng | Khách hàng, lead, người liên hệ | Đơn hàng, chứng từ |
| Giai đoạn | Trước khi chốt | Sau khi chốt |
| Dữ liệu | Cơ hội, bối cảnh báo giá, hoạt động | Đơn bán, tồn kho, công nợ, hoá đơn |
| Câu hỏi trả lời | Ai đang quan tâm, đang ở bước nào | Đã giao gì, còn nợ bao nhiêu |
CRM giữ bối cảnh thương mại: đã trao đổi gì, hứa gì, đang thương lượng ở mức nào. ERP giữ bản ghi giao dịch: cái gì đã thực sự bán, đã giao, đã thu.
Một hệ thống không thay thế hệ thống kia. Tích hợp là để hai bên nhìn thấy phần của nhau ở đúng thời điểm cần, không phải để gộp làm một.
Những dấu hiệu cho thấy nên tích hợp
Những tình huống này lặp lại hằng ngày ở doanh nghiệp bán qua đại lý hoặc bán B2B:
- Nhân viên kinh doanh phải nhắn cho kho để hỏi còn hàng không, trước mỗi lần báo giá.
- Trước khi gọi khách, phải mở phần mềm kế toán xem khách còn nợ bao nhiêu.
- Cùng một khách hàng được tạo hai lần, ở hai hệ thống, với hai cách viết tên.
- Chốt xong phải gõ lại toàn bộ thông tin đơn hàng sang hệ thống khác.
- Thông tin khách ở hai nơi khác nhau, và không ai chắc bên nào đúng.
- Báo cáo doanh số phải ghép tay từ hai nguồn mỗi kỳ.
Điểm chung: con người đang làm nhiệm vụ truyền dữ liệu. Đó là công việc mà máy làm tốt hơn, và cũng là chỗ sai sót hay xuất hiện nhất.
Nếu chỉ có một tình huống xảy ra thỉnh thoảng, tích hợp có thể chưa đáng. Nếu vài tình huống lặp lại mỗi ngày, chi phí thủ công đang tích luỹ.
Những dữ liệu thường cần trao đổi
Phạm vi thực tế khác nhau theo từng doanh nghiệp. Những nhóm hay gặp:
- Hồ sơ khách hàng — để hai hệ thống nói về cùng một đối tượng.
- Trạng thái đơn hàng — từ vận hành quay lại CRM, để sales biết đã giao chưa.
- Tồn kho — thường chỉ cần mức đủ dùng để báo giá, không cần chi tiết.
- Công nợ — số dư phải thu hiện trên hồ sơ khách trong CRM.
- Lịch sử mua — để biết khách từng mua gì.
Không phải mọi thứ đều cần đồng bộ. Một trong những quyết định quan trọng nhất của giai đoạn thiết kế là chọn ra tập dữ liệu nhỏ nhất đủ để giải quyết vấn đề đang có. Đồng bộ thêm một trường nghĩa là thêm một chỗ có thể lệch.
Một chiều hay hai chiều?
Không có câu trả lời mặc định. Nó phụ thuộc vào quy trình và vào khả năng của hệ thống nguồn.
- Một chiều thường đủ khi chỉ cần hiển thị: đưa trạng thái đơn hàng và công nợ từ hệ thống vận hành sang CRM để sales nhìn thấy.
- Hai chiều cần thiết khi cả hai bên đều tạo hoặc sửa cùng một loại bản ghi — và cũng phức tạp hơn nhiều, vì phải quyết định bên nào thắng khi hai bên cùng sửa.
Nhiều dự án bắt đầu bằng một chiều và chỉ mở rộng khi có nhu cầu rõ ràng. Không phải hệ thống nào cũng cho phép ghi ngược trở lại, nên khả năng hai chiều cần được kiểm chứng kỹ thuật trước khi cam kết phạm vi.
Realtime có luôn cần không?
Thường là không, và giả định mặc định “phải realtime” hay làm dự án phức tạp và đắt hơn mức cần thiết.
Hãy hỏi: nếu dữ liệu này chậm mười lăm phút thì ai gặp vấn đề gì?
- Công nợ hiển thị trên hồ sơ khách — cập nhật định kỳ thường là đủ.
- Trạng thái đơn hàng — vài lần mỗi ngày thường đủ để sales trả lời khách.
- Tồn kho cho mặt hàng biến động nhanh — có thể cần gần thời gian thực.
Tần suất cập nhật nên xuất phát từ quyết định mà dữ liệu đó phục vụ, không từ mong muốn chung chung. Mức độ khả thi còn phụ thuộc vào những gì hệ thống nguồn cho phép.
Những rủi ro cần xử lý trước khi tích hợp
Phần lớn sự cố tích hợp không phải lỗi kỹ thuật mà là lỗi thoả thuận:
- Nguồn dữ liệu chuẩn — với mỗi trường, bên nào là bên đúng? Không trả lời được câu này thì mọi xung đột sau đó đều không có cách giải.
- Định danh bản ghi — hai hệ thống nhận ra “cùng một khách hàng” bằng cách nào? Mã khách, mã số thuế, hay một khoá do tích hợp tạo ra?
- Dữ liệu trùng — nếu hiện đang có bản ghi trùng, tích hợp sẽ nhân chúng lên chứ không dọn chúng đi.
- Ánh xạ trường — trạng thái, đơn vị tính, định dạng ngày ở hai bên hiếm khi giống nhau.
- Xử lý lỗi — khi một bản ghi không đẩy được, ai biết và xử lý thế nào? Một tích hợp âm thầm thất bại nguy hiểm hơn một tích hợp báo lỗi to.
- Quyền sở hữu sau này — ai bảo trì khi một trong hai hệ thống nâng cấp?
Làm rõ những điểm này trước thường rút ngắn phần kỹ thuật đáng kể.
API, Flow hay tích hợp riêng?
Ba hướng thường gặp, chọn theo khả năng của hệ thống nguồn và độ phức tạp của luồng:
- API sẵn có — khi cả hai hệ thống đều mở giao diện phù hợp.
- Công cụ nối luồng như Zoho Flow — cho những luồng theo sự kiện, không cần viết mã cho mọi bước.
- Tích hợp tuỳ chỉnh — khi nghiệp vụ đặc thù hoặc hệ thống nguồn cần cách kết nối riêng.
Không phải hệ thống nào cũng mở đủ giao diện để kết nối, nên phạm vi cần được khảo sát kỹ thuật trước khi cam kết. Đây là hạng mục hay bị đánh giá thấp nhất khi ước lượng ban đầu.
Khi nào chưa cần tích hợp?
Cũng quan trọng không kém:
- Số đơn hàng mỗi ngày còn ít, nhập tay không tốn đáng kể thời gian.
- Dữ liệu ở một trong hai hệ thống chưa sạch — nên dọn trước, tích hợp sau.
- Quy trình bán hàng còn đang thay đổi; tích hợp sẽ phải làm lại.
- Chưa ai trả lời được câu “bên nào là nguồn chuẩn”.
- Vấn đề thật ra là quy trình chứ không phải dữ liệu.
Trong những trường hợp này, tích hợp sớm chỉ cố định một quy trình chưa ổn định.
Bước tiếp theo
Với mô hình bán qua đại lý, ranh giới CRM–ERP và luồng từ cơ hội bán hàng đến công nợ được mô tả cụ thể ở giải pháp cho mạng lưới phân phối.
Nếu bạn đang chuẩn bị một dự án có phần tích hợp, giai đoạn khảo sát là nơi những câu hỏi ở trên được chốt — dịch vụ triển khai mô tả các giai đoạn và mô hình trách nhiệm giữa các bên.