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

一：物料狀態(tài)管理或生命周期管理

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

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

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

第三個要說的是代碼本身是有版本管理的，也就是說可能還是同一個代碼，但是已經(jīng)是不同的版本，也有人把打樣版本用V01...表示，然后把轉(zhuǎn)正后的版本用V10...等表示，這個和戰(zhàn)斗機編碼規(guī)則一樣?？梢韵胂笠幌拢姹巨k理對應(yīng)到實物流的一定就是批次管理，批次管理對應(yīng)到的就是從實物接收、上架、上線等等過程都是可控的，另一個就是信息系統(tǒng)本身要具備選擇批次的能力，這個也不是不能實現(xiàn)，無非就是增加了計劃系統(tǒng)的關(guān)鍵信息，比如，默認為所有版本可以互換，那就直接采用BOM數(shù)據(jù)就可以了。也可以不互換，那么對每個BOM進行版本管理，計劃系統(tǒng)應(yīng)用時明確當(dāng)前調(diào)用的版本，如果有幾個版本時就要明確計劃系統(tǒng)采用的多少版本，這個無非就是后臺數(shù)據(jù)的維護，從而能夠?qū)崿F(xiàn)版本的管理。這個是困擾很多公司的一個關(guān)鍵問題，影響著的不僅僅是打樣，更多是試產(chǎn)，驗證，進料控制等。

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

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

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

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

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

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

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

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

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

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