流程设计

架构定义

架构这个东西，针对不同的目标，有不同的关注点，但从比较基础的语义来说，架构是一组互相关联的抽象逻辑约束。通过定义架构，我们推断可以通过达成架构内的逻辑约束目标来达成架构的目标。（常见的组织绩效目标分解OKR、PBC等工具的核心逻辑也是这种）

比如假如我们要从深圳去北京，我们可以建立这样一个逻辑：

1. 先在网上定机票
2. 提前2个小时打车到深圳机场
3. 坐飞机到北京首都机场
4. 通过导航软件决定坐某条公共交通线路到北京的酒店

我们执行这个逻辑是不是一定能到北京呢？不一定，因为这依赖很多细节，比如路上堵车 ，天气不好飞机不能起飞，或者干脆没有去北京的机票之类的。但你说你没有这个逻辑， 出门就向北走，能不能到得了北京呢？那大概率是不行的。

前面的这一组逻辑，就是架构。而设计前面这个逻辑的过程，就是架构设计。

从这个例子中，我们看到了架构设计的几个特点：

1. 它不是事无巨细，什么都设计，它更不是细节本身（只有实施，才是细节本身）
2. 虽然它粗糙，但它的逻辑仍是连续的，是可以达成目标的。
3. 它对执行具有限制作用，正是因为这个限制作用，才使我们在细节设计或者执行的时候简化了目标

架构的特点决定了架构大部分情况都是一种战略选择，它必然在缺乏细节逻辑的前提下进行设计，并且存在着失误的风险。这说起来很简单，只是因为上面的例子简单，实际上一旦执行，很多人都会下意识地犯错。

最常见的一个错误就是做架构设计的时候追求“我没错”。但凡“我没错”的设计，基本上都是有错的。因为架构设计首先是一种设计，所有选择中的一个选取。去北京可以坐飞机，也可以坐高铁，你要选其中一个，放弃另一个，放弃另一个是没有严格理由的，只是你不能两个都选而已。你要保证“我没错”，就必须两个都选，这就没有在做架构设计这件事情。“我没错”的另一个表现是脱离逻辑链，避开逻辑链去谈“正确的信息”，以图用信息填补没有设计的缺陷。比如，今天之内有12班航班飞北京，其中6班要中途转机，他们的机型分别是巴拉巴拉，这些机型的故障率用柱状图表述如下……。这看着都没有错，还很专业的样子但其实根本和我们要做的设计逻辑毫无关系。你说他有问题，他还给你辩解说“难道飞机安全不重要吗？”。

前面这个脱离逻辑链问题一个更加隐秘的体现是高层逻辑和下层逻辑不分。还是用前面这个坐飞机的例子来类比。打的这个选择，可能有不同的细节可以选择，比如可以是打出租车，也可以是用快车，专车之类的服务，这个确实也是我们必然要做的选择，但这个逻辑 的变化，不改变我们其他任何逻辑，这个东西就属于下一层的设计。我们不应该把它提到本层里面来。这很重要，因为我们在架构设计阶段，主要目的不是为了让整个事情能够落地，目的直接就能达成，而是保证高层逻辑合理了，目的达成的概率高。这样我们就可以专心根据高层逻辑的来做下层逻辑的设计，并及时根据现实的情况做出调整。所以我们必须全部心思反复权衡高层逻辑是不是最优的，有没有优化的余地，有没有多余的约束。高层逻辑引入的约束越少，我们做下层设计的自由度越大。但我们还需要保证逻辑链是成立的，所以引入约束就不可避免。我们是在这个两难之中选一个平衡。这时你把下层设计暴露到高层设计中，这个东西就影响我们对这个逻辑链的优化。也许只有一两个的时候我们还能脑补把它忽略掉，但这种东西稍一多，人脑的处理能力有限，它就影响我们对问题的判断了。

更关键的问题是，这样做很多时候，是为了掩饰高层逻辑链不严密。

而架构设计的目的就是为了让高层逻辑严密。高层逻辑可以粗糙，不表示它可以不严密。我们可以不细化坐快车还是专车，但我们不能不考虑例如“最近公司不让报销打的费用”这个要素，无论你打什么车，也不论你打车的时候对司机的语气好不好，如果你不想自己付钱，你就不能选打的这个方案。如果你选择其他公交路线，你的计划，时间都要改变，这才是高层设计要关心的问题。

所以，构架设计如此关注所谓的“关联”。当一个逻辑修改的时候，它会影响其他逻辑，我们就说他们有关联，有多个关联的东西，才值得放在同一层的逻辑里面讨论。

高层架构和低层架构

架构设计是设计一组约束（限制）。那么，什么东西会成为下一层的约束，而什么东西需要称为下一层的约束呢？毕竟如果最后每个约束都是约束，并没有什么不同，为什么有些约束会成为高层约束，而有些却只是低层约束呢？

这要从人的思考模型说起。人在思考的时候能够处理的信息其实很有限，但外部世界的信息是非常巨大的（即高信息熵状态）。为了在有限的计算能力下高效的思考，需要将对信息进行加工抽象，抹除掉细节而提取模式（Pattern），降低信息的熵。借助理解Pattern来理解这个世界，这样就可以通过足够简单的Pattern的重复来思考问题，控制复杂的组织，实现复杂的目标。（道>>恍惚>>有无）

我们制造高层限制，就是为了人为地降低信息熵。我们无意识地从深圳走路去北京，在路上遇到问题解决问题，这整个过程不受控，你无法对这个过程思考什么，人脑没法建立一 个逻辑去向这个方向努力。但你拆成“打的去机场”，“坐飞机去北京”，这就可控了。我们遇到细节障碍的时候，有一个就近的目的去管理我们的逻辑。

这个高一层的逻辑结构，就是人脑人为制造的架子，就是架构。它的目的就是让我们在做细节逻辑的时候，有一个依附，在发展的时候，有一个决定如何变化，能否变化的基础。所以，架构确实就是个架子，它是整个设计的逻辑的架子。 我们做这个架子的时候，“看不见”它里面的细节。

当我们把部分的逻辑链整理好放在一个大的，人为维护的”抽象逻辑“中，我们就可以整体控制这个系统。正如一个系统的所有功能都是打包好的小程序时，那么对这个系统的控制就是可控的。

但是为了能够让系统内的功能都被系统约束，就需要对小程序里的细节（底层逻辑）进行约束，认为的让它符合特定的约束要求。否则功能与功能之间按自己的逻辑发展，系统就会陷入混沌不可控制状态了。

所以，细节逻辑是天道（自然而然地发生，遵循最基本的规律），高层逻辑是人道（受到人为目的的约束和影响）。不符合天道，事情不会发生，不符合人道，事情不可控制——也就无法达成人的目的。

也因此，高层设计的目标只有两个：

1. 让天道（细节逻辑）有机会变得简单可控；
2. 能借助天道的力量实现目标；

细节逻辑在架构设计阶段是”不知“的状态，毕竟如果设计了所有的细节，那么这个系统也就设计完成了。架构设计阶段会逐步细化逻辑，碰到新的“知”，因此一个好的架构设计，应该是为这些还不知道的细节留下自由度，让它能导向目标，同时也不会与细节逻辑冲突，事事情无法发生。

为了实现这点，主要有两个策略：

1.经验。类似的架构设计的成果结果越多，这类架构成功的可能性更大。

2.利益。有人愿意为了某种约束投钱投资源，而这种资源可以保持这个约束的生命力，或者大部分人会自然而然地支持某种约束（因为支持了他们会获得利益），那么这种约束就可能是合适的。

所以做流程设计的时候，首先必须要考虑这个流程要实现什么目标，谁愿意为了这个目标而建立流程（约束），而这个目标受到了现有环境的什么约束？

流程的细节逻辑有时候反而并不重要，而至于流程的格式，承载形式、显得是否专业都是在做流程时延申出来的“名”，跟流程的目标已经偏离了十万八千里。

就算是公司的最高领导非要说我就是要建一个流程体系，那也可以分析出最高领导愿意为建立流程体系持续投钱的动力在哪里。否则我们直接把某家公司的流程体系文件Copy过来，叫他XX公司流程体系，不就行了。

高层逻辑和细节逻辑

从这些角度来理解架构，就很容易解释为什么架构设计“看不见”。这是因为架构设计是在抽象层次上的约束，而细节设计是在具象层次上的约束。抽象是为了能够可控，而具象是为了能够应对具体问题的变化。

所以针对高阶架构的设计，需要尽量用抽象的语义去贴一个具象的情况。比如软件架构设计师不会说做一个针对SSD的LRU算法，而会说针对IO设备的LRU算法。

而对于细节逻辑而言，往往设计可能会非常具象化。比如产线上的工序指导，SOP，这类逻辑都严格定义了每一类工作的约束选择，多长时间，多少次，多大力度，使用什么工具，诸如此类。产线的流程借助于此，为的是保证输出的结果可控（而非逻辑可控）

基于此，还会有一个有趣的推论：如果没有架构层面的设计能力，任何人都只能是做执行的外包团队。

没有架构设计，就只能在细节中迷失自我，不断机械重复。而要有架构，就需要有自己的利益链。在整个高层逻辑中，必须有你在保障客户的利益。而且你的保障逻辑链必须是在所有的解决方案中是由竞争力的，否则你会被整体替换。

对于做流程管理而言，如果只能按照已有的流程要求去做流程审计，调整流程的格式、文本、细节逻辑，那么这样的流程团队是一定会被替换掉的。流程管理团队一定需要由流程架构的设计能力，而这个流程架构需要能够保障公司“对快好易”地满足客户地需求，这样公司的老板才会愿意投入资源到流程管理团队中来。流程架构的整体解决方案必须是有竞争力的，否则会被其他的组织替换掉。

顶层架构

架构是分层的，每层架构以上一层定义的约束和目标为条件建立自己的逻辑链。

最顶层的逻辑链从利益开始。

比如组织一个团队，开发一款手机。这个目标虽然不直接——到底开发的是智能手机，还是传统手机？手机是否需要支持5G，这没有人给你约束——但这不表示这不能成为商业目标。架构本来就是要你主动发现约束，是要你的创造力，而不是你的体力。

又比如现在有一个项目终止了，人都没有事干，想办法让他们赢取利润，至少平衡他们的工资成本，这同样可以是一个商业目标。

但开发一个操作系统，分成内核和用户两个特权级。这不是目标，这个逻辑链不能作为顶层架构。你首先要从利益上说明“开发一个操作系统”这件事本身是有逻辑支持的——即最高层有利益支持。

这个地方也有一个很有趣的推论：设计本身是信息选择的过程。我们进行一层层向下设计， 让抽象变成具象。抽象有很高的自由度，简单建模，最开始的自由度很多，我们建立高层抽象，比如我不关心你如何到机场，你可以在x1的定义域内选，我也不关心你具体坐哪班 飞机，你可以在x2的定义域中选，所以高层逻辑是一个函数：

F1(F11(x111, x112...), F12(x121, X122...)...)

其中的xnnn是那个子逻辑的变量，是我们为细节选择不同的路径留下的自由度。设计细化的过程，是每个子函数进行选择的过程，每次细化，都是把变量变成常量的一个“选择”的 过程。

所以，高层设计不包含下层设计的信息。所以要求无限细化高层设计，或者要求细节设计可以从高层设计的约束本身上推出，本身就是缘木求鱼。我们能理解人意欲上希望有这样 “结论”，但这个“结论”本身是不可能达成了。错误的期望导致错误的行为。（这本质上就是盲人摸象式的思维，从局部细节难以了解整体抽象，而从整体抽象也无法得知局部细节）

架构的发展和成长

架构是上层抽象，是高自由度的范围定义。但最终真正定义它是什么样的，是它的细节。而细节是不可控的，是自然生长的。所以要控制架构，另一个角度是控制架构的环境。

比如企业的流程文化是万事均要经过领导审批，那么执行层面的流程一定会存在着无数的审批节点。最终的结果是流程又臭又长。

但每个执行层面的流程都是由这个模块的团队去设计的，人家就是觉得应该需要领导审批，这无法改变。

想要改变这种情况，最根本的方式就是控制业务的理念和需求：比如我一个需求最多只能经过三个审批节点，又或者一类风险最多只能审批两次。诸如此类。

通过控制这样的业务环境，来控制流程的细节。

实事求是

架构设计在很多地方最难的一件事是实事求是。架构设计必须是架构设计，而不能是“做架构设计”。换句话说，架构设计的目标必须是一个商业目标，而不能是架构设计自己。这叫外其身而身存。

架构设计的目标是为了达成那个商业目标，不是获得“这个架构设计不错”这样的评价。所以无论如何我们不应该出现“这样画一个架构视图是否符合架构设计的要求？”这样的问题， 架构设计没有要求，架构设计的逻辑都是为架构设计的商业目标服务的，不存在“做架构设 计”本身产生的设计约束。我们会有“这样设计架构不好”的评价，但这个评价不是针对架构 设计的规矩的，而是针对这样设计导致的商业目标被损害来说的。有时我们还会说“这个架构不符合架构我们的架构经验，因为关联太多了”，这个评价也是针对商业目标无法达成来 说的，不是针对架构设计必须有什么规矩这一点来说的。

所以，如果不能实事求是地看待架构设计工作，认为架构设计不是设计之外的一个设计， 架构带来的是一个伤害。因为你在商业目标之外引入了额外约束，而我们架构设计的自身 目的就是（在达成商业目标的前提下）减少约束。

所以，不强调实事求是这个前提，即使你完全执行我们前面提到的要求，最终它仍不是架构设计。

以前面深圳去北京的例子为例，我们可以坐高铁，也可以坐飞机。要让逻辑链可靠，我们应该调研和比较两者的优劣。但这样让成本提高了，我们不值得提高这个成本呢，我们的架构设计就是“我们直接选择坐飞机”，你要问“为什么不坐高铁？”，我答不上来，但我的选择就是“坐飞机”，问题我也解决了，这是实事求是。不能为了逻辑链完美，非要做各种调研，空耗资源。我也不会故意说“高铁它不稳定，高铁不环保”，这同样不是事实。这个思维模型，就叫“知不知上”。我不知道，但我不认为我就需要知道。这才是实事求是。

我个人更喜欢把这个要求叫“守弱”，因为“实事求是”是一个表扬自己的表述，人们会把自己的期望叫做“实事”，把不希望做的事情叫“不是这样的”。最终还是无法面对现实。

而守弱的要求是，我要主动呈现自己的弱点，所以“这个我也不知道”，“那个我也不知道” ，但“我知道这个”，它也支撑我的逻辑链了。所以，追求“守弱”，就是实际意义的实事求是。

对于流程架构设计来说也是如此。流程架构的目标首先是业务能够高效运转（关键在运转，其次在提高效率）。逻辑是否完美还在其次，这才是实事求是。

注：本文为网络文章的转载+批注，绝大部分内容均来自于Kenneth Lee。原文作者标注文章仅用于学习之用，不可用于其他用途。