供应链如何做研发协同（上）- 物料生命周期管理

从研发与供应链协同的操作层来看，涉及以下几个方面：1）物料生命周期管理，就包括从代码发放、打样、承认、小批量、批量管理；2）试产管理，针对不同的层级展开，也有自制与外协管理之分；3）选型；4）独家管理。

一：物料状态管理或生命周期管理

不要觉得奇怪，大多数人都会第一反应判断，认为物料代码是研发的事情并且认为这个事情和供应链之间没有太多关系。这个观点是不全部正确的，首先代码是个技术活，确实要研发承担主要责任，但这事情又是供应链的事情，需要承担监督和审核作用。因为从不同角度看到的代码有不同的应用意义。

要说代码首先就要分临时码和正式码，临时码也有叫着流水码，言外之意就是这个非正式的，只是为了走个程序或者是为了触发程序，毕竟现在的信息系统都靠代码驱动。临时码的性质是随机生成的东西，所需要的信息也是非常有限的，更多时候就是为了触发流程，比如可以采用字母进行区分，至于用A、B、C、D、OTH等都不重要，主要是为了说明这个物料有需求，但是到底是啥，需求方也不能准确说清楚。

第二个要说的就是代码本身又有打样的以及正式的，只是用了不同的方式进行管理，比如采用不同的开头数字、以不同的尾巴标识（带尾巴）、以属性管控等等。这样做的目的是为了减少系统中的正式代码数量，也为了批量性管理，因为代码数量就意味着复杂度，意味着太多的管理性要素，从信息流到实物流，尤其是对实物流的影响。1）以不同的数字开头是比较严谨的，数据流也比较清楚的。2）带尾巴的管理，这个方式也比较明面化。3）通过属性进行管控的，也就是同一个代码，从生命周期的每个阶段都是一个码，只是做了大量的属性维护，这种管理是让步式管理模式，增加了非常大的供应链幅度。从我的角度看，我更希望是用明显的开头进行管理，能够更大程度上做到目视化管理以及批量性处理，并且能够减少实物流管理上的难度。从操作性来说，研发特别不愿意采用第一种方式，因为这意味着太多的管理性工作。在实际应用中要结合到公司的实际场景进行区分。从严肃性来说，这里的代码本身就比临时代码更加严谨一些，至少会有关键性信息输入，作为所有工作的触发点了。

第三个要说的是代码本身是有版本管理的，也就是说可能还是同一个代码，但是已经是不同的版本，也有人把打样版本用V01...表示，然后把转正后的版本用V10...等表示，这个和战斗机编码规则一样。可以想象一下，版本办理对应到实物流的一定就是批次管理，批次管理对应到的就是从实物接收、上架、上线等等过程都是可控的，另一个就是信息系统本身要具备选择批次的能力，这个也不是不能实现，无非就是增加了计划系统的关键信息，比如，默认为所有版本可以互换，那就直接采用BOM数据就可以了。也可以不互换，那么对每个BOM进行版本管理，计划系统应用时明确当前调用的版本，如果有几个版本时就要明确计划系统采用的多少版本，这个无非就是后台数据的维护，从而能够实现版本的管理。这个是困扰很多公司的一个关键问题，影响着的不仅仅是打样，更多是试产，验证，进料控制等。

第四个要说的就是代码有几个状态，这几个状态时需要被系统和操作人员引用。这里本质上就是个爬坡和应用的过程，代码可以用前面说到的几种方式进行编码，然后端到端的应用。一般最主要的混乱点，第一个点的混乱是从打样到小批量，第二个是小批量状态没有管理。最大的问题还是在于技术能力本身不充分，很难说得清楚每一个代码到底达到多少叫着批量和小批量，尤其是面对新兴业务场景。如果在每个过程中还有不同的版本进行测试，尤其是涉及系统性产品，可能同时或则不同时调整的物料代码非常多的情况下，那么代码状态时可以想象会有多复杂。如果没有较好的系统进行管控，这个过程是失控的，整个产品质量是可以想象的。

第五个是一码一物还是一码多物，尤其是大批量生产以后到底是那种代码规则，一般会采用一码一物的方式，但是为了解决快速系统替代的问题，也可能采用一码多物的方式。一码多物带来的问题是同一客户可能存在多个版本的物料供给，如果用在系统产品中可能不明显，但是用在3PP时，就很明显。要把两个问题都解决掉的话，一个好的方式就是版本管理。

第六个就是个责任主体的问题，也就是流程的问题，流程无非就是RACI，就是说谁负责解决什么样的事情。代码申请到底是从研发使用部门发起还是从采购发起，还是说从器件工程师这个位置发起，其实本身并不重要，如果非要选择一个中立的位置，我认为器件工程师是最合理的。然后流经采购技术岗位和研发需求部门。为了规范这个动作，每个物料要有对应的要求。

第七个，物料到底要有多少属性，然后就是在哪个阶段到底维护多少信息。这个没有定论，看类别，看公司的管理水准。一般来说，会有物理属性、管理属性、应用性属性等，其中管理属性会涉及到多个层面，比如采购属性、批量性属性等等，这些属性最终会被ERP调用。

第八个，物流代码应用性矩阵，这个还很少见到，我倒是非常热衷这个事情。就是说某个物料应用到某个产品，可能实用性验证是通过的，但是用于别的物料就未必。这个事情比较邪门，有时候尤其是共用料的部分，所以有些公司会有基本的测试动作，比如符合性测试、兼容性测试、应用性测试，但是大多数公司不是这样的，只要进入到合格物料池子，这事就这么执行下去了。建立一个应用性矩阵，对于产品场景会更加清楚，同时也能够显性化管理，对业务的推动作用比较大。

第九个，就是代码编码，这个就比较简单了，一般用数字，也有用字母的，还有混合用的，对于小公司，都无所谓，对于大公司还是用数字比较好。这个事情的前提条件是首先要有品类的划分，这个也是实物流的关键依托，否则会出现大面积的混乱管理，尤其是存货管理。也会导致成本管控没有依据，这是个致命的事情。

第十个，代码既然是有生命周期的，那么就会涉及到代码的禁止性使用的问题，这个是一个过程管理，一般而言都是质量原因；另一个核心的事项就是代码优化管理。这个事情放在研发协同的其它篇章描述。

从上述10条，我们可以粗略地感受到，代码又复杂又简单，做好了旧代码看起来很复杂而管理很简单，从而能够做到化繁为简的效果。

如何落地，这个事情应该没有标准答案，但是总体上可以拿出一些具体的数据出来，这些数据可以从影响端的东西开始，比如品类代码在选型中的差别、成本差别、损差、质量标准等。然后是和公司高层就这个事情达成高度一致，也不用责备谁，就是承认这是一个现实，如果是空降领导这事就宜早不宜迟。建立规则到平稳应用规则，周期不会少于半年时间，这个过程就需要很大的耐性。

代码生命周期管理这个事情通常是所有业务混乱的最根本性因素，也是采购端第一个需要解决的、具体落地的事情，属于吃力不讨好但却利在千秋的事情。难度很大，但却是0-1过程中最需要解决的事情。我们吃过亏，也为此有过很多争论，有“流血”。成熟的企业已经没有这个问题，好好珍惜前辈为此留下的基业，珍惜你的平台。不成熟的企业，请老板善待这些为了公司真正的基业而付出努力的人，因为绝对理性是不存在的。