新系统上线已经三个星期。开发验收通过了，数据也搬过去了，供应商不再来联系。然后您路过办公室，看到的是：行政同事的屏幕上还开着旧的电子表格，技术员还在用 WhatsApp 发工作详情，而新系统里只有上周一半的订单。没有人故意刁难，大家只是在下午选了对自己最快的做法。
本指南写给刚刚上线或即将上线定制业务系统、并希望团队真正用起来的中小企业老板和经理。内容涵盖上线后的头 30 天：谁来负责系统、怎样培训、何时停用旧做法、怎样处理抱怨，以及怎样知道大家是不是真的在用。这是一般性的指引，不代表任何供应商的培训或支持承诺，而且讲的是人和习惯，不是软件。
为什么系统上线后会失败
通过测试的系统，在日常使用中仍可能失败。原因多半出在人身上，而且相当好预料：
- 大家守着旧做法。电子表格、笔记本或 WhatsApp 群还能用，人人都熟悉，也没有什么逼大家改变。两种方式同时开着，旧的就会赢，因为它不费力气。
- 新做法第一天更慢。在表单里输入一份工作，比在纸上写几笔更费时间，对用了多年旧流程的人尤其如此。好处（更少出错、报表即时可见、不用重复输入）多半落在老板和办公室，而不是录入的人身上。
- 没有人负责。供应商建好了，老板很忙，每位员工都以为别人会解答问题、修复小毛病。抱怨散落在各个聊天群里，什么也没有定下来。
- 培训只讲功能。两小时把每个菜单走一遍，周五之前就忘光了。人们记得住的，是星期一早上必须做的那五件事。
这些都不是技术问题，所以多加软件也解决不了。解决它们靠的是老板在头几周做出的几个决定。
指定一位负责人：系统“带头人”
在公司内部选一个人，每天负责这个系统，也就是系统带头人（system champion）。通常不是老板，也不是技术最强的人，而是了解工作实际怎么流转、受同事尊重、也愿意发问的人。小公司里，这往往是办公室经理、运营主管或资深行政。
带头人第一天不必是专家。他的工作是做同事第一个询问的对象、收集问题，并成为与供应商联系的唯一窗口。要给他真正的时间（头几周每天一两个小时是合理的），并当着团队的面说清楚，否则这会变成晚上做的副业。
| 职责 | 实际做法 |
|---|---|
| 第一联系人 | 同事先问带头人，而不是老板或供应商 |
| 维护反馈记录 | 把每条抱怨和问题记在同一个地方（见下面的模板） |
| 主持“演示给我看”环节 | 别人卡住时，到对方的座位或柜台旁陪十分钟 |
| 关注使用情况 | 每周查看几个简单数字，向老板汇报 |
| 对接供应商 | 发一份整理好的清单，把故障和变更请求分开 |
| 有一位指定的后备人选 | 请假或生病时可以顶上的第二个人 |
老板的角色同样明确：自己也用这个系统，要报表就从系统里拿，不要从旧表格拿；有人说“我还是用老办法”时，支持带头人。如果老板还在要电子表格，团队就会让它一直活着。
按真实的日常任务培训，而不是按功能
最常见的培训错误是把菜单逐个讲一遍。员工用的不是“客户模块”，而是接电话、排工作、查看还有什么未完成、开报价单。请围绕这些工作，按角色设计培训，并用本周的真实例子。
对大多数小团队，一个简单的做法就够了：每个角色一次 20 分钟的任务演示，一页纸的速查表，之后有人卡住时再做“演示给我看”的小环节。演示时用真实（或接近真实）的数据，让大家看到自己的客户和产品，而不是演示用的假数据。如果您做过用真实任务进行的用户验收测试，可以把当时的脚本直接拿来当培训材料。
| 角色 | 20 分钟演示涵盖 | 一页速查表包含 |
|---|---|---|
| 柜台或销售人员 | 查找或新增客户，开报价单或订单，查看状态 | 带截图的五个步骤，找不到客户时怎么办 |
| 外勤或技术人员 | 在手机上打开当天的工作，更新状态，添加备注或照片，结束工作 | 手机怎么登录，三种状态，打不开时找谁 |
| 办公室或行政人员 | 把报价单转成发票，记录付款，更正录错的内容 | 按顺序排列的每日流程，常见更正，月底步骤 |
| 经理 | 批准申请，查看每日摘要，找出逾期事项 | 各报表的位置，怎样批准，怎样提出变更 |
| 老板 | 您真正会用到的两三个画面或报表 | 每份报表回答什么问题，这样就不再需要电子表格 |
速查表只要一页，用员工真正读得懂的语言（英文、马来文或中文），配上真实截图和按钮上的原话，并贴在干活的地方。简短的“演示给我看”胜过冗长的课堂：在对方座位上用他自己的任务讲十分钟，比一小时的幻灯片更有效。如果系统有多种用户角色，每个角色的访问权限决定了各人看到什么，所以请按他们实际会看到的画面来培训。
定下切换日期，停用旧做法
切换日期（cut-over date）是旧电子表格或旧流程不再作为工作记录处所的那一天。没有这个日期，新系统就变成“多出来要填的一样东西”，重复录入也会悄悄变成长期习惯。
与团队一起选定日期，至少提前一两周公布，并写成文字。到了那天，把旧做法设为只读：把电子表格另存为只读副本，移到归档文件夹，并不再接受通过聊天发来的工作详情。“X 日之后不得重复录入”的规则很简单：切换日期之后，一条记录要么在新系统里，要么就不存在。
态度坚定不等于强硬。对关键记录，安排一段短暂的并行期是合理的，比如一两周内，把月底数字或发票与旧表格核对，并由一个指定的人负责比对。关键是并行期有结束日期，而且普通员工不必把所有东西都输入两遍。这是对新系统的核对，不是人人多做一份工。
怎样上线（所有人同一天切换，还是一次一个分店或一个流程）是另一个决定，应在上线前做出；本指南假定日期已定，重点放在日期之后发生的事。如果您还在判断系统何时能完成，请看定制业务系统要花多长时间；如果旧记录还要迁移，请读把数据迁入新系统。
头 30 天计划，逐周安排
第一个月决定习惯能不能留下。下面是一个可按需调整的简单计划；日期并不重要，重要的是每周都有人看数字。
| 时间 | 重点 | 要做的事 |
|---|---|---|
| 上线前 | 做好准备 | 指定带头人和后备人选，定下切换日期，打印速查表，进行 20 分钟任务演示，建立反馈记录 |
| 第 1 周 | 现场帮助 | 带头人在场、随叫随到；每天简短碰头；记下每个问题；小问题当天修；旧表格设为只读 |
| 第 2 周 | 消除摩擦 | 一起检查记录；区分故障和变更请求；给供应商发一份整理好的清单；公布已解决的事项，让大家知道意见被听到了 |
| 第 3 周 | 查看数字 | 查看使用情况指标；找出还有谁、哪项任务绕开了系统并问清原因；有需要就再做“演示给我看” |
| 第 4 周 | 补上缺口 | 结束并行期；确认月底报表出自系统；决定哪些变更请求要做；约定今后怎样报告问题 |
请预期头一两周会觉得更慢。这种下滑很正常，事先知道的团队，把它当成失败的可能性要小得多。第一天就明说：“接下来几天会慢一点，我们会修掉拖慢大家的地方。”
头几周由谁来回答问题
人卡住了又没人在身边，就会放弃系统。请提前决定谁回答什么，并用一条消息告诉所有人。
- “这个怎么做？”带头人，他不在时找后备人选。先看速查表，再来一次快速的“演示给我看”。
- “这个好像不对或坏了。”带头人记录下来，尝试重现，并判断这是使用失误、故障还是变更请求。
- “它能不能改成这样？”带头人记为请求，之后由老板决定（见下一节）。
- 给供应商的问题。只有带头人联系供应商，一次说清，让供应商收到的是一份整理好的清单。
上线之前，请先问供应商：上线后您能得到什么支持、持续多久，并要求书面答复。本指南无法告诉您任何供应商提供什么。
应对抵触：听出真正的摩擦点
有人说“我不喜欢新系统”，请把它当作信息。多数时候，抱怨针对的是某一个具体步骤，而且对方说得没错。先坐下来看他做一遍任务，再下判断。
| 您听到的话 | 可能真正的意思 | 有用的回应 |
|---|---|---|
| “比我的电子表格慢。” | 确实多了一步、必填项太多，或者熟练度还没练出来 | 一起计时；删去不必要的栏位；练习快捷操作 |
| “我找不到。” | 标签不清楚，或者从没人教过那个画面 | 做一次“演示给我看”；补进速查表 |
| “它不符合我们的做法。” | 最初需求里漏了某种情况，或某个例外只存在于大家脑子里 | 附上真实例子，记为变更请求 |
| “旧办法也挺好。” | 习惯使然，或怕在同事面前显得慢 | 重申日期，私下提供帮助，避免当众比较 |
| “我忘了。” | 干活的那一刻没有提醒去用系统 | 把这项任务放进每日流程；让带头人的碰头成为习惯 |
并非每个要求都是故障。以前能用现在不行，或与约定内容不符的，是供应商应当修复的故障；您想要的新东西则是变更请求，由老板评估价格和排期。把两者分清，与供应商的争执就会少很多；上线后的软件维护：故障与变更解释了两者的区别和各自怎么提。第一个月的好做法：快速见效的修复马上做，较大的要求先放进“以后再说”清单，到第 30 天大家一起决定，这样团队看到意见被听取，系统也不会天天都在变。
也要留意规律。如果三个人卡在同一步，那一步就该修。如果有人一直躲着系统，先私下问清是什么挡住了他，不要先认定是态度问题。
把反馈集中在一个地方
分散在六个聊天群里的抱怨，没法统计、排序，也没法逐条回答。请只用一份反馈记录（共享表格或表单），并告诉所有人：不在记录里，就当它没发生。带头人负责这份记录，并每周与老板一起检查。
| 日期 | 谁 | 发生了什么（一句话） | 类型 | 状态与负责人 |
|---|---|---|---|---|
| 第 2 天 | 柜台员工 | 用电话号码找不到回头客 | 问题 | 已回答，已补进速查表（带头人） |
| 第 3 天 | 技术员 | 保存后工作状态仍显示“未结” | 可能是故障 | 已附截图发给供应商（带头人） |
| 第 6 天 | 行政 | 希望列表里增加“应收余额”一栏 | 请求 | 放入“以后再说”清单，第 30 天决定（老板） |
四条规矩能让记录保持有用：每条一行，必须有日期和姓名，要有类型（问题、可能是故障或请求），状态要让人一眼看懂。条目关闭时要告诉当事人。一份没人回应的记录，只会教会员工不必费这个事。
用简单的方法衡量使用情况
要知道大家有没有在用，并不需要仪表板。每周检查几个简单的指标就够了。挑两三个，每周把数字记在同一个地方。
| 指标 | 怎么查 | 说明什么 |
|---|---|---|
| 录入系统的订单或工作所占比例 | 把系统里的数量与您从其他渠道知道的数量对比（已开发票、已完成工作、收到的消息） | 工作是否真的走新流程 |
| 切换日期之后电子表格的修改次数 | 查看旧文件的“最后修改”日期或版本历史，数一数该日期之后有几次修改 | 旧做法是否真的退役了 |
| 完成一项典型任务所需时间 | 在第 1 周初和第 4 周各计时一次常规任务（例如开一张报价单） | 随着大家熟练，摩擦是否在减少 |
仅作示例，数字是虚构的：一家维修服务公司一周完成 50 项工作，在系统里找到 38 项，约 76% 已录入。如果接下来两周升到 44 项再到 49 项，说明习惯正在形成。如果停在 38 项，就去查是哪些工作漏了、由谁处理，再问问是什么挡住了。
怎样才算好？没有放之四海而皆准的基准，因为这取决于您的业务和您的人。更合理的目标其实很简单：第一个月结束时，几乎所有工作都经由系统，电子表格不再被修改，常规任务用时不比旧做法长，老板从系统里读报表。如果某项指标一个月后仍然持平，请把它当作需要调查的问题，而不是对团队的定论。
清单：头 30 天
- 一位系统带头人和一位后备人选，并为这个角色留出时间。
- 以书面公布切换日期，当天把旧电子表格或旧流程设为只读。
- 仅在需要时安排简短的并行期，有结束日期，并有一人负责。
- 每个角色一次 20 分钟的演示，以真实的日常任务为基础。
- 每个角色一页速查表，打印后放在干活的地方。
- 一份反馈记录，每周检查，已关闭的条目要回复当事人。
- 每周记下两三个使用情况指标。
- 为变更请求设“以后再说”清单，并在第 30 天开会决定。
常见错误
- 让两种做法无限期并存。没有切换日期，旧做法就会一直留着。
- 每个功能都培训。只教各角色在普通星期一要做的事。
- 没有指定负责人。问题四处散落，小毛病永远没人修。
- 把抱怨当成态度问题。多数抱怨里藏着值得修的真问题。
- 老板自己还在用电子表格。团队跟着老板的要求走。
Gotka Technologies 的角色
Gotka 的应用与系统开发服务可开发手机应用、网络应用和业务系统，网络应用和仪表板起价 RM8,000，业务系统和系统对接起价 RM12,000，手机应用起价 RM15,000（均为参考起价），待需求明确后以书面报价为准。本指南属一般性建议，并不介绍任何培训、交接或支持条款，因此请要求任何供应商（包括 Gotka）把上线之后会发生的事写成书面。如果您还在判断要不要自建，请看企业已超出电子表格的信号；想向开发者说清需求，请看首次沟通前要准备什么。针对具体类型的系统，也可参考报价转发票自动化、员工考勤、请假与报销、客户门户、多分店管理和简单的 CRM。欢迎通过联系页面与我们团队联系。
本指南中的关键术语
- 上线（go-live）：新系统开始用于真实工作的那一天。
- 切换日期（cut-over date）：旧电子表格或旧流程不再作为工作记录处所的那一天。
- 系统带头人：每天负责系统、并作为问题第一联系人的那位内部人员。
- 并行期：有计划的短暂时期，期间对比新旧记录，通常只针对关键记录。
- 重复录入：把同一信息既录入旧系统，又录入新系统。
- 速查表：按角色编写、带截图的一页日常任务指南。
- 使用率（adoption）：人们在真实工作中实际使用系统的程度。
- 变更请求：新增或不同的功能，区别于故障，即某处没有按约定运作。
新系统上线后，员工为什么还在用旧的电子表格？
通常是因为没有什么逼大家改变，而且旧做法第一天更快。两种方式同时开着，电子表格不费力气，又没有人负责新系统或解答问题。解决办法在人：指定系统带头人，定下一个切换日期，之后旧文件只读，并按每个人自己的日常任务来培训。
公司内部应该由谁来负责新的业务系统？
指定一位专人，称为系统带头人，通常是办公室经理、运营主管或资深行政，要了解真实的工作流程并受同事尊重。他是大家第一个询问的对象，负责维护反馈记录、每周检查使用情况并联系供应商。请为这个角色留出固定时间，并指定一位后备人选以备请假。
应该怎样培训员工使用新系统？
按真实的日常任务培训，而不是按功能。为每个角色安排一次 20 分钟的演示，讲它自己的任务并使用接近真实的数据；再配一页带截图、用员工读得懂的语言写成的速查表；员工卡住时，到他们座位上做简短的“演示给我看”。如果有验收测试的脚本，可以直接再利用。
“X 日之后不得重复录入”是什么规则？
切换日期之后，一条记录要么在新系统里，要么就不存在，旧电子表格改为只读。不必苛刻：对发票或月底数字等关键记录，安排一段短暂、有计划的并行期是合理的，要有结束日期并由一人负责，这样普通员工就不必把所有东西都输入两遍。
怎样知道团队是不是真的在用新系统？
每周检查几个简单指标：录入系统的订单或工作占比（与其他渠道得出的数量对比）、切换日期之后旧电子表格被修改的次数，以及完成一项典型任务所需的时间。没有放之四海而皆准的基准，所以目标是第一个月结束时，几乎所有工作都经由系统完成。
员工抵触新系统时该怎么处理？
把抱怨当作信息。看他把任务做一遍，因为摩擦往往出在一个真实的步骤、缺少的栏位或没教过的画面。快速见效的修复马上做，较大的要求放进“以后再说”清单，把故障和变更请求分开，并提供私下的帮助，而不是当众比较。冷静地重申切换日期。