【IT168 专稿】相信大家都听过PDCA（计划-执行-检验-处理）这个管理上常用的循环手段，简单说来，PDCA就是不断检验组织的计划执行状况并做出反应，使之处于一个持续优化的过程。在PDCA循环中，最重要的一点是：你必须知道如何检验自身的不足，才能有针对性地做出反应，进而更好地调整计划。对于IT部门来说，导入helpdesk（帮助台）就能帮助CIO们做好检验的工作。
引进帮助台的三个理由
笔者服务的公司在去年导入了帮助台。起初，我们只是很单纯的想要解决IT工程师在日常工作中由于重复性劳动所造成的资源浪费问题。所谓“好钢用在刀刃上”，工程师应该做一些规划性的工作，而不是花50%以上的时间去解决诸如“代理服务器如何设置”的问题。因此，我们把日常工作中这些没有“养分”的问题提炼出来，移交给帮助台的人员处理，将工程师解放出来做更有价值的事情。
所以刚开始的时候，我们完全是从“如何更有效使用资源”的角度来考虑导入帮助台的。而随着时间的推移，导入帮助台的好处也逐渐在其他方面显现出来了：
首先，在帮助台回答问题的时候，需要有一个知识库来支持系统的日常工作，所以工程师必须保障知识库中知识项目的有效性；而帮组台的人员能否依据知识项目来回答用户的问题，就是对这些知识项目最直观的检验。过去，我们一直想推动KM（知识管理），让工程师整理自己手边的工作成为KM的计划。但因为没有持续的检验措施，这项计划常常沦为口号，难以落实在日常工作当中。正是因为有了检验这些知识项目的人员，现在我们导入知识项目的覆盖率已经超过90%，取得了初步的成效。
其次，对于重复发生的问题，从管理的角度来说我们希望这些问题可以彻底解决，不要再发生。但是在没有帮助台这样的检验工具之前，这更多地只能依靠个人的觉悟，没有办法形成一个有效的制度。觉悟高的人遇到常发生的问题会找出其背后的关键原因，反之则习以为常，形成一种没有效率的循环。这种做法除了浪费IT部门的时间以外，还占用了用户的宝贵时间，更造成了IT管理上很大的潜在风险：谁也不知道这些积累的问题会不会在某天以系统崩溃的形式体现出来。但在有了帮助台之后，通过每周的数据分析，我们就可以很容易地掌握系统的运行情况；根据这些报告，CIO会要求相关负责人提出相应的改善计划，并在改善计划上线以后继续进入新一轮的监控，持续地发现问题、改善问题。透过这样的PDCA循环，IT服务管理也变得更科学、更制度化了。
实施帮助台的四点建议
最后笔者想谈谈在实施帮组台过程中需要注意的几个问题：
①知识项目必须是持续完善的。在导入初期，公司的知识项目一定是不完善的，因为你没有办法真实地模拟出用户提问时的场景；所以刚开始的时候重点并不是你的知识覆盖率有多高，而是你能不能尽快地进入改善循环。上线时不要对知识项目有过多的要求，在未来的日子中自然有制度会帮你监督这件事情，只要持续关注帮组台给你的报告就可以了。
②减轻导入过程中的抵触心态。不可讳言，导入前期知识项目的整理对于工程师来说是一件相对烦琐的事情，所以有个别人员有些想法也是很正常的情况。笔者的建议是，如果IT员工抵触是因为烦琐，那可以与工程师沟通：“所谓‘长痛不如短痛’，这是一次性的工作，以后类似的问题就不需要再重复处理了”；如果有极个别的人认为把知识分享出来以后自己会没有价值，那这种人还是早点让他离开，这样的人不但自己不能进步，也会影响大部队的前进。
③用IT工具配合导入。以明基为例，我们把帮助台系统跟全公司的电话交换机做了整合，以确保每个电话（包括通话时间）都被记录下来，有利于进行持续分析。如果没有这个条件的话，笔者建议至少有一个系统可以手工录入一些关键的字段，这样才能发挥出帮组台的真正功用。
④分阶段上线。所有的系统一起上线肯定是不现实的，很多的制度规范也需要持续完善。刚开始的时候，我们把上线范围控制在基础架构这一块，成功以后再往应用系统推广。因为CIO需要一个成功典型来向老板以及部门同仁证明这个项目的可行性，而基础架构部分是最容易导入的，无疑是很好的选择；同时CIO应尽量选择用户最多的系统，一是因为这样效益比较容易体现，二是因为用户少的系统一般来说系统负责人都跟用户比较熟，要改变用户习惯让他们改找帮助台不是一件容易的事。
