中小企业数字化的起点，通常藏在日常追问里：订单到哪了、库存为什么不准、客户多久没跟、项目是否超支、回款谁在催。把其中一条追问变成可记录、可提醒、可处理的业务链，比先确定一个“大平台”更容易判断价值。
从重复发生的现场收集问题
不要只让各部门提交功能愿望。让业务人员带着当前表格、单据、群消息和系统截图，说明问题在哪个节点发生、涉及哪些岗位、现在如何补救、结果由谁确认。
把“数据不透明”改写成可观察事实，例如订单状态需要逐人询问、同一库存有多个版本、销售离职后客户无人接手。描述越具体，越容易判断问题属于流程、数据、权限还是工具。
用业务条件决定第一阶段
候选问题可以从五个方面比较：发生是否频繁，是否影响收入、成本、交付或客户体验，是否需要跨部门协作，现有数据能否取得，是否有明确负责人。没有负责人拍板的项目，即使技术简单，也会长期卡在口径争议。
第一阶段不必选择全公司最复杂的问题。更适合的对象是边界清楚、关键岗位愿意参与、完成后能核对结果的业务链，例如销售跟进、订单交付、库存记录、项目成本或门店日报中的一个。
把痛点写成最小业务闭环
范围说明至少回答五件事：谁发起，记录哪些数据，经过哪些岗位，什么情况算异常，最终结果回到哪里。这样才能区分一期必需动作与暂缓功能。
以回款提醒为例，重点不是做一个提醒页面，而是应收数据从哪里来、逾期如何定义、提醒给谁、处理记录写在哪里、管理者如何看到未关闭事项。闭环定义清楚后，页面数量反而不是主要问题。
数据口径由业务负责人拍板
客户状态、订单完成、可用库存、项目成本和逾期日期等定义，需要对应责任岗位和数据源。各部门沿用不同 Excel 口径时，新系统只会把争论搬到线上。
可以围绕第一阶段单独整理字段、编码和历史数据，不必先治理全公司所有资料。无法确认的口径列成待决项，由负责人在开发或配置前关闭。
工具路线由问题边界决定
标准流程可以优先评估 SaaS；表单与轻流程可以评估低代码；多个现有系统之间重复录入时，重点可能是系统集成；流程特殊、权限复杂或需要长期控制核心数据时，再评估定制开发。
路线选择要同时检查数据出口、接口、权限、维护和退出方式。只比较采购价格，容易忽略实施和内部配合工作。
启动前确认人、数据和验收方式
业务负责人负责规则与范围，实际岗位提供样例并参加试用，系统管理员维护账号和基础配置，服务商负责约定的实施或开发。每类问题应有唯一的确认路径，避免所有人都能提需求却没人能做决定。
验收方式也要在启动前写清，例如一笔业务能否从发起走到关闭，关键字段是否唯一，异常是否有责任人，管理者能否看到未处理事项。第一阶段完成后，根据真实使用中的数据质量和流程卡点决定是否扩展，而不是按最初蓝图机械铺开。
