The 7 Mistakes of CMMS/EAM (EAM七宗罪英文原文)

snow.lovers

Note: This presentation was originally delivered at EAM-2006 - The Enterprise Asset Management Summit

Why has the Enterprise Asset Management (EAM) software market had zero growth for the past six years? Why have three of the four market leaders experienced revenue declines? Why have all vendors suffered staggering losses? As a young Naval Academy engineer, the author set out in the early eighties to help a start up called The System Works makes its mark on the EAM (nee CMMS) software market. Over twenty years, fifty software companies, and hundreds of customer engagements later, the author takes a look at the road ahead for EAM users.

The early days of EAM/CMMS were heady times. Scores of bright young software developers teamed with maintenance practitioners to build the “world’s best maintenance planning system.” At The System Works, we embraced Reg Fast’s planning philosophy and preserved it in “MPAC” (Maintenance Planning And Control). Pat Gehl, Bill Shaw, Chuck Jett and others pursued similar strategies at companies like JB Systems, ShawWare, and Revere. We all had the same goal: develop a maintenance planning system that delivered tremendous return on investment (ROI). We all believed our maintenance software—called Computerized Maintenance Management Systems or CMMS in those days—would conquer the world!
In some respects, our dreams came true. The EAM market ultimately exceeded $1B in annual software and services revenue. The major vendors all “went public.” Virtually every Fortune 1000 company acquired an EAM/CMMS for their maintenance operation. However, there are signs that the EAM market is in trouble:
• The original market leader saw its EAM revenues plummet from $180M to under $100M and its thinly traded stock languishes under $2 per share.
• The #3 share leader, and the second major EAM player to go public, saw its top line drop 20% and be acquired by a “support” conglomerate.
• The market share leader in mining’s top line drop 35% from its record level.
• The current market share leader has struggled to accumulate a total of 5 percentage points in operating profit over the past five years.  
Perhaps most troubling is the fact the EAM market has languished at $1B for over 6 years. “Grow or die” is nowhere more applicable than software. Where this is no growth, there is no investment. If there is no investment, there is no innovation. With no place for innovation, the only way to differentiate is through price and service.  
These developments have led many experts to conclude there will be no standalone EAM market in just a few years.  This paper attempts to outline—from the perspective of a guy who worked hard and long to sell really cool EAM/CMMS software—where we went wrong and what the future holds for EAM users.

snow.lovers

Many software vendors hoped to revolutionize the maintenance market with new management concepts. The “Fram Oil Filter” model (pay me now, pay me later) of the 70s and 80s was followed by others—zone maintenance, Total Productive Maintenance (TPM), Reliability Centered Maintenance (RCM), Risk Based Maintenance etc.—which EAM vendors incorporated into their software in varying forms and degrees.  
What vendors didn’t tell you was we built our view of TPM or RCM; we didn’t want you to know we were embracing a limited view of the “new idea.” Software companies aren’t all that different from any manufacturer. The more variations we support, the less money we make. The number of RCM philosophies we support in our product—and there are more than a few—the more code we have to write and the lower our margins. Our goal was to convince customers that the definition we picked—as reflected on our software—was best practice. (If we were really confident we got it right, we’d call it a “global best practice”!) If the customer pushed back—Mr. Hospital, you process 100 work requests a day? We’ll let you create a work request without requiring an equipment number—we’d add a “parameter” that allowed customers to tweak our “global best practice” just a little.   
After 30+ years and probably 100,000 CMMS/EAM implementations, most of us know there’s no such thing as a single best practice. How you define and execute a particular business process—whether it’s maintenance work orders or invoices—depends on your market, the economy, staffing, competition, corporate strategy, the weather, who comes to work that day…
Many of my consulting friends may have just tossed this paper in the trash! Fear not, process pros, the author is actually your biggest fan. There is no doubt that exposure to other company’s best practices and experience applying those lessons has tremendous value. However, the notion that a software company—or a consultant for that matter—can define a single way to execute a business process in industries of fundamentally different structures (e.g. pipelines vs. pulp mills vs. government lab); sizes, and missions is absurd. It’s often hard to define one “best practice” for processing a work order in a single plant (fire extinguisher inspections, instrument calibration, pump overhaul etc.) much less across companies of 2 tradespeople to 800 and SICs 1131-9372.
Mistake numero uno for EAM/CMMS designers and marketers was the software is NOT the change agent that generates return on investment (ROI).  The business process has to be optimized for a particular company and even a particular maintenance crew before it saves money. Once you have designed the best practice for your business, you will need a software system to automate the process. However, starting with the software’s view of best practice is an albatross that hamstrings all but a handful of customers.

snow.lovers

You might want to know what’s printed in the Software Vendor’s Bible:
• Thou shalt have one release per year (OK, eighteen months works, but at least talk like it’s coming out once per year)
• Thou shalt have claim to have everything your competitors do
• Thou shalt talk about new stuff to shows you are smarter and faster than the competition


Over the course of nearly three decades, I have observed scores of software markets from EAM to billing systems; from trading exchanges to revenue management—and these “commandments” are hard wired into a software vendor’s DNA.  We believe in our customers, intellect, and experience so much we just know what we build is better than the other guys!
Although it’s silly to think one company has inherently smarter people than another, the real problem is the customer doesn’t have the time, money, or skill sets to deploy what we’ve built. Reliabilityweb reports that customers only use 15% of their EAM product functions. Some consultants say it might be 30%. The proudest and most advanced user will probably admit it’s no more than 50%. Under any scenario, customers certainly aren’t using most of what we build.  
I recently spoke with a Fortune 100 company that had spent millions on EAM and was the focus of several “success stories” appearing in Maintenance Technology, Plant Engineering and other publications. This Company has stated publicly their EAM system had helped them reduce overtime 60% and reduce their MRO inventories by millions of dollars. Yet, ten years after their go live date, the company had not implemented the Asset Bill of Materials (Parts List) function! Many of us see the Asset BOM as pretty basic stuff in terms of implementing an effective maintenance program. You put in the equipment. You put in the parts. You attach the parts of the equipment. Get these steps done and planners can identify the right parts to be used for planned maintenance. Tradespeople can retrieve the rights parts for an emergency repair without hauling the manual around. Yet, this successful Fortune 100 Company with millions of dollars invested in EAM didn’t need or use the function? Do software developers really believe that voice activated mobile devices or illustrated parts catalog with engineering mark up is fundamental to our customer’s success when they don’t even use the Parts List? Isn’t it time we asked ourselves if the 20-30 years of accumulated functionality has contributed any value to the customer’s maintenance operation?

snow.lovers

Agreeing on how easy a software package is to use is like agreeing on the best color for the living room couch: there are tons of variables and personal preference drives the decision. Since no one could define “ease of use,” each software vendor got to craft its own answer6.  And, after using hundreds of application software packages, I’m still waiting for one that’s “easy to use.”
There are users who will swear Vendor A’s product is hands down easier to use than Vendor B. Or that Vendor C is the hardest package to use. Since there is no standard for ease-of-use, what accounts for these variations?  Could it be because my implementation was supported by a really good training program or an experienced implementer? Did I recognize aspects of the system from previous experience? Was I committed—in the pig and ham sense—because I endorsed the product and I was expected to get it operational? Could it be that I’ve spent so much time with the system that it seems downright easy?
Mistake 2 pretty much set the table for Mistake 3. If the market required more functionality to stay up with the (Vendor) Joneses, vendors had less time to worry about making what was already built easier to use. Besides, if the vendors communicated experience and stature through a deep and wide product, it couldn’t be that easy could it?  How many times has a vendor said, “After all, it isn’t Excel!" (Or worse yet, “It’s not much harder than learning Excel.” Eek! Give me the former guy. At least he’s being honest!)
With 15% deployment rates, vendors should have worried more about usability than functionality. We should have started with a simple work collection program and added options, as customers needed more. However, this thinking was never prevalent in software. In 1980, TSW shipped its first product with almost ten different work order types (Inspections, Repetitives, Lubrications, Rebuilds, Emergency, Preplanned, Fabrications etc.) Even the cheapest EAM product ($99) has multiple work order types. We were in such a rush to beat our competition, we didn’t think much about how it would be used. Or not.
Instead of adding long lists of functions each release, vendors should be building software that’s as easy to use as the telephone. Do you have to take a class to learn how to call Mom? Does the phone require a 200-page instruction manual?  Customers have clearly stated they are no longer interested in 18-month software implementations. (Sure, Ms. Smith. We’ll come by on Wednesday to install your phone and you ought to be able to start using it in the second half of 2006!)7 Customers need to get the software installed without bleeding cash for contractors and overtime. A more fluid workforce means who gets trained today could be gone tomorrow. More customers are saying—as far as their EAM is concerned—let’s just start with creating work orders and charging costs. They have learned it doesn’t make sense to spend weeks or months planning or learning functions that aren’t going to be used. Or, have to be re-implemented when employees turnover.

snow.lovers

The key to successfully selling EAM/CMMS is to be a maintenance specialist. An early EAM leader’s favorite tagline was “Maintenance is our only business!” Granted, in a world of cranial-facial animalists and paleoanthropologists, specialization is chic and often necessary. But, we’re talking about information here. And, what good is enterprise information if it can’t be shared?
No one is saying specialization is bad.  However, EAM vendors have become so focused on maintenance, they have hamstrung the information objectives of the group they serve. EAM vendors—and all “point market” vendors for that matter—have insulated the maintenance function from the rest of the business by encouraging users to focus on their differences.  No one gets us! We need our own system! Every point vendor has played to the human desire to be unique. But, c’mon maintenance! Do we really think we are more unique than our customer service department? Do we really have more important or more complicated information management needs than production? We all need to recognize that every business function and department are unique and that argument only leads to an endless number of specialized information management silos.
Every department is important and what we do is no more or no less important than anyone else. We should be willing, eager in fact, to share our information and improve our operation with information from other departments. What maintenance department wouldn’t operate more efficiently if we knew the customer order changed and maintenance wasn’t releasing the equipment to us?  
Increasing competition and regulatory oversight make departmental information silos even more impractical. Few companies can remain competitive or compliant with each department operating autonomously. Lower barriers to entry; instant communication, and rapid innovation means our business—and the information systems we use—must share information and flexibly adapt to change faster than ever before.

snow.lovers

EAM vendors hate talking about technology. Maybe it’s because we sometimes detected friction between maintenance and IT. Maybe it’s because when we talked technology, maintenance’s eyes created enough glaze for a month’s supply of Krispy Kremes. Maybe it’s because we really never understood all that gibberish about hypertext or app servers either!
In our defense, maybe we minimized the technical mumbo-jumbo when we started selling EAM because it was the only way to get grizzled 30-year maintenance veterans to consider computers. (And, most of you still got ‘em on staff, we know!) But, today it’s hard to find a college graduate—Greek literature scholars excepted—who isn’t comfortable with computers. Good luck finding a tradesperson under 30 who hasn’t played a video game or worked on a computer. You don’t have to convince these people to use a computer, but you might have to explain why you don’t.
Disinterested maintenance vets weren’t the only reason to downplay technology. For EAM suppliers, money was also an important consideration. Most of us had fewer than 100 developers8,  so we had to focus on our “core competency.” That meant investing in better work order screens and letting another company worry about development toolsets or integration middleware.  If you get under the covers, you’ll find lots of “third party” products propping up your EAM package:

Application development tools (used to actually build the EAM screens) Document management (version control, check in/out, search index, red lining etc.) Workflow (configuring transactions/documents to be processed through business rules not coded into the application) Business intelligence (reporting tools and analysis) Portals (report and information “dashboards”) Enterprise application integration (exchanging information between applications) Graphical viewing tools (image rendering)
• Mobile computing and many, many more…

EAM vendors knew these 3rd party products would make buyers nervous—most of our product partners were smaller than we were—so we buried them in private label agreements or anyway we could keep the focus on the work order and off the plumbing. It turns out we were right to hide this; the overwhelming majority of these 3rd party EAM relationships have failed9.  
Unless vendor support, cost, implementation length, employee training and enterprise information sharing aren’t important to your maintenance business; technology does matter. When evaluating EAM systems, saying you don’t care about technology is like saying you don’t care who lays the foundation footers because you can’t see them.

snow.lovers

How many of us took one of our engineers or a technical tradesperson and anointed them the “power user”? In addition to being the “answer tech” on all EAM issues, these folks often developed reports and some added users and changed security profiles. Many maintenance chiefs have decided it’s cheaper to have a “go to” person on their payroll than wait for IT to get around to their requests. While this may have addressed maintenance’s immediate needs, it didn’t really help the company’s “big picture.” Creating departmental “system administrators” introduces staff redundancies, process inefficiencies, and makes IT costs harder to track and improve.  This has become an even greater concern as companies struggle to measure the return from their IT systems. Figure 1 illustrates how a Fortune 100 company characterized thirty-plus years of spending on EAM software.
One of the main problems is the accuracy of the IT project costs, especially point solution projects. We all know the out-of-pocket expense (software, hardware, and implementation services), but how many of us can report a true project cost including overtime, lost production, turnover, additional IT support expenses etc. If you can’t, you’re not alone. Studies show IT project costs are typically understated by four to five times.

Figure 1
“If EAM/CMMS are supposed to deliver so much value, how come my labor and material spend is a flat line?” Global EAM Coordinator

Corporate growth strategies, including merger and acquisitions plans, are also important considerations. Gartner reports that CIOs are expected to deliver up to 30% of synergy savings. Did you know that 95% of EAM vendors are under $5M in revenue and have less than 100 customers? If you are a user of one of these products, how much synergy will you contribute to the company’s strategic growth objectives? Will maintenance be an enabler of corporate growth or just another issue to be dealt with? We probably aren’t going to help the company much if we cling violently to our own view of what a maintenance system should be. If we take a broader view and realize that IT and cost structures do matter, perhaps we can contribute positively to our organization’s competitive advantage.

snow.lovers

Almost every application software product is a descendant of On Line Transaction Processing (OLTP), a mainframe construct for writing software to automate a business process. The main purpose of an OLTP was to get customer orders or invoices into an electronic record so the paperwork wouldn’t get lost. Wanna’ guess what the first EAM really was? An OLTP for work orders! Some did create some “online reports” (e.g. equipment cost history), but EAM/CMMS products were conceived, designed, and built as transaction processors.  
Early developers didn’t realize the customer wasn’t buying transaction automation; they wanted information. Customers wanted to know your worst offending assets, how to control overtime, the least reliable parts/vendors etc. Software’s dirty little secret is that we rarely thought about these requirements until the application had been designed and delivered10.
This problem stems from the way we were taught to build software. Despite the term de jour (rapid application development, prototyping etc.), most software is built under the same forty-year-old construct called Waterfall Development:

Define Design Code Test
• Implement

While report writing technically occurs in the Code phase, developers wait to build reports until the data model is stable. (That is, they don’t write reports until all information in the application has been identified, named, formatted etc.) You might find this surprising, but software isn’t really stable until the Implement phase when our quality assurance (QA) engineers have run the software through extensive testing. (You’re experience is the software might not be stable even then? You say it takes months of field deployment before you consider it stable? We know that! That’s why we can’t write many reports. We focus our programmers on the problems QA finds. By the time the software gets to the customer, only a fraction of the original developers are still deployed on the current release. Most have migrated to the next release, which is why we often ask you to wait “for the next release.”
Application software development should start with the information and not the transaction. Vendors should be thinking about that worst offender report before designing a single transaction. Can there be any doubt that our dismal ROI performance (16% real ROI from application software; see Mistake #2) stems from the scant attention we paid to what customers really needed? Customers never cared about how they entered work orders; they just wanted to know how to spend less on maintenance.
The Only Constant is Change

Despite my tongue-in-cheek confessional, those of us in application software weren’t morons, misguided or mean. We believed in what we did and our efforts made today’s progress possible. We were right that software could make people’s lives easier and businesses run better. But, we too often ignored signs that were fundamental to our long-term success. Our success should have been measured by how much how customers used our software and not by our competitor’s latest release. We needed software that served the enterprise, not just our own parochial view of the universe. We should have built more flexible software to support process changes and invested more in technology.
Wouldn’t it be great to visit Delphi and see what the Oracle11 says is coming for maintenance.  If EAM history is a guide, another seismic change is on the horizon12.  We may not know the survivor’s names, but I’ll bet their software will be simpler, more integrated, and cheaper.  For most companies, the Holy Grail of application software—return on investment—has never been discovered. After spending billions of dollars looking, the market just needs a drink. Maybe this time we’ll get something the entire company can benefit from.
About the Author
Dave Loesch has designed, built, and implemented EAM/CMMS for over twenty years. He has worked as an Implementation Associate, Vice President of Product Management, and the Vice President of Marketing for The System Works/TSW International. He has owned P&L responsibility for a number of software businesses including procurement, time and attendance, and business intelligence. As the Managing Principal of YieldPro Consulting Group, Loesch consulted with scores of application software companies—including most of the current EAM market leaders—on product development, strategic business plans, and fund raising. He currently leads the Oracle Industry Business Unit for Maintenance Solutions, which includes Oracle’s Enterprise Asset Management (eAM) solution in production at over 300 sites worldwide.

浪迹天涯

好东西，那个翻译一下就好了

papa

好多的字母啊!有中文的吗?

臨風買醉

1.企业价值的增长来自流程的改进，而非软件。
2.更多功能不意味更多价值
3.应用简单是建立在理解的基础之上的
4.应用软件都是专业的
5.技术并不重要
6.成本是其他人的问题（王顾左右而言他）
7.…………不明白，太专业
[s:4] [s:4]

snow.lovers

水手上有中文翻译的发一下撒

systemthinking

Dave Loesch的演讲,我去年翻译过,见我的blog(http://system-thinking.spaces.live.com)

本来要贴在这里的,但是字数限制没有办法全贴上来了。

------(节选)---------
2006年4月19日， 在美国伊利诺伊州芝加哥市罗斯蒙酒店举行的维修及可靠性技术峰会上，甲骨文公司的Dave Loesch发表了一篇演讲，以下是演讲稿的原文、译文、以及本人的分析和说明。本人认为，其实从EAM的起源和历史来说，中国EAM领域的从业者和用户，可以从西方发达国家二十多年来的EAM发展历程中吸取宝贵的经验和教训，我们来看看这位做了二十多年EAM的专家是如何分析EAM的过去、现在、和未来的吧，他山之石尚且可以攻玉，何况这是一位做了一辈子EAM的老专家的经验教训的总结呢？虽然是国外的专家，但是我们不要动不动就说什么中国的国情云云，其实仔细分析，我们会发现，跨越语言的障碍以后，EAM，或者进一步说，任何管理信息系统，不论是在西方还是东方，不论是在信息技术的起源地美国，还是在期待以后发优势，信息化促进工业化的中国，很多方面是有着相同的共性的规律的。http://www.reliabilityweb.com/art06/7_mistakes.htm

corel2002

他是为了推 Oracle EBS

danceswim

谢谢


鼎力  顶