表格较宽时，可以用键盘方向键或触控手势横向滚动查看完整内容。
企业准备开发订单、库存、生产、售后、客户或项目管理系统时，最容易犯的错，是先列几十个功能，再让软件公司按功能报价。
功能清单并不等于需求。真正决定项目能否落地的，是谁在什么情况下做什么、需要什么数据、发生异常怎么办，以及最后怎样证明系统可以使用。
下面这套 7 天方法，不要求企业先学会写专业需求文档。每天安排 60—90 分钟，由一名业务负责人牵头，邀请真正操作流程的员工参与，即可整理出第一版需求包。
开始前：先准备一个共享文件夹
建立以下 6 个文件，不需要购买新软件，用表格和文档就能完成：
| 文件 | 记录内容 | 最终用途 |
|---|---|---|
| 01-问题清单 | 当前最耗时、最容易错的事情 | 判断项目目标 |
| 02-现状流程 | 从开始到结束的真实步骤 | 找出系统边界 |
| 03-角色权限 | 谁查看、创建、修改、审核 | 设计账号和权限 |
| 04-数据字典 | 表格字段、来源、格式、负责人 | 估算迁移工作 |
| 05-异常清单 | 缺货、退回、撤销、重复等情况 | 避免只设计顺利流程 |
| 06-验收清单 | 输入、操作、预期结果 | 形成验收依据 |
另外收集正在使用的 Excel、纸质单据、聊天截图和旧系统页面。先复制样本并隐去身份证号、手机号、报价等敏感信息，不要把真实生产数据直接发送给尚未签约的第三方。
第 1 天：只写问题，不讨论功能
让参与者分别写下最近一个月遇到的具体问题。不要写“效率低”“管理混乱”，要写成可观察事实：
- 销售每天把微信订单再次录入 Excel；
- 仓库不知道哪个版本的发货单是最新的；
- 售后问题没有负责人和截止时间；
- 老板只能月底才看到应收款；
- 同一个客户在三张表里使用了三个名称。
给每个问题补四列：发生频率、涉及人数、出错后果、目前怎样补救。然后按“高频且影响交付”排序。
| 问题 | 频率 | 后果 | 第一阶段是否处理 |
|---|---|---|---|
| 发货单版本不一致 | 每周多次 | 错发、返工 | 是 |
| 月报排版耗时 | 每月一次 | 晚半天出报表 | 暂缓 |
第一阶段建议只选一条能够闭环的主流程。范围越多，不确定性越大。可同时阅读传统工厂数字化第一步怎么选，用“高频、影响交付、能够验收”三个条件筛选试点。
第 2 天：画出真实流程，而不是理想流程
选一个最近发生过的真实订单或工单，从结果倒推：谁收到信息、记录在哪里、交给谁、谁审核、什么时候结束。
每一步只写五项：
- 触发条件；
- 操作角色；
- 输入资料；
- 操作结果；
- 下一步接收人。
如果员工说“有时候不一样”，立刻记录分支。退货、插单、缺料、审批退回和客户改需求，往往比主流程更影响开发量。
最终把流程分成三类：第一阶段必须进系统、暂时保留人工、明确不在本项目内。这个边界会直接减少后期“我们以为包括”的争议。
第 3 天：整理角色与权限
不要只写“管理员”和“普通用户”。按实际职责列出销售、销售主管、仓库、财务、生产、客服、老板等角色，再逐项回答：
- 能看哪些部门和客户的数据？
- 能否新建、修改、删除？
- 修改已审核记录是否需要重新审批？
- 能否导出？导出是否包含敏感字段？
- 员工离职后，历史记录归谁？
| 操作 | 销售 | 销售主管 | 财务 |
|---|---|---|---|
| 新建订单 | 可以 | 可以 | 不可以 |
| 修改未审核订单 | 仅本人 | 全部门 | 不可以 |
| 审核价格 | 不可以 | 可以 | 查看 |
| 查看回款 | 仅本人客户 | 全部门 | 全部 |
权限表必须由业务负责人确认，不能让开发人员代替企业决定。涉及个人信息或经营数据时，还应遵守最小必要原则。《中华人民共和国数据安全法》把收集、存储、使用、加工、传输等都纳入数据处理活动，企业应在需求阶段明确数据用途和责任边界。
第 4 天：建立数据字典
从现有表格中挑一张最常用的，逐列记录：字段名称、示例、是否必填、来源、格式、是否敏感、由谁维护。
例如“客户名称”是自由填写还是从客户档案选择？“金额”是否含税？“完成时间”由系统自动生成还是员工填写？这些规则不明确，后续报表就很难可信。
抽查最近 30 条记录：
- 同一对象是否有多个名称；
- 日期、单位和编码是否统一；
- 必填字段是否大量为空；
- 是否存在合并单元格或备注里藏数据；
- 旧数据需要全部迁移，还是只迁近一年。
把“数据清洗”和“系统开发”分开估算。旧数据越乱，越不适合承诺一次导入成功。
第 5 天：补齐异常和通知
用“如果……怎么办”开会：如果库存不足怎么办？审批人请假怎么办？订单撤回怎么办？接口失败怎么办？重复提交怎么办？
每个异常都要确定系统动作、负责人和通知方式。
| 异常 | 系统动作 | 负责人 | 恢复条件 |
|---|---|---|---|
| 审批被退回 | 保留原记录并标记原因 | 创建人 | 修改后重新提交 |
| 重复客户 | 阻止保存并显示候选记录 | 销售主管 | 合并或确认新建 |
| 消息发送失败 | 记录失败状态，可重试 | 系统管理员 | 重试成功或人工确认 |
第 6 天：把需求写成可验收场景
将模糊功能改成“前置条件—操作—预期结果”。例如不要写“支持权限管理”，而要写：
已创建成都销售组与重庆销售组。当成都销售登录时，只能看到本组客户；主管可以看到本组全部客户；财务可以查看两组回款但不能修改客户资料。
每条场景最好带一组脱敏样例数据。国家标准信息公共服务平台列出的 GB/T 25000.51-2016 涉及就绪可用软件产品的质量要求和测试细则。企业不必把一周盘点变成认证项目，但可以借鉴“要求要可测试”的思路：每个重要需求都应有可观察结果。
第 7 天：召开 60 分钟范围确认会
会议只确认五件事：
- 第一阶段解决哪个业务问题；
- 主流程从哪里开始、在哪里结束；
- 哪些角色、数据和接口在范围内；
- 哪些异常必须处理；
- 用哪些场景验收。
将尚未达成一致的事项放入“待决策清单”，写清负责人和截止日期，不要让它们悄悄进入开发。
交给软件服务商前的完整度检查
| 检查项 | 合格标准 |
|---|---|
| 项目目标 | 能说清要减少哪类错误或等待 |
| 第一阶段范围 | 有明确包含项和不包含项 |
| 流程 | 主流程及关键异常都有记录 |
| 角色 | 权限表已经业务负责人确认 |
| 数据 | 有脱敏样本和迁移范围 |
| 接口 | 已列系统名称、联系人和可用资料 |
| 验收 | 核心需求都有输入和预期结果 |
完成这些资料后，再请服务商评估原型、周期和预算，报价之间才更容易比较。预算还可以参考企业数字化项目预算拆解。
AHAX 能参与哪一段？
AHAX 的软件定制与 AI 应用服务通常从业务判断、范围梳理和必要原型开始，再决定是否进入开发。我们不建议企业在流程、数据和验收都不清楚时直接承诺一个“大而全”的系统。
如果你已经整理好上述 6 个文件，可以在联系页面说明行业、当前流程和第一阶段目标，方便双方先判断项目是否适合继续评估。
参考依据
- 国家标准信息公共服务平台：GB/T 25000.51-2016：用于说明软件质量要求与测试应形成对应关系；本文不表示项目需要或已经通过该标准认证。
- 工业和信息化部：《中华人民共和国数据安全法》：用于需求盘点中的数据范围、处理活动和责任边界提醒。
- NIST Secure Software Development Framework：用于提醒采购方在需求与交付阶段纳入安全角色、验证和持续维护，而不是上线后再补。