The Equipment Last & Next PPM Dates
These two values, along with last repair date, are problematic since they can be either deduced from the
service history (in e-Quip the service history extends into the future as well as the past) or manually
entered on the equipment property page. The challenge is to know when to do which, and how to
resolve conflicts between the two.
This situation arises because one of the basic principles of database design has been broken (to
paraphrase Codd’s Third Normal Form: “1 fact – 1 place”), but why is this necessary? Ideally,
maintenance dates should always be calculated from the service history: the last PPM date is the date of
the most recently completed PPM job and the next PPM date is the soonest of all non-started PPM jobs
for the device. The service history also provides evidence that the work has either been done or is
planned. The reasons for the de-normalisation are:


Not all e-Quip users create jobs to record work done for all devices.
Not all users make use of e-Quip’s PPM scheduling mechanism to pre-emptively create jobs for
future planned maintenance.
A common example of the first scenario is where a large number of relatively simple devices are
serviced by an external contractor on an annual basis. Suppose for example that a contractor visits to
carry out an annual PPM on 500 or more suction controllers. Best practice would dictate that a PPM job
is created for each device serviced, but this is by no mean universal practice. Many users will simply
update the appropriate equipment records and enter the visit date into the last PPM date field. On the
assumption that these devices are maintained on an annual basis, these users might also calculate the
next PPM date (i.e. the visit date + 12 months) and write this to the equipment record as well. Clearly
this is not best practice, as no history or evidence is recorded, but this approach is by no means
uncommon.
The most common example of the second scenario is when either model-based or non-pre-emptive
auto-scheduling is used (see the section “How PPM Scheduling Affects Maintenance Dates”). For largely
historical reasons there are many users who are not comfortable with the concept of creating PPM jobs
a year or more before they are due; they want the PPM scheduling to tell them when maintenance is
due, but they want to create the jobs themselves. In both of these cases, the service history is used to
find the last PPM date, but not the next PPM date, which is written to the equipment record.
Before continuing, one semantic point should be cleared up: the next PPM date for a device indicates
when you next plan to service a device - it does not indicate when a device is due for maintenance. The
difference between the two is worth pointing out. The date that a device is due for maintenance is a
function of its last PPM date and its maintenance frequency. If an asset was last serviced on date X and
has a maintenance frequency of 6 months, then its PPM due date will be Y, where Y = X + 6 months. You
might plan to service this particular device on date Z, but Y & Z are not necessarily equal. A PPM plan
should aim to ensure that Z ≤ Y.
A similar situation arises when devices are either not found or not made available for PPM. Many
hospitals operate a strategy whereby the engineers will try to service a device on its next PPM date, but
if the device cannot be found after a reasonable time they will abandon the search (generally after
notifying the device owner). The outstanding PPM job will be closed with a status of Missed PPM, which
will have the effect of scheduling the next job. (This process is explained in greater detail in the section
“How PPM Scheduling Affects Maintenance Dates”). Semantically this means that the device is overdue
maintenance but the engineering staff do not plan to search for it until the planned date of its next
service. This strategy prevents users from being deluged with warnings about overdue PPM’s for devices
that they have little chance of finding. In hospitals which work this way it is relatively common to find
that if a device misses its PPM for a number of consecutive years then the device is removed from the
PPM schedules. This can result in a situation in which a device was last serviced 2 years previously but its
next PPM date is 1 year in the future.
Note: Throughout this document the following convention is used to label dates:
𝐷′
𝐷 ′′
𝐷′𝑒
𝐷 ′′ 𝑒
𝐷′𝑤
𝐷 ′′ 𝑤
The last PPM date for a device
The next PPM date for a device
The value in the LastPPMDate field in the equipment record. This may be
manually entered by users.
The value in the NextPPMDateDue field in the equipment record. This may either
be manually entered by users or may be set by the system as part of the PPM
scheduling process.
The latest value of the WorkEndDate field for all completed PPM jobs for a device
The earliest value of PlannedDate field for all non-started PPM jobs for a device
The last and next PPM dates are calculated on several occasions:



When displaying the equipment property page technical tab;
When displaying the equipment summary screen;
Whenever a PPM job is completed.
This document explains the various ways in which these dates are calculated.
Last PPM Date
Using the notation given in the introduction, the last PPM date 𝐷 ′ for a device is given by:
𝐷 ′ = 𝑀𝑎𝑥(𝐷 ′ 𝑒 |𝐷 ′ 𝑤 )
Where
𝐷 ′ 𝑒 = the value of the LastPPMDate field from the equipment record, and
𝐷 ′ 𝑤 = the value of the WorkEndDate field of the most-recently completed PPM job for this
device
When displaying the equipment property page 𝐷 ′ 𝑤 is calculated by analysis of the service history as
shown below.
dbo.MaximumOF
(
--- 𝐷 ′ 𝑒 The manually entered last PPM date
LastPPMDate,
(
--- 𝐷 ′ 𝑤 The completion date of the most-recently completed PPM job
SELECT MAX(WorkEndDate)
FROM Job
WHERE Inactive, 0 != 1 AND
EquipmentId = Equipment.EquipmentId AND
JobTypeClassId = 'PPM' AND
JobStatusClassId IN ( 'FINISHED', 'CLOSED' ) AND
WorkEndDate IS NOT NULL
)
)
This approach is not practical when displaying the equipment summary grid because it is displaying
multiple devices and it would be very expensive in terms of database processing to analyse the service
history for each device in the grid. Instead, the value of 𝐷 ′ 𝑤 is cached in the equipment record in a field
named LastPPMJobDate. We will see later how this cached value is kept up to date. Assuming that the
cache is up-to-date then the statement below is functionally equivalent to the statement above:
dbo.MaximumOF
(
--- 𝐷 ′ 𝑒 The manually entered last PPM date
LastPPMDate,
---
𝐷 ′ 𝑤 The completion date of the most-recently completed PPM job
LastPPMJobDate
)
Given that the user can manually enter a last PPM date 𝐷 ′ 𝑒 on the equipment property page, what
should be done if the user enters a value which conflicts with the evidence of the service history; i.e.
when 𝐷 ′ 𝑒 and 𝐷 ′ 𝑤 are logically inconsistent? For example, iIf 𝐷 ′ 𝑤 > 𝐷 ′ 𝑒 then a PPM job has been
completed more recently than the date entered by the user which renders 𝐷 ′ 𝑒 invalid. This is discussed
in the section “Resolving Maintenance Date Conflicts”.
Last PPM Dates Set by the System
Later we will see how and when the PPM scheduling mechanism calculates 𝐷 ′ in different situations.
There is however, one occasion when both 𝐷 ′ and 𝐷 ′′ are updated which is not, from a technical
perspective, part of the PPM post-processing.
Consider the following sequence.
1. The user opens an equipment property page and clicks Unlock.
2. On the service history tab the user double-clicks on a non-started PPM job and completes that
job.
3. The user saves the equipment record
In step 2, as soon as the user clicks Save & Close on job property page the job will be saved and, as we
will see later, the normal PPM post-processing will occur which will modify the maintenance dates. A
message will be displayed similar to “The following values on the technical tab have changed as a result
of saving this job [Last PPM Date, Next PPM Date]” then, these new values will be written to the
technical tab.
Now suppose that a new step, 2a, is added between steps 2 & 3:
2a. On the technical tab, the user updates the battery replacement date.
This new step has a material effect on the processing. If the only changes to the technical tab were
made by e-Quip itself then the system would know that there would be no need to save this tab to the
database; the changes were made when the PPM job was closed and the database has already been
updated. However, by modifying the battery replacement date field the user has now forced the system
to save the data on the technical tab, and this will include the newly-calculated maintenance dates. The
system has no way of knowing whether the dates that it is being asked to save were manually entered
by the user or set automatically by the system; possibly they may not even have changed at all (this
would happen if step 2 was omitted).
In later sections we will discuss the way in which the PPM post-processing uses a database procedure
named “qUpdateEquipmentMaintenanceDates” to process manually-entered maintenance dates, but
the scenario just described illustrates how parts of the PPM post-processing must be coordinated with
equipment edits.
Incidentally, this situation applies not only to the last PPM date, but also to the next PPM date and the
last repair date.
Next PPM Date
This is far more complex than the case of the last PPM date, since:


It can be calculated in a number of different ways
The system itself can write next PPM date values to the equipment which may become invalid
when other jobs are subsequently edited.
Again using the notation given in the introduction, the next PPM date 𝐷 ′′ for a device is given by:
𝐷 ′′ = 𝑀𝑖𝑛(𝐷 ′′ 𝑒 |𝐷 ′′ 𝑤 )
Where
𝐷 ′′ 𝑒 = the value in the NextPPMDateDue field in the equipment record
𝐷 ′′ 𝑤 = the earliest PlannedDate field for all non-started PPM jobs for this device
As with 𝐷 ′ , for performance reasons the implementation of 𝐷 ′′ 𝑤 varies depending on whether the
equipment summary screen or property page is being displayed. 𝐷 ′′ 𝑤 is calculated from the service
history for the property page but a cached value is used for the grid.
For the equipment property page the Next PPM Date 𝐷 ′′ is calculated as follows:
dbo.MinimumOF
(
--- 𝐷 ′′ 𝑒 The manually entered next PPM date
Equipment.NextPPMDueDate,
(
--- 𝐷 ′′ 𝑤 The planned date of the earliest outstanding PPM job
SELECT MIN(PlannedDate)
FROM Job INNER JOIN JobStatus
WHERE ISNULL(Job.Inactive, 0) != 1 AND
Job.EquipmentId = Equipment.EquipmentId AND
JobTypeClassId = 'PPM' AND
JobStatusClassId NOT IN ( 'FINISHED', 'CLOSED', 'MISSEDPPM'
)AND
PlannedDate IS NOT NULL
)
)
For the equipment summary screen the calculation is as shown below:
dbo.MinimumOF
(
--- 𝐷 ′′ 𝑒 The manually entered next PPM date
NextPPMDueDate,
--- 𝐷 ′′ 𝑤 The planned date of the earliest outstanding PPM job
NextPPMJobDate
)
The validation which is required to detect when 𝐷 ′′ 𝑒 and 𝐷 ′′ 𝑤 are logically inconsistent is similar to the
logic for 𝐷 ′.
Resolving Maintenance Date Conflicts
We have seen how the equipment record last and next PPM date fields 𝐷 ′ 𝑒 and 𝐷 ′′ 𝑒 can be manually
entered by users, and we will see later that 𝐷 ′′ 𝑒 can also be set by the system as part of certain types of
PPM scheduling. We have also seen how 𝐷 ′ 𝑤 and 𝐷 ′′ 𝑤 can be derived from the service history of a
device, and how e-Quip compares all of these values in order to display 𝐷 ′ and 𝐷 ′′. Inevitably situations
will arise where the dates stored in the equipment record 𝐷 ′ 𝑒 and 𝐷 ′′ 𝑒 will conflict with those found
from the service history, 𝐷 ′ 𝑤 and 𝐷 ′′ 𝑤 . If the maintenance dates are to be displayed correctly and
consistently then any such conflicts must be resolved.
This is done by the procedure “qUpdateEquipmentMaintenanceDates”, which is invoked whenever an
event occurs which may invalidate either 𝐷 ′ 𝑒 or 𝐷 ′′ 𝑒 . Note that the paragraphs below only discuss the
role of this procedure as it affects PPM dates – it does perform other actions as well, such as
maintaining last repair and repair warranty dates. It is also this procedure which is responsible for
updating the cached values of 𝐷 ′ 𝑤 and 𝐷 ′′ 𝑤 , which are used to optimise grid performance.
Note that this procedure never sets maintenance dates; it only removes dates which are invalid. The
actions of this procedure are as follows:
1. If this device is maintained using pre-emptive auto-scheduling (see the section “How PPM Scheduling
Affects Maintenance Dates”) then e-Quip assumes complete responsibility for maintaining both 𝐷 ′ and
𝐷 ′′. When this type of scheduling is in use the maintenance dates are always taken from the service
history, which means that any PPM dates stored in the equipment record, 𝐷 ′ 𝑒 and 𝐷 ′′ 𝑒 , are redundant
and can be deleted. No further action need be taken.
What are the criteria used to decide whether or not a device is being maintained under such a schedule?
It is not enough to assume that if the equipment is linked to a schedule then that schedule is in current
use. Neither is it sufficient to check if a PPM job for a pre-emptive schedule exists in the service history.
It may be that in the past the device was maintained under the schedule but is now maintained some
other way.
The deciding factor is whether or not a non-started, scheduled PPM job exists for this device. If
this is the case then the device is assumed to be under the control of the automatic PPM
scheduling mechanism. In this context, a scheduled job means a job where the PPM schedule
field is not blank.
If this is not the case then processing continues as follows:
2. The last PPM date 𝐷 ′ 𝑒 is read from the equipment record. This may be empty, may have been
manually entered or may have been written by the system as part of some previous PPM postprocessing.
3. The next PPM date 𝐷 ′′ 𝑒 is read from the equipment record. Again, this may be empty, may have been
manually entered or may have been written by the system as part of some previous PPM postprocessing.
4. The device service history is analysed to find 𝐷 ′ 𝑤 , i.e. the completion date of the most recently
completed PPM job
5. The device service history is analysed to find 𝐷 ′′ 𝑤 , the planned date of the earliest, non-started PPM
job.
5. These values are then compared.
If 𝐷 ′ 𝑤 > 𝐷 ′ 𝑒 then 𝐷 ′ 𝑒 ∷= ∅
That is, if the completion date of the most recently completed PPM job in the service history is later
than the last PPM date in the equipment record, then the equipment record value is invalid and will be
set to NULL. Otherwise it is left unchanged.
If 𝐷 ′′ 𝑤 < 𝐷 ′′ 𝑒 then 𝐷′′ 𝑒 ∷= ∅
That is, if the planned date of the soonest non-started PPM job in the service history is earlier than the
next PPM date in the equipment record, then the equipment record value is invalid and will be set to
NULL. Otherwise it is left unchanged.
On completion of this processing the maintenance dates will be logically consistent, although they may
not necessarily be correct; remember that whenever a user enters data manually there is always scope
for error.
How PPM Scheduling Affects Maintenance Dates
In e-Quip the purpose of PPM scheduling is to calculate when maintenance should next be planned for a
device; it is concerned with the next PPM date and will never have any effect on the last PPM date.
Scheduling is normally automatic and occurs whenever planned maintenance work is completed (i.e.
when a job which has a job type class of PPM is set to a status which has a class of Finished or Missed
PPM).
We have seen already that the next PPM Date 𝐷 ′′ for a device is given by:
𝐷 ′′ = 𝑀𝑖𝑛(𝐷 ′′ 𝑒 |𝐷 ′′ 𝑤 )
Where:
𝐷 ′′ 𝑒 = the value in the NextPPMDateDue field in the equipment record
𝐷 ′′ 𝑤 = the earliest PlannedDate field for all non-started PPM jobs for this device
The different scheduling methods implemented by e-Quip make use of either 𝐷 ′′ 𝑒 or 𝐷 ′′ 𝑤 in order to
maintain 𝐷 ′′ . The following paragraphs discuss the types of scheduling that are supported by e-Quip and
explains how 𝐷 ′′ is maintained.
a. Manual Scheduling: In manual scheduling e-Quip takes no part in the decision-making or job creation
process; the user assumes complete responsibility for calculating and maintaining the PPM planning
dates. Even if the user manually edits the maintenance dates and/or manually creates PPM jobs, e-Quip
will still calculate 𝐷 ′ and 𝐷 ′′ the same way. i.e.
𝐷 ′ = 𝑀𝑎𝑥(𝐷 ′ 𝑒 |𝐷 ′ 𝑤 )
𝐷 ′′ = 𝑀𝑖𝑛(𝐷 ′′ 𝑒 |𝐷 ′′ 𝑤 )
The only difference is that the user is controlling the values of 𝐷 ′ 𝑒 , 𝐷 ′ 𝑤 , 𝐷 ′′ 𝑒 and 𝐷 ′′ 𝑤 .
Wholly manual scheduling, where no PPM jobs are ever created and the equipment last and next PPM
date fields are the only record of work done and work planned, is not recommended. In the case of the
last PPM date this approach offers no evidence that the work has been done. Furthermore, only the
most recent PPM can be recorded, in the absence of jobs no history is maintained. Furthermore, there is
only one editable next PPM date field and so this approach is difficult and error-prone for devices on
multiple schedules. As those schedules are by definition external to e-Quip, it is impossible for e-Quip to
do anything but the most rudimentary validation.
b. Batch Scheduling: This is a special case of manual scheduling and occurs when managers adopt a
batch approach to PPM scheduling. This was very common practice in the past and its use is probably
still widespread. A manager may set an equipment filter to find all active devices in a particular location
and may then use the Create Job for Selected Items utility to create PPM jobs for all of those devices, all
planned for a particular period. The manager will probably maintain a schedule of which locations are to
be visited each month, and may repeat this process monthly.
Once the jobs have been created and before they have been completed the system will correctly use
𝐷 ′′ 𝑤 to display the next PPM date. Once the jobs are completed then 𝐷 ′ 𝑤 can be used to display the
last PPM date, but from then on the next PPM date will be undefined. i.e. no planned maintenance date
exists because the manager’s plans are external to e-Quip.
c. Contract-Based Scheduling: This is another special case of manual scheduling. If devices are
maintained by a 3rd party under a contract, it is common to arrange the dates of the contract visits in
advance with the supplier. A utility is available from the contract summary screen named Create
Contract Visit Jobs. This utility allows you to enter a visit date, work instructions, job type & job status,
and then creates a future job for each active device covered by the contract.
From the point of view of 𝐷 ′ and 𝐷 ′′ this is identical to batch scheduling. The only difference is that the
jobs are created with the Create Contract Visit Jobs utility rather than Create Job for Selected Items. This
approach has the same limitation as batch scheduling, in that once this year’s jobs are completed then
the next PPM date 𝐷 ′′ will be undefined until the contract is renewed.
d. Model-Based Scheduling: If a default service interval has been recorded for a model, then when a
PPM job is completed e-Quip will add this interval onto the completion date of the job to determine the
next PPM date. This value will then be written to the equipment record and hence becomes 𝐷 ′′ 𝑒 . (Note
that this is only done if the device is not linked to a PPM schedule. Schedules take precedence over
model-based scheduling). This is an example of a situation where 𝐷 ′′ 𝑒 is entered by the system rather
than the user.
In this case the service history is used to maintain 𝐷 ′ while 𝐷 ′′ 𝑒 is used to maintain 𝐷 ′′ .
e. Auto-Scheduling: There are two main variations of this approach: pre-emptive and non-pre-emptive
auto-scheduling. Pre-emptive auto-scheduling actually creates future PPM jobs while non-pre-emptive
auto-scheduling does not. Many users would regard pre-emptive auto-scheduling as being the
“standard” e-Quip approach to planned maintenance.
PPM schedules contain information about the maintenance frequency which allows the next PPM date
to be determined. For pre-emptive schedules they also contain a definition of the future PPM jobs which
will be created.
The first stage of auto-scheduling is to calculate the next PPM date 𝐷 ′′ for the device based on the
maintenance frequency held in the schedule. One of three actions then occurs:
1. Non-pre-emptive auto-scheduling: the calculated value of 𝐷 ′′ is written to the equipment
record, i.e. 𝐷 ′′ becomes 𝐷 ′′ 𝑒 .
2. Pre-emptive auto-scheduling where the future job details are held in the schedule: the system
creates a future PPM job with a planned date of 𝐷 ′′ . The job details stored in the schedule are
limited to a) Work Instructions, b) Job Status, c) Job Type & d) Job Priority, making this approach
appropriate when complex jobs, possibly involving spare parts, are not required.
3. Pre-emptive auto-scheduling where the future job details are defined in a job template: As in
case 2, the system creates a future PPM job with a planned date of 𝐷 ′′ , but in this case the job
to be created is defined in a job template. Normally the job template is linked to the PPM
schedule, but if a template has been linked to either a model or category then that will be used
in preference.
You can see that each of these techniques have different ways of maintaining the next PPM date for a
device, with some writing 𝐷 ′′ 𝑒 and others relying on 𝐷 ′′ 𝑤 .
For any scheduling technique which writes 𝐷 ′′ 𝑒 you should avoid manually changing this value as e-Quip
only calculates 𝐷 ′′ 𝑒 during PPM scheduling. If you overwrite its value then the date calculated by the
system will be lost.
How PPM Scheduling Works
We have seen that PPM scheduling occurs whenever planned maintenance work is completed. From a
technical perspective the first thing to note is that the stored procedures responsible for writing the job
data are not involved at all in maintenance date processing and PPM scheduling. These procedures
(pppJob_0, pppJob_1 etc, with one procedure for each tab) simply write the job details to the database.
Only once these procedures have completed and the job has been saved does any post-processing
occur. Job post-processing takes place in several stages and occurs regardless of how the job is being
closed (e.g. from the job property page, using bulk update or from the service history tab of the
equipment property page).
The post-processing proceeds as follows:
1. The procedure “qJobPostProcessing” is invoked first. It primarily carries out non-PPM tasks such as
the consumption of spare parts, updating of equipment meter readings, updating equipment status etc,
but is does have one element of PPM scheduling. If the device is not linked to a PPM schedule then this
procedure checks to see if the model has a default service interval. If it does, then that interval (in
months) is added to the job work end date, and the resulting value is written to the next PPM date field
in the equipment record 𝐷 ′′ 𝑒 .
Having done this the procedure “qUpdateEquipmentMaintenanceDates” is then called to validate the
maintenance dates in the equipment record (including the date 𝐷 ′′ 𝑒 just written) which might not be
consistent with the service history.
2. Next, auto-scheduling related post-processing takes place. The first thing that happens is that the next
PPM date 𝐷 ′′ is calculated using the information in the schedule. The calculation depends on whether
the schedule is anchored or floating.


Anchored 𝐷 ′′ = The Planned Date of the Job being closed + Maintenance Frequency.
Floating 𝐷 ′′ = The Work End Date of the Job being closed + Maintenance Frequency.
Note that for anchored schedules if the job being closed does not have a planned date, then the work
end date is used instead.
If the e-Quip PPM calendar feature is turned on, then having calculated 𝐷 ′′ the system will search the
calendar for the nearest date prior to the calculated value. For example, if the calendar is populated
with all days except weekends and public holidays then the system will set 𝐷 ′′ to be the closest nonholiday weekday to the calculated value.
Having found 𝐷 ′′ , one of two things then occurs:
a. For non-pre-emptive schedules (which do not generate future PPM jobs) 𝐷 ′′ is written to the
equipment record 𝐷 ′′ 𝑒 . This occurs within the procedure “UpdateNonJobPPMScheduleDate”.
b. For pre-emptive schedules (which do create future PPM jobs) the next job is then created
with a planned date of 𝐷 ′′ . For those schedules where the job is defined by the information
within the schedule this is done by the procedure “MakeSimplePPMJob”. In the case of
template-based pre-emptive auto-scheduling it is more difficult to create the job but the end
result is the same: a future PPM job with a planned date of 𝐷 ′′ .
Once this job has been created, the procedure “qUpdateEquipmentMaintenanceDates” is called again.
Now that a future PPM job has been created, this will validate any value in 𝐷 ′′ 𝑒 , if one exists.
Note: For pre-emptive auto-scheduling a future PPM is only created if an outstanding job for the device
& schedule does not already exist. In e-Quip there should never be more than one outstanding job for
the same device / schedule combination.
To summarise, every time a PPM job is completed, the system either creates future jobs or updates the
next PPM date field in the equipment record. It does not matter whether the job is completed from the
job property page, from bulk update or from within the service history tab of the equipment property
page: the post-processing is always the same.
What PPM Strategy should you Adopt?
Of course, different strategies are suitable for different device types, different locations, different teams
etc. It is very unlikely that there is a “one-size-fits-all” approach which is suitable for every device in your
inventory.
The following principles can guide you to choosing the optimum strategy:
1. For most devices which are maintained in-house, the simplest and most powerful method is to use
pre-emptive auto-scheduling. This is extremely easy to use and, once configured, is completely
automatic for the life of the device. It works well with either single or multiple schedules per device.
2. When using pre-emptive auto-scheduling it is a good idea to create two job status values to handle
situations where the work cannot be completed. These might be Not Found for PPM and Not Made
Available for PPM. They should both be assigned a status class of Missed PPM. Closing a job with one of
these statuses will still schedule future work, but gives you a clearer picture of the maintenance history
of a device.
Look at the sample service history below. We can see that the device was serviced in 1999, 2000, 2001 &
2002, but not in 2003, 2004 & 2005. The job planned for 1/9/2004 was created by the normal preemptive scheduling mechanism when the job for 1/9/2003 was closed with a status of Not Made
Available rather than Completed. The job status of Not Made Available (which has a class of Missed
PPM) tells the system to create the next job as usual. When e-Quip uses 𝐷 ′ 𝑤 to find the last PPM date,
missed PPM jobs are ignored.
This service history tells the full story of this device and this is far more useful than simply knowing that
the device was serviced in 1999, 2000, 2001 & 2002. Very often, what you haven’t done is as important
as what you have.
2. To reschedule PPM’s, bulk update jobs not equipment. Suppose that a particular ward is due a PPM
visit in March, but because of staff shortages you want to reschedule this work for May. Do you a) find
all equipment in that ward and then bulk update it all to set the next PPM date to be 1st May, or b) find
all of the PPM jobs due for that ward in March and bulk update them all to have a planned date of the
1st May? If you use pre-emptive auto-scheduling then the answer is definitely the latter. We have
already seen that setting the next PPM date for a device on a pre-emptive schedule has no effect and
the date is simply discarded.
The same is true for contract-based scheduling. It quite commonly occurs that either you or the
contractor will need to reschedule visits. As you have created jobs for these visits, then to reschedule
the work you should change the planned date of the jobs.
You should only reschedule work by editing the equipment record if you are using manual or modelbased scheduling.
3. Try to limit the number of PPM schedules that you create, and try to make them generic if at all
possible. For example, a PPM schedule with the work instructions “Annual PPM Due” can be applied to
almost any device, whereas a PPM schedule with the work instructions “Check battery condition and for
signs of oil leakage” can only be applied to devices which have batteries and which have an oil tank of
some kind.
Wherever possible you should use work instruction documents linked to models to inform the engineers
what to do, rather than include work instructions within the PPM schedule. If the work instructions for a
job say “Annual PPM Due” then engineers can click on Manage Documents on the job screen to tell
them exactly what to do and how to do it. This approach also handles revisions to work instructions
much better.
4. If you are philosophically opposed to creating future PPM jobs and are determined not to work this
way, then if the device is on a single schedule then consider using model-based scheduling. i.e. Simply
enter a service interval on the model screen and let the system calculate next PPM dates based on this.
Note that this approach is only possible:
a. Where jobs are used to record completed PPM’s (because it is the act of closing the PPM job
which calculate and writes the next PPM date).
b. Where the device has a single service interval.
5. For devices maintained on contract by 3rd party organisations, use contract-based scheduling. With
this approach the jobs for the duration of the contract are all created at the time that the contract is
created or renewed. Until a job is done the equipment next PPM date is taken from the outstanding
PPM jobs thus created. For example, if a device is maintained under a two visit annual contract, then
initially the next PPM date is the date of the 1st visit. Once the 1st visit job has been completed, the next
PPM date is then the planned date of the next visit job. However, once that job is completed the system
has no way of calculating the next PPM date. This will not be determined until the contract is renewed.
Recall that the next PPM date is the date on which you next plan to service the device, not the date on
which its currency expires. You will not plan to service the device again until you next renew (or review)
the contract.
Don’t be tempted to combine this approach with non-pre-emptive auto-scheduling. For the duration of
the contract, every time you complete a PPM job (created by the Create Jobs for Contract Visits utility)
the scheduling mechanism will update the equipment record with a next PPM date based on the
schedule. This may conflict with the date of the next outstanding job. If this date is after the planned
date of the next outstanding job then it will be deleted by qUpdateEquipmentMaintenanceDates
anyway and so serves no purpose. If it is earlier than the next outstanding job then it will be retained,
but it will be misleading. The date that you (via your contractor) plan to next service the device is the
date in the job not the date calculated from the schedule.
If you are tempted to do this there is a good chance that you fail to understand the difference between
the next PPM date and the date on which maintenance currency for the device expires.
6. Non-pre-emptive auto-scheduling is not appropriate for devices on multiple schedules. If you
understand the PPM post-processing you will know why. Suppose that a device is due to be serviced on
1/1/2013 (annual), 1/4/2013 (3-monthly), 1/7/2013 (6-monthly), 1/10/2013 (another 3-monthly), and
then again on 1/1/2014 (another annual). The pattern of annual, 3-monthly and 6-monthly can easily be
seen. Suppose that you create 3 non-pre-emptive PPM schedules. The annual schedule would have a
frequency of 12 months, the 3-monthly would have a frequency of 6 months (i.e. every April / October /
April / October / ...) and the 6-monthly would have a frequency of 12 months (i.e. every July).
This kind of scheduling can only work if the system pre-emptively creates future PPM jobs. Suppose that
you determine (by using a spreadsheet, spirit guide, deer entrails or some external planning tool), that
the device is due its annual service on 1/1/2013. You create a job for the device linked to the annual
schedule and then complete the job. Perhaps the job is completed on 5/1/2013. The PPM postprocessing knows only that an annual service on the device has been just been completed and
consequently calculates the next PPM date based on that schedule. This date is then written to the
equipment record. The next PPM date in this example will be either 1/1/2014 or 5/1/2014, depending
on whether the schedule is anchored or floating.
This date is clearly incorrect. Your spreadsheet knows that the device is due a 3-monthly service on
1/4/2013. E-Quip knows that the device is also on a 3-monthly schedule but it does not know the
starting point for that cycle. The only way that e-Quip can know that a 3-monthly service is planned for
1/4/2013 and that a 6-monthly is planned for 1/7/2013 is to create the jobs with the appropriate
planned dates, linked to the appropriate schedule. Hence, devices on multiple schedules cannot
satisfactorily be maintained on schedules which do not create future jobs.
Appendix A – Examples
The examples which follow demonstrate the most common PPM scheduling techniques and aim to
demonstrate how the last and next PPM dates are calculated and maintained.
1. Pre-Emptive Auto-Scheduling
This example demonstrates what is generally considered by e-Quip users to be the “standard” way of
scheduling PPM work. This example will also demonstrate the PPM Calendar feature. You should aim to
maintain the majority of your devices in this way unless there are good reasons to the contrary.
Create two PPM schedules as follows:
a. Major: frequency 12 months, anchored ; simple scheduling, work instructions “Major Service Due”
b. Minor: frequency 12 months, anchored; simple scheduling, work instructions “Minor Service Due”
Create a test asset. Link the major schedule to the device and create the first PPM job with a planned
date of 1/1/12. Link the minor schedule to the device and create the first PPM job with a planned date
of 1/7/12. The service history should appear as follows:
Note that the future PPM jobs have been created with planned dates of 26/12/2011 and
25/6/2012. Why are these dates not 1/1/2012 and 1/7/2012 as requested? The reason is that
this particular e-Quip installation is configured to use the PPM calendar. The calendar contains
all dates on which PPM jobs can be scheduled. This particular calendar is populated only with
Mondays, so PPM jobs can only be scheduled for a Monday. The closest Monday to 1/1/2012 is
26/12/2012 and similarly the closest Monday to 1/7/2012 is 25/6/2012.
The technical tab should now appear as shown below:
The equipment record in the database should contain:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = NULL
The equipment summary grid should appear as follows:
Now close the January job with a work end date of 5/2/2012.
The first thing to notice is that the PPM post-processing has created a new job planned for 24/12/2012
(which is the closest Monday to 26/12/2012, i.e. 12 months after the original job was closed).
Examine the technical tab:
This shows that the major service was completed on 5/2/2012 and the next service planned is the
minor, which is planned for 25/6/2012.
The equipment summary screen will now show:
The database will still contain:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = NULL
Next, close the June job with a completion date of 10/8/2012. Note again that the system has scheduled
a new job for the next minor service, which is planned for 24/6/2013.
The technical tab and equipment summary screen will appear as expected:
Note also that the database still contains:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = NULL
The values of 𝐷 ′ 𝑒 and 𝐷 ′′ 𝑒 have been consistently NULL, which indicates that 𝐷 ′ and 𝐷 ′′ are always
calculated from the service history, i.e. 𝐷 ′ 𝑤 and 𝐷 ′′ 𝑤 .
Notice that when using pre-emptive auto-scheduling there will always exist one non-started job for a
device for each schedule. In this example, at all times there will be two non-started jobs for this asset.
2. Manually Editing Equipment PPM Dates
We have just seen an example of PPM scheduling where e-Quip is completely responsible for
maintaining the last and next PPM dates. In that example those dates are always deduced from the
service history. What happens if the user manually edits these dates?
a. For the equipment record used in the example above, from the technical tab of the equipment
properties, change the last PPM date to 10/10/2012, then save, close and re-open the device. Notice
that the last PPM date has reverted to its previous value, i.e. your change has been discarded. The way
in which PPM dates are validated has already been described, so we might have expected that, as
10/10/2012 (the value we manually entered) is more recent than 10/8/2012 (the previous value), that
this date is valid and should not have been discarded. But recall from the section on
qUpdateEquipmentMaintenanceDates that:
If a device is maintained using “standard” PPM schedules which create future jobs then e-Quip
assumes responsibility for maintaining both the last & next PPM dates. In this case, any PPM
dates stored in the equipment record will be deleted.
For this type of scheduling, e-Quip will maintain the PPM dates, and any values that you enter manually
will be discarded.
b. Create a 6-monthly anchored PPM schedule with the “Do not Schedule Automatically” option set. For
a test asset create a completed PPM job on this schedule with a planned date and work end date of
1/1/2011. Look at the technical tab.
Examine the equipment record in the database:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = ‘1/7/2011’
Display the asset on the summary screen.
Notice that the last PPM date is being calculated from the service history, while the next PPM date is
being read from the equipment record.
Now edit the equipment record and change the last PPM date to 1/1/2010. Notice that the values
displayed and the values in the database are unchanged. i.e. the last PPM date in the equipment record
is still NULL, not 1/1/2010. The reason is that qUpdateEquipmentMaintenanceDates has seen that there
is a completed PPM job which is more recent than 1/1/2010, therefore this value is invalid and has been
deleted.
Now edit the equipment record and change the last PPM date to 1/5/2011. Now notice that in the
equipment record we have:
𝐷 ′ 𝑒 LastPPMDate = ‘1/5/2011’
𝐷 ′′ 𝑒 NextPPMDueDate = ‘1/7/2011’
Notice also that the correct values are displayed on both the summary screen and property page.
Now complete another PPM job for this asset on this same schedule with a planned date and work end
date of 1/7/2011. Look at the technical tab.
Look again at the equipment record in the database:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = ‘1/1/2012’
3. Model-Based Scheduling
Create a test asset linked to a model which has a default service interval set to 6 months. Create a
completed PPM job (with no schedule) with a work end date of 1/1/2011.
Look at the technical tab:
Then examine the equipment record in the database:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = ‘1/7/2011’
Notice that the last PPM date is being derived from the service history while the next PPM date has
been calculated as the work end date + the model service interval, and then written to the equipment
record.
Now edit the asset and change some non-date field (meter reading, for example), then save the record.
Look again at the database:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = ‘1/7/2011’
4. Contract-Based Scheduling
Create a test asset and link it to a contract which runs from 1/1/12 to 31/12/12. Run the Create Contract
Visit Jobs utility to create two visits: 1/2/12 & 1/8/12.
Look at the equipment technical tab:
Examine the equipment record in the database:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = NULL
i.e. the service history is being used to deduce both the last and next PPM dates.
Close the February visit job with a work end date of 5/2/12.
Look at the equipment technical tab:
Then look again at the equipment record:
𝐷 ′ 𝑒 LastPPMDate = NULL
𝐷 ′′ 𝑒 NextPPMDueDate = NULL
Now close the August visit job with a work end date of 10/8/2012 and then look at the equipment
technical tab:
Notice that the system has no way of calculating the next PPM date (i.e. the date on which you plan to
do the next maintenance, because you haven’t yet made any such plans). Using contract-based
scheduling, this is not defined until the contract is renewed and next year’s jobs are created.
This raises an interesting question: if the next planned maintenance date for this device is undefined
because you haven’t yet planned next year’s maintenance for it, then if you don’t renew the contract
how will you know when this device next should be maintained? Remember that when something
should be maintained and when you have planned to maintain it can be two entirely different things.
Could you use the dbo.PPMOverdueBy() function to find if the device is overdue for maintenance?
The important point to notice is that, in this example, at no stage have you entered anything into the
database which will tell e-Quip how often this device should be serviced. The only facts that e-Quip has
at its disposal are:
a. Two future PPM jobs for this device exist;
b. The device is currently covered by a contract which will expire on a given date.
There is not enough information here to allow e-Quip to calculate when the next PPM will be due once
the two outstanding jobs have been completed. Recall that earlier it was mentioned that contract-based
scheduling is a special case of manual scheduling: e-Quip is not calculating when maintenance is
overdue, only when it is planned. Once the contract is renewed then you will schedule the jobs for that
contract using the Create Contract Visit Jobs utility. If you do not renew the contract then you must
make alternative arrangements for scheduling. i.e. you can’t use contract-based scheduling for devices
which aren’t on contract.
G.R.Stanbury
Integra
19th March, 2013