关于EAM的七个错误看法EAM的发展误区.docx
《关于EAM的七个错误看法EAM的发展误区.docx》由会员分享，可在线阅读，更多相关《关于EAM的七个错误看法EAM的发展误区.docx（11页珍藏版）》请在冰豆网上搜索。
关于EAM的七个错误看法EAM的发展误区
关于EAM的七个错误看法（EAM的发展误区）
ByDaveLoesch首次发表于美国EAM-2006资产管理峰会上。
2006年4月19日，在美国伊利诺伊州芝加哥市罗斯蒙酒店举行的维修及可靠性技术峰会上，甲骨文公司的DaveLoesch发表了一篇演讲：
“对于CMMS/EAM的七个错误－软件狂热者在维修工程中疏忽的问题。
”
[译文]：
为什么企业资产管理软件市场在过去六年里经历了零增长？
为什么四分之三的EAM市场领导者经历了营收下降？
为什么所有的EAM软件提供商都承受了沮丧的损失？
作为海军院校的一名年轻工程师，作者早在八十年代早期开始帮助建立一家叫做“TheSystemWorks”的公司，并使其在EAM（那时候叫CMMS）软件市场上扬名立腕。
二十多年过去了，作者积累了五十多家软件公司以及数百个客户的经验，在此为大家分析和展望在EAM软件用户面前的未来之路。
EAM/CMMS在早年间，那可真是激动人心的时代。
许许多多聪明而年轻的软件开发者和设备维修业者在一起创建“世界上最好的维修计划系统”。
在TheSystemWorks公司，我们信奉RegFast的计划哲学，并将其纳入“MPAC”（维修计划与控制）系统。
与此同时，PatGehl,BillShaw,ChuckJett和其他一些人在JBSystems,ShawWare,和Revere这些公司也在追求和实践着类似的策略。
我们有一个相同的目标：
“开发出世界上最好的，能带来极大的投资回报率（ROI）的维修维护计划管理系统。
”我们相信我们的维修维护管理软件——那时候叫做“计算机化的维修管理系统”（CMMS）将会征服整个世界！
从某些方面来说，我们的梦想成为了现实。
EAM市场的年度软件与服务总营收最终超过了10亿美元。
主要的EAM厂商都实现了公开上市。
事实上，财富1000强中的每一个公司都在使用EAM/CMMS系统进行自己的维修维护操作。
然而，这里有一些EAM市场现在处于不幸之中的信号：
•原先的市场领导者，发现自己的EAM营收从1.8亿美元下降到了1亿美元，并且它的交易稀疏的股票萎缩到了两美元每股。
•股票排名第三的市场领导者，也是第二大主要的上市EAM厂商，发现自己的市值下降了20%，并且作为一个“补充性”的联合企业被收购了。
•从前的股票市场的领导者的市值，从顶峰时期下降了35%。
•现在的市场的领导者在过去的五年中，通过不懈努力，才获得了5%的税后净营运利润。
也许最令人头疼的事情是，EAM市场已经在10亿美元的水平上萎缩不前超过6年了。
“要么成长，要么死亡”在软件业是放之四海皆准的真理。
没有增长，就没有投资，没有增长，就没有创新。
没有创新，那么唯一有区分的路数就只有价格和服务了。
这些发展趋势已经导致很多专家推断，在几年内，将不再有单独的EAM市场了。
本文试图概括出——从一个很久以来努力工作、出售很酷的EAM/CMMS软件的家伙的视角——来看看我们犯了哪些错误，以及EAM的用户们面临着怎样的未来。
错误#1：
“给我看看（省下来的）钱在哪里？
”，其实省钱来自业务流程的改变，而不是软件。
很多软件供应商希望用新的管理理念来使维修软件市场发生革命性的变化。
从70年代和80年代的“FramOilFilter”模型（现在支付我，还是以后支付我）、到后来的区域维修、全员维修（TPM）、以可靠性为中心的维修（RCM）、基于风险的维修等等——EAM厂商们以不同的形式在不同的程度上在各自的软件中引入了这些概念。
软件供应商们并没有告诉你的是，我们是以我们自己的观点来建立TPM和RCM的。
我们并不想让你们知道，我们其实只信奉有限的“新理念”。
软件公司和制造业厂商相差其实并不多。
我们支持的变化越多，我们挣的钱就越少。
我们在产品中支持RCM以及其它更多的理念越多，我们就不得不编写更多的代码，我们的利润也就越少。
我们的目标是让客户相信，我们精选的定义——就像在我们的软件中的那样——是最佳实践。
（如果我们真的确信自己正确的话，我们更愿意把它叫做“全球最佳实践”！
）如果客户往后倒退的话，比如在医院，你需要一天处理100个工单申请？
我们可以让你创建一个不需要指定设备编号的工作请求——我们可以增加一个“参数”，让客户可以把我们的“全球最佳实践”稍稍扭曲一点。
经过超过30多年以及差不多100,000次CMMS/EAM的实施经验,我们中的大部分人都知道，其实并没有什么独一无二的最佳实践。
你如何定义和执行一个特定的业务流程——不管它是维修工单还是发票——取决于你的市场，经济状况，员工，竞争，公司战略，天气，甚至那天来工作的是谁。
大部分我的做顾问的朋友也许会把这篇文章扔到垃圾筒里面去！
不要害怕，积极面对吧，本文作者实际上是你们最大的爱好者。
毫无疑问，了解和学习其它公司的最佳实践和试着使用这些经验是有极大价值的。
然而，认为一个软件公司或者顾问能够对于许多不同的行业可以实行一种方式的业务流程的想法是及其荒谬的。
这些行业在基础架构，规模大小，核心业务方面各有迥异，比如油气管道、纸浆厂、政府实验室等等。
通常来说，为一个单独的工厂（停火指令，仪表校验，泵的检查，等等）定义一种“最佳实践”的方式来处理工单都是非常艰难的，更不要说对于从只有2个人的小公司到800人大公司，甚至从1131到9372各种型号的集成电路来说了。
EAM/CMMS的设计者和市场人员所犯的第一个错误是：
他们没有认识到软件本身并不是带来投资回报（ROI）的变革的代理人。
当软件为你省下钱来之前，业务流程不得不为一个特定的公司甚至一个特定的维修部门做出优化。
一旦你为了你自己的业务设计出了最佳业务实践的流程，你就需要一个软件系统来自动化地处理这种业务流程。
然而，一开始就从软件的观点来看待什么是最佳业务实践，其实对于除了屈指可数的少数客户之外的大多数客户而言，都是一个有害的沉重负担。
错误#2：
更多的功能不意味着更多的价值
你可能想知道在软件供应商的圣经上写着什么：
•你必须每年有一次升级的版本发布；（好吧，确实需要18个月才能办到，但是至少说起来就像是一年一次吧）
•你必须声称具有你的竞争对手所能做到的一切。
•你必须谈论一些新玩意，以炫耀你比你的竞争对手更聪明和更迅速。
在过去的三十年中，我观察了许许多多的软件市场，从EAM系统到计费系统；从股票交易系统到税务管理系统—而这些戒律都是深深嵌入到软件供应商的DNA里面去的。
我们对我们自己的客户、聪明才智和经验是如此地深信不疑，我们只知道我们自己造的东西就是比别人的东西要好！
虽然认为一个公司比另一个公司天生地就有更聪明的员工是一种愚蠢的想法，其实真正的问题在于客户的公司并不具有用来开发软件公司所开发出来的软件的资源，比如时间、金钱、技术等。
Reliabilityweb的报告显示，用户只用到了他们采用的EAM产品的15%的功能。
有些顾问声称也许达到了30%，而最得意和最高级的用户也许会承认没有超过50%。
无论如何，我们的客户从来就没有用过我们造出来的大部分功能。
我最近和一家财富前100强的公司的人聊过。
这家公司在EAM系统上花了数百万美元，并且是几家有关维修技术、工厂工程等出版物中发表的几个“成功案例”的焦点之一。
这家公司曾经公开宣称他们的EAM系统帮助他们削减了60%的加班时间，并且削减了数百万美元的维护维修运营库存。
然而，在系统上线运行了十年后的今天，这家公司仍然没有应用资产物料清单功能（备件列表）！
我们中的很多人认为资产物料清单对于实施一个有效的维护程序来说，是一个最基本的功能。
你在软件中录入设备数据，你在软件中录入备件的数据，你把设备及其备件关联起来。
这些步骤做完以后，做维修计划的人就可以为维修计划指定正确的备件。
技术工人们就能够为一次紧急维修查询出正确的备件，而不需要在操作手册中乱找一气。
然而，这家在EAM系统上投资了数百万美元的，成功的财富100强公司并不需要或使用这些功能吗？
当我们的客户甚至都不使用备件列表时，软件开发者真的认为声控移动设备或者有插图和工程学标记的备件目录对于我们客户的成功是必不可少的吗？
我们是不是该问问自己，二三十年来积累的功能对于我们客户的维修维护操作是不是真的贡献了任何价值？
保修凭证管理也许是最近的一个有关功能方面的EAM的错误。
每个软件提供商都在吹捧它，而招标建议书征询文件（RFP）都要求需要它。
但是我倒要等等看哪个维修部门愿意看着让生产线停工24小时，只是为了等待备件制造商来替换或维修一小块保修的零件，而其实我们都知道可以现在就把它修好，然后事后再向制造商询问。
（我听有些客户说过，他们很高兴宁愿花10美元来节省0.1美元。
）不，我不是一个勒德分子（译者注：
卢德派成员：
在1811年到1816年期间骚乱，并捣毁节省劳动力的纺织机器的英国工人。
他们认为这些机器会减少就业）。
我承认技术手段在追踪类似保修过期信息等方面确实很棒。
然而，在我们都为了一个大肆宣传的旅程买单程票之前，我们需要认识到，保修管理软件的价值是受到很多软件以外的，不受软件控制的因素所影响的（你要像一个真正的专业保修工作负责人那样思考问题）。
其实软件行业再一次地成功地指出了一个痛处（译者注：
保修管理），并且建立了一个所谓的“软件解决方案。
”（去试试看在Google里面搜索“warrantysoftware”，当你得到超过55,000,000的搜索结果时请告诉我…）当然，很多买家没有注意到——也许不会被软件销售人员告知——为了得到因为保修节省下来的钱，业务流程本身也是必不可少的。
而且EAM软件销售的怪圈——不完全的实施和极大的失望，又要开始了。
错误#3：
易于使用是一个不重要的想法。
认可一个软件包的易用性，就好比认可对于起居室的沙发来说，什么是最好颜色：
关于这个决定，有太多的变量和个人喜好在起作用。
既然没有人能定义“易于使用”，每个软件供应商都有自己的答案。
而我在有了数百个应用软件包的经验之后，我还在继续等待一个“易于使用”的。
有些用户会发誓说，软件供应商A的产品比软件供应商B的产品更易于使用，或称软件供应商C是最难使用的产品。
但是既然并没有易于使用的标准，那么是什么造成了这些不同的说法？
是不是有可能因为我们公司的实施工作有一个非常好的培训项目支持？
还是因为有一个经验丰富的实施顾问？
还是因为我从先前的不佳体验来认识现在的系统？
还是因为我既然签字认可了这个产品，我就不得不宣誓效忠于它，并且希望它能易于操作？
有没有可能是因为我在这个系统上花了如此多的时间，以至于它看上去是非常好用的？
错误＃2其实为错误＃3奠定了基础。
如果市场竞争需要更多的功能来赶上竞争对手，那么软件供应商的时间就会较少用来担忧已经开发出来的东西怎么样才更好用了。
除此之外，如果软件供应商们深入广泛地交流了有关经验，那么也许这些软件就不会那么“好用”了。
有多少次，软件供应商们说，“毕竟那不是Excel！
”（或者更差劲的说，“其实这并不比学习Excel更难！
”）唉！
给我前面那个家伙吧，至少他还是诚实的。
面对着只有15%的功能利用率，供应商们应该为软件的可用性而不是功能性担忧更多了。
我们应该从一个简单的工作单收集程序开始，然后根据用户的需要再增加新的功能。
然而，这种想法在软件行业从来没有流行过。
在1980年，TSW公司发布了他的第一个产品，这个产品具有差不多十种不同的工单类型（检测、重复检修、润滑、改造、紧急、预先计划、装配，等等）。
甚至最便宜的EAM产品（$99）也具有多种工单类型。
我们迫不及待地想打倒我们的竞争者，我们并没有考虑太多有关这种产品到底会被怎么样使用或者不被使用的问题。
供应商们应该开发像电话一样易于使用的软件，而不是为每个软件版本增加长长的功能列表。
你愿意花费一节课的时间来学习怎么样给你妈妈打电话吗？
电话需要有一份长达200页的操作说明书吗？
客户们已经非常清楚地表示，他们对于需要长达18个月的软件实施已经没有兴趣了。
（当然,史密斯太太，我们将在这个星期三来安装你的电话，你应该在2006年下半年就可以使用了。
）客户们需要在不为合约大出血和加班工作的情况下把软件安装好。
更高的员工流动率意味着今天来参加培训的人也许明天就走了。
更多的客户会说，既然EAM系统已经得到关注了，那么我们就从创建工单和计算成本开始吧。
他们已经明白花上数周甚至数月来计划或者学习可能用不上的软件功能，或者，当员工换人时，不得不被重新实施一遍软件，是毫无意义的。
错误#4：
应用软件是一门专业学问。
成功地卖出EAM/CMMS的关键是本身成为一个维护管理的专家。
一个早期的EAM领导厂商的标语就是“维护工作是我们仅有的事业！
”我们承认，在一个存在面部头盖骨动物艺术画家和古人类学家的世界上，专业分工是时髦和必须的。
但是，我们在这里谈的是信息，如果一个企业的信息不能共享，那么对它有什么好处？
没有人说专业分工是坏事。
然而EAM供应商们在维护工作上是如此的专注以至于他们阻挠了他们所服务的群体的信息管理的目标。
EAM供应商——以及所有的专注“点市场”的供应商们——用鼓励和怂恿用户专注于它们之间的区别的方式，将维护功能从其它业务中隔绝开来。
没有人和我们一样！
我们需要我们自己的系统！
每一个点供应商都表现了人类那种渴望自己是独一无二的本性。
但是，提醒我们这些做维护软件的人！
我们真的认为我们比客户服务部门更独特？
我们真的认为我们比生产部门具有更重要或者更复杂的信息管理需求吗？
我们都需要达成共识的就是，每一个业务功能和部门都是独一无二的，而争论只能导致没有止境的数量的专业化的信息孤岛。
每一个部门都是非常重要的，我们所做的，比任何其它人所做的都不见得更重要或更次要。
我们应该非常愿意，非常渴望和其它部门的人们共享信息、提高我们管理信息的水平。
如果我们知道客户订单已经发生了变化或者供应商并没有来得及发出设备的话，那么维护部门就会运营得更有效率一些了。
日益提高的市场竞争性和规章制度的要求使得部门级的信息孤岛更加地不合实际。
很少有公司能竞争力地独立运作每个自治的部门。
更低的进入门槛；更直接的交流，以及更快速的创新都意味着我们的业务——以及我们使用的信息系统——都必须共享信息，比以往任何时候都能更灵活地适应变化。
错误#5:
技术并不要紧
EAM供应商们厌恶讨论技术,也许这是因为我们有时发现在维护工作和IT之间有摩擦.也许这是因为当我们讨论技术时,维护人员的眼睛会瞪得像甜甜圈那么大（译者注:
意思是对维护人员说技术问题时,他们会感到很迷茫）,也许这是因为我们实际上从来没有搞懂有关超文本和应用服务器的胡言乱语究竟是什么意思!
从我们自我辩解的角度来说,也许当我们开始出售EAM产品的时候,我们最小化了技术方面的晦涩难懂的话,这是因为这样做是让头发斑白的有30年工作经验的资深专家们考虑使用计算机的唯一方式。
（而且我们知道，你们中的大部分仍然拥有这些老员工！
）但是,今天这个时代已经很难发现一名大学毕业生-古希腊文学专业的除外-对操作计算机感到不舒服的了.能发现一名还没有玩过视频游戏或者没有在电脑上工作过的,不到30岁的伙计是很走运的事情了.你没有必要让他们信服为什么要使用电脑,但是你必须做出解释为什么不使用电脑.
失去兴趣的维修专家们不是看低技术的唯一理由.对EAM供应商来说,资金也是一个重要的考虑原因.大部分EAM供应商拥有的开发人员少于100个,因此我们不得不专注于我们的"核心竞争力."这就意味着EAM供应商要在更好的工单界面上下功夫,而让别的公司来为开发工具集或者集成中间件而担忧.如果你揭开面纱,你会发现很多所谓的"第三方"产品在支撑着你的EAM软件
●应用开发工具集（用来实际创建EAM软件界面的）
●文档管理（版本控制,签入/签出,检索索引,圈红线等等）
●工作流（配置没有被硬编码到软件中的,但又对应交易或文件的处理过程）
●商业智能（报表工具和分析）
●门户（报表信息的仪表板）
●企业应用集成（在不同的应用之间交换信息）
●图像查看工具（图像展示）
●移动计算和许多许多更多的其它东西...
EAM供应商们知道这些第三方的产品会使客户神经紧张的-大部分我们的产品伙伴都比我们小-因此我们用贴牌许可证协议或任何可能的方式来控制它们,从而使我们自己能集中精力在工单上.看起来我们这么做是正确的,但是绝大多数试图控制第三方的做法已经失败了.
除非供应商支持,成本,实施周期,员工培训,以及企业级的信息共享对你的维护业务并不重要,技术确实事关重大.当评估EAM系统时,声称自己不在乎技术,就像声称自己因为看不见,所以并不在乎建筑物的地基一样.
错误#6:
成本是某些别人的问题
我们当中有多少人把我们的工程师或技术人员中的一个授权为"超级用户"?
除了回答有关EAM的技术问题之外,这些人通常还负责开发报表,以及增加用户,配置权限的工作.很多维护部门的负责人认为,与其等着IT部门的人来响应问题请求,还不如在自己部门的薪水册上保有一个能随时响应问题的员工划算.虽然这种方式可能侧重于维护维修工作的需求相应的及时性,但是这种做法真的不符合企业整体的大蓝图.创建部门级的系统管理员引入了员工冗余,过程低效,以及使IT成本更难被跟踪和提高.当企业努力衡量IT系统的回报时,这已经成为一个更重要地被关切的问题.
主要问题之一是IT项目成本的精确性,特别是对特定问题的解决方案的项目.我们都知道看得见的花费（比如软件,硬件,以及实施服务费用）,但是我们中有多少人能够报告一个真实的,包括加班,降低生产率,额外的IT支持等费用在内的项目真实成本呢?
如果你不能,那么你就不能是单独的解决方案项目.研究表明,研究显示IT项目成本通常是被打了四到五折的真实成本.
联合增长战略,包括合并和收购计划,也同样是重要的考虑因素.Gartner报告认为首席信息官们被期待着能用协同方式节省30%的成本.你知道95%的EAM供应商们具有低于五百万美元的营收和少于100个客户吗?
如果你是这些产品之一的用户,你怎么样为公司的战略成长目标做出协同的贡献呢?
维护维修是联合增长战略的推动者之一,还仅仅是要被处理的另一个问题?
我们如果强烈地坚持我们自己关于一个维护维修系统应该是什么样子的观点,那么就不可能给企业有太多的帮助.如果我们展开更广阔的视角,我们就会认识到,IT和成本确实很重要,也许这样做我们才能对我们所在组织的竞争优势有积极的贡献价值.
错误#7:
诅咒信息系统的麻烦吧！
我们还是用联机事务处理好了.
几乎每一种应用软件产品都是联机事务处理系统的后代,这是一种用来编程自动处理业务流程的主机终端结构.OLTP的主要目的是使客户的订单或者发票能够电子化,以此避免纸质工作可能的损失.想猜猜看第一个EAM系统实际上是什么吗?
一个OLTP的工单!
有些系统确实创建一些"在线报表"（比如设备成本历史）,但是EAM/CMMS产品实际上是作为一个交易处理过程被构思,设计和建立的.
早期的软件开发者没有意识到客户其实不是在购买自动化的交易处理系统,它们实际上需要的是信息.客户们想知道的是最糟糕的设备资产是哪个?
怎么样控制加班时间?
最不可靠的备件或供应商是谁?
等等.软件的肮脏的小秘密是,我们在应用软件设计好和发布以后之前,几乎从来没有考虑过这些需求.
这个问题来源于我们是被教导以何种方式来创建软件的.不管名词术语如何（快速应用开发,原型法,等等）,其实大多数软件是建立在一个同样古老的,已经有四十年历史的,叫做瀑布模型的基础之上的:
●定义
●设计
●编码
●测试
●实施
虽然编写报表从技术角度来说,从编码阶段已经开始,但是开发人员还是直到数据模型已经稳定的时候才开始创建报表.（那就是说,开发人员不会开始编写报表,除非应用软件中所有的信息都已经被识别,定义,格式化,等等.）你也许发现这很令人吃惊,但是软件本身不等到实施阶段,当我们的质保工程师已经在软件上做了大量的测试之后,是不会稳定的.（你的经验是,软件甚至经历了几个月的实施之后才能说它已经稳定?
我们知道的,那就是我们不能编写更多的报表的原因.）我们让我们的开发人员专注于质保部门发现的问题上.等到了软件应该发布给客户时,只有一小部分原来的开发人员还留在当前的版本上继续工作.大部分人已经转移到下一个版本的工作上去了.这也是我们经常告诉你"请等待下一个版本"的原因.
应用软件开发应该从信息开始而不是从交易处理开始.软件供应商们在设计每一个独立的交易之前都应该考虑最麻烦最糟糕的报表可能是什么样子的?
对于我们那令人沮丧的投资收益率（16%的真实投资收益率是从应用软件而来）是从我们付出很少注意力而实际上又是客户实际需要的地方来的说法还有任何疑义吗?
客户从来不关心如何录入工单,它们只是想知道如何能够在维护维修工作上花费更少.
唯一不变的只有变化
尽管我是在做半开玩笑的忏悔,其实我们搞应用软件这行的大部分都不是低能儿,也不是误导大家或在做类似的事情.我们相信我们做的是什么,我们的努力成就了今天可能的进步.我们是对的,软件确实能让人们的生活更加美好,能让商业运作更加地快速.但是,我们太忽视决定长期成功的基础要素了.我们的成功应该用客户到底在多大程度上利用了我们的软件来衡量,而不是用我们竞争对手最新发布的版本来衡量.我们需要能够服务于整个企业的软件,而不是从我们的世界观出发的软件.我们应该建造更灵活的,能支持流程变化的软件,并且在技术方面做更多的投资.
如果EAM的历史是一个指南的话,那么另一个seismic的变化正出现在地平线上.我们也许不知道幸存者的名字,但是我敢打赌说幸存者的软件一定是更简单,更集成化,更便宜.多大多数公司来说,应用软件的圣杯-在投资上有所回报的-还没有被发现.在经过花费了数十亿的美元后,EAM市场也许真的需要喝一杯了.也许这次我们能得到一些能让整个公司收益的东西.
关于作者
DaveLoesch（演讲者）有二十多年设计、开发、实施EAM/CMMS系统的经验。
他曾经历任TheSystemWorks公司的助理实施顾问、负责产品管理的副总裁、以及负责市场工作的副总裁。
他曾经负责许多软件业务方面的损益责任，包括采购、时间进度、出席率，以及商业智能。
作为YieldPro顾问集团的一员，Loesch为许许多多的应用软件公司做过咨询－包括当前EAM市场上的大部分领导厂商－这些咨询内容包括产品研发、业务战略规划、以及投资融资。
他目前领导Oracle公司的行业维护解决方案业务部门（theOracleIndustryBusinessUnit），该部门的业务包括在全世界已经有300多案例的Oracle企业资产管理解决方案。
升级会员 