Category: Mobility (Page 1 of 2)

Most common use cases for Maximo Mobile solutions

For many organisations, when starting a mobile project, the stakeholders may not have prior experience with mobility solutions for EAM. As such, we are sometimes asked to implement features that do not add much value to the business. As consultants, it is satisfying to see something we implement being used and helps the end-users on the field. And nothing can be more frustrating than spending time building features that are not going to be used. In this post, I will talk about some commonly used and not used functions of a mobile app.

Work Execution

Despite its name is Asset Management software, 80% of activities in Maximo happen around the Work Management process. It is not a surprise work execution is the number one use-case for a mobile app. However, work management is a big process with a few major stages and many different activities. Only certain activities need to be recorded in the field with a mobile device. Below are some common ones:

  • Change Work Order status: start work, put it on hold, or complete the work
  • Record actual costs: travel time, work time, material consumption
  • Capture and attach photos
  • Enter work log
  • Capture operational parameter (meter reading)

By having a mobile device to capture these data on the field as it happens, organizations benefit from having much more accurate data. The last one is a key enabler for a comprehensive Condition Monitoring program which is an important topic and I’ll cover it in a separate post.

Physical Signature

The ability to physically sign on a mobile device sounds great. Most mobile apps has this function. I have implemented this a few times. The user can physically sign on a mobile device. The signature is printed at the bottom of some BIRT reports (e.g. Work Completion form or Risk Assessment form etc.). It looked great and the customers were excited about it. But in all honesty, I find it’s not really an important feature.

Work Planning and Approval

These are the activities that can and often be done in an office setting with the user accessing Maximo using a browser. The planning process can involve 3rd party scheduling tools like Akwire, Primavera, Visual Planner etc. Who would want to go to the field to schedule and assign people to some work orders on a tiny mobile screen? Some mobile apps do have the capability to do that, but it doesn’t mean we have to use it. These features are available usually for the field user to see the planned information, and possibly edit some incorrect details.

Inspection Form

Inspection Form was introduced from Maximo 7.6.0.8 as part of the Work Center module, and progressively improved in the last few releases. This is the best feature among those added to Maximo for the last 10 years. However, the Work Center interface is still too limited to be practical (UI is too slow, requires stable and fast connectivity, and not customizable).

EzMaxMobile does the job very well by providing responsive online and offline UI and works well with the out-of-the-box backend in Maximo. From my limited knowledge, Datasplice had Inspection app since at least a few years back, long before Maximo. That is because Datasplice is an independent system with its own database. There are inspection mobile solutions provided by industrial vendors too (e.g. Honeywell).

I don’t know how well these solutions work. My point is this is a common requirement and haven’t been addressed by Maximo until recently. By filling out inspection forms on a mobile device, data is fed directly to the meter reading tables. With this, condition monitoring can be setup in Maximo which raises alarms or PM work orders automatically.

Inventory Count / Stocktake

My first three mobile projects were to address this requirement, so, it must be a good use-case. The task is simple: the user scans a barcode, enters a balance value, then saves. Extended features could be adding a photo of the item, adding a new bin, or updating item specification which later can be used for the cataloguing and de-duplication process. The key to getting it to work is a really smooth and efficient user experience as these steps need to be repeated a thousand times in one shift. Fast and simple UI running in full offline mode is a must.

Me counting and capturing item spec at a time mobile solution wasn’t available. All data needed to be manually entered into Maximo by some interns later on

Inventory Issue/Transfer/Receipt

I’ve seen some projects involved these apps. In general, how often it is used and how much value it brings to the organization is not known to me. I think it does add value, but of course, not at the level of the Point-of-Sales solutions we often see in a supermarket.

Purchase Requisition/Purchase Order

Although PR and PO apps are available on some mobile solutions, I haven’t seen them used anywhere. There is some value for the field workers to be able to create Requisition. That function belongs to the Work Order module though. The data then flows to the PR application and handled by the backoffice staffs with a computer and a browser.

Risk Assessment/Toolbox Talk

This is a great use case for a mobile app. It is something that must be done on the field, it adds a lot of value in term of safety improvement and compliance. In many cases, it has some legal implication. Unfortunately, even the Oil & Gas (HSE) module in Maximo does not meet all of the requirement and usually needs a lot of customization. We had implemented this feature in EzMaxMobile for some clients. But the assessment forms and the compliance requirements are different in each industry and from company to company. Thus, I don’t think we can see a standard risk assessment mobile app for Maximo anytime soon. If your company needs it, you may have to pay for the customization effort.

A risk assessment form on iPad screen

A case for EzMaxMobile

I spend a large portion of my time working with mobile solutions, but I haven’t talked much on this topic. In this post, I will give a bit of praise to EzMaxMobile.

Why should you listen to me: I know a bit about mobile solutions for Maximo. I’ve done several (failed) pilots with the Maximo mobile suite (of the olden days). I’ve built a mobile app which is pretty successful and is being used by some large Oil & Gas operators. I have a bit of experience on a few small Anywhere projects, with Datasplice, and a few smaller home-grown apps.

Why shouldn’t you listen to me: the settings and the level of my involvement for each of the above projects/deployments are vastly different, as such, my opinion on this matter is heavily biased (toward EzMaxMobile).

Mobile devices used by a major marine port in Sydney

Back to the topic, as of today (2020), I think EzMaxMobile is by far the best mobile solution for Maximo. There are many things that InterPro (and Chon Neth, the original author of the popular Maximo Times blog) have done right with this product. Below are the 3 things I love the most:

  • Consistency with Maximo: EzMax uses the same business layer with Maximo and inherits all MBO business logic. It means, 90% of all logic customization done in Maximo automatically flows through to the mobile app. It includes integration processing rules, MBO java extension, automation scripts, security settings, and error messages. If you’ve heard of the phrase “the best code is no code at all”, you will appreciate to know that they’ve achieved exactly that with this product. On this point, EzMax is the clear winner when compared with Datasplice because EzMax is built for Maximo, while Datasplice is built as an independent work management mobile app that works with both SAP and Maximo.
  • A great open framework: in certain cases, there are still rules that need to be configured on the Mobile app only. For that, EzMax has a great framework that is very similar to Maximo architecture which consists of a core library (which we can decompile to understand the logic), and MVC components of which the source code is provided. Third-party implementers like me are free to modify and extend any logic to meet user requirements. The business layer is written in Java, as such, we don’t need to know native mobile development skills such as Android or iOS to customize the app. It definitely doesn’t need Android Studio and/or Xcode (which needs a MacBook), that’s another big plus. Having experience building mobile app before, I can tell it’s easy to build and deliver an app with a predefined specification. Most developers of home-grown apps will be stuck at that, building and implementing their own app. Ability to build an open framework and enable 3rd party implementers to build and extend on top of that is a totally different level. So just for this point alone, my hat’s off to you, Mr. Chon.
  • Instant development loop and ease of deployment: this is probably what I love the most when working with EzMax. Instant development loop means immediately after updating the code, I can see the result. On production, full redeployment takes 5-10 minutes. However, most small changes can be done on-the-fly without downtime, and users see the change immediately. On other platforms where compiling the code to native iOS/Android app is required, we usually have to wait for 10-30 minutes to compile the code in XCode/Android before you can run it. Then redeployment, then users have to re-install the app. Although it doesn’t sound that interesting to the business users, it will directly translate into the much higher overall productivity, and thus, lower cost for the customer. In a recent project I involved, it took me less than 10 hours of dev work to cover minor screen changes which include 100+ fields in about 20 app screens. For Anywhere, it’s likely to take me one full man-month or more, not to mention, many of the changes wouldn’t be possible in Anywhere in the first place. (And a small note: when a developer loves something, it directly leads to a much higher quality product and happy users; when a developer hates something, it means glitches, frustration, and meeting room arguments)

To be fair, there are certain things I don’t like about EzMaxMobile. For example, Offline mode has a different code structure, i.e. any screen changes need to be done twice for the online and offline screens. Besides, Offline functionality is also more limited than Online. This is the inherent problem with any offline mobile app. Think about it: an offline app will need all 3 layers: database, business, and UI in one mobile device. In other words, full capability means you need the whole Maximo system running on a mobile device, which is impossible. However, on this aspect, Anywhere does provide smoother transition between Online and Offline. Anyway, it doesn’t really matter much when Anywhere’s capability is too limited in the first place.

Inspection app provides a mobile-friendly UI to the Work Center Inspection app and offline capability

Again, this is my personal and very biased view. I currently work for a company which provides EzMaxMobile implementation service (means I spent a lot more time working with EzMax). However, I don’t have any involvement in business development, thus I don’t have any obligation or receive any benefit for promoting it. In fact, we do provide implementation services for both EzMaxMobile and Anywhere. However, I think compared with Anywhere, EzMax is far more practical. In my opinion, IBM would do the Maximo world a favour by ditching Anywhere and acquire Interpro.

As for the Maximo users, I cannot say in general which mobile solution is the best for you as there are many other options out there (e.g. EAM360, Informer). It also largely depends on what local providers are available in certain countries and the products they use. Most of the time, the success of an implementation depends on the consultant, not the product. Thus, my suggestion is, if you are thinking about implementing a mobile solution, don’t just blindly go for a “default”, brand-name solution. Do your homework by getting quotes and demo on a list of specific requirements. For mobile solutions, the requirements are usually simple, focusing on a few tasks that add value to a worker if done on the field. It is not difficult to define specific requirements during the RFx processes. If you don’t know what the requirements are yet, do a small pilot with an out-of-the-box installation first. License, server, and installation service are cheap. It’s the customization that costs the most. How about starting with a trial license or 5 named-user licenses, no customization, then get some feedback from the field guys? It’s not a bad idea to do a dual pilot, then comparing products side-by-side. I’ve seen one or two clients who did just that, and it saved them a lot of money and frustration over the long run.

Process Inbound Twilio SMS message in Maximo

In my previous post, I provided some demos on how we can process inbound text messages to create SR and route Workflow. There are a few people on LinkedIn asked me how to do it. I also like to explore the option of integrating Maximo with Twilio directly without the need for AppConnect. With Maximo 7.6, we can create a simple API using automation script. To prove the concept, the video demonstrates how we can create a simple API with automation script and direct Twilio HTTP requests to Maximo:


Below is the source code for the script in the video:

In this case, for the sake of simplicity, I only include the bare minimum components to make it works. You will probably want to write some scripts to automatically populate the “Reported By” person based on source phone number and populate other details like location/asset number based on the content of the incoming message. Also, it would be nice to respond with a text message for confirmation and provide the users with the new SR number.

With this method, we’ll need Maximo to be accessible from the Internet, it’s is not a problem for a cloud-based system. But if you have an onpremise system, you’ll need to configure port-forwarding to make Maximo accessible from the Internet. For development, since my ADSL router does not support port-forwarding, I used a tool called ‘ngrok’ to forward access of my local Maximo to the web via ngrok.io

The Scripted API is a new feature in Maximo 7.6. Thus this approach won’t work if you have an older Maximo version. It that case, probably using App Connect is an easier option. With App Connect, I used it for two functions:

  • Act as an API gateway to route Twilio request to a local server
  • Quickly transform HTTP request to REST/JSON request which Maximo can easily consume

App Connect is just a fancy name for a newer version of IBM Integration Bus (which IBM now call it App Connect Enterprise) and a bunch of new cloud-enabling features. So you’ll need some basic understanding of IIB in order to set it up. For connecting App Connect (the cloud component) and local Integration server, I followed the tutorial here: link

Send SMS Notification from Maximo using Twilio

Email or SMS Notification?

Occassionally, someone would ask me if we can configure Maximo to send notifications via SMS. With Maximo, the answer to such questions is always Yes. However, with this one, it will cost some money, very cheap though.

Since it is not free, I would say for most Maximo notification scenarios, the user would be ok with email notification which is free. However, there are certain scenarios where SMS notifications can add value such as:

  • Notify a field worker when a new high priority Work Order is assigned to him/her
  • Notify an asset owner when the asset deviates from the normal operating parameter range or when downtime is reported
  • Notify Maximo admin when there are repeated login attempts from an uncommon IP address or when there is a major problem tracked by the Escalation app.

In the section below, I provide the detailed steps on how to set up a trial Twilio account and send notifications from Maximo

A. Setup a Twilio trial account

With your trial account, Twilio will give you a small initial balance to buy a phone number and use the service. I got $15, and it will cost me $6 to buy a phone number, and 5 cents to send a text message.

  1. Create a trial account on Twilio.com: you’ll have to use your real mobile phone number to verify the account.
  2. Login using your trial account, go to Console, then create a new Project. Select “Products”, then choose “Programmable SMS”. Give your project a name, for example: “Maximo”. Then skip the rest of the steps to create the project
  3. On the left menu, click on the icon with the title “Programmable SMS”. In this menu, open the “SMS” submenu, open the “Messaging Services” page, then click on “Create new Messaging Service
  4. Give the messaging service a name, such as “MaximoNotification”. For use case, choose “Notifications, Outbound Only”. Then click on Create
  5. After the messaging service is created, open it. On the left menu, click on Number to open it, then click on “Buy a Number” to purchase a telephone number. On the pop-up, select your country code, then click on “Search”. It will give you a list of numbers to choose from
  6. Choose a number with SMS capability, and click on Buy. Depends on the country you live in, you may have to enter some details for your new number. I’m in Australia, so I have to enter my address.
  7. After purchasing a number, you are ready to send SMS messages from your Twilio account.
    Please note: with Trial account, it can only send SMS messages to a Verified Number. Your mobile number which you entered when registering is automatically added to this list. So you will be able to send SMS to that number. But if you like to send SMS to a different number, you’ll have to add it to the ‘Verified Caller ID’ list first.
  8. Go to “Console Dashboard”, open the “Settings” sub-menu, then open “General” page to take note of your Account SID, and Authentication Token. You will need it to send an SMS from Maximo.

B. Configure Maximo to send REST requests to Twilio

There are different ways to set this up depending on your requirement. In this example, I’ll create an ‘Action’ automation script, and send a REST request using Apache HTTPClient library. Action auto script can be used with Workflows or Escalation. In this example, I’ll send out an SMS when the workflow is initiated on the Service Request application.

The setup steps are as follows:

  1. Go to Automation Script application, create an ‘Action launch point’ automation script. Give the launch point a name, for example: “SENDSMS”. Set the action name as “SENDSMS” too. Set “SR” as the main object. Select “Jython” for script language. For the script, copy/paste the example code below to the “Source Code”
  2. With the code above, replace {YOUR_ACCOUNT_SID}, {YOUR_AUTH_TOKEN}, {YOUR_PURCHASED_PHONE_NUMBER} with actual details of your Twilio account. For testing purposes, replace {RECIPIENT_PHONE_NUMBER} with your phone number. Later on, once it works, you can replace it with a variable retrieved from your record using mbo.getString()
  3. Create a new workflow “SEND_SMS” for the SR object, connect the Start and Stop node with one line. And set the line to use ‘SENDSMS’ action. After that, Enable and Activate the Workflow. And remember to Add Workflow to SR application using the Select Action menu if you haven’t done so.
  4. Open an SR record, then click on the route button to initiate the “SEND_SMS” workflow
  5. After clicking on the Route workflow button, you should be able to receive an SMS message on your phone:

Source Code:

In a later post, I’ll talk about integrating Twilio with Maximo to create new Service Requests via SMS. For now, good luck with spamming your end-users with endless work requests 🙂

Barcode/RFID Scanning for Maximo Everyplace

I’m in love with Maximo Everyplace. It is so simple and easy to use. And guess what, it is totally free now with Maximo 7.6.

Recently I worked with a client and while the team still discussing various options for mobility solutions, I quickly duplicated and produced an Everyplace mobile app on Test environment and demonstrate a smooth workflow with barcode scanning on my iPhone, all done within 15 minutes. I understand there are certain reasons for choosing a more complex online/offline, even native app solutions. However, since everyplace is so easy and cheap to implement, so why not have it as a backup solution just in case the more complex one doesn’t work. If you have experienced the use of such offline, installed app solution, you will know what I’m talking about. Things like app crashes or hang are quite common. Those things are usually quite difficult to support as the programmers, who for 99% of the time are present not onsite and do not have access to log files to see what happened to investigate and provide timely bug fix. In this case, for the end-users it is extremely frustrating as they cannot proceed with their work.

One of the most common requirements with mobile app is ability to scan barcode to quickly search for asset, location, inventory item code, or work order number. Since Everyplace runs on browser, it doesn’t have a way to work directly with smart phone or tablet’s camera to read barcode. One solution is to use barcode scanner custom keyboard. This has been mentioned earlier in other blog posts such as by Bruno Portaluri (link) on how to use Barcode scanner keyboard app or IBM Android app for Everyplace. These are all Android solution.

With iOS, for many years, the only option is to use external barcode scanners because Apple restricted its custom keyboard API from accessing the camera. However, I recently found out about this app: ScanditWedge which does exactly the same thing, but now on iOS. The license for the use of their app is quite expensive though. But at least, now we know something like this is possible on iOS. I tried their trial license which allows the use of the keyboard on 20 devices for 2 weeks and it works like charm on my iPhone. So, this is definitely something you can consider.

For RFID, with built-in NFC reader on many Android devices and NFC scanner keyboard, it is possible to work with Everyplace. I have built native app and utilize the internal NFC reader of the ECOM Tab-EX (designed based on the Samsung Tab Active) and the ECOM Smart-Ex 01, and 02. All of those have been implemented and proven to work well under industrial settings. However, currently I do not have access to such device to test the newer NFC scanner keyboard apps. But I believe they would work the same with barcode scanner keyboard (You may need a separate field to store RFID tag’s ID string for this purpose).

On iOS, it’s been a long story. Apple introduced NFC support since iPhone 6, but the hardware acts as a passive RFID tag, used for ApplePay only. They restricted API access to 3rd party developers. Only in the latest iPhone 7, iPhone 8, and iPhone X, the hardware can actually act as a scanner, and with recent release of iOS 11, Apple have opened API access to 3rd party developer to read stored information in RFID tag (not tag ID). The demo video below by Serialio clearly demonstrated this capability.

I’ve personally tested this capability on iPhone 6 Plus and iPhone 7 plus using GoToTags and can confirm it works with iPhone 7. So this is another great news because we now know that it is technically possible to use iPhone to scan RFID and identify Asset/Check Point/Labor etc. (although not very convenient to setup).

RFID/Barcode and Integrated Mobile Solutions for Maximo

      I had to look at RFID/Barcode options for Maximo mobility solution recently. Although these technologies have been around for decades and have become a commodity, when integrating with other systems like Maximo Anywhere or Everyplace, there are certain problems that we have to deal with. In this post, I’ll discuss a few concerns related to this topic, hopefully it helps Maximo consultants to save some time when considering the solution. These are just a brain dump of different things related to the topic that I have in mind. Thus, you can read them at any order or only look that the part that you are most interested in.

  • Barcode vs QR code: When it comes to barcode reading, many people think that they can simply use the built-in camera of the phone or tablet to read barcode, as seen in many product comparing apps. However, in industrial setting, one should consider various extreme conditions that field workers have to work in. For example, in construction or in oil & gas, working at night is common. In such case, the camera doesn’t do well in reading barcode. In some of our tests, under pretty good ambient light, reading barcode takes up to 3-5 seconds while QR code reads almost instantly. In poorer conditions though, the camera simply couldn’t focus and can’t read anything. Thus, if the requirement is to work in environment where lighting condition is always ideal, Barcode or QR codes doesn’t matter, I’m a bit lean toward QR code as it read faster and enable higher workflow efficiency. Otherwise, we should consider other options such as RFID or using laser barcode reader.
  • Barcode vs RFID: When it comes to barcode (QR code is included in this category) versus RFID, they have very different attributes that one should really think carefully before deciding on which one suits their requirements the most. Many of the better features of RFID do not apply in certain asset management application. For example, RFID tags don’t need line of sight to be read or RFID can be read in bulk simultaneously. However, in asset identification, these are usually not required. However, one feature of RFID that is a clear advantage when compare to Barcode is that RFID tags can be a lot more durable under extreme conditions such as in processing plants where conditions usually involve high temperature, high moisture, and can be tampered with chemical/oil, even the some of best weather-resistant barcode label brands can wear out/fade out pretty quick (in few months). In this case, RFID tag is a clear winner. On the other hand, if working under extreme conditions is not a requirement, I would generally suggest using barcode as it is much cheaper and simpler to use. For example, we can encode Asset Number or Inventory Item Number directly to print out barcode labels, and on Maximo apps, we will just scan and lookup barcode using the standard “assetnum” and “itemnum” fields. If RFID is to be used, we generally need a separate custom field to store the tag’s ID string. Then we have to customize the app to lookup asset/item using this field instead of the standard asset/item number. We also need an extra step of reading and updating the tag’s ID string into the record in Maximo before it can be used.
  • Built-in camera/NFC reader vs specialized reader: Here I’m discussing about the pros and cons of using built-in camera or NFC reader (NFC is one form of RFID) versus using a specialized, external Barcode/RFID device. Built-in reader is obviously simple and more compact, thus it is suitable for occasional use. However, if your application requires frequent reading of barcode/RFID, you should go for a specialized laser barcode reader or RFID reader. These tools are designed specifically for the job, as such, it is a lot more efficient and easier to use. As mentioned above, using the camera to read barcode under poor ambient light can be problematic, but if a laser reader is utilized, poor ambient light is not a problem as the device has its own laser light source, and thus can read under any lighting condition. When it comes to industrial use, invest in specialized tool can be a bit more costly but almost always give a much better return in term of improved productivity and user acceptance. One thing to consider with external reader is that, field workers usually has to wear/carry many accessories such as PPE equipment, walkie-talkie, safety-belt, and other work-related tools. The idea of having to carry an extra phone/tablet and an external reader doesn’t sound convenient. As such, one should consider higher level of resistance from field workers if external reader is introduced. Another drawback if you consider external bluetooth scanner is that the pairing-up process between bluetooth devices and smart phones sometimes aren’t straightforward, these kind of glitches can sometimes create additional reasons for the workers who resisted to change to pushback and refuse to use the solution. As such, if possible, choose devices with built-in or connected laser barcode/RFID reader over wireless devices
  • iOS vs Android: Almost everyone prefers using an iPhone or iPad over Android devices. However, iPhone and iPad is designed for consumer market. When it comes to industrial use, iOS devices have many shortcomings such as they are not designed to work under extreme conditions such as under rain, hash sunlight, or sensible to touches when worker wearing thick gloves. Apple is also more restrictive in term of providing API for 3rd party developers, as such, there are less options provided by 3rd party vendor when it comes to industrial application. In the Energy and Mining industries, the use of intrinsically-safe/non-explosive (EX) electronic equipment is mandatory. This make Android platform the only option as currently, there is no iOS device on the market that can meet this safety requirement. Over the last few years, many companies introduce various computing devices such as smart phones, tablet, and even laptop meeting this standard. Some of those companies includes ECOM, Honeywell, Motorola etc. Therefore, if you design a solution for use in Hazardous areas that requires intrinsically-safe equipment, forget about iOS.
  • Online only vs Offline support: Here I’m only talking about Maximo Everyplace versus Maximo Anywhere. From Maximo version 7.6, Everyplace become a built-in feature. As such, it doesn’t cost anything to use. The process to produce a simplified app by duplicating an existing Maximo application then modify it to fit into small mobile  screen and to do a specific task generally takes only a few hours to a few days maximum. The users who are already familiar with Maximo will virtually don’t need any training at all. As such, if working environment has available wireless LAN or 3G/4G internet connection (which is pervasive and very cheap now), you should go for this solution, it’s a no-brainer. However, in certain conditions, stable connection is not always available, such as inside deep tunnel for infrastructure company or inside confined-space/basement of a large building. In this case, we need to use Anywhere to support offline/online working mode. However, let’s be realistic here. Do your field workers really need to use Maximo app when going in a confined space? In a client who I had chance to work with recently, they said they need offline solution because Everyplace won’t work inside underground tunnels. I went around to check and found out that in most areas inside underground tunnels, 4G network is fast and stable. Some areas may have poor signal. But with standard work order process, we generally only need access to the app to check-in when starting the work, and to check-out after the work is done. In this case, identify and designate several safe areas where network connection is available to check-in and check-out would do the job. With the widespread of 3G/4G repeaters installed by network companies,
    you might not realize that 3G/4G network is now available in many areas
    where it was not possible before like inside tunnels, underground train
    stations, or parking basements of big buildings.

          For other applications such as asset audit/inspection, where users need to use the app to scan the equipment or check-point, if network connection is unstable, offline solution will be required. 

    Maximo Anywhere is a great offline solution because it provides very smooth experience when transition between online/offline working mode. However, it comes with a price. It is very expensive in term of license fee. It is also a complex platform that requires MobileFirst development skills to configure/customize. Keep in mind that this is still a relatively new solution and not widely proven in the industry, especially when it comes to integration with other 3rd party hardware/software. However, IBM team have been moving really fast with the development of this solution. In the past few year, the solution has seen considerable improvement and level of adoption by the asset management community. So kudos for IBM R&D team for this progress.
    Considering the significant cost of Anywhere product, we should carefully survey the work environment and take these aspects into account when considering the two solutions.

  • IBM Mobility vs 3rd Party Solutions: When it comes to mobility solutions for Maximo, most people immediately think of IBM’s mobility solutions which includes Maximo Mobile Suites (gone), Maximo Everyplace, and Maximo Anywhere. However, to make objective evaluation, one must go further than that to evaluate 3rd party mobility solutions such as EzMaxMobile, Datasplice, Syclo Work Manager (now SAP), and many other lesser known custom-built systems. (eLogBook mobile is one of such solutions which I and my team built when working for Avenue Business Solutions). The advantage of IBM mobile solutions is that they are open platform. Therefore, any Maximo consultant with the right skill can customize the apps without IBM’s restriction as long as the users have the right license (which can be very expensive). The problem with IBM solutions is that they don’t always work in practice (e.g. the notorious Maximo Mobile Suites), too complex (Anywhere/MobileFirst solutions), having limited support from IBM (tickets generally take months to resolve or not resolved at all), or having limited material available for developers to customize/integrate. Gartner over the last several years have been putting IBM mobility solution under the “Cautions” section. Only in the recent 2017 report they say something a bit more positive about it which reflects recent development in IBM Mobile First strategy and the Anywhere solution . Third-party vendors on the other hand usually have consultants available to come in and guide clients to design process and implement their product properly and with much lower cost. They are usually smaller companies with dedicated people working in mobility space, as such they can provide a much better integrated solution with proven integration modules, software, hardware options and best practice recommendation for processes. Mobile apps provided by 3rd party companies can be less customizable than IBM’s product, and client usually have to rely directly to the vendor to provide 3rd level support, but they are usually very well designed to achieve high efficiency and smooth user experience. Overall, implementing these solutions are usually much more cost effective, provide better ROI, and client usually see much higher success rate.
« Older posts