Definitions, acronyms, and abbreviations
Service Type
Service types are used to predefine the sequence in which activities must be carried out and to determine the cost amount according to a certain type of service. Service types are linked to service procedures. Which service procedure is applied to each service order, service call, contract or maintenance activity is determined by the service type.
Service Execution Assignment
The service execution assignment is the allocation of a service order activity to 1 or more service engineers. Each activity of the service order should have at least 1 service execution assignment before the order can be released. In other words, at least 1 engineer is kept responsible for the execution of the service order activity.
Not only work can be distributed and assigned on a very specific level (service order activity level) but also actual progress of that service execution assignment can be measured. Actual progress is measured on service execution assignment level, which will affect the progress on service order activity level, which will affect the progress on service order header level.
Service Engineer
The Service Engineer is the skilled person who really executes the service. The service order engineer must be able to download the assigned service order activities in ESR. When he has made progress, ESR should offer him the possibility to do that. When the engineer is at the customer site, he also must be able to create more service order activities, which he will execute immediately. This means that actual progress will be transferred to ERP from the previous assigned service order activities, but also from the service order activity (ies) he created himself.
Service Order Header Engineer
The service order header engineer is the person who is responsible for the service order to eb executed. The Service Order Header Engineer is the person who is responsible for the service order to be executed at the customer site. It is the defaulted execution engineer. In case a service order is used in a project environment, quite often there is 1 person who is responsible. He has the role of responsible engineer and contact person, which means he is not involved in the real execution of the work. To support this situation, the responsible engineer can be filled in on the service order header, and all the service order activities can be assigned to other engineers. This is called a multi-Engineer scenario. If the responsible engineer also does a part of the work, it means that some of the activities are also assigned to him.
Planner
The Planner is the person who schedules service orders and/or service order activities. The planner must have insight in the work the service order engineers are doing. This means that actual progress must be visible in BSS. By means of using a filter, the actual times per service order header or activity per engineer can be compared with the planned times of the service order header or activity. Comparing these views makes it possible to compare if the delay is too much, and if corrective actions are required to make a better schedule for the coming, future period.
Term |
Description |
BSS |
Baan Service Scheduler |
ERP |
Enterprise Resource Planning |
ESR |
E- Service Remote |
SOA |
Service Order Activity |
SOC |
Service Order Control module |
SOH |
Service Order Header |
|
|
1.3 References
Basic knowledge of the service business procedure and the understanding of the working of Baan applications are expected.
1.4 Overview
Chapter 2 discusses the process model. The processes regarding the new functionality are explained.
Chapter 3 is about the user interface.
2 Process Model |
2.1 Process Flow Diagrams
2.2 Process Descriptions
As explained already partially, it is required to introduce the service execution assignment concept. This means that not only work can be distributed and assigned on a very specific level (service order activity level) but also actual progress of that service execution assignment can be measured. The definition of a service execution assignment is as follows:
Definition Service Execution Assignment:
The Service Execution Assignment is the allocation of a Service Order Activity to 1 or more Service Engineers. Each Activity of the Service Order should have at least 1 Service Execution Assignment before the Order can be released. In other words, at least 1 Engineer is kept responsible for the execution of the Service Order Activity. Actual progress is measured on Service Execution Assignment level, which fill affect the progress on Service Order Activity level, which will affect the progress on Service Order Header level.
This means that a service engineer, working in the field, can synchronize with the ERP-backbone and report the actual progress.
Next to the existing session “Service Order Engineers”, a new session “Service Execution Assignments” (tssoc2106s000) has been created in order to manage the service execution assignments per engineer. Actual times per engineer per service order activity must be stored there. ERP will not link functionality and behavior to this new table (example: when not all service execution assignments are set to completed yet, still making the activity completed is possible).
2.2.1 Filling Service Engineer on the Service Order Header
It is not realistic that a service order will be executed fully by 1 engineer. If that is the case, it is called single-Engineer scenario. This engineer can be called the ‘Execution Engineer’ because he is doing the full execution of the service order. On service type level it is possible to indicate which role the engineer on the service order header should have by tagging the checkbox of “Generate Default Assignment for Service Engineer”.
If the service engineer is filled on the service order header, then based on the service type, service execution assignments for each linked activity will be created for this engineer. A 0-line will be made for that engineer in session “Service Engineers”.
Note: this has been implemented in both the Plan by Order situation and the Plan by Activity situation.
If more engineers are working on that order, it is called a multi-Engineer scenario. This means that more engineers are working on the activities of the service order. In these situations, it is logical to appoint 1 engineer, who is kept responsible for the whole execution of the order. This responsible engineer can be filled in on the service order header. For that engineer, it is assumed that no work will be done by him. If that header engineer also participates in the execution, then service execution assignments must be created for him manually.
In case a service order is used in a project environment, quite often there is 1 person who is responsible. He has the role of responsible engineer (foreman) and contact person, which means he is not involved in the real execution of the work. To support this situation, the responsible engineer can be filled in on the service order header, and all the service order activities can be assigned to other engineers. This is called a multi-engineer scenario.
If the responsible engineer also does a part of the work, it means that some of the activities are also assigned to him. Only in a manual way, it is possible to create service execution assignments for the responsible engineer. In that case, he is not only having the role of a responsible engineer anymore, but he has become an execution engineer as well.
If the service order engineer is made empty on the service order header, which is possible as long as the service order is not released (and the “Reschedule with Detail SRP” button is tagged for a planned service order), the service execution assignments, which have been made, will be removed for that engineer. If service execution assignments were already assigned to another employee as a manual action in the tssoc206 table (to support the Multi-Engineer Scenario), these service execution assignmentswillnot be removed when the header engineer is removed. The 0-line will be removed for that engineer in session “Service Engineers”
If the service engineer is filled in again, then for all activities present, service execution assignments will be created again for that header engineer (based on the service type of the activity). The service execution assignments, which were already present for another engineer (engineer B), will remain. Example: when 5 activities are present, and 2 of them were already defined for engineer B, and the header engineer A is filled in again è 7 service execution assignments will be present after this action: 5 for engineer A and 2 for engineer B. A 0-line will be made for that engineer in session “Service Engineers”
Note: It is possible to update the service order header engineer (changed functionality). This means that the behavior of Plan by Activity situation will be equal to the Plan by Order situation, mainly because the Plan by Activity concept exactly fits within the functionality of working with a responsible engineer and execution engineers.
2.2.2 Assign Service Engineers to Service Orders via “Service Engineers”
If a service engineer is assigned to a specific activity, then this engineer will be displayed on that service order activity and a service execution assignment for the activity will be created for the engineer.
If a second engineer is filled in for the same activity to support a Multi Engineer scenario, also for this engineer a service execution assignment for that activity will be created.
Only 1 engineer can be displayed per activity, which means that the first engineer, linked to the activity via “Service Engineers”, is displayed.
If a second engineer is linked to a service order with a 0-line, via “Service Engineers”, then this means that these 2 engineers are kept responsible for the service order.
On the service order header still the first engineer is filled. If no engineer was defined yet on the service order header, still nothing is done, because filling the header engineer via “Service Engineers” is not allowed.
No service execution assignments for each activity will be created for that second header engineer, only for the first header engineer service execution assignments must be created automatically.
2.2.3 Update Service Execution Assignments via “Service Execution Assignments”
Making a service execution assignment for a service order header is not allowed.
When assigning an engineer to an activity, then the engineer will be displayed for that service order activity in case it is the first engineer. In session “Service Engineers”, the engineer is added for that activity. It is not possible that there was already a link defined in this session between that same engineer and the activity, because in that case such a service execution assignment should already exists.
When assigning a second engineer for an activity, to which already an engineer was assigned, then in session “Service Engineers”, the engineer is added for that activity. It is not possible that there was already a link defined in this session between that same engineer and the activity, because in that case such a service execution assignment should already exists.
Note: It is not possible to assign the same engineer to the same activity twice, like to say that engineer will do ‘painting’ as activity 10 from 10.00 till 11.00 and from 14.00 till 15.00.
Supporting this scenario goes to far for the current moment, because it would mean that an extra view in BSS is required. Workaround is to create a second activity, to which that engineer can be assigned
Progress can be booked also when the activity is completed: a service execution assignment for the activity is created for an engineer. In session “Service Engineers”, the engineer is added for that activity.
This is only possible when no ESR is used.
Note: An addition of service execution assignment for an engineer is not allowed when the service order is completed, because the status of the order is too far already.
When removing a service execution assignment, made for an engineer, then the link between the engineer and the activity defined in “Service Engineers” will be removed. If more engineers were linked to the same activity, it will result in a display of another engineer for the activity. If the engineer is the only engineer for that activity, the engineer display will be removed
2.2.4 Release Service Order
Releasing a service order is only allowed if for each activity at least 1 service execution assignment has been defined in the table “Service Execution Assignments”.
If a service execution assignment is not defined yet, during the release process, service execution assignments will be created for the order header engineer. The order header engineer must be filled to get the order released.
2.2.5 Complete Service Order
The “Service Execution Assignments” session will not only be used by the ESR application, but also the ERP-application itself can make use of the session.
If ESR is used, then progress per service order header is done by marking the job sheet as being completed, which means that if all job sheet completion times have been filled in, the service order can be set as completed.
Only when the downloaded time is filled for all service execution assignments, then via ESR the order header may be completed. Making the header completed in a manual action (pressing the button Completed) is always possible in ERP.
When all service order activities got status completed, then a question is asked to make the Service order header completed. When all service execution assignments for a service order activity have got actual times, then the latest execution finish time must become the actual finish time of the service order activity if that field is empty. If this actual finish time on the service order activity is already filled, then an update is not required. This means that the trigger goes from the bottom to the top. The same concept is applied in the relation between service order activities and service execution assignments: when the last service execution assignment is completed, then the activity will get status completed.
The opposite is also possible: when the service order header is made completed, it means that automatically the service order activities are made complete. The same is applied to the service execution assignments: when the service order activity is made complete, then all the service execution assignments will be filled. The actual times are filled by the engineer, but if the service order or the service order activity has been set to complete in ERP, then the actual times of the service order activity will be transferred to the related service execution assignments if the actual times of the service execution assignments are empty. If actual times of the service order activity are not filled, then the service execution assignments will not be updated. When these times are filled in at a later moment, then still a top-down update is required, so the service execution assignments having no times filled in, will be filled in then. This is a top-down approach.
2.2.6 Post Service Order to History
When a service order is closed and posted to history, the data of the service execution assignments will be posted to history as well. This history data is stored in “History Service Execution Assignments” (tssoc8553m000).
2.3 Process Design Considerations
2.3.1 Synchronization issues
Due to the limitation that the session “Service Order Engineers” (tssoc2105m000) must remain (migration issues), it means that synchronizing will take place between this ‘old’ session and the new session “Service Execution Assignments” (tssoc2106s000). When for example a 0-line is inserted in the “Service Order Engineers” session, it can have impact for the service execution assignments (in case it is the execution engineer). Also when an engineer is linked to an activity in the “Service Order Engineers” session, it also will update the assignments in “Service Execution Assignments” session.
3 User Interface |
3.1 SynchronizationESR2.1 – ERP – BSS 2.1
3.1.1 Functional description
In the integration of E-Service Remote 2.1 and ERP, the new table “Service Execution Assignments has got an essential role. Here, it will be made clear how the integration looks like and how synchronization takes place.
Statement: the ERP system is regarded as the leading environment.
Example 1: Engineer has downloaded his service execution assignment in ESR and a change in the planned dates takes place
A service execution assignment has been created for engineer A. The planned start time is 25-4-2002 from 10.00 till 12.00. The activity and this service execution assignment have been released, which made it possible for engineer A to download that service execution assignment. This first download took place at 24-4-2002 at 17.00. The downloaded time is filled in for that service execution assignment.
Early in the morning of 25-4-2002, the customer tells that the service execution assignment can’t be executed and that the planned execution time will become on 28-4-2002. When the planner fills in these new planned times on the service order activity, he must be able to manage and keep in control what happens with the service execution assignments. When the change is effective, this time (25-4-2002 at 9.00:00) is filled in as ‘last changed time’. When the planner sees that the downloaded time of the service execution assignment is still not after the ‘latest update planned time’, he can conclude that engineer A still has ‘wrong values’ on his own database.
Example 2: Re-service execution assignment is done between Field Service Engineers
When a service execution assignment (line nr. 10) is done to engineer A, then the following options are possible:
– downloaded time is not filled in => then the planner can create a new service execution assignment (line 20) and assign that to engineer B. Because the downloaded time is not filled in yet, deleting service execution assignment 10 is allowed. (Deleting is not allowed when for that activity no service execution assignment is present; at least 1 service execution assignment must be present for a released activity)
– downloaded time is filled in => when the downloaded time is filled in, then deleting the service execution assignment (and therefore re-assigning) in ERP is not allowed anymore. The planner must be able to fill in the execution start time & execution finish time and the job sheet completion time to be sure that an engineer will not execute that service execution assignment. When the planner has filled in these actual times, and the engineer downloads that activity again, he can recognize that no execution is required anymore, because actual times are filled in already.
A planner can do re-service execution assignment in this situation by making a new service execution assignment for another engineer.
Example 3: Updating times in ERP
When a planner fills in actual times on the service order activity, and no actual times are filled in yet for the service execution assignments, then the missing actual finish times can be filled in on service execution assignment level when the service order activity status is Completed.
When an engineer makes on a later moment (so actual times are already filled in at ERP) an update via ESR, then the actual times will be updated in the ERP environment. When the execution finish time of the service execution assignment falls after (is later) the actual finish time of the service order activity, then the time on the service order activity will be updated.
Changing the times on the service order activity again, will not change any actual time on the service execution assignment level (if they were filled in already).
3.1.2 E-Service Remote
In the ESR application, it is possible for the engineer to download assigned service order activities. Also creating a new service execution assignment (service order activity) is possible. Booking actual progress per service execution assignment is required; after having entered the actual times, these times must be synchronized (uploaded) to the ERP backbone.
If also a responsible engineer is involved in the service order execution, it means that he is able to register activities (or even the service order) as Complete.
3.1.3 ERP
In the ERP environment ( iBaan ERP 5.0c release), a separate session has been made to visualize the actual progress. Due to migration issues it was not possible to add the actual progress times in the Service Order Engineer session.
This means that synchronization is required between this new session (Service Execution Assignments) and the Service Order Engineer session. In a next iBaan ERP version, all these data will be stored in a central session.
3.1.4 Integration E-Service Remote and ERP
In ERP, it will be recognized if the ESR application is used. The main reason for this is, that the new functionality is also available for ERP- usage when ESR does not use it. When ESR is implemented, and some of the service orders will be made actual with the ESR application, it is required to recognize that by checking if the downloaded time is filled. If for 1 service execution assignment of the service order a downloaded time is filled in, it is assumed that ESR will make the order complete.
When the downloaded time is filled, which means that ESR is used, then an activity is assigned, un-allocation of that service execution assignment is not allowed anymore. If an ESR engineer becomes ill, it means that a planner should manually fill in the other service execution assignment times (accepted time or rejection time if assignment was not accepted yet, execution start time, execution finish time) and should create a new service execution assignment.
Of course ESR is also able to fill the accepted time, the service execution assignment start, service execution assignment finish & job sheet completion time, but these times can also be filled in at ERP side (or BSS). Only ESR uses the downloaded time and the downloaded time can’t be filled by ERP or BSS. Only when the downloaded time is filled for all service execution assignments, then via ESR the order header may be completed. Making the header completed in a manual action (pressing the button Completed) is always possible in ERP. The ERP environment will regard the whole order as being treated by ESR as soon as 1 of the service execution assignments has got a downloaded time filled. This means that this is not done per activity.
3.1.5 Baan Service Scheduler
In BSS, it is possible to see the actual progress per service execution assignment. The actual progress is made visible per service order activity. If more engineers are working on the same activity, 2 or more bars, representing the same activity, are visible behind the engineer line. By means of tool-tips, the actual progress of that engineer becomes visible.
3.2 Changes in ERP
3.2.1 Service Types (tsmdm0130m000)
On the form of this session, the parameter “Generate Default Assignment for Header Engineer” (checkbox) is placed.
Generating service execution assignments automatically is based on Service Types, because the type of work (activity) determines if 1 or more assignments are required for the execution. In order to support the situation above and the responsible/execution engineer concept, a new field “Generate Default Assignment for Header Engineer” is introduced in this session. This parameter is an indicator in order to define if a service order activity is to be executed by the engineer which is filled in on the service order header or that more engineers are required for the execution.
If the parameter is set to “Yes”, it indicates that if a service engineer is filled on a service order then assignments are created automatically for all activities on which a service type is defined on which this parameter is set to “Yes”. Also, if a service activity is created then assignments are created automatically if on the activity a service type is defined on which this parameter is set to “Yes”.
If the parameter is set to “No”, it indicates that in fact more engineers are required for the execution and later on in the process a planner decides who will execute the work.
The default value of the checkbox “Generate Default Assignment for Header Engineer” is set to “Yes” in order to support the original functionality.
The flag is set on service type level instead of order level to prevent migration issue for the customers, already working with the iBaanERP5.0c Service module. Reconfiguring “Service types” won’t take as much effort as reconfige “Service orders”.
3.2.2 Service Order Activities (tssoc2110s000)
On the first form, the parameter “Generate Def. Assignment for Header Engineer” is displayed on the right side of the field “Service Type” so that the planner is triggered if service execution assignments are automatically created or not.
3.2.3 Service Execution Assignments (tssoc2506m000)
In this new session, an overview of the Service execution assignments by order is displayed. Data like employee, downloaded time, accepted time and job completion time are shown by service order. By double clicking a service execution assignment line, the detail session “Service execution assignments” (tssoc2106s000) will be started.
It is possible to start this session via session “Service Order” (tssoc2500m000), session “Service Order Activities” (tssoc2510m000), and via menu “Processing”(mtssoc3003m000).
3.2.4 Service Execution Assignment List (tssoc2507m000)
In this new session, an overview of the Service execution assignments is displayed. Data like employee, downloaded time, accepted time and job completion time are shown by service order.
It is possible to start this session via session “Service Order” (tssoc2500m000) and via menu “Processing”(mtssoc3003m000).
3.2.5 Service Execution Assignments (tssoc2106s000)
In this new session, the Service Execution Assignments control is being managed. Actual times per engineer per service order activity must be stored there.
3.2.6 History Service Execution Assignments (tssoc8553m000)
A new overview session has been created in order to display the history data of service execution assignments.
It is possible to start this session via session “History Service-Orders Header” (tssoc8551m000) or via menu “History” (mtssoc3008m000).
3.2.7 History Service Execution Assignments (tssoc8553s000)
A new detail session has been created in order to display the history data of service execution assignments.
This session can be started via session “History Service Execution Assignments” (tssoc8553m000).