**OA系统实施范围怎么定，关键不是先列“一期做什么、二期做什么”，而是先判断每一条需求有没有资格进入一期。**更实用的办法，是让每条需求依次通过四个条件：**不做会不会阻塞上线、规则是否已经稳定、外部依赖是否就绪、这件事到底该不该由OA承担。**华天动力OA可以用流程、表单、权限、报表、接口和数据等模块化能力承接不同建设内容，但项目范围仍应先由业务目标决定。
财政部《政府采购需求管理办法》要求，采购需求应当清楚明了、表述规范、含义准确；需要供应商提供解决方案时，应说明功能、应用场景、目标等基本要求，并尽可能明确客观、量化指标。这个规则面向政府采购，不是所有企业OA项目的强制标准，但它提供了一个很有价值的范围管理原则：需求只有先说清楚目标、场景和验收条件，才适合进入正式建设范围。
先问最简单的问题：
这一项不做，核心业务还能不能切到新OA？
例如：
这类需求更接近“一期刚需”。
相反，如果只是：
即使有价值，也未必需要阻塞首期上线。
华天动力OA的魔方架构把流程、门户、表单、报表、接口和数据等能力模块化，企业可以先围绕核心业务启用必要能力，再逐步扩展，不必为了“功能完整”把所有模块一次性铺开。
有些需求很重要，但业务部门自己还没有定下来。
例如：
“集团合同审批要统一。”
继续追问可能发现：
这类需求如果强行进入一期，实施人员只能一边配置、一边等制度变化，返工概率很高。
更适合的处理方式是先标成：
高价值，但规则未冻结。
等制度、角色、条件和例外规则清楚后再正式配置。
系统可以通过条件流程、节点权限和表单配置承接已经明确的管理规则，但不能替企业完成制度决策。
有些需求本身并不复杂，难点在别的系统。
例如：
“OA一期必须显示ERP供应商状态。”
这条需求还要继续确认：
如果第三方接口还没有开放，OA单方面无法完成闭环。
在华天动力OA实际集成项目中，可根据第三方系统条件采用实时、定时或批量方式，并结合REST、SOAP/WebService、ODBC等方式交换数据；这些事实只能证明产品有多种集成手段，不能证明所有外部依赖都能由OA项目独立解决。
因此，外部依赖没准备好的需求，不一定适合硬塞进一期关键路径。
最后一关经常被忽略。
企业容易把“OA能做”理解成“OA应该做”。
例如：
如果专业系统已经承担权威业务，把整套专业功能重新搬进OA，反而可能产生两套数据和两套规则。
其当前技术架构强调模块化组合、低代码配置和开放集成。更合理的边界通常是：
OA负责协同和管理规则，专业系统负责专业业务，双方通过数据和流程连接。
一条需求进入一期前，可以依次问：
四问之后，需求通常会落到四种结果：
| 结果 | 处理方式 |
|---|---|
| 必须且已就绪 | 进入一期 |
| 有价值但不阻塞 | 进入二期 |
| 规则/依赖未成熟 | 暂缓，先完成前置条件 |
| 属于专业系统职责 | 留在专业系统，通过OA集成 |
这样确定OA系统实施范围，比先列几十个模块再分一期、二期更容易控制项目边界。
评估华天动力OA时也应使用同一方法：先确定需求凭什么进入一期，再决定由成熟模块、流程配置、低代码还是系统集成承接。产品能提供的是建设手段，企业仍要先确定建设边界。
