本文定位：匿名客户案例。它不是产品宣传稿，而是把一个常见的企业数字化问题拆成“背景—症状—方案—结果—经验”，方便你对照自己的情况判断。
一、背景：问题不是突然出现的
客户是一家项目型企业服务公司，销售订单不少，但老板总觉得利润不对。问题出在收入、成本、工时、回款分散在四套表里，项目结束后才知道赚没赚钱。
二、关键症状：真正卡住业务的地方
我们先把项目从“合同编号”改成经营对象：每个项目都有预计收入、预计交付周期、内部负责人、外采预算、回款节点和工时记录。员工不用填复杂日报，只选择项目和工作类型。
三、落地/救火路径：先收口，再扩展
系统上线后，每周自动生成项目利润预警：工时消耗超过预算 70% 但进度不到 50%，外采费用超过预算，回款节点临近但交付物未确认，都会提前提醒项目经理和老板。
四、结果：能被管理动作验证的变化
这套系统没有追求精确到每一分钟，而是让管理层提前看到趋势。以前项目亏损是事后复盘，现在至少能在交付中段发现风险并止损。
五、给同行的建议：别先追求大而全
项目型公司最容易犯的错，是只管签单不管交付成本。把销售、交付、财务放进同一张项目经营表，才是真正的数字化起点。
六、可直接照抄的检查清单
| 检查项 | 要问的问题 | 不合格信号 |
|---|---|---|
| 业务目标 | 这次项目到底要让哪个指标变好？ | 只说“提升效率”，没有具体场景 |
| 数据来源 | 关键数据现在在哪里、谁负责维护？ | 数据散在个人 Excel 和聊天记录里 |
| 责任闭环 | 异常出现后谁处理、多久复查？ | 只有提醒，没有责任人和复查机制 |
| 上线范围 | 第一阶段哪些必须做、哪些先不做？ | 一期就想覆盖所有部门 |
| 管理承接 | 上线后在哪个会议、哪个岗位使用？ | 系统上线后没人固定看 |
七、项目利润表不要一开始追求财务级精确
项目型公司做利润分析，第一阶段最容易卡在“每一分钱都要精确归集”。这会让员工填报负担太重，最后没人愿意用。这个案例里我们采用的是经营口径优先：先把项目收入、预计成本、已发生外采、内部工时、回款节点和交付进度放到同一张表里，允许部分成本按规则估算。
例如内部工时不要求员工写长日报，只选择项目、工作类型和耗时区间；外采成本以采购申请和报销记录为准；回款以合同节点和财务到账为准。这样得到的不是审计报表，但足够让老板提前看到风险：某个项目还没交付一半，工时已经烧掉七成；某个客户已经验收，但尾款迟迟没有跟进；某个项目报价很高，但外采成本也同步失控。
等团队习惯了这套经营口径，再逐步细化到人效、毛利、客户类型和项目经理维度。先让管理层每周愿意看、项目经理愿意改，系统才有继续深化的基础。
八、项目型公司要先统一“项目”这个对象
这个案例最关键的变化，是把项目从财务合同编号变成经营对象。过去销售看客户和合同，交付看任务和人员，财务看回款和发票，老板要判断利润时只能把几张表拼在一起。系统上线后，每个项目都有统一编号，并绑定客户、合同、交付负责人、预算工时、外采预算、回款节点和验收状态。
这样做的好处是，每个部门仍然处理自己的动作，但动作都回到同一个项目上。销售签单后，交付能看到承诺范围；交付消耗工时后，老板能看到预算变化；财务收到回款后，项目利润表能同步更新。
项目经营表不是为了替代财务报表，而是为了让管理层在项目进行中看到风险。等财务月末结账再发现亏损，已经很难补救。
九、利润预警要看趋势，不要只看结果
第一阶段我们没有追求精准到分摊每一笔办公费用，而是抓住几个会让项目失控的趋势：工时消耗过快、外采费用超预算、交付进度慢于回款节点、客户验收迟迟不确认、变更需求没有补报价。
这些信号一旦出现，系统就提醒项目经理和老板。提醒的目的不是追责，而是让项目中途有机会调整范围、补充报价、安排资源或暂停无效投入。项目型公司数字化的价值，往往就在这些提前两三周发现风险的节点里。
十、落地前可以先问自己的五个问题
第一，当前最痛的业务动作是什么，是销售漏跟、库存不准、项目亏损、数据口径不一，还是系统没人用？如果一句话说不清，说明项目目标还需要继续收敛。第二，这个动作今天的数据在哪里，是系统里、Excel 里、微信群里，还是某个人脑子里？数据越分散，第一阶段越要小。第三，谁是这个数据的负责人，谁有权决定字段口径和流程变化？没有负责人，系统上线后也会变成无人维护的表。
第四，异常出现后谁处理，处理结果回写到哪里？很多数字化项目只做到“发现问题”，没有做到“问题被处理并复查”，价值会卡在最后一公里。第五，老板或管理层准备在哪个会议里固定使用这套系统？如果上线后没有会议承接，大家很快会回到原来的汇报方式。
这五个问题的答案，比功能清单更重要。功能清单决定开发什么，五个问题决定系统上线后有没有人用、有没有人维护、有没有管理动作跟上。
十一、适合先做小诊断的企业画像
如果你的企业已经有一些系统，但数据分散、口径不一、老板看数还要等人导表，适合先做诊断；如果你的企业还主要靠 Excel、钉钉群和人工审批，也适合先做诊断，因为这时最重要的是确认第一阶段到底该系统化哪一段。
不适合一上来做大项目的情况也很明确：目标太泛，只说“全面数字化”；内部没人能拍板；历史数据没人愿意清；业务部门只想让 IT 自己解决；老板希望一次上线解决所有问题。遇到这些情况，先做 1 到 2 周的小范围梳理，反而比直接开发更省钱。
开沿通常会把诊断结果拆成三张图：业务流程图、数据流转图、一期范围图。三张图对齐后，再决定用标准 SaaS、低代码、钉钉二开、系统集成还是定制开发。这样做慢在前面，快在后面，也能减少上线后推倒重来的概率。
补充一点：第一阶段还要提前约定复盘节奏。上线后的前四周，建议每周固定看一次使用数据、异常清单和业务反馈，把必须改的小问题快速收掉，把“以后再说”的需求放进二期池。这样既能保护一期范围，也能让业务团队看到系统是在持续服务他们，而不是上线后就没人管。
十二、开沿的建议
如果你看到这里，最该做的不是立刻问“做一套多少钱”，而是先把当前流程画出来：数据从哪里来，谁加工，谁决策，谁执行，结果回写到哪里。只要这条链路不清楚，系统越复杂，后期越难维护。
开沿更愿意先做小范围诊断：选一个高频场景，确认数据和责任是否能闭环，再判断适合低代码、标准 SaaS、二开还是定制。这样预算更可控，也更容易让团队真正用起来。
