Skip to end of metadata
Go to start of metadata

Performance-based logistics (PBL) has become the preferred sustainment strategy for defense organizations and civil businesses deploying complex asset systems such as jets, helicopters, and ships. Instead of buying an entire jet, for example, or the parts, tools, and repairs needed to maintain a jet, today's organizations are now buying the availability or readiness of jets from external service providers who guarantee that the jet's functionality will meet predetermined safety and efficiency objectives. In short, a PBL contract of the highest level stipulates that the service provider is responsible for all of the planning, implementation, and coordination required to maintain and repair an asset system being deployed by the organization that has signed the PBL contract. In some instances, a PBL contract will specify that the service provider first design and build the asset system as well.
The Maintenance Service Collaboration ES bundle integrates the databases of organizations deploying complex asset systems with the databases of the service providers that maintain and repair them. The bundle's services enable either party in the service chain to notify one another of the need to maintain or repair an asset system. After a maintenance request has been submitted, users can validate and plan the work. Maintenance orders to perform the work can be generated from maintenance requests as well. Later, once the service provider has created, changed, or updated data in its backend system to reflect the work performed, the other party can transfer the same data to its own system.

Maintenance Service Collaboration (click to enlarge)

For example, if a technician employed by the organization using an F-16 jet notices during a checkup that the jet's landing gear needs to be replaced, the party that has been contracted to maintain and repair the fleet of jets will receive a message in its system that triggers the actual maintenance process. After the request has been validated, the attendant personnel can plan the date, time, and location of the repair, as well as arrange for the availability of all requisite manpower, tools, parts, and equipment. A maintenance order will then be generated from the maintenance request, whereupon the work can be executed.

To ensure that the resulting data precisely reflects the actual equipment after it has been repaired, the service provider transfers all consequent histories to the backend system of the organization deploying the F-16. Among the diverse types of information that may be included in these histories are the time, date, and location of the maintenance or repair, the name of the technician who performed the work, the equipment used (along with its respective serial number), and the installation point of the equipment, to name just a few. In this way, both the defense organization and its contracted service provider can be said to collaborate on the program by which a fleet of jets is maintained and repaired such that it is both accurate and routine, regardless of the maintenance request's point of origination in the service chain.

This collaboration is made possible by the reference and allowed configurations that were established in an earlier process using the closely related Asset Configuration ES bundle. During this process, both the organization deploying the complex asset system and the asset system's service provider created two interrelated models that hierarchically mirror the structure of the asset system. The first of these models, the reference configuration, lists the points of installation for every single one of the parts that an asset system must have for it to meet the safety and efficiency specifications as outlined in the asset system's Statement of Requirements (SOR). For example, an asset system such as an F-16 must have a body, which itself must have a fuselage, wings, tail, and so on. Inside the jet's body there are points to install an engine, a cockpit, landing gear, and a variety of weapons systems, to name a few. The cockpit, for instance, contains a dashboard, a seat, and a throttle, among many other components. In the F-16's reference configuration for each of these components, the installation points are reflected in a discrete, hierarchical structure.

Each jet in a fleet of F-16s is modeled upon a single reference configuration in accordance with the allowed configuration for this fleet. The allowed configuration of a complex asset system mirrors its structure, but with important differences. The F-16's reference configuration requires that all jets be equipped with an engine, rockets, and ailerons, for instance; the jet's allowed configuration, on the other hand, lists the specific type of engine, rockets, and ailerons that are allowed to be installed in an individual F-16.

Table of Contents

Table 1. SAP ERP terms and Enterprise SOA equivalents

SAP ERP Term

Enterprise SOA Term

Functional Location

Installation Point

Piece of Equipment

Individual Material

Material

Material

Measuring Point

Measuring Device

Service Notification

Service Request

Service Order

Service Order

Service Confirmation

Service Confirmation

Service Contract

Service Contract

Measurement Document

Measurement Document

The allowed configuration may permit three types of engines to be installed in an F-16, but only two types of rocket and one type of aileron. In a fleet of F-16s based upon such an allowed configuration, then, there may be three individual F-16s, each equipped with a different allowed engine. Of those same three jets, however, two may use one type of allowed rocket while the third uses the other allowed type. Since only one type of aileron may be installed in any of the jets in a fleet of F-16s, all three of the jets in this example will have the same allowed aileron (as will every other jet in the fleet). The allowed configuration for an asset system such as an F-16 will also include all relevant equipment and serial numbers associated with the type of engines, rockets, and ailerons that are allowed to be installed.

The master data for the reference configurations of an asset system includes functional locations (FLOCs) - also known in Enterprise SOA terms as installation points - but no equipment hierarchies and equipment or material master records. (Table 1 provides a list of SAP ERP terms and their enterprise SOA equivalents.)

The process by which a complex asset system is maintained and repaired consists of four main steps, each of which comprises numerous substeps or subprocesses. In the first step, one or more requests for maintenance are submitted. In the second, the maintenance is planned and scheduled. The third step involves the actual execution of the maintenance. Depending on the degree to which the asset system has malfunctioned, this could require as little work as a simple tune up or as much work as the total overhaul of one of the asset's major components, such as an engine or landing gear system. When the latter is the case, the step includes three additional substeps, including the removal of the respective equipment, followed by the transfer of the replacement equipment from one location to that of the repair, and the subsequent installation of the new equipment. In the fourth and final step, the work is validated, maintenance requests are closed, and appropriate notifications dispatched.

Implementing the Maintenance Service Collaboration ES bundle allows organizations and civil businesses deploying complex asset systems such as jets, helicopters, and ships to identify, track, plan, execute, and validate the maintenance and repair of complex asset systems.

The Maintenance Service Collaboration ES bundle leverages enterprise SOA by enabling service-based communications with modules of SAP ERP 6.0 including SAP Plant Management, SAP Materials Management, SAP Document Management System, SAP Controlling Module, SAP Integrated Product and Process Engineering, and SAP Knowledge Management. All customers and partners must provide their own user interfaces to the enterprise services in this bundle.

Audience

The target market for the Maintenance Service Collaboration ES bundle includes all those organizations and civil businesses that deploy complex asset systems, especially those in the defense and security, aerospace and defense (A&D), industry machinery and construction (IM&C), high-tech, and airline industries.

Some defense customers plan to use these services to implement new collaborative processes together with defense system integrators and implementation partners. There are manufacturer customers that plan to use these services to implement a service-oriented architecture, as well. This is the basis to implement collaborated processes to support all possible levels of PBL contracts.

Several roles in the organization will use this bundle, including:

  • the engineering authority, technical authority, and configuration manager, any of whom may create a maintenance request
  • the maintenance planner, who creates maintenance plans for equipment and schedules its service
  • the maintenance control desk contractor, who evaluates maintenance requests to see if they overlap with other requests and converts them into maintenance orders
  • the maintenance technician, who executes the maintenance tasks
  • an inspector, who checks the technician's work

    For details on Service Operations, Business Objects and Process Components, please check the ES Workplace.


How To Use This ES Bundle

The overall process by which a service provider maintains a complex asset system such as an F-16 jet is complicated, requiring meticulous care and attention from the beginning, when an equipment defect or malfunction is noted and maintenance requests are initiated via SAP ERP 6.0, to the middle, when the equipment is removed, repaired, replaced, and reinstalled, to the end, when the work is completed and validated, notifications are issued, and maintenance requests closed.

Prior to the introduction of the Maintenance Service Collaboration ES bundle this process was more difficult still, due primarily to the intensive labor that was required to ensure that all parties were simultaneously armed with the most current and complete data about their asset systems. Long before defense organizations and civil businesses could maintain their asset systems, for example, they had to create their asset configurations manually. Not only was this process laborious, but also it was lengthy, typically requiring months for workers to unload the paper forms received from the Original Equipment Manufacturer (OEM), organize them, and then literally type in every piece of data needed to recreated an asset configuration in their own system.

The same type of labor was required when maintaining or repairing an asset system. For instance, if an operator in the field noticed or suspected a defective piece of equipment on a jet, she had to write or type a request for maintenance and then submit it to a maintenance control desk contractor personally or via messenger service, fax, or email.

If the request was submitted in hard copy, the contractor had to reenter the information in his system after verifying that it contained all necessary instructions and specifications. If the request was submitted electronically, the contractor still had to reenter the data using copy and paste techniques, at minimum. Either way, this phase of the process alone was painstaking, and it was merely the beginning. To forward the request to the maintenance planner, the contractor needed to follow the same steps as the field operator who initially submitted it. As the request advanced through the procedural pipeline, similar steps would have to be repeated again and again. And each time the maintenance request or order needed modification, it would have to be entered by hand, right down to the final inspection validation-an inefficient and error-prone process, to say the least.

Today, the Maintenance Service Collaboration ES bundle renders the tasks required to maintain a complex asset system quite manageable. Regardless of the vantage point in the configuration landscape, personnel such as engineering authorities, technical authorities, configuration managers, maintenance supervisor contractors, maintenance planners, and maintenance technicians have 360-degree visibility into the asset system's structure, equipment, materials, and data. As such, they can identify, track, plan, execute, and validate the maintenance of their complex asset systems with accuracy and relative ease.

There are two general types of maintenance or repair processes for which users can deploy the services in the Maintenance Service Collaboration ES bundle. The first is light maintenance, whereby an asset system such as a fighter jet is brought to the repair platform for attention to a minor issue such as a flat tire, leaking pump, general tune up, and the like. In such a case, the jet is examined and, if need be, repaired quickly enough to prevent the maintenance plan from being deactivated (every asset system has a maintenance plan that was established with its asset configuration).

The second type of process for which users can deploy the bundle's services is heavy maintenance or repair. Here, the fighter jet has experienced a malfunction critical enough to warrant work that could take days or weeks and so it must be taken out of service. Such circumstances demand that the jet's maintenance plan be deactivated until the jet has been recommissioned for field operations. Maintenance plans adhere to strict protocol. For example, the jet's plan may require its engine to be inspected with every 100 hours of flight time. If the jet is decommissioned for any significant period, however, it makes no sense to invest valuable time and resources inspecting it. When all is said and done, regardless of the type of maintenance or repair process that is engaged, the maintenance request that specified the work must be closed and the jet's operational status updated.

Figure 1 shows an overview of the process for maintaining equipment.

Figure 1. Maintaining Equipment (click to enlarge)



Requesting Maintenance

The maintenance service collaboration process begins when anyone associated with the asset system notices or suspects that one or more pieces of its equipment is malfunctioning. At that point, a request for maintenance must be created, during which process such personnel as the technical authority, the equipment manufacturer, the operator of equipment measuring points, or a mechanical technician must search in SAP ERP 6.0 for the equipment to be repaired, the organization that owns the equipment, or the respective damage codes.

When the maintenance control desk contractor receives a request for maintenance, she reviews it to verify that it contains all necessary instructions and specifications, forwards it to the maintenance planner, and then confirms its status in the maintenance pipeline by sending a notice to the person who initiated the request. At this time, she will also check for outstanding notifications to ensure that the current request does not overlap with any previous requests.

Planning and Scheduling the Maintenance

Now that the request has been initiated, it must be planned. The maintenance planner is responsible for reviewing and updating the maintenance request, as well as for establishing its priority. Additionally, it is his task to update the status of the request and of all equipment related to it. First, the maintenance order must be created, based on data in the maintenance request. This order will specify the department responsible for executing the maintenance, the individuals who will perform the actual work, and the dates when the work will begin and end, according to the availability of resources.
At this juncture, the maintenance planner determines the specific operations that must be performed to complete the maintenance order, along with the material requirements associated with each operation. The decision is made by a careful analysis of the SOR, along with any other relevant documentation in the asset system's reference configuration. He will also order all of the parts required to complete the maintenance order, identify any external work centers and services that are needed, and notify them that they have been assigned their respective tasks. This subprocess consists largely in requisitioning external services and then issuing purchase orders to the respective vendors.
Now the supervisor is ready to update the maintenance order's status to "scheduled." A final estimate for the cost of the resources and materials is confirmed at this point, along with an estimated date of completion.

Executing the Maintenance

As was previously mentioned, the step whereby the actual maintenance is executed could require as little work as a simple tune up or as much work as the total overhaul of one of the asset's major components, such as an engine or landing gear system. When the latter is the case, the step includes three additional substeps, including the removal of the respective equipment, followed by the transfer of the replacement equipment from one location to that of the repair, and the subsequent installation of the new equipment. Either way, the attendant technician must examine the suspect piece of equipment to determine whether is still usable. If in fact the equipment needs work, it must be noted in SAP ERP 6.0 as decommissioned, and its status appropriately updated. Should the equipment be substantial, such as an engine, the technician must locate its installation point (the FLOC) in the asset's reference configuration, along with its respective serial number. Only after these substeps have been taken can the technician begin to dismantle the defective piece of equipment.

The maintenance technician must also create notifications for the transfer of equipment and then update the project in SAP Project System (if these activities are part of a project that is being handled using this tool). Sometimes this entails removing the part from another asset system of the same type and transporting it to the site where the asset being maintained is located. The piece of equipment is packaged in accordance with tech instructions in preparation for transport to the site of the asset's maintenance. All transport instructions are consulted at this time, as well. If specifications can be met, the attendant supply technician authorizes the physical transportation.

Either a technician employed by the organization deploying the asset system or one employed by the service provider can dismantle the equipment being repaired or replaced. Regardless of who executes the maintenance, though, each step in the process must be reflected in the asset's actual configuration (also referred to as an as maintained configuration). The update must be executed in the SAP ERP 6.0 backbone at the time any change is made to the actual asset system, or immediately thereafter. For example, if the left engine in an F-16 jet has been removed, a gap is created in the jet's actual configuration, which will be filled once the new equipment has been installed.

Closing the Maintenance Request

Having received the equipment, the maintainer determines its precise installation point by searching for the gap in the reference configuration that was created earlier. The technician performing the maintenance can now select and prepare the equipment for installation, check it against existing specifications and requirements (which are reflected in the Master Parts List for the allowed configuration) to guarantee its validity, install the equipment, and, if the maintenance plan was deactivated, initiate a new plan to be followed thereafter. The final task in the overall maintenance process is to complete the maintenance order by closing the activity in the maintenance work order operation and closing the related maintenance request (or maintenance notification). Frequently, inspections will be performed to guarantee the work. If so, these will also be reflected in SAP ERP 6.0.

Each of the following use cases will show how different outcomes can be achieved by using the enterprise services in different combinations. Note that these examples may refer to users directly invoking enterprise services. This illustrates the flow of the service operations; in fact, service operations are invoked by an application, by an application's user interface, or by another service operation.

While these use cases illustrate a few of the ways that this ES bundle could be used, the intention is to show the flexibility and reusability of these business objects and enterprise service operations so that you will have a clearer understanding of how to best deploy them in your own environment. This wiki is also a space for you to share knowledge and collaborate with others who are implementing the Maintenance Service Collaboration ES bundle.

Use Case 1: Performing Maintenance on a Complex Asset System

In the opening use cases for the Asset Configuration ES bundle, a defense organization created reference and allowed configurations for a new fighter jet by modeling them on the basis of an older jet that is still in service, an F-16. Now, having been built (that is, completely configured in terms of installation points and installed individual materials) and then deployed in the field, the new fighter is ready for its first maintenance service. Any number of personnel can create the maintenance request, including the engineering authority, technical authority, configuration manager, maintenance supervisor contractor, maintenance planner, or maintenance technician.

The process of creating a maintenance request typically involves searching in SAP ERP 6.0 for such items as the organization that owns the equipment, the equipment to be repaired, and the respective damage codes. The request itself can be created by triggering the Create Maintenance Request service operation, which uses the Maintenance Request business object. Once generated, the request can be found and reviewed at any time by invoking the Read Maintenance Request service operation. To locate other data related to the asset system, such as the organization that owns the asset system and contact information for personnel within it, the user can invoke a service such as the Read Document_V1 service operation, which uses the Document business object.

She can find the equipment she is looking for, along with any equipment-related data, by invoking the Find Individual Material by Elements, Find Parent Individual Material by Individual Material, Find Subordinate Individual Material by Individual Material, or Find Top Level Individual Material by Individual Material service operations, all of which use the Individual Material business object. Any of these services return a list of results, and the user can invoke Read Individual Material to see details. It is particularly important that the user also trigger the Read Individual Material Property service operation since it will provide her with the most current data about the equipment's usability. If the equipment is in any way deficient, the user can invoke the Update Individual Material Property service operation to alter its status.

Before the request can be turned into a maintenance order, it must be sent to the backend system of the service provider's maintenance control desk contractor who acknowledges the request with a return notification and then proceeds to ascertain that the request does not overlap with any other recently generated requests. He also needs to verify that the current request contains all necessary instructions and specifications. To search for existing notifications, the contractor can trigger the Read Quality Issue Notification service operation, which uses the Quality Issue Notification business object.

Upon confirming these details, he will update the status of the request, assign it to the maintenance planner, and then again confirm its status in the maintenance pipeline by sending an update to the user (or system) that initiated the request. To alter the request at any time, he can trigger the Change Maintenance Request service operation. Should he need to subsequently review the request without handy access to its name or code number, the contractor can invoke the Find Maintenance Request by Elements service operations.

In addition to being responsible for reviewing the maintenance request, turning it into a maintenance order, and then planning the order's specific tasks, the maintenance planner is also responsible for establishing its priority. The order will specify the department responsible for executing the maintenance, the individuals who will perform the actual work, and the dates specifying when the work will begin and end, according to the availability of resources. To execute these tasks, the planner can invoke a variety of service operations, depending upon his needs, such as those that use the Individual Material, Maintenance Plan, Maintenance Task List, Installation Point, and Master Parts List business objects.

For example, the planner will likely need to examine the fighter's maintenance plan to see whether it is due for any standard maintenance, or for any maintenance that pertains to the current request, in this case, a leaking fuel pump. It is at this stage that the planner will also determine whether to deactivate the fighter's maintenance plan in consequence of the repair now under way. Any decisions made by the planner will depend as well on what he finds in the maintenance plan's affiliated task list, which must be adhered to if the plan itself is to be consistently achieved. To find and examine the fighter's maintenance plan, the planner can invoke the Read Maintenance Plan service operation. If by chance he does not have the name or code of the plan at his disposal, he can search for it according to data contained in it. To initiate the search, he can trigger the Find Maintenance Plan by Elements service operation. The planner can access any task list he wishes to examine by invoking the Read Maintenance Task List service operation. He may also trigger Find Maintenance Task List Simple by Elements to search for a task list whose name or code he does not have handy. A careful analysis of the asset system's SOR, along with any other relevant documentation, will inform the planner's decision. He can examine these and other relevant documents by invoking the Read Document_V1 service operation.

If the planner wishes to view and analyze equipment that the maintenance technicians may need to perform the work, he can do so by triggering one or more of the aforementioned Individual Material service operations. The Master Parts List with allowed variants can be searched for and examined by invoking the Read Master Parts List Access Node, Read Master Parts List Structure Node, and Read Master Parts List Variant service operations.

Before the planner can give final authorization for the removal or installation of any equipment from an asset system, he must first locate its precise structure node in the actual configuration, which he can do by triggering the Find Installation Point by Elements service operation. This service uses the Installation Point business object, as does the Read Installation Point service operation, whose functionality is necessary for looking up the serial number of the piece of equipment that is installed at this installation point. In this use case, there is only one defective fuel pump on the fighter jet, so there is no question about its location or serial number. The importance of these services becomes especially evident, however (as will be seen in the next use case), when a planner is dealing with two or more pieces of the same type of equipment. For example, the fighter jet currently under maintenance has two engines, a left and a right one, as well as two sets of landing gear. Ascertaining the equipment's structure node and serial number beforehand leaves no question for the maintenance technician performing the work as to which piece of equipment requires service.

Having determined that the leaking fuel pump can be replaced within an hour or two, and that a replacement pump is already on hand in a storage facility adjacent to the repair platform, the maintenance planner decides that it is not necessary to deactivate the jet's maintenance plan---its absence from the field will be negligible. At this juncture, he will also order any required parts or tools, identify all external work centers and services that are needed, and notify them that they have been assigned their respective tasks. This subprocess consists largely in requisitioning external services and then issuing purchase orders to the respective vendors.

A final estimation for the cost of the resources and materials is confirmed at this point, too, along with an estimated date of completion. These concerns met, the supervisor is ready to update the maintenance order's status to "scheduled." To do so, he can trigger the Change Maintenance Order service operation, which uses the Maintenance Order business object.

The maintenance technician performing the work will make additional changes to the maintenance order once she receives. First, she must officially establish that the jet is now temporarily out of order so that no one else in the chain of command will mistakenly believe that it is available for use in field operations. To locate its current status, the technician can invoke the Find Allowed User Status by ID and Type service operation, which uses the Maintenance Request business object. To modify the asset's status to reflect that it is temporarily unavailable for deployment, the technician can trigger the Change Individual Material User Status service operation, which uses the Individual Material business object.

Upon removing the leaking fuel pump, the technician will invoke the Dismantle Individual Material service operation, which uses the Individual Material business object, and then create an accompanying notification by triggering the Create Quality Issue Notification service operation, which uses the Quality Issue Notification business object. When the technician installs the new fuel pump, she will confirm the work by triggering the Install Individual Material service operation. She will also test the new pump, and, given that all is in order, annotate the exact parameters and results of the test in the SAP ERP backbone by invoking the Create Measurement Reading service operation, which uses the Measurement Reading business object.
Before closing the maintenance request, the technician will formally verify that the pump has been certified as acceptable for use in the asset's allowed configuration by triggering the Check Master Parts List Function ID Variant service operation, which uses the Master Parts List business object. If the system validates the part, the maintenance is concluded. All that remains to be done is to confirm its execution, and the technician can do this by invoking the Create Maintenance Confirmation service operation, which uses the Maintenance Confirmation business object.

An inspector might need to double check the maintenance technician's handiwork, too. In the meantime, he may wish to review the maintenance confirmation, which he can do by triggering the Check Maintenance Confirmation Creation service operation. To record his inspection, he can invoke the Create Material Inspection service operation. Any alterations to the inspection, now or in the future, can be implemented by triggering the Update Material Inspection Decision service operation, which also uses the Material Inspection business object. Before authorizing the jet for redeployment in the field, the inspector must update its status in SAP ERP 6.0 by invoking the Update Individual Material Property service operation.

Regardless of who initiates and performs the work, to ensure that status of the jet's equipment system remains transparent and that the maintenance reporting is consistent, it is crucial that attendant service personnel transfer all resulting maintenance histories from the service provider's backbone to the backend system of the organization deploying the new fighter.

Step

Enterprise Service Invoked

Step 1: To create a request

Create Maintenance Request

Step 2: The request can be found and reviewed

Read Maintenance Request

Step 3: To locate other data related to the asset system

Read Document_V1

Step 4: To find the equipment the user is looking for, along with any equipment-related data

Find Individual Material by Elements or
Find Parent Individual Material by Individual Material or
Find Subordinate Individual Material by Individual Material or
Find Top Level Individual Material by Individual Material

Step 5: To view details about the material

Read Individual Material

Step 6: To review the current data about the equipment's usability

Read Individual Material Property

Step 7: If the material is in any way deficient, the user can alter its status

Update Individual Material Property

Step 8: The contractor searches for existing notifications

Read Quality Issue Notification

Step 9: To alter the request

Change Maintenance Request

Step 10: To review the request without handy access to its name or code number

Find Maintenance Request by Elements

Step 11: To find and examine the maintenance plan

Read Maintenance Plan

Step 12: The user can search for it without handy access to the name or code of the plan

Find Maintenance Plan by Elements

Step 13: To examine the task list

Read Maintenance Task List

Step 14: To search for a task list whose name or code he or she does not have handy

Find Maintenance Task List Simple by Elements

Step 15: To examine the relevant documentation

Read Document_V1

Step 16: To search and examine the Master Parts List

Read Master Parts List Access Node and
Read Master Parts List Structure Node and
Read Master Parts List Variant

Step 17: Before the planner gives his final approval, he locates its precise structure node in the actual configuration

Find Installation Point by Elements

Step 18: To search for information about the installation point

Read Installation Point

Step 19: To update the maintenance order's status

Change Maintenance Order

Step 20: The maintenance technician locates its current status

Find Allowed User Status by ID and Type

Step 21: To modify the asset's status to reflect that it is temporarily unavailable for deployment

Change Individual Material User Status

Step 22: To remove the defect

Dismantle Individual Material

Step 23: Then the maintenance technician creates an accompanying notification

Create Quality Issue Notification

Step 24: To confirm that he or she installs the new item

Install Individual Material

Step 25: To test the new item

Create Measurement Reading

Step 26: The technician formally verifies that the item has been certified as acceptable for use in the asset's allowed configuration

Check Master Parts List Function ID Variant

Step 27: To confirm the maintenance execution

Create Maintenance Confirmation

Step 28: An inspector reviews the maintenance confirmation

Check Maintenance Confirmation Creation

Step 29: To record the inspection

Create Material Inspection

Step 30: To alter the inspection

Update Material Inspection Decision

Step 31: To update its status

Update Individual Material Property

Use Case 2: Performing Heavy Maintenance on a Complex Asset System

The previous use case described circumstances in which a fighter jet was removed from field operations so that concerns about a leaking fuel pump could be addressed. Because the pump was in fact defective, it was necessary to replace it, which the attendant maintenance technician did in just a couple of hours. Ordinarily, when an asset system is removed from the field for any significant period of time, the maintenance plan to which all technicians strictly adhere must be deactivated. If, for example, the jet's plan requires its engine to be inspected with every 100 hours of flight time, but the jet has been decommissioned for three weeks while it is at a subcontractor site for maintenance, it would make no sense to create any maintenance item in the operator's system. Deactivating the maintenance plans of decommissioned asset systems saves organizations time, labor, and money.

Such was not the case with the jet whose fuel pump was leaking, so its maintenance plan did not require deactivation. In this use case, however, the situation is more dire. A jet's engine has badly malfunctioned, to the extent that it requires a total overhaul that could take anywhere from three days to three weeks to complete, depending on a variety of factors, including the availability of resources and equipment and the location where the overhaul must be performed (by internal staff, by a subcontractor, or by the vendor).

Another difference between this use case and the last one is in the lack of readily available equipment. The technician in the prior use case had a new fuel pump on the repair platform, ready to install when the jet arrived for service. Here, however, the defense organization deploying the jet with the defective engine does not have a replacement engine on the premises, or even in storage at another location. What the organization does have is another jet of the same type that is also out of service. While the engine from jet number two is fully operational, it has a host of other defects that for a number of reasons cannot currently be attended to. Consequently, a decision could be made to remove the working engine from jet number two and then install it in jet number one, which is located at another base. The defective engine that is taken from jet number one will then be transferred to the base at which jet number two is stored, where it and the other pieces of the jet's defective equipment will undergo repairs at a later date.

To avoid unnecessary repetition, it can be assumed that all of the steps and services that were applied in the previous use case have been applied in this use case as well. That is, a maintenance request was submitted and authorized for jet number one, and all equipment-related data were examined.

Figure 2. Transferring Equipment (click to enlarge)


It was during the process of creating a maintenance order from the initial request that the maintenance planner realized an engine was not available to replace the defective engine in jet number one. A thorough search of available materials, maintenance plans, master parts lists, and installation points, however, revealed the availability of the engine in jet number two. The services deployed to perform these searches are the same as those described in the previous use case, and include those that use the Individual Material, Maintenance Plan, Maintenance Task List, Installation Point, and Master Parts List business objects.
Anytime an asset system undergoes service of any kind, however minimal, a maintenance request and order must be created to document the work. Therefore, a maintenance request must be created for jet number two so that technicians receive authorization to dismantle its working engine in preparation for transport to the base where it will be installed in jet number one. Incidentally, it has become clear by this point that neither jet number one nor two will see field deployment in the near future, so the maintenance plans for both are deactivated by invoking the Deactivate Maintenance Plan service operation, which uses the Maintenance Plan business object.
The attendant maintenance planner must locate the precise structure node in the actual configurations for both of the engines that are to be removed from jet numbers one and two. In addition, he must also locate where both of the engines are to be installed, all of which he can do by triggering the Find Installation Point by Elements service operation. This service uses the Installation Point business object, as does the Read Installation Point service operation, whose functionality is necessary for looking up the serial numbers of the installed individual materials for both engines. Again, ascertaining the equipments' serial numbers beforehand leaves no question for the maintenance technician performing the work about which engines are to be serviced.
Once both engines have been pulled, the technicians at either base will invoke the Dismantle Individual Material service operation, which uses the Individual Material business object, and then create an accompanying notification by triggering the Create Quality Issue Notification service operation, which uses the Quality Issue Notification business object.
In addition, both maintenance technicians must create notifications for the transfer of the engines and then update the projects in SAP Project System (if these activities are part of a project that is being handled using that tool). Both engines will be packaged according to tech instructions in preparation for transport to their respective maintenance sites, and all transport instructions will be consulted. Goods receipts will also be drawn up for the defective engine and for the working engine, as will goods issuances. Finally, if all specifications can be met, the supply technician overseeing this phase of the process will authorize the physical transportation of the engines.
When the technicians install the engines in the respective jets, each one will confirm the work by triggering the Install Individual Material service operation. The technician servicing jet number one will also test the engine to ensure that it still meets all required specifications and requirements. To annotate the exact parameters and results of the test in the SAP ERP backbone, he can invoke the Create Measurement Reading service operation, which uses the Measurement Reading business object.
Before the maintenance requests for jet number one can be closed, the attendant technician must formally verify that the engine has been certified as acceptable for use in the asset's allowed configuration by triggering the Check Master Parts List Function ID Variant service operation, which uses the Master Parts List business object. If the system validates the engine, the maintenance is concluded. Although the technician servicing the jet with the defective engine could not perform any tests, as a formality he must nevertheless engage the same validation process for the engine that the technician performed for the working engine in jet number two.
All that remains to be done is to confirm the execution of the work on both jets, which either technician can do by invoking the Create Maintenance Confirmation service operation, which uses the Maintenance Confirmation business object.
As in the previous use case, inspectors may need to double check the handiwork of both maintenance technicians. They can review their maintenance confirmations by triggering the Check Maintenance Confirmation Creation service operation, and they can record their inspections by invoking the Create Material Inspection service operation, which uses the Material Inspection business object. Any alterations to these inspections can be implemented by triggering the Update Material Inspection Decision service operation, which also uses the Material Inspection business object. Before authorizing jet number one for redeployment in the field, one of the inspectors must update its status in SAP ERP 6.0 by invoking the Update Individual Material Property service operation.
As ever, regardless of who initiates and performs the work, to ensure that the equipment systems for both jets remain transparent and that the maintenance reporting be consistent, it is crucial that attendant service personnel transfer all resulting maintenance histories from the service provider's backbone to the backend system of the organizations deploying the jets.

Step

Enterprise Service Invoked

Step 1: If it has become clear that neither jet number one nor two will see field deployment in the near future, the maintenance plans for both have to be deactivated by the technician

Deactivate Maintenance Plan

Step 2: To search for an Installation Point according to specific data

Find Installation Point by Elements

Step 3: To view the serial numbers of the installed individual materials

Read Installation Point

Step 4: To pull the engines

Dismantle Individual Material

Step 5: To create an accompanying notification

Create Quality Issue Notification

Step 6: The technicians install the engines in the respective jets and confirm the work

Install Individual Material

Step 7: To test the engine and annotate the results

Create Measurement Reading

Step 8: The technician formally verifies that the engine has been certified as acceptable for use in the asset's allowed configuration

Check Master Parts List Function ID Variant

Step 9: To confirm the execution of the work

Create Maintenance Confirmation

Step 10: An inspector reviews the maintenance confirmation

Check Maintenance Confirmation Creation

Step 11: To record the inspections

Create Material Inspection

Step 12: To alter the inspection

Update Material Inspection Decision

Step 13: To update the status of the jet

Update Individual Material Property

Best Practices

Maintenance Collaboratoin Solution

Maintenance Collaboration is available as an Implementation Package based on SOA* on


The Maintenance Collaboration solution allows identification, planning and execution of maintenance to technical systems by offering collaboration between service providers and their customers.
The Package inculdes the following features:

  • The scenario includes the creation of a service maintenance request, the central validation of requests by personnell responsible for a specific unit and the central planning of respective maintenance activities
  • Maintenance data can be made available either in the service provider system or the customer system, depending on the contractual agreements
  • Provide web based transparent automated and integrated process for operational units to enable quick responsiveness for maintenance requests
  • Seamless integration of business partners (supplier and business partner)
  • Simplified and easy-to-use user interface providing comprehensive information at one glance regarding to business functions

For detailed information including pricing, visit https://ecohub.sdn.sap.com/irj/ecohub/solutions/maintenancecollaboration

*What is an Implementation Package based on SOA?

An Implementation Package based on SOA is a business process solution.  It is provided via the rapid implementation of a tailored application
based on SOA. It helps enterprises differentiate, while lowering the related cost.

The Implementation Package comprises the combination of:

  • Business Use Case
  • Delivery Type and Methodology
  • Technical Foundation and Tool Support

Simple Sample Apps

Simple Sample App available

If you are looking for best practices in consuming enterprise services from the Maintenance Service Collaboration ES bundle, please refer to the Simple Sample App Create Quality Notification and Upload Document as a ready-to-run example, including testing data for immediate use.

SOA-based Composite for Maintenance Service Collaboration at Canadian Department of National Defense.



Easy-to-use Web applications should enable everybody at the Army, Air Force, and Navy to submit maintenance requests for equipment. Increasing process efficiency and quality of the maintenance process are the main business drivers to build the composite using SAP NetWeaver Composition Environment 7.1 (SAP NetWeaver Visual Composer, SAP Composite Application Framework, guided procedures), based on the maintenance service collaboration ES bundle communicating with modules of SAP ERP 6.0.

This composite has been developed as a Proof of Concept project in cooperation between Canadian Department of National Defense (DND) and SAP Field Services ( Value Prototyping + Custom Development ), in order to demonstrate how to use the enterprise services, what are the tools and what is the best approach for SOA projects. We gained experience going through the whole project - from defining business process steps to the technical challenges.

Business benefits

  • Increased level of readiness of the assets
  • Efficient collaboration between asset operator and service provider
  • End-user acceptance through UI Simplicity and better usability

Project phases

  1. Process and roles definition
  2. Data Context and Mapping of the Enterprise Services
  3. Business process simulation (UI Mock-Up)
  4. Solution Design
  5. Development 
  6. Test, Delivery + Know-how transfer

For more information please contact Bronislaw Tultschin  from SAP Value Prototyping.


Business Process and Solution Design


One-slide Overview of this solution





Future Directions

A related ES bundle, referred to as Take-Over/Hand-Over, may be added to provide mapping of an XML file to ERP, making it easier to load complex asset systems into SAP ERP 6.0.

System Requirements

Related ES Bundles

End-to-end Processes Where This ES Bundle Is Used

SOA Homepage on SDN