Companies already running SAP PM should evaluate maintenance software based on the architecture and process they want to preserve. Asset master data, plans, orders, costs, and materials may reside in SAP, but scope and maturity vary between companies. Before comparing screens, document what your environment already controls, where work leaves the official system, and which data must return to SAP.
This guide structures the evaluation around six dimensions: integration and data governance, field operations, planning and scheduling, architecture and security, implementation and support, and total cost. The questions do not have universal answers. The appropriate answer depends on process, configuration, corporate controls, and operational risk.
Before features, decide the role of SAP PM
The first criterion is to define which system will remain the maintenance system of record. Several designs are possible, and their effects depend on the implemented scope:
- Replace SAP PM: the company migrates master data, history, and processes to another CMMS or EAM and keeps the integrations required with the ERP.
- Run SAP PM alongside another maintenance system: each platform owns a defined scope. This design requires clear rules for data ownership, synchronization, and conflict handling.
- Keep SAP PM as the system of record with an execution and planning layer: the application and portal work with SAP objects and processes within the integrated scope.
None of these architectures is inherently correct. The decision should consider corporate strategy, master data quality, existing integrations, change cost, field experience, and historical data governance. The list of maintenance software grouped by architecture, currently available in Portuguese, can help organize the shortlist.
Dimension 1: integration and data governance
Integration should be described object by object and process by process. The phrase "native integration" does not explain the mechanism, data direction, latency, or who maintains the interface.
Questions for the vendor:
- Which mechanism connects the solution to SAP, and which components reside in the customer environment, middleware, and vendor environment?
- Which objects and actions are covered: order, operation, notification, confirmation, measurement, reservation, bill of materials, and document? Which are read and which are written?
- Which system maintains equipment, functional locations, measuring points, work centers, and catalogs? How are discrepancies detected and handled?
- When a user creates or changes a document outside SAP, which document is created in SAP and which fields are populated?
- Is each process integrated immediately, on a schedule, or by user action? What happens when SAP or middleware is unavailable?
- Which logs are available for operations, support, and audit? Who monitors, reprocesses, and communicates failures?
Request an integration matrix with the object, direction, trigger, expected latency, error handling, and responsible party. This evidence is more useful than a generic real-time claim.
Dimension 2: field operations
Field scope should be compared with the technician's actual routine. Offline may mean only viewing a downloaded order, or it may include execution, confirmation, notifications, and materials. Define the required minimum before the demonstration.
Questions for the vendor:
- Which data must be synchronized before entering an area without connectivity?
- Which actions work offline, and which require connectivity?
- How does the system handle conflicts, pending documents, and synchronization failures?
- Can time entry capture start and finish during execution? Is manual entry also available and controllable?
- Does the notification use SAP-configured catalogs when applicable? Which fields vary by notification or order type?
- How do checklists, reasons for nonexecution, technical notifications, and finding treatment work?
- Which attachments can be sent or viewed, where are they stored, and how do they relate to DMS and retention policy?
- Does the application support the devices, operating systems, and security controls used by your company?
Request a demonstration with one of your scenarios: an order with operations, offline execution, an unperformed item, a technical notification, confirmation, and synchronization. Record what depends on configuration and what belongs to the contracted scope.
Dimension 3: planning and scheduling
Planning should connect demand, capacity, the work window, and integration. An isolated Gantt chart does not prove that scheduling was applied to the official process.
Questions for the vendor:
- Which orders enter the tool and which plant, type, status, date, and scheduling filters control them?
- How are work centers, shifts, absences, skills, certifications, availability, and utilization represented?
- Which scheduling actions are sent to SAP, when does that happen, and how does the user follow the log?
- How do preventive orders already generated by an SAP plan enter the scheduling period?
- How are backlog, criticality, stopped equipment, materials, and constraints shown to the planner?
- What changes on the board when execution is delayed, partially confirmed, or not integrated?
- Which data is available for the customer to build its own indicators?
Preventive strategy and frequency remain in SAP PM. Evaluate the tool by its ability to schedule, allocate, integrate, and track orders generated by that strategy, without assuming it automatically defines the plan.
Dimension 4: architecture and security
IT, security, privacy, and SAP stakeholders should participate before contracting. Requirements vary with corporate architecture, data classification, and access policy.
Questions for the vendor:
- How do authentication, revocation, profiles, and segregation of duties work?
- Which actions use individual identity, and which pass through a technical integration user? How is authorship preserved?
- Which data remains on the device during offline use, and how is it protected or removed?
- Where are data, logs, attachments, and documents stored? Which retention, backup, and disposal policies apply?
- How are changes, approvals, synchronizations, and integration failures made auditable?
- Which security evidence, tests, and incident response processes can your team evaluate?
- How is the solution tested against an SAP update, middleware change, or S/4HANA migration?
Do not assume that reproducing SAP authorization or using single sign-on resolves every control. Request the identity and permission design for each critical action.
Dimension 5: implementation and support
A schedule only makes sense when scope, dependencies, environments, and responsibilities are defined. The same solution may require different effort depending on SAP customizations, integration, master data quality, and rollout reach.
Questions for the vendor:
- What is the scope of the first group going live, and which prerequisites must be complete?
- Who is responsible for SAP, middleware, infrastructure, devices, master data, testing, and training?
- Which environments will be used for configuration, quality assurance, and production? How is the promotion between them handled?
- How will field users, planners, administrators, and internal support be prepared?
- Which languages, hours, and channels does support cover? How do severity, escalation, and on-call coverage work when applicable?
- Is onsite service required? In which locations, with how much notice, and under which conditions?
- How are new users, plants, and process changes introduced after go-live?
- Which customer references with comparable architecture, scale, and complexity can be verified?
The location of the support team is not a universal criterion. The criterion is the coverage required by the operation: language, time zone, SLA, severity, remote capability, presence when required, and escalation path.
Dimension 6: total cost
Compare licenses, implementation, integration, maintenance, and internal effort over the same horizon. The lowest upfront amount may not represent the lowest total cost, but this conclusion must come from proposal figures and the company's scenario.
Questions for the vendor:
- How are licenses counted, and what changes with users, plants, volume, seasonal peaks, or new modules?
- Which implementation services are included, and which may become change requests?
- Are SAP integration, middleware, packages, infrastructure, and environments included?
- Which recurring costs apply to support, maintenance, updates, and infrastructure?
- Are additional SAP or third-party licenses required? Who validates that need?
- What internal effort is expected for SAP, IT, maintenance, testing, training, and continuous operations?
- How do price adjustments, expansion, scope reduction, contract termination, and data return work?
A consistent checklist for the vendor meeting
The table uses the same six dimensions as the guide. The third column does not prescribe a universal answer; it shows the evidence needed to evaluate the response in your context.
| Dimension | Core question | Evidence to evaluate in your context |
|---|---|---|
| 1. Integration and data governance | Which objects, actions, directions, and triggers connect the solution to SAP? | Object-by-object matrix, mechanism, latency, error, reprocessing, log, and responsible party. |
| 2. Field operations | Which activities work online and offline in the technician's real scenario? | Demonstration with order, checklist, notification, confirmation, and synchronization, including limits and dependencies. |
| 3. Planning and scheduling | How do capacity, constraints, and scheduled actions relate to SAP orders? | Scenario with filters, allocation, triggered integration, log, delay, and execution update. |
| 4. Architecture and security | How do identity, permission, storage, and audit protect each action? | Architecture diagram, access matrix, retention, offline protection, audit trail, and security evidence. |
| 5. Implementation and support | Who delivers, operates, and supports each part of the scope? | Schedule, RACI, prerequisites, environments, training, languages, hours, SLA, and escalation. |
| 6. Total cost | What does it cost to implement, integrate, maintain, expand, and exit? | Worksheet with licenses, services, third parties, infrastructure, internal effort, adjustments, and exit. |
Signs that the answer is still incomplete
- "Native integration" without an object and action matrix: request the mechanism, direction, trigger, error treatment, and responsible party.
- "Works offline" without defining actions and data: request execution of the scenario your plant needs.
- "Integrated planning" without showing what is sent to SAP: request the action, integration point, and log.
- "Enterprise security" without identity and an audit trail by action: request the authentication, authorization, and audit design.
- "Complete support" without language, hours, SLA, and escalation: document the required contractual coverage.
- "Fixed price" without integration, third parties, and maintenance: compare total cost over the same period.
When the shortlist already has named vendors
Apply the same six dimensions to every candidate. The pages for Tractian alternatives, Engeman alternatives, Fracttal alternatives, Manusis alternatives, Sigga alternatives, and PM Run versus Produttivo help structure the discussion by architecture. Verify vendor information directly in the current proposal and documentation.
Where PM Run fits into this architecture
PM Run is an execution, mobility, and planning layer integrated with SAP PM. It does not replace SAP as the system of record. PM Run Mobility documents order creation with fields that reflect IW31, online and offline execution, confirmations, operational checklists, notifications, reservations, measurements, and attachments according to environment features and configuration. PM Run Planning documents Gantt views, scheduling, resource utilization, capacity, shifts, absences, skills, certifications, official scheduling, and integration of actions with SAP.
This scope does not eliminate the need to evaluate the mechanism, covered objects, configuration, security, implementation, support, and cost in your company's environment. Learn about PM Run maintenance software integrated with SAP PM and bring the six dimensions in this guide to the technical discussion.
Frequently asked questions
How should a company choose maintenance software when it already runs SAP PM?
First define SAP's role as the system of record. Then compare integration, field operations, planning, security, implementation, support, and total cost using the same scenario and equivalent evidence for every vendor.
What should you ask about SAP integration?
Ask about the mechanism, objects, actions, data direction, trigger, latency, unavailability handling, logs, reprocessing, and maintenance responsibility.
Do you need to replace SAP PM to add mobility?
Not necessarily. A mobility layer can work with SAP PM objects. Exact scope depends on the solution, integration, and environment configuration.
What is a reasonable implementation timeline?
There is no universal timeline. Compare first-group scope, prerequisites, environments, integrations, testing, training, responsibilities, and acceptance criteria.
Does support need to be local?
Not as a universal rule. Define the required coverage in language, hours, channel, SLA, escalation, and physical presence when the operation requires it.
How can proposals be compared fairly?
Use the same six dimensions, request equivalent evidence, and add licenses, implementation, integration, third parties, maintenance, infrastructure, internal effort, expansion, and exit.
