流程“河”
在公司内部有很多流程，它们的作用应该是什么？只是应付各种审计，给一线人员增加负担，做各种报表？错！如果一个流程只是实现上述功能，它们就应该被立刻废弃。真正的好的流程一定要能够增加价值。
流程本质上是组成业务的基本单元，也就是说，每个业务都有一系列的流程所组成。而流程，则是由跨越一个或多个组织的活动组成，这些活动利用一个或多个输入要素，对其进行转换和增值，最后向内、外部客户提供一种或多种产出。
因此，流程的顺畅与否，流程过程是增值了还是增加了太多的成本，对业务的结果具有重大的影响。
可以用河流来比喻流程。河流会流经不同的区域，每个区域可能有支流汇入其中，同时有人疏通河道，有人清理污染，也会有蒸发渗漏，有人偷排污水，有人抽水灌溉农田，还有人筑起大坝。当河流从源头流入大海，水量和水质决定了大海的质量。这其中，支流、疏通河道、清理污染就是对流程的增值，蒸发泄漏、污水、抽水灌溉、大坝、疏通河道和清理污染的人力则是成本，大海就是为顾客提供的产品或服务。
一个流程会有不同的节点，会有若干活动。如何评判这个流程是否能够促进业务，有必要分析一下这些节点和活动带来的“收入”和“成本”。例如从产品开发到上市交付过程，大的活动会有需求分析、开发、测试、交付等，节点会有需求评审、发布评审、上市评审等，涉及的部门会包括市场、产品、开发、测试、财务、法务、交付、售后等，流程的终点是外部客户。
所有活动投入的人力都是成本，在各个活动和评审环节所停留的时间也是成本（机会成本），得到的收益有需求澄清、代码本身、代码质量提升、产品质量提升、提升客户体验、规避财务和法律风险等。当把这些收益和成本都梳理出来后，就比较容易判断是否满意这样的投入产出比（ROI），哪些步骤和环节的成本大于收益，应该被优化甚至砍掉。又或者，一些流程和环节在业界是成熟做法，但为什么这么设计，这里面有什么关键注意事项？如果不理解内在原因很容易流于形式。如果按照前面的方法来做分析，就能这个弊端。
例如，一个成熟的场景，成熟的客户，法律风险相对较小，这时候如果花费过多时间（成本）去评估法律风险（收益），就是负收益了，此时可以考虑换个更快速简易的方式，甚至极端情况下取消。
又例如，在上市时间紧迫的压力下，是否应该减少需求分析、测试和评审所花的时间？如果减少这些时间自然减少了相关成本，但是有可能也会减少相应的收益，这样的交换是否划算？把收益和成本梳理清楚，摆在决策者的面前，这样他们就能更准确地做出判断。
在现实中，不少流程或环节的设立只是为了突出相关部门的存在感，对业务并没有实际的价值，这种分析方式可以帮助识别和评判这类流程或环节的合理性。
有人可能会希望有个定量的方式来更方便的评估，很遗憾，这个比较难。这种方法只是提供了一个更细致的评估和分析流程表现的方法，不能完全自动化。从个人观点来说，除非已经有成熟的业务模型、成熟的组织体系，否则试图完全量化都是没有意义的行为，尤其是在快速变化的内或外部环境中。
前面提到，一个业务是由一个或多个流程组成的，流程和流程之间可能会存在大量断点，这也是很多流程多的公司容易犯的毛病。导致流程之间出现断点的最主要原因，就是这些流程由不同部门的不同人负责，而他们缺乏有效沟通，同时也只关注自己范围内的事情。
往更高的方面说，一家公司的诸多业务之间可能存在关联关系，例如LTC、产品开发、生成、供应链管理、交付、客户服务、售后等等，这些流程之间存在在依赖或互为输入输出的关系。但经常的情况是，不同业务、不同部门之间的合作并不顺畅，导致流程之间存在断点。如果要理顺公司的大部分业务，尽量排除流程断点，一个比较好的方式是把所有流程放进一张全景图。就像一张全国地图呈现所有河流的走向、关联关系，然后模拟实际场景运行流程（就好像开个小船顺着河流巡游），这样就比较容易发觉它们之间连接的顺畅情况以及可能的问题。
解决这个问题的一个可行的方法，就是有人从总体上负责（流程架构师）。他至少要做好三件事：
- 定义总体流程架构，有哪些流程，流程的范围和目的是什么
- 定义流程间的接口
- 各流程就绪后，按照业务的情况，沙盘演练，把各种场景都跑一遍，这个过程中，也要关注流程的增值情况
当然，这也要求这样的流程架构师能够有足够的影响力或权威，并关注细节，以获取相关的信息，并推动流程变革。