שטוטאקויV, אתר מאמרים אישי

April 20, 2016

Predictive maintenance & support for operational system

Filed under: מערכות מידע — רונה @ 4:16 am


It’s the same old story always, you put a system in production, the first couple of months you maintain a rapid response team which cater to every whim and any operation error that can ever be, everybody is happy, the system implementation completed all things running smoothly and then it is time to go to “Business as usual” phase. The vendor wants to get there so that they can collect a license fee, the client wants to get there in order to disband the project, close the budget item and employ his application experts in new projects. And that’s if all is well.

But the system is still alive and issues that may have not been identified in time are already in and may only reveal themselves in 1,2,3 , 12 months time. Support wise, the online support is done by a dedicated help desk which may respond promptly or laid back but will always react.


I’ll assume for the sake of the article that an information system is comprised of Items and these items may undergo Events scheduled or manually initiated. It doesn’t really matters what are the events or what are the items. A stock management system may include a scheduled expiry event for an item and an initiated event for sale. Or the items can be timesheets and the scheduled events can be working hours while the initiate ones are time offs. Regardless of the systems subjects they all can be categorized into items, scheduled events and initiated events.
Usually scheduled events will be executed by a scheduler in batch while initiated events will be triggered by a web service.

Weight and distributions

Most of the events on most information systems are actually scheduled events which happen on a daily or monthly frequency. The initiated events are usually 30 % off the total of accounts.

What can we do?

Aiming to act instead of react, the scheduled events may be predicted and so rolled forward.
Which means that out of any 10 activities in an information system, 7 can be predicted, i.e. performed and checked beforehand.

In order to implement such a methodology, it is required to age the whole system on outside the normal cycle and check for deviating values automatically,

Just to illustrate. Assuming an information system which mange items X each item may undergo an event A which should have consequences C on a monthly basis. This can be a contract billed for on a monthly basis and the consequences would be a cash balance or a purchase transaction.

Assuming that the consequences C can be tested by an SQL statement. It is possible to run the set of Events A and progress over a time line and check the results automatically.

The aging process will look like:

Item T0 T1 T2 T3 T4 T5 T6 T7 T8
1 E Check E Check E Check E Check E Check E Check E Check E Check E Check
2 E Check E Check E Check E Check E Check E Check E Check E Check E Check
3 E Check E Check E Check E Check E Check E Check E Check E Check E Check

Given the above example, E would be a preauthorized cheque request or credit card transaction and the Check would comprise of an SQL which checks the cash balance, accounting transactions and goods supplied for deviating values.

Deviating values in this illustration will be any Check result which does not meet our expectation: transaction performed but not reported, transaction performed and cash balance remains the same, transaction performed but no change to goods or transaction not performed at all.

This should be analyzed and either have the expectation amended or the root cause identified.

What can be done with the results

These results are predictive in a sense that we do not actually know that these will be the results, so to act upon them directly would probably be wrong. Item 1 in the above example may not even be there on T1 if for example it’s a house hold in a neighborhood which is billed periodically for Jon J Jr’s piano lessons may move to Greanock by the end of T0. But what can be done is to prepare the business users. In some other cases the event E may be something that is mandatory and then a fix to item 3 can be applied.

The immediate result, however, should be a report, identifying the future problems and the future mitigation suggested.

What about initiated events

Although it is much more apparent how to predict scheduled events , initiated events can be predicted as well.

Taking the above example, the aging process can initiate a move to Greanock for all households in T0 and to identify which of the can actually complete the move.
this kind of a predictive check can be manifested as a health card attached to each household:

Item 1 can undergo monthly cash request while cannot be relocated to Greanock.

Where can we take this further

The health card and potential scheduled failures can be fed back to the system dictating whether the option to relocate to Greanock will actually be presented to the user until fixed.


By means of methodological change, system support can be altered from a responsive mode into an action mode.

The methodology includes execution of potential or scheduled events in advance, before the user performs them or the system initiates them and trapping inadequate or deviating results.

Powered by WordPress