系统上线，逐渐交接到内部团队的手里面；

　　知识转移，各种技术交付物都要消化学习。

　　为用户答疑，解决技术问题，

　　将异常处理，收集优化建议；

　　System Admin的日常，日日夜夜似瞎忙。

　　直到有一天，偶然看到ITIL宝典，

　　参照其理念，梳理系统运维实践。

　　ITIL 是信息技术服务管理中方方面面的最佳实践库，同时也有相应的认证考试。它是之前我们聊过的ServiceNow等ITMS系统背后的理论基础。

　　参考ITIL中的概念，我将HR系统管理员的工作理解为：将四类系统运行中的反馈（事故、监控事件、服务请求和改进建议）进行全面地收集，科学地处理，最终有序地产出为两类输出（系统变更和知识库）。

　　云端系统的一个好处是，在系统上线后也能持续、快速的优化系统、根据业务实际需求调整业务规则、甚至添加新的功能，而无需动到代码。此前介绍过的加密PDF分发就是一个例子。

　　HR系统管理员要主动识别、收集改进机会（improvement opportunity）。

　　案例：我们发现员工总对员工档案中某个区间有疑惑，就在这个区间加上相关知识库文章的连接；

　　发现经理在休假前常常不记得设置流程自动转授权，就设置自动提醒的规则；

　　发现用户总在一个应该点插入新记录的地方点了修改原记录，就设置在点了修改原记录后报错的规则；

　　发现HR每天要下载同一份报表再做二次加工，我们就将设置好过滤条件和格式报表每天定时发送。

　　HR系统管理员还要鼓励用户多多反馈系统的改进建议，哪怕是抱怨甚至投诉。用户使用系统、反馈问题、持续优化，这才是一个良性的循环。管理员动不了代码改不了系统的底层设计，但系统可以通过配置实现的扩展，也能帮助我们一点一点提升用户体验。

　　系统的不断演进，也帮助了在人力资源部甚至整个企业内培养持续改进的意识与文化。

　　收集到改进机会，管理员要统一记录、评估优先级、考虑如何衡量改进效果、与各方沟通。

　　对于比较复杂的改进或业务调整，管理员还要主导业务分析（Business Analysis）。这类改进建议通常由HR提出。通过沟通、分析，管理员（有些公司有专门的业务分析师）要能定义出其中的需求，提出能满足需求或者解决问题的建议方案。

　　建议方案要能提升实际的工作效率，因此并不限于变更系统功能，也可能是线上功能改进、线下处理方式改进、甚至业务流程改变的结合。

　　在此之后，才是验证和测试技术方案、计划系统变更。

　　验证与测试（Validation & Testing）

　　为了系统的新功能、新调整能达到预想的要求，而不会带来新的问题，在生产系统变更之前都应该在测试系统做好验证与测试工作。

　　对于SuccessFactors的管理员来说，做得最多的复杂调整就是改Business Rule了。写Business Rule的条件语句并不算太复杂，但有些错误是靠检查语句很难发现的，要靠各种场景的操作测试，结合Business Rule Log中记录的结果才能定位和解决错误。

　　回归测试（regression test）是最容易被忽略的测试。我们除了要测试新的功能、新的调整是否按照我们的预期执行了，还要回过头来测试原本一直正常的原有功能会不会因为这次调整反倒不能正常运行了。实践中，这样的情况并不少见。

　　云端HR系统的变更，主要是指各种系统配置调整，这些调整要有计划。

　　变更的原因可能是因为原有问题的修复、原有功能的改进、业务调整、新需求新功能等。

　　SuccessFactors上线后主要的变更内容有Buiness Rules、报表、Dynamic Role、权限设置、版本升级后新增的配置点、数据结构等。管理员需要在实践中掌握这些技术、积累测试经验。

　　即使是验证过的变更，也不一定马上会在生产系统实施。

　　变更管理就是为了平衡变更带来的风险和收益，变更都要有评估、排期和相应的授权。变更被分为三类：

　　标准（Standard）: 主要是需要定期完成的规定动作，风险已充分了解，步骤有标准的文档。比如管理员每年年底要调整下年的节假日及调休、每年七月要调整社保公积金配置。

　　正常（Normal）: 通常的情况，每次有这类变更都需要重新评估、排期，如果有审批流程的还要重新审批。

　　紧急（Emergency）：处理紧急、突发情况的变更，评估和测试尽量要按照正常类的来做，文档记录工作可以候补。

　　将变更进行分类，可以作为变更排期的依据。

　　变更排期（Change Schedule）能够让资源分配更科学、避免冲入、协助各方沟通。排期还应考虑影响业务的时段，要避开避开业务高峰期；有些变更与变更之间有逻辑关联必须按照特定的先后顺序执行，计划时也应考虑。

　　HR系统管理员处理要维护系统功能，还会要提供各种服务。

　　例如问询服务（用户来问这个功能在哪里找、哪个功能要怎么用）、数据导出服务（例如有些数据无法做成自助报表）、数据调整服务（例如有些数据的调整权限没给到员工/经理自助）、流程特殊处理（例如有特殊情况需要加签）。

　　管理服务请求，是为了保证服务质量。方法类似于管理事故，要有服务水平协议作为衡量标准，让用户和管理员对齐对服务请求处理的预期。

　　服务请求的处理要尽可能的标准化、自动化。

　　对于常见的请求、常见的问询，应该整理到知识库中，既保证服务的一致性，又逐渐培养用户自助去知识库找答案的习惯。

　　HR系统管理员在日常工作中处理事故、分析问题、变更系统、交付请求、解答问询，积累的经验都应该整理成文，在知识库中维护，以便在后续的工作中能够复用、分享，提高工作效率。

　　知识管理的目标，是保证所有的相关人员，都能在正确的时间、以合适的形式、在权限允许的内获得正确的、层次合适的信息。

　　系统实施的交付物，往往是几大本上千页的操作手册。这些手册是很难以帮助用户快速地找到解决方法的。

　　知识不是单纯的信息，而是可以在特定环境下可以使用的信息。

　　HR系统管理员要理解，是谁、在什么环境下需要这些知识。

　　在SuccessFactors中，我们也曾介绍可以使用Jam模块的知识库功能管理知识。可以针对不同的用户，比如普通用户、HR用户、系统运维团队创建不同的Jam Group，分别维护适用于他们的知识库文章，并按业务场景对文章进行分类和打标签。