This topic concerns Primary and Secondary Implementation Packages in ASI.
When you add an Asset Strategy to an Implementation Package, all Actions that belong to that Asset Strategy become available for use in that Implementation Package. In some cases, however, depending upon your business processes and personal workflows, you might not want to implement all of those Actions in the same Implementation Package. Instead, you might want to
Throughout the ASI product and this documentation, the following terminology is used to describe Implementation Packages:
Except for
Note that an Implementation Package can be both a Primary Implementation Package and a Secondary Implementation Package. For instance, consider the following image, where Package 1, outlined in red, is:
Throughout this documentation, wherever functionality is available for both types of Implementation Packages and the distinction is irrelevant to the explanation, we simply use the term Implementation Package.
Suppose that an Asset Strategy Template contains the following Actions that apply to all pumps:
As illustrated in the following image, you could apply this template to three specific pumps (Pump 101, Pump 102, and Pump 103), which would create three distinct Asset Strategies that all inherit Actions from the template.
After these Asset Strategies exist, you could create a single Implementation Package from them. As illustrated in the following image, all Actions would become available in that Implementation Package, labeled Primary Package 1. In the image, all Actions of the same name are grouped together and shaded a common color. For example, you can see three Vibration Analysis Actions shaded in yellow, where each one is for a different pump (101, 102, or 103).
After the Actions exist in the Implementation Package, you could build a single SAP Maintenance Plan from them. For the purpose of this example, however, we assume that your company requires different users to complete different routes, where each route involves performing only one type of action (only vibration analyses, only thermography analyses, and so on).
Based upon this assumption, you would not want to create a single Maintenance Plan from all of these Actions. Instead, you would want to transfer the common Actions to other Implementation Packages, where each of those Implementation Packages represents an individual route that should be performed by one person.
In the following image, you can see that each group of common Actions is transferred to a Secondary Implementation Package, labeled according to the type of action. For example, all Vibration Analysis Actions have been transferred to the Vibration Route Implementation Package.
Suppose that later, you apply the original Asset Strategy Template to another pump (Pump 104), creating Asset Strategy 4, and you add that Asset Strategy to another Primary Implementation Package, Primary Package 2.
Suppose that Pump 104 exists in a different building than Pump 101, 102, and 103. Regardless of the building in which pumps exists, overhauls are performed on all pumps by the same person. Other actions, however, are divided among operators according to the building in which those pumps exist. In other words, the operators performing actions on Pump 101, 102, and 103 are not going to perform those actions on Pump 104.
In this case, you decide to transfer:
The Overhaul Action to the existing Secondary Implementation Package Overhaul Package.
The Vibration Analysis, Thermography, and Lubrication Actions to new Secondary Implementation Packages.
The final image depicts all of the Actions in their appropriate Implementation Packages.
Note: For the Actions in Primary Package 2, the image illustrates the transfer of only the Vibration Analysis Action to a separate Secondary Implementation Package. The other Actions shaded in gray would also be transferred to other Secondary Implementation Packages.
Copyright © 1993-2015 Meridium, Inc. All rights reserved.