Oracle eAm Vs Maximo

Oracle eAm Vs Maximo

262

1

2

3

4

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 Oracles 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:

1. Terminology and Process Flow

2. Flexibility versus the Best Practice Box

3. Business Intelligence

4. Integrated Technology Stack

5. Web-architected product

6. Integration and Access to Enterprise Information

7. Improved Financial Controls

8. Automated Scheduling

9. 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 systems 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 usersinventory, purchasing, accountingare accessing Maximo, they understand theyre 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 Oracles approach doesnt require any additional work on the part of the userthe system will default values as determined by the GLthese 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 BoxMany 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. Its 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, its 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 departmentprimarily served by another group of 3,000 developerswho relies heavily on our application development, database and business intelligence tools.

With over 40,000 customers, Oracle hasnt 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 IntelligenceThe 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 minorchange the order of the report columns; remove/add a field etcbut 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 real-time decision making.

Furthermore, any ad hoc query or report written with Oracle tools can be displayed on the users 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 multi-dimensional 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 StackUnlike 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.

Maximos 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.

1Nor 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 productWeb-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 Maximos only Web-architected feature.

The Java components in Maximo 5 communicate using CORBA and COM, not XML Web services as Web-based 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. Its likely no accident that MRO is the only major EAM software vendor that doesnt host its own software so that customers can access it over the Internet.

[Go To Top of the Document]Integration and Access to Enterprise InformationBy 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 vendorsincluding MROhave 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 wantweekly, daily, hourlybut 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 worldincluding Oracle and MROare 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 dont tell you about certified integration kits is the integration is certified on the last release of each vendors 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 Oracles 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 clients 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 ControlsAs 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 Oracles 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 Oracles 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 suites inherent integration.

[Go To Top of the Document]Automated SchedulingAlthough 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 variables1and scheduling parameters vary from industry to industry and customer to customerfor 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.

1Scheduling 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 ManagementBecause Oracles inventory module was designed to manage raw materials, finished goods and MRO supplies, the materials management functionality of Oracles eAM far surpasses point solution capabilities like MRO. Of course, eAM includes the basic MRO inventory functionality like requisitions and workflow-based 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]ProcurementPoint 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 PlansThe 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 EnterpriseAs 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.

iSupplierMaintenance departments are increasingly relying on contractors, and, in some cases, assuming full responsibility for maintenance execution. Traditionally, point vendors required that contractors use the system (just like an employee) to manage asset and cost and history. However, contractors rarely wanted to learn the customers 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 customers use.

Because iSupplier is self serve interface requiring minimal training, contractors can be replaced with minimal effort. Most importantly, iSupplier restricts a contractors 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 suppliers order management system. Customers can manage their own environment or run OSN through Oracles hosting service, On Demand.

ServiceOracle 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 ManagementAlmost every EAM point vendor claims to offer its customers asset lifecycle management. However, a point solutions 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 solutionand this includes Maximocan 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 Oracles E-Business Suite provides out of the box complete asset lifecycle management:

FinancialsUsing 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.

ManufacturingSimilarly, 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 others work order backlog to decide when to schedule production and maintenance work.

Property ManagementLarge 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 propertys 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 ManagementOracle 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 dont want maintenance to have to scroll through productions 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 dont want a tradesperson to have to scroll through the entire corporate catalog to locate a part at his warehouse. Oracles sophisticated organization managementstarting with global organizations at the HR level and proceeding through production, maintenance, inventory and sub-inventory locationsallows customers to optimize the productivity of plant workers without sacrificing the E-Business Suites 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 users 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 ConsiderationsAlthough the following section describes issues outside functional differences, Oracle thinks they are important considerations when comparing eAM to MAXIMO:

Multiple Code LinesAlthough MRO has a corporate objective of maintaining a single code line, the reality is the company has multiple products targeted at the maintenance market:

MAXIMOThis is MROs flagship product and represents a majority of the companys revenue. Although the underlying code is the same, MRO does package several industry versions including nuclear utilities, transportation, pharmaceuticals etc. (See Support implications.)

MainControlIn 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). Todayand 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/2MRO 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 AdvantageIn 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. Thats 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 marketas Oracle did in 2000 to eAMit is very hard for point vendors to keep up. Suite vendors marshal development departments numbering in the thousandsOracle has 6,000 application developers alonewhile 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 arent 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 Oracles 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 BIthat adds another 3,000 developers in Oracles case aloneOracles 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. Lets consider the market share leaders in a variety of point markets and what happened once the suite vendors started shipping competitive products:

Point Market#1 Share LeaderPeak RevenueCurrent RevenueCRM

Siebel

$2.1B (2001)

$1.3B (2003)

SCM

i2

$908M (2002)

$494M (2003)

EAM

Indus

$178M (1999)

$111M (2003)3

3Excludes about $40M in CIS and billing revenue represented by the acquisition of SCTs Energy and utilities business.

The dynamics are always the same. Point vendors have difficulty building enterprise functionality with the suite vendors multiple development specialists in maintenance, inventory, accounts payables, financials etc. The point vendors also dont 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 vendors 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 IntegrationDuring 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 vendors EAM; their 3rd party mobile solution, and the Oracle application suite.

Although there is no shortage of companies interested in working with Oraclethe Oracle E-Business Suite market exceeds $20Bwe 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 customerand we will sell Oracle products or work with 3rd party vendorswe often dont demonstrate all available options in our sales campaign. One reason is we have a large universe of partners (over 11,000) and we dont often like to give unfair advantage to one over another in the sales cycle.

ImplementationMRO 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 projectwhich might be as critical to the customercan 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.

SupportAlthough 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 vendors and the customers interests are well served. However, an inflection point is reached when most of the vendors 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.

Vendors 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.