江南APP前面的文章中，我们分享了推进供应链改善项目时，在确定项目计划时如何为改善项目匹配关键资源——人力资源。今天我们来分析供应链改善项目的项目计划中另一个部分的内容：如何确定技术方案。确定技术方案的意思，就是确定我们达成项目目标所需要完成的技术工作以及完成的顺序。这个部分包括三项内容：供应链体系的技术方案设计、实施路径设计、配套的数字化方案。

　　在体系化地推进供应链改善时，技术方案的基本框架结构在体系中已经做了一定程度的定义，所以最重要的确定技术方案的工作，就是在适用的技术解决方案框架基础上，根据项目的个性化特点来做适应性调整。

　　很多人认为“适应性设计”就是修修补补、收拾一下边边角角的意思，类似于“微调”的意思。其实完全不是那么回事。

　　“微调”的做法多半是拿个模板去套用，然后稍作调整，而适应性设计，是指根据技术解决方案框架的原理和原则，根据项目特点，设计出最符合项目需求的新的技术方案。这种“适应性设计”，幅度可能大到从表面上完全看不出来于原来的技术解决方案框架有什么相似之处，但是，其后面底层逻辑是相同的。我们来举个例子看看，什么是“适应性设计”。

　　我们遇到的一个企业，需要做计划管理的改善。该企业是为建筑项目提供建筑用的结构材料的，接单生产。他们提供的产品有个特点，技术规格是分几步完成确认的，而且每个项目所用的材料的尺寸、材质、颜色等等，都不同，也就是规格不可穷举。

　　但同时，因为该企业只是为建筑项目提供结构材料（不是全部材料），所以成品的种类是有限的，每类成品里的单个成品，虽然规格各不相同，但都有很多共同特征，用于生产这些成品的设备和物料是非常类似的，该企业的工厂里有着清晰的按工艺路线排布的加工设备，有的产品甚至有从首序到末序的全自动生产线。

　　做过计划管理的人都知道，接单生产有两种最基本的供需匹配技术解决方案。一是对应标准品量产的MTO模式，一种是对应定制化项目管理的ETO模式。MTO模式经过需求解耦点位置调整，还可以演化出MTS和ATO等模式。

　　MTO模式的成品计划是三层结构，顶层的销售运营计划（S&OP计划）对应的规格颗粒度是“产品族”，中间那一层的主生产计划（MPS）和底层的排产计划（PS）对应的规格颗粒度的“产品料号”。主要的资源（产能和物料）计划都是由主生产计划驱动的。

　　而在ETO模式下，完成品或交付物有两层计划，分别项目分解计划（PBS Project Breakdown Structure)和工作分解计划（WBS Work Breakdown Structure），项目资源需求是由WBS驱动的，最后形成资源需求计划（RBS Resource Breakdown Structure）。在项目管理中，因为交付物和所需资源都是定制的，所以基本不使用“料号”的概念。简单说，就是“一次一个样儿”。

　　好了，回顾完基本的技术解决方案架构，我们来看看前述企业的特点：“规格定制且渐进明细”是用ETO方案进行的项目制管理的典型特征。而“设备、材料共用、工序稳定”又是用MTO方案进行标准品量产管理的典型特征。

　　这个企业的特点可以总结为“规模化的半定制”，计划该怎么建？成品计划应该有几层，每层对应何种成品规格颗粒度？各层计划相互之间是什么转换关系？资源计划应该有几种？每种资源计划由成品计划的哪一层驱动？齐套交付如何保证？

　　经过仔细分析和反复推演，最后为该企业设计出了一个非常独特的计划体系技术方案。在成品计划上依旧选择了MTO模式的三层模型，以中间层的MPS驱动资源计划。但MPS需求不是用“成品料号”表达的，而是由项目交付节点（WBS）和每个节点对应的需交付成品表达。但是产能计划和物料计划都和MTO模式基本相同。

　　这些技术方案听起来不是那么直白，有点绕，不过这不是重点，重点是这套技术方案就是有的地方用项目管理的方式，有的地方用标准品批量生产的管理方式。

　　这种方案表面上看起来完全是一个全新的模型，但是其实它只是把客户的作业链条分为了不同的分段，按照每个分段上最明显的特征选择了不同的基本供需匹配模式，并把每个分段平顺连接而已。也就是说，做了个外科手术，成功地把牛头对到了马嘴上。

　　这，就是我们所说的“适应性设计”。这种设计的结果有时候看起来与任何一种经典模式都不搭边，但其实就是经典模式经过与工作场景精确匹配后的裁剪、拼接和转换的结果。MTO、MTS、ATO和ETO，这些经典模式虽然简单，但是它们就像10个阿拉伯数字能够变化出所有的数一样，可以根据企业自己的特殊需求，变化出无数新颖又实用的体系结构。

　　完成了技术方案的设计后，还有个容易被忽略、但是也有相当技术难度的部分，就是对推进技术方案的实施路径的设计。

　　我们都知道，一套技术方案，尤其是会导致全局变革的关于体系结构的技术方案，基本都不能一步到位地全方位推进的，需要考虑团队的自身的客观条件、对技术方案的理解接受程度等因素，分批推进，以降低推进难度、保证推进效果。

　　要分步就首先就需要拆分任务。把引入一个大的体系所需要做的变化，分解成若干独立可交付的小的变化，然后让这些小变化逐个发生。这种拆分成小变化并确定推进小变化的顺序的设计，其难度并不亚于大体系的技术方案设计。这种实施路径的设计，考验的不是技术能力，而是对“变化”的管理能力。

　　打个比方，我们原来过的是田园牧歌般的生活，住在漂亮的小木屋里。但是出于各方面的考虑，我们决定，要迁到大城市里，住进高楼大厦。

　　设计完技术方案，就好像我们已经确定了要住进什么样的高楼大厦里。而实施路径的设计，就相当于我们要想清楚，如何让习惯于小木屋生活模式的人，能够习惯高楼大厦里的生活。

　　我们需要知道，高楼大厦与小木屋的千百个不同里，哪几个或十几个不同，是最让小木屋里成长起来的人最不舒服的。然后，还要想好用什么方法让他们理解并适应这十几个不同，先练习适应哪个、后练习适应哪个。

　　调整供应链管理体系的结构，影响面是非常广的，我们相当于要管理好几百几千人从小木屋到高楼大厦的适应过程。这种对变化的管理能力，就是设计出最有效的实施路径所需要的核心能力。

　　在数字化程度已经成为管理体系的先进程度主要指标之一的时候，各种管理方案的改善，都需要有配套的数字化方案。甚至在设计技术方案的同时，就应该考虑到与数字化方案的对接。

　　现在大家都普遍接受的一种说法是，数字化方案的灵魂，是其所依据的管理方案。很多数字化转型的失败，都不是因为信息系统的技术方案不够好，而是因为它反映的管理方案出了大问题。

　　数字化方案，最重要的就是对真实业务场景的理解和在数字世界里建立映射的过程。而供应链管理在很多方面，已经有相当成熟的管理体系，所以数字化方案，应该是这些管理体系（或经过适应性设计而成的体系）在数字世界里的映射，是不能自由发挥的。

　　所以，要想拥有优质的数字化方案，要想信息系统真正成为管理提升的有力帮手，那数字化方案的设计者，也必须是深刻理解供应链管理体系的人。