Mobile solutions are often added to the Maximo enterprise almost as an afterthought. Mobile projects are executed after the Maximo implementation or upgrade is complete. Project budgets are tight and the benefits of mobility are underestimated. These lead to compromises in the choice of mobility product, and in the scope of the implementation.

There are now plenty of mobile system providers catering to this perception and providing those compromise solutions. As a result, we are seeing Requests for Proposals with the compromises baked in!

  • "Solution must be completely off the shelf."
  • "Solution must work on any platform."
  • "Must be a single App for everything in Maximo."
  • "Must have the ability to add mobility to any enterprise application in the organization, not just Maximo."
  • "Must install quickly and easily."
  • "Must be user-configurable."
  • "All of our unique customizations must work in your App Out of the Box"
  • "Our budget is tiny."
  • "We want it tomorrow."

Maximo Mobile ChecklistOK, so some of those don’t sound like compromises, at least not on the face of it. From the customer perspective they may not be. They actually sound like a great wish list!  However, for a solution to meet those requirements it has to be created with compromise in mind.

Before we look at what those compromises are, where the weakness is in the strategy, we need to look at the reasons for deploying a mobile solution, and the organizational benefits to be gained.

  1. Efficiency. Using a mobile device to be notified of your work, understand the requirements, follow procedures, and capture the data is hands-down the most efficient way to operate. So many effort-wasting activities can be eliminated.
     
  2. Data Quality. The main point of the mobile solution is to capture data. You are doing that now, initially with paper and pen probably. With a mobile solution the data to be captured is enforced. With a good solution it is made easy, and even intuitive, to capture that data.
     
  3. Data Quantity. When capturing information using paper and pen it is normal to take shortcuts. Transcribing that data at the end of the day leads to more shortcuts being taken. If another employee is responsible for that transcription you often compound that problem by losing reason 1 completely, and reducing reason 2 considerably.
     
  4. Worker Safety. The safety angle has been a tough one in the past. Safety procedures can be delivered easily for each work order, asset, and location. Lock outs and tag outs can be better handled. Job safety analysis can be enforced and acknowledged. But this can be somewhat countered in some cases/industries by the need to hold on to a device when it might not be prudent to do so. However, in the world of Covid-19 safety is back at the top of the list. By using mobile devices for work and inspections the worker no longer has to visit the office (along with all those potentially infected co-workers) to collect work assignments. They do not have to be called in for updates, and nor do they need to go to the office at the end of the day.
     

Let’s go back and look at our sample list of requirements. We see a lot of these listed as requirements in the ‘Mandatory’ or ‘Must have’ columns. But why is that? Why should any of these be mandatory requirements when they also add limits on capability and innovation?

  • "Solution must be completely off the shelf."
  • The source Maximo system is almost certainly not ‘completely off the shelf.’ In 18 years working with Maximo I have never come across a customer using Work Order Tracking without some level of customization (modification of system by any means – not getting into a customization vs configuration debate here).  Therefore, in most cases it is unreasonable to expect an add-on system to automatically understand your changes and automatically adapt to them.
     
  • There is inherent ambiguity in the term. What does it even mean? The general acceptance is the same as the customization vs configuration argument which makes sense. However, insisting that all customization is evil and must be avoided at all costs makes less sense. Instead of a blanket ban, consider modifications on a case by case basis while considering both the risk and the benefits.
  • "Solution must work on any platform."
  • Consider whether you are really going to deploy the mobile solution to Android, iOS, and also Windows. Doing so can increase support overhead and may also disqualify an otherwise great solution.
  • "Must be a single App for everything in Maximo."
  • This requirement often comes about because there is a misunderstanding about what it means for a user to be able to do everything within a single app. Some solutions have different apps, for instance, for work order management and inventory management. That is perfectly fine because it is rare for the two roles to be undertaken by the same person.
     
  • However, some providers create separate apps for every function. Consider how annoying it is for a warehouse operator to have to log in each time for the functions of receiving a new item, later counting it in the bin, and issuing it to a work order or technician. Those functions should be in a single app behind a single login.
     
  • One downside to a single app approach is that it can make the app more vulnerable to bugs and errors. A larger and more complex code base can be more vulnerable.
  • "Must have the ability to add mobility to any enterprise application in the organization, not just Maximo."
  • This makes no sense if you drill down into the details, yet it happens. I have even seen a large company deprecate an excellent work order management and inspections app, built from the ground up for Maximo, in favour of a generic mobile app builder suite. It would take years before the capability could be matched, if ever. Every user from that day on was constantly frustrated and less productive.
     
  • Get the tool that is best for the job. Each job, not every job.
  • "Must install quickly and easily."
  • Most of them can do this so it is another ambiguous requirement that can be easily manipulated. Mobile Informer, IBM Anywhere, DataSplice, and EZMaxMobile for instance can all be installed within one to two hours in almost any environment. Sometimes it only takes minutes (I once saw an installation take 11 minutes from scratch to seeing a list of work orders). However, the installation is just the start and the system is never ready to use at this point. There will be a lot of configuration and, dare I say it, customization before it is fully usable and meeting the requirements. When I was in the Air Force I learned to fly very quickly. From starting flying training to my first solo was just a few weeks. However, it was a few more years before I was on my squadron with a combat ready status. Learning to fly is one thing, learning to operate is a different ball game and takes a lot longer.
  • "Must be user-configurable."
  • I agree with this principle – up to a point. If it is too configurable it encourages too much tinkering. ‘Easy’ changes also typically go through a less rigorous change manage process.
     
  • ‘Configuration’ is often another term that is manipulated by software vendors. OK, so ‘this’ solution does not need to be recompiled and redeployed to change the work process. But if you have to use proprietary syntax to write ‘configuration statements’ in a proprietary administration tool, is it really configuration? Is it better to use a vendor-specific administration tool using newly-learned and unique skills, or to use industry standard a proven tools such as Android Studio or X-Code?
     
  • I have worked with both types of application – all configuration and all [nearly] all custom code. What I found was that the end to end implementation projects were very similar in length and cost, but the final product was significantly better with the custom approach.
  • "All of our unique customizations must work in your App Out of the Box"
  • Of course they will. Why would they not? Our app is magic.
  • "Our budget is tiny."
  • So, after spending hundreds of thousands of £££ on Maximo there is an expectation that adding a mobile solution must be achieved for next to nothing? Generally speaking, when it comes to mobile Maximo solutions you get what you pay for. There are exceptions, but the more you spend the better the solution. Adding a mobile solution, or upgrading to replace an inadequate or defunct one, is usually the best way to maximise the benefit of Maximo. The ROI can be swift both in terms of cost and data quality. Far more work orders can be completed, less waiting time for inventory, fewer mistakes made, SLAs can suddenly be met, fewer fines levied for non-compliance. Spend enough to get a good solution that meets all of your needs and is reliable. You will get the cost back and more.
  • "We want it tomorrow."
  • Of course you do! It is the way of the world now, whether it is the latest iPhone or a new car – it can’t come quickly enough. I just ask that you give your solution provider a reasonable amount of time to spin up the project team and do the implementation. I have honestly known customers spend two years working up to a mobile solution and then ask for a kick-off the week following the PO being issued.

The bottom line is that I suggest you consider the functional requirements before the examples I list here. All of the above makes for a good wish list and should be considered when comparing solutions, but do not lock yourself in to them being mandatory criteria.

Maximo Mobile ReviewAt Vetasi in our Mobile Centre of Excellence, we work with many mobile solution partners so that we can offer our customers a number of options and then work with them to implement a solution that provides the best functionality and value. Our consultants have many years of experience with each product and have encountered and overcome many real-world challenges. In addition to providing
sales of licenses and implementation services, we offer mobile selection workshops and pre-tender support so reach out if you have any questions or want our help.

In this article I talked about the high-level requirements and mistakes often made in selection. Watch out for a follow up where I will discuss some of the common functional requirements and how different solutions meet them.

About the author

A Certified Maximo consultant, Graham has over 17 years working in the Maximo community. In addition to managing global Maximo IT projects and services, Graham has designed and deployed Maximo applications and solutions for many industries including Defence, Facilities, Manufacturing, oil and Gas, Education, and Utilities . After retiring from the RAF Graham started his IT career as a the IT Manager for a Maximo customer. In 2007 he crossed over to the delivery side and moved to Texas to implement Maximo for CSC. His very first project sort of took him back to his aviation past when he upgraded Maximo for NASA at Johnson Space Center in Houston!

Graham is a Maximo Mobility specialist having worked with multiple mobile products and industries over the past ten years. He is now Vetasi’s Global Mobile Sales and Business Development Leader with responsibility for our Mobile Centre of Excellence.


Linked In

© 2013-2021 Vetasi Ltd. All rights reserved. Website by Zerotouch

  • English
  • Español
  • Polski
  • Русский