| DEX: (D004) work_package_definition — Work Package Definition | Date: 2007/09/14 16:11:29 Revision: 1.86 |
Continued provision of a required capability, delivered through the operation of a complex capital asset, is achieved through processes that identify, requisition and complete the support work necessary to sustain the asset at it's required functional performance throughout its life. This work is defined either to address a maintenance need, sustaining or restoring asset functions, or to embody a change directive, enabling the asset to deliver revised functionality. In either case, the work is expressed in terms of tasks that need to be executed.
This ‘Work Package Definition’ exchange allows the support requirement for a product, expressed as a list of the tasks to be undertaken as an integrated package of work at a declared location between a set of dates, to be passed between a requestor (such as a product Support Manager) and a support service provider. It has been designed to provide the maximum flexibility in use, while meeting a defined core business need. Extensive use is made of Reference Data Libraries to allow industry specific terminology to be called forward in order to characterise the basic model.
The DEX comprises three basic components, the identification of the support opportunity for the product, the representation of the package that defines the scope of work and the representation of the individual work items that are contained within that package.
The DEX assumes that there is a Support Manager (a type of Person) acting in the role of Support Authority for the asset. The Person in this role has the authority to commit the asset to specific operational usage for defined periods of time. Such periods, termed life cycle opportunities, are defined by their start and finish dates, either planned or actual, and can be classified by the type of activity to which the asset is commited. It is possible for an asset to be assigned to more than one opportunity simultaneously, provided that the activities being undertaken are not mutually exclusive. Within the scope of this DEX, allowable activity classifications will all be subtypes of a support opportunity.
As required by the maintenance plan (see DEX maintenance_plan) established for the asset (the Product_as_individual in ISO 10303 terms), the Support Manager should have identified a series of Support Opportunities across the life cycle to ensure that sufficient time in the life of the product has been reserved in order to complete necessary support work. This DEX assumes that each opportunity will have been given an identity unique to the product. Provision is made in the DEX to identify the Location at which the support work will be undertaken. This is appropriate for mobile products where the Support Manager may have a variety of locations to choose from. The DEX enables a package of work to be put out to tender for any number of competing service providers to bid against.
Each work package will contain one or more tasks that must be completed if the asset is to be brought, or returned, to a designated level of capability. The process of compiling such a package may be initiated in a number of ways.
For example
The compilation process selects, from the list of all possible tasks, only those tasks which are to be completed during the nominated support opportunity, designated in the product life cycle management plan for such activities to be undertaken. The selection process itself is out of scope for this DEX.
Examples of such support opportunities include :
A baseline assumption of the DEX is that the requestor will not, in general, mandate a detailed programme schedule for the work upon the service provider. However, certain tasks may be dependant on other tasks and these dependences can be specified.
For example
Each task identified within the Package will be supported by a specification of the work required. Information available within the specification will vary depending upon its origin and completeness.
For example :
Within the task specification, the opportunity exists to identify all the resources that will be required to complete the task, in terms of external facilities, human resources and replacement parts. It is not the role of this DEX to communicate a comprehensive list of all the resources required to complete the tasks within an individual work package, but this may be derived by inspection of the resource requirements specified for each task.
The exchange is able, by the attachment of an authorization, to indicate the status of the Approval for the work to proceed. This can be applied either to the entire work package, to individual tasks within the work package, or both.
For example :
Emerging maintenance needs, identified as a result of tasks already being undertaken as part of the current Work Package, cannot be added to the current package. This is because the task list for the current package will have been frozen on authorisation. Such emerging work must, therefore, be made the subject of a separate, supplementary or subsequent, package.
Supplementary example :
When emerging work needs to be completed within the same time window of the current support opportunity, it is common practice for the identification of any supplementary work packages to be derived by extension of the identification given to the main package.
Subsequent example :
Given the business requirements specified above, DEX 4 can be seen (below) to have a context which is able to take account of configuration changes, regular scheduled maintenance (restoration and discard), and condition-based maintenance (decided by predicted product performance) required during a period of support. The result will be realized by an as-maintained version of the product, whether it be a modification to the product configuration, or maintenance. DEX 9 reports on the condition of the product after the support period and must thus refer to the as-maintained version of the product as well as the activities carried out. DEX 7 reports on the condition of the product after a period of service, including any fault states encountered and remedied, as well as fault states that remain outstanding. There may also be information on any degradation of the product requiring future remedial action, which might have been predicted within DEX 5. DEX 3 provides a representation for the tasks to support these. Where tasks are not available through this mechanism, they may be provided by DEX4.
The role of DEX 4 is not to represent a detailed plan or schedule of the activities defined, nor is it required to optimise task planning where overlaps in activities are present. DEX 4 presents a package of necessary work that a support provider may wish to carry out on behalf of the owner or custodian of the asset. It is the responsibility of the support contractor to plan the work within the timescale and specifications given. The contractor is also responsible for ensuring efficient use of resources by removing duplicated or redundant activities which may be present across items of work. The contractor may have a library of tasks which realize some or all activities, which may be the result of a Logistic Support Analysis (LSA). However, it is up to the contrator to identify these and any relationships between the activities and the tasks. DEX 4 provides the structures and sequences the activities authorized to be perfomed. A suitable planning system may take the activities and resources defined for the work and schedule both tasks and resources accordingly to meet the timescales specified.
© OASIS 2010 — All rights reserved