Evaluation Infosheet
For a life sciences manufacturer, a useful comparison begins with the same requirements for both suppliers. Ask each to demonstrate the processes you need, identify the commercial and configuration scope, and provide the evidence your Quality and IT teams will use to assess the proposal.
This framework separates six evaluation areas. It does not select a universal winner or infer fit from a vendor’s general positioning. If you are still deciding whether to remain on an IBM path, start with the Maximo end-of-support guide.
Define the site and asset scope, intended uses, user roles, deployment model, integrations, retained records, and planning period before comparing responses. Use the same normal and exception scenarios in both demonstrations.
| Evaluation area | Evidence to request from IBM / MAS proposal | Evidence to request from Blue Mountain / RAM proposal |
|---|---|---|
| Validation and supplier evidence | Release-specific deliverables, configuration assumptions, customer activities, and evidence limitations. | Release-specific deliverables, configuration assumptions, customer activities, and evidence limitations. |
| GMP-relevant processes | Demonstration of the agreed processes and controls, with native capability, configuration, and extensions identified. | Demonstration of the same processes and controls, with native capability, configuration, and extensions identified. |
| Calibration and records | Standards, tolerances, data sheets, readings, as-found/as-left results, traceability, reverse traceability of standards, exception handling, historical context, and commercial scope. | The same calibration and record scenarios, with commercial scope and any dependencies identified. |
| Deployment and operations | Exact hosting offer, architecture, support dependencies, responsibilities, access, recovery, and change process. | Exact hosting offer, architecture, support dependencies, responsibilities, access, recovery, and change process. |
| Commercial scope | Roles, entitlements, environments, component charges, services, assumptions, renewal terms, and exit costs. | Roles, entitlements, environments, component charges, services, assumptions, renewal terms, and exit costs. |
| Life sciences references | Approved references with relevant process, asset, deployment, and project scope. | Approved references with relevant process, asset, deployment, and project scope. |
The table is a shared evidence request. Product conclusions should follow the responses, demonstrations, and applicable agreements.
Ask what supplier documentation is actually delivered, for which release and configuration, and how it can support the customer’s intended-use assessment. Identify the assumptions and limitations before estimating customer effort.
Supplier evidence does not replace the customer’s assessment of intended use or verification of configuration, data migration, interfaces, access control, and operating procedures. Define the customer’s responsibilities using the same method for both proposals.
Avoid turning a product’s compliance language into a promise about the implemented system. Ask the supplier to demonstrate required controls and explain what depends on configuration, procedures, and customer verification. Quality should approve the interpretation and assurance plan.
Request in writing: the deliverable list, version, scope, access terms, example evidence, customer activities, and responsibilities for later changes.
Document where the proposed system supports equipment status, maintenance, calibration, review, approval, and product-quality decisions. Ask each supplier to demonstrate the same process from its starting record through the required review and exception handling.
A general workflow capability is not proof of a particular end-to-end process. Record the native steps, configuration, extensions, integrations, and procedural controls in the proposed design. Where a requirement is unresolved, ask for evidence; do not convert the missing answer into a claim that the other product lacks the feature.
Request in writing: a requirement-to-design map with evidence, commercial scope, configuration work, acceptance criteria, and open items.
IBM’s customer-managed MAS 9.2 licensing guidance places Calibration within Maximo Manage entitlement, with access at the Base and Limited tiers. Calibration does not carry a separate installation AppPoint charge; user access still consumes AppPoints under the applicable tier. Evaluate the required calibration processes and records against the proposed release and configuration.
For both proposals, follow a representative calibration through standards, tolerances, readings, as-found/as-left results, traceability, reverse traceability of standards, review, and historical retrieval. Evaluate detection of an exception separately from the routing, escalation, and approval process your organization requires.
Ask how the proposed design connects calibration and maintenance information where your process requires it. Confirm which records, relationships, and interfaces are included in the quoted scope. A demonstration should identify each dependency and any customer configuration.
Request in writing: the scenario results, record examples, configuration assumptions, entitlement scope, and unresolved requirements.
Customer-managed MAS 9.2 requires OpenShift and entitlement for the cores used. IBM’s bundled Red Hat rights are valid only in support of MAS and while IBM Subscription and Support is in effect; Reserved entitlements are excluded.
Evaluate MAS SaaS under its own service terms. IBM’s Dedicated documentation states that new purchases are unavailable and existing contracts continue on their terms, so confirm whether that existing-service context applies. Customer-managed licensing tables do not establish either hosted service’s schedule.
For RAM, request the proposed architecture and operating-responsibility document. Compare the actual proposals layer by layer: platform operation, security, access administration, backup, recovery, incident investigation, evidence, and change approval. A hosted label alone does not define those responsibilities.
Request in writing: one responsibility matrix for each proposed service and the relevant terms and dependencies.
For customer-managed MAS 9.2, reconcile user roles and application access to the AppPoint model and applicable tier. Distinguish industry solutions and add-ons from supplemental add-ons and identify component installation charges.
Request the equivalent role, application, environment, and service scope in the RAM proposal. Include implementation, data work, interfaces, assurance activities, operations, internal effort, renewal assumptions, and exit costs for both candidates.
Model changes in users, concurrency, sites, applications, and services under the applicable agreement. This is a scenario analysis; a change in licensing model does not establish a price increase, savings percentage, or total-cost advantage by itself.
Request in writing: a reconciled scope and cost model with quoted items, estimates, assumptions, and sensitivity to changes.
Request approved customer references relevant to the process and project scope under evaluation. Identify the starting system, sites, asset mix, deployment, implementation boundary, and period covered by the result.
For a quantified result, ask for the baseline, calculation, costs included, denominator, and attribution. Treat the example as one customer’s evidence within that scope, not a forecast for every migration.
Request in writing: permissioned references and the supporting context for any customer or quantitative claim used in the decision.
Ask each supplier for a permissioned sample that shows the fields and context your reviewers need. This may include a calibration record, audit information, or an inspection-related report where the supplier can provide a defensible example.
Establish whether the sample is synthetic, a demonstration record, or customer material. Identify its release, configuration, scope, and limitations. Do not assume a sample establishes regulatory compliance or that it represents every customer’s configuration.
MAS may fit when the proposed system demonstrates the required processes and the organization accepts the documented terms, responsibilities, and transition plan. RAM may merit selection when its proposed system meets those same tests for your operation. Neither conclusion follows from a vendor category alone.
Use mandatory requirements and unresolved-item criteria agreed before the demonstrations. Retain the evidence behind the decision and record which assumptions require confirmation before contract or go-live.
Discuss your requirements with Blue Mountain, or download the Post-EOS Migration Guide for the broader decision framework.
This material is a planning framework, not legal or regulatory advice, an IBM entitlement determination, or a guarantee of compliance. Confirm contractual terms with IBM or the relevant supplier and approve the assurance approach through your quality system.
