Concepts

Settings

Sharing and Partitioning Data Between Sites

In a multi-site environment, different sites can own different types of objects. Object ownership is defined by site type and identifies which sites control and maintain the information about an object. For example, some objects, like resources or standard task templates, might be owned by a head office but used by the various lower-level sites. Part of setting up your site hierarchy includes determining which sites own which types of objects as well as which sites need access to those objects.

Data is partitioned (not shared) between sites at the same level in the site hierarchy (peer sites). Typically, each site has its own assets, work order backlog, and so on. In APM, you can decide which information is shared or partitioned using site types and your site hierarchy.

Sharing Common Data Between Sites

Sharing certain common types of data makes the reporting process easier (you can compare apples to apples). For example, if you want to see how much you are spending on maintenance for one type of equipment, system, or sub-system of assets, you want to be able to compare the same costs between the various sites in your company. Defining asset types at the highest level in the site hierarchy ensures consistency in the reporting of data (based on asset type) between lower-level sites.

Sharing data can also help to streamline and control maintenance information, and reduce unnecessary data entry where common information is used between sites. For example, you can take advantage of standard preventive maintenance jobs at multiple sites by owning and setting up job templates (and standard documents) at a higher-level site. In this way, you can ensure consistency of job procedures and safety instructions across sites.

Before data can be shared between sites, it must be set up at a site higher in the site hierarchy. When data is displayed in APM, you have the option of viewing data for your site only or for sites above or below your site in the site hierarchy. For example, when viewing a list of job templates, you can limit your search to templates that apply only to your site or switch to the full listing of all job templates that have been created to be shared for the whole organization.

TOP

Partitioning Data Between Sites

Data that is owned by one site is always partitioned from its peer sites (that is, sites that are at the same level in the site hierarchy). This is the main purpose of multiple sites in APM.

Partitioning data, like work orders and work requests, makes the day-to-day operation of the individual maintenance organizations much easier. For example, finding a work request takes less time when only your site’s list of requests is being searched.

The starting point in defining how your data will be shared or partitioned is to set up site types.

TOP

What Are Site Types?

Site types define how objects, such as assets and task templates, are owned at each level in the site hierarchy. A site that cannot own an object might still be able to create objects (for example, task templates), but they will be owned (stored) at a higher site in the hierarchy. How objects are owned determines how data will be partitioned within APM.

Site types at higher levels of the organization own data that is shared by lower sites, such as value lists, resources, and standard documents. Data that higher-level sites wish to control (such as task templates) can be owned and secured at the higher site. This data can then be viewed and used by lower-level sites.

Lower-level site types own data that is unique and not shared between peer sites (that is, sites of the same type and at the same level in the site hierarchy). For example, data that is added and changed on a day-to-day basis, such as work orders, work requests, and assets, are usually owned by lower-level site types.

TOP

How are Site Types Used in the Site Hierarchy?

If you are using multiple sites, you must decide how each type of object is owned in APM. When you create sites, select the appropriate site type to identify the object ownership settings. When you set up your site hierarchy, you might set all sites on the same level to the same site type. This ensures that they have the same object ownership properties.

If you have licensed the Enterprise Asset Management (EAM) module, you can turn it off on individual sites. In a site hierarchy that contains both EAM and non-EAM sites in the same branches, if you are using a central Purchasing site at a higher level, create different site types for EAM and non-EAM sites with different object ownership rules. The non-EAM site type should not include permission to own purchasing objects (purchase orders, RFQs, invoices, contracts, suppliers, and supplier resources). This will prevent purchase orders, for example, from being created at sites that do not support them.

The examples and guidelines in this document will help you make decisions on how to set up your site hierarchy. The following graphic shows how site types map to an example site hierarchy.

You can create a variety of types of sites, from the head office to regional offices, divisions, plants, shared warehouse locations, or logical organizations created for summary and reporting purposes.

Object ownership in a complex site hierarchy often looks like the following:

Objects	Head Office Site Type	Country Site Type	Region Site Type	Location Site Type
Administrative Settings	X
International Settings	X
Accounting Settings/Financial Periods	X
Employees	X		X	X
Resource Transactions	X		X	X
Suppliers	X			X
Purchase Orders	X
Resources	X
Warehouses				X
Assets				X
Work Requests, Work Orders,				X
Work Schedules				X
Requisitions				X
Standard Tasks, Jobs				X
Standard Task/Job Templates	X
Standard Documents	X

You can use this table as a guideline in establishing your site type settings.

TOP

General Rules of Object Ownership

Some data that must be shared between sites (as defined by APM) are contained in objects that are automatically owned at the top site in your site hierarchy.

Objects automatically owned by the top site include:

•	Maintenance value lists (for example, work types and maintenance groups)

•	Inventory value lists (for example, ABC classifications, and resource categories)

•	Procurement value lists (for example, extra charges and FOB points)

•	Accounting value lists (for example, GL accounts and labor rate types)

•	Financial periods

•	International value lists (for example, exchange rates and countries)

•	Site types

Site ownership is determined by the site type for the following objects:

Foundation Objects

•

Employees

•

Resources

Maintenance Objects

•

Assets

•	Asset activity reports

•	Asset transfer documents

•	Indicator templates

•	Maintenance schedules

•

PM routes

•

Projects

•	Standard documents

•	Standard tasks and jobs, and job and task templates

•	Work orders

•	Work requests

Analyses

•	Asset prioritization analyses

•	Current practice reviews

•	Maintenance task analyses and MTA templates

•	RBI analyses

•	RCM2 analyses and templates

Materials

•

Contracts

•

Invoices

•	Purchase orders

•	Requests for quotation

•	Requisitions

•	Resource Transactions

•	Supplier resources

•

Suppliers

•	Transaction entry forms

•	Warehouses

Asset Health

•	Asset health calculations

•	Asset health report definitions

Approval settings are also site-specific. You will set up document approvals at the site that owns the document objects (work request, work order, requisition, purchase order and asset transfers).

The objects for which you must define the ownership by site type are described below in detail.

Note: The two-tiered site hierarchy shown in the illustrations is an example only. It is used to help explain the multi-site concepts. You are not limited to a two-tiered hierarchy.

TOP

Value Lists

All value lists are automatically owned at the top-most site. You do not have an option within site types to change this. When you add an item to a value list (for example, an asset type), it is added at the top-most site and becomes visible to all other sites. This helps to ensure that data entered at each site is consistent.

If a Plant 2 employee adds a setting or value, it is added to the common listing owned at the top-most site. The setting or value can be viewed by all other sites.

All settings and value lists are added at the top-most site. They can be viewed at all sites, with some exceptions. For the following, site-specific settings are required:

•	Labor rates

•	Document numbering

•	Maintenance groups

Although labor rate types are defined at the top-most site (for example, regular, overtime, holiday), the actual labor rates are unique to each site. When you add a timecard, the labor rate used is the one specified for the site in which you are adding the timecard.

Document numbering settings, which are alphanumeric identifications that distinguish one object from another, must be unique within each site. For example, each work order at each site must have a different work order number, but work orders at different sites can have the same number. If necessary, you can enter a site-specific prefix or suffix for objects that need document numbers that are unique throughout the enterprise. You need to open the document numbering settings dialog in each site to set the numbering format by site.

Maintenance groups can be numerous in many organizations. Therefore, you can set up a hierarchy of maintenance groups, then from each site, identify the top maintenance group. If you have done this, then the maintenance group lists show only the children of the maintenance group designated as the top-most group for that site.

TOP

Employees

Employees will likely be owned by all site types, with the majority of employees owned at the lowest level in the site hierarchy: the operating sites. Employees must be created in APM in the site in which they work. If an employee will work in multiple sites, you must create that employee at a higher-level site.

An employee can belong to only one site at a time in APM: the site in which the employee profile is created (the employee’s working location). It is in this site that the employee must enter all of his or her transactions (for example, timecards, issues, and so on). If the need arises, you can transfer an employee to another site. In order to transfer an employee, that employee must have no unfinished work or responsibilities at the site from which he or she is transferring. For example, he or she cannot be included in the availability of an open work schedule.

For example, an electrician works at both Plant 1 and Plant 2. His employee profile is set up at the Head Office site. When scheduling/assigning of work tasks takes place at Plant 1, the scheduler can select from a listing of employees for Plant 1 and above, and so the electrician is included in the list. However, the electrician will still need to enter his timecards in the Head Office site.

Further, to identify an employee responsible for a document (for example, a buyer of a particular item from a supplier or a planner of a work order or task template), he or she must be added as an employee at the site that owns the documents or objects. For example, planners must be added at a site at, or higher than, the site that owns the task templates and work orders.

Employees set up at peer sites are not ever visible between those sites. For example, employees entered at Plant 1 will not be visible from Plant 2.

TOP

Suppliers

If you have centralized Purchasing (or at least have a corporate supplier listing that is used at all sites), you need to set ownership of suppliers at your top-most site or a higher-level site than the sites that will use the common listing of suppliers, as shown in the following graphic:

In this example, all suppliers are added at Corporate (the only site type that owns suppliers). Plant 2 cannot add local suppliers (only viewed at Plant 2). If a Plant 2 employee adds a supplier, it is added to the common listing of suppliers owned at the Head Office and can be viewed at Plant 1.

Lower-level sites can also own suppliers if you wish them to be able to add their own local suppliers that are not shared by peer sites. This is shown in the following graphic:

Head office can add suppliers common to Plants 1 and 2. Plants can add local suppliers; however, suppliers added at Plant 1 cannot be viewed by Plant 2. Head office can view the list of all suppliers, including local suppliers added at Plants 1 and 2.

Resources and Warehouses

Resources are the materials, tools, trades, and services you require to fulfill the work order requirements at your company. Site types set ownership of all resources as a group. You cannot set different ownership rules for materials, trades, services, and tools individually. Typically, all resources are owned at the top-most site so that spare parts and trades only need to be added once and are consistent across all sites.

If you have multiple sites in different geographical areas, you can define your warehouses at lower-level sites. When spare parts are planned for a work order, the planner can then view only the warehouse inventory balances for his or her site. The following graphic illustrates an organization where resources are owned at the top, while warehouses are owned at a lower site.

In this example, Head Office can own resources common to Plants 1 and 2. Each plant can add resources specific to it, as well as view common resources owned at the Corporate site. Head Office can view the list of all resources, including those local to plants. Plant 1 cannot view warehouse balances specific to Plant 2 and vice versa.

If you own resources at all levels in your site hierarchy, you can vary the site at which you add resources based on the type of resource you are adding:

•

Materials/Spare Parts. If you have a centralized spare parts catalog that is used at all sites, set ownership of resources at your top-most or higher-level site. The lower-level sites can also own resources, for example if you wish them to be able to add their own spare parts, which are not shared by their peer sites.

•	Trades. If some trades are available only at one site, that site type must be able to own resources so that you can add them there. If a common list of trades must be available at all sites, add them at the top-most site so that they are shared.

Note that you are defining the trade in general here, not identifying specific employees. Most likely, all trades will be set up at the top-most site so that the listing of trades at the lower-level sites is the same, common listing. However, when scheduling specific employees to the trade requirement, you can show in listings only those employees at the specific site in which you are working, or you can also include employees defined at higher-level sites.

•	Services. Service type resources, for example contract electricians, might be available only locally to service specific sites. If this is the case, resources must be owned at the lower-level site type to allow for the addition of services at that level.

•

Tools. Like spare parts, you can share the listing of tools across multiple sites. In this case, set ownership of resources at your top-most site. If you want lower-level sites to be able to add their own tools which are not shared by their peer sites, you must allow that site type to also own resources.

TOP

Supplier Resources

In a multi-site environment, the site where a supplier resource is defined controls which suppliers are available for a particular purchase. The system uses the following rules to control the supplier resources available for a particular demand or P.O. line:

•	Only supplier resources for active, ordering suppliers are considered. A bidder-type supplier may be manually selected but is not defaulted by the system.

•	Only supplier resources for the demand’s type of purchase are considered. For example, if the demand is for a repair order, only repair order supplier resources are considered.

•	If at least one supplier resource exists for the resource at the demand’s site, only the supplier resources at the same site are considered. Supplier resources defined at other sites are not considered or available for the demand.

•	If no supplier resources exist at the demand’s site, the system reviews resources at sites higher up the site hierarchy (parent sites) until a site is located with a supplier resource. The supplier resources from this site are then available for this demand.

The following example will help to explain this process. The site hierarchy and supplier-resources in the illustration below are used in the examples.

As shown in the drawing, different sets of supplier resources have been defined at three of the sites. Suppliers S1 and S2 have supplier resources defined at the corporate level. The Eastern Division has one supplier resource from corporate supplier S1, and one from local supplier S3. Plant W2 in the Western Division has one supplier resource from corporate supplier S1, and one from a local supplier S4.

Here is how this information is used:

Site Where The Demand Is Placed (PO or WO):	System Selects Supplier Resources From This Site:	Supplier Resources That Are Available:
ABC Corporation	ABC Corporation	S1-R1, S2-R1
Eastern Division	Eastern Division	S1-R1, S3-R1
Plant E1	Eastern Division	S1-R1, S3-R1
Western Division	ABC Corporation	S1-R1, S2-R1
Plant W1	ABC Corporation	S1-R1, S2-R1
Plant W2	Plant W2	S1-R1, S4-R1

You can select the preferred supplier for a supplier resource when entering the price information for the resource. Because of this, the preferred supplier for any resource can be specific to the site and purchase type. For example, your organization could have:

•	Different preferred suppliers for the same resource in different sites. This occurs most often when the sites are located in different geographical areas.

•	Different preferred suppliers for the same resource for different types of purchases. For example, one supplier could be identified as the preferred supplier for new purchases, while a second supplier is preferred for repairs.

•	Different types of suppliers defined at different levels of the hierarchy. For example, the suppliers for new purchases could be defined at the corporate level, while repair suppliers are defined locally.

Only regular prices can be designated to be used for a preferred supplier. Special prices cannot be marked as a resource’s preferred price.

Resource Transactions and Transaction Forms

Resource transactions include warehouse issues, returns, receipts, adjustments, and timecards. The transactions and forms should be owned at the same site type as the employees conducting the transaction. You must ensure that the employees creating the transactions are set up in the same site as the warehouses (issues, returns, adjustments) and/or the purchase orders (receipts), or the work orders (timecards).

Requisitions

Requisitions are usually owned at the same site type as work orders (and work orders are automatically set at the same site type as assets). When you identify the site type that owns work orders, APM automatically adds requisition ownership to that site type. You cannot change this. Requisitions are automatically generated from work orders for material requirements (to be fulfilled via purchase). To allow this, they need to be owned at the same site type.

In this example, Head Office can view listings of requisitions for all descendant sites (Plants 1 and 2), but Head Office cannot create requisitions. Plants can view and create local requisitions only. They cannot view requisitions from peer sites.

Requisition numbers are uniquely identified in APM. However, you can specify a prefix within each site to add to the requisition number so that the numbering scheme can be the same (except for the prefix).

Purchase Orders

If you have centralized Purchasing (that is, purchase orders for all lower-level sites are managed by a central Corporate office), you must set ownership of purchase orders at your top-most site or a higher-level site than the sites that will enter the purchase orders (when there are multiple lower-level sites). Demand for resources can be consolidated onto one purchase order (if warehouses are in different sites, separate lines will be created). Resources can then be received at the appropriate warehouse. You should add the employees who are buyers at the same site that the purchase orders are owned.

In this example, all purchase orders are added at Corporate (the only site type that owns purchase orders). Individual plants cannot manage their own purchase orders. If an employee adds a purchase order at a plant, it is added at Head office and can be viewed by other plants.

If you want lower-level sites to be able to manage their own, unique purchase orders, you can also allow ownership on those site types. If multiple levels of site types own purchase orders, ensure that, in APM, you are in the correct site when adding the order.

In this example, Head Office can add purchase orders, consolidating orders for multiple lower-level sites. Head Office can view listings of all purchase orders, including the orders managed at descendant plants. Individual plants can manage their own purchase orders, as well as view purchase orders added at Head Office. Individual plants cannot view each others’ purchase orders.

Purchase order numbers are uniquely identified in APM. However, you can specify a prefix within each site to add to the purchase order number so that the numbering scheme can be the same (except for the prefix).

Requests for Quotation

The following rules apply to an RFQ in a multi-site environment:

•	A “for demand” RFQ contains purchase demands from a single site only. This rule is by default because a work order or requisition exists in a single site, and an RFQ is created for one work order or one requisition only.

•	The RFQ is created at the source document’s site. If the source document’s site does not allow RFQ ownership, the RFQ is created at the first site above the source document’s site that can own RFQs.

•	The supplier-resources created from the RFQ are created at the site that the supplier prices are for, as identified on the RFQ. Only sites that are allowed to own supplier resource prices can be selected on an RFQ.

•

The resources referenced on the RFQ must exist at the RFQ’s site or at a parent site. A resource from a lower-level site cannot be referenced on an RFQ. This means that ownership of RFQs must be at either the same site type where resources are owned or at a lower-level site type. This is consistent with the general approach that resources are ideally owned and created at higher-level sites.

•	The suppliers referenced on the RFQ must exist at the RFQ’s site or at a parent site. A supplier from a lower-level site cannot be referenced on an RFQ.

Contracts

A purchasing contract can be used to create purchase orders:

•	At the same site as the contract

•	At a site below the contract’s site in the hierarchy. For example, you might create a purchase order at a plant site (the lower-level site) that references a contract created at an administrative, central site (a higher-level site).

Both the contract and the supplier resources referenced on the contract must be at the same site.

Assets

Assets are usually owned by the lowest-level site type. The lowest level in your site hierarchy is where most of the asset-related activity occurs. An asset must be created in the site in which its maintenance work occurs. When you set asset ownership, work request, and work order (and requisition, based on work order) ownership is set automatically in that site type. But you can change this if you wish.

Because assets are uniquely identified in APM, they can exist in only one site at a time. Assets cannot be viewed by peer sites, but they can be viewed by parent or child sites (that is, you can look up and down the site hierarchy but not across at the same level).

In this example, Head Office can view lists of assets for all descendant sites (Plants 1 and 2). Head Office cannot create assets. Plants can create and view local assets. Individual plants cannot view assets created at other sites.

If the need arises, you can transfer an asset to another site (provided there is no work outstanding, and so on, at the original site).

Asset Transfer Documents and the In-Transit Site

When you transfer an asset to another site, you must fill out an asset transfer document. Asset transfer document ownership is automatically set when the asset ownership is established. You cannot change this.

You will need to designate one site as the in-transit site to hold the asset when it is being moved from site to site. This is typically the top-level site or site type (because you can have only one in-transit site and it is designated on the site type). When you set the in-transit site, ownership of several objects is set automatically. The objects affected are:

•

Asset

•	Asset transfer documents

•	Standard tasks and jobs and PM routes

•	Standard task and job templates

All associated standard tasks, standard jobs, and PM routes are transferred with the asset. Also, the standard tasks and jobs could be based on templates, so the template ownership is also needed while in transit (even though the template may not be moved).

TOP

Work Requests and Work Orders

Work requests and work orders should be owned at the same site type as assets. They must be created in the site in which the maintenance work will occur. When you set asset ownership, work request and work order ownership are automatically enabled as well. You can change this if you wish, but it is recommended that they are owned at the same site type. When you set work order ownership, requisition ownership is set automatically to the same setting. This setting cannot be changed.

In this example, Head Office can view listings of work requests for all descendant sites (Plants 1 and 2), but Head Office cannot create work requests. Individual plants can create and view local work requests.

Work requests and work orders cannot be viewed by peer sites, but they can be viewed by parent or child sites (that is, you can look up and down the site hierarchy but not across at the same level). You can review the work backlog for an asset, a system or sub-system (a collection of assets and its descendents), an entire site, or multiple sites in the same site hierarchy.

Work request and work order numbers are uniquely identified in APM. However, you can specify a prefix within each site to add to the document number, so that the numbering scheme can be the same (except for the prefix).

TOP

Schedules

Work schedules are typically owned at the same site type as work orders. They are usually created at the site in which the maintenance work occurs.

Work schedules cannot be viewed by peer sites, but they can be viewed by parent or child sites (that is, you can look up and down the site hierarchy but not across at the same level).

However, an employee can be assigned to work tasks at multiple, peer sites if the employee is set up at a higher-level site.

Task and Job Templates

Task templates are standard task plans that you can use for more than one asset. For example, you could set up a task template for taking the vibration readings on pumps. If you want to use these templates for creating standard tasks and jobs for assets across multiple sites, then a higher-level site must own task and job templates. The lower-level sites can use the templates to create standard tasks and jobs for their specific assets.

If templates are owned only at the higher-level sites, then employees at lower-level sites (with security to add templates) can add templates at the higher-level site. The templates that they add can be used by all descendant sites.

If you want lower-level sites to be able to add their own templates, specific to their site’s assets, you can also allow these sites to own task and job templates. These templates are not shared by their peer sites.

If you are using multiple sites, ensure that the In-transit site type (for asset transfers) also owns standard task templates and job templates. All associated standard tasks, standard jobs, and PM routes for the asset must also be transferred with it. So, if the standard tasks and jobs are based on local templates, they also need to be transferred.

TOP

Standard Tasks and Jobs, PM Routes

A standard task is a plan for a maintenance task that is done repeatedly for a specific asset. You can set up a collection of standard tasks on a standard job. You can generate a work order based on triggers set up on the job. The standard task contains all of the information required to create a work order task.

The lowest site in the hierarchy usually owns standard tasks and jobs (and PM routes) because these are unique to assets and usually also own work orders. These standard tasks and jobs are not shared by their peer sites.

If you are using multiple sites, you need to ensure that the In-transit site type (for asset transfers) also owns standard tasks, jobs, and PM routes. All associated standard tasks, standard jobs, and PM routes for the asset are transferred with it.

TOP

Standard Documents

A standard document is a file that contains extra instructions for assets or work orders, such as safety instructions, drawings that help to identify the asset, links to vendor catalogs, and so on.

If you have a common set of maintenance documents that can be used across all of your sites, then set up ownership of standard documents at your top-most site or a higher-level site than the sites that use the common listing of documents.

In this example, documents are added at the Corporate site and can be viewed by all descendant sites. Employees of individual plants can add standard documents to the common list of documents owned at the Corporate site.

Lower-level sites can also own standard documents if you wish them to be able to add their own unique documents that are not shared by their peer sites.

Standard documents cannot be viewed by peer sites, but they can be viewed by parent or child sites (that is, you can look up and down the site hierarchy but not across at the same level).

TOP