在为客户做HER软件的培训有些时日，每一次的感受都不一样，接触的客户多了，自己的感触就会越来越强烈，目前的任务已经不仅仅是如何讲好软件使用和用途了，而是把中国的ehr怎么做好的问题。虽然这个命题有点大了，但是中国的ehr的确还需要很大引导，我们的企业正如饥似渴的等待着优秀的软件团队帮助他们完成脑袋中的理论。

应该说hr的概念在任何企业的负责人员心中都有了一定的地位！至于说这个地位高还是底，清晰还是模糊，完善还是不完善，那不是一个人的力量能分析和解决的问题。

一支优秀的ehr团队需要的是hr专业人才和高级的程序员。如果没有hr专业人才，那我们的程序员就象老黄牛一样，不停的根据客户的需求修改软件功能，这里存在两个很大的隐患：

第一是客户：他也许不是一个“精明”的或者说地道的hr人员，他的需求不是从自身企业的角度出发得来的，是根据一些流行的理论或者词语转换来的，这样就麻烦了，只要有新的名词和理论出来，hr就会发出需求然后程序员响应，没有人过问这些需求是不是有价值；如果不在服务期内客户就不愿意提需求了，但也许这样我们会失去一些有价值的东西，对我们和客户都是一笔损失。

第二是程序员（供应商）：只管编程。不管我做的这个需求是不是有用，客户需求就是上帝的指派，编写出来了，满意度就高了，你好我好大家好。但可能费了心血做出的程序还没使用这个需求就“过时”啦！

对以上两个隐患我的想法：这两个隐患是完全可以避免的，怎么避免？小女子认为两个字－沟通。

当然很好的沟通也是有前提条件的：客户和程序员之间要互相了解一点。别小看这个一点，没有这一点，就永远无法沟通。就象化学里的王水，它的配比就是盐酸、硫酸3：1，错一点就不是王水了。我个人是这样理解“一点”的：

对客户要知道的一点包括：1.只有你没想到的，没有软件做不出来的，现在的高端产品和网络、电子商务的应用，完全可以实现你所想到的一切2.也许一个事务实现起来有困难，但是总可以变通的去处理，在提出一些需求的时候，要在脑子里大概过滤一下：这个需求是不是白日做梦的需求，只要有一丝可能性，那就尽管去提。3.了解一些简单的软件工程的常识（我说的是常识，不是知识），因为将来的需求还是靠软件实现的嘛，就象你学开车，最起码要知道点汽车的构架和机械常识吧，这个要求并不过分。有了软件方面的常识，以后提出需求就知道大概难度有多少，需要的工期有多少，和程序员说话的时候也不至于有语言障碍（此话有些严重，但决不是危言耸听）。

对程序员要知道的一点包括：1.软件公司需要的都是高级程序员了，你的软件工程的水平不可以让客户失望，即便是不好做的需求，也要和客户讲清楚为什么不好做，难度在那里，需要怎么处理，和客户说话也尽量避免专业的术语，尽量让他们明白就好。2.不要一味埋头写语句，一定要有一些hr方面的知识，当客户提出需求的时候，我可以很准确的理解他的含义！这会避免我们很多的重复工作。3.时不时的给客户提点小意见，因为你接触和处理过的客户毕竟多嘛，你的实践经验也是不可忽视的，可以把其他企业好的建议用在你现在的客户那里，或者就当前的需求做一些自己的见解，这样会拉近你和客户之间的感情。

以上是我个人的很卑微的见解，也许就是一派胡言，也许就是金玉良言，但是不管怎样，以上的这种感受会一直在我的脑海里徘徊，等到这些隐患减小或者消失的时候也许我们的HER产品就成熟了。

另外我想到一个建议：为客户做可持续的服务。过2－3年，供应商可以调查企业使用系统的效果，这样做存在一定风险（挑战和机遇共存），但是不做就不可能让HER产品成熟，供应商可以根据调查的结果再对现有的模块做调整。当然也可以在做新客户的时候就深入的作好售前支持工作，这样做客户会对我们的团队产生信任感！而这种信任是供应商和客户之间良好关系的桥梁。

我觉得我们的团队目前缺少咨询（也许有很好HR咨询，我有眼无珠不知道），因为没有咨询就做不了可持续的售后服务。

刚才我又看了自己写的文稿，发现实际潜在问题还是很多，客户如果提出的都是日常行政方面的需求，那也没办法啦，只有给他们一一解决。可能是在购买软件的时候就已经把软件定位成一个行政事务处理的“助手”啦！或者是开始有战略“伙伴”的要求，但是软件没有这方面的功能客户自然就把战略方面的功能忽略了。

总之，把ehr 做的成熟，需要每一位参与人员的智慧！事因难能，所以可贵，我想还是把自己份内的事情做好，加强软件的咨询能力，慢慢带动客户走进ehr！