第三节 建立端到端的业务流逻辑
产业链分析、商业模式与企业战略澄清、供需匹配模式确定为企业供应链确定了基本的价值定位、边界、指引、约束、原则、要点，把握了这些顶层要求，才能展开供应链体系的构建，这些既有助于防止“见木不见林”式的局部分裂建设，也有助于防止机械地蹈袭各种理论模型、各种标杆实践。供应链的业务流逻辑对供应链体系而言，就像是现代框架式建筑的“框架”，是供应链体系的核心构成部分，它也为整体体系提供了一个基本坐标系。限于篇幅，本章对建立端到端逻辑只能进行一个原则性、关键的阐述。
一、兼顾业务逻辑中的运筹逻辑与人性逻辑
对企业而言，为寻求组织效率、效能最优解对组织分工、组织活动、组织资源利用方式进行创造性的规划和安排，可以视为运筹学意义上的努力，据此而形成的业务逻辑中必然体现了这种运筹逻辑。大家平时能接触到的各种管理方法、管理工具，多数都是运筹学意义上的，着眼于优化企业的业务逻辑，比如专业化分工、目标管理、六西格玛管理、瓶颈管理等。
在这些运筹方法中，把人视为经济学意义上的人，就像下棋人下棋时不用考虑棋子会不会愿意。但现实中的人是社会学意义上的人，都有七情六欲，会通过围绕自我的利害计算选择自身行动（也就是博弈策略选择），这意味着从运筹学意义上进行的安排未必能如预期一样被执行，这就是隐藏在业务逻辑中的人性逻辑。
比如按照企业预期逻辑，研发阶段本是应该为产品量化生产在可批量制造性、可采购性等方面考虑周全，转产后即可顺利进入批量生产，而现实未必如此。销售部门与计划部门的关系，道理上客户订单及尚未形成正式订单的未来客户需求都应该了解清楚，及时传递给计划部门组织做好生产准备，而现实中客户需求的传递往往不如意。制造、采购、工程等部门在运筹逻辑上应该及时把各自动态的业务信息传给作为中枢的计划部门，而计划部门在运筹逻辑上应该基于充分的信息制定生产计划，确保计划是可行的，但实际上前者往往并不能主动及时将信息传递给计划部门，而计划部门也经常下放一些没有可执行性的生产安排。现在越来越多的企业意识到，采购应该提前介入研发环节，甚至做出明确的规定性要求，但实际上采购部门名副其实地介入研发环节何其不易，事情按照规定要求进展绝非易事。
小贴士
新中国建立后实行了几十年的人民公社制，从最初设想的运筹逻辑上看好处多的不得了，把小农户生产整改为生产队集体生产制，这是实行了规模效应；建立集体大食堂，不但可以减少家家户户小灶做饭的浪费，而且从总体上节省了人民花在做饭上的时间。但是这种美好的运筹逻辑设计没有尊重人性，既没有尊重群众的人性，也没有尊重党员和干部的人性，所以运气的规模效应并没有显现出来，人浮于事、生产力水平极其低下。
在目前企业常用的管理模式、管理方法中，大力去推行却不能达成预期目的的情况广泛存在。究其原因，除去推行本身存在的诸多问题外，这些模式与管理方法在方法论本身上重运筹逻辑而轻人性逻辑的特点，也是导致实施出现偏颇的重要原因。客观地讲，既然能成为一种标杆化管理模式或管理方法，一定有它的道理和价值，只是在标杆实践中它起作用的时候，除了运筹逻辑本身带来的进步，还一定有属于人性逻辑层面的支撑条件，这些条件往往是隐形的。对这些条件一无所知或认知不深、不明其理，就会导致企业导入这些模式或方法时在方法论本身上就存在缺陷，从而导致有其形而无其实。
KPI导向的绩效考核模式是不可否认其价值的，绩效考核是责权利闭环的重要组成部分，做好了可以起到将功罚惰的作用。但近年来这种模式广受诟病，抛开部分人偏见性的成分，这套方法本身对人性逻辑（也就是人群本质关系是博弈关系）的认知不够，是根本性的原因。在绩效考核中，第一个层面的博弈在员工与企业关系的垂直方向，考核指标不能太多，太分散了力度不够，但指标少了以后，指标对其实际工作责任的代表性即是一个问题，如果不具备代表性，就会诱导员工从采取“孙膑赛马”的“智慧”，把注意力都投注在考核的几个指标上而放弃其余，这是人性使然；更坏的情况是员工采用投机性手段把指标值做得更好看，这种投机往往以牺牲企业整体利益、未来利益为代价。第二个层面的博弈在部门之间关系的横向方向，很多工作需要跨部门的协作才能出成效，绩效考核模式本身很难解决本书第一章提到的“辅责效应”，于是主责部门就会感到心有余力不足，进而采取比较消极的态度对待这些指标。
绩效考核属于“黑盒”性质的管理手段，就是“不管黑猫白猫，抓住老鼠就是好猫”，这样给了被考核者很大的博弈策略空间，其中很多策略是对企业整体利益不利的。要彻底解决绩效考核模式的弱点，就必须重视“白盒”管理，也就是重视过程管理，重视业务流程的透明化管理，这样才可以控制那些企业不希望看到的博弈策略为被考核者所采用。（作者《管理：以规则驾驭人性》第11章的“规则如何影响博弈”一节对此有详细论述。）
阿米巴模式近年来在国内很流行，它的运筹逻辑原理同20世纪80年代初中国农村改革实施的“包产到户”政策有异曲同工之妙，把企业的所有部门通过数据手段定位为一个可以独立核算的经营单位，这样每个部门的“责权利”就都统一了，部门的主动性、积极性就被调动起来了。它的问题在于跨部门之间关系的量化界定上，企业的价值创造模式本身是基于专业化分工思想建立起来的集体化模式，除了诸如销售与制造部门等少数部门的工作容易分离出来作为一个相对独立的阿米巴，多数部门的工作很难数字化地与周边部门的工作分离出来。当强行人工干预去做分离时，第一个问题是分离的合理性，分离本身偏颇太多，就不能把所有部门的力量汇聚中统一的合力，而是各自为政、各说各话；第二个问题是这种模式本身提倡“斤斤计较”式的计算，各阿米巴之间的多数数字关系是人为强行把定性事物定量化，不同部门之间的理解分歧会非常大，这样无疑会几何级加剧部门之间的冲突性博弈，削弱企业原本就不容易做好的协同效应。在诱导重视短期利益、轻视长期利益方面，阿米巴也同绩效考核模式有异曲同工之妙。
美国管理大师迈克尔·哈默提出的流程再造理论是我个人在管理领域的启蒙性著作，随着我实践经验的增长和对流程再造理论思考的深化，我发现这位才华横溢的计算机博士的注意力都集中在了运筹逻辑方面，而对人性逻辑重视不够。这体现在流程再造理论总是寻求“几何学”意义上的业务价值链最短与最优，绝对地认为流程决定组织，并认为可以消灭企业中的组织，只要抓住流程企业运营效率就会提升。很显然，这些认知与现实是有很大出入的。
如何把运筹逻辑与人性逻辑融合在一起呢？从业务逻辑设计的整体讲，两种逻辑要相互参照、迭代式完善，从业务逻辑设计的具体思考步骤上，应该先考虑从运筹逻辑角度构建一个假设基础，然后从人性逻辑角度去验证这个假设基础的可行性，然后再调整运筹逻辑，如此循环迭代进展。多数情况下，并不会用人性逻辑完全否定运筹逻辑，而是通过人性逻辑角度的校验，来调整、完善运筹逻辑，使运筹逻辑能够在考虑人性逻辑的基础上站得住脚、具有可行性。换句话说讲，运筹逻辑的可行性取决于对业务过程中各种立场博弈的驾驭，或顺人性，或制人性，关键是要能切实确保人们按照业务逻辑的预期去行事。
二、遵从集成思想
集成思想是集成供应链的灵魂所在，前文已述，在此强调两点，其余不重复叙述。
一是应对决策分裂效应的关键在于跳出惯性思维，能够回到未分工之前考虑问题。所谓跳出惯性思维就是我们耳濡目染的各种企业内部分工方式。粗看起来，供应链分工后的部门无非都是销售、计划、采购、制造、质量、工程、物流等，但按照动态业务逻辑细看，其实不同企业不尽相同，其业务合理性与效率也是不尽相同的，管理可创新处多寓于此。
二是集成是建立在专业分工基础上的，现实中很多企业在专业化分工方面基础比较弱，此时要先强化专业分工，先保证具备基础专业能力，然后再以集成方式强化业务协同性。比如采购早期介入研发，采购在技术层面要有一定的基础，才能使这种集成方式有成效。
三、坚持端到端的业务流程原则
就供应链而言，端到端的意思就是从客户需求到完成对客户的交付。坚持端到端的业务流程原则有三个考虑：一是流程思维；二是确保体系的整体性；三是确保不同业务流程之间的衔接性。
流程思维即以业务流为主轴和基准坐标去构建整体业务体系。事实上，任何一个业务流，天然就是一个流程，价值一定是通过业务流产生的，按照流程去进行管理才是回归本源。只不过管理学占主导地位的管理职能理论把管理职能分为计划、组织、人事、领导和控制五个大项，企业实践莫不相从，基于这五项去展开管理体系，而最天然的业务流程反倒被淹没、被边缘化了。可以说流程思维是一种返璞归真，把管理的注意力重新聚焦到业务流本身，管理的种种措施都要围绕业务流展开。这种回归有助于突破传统管理理论容易产生官僚主义、形式主义的局限。
确保体系的整体性，就必须要有整体视角、顶层设计视角，以供应链整体最优为核心原则设计整体业务路径、区分部门权责边界。举个例子，当中央政府决定修一条跨越多个省份的新铁路时，如果铁路在每个省份的路径都由各个省份自行决定，甚至由省下一级的市自行决定，可以想象最后修成的铁路会是如何的“九曲十八弯”，其中的道理并不复杂，每个省市都会站在自己的立场，希望铁路尽量多经过自己地盘内的城市，这就是人性逻辑。现实情况下，企业供应链业务流的形成，更多是由下而上拼合成的，而非以顶层设计方式设计的，要突破这种局限，就必须有整体视角、顶层设计思维，进而确保业务流整体性的性能最优。
确保不同业务流程之间的衔接性，实质上意味着每个流程的设计过程都要瞻前顾后，流程和流程之间要彼此校验，确保它们之间的一致性和协同性。各个业务流环节的功能设定、各个部门分工范围与具体职能的界定也是在这个过程中以不断假设、求证，如此循环迭代，以逐步趋于完善的。比如在设计计划流程时，考虑到订单总量大于总产能时怎么处理，就会延伸出上游销售部门需要依据客户重要性做出客户分级定义，依据项目重要性做出订单分级定义。在采购部门导入新供应商以应对一款新产品的转产需要时，发现时间有限，根本来不及去充分地认证供应商、选择供应商，这样就延伸出采购部门应该在研发过程的早期阶段就进行供应商寻源与预认证，这其实也是在调整研发流程和采购流程之间的关系。
四、构建步骤
以下步骤体现一个大致的思考框架，在实操中次序并不是绝对的，更多时候各环节间是迭代式推进的，相互参照、相互假设、相互验证、共同完善。
1. 确定供应链的基本业务流
基于企业所在产业链特征、企业商业模式选择、与供应链相关企业战略，以及企业现状运作方式可以先绘制出企业供应链的基本业务流路径。对于制造型企业而言，销售管理、计划、采购、制造、物流这几大活动环节基本是可以确定的，但每个活动环节的组织与活动结构、各环节的厚度是不尽相同的。比如B2C业务形态企业的供应链的销售端的层次因渠道的存在会多一些，而B2B业务形态的供应链的销售端直接对接最终企业客户，层次会少一些。进而要依据产业分析、商业模式与战略分析、基本供需匹配模式选择识别出粗线条的路径结构，以及各大环节的战略性要求，以备下一个步骤使用。比如华为通信设备制造业务供应链的基本路径中存在两条主线，即按预测备料、按订单制造。同时，企业对各大环节的特殊性要求也要在基本业务流图上标识出来。比如生产大宗货物企业的承运管理比较复杂，是供应链管理的要点，要标识出来；相对而言，生产小型电子产品的企业承运管理要简单很多，不必特别强调。
业务流的实质是活动流，里面可能既包含信息流，也包含物流、资金流，这不同于把“三流”分离对待的方式，在这个阶段确定活动流是第一位的，信息流、物流、资金流应该从属于活动流。
对于生产多元化产品的集团型企业，会涉及多条供应链或供应链多分支的情况，这要依据公司的战略选择分别绘制出来。
商业企业的基本业务流与制造业有较大差异，其物流环节相对复杂，但确定供应链基本业务流的思路大体是相同的。
2. 各大环节的活动分解
对制造型企业而言，我们大体可以按照销售管理、计划、采购、制造（质量与工程服务于制造，不算独立的环节）、物流几个大环节展开进一步的业务流程与组织设计。虽然一般情况下每个环节都有一个主责部门，但使用环节这一概念是更合适的，这样可以避免先入为主。另外，我们假设每个主责部门都是一个模糊的部门概念，尚没有展开部门内部的详细分工，即此时使用的是笼统的销售部、计划部、采购部、制造部、仓储与物流部。
因为使用了“环节”而非“部门”概念，所以会相应地使用“活动”而非“职能”这一概念，“职能”是相对于部门而言的，“活动”则是相对于环节而言的，也就是这个环节要做的事。下面以销售与计划两大环节为例，粗略阐述如何确定该环节应该包括的活动，进而这些活动再对应到相关的部门职能。
从供应链视角看，销售管理（指销售后端管理）环节的核心活动是收集和接受客户需求，进行必要的加工后再传递给计划部门。当设计者把自己置入现实的业务场景，会发现围绕核心活动还有必要的其他活动，比如产品报价、客户信用管理、回款管理、跟单等。
每个活动都会对应着一个或一套流程，首先要弄清楚这个活动的价值所在，它不会无缘无故存在的，比如客户信用管理是为了防范公司的回款风险，而报价则是企业交易必需的一个步骤。其次，先定义这个活动的关键步骤与共同执行部门（多数情况下并不是一个部门就可以完全覆盖一个完整的功能）。比如报价活动可以分为核价与定价两部分。定价一般是销售部门依据市场情况、销售策略等确定（对供应链而言这个不是重点）；核价则是一个成本核算过程，要把组成产品成本的各种成本逐一核算，最后再汇总为一个总成本。一款新产品的核价可能涉及研发部门、工程部门、采购部门、财务部门等，这样我们就知道了这些部门应该有这些职责。订单接受与评审功能则是需要下游部门的介入，订单的实质是对客户的一个承诺，计划部门要依据产能情况评估能否满足客户的需求，采购部门可能需要就一些供应瓶颈部件做出评估，而对于第一次投产的新产品，研发部门可能需要介入评估，我们由此可以知道这些部门应该有这些职责。
也就是说，各个部门的职责范围是通过活动分析得来的。每个活动的关键构成步骤与相关参与部门，就构成了流程的核心要素。以此类推，我们用这个方法就可以得到销售这个环节的大部分业务流程清单、每个业务流程的参与部门及所扮演的角色。
在计划环节，我们知道计划部门需要把订单集中起来，依据产能条件排出生产的主计划，进而再把生产主计划进行分解，排出采购计划与加工计划。在安排生产主计划时，有可能遇到订单多而产能不足的情况，这时不能完全满足所有的订单要求，于是就需要有个优先级排序。如何排序呢？可能需要按照客户的重要性、订单本身的重要性，如果完全拍脑袋确定是很难达成共识的，比较好的做法是事先对客户做一个重要性的分级，对具有不同特征的订单做一个重要性的分级，这些工作需要最靠近客户、最了解市场的销售部门来评估，所以可能需要让上游销售环节增加一套客户分级、订单分级管理流程。这样我们就知道销售部门还应该有这么一个职责。
安排采购计划时，计划部门必须要先知道不同物料的标准采购周期，标准采购周期要由采购部门给出，所以就引申出采购部门的一个具体职责，即必须给每种物料确定一个标准的采购周期，这个动作要在采购流程中明确体现出来。
计划环节的其他活动都可以用类似的方式进行逐一分析，这样就可以得出计划领域的一条流程清单，以及在其他领域需要设定以支持计划流程的业务流程清单、每个业务流程的参与部门及所扮演的角色。
逐一把供应链的各大环节的各种活动都用这样的方法分析完毕后，就会得出供应链范畴内的一整套业务流程清单、每个业务流程的参与部门及所扮演的角色。按照部门把各自的职责进行汇总后，就基本确定了每个部门的职责范围，这个职责范围就成为每个部门进行更细致组织与岗位分工的一个基本依据，此时就可以初步列出一套比较像样的组织结构了。在这个步骤中，大致的流程清单、关键流程结构、与流程配套的组织结构基本上就形成了。
小贴士
这套方法也可以印证笔者在《管理：以规则驾驭人性》中提出的“组织即流程，流程即组织”观点。
3. 提炼出可异步化的流程
所谓可异步化的流程，就是从原本是以一条龙方式完成的整个工作中，提取出一部分，提前把这部分的工作做好。而这部分成果可以被剩余部分的其他工作直接引用，从而缩短总工作周期。很多时候，提前做好的这部分工作的成果还可以被重复使用、共享使用。异步化是一种运筹学意义上典型方法，能优化系统的整体结构、提高系统效率。
供应链领域可实施异步化的活动非常多，这些异步化的流程设置能提升效率，同时还会强化业务的规范化与标准化，所以才专门提出去扫描、识别、提炼可进行异步化改造的流程。
比如销售部门在接受订单时要先评估客户的信用情况，风险在可控范围内才能接受，这样在订单处理流程中就植入了一段信用评估流程。信用评估可能由专业部门把关，比如由财务部负责，考虑到每次都这么处理很烦琐，所以就会考虑是否应该在订单处理流程之外，事先建立一套信用等级标准，这样订单处理时就不必每次都提交到财务部审核，于是就很容易想到事先制定一个客户信用标准管理流程，把这些事提前完成。
为了在客户订单需求大于产能时，更适当地进行订单优先排序，可以把专门设置进行客户分级管理、订单分级管理的异步化流程以事先输出客户分级标准与订单分级标准，这样计划部门安排生产时就有可以快速处理、有据可依。
为了避免每次采购都需要和供应商进行一次议价，可以采用一揽子定价方式，企业与供应商在某个时段内议定一个统一的价格，这样每次采购时就不必先去议一次价。为了支持这个做法，就需要有一个专门的价格管理流程支持。
为了避免每次与合同供应商签订合同都需要财务部门对付款条件进行审核，可以事先把公司认可的付款条件标准确定下来，这样只要采购合同的付款条件在标准之内，就不必再让财务部门专门去做一次审核。那么管理付款条件标准这件事就可以形成一个异步化的流程。
4.进行流程间的串接
前面按照供应链的各大环节进行活动分析时识别出的流程，以及从异步化角度提炼出来的流程，大多不是孤立存在的，它们要与其他流程，特别是由不同部门主导的其他流程进行衔接，才能把流程价值传递下去。现实中，因为部门墙的存在，常常存在不同部门之间没有有效衔接的情况，所以流程串接工作在端到端的业务流程设计中非常关键。
当采用顶层设计方式时，本身就在设计初步的端到端的业务流时整体性考虑了关联流程之间的关系，只是那个阶段还比较粗糙而已。另外，初步通过流程串接分析，再迭代式地返回来优化各个独立的流程是流程优化的重要途径。下面我尝试举几个例子进行说明。
比如来自市场的客户需求有订单、准订单、预测几种形态，在销售环节会有不同的流程来处理它们，继续传递下去就到了计划环节，计划环节面对这几种不同的需求形态，也需要用不同的方式进行承接，这样计划流程中就必须体现这种分支化的应对，或以不同流程的方式，或以通一个流程中设置不同分支的方式，这种考虑就是在进行流程之间的串接。通过这种串接还可以前后彼此校验，进而继续完善各个流程。
新供应商认证流程的触发是源于产品设计需求，这就需要把新供应商认证流程与研发流程进行衔接，正确的做法是在研发流程中明确具体的可触发新供应商认证流程的节点，并明确上游节点具体为下游流程提供了哪些输入。
车间用料的领取管理，是采用生产车间带着计划部门开出的领料单去仓库领料，仓库依据领料单发料方式，还是采用计划部门直接发物料单给仓库，仓库事先备好料，或者主动送到车间，或者待车间来领料的方式，需要基于企业实际情况做出策略性的选择，进而是在计划流程、制造流程、仓库出料流程之间做出清晰的接口设定。
5. 识别逆向流程、变更流程、异常流程
相对于正向的常规业务流程，逆向流程、变更流程、异常流程往往不太受重视，这是因为在企业规模从小到大的发展过程中，开始这几类流程要解决的问题出现频次较低，组织规模也小，依靠管理者的执行统筹能力或员工之间的默契就能基本消化这些问题。随着企业规模渐增，这几类流程要解决的问题出现的绝对数量日增，组织也日益复杂，这几类“非常规”流程几乎毫无例外地都是跨部门流程，仅仅依靠管理者的执行统筹或部门之间的默契解决这些问题的方式日益捉襟见肘、力不从心，信息流通不畅和部门立场博弈（体现为“辅责效应”和“博急效应”）严重干扰这些问题的妥善解决，同时这类问题处理不好带来的成本性、质量性、效率性损失也越来越大。这个时候，企业就应该专门关注一下这三类“非常规”流程了。
逆向流程多出现在涉及供应链中的实物流的地方，因为信息流的逆向作业一般是以变更流程的方式来应对的。在制造型企业供应链中常见的逆向流程包括但不限于客户退货流程、采购物料退货流程、车间退料流程、呆死料处理流程、报废流程、借料还料流程、车间返修流程、客户返修流程等。这些流程基本都是跨部门流程，除了涉及逆向处理的程序，还包括对触发逆向流程条件的充分必要性的判定，判定背后是各部门不太乐意承担的责任问题，所以都是极容易出现扯皮、搁置现象的流程，也是“博急效应”高发的流程。因此，在供应链的业务逻辑设计中要特别关注逆向流程。
变更流程有两个关键：一是论证变更的必要性；二是变更后涉及多个部门采取善后措施的长程序链。变更的必要性如果控制不严，很轻易就能变更，不但容易发生变更过滥的现象，还会影响相关人员在正序流程中工作的严谨度。如果没有严格的程序控制，变更后确保波及的下游部门都能及时采取善后措施也非易事，比如当研发部门做了一个BOM变更后，可能触发下游供应链的计划部门要调整生产计划、物料计划，采购部门要变更采购订单并处理在途订单，供应商要变更物料型号，品质部门要变更检验标准，仓库库存要盘点呆滞物料等。所以，变更流程一定要精细化，不同条件会触发什么部门采取什么措施的脉络要清清楚楚，最好还要在流程中设置一个统筹人，确保多分支的善后措施能够无遗漏地做到位。制造型企业中常见的影响供应链领域或供应链领域内部的变更流程有，设计变更、BOM变更、工艺变更、客户订单变更、生产计划变更、采购计划变更、质量标准变更、合同变更等。这一类流程涉及面广、数量多，也是供应链整体业务逻辑的必要构成部分。
异常流程即处理异常状况的流程，所谓异常状况就是超出了正常的状况，不符合既有的规范标准或经验性规律。在范围广泛的供应链领域，每个流程阶段都可能出现异常状况，很多异常状况是出现在审批性、接受性环节，这时退回上游环节重新作业即可，无需建立专门的异常处理流程。比如计划部门发现销售部门传递的订单有错误，打回销售部门做出修改重新提交就可以，制造部门发现计划部门的生产计划不符合实际情况，也可以告知计划部门调整后重新提交。也有一些异常状况发现的相对滞后，有些相关联的作业已经被执行，这个时候就需要进行变更或逆向流程来解决已经形成既定事实的问题，这种情况异常状况处理往往已经被包含在变更流程或逆向流程中。比如BOM错误被发现后，会通过BOM变更流程进行处理，给客户的发货错误或产品有质量问题会通过客户退货流程进行处理。
前面这两种情况都是异常相对容易判定，也容易判断问题原因的，但还有一些异常状况是不容易做出判断结论的，需要多部门共同参与分析、判断，也是容易出现“博急效应”的，这些异常状况一般是需要专门设置异常处理流程。比如来料异常处理流程、制程不良品处理流程、设备异常处理流程等，这些异常处理流程的下游往往会衔接逆向流程、变更流程。
很多年前，华为在各大部门建立一个叫作“文件投入处”的小部门时，为这个小部门提出一个工作口号——“例外的工作例行化，例行的工作流程化”。我认为这句话可以作为构建供应链管理体系时针对上述三种“非常规”流程的指导方针。
6. 详细的组织分工界定
前面几个步骤基本是基于相对模糊的部门分工假设展开的，这几个步骤之后，供应链方方面面的业务脉络全图基本就全出来了，此时就可以把模糊的部门进行清晰确定和细分了，即确定每个大部门内部详细的组织与岗位分工。这项工作大体而言要依据企业行业特征、企业规模、商业模式选择、供应链战略、供需匹配模式选择、业务流程脉络、各环节的工作量等环境与条件来具体构思论证。后面有专门章节讨论这方面的细节，此处不再赘述。
7. 最终流程的完成
前面几个步骤的工作重心在于勾勒供应链流程总体的、关键的框架，以及组织结构与分工，最后一个步骤就是各个流程的细节设计了，包括完成每个流程的详细路径设置、角色对应、活动描述、工作模板、操作指引等。