Sự số hóa và nhu cầu của các công ty phải phản ứng linh hoạt và nhanh chóng đối với yêu cầu của khách hàng đang thay đổi vai trò của hệ thống ERP trong các công ty. Trong bài viết này, bắt đầu từ vai trò cổ điển của ERP trong các công ty, sự chuyển đổi thành vai trò tương lai của nó được nhấn mạnh, đồng thời cũng cho thấy sự tương tác giữa các lớp hệ thống chính như ERP, PLM, CRM, MES và CPQ. Bài viết được chia thành hai phần. Phần đầu tiên xem xét về sự chuyển đổi hiện tại của vị trí của hệ thống ERP trong các công ty, trong khi phần thứ hai thảo luận về tương lai của hệ thống IT trong các công ty.
Thay đổi vị trí của ERP trong các công ty
Nhiều công ty nhận thấy rằng số hóa sẽ thay đổi căn bản cách kinh doanh và ngành công nghiệp của họ. Các bước nhảy công nghệ gần đây và các khủng hoảng toàn cầu đã tạo ra tiềm năng cho sự đảo lộn đa chiều có thể chưa từng tồn tại dưới dạng này trước đây.
Điều này tạo ra nhu cầu cho các công ty phải tự đặt câu hỏi về mình ở tất cả các lĩnh vực, nhúng tính linh hoạt vào quy trình của họ, có khả năng phản ứng nhanh chóng và hiệu quả đối với yêu cầu của khách hàng thay đổi, và cũng phải đối mặt với các mô hình kinh doanh dựa trên dữ liệu.
Điều này ảnh hưởng đến kiến trúc thông tin và thiết kế hệ thống IT, và cũng thay đổi căn bản vai trò của ERP.
Vị trí ban đầu của ERP trong các công ty
Sự ra đời của các hệ thống ERP vào cuối những năm 1980 có ý nghĩa như một cuộc cách mạng. Lần đầu tiên, đã có thể theo dõi lưu lượng số lượng và giá trị của một công ty, điều khiển sản xuất và chuỗi cung ứng, tính toán chi phí sản xuất và chuẩn bị bảng cân đối kế toán trong một hệ thống IT.
Việc bao phủ nhiều lĩnh vực ứng dụng trong một hệ thống IT trung tâm này đã dẫn đến quan điểm tập trung vào ERP ở nhiều nơi, cho rằng tất cả các chức năng doanh nghiệp có thể được thống nhất trong một hệ thống IT lớn duy nhất, ERP, và không cần gì khác trong công ty ngoài hệ thống IT lớn duy nhất này.
Quan điểm này bao gồm hai điểm mù quan trọng vẫn còn tác động đến ngày nay. Một trong những điểm mù đã trở nên rõ ràng khi CRM xuất hiện và Salesforce thành công kèm theo. Những nhà sản xuất ERP lớn, đầu tiên là SAP, thực sự chưa bao giờ thể thiết lập mình trong lĩnh vực này. Lý do cho điều này là phức tạp. Một lý do quan trọng mà ít ai để ý đến nhưng quan trọng là sự khác biệt cơ bản trong cách suy nghĩ và mô hình hóa của ERP và CRM. Một hệ thống ERP được thiết kế bằng mô hình dữ liệu và chức năng để xử lý hình thức của các thủ tục, theo nghĩa của các giao dịch. Logic cơ bản này cũng tạo hình và hướng tư duy và hành động của các nhà cung cấp của các hệ thống như vậy. Một hệ thống CRM, ngược lại, tuân theo một cách tiếp cận khác. Đối tượng kinh doanh quan trọng trong hệ thống CRM là cơ hội, tức là cơ hội bán hàng. Một cơ hội không có tính chính thức cao. Nó có một chu kỳ sống và được phát triển từng phần khi trưởng thành. Một logic quy trình một cách chặt chẽ và giao dịch, như cần thiết trong ERP, không phù hợp với một hệ thống CRM.
Các loại dữ liệu và những gì chúng có thể cho chúng ta biết
Tình huống đã mô tả đã chỉ ra một trong những điểm mù của quan điểm tập trung vào ERP. Nó trở nên rõ ràng hơn nếu phân tích các loại dữ liệu của ERP (xem Hình 1). Thuật ngữ SAP S/4HANA được sử dụng để giải thích điều này. Hình 1, Chi tiết A cho thấy một công ty với ERP là hệ thống IT chính. Dữ liệu trong hệ thống ERP có thể được phân loại thành các đối tượng tổ chức, dữ liệu chủ (có và không có liên kết tổ chức) và dữ liệu giao dịch. Dữ liệu tổ chức có nhiệm vụ đại diện cho các thực thể thực (ví dụ, nhà máy), thực trừu tượng (ví dụ, khu vực MRP, tổ chức bán hàng) và các thực thể pháp lý (khu vực kiểm soát, mã công ty, v.v.) trong doanh nghiệp. Dữ liệu chủ được xác định là dữ liệu cơ bản không thay đổi trong một khoảng thời gian nhất định. Dữ liệu giao dịch trong ERP ghi lại các giao dịch đang chờ xử lý, sẽ được thực hiện hoặc đã được thực hiện.
Hệ thống ERP so với dữ liệu chủ
Để tổng kết: “Nhiệm vụ chính của một hệ thống ERP là khởi động các quy trình và ghi lại hoàn thành của chúng. Các quy trình tập trung vào luồng lượng và giá trị. Trọng tâm không nằm ở việc mô tả cách thức thực hiện một quy trình, mà nằm ở việc ghi lại chính thức, hoàn thành và các chuyển động liên quan đến lượng và giá trị. Dữ liệu chủ cung cấp khung hoặc cấu trúc cần thiết cho nhiệm vụ này (xem Hình 1, Chi tiết B). Hình 1, Chi tiết C cho thấy những người trong tổ chức sử dụng các ứng dụng văn phòng, v.v. tạo thông tin, cơ bản là dữ liệu chủ. Từ quan điểm trung tâm ERP cổ điển, điều này có vẻ bình thường. Giả định rằng dữ liệu chủ không thay đổi trong một khoảng thời gian, quan điểm này cũng là hợp lý.”
Điểm mù đầu tiên – dữ liệu chủ ngày nay thay đổi liên tục
Ngày nay, giả định này không còn đúng! Điều này đã rõ ràng thông qua sự thay đổi mẫu quy trình trong ngành công nghiệp rời rạc. Động cơ thay đổi là nhu cầu của các công ty phải có khả năng phản ứng nhanh chóng, hiệu quả và không tăng chi phí đối với yêu cầu khách hàng thay đổi. Thị trường yêu cầu cung cấp các sản phẩm cá nhân hóa cao, nếu có thể với thời gian giao hàng và giá cả của các sản phẩm tiêu chuẩn. Mẫu quy trình Chọn để Đặt hàng (STO) và Thiết kế để Đặt hàng (ETO), từ trước đến nay vẫn phổ biến trong nhiều công ty, ngày nay gần như phát triển một cách phổ quát thành Mô phỏng để Đặt hàng (CTO/CTO+). Kiến thức về sự tồn tại của các mẫu quy trình khác nhau và công thức của chúng là một trong những kết quả quan trọng của những năm qua. Trong văn bản truyền thống tập trung vào ERP, chiến lược tích trữ hàng tồn, bao gồm Mua để Tồn kho (MTS), Lắp ráp để Đặt hàng (ATO) hoặc Sản xuất theo Đặt hàng (MTS) (Hình 2, Chi tiết A) được đề cập theo một loạt với mẫu quy trình Thiết kế để Đặt hàng (ETO) (Hình 2, Chi tiết B). Ngày nay, cần phải phân biệt rõ ràng giữa mẫu quy trình tạo thông tin và chiến lược tích trữ hàng tồn. Sự lựa chọn chiến lược tích trữ hàng tồn xác định vị trí điểm tách khách hàng tương ứng và cách mà quy trình từ đầu đến cuối được liên kết với quy trình kế hoạch-sản xuất (trực tiếp kết nối hoặc tách biệt qua tích trữ hàng tồn).
Mẫu quy trình (xem Hình 2, Chi tiết B) xác định cách thức tương tác giữa quy trình tạo thông tin, phát triển và thay đổi dữ liệu chủ liên quan đến sản phẩm (gọi là tạo thông tin) phải tương tác với các quy trình thực hiện, tức quy trình từ đầu đến cuối và quy trình kế hoạch-sản xuất (gọi là sử dụng thông tin). Sự xác định chính xác của chúng (xem Hình 2, Chi tiết C) là tiêu chí thiết kế trung tâm cho việc triển khai Quản lý Chu kỳ Sản phẩm (PLM).
Các quy trình liên kết
Hình 3 cho thấy các mẫu quy trình chính và tương tác giữa các quy trình tạo thông tin và sử dụng thông tin một cách rất tóm tắt. Trong STO nghiêm ngặt, tạo thông tin và sử dụng thông tin được tách biệt. Sản phẩm được phát triển và sản xuất sau khi bắt đầu sản xuất (SOP). Quan điểm cổ điển rằng dữ liệu chủ không thay đổi trong một khoảng thời gian lớn phần lớn đúng với STO. Với ETO nghiêm ngặt, việc tạo thông tin được bao gồm trong việc sử dụng thông tin. Ở đây, quan điểm cổ điển về dữ liệu chủ ổn định phần lớn cũng áp dụng. Với ETO, một phần lớn các thành phần sản phẩm được phát triển cho một đơn hàng cá nhân. Vì thông tin kết quả chỉ được sử dụng trong đơn hàng này, dữ liệu chủ vẫn phần lớn ổn định.
Mọi thứ khác biệt tại CTO+
Tuy nhiên, trong mẫu quy trình CTO+, tình hình này thay đổi một cách cơ bản. Trong CTO+ (xem Hình 3, chi tiết D), các thành phần sản phẩm tiêu chuẩn được bổ sung một cách tức thì bằng việc phát triển cá nhân trong trường hợp một đơn hàng. Điều này phải được thực hiện một cách tự động cao và trong thời gian ngắn nhất có thể. Tạo thông tin và sử dụng thông tin phải tương tác một cách cực kỳ linh hoạt. Các thành phần cụ thể cho đơn hàng thường được thêm vào hệ thống module và sau đó được sử dụng trong các đơn hàng và dòng sản phẩm khác nhau. Điều này dẫn đến tăng độ phức tạp với tần suất thay đổi dữ liệu chủ liên quan đến sản phẩm. Yêu cầu kiểm tra tăng cường càng làm trầm trọng thêm vấn đề này.
Trong trường hợp mẫu quy trình CTO/CTO+, dữ liệu chủ do đó thường xuyên thay đổi và phải được thực hiện một cách cấp thiết. Kết quả là việc tạo và quản lý vòng đời của chúng trở thành trung tâm của sự quan tâm. Điều này đã được chứng minh rõ ràng trong những năm gần đây thông qua sự phổ biến ngày càng tăng của quản lý chu kỳ sản phẩm (PLM) trong ngành công nghiệp.
EBOM và MBOM – Sự cần thiết của phương pháp đa cấu trúc
Việc xử lý phát triển độ chín và vòng đời của dữ liệu chính liên quan đến sản phẩm là một thách thức lớn đối với các công ty. Mẫu quy trình CTO+ yêu cầu xây dựng các dòng sản phẩm bao gồm các mô-đun có thể tái sử dụng. Cấu trúc sản phẩm đại diện cho dòng sản phẩm như vậy (thường được gọi là Engineering Bill of Material (EBOM) 150%) phải được cấu trúc chức năng để đại diện cho các mô-đun này. Khi triển khai mẫu quy trình CTO+, việc lắp ráp thường được thay đổi từ lắp ráp tại chỗ sang khái niệm lắp ráp dọc theo dây chuyền. Để làm điều này, một Manufacturing Bill of Material (MBOM), chứa các mô-đun lắp ráp có thể lưu kho, là bắt buộc như một đầu vào cho quá trình MRP (Material Requirements Planning – Lập kế hoạch nhu cầu vật liệu) trong hệ thống ERP. Cấu trúc của MBOM dựa trên bố trí sản xuất. Phương pháp này được gọi chung là khái niệm đa cấu trúc và thay thế cách suy nghĩ thông thường trước đây rằng cấu trúc sản phẩm và bill of material là một thứ.
Tầm quan trọng của quản lý vòng đời sản phẩm trong quy trình từ đặt hàng đến thu tiền
Trong quá trình từ đặt hàng đến thu tiền, EBOM 100% cần thiết cho đơn hàng được tạo ra từ EBOM 150% và sau đó được bổ sung theo yêu cầu cụ thể của đơn hàng (Hình 3, chi tiết E). EBOM 100% này sau đó được chuyển đổi thành MBOM 100% cụ thể cho đơn hàng. Trong mẫu quy trình CTO+, việc duy trì EBOM và MBOM cũng như việc chuyển đổi EBOM thành MBOM được thực hiện trong lĩnh vực nhiệm vụ Quản lý vòng đời sản phẩm (PLM) và do đó trong hệ thống PLM. Từ đó, MBOM được cung cấp vào ERP. Ý tưởng trước đây rằng bill of material sẽ được tạo ra trong ERP không còn phù hợp với CTO+ nữa.
Tóm lại, có thể nói: Vị trí của ERP trong các công ty đang thay đổi. Mẫu quy trình CTO/CTO+ đang thay đổi cách nhìn về ERP và dữ liệu chính. Trong khi trước đây chúng được coi là ổn định trong dài hạn, hiện nay chúng đang phải đối mặt với những động lực phức tạp. Việc xuất hiện và quản lý vòng đời của chúng đang trở nên quan trọng và thu hút sự chú ý đến PLM. ERP như là hệ thống chiếm ưu thế cho đến nay trong các công ty đang gặp áp lực do sự quan trọng ngày càng tăng của PLM và CRM trong việc đảm bảo các chức năng cốt lõi của doanh nghiệp. Điều này có thể thấy rõ nhất trong sự đối tác giữa Siemens và SAP và trong những cuộc thảo luận chặt chẽ đi kèm về cách ERP và hệ thống PLM nên tương tác.
Sẽ còn tiếp tục –
Một chủ đề rất hiện tại và trực tiếp theo sau luận điểm trước đó là vị trí của Hệ thống thực hiện sản xuất (MES) so với ERP và PLM.
Đọc phần tiếp theo để biết cách PLM đang chuẩn bị thay thế ERP từ đỉnh của hình thành tự động hóa và tại sao MBOM trong PLM là cổng vào cho MES.
5 sự thật quan trọng nhất
Các hệ thống ERP, xuất hiện vào những năm 1980, đã cách mạng hoá cách các công ty quản lý sản xuất, chuỗi cung ứng và tài chính của họ. Sai lầm khi nghĩ rằng mọi thứ trong các công ty có thể được tập trung trong một hệ thống ERP duy nhất. Các hệ thống ERP tập trung vào việc khởi động và tài liệu hóa quy trình liên quan đến lưu lượng số lượng và giá trị. Dữ liệu chính cung cấp cấu trúc cần thiết cho việc triển khai. Ngày nay, dữ liệu chính không còn ổn định mà phải thay đổi liên tục do yêu cầu của các sản phẩm được cá nhân hóa một cách cao.
Disclaimer: I am the author at PLM ECOSYSTEM, focusing on developing digital-thread platforms with capabilities across CAD, CAM, CAE, PLM, ERP, and IT systems to manage the product data lifecycle and connect various industry networks. My opinions may be biased. Articles and thoughts on PLMES represent solely the author's views and not necessarily those of the company. Reviews and mentions do not imply endorsement or recommendations for purchase.
Don’t hesitate to contact Thanh for advice on automation solutions for CAD / CAM / CAE / PLM / ERP / IT systems exclusively for SMEs.
Luu Phan Thanh (Tyler) Solutions Consultant at PLM Ecosystem Mobile +84 976 099 099
Web www.plmes.io Email tyler.luu@plmes.io