How an incorrect problem classification can prevent management prioritising an important fix ( #fewCallsNoProblemsMASMaximo )

If you are relying on help desk calls to assess the health of your system then it is important to ensure that the calls are classified correctly...

In this case a serious interface design issue was being hidden because the issue was being logged as “user error “

Working with multiple customers means that I see some of the same problems

One problem is the approach to issues. Once the initial irritation has passed then there can be a weary acceptance that the problem has to be lived with and this acceptance removes the push to resolve the underlying problem.

The underlying issue

Maximo allowed users to enter a value of up to 200 characters. Maximo was interfaced to another system. Users created records in Maximo and these were then automatically transferred to another system.

The destination system only allowed 150 characters in the same attribute.

Neither system was changed to modified to use a common length. The project team decided that the solution was to teach users that they must only ever enter 150 characters ... even if Maximo allowed them to enter more.

Users often forgot or didn't obey the advice to limit the number of chracters.

This regularly led to failures when trying to transfer transactions between the two systems ... and it had a knock on effect of delaying financial transactions.

The interface transaction was only triggered after the record was successfully saved so the user had no visibility of the error until someone contacted them asking why they hadn’t created the record. The business processes meant that the missing record may take several weeks to be spotted because the processes at the receiving end only checked the records at the end of the month.

This meant raising help desk calls to investigate what had happened and to get the data corrected.

The issue wasn’t picked up in testing because no one thought to enter a long piece of text in the field. When it was detected the implementer’s initial response was tell the user to “count the number of characters and keep it below 150”

It was an impossible request given the amount of other work that the user had to do ; the result was that the users forgot and transactions failed. A call would be raised with a root cause of “user error“ when the real issue was the interface design.

Anyone analysing the call statistics would have just seen lots of “user errors” without understanding that there was a serious interface design error.

Having a support person regularly working in that area meant that they could identify the pattern and put together a series of options ...

Options included :

1.???? Telling the users never to include more than 150 characters. This led to an interesting culture clash because the implementer’s culture meant that these types of rules were naturally followed, while the users were more inclined to enter the value that they wanted to

2.???? Adding a label to remind the users to count the number of characters – this led to questions about why the system couldn’t do the count

3.???? Add a validation to check the length of the value and then tell the user to reduce the length of the value – testing showed that this generated intense frustration

4.???? Add a customisation to automatically reduce the value by abbreviating certain words – this risked generating messages that made no sense

5.???? Letting users enter a long value but then automatically cut the value short when the value was transferred to the other system – this led to situations where the record in the other system was useless because important data had been put at the end of the value and so it was lost when the text was cut off

6.???? Carry on letting users enter long values and use SQL update statements to manually reduce the length of the value

The long term solution was to:

1.???? Reduce the length of the field so the two systems matched

2.???? Implement a data cleanup operation to reduce the length of values that had previously been stored in Maximo.

This should have been implemented when the interface was implemented

Fixing the size issue had several effects :

1.???? Reduced frustration for the users

2.???? Reduced workload for the support staff enabling them to spend more time enhancing the system

3.???? Improved financial reporting because the transactions went through first time

4.???? Improved data quality

5.???? Reduced use of sql update statements leading to reduced risk of data corruption

Sadly there were other interface issues which were not so easily fixed. I developed a BIRT report to help users identify if their transactions had hit problems, that report executes multiple queries in seconds and reduced the investigation time from 20 minutes to 2 minutes

Cohesive advice

Reviewing the "user errors" case meant that the underlying problem was fixed and in doing so this removed a large number of supprt cases.

Resolving this also built up trust with my users and meant that I could build other solutions e.g. the BIRT report

Years later I met one of the users who still remembered some of the improvements and recommended me if their colleague wanted new features.?

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

If you like this article then please share or like it.

Whilst I support the wider Maximo community and encourage the spread of knowledge, when republishing content from this blog please include the originating author along with the article or parts of.

If people do find parts of this blog coming up in blogs/newsletters/communications then please contact me directly. I’m happy to connect on LinkedIn to discuss.

Disclaimer

The postings on this blog are my own and don't necessarily represent Cohesive's positions, strategies or opinions.

The materials on this site are provided "AS IS" and the author will not be liable for any direct, indirect or incidental damages arising out or relating to any use or distribution of them. Readers are advised to test any changes/recommendations thoroughly before use