Setting up preventative maintenance service cycles in JD Edwards EnterpriseOne using Associations

One common requirement for many different types of fixed and mobile plant is the requirement to establish service cycles. These service cycles are either meter based, interval based or both. A common example would be light vehicle servicing where the requirement would be for a service to be performed every 10,000 kilometers or six months, whichever comes first and it major intervals more significant services are required to be completed.

So how does JDE Plant & Equipment management meet this requirement? Through the use of associations. The associations functionality allows individual maintenance schedules to have a relationship to each other thus you can establish one or more service cycles for a unit.

In this post we're going to run through how you actually go about establishing a working service cycle using a light vehicle as an example and some of the gotchas that you should look out for.

Context

For this example we'll be setting up a single service cycle for a light vehicle. In this case the vehicle will require a service every 10,000km or 6 months, whichever comes first. Obviously not every service will be the same so at 20,000km, 40,000km and 120,000km there will be differing servicing requirements.

Preliminary setup

The first important point to understand about associations in this context is that you will be setting up four separate service schedules that are related to each other as opposed to a single schedule with changing maintenance types. This is an important distinction for users which are familiar with other computerised maintenance management systems (CMMS) and must be understood to be able for the successful operation of these types of setups.

In this case we've created four maintenance types to reflect the four different types of services:

• LVTH010K - Toyota Hilux 10,000KM Service
• LVTH020K - Toyota Hilux 20,000KM Service
• LVTH040K - Toyota Hilux 40,000KM Service
• LVTH120K - Toyota Hilux 120,000KM Service

As you can see we've ensured that our codes are going to appear in a logical order when sorted alphabetically. A minor point but one that can significantly improve the user experience when dealing with units that have dozens of different maintenance types associated with them.

For each maintenance type we've configured the base PM schedule items:

• LVTH010K - 10,000KM or 182 days
• LVTH020K - 20,000KM or 364 days
• LVTH040K - 40,000KM or 728 days
• LVTH120K - 120,000KM or 2184 days

One important point is managing how each service divides into the next. For the service cycle to be clean and easily understood we generally want all of the child services to divide cleanly into the top parent service. So in this case the top parent service is the 120K service. So we could introduce a 60K service without any major issues but if we introduce an 80K service things start to get ugly as 80K does not divide into 120K. In the real world where units are not serviced exactly to schedule this complication just adds an extra complexity for maintenance planners that is good to avoid.

Once the PM schedule entries have been created we're going to create the maintenance rules for them. It is very important to understand how the maintenance rules work and how those rules will work once associations are introduced. If the maintenance rules are not set correctly, and then you combine this with incorrect tolerances on your associations, a right royal mess will be created once you're up and running as services get performed outside of the scheduled interval.

In this case we're going to set the same maintenance rules for all of the services with a threshold of 95%. For simplicity we'll assume that this light vehicle is going to travel 100KM per day, 7 days per week. If that is the case then for each of the services we get the following planning fences:

• LVTH010K - work order will trip 500KM before due which is effectively 5 days
• LVTH020K - work order will trip 1,000KM before due which is effectively 10 days
• LVTH040K - work order will trip 2,000KM before due which is effectively 20 days
• LVTH120K - work order will trip 6,000KM before due which is effectively 60 days

Now in reality you would try to tune your thresholds so that the work order is being tripped as late as possible.  If you don't need 60 days to plan your 120K service then you should increase the threshold to suit.

That's it for the preliminary setup. We now have an operating set of PM schedules but they are running independently of each other.

Creating the Associations

When we create associations for these four PM schedules we're effectively loosely coupling them together. I use the term loosely because it is important to understand that you are still running four separate PM schedule lines. The relationship between the services is not concrete and can easily be broken altogether.

In this example each parent service consumes the child services. So a 20K service replaces the 10K service, the 40K service replaces the 20K and 10K service and the 120K service replaces all of them. This means that we only require a single work order every time a service on this vehicle is performed.

The association set ups for each of the parent services is shown in these screenshots.

It is important to note that the associations are not automatically cascading.  That is, just because the LVTH010K service is associated to the LVTH020K service and the LVTH020K service is associated to the LVTH040K service, the LVTH010K service is not automatically associated to the LVTH040K service. You must explicitly define this in the associations for each service.

Because we only want a single work order per service we must set the Separate Work Order flag to 2 and also provide a status for existing work orders if they need to be cancelled to meet this requirement. Cancellation will only occur based on the child service being within threshold and the PM status being within the range specified in the relevant maintenance rule. If you don't want the PM Status Update UBE to cancel tripped work orders you would leave the association range at 01 in the maintenance rules.

The final piece of the puzzle is setting the thresholds for the associations. If we focus on the meter component then we must consider the effective meter to run value of the parent service compared to the child service.  So in our example the maintenance rules state that when the meter gets to 114,000KM the 120K service should be tripped. This means that the unit has 6,000KM until the service is due. So this means that for the 120K service to pick up the 10K at the same time the percentage threshold on the associated 10K service can be no higher than 40%. In reality 40% is far too high a threshold for this scenario. If we take a situation where the last 10K service was performed at 111,000KM that means that when the unit hits 114,000K the 10K service is only 30% due while the 120K service will be 95% due. If we set the threshold for the associated 10K service to 40% then it will not be picked up when when the 120K service it tripped. Instead we can actually set the threshold to 0% which means that when the 120K service trips it will always pick up the 10K service assuming that it is not at a open PM status greater than 50.

If the threshold for the 120K service was set to 90% rather than 95% you would not be able to use 0% because 90% gives an effective meter to run of 12,000KM which is greater the service interval specified on the 10K service. In that instance you would actually need to set the Multiple Work Order code on the 10K to 1 and change the associations range on the service down to 01 records only to handle the overlap between planning the 10K service and planning the 120K. Unless your planning fences dictate that you need your PM schedules to be tripping this early, this sort of scenario should be avoided as it will create a complicated environment for your maintenance planners.

Once the associations have been defined in this manner you should now have everything configured to execute the planning cycle.

Running the PM Schedule

When running service cycles using associations there are a few important things that need to be managed for the solution to work effectively and reduce the amount of manual planning that would need to be carried out. Firstly if you are using meters as part of the service interval then you must ensure that you are getting timely and regular meter readings into the system. Failure to do so can cause significant fluctuation in the percentage due which can cause difficulty in planning. The second is that servicing is carried out a close to schedule as possible. Servicing unit significantly early or late relative to their planned service date can cause the associations to get out of sequence. The last requirement is that PM schedule lines are closed as soon as practicable. If you are using model work orders then this means that the work order is moved to a status which closes the related PM schedule line as soon as possible after the work has been completed.

Failure to manage the process in this way will cause significant overhead for maintenance planners when using associations as the automated generation and association of PM schedule lines will frequently fail to occur.

One final note on running the schedule. You must ensure that your R12807 Update PM Schedule Status report has data sequencing set so that your PM schedule lines are processed in order from most frequent to lease frequent. Failure to do so will cause the associations to burn through work order numbers while processing. There is a white paper available from Oracle within information on how to do this.

What about forecasting

JDE enables preventative maintenance forecasting through the use of PM projections. Unfortunately there is a significant issue with the projections generation report (R13411) in that it does not take into account associations. This means that it will project the 10K service every 10,000KM when in reality the 10K service will only occur every 20,000KM.

At Rinami we have developed a set of enhancements that offers planning improvements including more sophisticated calculation of the PM schedule occurrences value and also generates the PM projections taking into account the associations. This enables organisations to run far more accurate PM forecasting and budgeting processes using the PM schedules they have defined within JDE. Please contact us if you like to know about this enhancement to JDE Plant & Equipment Management or would like know more about how we can assist you with implementing or improving your Enterprise Asset Management processes and systems. 

Success with Mobile Applications in the Enterprise

The forecast is clear: demand for mobile applications in the workplace will increase considerably in the next few years. Is your organisation ready to capitalise on the benefits of this trend? It’s a decision that can have a profound positive impact on your business—if it’s done right.

At Rinami, we are contributing to the mobile revolution by developing custom mobile applications that are tightly coupled to your JD Edwards EnterpriseOne system. From this experience we have discovered two important keys to developing effective mobile application for the enterprise market.  

Meet Business Goals

The most important step is to realise that, unlike traditional enterprise resource planning (ERP) systems that try to be all things to all people, mobile applications need to be finely tuned. This means drilling down to processes and tasks that are tailored specifically to the unique requirements of the business.

Enterprise-level mobile applications are designed to solve distinct problems such as compliance and workflow. Your first step is to define these problems in specific terms, making sure to gather input from not just IT executives, but all decision makers in the company.  Then, you can tie the problems to the goals the company wants to achieve and focus development on delivering a solution that meets these goals. 

One important note about paring an enterprise mobile application down to the needs of the business, is to maintain some flexibility. Just like your ERP product, your enterprise mobile applications should be configurable so that as the needs of the business change, the applications can change with them without having to be redeveloped. One way that Rinami meets this requirement is to integrate tightly with the business logic within JD Edwards to ensure that if configuration changes are made to the relevant applications with JDE then those changes are instantly reflected in your mobile applications.

Meet User Requirements

In addition to understanding the business objective, you must also understand and cater to the needs of the users of enterprise mobile applications. This sounds obvious, but there is a big shake up in the workplace that is making this an important consideration more than ever before: the consumerisation of IT. This concept basically means that users are expanding their experience with technology as a consumer to impact their expectations regarding their technology experiences at work.

Design and usability are important factors for developing mobile applications for any market. However, it tends to have more weight in the consumer market. That is changing in a big way. Whether a company has a bring-your-own-device (BYOD) policy or provisions certain mobile devices for their employees to use, the company apps that run on those devices should meet the needs and desires of the users—employees. Choosing to ignore these desires can cause disinterest and dissatisfaction that can ultimately render the application ineffective.

Mobile applications must be intuitive to the user whether they are consumer games or providing real time delivery tracking and capture. This means that mobile applications must be designed around your business process to ensure that the user is left in no doubt about how to use their mobile application. The information that is presented is everything they need to complete their task and nothing that that they don't need. The flow of the application should exactly match the flow of the process they are completing.

While sounding simple, these key points are fundamental to a successful mobile strategy and should be at the forefront when considering how to deliver you business processes over mobile devices.

Preparing for the Future

There are several challenges with implementing a business model that includes the use of mobile applications. The biggest of which is managing and securing the applications and data on your mobile applications. Mobile device management and security software is now available from a range of vendors, including Oracle, to enable this across all of your business mobile devices. But even without these types of tools, it possible to develop and deploy mobile applications into your enterprise that are secure and do not expose your business to unnecessary risk.

With the significant investment that organisations have already made in their core business systems, embracing the mobile revolution should be about enhancing the value of that investment and delivering information and collecting data from your workforce in the most efficient means possible.

The future of enterprise mobile applications has arrived and the benefits are very real. If you want to understand how Rinami can help you deliver solutions that are tailored to meet you specific requirements and objectives please contact us.