当IT部门增加新技术项目的时候，其员工人数却多年来保持不变。与此同时，终端用户越来越习惯于“自助服务”，IT部门应该遵循自助服务的工作原则吗？自助服务并不适用于所有情况——但是在IT有10个领域是它适合的。

ZD至顶网CIO与应用频道 10月05日 专栏： 当IT部门增加新技术项目的时候，其员工人数却多年来保持不变。与此同时，终端用户越来越习惯于“自助服务”，IT部门应该遵循自助服务的工作原则吗？自助服务并不适用于所有情况——但是在IT有10个领域是它适合的。

1、越来越多的测试流程自动化

通过设置用户测试账户和资源、授权用户，让他们在方便进行测试的时候可以登录到系统和应用中，IT部门就不用打电话请求应用测试设置了。活动日志可以根据用户名或者部门获取测试资源使用情况，如果测试是内部计费项目的话，IT部门可以将账单发送给不同的用户部门。

大多数站点已经采用了这种机制的各种方式，但是他们缺乏一个有序的测试资源配置流程，确保在测试之前就已经拥有测试资源（以及用户友好的服务终端），这样用户和IT部门就不用把时间花费在现场设置上。测试结果也可以自动进入处理流程，让用户在进行测试的过程中报告漏洞，然后这些报告会发送给对口的IT人员那里。当IT修复漏洞的时候，一个类似的自动通信会发送到发出请求的用户那里，这样他们就会知道问题已经被解决了。这种后端的自动化避免了大量的通信故障，使得个人可以在方便的时候，更好地着手自己的工作。

2、用户IT发送和更新

当IT中有越来越多流程自动化的时候，用户ID和密码的发送和更新可能仍然是一个需要大量手动操作的过程。通常情况下，当有新员工的时候，发送这些ID和密码会涉及到人力资源主导的流程。不过。如果用户域管理员有一个自助服务终端连接到他们可以发送IT新用户请求（或者拥有新权限的现有用户）的系统中，那么事情就方便多了。IT安全和网络人员可以从这里开始——当流程完成的时候，发送一个自动消息到域管理员那里。

3、数据保留策略

与用户ID发送和更新一样，数据保留也是一个需要手动执行的流程。将账户、人力资源、生产制造、销售等数据保留多长时间，这是在IT和其他部门经理的不同会议上要做出的决定——而且这些会议可能是冗长而乏味的。自助服务式的数据保留，可以避免这些一对一的会议，IT部门会发送出一个年度更新截屏给每个域的终端用户管理员，罗列出这个域中的数据资源，以及现有数据保留策略，向管理员询问是签署现有的策略继续执行，还是进行变更。然后这种自助式的更新会发送给IT数据管理员。数据保留审查的事务日志可以保存下来，以便审查人员在检查数据监管的时候进行查看。

4、收回和推送应用

新软件版本的分发也可以是自动化的，只需要简单地把这些版本从中央IT推送下至终端用户设备，只要当用户打开他/她的设备。相反，如果用户（或者IT）不需要完全自动化的更新流程，他们可以“收回”更新到他们的设备，接收到一个来自IT关于新版本发布的在线通知，选择是否下载。所有这些都可以在不用联系IT的情况下完成。

5、培训

关于新IT应用的培训，甚至是关于业务职能或者系统的课程，也开始完全是自助服务式的，终端用户登录到一个培训终端，选择他们想要在线进行的课程。

6、用户请求日志

最新的应用和系统增强可以自动进入自助服务工作流程，在这个流程中终端用户采用预设计的在线模板，这个模板描述了请求的特性或者功能，所在的应用，以及任何其他IT需要的细节，以便调度和完成请求。像这样的自助服务可以节省IT部门与最终用户的会议时间而直接对应用进行改进，把当面会议时间用到讨论更为复杂的系统更改上。

7、资产登记

如果IT是新硬件和新软件的中央采购代理，那么就可以设置一个面向用户新设备请求的自助服务终端，也可以让用户自己填写设备和软件接收文件。这些条目可以放到IT资产管理和追踪系统中，将有助于确保IT资产没有放错地方或者被遗忘。

8、修复

针对终端用户对修复设备的请求也可以实现自助服务和流程自动化——他们的请求会发送到一个IT服务域中。一旦修理在进行中，系统可以自动通知终端用户。

9、自助服务报告

在分析的时代，不同业务领域都很少意识到IT部门有大量可用的、可能是由其他业务部门一次性开发的关于公司活动报告。IT部门可以给这些报告创建一个让终端用户可以浏览和选择的汇总。

10、高峰时间云端资源配置

每年，不同企业领域都会遇到资源需求的“高峰期”，这时候他们必须增加平均IT资源消耗。这可能是销售部门，比如平时繁忙的推广，或者是财务部门，必须满足年终结算任务的资源密集型处理。IT通常了解这些需求的起伏——但是有些需求也可能是意外出现的。自助服务终端可以让终端用户获得额外的资源请求。

相爱相杀：移动联通IT支撑回忆录（六）

我写的不是小说，而是我的印象和记忆中，移动与联通有关IT支撑的历史往事。
在十数年间，双方相互学习、相互借鉴，同时又相互竞争、相互敌视，在不同的阶段交替领跑。
在这些现象背后有什么深层次的原因，又是哪些偶然的因素，造就两家运营商前台营销竞争激烈，后台支撑相爱相杀？
容我慢慢讲这段IT往事。
过五关斩六将，经分系统方得立项
打比方凑需求，数据仓库艰难起步
“我们先进行计费系统的集中，在此基础上再把营业账务集中了，然后才能进行客服系统的整合。之后，我们就可以基于这些系统的数据建设数据仓库，基于这些系统的应用推进电子商务。”这段话，是我在1998说的。
当时，在和省公司的计费部门座谈交流时，一些同事对实施移动电话省级计费系统集中化心存顾虑，而我则对未来充满了信心。
前几个步骤，移动扎扎实实地走了过来，尤其是BOSS集中化的实施，全方位地提升了支撑能力。
如同前几章所言，2001年做完了BOSS规范，启动了工程项目，业界的资源已经聚集在了中国移动周围，我们的判断是，这一仗赢定了，于是转头开始走下一步–建设数据仓库。
如果不是当年移动刚刚成功地做成了BOSS系统，那么经营分析系统的建设就不可能完成。
移动的经营分析系统是在规划为主、需求为辅的情况下启动的，如果不是对总部的指挥有信心，恐怕各省没有那么大的决心和动力，花钱建一套技术不成熟、需求不完备、投资相当大，而且当时战略价值不那么突出的系统。
而BOSS系统完成了系统数据的整合和支撑能力的提升，给数据仓库系统的建设打下了基础；BOSS的成功更树立了IT支撑队伍的信心，以及总部在系统规划层面的威望。
所以，我经常讲，最强大的执行力不是来自于上对下的权力，而是下级对上级的信任；虽然承担这种信任会有很大压力，但是这种上下同心同德，才是能做成大事的保证。
话题扯远了，回来再说移动数据仓库系统立项的艰难过程，看如今大数据的火热，难以想象当年做数据仓库系统的艰辛。
首先的难题，是要说服公司各级领导和主管部门，应该建数据仓库系统。
在大多数人看来，BOSS已经是投资巨大的IT支撑系统，有海量的数据，也购买了大量的硬件存储，为什么还要花钱再建一个数据仓库系统，直接在BOSS系统上做分析不行么？
专业术语很难解释清楚，我们可以用类比的方式来，解释数据仓库系统建设的必要性。
这就是移动的”菜地理论”。
BOSS系统的数据处理是OLTP，是面向交易的生产系统，就像菜地的设计是为了丰产，要播种、施肥、除草、收获方便，这一垄全是土豆，那一垄都是茄子。而分析师就是大厨，要想做道地三鲜，就需要对地里的蔬菜重新处理。
原始的方法，是让大厨自己去菜地。农家菜都是这么凑活弄的，种菜、洗菜、炒菜、上菜，端盘子记账洗碗筷一条龙，反正量小，无所谓。
可是要想做出专业的菜肴，专业厨师的心思应该花在烹饪环节，不可能操心太多原材料的事儿。而且，菜地里一天到晚都是来摘菜的闲杂人等，也影响生产。
就像在生产系统里总跑大数据量的统计运算，会极大消耗计算机的性能，影响正常业务处理。
专业协作的模式就不一样了。要把菜地的产品转运到菜市场（数据仓库），放进菜市场之前还对他进行了清洗和简单处理，类比在数据仓库系统里就是ETL的过程。
菜市场里各种原料的摆放方式和菜地不同，目的不再是为丰产，而是为了取菜的便利和销量（数据利用效率）。厨师可以自己去菜市场买菜，也可以由采买人员拎着菜篮子进菜市场，按照厨师开的单子照需求抓原料。
这个菜篮子，就是IT专业术语里的数据集市。
所以，建数据仓库系统就相当于盖一个菜市场，让市场人员得以专心去做专业的分析工作，而且不影响生产系统的工作效率。
道理虽然解释清楚了，但是这个投资可真不小，这一大笔钱花得值么？
要解答这个问题，就要看业务需求了，尤其是对未来需求的预测。
如今，大数据的概念风起云涌，到处都有人在忽悠，可在当时，说运营商通过数据分析来发展业务，还是绝对的新鲜事。
IT人员从发展的角度看，坚持认为建设数据仓库系统是必要的；计划部门秉承通信网络的管理模式，认为需求不足、经济效益评估差就不该立项；这时候业务部门的态度至关重要。
他们怎么看待数据分析的需求？
十几年前，在移动通信大发展的时代，只要网络容量有了，系统能力和号码资源跟得上，市场发展几乎无上限。只要稍微进行一次价格调整，或者推出一款针对性的套餐，用户就哗啦哗啦地进来，数据分析最多是事后的统计，不需要多么专业。
有幸的是，移动的领导们没有那么短视，业务部门也明白市场不会这么一直舒服下去，应该尽早做好精打细算过日子的准备，因此非常支持数据仓库系统的建设。
中国移动的数据仓库系统的名字，就叫做”经营分析系统”，就是为了体现出这一系统和市场业务的紧密关系。
而为了更好地体现业务需求，支撑部门进行了全国范围的调研，整理出九大类、上百项数据统计分析需求，作为全网建设的业务目标。
现在看起来，这些需求有的价值不高，在实战中发挥的作用也不大；但靠这些或靠谱、或不靠谱的需求，推动起来的经营分析系统，却为中国移动的发展发挥了越来越重要的作用。
当然，这是后话。
当时，完成了规划立项，等到真开始动手做技术方案的时候，我们才意识到，经分系统可比做BOSS难多了。
这方面的故事，下回再说。