A service object is a physical asset or piece of equipment that requires maintenance or repair. Service objects can be anything from complex industrial machinery, a building to consumer products, and can be located at a customer site or in a company's own facilities. The service object holds key information about a specific piece of equipment and can be linked to a model, a part and a serial number.
Service object classification can be of two different types, Functional or Serial. The main difference between a functional object and a serial object is that a functional object is seldom moved while serial object move frequently around in the facility, to other object structures, as well as placed into inventory.
Serial objects can also be non-movable type. Non-movable serial objects, such as turbines or any other very large pieces of equipment that are not actually functional objects, but which will be moved seldom from their locations, can also be registered as functional objects. For objects such as these that represent tangible parts, you also can define a part number and a serial number, just like you can for serial objects. However, the object's position in the structure cannot be changed.
Moreover, in a service context, service object classification can also be used to represent basic serial tracking behavior of objects. The serially tracked objects can be defined with the 'Serial object' classification and the objects that are not serially tracked with the 'Functional object' classification. The serialization of the model should be matched with the object classification when attaching a model to the service object, i.e.: Serial Models can be connected to Serial Objects while Non-Serial Models can be connected to Functional Objects.
The model can be added directly to the service object or will be automatically added if a Model-Part connection is established for the selected part. When establishing the connection between the Model and the object, the serialization of the two should match. When a Model is associated with a service object, the service-related information defined on the model will either be inherited or instantiated to the Service Object. It is not mandatory to add a model on a Service Object.
When there is no Model attached to the Part, the Part can be added on a Service Object without matching the serialization of the Part and the Classification of the Service Object (a serialized part can be added to a functional service object and vice versa). If there is a model connected to the part, the connection cannot be established if the Model serialization and the service object classification conflicts. Once the connection between the part is established, the model will be added to the object automatically if available.
The Skills tab contains details about Skills, Certificates and Competencies that a person should have in order to perform work for the specific object. The skills can be entered on the Service Object or be inherited from Models and Model Families. When a skill record exists on a Service Object, it will be inherited to the Work Tasks the Service Object is used on, as skill requirements.
There can be multiple customer warranties applied on an object. The warranties defined on the service object will be used on the request scopes created for the object when the scope is created within the warranty validity period.
This tab can be used to enter and view information on the various party types that are connected to the Service Object. Party is a concept used to summarize all types of stakeholders with which the object has a business relation, for example a supplier or a customer. A Primary party record can be defined for each Party Type. The Customer is used to control whether a Request or a Request Contract can be created for the Customer.
The Service Notes are free-text comments that can be used to capture information relevant to the Service Object, for example who to contact to access a certain piece of equipment. The notes will also be visible on Requests and Work Tasks associated with the Service Object, by enabling Show Associated Notes in the respective Service Notes tabs. More information about Service Notes.
Some object information e.g. test points are used for updating measurements. Enter different test points on objects, to capture measurements on Work Tasks in the execution process, or though other means such as IoT. These test points do not necessarily need to be visible parts of an object, e.g., bearings for a pump, or a welding on a tank.
The parameter represents an object's condition such as Temperature, Quantity produced or Operation hours, Oil level, Pressure, etc. The parameter can measure one of two types of values; Accumulated or Limit values. An Accumulated parameter can for example measure operation time or produced quantity. A Limit parameter can be used to measure temperature, oil level, pressure, water flow, etc.
The Test points and Parameters added on a model will be instantiated on the service object when the object - model connection is established without apart. When a part - object connection is established, the Test points and Parameters will be instantiated from the part.
Recurring Service Programs and scopes that have been defined for the specific Service Object.
The Service Record lists all the Work Tasks created for the Service Object, along with the current Request and Work Task status.
The Costs tab lists all costs reported against service work tasks done for the Service Object, split by Cost Type such as Material, Personnel etc.
The Contracts tab lists all the Request Contract Lines that are related to the specific Service Object, regardless of contract status.
A manufacturer normally defines a set of recommended spare parts/material that are needed to repair or maintain a specific model/object, along with required quantities. The spares list allows a user to add this recommended list to the application on the Service Object. And the Spares can be Parts registered in the system or No-parts that are not registered in the system. The spares can also be defined on a model and these spares will be inherited to the service objects when the model connection is established.
A summary view of the total number of each part that has been used in services for the selected object, during a selected time frame.
It is possible to define the availability for a Service Object. There are two types of Availability that can be defined. Only one option can be used at a time.
It is possible to define preferred or unpreferred scheduling resources for a Service Object, using preferences.
Allows the user to see a log of significant actions performed on the Service Object since it was created e.g. In Operation and Out of Operation or a move to a new structure or site.