业务基线之所以在数字化选型中居于前置位置，是因为它直接决定了选型问题的性质。多数企业习惯从“我们需要什么系统”出发，但系统只是手段，真正要回答的是“当前业务在哪个环节消耗了成本、拖慢了交付、制造了错误”。没有基线，选型就会退化为功能清单的比对，而功能多寡与业务改善之间并没有必然联系。一个能够被核对的现状描述，才能把选型从“技术偏好”拉回“业务问题”。
建立基线不需要一开始就建设复杂的数据仓库，关键在于口径稳定。对首个试点场景而言，通常只需围绕高频业务动作收集最小数据集：业务量、处理时长、人力投入、异常情况、业务影响和数据来源。这里容易犯的错误是把“审批效率提升”这类表述直接当作目标，却没有说明它指的是平均处理时长还是超时单量；也没有界定成本计算覆盖的是直接人工、返工成本还是机会成本。口径不一致，后续所有验收都会失去依据。即便数据暂时不完整，也可以用连续抽样记录代替，但必须标注样本范围、统计周期和估算方法，否则不能作为项目成效的正式依据。
基线的作用不只是提供对比数字，更在于暴露流程断点。业务部门提出的“需要一个系统”“希望自动化”往往只是不满的表达，不是真实需求。信息重复录入、责任交接不清、关键数据不可见、规则依赖个人经验、异常缺少反馈机制，这五类断点才是需要被技术方案回应的对象。值得注意的是，这些断点并不都需要新系统解决，有些源于职责不清，有些源于制度不一致，有些只是字段定义混乱。如果流程本身没有理顺，直接把原有问题搬进系统，只会让低效流程变得更稳定地低效。
选型的技术判断也应建立在基线之上。一个场景是否适合引入自动化或智能化工具，要看数据是否可用、判断规则是否清晰、错误成本是否可控，以及结果能否被验收。技术热度不能替代业务需求，人工智能和智能体只有在数据条件与规则边界都满足时才有实际价值。这也是为什么首个项目通常不应从企业级大平台开始——平台建设范围广、周期长、参与部门多，短期内很难证明业务成果，而一个范围可控的场景更容易形成闭环验证。
最终，业务基线决定了选型是“可验收的改进”还是“不可证伪的投入”。当企业面对多个候选场景时，可以用业务价值、痛点强度、数据条件、落地难度和复制价值五个维度做横向比较，但评分不是制造精确的数学结论，而是让不同部门在同一套标准下讨论。一个场景即使价值很高，如果数据完全缺失、责任边界不清、业务负责人不愿参与，就不适合作为第一刀。先处理一个价值略低但更容易形成结果的场景，再把方法和经验迁移过去，通常比押注一个高风险的大项目更稳妥。