Kết nối CRM, kế toán và đơn hàng: điều gì làm thay đổi báo giá tích hợp?

Hai nhà cung cấp có thể cùng báo giá kết nối CRM, hệ thống đơn hàng và phần mềm kế toán, nhưng phạm vi công việc rất khác nhau. Một bên có thể chỉ chuyển đơn hàng mới. Bên kia còn có thể đối chiếu khách hàng, trả trạng thái kế toán, xử lý thay đổi về sau và đưa dữ liệu cũ vào kết nối.

Để so sánh báo giá, hãy mô tả điều cần xảy ra với một đơn hàng cụ thể và ai kiểm tra kết quả. Số lượng ứng dụng cho biết công việc diễn ra ở đâu. Quy tắc giữa các ứng dụng cho biết cần xây dựng những gì.

Theo dõi một đơn hàng qua các hệ thống

Hãy hình dung một doanh nghiệp bán buôn giả định. Bộ phận kinh doanh lưu thông tin liên hệ khách hàng trong CRM, nhân viên xác nhận đơn trong hệ thống đơn hàng, còn bộ phận tài chính dùng phần mềm kế toán riêng. Doanh nghiệp muốn một đơn đã được chấp nhận tạo ra chứng từ nháp để tài chính xem xét.

Lấy đơn hàng ORD-204 làm ví dụ. Khách hàng của đơn này có mã C-81 trong CRM và tài khoản A-347 trong hệ thống kế toán. Cần có người xác nhận hai mã đó thuộc cùng một khách hàng. Chỉ so tên công ty sẽ để lại vấn đề chưa giải quyết khi tên thay đổi hoặc hai hồ sơ trông giống nhau.

Sau đó, xác định hệ thống nào là nguồn thông tin có thẩm quyền cho từng dữ liệu. CRM có thể cung cấp tên người liên hệ, kế toán cung cấp thông tin lập hóa đơn đã được phê duyệt, còn hệ thống đơn hàng cung cấp số lượng đã được chấp nhận và giá đã thống nhất. Đây chỉ là quy tắc đề xuất cho ví dụ; doanh nghiệp cần tự thống nhất quy tắc của mình.

Chữ “đã chấp nhận” cũng cần được định nghĩa. Bộ phận kinh doanh chấp nhận đơn không có nghĩa là tài chính đã phê duyệt chứng từ được tạo ra. Tài liệu của Microsoft về Dynamics 365 Sales minh họa sự khác biệt qua các giai đoạn báo giá, đơn hàng và hóa đơn riêng. Đó là quy trình của một sản phẩm cụ thể. Kết nối của bạn cần tuân theo phần mềm và quy tắc kinh doanh thực tế.

Cùng ba hệ thống, phạm vi khác nhau

Dưới đây là ba phạm vi có thể áp dụng cho doanh nghiệp giả định. Mỗi phạm vi thêm việc phải xác định, triển khai và kiểm tra, với điều kiện các sản phẩm thực tế hỗ trợ những thao tác cần thiết.

Phạm vi nhỏ hơn có thể đã đủ. Công việc thủ công phải được nêu rõ trong đề xuất để bên mua quyết định cách làm đó có phù hợp hay không. Với phạm vi lớn hơn, cần mô tả cụ thể các luồng dữ liệu và quyết định bổ sung.

Viết sơ đồ kết nối để nhà cung cấp có thể báo giá

Bắt đầu bằng luồng từ hệ thống đơn hàng sang kế toán và ghi rõ sự kiện kích hoạt: “Đơn hàng chuyển sang trạng thái đã chấp nhận trong hệ thống đơn hàng”. Ghi mã đơn hàng và cách đối chiếu mã khách hàng. Liệt kê các trường dữ liệu được chuyển, gồm cách hiểu số lượng, chiết khấu, tiền tệ và trạng thái khi có liên quan. Thống nhất cách xử lý kế toán với người chịu trách nhiệm.

Chỉ rõ thao tác ở hệ thống đích: tạo bản nháp, cập nhật bản nháp còn đủ điều kiện chỉnh sửa, hoặc chuyển trường hợp đó cho tài chính. Nêu ai được phê duyệt. Xác định thời gian chuyển dự kiến và thời điểm nhân viên cần kiểm tra một giao dịch chưa hoàn tất. “Thường xuyên” kém cụ thể hơn một thời hạn đã thống nhất theo nhu cầu kinh doanh.

Mô tả riêng từng luồng trả về. Kế toán gửi lại mã chứng từ là một thao tác. Gửi lại trạng thái thanh toán là thao tác khác. Không thao tác nào có nghĩa mọi thông tin khách hàng hoặc chứng từ đều có thể sửa ở cả hai hệ thống.

Hướng dẫn của Microsoft về chuyển đổi dữ liệu giữa các hệ thống giải thích vì sao những khác biệt về ý nghĩa dữ liệu cần được xử lý có chủ đích, đồng thời cần tính đến việc bảo trì và theo dõi. Hướng dẫn mô tả một mẫu kiến trúc, không yêu cầu mọi kết nối đều phải dùng mẫu đó. Khi lập báo giá, điều thiết thực là nêu rõ công việc chuyển đổi thay vì cho rằng hai trường có tên gần giống sẽ mang cùng ý nghĩa.

Thống nhất cách nhân viên kiểm tra kết quả

Với từng luồng, hãy ghi rõ thế nào là hoàn tất. Chỉ gửi một thông điệp chưa cho biết bản nháp cần tạo có tồn tại với đúng khách hàng và tổng tiền hay không. Thống nhất cách đối chiếu bản ghi nguồn và đích, phát hiện kết quả bị thiếu hoặc sai lệch, và tìm mã cần thiết để điều tra.

Chỉ định người hoặc nhóm đầu tiên nhận trường hợp lỗi, thông tin họ có thể xem và ai được sửa bản ghi nguồn hoặc cho phép thử lại. Đưa vào các ví dụ như khách hàng chưa được nhận diện, trường dữ liệu bị từ chối và thay đổi đến sau khi chứng từ đã được xem xét. Quyết định trường hợp nào nhân viên sẽ xử lý thủ công.

Khi đó, sơ đồ kết nối trở thành bản mô tả có thể thực hiện: sự kiện kích hoạt, dữ liệu gốc có thẩm quyền, mã định danh, chiều chuyển, ý nghĩa các trường, thao tác ở đích, thời gian, cách xác nhận hoàn tất và người phụ trách trường hợp lỗi. Thêm người cung cấp tài khoản thử nghiệm và xác nhận kết quả đạt yêu cầu.

Xác định ranh giới của dữ liệu lịch sử

“Bao gồm đơn hàng cũ” đặt ra nhiều câu hỏi. Hãy chọn loại bản ghi và khoảng thời gian, xác định dữ liệu khách hàng liên quan cần có, rồi giao trách nhiệm đối chiếu và làm sạch dữ liệu. Nêu rõ những gì sẽ được kiểm tra sau khi nhập.

Tách công việc một lần này khỏi việc chuyển dữ liệu liên tục. Thống nhất tập dữ liệu cũ kết thúc ở đâu và xử lý đơn hiện tại bắt đầu từ đâu, kể cả cách tính các thay đổi trong giai đoạn chuyển tiếp. Nếu không, hai nhà cung cấp có thể dự tính lượng việc chuẩn bị và kiểm tra khác nhau dù cả hai đều ghi “nhập dữ liệu” trong đề xuất.

So sánh các giả định và công việc vận hành

Yêu cầu mỗi nhà cung cấp báo giá theo cùng một sơ đồ kết nối. Đề nghị họ nêu những gì đã xác nhận về phiên bản sản phẩm, thao tác được phép, quyền truy cập, giới hạn giao diện và điều khoản của bộ kết nối, cùng những gì còn phải kiểm tra. Việc có tài liệu API hoặc logo bộ kết nối chưa chứng minh tài khoản của bạn thực hiện được thao tác cần thiết.

Khi chưa có quyền truy cập hoặc một quy tắc chưa được quyết định, hãy hỏi cách giải quyết điểm chưa rõ đó và ảnh hưởng của nó đến đề xuất. Hướng dẫn Contracting for Agile của Chính phủ Anh bàn về tác động của thông tin chưa đầy đủ đến lựa chọn thương mại trong mua sắm công. Với việc so sánh này, bài học hữu ích là làm rõ các giả định trước khi coi hai cam kết là tương đương.

Tách việc thiết lập và thử nghiệm ban đầu khỏi phí thuê bao phần mềm hoặc bộ kết nối định kỳ. Sau đó, xác định công việc vận hành và bảo trì đã thống nhất: quản lý thông tin truy cập, kiểm tra các lần chuyển chưa xong, điều chỉnh quy tắc đối chiếu dữ liệu và xử lý thay đổi về khả năng tương thích. Hỏi phần nào được bao gồm, ai thực hiện và cách thống nhất các thay đổi về sau. Một dòng phí thuê bao không tự giải thích những trách nhiệm đó.

Kết thúc việc so sánh bằng cách theo dõi ORD-204 trong từng đề xuất. Bạn có thấy dữ liệu nào đến, đến khi nào, điều gì xảy ra nếu không hoàn tất và ai tiếp nhận không? Mỗi điểm khác biệt là một quyết định về phạm vi cần bàn trước khi so tổng giá.

Nếu muốn trao đổi với LINK-V về một kết nối đã xác định, dịch vụ tích hợp API của chúng tôi là điểm bắt đầu phù hợp. Hãy mang theo các luồng dữ liệu và câu hỏi chưa giải quyết. Phạm vi và công việc vận hành, bảo trì tiếp theo được thỏa thuận riêng cho từng dự án.

Câu hỏi về báo giá tích hợp