When ITIQPro's MCe Becomes the Better Choice

MaintainX can be an good choice for organizations, especially smaller ones, that want to get a maintenance program running quickly and don't need more. It provides the core capabilities expected from a modern CMMS: assets, work orders, preventive maintenance, procedures, parts, meters, reporting and mobile access. Larger organizations have reported to us that after months or years of trying, they are never able to get to the point they want to.

But for many organizations, that is all they want.

The question changes as the maintenance operation becomes larger or more sophisticated.

At that point, the requirement is often no longer simply:

"How do we manage maintenance?"

It becomes:

"How do we model, automate, integrate and manage the entire maintenance and asset-management operation?"

That is where ITIQPro's MCe becomes a substantially different proposition.

MCe is designed not merely as a work-order application, but as a highly configurable Enterprise Asset Management platform. Its broader data model, automation capabilities, integration tools, reporting system, security model and ability to work with external systems make it particularly suitable for organizations whose requirements have started to extend beyond a conventional CMMS.

The decision between MaintainX and MCe therefore should not necessarily be made on the basis of whether both products can create a work order or schedule a PM.

They can.

The more useful question is:

What happens when your maintenance system needs to become part of the operational infrastructure of your organization?

A Broader Asset Management Model

A major difference becomes apparent when looking beyond the Asset itself.

An enterprise maintenance operation contains far more relationships than simply:

Asset → Work Order

Assets exist within organizations, departments, repair centers, classifications, locations and operational structures.

Work requires labor, crafts, shifts, procedures, inventory, tools, contractors and approvals.

Organizations may also need to manage customers, contracts, projects, purchasing, training, documents, failure information and many other related entities.

MCe is designed around that larger model.

Depending on the implementation, an organization can manage interconnected information including:

• Assets
• Work Orders
• Preventive Maintenance
• Procedures
• Classifications
• Specifications
• Repair Centers
• Departments
• Shops
• Crafts
• Shifts
• Labor and Users
• Companies
• Contacts
• Customers
• Contracts
• Projects
• Purchase Orders
• Inventory
• Stockrooms
• Parts
• Tools
• Toolrooms
• Documents
• Failure information
• Training
• Zones
• Accounts
• Categories
• Assignment Rules
• Events and Actions
• Maintenance Automations

This becomes important because a mature maintenance organization rarely operates as a collection of isolated work orders.

Everything is related.

A failed pump may belong to a particular system, classification, repair center and department; require particular crafts, parts, procedures and tools; have purchasing implications; be associated with a contractor; and ultimately contribute to reliability and cost reporting.

MCe is intended to preserve and use those relationships.

Classifications Turn Assets into Structured Data

One of the most important differences in a larger EAM implementation is the ability to describe assets consistently.

Consider these assets:

Pump P-101 Pump P-102 Pump P-103

Knowing that all three are pumps is useful.

But an EAM system should be able to know considerably more.

A Pump classification might establish specifications such as:

• Manufacturer
• Model
• Pump Type
• Flow Rate
• Head
• Motor Power
• Voltage
• RPM
• Seal Type
• Bearing Type
• Suction Diameter
• Discharge Diameter
• Design Pressure
• Design Temperature

A Motor classification will have an entirely different set of specifications.

A Vehicle would have another.

An HVAC unit another.

Instead of every asset simply being a record with miscellaneous information attached to it, classification gives the organization a structured asset information model.

That provides better searching, filtering, validation, reporting and automation.

It also becomes extremely valuable during integrations.

An external system does not merely have to know:

"This is Asset 14328."

It can know:

"This is a centrifugal pump with these characteristics."

That is a much more useful foundation for enterprise asset management.

The Asset Tree Is More Than Navigation

MCe's Asset Tree can represent the physical or functional relationship between equipment:

Facility

• Production
  • Line 1
    • Filler
      • Fill Pump
        • Motor
        • Pump Assembly
      • Valve Bank
      • Controls
    • Capper
    • Labeler

The value of that structure extends beyond making assets easier to find.

The hierarchy provides context.

A technician looking at a motor can understand which pump it belongs to, which machine contains the pump, which production line contains the machine and where that line fits into the facility.

Depending on the process being implemented, that hierarchy can then influence reporting, work management, automation and other operations.

Organizations therefore do not have to choose between an enormous unstructured equipment population and an artificially shallow asset model.

They can model their equipment at the level that actually makes sense.

Specifications Allow Different Assets to Describe Different Things

One challenge with generic CMMS asset records is that equipment does not all have the same properties.

A boiler does not have the same important characteristics as a vehicle.

A vehicle does not have the same characteristics as a transformer.

A transformer does not have the same characteristics as a centrifugal pump.

Trying to solve that problem by continually adding generic fields produces increasingly complicated screens containing fields that apply to only a small percentage of assets.

MCe's classification and specification model allows the data structure to reflect the equipment instead.

That means organizations can establish standards such as:

Classification: Electric Motor

with specifications for:

• Voltage
• Phase
• Horsepower
• RPM
• Frame
• Enclosure
• Insulation Class

while:

Classification: Centrifugal Pump

can have:

• Design Flow
• Design Head
• Impeller Diameter
• Suction Size
• Discharge Size
• Seal Type

This is important not only for technicians, but also for reporting, engineering information, asset replacement, integrations and automation.

Automation Goes Beyond Preventive Maintenance

Preventive maintenance is fundamentally important, but not every maintenance process begins with a calendar or meter.

Modern equipment generates information continuously.

Events occur.

Conditions change.

External systems provide information.

People update records.

Sensors report measurements.

Business rules need to react.

MCe's Events & Actions and Maintenance Automation capabilities allow the system to respond to those situations.

Instead of limiting automation to:

"Every 30 days, create this work order."

an organization can build processes more like:

When this happens, evaluate these conditions and perform these actions.

That opens considerably broader possibilities.

For example:

Temperature exceeds a threshold → evaluate the affected equipment → create work → notify the appropriate people

or:

A particular type of Work Order reaches a particular state → evaluate business rules → update related information → send information elsewhere

or:

External weather data indicates excessive wind speed → identify scheduled work involving elevated access → warn the responsible personnel or modify the process

or:

An IoT system reports an abnormal condition → identify the corresponding MCe asset → evaluate the condition → create the appropriate maintenance response

The maintenance system begins to participate in operations rather than simply waiting for somebody to enter information into it.

MCe Can Use Information Outside MCe

This is one of the areas where the architectural difference becomes particularly important.

An organization increasingly has information distributed among many systems:

• ERP
• accounting
• building automation
• SCADA
• GIS
• IoT platforms
• weather services
• vendor systems
• customer systems
• inventory systems
• corporate databases
• web services
• internal applications

Maintenance decisions frequently depend on that information.

MCe's philosophy is that the maintenance system should be able to participate in that environment.

Through APIs, DataHub, Events & Actions and other integration mechanisms, information can move into and out of MCe rather than requiring the maintenance database to become an isolated information island.

DataHub Provides a Dedicated Integration Layer

Integrations eventually become more complicated than:

"Import this spreadsheet."

Organizations need repeatable processes.

They need to:

• import information;
• export information;
• synchronize systems;
• transform data;
• schedule exchanges;
• work with external identifiers;
• deal with changes;
• automate processing;
• and keep integrations maintainable.

MCe's DataHub is specifically intended for these types of workflows.

This is valuable for organizations that have several systems of record.

For example:

ERP → financial and purchasing information

MCe → maintenance and asset management

GIS → geographic asset information

IoT → operational measurements

External contractor system → service activity

An enterprise implementation should not require people to manually keep all of those systems synchronized.

REST and GraphQL APIs

MCe also provides programmatic access for organizations building their own integrations.

The MCEverywhere REST API provides HTTPS-based integration using API authentication.

MCe's GraphQL API provides another integration model where applications can request the information they require and, where appropriate, use WebSockets for more interactive scenarios.

That is important when MCe becomes part of a larger software ecosystem.

The goal is not that every customer needs to write software.

The goal is that an organization is not trapped when it eventually does need to integrate something.

Reporting Becomes an Information Platform

MaintainX has meaningful reporting functionality, including standard reports, custom reports and dashboards. Its current product also supports global reporting for qualifying Enterprise configurations.

MCe approaches reporting as a broader configurable capability.

An organization may need something simple:

Work Orders completed this month.

But eventually somebody asks:

Show every critical asset in these classifications that had more than three corrective Work Orders during the previous twelve months, group those failures by category, include actual labor and material cost, and compare that with the previous year.

Or:

Show overdue work grouped by Repair Center and supervisor, excluding canceled and denied work, with links directly to the affected records.

Or:

Combine maintenance information with business-specific information that our organization stores in additional fields or related data.

At this point reporting needs to understand the actual data model rather than only providing a predefined collection of maintenance charts.

MCe's reporting architecture is designed to allow customers to build reports against that broader model.

This is particularly valuable because every organization's definition of a useful maintenance KPI eventually becomes slightly different.

Dashboards Should Answer Different Questions for Different People

A maintenance manager does not need the same information as a technician.

A plant manager does not need the same information as a planner.

A reliability engineer does not need the same information as somebody in purchasing.

An executive does not need the same information as any of them.

MCe allows reporting and dashboard experiences to be built around the questions relevant to those users.

For example:

Technician

• My open work
• My overdue work
• Today's work
• Equipment requiring attention
• Recently accessed assets

Maintenance Manager

• Open work by supervisor
• Work backlog
• PM compliance
• Emergency work
• Labor utilization
• Failure trends

Reliability

• Repeat failures
• Failure by classification
• Failure by manufacturer/model
• Asset maintenance cost
• High-risk equipment
• MTBF/MTTR-style analysis

Management

• Maintenance cost
• Backlog trends
• Asset availability indicators
• Performance by facility
• Performance by department
• Long-term trends

The reporting layer can therefore reflect the organization rather than forcing every user into the same dashboard.

Security Can Follow the Organization

As organizations become larger, "Administrator or User" is rarely enough.

MaintainX has progressed beyond that simple model: it currently supports several default roles and custom roles, although some customized permissions and features are plan-dependent.

MCe's advantage is the ability to integrate security into the broader organizational data model.

Access can be designed around concepts such as:

• users;
• Access Groups;
• Repair Centers;
• responsibilities;
• modules;
• records;
• functionality;
• organizational boundaries.

This matters in environments where the same installation may serve substantially different groups.

For example:

Facilities may need access to building equipment.

Production Maintenance may need access to manufacturing equipment.

Contractors may need access to only a tightly controlled subset.

Management may need broad read access without operational edit capabilities.

Regional personnel may need information for their region without access to another.

The objective is not simply to decide who can log in.

It is to decide:

What should this person be able to see and do once they are inside the system?

Repair Centers Allow Operational Separation

Repair Centers provide another useful organizational dimension.

A large organization may effectively contain several maintenance organizations inside the same enterprise:

North Plant Maintenance

South Plant Maintenance

Facilities

Fleet

IT

Utilities

Those groups may have different:

• personnel;
• assets;
• work;
• supervisors;
• procedures;
• planning processes;
• security;
• reporting requirements.

MCe can model these operational boundaries without necessarily requiring the enterprise to treat them as completely unrelated systems.

That becomes particularly valuable as a maintenance deployment expands from one department to the entire organization.

Assignment Rules Can Encode How Work Gets Distributed

Creating work is only the beginning.

Someone needs to determine who should receive it.

That decision may depend on:

• asset;
• location;
• classification;
• Repair Center;
• work type;
• priority;
• craft;
• shift;
• department;
• other business information.

MCe's Assignment Rules provide a way to incorporate these decisions into the system rather than relying entirely on dispatchers remembering organizational knowledge.

That moves another piece of the maintenance process from:

"Someone knows what to do."

to:

"The system knows how we normally do this."

That distinction becomes increasingly valuable as an organization grows.

GIS Can Become Part of Asset Management

For organizations with geographically distributed assets, a list or even a conventional equipment tree is not always the best way to find something.

The natural interface may be a map.

MCe's GIS direction is intended to allow assets and Work Orders to participate in geographic workflows.

That can be important for organizations managing:

• utilities;
• municipalities;
• campuses;
• pipelines;
• roads;
• telecommunications;
• distributed facilities;
• environmental assets;
• field infrastructure.

A user should be able to think spatially:

"Show me the work in this area."

or:

"Show me the assets around this location."

rather than having to know the Asset ID before finding the equipment.

MCe's GIS architecture is also being designed with compatibility with external GIS information, including ArcGIS-style environments, rather than treating the maintenance map as an isolated picture.

Offline Is More Than Losing the Internet for a Moment

Field maintenance frequently occurs where connectivity is poor or nonexistent.

An effective mobile maintenance system therefore cannot assume that every user has a stable connection to the server.

MCe's architecture includes offline operation and synchronization so that field activities can continue when connectivity is unavailable and synchronize when communications return.

This is particularly valuable for:

• remote facilities;
• basements;
• mechanical rooms;
• industrial sites;
• utilities;
• field infrastructure;
• rural operations.

The important distinction is that temporary loss of connectivity becomes an expected operating condition rather than an exceptional failure.

MCe Can Adapt to the Organization

Perhaps the most important difference emerges when someone says:

"Our organization doesn't work exactly that way."

With a simpler CMMS, the answer can eventually become:

"That is how the software works."

MCe is deliberately designed to support much more configuration around the organization's actual processes.

This includes combinations of:

• classifications;
• specifications;
• custom configuration;
• reports;
• dashboards;
• Assignment Rules;
• Events & Actions;
• Maintenance Automations;
• integrations;
• scripting;
• APIs;
• permissions;
• organizational structures.

This does not mean that every customer should customize everything.

In fact, unnecessary customization should generally be avoided.

It means that when a legitimate business requirement exists, the system provides considerably more room to model it.

The System Can Grow with the Organization

A small maintenance team may initially need:

Assets + PMs + Work Orders

Later it may need:

+ Inventory

Then:

+ Purchasing

Then:

+ Contractors

Then:

+ Multiple facilities

Then:

+ Automation

Then:

+ ERP integration

Then:

+ GIS

Then:

+ IoT

Then:

+ Advanced reporting

Then:

+ AI-assisted workflows

A major advantage of selecting a broader EAM platform is that each new requirement does not necessarily trigger another search for another disconnected product.

MCe provides a foundation on which those requirements can continue to be developed.

GERALD Adds AI to the Existing Asset Model

Artificial intelligence becomes much more useful when it has structured operational context.

ITIQPro's GERALD capabilities are designed to work within the MCe environment, where the system already understands assets, work, classifications and other maintenance information.

The important concept is not simply adding a chatbot to a maintenance application.

It is allowing AI-assisted functionality to operate in the context of the maintenance system and its data.

MCe also allows organizations to control AI use according to their requirements, including the ability to disable AI at different organizational scopes and, where appropriate, configure the AI provider.

This allows organizations to adopt AI where it provides value without requiring that every customer or every user use it.

Integration Rather Than Isolation

Eventually, the maintenance system becomes one of several critical business applications.

At that point the question is no longer:

"Does it have an integration with Product X?"

The more sustainable question is:

"Can we integrate it with the systems we have today and the systems we haven't purchased yet?"

That is why general-purpose capabilities such as:

• DataHub;
• REST APIs;
• GraphQL;
• Events & Actions;
• automation;
• external data access;

become strategically important.

Point-to-point integrations solve today's problem.

An integration platform helps solve tomorrow's problem.

MaintainX Can Still Be the Right Choice

None of this means that every organization should choose MCe.

A smaller organization primarily looking for:

• straightforward asset management;
• work orders;
• PMs;
• procedures;
• mobile execution;
• quick implementation;

may find MaintainX to be a very good fit.

The difference becomes increasingly apparent when requirements include things such as:

• complex asset structures;
• detailed classifications and specifications;
• multiple operational organizations;
• sophisticated permissions;
• enterprise integrations;
• significant data synchronization;
• custom business processes;
• event-driven maintenance;
• automation;
• GIS;
• highly customized reporting;
• external systems;
• IoT;
• or organization-specific workflows.

At that point, the comparison is no longer simply one CMMS against another.

It becomes a question of CMMS versus broader EAM platform.

When Moving from MaintainX to MCe

For an organization that has already invested in MaintainX, moving to MCe should not mean throwing away that investment.

Assets, hierarchies, locations and other useful maintenance information can provide the starting point for the MCe implementation.

The organization can initially reproduce the structures that already work.

Then it can begin asking:

Can classifications improve our asset information?

Can specifications standardize our equipment data?

Can we model the organization more accurately with Repair Centers?

Can Assignment Rules automate work distribution?

Can Events & Actions eliminate manual processes?

Can DataHub eliminate repeated data entry between systems?

Can our ERP and maintenance systems exchange information automatically?

Can our GIS information become part of maintenance?

Can sensor information initiate maintenance activity?

Can reports answer our organization's questions rather than only the questions anticipated by the software vendor?

Can we automate processes that currently exist as instructions somebody has to remember?

Those are the areas where the move begins providing value beyond simply replacing one Work Order screen with another.

When Running MaintainX and MCe Together

The same capabilities can justify introducing MCe even when MaintainX is not immediately being replaced.

An organization might initially synchronize selected MaintainX information into MCe because it needs capabilities surrounding that information that extend beyond its existing implementation.

MCe can become the broader asset-management and integration platform while the organization determines which processes should remain in MaintainX and which should migrate.

Over time, that boundary can change.

The important thing is to establish clear ownership for synchronized information so that the two systems complement each other rather than compete over the same records.

The Difference Appears at the Edges

If the evaluation consists entirely of:

"Can I create an asset?"

"Can I create a PM?"

"Can I assign a Work Order?"

"Can a technician complete it on a phone?"

then many modern CMMS products will look reasonably similar.

The differences become apparent when you keep asking "and then what?"

Can the asset have a sophisticated classification and specification model?

Can it participate in a complex hierarchy?

Can access follow organizational structures?

Can work assignment follow business rules?

Can an external event initiate a maintenance process?

Can information from another database participate in that decision?

Can MCe send the result to another system?

Can the same platform handle inventory, purchasing, tools, contractors and organizational structures?

Can geographically distributed assets participate in GIS workflows?

Can we build reporting around our own business questions?

Can we automate processes unique to our organization?

Can we extend the system again when the next requirement appears?

Those questions describe the point at which an organization is moving from computerized maintenance management toward enterprise asset management.

The Key Principle

MaintainX can be an effective way to manage maintenance.

ITIQPro's MCe is intended to provide something broader:

A platform for managing the assets, information, people, processes, integrations and automation surrounding maintenance.

For an organization whose requirements are straightforward, that additional capability may not be necessary.

For an organization that expects its maintenance operation to become increasingly integrated, automated, data-driven and organization-specific, it can be the difference between selecting a system that solves today's problem and selecting a platform capable of supporting what comes next.

The reason to move to MCe should not be that MaintainX cannot create a Work Order.

It should be that the organization has reached the point where creating and completing the Work Order is only one small part of what it needs its asset-management system to do.