Oracle EAm vs Maximo

Oracle eAm Vs Maximo

•

• • •

1

• •

4

2 3 5 (6 votes, average 3.83 out of 5) Written by Ronin Jackson | 10 August 2010 Oracle eAm Vs Maximo This document was prepared to help Maximo customers consider the issues involved in replacing Maximo with Oracle’s eAM product. The document contains references to specific functionality of each product, but also highlights strategic issues involving integration, product support, and long-term viability. Given that the enterprise asset management (EAM) market is dynamic, we recognize that some of this information can be superceded by vendor strategy shifts or product releases.

Note: Before you go through this document, you are advised to have a look at the article Oracle eAM Vs Maximo Vs SAP Vs JDE Vs Indus Vs Infor eAM. which is a complete product comparison of eAM vis-a-vis other players in the maintenance applications. If however you are looking just for Maximo Vs eAM comparison and you have time on hand (cos this document is quite long), please read on However, we feel the document highlights representative issues that should be considered when comparing eAM to Maximo.The following differences should be considered: Terminology and Process Flow Flexibility versus the Best Practice “Box” Business Intelligence Integrated Technology Stack Web-architected product Integration and Access to Enterprise Information

Improved Financial Controls Automated Scheduling Inventory/Materials Management 10.

Procurement

11.

Quality/Collection Plans

12.

Extended Enterprise

13.

Complete Asset Life Cycle Management

14.

Global Enterprise Management

15.

Other Considerations

Terminology and Process Flow Every software package has its own terminology and process flows. While at a high level, the process flows are similar (i.e. requesting-planning-scheduling-closing work) the programs a particular vendor builds will vary slightly. The biggest difference a customer notices is the terminology. Although MRO and Oracle often use similar terminology, the differences will require Maximo users to get accustomed to the Oracle eAM terminology and process flows. (The reverse is also true. If an eAM customer wanted to use Maximo, they would have to get familiar with the new system’s terminology and process flows.) Another dimension of this issue is the difference in the product footprint. Maximo users are most often the maintenance department. Even if other users—inventory, purchasing, accounting—are accessing Maximo, they understand they’re looking at maintenance-specific information so they expect maintenance-only terminology. This assumption is not the case with Oracle. As an enterprise system, our “first-line” customers include maintenance as well as virtually all enterprise departments. Consequently, we often use terminology that is generalized for multiple departments. For example, the Oracle “Item Master” is used to build inventory items, rebuildable stores, asset groups and activities (preplanned work orders). Clearly, maintenance will not recognize “Item” as a description that incorporate Asset Groups. However, the low cost of ownership of the Oracle solution requires that we leverage similar objects to minimize the technology footprint and to lower training and support costs. Of course, we would never ask a tradesperson to enter an “Item” when we are asking for an “Asset Group,” but user involved in set up may encounter occasional unfamiliar terminology. As an enterprise solution, Oracle also tracks information that point solutions do not. One example is accounting information. In point solutions like Maximo, the accounting information is fairly simple. (Usually limited to cost centers and/or general ledger [GL] account codes.) In Oracle, you will often see the concept of credit and debit accounts because accounting practice requires financial transactions to balance. While Oracle’s approach doesn’t require any additional work on the part of the user—the system will default values as determined by the GL—these values will display in areas of eAM. While maintenance users do not need to concern themselves with the details of the accounting system, eAM manages these relationships so

financial integrity can be maintained. In summary, the terminology “translation” process is adequately handled through process review and product training. However, customer project managers should look for cases when users are resisting change simply because they are accustomed to the previous system. In many cases, more efficient ways of accomplishing maintenance tasks can be achieved if users can be encouraged to consider new operating practices. [Go To Top of the Document]

Flexibility versus the Best Practice “Box” Many point solution vendors jumped on the Best Practice bandwagon because it helped them achieve an important business objective: reduce lines of code and minimize customer modifications. Material reservations are a good example. If vendors could convince customers that material reservations should be soft (i.e. allow someone other than requestor to retrieve the material in an emergency) then the EAM vendor only had to program one way of processing MRO inventory requests. Of course, customers often want certain reservations to be “hard” meaning the material hold cannot be released without specific action. Because of the size and diversity of the Oracle customer base, “best practice” is often an elusive concept. It’s almost possible to arrive at one business practice that works equally well in all industries and all customers. This helps explain why Oracle asks so many questions when a customer describes a business requirement. To continue with the material example above, the customer might ask “Can we place hard reservations on material requests?” A good implementation manager will ask you in what cases you need hard reservations; understand when soft reservations make sense; and, will continue to probe until we fully understand your requirements. At the end of the day, Oracle eAM supports both hard and soft reservations, but the issue is not what the software can do, but how it needs to work for you. The larger issue is Oracle eAM rarely has one way of accomplishing a specific task. We often have two or three or even four ways of meeting a customer request. We rarely talk about best practices because there are simply too many kinds of customers for any one solution to work equally well for all of them. This goes to a fundamental difference between a point solution like Maximo and an enterprise solution like eAM. MRO is a $200M company with 200 developers all focused on one application: maintenance management. They make money by getting as many customers as they can to buy the same software version. When a customer requests a change to Maximo, it’s a losing business proposition for MRO because they need to focus developers on software that can be resold to a very targeted market. Oracle is a very different kind of company. Our customer is the entire enterprise. Our 6,000+ application software developers deliver software to manufacturing, supply chain, finance and maintenance; our customer is also the IT department—primarily served by another group of 3,000 developers—who relies heavily on our application development, database and business intelligence tools.

With over 40,000 customers, Oracle hasn’t tried to develop one solution that fits every customer. Like point solutions, our goal is to deliver highly functional, relevant software to the line of business. However, we recognize that customers also need software that can be adapted to unique business needs. [Go To Top of the Document]

Business Intelligence The first thing a user might notice when comparing MAXIMO to eAM is the difference in the number of standard systems reports. As a product in the market for over 30 years, Maximo has a more extensive library of standard systems reports. However attractive these reports might seem, Oracle takes a different approach. Over 13,000 application projects has taught us the most accurate answer to the question “How many standard system reports do you have?” is “One less than you need.” The bottom line is every customer, every project, and every user has unique information requirements that are rarely addressed by canned reports. Sometimes the variations are minor—change the order of the report columns; remove/add a field etc—but often the differences are more complex (calculate/include production statistics, backorder information, RMAs etc.) Importantly, standard system reports are rarely built in the “user friendly” query language tool. Standard system reports are almost always written with the same tool as the program that runs the PM schedule or prints the work order. These “server side” reporting tools require more horsepower because they are often calculating values or massaging large amounts of data. They are also much more complex to use and almost always require programming skills. The first component of the eAM strategy was to provide report information where it is most needed: in the application where users can get at the data without waiting for a report to be generated. Many eAM transactions contain embedded BI. That means, while technically a “report” may be running in the background, the information is presented to the user as part of the normal business flow to facilitate realtime decision making. Furthermore, any ad hoc query or report written with Oracle tools can be displayed on the user’s screen and this information can also be configured to be accessible to users as part of transaction flows. The most important element of the eAM BI strategy is the Oracle technology stack. Oracle applications, including eAM, take advantage of native capabilities of Oracle technology including Discoverer (ad hoc reporting/analysis/Web reporting tool). Our most compelling BI offering comes through Daily Business Intelligence (DBI). With DBI, customers no longer have to extract data from the EAM system and transfer it to a data warehouse. Oracle has merged the capabilities of an online transaction processing (OLTP) system with the multidimensional analysis capabilities of a data warehouse into a single information architecture. Not only does an integrated environment means less technology infrastructure and support cost, it means the maintenance department has access to real-time BI data from which they can drill down to live transactions to understand

the root cause of a problem. With point solutions like MAXIMO, the enterprise BI is managed outside the maintenance application and costly, redundant decision support environments are required. Furthermore, drill down to real-time transaction data is virtually impossible because of the cost. [Go To Top of the Document]

Integrated Technology Stack Unlike MRO or other point solutions, Oracle delivers the application software (eAM) and the development tools used to build the application. (Point solution vendors have to rely on 3rd party companies for their development environments.) Because point vendors have to compete with much larger development engines (again, Oracle has 3K technology developers alone that contribute to eAM functionality) the point vendors must seek out the latest technology that can create a perceived competitive advantage. Maximo’s screen customization is an example of this. Many MRO customers chose Maximo 4 (client/server version) because the product allowed customers to change field labels, alter screen formats etc. without modifying source code. However, when the Internet took off, the company that MRO relied to provide that capability went bankrupt. 1 MRO was forced to re-write the capabilities of the 3rd party product (distracting even more developers from building EAM functionality). Perhaps, most importantly, this strategy shift means Maximo 5 customers cannot migrate the alterations they made in version 4. In addition to what we call the Oracle Application Framework (the application development environment/toolkit), Discoverer (query language); workflow; OLAP (multidimensional analysis); CAD; and DBI are additional examples of how the Oracle “technology stack” is integrated with and adds value to eAM. Not only does an integrated technology stack mean lower IT costs, it speeds implementation and ROI because users have to install and learn. In all of these cases, MAXIMO must partner with a 3rd party company to deliver comparable functionality. Not only does this add to the MRO acquisition cost, but more importantly, it represents significant long-term maintenance costs as these multi-vendor solutions have to be maintained and re-implemented through the subsequent product releases of each vendor. (In worst-case scenarios like the MRO screen customization tool, the burdens are insurmountable and the company goes out of business.) With Oracle, these integrations are supported “out of the box” and we own the testing and performance of the entire suite before we deliver it to a customer. Finally, leveraging the integrated technology stack allows Oracle eAM to deliver unparalleled performance. Most point solutions, including MRO, have architected their applications to support multiple data bases (SQL Server, Oracle etc.) Oracle eAM is available only on the Oracle data base platform so we are able to take advantage of the native capabilities of the Oracle database. Although database independence is an

advantage to the vendor, it does nothing for the user. Oracle has opted to limit our market opportunity in favor of delivering the highest performing application to our eAM customers. 1

Nor is MRO alone in this problem among point vendors. In 1995, TSW launched its client/server product

using development tools/infrastructure from SHL. When SHL was sold to AutoDesk, support for the EMPAC class libraries went by the wayside and TSW was ultimately acquired by The Indus Group. [Go To Top of the Document]

Web-architected product “Web-enabled” means a software application can be run over the Internet. “Web-based” means the product was designed from the ground up to optimize the unique capabilities of Internet computing. As a product that was designed for a PC and migrated through several technology generations, Maximo can only be described as a Web-enabled product. In fact, browser support is Maximo’s only Web-architected feature. The Java components in Maximo 5 communicate using CORBA and COM, not XML Web services as Webbased products do. When compared to XML Web Services, Maximo component integration is a specialized, programming-intensive, binary, and firewall-bound process. Maximo components were a necessary re-write to replace obsolete 4GL development environment sourced from company in bankruptcy. MRO has made no firm commitment to delivery of a complete XML Web services interface. It’s likely no accident that MRO is the only major EAM software vendor that doesn’t host its own software so that customers can access it over the Internet. [Go To Top of the Document]

Integration and Access to Enterprise Information By design, point solutions like MAXIMO must be interfaced to other enterprise applications. At a minimum, this means the MAXIMO work management system must be interfaced to inventory, purchasing, accounts payable, contractor management, and the general ledger. In more complex environments, MAXIMO may also be interfaced to manufacturing, fixed assets, projects, and property management. Some clients may even want their EAM system to communicate with customer facing applications (call center/CRM), order management (service contracts) and accounts receivables (work order billing). Some point vendors—including MRO—have developed “standard” integration kits to the Oracle E-Business Suite. In most cases, this integration focuses on Oracle financials, that is, posting maintenance labor and material costs to the general ledger. Despite the fact that Maximo pre-builds this integration and can ship it to the client “out of the box,” in most cases the interface is often executed on a weekly or even monthly basis. (Point solution vendors will always tell you that you can update the GL as often as you want—weekly, daily, hourly—but the infrastructure cost and support requirements almost always lead customers to chose to run less frequent updates.) Some point solution vendors do offer “integration kits” to Oracle purchasing. (The ability to send an inventory

demand signal or direct requisition to the purchasing system.) However, these interfaces are focused on communicating the demand and do not integrate the complete purchasing process flow back to maintenance. (For example, MAXIMO-to-Purchasing integrations often do not send purchasing status data back to the maintenance system. Even fewer allow maintenance to “drill into” purchase order details or provide vendor performance data to the requisitioner.) Like the GL interface, the overwhelming majority of MAXIMO-purchasing integrations are handled on batch basis. While a purchasing interface will likely be more timely (usually nightly), maintenance still deals with information that is 24 hours old. Of course, MAXIMO offers no standard integration to other Oracle modules like inventory, property management or manufacturing, so these interfaces have to be custom built. Although the nature of a “pre-built” integration to Oracle financials or purchasing sounds appealing, it overlooks the most costly aspect of the project: maintaining the integration through upgrades and new releases. Virtually every software company in the world—including Oracle and MRO—are committed to at least one important release of their software each year. Almost all software companies, augment these annual releases with several point releases or patches to add minor functionality throughout the course of a year. Even if you limit yourself to one upgrade per application every other year and only accept a patch release in the “off year,” adopting an EAM point solution strategy requires one significant release each year and at least two patches per year (one per application). What vendors often don’t tell you about certified “integration kits” is the integration is certified on the last release of each vendor’s products. Every time a change is made to either application, the entire suite must be re-tested. Furthermore, maintenance is not an isolated application. The maintenance applications interacts with inventory, purchasing, AP, GL etc. and a change in any one of these areas will require significant testing and QA. Likewise, a change in the EAM application is likely to require testing and QA in the other applications. The cost to develop an interface to an enterprise system can be as much as $100,000. There are nearly 80 touch points between Oracle’s eAM and other modules in the E-Business Suite meaning the cost to develop these interfaces from scratch could be as much as $8,000,000. Even if the integration is “pre-built,” there are generally costs associated with testing against a client’s specific instance and configuration. Most importantly, every time you upgrade either application, the system must be re-tested and certified, which will consume weeks and even months. With a highly integrated point solution like EAM, you can rapidly find yourself going from one upgrade testing cycle to another, which is costly and extremely disruptive to daily operations.

[Go To Top of the Document]

Improved Financial Controls As was mentioned, point solutions like MAXIMO track the GL account code on work orders. Most often these account codes are combinations of a cost center (department) and a transaction type (labor charge, materials, etc.) If the user wants to capture a specific charge code (e.g. contractor services, a special projects fund) the user must remember the code or look it up and manually change the code on the work order. (Changing account codes can also affect the proper accumulation of cost history in point solutions.) Oracle avoids the complexity and errors associated with this disjointed process by integrating the GL with eAM. Furthermore, eAM tracks debit and credit accounts so maintenance costs balance with the general ledger. (At one mining customer, the implementation of Oracle’s eAM resolved a $6M imbalance between the general ledger and the point solution. These kind of imbalances are becoming increasingly unacceptable in an age of increased corporate governance.) Not only does Oracle’s integrated eAM-financial solution provide an audit trail of all transactions, but the information is available real-time. Because of the sophistication of other Oracle modules like purchasing and accounts payables, Oracle eAM is better suited to process purchase price and invoice price variances back to the work order and the asset. Most point solution integrations rarely attempt to integrate their work order system with the purchasing and invoicing subsystems of suite vendors because the interfaces are very complex and expensive to maintain. Finally, Oracle eAM provides more flexibility in correcting GL postings. Point solutions often manage to this issue with a two-step work order completion process. In the first step, work orders are “completed” so they are removed from the backlog. Completed work orders can usually continue to accept material and labor charges. Once the work order is “closed”; however, the charges are posted to the GL and the work order is effectively archived. (That is, no longer allows changes.) Although Oracle eAM supports the same two-step work order completion and close process, we can allow maintenance to re-open a “closed” work order because of the suite’s inherent integration. [Go To Top of the Document]

Automated Scheduling Although few customers actually use the functionality, MAXIMO includes algorithms to automatically schedule work. The fundamental challenge in automated maintenance scheduling is the fact there are typically too many variables1—and scheduling parameters vary from industry to industry and customer to customer—for a software package to accurately and predictable manage maintenance schedules. Despite the challenges, automated scheduling is something of a Holy Grail in the EAM market. When we launched eAM, we studied the issue carefully and relied heavily on the input of development partners like ALCOA. We learned of several previous development efforts to build automated scheduling engines, but found very few customers who had actually deployed the technology. (One industry expert estimates fewer

than 5% of maintenance departments use a CMMS to schedule at the employee level.) Our research uncovered a common denominator in many of these scheduling products. Most EAM scheduling systems were built in conjunction with a specific customer. While the developed software may have worked for that specific client, few other customers could apply the scheduling principles built into the software. We elected not to repeat the errors of previous EAM vendors and invest significant resource in a scheduling system that significant customers would not adopt. While we have not ruled out the notion of building an automated scheduling system, we are following the market and listening to customers to provide the fundamental concepts that a number of customers can embrace. 1

Scheduling variables include but are not limited to tradesperson availability (work schedule, location); skills,

certifications and aptitudes (including asset, job, material, and tool familiarity); material, equipment, and tool availability; contractor involvement; production priorities etc. [Go To Top of the Document]

Inventory/Materials Management Because Oracle’s inventory module was designed to manage raw materials, finished goods and MRO supplies, the materials management functionality of Oracle’s eAM far surpasses point solution capabilities like MRO. Of course, eAM includes the “basic” MRO inventory functionality like requisitions and workflowbased approvals; stock and non-stock management; automatic reordering; receiving; physical inventory etc., but we require more sophisticated functionality to service global inventory organizations. Examples relevant to maintenance materials management include: In addition to the “traditional” MRO re-order algorithms (Min/Max, ROP/ROQ/EOQ), eAM allows customers to utilize sophisticated material requirements planning (MRP) and Advanced Planning Systems (APS) to optimize materials management. Lot tracking is an inventory concept most often used in manufacturing and as such is rarely available in eAM point solutions. One example of how lot tracking can provide value to an MRO organization is support for warranty tracking on non-serialized inventory items. Oracle has developed sophisticated vendor managed inventory (VMI) and consignment inventory systems as part of our raw materials and finished goods inventory systems. Oracle also supports advanced shipping notices (ASN). eAM provides full access to these advanced materials management functions. Unit of Measure and decimal quantities are typical shortfalls of point solutions like MAXIMO. Again, the production material handling capabilities of the Oracle Inventory system provide advanced functionality if these areas. Sophisticated three way and four way (inspections) matching including integrated use of the Oracle Quality module. Multiple stock room management allows plants to manage separate warehouses (with separate

ROPs) and/or manage multiple stock rooms across multiple plants/geographies. [Go To Top of the Document]

Procurement Point solution purchasing solutions like MAXIMO are geared to MRO materials and, to a lesser extent, services. (Point solutions often require an inventory “receipt” of services to be able to post charges to the work order.) On the other hand, Oracle has a robust enterprise procurement system designed to support advanced procurement capabilities including global agreements with subsidiary/plant implementation; workflow-based purchase order and contract approvals; real-time shipment tracking and tracing (FedEx, UPS etc.); supplier transaction hubs; reverse auctions; clause libraries with version control; and digital signatures. Oracle also offers extensive vendor performance management tools including DBI with procurement-specific KPIs (e.g. contract leakage, non-contract purchases; invoice growth; price savings etc.) and an optimization engine (including the ability to enter constraints like minority owned firms) to assist in vendor selection. [Go To Top of the Document]

Quality/Collection Plans The Oracle E-Business Suite includes a powerful tool called Quality/Collection Plans. Collection Plans are multi-purpose, multi-use data templates that can be attached to an asset, asset group, work order, or work order step. The user can define the fields of information to be collected as well as the format (data type, attributes etc.) You can also specify the values that can be entered in the collection plan and, most importantly, you can trigger actions off the data collected. That means, a particular value entered into a collection plan could trigger an email, create a work request, generate a work order etc. Collection plans have been successfully deployed by eAM customers to manage wide range of business functions including reliability centered maintenance (RCM) programs and job standards. Collection plans are a powerful, user-configurable, release protected technology that can be used to address many of the unique business requirements of a maintenance department. [Go To Top of the Document]

Extended Enterprise As an enterprise solution provider, Oracle offers more capabilities to integrate maintenance with the extended enterprise of suppliers, customers, and partners. Specific examples include:

Internet Procurement (iProc) iProc allows maintenance users to “punch out” to an Amazon-like user interface (shopping carts, express

check out etc.) to requisition MRO items. While iProc can be integrated with single supplier catalogs like Grainger or McMaster-Carr, it can also manage a corporate catalog linked to multiple vendor catalogs for easy price and availability comparisons. iProc is seamlessly integrated with eAM so the requisition description entered on the Work Order is carried into the iProc shopping cart. Details of completed procurement transactions are likewise carried back to the work order.

iSupplier Maintenance departments are increasingly relying on contractors, and, in some cases, assuming full responsibility for maintenance execution. Traditionally, point vendors required that contractor’s use the system (just like an employee) to manage asset and cost and history. However, contractors rarely wanted to learn the customer’s EAM product and, customers were reluctant to provide access to internal systems. Traditionally, customers with heavy contractor usage had three options: 1) Assign entering and closing contractor work orders to an employee (a significant administrative burden); 2) Require the contractor to enter information into a stand-alone system (which provided no integrated view of asset performance and required additional IT support); or 3) Allow the contractor to use their own system (which avoided the additional IT expense but provided no asset or work management visibility or history). Oracle has solved this complex issue with iSupplier. Not only can contractors manage purchase orders and invoices through iSupplier (reducing the burden on buyers), they can also review assigned work orders; enter time against work orders; and close work order operations (when internal resources are co-mingled with contractors on multi-step jobs). Of course, because they are using eAM work orders, all work and asset activity and cost histories are maintained for the customer’s use. Because iSupplier is “self serve” interface requiring minimal training, contractors can be replaced with minimal effort. Most importantly, iSupplier restricts a contractor’s access to only their data so security and data integrity controls are maintained.

Oracle Supplier Network (OSN) An Internet-based transaction hub that integrates Oracle purchasing with key supplier’s order management system. Customers can manage their own environment or run OSN through Oracle’s hosting service, On Demand.

Service Oracle offers a Call Center product that allows customers to “call in” requests for maintenance support. The call center rep can immediately dispatch work to maintenance and use the call center interface to communicate with customers and provide real-time updates on work status. [Go To Top of the Document]

Complete Asset Life Cycle Management Almost every EAM point vendor claims to offer its customers “asset lifecycle management.” However, a

point solution’s view of the asset lifecycle is limited to maintenance activities. Although a point solution may capture the fixed asset number or a property asset identifier, it only functions as a reference field with no access to the related functionality behind the identifier. No point solution—and this includes Maximo—can manage the complete lifecycle of the asset including fixed assets, design/construction, production, and property management. Unless you plan on building and maintaining interfaces between MAXIMO and your other enterprise systems in all of these areas, you will never achieve the integrated information environment required for asset lifecycle management. On the other hand, consider how Oracle’s E-Business Suite provides “out of the box” complete asset lifecycle management:

Financials Using Oracle Projects and Fixed Assets customers can manage capital projects and create fixed asset records. eAM functions as an integrated work breakdown system for capital projects and eAM work order costs and assets are linked to the Fixed Assets system. Of course, for assets that are already in place, eAM supports a one-to-one or one-to-many fixed to maintenance assets relationship so fixed asset data (e.g. depreciation schedules) can be considered in the evaluation of the total maintenance and operating costs.

Manufacturing Similarly, eAM assets can have a one-to-one or one-to-many relationship with production assets. This enables production to manage and schedule equipment for its master production schedule while maintenance can manage the equipment from a maintenance perspective. eAM work orders are reflected as capacity constraints in the production schedule and both planners (maintenance and production) can view each other’s work order backlog to decide when to schedule production and maintenance work.

Property Management Large organizations often want to use Oracle Property Manager to manage its physical space (square footage, use, lease information etc.). For complete asset lifecycle management, this information must be linked and integrated to the eAM system. Oracle allows property managers to build their facilities hierarchy in Property Manager and then export that information to eAM. However, it is not a simple export routine. eAM includes a data-scrubbing tool to transform property’s view of the asset into a structure that makes sense to maintenance without losing the benefits of integration. [Go To Top of the Document]

Global Enterprise Management Oracle implementations are typically multi-site and often multinational. This means we had to build a system that provided enterprise information management without sacrificing individual plant productivity. For example, Oracle customers often want one inventory system, but they don’t want maintenance to have to scroll through production’s raw material lists (or vice versa). Similarly, if maintenance departments support specific plants or P&Ls, you might need to segment the data so maintenance only sees the assets and work

orders relevant to their responsibilities. Likewise, you may want to manage multiple inventory locations on an enterprise basis to leverage volume purchasing, but you don’t want a tradesperson to have to scroll through the entire corporate catalog to locate a part at his warehouse. Oracle’s sophisticated organization management—starting with global organizations at the HR level and proceeding through production, maintenance, inventory and sub-inventory locations—allows customers to optimize the productivity of plant workers without sacrificing the E-Business Suite’s global enterprise management capabilities. Global enterprise management also means the system must be able to support multiple languages. This goes beyond supporting Japanese in one plant and English in another. Many organizations today have multi-cultural work forces where English, Spanish and French-speaking employees work side-by-side. The only way to adequately address these environments is through multiple language support at run-time. That means, a single instance of the database can display multiple languages depending on the user’s login. eAM leverages the advanced Unicode capabilities of the Oracle database to deliver exactly this functionality. Not only does this optimize employee productivity, multi-language support on a single instance reduces infrastructure requirements and streamlines maintenance and support. [Go To Top of the Document]

Other Considerations Although the following section describes issues outside functional differences, Oracle thinks they are important considerations when comparing eAM to MAXIMO:

Multiple Code Lines Although MRO has a corporate objective of maintaining a single code line, the reality is the company has multiple products targeted at the maintenance market: MAXIMO This is MRO’s flagship product and represents a majority of the company’s revenue. Although the underlying code is the same, MRO does package several industry versions including nuclear utilities, transportation, pharmaceuticals etc. (See Support implications.) MainControl In 2002, MRO acquired a maintenance system targeted at Information Technology Asset Management (ITAM) called MainControl. Although the product shared some similarities with MAXIMO, ITAM requires additional capabilities in the areas of user tracking, software configurations, help desks, and other IT-specific issues. Although MRO has announced it plans to merge this product into MAXIMO, the company only sold three MainControl licenses in the first half of 2004. (Furthermore, the current MainControl product contributes $3.6M in 2003 support revenues.)

How aggressive MRO can be in merging these products remains in question (little new revenue opportunity while risking support revenues). Today—and we expect for the foreseeable future--MainControl is a separate product with separate development resources representing a resource drain on the limited MRO R&D budget. Project/2 MRO actually started in Project Management software (the original name of the company was Project Software and Development, Inc. or PSDI). Although they are no longer actively marketing Project/2, they still provide support to customers. MAXIMO Advantage In 1996, MRO acquired a PC-based product called Chief Advantage from Florida-based Maintenance Automation Corporation. Chief was sold almost exclusively over the phone and the vast majority of installations were single user. MRO tried to incorporate the product into an end-to-end product footprint (hence the Maximo Advantage moniker), but they have switched gears and the product is now sold and supported separately. Maintaining multiple code lines is even more precarious in the current technology environment. Customers have made it clear they no longer can afford multiple “islands of information.” That’s why ERP vendors like Oracle, SAP and PeopleSoft have developed with product offerings not only in EAM, but Customer Relationship Management (CRM), Supply Chain Management (SCM), Warehouse Management Systems (WMS), Product Lifecycle Management (PLM) and other “markets” that have historically been dominated by domain experts like MRO. Once an ERP vendor commits to a point market—as Oracle did in 2000 to eAM— it is very hard for point vendors to “keep up.” Suite vendors marshal development departments numbering in the thousands—Oracle has 6,000 application developers alone—while point vendor R&D staffs are in the hundreds (MRO has about 200 developers across all products). Every point solution developer that is re-directed to another product line makes it even more difficult. While point vendors will say such “developer count” comparisons aren’t “apples to apples,” any way you slice the data the suite vendors have for more resources to apply to customer business requirements. For example, Oracle has over 70 developers devoted to the maintenance module alone. To compare that to MRO, you would also add Oracle’s development staff for inventory, purchasing, accounts payables (invoice matching), iProc, iSupplier, Projects, Property Manager, and other “modules” that provide value to the maintenance function. Without including the developers working on technology elements like workflow, RFID, portals and BI—that adds another 3,000 developers in Oracle’s case alone— Oracle’s eAM development team outnumbers MRO at least 5:1. This is not unique to eAM. Point vendors in CRM and SCM have experienced first hand the difficulty of competing with the ERP suite vendors. Let’s consider the market share leaders in a variety of point markets and what happened once the suite vendors started shipping competitive products:

Point Market

3

#1 Share Leader

Peak Revenue

Current Revenue

CRM

Siebel

$2.1B (2001)

$1.3B (2003)

SCM

i2

$908M (2002)

$494M (2003)

EAM

Indus

$178M (1999)

$111M (2003)3

Excludes about $40M in CIS and billing revenue represented by the acquisition of SCT’s Energy and

utilities business. The dynamics are always the same. Point vendors have difficulty building enterprise functionality with the suite vendor’s multiple development specialists in maintenance, inventory, accounts payables, financials etc. The point vendors also don’t have access to technology infrastructures like Oracle and Microsoft to extend their offering so they often have to partner to deliver comparable functionality. This strategy extends the development timeline and creates support and maintenance challenges. Finally, point solution vendors must build and support the integration to the other enterprise applications that are embedded in the suite vendor’s offerings. It is often this last component (integration) that poses the biggest challenge for point vendors. Most customer IT departments are reluctant to own the integration associated with point applications so the burden on building and maintaining these integrations falls on the point vendor. The companies that can least afford to re-direct previous development resources. Product lines and development resources may seem far removed from the needs of a maintenance user, but it is an important consideration in evaluating the long-term viability of your EAM partner. In some cases, customers use their EAM system for ten years or more. Customers cannot afford to make a major commitment to one vendor only to have them exit the market, retire a product, or otherwise disrupt their use of a mission critical application like EAM. Third Party Integration During the sales and demonstration cycle, customers will often see that MRO promotes a number of 3rd party solutions. This can manifest itself in the form of workflow; SCADA/PLC; mobile computing, and GIS. Part of this is due to the fact that MRO has worked with many of these companies over the course of three decades and they have developed some good sales/marketing relationships.

Although these kind of open partnerships are never bad for the customer, it is important that prospective buyers investigate the degree to which these joint solutions have actually been deployed in the Maximo client base. The reality is many of these partnerships are formed as a vehicle to advance both vendors interest in the sales cycle. While the products may be “integrated” in the demonstration phase, very few customers actually deploy the joint solution because of the cost or a variety of other reasons. The bottom line is these 3rd party partnerships present the same challenges to the point vendor as integrating to ERP applications. They require development, testing, and implementation cycles that must be repeated through each release by both vendors. Now imagine upgrading your point vendor’s EAM; their 3rd party mobile solution, and the Oracle application suite. Although there is no shortage of companies interested in working with Oracle—the Oracle E-Business Suite market exceeds $20B—we often have our own tools, which offer the customer options to competitive solutions. For example, the Oracle technology stack has a wireless component that allows eAM users to use mobile devices. Many 3rd party solutions offer “store and forward” solutions (i.e. disconnected); which can be viewed as competitive to the Oracle product direction. Although our focus is always on what is best for the customer—and we will sell Oracle products or work with 3rd party vendors—we often don’t demonstrate all available options in our sales campaign. One reason is we have a large universe of partners (over 11,000) and we don’t often like to give unfair advantage to one over another in the sales cycle. Implementation MRO has built a respectable $170M+ business around EAM. There does exist an MRO “ecosystem” of independent companies servicing Maximo customers. The most aggressive estimate places the total MRO market at about $350M. On the other hand, Oracle is a $10B company and the Oracle market ecosystem is estimated to be over $40B. Although this is often not an issue when the software vendor wants the deal (no software company is going to ask a customer to wait a year to start their implementation), the real impact is felt down the road when the customer seeks to expand their implementation. It is at this time that a customer will likely feel the pain of a smaller market ecosystem. Trying to find a qualified MRO partner in a $50K or so project—which might be as critical to the customer— can be difficult and promises to be even more troubling as the point market shrinks. Conversely, Oracle has a robust infrastructure of over 6,000+ integrators poised to deliver Oracle expertise on a wide range of service initiatives. Support Although the same market dynamic exists in support as services (smaller market, fewer companies to provide services/support), customers can generally avoid the problem of support through paying annual maintenance fees to the vendor. However, even a willingness to pay support does not guarantee adequate customer service because every application software vendor has “retired” a product and no longer provides

support. Support is affected by the “multiple code line” issue described previously. Every application software product has a period in which support revenues far exceed the cost of supporting the product (usually when the product is no longer actively sold and there are no material sales or marketing costs) and both the vendor’s and the customer’s interests are well served. However, an inflection point is reached when most of the vendor’s developers are interested in working on the new product (essentially a career development issue) and customers start migrating to the new product. This makes development more expensive (because fewer developers are available to support the older version) and revenue smaller. Ultimately, the vendor must “retire” the release (also referred to as placing the product “in support mode” although that term is confusing because what it means is the vendor is no longer adding functionality unless a customer specifically pays for an enhancement over and above what they pay for maintenance) and the customer is left to fend for themselves. Although MRO and Oracle deal with exactly the same business issue, customers should ask themselves which vendor is better positioned to provide long-term support. Who can better afford to allocate resources to supporting older customers: Oracle with its 9,000+ developers or MRO with its 200? Finally, customers should consider the support implications of MRO “vertical” product packages. Today, MRO offers specially configured product kits for a variety of industries including utilities, transportation, pharmaceuticals, IT and others. While these vertical “products” do not represent separate “code lines” (they are configurations of the base software and do not involve source code modifications), they do require support resources. Vendor’s that provide vertical product templates must maintain support resources and technical infrastructure to support these iterations of the base product. These product iterations accelerate the “retirement” iteration point by adding costs and diluting revenue streams of each product versions. While vertical product templates are very appealing in the sales cycle, customers should not ignore the long-term implications of such a fractured product and support strategy.