Tích hợp ERP với CRM và kế toán là nối ba hệ thống để một giao dịch bán hàng đi trọn từ cơ hội, báo giá, đơn hàng, giao hàng, hoá đơn tới thu tiền mà không ai phải nhập lại. Điều quyết định thành bại không phải công nghệ kết nối mà là bảng phân quyền dữ liệu: mỗi đối tượng — khách hàng, sản phẩm, giá, đơn hàng, công nợ — do hệ thống nào làm chủ, hệ thống nào chỉ đọc.
Bài này dành cho trường hợp phổ biến ở doanh nghiệp vừa tại Việt Nam: CRM do phòng kinh doanh chọn, phần mềm kế toán đã dùng nhiều năm, và ERP hoặc phần mềm quản lý kho mới triển khai. Nếu bạn cần hiểu ERP là gì và gồm những phân hệ nào, đó là chủ đề nền tảng nên đọc trước; ở đây tập trung vào cách các hệ thống nói chuyện với nhau.
Vì sao ba hệ thống này hay "đánh nhau"
Mỗi hệ thống sinh ra từ một nhu cầu khác nhau. CRM tối ưu cho tốc độ của người bán: tạo khách nhanh, sửa báo giá liên tục, chấp nhận thông tin chưa đầy đủ. Phần mềm kế toán tối ưu cho tính chính xác và tuân thủ: khách hàng phải có tên pháp lý, mã số thuế đúng, chứng từ đã ghi sổ thì không sửa được mà phải điều chỉnh. ERP hoặc phần mềm kho tối ưu cho vận hành: tồn kho, lô, hạn dùng, kế hoạch giao.
Ba logic này xung đột ở các điểm giao. Người bán muốn tạo khách hàng mới ngay trong cuộc gọi; kế toán không muốn hàng trăm "khách hàng" không có mã số thuế tràn vào sổ công nợ. Người bán muốn sửa đơn hàng sau khi khách đổi ý; kho đã soạn hàng theo đơn cũ. Nếu không có quy tắc, tích hợp chỉ làm cho sự xung đột xảy ra nhanh hơn.
Một ví dụ quen thuộc ở doanh nghiệp phân phối: người bán hứa với khách giao trong hai ngày dựa trên số tồn hiển thị trong CRM, nhưng số đó được đồng bộ từ ERP mỗi đêm và hàng đã được giữ cho một đơn khác từ sáng. Khách nhận hàng trễ, người bán đổ lỗi cho kho, kho đổ lỗi cho phần mềm. Lỗi thật nằm ở thiết kế: tồn kho khả dụng là dữ liệu thay đổi từng phút, không nên lưu bản sao đồng bộ theo lô mà phải đọc trực tiếp từ hệ thống làm chủ khi cần.
Giải pháp là thừa nhận mỗi hệ thống có một giai đoạn làm chủ trong vòng đời giao dịch. Trước khi chốt đơn, CRM là chủ. Từ lúc đơn được xác nhận, ERP là chủ. Từ lúc hoá đơn phát hành, kế toán là chủ. Dữ liệu chảy theo một chiều chính qua các giai đoạn, và mọi sửa đổi ngược chiều phải đi qua quy trình chứ không qua đồng bộ tự động.
Bảng phân quyền dữ liệu mẫu
Bảng dưới đây là một cách chia phổ biến, cần điều chỉnh theo quy trình của từng doanh nghiệp. Cột "Chiều đồng bộ" mô tả dữ liệu chảy từ đâu tới đâu.
| Đối tượng | Hệ thống làm chủ | Chiều đồng bộ | Ghi chú |
|---|---|---|---|
| Khách hàng tiềm năng, cơ hội | CRM | Không đồng bộ | Chưa phải khách hàng chính thức, không đưa vào ERP hay kế toán |
| Khách hàng chính thức | ERP (hoặc kế toán) | ERP → CRM, kế toán | CRM đề xuất tạo mới; hồ sơ được duyệt mới sinh mã chính thức |
| Sản phẩm, đơn vị tính | ERP | ERP → CRM, kế toán | CRM không được tạo mặt hàng |
| Bảng giá, chiết khấu chuẩn | ERP | ERP → CRM | Chiết khấu ngoài khung cần phê duyệt ghi nhận trong ERP |
| Báo giá | CRM | Không đồng bộ hoặc chỉ khi chốt | Có thể có nhiều phiên bản; chỉ phiên bản được chấp nhận mới đi tiếp |
| Đơn bán hàng | ERP | CRM → ERP khi chốt, trạng thái ERP → CRM | Sau khi tạo trong ERP, sửa đơn phải làm ở ERP |
| Hoá đơn, công nợ, thu tiền | Kế toán | Kế toán → ERP, CRM | CRM chỉ hiển thị để người bán biết khách còn nợ |
Hai quyết định hay gây tranh cãi nhất là nơi tạo khách hàng chính thức và nơi giữ bảng giá. Cả hai nên giao cho hệ thống có quy trình kiểm soát chặt hơn, đồng thời cho CRM quyền đề xuất để người bán không phải chờ.
Luồng quote-to-cash qua ba hệ thống
Thuật ngữ quote-to-cash chỉ toàn bộ chuỗi từ báo giá tới khi tiền về tài khoản. Dưới đây là luồng điển hình, kèm điểm tích hợp ở mỗi bước.
- Báo giá trên CRM dùng sản phẩm và bảng giá đã đồng bộ từ ERP. Người bán thấy tồn kho khả dụng qua một lời gọi đọc tới ERP, không lưu bản sao tồn kho trong CRM.
- Chốt báo giá: nếu khách hàng chưa có mã chính thức, CRM gửi yêu cầu tạo khách hàng sang ERP; bộ phận phụ trách duyệt, ERP trả mã về CRM.
- Tạo đơn bán hàng: CRM đẩy báo giá đã chấp nhận sang ERP kèm mã định danh duy nhất để tránh tạo trùng nếu gửi lại.
- Kiểm tra hạn mức tín dụng trong ERP dựa trên công nợ đồng bộ từ kế toán; đơn vượt hạn mức chuyển sang chờ duyệt, trạng thái báo ngược về CRM.
- Xuất kho và giao hàng trong ERP; trạng thái giao cập nhật về CRM để người bán trả lời khách.
- Phát hành hoá đơn điện tử từ kế toán hoặc ERP tuỳ thiết kế; số hoá đơn và trạng thái gắn ngược vào đơn hàng.
- Ghi nhận thu tiền trong kế toán sau khi đối soát sao kê ngân hàng; công nợ cập nhật sang ERP và CRM.
Ở bước sáu, câu hỏi hệ thống nào phát hành hoá đơn cần quyết định sớm vì liên quan quy định về hoá đơn điện tử và kết nối với nhà cung cấp dịch vụ hoá đơn. Chỉ nên có một nơi phát hành để tránh hoá đơn trùng; hãy kiểm tra yêu cầu hiện hành với kế toán trưởng và nhà cung cấp dịch vụ.
Đồng bộ công nợ và bút toán: thời gian thực hay theo lô
Không phải luồng nào cũng cần thời gian thực. Trạng thái đơn hàng và tồn kho khả dụng nên gần tức thời vì người bán dùng để trả lời khách. Ngược lại, bút toán doanh thu và giá vốn từ ERP sang kế toán thường được đẩy theo lô cuối ngày hoặc cuối kỳ, dưới dạng chứng từ tổng hợp hoặc từng chứng từ, tuỳ yêu cầu chi tiết của kế toán.
Đẩy theo lô có lợi cho kiểm soát: kế toán có điểm dừng để rà soát trước khi ghi sổ, và có thể đối chiếu tổng số đơn, tổng giá trị giữa hai hệ thống. Đẩy từng chứng từ tức thời làm sổ sách luôn cập nhật nhưng mỗi lỗi ánh xạ tài khoản sẽ ghi sai ngay vào sổ, và việc điều chỉnh sau khi khoá sổ tốn công hơn.
Dù chọn cách nào, cần một bảng ánh xạ tài khoản được kế toán trưởng phê duyệt: nhóm sản phẩm nào ghi vào tài khoản doanh thu nào, kho nào tương ứng tài khoản hàng tồn kho nào, khoản chiết khấu ghi ra sao. Bảng này là tài liệu nghiệp vụ, phải nằm ngoài mã nguồn để kế toán tự xem và đề xuất sửa. Khi ánh xạ được viết thẳng vào mã, mỗi lần thay đổi hệ thống tài khoản là một lần phải gọi lập trình viên.
Bảy lỗi tích hợp hay gặp và cách phòng
Tạo trùng đơn khi mạng chập chờn. CRM gửi đơn, không nhận được phản hồi, gửi lại. Phòng bằng khoá định danh duy nhất cho mỗi đơn để ERP nhận ra lần gửi lặp.
Sửa đơn hai nơi. Người bán sửa số lượng trên CRM sau khi đơn đã vào ERP; thay đổi không đi tiếp hoặc ghi đè thao tác của kho. Phòng bằng cách khoá đơn trên CRM sau khi chuyển.
Mã sản phẩm lệch. Một mặt hàng ngừng kinh doanh trên ERP nhưng vẫn hiện trên CRM. Phòng bằng đồng bộ trạng thái sản phẩm, không chỉ tên và giá.
Làm tròn số khác nhau. CRM tính thuế theo từng dòng, kế toán tính trên tổng hoá đơn; chênh vài đồng nhân lên hàng nghìn hoá đơn. Thống nhất một quy tắc làm tròn và một nơi tính.
Múi giờ và ngày chứng từ. Đơn tạo lúc 23 giờ 30 trên hệ thống đám mây đặt giờ quốc tế bị ghi sang ngày hôm sau. Kiểm tra cấu hình múi giờ ở cả ba hệ thống.
Lỗi im lặng. Một bản ghi bị từ chối vì thiếu trường nhưng không ai được báo. Mọi bản ghi lỗi phải vào một hàng đợi có người xử lý và cảnh báo.
Không có đối chiếu định kỳ. Tích hợp chạy nhiều tháng, lệch dần. Thiết lập báo cáo đối chiếu số lượng và giá trị đơn, hoá đơn, công nợ giữa các hệ thống hằng tuần.
Kiểm thử và vận hành sau khi kết nối
Kiểm thử tích hợp khác kiểm thử từng phần mềm ở chỗ phải đi trọn kịch bản nghiệp vụ, gồm cả đường vòng: đơn bị huỷ sau khi xuất kho một phần, khách trả hàng sau khi đã xuất hoá đơn, thanh toán thiếu, thanh toán gộp cho nhiều hoá đơn, khách hàng đổi tên pháp lý giữa kỳ. Mỗi kịch bản phải có kết quả mong đợi ở cả ba hệ thống, được người dùng nghiệp vụ xác nhận.
Trước khi chạy thật, nên chạy song song một thời gian ngắn: nhập liệu theo cách cũ và để tích hợp chạy trên môi trường thử với dữ liệu thật đã ẩn danh, rồi so kết quả cuối ngày. Cách này tốn công nhưng bắt được những lỗi ánh xạ mà kịch bản thử không nghĩ tới.
Sau khi chạy thật, trách nhiệm vận hành phải rõ: ai nhận cảnh báo, trong bao lâu phải xử lý, khi nào được phép tạm dừng đồng bộ. Mỗi lần một trong ba phần mềm nâng cấp phiên bản, bộ kịch bản kiểm thử hồi quy cần chạy lại. Đây là chi phí định kỳ mà dự toán ban đầu hay bỏ sót, và là lý do nhiều tích hợp chạy tốt năm đầu rồi hỏng dần vào năm thứ hai.
Một thói quen vận hành đáng giá là họp rà soát tích hợp ngắn mỗi tháng giữa IT, kinh doanh và kế toán trong vài tháng đầu: xem số bản ghi lỗi theo loại, nguyên nhân gốc, và những thay đổi quy trình sắp tới có thể ảnh hưởng tới ánh xạ. Phần lớn lỗi tích hợp sau giai đoạn đầu không đến từ mã nguồn mà từ thay đổi nghiệp vụ không được báo cho người phụ trách kết nối, chẳng hạn mở thêm kho, thêm loại chiết khấu hay đổi cách đánh mã sản phẩm.
Câu hỏi thường gặp
Có nên thay CRM và kế toán bằng một ERP đủ phân hệ để khỏi tích hợp không?
Một hệ thống thống nhất giảm số điểm tích hợp, nhưng đổi lại phải chấp nhận phân hệ CRM hoặc kế toán của ERP có thể kém linh hoạt hơn phần mềm chuyên dụng, và chi phí chuyển đổi lớn. Quyết định nên dựa trên mức độ đặc thù của quy trình bán hàng và độ ổn định của phần mềm kế toán hiện có.
Người bán có nên thấy công nợ của khách trên CRM không?
Nên thấy ở mức đọc: tổng dư nợ, nợ quá hạn, hạn mức còn lại. Thông tin này giúp người bán không chốt đơn với khách đang quá hạn và chủ động nhắc thanh toán. Không nên cho sửa hay ghi nhận thu tiền từ CRM.
Đồng bộ khách hàng hai chiều có được không?
Được về kỹ thuật nhưng phải có quy tắc giải quyết xung đột cho từng trường, ví dụ thông tin liên hệ lấy theo CRM, thông tin pháp lý lấy theo kế toán. Đồng bộ hai chiều không quy tắc là nguyên nhân phổ biến của dữ liệu bị ghi đè qua lại.
Tích hợp nên làm trước hay sau khi triển khai ERP?
Nên thiết kế cùng lúc với ERP, vì bảng phân quyền dữ liệu ảnh hưởng tới cấu hình ERP. Việc lập trình kết nối có thể làm sau giai đoạn cấu hình lõi, nhưng phải xong và kiểm thử trước ngày chạy thật.
Khách hàng cá nhân mua lẻ có cần đưa vào phần mềm kế toán từng người không?
Thường không cần. Nhiều doanh nghiệp bán lẻ dùng một mã khách lẻ chung trong kế toán và giữ chi tiết người mua ở hệ thống bán hàng hoặc CRM, trừ khi người mua yêu cầu hoá đơn ghi thông tin riêng. Cách làm cụ thể cần đối chiếu quy định hoá đơn hiện hành.
Làm sao biết tích hợp đang lệch?
Thiết lập báo cáo đối chiếu tự động theo tuần: số đơn và tổng giá trị đơn đã xác nhận trong ERP so với CRM, tổng hoá đơn so với doanh thu ghi sổ, tổng công nợ giữa kế toán và ERP. Chênh lệch khác không cần được giải thích từng khoản.