Câu hỏi vui. Hãy thử trả lời nó và so sánh một số quan điểm
1) Không: PLM là một chiến lược
Một số nói: không, nó không phải là một hệ thống. PLM trên hết là một chiến lược.
“Có thể hữu ích khi coi các chiến lược kinh doanh là các hệ thống, đặc biệt là khi nói đến quản lý chiến lược. Bằng cách xem mỗi sáng kiến chiến lược là một hệ thống các mục tiêu và dự án, chúng ta có thể thu nhỏ và nhận ra cách mỗi yếu tố phù hợp với bức tranh lớn hơn của chiến lược tổng thể. “
2) OK, PLM là một chiến lược, nhưng nó là gì nữa?
Một chiến lược không phải là một hành động. Đó là “một kế hoạch hành động được thiết kế để đạt được mục tiêu dài hạn hoặc tổng thể.” (Ngôn ngữ Oxford).
Đó là một chủ đề chung, nó là thứ xác định mục tiêu và con đường để đạt được mục tiêu đó.
Trên thực tế, PLM là những gì bạn làm, không phải những gì bạn nghĩ đến. Vì vậy, tôi cho rằng PLM KHÔNG phải là một chiến lược, ngay cả khi việc triển khai nó phải dựa trên một chiến lược rõ ràng, hiệu quả và thực dụng.
3) Vậy PLM là gì?
PLM có thể được gọi là một hệ thống. Đó là một cách tiếp cận có hệ thống để quản lý quá trình tạo ban đầu và hàng loạt thay đổi mà một sản phẩm trải qua, từ thiết kế và phát triển cho đến khi ngừng sử dụng hoặc loại bỏ cuối cùng.
Hệ thống PLM tích hợp con người, dữ liệu, quy trình và hệ thống kinh doanh, đồng thời cung cấp xương sống thông tin sản phẩm cho các công ty và doanh nghiệp mở rộng của họ
4) Vì vậy, nếu PLM là một hệ thống, thì việc có một cách tiếp cận hệ thống để thiết kế và triển khai nó trong một công ty có hữu ích không?
Đây là niềm tin cá nhân của tôi. Tôi tin rằng cách tiếp cận hệ thống mạnh mẽ, sử dụng các công cụ mô hình hóa hệ thống có thể đặc biệt hiệu quả.
Niềm tin của tôi dựa trên những lý lẽ sau:
Quản lý độ phức tạp: Phương pháp Kỹ thuật hệ thống giúp quản lý độ phức tạp bằng cách cung cấp một nền tảng để trực quan hóa, chỉ định, tạo và ghi lại các thành phần PLM. Nó tạo điều kiện cho sự hiểu biết về các triển khai PLM phức tạp và thúc đẩy thiết kế hiệu quả của các giải pháp đó. Chức năng này đặc biệt quan trọng trong thiết kế hệ thống PLM, thường bao gồm các quy trình phức tạp liên quan đến nhiều bên liên quan và các giai đoạn vòng đời khác nhau.
Phương pháp tiếp cận toàn diện: Phương pháp Kỹ thuật hệ thống cho phép có cái nhìn toàn diện về cách các hệ thống con tương tác với nhau, giúp dễ dàng hiểu được hành vi tổng thể của hệ thống. Cách tiếp cận này rất cần thiết cho giải pháp PLM, bao gồm nhiều khía cạnh khác nhau trong vòng đời của sản phẩm và yêu cầu hiểu biết toàn diện về cách các khía cạnh này liên quan với nhau.
Cải thiện giao tiếp: Phương pháp Kỹ thuật hệ thống cung cấp một ngôn ngữ chung (ví dụ: SysML) giúp thu hẹp khoảng cách giữa các bên liên quan khác nhau, chẳng hạn như kỹ sư, người quản lý dự án, nhà cung cấp và khách hàng. Trong bối cảnh của PLM, điều này tạo điều kiện giao tiếp và hiểu biết giữa các bộ phận và giúp gắn kết mọi người hướng tới các mục tiêu chung.
Mô hình hóa dữ liệu: Việc sử dụng các sơ đồ lớp UML hoặc SysML giúp tổ chức các đối tượng nghiệp vụ được triển khai, mô hình hóa và phân tích các thuộc tính và thuộc tính của chúng, mối quan hệ giữa các đối tượng này, bản chất của các mối quan hệ của chúng, để phát hiện sự không nhất quán hoặc lỗ hổng. Nó cũng cho phép phân tích khoảng cách giữa mô hình kinh doanh được xác định như vậy và mô hình cốt lõi của giải pháp được triển khai.
Giảm rủi ro: Bằng cách cho phép tạo nguyên mẫu ảo, Kỹ thuật hệ thống giúp xác định và giải quyết sớm các vấn đề tiềm ẩn trong quá trình thiết kế. Khả năng này rất có lợi cho PLM, vì nó làm giảm nguy cơ mắc lỗi tốn kém và làm lại sau này trong vòng đời sản phẩm.
Theo dõi yêu cầu: Kỹ thuật hệ thống hỗ trợ phân tích và theo dõi yêu cầu. Tính năng này đặc biệt hữu ích cho việc thiết kế giải pháp PLM, phải đáp ứng các yêu cầu kinh doanh, chức năng, kỹ thuật… khác nhau.
4) Nhưng, những rủi ro của cách tiếp cận kỹ thuật hệ thống là gì?
Rủi ro chính của cách tiếp cận như vậy là thiết kế một giải pháp không phù hợp với khả năng của phần mềm được triển khai hoặc cách làm việc của khách hàng.
Điều cần thiết là làm việc trong một vòng khép kín và thực hiện phân tích khoảng cách “gần thời gian thực” giữa giải pháp được thiết kế và khả năng của phần mềm cũng như quy trình kinh doanh. Mỗi sự khác biệt được phát hiện phải được giải quyết càng sớm càng tốt, theo 4 cách khác nhau:
- Tham số hóa, tuân thủ các thông lệ tốt nhất về phần mềm
- Cải cách nhu cầu, phù hợp với giải pháp. Điều này thường có thể xảy ra vì một nhu cầu hiếm khi được thể hiện như vậy, mà thường là sự khởi đầu của một trong những giải pháp khả thi.
- Đơn giản hóa “thông báo” . Điều quan trọng là nghiên cứu một giải pháp trong tất cả sự phức tạp của nó. Điều quan trọng nữa là thực hiện các đơn giản hóa để làm cho giải pháp nhẹ hơn, dễ sử dụng hơn, hiệu quả hơn. Đơn giản, những đơn giản hóa này phải được thực hiện một cách hợp lý, để không gây nguy hiểm cho tính toàn vẹn và khả năng mở rộng của giải pháp.
- Tùy chỉnh nặng , đây chắc chắn là giải pháp cuối cùng và tồi tệ nhất để lấp đầy khoảng trống.
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