Navigation
Home
News
Newsletter
Knowledge Bases
Web Workshops
Tutorials
Directory
Books
Maintenance-Tips
Conferences
Forums
Photo Albums
Reliability Radio
Benchmark
Calendar
Gadgets
Jobs
Twitter
Network Links
Archives
en Español
XML/RSS Feeds Advertise

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

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.

Mistake #1: “Show me the money” comes from process change, not software 

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. 

Mistake #2: More functionality doesn’t mean more value 

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?

Mistake #3: Ease of use is an after thought 

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 answer⁶.  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!)⁷ 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. 

Mistake #4: Application software is specialized 

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. 

Mistake #5: Technology doesn’t matter 

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 developers⁸,  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 failed⁹.  

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. 

Mistake #6: Cost is somebody else’s problem 

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. 

Mistake #7: Damn the (Information) Torpedoes! Or, “We put the T in OLTP” 

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 delivered¹⁰.

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 Oracle¹¹ says is coming for maintenance.  If EAM history is a guide, another seismic change is on the horizon¹².  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.

[1] Each estimate depends on how you define the market. Some analysts include Information Technology Asset Management (ITAM), but exclude Computer Aided Facilities Management (CAFM). Some studies include estimated revenues from Enterprise Resource Planning (ERP) vendors while others do not. The principal analysts that follow EAM—defined by the author as work management and asset history products for maintaining equipment, buildings, fleets and networks—would agree the market is approximately $1B in annual software and services spend.

[2] In contrast to other software companies like Oracle and SAP, which have accumulated operating profits of 172% and 89% respectively over the same timeframe.

[3]Before you burn your EAM vendor in effigy, know that this problem is not exclusive to EAM.  In the 1980s companies like Coda and Cyborg dominated the “point” financials market yet today there is no such as thing as a “standalone” financials vendor. Marcam and Datalogix blazed new trails in process manufacturing with formulas, recipe management, and multiple units of measures yet the “standalone” process market is gone.  Supply Chain Management? i2’s revenue has plummeted from $908M to $375M. Customer Relationship Management? The dominant share leader, Siebel, dropped from $2B in revenue to $1.3B, and is in the throes of being acquired by Oracle.

[4]When originally designed, most CMMS required an Equipment number when creating a work request. The assumption was production had to tell maintenance where to go to fix the problem. This “best practice” –and I have heard it described that way—didn’t work in a hospital where nurses wouldn’t have a clue about the equipment number.

[5] You’re not alone if you thought the software would be a change agent and there are a few success stories. AMR, Gartner and others report that application software projects deliver ROI about once every five projects. (AMR: “Real ROI averages 16%.”) However, many customers find that ROI occurs when they implement business process changes that the software happens to support.

[6] Be prepared for every vendor to whip out their demo kits and debate you til’ the cows come home on this one. “We are easy to use! Let me prove it!” But, the sad reality is ease of use has never been a driver in application software. Just check the vendor’s next release notes and see how much of their development effort targets “new stuff’ versus usability improvements.
 
[7]OK, there are software developers now working for phone companies so some of the newer models have some really angry technical manuals. But, how many of you have actually read them and take advantage of all the functions? I wonder if it might be within a stone’s throw of the 15% adoption rate of EAM software?
 
[8] There are only four or five EAM vendors that have more than 100 developers. Almost all EAM vendors divide those developers among multiple product lines. (For example, the company with the largest EAM development staff—MRO has 228 developers—splits those developers across multiple products [Maximo version 6, Maximo version 5, Maximo version 4, MainControl et al].

[9] Every point vendor changes application development tools when technology undergoes a major shift. (e.g. client/server to browser.) The Progress and Powerbuilders of the client/server days have been replaced by an entirely new host of players in the EAM “browser” space. In some cases, EAM buyers are left holding the bag when point vendor application tools—like Gupta—go bankrupt. Other EAM “technology” failures include document management companies being acquired by eCommerce companies (and abandoning engineering functionality) and the dizzying array of acquisitions in the mobile computing space. Partner de jour dominates search engines, illustrated parts catalogs, tool control, RCM, dashboards, MSDS and other EAM “essentials”. Application vendors like SAP and Oracle are taking control over more parts of these “technology” components because they realize customers cannot handle the disruption when a part of the solution is yanked out from under them. (Markets are cruel masters.)

[10] To validate this, ask to meet your EAM vendor’s best and brightest developer and ask them when they last developed a report. Asking a software developer to write reports is like asking a Winston Cup winner to drive car pool. All the “heavy lifting” (i.e. intellectual challenge) is perceived to be in the transactions. Furthermore, report writing is the last thing development thinks about when building a new release. In most cases, report writing is delegated to new hires or the support staff.
 
[11] As an employee of the Oracle Corporation, the author apologizes for this shameless plug.

[12] Character based (“green screen”) CMMS started shipping in the late 1970s and had a lifespan of 20-25 years. (Off the market by the early 1990s.) Client/server systems appeared in the early 1990s and were replaced by browser systems within 10-12 years. Browser-based EAM systems first appeared in 2000 meaning their replacement should come in the 2008-2010 timeframe.