|
|
|
|
|
1
|
2
|
3
|
|
4
|
5
|
6
|
7
|
8
|
9
|
10
|
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
|
18
|
19
|
20
|
21
|
22
|
23
|
24
|
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
|
|
#7015 - 18/03/03 06:36 PM
Building A Database - Servicing Periods
|
Joe Emmerson
Savant
Registered: 17/04/01
Posts: 120
Loc: Lancaster
|
For the many intelligent people around I pose a question about either your Current bought database or one that has been designed in-house.
Servicing periods for equipment vary greatly, some requiring inspection every 4 months, some 6 monthly, some annualy etc.
How does your database distinguish between what is NEXT due on an equipment?
I'm looking on a reasonable work around or solution for creating a new database, but want to do it to peoples needs and not overkill or complicate matters where they dont need to be complicated _____________________________________________
for example, a debrillator which needs 2 four monthly inspections, followed by an annual inspection.
1) Would you have to enter 3 servicing reminders for this equipment, re-occuring annualy? (seems like a lot of work)
2) Would you set the servicing reminder for *all* that type of equipment to 4 monthly, and look back in the database servicing history to ascertain what type of inspection to do when it comes in?
3) Do you tick boxes to say what the servicing requirements are i.e [6 Monthly], [Annual], [Two Yearly], [5 Yearly], [8 Yearly] (Seems a bit of an overkill?)
_____________________________________
Note i have seen a system that uses method 1, but it seems to me very very time consuming.
I pose a double question, what is your current method, and what do you actually need?
|
|
Top
|
|
|
|
#7016 - 18/03/03 07:09 PM
Re: Building A Database - Servicing Periods
|
Alex
Mentor
Registered: 10/08/00
Posts: 167
Loc: Mid Yorkshire Hospitals NHS Tr...
|
Joe, lookup EMAT under Barwick systems. it will do what you want it to do. or give me a ring. alex
|
|
Top
|
|
|
|
#7017 - 18/03/03 07:43 PM
Re: Building A Database - Servicing Periods
|
Joe Emmerson
Savant
Registered: 17/04/01
Posts: 120
Loc: Lancaster
|
I'm looking at the structure of a database with a view to creating a master table of fields, rather than an already existing system.
I'm looking more into what methods are there in the current systems available or how people have tackled this problem with their home-built database.
Weighing up the process of complex programming / algorithms to auto-detect servicing type due or whether to just say that "its due on xxx" will suffice.
^^ It would be easy for the programmer to have the user input 3 servicing periods for 1 piece of equipment (4 month, 4 month, 1 year) and have it re-occur annually, but not so good for the user with 1500 different types of equipment to transfer over to a new system.
I was thinking of two possibilities,
(1) would be to ignore the service required and concentrate on the date due only (as the possibilities are huge)
(2) would be to try some complex code to determine what service is due next, taking into account its previous history of servicing (but is it really really worth the effort and time?)
with option (2) it must be based on the USER only having to tick boxes like "6 Monthly", "Annual", "5 Yearly" and the system determining which one is next in the sequence.
|
|
Top
|
|
|
|
#7018 - 18/03/03 08:25 PM
Re: Building A Database - Servicing Periods
|
Huw
Hero
Registered: 20/06/00
Posts: 1390
Loc: Essex
|
Hi Joe, The database we are curently using allows for two types of PPM.
A 'major' and a 'minor' - they can then be scheduled on a 'rolling' or fixed basis.
We use the fixed date option.
We generally schedule equipment for a major ppm and a minor ppm at 12 monthly periods - with the date of the minor six months before/ after the major.
HTH
|
|
Top
|
|
|
|
#7019 - 19/03/03 09:19 AM
Re: Building A Database - Servicing Periods
|
Joe Emmerson
Savant
Registered: 17/04/01
Posts: 120
Loc: Lancaster
|
"We generally schedule equipment for a major ppm and a minor ppm at 12 monthly periods - with the date of the minor six months before/ after the major"
Does that mean for every equipment, you need to set 2 schedules?
or does the database only need the 12 monthly due / last done date and work out the 6 monthly periods inbetween itself?
|
|
Top
|
|
|
|
#7020 - 01/04/03 02:28 PM
Re: Building A Database - Servicing Periods
|
Joe Emmerson
Savant
Registered: 17/04/01
Posts: 120
Loc: Lancaster
|
Any more input, anyone?
Or am I wittering on again and not explaining myself properly
This is YOUR chance to have some input on what a database SHOULD do.
|
|
Top
|
|
|
|
#28737 - 17/03/08 07:13 PM
Re: Building A Database - Servicing Periods
[Re: Huw]
|
Geoff Hannis
Hero
Registered: 12/02/04
Posts: 3026
Loc: the path less trodden
|
Forgive me for dragging forward this "blast from the past" (it was posted well before I became acquainted with the forum), but I'm interested in this stuff. It's only five years old, and Joe must have got it all squared away by now (but newcomers may be interested, too).
Fundamentally, we biomeds almost always run PM scheduling on elapsed calendar time (ie, days) do we not (rather than machine hours run, miles covered, condition, or whatever)?
So the way I've always done PM programming is to set the PM interval in days (eg, six-monthly :: 180). That way, in a year you can have as many PM's as you like (from none to 365). Every two years would be 730 days, etc.
All you need the system to be aware of is the Last PM date and the interval, and have it run a routine to check if the Next PM is due (or over-due) as it fires up each day.
On the matter of Major and Minor services, I know that ECRI (and therefore, HECS) likes this idea. For instance, Major procedures are often set annually, and Minor every six months.
But as Joe has mentioned, things can get a bit unwieldy using this approach (two schedules). But why stop there? Why only two levels of service (what if you want to have five, say)? What if you want different ones for different trades? What if the Minor is late, and starts to approach the Major? It all gets too complicated, and I rejected this idea years ago. So what I do if more than one level (Major, Minor, whatever) is needed, is to simply mention this in the procedure itself! If you must have Major and Minor routines (and I would avoid them, myself, when writing PM procedures), if it's time for the Major procedure, do it. Otherwise carry out the Minor one. Something like that.
What are the differences likely to be, anyway? Main filters changing every year (Major), complete overhaul every five years (Mega-Major)? Re-painting every ten? Anything like that can be noted in the procedure narrative, if need be.
There is another way (which I consider reasonably elegant) of dealing with the Major-Minor thing, but I won't go into that just now.
The bottom line is that all this stuff shouldn't be a chore. Just get it set up properly in the first place, then let the computer do the work. Leaving you to get on with the real work!
Edited by Geoff Hannis (17/03/08 07:36 PM) Edit Reason: It wasn't elegant!
|
|
Top
|
|
|
|
|
|