系统上线之后，谁来对它负责

先说结论

• 系统上线只是换了一个阶段：签完验收单，结束的是以月计的项目实施期，以年计的使用期才开始；业务、人员、数据都在变，总得有人把这些变化带进系统。
• 没有人负责时，系统会一步步走下坡：主数据慢慢失真，规则没人更新，电子表格回来了，懂的人走了，最后只剩一小部分在用。
• 「对系统负责」至少包含五件事：主数据维护、规则与参数调整、培训新人、收集需求并判断轻重、与供应方对接；合适的人选懂业务、能在部门之间协调口径、有时间，并有老板的授权。
• 可以把「判断」和「执行」分开：业务上改不改、改得对不对由企业自己的人判断，技术实现可以请外部服务商；上线后头几个月，先指定系统负责人、收拢系统旁边的电子表格、建问题与需求登记簿、定期核对主数据。

系统上线那天，通常是整个项目里最热闹的一天：实施人员还在现场，各部门的骨干刚培训完，老板在会上讲几句话，大家对着新界面录入第一张单据。验收单签完，很多企业心里会松一口气：这件事办成了。

从系统的角度看，那一天只是开始。一套管理系统往往要用上好几年，这几年里订单结构会变，产品会换代，人员会流动，工艺会调整。系统能不能跟着这些变化走，很大程度上关系到几年以后它还在不在用。

本栏目《二十余年企业信息化的观察》归纳过一条规律：系统停用的原因，多在软件之外，其中之一是上线之后没有人负责持续维护。这篇文章把这一条展开来谈。如果您的企业刚上线或正准备上线一套系统，可以对照着看。

本文只谈今天企业里在用的管理系统，例如进销存、ERP、车间管理、生产排程这一类。文中引用的研究与文件均注明出处，列在文末；我个人的看法集中放在「以下是我的观察」一节。

为什么说系统上线只是换了一个阶段？

研究企业系统的学者很早就把「上线之后」单独拿出来看。Markus 与 Tanis 在 2000 年提出一个企业系统的经历周期，把整个过程分为四段：立项、项目实施、上线磨合、持续改进 [1]。后两段和本文关系最大：

• 上线磨合期：企业开始真正接住这套系统，直到进入正常运转为止。这一段的典型工作是修正错误和返工、调整系统性能、再培训，以及临时增加人手来应付效率下降 [1]。
• 持续改进期：从正常运转开始，一直延续到系统被升级或被替换。企业要到这一段，才能真正看清这笔投资有没有回报。典型工作是持续改进业务、继续提升使用者的技能、做上线后的效益评估；作者特别指出，这些「典型」工作常常没有人做 [1]。

签完验收单，结束的是项目实施期；系统的使用期从这时才开始，前者以月计，后者以年计。

软件工程领域有一条相近的观察。Lehman 根据 1960 至 1970 年代在大型软件项目中的经验，提出过一组软件演化定律 [4]。其中第一条叫「持续变化」：一个软件系统如果不持续调整以满足新的需要，在使用者眼里会越来越不好用 [4]。这条定律针对的是嵌在现实环境里、需求随环境变化的系统 [4]，企业的管理系统正是这一类。它所处的环境至少有三样东西在变：

• 业务在变：新客户带来新的订单类型和交期要求，产品换代带来新的物料和工艺路线，客户审核带来新的追溯要求。
• 人员在变：参与实施的骨干调岗或离职；新员工没有经历过上线培训，只能跟着老员工学「怎么点」，不清楚「为什么这样设」。
• 数据在变：物料编码一天天增加，设备有增有减，供应商在更替，工时定额和良率随着工艺改进而变化。

系统本身不会自己跟上这些变化，总得有人把变化带进系统。

没有人负责时，系统会怎样走下坡？

系统停用，常常是一条缓慢的下坡路，每一步单独看都不算严重。

第一步，主数据慢慢失真。 主数据是指物料、产品、客户、供应商、员工这类业务对象的基本资料 [3]；在工厂里，设备、工艺路线、工时定额通常也归在这一类。新物料来不及建档，先借用一个相近的编码；设备换了，系统里的产能参数没改；工时定额还是几年前测的。Haug 等人 2011 年的研究指出，数据质量的维护工作常常被忽视，质量差的业务数据是不少企业一项可观的成本 [3]。主数据一旦不准，建立在它上面的计划、成本、库存都会跟着偏。

第二步，规则没人更新。 排产的优先顺序、审批的流转条件、库存的安全量、报工的口径，都在上线时按当时的业务设好。业务变了，规则还是原样。系统算出来的结果越来越「不对劲」，使用者开始不信它。

第三步，电子表格回来了。 系统的结果不可信，计划员就在旁边另开一张表自己算，系统里只补录一个结果应付检查。Markus 与 Tanis 记录过一个相似的现象：上线磨合期里，一线人员为了应付早期问题采用了变通做法，问题解决以后，变通做法却没有撤掉 [1]。变通做法固定下来以后，系统就只剩下「录入」的用处，真正的管理又回到了表格和聊天群里。

第四步，懂的人走了。 同一篇研究指出，持续改进期的一个常见问题，是那些理解「当初为什么这样配置」、也知道怎样借助系统改进流程的人员流失了 [1]；而在上线磨合期，企业又容易过度依赖项目组里懂系统的少数人，没有把相关知识和技能分到各个相关岗位 [1]。人一走，配置背后的理由也跟着走了，后来的人不敢改，也不知道该怎么改。

第五步，系统只剩一小部分在用。 Jasperson 等人 2005 年的综述写道，IT 使用者往往只用到很窄的一段功能，使用深度偏低，也很少主动去扩展已有的功能 [2]。走到这一步，系统名义上还在用：财务照常记账，生产模块却已经闲置，直到某一次换系统的讨论里被正式放弃。

这五步有一个共同点：发现问题的人一直都有，缺的是能把问题带回系统、改好、并确认改对了的人。

「对系统负责」具体包含哪些事？

「要有人对系统负责」这句话，说出来容易流于口号。拆开看，至少包括下面五件事。

这五件事里，技术动作只占一部分，大部分工作要求懂业务、了解本厂的规矩。Haug 等人的研究还提出一个务实的观点：数据质量没有必要追求完美，改进到某个合适的水平即可，关键是找到维护投入与数据问题造成的损失之间的平衡点 [3]。对中小企业来说，这意味着主数据维护的目标是让系统算出的结果够用；而「够用」的标准，需要有一个人来定。

系统负责人这个角色，放在谁身上合适？

这个角色在企业里有不同叫法，「系统负责人」「关键用户」都有人用，本文统称系统负责人。叫法各不相同，要看的是下面几个条件。

懂业务，最好是系统的重度使用者。 排产系统的负责人，合适的人选往往来自计划或生产管理岗位；进销存系统则往往是熟悉采购和仓储的人。这个人要能判断一次改动在业务上对不对。懂一些技术会更好，但排在懂业务之后。

能在部门之间协调口径。 主数据和规则往往横跨几个部门：物料编码牵涉技术、采购和仓库，排产规则牵涉销售、计划和车间。系统负责人需要把各方的说法对到一处，这要求这个人在企业里说话有一定分量。

有时间。 如果这件事只是在原岗位之外「顺便」做，一忙起来就会被挤掉。比较稳妥的做法是写进岗位职责，给出大致的时间占比，并在考核里体现。

有老板的授权。 工业和信息化部办公厅 2022 年印发的《中小企业数字化转型指南》提出，实施企业数字化转型「一把手」负责制，构建适配的组织架构，制定绩效管理、考核方案和激励机制等配套制度；定期组织经营管理者和一线员工参加数字化培训；引导业务部门和技术部门加强沟通协作；有条件的企业可以探索设立专门的数字化转型部门 [6]。学术研究也有相近的结论：Nah 等人 2001 年综述企业系统实施的文献，归纳出 11 个关键成功因素，其中包括高层支持、项目倡导者（在企业内部推动项目的人），以及绩效的监测与评估，并把这些因素对应到从立项到持续改进的各个阶段 [5]。

具体到授权，建议至少把下面几条说清楚：

• 主数据的新建和修改，由系统负责人或其指定的人审核通过后才生效；
• 规则和参数的调整，有一个固定的「提出、评估、拍板」流程：系统负责人有权提议，涉及多个部门的，由老板或分管领导拍板；
• 需求的先后顺序由系统负责人排，各部门有不同意见可以提出，但不各自直接去找供应方；
• 系统负责人可以请各部门安排人员参加培训、配合数据核对。

缺了这些授权，系统负责人只能去「协调」；协调不动的时候，事情又会停在原地。

系统负责人由企业自己担任，还是请外部服务商？

Markus 与 Tanis 在描述持续改进期的主要参与者时，列的是运营管理者、最终使用者，以及 IT 支持人员，并注明 IT 支持人员可以来自企业内部，也可以来自外部；涉及升级时，供应方人员和顾问也可能参与 [1]。两种安排都常见，各有取舍：

一个常见的折中，是把「判断」和「执行」分开：业务上改不改、怎么改、改得对不对，由企业自己的人判断；技术上怎么实现、出了故障怎么修，可以请外部服务商承担。即使主要依靠外部服务商，也建议企业内部至少保留一位对接人：不必会做配置，但要知道系统里有哪些关键规则、为什么这样设，并能验收服务商交回来的改动。

这样分，也有经济学上的理由。《权力与预测》一书讨论决定权该交给谁时，列了四个条件：谁掌握做决定需要的信息，谁有相应的技能，谁的利益和企业最一致，谁能协调几个部门 [7]。业务取舍上，信息和后果都在企业里，这四条多半指向企业自己的人；技术实现上，技能在服务商一侧。书里还有一个提醒：系统按事先写进去的规则和参数自动运行时，写进这些规则的人，实际上就是在做决定的人。所以规则和参数的调整由谁提议、谁拍板，要和系统负责人的授权一起定下来。

上线后头几个月，最该做哪几件事？

上线磨合期是问题最集中的时候：前面各阶段留下的差错多在这时显现，一些临时的变通做法也容易在这时固定下来 [1]。下面几件事，越早做越省力。

1. 指定系统负责人，并当众宣布。 名字、职责、授权范围写成一页纸，在上线后的第一次例会上公布，让各部门知道有问题找谁。
2. 盘点并收拢系统旁边的电子表格。 问一问各岗位还在用哪些表格：能进系统的逐步进系统，暂时进不了的记下原因。当初为应付早期问题而采用的变通做法，问题解决以后要及时撤掉 [1]。
3. 建一本问题与需求登记簿。 一张共享表格就够：谁提的、什么问题、属于操作、数据还是功能、影响多大、怎么处理的。每周过一遍。
4. 定期核对主数据。 挑出最关键的几类，比如常用物料、设备产能、工艺路线，按周或按月抽查，看系统里的资料和现场是否一致。
5. 把配置背后的理由记下来。 每条关键规则、每个重要参数，为什么这样设，当时由谁拍板。持续改进期常见的人员流失问题，损失的正是这类「当初为什么这样配置」的理解 [1]，写下来就能留下一部分。
6. 准备新人培训材料。 按岗位整理一份简短的说明，最好配上本厂真实单据的截图，下一位新员工入职时直接能用。
7. 头几个月结束时做一次回顾。 对照上线时定下的目标，看哪些做到了、哪些没有、原因在哪里、下一步改什么。上线后的效益评估常常没有人做 [1]，而它正是决定下一步投入的依据。

《中小企业数字化转型指南》概括的思路是「从易到难、由点及面、长期迭代、多方协同」[6]。上线以后的这几件事，就是「长期迭代」落到日常里的样子。

以下是我的观察

以下是我个人的看法，没有统计数据支撑，读者可以对照自己的经验判断。

一、上线那一刻，常常是企业对系统投入精力最多的时候，也是投入开始明显减少的时候。 实施期里有项目组、有例会、有老板盯着；验收之后项目组解散，各人回到原岗位。我见过的系统里，用得久的，上线以后通常一直有一个人在照看它。

二、合适的系统负责人，往往是系统最大的受益者。 一个人如果每天靠系统的结果干活，系统不准，这个人最先难受，也就最有动力去维护它。负责维护的人和靠它干活的人如果是两拨人，维护就容易变成一份额外负担。

三、主数据维护是最不起眼、也最容易被跳过的一件事。 它不像新功能那样显眼，做好了也少有人注意。可排产不准、库存对不上、成本算不清，追到根上，常常是某几类主数据很久没有人核对过。

四、系统负责人的工作需要被看见。 这个角色做得好的时候，看起来像是什么也没发生：数据是准的，规则是新的，新人上手快。如果只在出问题时才想起这个人，这个角色很难长久。把这项工作写进职责、算进考核，本身就是一种支持。

上线那天，还应该一起定下什么？

系统上线后的几年，才是它真正产生价值的时间。这几年里，业务、人员、数据都在变，需要有人把这些变化带进系统。之后由谁来照看它、这个人需要什么授权和时间，值得在上线那天就和实施方案一起定下来。

作者所在的青岛艾普仕（APSer）以制造业深度定制化交付为主业。如果您正在筹备上线，或者已经上线了一套系统，欢迎交流上线之后的安排。

参考来源