这东西咋用?

对于集成商而言，项目已经结束了，而对于用户而言，才刚刚开始而已……

昨天正坐在办公桌前郁闷发呆的时候，一位老兄突然跳到我面前，瞪着大眼睛说：“那个谁，会……会议室……”

原来他下午要去忽悠客户，当然也不是他主动，是客户想被忽悠，又不怎么信任那个给他们做项目的集成商，怕被忽悠傻了，于是就想起我们这位老兄。其实客户出了几个题目，大概这么几个意思：

系统建成了，咋用？
想设几个分析员，咋培养？
系统好不好，咋评价？

哇塞，这些问题都挺虚的吧，咋答？这老兄也没谱，我只好硬着头皮先忽悠他了。
嘿呀，咋用？本来在项目开始建设之前的需求分析阶段就应该界定出来项目该咋用了，不过系统上线之后还需要重新整理一下，把系统功能（包括报表、Cube、仪表盘等）和整个系统的用户一一对应出来，不过这个对应可不像需求分析文档中那样笼笼统统地按照角色，要定位到具体某个人需要的具体哪几张报表和哪几个Cube以及哪几个仪表盘。
这个当然是第一步，第二步是要根据真正的应用需求对系统进行一次设置或者配置，比如报表的调度和邮件分发，比如数据访问权限的细致设置，再比如每个人的个性化的首页的定制等等。

还有第三步，每个人都有了个性化的界面了，每个人都能通过邮件收到日常的数据信息了，还要再给用户一点培训，最基本的，给用户创建一个登录系统的URL的快捷方式放到桌面上，然后告诉用户如何登录，如何管理自己的密码，有了问题如何与系统管理员联系。进一步的，要培训用户如何使用这些系统功能，比如这些报表中的业务定义规则，数据统计规则，如何发现异常的数据以及如何对异常数据进行进一步的分析。软件的基本操作方法的培训，以及数据分析方法的业务培训。

当然说到培训，也就免不掉培训对象、内容和培训方式的问题，从培训对象来说，高层领导、中层管理者以及部门职员三个层面的培训都必不可少，层次越高个性化越强。对高层领导来说，由于领导工作繁忙，培训只能见缝插针，在领导有空有心情的时候抓紧时间进行讲解，内容上不要弄太多复杂的东西，尤其不要技术和原理性的东西，说明白领导的主页上有哪些内容，干什么用的，怎么用法就OK了，如果领导心情好当然还可以聊聊为什么提供这些功能给他，这些就足够了。而对于职员层面的用户来说，需要放羊式培训，普及化教育，集中起来，定制教材（一定要包括业务分析过程的例子和练习题），内容方面就是软件使用，以及如何做简单分析解决业务问题（或者就是如何做简单报表）。而中层管理者介于两者之间，培训方式上可能要见缝插针，也可能参加大班培训。

上述这些工作做完，至少，每个系统用户都知道自己在这个系统中有哪些功能可用了，也知道如何使用了。

那么下一步，就是要跟踪这些用户的使用行为，根据系统记录的登录日志，来看这些用户是否真的在每个数据刷新或者发布周期都登录到系统上去浏览了自己号称需要了解的数据内容。对于那些实际访问频率不高的用户，要主动回访，征求用户的意见，问为什么不常登录？当然，对于那些登录频率较高的用户，也要进行回访，征求改进意见。这些反馈都是系统改进的重要依据。

第二个问题，数据分析员如何培养？

我自己认为这个问题有点超前，事实上客户那边目前并没有专业的分析员存在，没有专门的岗位，也没有专门的人员，在谈如何培养之前，反倒应该先考虑一下分析员这个岗位到底是干什么的，也就是说应该有哪些职责（当然，与工作职责相关的工作流程，比如谁提出分析要求，分析的结果以何种方式返回等，也需要定义出来），确定职责之后，再确定人员的资格要求。这些工作有点象人力资源的工作范畴了。不过我个人认为，这个事情不做，培养的事情也就不用谈了。

假定分析员的职责清楚，人员落实，那么对分析员的培训就可以开始了。当然第一步的培训还是要让分析员知道自己的职责和工作流程了，下一步是数据分析方法，什么样的业务问题适合用什么分析方法，如何定义分析目标、流程已经分析报告模板；再下一步是培训系统中可用的数据模型，包括数据仓库中的数据结构、Cube列表和语义层列表等。分析员要熟练掌握各种工具，还要理解业务，还要了解数据，实在是一个不好干的活。而对分析员的培训，恐怕要集成商、厂商、业务专家、人力资源等多个部门的人一起充当老师了，有点象全真七子带一个徒弟的架势。

要说这第三个问题还是满有趣的，因为向来BI系统的成功标准都是一笔糊涂帐。反正在没有严格的成本核算的情况下去计算系统的ROI是一个完全不现实的事情。干脆，从另外一个角度看问题吧，让系统有用就当它成功好了。

如何判定系统是否有用，可以从系统功能的利用率和系统用户的访问频率来定义，系统功能方面，要判断出来以下几个点：

热点：访问频率最高的功能项，包括报表、Cube或者其他的等等；
冷点：访问频率最低的功能项；
重点：高层领导时常访问的功能项。

未来的系统演进，要重点关注热点功能和重点功能，围绕这两个点让系统进化；而让冷点逐渐退化。

对于系统用户的访问频率要发现这样一些用户：

热情用户：经常访问系统看数据、做分析的用户（比如访问频率最高的前10％）；
冷漠用户：很少登录系统的用户，如果这些人对系统功能的实际需求很少的话，就随他去吧；

重点用户：高层领导用户，时不时登录系统的高层用户。

未来系统的发展还需要深入挖掘热情用户和重点用户的需求，这些人是系统发展的真正推动者。

作为集成商而言，系统上线可能意味着项目结束；而对用户而言，项目上线，才是项目的真正开始。甲方的IT部门，作为项目的承建方，在此后需要把自己定位在乙方的位置上，把业务部门用户当作甲方，尽量多提供一些主动的回访和主动服务，才能保持项目的生命力，否则即使项目做得一朵花，不浇灌也难免要迅速枯萎。