为什么要先修流程,再上系统,而不是同步进行
我们三次主导CRM上线(CRM implementation):一次在广告代理公司,一次在季节性企业礼品生产企业,一次在在线预约平台。三家公司,三个行业,三支团队。共同点只有一个:每一次,配置(system configuration)的第一个版本,都是把现有的工作方式原样搬进字段和状态里。
这正是决定项目命运的关键节点。如果上线前的流程里存在非必填字段、人工例外和「这里我们通常打电话协商」这类做法,这一切都会原样迁移进系统,并被赋予「正常」的地位。此后再修正的成本会大幅上升:混乱这时已经拥有了系统配置、集成和训练有素的用户。
系统不会替流程理清秩序——它只会把流程原样固化下来。上线前没有解决的一切,都会变成一项配置、一个例外、一种用户习惯,而修正成本会呈数量级上升。因此在项目启动前,必须解决三件事:必填字段(mandatory fields)清单、计算规则,以及角色之间的交接点(handoff point)。
系统上线到底固化了流程里的哪些问题
「系统固化混乱」这句话听起来像个比喻,直到把它拆解成具体的机制。一共有四种机制,每一种都能在上线后的头几周内观察到。
非必填字段(optional field)会永远空着。在配置阶段,「设成非必填,不然没人会填」这种说法几乎总能占上风。一个季度后就会发现,80%的记录里这个字段都是空的,根本没法据此做报表。哪些数据必填,这是一个流程决策,而不是技术决策,上线之后再来决定就已经太晚——这时只能靠事后补录。
例外情况会变成一个状态(status)。「这个客户我们要另外处理」在实施阶段看起来是件小事,于是就为它单独建了一个状态或者一种交易类型。一年后,这样的状态积累到十二个,而没有一个员工能说清楚其中四个之间的区别。每一个状态,都会在报表、权限和新人培训里各自分出一条支线。
口头约定会在系统里变得不可见。以前两位同事口头就能解决的事,系统里却什么都看不到:申请挂在某个状态上,而实际工作照常在推进。表面上流程在走,实际上工作绕开了系统,系统里的数据也就不再反映真实情况。管理者接下来依据的报表,描述的并不是正在发生的事。
凭经验计算的做法,会搬进一个自由文本字段(free-text field)。如果计算规则在上线前没有被明确固定下来,系统里就会出现一个「金额」字段,由经理手动填一个数字进去。系统看起来是上线了,但算法依旧是人工的——连同它以前带来的所有错误一起保留了下来。
| 上线前没有解决的问题 | 变成了什么 | 何时被发现 |
|---|---|---|
| 哪些数据必须填写 | 大多数记录里的空字段 | 第一次尝试做报表时 |
| 什么算例外情况 | 十几个没有实质区别的状态 | 培训新员工时 |
| 角色之间的交接点(handoff point)在哪里 | 工作绕开系统进行 | 报表与实际情况不符时 |
| 金额按什么规则计算 | 供手动录入的自由文本字段 | 与财务对账时 |
| 谁是流程责任人(process owner) | 谁嗓门大,谁就能改配置 | 两三个季度后,问题集中爆发 |
这五行有一个共同点——发现问题的时机。没有一个问题会在项目进行中暴露;它们全都是在项目正式收尾之后才浮现出来的,那时实施团队已经解散,预算也已经花完。
ERP和CRM实施超支超期的比例有多高
企业系统实施情况一直有人在持续跟踪统计,得到的结论相当一致:问题不在技术,也不在供应商身上。
超过四分之一实施过ERP的企业表示项目超出了预算,另有近四分之一表示项目超出了计划工期。
这里必须先做一个说明,而且是我自己主动加上的:这份报告出自一家专门做ERP实施陪跑业务的咨询公司。样本并非随机抽取——受访者是主动回应邀请参与的,很可能偏向该公司自己的客户和订阅者。这个数字只能当作数量级的参考,不能当作市场层面的精确测量。
平均而言,只有48%的组织级数字化举措(digital initiative)达到或超过了预定的业务目标。而在分析师归类为数字化转型领先者的那批企业中,同一指标为71%。
这是一份新闻稿,而不是完整报告:调查工具、数据采集周期以及问题的具体措辞都没有公开。这里真正有价值的不是48%这个比例本身,而是领先者与其余企业之间23个百分点的差距——它说明结果并不取决于是否上线了系统,而取决于系统周围的工作方式是如何组织的。
系统上线前应该先做的三件事
到第三次实施的时候,我们需要在启动前做出的一套决策已经固定了下来。这份清单很短,不需要分析师,也不需要额外预算——只需要流程责任人(process owner)投入时间。
第一项决策最让人不痛快,因为它关乎「禁止」。设置必填字段,意味着有人没法再用以前习惯的方式把工作做完,这会引来抵触。但恰恰是必填字段,才能提供当初购买这套系统所看重的报表能力——同样的机制,也是我们的报价单生成器能产生效果的根本原因。
第二项决策,是在能够计算的地方,把系统里的自由录入去掉。只要金额还是靠手工填写,就谈不上自动化——那只是一张用来做人工工作的电子表单。
第三项决策关乎角色之间的交接点。每一次交接都应该是系统里的一个事件,而不是口头约定。如果工作在两个人之间是靠口头传递的,系统里显示的和实际发生的就会是两回事。
另外要单独说明一下,这份清单里没有什么。清单里没有一份长达二十页、描绘「现状」的流程图,也就是常说的现状梳理(as-is process mapping)。这类描述几乎总会有人做,却几乎从来没人读,对上面三项决策也起不到任何帮助——因为它记录的是可观察到的行为,而决策关乎的是「应该是什么标准」。在我们第三次实施时,我们放弃了完整的现状梳理,把省下来的时间花在两天集中梳理必填字段上——这最终成了唯一真正影响结果的准备工作。
清单里没有的第二件事,是选择平台。这不是说选平台没有意义,而是它处于次要位置:上面三项决策,对任何一款主流系统的表述方式都是一样的,没有一项依赖具体供应商。如果顺序反过来,先选系统再讨论流程,就等于保证了关于「标准应该是什么」的讨论,会被限定在某个具体产品的功能边界里进行,而不是从业务本身出发。
为什么上线后修正流程成本更高
成本上的差异不是一种感觉,而是依赖关系的算术题。上线前,一项决策的改动只发生在文档里。上线后,同样一项决策的改动会牵涉配置、已经积累的数据、集成、报表和用户习惯,每一层都需要单独投入工作量。
在一个包含1471个IT项目的样本中,平均预算超支为27%,但每六个项目里就有一个属于「黑天鹅」项目,平均预算超支高达200%。风险集中在分布的尾部,而不是集中在平均值上。
这项研究我在关于工作量估算误差的文章里做过更详细的拆解。这里重要的是其中一点:超支并不是均匀分布的。凡是项目范围由系统功能而不是流程决策来决定的项目,恰恰会落入那条尾部——因为每一个被推迟的决策,最终都会以计划外工作量的形式冒出来。
系统上线前必须回答的四个问题
缺了哪些数据,一条记录就没有意义
列出三到五个字段。如果超过这个数量,你列的就不是「必须」,而是「希望拥有」。
这里由系统来计算什么
凡是能从其他数据推导出来的金额、期限和状态,都应该由系统自动算出,而不是人工输入。
工作在哪些地方转移责任人
把每一个交接点列出来。每一次交接都应该成为一个事件:谁交出、谁接收、什么时间。
谁有权修改系统设置
需要一个有权说「不」的人。没有这个人,一年后的系统配置反映的会是历年提出过的各种请求,而不是流程本身的逻辑。
如果这四个问题都还没有答案,那么实施项目其实还没有真正开始——目前进行的只是采购。
关于流程和系统上线的常见问题
上线CRM或ERP之前,是否必须先把流程完整描述出来?
完整描述不是必须的,但有三项决策必须做出:哪些数据必填、哪些内容由系统代替人来计算、角色之间的交接点在哪里。这三项决策只需要流程责任人参加几次工作会议,而它们对结果的影响,超过选择哪个平台。没有这三项决策,再完整的流程描述也救不了项目;有了这三项决策,通常也就不再需要完整描述了。
能不能一边上线系统,一边修正流程?
可以,但代价要付两次:先为旧流程做一次配置,再为新流程做一次重新配置,还要连同已经积累的数据一起迁移。当流程离开一个真正运转的系统就无法被理解清楚时,这种同步做法是合理的——但这种情况下,更诚实的说法是把第一阶段称为一次预先就打算返工的试点(pilot),而不是称为正式上线。
系统已经上线了,但流程依然混乱,该怎么办?
不要一次性把所有配置都推倒重来。挑一份管理者真正在用的报表,自下而上地把它过一遍:这份报表用到哪些字段、这些字段在多少记录里被填写了、数值又是从哪里来的。通常会发现,只要把两三个字段设为必填、去掉一个自由录入字段,这份报表就能开始反映真实情况。
这些决策应该由IT部门来定,还是由业务部门来定?
应该由流程责任人来定,也就是那个对结果负责、而不是对系统负责的人。分工是否合理有一个标志:IT部门回答的是「该怎么实现」这个问题,流程责任人回答的是「什么才算标准」这个问题。如果必填字段是由实施方来决定的,那就说明「什么是标准」这个问题从头到尾都没有人真正回答过。
「三次实施全部都是从原样照搬现有流程开始的」这一表述,指的是作者本人所在三家公司的CRM上线经历:一家数字营销代理公司(以Мегаплан作为记录系统)、一家季节性企业礼品生产企业,以及一家在线预约平台。文中列出的预先决策清单和流程分阶段方式,来自同一时期的客户交互规范文件。这些属于作者所在公司的内部资料,未经过独立第三方核实,仅作为说明机制的示例引用。文中五项被推迟决策的清单及其被发现的时间点,是根据这些实施经历回溯整理而成。
- Panorama Consulting Group. The 2026 ERP Report(对170家企业的调查,2025年1月—2026年1月)。panorama-consulting.com
- Gartner. Survey Reveals That Only 48% of Digital Initiatives Meet or Exceed Their Business Outcome Targets. 新闻稿,2024年10月22日。gartner.com
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 2011年9月。hbr.org