从Word到Stages:我使用过的流程工具

我纠结过一阵子：是先介绍建模工具，还是先讲元模型，还是直接上手建模实操？后来我想明白了，脱离工具谈实践是不可能的。工具之间的差异太大了，不同的工具决定了你不同的工作方式、不同的思考习惯，甚至不同的职业轨迹。所以我决定先从自己用过的工具说起，不做横向对比，那些对比AI比我专业多，主要说说自己的真实感受。

一、Word+Excel时代

我第一次写流程文档，是在一家外企。那家公司的管理体系让我至今印象深刻——所有的标准、制度、流程、规范全部放在一个文档系统里管理，主文件格式是PDF，由Word转成。那个系统有些刻板，但就是这种刻板，反而让全公司的人都对它肃然起敬，也让我养成了非常好的标准化习惯。

我写的第一份流程文档用的就是它的模板。章节框架、字体字号全部规定好了，还附带详细的填写说明。一开始觉得有点束缚，但很快就发现这种束缚其实是保护——它帮我把框架搭好了，告诉我一份流程文件应该包含什么内容，不至于让我的第一个流程文件随心所欲地跑偏。

那时候我画流程图其实不是图，用的是Excel方式，每个活动一行，填写活动名称、角色、输入、输出、工具。后来我发现Excel表格的方式我自己喜欢，但对大部分读者不太友好。不过，用表格梳理逻辑的习惯我一直保留到了今天。

在外企的那段经历让我意识到一件事：用最简单的载体是可以实现高度标准化的，但前提是前人有足够的经验累积，团队有足够的标准化自觉。可惜，这种自觉在我接触的很多同事中，常常走不下去。我会被拖入各种关于流程文件格式要求不合理的讨论中。我后来变为流程文件的审核者，发现自己花在教他们如何修改流程文件的时间和精力非常大，我教会了他们，但是对他们来说，这仅仅是一次性的工作。很多时候，我都是自己上手帮业务部门完成编辑的工作，因为这样更高效。那时候我以为这是执行力的问题，后来才明白，这是工具和管理意识的问题。

二、Word+Visio时代

Excel擅长RASIC划分，但是对于稍微复杂一点的流程图，加了决策，加了不同流向，它就不擅长了。我告别了Excel，转向专业的Visio画流程图。用Visio画泳道图，每个活动一个矩形框，决策点用菱形框，箭头连接先后顺序，横轴是角色，纵轴是时间线，一张图把谁做什么、活动顺序、怎么衔接全部说清楚了，非常直观。我还在活动旁边加了一列“工具列”，用不同的符号区分是IT系统还是线下表单模板，并没有去做流程元素的深入研究，而是自己做过工程师，发现除了知道谁干什么重要，怎么做也非常重要。

但Visio的问题很快就暴露了。首先是普及率，Visio不是Office标配，大部分人打不开Visio文件，所以我画完图还得打印成PDF再嵌入Word文档。流程开发过程中版本变动频繁，为了让大家方便阅读，我花在调整格式上的时间比画图还多。其次是图文分离，流程图画出来了，但每个活动的详细说明、输入输出的文档模板、对应的标准条款还是只能写在Word里，流程信息被拆成两半，看的人需要在图和说明之间来回切换。更麻烦的是跨流程关联，一个研发流程往往包含几十个子流程，在Visio里只能靠加超链接，点开一个又链接更多，用不了多久就会迷失在文件迷宫里。

要命的是维护成本。每次修改流程，我都要手动检查Visio图和Word里的描述有没有遗漏。这种手工维护的工作量随着流程规模扩大呈指数级增长。Visio让流程变好看了，但没有让流程变好用——恰恰相反，它让流程文件更难维护了。

三、PPT时代

Word加Visio的方式虽然不好用，我也坚持了很多年。直到换了一家公司，发现新公司的流程是用PPT呈现的。第一眼是被惊艳到的——PPT模板和样例设计得非常漂亮。相比之下Word文档显得太啰嗦太刻板，密密麻麻的的文字，Visio图显得不够“高大上”。PPT图文并茂，元素规范而突出，可以加动画过渡，每页一个主题，阅读体验确实好。

PPT的好处是灵活。你可以把流程画得漂漂亮亮，配色统一、字体美观、布局精致，一页放流程图，下一页放活动说明，再下一页放角色职责表，随时调整、随时美化、随时在会议中展示。

但PPT的坏处和Word如出一辙，甚至更严重。

为了从多个角度呈现一个流程，我常常要用三页图：一页泳道图，一页SIPOC图，一页RASIC图。对阅读者来说这极大满足了感官诉求——直到今天，大多数领导都要求这样呈现。但管理成本极其高昂，为了在领导面前完美呈现，我耗费了大量时间在格式编辑和前后一致性核对上。但如果不耗费这个成本，PPT的效果比Word更糟——Word很容易做到格式规范，但PPT的灵活给了它太多天马行空的自由，在做得不好时只会显得更加粗制滥造，流程文件是立法文件，一篇看起来好看的PPT，本身就显得它不是很严肃，如果再加上里面的错漏和前后不一致，它的公信力是树立不起来的。

更有意思的是，接触了另一家公司的PPT后，对比一下子就出来了：A公司的模板和配色更好看，B公司的元素更全，PPT本身成了被比较的对象，流程内容反而退居其次。

规范的PPT载体可能是流程文件阅读最好的呈现方式，但对流程管理者来说也是最灾难的一种载体。其实除了Office套件，我也接触过WPS和飞书文档里的流程图功能，更加惊艳。但所有这些以文件为主要载体的工具，都难以解决流程版本及流程间衔接的问题。流程文件的标准化要么做得很糟糕，要么就得耗费大量审核-沟通-确认-修改-再审核的管理成本，耗到最后往往是迫于时间压力的争吵和无奈妥协。

四、简易BPM平台时代

产生真正质变的流程管理，是从流程文件的载体转到了流程建模平台，实现流程中的内容结构化。为了避嫌，我不提使用的第一家BPM系统的名字了，姑且叫它“简易BPM平台”。这是我第一次接触真正的流程管理系统，第一次接触“流程建模”——而不是写流程文件。习惯了Office套件的管理方式后，它给我的第一感觉是：专业。似乎终于有一个地方可以正式地、系统地管理流程了。

我可以在平台里创建流程模型，定义活动、角色、表单、路由规则，流程可以发布、查阅、版本管理。员工可以在系统里查看流程、跟踪状态。流程建设和发布一体化，让版本管理轻松自由。这一切比Word加Visio强太多了。虽然学习成本不低，我还是花了很多时间把之前散落在PPT里的流程在BPM平台里重新建了一遍。

但用了一段时间之后，我发现它也有局限。首先是学习成本确实高，模型建好了，然后呢？流程管理者满意了，但流程建设者在吐槽，流程评审者和使用者也不满意——大家都说还是PPT好用，流程建个模有什么用处？这个BPM平台让我看到了系统的价值，也看到了系统的边界。我不再坚持流程建模，而是妥协退守回了PPT时代。作为流程管理者，我必须回答一个问题：流程为什么要建模？从那个简易BPM平台里，我没有找到答案。

五、Stages时代

几年前，我接触到了Stages。有了之前简易BPM平台的建模经验，我不再盲目接受一个新的流程管理工具。而且我看到流程管理部门的很多同事都在吐槽这个软件，专业部门的同事也抵触它——大家都已经习惯了体系文件的Word格式和流程文件的PPT格式。

Stages的培训文件里有一句话：“Stages最大的特点是它的元模型，它把流程变成了数据，而不是文档。”我当时没看懂，但这句话在脑子里留下了印记。后来我开始认真了解Stages，去参加相关的论坛，越了解越发现它似乎就是我一直想要的那个东西。

Stages不是画图工具，也不是审批流引擎，而是一个流程建模与管理平台。它最核心的能力是它的元模型——一套预定义的、基于汽车行业最佳实践的流程要素关系框架。什么是元模型？用我自己的理解：元模型就是流程的“语法规则”。在没有元模型的时代，流程要素之间的关系是隐式的、靠人脑记忆的。我知道活动A产出了文档B，但这个“产出关系”没有被系统记录，它只存在于我的脑子里或者写在某段文字里。而在Stages里，元模型定义了流程活动可以和产出信息项建立“产出”关系，可以和角色建立“负责”关系，可以和标准条款建立“映射”关系——这些关系是显式的、结构化的、可查询的。

这意味着当我在Stages里创建一个“软件需求分析”活动时，可以直接关联“软件需求规格书”这个产出物，关联“系统工程师”这个角色，关联ASPICE的“SWE.1”条款，系统会记住这些关系。当我后续修改这个活动时，系统会自动检查：你删除的这个活动关联了ASPICE的强制条款，确定要删吗？当我准备ASPICE审核时，不需要再手动翻文档做表格，系统可以直接生成一份报告：ASPICE SWE.1条款对应的流程活动是什么、负责角色是谁、产出文档是哪些。这些能力，是Word、Visio、PPT，甚至我之前用过的那个简易BPM平台都做不到的。

六、为什么想完全切换到Stages

说实话，公司现在还没有完全切换到Stages。各种管理系统中，Word、Visio、PPT、Stages同时存在，存量流程还在慢慢迁移，团队的习惯还在慢慢改变。但我的目标很明确：完全切换到Stages。

为什么？因为我越来越清楚地认识到，流程管理的终极问题不是“怎么画”，而是“怎么管”。Word和PPT只管“文档”不管“关联”，你可以在文档里写“活动A产出文档B”，但系统不知道这个关系，当活动A变了，文档B会不会受影响？系统不会提醒你，你只能靠自己记住。Visio只管“图形”不管“数据”，你可以画一张漂亮的泳道图，但图背后的信息无法被系统化管理和查询。简易BPM平台只管“审批流”不管“工程流”，它能把一个审批单跑得很顺畅，但它不理解ASPICE条款和流程活动之间的映射关系，不理解产品开发流程特有的复杂性和合规要求。

Stages不一样，它从一开始就是为了解决这些问题而设计的。它的元模型把流程变成了可管理、可追溯、可分析的数据资产，内置标准库让合规映射不再是手工苦力，全球裁剪能力让跨国协同成为可能。我想要的不是“画流程的工具”，而是“管流程的平台”。Stages是我目前见过的、最接近这个目标的工具。

当然，切换的过程并不轻松。学习曲线是真实的——从“画图思维”到“建模思维”需要时间；存量流程的迁移是巨大的——几千个Word和PPT文件怎么系统地转成Stages模型；团队的接受度是挑战——工程师们愿意用一个新工具吗？但这些问题是怎么做的问题，不是要不要做的问题。方向已经定了，剩下的只是路径和节奏。

七、给同行的一点建议

在行业论坛交流时，我们必然会交流大家现在公司里用的是哪个工具。如果读者朋友问我应该用什么工具，我的回答是：看你在哪个阶段。

如果你只是偶尔画几张流程图，Word、Visio、PPT就足够了，觉得这些太普通，想炫技的话，用各种平台的流程图功能也可以，比如飞书文档的流程图。如果你需要把流程的各个版本管理起来，简易的BPM平台是合适的选择。但如果你和我一样，身处汽车行业的产品研发领域，需要管理成百上千个相互关联的流程，需要在全球范围内实现标准化与本地化的平衡——那么，Stages是一个值得认真考虑的选择。

工具演进的本质不是工具本身越来越高级，而是我们对流程管理的理解越来越深刻。

从Word到Visio，流程实现了“可视化”；

从Visio到PPT，流程实现了“以读者为中心”；

从PPT到简易BPM平台，流程管理实现了“版本化”和“系统化”；

从简易BPM平台到专业的Stages，我希望学会让流程“资产化”——让流程不再是躺在文档里的文字和图形，而是可以被管理、被追溯、被复用的企业核心资产。

这条路还很长。但至少，我知道方向在哪里。