AHAX 公开知识库阶段 · 文章
01 先判断问题是否值得做
先看经营损失、流程断点和方案边界，再决定要不要建设系统，以及该用现有工具、SaaS、低代码、定制还是混合方案。
很多企业一上来就说“想做个系统”，但真正该先回答的是：损失发生在哪里、流程断在哪一段、谁负责、拿什么验收。
事实：只有把损失、断点、责任和数据说清楚，软件才有可能变成可管理的业务工具。外部证据：工信部关于中小企业数字化水平评测、试点评测指南和数字化赋能专项行动，反复强调分层推进、标准化能力、开放接口和可验证成效。AHAX 判断：如果问题还没有稳定到能被描述和复核，就不要先谈建设；先把问题压缩成一页纸。示意案例：下文的企业场景只用于说明方法，不是客户案例，也不代表统一结果。
管理者先看结论
Section titled “管理者先看结论”先看结论，不要先看技术名词。对管理者来说，这一章只有一句话：先判断这件事值不值得做，再判断做成什么样，最后才判断用什么方式做。
如果下面三个条件同时不成立，通常不该先建系统：
- 经营损失说得清楚，能落到次数、时长、金额、差错率、返工量或等待时间。
- 流程断点说得清楚，知道卡在谁、哪一步、哪类信息和哪种交接。
- 责任说得清楚，知道谁是业务 owner，谁接受结果，谁长期维护。
5 个是否值得建设的信号
Section titled “5 个是否值得建设的信号”| 信号 | 你会看到什么 | 为什么值得建 | 如果没有就先别建 |
|---|---|---|---|
| 损失是重复发生的 | 返工、漏单、错单、催问、延误、对账花时间，每个月都在重复 | 重复损失才适合用流程和系统去收口 | 偶发问题先靠人工规则或现有工具处理 |
| 断点出现在跨岗位移交 | 信息在微信、Excel、口头沟通和个人电脑之间来回跑 | 系统最擅长把“交接”变成可追踪状态 | 如果只有一个人偶尔出错，先补规范 |
| 规则已经相对稳定 | 订单、报价、审批、配件、工单、回访的核心规则能说清 | 稳定规则适合做成可复用流程 | 规则还经常变，先别固化成系统 |
| 数据能被拿到且能对齐 | 客户、产品、订单、库存、项目、发票至少有一套主口径 | 没有数据口径，系统只会把混乱写进数据库 | 先统一台账、主数据和字段口径 |
| 负责人愿意长期参与 | 业务负责人愿意定义、试跑、改规则、验收和复盘 | 没有 owner，系统只能停在演示 | 没人签字、没人用、没人改，先暂停 |
AHAX 判断：不是五条全满才可以做，但至少要同时看到“损失可见”和“负责人可落地”。这两条缺一条，建设风险就会明显上升。
经营损失与流程断点怎么诊断
Section titled “经营损失与流程断点怎么诊断”先从经营损失入手，不要从功能入手。常见的诊断顺序是：
- 看损失在哪里出现，是获客、报价、交付、库存、协同、质量，还是风控。
- 看损失是怎么重复的，是重复录入、重复确认、重复催办，还是重复返工。
- 看断点在哪个交接处，是客户到销售、销售到交付、交付到财务，还是总部到门店。
- 看损失是否能被记录成证据，是能看见工单、消息、时间戳，还是只能靠感觉。
- 看损失是否能被修复，是靠流程统一就能解决，还是必须先建设系统。
AHAX 判断：如果损失主要来自责任不清、数据口径不一和执行纪律松散，软件不是第一刀；先优化流程，再决定要不要写进系统。
适用与不适用
Section titled “适用与不适用”不是所有痛点都该进入建设阶段。下面这组边界，先把“要不要做”说清楚，再谈“怎么做”。
| 方案 | 更适合什么情况 | 不适合什么情况 | 主要约束 |
|---|---|---|---|
| 暂不建设 | 只有偶发问题，或问题还没办法稳定描述 | 把一时焦虑当成长期需求 | 先靠人工规则、表单或现有工具止血 |
| 优化现有工具 | 现有表格、IM、表单、OA、CRM 还能承载，问题主要是口径和协同 | 现有工具已经无法表达核心流程 | 要先统一字段、权限和责任，再谈升级 |
| SaaS | 流程接近行业通用做法，且愿意接受平台边界 | 差异规则多、主数据要求高、退出要求强 | 要先看导出、接口、权限、停用和迁移 |
| 低代码 | 规则不复杂，但表单、审批、看板、台账和迭代速度要求高 | 复杂权限、复杂同步、复杂审计和大规模数据治理 | 平台能力边界会限制深度定制 |
| 定制开发 | 差异流程直接影响收入、交付、合规或客户体验 | 只是“看起来更像自己的系统” | 必须接受需求、测试、运维和持续改进成本 |
| 混合方案 | 通用模块可复用，关键差异必须掌握在自己手里 | 想一次性把所有事情都塞进一个系统 | 要把接口、迁移、日志、权限和退出边界写清楚 |
AHAX 判断：通用流程优先复用标准化系统，关键差异流程再考虑定制。不要因为供应商有默认模块，就让你的业务去适配它。
这张表不是给报价看的，是给管理者决定路线看的。
| 方案 | 适合时机 | 优点 | 代价与约束 | 退出条件 |
|---|---|---|---|---|
| 暂不建设 | 问题不稳定、数据不齐、owner 不明 | 不会把错误固化成系统 | 痛点暂时还要靠人工处理 | 连续两轮梳理后仍说不清损失与责任，就继续停 |
| 优化现有工具 | 现有工具只差口径、表单、字段和责任 | 成本低，推进快，阻力小 | 维护分散，易回到旧习惯 | 如果优化后仍然无法形成闭环，再考虑升级 |
| SaaS | 行业流程标准，管理诉求更强 | 启动快，实施快，供应商负责一部分运维 | 平台边界、套餐变化、数据导出都要看 | 发现核心差异无法表达，转为混合或定制 |
| 低代码 | 规则不重但变化快，需要快速试错 | 配置快，适合内部台账和轻流程 | 深层权限、复杂同步和审计能力有限 | 当流程开始涉及多系统主数据时，不要硬撑 |
| 定制开发 | 流程差异直接影响经营结果 | 业务贴合度高，数据和流程更可控 | 需求、研发、测试、上线、运维都要承担 | 若 owner 不在场或验收不明确，暂停立项 |
| 混合方案 | 标准化与差异化同时存在 | 保留标准能力，关键闭环自己掌握 | 接口、迁移和边界管理更复杂 | 一旦接口不稳或责任边界不清，先收缩范围 |
外部证据只能支持标准化复用、互操作和分层推进，不会直接替你证明“必须自建”或“必须上云”。这部分最终仍然是 AHAX 判断。
这一章的实施，不是直接开工，而是先做两周发现。两周的目的不是写完方案，而是把问题、边界和优先级收敛到能决策。
两周发现流程
Section titled “两周发现流程”| 天数 | 主要动作 | 负责人 | 交付物 |
|---|---|---|---|
| 第 1-2 天 | 访谈业务 owner、一线人员和管理者，收集损失样本 | AHAX 方案方 + 业务 owner | 问题清单、损失样本、现有工具清单 |
| 第 3-4 天 | 画流程断点，列出每一步的输入、输出、责任人 | 业务 owner + 一线代表 | 流程图、断点图、责任草案 |
| 第 5-7 天 | 统一对象、字段、状态和口径，检查数据能否拿到 | 产品/实施 + 业务 + IT | 主数据草案、字段表、现有系统边界 |
| 第 8-10 天 | 做方案分组，判断暂不建设、优化、SaaS、低代码、定制或混合 | 管理者 + 业务 owner | 方案对比表、初步优先级 |
| 第 11-12 天 | 用一个最小闭环做验收方式草拟 | 业务 owner + 测试/实施 | 验收清单、测试场景、证据要求 |
| 第 13-14 天 | 复盘并冻结第一期范围，决定继续、暂停或换方案 | 管理者 | 一页问题说明书、立项建议或暂停结论 |
| 角色 | 主要责任 | 必须参与什么 | 不承担什么 |
|---|---|---|---|
| 管理者 | 定优先级、定边界、定资源 | 结论评审、冲突拍板、退出判断 | 不替代业务 owner 写流程 |
| 业务 owner | 定规则、定验收、定例外 | 访谈、流程确认、验收签字 | 不把责任推给 IT |
| 一线代表 | 提供真实操作细节 | 还原步骤、异常、例外和手工绕路 | 不只给“理想流程” |
| 实施/产品 | 把问题变成可执行的方案 | 流程拆分、字段定义、原型和测试 | 不替业务做经营判断 |
| IT/技术 | 判断接口、权限、日志、备份和维护方式 | 系统边界、集成、部署和恢复验证 | 不替代业务 owner 决定规则 |
权重优先级模型
Section titled “权重优先级模型”这是 AHAX 判断 用的排序模型，不是行业平均值，也不是统一标准。它采用 500 分制：每项只能取 0、1、2、3、4、5 中的一个整数分，不允许半分或其他小数，再乘以权重百分数的数值；六项权重合计 100，最高分为 5×100=500。0 分表示没有证据或条件完全不具备，5 分表示证据充分、条件成熟。它把“感觉重要”改成“能比较”。
| 因子 | 权重 | 评分口径（0-5 分） | 低分意味着什么 |
|---|---|---|---|
| 发生频率 | 20% | 每周/每天是否稳定出现 | 只是偶发，不急着建 |
| 经营损失 | 25% | 损失是否会影响收入、交付、成本或客户关系 | 损失可忽略，先优化 |
| 流程稳定性 | 15% | 规则是否足够稳定，能否写成步骤 | 规则还在变，先别固化 |
| 数据可得性 | 15% | 关键数据是否已经存在或可补齐 | 没有数据口径，先统一 |
| owner 投入 | 10% | 业务负责人是否能持续参加 | 没人负责，就别上系统 |
| 验收可测性 | 15% | 能否写成明确的测试和证据 | 只能“感受好用”，不能验收 |
公式很直接。这里的 20、25 等整数就是 20%、25% 等权重在 500 分制中的计算系数：
总分 = 频率×20 + 损失×25 + 稳定性×15 + 数据×15 + owner×10 + 验收×15
AHAX 示例（非客户案例）
Section titled “AHAX 示例（非客户案例）”| 候选闭环 | 频率 | 损失 | 稳定性 | 数据 | owner | 验收 | 总分 |
|---|---|---|---|---|---|---|---|
| 报价返工闭环 | 4 | 5 | 4 | 3 | 5 | 4 | 420 |
| 客诉跟进闭环 | 3 | 3 | 3 | 4 | 4 | 4 | 340 |
| 月度报表自动化 | 2 | 2 | 5 | 5 | 3 | 5 | 345 |
计算示例：
4×20 + 5×25 + 4×15 + 3×15 + 5×10 + 4×15 = 420
另外两行也可以复算：
3×20 + 3×25 + 3×15 + 4×15 + 4×10 + 4×15 = 340
2×20 + 2×25 + 5×15 + 5×15 + 3×10 + 5×15 = 345
| 500 分制区间 | 下一步 |
|---|---|
| 420–500 | 进入立项论证：核对预算边界、技术路线、治理责任和停止条件，再由管理者决定是否立项 |
| 340–419 | 先补证据：增加真实样本、异常场景和一线访谈，修正评分后再评审，不直接进入开发 |
| 250–339 | 先做小范围流程优化或现有工具试验，用实际结果验证损失是否值得系统化 |
| 0–249 | 暂不建设：保留问题记录，指定观察指标和复查时间；条件变化时再评估 |
AHAX 判断：四档阈值只用于内部排序和确定下一步，不代表行业平均，也不是自动立项结论。即使达到 420 分，管理者仍要结合现金流、合规约束、机会成本和负责人投入作出最终决定。
这两周最后要交什么
Section titled “这两周最后要交什么”- 一页问题说明书。
- 一张流程断点图和对应的真实样本数据。
- 一张方案对比表和可复算的优先级评分表。
- 一组关键场景与后续验收草案。
- 一份写明责任人、建议路线和退出条件的管理者决策记录。
如果最后拿不出这五样，就不要进入正式建设。继续开会也不会把问题变清楚。
建设最容易死在三件事上：范围膨胀、责任悬空、数据不对。下面这张风险矩阵要和第一期范围一起看。
| 风险 | 影响 | 负责人 | 早期信号 | 应对方式 | 退出条件 |
|---|---|---|---|---|---|
| 范围不断膨胀 | 预算和注意力被摊薄，最小闭环迟迟不能验证 | 业务 owner | 今天加一个字段，明天加一个部门，后天加一条流程 | 冻结“最小闭环”，超出的放路线图，由管理者确认变更优先级 | 连续两次范围评审仍无法冻结，暂停建设并重做问题说明书 |
| 业务 owner 缺位 | 规则无人确认，供应商只能猜，最终无人承担采用结果 | 企业管理者 | 会议很多，但关键规则没人拍板，评审反复改口 | 书面指定业务 owner，明确其评审、样本提供和决策时限 | 发现阶段结束仍无 owner 或 owner 无法投入，停止立项 |
| 数据口径不一致 | 同一指标算出多个答案，迁移和报表都失去可信度 | 数据归口负责人 | 同一个对象有多个名字、多个表、多个版本 | 先建立字段字典、来源优先级和争议裁决人，再讨论系统 | 两周内仍无法确定关键字段口径，转为数据治理或现有工具优化 |
| 接口或同步不稳定 | 重复录入、漏单和状态延迟继续存在，自动化反而制造新差错 | IT/技术负责人 | 依赖多个旧系统，字段经常对不上，接口权限迟迟拿不到 | 先验证接口、导入导出和失败补偿路径，必要时采用混合方案 | 关键数据无法稳定取得且没有可接受的人工兜底，取消该技术路线 |
| 上线后没人维护 | 故障、权限变更和业务规则调整无人处理，系统快速失效 | 企业管理者与运维负责人 | 交付前仍没人接手，也没有维护责任和预算 | 在立项前指定运维责任人，明确变更、故障、备份和升级责任 | 正式开发前仍无维护责任人或资源安排，暂不建设 |
AHAX 判断：退出条件不是失败，而是止损。该停的时候停，该改路线的时候改路线，比硬推一个不完整系统更省钱。
这里要把两种验收分开。两周发现阶段验收的是“问题是否足够清楚，是否值得进入下一步”，不是验收一个已经建成的系统；项目交付或上线验收，才检查系统是否按约定工作。
发现阶段验收
Section titled “发现阶段验收”| 验收证据 | 谁来出具 | 通过标准 |
|---|---|---|
| 一页问题说明书 | 业务 owner + 管理者 | 问题、损失、边界、方案和退出条件都写清 |
| 流程图和断点图 | 业务 owner + 一线代表 | 每一步都能对应到责任和数据 |
| 样本数据包 | 一线代表 + 数据归口负责人 | 正常、异常和边界样本都能追溯来源，关键口径无悬而未决的冲突 |
| 优先级评分表 | 方案负责人 + 管理者 | 权重合计 100，分项有证据，计算可复算，区间对应明确下一步 |
| 场景与验收草案 | 业务 owner + 一线代表 | 写明关键场景、预期结果、异常处理和未来需要保留的证据，但不声称已经跑通系统 |
| 责任人决策记录 | 管理者 | 写明 owner、建议路线、继续或暂停决定、理由和下一次复查条件 |
发现阶段的通过，不等于项目已经立项，更不等于系统可以上线。它只说明管理者拿到了足以继续论证、补证据或停止建设的材料。
项目交付/上线验收提示
Section titled “项目交付/上线验收提示”进入建设后，才需要按项目边界验收真实场景是否跑通，以及权限隔离、数据导出、操作日志、备份恢复、故障处理和交接维护是否留下证据。这些项目交付项不是两周发现阶段产物，也不能因为发现报告写了“计划支持”就视为通过。涉及 Web 与后台边界时继续看第 5 篇：网站与业务后台；涉及多端、账号、权限与同步边界时继续看第 6 篇：多端系统。
AHAX 判断：本章结束时，管理者只对“问题说明书和下一步决策是否合格”签字，不对尚未开发的权限、日志或恢复能力提前签收。后续项目是否完成，要以真实环境中的交付验收证据为准。
这一章最重要的学习作业，不是查更多资料，而是写出一页问题说明书。写完之后，再去找方案。
一页问题说明书怎么写
Section titled “一页问题说明书怎么写”| 一页字段 | 只写什么 | 目的 |
|---|---|---|
| 问题是什么 | 用一句话说清业务痛点 | 让大家先对同一个问题说话 |
| 损失在哪里 | 写次数、时长、金额或差错 | 把“很烦”变成证据 |
| 断点在哪里 | 写哪一步、谁和谁之间断了 | 找到系统可能介入的位置 |
| 现有工具是什么 | 列出表格、表单、IM、CRM、OA 等 | 先判断能不能优化现有工具 |
| 候选方案是什么 | 暂不建设、优化、SaaS、低代码、定制、混合 | 把路线摆到桌面上比较 |
| 风险是什么 | 写 owner、数据、接口、维护 | 提前知道哪里会翻车 |
| 验收怎么看 | 写证据，不写感觉 | 防止把演示当结果 |
| 退出条件是什么 | 写到什么程度就暂停或换路 | 防止越做越大 |
- 先访谈业务 owner，再访谈一线人员。
- 用一页纸把问题压缩到能看完、能签字的程度。
- 把一页纸拿去做一次 30 分钟评审，删掉没证据的句子。
- 如果第二次还写不清，就先停在优化现有工具或流程诊断，不要急着建系统。
AHAX 判断：写到第二页，通常说明问题还没有收敛。先收敛问题，再谈方案，效率更高。
最后核验：2026-07-15