Trọng lượng của sản phẩm được ghi trong hệ thống quản lý vật tư. Tỷ lệ nguyên liệu tái chế được ghi trong hệ thống công thức. Chứng chỉ của nhà cung cấp được lưu dưới dạng tệp PDF trên ổ đĩa mạng. Hồ sơ sản phẩm cần cả ba thông tin này trong một bản ghi dữ liệu duy nhất, và chính điều này mới là trọng tâm của dự án tích hợp, chứ không phải việc kết nối hai hệ thống.
“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ế, điều này thường đi kèm với một dự án kéo dài ba tháng. Chúng tôi công bố hướng dẫn này để bộ phận CNTT của quý vị có thể kiểm tra những thông tin thực sự được yêu cầu trước khi ký kết hợp đồng. Bài viết này sẽ chỉ ra những dữ liệu mà Thẻ thông tin sản phẩm cần từ các hệ thống của quý vị, ba phương thức để dữ liệu được chuyển đến chúng tôi, cũng như lý do tại sao quá trình này có thể hoàn tất trong vòng hai tuần.
Những gì hệ thống ERP của quý vị thực sự cần cung cấp
Để tạo ra một Thẻ thông tin sản phẩm (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ệ nguyên 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 (để tuân thủ nghĩa vụ 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ị. Tuy nhiên, trên thực tế, chúng được phân tán trong 4 đến 7 mô-đun: Quản lý vật tư, Sản xuất, Chất lượng, Cơ sở dữ liệu nhà cung cấp, đôi khi là một mô-đun riêng biệt dành cho dữ liệu môi trường, hoặc đôi khi là một hệ thống độc lập dành cho công thức và bảng danh mục linh kiện.
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 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 phương pháp đã được kiểm chứng
Phương pháp 1: Trích xuất dữ liệu từ hệ thống ERP
Phương pháp này hoạt động hiệu quả với các hệ thống ERP hiện đại (SAP S/4HANA Cloud, Dynamics 365, Odoo). Nhà cung cấp DPP sẽ lấy dữ liệu qua giao diện của hệ thống ERP (về mặt kỹ thuật là OData hoặc REST). Chỉ lấy những thay đổi, theo lịch trình hoặc được kích hoạt bởi một sự kiện cụ thể.
Ưu điểm: Ít công việc phát triển từ phía quý vị; quý vị chỉ cần cấp quyền truy cập đọc, còn nhà cung cấp sẽ đảm nhận việc chuyển đổi dữ liệu.
Nhược điểm: Không tương thích với các phiên bản SAP ECC cũ hơn nếu không có lớp giao diện bổ sung. Quý vị cần thiết lập các quy tắc rõ ràng về việc ai được phép truy cập dữ liệu nào.
Phương án 2: Chuyển tiếp các thay đổi
Hệ thống ERP của quý vị sẽ thông báo mọi thay đổi dưới dạng sự kiện (thông qua SAP Event Mesh, Apache Kafka hoặc RabbitMQ), và nhà cung cấp DPP sẽ tiếp nhận các sự kiện này.
Ưu điểm: gần như theo thời gian thực, có khả năng mở rộng linh hoạt, các hệ thống không phụ thuộc lẫn nhau.
Nhược điểm: Việc thiết lập khá phức tạp và đòi hỏi cơ sở hạ tầng mà không phải bộ phận CNTT nào cũng có. Đối với các doanh nghiệp nhỏ, giải pháp này thường là quá mức cần thiết.
Phương án 3: Sử dụng lớp tích hợp hiện có
Quý vị đã có sẵn 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. Lớp này đóng vai trò như một “hợp đồng”: Nhà cung cấp DPP giao tiếp với lớp này, 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ó, các quy tắc được duy trì ổn định, bên thứ ba không truy cập trực tiếp vào hệ thống ERP.
Nhược điểm: Chi phí cho lớp tích hợp của quý vị cũng tăng theo.
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: Giao diện của chúng tôi chấp nhận định dạng dữ liệu trung lập (một lược đồ JSON), mà quý vị có thể điền dữ liệu vào 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 hiện có 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 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 quý vị trước khi tải lên
Định dạng đầy đủ và tất cả các truy vấn đều được công bố công khai tại Tài liệu API, dưới dạng tài liệu mô tả giao diện theo tiêu chuẩn OpenAPI. Bộ phận CNTT của quý vị có thể kiểm tra giao diện này trước khi ký kết 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 nào trong hệ thống ERP sẽ tương ứng với trường nào trong DPP?
- Ngày 3 đến 5: Các bản xuất JSON đầu tiên từ hệ thống ERP, được kiểm tra qua công cụ xác thực của chúng tôi.
- Ngày 6 đến 8: Khắc phục lỗi (các 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 chính thức đ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 đồ dữ liệu - đây chính là nơi quyết định chất lượng dữ liệu.
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, quý vị cần xác định rõ hệ thống nào sẽ là hệ thống chủ đạo cho từng trường dữ liệu cụ thể.
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 dịch vụ truy vấn qua giao diện (OEKO-TEX đi đầu, trong khi 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 hệ thống 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. Liệu DPP có phải 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, trong khi 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ờ gây cản trở, 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 cần điều chỉnh các 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ị hiện 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 thành viên 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 triển khai dự án
Trước khi gửi yêu cầu đề xuất (RFP) đến ba nhà cung cấp, quý vị hãy tự 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 này?
- Quý vị có lớp tích hợp nào cần được sử dụng không?
- Có giao diện nào đang hoạt động thông qua hệ thống ERP của quý vị không?
Các câu trả lời sẽ quyết định phương án nào trong ba phương án trên phù hợp với quý vị.
Các câu trả lời sẽ xác định liệu dự án sẽ kéo dài hai tuần hay sáu tháng.
Các câu hỏi liên quan đến bài viết này
Giao diện REST có đủ hay chúng ta cần một phần mềm trung gian?
Giao diện này là đủ. Ba mô hình này khác nhau ở chỗ quá trình chuyển đổi diễn ra ở đâu, chứ không phải ở những gì chúng tôi nhận vào - giao diện của chúng tôi chấp nhận một lược đồ JSON trung lập, bất kể quý vị đã tạo ra nó bằng công cụ nào. Dữ liệu được trích xuất từ một hệ thống ERP hiện đại, luồng sự kiện và lớp tích hợp hiện có đều được chuyển đến cùng một điểm cuối. Việc sử dụng phần mềm trung gian (middleware) là hợp lý nếu quý vị đang vận hành một hệ thống như vậy và muốn duy trì nó như một phần của thỏa thuận với các bên thứ ba. Nếu hiện tại chưa có, xin đừng mua phần mềm này chỉ để đáp ứng yêu cầu của “hộ chiếu sản phẩm”.
Trong hội thảo lập bản đồ sẽ quyết định những nội dung gì?
Trường ERP nào sẽ tương ứng với trường trong hệ thống đối tác - và hệ thống nào sẽ là nguồn dữ liệu chính khi có nhiều hệ thống lưu trữ cùng một giá trị. Buổi hội thảo diễn ra vào Ngày 1 và Ngày 2, và đây chính là điểm mấu chốt của toàn bộ dự án, bởi vì chất lượng dữ liệu sẽ được quyết định tại đây chứ không phải ở giai đoạn lập trình sau này. Xin vui lòng mời những người trực tiếp quản lý các hệ thống tham gia, chứ không chỉ những người chịu trách nhiệm về dự án - các bộ phận Dữ liệu cơ sở, Sản xuất, Chất lượng và Mua hàng hiếm khi nằm trong cùng một phòng ban. Tất cả các công đoạn sau đó, bao gồm xuất dữ liệu, xác thực và khắc phục lỗi, đều là công việc kỹ thuật.
Các chứng chỉ của chúng tôi hiện chỉ có dưới dạng bản quét PDF. Chúng tôi nên xử lý chúng như thế nào?
Bản quét không phải là nguồn dữ liệu có cấu trúc và do đó không thể sử dụng được cho thẻ thông hành. Có hai cách thực hiện hiệu quả: các nhà cung cấp dịch vụ chứng nhận ngày càng cung cấp các yêu cầu truy vấn qua API; và trong trường hợp chưa có API, quý vị hãy nhập các giá trị thủ công, nhưng luôn phải đi kèm ngày hết hạn để đảm bảo không có chứng nhận đã hết hạn nào còn tồn tại trong thẻ thông hành đã được công bố. Xin hãy lên kế hoạch thực hiện phương pháp nhập liệu thủ công như một công việc định kỳ, chứ không phải là nhiệm vụ chỉ thực hiện một lần.
Bộ phận CNTT của chúng ta có thể kiểm tra giao diện này trước khi chúng ta ký bất kỳ văn bản nào không?
Vâng. Sơ đồ đầy đủ và tất cả các điểm cuối đều được cung cấp dưới dạng đặc tả OpenAPI tại Tài liệu API, kèm theo các yêu cầu mẫu, phản hồi lỗi và thông tin chi tiết về xác thực. Tất cả những thông tin này đều không bị ràng buộc bởi bất kỳ cuộc đàm phán kinh doanh nào, do đó đội ngũ tích hợp của quý vị có thể đánh giá mức độ phức tạp trước khi ký kết hợp đồng. Nếu một nhà cung cấp không công khai giao diện của họ ở giai đoạn này, thì đó cũng là một dấu hiệu cần lưu ý.
Khi chúng ta chuyển sang nhà cung cấp khác, dữ liệu của chúng ta sẽ ra sao?
Hệ thống sẽ hỗ trợ quý vị. Giao diện này chấp nhận lược đồ JSON trung lập thay vì định dạng độc quyền, và toàn bộ dữ liệu của quý vị sẽ được xuất ra dưới dạng CSV, XLSX, JSON-LD và SQL hoặc thông qua REST-API. Điều này là có chủ đích - định dạng mà quý vị nhập liệu có tính di động cao, do đó việc chuyển đổi chỉ cần thực hiện xuất dữ liệu chứ không cần phải xây dựng lại từ đầu. Hãy đặt cùng một câu hỏi cho mỗi nhà cung cấp trước buổi hội thảo lập bản đồ, bởi sau đó các tên trường của quý vị sẽ được tích hợp vào mô hình của họ.
Thực tế thì việc kết nối mất bao lâu?
Trong các dự án mà chúng tôi hỗ trợ, quy trình kéo dài hai tuần: hai ngày để lập bản đồ dữ liệu, ba ngày để hoàn tất các lần xuất dữ liệu đầu tiên thông qua công cụ kiểm định của chúng tôi, ba ngày để khắc phục lỗi, và hai ngày để hoàn tất việc công bố các “hộ chiếu dữ liệu” đầu tiên. Quá trình tốn nhiều thời gian nhất không bao giờ nằm ở phần mã nguồn, mà là những vấn đề mà công cụ kiểm định phát hiện ra - các trường dữ liệu còn thiếu, cách mã hóa không thống nhất, hay những giá trị mà không ai chịu trách nhiệm. Xin quý vị hãy lên kế hoạch dành đủ thời gian cho những giai đoạn này, thay vì cắt giảm chúng. Một dự án bỏ qua các giai đoạn này sẽ vô tình công bố cả những lỗ hổng đó cùng với sản phẩm.
Chúng ta có cần phải kết nối tất cả các sản phẩm cùng một lúc không?
Không. Quý vị hãy bắt đầu với những sản phẩm cần được phê duyệt trước tiên, cùng với một hệ thống nguồn - lược đồ trung lập này chấp nhận cả danh mục một phần lẫn danh mục đầy đủ, và các thao tác nhập liệu có thể lặp lại, do đó các lần chạy sau sẽ cập nhật danh mục. Điều này cũng giúp buổi làm việc về lập bản đồ giữ được quy mô vừa phải, đủ để hoàn thành trong hai ngày. Việc mở rộng sau đó chỉ là một nhiệm vụ lập bản đồ, chứ không phải một dự án mới.
