Maximo Open Forum

We are looking at Job Plan Revisions and am having trouble seeing the benefit of them.  I have written audit reports that tells us who made what change to the job plans and all of the sub-tables associated with it. I am not trying to solve for that and it seems to me that it has changed "Who made that change?" into a far more complicated situation with two possible answers.  The person who made the specific field change and the person who enabled the revision.

• Other than being able to queue up changes to release all at once, what other benefits are there?
• Can you have a revision history where rev1, is a copy of rev 0, rev 2 is also a copy of rev 0 or does it enforce linearity and each revision must be a copy of the last ACTIVE version?  Meaning Rev2 MUST be a copy of Rev1.
• Why are we missing indexes for about half of the sub-tables on JobPlanID?
• If JobPlanID is the join for most of the Job Plan tables now, why is there no JobPlanID on the WorkOrder table so that you can associate it to the proper version easily?  SiteID + JPNum + PlusCRevNum is not nearly as efficient.  I know they load the JobTaskID now for the isTask = 1 so why not something for the isTask = 0?
• Same question with some of the other tables like JobPlanSpec, JobTaskSpec, PlusCJPStatus

Job Plan revisions came from our Calibration add-on. I think understanding that helps understand the intent behind it. Maximo is used by a lot of regulated industries that need control over these procedures, often with formal approval processes. Prior to job plan revisions, anyone could edit an active job plan, and it would take effect immediately. They could add/remove/modify steps that could lead to potentially disastrous results from a health, safety, or environmental perspective. This helps try to avoid that and provides historical context of what was used when the work order was completed.

Yes, when you create a revision it must be based on the current active revision. You can't revise revision 0 when you have revision 1 active. The revision step starts mostly with a duplicate action so revising an older revision would lead to the incorrect tasks, attachments, plans, etc. 

Which tables do you think we perform a join on using JOBPLANID that is not indexed? I checked JOBITEM & JOBTASK for example and both of those have indexes out of the box. It's possible someone has removed them in your environment or there are other tables. 

Regarding the JOBPLANID not getting copied to the WORKORDER, that could be done with a crossover domain. I agree the join based on org/site is complicated. I'm not sure why we never added it out of the box.

JOBPLANSPEC uses REFOBJECTID to indicate the jobplanid and JOBTASKSPEC uses REFOBJECTID to indicate the JOBTASKID. PLUSCJPSTATUS could make sense, but we followed our normal convention of joining based on the primary key column sequence of the parent object. Similar to how we join WOSTATUS based on WONUM & SITEID rather than WORKORDERID. I would agree, however, the complexity of this since it is at a SYSTEM/ORG/SITE level would make it better if it was a static ID. 

I understand the reason behind it.  In my system, we have rules around certain special job plans that the vaste majority of people cannot edit.  We also audit all job plan changes for the prior month on a report along with the jobtitle and rights of the person who made the change and when.

It could be my version of Maximo but I would expect JobPLanID to be indexed on the following:

JobLabor

JobPlanSpec

JobTaskSpec

JPTaskRelation

PlusCJPStatus

PS: Why does the JOBPLAN relationship PLUSCJPDSJOBPLAN not factor in SiteID?  We have the same Job Plan Number in different sites...