“Tích hợp ERP liền mạch” là một lời hứa tiêu chuẩn, nhưng trên thực tế lại đi kèm với một dự án kéo dài ba tháng. Chúng tôi công bố Cẩm nang API của mình để bộ phận CNTT của quý vị có thể kiểm tra những gì thực sự được yêu cầu trước khi ký hợp đồng. Dưới đây là những điều quý vị cần biết trước khi bắt đầu một dự án tích hợp.
Những gì hệ thống ERP của quý vị thực sự phải cung cấp
Để xây dựng một DPP, chúng tôi cần các thông tin sau cho mỗi sản phẩm:
- Dữ liệu cơ sở - Mã sản phẩm, tên sản phẩm, các biến thể, trọng lượng, kích thước, hình ảnh
- Dữ liệu danh mục linh kiện - Các thành phần kèm theo số lượng và tỷ lệ vật liệu tái chế
- Dữ liệu nguồn gốc - Nơi sản xuất, số lô, ngày sản xuất
- Dữ liệu môi trường - CO2eq trên mỗi đơn vị, lượng nước tiêu thụ, lượng năng lượng tiêu thụ
- Dữ liệu nhà cung cấp - Ai cung cấp thành phần nào (để thẩm định)
Về mặt lý thuyết, tất cả các dữ liệu này đều có sẵn trong hệ thống ERP của quý vị. Trên thực tế, chúng được phân tán trong 4 đến 7 mô-đun: Quản lý vật tư (MM), Sản xuất (PP), Chất lượng (QM), Nhà cung cấp (LFA1), đôi khi có một mô-đun EHS riêng biệt cho dữ liệu môi trường, đôi khi là hệ thống PLM cho công thức sản phẩm.
Câu hỏi về tích hợp không phải là: “Hệ thống ERP của quý vị có cung cấp dữ liệu cho một DPP không?” Mà là: “Làm thế nào để quý vị tổng hợp dữ liệu từ 5 hệ thống con thành một bộ dữ liệu thống nhất?”
Ba mô hình tích hợp đã được chứng minh hiệu quả
Mô hình 1: OData / REST-Pull
Hoạt động tốt với các hệ thống ERP hiện đại (SAP S/4HANA Cloud, Dynamics 365, Odoo). Nhà cung cấp DPP trích xuất dữ liệu qua OData hoặc REST. Theo từng đợt, theo lịch trình hoặc theo sự kiện.
Ưu điểm: ít phải phát triển từ phía quý vị, quý vị cung cấp thông tin xác thực truy cập (Read-Credentials), nhà cung cấp sẽ xây dựng quy trình chuyển đổi.
Nhược điểm: không hoạt động với các phiên bản SAP ECC cũ hơn nếu không có lớp API bổ sung. Quý vị cần có cơ chế quản trị đối với các yêu cầu truy cập dữ liệu (Data Access Requests).
Mô hình 2: Tích hợp dựa trên sự kiện
SAP Event Mesh, Apache Kafka, RabbitMQ. Hệ thống ERP của quý vị công bố các sự kiện thay đổi, nhà cung cấp DPP tiêu thụ chúng.
Ưu điểm: gần như thời gian thực, khả năng mở rộng linh hoạt, tách biệt.
Nhược điểm: Việc thiết lập phức tạp và cần cơ sở hạ tầng mà không phải bộ phận CNTT nào cũng có. Đối với các công ty nhỏ, giải pháp này thường là quá mức cần thiết.
Mô hình 3: Phần mềm trung gian / ETL
Bạn có một lớp tích hợp (Mulesoft, Boomi, Informatica, Azure Data Factory) giữa hệ thống ERP và các hệ thống bên ngoài. Phần mềm trung gian đóng vai trò là “cầu nối” - nhà cung cấp DPP giao tiếp với phần mềm trung gian, chứ không bao giờ kết nối trực tiếp với hệ thống ERP.
Ưu điểm: Có thể tận dụng các khoản đầu tư hiện có, quản trị ổn định, bên thứ ba không thể truy cập trực tiếp vào hệ thống ERP.
Nhược điểm: Chi phí phần mềm trung gian của quý vị sẽ tăng theo quy mô.
Cách chúng tôi thực hiện khác biệt trong các dự án cụ thể
Nhiều nhà cung cấp muốn kết nối trực tiếp với hệ thống ERP của quý vị. Về nguyên tắc, chúng tôi luôn tích hợp một bước trung gian: API của chúng tôi chấp nhận lược đồ JSON trung lập, mà quý vị có thể điền dữ liệu bằng công cụ tùy chọn của mình. Điều này có nghĩa là:
- Quý vị có thể tự xử lý dữ liệu bằng các công cụ mà đội ngũ của quý vị đã quen thuộc
- Quý vị có thể thay thế chúng tôi - định dạng trung lập này có tính di động cao
- Quý vị có thể trích xuất toàn bộ dữ liệu của mình bất cứ lúc nào - dưới dạng CSV, XLSX, JSON-LD và SQL cũng như thông qua REST-API
- Chúng tôi cung cấp một công cụ kiểm tra tính hợp lệ khi nhập liệu, giúp kiểm tra dữ liệu của bạn trước khi tải lên
Sơ đồ đầy đủ và tất cả các điểm cuối (endpoints) đều được công khai dưới dạng đặc tả OpenAPI tại /apidocs. Bộ phận CNTT của quý vị có thể kiểm tra giao diện này trước khi ký hợp đồng - bao gồm các yêu cầu mẫu, phản hồi lỗi và chi tiết xác thực.
Khung thời gian thực hiện phương pháp này trên thực tế:
- Ngày 1 đến 2: Hội thảo lập bản đồ dữ liệu. Trường ERP nào sẽ tương ứng với trường DPP nào?
- Ngày 3 đến 5: Xuất dữ liệu JSON đầu tiên từ hệ thống ERP, thông qua công cụ kiểm tra hợp lệ của chúng tôi.
- Ngày 6 đến 8: Khắc phục lỗi (trường dữ liệu thiếu, mã hóa không nhất quán).
- Ngày 9 đến 10: Các DPP đầu tiên đi vào hoạt động.
Chỉ hai tuần, chứ không phải ba tháng. Điểm mấu chốt nằm ở hội thảo lập bản đồ - chính tại đây, chất lượng dữ liệu sẽ được quyết định.
Những điều có thể xảy ra sai sót: những cạm bẫy phổ biến nhất
Dữ liệu cơ sở sản phẩm tồn tại trên nhiều hệ thống: SAP lưu trữ mã sản phẩm, PIM lưu trữ hình ảnh và nội dung tiếp thị, PLM lưu trữ bảng danh mục linh kiện. Không ai có được bức tranh tổng thể nhất quán. Giải pháp: Trước khi bắt đầu dự án, hãy xác định hệ thống nào là “Nguồn dữ liệu chính xác” (Source of Truth) cho từng trường dữ liệu.
Chứng chỉ dưới dạng PDF: Các nhà cung cấp gửi chứng chỉ GOTS, OEKO-TEX hoặc REACH dưới dạng bản quét PDF. Đây không phải là nguồn dữ liệu có cấu trúc. Giải pháp: Các tổ chức cấp chứng nhận ngày càng cung cấp các truy vấn qua API (OEKO-TEX đi đầu, GOTS còn chậm hơn). Hoặc: nhập liệu thủ công, nhưng phải kèm theo ngày hết hạn để đảm bảo không có chứng chỉ đã hết hạn xuất hiện trong DPP.
Bảo mật công thức: đặc biệt trong lĩnh vực mỹ phẩm, thực phẩm và dược phẩm: công thức đầy đủ là bí mật kinh doanh. DPP có nên công khai thông tin này không? Giải pháp: Mô hình ba cấp độ của ESPR. Danh mục sản phẩm được công khai, các cơ quan chức năng mới có thể xem công thức đầy đủ. Điều này hầu như không bao giờ là rào cản, nhưng cần được làm rõ từ sớm.
Dữ liệu CO₂ dựa trên nhà cung cấp: Nhà cung cấp của quý vị cung cấp giá trị trung bình cho toàn bộ danh mục sản phẩm của họ, chứ không phải theo từng lô. Giải pháp: Tạm thời chấp nhận, về lâu dài điều chỉnh hợp đồng với nhà cung cấp. ESPR yêu cầu các giá trị cụ thể cho từng sản phẩm kể từ một ngày mốc nhất định, nhưng thực tiễn hiện tại là một giải pháp thỏa hiệp.
Các phiên bản ngôn ngữ địa phương: Hệ thống ERP của quý vị chỉ chứa tên sản phẩm bằng tiếng Đức và tiếng Anh. Đối với 27 quốc gia EU, quý vị cần nhiều hơn thế. Giải pháp: Dịch máy kết hợp với cơ sở dữ liệu thuật ngữ; chúng tôi có một bài viết riêng về vấn đề này.
Những câu hỏi quý vị nên đặt ra trước khi bắt đầu dự án
Trước khi gửi yêu cầu đề xuất (RFP) cho ba nhà cung cấp, hãy trả lời các câu hỏi sau trong nội bộ:
- Sẽ có bao nhiêu sản phẩm/mã hàng cần có DPP? (10, 10.000, 1 triệu?)
- Hiện nay, những hệ thống nào đang lưu trữ dữ liệu liên quan đến DPP?
- Bộ phận nào quản lý từng hệ thống đó?
- Quý vị có đầu tư vào phần mềm trung gian (middleware) nào cần được tận dụng không?
- Có lớp API nào đang hoạt động trên hệ thống ERP của quý vị không?
Các câu trả lời sẽ quyết định mô hình nào trong ba mô hình trên phù hợp với quý vị. Và chúng cũng xác định xem dự án sẽ kéo dài hai tuần hay sáu tháng.