Teamcenter中的BOM模塊中的版本規則在實際項目中起到什麼作用？

01-21

作為一個剛入職的新手，我想問PLM大神們一個問題：Teamcenter中的BOM模塊中的版本規則在實際生產環境中起到什麼作用，基本功能我都明白，什麼最新發布，最新工作之類的，但是他僅僅是用來控制顯示Item版本的么？還有，再問一個小問題：Teamcenter的OOTB的渲染xml文件在哪裡能找到？？還是說OOTB的渲染已經應用了，所以不存在了？

一組前提性的基本常識：

1 Item 用來指代實際業務場景中需要管理的零部件；

2 一個 Item 擁有至少一個 Revision；

3 這些 Revision 所包含的數據互不相同；

4 這些 Revision 指代的都是同一種零部件，只不過指代的是該種零部件的不同版本；

接下來進入正題。

BOM有精確和非精確之分。一個部件的非精確BOM僅僅定義了該部件使用了哪些零件（或者子部件，但為簡便計，此處均視作零件，下同），但並沒有定義這些零件各自都是哪個版本被用於該部件。換言之，非精確BOM是一個「活」的產品結構，精確BOM是一個「死」的產品結構。問題就在這個「活」字。既然產品結構是「活」的，那就意味著產品結構還沒有定義完全，產品結構的信息是有歧義的。顯然，若僅如此是不夠的。為此，非精確BOM需要有一個配套的版本規則，來共同說明這個部件到底是由哪些零件構成，以及由這些零件各自的哪個版本構成。

例如，甲是一個部件，工程師在設計它的某一個版本（甲/X）時，定義它由乙和丙兩個零件構成。那麼，甲/X的產品結構（非精確）可以用簡單等式表達為：甲/X=乙+丙。

然而，乙和丙各自都有若干個版本（乙/A、乙/B、乙/C…… 丙/A、丙/B、丙/C……）。那麼甲/X到底是什麼樣子的呢？是乙/A+丙/A嗎？還是乙/A+丙/B？抑或是其他的組合？版本規則就是回答這個問題的。

版本規則（Revision Rule）是由用戶設置的、用於確定產品結構中的每一個 Item 在特定時間具體選用（或著說「配置」）其哪一個 Revision 的一組參數。每一種版本規則是由若干個規則條目構成的。

從題主的描述來看，他對規則條目的類型以及每種類型規則條目的參數的含義是清楚的，對版本規則發揮作用的機制也是清楚的。看來，問題在於：為什麼要人為地弄一個「非精確BOM」這個概念出來？弄出來又不能直接用，還得再整一個版本規則來配合使用，這豈不是故弄玄虛嗎？為什麼不直接用精確BOM就好了？非精確BOM到底有什麼業務價值？

其實，原因很簡單：設計方法需要這麼做。

產品的設計不是一蹴而就的，是有一個過程的。我們在設計一個產品時，不會一下子就把產品的所有細節，包括用於構成產品的所有零件的所有細節都全部想清楚。我們往往在設計的早期階段，頭腦中只有一個粗線條的產品概念。假設，我們的任務是設計一款可以在微波爐中加熱食物的塑料食盒。一開始，我們能夠想到的僅僅只是：這個食盒由盒體與盒蓋兩部分組成。至於這兩個零件的細節應該是怎樣的，當時的我們是回答不了的。

這些細節包括：

這兩個零件應該是方的還是圓的？

長寬或直徑尺寸應該是多少？高度應該是多少？厚度又應該是多少？

用什麼材質？

是否需要把手和提手？把手和提手應該是什麼形狀？尺寸是多少？

兩者的介面應該是怎樣的？是需要能夠扣緊在一起的還是僅僅只需要盒蓋可以掩蓋住盒體就好？

……

當這些細節都還不確定的時候，我們也還是要將我們在那個時刻的設計方案（即「這個食盒由盒體與盒蓋兩部分組成」）表達出來。那麼，怎麼表達呢？顯然，食盒/A=盒體+盒蓋。你看，這就是一個非精確BOM。也許，我們最初設想的盒體的厚度是1mm（這就是盒體/A），但後來工藝部門反映這個厚度不合理，而設計部門將厚度值修改為1.8mm（這就有了盒體/B）。1.8mm的厚度就合理嗎？這個厚度的盒體，其加熱效率好不好呢？也許在進行了驗證之後，這個厚度值還需要再次修改（也許還會出現一個盒體/C）。零件的設計方案還在變化的時候，零件的版本當然就可能層出不窮。怎麼表達食盒的結構呢？有兩種方案：

方案一，用精確BOM，當零件出現了新版本後，也要為部件創建一個新版本，讓部件的新版本使用零件的新版本。這樣，就會出現這種情況。

第1天：食盒/A=盒體/A+盒蓋/A

第2天：食盒/B=盒體/B+盒蓋/A

第3天：食盒/C=盒體/B+盒蓋/B

第4天：食盒/D=盒體/B+盒蓋/C

……

第n天：食盒/X=盒體/Y+盒蓋/Z

方案二，用非精確BOM，部件的產品結構保持不變，關於「零件各自的哪個版本參與部件的構成」的信息，與部件的產品結構信息分開，不綁在一起。這樣，

第1～n天：食盒/A=盒體+盒蓋

顯然，在這裡方案一併不好，因為這需要隨時對部件的產品結構進行維護，工作量大。要知道，產品結構往往是資深技術人員（甚至是技術領導）確定的。你一個剛畢業的工程師自己沒有想清楚導致三天兩頭地改尺寸，難道還要領導跟著你不停地改產品結構嗎？你們是一個人設計一個零件，要都這麼干，領導還干不幹其他活了？

說到這裡，應該能夠體會到非精確BOM的價值了吧。

當然，這個舉例很誇張，很極端。例如，零件僅僅修改一個尺寸，版本號（Revision ID）往往是不變化的，變化的只是版序號（不是盒體/A→盒體/B，而是盒體/A.1→盒體/A.2）。但唯有誇張和極端，才便於理解概念的意義。理解概念的意義才是重點。假如技術管理部門規定的零部件狀態包括「Working」、「Validation」、「Approved」、「Released」四種，那麼請想像一下這樣一個場景：

盒體/A已經發布了，處於 Released 狀態，但後來根據市場反饋決定對盒體進行變更。於是有了三個新方案：盒體/B、盒體/C與盒體/D。其中，盒體/B通過了驗證，也被批准了，處於「Approved」狀態；盒體/C同樣也通過驗證，但還沒有召開評審會，因而尚未被批准，處於「Validation」狀態；盒體/D還沒有來得及通過驗證，尚處於「Working」狀態。

在這種場景下，如果我希望知道「截止到目前，用已經具備 Approved 狀態的零件版本（若有多個版本都具有該狀態，以最後批准的版本為準）所構成的食盒是什麼樣子 」，那麼顯然就應該用非精確BOM並配合以包含有狀態條目和最新條目的版本規則，是最便利的。

在這種場景下，如果我希望知道「截止歷史上的某一天，用當時已經具備 Approved 或 Validation 狀態的零件版本（有 Approved 狀態的版本優先；若無 Approved 狀態，則有 Validation 狀態的版本也行；以獲取狀態時間最晚的版本為準）所構成的食盒是什麼樣子」，那麼顯然就應該用非精確BOM並配合以包含有狀態條目、時間條目和最新條目的版本規則，是最便利的。

好了，相信把這個問題基本說清楚了吧，儘管有些繞口（沒辦法，事情原本就有這麼複雜）。

最後，指出題主在問題說明中的一處值得注意的用詞：他僅僅是用來控制顯示Item版本的么？版本規則不是用來控制顯示什麼版本的，而是用來控制篩選出（或者說「配置出」）什麼版本的。僅僅控制顯示，的確沒有什麼業務意義。控制配置什麼版本，從而配合非精確BOM，才有意義。

關於互換性，如果判斷出來因為子件的變化而導致父件的互換性出了問題，是不是要求父件更換一個新的號碼呢？