销售部门想换客户管理系统，财务希望统一报表，运营提出自动化，技术团队还要处理旧平台。每个项目单独看都有理由，放在一起却可能争用同一批业务骨干和数据人员。
数字化项目排序的起点，是明确当前最需要改善的经营结果，再确认阻碍它的环节。只有找到了这个环节，才能判断系统、流程、数据和岗位分工分别需要改什么。
沿着一条业务链找问题
选定一个经营目标，把实现它的主要步骤画出来，并给每一步找到可核对的记录。交付慢，可能是排产能力不足，也可能是订单信息反复确认；销售跟进慢，可能是线索没有分配，也可能是根本无人承接。
不要过早把现象命名为“缺一个系统”。可以先观察几笔真实业务，问清谁在等待、等待什么、如何知道事情已经完成。样本未必能代表全局，但能帮助缩小接下来调查的范围。
若问题主要来自权责不清，先明确处理规则；若规则已经稳定，重复操作占了大量时间，再评估自动化；若数据口径无法统一，先解决定义和责任。这样形成的项目，才与目标有清楚的连接。
先处理不能等待的事项
已确认的重大安全风险、数据完整性问题或其他必须履行的要求，需要进入相应的风险处理机制。它们不应与普通效率项目一起比短期回报。
其余项目再讨论优先级。对同一类改进，至少准备三个选项：维持现状并加强管理、先做有限范围改进、进行较完整的建设。选项不同，投入、可逆性和见效条件也不同，避免讨论一开始就被某套采购方案限定。
用四个维度把分歧摊开
经营价值：影响什么，有多少证据
写清预期变化对应的业务指标和基线。节约处理时间、减少差错、降低损失风险，可以有不同的验证方式，不必全部强行折算成收入。
收益估计要标出依据和不确定性。能够直接观察的损耗，与建立在多重假设上的增长机会，应分开陈述。项目演示效果和供应商承诺不能代替本企业的证据。
启动条件：现在能否做成
检查业务负责人是否有时间参与，流程是否足够明确，关键数据是否能使用，技术依赖是否可满足。还要问上线后由谁运营，谁处理异常，费用和工作量是否已纳入计划。
某个条件欠缺，不一定否定整个项目。但应拆出具体准备任务，避免用开发进度掩盖前提尚未成立的事实。
协同成本：谁的工作会被改变
列出涉及的岗位和关键决策，特别是需要改变权责、指标口径或考核方式的部分。项目跨部门较少，也可能因一项关键权限长期悬而未决；涉及部门较多，也可能已有成熟的协作方式。因此，不能只数部门数量。
核心问题是依赖是否明确、分歧由谁裁决，以及被改变工作方式的人能否参与验证。
复用潜力：后续哪些场景真的会使用
统一客户标识、接口和指标定义，可能减少后续重复建设。但“未来所有业务都能用”不是足够的立项理由。
优先让当前场景提出具体要求，再核对已知的后续需求。尚不确定的通用能力可以预留扩展空间，避免先建一套庞大平台再寻找使用者。
评分用来讨论，容量用来排期
可以给四个维度设置少量等级，并为每档写清证据要求。权重根据当前经营目标协商，不必照搬固定比例。协同成本要明确高分究竟代表成本低还是难度高，避免不同人反向评分。
若分数接近，优先查看依据是否可靠、项目是否可分段验证。对打分分歧最大的地方安排调查，往往比继续调整小数点更有效。
排序之后还要检查实际容量：同一位骨干是否出现在所有项目里，业务部门能否同时配合，测试和上线窗口是否冲突。没有可用资源的第一名，也不能直接变成开工指令。
三个任务池，各有不同去向
执行池放价值清楚、条件基本具备的项目，明确负责人、阶段结果、资源和验收方法。
准备池放值得做但缺前提的项目。每项必须写出缺什么、谁补齐、何时检查，以及满足什么条件才进入执行池。它不应成为没有期限的等待区。
暂缓池放当前关联弱、投入不合算或存在更好替代办法的项目。注明重评触发条件；没有合理后续用途的项目可以取消，避免反复占用讨论时间。
情境示例：一家企业想同时上线客户管理、经营报表和销售预测。若客户标识重复、销售阶段定义不一致，可以先选一个销售流程试点，同时整理必需数据。报表限定在能核对的指标，预测项目进入准备池，等数据和使用场景得到验证后再判断。转入下一阶段的条件，应包括数据可核对、业务负责人确认用途，以及试点出现足够的使用证据。
启动时就约定何时暂停
阶段复盘至少确认：原目标是否仍成立，条件是否按计划补齐，投入是否超出边界，已完成部分是否被使用，以及是否出现更低成本的替代方案。
负责人无法持续参与、关键依赖无法在需要的时间满足、收益假设被证据推翻，都应触发重新决策。暂停要同时安排系统、数据和已有承诺的收尾，避免形成新的维护负担。
真正的优先级会体现在资源变化上：哪些项目获得了完整投入，哪些只做准备，哪些明确停止。本季度具体启动几个，取决于组织能承接多少，而不是目标清单能列多长。