SAP asset tree structure compatibility with MCe

Synchronizing SAP Asset Structures with ITIQPro's MCe

When synchronizing asset information between SAP and ITIQPro's MCe, the first question is not:

"How do we turn the SAP asset list into an MCe Asset Tree?"

SAP already has hierarchical capabilities for representing technical assets.

The more important question is:

"How should the SAP technical-object structure be represented in MCe, and which portions of that structure should be synchronized?"

This distinction is important because SAP does not represent the maintenance world using a single concept called an Asset.

In SAP Asset Management, two particularly important technical objects are:

Functional Locations
Equipment

Understanding the distinction between them is essential before designing an MCe synchronization. MCe provides features like 'location type', 'rotating assets', 'serialized assets' that will come to bear to properly model the SAP structure in MCe.

SAP Functional Locations and Equipment Are Not the Same Thing

A Functional Location represents a position within the organization's technical structure where maintenance can be performed.

That structure may be based on:

physical location;
function;
process;
system;
plant structure;
or a combination of these concepts.

Functional Locations can themselves form a hierarchy.

For example, an organization might have:

PLANT-01

PRODUCTION
- LINE-01
  - FILLING
  - PACKAGING
- LINE-02
UTILITIES
- COMPRESSED-AIR
- CHILLED-WATER

This is already a tree.

SAP then has the separate concept of Equipment.

Equipment generally represents an individual physical object that the organization wants to maintain as an independent object with its own identity and maintenance history.

For example:

Functional Location:

PLANT-01 → UTILITIES → CHILLED-WATER

may contain:

Equipment:

CHILLER-001
CHILLER-002
PUMP-101
PUMP-102

This distinction is extremely useful in SAP because the Functional Location can remain constant while the physical Equipment changes.

For example:

Functional Location: PUMP-POSITION-01

may currently contain:

Equipment: PUMP-12345

If that pump fails and is replaced, SAP can remove PUMP-12345 and install PUMP-67890 at the same Functional Location.

The position remains.

The physical equipment changes.

That distinction should not accidentally be destroyed when the information is synchronized into MCe.

SAP Can Also Have Equipment Hierarchies

The structure becomes more interesting because SAP Equipment can itself be hierarchical.

For example:

Functional Location: PACKAGING-LINE-01

contains:

Equipment: PACKAGER-001

DRIVE-ASSEMBLY
- MOTOR-001
- GEARBOX-001
CONVEYOR-ASSEMBLY
CONTROL-PANEL

SAP therefore potentially gives us two related hierarchies:

Functional Location hierarchy

and:

Equipment hierarchy

with Equipment installed into the Functional Location structure.

That means a synchronization project needs to understand considerably more than a simple ParentAssetID.

Think of SAP as Providing the Technical Structure

A useful starting point is to think of SAP as providing a technical model something like:

Functional Location

Functional Location
- Functional Location
  - Equipment
    - Sub-Equipment
      - Sub-Equipment
  - Equipment
- Functional Location
  - Equipment

MCe can then represent an appropriate version of this as an Asset Tree.

For example, SAP might contain:

Functional Locations

CA01

BLDG-A
- PRODUCTION
  - LINE-01

with:

Equipment

LINE-01 ↳ PACKAGER-100 ↳ FILLER-200 ↳ CONVEYOR-300

and PACKAGER-100 may itself contain:

PACKAGER-100 ↳ MOTOR-101 ↳ GEARBOX-102

The MCe Asset Tree could naturally become:

Calgary Plant

Building A
- Production
  - Line 01
    - Packager 100
      - Motor 101
      - Gearbox 102
    - Filler 200
    - Conveyor 300

The result is a single, intuitive hierarchy for the MCe user even though its source information originated from several SAP concepts.

The First Major Decision: What Should Become an MCe Asset?

This is one of the most important design decisions in an SAP integration.

It may be tempting to say:

"Every SAP Functional Location becomes an MCe Asset, and every SAP Equipment record becomes an MCe Asset."

Sometimes that will be correct.

Sometimes it will produce a terrible Asset Tree.

A large SAP implementation may have Functional Locations that exist for structural, accounting, process or technical reasons that provide little value to the people using MCe.

For example, SAP may have:

Plant

Area
- Process
  - System
    - Subsystem
      - Technical Position
        
        Equipment

That may accurately represent the SAP technical model.

But it does not automatically follow that an MCe technician needs to navigate every one of those nodes.

Depending on the specific situation you might want to have that entire tree but have technicians have multiple starting nodes instead of starting at the top of the tree, or you may prefer to simple not have some of the base nodes.

The MCe tree should represent the portions of the SAP structure that provide useful maintenance context while supporting the long term Enterprise Asset Management (EAM) needs.

Do Not Confuse Synchronization with Duplication

A successful SAP integration should not necessarily attempt to turn MCe into another SAP database.

SAP may contain an enormous amount of information about an Equipment record or Functional Location.

MCe does not necessarily need all of it.

MCe may contain an enormous amount of information about an Equipment asset or a Location asset.

SAP does not necessarily need all of it.

The objective should be:

Synchronize the information MCe needs to perform its role while preserving SAP as the authoritative source for the information SAP owns and preserving MCe as the authoritative source for the information that MCe owns.

For example, MCe may need:

SAP Equipment Number;
Functional Location;
description;
parent/superior equipment;
technical object type;
classification information;
manufacturer;
model;
serial number;
status;
criticality;
selected organizational information;
selected characteristics;
installation information.

It may not need every SAP field associated with that object.

The correct synchronization model is based on purpose, not database completeness.

Preserve SAP Identity

This is particularly important with SAP.

An MCe asset synchronized from SAP should have a persistent reference to the SAP object from which it originated.

Do not rely exclusively on:

Asset Name;
Description;
tree position;
current Functional Location;
manufacturer serial number.

Those things can change.

The integration needs to know:

"This MCe record represents this specific SAP technical object."

This becomes especially important when equipment is moved.

Equipment Movement Must Be Understood Correctly

Suppose SAP contains:

Functional Location: LINE-01/PUMP-POSITION-01

with:

Equipment: PUMP-1001

The corresponding MCe tree might show:

Line 01

Pump Position 01
- Pump 1001

Later, PUMP-1001 is removed and installed elsewhere.

SAP may now say:

LINE-02/PUMP-POSITION-03

PUMP-1001

The integration should recognize that PUMP-1001 has moved.

It should not conclude that:

the old Pump 1001 was deleted; and
a completely unrelated new Pump 1001 was created.

The identity belongs to the Equipment.

Its installation position can change.

This distinction is fundamental to preserving useful equipment history.

Functional Location Identity Is Equally Important

The opposite is also true.

Suppose:

PUMP-POSITION-01

contains:

PUMP-1001

and PUMP-1001 is replaced with:

PUMP-2047

The Functional Location has not become a different Functional Location.

Instead:

Pump Position 01

Pump 1001
Pump 2047

The location or functional position has remained constant while the physical object installed there has changed.

An integration that collapses Functional Location and Equipment into a single identifier can lose this distinction.

Decide Whether Functional Locations Become Assets or Structure

There are several valid MCe models.

Model 1 — Functional Locations and Equipment Both Become MCe Assets

For example:

Plant

Building
- Production Line
  - Pump Position 01
    - Pump 1001

This provides the closest conceptual representation of SAP.

It can be particularly valuable when users need to create work against both the functional position and the physical equipment or when the functional position makes sense to use to limit which assets a given technician should have access to, remembering that in MCe a technician can be granted access to several nodes, they don't need to have access to the entire MCe tree from it's root.

Model 2 — Selected Functional Locations Become Tree Nodes

Perhaps SAP contains eight Functional Location levels, but only four provide useful navigation in MCe.

The resulting MCe tree might therefore be:

Plant

Production
- Line 1
  - Pump 1001
  - Pump 1002
  - Conveyor 100

Intermediate SAP structure that is useful to SAP but unnecessary to MCe can remain synchronization metadata rather than becoming visible MCe Assets.

Model 3 — Equipment Is the Primary Asset Structure

For some implementations, the customer may want the MCe Asset Tree to focus predominantly on physical Equipment.

Functional Location information can still be synchronized and associated with the asset without every Functional Location becoming an Asset Tree node.

The correct choice depends on how MCe will be used.

Ask Whether Users Maintain the Position or the Equipment

A particularly useful question during the design process is:

"Would you ever create maintenance work against this position when the current equipment is not installed?"

If the answer is yes, the Functional Location probably has independent maintenance significance.

Consider:

Boiler Room

Boiler Position 1
- Boiler Serial 84372

Work such as:

inspect gas supply;
inspect foundation;
inspect electrical connection;
inspect ventilation;
verify clearances;

may belong to the position rather than the particular boiler installed there.

Meanwhile:

replace burner;
repair heat exchanger;
inspect refractory;

may belong to the physical Boiler.

In those situations, preserving both concepts in MCe can be extremely useful.

SAP Naming Structures Can Help Construct the Tree

SAP Functional Locations are often configured with structured labels.

For example:

CA01-B01-UTIL-CHW-P01

may encode:

CA01 — Plant B01 — Building UTIL — Utilities CHW — Chilled Water P01 — Pump Position 01

If the SAP implementation uses a consistent Functional Location structure, that gives the synchronization process another reliable source for constructing the MCe tree.

However, where explicit SAP hierarchy relationships are available, those relationships should normally be preferred over attempting to infer everything from strings.

The naming structure can still be extremely valuable for validation and display.

Equipment Hierarchies Should Usually Be Preserved

If SAP explicitly says:

CHILLER-100

COMPRESSOR-101
- MOTOR-102
CONDENSER-103
EVAPORATOR-104

there is normally good reason to preserve that structure in MCe.

These are not merely names that happen to look related.

SAP is explicitly describing Equipment as being installed within superior Equipment.

The corresponding MCe structure can naturally become:

Chiller 100

Compressor 101
- Motor 102
Condenser 103
Evaporator 104

This allows the maintenance history of the individual Equipment records to remain distinct while preserving the relationship between them.

But MCe Does Not Have to Stop Where SAP Stops

This is where the synchronization model becomes particularly useful.

SAP may deliberately maintain equipment only to a certain level.

For example:

CHILLER-100

COMPRESSOR-101
CONDENSER-102
EVAPORATOR-103

MCe users may want:

CHILLER-100 (SAP + MCe)

COMPRESSOR-101 (SAP + MCe)
- Drive Coupling (MCe)
- Oil Filter (MCe)
- Suction Temperature Sensor (MCe)
CONDENSER-102 (SAP + MCe)
- Fan 1 (MCe)
- Fan 2 (MCe)
- Fan 3 (MCe)
EVAPORATOR-103 (SAP + MCe)

There is no requirement that every maintainable object created in MCe also become SAP Equipment.

That decision should be driven by business requirements.

Establish an SAP Synchronization Boundary

This creates a useful concept:

The SAP Synchronization Boundary

Some MCe Assets represent SAP technical objects.

Others exist only within MCe.

For example:

Functional Location: CHILLED-WATER (SAP)

CHILLER-100 (SAP Equipment)
- COMPRESSOR-101 (SAP Equipment)
  - Oil Filter (MCe only)
  - Coupling (MCe only)
  - Sensor (MCe only)

The integration must know that the first three records participate in SAP synchronization while the detailed MCe children do not.

Creating:

Compressor 101 → Vibration Sensor

in MCe should not automatically result in somebody discovering a new Equipment master record in SAP.

This Is Particularly Important for Bidirectional Synchronization

If SAP is the system of record for Equipment master data, MCe may receive changes from SAP but send back only carefully selected information.

For example:

SAP → MCe

Equipment identity
Functional Location
superior Equipment
description
status
manufacturer
model
serial number
classification
selected characteristics

while:

MCe → SAP

might include only:

approved maintenance information;
selected status changes;
meter information;
selected work information;
or other explicitly agreed data.

The exact direction depends on the implementation.

The important point is that synchronization direction should be established field by field and process by process.

"Bidirectional synchronization" should never simply mean:

"Whichever system changed last wins."

SAP Should Usually Remain Authoritative for SAP-Owned Structure

If the organization continues using SAP as its enterprise system, there is generally value in making SAP authoritative for the technical objects it owns.

For example, if SAP moves:

PUMP-1001

from:

LINE-01

to:

LINE-02

the corresponding synchronized MCe Asset should normally move as well.

But consider that MCe contains:

PUMP-1001

Motor
Coupling
Seal
Vibration Sensor

where those children exist only in MCe.

When SAP moves PUMP-1001, the MCe synchronization should normally move the entire branch:

LINE-02

PUMP-1001
- Motor
- Coupling
- Seal
- Vibration Sensor

The MCe-specific detail should not be destroyed merely because the SAP-owned parent changed location.

Classification Requires a Mapping Decision

SAP technical objects can contain classification and characteristic information.

MCe also has Classification and Specification capabilities.

This creates an opportunity to do considerably more than synchronize a description.

For example, SAP may identify an Equipment object as a particular pump type and maintain characteristics such as:

design flow;
design head;
manufacturer;
model;
power;
material;
connection size.

Rather than simply putting all of that information into miscellaneous text fields, appropriate SAP classification information can be mapped into the MCe Classification and Specification model.

That gives MCe users structured information that can subsequently be used for:

searching;
filtering;
reporting;
automation;
comparison;
maintenance decisions.

The two classification systems do not necessarily need to be identical.

A mapping can determine how SAP's enterprise classification should be represented for the MCe maintenance use case.

Be Careful with SAP Deletions and Inactivation

If a synchronized technical object disappears from a normal SAP query, MCe should not immediately assume:

"Delete the Asset."

There are several possible reasons.

The object may have:

become inactive;
been dismantled;
moved;
been marked for deletion;
changed status;
fallen outside the synchronization scope.

And the corresponding MCe Asset may contain:

work history;
documents;
MCe-only child assets;
specifications;
comments;
other operational information.

In most implementations, retaining history is substantially more important than making the tree perfectly reflect only currently active equipment.

The synchronization design therefore needs explicit rules for retirement, deactivation and deletion.

Decide How Much of SAP to Synchronize

A large SAP environment can contain vastly more technical objects than a particular MCe implementation needs.

Suppose a multinational organization has:

500,000 SAP Equipment records

but MCe is being introduced for one division containing:

18,000 relevant Equipment records.

There is generally no benefit in synchronizing the other 482,000 simply because they exist.

Synchronization scope might be determined by:

Plant;
Maintenance Plant;
Functional Location branch;
Planner Group;
Equipment category;
technical object type;
status;
classification;
organizational information;
another agreed business rule.

This keeps the MCe environment relevant to its users and reduces unnecessary synchronization activity.

If in the future more is needed, perhaps because other divisions move, you can add additional roots and decide whether existing technicians should be given access to their previous root and/or the new root

Do Not Assume the Entire Functional Location Tree Is Required

The same principle applies to Functional Locations.

You may need portions of the parent hierarchy to provide context even though those nodes would not otherwise satisfy the synchronization filter.

For example, if MCe needs:

PUMP-POSITION-14

we may also need:

Canada

Calgary Plant
- Utilities
  - Chilled Water
    - PUMP-POSITION-14

even if the synchronization rule technically selected only the pump position.

The integration therefore needs to understand ancestor requirements.

A filtered synchronization should not produce:

PUMP-POSITION-14

floating at the root of the MCe Asset Tree simply because its SAP ancestors were excluded from the normal asset-selection criteria.

Structural Nodes Can Be Synchronized Differently

It may be useful to distinguish between:

Operational MCe Assets

and:

Structural MCe Assets

For example:

North America ↳ Canada ↳ Calgary Plant ↳ Utilities ↳ Chilled Water ↳ CHILLER-100

Perhaps only CHILLER-100 and some of its immediate technical structure are objects against which MCe users normally perform maintenance.

The upper levels still provide extremely useful navigation.

Those records can therefore be treated differently where appropriate while still preserving the SAP hierarchy.

Synchronization Should Be Incremental

After the initial synchronization, there should normally be no reason to repeatedly process the entire SAP technical-object population.

A production integration should be designed to identify and process relevant changes.

Conceptually:

SAP change → identify affected technical object → retrieve required SAP information → determine corresponding MCe Asset → evaluate hierarchy → update MCe → preserve MCe-specific information

This becomes particularly important for large SAP environments.

The synchronization process should also be capable of handling dependency changes.

Changing one Functional Location relationship may affect the effective hierarchy of many descendants.

Keep an Integration Identity Separate from the Display Identity

An MCe user may want to see:

Chilled Water Pump 1

rather than:

000000000001847291

or a highly encoded SAP technical identifier.

That is fine.

The SAP identity should still be retained internally for synchronization.

This allows MCe to present information in a form useful to technicians without compromising the integration.

The same principle applies to Functional Location labels, Equipment numbers and other external identifiers.

The same principle applies to MCe's object GUIDs

Integration identity and user-friendly identity do not have to be the same thing.

A Practical SAP-to-MCe Design Exercise

Before synchronizing an entire SAP environment, select several representative technical structures.

Include:

a simple Functional Location with Equipment;
a deep Functional Location hierarchy;
Equipment with sub-Equipment;
movable Equipment;
a replaceable Equipment position;
an asset with substantial history;
an asset with classification and characteristics;
inactive or dismantled Equipment;
an area where MCe needs only a subset of SAP assets;
an area where MCe will contain additional detail.

Then construct the proposed MCe Asset Tree.

For every node, ask:

Is this an SAP Functional Location?

Is this SAP Equipment?

Is this an MCe-only Asset?

Is this primarily a structural node?

Who owns it?

Can its parent change?

Can the physical object move?

Can it be replaced while the position remains?

Can MCe users create children underneath it?

That exercise exposes most synchronization problems before they affect thousands of records.

Questions to Answer Before Synchronizing SAP and MCe

Before implementation, establish:

Which SAP Plants or organizations are in scope?
Which Functional Locations are in scope?
Which Equipment is in scope?
Do all synchronized Functional Locations become MCe Assets?
Do all synchronized Equipment records become MCe Assets?
Which SAP hierarchy levels should appear in the MCe Asset Tree?
How are SAP Functional Locations distinguished from SAP Equipment in MCe?
How are superior/sub-Equipment relationships represented?
How are Equipment installations at Functional Locations represented?
What happens when Equipment moves?
What happens when Equipment is replaced?
What happens when Equipment is dismantled?
What happens when a technical object becomes inactive or is marked for deletion?
Which SAP system is authoritative when multiple SAP environments are involved?
Which fields are SAP-owned?
Which fields can MCe update?
Which fields are MCe-only?
How are SAP classifications and characteristics mapped into MCe Classifications and Specifications?
Can MCe users add additional child Assets?
How are those MCe-only Assets prevented from being created accidentally in SAP?
How are hierarchy changes synchronized without losing MCe-only descendants?
Which identifiers are retained for integration?
What information is displayed to MCe users?
How are synchronization errors reported and corrected?
What determines that an SAP change needs to be synchronized?

These decisions are considerably more important than the mechanics of moving records between the two systems.

The Key Difference from a Simpler CMMS Integration

With SAP, we should assume that the existing system may already contain an extremely sophisticated and carefully designed technical structure.

The objective is not to replace that structure simply because MCe has an Asset Tree.

The objective is to make that structure useful within MCe.

SAP can continue to provide the enterprise technical-object model:

Functional Locations Equipment Equipment hierarchies Installations Classifications Characteristics

while MCe presents the appropriate portions of that information in a maintenance-oriented Asset Tree and adds the information and functionality needed by its users.

Where appropriate, MCe can also extend below or around the SAP structure with additional Assets that do not need to become SAP master data.

The Key Principle

For a continuing SAP environment, the best integration is usually not:

"Copy SAP's assets into MCe and copy MCe's assets into SAP."

It is:

"Allow SAP and MCe to represent the same physical maintenance environment while respecting the purpose and ownership of each system."

SAP Functional Locations can provide the stable technical or spatial structure.

SAP Equipment can provide the identity of the physical objects installed within that structure.

SAP Equipment hierarchies can describe complex equipment.

MCe can translate those relationships into an intuitive Asset Tree, synchronize the information its users need, and—where appropriate—extend that structure with additional maintenance detail that does not need to become SAP master data.

That gives the organization the advantages of MCe without asking it to abandon the technical-object model it has already invested in building in SAP.

The goal should not be to make MCe another copy of SAP. It should be to make SAP's asset information substantially more useful to the people and processes that are using MCe.