Author: Viet Tran (Page 5 of 14)

Most common use cases for Maximo Mobile solutions

8 August 2020 / Viet Tran / 1 Comment

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

1 August 2020 / Viet Tran / 2 Comments

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.

String Concatenation in WebMethods

29 July 2020 / Viet Tran / 0 Comments

Manipulating string is probably the most frequent operation we need to do when transforming data. Thus, I’d like to talk a bit about string concatenation in WebMethods. The most basic way to add two strings is to use the pub.string.concat service in the WmPublic package as shown below:

Image 01. pub.string.concat service

However, this approach is way too limited. For example, to combine a Unique ID string which consists of a Prefix, an auto ID number, a Suffix with separator in between such as: WO-10012-CM, we’ll need to use at minimum 4 lines of code, and a number of temporary variables. That’s crazy.

An alternative approach is to use variables substitution when assigning values to a variable as shown below. In this case, we can build a new string from an unlimited number of variables in just one line of code.

Image 02. using variables substitution

This approach doesn’t work if one of the input variables can have a Null value. In that case, it will give us an unwanted result as shown below:

Image 03. Bad result when input is Null

With Tundra library, we have a much more flexible tundra.string.concatenate service. It allows us to add unlimited number of strings in one line, and at the same time, have some other capabilities such as adding separator.

Image 04. Use tundra.string.concatenate

In the example above, I can achieve the same result in one line of code, and the tundra service is smart enough not to add the second separator when the $suffix variable is Null.

However, beware of the annoying bug with WebMethods that it doesn’t have ability to set the order of input variables. Thus, when you make an update to one input, for example, in the example below, I changed the input variable str2 to map it to a different variable, it will move to the bottom of the list, and thus, messed up the final output.

Image 05. Last updated variable is moved to the bottom

A workaround is to update the other variables manually to correct the order. But from my experience, anything having more than 3 inputs will be a maintenance nightmare.

Image 06. A “quick” update messed up the order of concatenation

The more robust approach is to write our own concatenate service as part of a common service package. It can take a bit of time, but if we have a big project, it’s worth the effort in building some common service library to be reused across the entire environment. Ten minutes spending on building this service can save the whole team countless number of hours in development and maintenance.

Edit: After reading this post, Lachlan Dowding, Tundra library’s author, told me we can use String List to workaround the WebMethods’s bug on changing the order of input strings when using the Tundra’s concatenate.

Play around with Map control in Cognos Analytics

28 July 2020 / Viet Tran / 0 Comments

There’s been quite a bit of talk recently on the web about the new partnership with MapBox to deliver new map capabilities to Cognos Analytics (and there isn’t much talk about the discontinuation of support for ArcGIS in this new version). I decided to spend a bit more time to learn about the map functionality in this new Cognos version. The best way to get to know something is by doing it. So I cooked up some “real” requirements and tried to build a few dashboards.

The first one, I like to see whether a change in average temperature will affect the number of calls to fix break/leak issues related to water supply piping system, and whether a change in average rainfall will affect number of calls related to sewage/drainage systems. The data should be broken down to suburb and post-code level. Below is what I got:

For the second one, I like to compare the average planned vs actual labour hours spent on maintenance work, and the amount of time field workers spent to get to work location vs the amount of time spent on doing actual maintenance work. The purpose is to see whether there is a difference in remote areas and if it affects planned vs actual ratio. Below is what I got:

Overall, I am impressed with the ease of use, the responsiveness, and the level of interactivity of this new Map control in Dashboard. However, through this exercise, I found there are quite a number of limitations to this new map control:

This map control is only available in Dashboard. With Report, and Active Report, a different version of Mapbox control, and older map controls are available. However, they are both a lot less interactive and much more limited in functionality.
It only supports X/Y coordinates, thus, if your data is easting/northing, it needs to be converted to X/Y coordinates first.
For high-lighting map regions, Australian Postcode is supported and is the lowest level of detail. High-lighting suburbs is not supported, the lowest level of detail is council/city regions and the region names must match with the Mapbox pre-defined list. Thus, some level of data cleansing must be done if the region names in your data doesn’t match exactly with the city/region name in this list.
It is possible to upload custom maps to MapBox to achieve more refined areas, however, there was an issue with MapBox changing the way to manage Layout ID. The issue is only corrected with newer versions of Cognos (from 11.1.x). Thus, this custom map function doesn’t work with older versions (including v11.0.11 which is bundled with Maximo)

Implement If-Then-Else Logic in WebMethods

28 July 2020 / Viet Tran / 0 Comments

Conditional Logic is the most important building block of any software development tool. WebMethods is not a programming language, but since we use it to build integration interface, which is also software, it means we are also programming with it. Writing a simple “If-Then-Else” condition in WebMethod is way too verbose to me though. The official tutorial on SoftwareAG teaches us to implement an if-then-else logic using the Branch, Sequence, and Map nodes as depicted in the sample below:

As we can see, one simple If-Then-Else condition will require at least 5 lines to achieve. A more complex Case condition with multiple branches can take up half of a screen’s real estate. This makes the code harder to read.

My preferred alternative approach is to use the “Copy Condition” when mapping variables as shown below:

If the condition specified in this “Copy Condition” is True, the value will be mapped from the left-side variable to the right-side variable. In this case, value of the $valuelist/Approved variable will be mapped to the $output variable if condition $var1 = ‘A’ is True.

To achieve the default (Else) branch, we use the NOT (!) operator such as:

! ($var1 = ‘A’ OR $var1 = ‘W’ OR $var1 = ‘C’)

By doing this, no matter how many conditions we have, we can fit everything in one line.

My failed attempt to get Maximo to work with Azure SQL database

25 July 2020 / Viet Tran / 6 Comments

Recently, I started playing with Azure by attempting to migrate a Maximo instance from my local VM to Azure platform. Although the attempt was a success. I didn’t realize SQL Server and Azure SQL are different databases (or more correctly, two different versions). There were a few issues during the process, but I figured out how to work around them and got Maximo running on Azure VM and Azure SQL. After sharing the result on LinkedIn, there were some comments that Maximo couldn’t be installed on Azure SQL and IBM doesn’t support it, so I spent a bit more time digging and thought I should share the details and some of my opinions on this matter.

First, let us be clear, Azure is a big cloud platform which offers many different services. I’m not a cloud expert, but from what I understand, we are talking about two main services:

Azure VM: which is IaaS and it lets us run a virtual machine on the cloud. You can run many different Windows or Linux versions on it; it is transparent to the standard business applications (Maximo). In other words, there shouldn’t be any issue running Maximo on Azure VM as long as you stick to the OS versions supported by Maximo. For example, when referring to Maximo 7.6.1.1 Compatibility matrix, Microsoft Hyper-V 2012 and 2012 R2 are supported, and with them, Windows Server 2012 and 2016 are supported as Guest OS. In fact, many companies large and small are running Maximo on Azure VM.
Azure SQL: is a cloud version of SQL Server. It has the core engine of SQL Server database, but certain aspects of it has been modified to work on a cloud environment and to support multi-tenancy. Current version of Maximo doesn’t support Azure SQL, and IBM don’t have any plan to support it in the near future with Maximo 7.6.1.x and 8 (according to their 2020 Roadmap).

Even with that knowledge, I was still curious on whether I can make it work from technical perspective and did a few experiments:

A – Installing Maximo 7.6.1 from scratch on Azure VM and Azure SQL:

People mentioned that Maximo cannot be installed on Azure SQL, so I did just that, just to know what exactly the issue is (and secretly, I hoped I could fix
it). I followed the standard Installation process and managed to install
Websphere, prepare the environment, and install Maximo SMP.

After SMP was installed, I couldn’t get the Configuration tool to connect to Azure DB because it couldn’t resolve the DB Alias provided by Azure.

I attempted to execute this step manually using command line by setting up the
maximo.properties file, then run the maxinst.bat tool. However, DBC script failed when it ran an undocumented DBCC ‘CALLFULLTEXT’ command:

To be honest, installing a fresh Maximo DB on Azure SQL shouldn’t be a problem from technical perspective, because we can always install it on an on-premise SQL
Server, then put it on to Azure SQL (using the process I described in my previous post). However, this is definitely a failure.

B – Upgrading Maximo from 7.6.0.6 to 7.6.0.9

It is critical to be able to upgrade and install updates, fix packs, or industry add-ons. From technical stand point, all of these activities are essentially the same process; it involves running a large number of DBC scripts, which mostly consists of SQL commands. I wanted to see if it works on Azure SQL.

I started out with a simple task first: upgrading from Maximo 7.6.0.6 to 7.6.1. To do this, I simply replaced the existing 7.6.0.6 SMP folder installed previously with a new 7.6.1 SMP folder, then run the updatedb tool. On the first run, I had several issues related to incompatible collation between “Latin1_General_CI_AS” (default setting of on-premise SQL Server) and “SQL_Latin1_General_CP1_CI_AS” (the default value of Azure SQL’s databases, which can be changed, and the ONLY supported collation of master and tempdb).

Changing a database collation is a complex job which involves updating the value at all three levels: database, table, and column. To do it, we have to drop all indexes and constraints on the tables, then run the update script, then re-create the indexes. I only wanted to find out if upgrade is possible, so I tried again with a fresh Demo DB created with “SQL_Latin1_General_CPI1_CI_AS” collation. The upgrade is successful this time. So, that is a small success.

C – Install Add-ons

Next, I tried installing some serious industry add-ons (Scheduler 7.6.7, Oil and Gas 7.6.1, Utilities 7.6.0.4, Control Desk 7.6.1) on top of the working instance from the previous step. These are probably the most complex add-ons we could get for Maximo. As such, if it worked, there wouldn’t be any problem to get it to work with any future upgrade/update.

The process failed when it tried to run some scripts belong to the ICD add-ons. This time, it had an issue when trying to access object spt_values in the master DB which will never be given in a multi-tenancy cloud environment. There were a few posts on the web showing us how to work around this issue. But I stopped that this, and that is the end of my attempt. There’s no point in trying to spend too much time in getting something to work knowing it is not supported by IBM (unless there are some clients willing to pay for my time doing that in the future)

Conclusion: the result of this process confirms what others have reported, Maximo doesn’t work with Azure SQL database. Although the issue with collation can be worked around (with a lot of effort), there are more than one issue with various DBC scripts requiring access to the master DB which is not possible in Azure DB. For people with extensive knowledge on DBC scripting and custom DBC handler, they might be able to modify the problem scripts to get it to work, but that is definitely not supported by IBM and the effort cannot be justified in my opinion. As support for Azure DB is not on the road map. At this stage, our only option is to use on-premise DB version installed on the cloud as a separate DB server.