How to implement a CMMS: the ANCAP SAP-PM case

In one line

Implementing a CMMS is not just installing software: in ANCAP's case, most of a 39-week project went into defining processes and an objective risk matrix, not into configuring screens.

The problem it set out to solve

ANCAP, Uruguay's state-owned oil company, ran its La Teja Refinery with seven execution units (six shops plus the Outlying Areas department) that each prioritized, planned and scheduled maintenance on their own. That decentralization had no common criterion: it created large imbalances in how work requests got fulfilled. The existing system (SIMAN, from an Argentine software firm) only synced monthly with the materials and cost systems, and planning and scheduling were done in Excel on SIMAN's own server — a tedious task, with multiple iterations every time a plan involved several shops at once. When the company tried to track key performance indicators (KPIs) systematically, the existing system could not support it, and that is where the search for a CMMS began.

The risk matrix: prioritizing without depending on who asks

Before touching any software, the consulting firm supporting the project (KBC Advanced Technologies) recommended something different first: a "risk matrix" that prioritizes jobs based on the potential consequences of not doing them and the probability of those consequences happening within a given timeframe. It is an objective tool that does not depend on who requests the work or who executes it.

The case also carries an honest lesson about designing any rule-based system: the matrix only applied to work orders, not to "services" (jobs of up to 8 person-hours, managed through a more agile module with less record-keeping). Some "resourceful" requesters started splitting large jobs into several services to dodge prioritization — which ended up overloading the crews assigned to services, at the expense of the legitimately prioritized work orders. Fixing that workaround in the new system was, according to the author himself, one of the points that took the most analysis time in the whole project.

The project's 5 phases

Phase I — Selection and training (3 weeks). A group was put together with 5 key reference users (2 managers and 3 department heads, part-time, for strategic decisions) and 8 functional users working full-time. 16 people were trained in both the maintenance (PM) and materials (MM) modules at once, given how strongly the two were interrelated.

Phase II — Conceptual model (16 weeks, averaging 10 full-time people). Two subgroups were formed: one for process analysis and one for master data. The process group identified around 20 processes, of which 4 were the main ones (Pareto again) and were tackled first. The project's premise was "zero custom development": SAP adapted to ANCAP's existing procedures where possible, and ANCAP adapted to SAP where it could not. This phase's deliverable was a "Business Blueprint" documenting every step needed for the later configuration, following the ASAP (Accelerated SAP) methodology.

Phase III — Configuration, data load and testing. All configuration was done in a development environment separate from the real data, then "transported" into the production and quality-assurance environments — a procedure specifically designed to minimize configuration errors. 22,507 functional locations and 12,766 pieces of equipment were loaded. On average, 14 people worked on the maintenance module during this phase, and close to 40 people across the full SAP project (which also covered procurement, costs, fixed assets, finance and budgeting).

Phase IV — User training and go-live. Training courses ran for 4 weeks for 140 users. Go-live happened in week 39 of the project, with a weekend transition described as "very demanding" — the team deliberately chose a fast, decisive cutover instead of a gradual migration, backed by a phone and email help desk plus dedicated on-site support.

Phase V — Continuous improvement. A "Competence Center" was created (one full-time programmer and one full-time analyst, plus two key configuration users) to sustain the system after go-live — with meetings that became less frequent as the module stabilized.

Notification and Order: the distinction that organizes everything

In SAP's terminology, a request for intervention first creates a maintenance notification, linked to the equipment's history and to the maintenance catalogs; the notification then gives rise to an order, which is what links to costs and to human resources (labor, materials, rates per work center). Both documents are needed to manage the asset efficiently: one without the other leaves either an incomplete history or cost control with no traceability back to why the money was spent.

Functional location and equipment: why they are not the same thing

SAP distinguishes the functional location (the function to be performed, for example "pump 2806") from the equipment (whoever physically performs that function right now). The case documents a real example: functional location 2806-JA had a Worthington-brand pump installed, with a Sulzer backup pump available for the same function. If the Worthington unit ever gets moved to another location, its maintenance history follows it — it does not stay stuck to the functional location where it used to be installed. It is the difference between asking "what happened to this pump (the physical machine)?" and "what happened to this function (the location)?", and the system needs to answer both without mixing them up.

Results

The full project took 39 weeks (a bit over 9 months), which the author notes is consistent with SAP's own statistics for projects of this scale (between 7 and 9 months). The team ranged between 10 and 14 people depending on the phase, with a total of 19,000 person-hours invested. For planning plant shutdowns (every 4 years, with execution intensity that quadruples compared with routine maintenance), a dedicated project-management software (Primavera P3) was also used, which allowed the plant to be handed back to Operations 2 days earlier than traditional — an improvement that, on its own, paid for the software and the team dedicated to planning the shutdown.

The overall management improvement was verified externally: ANCAP has taken part since 1996 in Solomon Associates' refinery performance survey, and those indicators reflected the improvement in costs and mechanical availability at the plant.

What learning from this case is for

A CMMS does not solve a management problem by itself: ANCAP first defined the risk matrix and centralized planning (phases that did not depend on any software), and only afterward looked for a tool that could sustain that model with real-time data. Buying the system before the process is clear is, in fact, the reverse of the sequence this case documents as successful.

Benefits

• The risk matrix gives an objective prioritization criterion, independent of who requests or executes the work
• The distinction between functional location and equipment solves a real traceability problem: a machine's history is not lost when that machine changes function or location
• The case's numbers (39 weeks, 19,000 person-hours, 140 trained users) give a concrete reference for the real scale of a project like this, useful for sizing one of your own before starting

Limitations to keep in mind

• The case describes a large refinery (22,500 functional locations, close to 13,000 pieces of equipment) — the project's scale is not representative of a medium or small plant
• The "zero custom development" premise required the organization to adapt to SAP on several points, not just the other way around — a management decision not every company is willing to make
• This is the report of a successful project told by the person who led it — it does not include a comparison with similar projects that failed or ran late

In summary

ANCAP did not start with the software: it started with an objective risk matrix and centralized planning, and only then implemented SAP-PM across 5 phases over 39 weeks to sustain that model with real-time data. The result — lower maintenance cost, better availability, 2 fewer days of plant shutdown — was verified with an external performance survey, not just the internal feeling that "the system is better now."