PLM已經是一個廣為接受的概念。從字面意思可以看出,PLM系統最核心的任務是進行“產品生命周期的管理”。在PLM系統中,零部件也有生命周期,反映零部件的階段和狀態。而企業實施PLM系統過程中的一個主要任務,就是定義零部件的生命周期構成及演進規則。
過短的零部件生命周期管理
我曾參與過一些公司PLM系統實施,發現方案中零部件所謂的“生命周期”往往是指零部件的“設計周期”;零部件的發放實際指的是“設計完成”,而非投入生產。
圖1 過短的生命周期圖
如上圖是某公司PLM系統中定義的零部件生命周期圖。當零件創建出來時即處于“創建”階段,這時工程師對零件進行各方面的詳細設計。一旦完成,工程師將零件的生命周期狀態提升到“審核”,這時啟動一個審核流程; 如果審核者發現設計有誤,則駁回給工程師,工程師根據審核意見進行修改,然后再提交,如此往復。如果審核通過,則零件生命周期狀態提升到“批準”階段,同時觸發一個批準流程。批準流程的簽審過程與“審核”一樣,只是簽審人不同。如果批準通過,則零件生命周期提升到“發放”,零件被凍結。若需要修改,則需要將零件修訂一個新版本,然后在新版本上進行修改。
上述整個過程都發生在研究部門內部,工藝和制造部門則不參與。當零件被發放后,工藝和制造部門才在此基礎上展開工作。如果工藝或制造部門在后面發現了問題,他們會通知研發部門,于是工程師將零件修訂一個新版本,然后根據下游或現場反饋的情況在新版本上進行修改,修改完成后再次進行上述的簽審流程,然后發放一個新版本,完成變更。
按照這個模式,零件的一個生命周期實際上指零件在研發部門的一段生命期,如果零件通過了研發部門的審核,即代表生命周期走到了最終點。當下游部門提出零件有缺陷時,零件需要“重生”一次(修訂一個新版本),然后經歷一個新的生命周期。
我們來看一下一個零件的一般開發過程。一個零件從概念階段到批量生產,一般要經歷如下階段:
圖2 零部件的開發過程
可以看出,零件設計階段只占全部生命期的一半,后面還有大量的驗證工作需要進行。而研究表明,產品80%的修改是在制造階段以后完成的。從這個角度看,設計階段的完成實際連整個生命期的一半都不到。這個時候宣布零件“發放”實際上不合適。就如同一個大學生剛完成本科學業就宣布他已經成才一樣。
這種情況的發生并非偶然。現在很多制造企業的組織結構仍然是行政式的,研發部門負責產品研發,制造部門負責試制生產。 工作流程也一般是串行的。研發部門將設計簽審后的圖紙交到下游部門試制生產,出現問題再向上游反饋,而在零件設計階段他們參與得很少。而PLM系統的實施則往往從研發部門開始,然后再延伸到制造部門。有的甚至只局限在研發部門內部。這樣在系統部署之初,對零件的生命周期的定義就只定義到設計階段,而一般不會從整個過程的角度去定義。同時,一些企業“甩過墻”式的設計習慣也加強了這種情況。所謂“甩過墻”的設計是指“我這個部門完成我的工作后就把結果甩給隔壁的部門,然后沒我的事情了”。
零部件生命周期過短的影響
無論這種情況是如何產生的,帶來的影響卻是相同的——零件實際上沒有完整的生命周期。零件在設計階段被"發放"后, 下游部門提交的變更只能在新版本上進行,這就扭曲了版本本身的作用。
在PLM系統中,版本(revision)一般由大版本(version)和小版本(iteration)構成。小版本標記一次修改,大版本標記一次發放。這里的發放是指零件已經完成設計驗證并投入生產。從標記修改的角度看,版本可理解為:小版本標記投入生產之前的修改,大版本標記投入生產之后的修改。由于生產前的驗證和準備投入了大量的時間和成本,因此對零件在生產之前和生產之后的變更處理是不同的。
在零件投入生產之前,模具尚未開模,采購訂單尚未下發,大量成本尚未發生。這時零產品處于設計或驗證階段,目標之一就是盡可能地發現和消除零件的缺陷,使零件具備高質量。因此這時發生的修改應該是即時生效的。
而零件一旦投入生產,則大量成本已經發生,對修改的處理變的謹慎。 并且投入生產的零件一般是經過驗證的,這時發現的問題往往是改進性質的。因此修改一般不會即時生效,而是有可能等到下一款產品才實現,或等現有供貨耗完后才使用新設計---當然,也不排除一些致命缺陷需要及時修復,而這在生產后一般要少得多。
因此,二者處理的主要問題一個是糾錯型,一個是改進型。最直接的不同就是修改是否要即時生效。
在一般的PLM系統中,零件在未發放之前的修改只增加小版本,并且新的小版本會即時生效,即父級會馬上自動引用最新小版本;而大版本的增加一般不會即時生效。一般是當父級未被發放時,新版本的子級發放后父級會自動引用新版本:如果父級已發放,則新版本的子級發放后父級不會自動引用新版本。如果要引用,則需要將父級修訂一個版本,然后再發放新版本的子級。 這與產品投諸生產后的改進是一致的。如下圖:
圖3 零部件版本管理
但當零部件的生命周期僅代表其設計周期時, 就打破了上面的規則。
試想,當某一部件設計完成, 研發部門將其及子項悉數“發放”。而后下游部門發現部件或子項存在問題,并提交給研發部門修改。這時工程師需要將部件修訂一個新版本然后進行修改。這意味著之前 “發放”的版本實際并未進行生產,這就扭曲了“發放”的本意。
不僅如此,若需要修改的是部件的子項(實際上大部分情況都是修改子項),那么新版本的子項發放后該部件不會自動引用新版本。這樣就必須修訂該部件。如果部件有父級,則需要依次往上修訂。這樣一次修改就會產生大量的修訂,勢必使變更效率變慢。如果不想層層往上修訂,則必須把系統開發成“即使父級處于發放狀態,子項修訂新版本后,父項也會自動引用新版本子項”。這樣做產生的問題是:部件永遠處在最新狀態下,這樣失去了對歷史狀態的追溯功能。
因此,無論從那個角度考慮,一旦零部件走出了設計階段,這個生命周期圖就無法在準確描述其生命階段和狀態。
建議
上述問題的產生,是由于零部件的生命周期圖只描述到設計階段完成,而零部件后面的演進則超出了這個階段。即用較短的生命周期圖描述較長的生命期。要解決這個問題,需要將產品的生命期延伸到驗證和制造階段。產品設計階段的完成只能定義為“設計凍結”,而不能定為“發放”。真正的“發放”定義在產品驗證完成后,批量生產之前。如下圖:
圖4 零部件生命周期管理
上圖中,在“設計凍結”之前,零部件處于設計階段,研發部門工程師可以對零部件進行修改;所有的修改完成后,便可提交審核,并最終進入“設計凍結”。零部件提升到"設計凍結"需要做一個校驗:只有當所有子項被提升到"設計凍結"后,父項才能提升到"設計凍結"。 在該階段,研發部門部門工程師無權再進行修改。
“設計凍結”表示零部件設計階段的完成,但尚未“發放”。當下游部門發現問題時,便提交給研發部門。研發部門工程師接到修改意見后,可將零部件降級到"創建"狀態進行修改。修改完成后零部件增加一個小版本,其父級也自動引用新的小版本。然后零件被提交簽審,簽審通過后,零件再次提升到“設計凍結”,系統收回工程師的修改權限。 所有對反饋問題的處理都遵循這個模式。當驗證階段反饋的所有問題都被妥善處理后,產品便可以提交發放。同“設計凍結”一樣, 產品發放時也要遵循一個原則:只有當所有的子項發布后, 父項才能被發布。
一旦產品進入“發放”階段,系統便將其凍結,作為歷史查詢記錄。用戶若要修改,則需要將其修訂新的大版本,然后在新的版本上進行修改操作。 當然,新的版本發放后,其父級不會自動引用。
對于一些特殊情況,即在生產階段發現的一些嚴重缺陷因而不得不進行的修改。這時需要提出修改申請,然后由具有管理員權限的賬戶執行對發布后的修改。 這種情況必須嚴格控制。因為生產之后的修改必然伴隨這高昂的成本。
表面上看,圖4與圖1中的生命周期只增加了兩個生命周期階段,但實際上卻有很大的不同。在圖1的生命周期中,設計完成即表示產品“發放”,產品驗證和批量生產前的階段被排除在零部件生命周期之外;而這個生命周期圖則將產品設計完成后,批量生產前的階段也囊括到產品生命周期內,產品只有等全部驗證通過后才被認為能夠“發放”,因此是將設計和工藝制造視為一個流程內。
現在,咨詢機構和廠商更愿意把PLM管理的生命周期延伸到銷售和售后階段,從這個角度看,要實現零部件的全生命周期管理任重而道遠!這里面不僅僅只是增加若干個生命周期階段的問題,而是這些階段之間是如何演進及需要遵循哪些基本規則。
核心關注:拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用,蘊涵了豐富的ERP管理思想,集成了ERP軟件業務管理理念,功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理,全面涵蓋了企業關注ERP管理系統的核心領域,是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處:拓步ERP資訊網http://www.guhuozai8.cn/
本文標題:談零部件的生命周期管理