基本信息
阅读时间：约 11 分钟
字数：约 4400 字
摘要：流程的价值不在文档本身，而在于它让下一次执行不再依赖记忆。本文给出流程的写法、验证方式、更新机制与在团队中的落地路径。
全文语音
中文
English
日本語
한국어
流程不是规范，它不追求完美，只追求让下一次执行不再需要从零回忆。
记忆最容易出错的地方不是事实，而是顺序，而顺序恰是流程最擅长记录的部分。
第二章 值得固化的三类事项
流程的修订最好由执行者完成，写流程的人往往已经脱离了执行现场。
流程开头的适用范围最好给出正反两例，帮助使用者快速判断自己是否适用。
流程的适用范围最好写成一句话，过长会让使用者不确定自己是否应该参照。
如果一件事每次都要临时决定由谁来做，那么它就需要一条明确的责任分配规则。
高价值低频次的事项同样需要流程，因为一次严重失误的代价远高于写文档的成本。
选择固化对象时可以按频率乘以影响来排序，排在前面的事项优先处理。
技术性操作写起来最直接，因为每一步的正确结果都是客观可验证的。
沟通动作容易被忽略，但它的不一致会造成返工，因此同样值得被写下来。
判断类事项写作难度最大，但可以写成判断依据而不是替执行者做决定。
跨部门协作事项尤其需要流程，因为责任人往往不在一起，口头约定最先失效。
选错固化对象通常会导致流程被视为形式，此后所有人都会轻视流程本身。
第一类技术性操作，例如部署、对账、报销，它们有明确的正确结果，容易被写清。第二类是沟通动作，例如客户回复、交接说明，它们的价值在于稳定而不是最快。第三类是判断类事项，例如采购审批与风险评估，它们最难写但可以写成判断依据。
低频但高风险的事项最需要流程，因为出错概率低并不意味着出错影响小。高频低风险的事项反而不太需要，写出来的收益可能被维护成本抵消。
当流程的使用者超过三人时，口头传递的版本差异会明显放大。
第三章 流程的写法
每份流程开头都应当写明适用场景与不适用的场景，避免被用错的地方。
写流程时可以先画出极简草图，确认步骤顺序后再转成文字，这样不易遗漏分支。
写流程时可以先用口语记录，之后再润色，口语版本往往更贴近真实的操作。
写流程前应当先跑一遍完整过程，并在旁边记录每一处停顿，这些停顿就是文档骨架。
流程中的名词应当统一，同一件事在不同步骤里出现不同叫法会让执行者产生误会。
把常见错误写在步骤旁边，比写在单独的注意事项里更容易被注意到。
步骤顺序应当与执行一致，不要用归类式的写法让执行者自行推断先后。
每步尽量只做一件事，把相关联的动作合并会让执行者在实际操作中跳过其中一部分。
结果描述最好使用可被检查的形式，例如文件名、金额、状态变更，而不是完成。
涉及外部系统的步骤应当写清楚入口与账号归属，这是最常造成停顿的地方。
写完后应当由执行者朗读一遍，读起来别扭的句子通常在实际执行中也会别扭。
开头一句话说明这个流程解决什么问题，读者只消一眼就能判断是否与自己相关。主体按步骤排列，每步一行，避免一屏里塞入多个动作造成理解负担。每步应当包含输入、动作与结果三要素，缺少结果的一步无法被执行者验证。
易错点单独标出，例如需要确认的字段名、需要留存的附件，这些是最常被忽略的部分。结尾写明适用范围与例外情况，没有例外的流程在实际中都会出现例外。
如果一份流程一年内没有被修订过，通常说明它已经无人使用。
第四章 保留判断空间
流程的价值不在于写得完整，而在于被执行者在实际场景中默认打开。
流程中的每一步都应当能在合理时间内完成，耗时过长的一步通常说明它混入了两项工作。
每一份流程都应当标注最后更新的日期，日期是判断它是否可信的第一依据。
给例外设定一个处理时限，能让执行者在异常情况下不至于无限期拖延。
判断标准的阈值最好有依据，例如来自历史数据，这样它在争论中更容易被接受。
例外发生后应当触发一次流程修订，把处理过程变成正式步骤的一部分。
判断空间的宽度应当与事项的风险匹配，低风险事项可以留得更宽一些。
例外清单不宜过长，超过五条的例外清单意味着流程本身需要重新组织。
遇到例外时应当有记录动作，因为例外记录是后续修订流程最主要的输入。
授权层级需要写清，否则执行者会为了一个例外来回确认，反而降低效率。
留白不是放任，它的前提是执行者清楚自己需要为判断结果负责。
把流程写成必须照做的指令，会在第一次例外出现时让人不敢使用。更好的写法是把例外明确列出，并说明遇到例外时应该找谁决定。判断标准应当写成条件而不是结论，例如金额超过某个值时转审批，而不是直接写必须审批。
流程中应当保留一个可以停下来的位置，让执行者在异常时提出疑问而不是硬着头皮继续。保留判断空间的流程更容易被遵守，因为它承认执行者拥有局部信息。
把流程放在执行现场而不是文档库里，被打开的概率会高出许多。
第五章 验证流程是否可用
流程的修订最好由执行者完成，写流程的人往往已经脱离了执行现场。
流程被引用最多的是高频事项，因此它们也是最值得投入修订精力的部分。
流程涉及的外部依赖应当单独列出，例如需要账号、权限或第三方的确认。
验证可以在真实的第二个实例上进行，这样既不打断正常流程，又能得到真实反馈。
验证时应当记录每一步的实际耗时，与预期明显不符的步骤就是需要细化的地方。
验证完成后应当更新文档，把验证中发现的描述偏差一并修正，否则文档会继续失真。
验证前应当明确合格标准，例如完全独立执行且不询问任何人，作为唯一判据。
验证时不宜在流程执行中加入改进意见，否则无法判断流程本身的问题在哪里。
如果发现熟悉的成员执行也很吃力，说明描述与真实操作之间已经出现偏差。
验证结果应当区分卡点与缺陷，卡点多说明表达问题，缺陷多说明步骤缺失。
验证通过后应当给出一段稳定期，稳定期内的修改建议全部汇总后再统一处理。
第一个验证方式是让新人独立执行，不看原作者，卡住的地方就是流程的缺口。第二个验证方式是检查每步的结果描述，如果结果无法被验证，这一步就是空的。第三个验证方式是模拟一次异常，看看流程是否能引导到正确的处理路径。
第四个验证方式是测量执行时间，如果执行时间明显长于老手，说明步骤写得不够具体。验证应当定期进行，建议每季度一次，因为人员与工具的变化会让流程悄悄过期。
当流程的使用者超过三人时，口头传递的版本差异会明显放大。
第六章 流程的维护
如果流程中出现了两个人同时负责的步骤，通常意味着责任边界需要重新划分。
如果一件事总是被延迟执行，通常不是因为不重要，而是因为流程把它写得太不吸引人。
维护人应当定期查看流程的实际使用情况，使用数据比主观印象更可靠。
当流程依赖的系统被替换时，相关步骤必须整体复核，而不是只看文字是否还通顺。
维护的最大障碍不是时间不足，而是缺少一个被指定承担这件事的人。
负责人不必是最高级别的人，只要对结果负责并且有时间参与修订即可。
触发条件中可以加入客户反馈这条，外部反馈往往比内部观察更早发现问题。
修订记录应当写清时间、原因与改动点，缺少原因的修订在半年后无法被理解。
旧版本保留应当有限度，保留最近三到五个版本通常已经足够。
维护可以设置一个固定时间，例如每季度最后一个工作日下午集中处理修订。
维护的第一步是指定负责人，没有负责人的流程会自然腐烂。第二步是设定触发条件，例如工具升级、人员变动、出现两次同类失误时触发修订。第三步是记录每次修订的原因，原因记录比修订内容更能帮助未来的维护者。
第四步是归档旧版本，保留历史版本可以避免在争论中反复回到原点。维护成本最低的方式是让修订发生在事情发生时，而不是集中在大扫除中。
第七章 团队中的落地路径
使用流程时最先被跳过的往往是中间步骤，因此中间步骤的必要性最需要复核。
流程中的检查点最好有明确的责任人，无人承担的检查点等于没有检查点。
落地初期可以让流程与探索并行，允许暂时的不一致，通过几次迭代后再统一。
选择试点执行者时最好选择愿意反馈的人，愿意反馈的人能带来最关键的细节。
把流程纳入例会讨论，可以让修订变成一件自然发生的事而不是额外任务。
挑选对象时应避开最难的事项，先用一件容易成功的事建立信任更有效。
流程与考核挂钩会带来短期服从，但也会让执行者只关注形式而不看结果。
在团队内部指定讲解人比全员培训更省时，讲解人掌握了细节才能回答追问。
落地过程中应当公开收集回来的卡点，被采纳的修改能显著提高后续遵守率。
如果三个月内无人使用，通常说明它没有被放在执行路径上，而非人们不愿意配合。
落地第一步是从现有工作里挑一件最常做的事，通常就是最高频的那件。第二步是把流程写在可执行的地方，例如工具内链接或模板文件，而不是只在目录中。第三步是指定第一个使用者，让流程在实际任务中被检验而不是停留在文档里。
第四步是收集卡点反馈，反馈应当来自执行者而非管理者，因为前者才知道哪里会卡。第五步是把修订纳入团队节奏，例如周会的固定一项，避免修订永远排不上。
第八章 常见失败模式
流程的成功经验值得写成附注，让后续的使用者知道为什么这样做。
执行中发现更好的做法，应当在下一次执行时立即采用，而不必等到下一次修订。
还有一个常见问题是在流程中塞入与主题无关的内容，最终使流程变得难以阅读。
流程缺少索引时，使用者在最需要它的时刻往往找不到它。
如果用不上流程的人从不提出异议，通常说明他们不知道流程的存在。
还有一种失败是流程与实际并行两套，最终人们会默认使用旧的那一套。
流程没有版本标记时，两个人可能在执行不同版本的同一流程而产生分歧。
把流程写成一次性任务的人，往往低估了它与实际操作之间的细化空间。
适用范围写得过于宽泛，会让执行者在无关场景中被迫参照而收获甚微。
忽视反馈收集的设计，会让流程在实现第一批细节完善之前就失去可信度。
第一种是把流程写成说明书，追求详尽，结果没人愿意读，最后也没有被执行。第二种是流程只描述正常路径，一旦出现例外就完全失去指引作用。第三种是没有负责人，谁都能改谁都能不改，流程在半年内就与现实脱节。
第四种是流程过于频繁地修改，修改本身消耗的执行注意力超过它节省的时间。第五种是把流程当成考核工具，一旦与绩效挂钩，人们开始照搬形式而忽略结果。
流程是否越正式越好。不是，能被使用的方式才是最好的方式，形式感不等于有效性。
没有专职文档维护的人怎么办。可以由执行者轮流承担修订，关键是有人负责。
流程会不会限制创新。多数情况下不会，因为流程针对的是重复事项，创新发生在例外上。小团队需要流程吗。需要，小团队更需要，因为人力少意味着没有冗余去试错。流程多久更新一次合适。以事件触发为主， quarterly 的人工检查为辅。
谁来写流程比较好。做这件事最多的人来写，因为他最清楚哪里会出错。流程写得越细越好吗。不是，能被执行者理解并执行的粒度才是有用的粒度。如何促使团队使用流程。把它放在执行路径上，而不是只放在知识库中等待查找。
常见问题
流程是否越正式越好。不是，能被使用的方式才是最好的方式，形式感不等于有效性。
没有专职文档维护的人怎么办。可以由执行者轮流承担修订，关键是有人负责。
流程会不会限制创新。多数情况下不会，因为流程针对的是重复事项，创新发生在例外上。
小团队需要流程吗。需要，小团队更需要，因为人力少意味着没有冗余去试错。
流程多久更新一次合适。以事件触发为主， quarterly 的人工检查为辅。
谁来写流程比较好。做这件事最多的人来写，因为他最清楚哪里会出错。
流程写得越细越好吗。不是，能被执行者理解并执行的粒度才是有用的粒度。
如何促使团队使用流程。把它放在执行路径上，而不是只放在知识库中等待查找。
综合整篇文章来看，流程真正带来的不是约束，而是把判断与记忆的负担从人身上转移到文档上。
图片来源：图1 KingsInnPhotography / Pixabay (CC0) · 图2 Matias_Luge / Pixabay (CC0) · 图3 12019 / Pixabay (CC0) · 图4 YHBae / Pixabay (CC0) · 图5 pen_ash / Pixabay (CC0) · 图6 sashamatic / Pixabay (CC0) · 图7 nimrodins / Pixabay (CC0) · 图8 12019 / Pixabay (CC0) · 图9 stevesnyderphotography / Pixabay (CC0) · 图10 tasha / Pixabay (CC0) · 图11 KlausAires / Pixabay (CC0) · 图12 lin2015 / Pixabay (CC0) · 图13 Pexels / Pixabay (CC0) · 图14 PIRO4D / Pixabay (CC0) · 图15 Alois_Wonaschuetz / Pixabay (CC0) · 图16 BeJan / Pixabay (CC0) · 图17 12019 / Pixabay (CC0) · 图18 Alexas_Fotos / Pixabay (CC0) · 图19 Alois_Wonaschuetz / Pixabay (CC0) · 图20 Tama66 / Pixabay (CC0) · 图21 DenisDoukhan / Pixabay (CC0) · 图22 RuslanSikunov / Pixabay (CC0) · 图23 schuetz-mediendesign / Pixabay (CC0) · 图24 jonleong64 / Pixabay (CC0) · 图25 sasint / Pixabay (CC0) · 图26 fegatelligiancarlo / Pixabay (CC0) · 图27 ClaudiaWollesen / Pixabay (CC0) · 图28 fegatelligiancarlo / Pixabay (CC0) · 图29 MiraCosic / Pixabay (CC0) · 图30 Dimhou / Pixabay (CC0) · 图31 MiraCosic / Pixabay (CC0) · 图32 focusonpc / Pixabay (CC0)
本文为信息分享与财商教育，不构成任何证券、期货或投资咨询建议，亦不构成个性化投资建议。市场有风险，决策需谨慎。
本文由 AI 生成，经人类主编终审。
评论(0)