大型组织中的流程与灵活性

尽管我常自称主要兴趣在技术领域，但至今我已接触过多种不同的组织和管理风格：从1996-2002年破解/黑客小组的自组织混沌，到以工程为中心的小型初创公司zynamics，再到我曾咨询过的各种政府及行业组织，乃至谷歌这样庞大但仍以工程为核心文化的企业。

我喜欢思考组织——它们的结构、信息流动方式、优势与功能障碍。部分原因可能受我父亲的影响（他广泛著述矩阵组织，但也研究失败的组织）；另一部分则是认识到公司文化和组织文化都至关重要。在任何组织中，设定文化组织结构并保持其健康是至高无上的，也可能是长期成功的关键要素。忽视文化组织结构（无论是显性还是隐性）都将自食恶果。

去年我有大量时间思考，因此在未来几个月，我将写几篇关于公司文化和管理文章。

首篇文章关于组织流程——它们为何重要，以及它们如何自成一体并扼杀灵活性。

从一个技术轶事开始

2004年初，BinDiff的第一个原型开始正常工作——恰逢微软发布MS04-001：微软ISA服务器（现已停产的防火墙产品）H.323解析组件中存在一系列有趣的小型内存损坏问题。对补丁使用BinDiff后，明显问题出在中央库的ASN.1 PER解析例程中——但补丁并未修复该库，而是在ISA服务器内部修复了问题。

该补丁仅修复了一条利用路径，但实际漏洞仍然存在。这意味着任何使用同一库的其他程序仍然易受攻击，且补丁实际上披露了安全问题。我开始搜索使用该库的其他应用程序。我发现的第一个受此漏洞影响的程序是Netmeeting——微软无意中向所有人提供了Netmeeting的远程代码执行漏洞。直到4月份的MS04-011，该漏洞才在正确位置——库中得到修复。

该漏洞的技术细节并不十分有趣——有趣的是错误揭示了微软组织结构中的缺陷，以及它们对漏洞报告的反应。

我们能从这一事件中推断/学习/推测什么？

漏洞报告可能被路由到产品团队——例如，如果在你的产品中报告了漏洞，漏洞报告会路由给你。

修复漏洞的责任似乎在于产品团队（见上文），并且团队有动力（直接或通过功能截止日期等间接方式）快速处理漏洞报告。

修补共享中央代码比修补自有代码更困难（原因多样——可能是兼容性顾虑、其他团队的其他优先级，甚至可能是请求更改关键代码的繁重流程）。

可能的情况是，ISA团队认为处理他们这边的问题就足够了——要么因为他们没有意识到同一问题会影响其他人，要么因为处理其他团队/库很麻烦，或者其他未知原因。微软的漏洞修复流程激励了“浅层”修复，因此对攻击者而言，找到漏洞的最终根本原因可能暴露其他易受攻击的程序。

这是一个典型的做出局部便利决策却对更大组织产生不利影响的例子。

据我所闻，微软从这一事件中学习并进行了组织变更，以防止未来类似错误。他们引入了一个流程，所有补丁在发布前都经过中央审查，以确保不会无意中在错误位置修复漏洞或披露其他地方的漏洞。

流程作为组织学习

在MBA所谓的“组织学习”中，流程是从先前失败经验中创建的，以防止错误再次发生。流程有点类似于组织疤痕组织——组织伤害了自己，为防止未来此类伤害，流程被建立。

令人惊讶的是，大多数组织建立流程时没有明确记录是什么失败和什么事件导致流程建立。这种知识通常只存在于当时在场的个人头脑中，或存在于与当时在场者交谈者的民间传说中。大约五年后，没有人记得原始事件——尽管流程将生机勃勃。

流程可以防止组织重复做愚蠢的事情——但太多时候，流程自成一体：人们开始盲目应用流程，在过于字面思维的人手中，流程成为生产力或效率的障碍。负责应用和执行流程的人可能自己不知道它为什么存在——只知道它是“流程”，并且不遵循它可能发生坏事。

我祖父曾说过（我将转述）：“有责任的工作不是简单应用规则，而是需要判断如何以及在何处做出例外”。这句话包含一个重要真理：

组织中所有地方的人都需要……

有权做出例外：在展示合理判断后，人们需要感到有权在流程字面意义阻碍更大利益且更改流程过度时（例如，在一次性情况下）做出例外。

有权挑战流程：流程背后的推理必须对组织成员可访问，并且需要有一种（相对无痛）的方法来提议更改流程。由于无力感是职业倦怠的主要驱动因素之一，这将有助于保持个人和组织结构健康。

一些组织在“例外”部分做得好——大多数大型组织仅因人们经常愿意弯曲/扭曲/忽略流程而运作。非常非常少的组织在“挑战”部分做得好——确保每位员工知道并理解流程服务于公司，并且欢迎流程改进。

我认为未能实现挑战流程通常源于“缺乏机构记忆”。当组织未能跟踪流程创建原因时，各种有害副作用出现：

没有人能有意义地判断流程精神——它设计用来防止什么？

对流程做出例外风险更大——如果你不知道它设计用来防止什么，你怎么知道在这种特定情况下该风险不适用？

修改流程风险更大。（同上原因。）

挑战流程无法以分散/自下而上的方式发生：通常是最初级的员工可能对 obstructive 流程有最新眼光——但由于他们不知道流程存在的历史，他们通常无法有效提议更改，因为他们对组织不够了解以排除不良副作用。这直接破坏了工作流的分散、自下而上改进。

处理流程的健康方式是什么？

认识到它们是“组织记忆”的一种形式：它们通常是对某些不愉快事件的反应形成的——意图防止该事件重复。同样重要的是认识到未检查和未挑战的流程可能成为组织“疤痕组织”——阻碍多于帮助。

跟踪创建每个流程的确切动机——“为什么”。这将涉及写半页或更多，并与参与流程创建的其他人核对描述准确且可理解。

流程背后的动机应对受其影响的每个人可访问。

每个人都应知道公司流程应支持而非阻碍完成工作。每个人都应感到有权提议更改流程——理想情况下同时说明这些更改不会导致流程设计防止的问题重复。

人们应有权偏离或忽略流程——但频繁或甚至罕见但重复的例外是流程需要改进的红旗。不要通过授予例外机制积累“遗留流程”和“组织债务”。

每个人都应意识到保持流程功能性和精简对保持组织健康至关重要。即使流程不合理且 obstructive，大多数人本能地尝试接受它——但第一本能理想情况下应为改变它以更好。建设性挑战破碎流程是对组织的服务，而非攻击。

明智的做法可能是将流程视为代码——包括相关流程的所有权、版本控制，以及人员换工作时流程所有权的移交。然后流程修正可以作为文本提交，由流程所有者审查、讨论并最终批准——很像补丁或删除死代码。

保持组织健康很难。然而，保持健康的最关键成分是组织成员关心保持健康。因此，鼓励在出现问题时修复组织绝对关键——并且不鼓励人们“盲目遵循流程”。