WorkflowPro：做一个真正被人用的企业自动化系统

企业软件有个恶名：臃肿、难用、昂贵。我见过这个恶名是怎么来的——大多数企业软件是由那些优化合同范围而不是优化真实使用者体验的团队做出来的。

WorkflowPro 是一次做不同事情的机会。

问题

客户是一家电梯制造企业，200 多名员工分布在运营、HR、财务和项目管理部门。他们的审批流程——采购申请、报销、请假申请、设备采购、合同审核——全部通过邮件和打印表单来走。东西会丢，本来几小时能定的事情要拖几周，没有人知道一个申请现在到了哪个环节。

HR 部门尤其痛苦：员工档案、入职 checklist、政策签署、部门调动，都靠共享文件夹加人工跟进来维持。这套东西能运转，全靠两个特定员工脑子里的隐性知识撑着。

他们之前试过一个现成的工作流产品，太泛化、太贵，每次需要新增一个表单都要请顾问。两年后实在扛不住了，找到了我们。

WorkflowPro 是一个 Rails 单体应用，这是我刻意的选择。200 个用户、一家公司，不需要微服务，单一部署的运维简单性在它运行的那些年里回报了许多次。

核心数据模型围绕三个概念：

工作流模板定义流程的步骤、审批人和条件。一个采购申请模板可能规定：5000 元以下需要一个主管审批；5000 到 50000 元需要主管加财务总监；超过 50000 元还需要一个副总裁签字。

工作流实例是正在模板里流转的具体申请。员工提交采购申请后，一个实例被创建，系统知道当前处于哪一步、谁需要行动，以及下一步是什么。

动作是推进实例的事件：批准、拒绝、要求补充说明、超时自动升级。

这种分离是我做过的最重要的设计决定。工作流模板偶尔会变，但实例在流转过程中永远不会更换模板。把它们分开意味着我们可以更新审批链，而不影响进行中的申请——这正是你需要的行为。

在设计会议上，我花了两个小时和客户争论怎么建 HR 数据模型。他们想把员工建成一张表里的若干行，带几十列。我想把关系显式建模：员工有职位，职位属于部门，部门有负责人。

那个争论值得打。HR 集成——用员工数据自动填写申请人信息、自动路由给正确的主管、处理组织架构变动——只有在关系模型真实反映现实的情况下才能干净地工作。

三年后，这个 schema 没有发生过一次破坏性的变更。新的功能需求——文档版本控制、授权代理审批、批量处理、部门调动工作流——都自然地嵌入进已有的结构里。

我做了很多东西，真正起作用的其实就那么几个。

邮件通知里直接包含操作按钮。 审批人不会主动去打开应用——他们在看邮件。每封通知邮件都包含一个”批准”或”拒绝”按钮，用一次性 token 做认证，不需要登录就能记录操作。加了这个之后，采纳率从 40% 涨到了 90%。

代理审批。 人需要休假，代理审批的能力——把你的审批权限临时委托给一个同事，设定起止日期，到期自动恢复——解决了之前系统根本没法处理的问题。事后来看，这是用户反馈里提及最多的功能之一。

完整的审计追踪。 每次状态变更都记录了谁做的、什么时候、留了什么备注。制造业的运营团队非常看重这个——他们需要能够为合规目的还原一个决策的来龙去脉。审计追踪在最初的需求文档里只是个 checkbox，后来变成了一个频繁被用到的功能。

超时自动升级。 如果一个审批超过 X 小时没有动静，自动升级给审批人的上级。这个功能花了两天开发，几乎消灭了”卡在某人收件箱里”的问题。

文档管理功能过度设计了。我做了一个带签出/签入、预览渲染和细粒度权限矩阵的版本化文档存储系统。其中大概 20% 的东西被真正用过。一个简单的文件附件加版本历史，能覆盖 90% 的使用场景。

我还做了一个有 15 张图表的报表仪表盘。用户常看的只有两个：一个是”待我审批的申请”，一个是”各部门平均审批时长”。我本应该先上这两个，看有没有人要求更多，再决定做不做后面那些。

我最骄傲的不是某个具体功能，而是系统在生产环境运行了三年，服务 200 多个日常活跃用户，没有一次计划外故障。

这个稳定性来自一些无聊的决定：单个 Heroku 标准 dyno 跑 Puma，Postgres 是唯一的数据存储，Sidekiq 加 Redis 处理后台任务，对状态机转换有完整的测试覆盖，暂存环境和生产环境精确对应。

唯一出过问题的一次是一个数据库迁移在工作时间锁表时间超过预期。我们做了复盘，把零停机迁移实践加进了部署 checklist，之后就再也没出现过。

企业软件不需要复杂，它需要可靠、可理解，并且围绕人们真正的工作方式设计。WorkflowPro 做到了这三点，所以它还在跑。