实施帮助台的四点建议
最后笔者想谈谈在实施帮组台过程中需要注意的几个问题：
①知识项目必须是持续完善的。在导入初期，公司的知识项目一定是不完善的，因为你没有办法真实地模拟出用户提问时的场景；所以刚开始的时候重点并不是你的知识覆盖率有多高，而是你能不能尽快地进入改善循环。上线时不要对知识项目有过多的要求，在未来的日子中自然有制度会帮你监督这件事情，只要持续关注帮组台给你的报告就可以了。
②减轻导入过程中的抵触心态。不可讳言，导入前期知识项目的整理对于工程师来说是一件相对烦琐的事情，所以有个别人员有些想法也是很正常的情况。笔者的建议是，如果IT员工抵触是因为烦琐，那可以与工程师沟通：“所谓‘长痛不如短痛’，这是一次性的工作，以后类似的问题就不需要再重复处理了”；如果有极个别的人认为把知识分享出来以后自己会没有价值，那这种人还是早点让他离开，这样的人不但自己不能进步，也会影响大部队的前进。
③用IT工具配合导入。以明基为例，我们把帮助台系统跟全公司的电话交换机做了整合，以确保每个电话（包括通话时间）都被记录下来，有利于进行持续分析。如果没有这个条件的话，笔者建议至少有一个系统可以手工录入一些关键的字段，这样才能发挥出帮组台的真正功用。
④分阶段上线。所有的系统一起上线肯定是不现实的，很多的制度规范也需要持续完善。刚开始的时候，我们把上线范围控制在基础架构这一块，成功以后再往应用系统推广。因为CIO需要一个成功典型来向老板以及部门同仁证明这个项目的可行性，而基础架构部分是最容易导入的，无疑是很好的选择；同时CIO应尽量选择用户最多的系统，一是因为这样效益比较容易体现，二是因为用户少的系统一般来说系统负责人都跟用户比较熟，要改变用户习惯让他们改找帮助台不是一件容易的事。
