為了生產智能、互聯的產品，工程團隊必須采取系統方法，來管理整個產品生命周期中的信息和流程。問題是，大多數工程師都局限在兩個學科中的一個——系統工程(SE)或產品生命周期管理(PLM)。

雖然系統工程和產品生命周期管理都可以管理復雜的產品，但也有明顯的差異。這兩個歷史悠久的學科如果結合起來，就會創造出生產下一代復雜產品所需的方法。然而，重新規劃工程組織如何管理產品開發并不是一件容易的事。

實現系統級的方法

如今的產品，多個系統相互嵌套，同一個設計中可能包含電氣、機械和軟件等多個層次。為了管理相互依賴的多個學科，工程團隊必須使用系統級的方法。系統工程和PLM作為系統級學科，具有相對優勢——就像同一枚硬幣的兩面，目標是按時、在預算內(或低于預算)，交付優質產品。每個學科如何實現這個目標各不相同，但理解這些至關重要。

系統工程的起源，最早可追溯到用筆和打字機在紙上設計的時代。它始于航空航天和國防工業，企業花費數月甚至數年的時間，開發出一種滿足客戶需求的產品。無論是過去還是現在，這類客戶仍然主要是政府機構，需要精確地滿足客戶要求。系統工程師的任務是獲取這些要求，以及在生命周期中其它利益相關者的需求，并將其轉換為系統模型，以指導開發最終產品或系統所包含的軟件或硬件。

另一方面，PLM在生命周期的后期出現，著力于物理設計、計算機輔助設計(CAD)模型和物料清單(BOM)上。PLM的基本元件是零件、子組件或裝配結構。起初它們主要由系統工程師來定義。

盡管這兩種方法都使用相同的信息，并且相互補充，但是它們的起源和重點各不相同。局限在系統工程方法中的工程領域的領導，可能并不愿意為PLM費心；同樣，在PLM工作的機械工程團隊的領導，也不想把一天的時間都花在管理需求上。他們都選擇集成方法的原因是這個行業正在發生變化。為了跟上競爭的需要，這兩個團隊也需要這樣做。

工程組織的協作

計算機程序員MelvinConway在1968年就指出，系統設計的結構必定復制設計該系統的組織的溝通結構。這一理論后來被稱為“康威定律”，意味著產品將反映構建產品工程團隊的組織結構。如果系統工程和PLM組單獨工作，這可能會出問題。

當系統工程和PLM團隊獨立工作時出現的挑戰源于文化和技術的不一致。他們已經規范了他們的做事方式，并期望對方適應并效仿。除了彼此獨立之外，其它部門甚至同一公司的工程職能部門(例如軟件團隊)，也會因為自說自話導致溝通困難。獨立的信息系統也使這一過程變得更加困難。

系統工程和PLM團隊正在開發相同的產品，但由于所用的開發工具以及數據處在不同的數據庫，共享信息并不容易。因此，在生命周期中，團隊和下游之間的數據處理和切換過程，非常容易出錯。康威認為，這些錯誤將出現在最終產品中。一個完全集成的系統概念——在產品生命周期中，每條產品信息都是相互連接和一致的——就是個神話。然而，這并不意味著不可能實現整體產品的開發。

面向未來的工程組織

面向未來的工程組織，聽起來可能像是一項艱巨的任務。尤其是在今天，團隊正忙于應對日益復雜的產品、法規和激烈的全球競爭。實現這一愿景的第一步，是創建系統工程和PLM合作的環境。要做到這一點，工程領導應該考慮：

聯合系統工程和PLM團隊——在概述了他們的共同目標和集成開發方法的好處后，整合系統工程和PLM團隊將取決于跨學科的溝通。如果組織中還不存在類似的溝通論壇，那就創建一個。如果已經存在，那就鼓勵人們使用。

為這兩個學科創建包容性流程——擺脫"自我為中心"的信仰體系，設計新的流程，將每個學科的各個部分連接起來。通過保留一些有利于其它團隊的最佳實踐來滿足每個團隊的需求。

將信息連接并集成到工程中的單一可信來源中——系統級設計需要系統級平臺。多供應商解決方案將具有管理開發過程每個階段所需的廣度。超越文檔、PDF和電子表格的界限非常重要。

規劃變革——保持靈活性，選擇具有開放應用程序接口（API）和靈活架構的工具，使組織能夠輕松適應變化。在當今的數字時代，今日之最佳實踐，未必使用于明日。

咨詢外部合作方——集成方法還需要考慮客戶、供應商和工程過程中其它參與者的需求。聯合供應鏈上下游合作方召開會議，并利用來自現場的反饋來改進新流程。

將系統工程和PLM的最佳技術結合起來，將為持續改進和數字化轉型奠定基礎。開發顛覆性產品和系統需要采用顛覆性方法，這需要正確的變更管理流程和技術。

聲明：本文為轉載類文章，如涉及版權問題，請及時聯系我們刪除（QQ:2737591964），不便之處，敬請諒解！