If I’m following you correctly, the separation is if you put steps on a grouped and merged PM.  For example, I did a quick demo where I have two NC Lathes that I want to do thorough monthly PMs on with task steps 1 through 3.  This will generate two separate tasks, one for each machine.  I also have three bar feeders that I just want to do visual inspect and cleaning on, so in the same Grouped and Merged PM, I don’t put task step in for them.  This creates an additional task with steps for each bar feeder.  See below.
 

NC PMs have task steps:

The bar feeder PMs don’t have task steps:

The resulting PM work order looks like this:

Does this help?

Hi Jerry,

I am not using Work Steps at all on the PM Action. I only have one template and in the work list tab I have one row. 

Instead I have 13 PM Actions with different criteria.

These has been generated on a WO as 5 different Tasks. Divided after the Action Code. E.g. With 3 Work Task Steps where there are 3 actions of the same type.

My question is what determines if these will be a Work Task or a Work Task Step? Is it the interval, action, maint org, etc or something different? Or all combinations would create a new work task?

kind regards

Christian

I’d have to investigate further, but it looks like it’s divided by action code.  Although I’d think the maintenance org might be another varible.  That’s really a weird PM you put together for fire extinguishers, but I think I see the objective for testing purposes.. 

I was told to keep the work task template connected, action code, maintenance org, work type the same. 
then if merge was selected and pm group was the same for the pm actions and that they would fall on the same due date then it would merge into one wo with one task with x work tasks steps. X being the number of pm actions. 
 

that is how we have created our monthly checks for e.g. fire extinguishers. 

we also did quite some testing with work task template and work list on same in order to make the pm and work orders behave as desired. 
 

Thank you both. I really like the setup we have now, just need to be sure how the system works so that we don’t have a trigger that would create work task or steps were we did not expect.

@JerryB You are correct with the comment about weird setup, we dont have that many different maintenance routines for our extinguishers. Just needed to create more PM Actions for testing purposes. What we do want, is to have typically one inspection on several objects and then a re-certification on the same objects with a greater interval.

kind regards
Christian

Hi,

I have done some additional testing and what I have found out is the following;

It is the resource that determines if it will be several Work Tasks. If you have different resources on the PM Actions they will become different Work Tasks.

I have tested by changing Maint Org, not have a Work Task Template, Action Code, different Work Descriptions and different intervals. Changing any of these wont do anything, they will be Work Task Steps no matter what.
 

What I havent found out is which maint. org. or action code that is chosen, or if this is random, when you only have one Work Task.

For me it was a really heads up finding out that different intervals will be steps on the same Work Task.

Example;
1 month Inspection on X number of objects

12 month Re-certification on X number of objects (same objects)

This will come out as 1 Work Task if it is the same resource that will do both jobs. Even if action, maint org, description, etc are different.

kind regards
Christian

@JerryB - is IFS working on this issue at all? Please add information whether IFS is considering a change in the work generation process in regards of this discussion. 

Please also consider the comments in the attached document provided to IFS at the O&G networking meeting in November. 

Kind regards,

Marie

Hi,

I’m aware of that this answer is a bit late for the original question but still hope it can be of use for someone.

Below you can find some information of the thinking behind some ways of grouping together several PMs into same WO.

Regarding merge criteria there might have been one or two more criterion added to the list. 

Mechanisms for putting PM Actions together into same Work Order

In App10 when introducing Work Task concept in Service & Asset a lot of work was also done in the PM area. One thing among other was to remove the earlier way of distinguishing between Separate PM Actions and Route PM Actions, to just have PM Actions. On the other hand, then different mechanisms were introduced to be able to get more than one PM Action into same Work Order after generation. In this way it become more flexible how to build up Work Orders from one or more PM Actions.

PM Group ID

• By using same PM Group ID, the PM Actions will be grouped together and the Work List lines on the PM Actions will become Work Tasks on the Work Order.
• Criteria for a Grouping to take place is that all PM Actions
  • have same value in PM Group ID
  • fall due at same time

• Note! During an upgrade earlier Route PM Actions will be converted to PM Actions with a PM Group stated, where the Route List will become a PM Group ID.

Example - Group

PM Group + Merge

• Merge can only be used as an addition to PM Group ID.
• By using same PM Group ID + Merge flag the PM Actions will be merged together, the Work List lines on the PM Actions will become Work Tasks Steps within one Work Task on the Work Order.
• Criteria for a Merge to take place is that all PM Actions
  • have same value in PM Group ID and with Merge flag ticked
  • fall due at same time
  • each PM Action consist of only one Work List line
  • have no Work Steps under the Work List
  • should have same planning for (resource/part, qty, sales part, and no manual price source)
    • resources
    • material
    • planning
  • if used also same values for
    • customer
    • contract/contract line
    • location
    • work type
    • vendor

• A merge will happen if and only if above condition are fulfilled.
• If not all criteria are fulfilled for a merge to take place, a group will still be done if possible.
• If above conditions are fulfilled when there are only one PM Action available for the group, it will self-merge.

Example - Merge

• When one or more of these conditions are not fulfilled the grouping will happen instead of the merge if the two conditions for grouping are fulfilled.
• If there will be a mix of PM Actions that fulfill the criteria for a merge or for a grouping, it’s possible to get both Grouped and Merged PM Actions into same Work Order, presented as Work Tasks and Work Task Steps.

Example – Mix of Group and Merge

How costs are divided for grouped/merged Work Orders

One more thing to consider in the decision of using Group or Merge when generating a Work Order from several PM Actions is how you want to divide the costs for the resource, material etc. used for the work done.

Group

• Here you get Work Tasks created on the Work Order for the Work List lines on the grouped PM Actions.
• Each Work Task on the Work Order will get all its costs into the Eq Object entered as Actual Object on the Work Task line.
  • I.e. reporting is done on Work Task level and cost is taken of the object on the Work Task.

Merge

• Here you get Work Task Steps created connected to one (merge) Work Task on the Work Order, one Work Task Step for each Work List line on the merged PM Actions.
• As default there is no object entered as Actual Object on the (merge) Work Task and all costs will be divided equally between the Eq Objects on the Work Task Steps.
  • I.e. reporting is done on Work Task level and cost is spread equally down to the objects on the Work Task Steps.
• If manually entering an Eq Object on the (merge) Work Task line, this object will take all costs and the Work Task Steps will then take no costs.
  • I.e. reporting is done on Work Task level and cost is taken of the object on the Work Task.

In addition to the concepts described above we have also introduced two other mechanisms for getting several PM Actions into same Work Order.

PM Grouping Rules

• PM Grouping Rules makes it possible to group together PM Actions into same Work Order according to a predefined grouping rule.
• This functionality can only be used on its own, i.e. not together with PM Group and Merge functionality.
• When defining a PM Grouping Rule there are some predefined parameters to select among, where one or more parameters then will be used as base for the grouping. Predefined parameters are Action, Contract ID, Contract Line, Customer, Maintenance Organization, Object ID, Priority and Work Type.
• A work order will be created for each different value of the parameter defined for the PM Grouping Rule, or for each combination if there are several parameters defined.
  
   

Example – PM Grouping Rule (Parameter: Maint Org)

How costs are divided using PM Grouping Rules

Grouping Rule

• Each Work Task will get all costs into the Eq Object entered as Actual Object on the Work task line.

Apply PM to existing Work Order

• Functionality that enables to look for an existing Work Order to which the PM Action can be applied instead of creating just another new Work Order.
  • If a PM Action can be applied to an existing Work Order - Will become part of the scope for the existing Work Order.
  • If a PM Action cannot be applied to an existing Work Order - New Work Order will be created for the PM Action generated.
• Will only occur if certain criteria is fulfilled for the Work Order
  • ’Allow PM Group/Merge’ flag is set.
  • not yet started.
  • WO execution is same as PM Actions fall out.
  • Work Order have same PM Group ID as the PM Actions

Example – Apply PM to existing Work Order

How costs are divided using PM Grouping Rules

Apply to open WO

• Cost will be divided according to the rules for other Grouped or Merged PM Actions.