制定数字计划前，先建立一份业务基线

很多技术项目从功能清单开始：网站、客户管理、自动提醒、报表、AI。问题是，同一个功能名称在不同企业里承担的责任完全不同。如果没有共同理解，团队会很快进入「大家说的是同一个词，想的却不是同一件事」的状态。

业务基线(Business Baseline)用一组简洁、可审核的文件，记录项目开始时企业怎样运作。它不是为了把企业写成一本百科全书，而是为了让后续决定建立在同一组事实之上。

基线应该回答哪些问题

一份实用基线通常包括六部分：

1. 企业与市场

• 企业提供什么产品或服务；
• 主要服务哪些客户；
• 客户为什么选择它；
• 业务通过哪些地区和渠道发生。

2. 当前目标

• 接下来六到十二个月最重要的业务目标；
• 哪些目标与数字化有关；
• 哪些只是想法，还没有获得资源承诺。

3. 核心流程

• 客户怎样发现、咨询、购买和获得服务；
• 员工怎样接手、批准、交付和跟进；
• 哪些例外最常发生。

4. 资料与工具

• 客户、订单、库存、付款或项目资料在哪里；
• 哪一份记录被视为最终事实；
• 哪些工具重复保存同一资料；
• 哪些帐号、域名和系统由谁拥有。

5. 角色与责任

• 谁作出业务决定；
• 谁执行日常工作；
• 谁审核结果；
• 关键员工不在时，谁能接手。

6. 当前问题和证据

• 哪些工作持续浪费时间；
• 哪些错误、延误或客户投诉反复发生；
• 问题出现的频率和影响；
• 团队已经尝试过什么。

文件不需要很长，但必须能被审核

小企业的第一版基线可以只有几页，加上两三张流程图或表格。比篇幅更重要的是，每一句话能否由负责人确认。

建议把内容分成三种：

• 已确认事实：负责人同意，并有资料或实际操作支持；
• 暂定判断：目前最合理，但需要进一步验证；
• 待确认问题：不同人说法不一，或尚未决定。

不要为了让文件看起来完整，把不确定的内容写成事实。标明未知，反而能保护后续决策。

让实际做事的人参与

只和管理层讨论，容易得到理想流程；只和一线员工讨论，又可能看不到商业目标和风险承担。

建立基线时，可以分别询问：

• 管理层：最重要的结果和不可接受的风险是什么？
• 一线员工：每天实际怎样完成，哪里最常绕路？
• 财务或行政：哪些资料必须准确，错误怎样影响结算？
• 客户接触角色：客户最常不理解、等待或抱怨什么？

把差异写出来，再由有权决定的人确认规则。

基线不是永久不变的真相

它记录的是某个时间点的共同理解。企业推出新服务、调整团队或改变市场后，基线也需要更新。

因此，每份核心文件应保留：

• 版本或更新日期；
• 修改了什么；
• 谁确认了这次改变；
• 哪些计划因此需要重新评估。

不需要复杂的文件治理。一个清楚的日期、负责人和修改记录，已经比散落在聊天里的决定可靠很多。

为什么这项工作本身就有价值

即使企业暂时不建设任何系统，一份经过确认的业务基线也可以用于：

• 培训新员工；
• 比较供应商建议；
• 识别重复工作和责任缺口；
• 规划预算；
• 在负责人离开时减少知识流失；
• 让未来项目更快进入有效讨论。

它把原本只存在于老板或资深员工脑中的知识，变成企业可以共同使用的资产。

一个最小可行的基线套件

如果希望从小开始，可以先完成四份内容：

1. 一页企业与目标说明；
2. 一张从客户进入到交付的核心流程图；
3. 一份工具、资料与负责人清单；
4. 一张按影响和频率排列的问题清单。

由关键负责人审核后，这四份内容已经足以开始讨论数字路径。之后需要的细节，应由实际项目逐步补充，而不是一开始就写一套没人维护的大型手册。

---

本文提供通用的业务基线方法。文件的深度应与企业规模、风险和当前决策相匹配。