Maximo Mobility Myth Busters Part Two
Part Two - A philosophical look at customisation vs configuration.
“We have spent millions customising Maximo to get it to meet our unique processes, now we need an off the shelf mobility solution that we can plug in and will just work”
In this post, I am going to discuss the RFP myth of an entirely Commercial Off the Shelf (COTS) mobility system as being suitable to meet an organization’s unique business processes. There are many thousands of Maximo customers worldwide. They span many industries and each has its own way of doing business. No two of those many thousands of Maximo instances are alike. They have been altered through various methods of configuration or customization. So is it reasonable to expect that any mobile add-on for Maximo can be implemented without modification, and match those processes? More importantly, is it reasonable to expect that a mobile solution designed to support the widest possible range of processes can deliver a streamlined user experience that helps walk your users through their work, and supports compliance with corporate or regulatory requirements?
No, it is not, of course. A tool that truly supports a process, rather than merely accommodates it, delivers incredible value in the form of user experience and, as a result, in user adoption. At the end of the day, user adoption drives ROI, so it is critical that the app be able to reflect your business as much as your Maximo implementation does. And in fairness, most organizations allow for some App modification in their RFPs when it comes to the requirements. The real issue then is configuration vs customization.
“Customization” has become a dirty word in the context of software applications. Rightly so, in some cases. A heavily customized enterprise application becomes a monster, especially when it is time to upgrade. This is especially true of Maximo with its twice-yearly release schedule and a long history of customization by customers. But should the same rule, the same level of resistance to customization, apply to all applications within an enterprise? I would argue that it should not, and (no surprise!) I am going to discuss Maximo Mobility as a case in point.
There are two aspects to this. The first is whether or not customization is acceptable at all, and I will tackle that one today. The second is where the line is drawn when defining customization vs configuration. To put it another way, when does configuration actually become customization?
If you accept the premise that there should never, ever be any customization of your mobile App you are accepting that the product is suitable to meet all of your needs and desires. Or, you are accepting that those needs and desires that cannot be met are acceptable collateral damage. In other words, you are accepting a level of compromise.
In the customization vs configuration debate, the primary argument against customization is the upgrade path for the App. That makes sense when looking at ERP systems, but not so much for peripheral tools such as mobility solutions. As mentioned already, Maximo has a twice-yearly release cycle that includes changes to the platform at all levels. If it is not stored in the database it is open to being overwritten in the upgrade process. Twice-yearly. That can get very annoying and is time-consuming to mitigate. Maximo is also huge, highly complex, and fragile. It needs to be nurtured and treated with kid gloves. For those reasons, Maximo comes with large support staff (in-house, partner, or both) working constantly to monitor, maintain, fix, tweak, enhance, and upgrade it.
When you select a Mobile App, it is for a specific purpose which is a small subset of what Maximo can do. It is a point solution with limited scope. You want it to be the best at doing that small thing, without compromise. You want it to do exactly what you want, no more and certainly no less. You need it to be reliable, easy to use, perform well in all situations, and to have all of the necessary data ready to go at any time. You need it to be intuitive to use, with little or no training. You also need it to be easy to support and maintain. All of that has to be considered within the context of your specific requirements and workforce, not those assumed by the vendor.
Once you have selected and implemented the chosen solution that meets all of those requirements, how often do you need to upgrade it? With Maximo, each fix pack release comes with multiple bug fixes, enhancements, improvements, and new features. If you just need one of those, you have to get all the others even if you don’t use them. And that approach makes sense for ERP systems. You also have to consider that vendor support for ERP systems only goes back so far. There is pressure to upgrade to stay supported. However, the same does not generally apply to mobility solutions.
A good mobile solution, when deployed well, will last for many years without a need to upgrade. There may be a need for fixes but these will generally be quite small and will not require a total overhaul of the App. Typically they are a result of changes to the device operating system or to Maximo. Occasionally a new hardware device may require a modified SDK to use a peripheral. Sometimes a bug will emerge in the App software. It is also true that business process change necessitates App modification. All of these can be fixed quickly and easily without a major upgrade.
If we destroy the myth that upgrades will be both hard and frequent enough to be a big deal, we can then look again at whether customization must be avoided at all costs, and what that actually means in terms of upgrades. In my next post, I am going to look at the pros and cons of customization in more detail. We will also explore what configuration and customization mean within the context of Maximo Mobile Apps.