從研發與供應鏈協同的操作層來看，涉及以下幾個方面：1）物料生命周期管理，就包括從代碼發放、打樣、承認、小批量、批量管理；2）試產管理，針對不同的層級展開，也有自制與外協管理之分；3）選型；4）獨家管理。

一：物料狀態管理或生命周期管理

不要覺得奇怪，大多數人都會第一反應判斷，認為物料代碼是研發的事情并且認為這個事情和供應鏈之間沒有太多關系。這個觀點是不全部正確的，首先代碼是個技術活，確實要研發承擔主要責任，但這事情又是供應鏈的事情，需要承擔監督和審核作用。因為從不同角度看到的代碼有不同的應用意義。

要說代碼首先就要分臨時碼和正式碼，臨時碼也有叫著流水碼，言外之意就是這個非正式的，只是為了走個程序或者是為了觸發程序，畢竟現在的信息系統都靠代碼驅動。臨時碼的性質是隨機生成的東西，所需要的信息也是非常有限的，更多時候就是為了觸發流程，比如可以采用字母進行區分，至于用A、B、C、D、OTH等都不重要，主要是為了說明這個物料有需求，但是到底是啥，需求方也不能準確說清楚。

第二個要說的就是代碼本身又有打樣的以及正式的，只是用了不同的方式進行管理，比如采用不同的開頭數字、以不同的尾巴標識（帶尾巴）、以屬性管控等等。這樣做的目的是為了減少系統中的正式代碼數量，也為了批量性管理，因為代碼數量就意味著復雜度，意味著太多的管理性要素，從信息流到實物流，尤其是對實物流的影響。1）以不同的數字開頭是比較嚴謹的，數據流也比較清楚的。2）帶尾巴的管理，這個方式也比較明面化。3）通過屬性進行管控的，也就是同一個代碼，從生命周期的每個階段都是一個碼，只是做了大量的屬性維護，這種管理是讓步式管理模式，增加了非常大的供應鏈幅度。從我的角度看，我更希望是用明顯的開頭進行管理，能夠更大程度上做到目視化管理以及批量性處理，并且能夠減少實物流管理上的難度。從操作性來說，研發特別不愿意采用第一種方式，因為這意味著太多的管理性工作。在實際應用中要結合到公司的實際場景進行區分。從嚴肅性來說，這里的代碼本身就比臨時代碼更加嚴謹一些，至少會有關鍵性信息輸入，作為所有工作的觸發點了。

第三個要說的是代碼本身是有版本管理的，也就是說可能還是同一個代碼，但是已經是不同的版本，也有人把打樣版本用V01...表示，然后把轉正后的版本用V10...等表示，這個和戰斗機編碼規則一樣。可以想象一下，版本辦理對應到實物流的一定就是批次管理，批次管理對應到的就是從實物接收、上架、上線等等過程都是可控的，另一個就是信息系統本身要具備選擇批次的能力，這個也不是不能實現，無非就是增加了計劃系統的關鍵信息，比如，默認為所有版本可以互換，那就直接采用BOM數據就可以了。也可以不互換，那么對每個BOM進行版本管理，計劃系統應用時明確當前調用的版本，如果有幾個版本時就要明確計劃系統采用的多少版本，這個無非就是后臺數據的維護，從而能夠實現版本的管理。這個是困擾很多公司的一個關鍵問題，影響著的不僅僅是打樣，更多是試產，驗證，進料控制等。

第四個要說的就是代碼有幾個狀態，這幾個狀態時需要被系統和操作人員引用。這里本質上就是個爬坡和應用的過程，代碼可以用前面說到的幾種方式進行編碼，然后端到端的應用。一般最主要的混亂點，第一個點的混亂是從打樣到小批量，第二個是小批量狀態沒有管理。最大的問題還是在于技術能力本身不充分，很難說得清楚每一個代碼到底達到多少叫著批量和小批量，尤其是面對新興業務場景。如果在每個過程中還有不同的版本進行測試，尤其是涉及系統性產品，可能同時或則不同時調整的物料代碼非常多的情況下，那么代碼狀態時可以想象會有多復雜。如果沒有較好的系統進行管控，這個過程是失控的，整個產品質量是可以想象的。

第五個是一碼一物還是一碼多物，尤其是大批量生產以后到底是那種代碼規則，一般會采用一碼一物的方式，但是為了解決快速系統替代的問題，也可能采用一碼多物的方式。一碼多物帶來的問題是同一客戶可能存在多個版本的物料供給，如果用在系統產品中可能不明顯，但是用在3PP時，就很明顯。要把兩個問題都解決掉的話，一個好的方式就是版本管理。

第六個就是個責任主體的問題，也就是流程的問題，流程無非就是RACI，就是說誰負責解決什么樣的事情。代碼申請到底是從研發使用部門發起還是從采購發起，還是說從器件工程師這個位置發起，其實本身并不重要，如果非要選擇一個中立的位置，我認為器件工程師是最合理的。然后流經采購技術崗位和研發需求部門。為了規范這個動作，每個物料要有對應的要求。

第七個，物料到底要有多少屬性，然后就是在哪個階段到底維護多少信息。這個沒有定論，看類別，看公司的管理水準。一般來說，會有物理屬性、管理屬性、應用性屬性等，其中管理屬性會涉及到多個層面，比如采購屬性、批量性屬性等等，這些屬性最終會被ERP調用。

第八個，物流代碼應用性矩陣，這個還很少見到，我倒是非常熱衷這個事情。就是說某個物料應用到某個產品，可能實用性驗證是通過的，但是用于別的物料就未必。這個事情比較邪門，有時候尤其是共用料的部分，所以有些公司會有基本的測試動作，比如符合性測試、兼容性測試、應用性測試，但是大多數公司不是這樣的，只要進入到合格物料池子，這事就這么執行下去了。建立一個應用性矩陣，對于產品場景會更加清楚，同時也能夠顯性化管理，對業務的推動作用比較大。

第九個，就是代碼編碼，這個就比較簡單了，一般用數字，也有用字母的，還有混合用的，對于小公司，都無所謂，對于大公司還是用數字比較好。這個事情的前提條件是首先要有品類的劃分，這個也是實物流的關鍵依托，否則會出現大面積的混亂管理，尤其是存貨管理。也會導致成本管控沒有依據，這是個致命的事情。

第十個，代碼既然是有生命周期的，那么就會涉及到代碼的禁止性使用的問題，這個是一個過程管理，一般而言都是質量原因；另一個核心的事項就是代碼優化管理。這個事情放在研發協同的其它篇章描述。

從上述10條，我們可以粗略地感受到，代碼又復雜又簡單，做好了舊代碼看起來很復雜而管理很簡單，從而能夠做到化繁為簡的效果。

如何落地，這個事情應該沒有標準答案，但是總體上可以拿出一些具體的數據出來，這些數據可以從影響端的東西開始，比如品類代碼在選型中的差別、成本差別、損差、質量標準等。然后是和公司高層就這個事情達成高度一致，也不用責備誰，就是承認這是一個現實，如果是空降領導這事就宜早不宜遲。建立規則到平穩應用規則，周期不會少于半年時間，這個過程就需要很大的耐性。

代碼生命周期管理這個事情通常是所有業務混亂的最根本性因素，也是采購端第一個需要解決的、具體落地的事情，屬于吃力不討好但卻利在千秋的事情。難度很大，但卻是0-1過程中最需要解決的事情。我們吃過虧，也為此有過很多爭論，有“流血”。成熟的企業已經沒有這個問題，好好珍惜前輩為此留下的基業，珍惜你的平臺。不成熟的企業，請老板善待這些為了公司真正的基業而付出努力的人，因為絕對理性是不存在的。