以下步骤体现一个大致的思考框架，在实操中次序并不是绝对的，更多时候各环节间是迭代式推进的，相互参照、相互假设、相互验证、共同完善。

1.​ 确定供应链的基本业务流

基于企业所在产业链特征、企业商业模式选择、与供应链相关企业战略，以及企业现状运作方式可以先绘制出企业供应链的基本业务流路径。对于制造型企业而言，销售管理、计划、采购、制造、物流这几大活动环节基本是可以确定的，但每个活动环节的组织与活动结构、各环节的厚度是不尽相同的。比如B2C业务形态企业的供应链的销售端的层次因渠道的存在会多一些，而B2B业务形态的供应链的销售端直接对接最终企业客户，层次会少一些。进而要依据产业分析、商业模式与战略分析、基本供需匹配模式选择识别出粗线条的路径结构，以及各大环节的战略性要求，以备下一个步骤使用。比如华为通信设备制造业务供应链的基本路径中存在两条主线，即按预测备料、按订单制造。同时，企业对各大环节的特殊性要求也要在基本业务流图上标识出来。比如生产大宗货物企业的承运管理比较复杂，是供应链管理的要点，要标识出来；相对而言，生产小型电子产品的企业承运管理要简单很多，不必特别强调。

业务流的实质是活动流，里面可能既包含信息流，也包含物流、资金流，这不同于把“三流”分离对待的方式，在这个阶段确定活动流是第一位的，信息流、物流、资金流应该从属于活动流。

对于生产多元化产品的集团型企业，会涉及多条供应链或供应链多分支的情况，这要依据公司的战略选择分别绘制出来。

商业企业的基本业务流与制造业有较大差异，其物流环节相对复杂，但确定供应链基本业务流的思路大体是相同的。

2.​ 各大环节的活动分解

对制造型企业而言，我们大体可以按照销售管理、计划、采购、制造（质量与工程服务于制造，不算独立的环节）、物流几个大环节展开进一步的业务流程与组织设计。虽然一般情况下每个环节都有一个主责部门，但使用环节这一概念是更合适的，这样可以避免先入为主。另外，我们假设每个主责部门都是一个模糊的部门概念，尚没有展开部门内部的详细分工，即此时使用的是笼统的销售部、计划部、采购部、制造部、仓储与物流部。

因为使用了“环节”而非“部门”概念，所以会相应地使用“活动”而非“职能”这一概念，“职能”是相对于部门而言的，“活动”则是相对于环节而言的，也就是这个环节要做的事。下面以销售与计划两大环节为例，粗略阐述如何确定该环节应该包括的活动，进而这些活动再对应到相关的部门职能。

从供应链视角看，销售管理（指销售后端管理）环节的核心活动是收集和接受客户需求，进行必要的加工后再传递给计划部门。当设计者把自己置入现实的业务场景，会发现围绕核心活动还有必要的其他活动，比如产品报价、客户信用管理、回款管理、跟单等。

每个活动都会对应着一个或一套流程，首先要弄清楚这个活动的价值所在，它不会无缘无故存在的，比如客户信用管理是为了防范公司的回款风险，而报价则是企业交易必需的一个步骤。其次，先定义这个活动的关键步骤与共同执行部门（多数情况下并不是一个部门就可以完全覆盖一个完整的功能）。比如报价活动可以分为核价与定价两部分。定价一般是销售部门依据市场情况、销售策略等确定（对供应链而言这个不是重点）；核价则是一个成本核算过程，要把组成产品成本的各种成本逐一核算，最后再汇总为一个总成本。一款新产品的核价可能涉及研发部门、工程部门、采购部门、财务部门等，这样我们就知道了这些部门应该有这些职责。订单接受与评审功能则是需要下游部门的介入，订单的实质是对客户的一个承诺，计划部门要依据产能情况评估能否满足客户的需求，采购部门可能需要就一些供应瓶颈部件做出评估，而对于第一次投产的新产品，研发部门可能需要介入评估，我们由此可以知道这些部门应该有这些职责。

也就是说，各个部门的职责范围是通过活动分析得来的。每个活动的关键构成步骤与相关参与部门，就构成了流程的核心要素。以此类推，我们用这个方法就可以得到销售这个环节的大部分业务流程清单、每个业务流程的参与部门及所扮演的角色。

在计划环节，我们知道计划部门需要把订单集中起来，依据产能条件排出生产的主计划，进而再把生产主计划进行分解，排出采购计划与加工计划。在安排生产主计划时，有可能遇到订单多而产能不足的情况，这时不能完全满足所有的订单要求，于是就需要有个优先级排序。如何排序呢？可能需要按照客户的重要性、订单本身的重要性，如果完全拍脑袋确定是很难达成共识的，比较好的做法是事先对客户做一个重要性的分级，对具有不同特征的订单做一个重要性的分级，这些工作需要最靠近客户、最了解市场的销售部门来评估，所以可能需要让上游销售环节增加一套客户分级、订单分级管理流程。这样我们就知道销售部门还应该有这么一个职责。

安排采购计划时，计划部门必须要先知道不同物料的标准采购周期，标准采购周期要由采购部门给出，所以就引申出采购部门的一个具体职责，即必须给每种物料确定一个标准的采购周期，这个动作要在采购流程中明确体现出来。

计划环节的其他活动都可以用类似的方式进行逐一分析，这样就可以得出计划领域的一条流程清单，以及在其他领域需要设定以支持计划流程的业务流程清单、每个业务流程的参与部门及所扮演的角色。

逐一把供应链的各大环节的各种活动都用这样的方法分析完毕后，就会得出供应链范畴内的一整套业务流程清单、每个业务流程的参与部门及所扮演的角色。按照部门把各自的职责进行汇总后，就基本确定了每个部门的职责范围，这个职责范围就成为每个部门进行更细致组织与岗位分工的一个基本依据，此时就可以初步列出一套比较像样的组织结构了。在这个步骤中，大致的流程清单、关键流程结构、与流程配套的组织结构基本上就形成了。

小贴士：

这套方法也可以印证笔者在《管理：以规则驾驭人性》中提出的“组织即流程，流程即组织”观点。

3.​ 提炼出可异步化的流程

所谓可异步化的流程，就是从原本是以一条龙方式完成的整个工作中，提取出一部分，提前把这部分的工作做好。而这部分成果可以被剩余部分的其他工作直接引用，从而缩短总工作周期。很多时候，提前做好的这部分工作的成果还可以被重复使用、共享使用。异步化是一种运筹学意义上典型方法，能优化系统的整体结构、提高系统效率。

供应链领域可实施异步化的活动非常多，这些异步化的流程设置能提升效率，同时还会强化业务的规范化与标准化，所以才专门提出去扫描、识别、提炼可进行异步化改造的流程。

比如销售部门在接受订单时要先评估客户的信用情况，风险在可控范围内才能接受，这样在订单处理流程中就植入了一段信用评估流程。信用评估可能由专业部门把关，比如由财务部负责，考虑到每次都这么处理很烦琐，所以就会考虑是否应该在订单处理流程之外，事先建立一套信用等级标准，这样订单处理时就不必每次都提交到财务部审核，于是就很容易想到事先制定一个客户信用标准管理流程，把这些事提前完成。

为了在客户订单需求大于产能时，更适当地进行订单优先排序，可以把专门设置进行客户分级管理、订单分级管理的异步化流程以事先输出客户分级标准与订单分级标准，这样计划部门安排生产时就有可以快速处理、有据可依。

为了避免每次采购都需要和供应商进行一次议价，可以采用一揽子定价方式，企业与供应商在某个时段内议定一个统一的价格，这样每次采购时就不必先去议一次价。为了支持这个做法，就需要有一个专门的价格管理流程支持。

为了避免每次与合同供应商签订合同都需要财务部门对付款条件进行审核，可以事先把公司认可的付款条件标准确定下来，这样只要采购合同的付款条件在标准之内，就不必再让财务部门专门去做一次审核。那么管理付款条件标准这件事就可以形成一个异步化的流程。

4.​ 进行流程间的串接

前面按照供应链的各大环节进行活动分析时识别出的流程，以及从异步化角度提炼出来的流程，大多不是孤立存在的，它们要与其他流程，特别是由不同部门主导的其他流程进行衔接，才能把流程价值传递下去。现实中，因为部门墙的存在，常常存在不同部门之间没有有效衔接的情况，所以流程串接工作在端到端的业务流程设计中非常关键。

当采用顶层设计方式时，本身就在设计初步的端到端的业务流时整体性考虑了关联流程之间的关系，只是那个阶段还比较粗糙而已。另外，初步通过流程串接分析，再迭代式地返回来优化各个独立的流程是流程优化的重要途径。下面我尝试举几个例子进行说明。

比如来自市场的客户需求有订单、准订单、预测几种形态，在销售环节会有不同的流程来处理它们，继续传递下去就到了计划环节，计划环节面对这几种不同的需求形态，也需要用不同的方式进行承接，这样计划流程中就必须体现这种分支化的应对，或以不同流程的方式，或以通一个流程中设置不同分支的方式，这种考虑就是在进行流程之间的串接。通过这种串接还可以前后彼此校验，进而继续完善各个流程。

新供应商认证流程的触发是源于产品设计需求，这就需要把新供应商认证流程与研发流程进行衔接，正确的做法是在研发流程中明确具体的可触发新供应商认证流程的节点，并明确上游节点具体为下游流程提供了哪些输入。

车间用料的领取管理，是采用生产车间带着计划部门开出的领料单去仓库领料，仓库依据领料单发料方式，还是采用计划部门直接发物料单给仓库，仓库事先备好料，或者主动送到车间，或者待车间来领料的方式，需要基于企业实际情况做出策略性的选择，进而是在计划流程、制造流程、仓库出料流程之间做出清晰的接口设定。

5.​ 识别逆向流程、变更流程、异常流程

 相对于正向的常规业务流程，逆向流程、变更流程、异常流程往往不太受重视，这是因为在企业规模从小到大的发展过程中，开始这几类流程要解决的问题出现频次较低，组织规模也小，依靠管理者的执行统筹能力或员工之间的默契就能基本消化这些问题。随着企业规模渐增，这几类流程要解决的问题出现的绝对数量日增，组织也日益复杂，这几类“非常规”流程几乎毫无例外地都是跨部门流程，仅仅依靠管理者的执行统筹或部门之间的默契解决这些问题的方式日益捉襟见肘、力不从心，信息流通不畅和部门立场博弈（体现为“辅责效应”和“博急效应”）严重干扰这些问题的妥善解决，同时这类问题处理不好带来的成本性、质量性、效率性损失也越来越大。这个时候，企业就应该专门关注一下这三类“非常规”流程了。

逆向流程多出现在涉及供应链中的实物流的地方，因为信息流的逆向作业一般是以变更流程的方式来应对的。在制造型企业供应链中常见的逆向流程包括但不限于客户退货流程、采购物料退货流程、车间退料流程、呆死料处理流程、报废流程、借料还料流程、车间返修流程、客户返修流程等。这些流程基本都是跨部门流程，除了涉及逆向处理的程序，还包括对触发逆向流程条件的充分必要性的判定，判定背后是各部门不太乐意承担的责任问题，所以都是极容易出现扯皮、搁置现象的流程，也是“博急效应”高发的流程。因此，在供应链的业务逻辑设计中要特别关注逆向流程。

变更流程有两个关键：一是论证变更的必要性；二是变更后涉及多个部门采取善后措施的长程序链。变更的必要性如果控制不严，很轻易就能变更，不但容易发生变更过滥的现象，还会影响相关人员在正序流程中工作的严谨度。如果没有严格的程序控制，变更后确保波及的下游部门都能及时采取善后措施也非易事，比如当研发部门做了一个BOM变更后，可能触发下游供应链的计划部门要调整生产计划、物料计划，采购部门要变更采购订单并处理在途订单，供应商要变更物料型号，品质部门要变更检验标准，仓库库存要盘点呆滞物料等。所以，变更流程一定要精细化，不同条件会触发什么部门采取什么措施的脉络要清清楚楚，最好还要在流程中设置一个统筹人，确保多分支的善后措施能够无遗漏地做到位。制造型企业中常见的影响供应链领域或供应链领域内部的变更流程有，设计变更、BOM变更、工艺变更、客户订单变更、生产计划变更、采购计划变更、质量标准变更、合同变更等。这一类流程涉及面广、数量多，也是供应链整体业务逻辑的必要构成部分。

异常流程即处理异常状况的流程，所谓异常状况就是超出了正常的状况，不符合既有的规范标准或经验性规律。在范围广泛的供应链领域，每个流程阶段都可能出现异常状况，很多异常状况是出现在审批性、接受性环节，这时退回上游环节重新作业即可，无需建立专门的异常处理流程。比如计划部门发现销售部门传递的订单有错误，打回销售部门做出修改重新提交就可以，制造部门发现计划部门的生产计划不符合实际情况，也可以告知计划部门调整后重新提交。也有一些异常状况发现的相对滞后，有些相关联的作业已经被执行，这个时候就需要进行变更或逆向流程来解决已经形成既定事实的问题，这种情况异常状况处理往往已经被包含在变更流程或逆向流程中。比如BOM错误被发现后，会通过BOM变更流程进行处理，给客户的发货错误或产品有质量问题会通过客户退货流程进行处理。

前面这两种情况都是异常相对容易判定，也容易判断问题原因的，但还有一些异常状况是不容易做出判断结论的，需要多部门共同参与分析、判断，也是容易出现“博急效应”的，这些异常状况一般是需要专门设置异常处理流程。比如来料异常处理流程、制程不良品处理流程、设备异常处理流程等，这些异常处理流程的下游往往会衔接逆向流程、变更流程。

很多年前，华为在各大部门建立一个叫作“文件投入处”的小部门时，为这个小部门提出一个工作口号——“例外的工作例行化，例行的工作流程化”。我认为这句话可以作为构建供应链管理体系时针对上述三种“非常规”流程的指导方针。

6.​ 详细的组织分工界定

前面几个步骤基本是基于相对模糊的部门分工假设展开的，这几个步骤之后，供应链方方面面的业务脉络全图基本就全出来了，此时就可以把模糊的部门进行清晰确定和细分了，即确定每个大部门内部详细的组织与岗位分工。这项工作大体而言要依据企业行业特征、企业规模、商业模式选择、供应链战略、供需匹配模式选择、业务流程脉络、各环节的工作量等环境与条件来具体构思论证。后面有专门章节讨论这方面的细节，此处不再赘述。

7.​ 最终流程的完成

前面几个步骤的工作重心在于勾勒供应链流程总体的、关键的框架，以及组织结构与分工，最后一个步骤就是各个流程的细节设计了，包括完成每个流程的详细路径设置、角色对应、活动描述、工作模板、操作指引等。