Monday, 25 August 2014

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.


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. 

Sunday, 17 August 2014

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.

Friday, 15 August 2014

LG G Watch Review for Enterprise Applications

We've recently been testing the new LG G Watch to enhance some of our mobile applications for JD Edwards. This device is just another example of how much benefit can be gained from utilising consumer devices for enterprise applications. The distinct advantage that the consumer market provides is the high level of competition and huge sales volumes that means that the latest technologies are available at very low cost.

Our first impressions when taking the LG G Watch out of the box is that it has the look to make the cross over from consumer to industrial device. One of the issues with a lot of consumer devices is that they try to be as much a fashion accessory as they are a practical piece of equipment. This is fine for the consume market but can be a deterrent when it comes to businesses considering them as a part of a mobile solution. While it by no means has an industrial look, the LG G Watch is certainly plain enough to be inconspicuous and is small enough to be comfortably worn all day. We would certainly suggest that it is a far better design in appearance and practicality than either the Samsung Gear range or the soon to be release Motorola 360.

As far as performance goes there's really only two things that we need to worry about which is how does the screen perform in different conditions and what sort of life does the battery give.

Firstly to the screen. We had no issues at all with the 280 x 280 pixel square screen on the LG. We were able to design user interfaces for a few different applications to easily fit and with the right selection of colors and contrast there were no problems reading the screen quickly or in full sunlight. The fact that Android has been designed to work with a broad range of screen resolutions for a long time means that the process of creating screen layouts for the Android Wear devices is no different to any other Android device.

Now the battery life. The LG G Watch comes with a 400mAh battery that according to the LG website should last you a full day on a single charge. In our business a full day is considered somewhere between 8 to 12 hours and our experience is that while you can get a full day out of the device, you certainly won't get 8 hours of use out of it and a more realistic number would be only a few hours of continuous use. For the majority of situations where we would look to make use of the device this would probably be a bit of a deal breaker. You would like need to be able to at least top up the battery during the day rather than just at the end of each day. There's certainly nothing scientific about these observations and it is just from our experience while testing the device with our applications.

One of the well documented considerations when designing mobile apps is to ensure that the application has clear functions and intuitive for users to operate. With wearable devices this takes on a even more significant importance. We spent a few hours discussing how the LG G Watch could enhance some of our existing applications. Ultimately it came down to identifying very specific use cases within the applications and designing clean and simple components to meet those requirements. What that meant is that as soon as the use case had an if statement somewhere, processing moved back to the primary mobile device.

So what scenarios did we end up testing? Well the first was using the the LG G Watch as part of a warehouse picking application. The primary goal when we started was to test out how the device would go with voice picking and ultimately our results were mixed. The first issue we had to overcome is the fact that the voice recognition algorithms are really designed for natural language so if the identifiers for the items being picked are lot or serial numbers that are mixture of letters and numbers then life became a bit difficult. Add in some other random characters and it became a whole lot harder. The second main issue we had was the nature of the microphones on these devices means that they are not good at cancelling out background noise and therefore recognition of the speech can be all but impossible in some situations. 

The final issue we had was occasionally the voice recognition would stop working all together and just throw an error that it was unable to reach to the Google Cloud for processing. One of the great improvements with Android 4 for our applications was the fact that decoding of voice to text was completely locally on the device rather by a server somewhere out on the ether. We're not sure why the watch was unable to contact the servers for processing as the mobile device the watch was paired with had connectivity but either way, we'd like to see the processing handled by the device the watch is paired do the processing rather than servers out in the cloud.

Ultimately we do believe that voice picking is possible with the LG G Watch but only in situations where the list of possible items being picked is fairly small and the environment doesn't have a significant amount of background noise. With a list that is small enough it is possible to put in place some fuzzy matching logic to make the solution workable.

The next application we attacked was a quality management solution and we effectively used the watch to provide step by step instructions to the user. So basically go to this location, find this lot, take this many samples, confirm on the watch that you have taken the samples and then move on to the next location. We found this sort of use case to be well suited to the watch as we the users didn't need to access the primary mobile device at all and had both hands free to perform their functions. The information they required could easily be presented on the watch and the user interactions required to drive the application were simple.

So in summary we feel that devices like the LG G Watch provide an excellent opportunity to get even more productivity and efficiency gains out of mobile applications in an enterprise environment at a very low cost. Developing for the devices is simple and their integration with Android mobiles and tablets has been well implemented. Hopefully an opportunity will present itself in the near future to put some of these devices to use in anger.

If you have any questions about our experiences with the LG G Watch or want to know how Rinami can assist you with delivering mobile solutions into your business, please contact us.