Tích hợp CRM và ERP: Đồng bộ dữ liệu nào, ai quản lý và kiểm thử ra sao?

Tích hợp CRM và ERP kết nối các hoạt động phục vụ khách hàng với hệ thống ghi nhận đơn hàng, tồn kho, lập hóa đơn và các nghiệp vụ khác. Phần khó là quyết định bản ghi nào cần chuyển, hệ thống nào được phép thay đổi và cách phát hiện một lần chuyển thất bại.

Hãy bắt đầu từ một bước bàn giao nghiệp vụ. Nhân viên kinh doanh cần mã đơn hàng đã được chấp nhận. Bộ phận tài chính cần thông tin định danh bên được lập hóa đơn mà họ có thể tin cậy. Nhóm dịch vụ cần biết trạng thái giao hàng hiện tại. Mỗi nhu cầu cần một hợp đồng dữ liệu cụ thể. Cam kết đồng bộ mọi thứ không giải quyết được các quyết định này.

Bài viết hướng dẫn cách lập hợp đồng dữ liệu và kiểm thử một quy trình trước khi mở rộng. Bảng phân quyền và ví dụ đơn hàng đều là giả định. Chúng không đại diện cho trường hợp khách hàng, bộ kết nối đóng gói của Qonnex hay khả năng hỗ trợ giao diện giống nhau ở mọi CRM và ERP.

Giao cho tích hợp CRM và ERP một nhiệm vụ đo được

Chọn một bước bàn giao có điểm kích hoạt và điểm kết thúc rõ ràng. Ví dụ, một yêu cầu đặt hàng đã được cấp phép trên CRM trở thành đơn hàng được chấp nhận trên ERP, sau đó ERP trả mã đơn về CRM. Phạm vi này cụ thể hơn yêu cầu chung chung là “làm cho hai hệ thống khớp nhau”.

Chỉ định người chịu trách nhiệm cho kết quả nghiệp vụ. Nhóm vận hành kinh doanh có thể phụ trách chất lượng yêu cầu. Bộ phận vận hành có thể phụ trách chấp nhận đơn hàng. Tài chính có thể quản lý các kiểm soát lập hóa đơn. CNTT chịu trách nhiệm vận hành kỹ thuật và cần các bộ phận nghiệp vụ cùng xác định trách nhiệm của họ.

Ghi rõ điều cần cải thiện và cách đo. Có thể theo dõi thời gian nhập lại bằng tay, số yêu cầu bị từ chối, thời gian tồn đọng của lượt chuyển chưa xử lý và các sai lệch phát hiện khi đối soát. Xác định nguồn của từng chỉ số trước khi xây dựng kết nối.

Bài viết của Qonnex về chi phí công việc thủ công giải thích chi phí của việc nhập lại và bàn giao nhiều lần. Khi triển khai, hãy cụ thể hóa kết quả chẩn đoán thành một quy trình có tên, một người phụ trách và một kết quả có thể kiểm tra.

Hãy xác định nhu cầu nghiệp vụ trước khi cam kết cập nhật thời gian thực. Màn hình số dư cập nhật qua đêm và phép kiểm tra tồn kho trước khi xác nhận đơn có yêu cầu khác nhau về độ trễ. Ghi rõ dữ liệu được phép cũ đến mức nào và cách hiển thị dữ liệu quá hạn.

Lập danh mục bản ghi phục vụ nhiệm vụ đó

CRM và ERP có thể chia sẻ thông tin khách hàng, sản phẩm, đơn hàng và tài chính, nhưng khái niệm trong hai hệ thống có thể khác nhau. Khách hàng tiềm năng chưa đương nhiên đủ điều kiện lập hóa đơn. Cơ hội bán hàng chưa phải đơn hàng đã được chấp nhận. Giá trị cơ hội trong danh mục bán hàng chưa phải doanh thu đã ghi nhận.

Tổng quan tích hợp của IBM nêu các nhóm thông tin thường được chia sẻ như khách hàng, sản phẩm, giá và bán hàng. Hãy dùng danh sách này để rà soát các trường có thể cần chuyển, rồi chọn theo nhu cầu thực tế.

Với mỗi bản ghi trong quy trình đầu tiên, hãy xác định:

• Mã định danh ổn định ở nguồn và đích.
• Các trường cần có khi tạo bản ghi và các trường được phép sửa sau đó.
• Những bản ghi liên quan phải có trước.
• Sự kiện nghiệp vụ cho phép tạo hoặc cập nhật bản ghi.
• Phản hồi của hệ thống đích xác nhận đã chấp nhận bản ghi.

Xác định thứ tự phụ thuộc. Một yêu cầu đặt hàng có thể cần định danh khách hàng đã được duyệt và mã sản phẩm hợp lệ. Hãy quy định cách xử lý nếu thiếu một trong hai. Việc tạo bản ghi tạm để chuyển tiếp có thể làm dữ liệu lập hóa đơn và báo cáo trở nên thiếu tin cậy.

Tách khóa nghiệp vụ khỏi tên hiển thị. Hai công ty có thể có tên giống nhau. Một công ty có thể đổi tên mà vẫn là cùng một tài khoản. Ghi lại cách ánh xạ mã định danh giữa hai hệ thống và người có quyền duyệt việc sửa ánh xạ đó.

Phân quyền đến từng trường dữ liệu

Quy định “CRM quản lý khách hàng” thường quá rộng. Nhóm vận hành kinh doanh có thể phụ trách quan hệ khách hàng và tùy chọn liên hệ, còn tài chính kiểm soát điều khoản lập hóa đơn và thông tin pháp lý đã duyệt của bên được lập hóa đơn. Hãy quy định quyền hạn với từng trường quan trọng trong bước bàn giao.

Bảng dưới đây minh họa một cách thiết kế cho doanh nghiệp giả định. Mỗi doanh nghiệp cần tự xác định cách phân công.

Quy định trước cách xử lý xung đột. Nếu ai đó sửa trên CRM một trường lập hóa đơn do ERP quản lý, ứng dụng sẽ chặn, bỏ qua thay đổi và hiện cảnh báo, hay gửi yêu cầu đến tài chính? Hãy chọn cách xử lý rõ ràng. Việc ghi đè âm thầm làm người dùng mất niềm tin vào cả hai hệ thống.

Quy tắc “lần cập nhật cuối được ưu tiên” không thay thế được quy định về quyền hạn. Dấu thời gian mới hơn chưa chứng minh người sửa có thẩm quyền hoặc dữ liệu chính xác. Nếu cho phép sửa đồng thời, hãy quy định cách xử lý phiên bản và quyết định nào cần con người đưa ra khi hệ thống không thể xử lý xung đột một cách an toàn.

Viết hợp đồng dữ liệu bằng ngôn ngữ nghiệp vụ

Hợp đồng dữ liệu là thỏa thuận về ý nghĩa của một lượt chuyển. Người phụ trách quy trình phải đọc hiểu được và nhóm triển khai phải có đủ chi tiết để kiểm thử.

Với yêu cầu đặt hàng, hãy ghi mã nguồn, ánh xạ khách hàng đã duyệt, dòng hàng, số lượng, đơn vị, tiền tệ, các ngày bắt buộc và quy tắc kiểm tra áp dụng. Xác định cách xử lý chiết khấu, thuế, chi tiết giao hàng và trường tùy chọn theo nghiệp vụ thực tế. Giá trị để trống và giá trị bằng không có thể mang ý nghĩa khác nhau.

Quy định độ chính xác, múi giờ và cách dùng ngày. Một hệ thống có thể tính theo thùng, hệ thống kia tính theo từng sản phẩm. Ngày yêu cầu giao hàng khác với thời điểm phát sinh sự kiện. Số tiền thiếu đơn vị tiền tệ là dữ liệu chưa đầy đủ.

Có thể dùng yêu cầu giả định sau trong buổi lập kế hoạch:

Đây là các mã giả lập, không phải ảnh chụp màn hình hay dữ liệu hệ thống thật. Mọi số lượng và thời điểm trong ví dụ đều mang tính minh họa.

Mô tả đường trả kết quả chi tiết như đường gửi yêu cầu. Người dùng bên kinh doanh cần phân biệt đã gửi, đã chấp nhận, đã từ chối và đang chờ xác nhận. Thông báo gửi thành công chỉ xác nhận việc truyền dữ liệu. Cần bằng chứng riêng cho việc ERP đã chấp nhận đơn.

Chọn chiều đồng bộ và độ trễ theo nhu cầu

Truyền một chiều có thể phù hợp khi hệ thống nhận chỉ cần hiển thị giá trị chính thức. Trao đổi hai chiều có thể phù hợp khi mỗi hệ thống quản lý một phần khác nhau của quy trình. Quyền chỉnh sửa trường dùng chung vẫn do hợp đồng dữ liệu quy định.

Tổng quan dual-write của Microsoft mô tả tích hợp cụ thể giữa các ứng dụng tài chính, vận hành của Dynamics và Dataverse, bao gồm hoạt động hai chiều và kiểm soát vận hành. Đây là ví dụ cho một nền tảng cụ thể. Hãy xác minh riêng khả năng của sản phẩm khác và nhu cầu cập nhật hai chiều của từng bản ghi.

Tách quyết định kiến trúc khỏi hợp đồng nghiệp vụ. Kết nối API trực tiếp, nền tảng tích hợp và tính năng tích hợp có sẵn có các giới hạn khác nhau. Hãy xác định yêu cầu về dữ liệu, thời gian, quyền hạn và khôi phục trước, rồi đánh giá phương án nào được hỗ trợ và đáp ứng yêu cầu với chi phí vận hành chấp nhận được.

Hỏi rõ giới hạn liên quan đến quy trình: đối tượng được hỗ trợ, phương thức cập nhật, giới hạn tần suất, kích cỡ lô, thứ tự xử lý, thông báo sự kiện và thông tin lỗi. Kiểm tra các điểm này trong tài liệu hiện hành của hệ thống thực tế. Một bộ kết nối có tên trong danh mục vẫn cần được kiểm tra với giao dịch bạn định thực hiện.

Quy định cách xử lý khi bảo trì theo kế hoạch. Nếu ERP tạm ngừng, yêu cầu có thể được xếp hàng an toàn không? Người dùng có cần dừng xác nhận hàng còn hay không? Ai quyết định nối lại kết nối? Hãy trả lời các câu hỏi đó trong thiết kế vận hành trước lần gián đoạn đầu tiên.

Thiết kế cách khôi phục cập nhật bị lỗi

Một số lỗi có nguyên nhân rõ ràng, chẳng hạn yêu cầu bị từ chối vì thiếu bản ghi khách hàng bắt buộc. Có trường hợp khó xác định hơn: ERP chấp nhận đơn hàng nhưng phản hồi không đến được hệ thống tích hợp. CRM vẫn hiện đang chờ dù đơn đã tồn tại.

Dùng yêu cầu giả định DEMO-ORD-104 để diễn tập tình huống thứ hai. Quy trình khôi phục cần giữ mã yêu cầu, kiểm tra ERP thực sự chấp nhận điều gì và lấy lại mã đơn nếu giao diện hỗ trợ tra cứu. Nếu không thể xác nhận an toàn, chuyển bản ghi sang điều tra trước khi tạo thêm đơn.

Yêu cầu nhóm triển khai giải thích vì sao có thể gửi lại an toàn. Thao tác có tính lũy đẳng được thiết kế sao cho lặp lại cùng một yêu cầu không làm hiệu ứng nghiệp vụ xảy ra thêm lần nữa. Hãy kiểm tra giao diện thực tế có hỗ trợ tính chất này không và bảo vệ trong bao lâu.

Một số lỗi cần xử lý ngoài việc gửi lại yêu cầu hoặc khôi phục giá trị cũ. Đơn được chấp nhận có thể đã kích hoạt công việc tiếp theo. Hướng dẫn giao dịch bù trừ của Microsoft giải thích vì sao việc khôi phục có thể cần thao tác riêng theo nghiệp vụ và đôi khi cần con người can thiệp. Với quy trình này, hãy xác định ai có quyền hủy, sửa hoặc xử lý giao dịch đã chấp nhận.

Giữ đủ bằng chứng để điều tra, gồm mã yêu cầu, thời điểm sự kiện, mã ở nguồn và đích, trạng thái xử lý, lịch sử thử lại và loại lỗi. Tránh đưa toàn bộ hồ sơ khách hàng hoặc thông tin bí mật vào nhật ký vận hành. Hiển thị trạng thái giúp người dùng biết cần làm gì tiếp theo.

Đối soát bản ghi nghiệp vụ bên cạnh trạng thái tác vụ

Bảng điều khiển có thể báo tác vụ thành công trong khi bản ghi vẫn sai. Một tác vụ có thể chạy xong dù ánh xạ nhầm khách hàng, quy đổi sai đơn vị hoặc bỏ sót một dòng hàng. Hãy đối soát kết quả nghiệp vụ riêng với trạng thái kỹ thuật của lượt chuyển.

Với nhóm bản ghi thí điểm, dùng các mã đã được giữ lại để đối chiếu yêu cầu nguồn với bản ghi được chấp nhận ở đích. Kiểm tra các trường quan trọng và số dòng. Phân loại mọi mục chưa khớp thành bị từ chối, đang chờ, ngoài phạm vi hoặc cần điều tra. Chỉ định người phụ trách và lịch rà soát các mục chưa giải quyết.

Định nghĩa dữ liệu “hiện tại” trên CRM. Người dùng cần phân biệt được giá trị đã lâu không làm mới với giá trị mới. Quy định khi nào phải cảnh báo dữ liệu cũ và người dùng có được phép ra quyết định dựa trên dữ liệu đó hay không.

Tính cả khối lượng đối soát vào phép đo. Nếu kết nối bỏ được bước nhập lại nhưng phát sinh nhiều công kiểm tra tay, hãy đưa phần công đó vào so sánh. Bài viết của Qonnex về đo hiệu quả đầu tư tự động hóa giải thích vì sao cần tính đủ chi phí vận hành.

Kiểm thử hợp đồng trước khi mở rộng kết nối

Dùng môi trường thử nghiệm có kiểm soát với bản ghi giả lập hoặc dữ liệu đã được cấp quyền phù hợp. Thiết kế ca kiểm thử dựa trên hợp đồng nghiệp vụ. Kiểm tra thông tin xác thực và phản hồi API thành công mới chỉ là một phần.

Ghi kết quả thực tế, bằng chứng và xác nhận của người rà soát. Thống nhất lỗi nào chặn triển khai và cách kiểm thử lại ca đã sửa. Khả năng sửa tay của lập trình viên sau khi chạy thử chưa đủ để nghiệm thu ca đó.

Mời những người trực tiếp vận hành bước bàn giao tham gia. Đề nghị nhân viên kinh doanh giải thích một đơn đang chờ, nhân viên vận hành điều tra một yêu cầu bị từ chối và tài chính xác minh các trường do họ quản lý. Khả năng xử lý ngoại lệ của các nhóm này là một phần của nghiệm thu.

Chỉ định người duy trì kết nối

Chỉ định một người phụ trách kỹ thuật và một người phụ trách nghiệp vụ. Ghi rõ ai theo dõi lỗi, duy trì ánh xạ, duyệt sửa trường và thay thế khi có người vắng mặt. Thiết lập quy trình rà soát khi ứng dụng nâng cấp hoặc giao diện thay đổi.

Giới hạn quyền truy cập vào các bản ghi và thao tác mà kết nối cần. Tách thông tin xác thực thử nghiệm với sản xuất, quy định cách gia hạn và bảo đảm tài khoản tích hợp không phụ thuộc vào quyền truy cập của một nhân viên cụ thể. Người phụ trách an ninh của tổ chức cần rà soát các kiểm soát thực tế.

Đặt quy trình tạm dừng và khôi phục trước khi triển khai. Quy trình phải giữ công việc đang chờ và nhận diện những mục đã được chấp nhận. Khi nối lại kết nối, xác minh từng sự kiện cần xử lý lại thay vì gửi lại toàn bộ từ lúc gián đoạn.

Lần rà soát vận hành đầu tiên nên xem các bản ghi chưa xử lý, dữ liệu quá hạn, công sức sửa lỗi và bằng chứng về cải thiện dự kiến. Chỉ mở rộng sang loại bản ghi khác sau khi đã xác định các phụ thuộc và kiểm soát của nó. Hiển thị trạng thái hóa đơn và ghi mới bản ghi lập hóa đơn có quyền hạn và rủi ro khác nhau.

Mang theo hợp đồng dữ liệu khi bàn triển khai

Dịch vụ nâng cao hiệu quả vận hành hiện tại của Qonnex bao gồm kết nối các công cụ CRM, kế toán và vận hành đang có. Phạm vi phù hợp phụ thuộc vào giao diện và quy tắc vận hành hiện tại của doanh nghiệp. Có thể tích hợp mà vẫn sử dụng các hệ thống hiện tại. Khả năng cung cấp một bộ kết nối cụ thể của Qonnex cần được xác minh riêng.

Trước khi chọn cách triển khai, hãy chuẩn bị bốn tài liệu: bảng phân quyền theo bản ghi, hợp đồng dữ liệu, quy trình xử lý lỗi và đối soát, cùng ma trận nghiệm thu. Nhờ đó, các bên có thể xem xét từng quyết định cụ thể khi bàn về tích hợp.

Tách nội dung thương mại khỏi kiểm thử kỹ thuật. Bài giải thích của Qonnex về tư vấn dựa trên kết quả trình bày cách tiếp cận này. Kết nối hoạt động vẫn cần bằng chứng nghiệm thu và phương pháp đo kết quả nghiệp vụ đã thống nhất.

Để đánh giá một bước bàn giao cụ thể, hãy mô tả điểm kích hoạt, các hệ thống, người phụ trách và ngoại lệ hiện tại trong Bản phân tích doanh nghiệp. Bắt đầu từ bản ghi thường xuyên phải nhập lại và quyết định đang chờ bản ghi đó.