Maximo Anywhere

  • 1.  Anywhere WT offline: Is there any functionality that only works online?

    Posted Fri May 21, 2021 05:54 PM
    Edited by User1971 Sun May 23, 2021 03:16 PM
    Anywhere Work Technician 7.6.4:

    I have a limited scenario where users want to use Anywhere WT in offline mode. (A handful of Anywhere users will occasionally work at a facility that doesn't have Wi-Fi.)

    Are there parts of Anywhere WT that only work in online mode? (queries the Maximo server directly; no lookup data)

    1. Searching for WOs
    2. Validation via automation scripts
    3. WO --> Asset field --> Asset's WO history


  • 2.  RE: Anywhere WT offline: Is there any functionality that only works online?

    Posted Sun May 23, 2021 03:14 PM

  • 3.  RE: Anywhere WT offline: Is there any functionality that only works online?

    Posted Mon May 24, 2021 08:19 AM
    Yes to your 3 mentions. I don't have many others but here are a few.

    Not a fault of the app, but push notifications. You obviously need connectivity for push notifications to work (such as alerting to emergency work). 

    General validation of security/data restrictions I wouldn't depend on the device logic. For example, whether or not a status change is allowed or whether an attribute is editable or read-only. We see quite a bit where these restrictions are only implemented on the server side. For example, out of box we have users who can see and change something to APPR inside of Anywhere but don't have the actual permission to Approve the work order so an error is thrown server side when they do it. 

    For the most part though, almost all functionality is supported offline. You can add attachments, labor, materials, etc. If you do mapping I'm told you can even do directions offline. The big difference to me is whether an error is caught immediately or when the device is later synchronized.

    Steven Shull
    Director of Development
    Projetech Inc

  • 4.  RE: Anywhere WT offline: Is there any functionality that only works online?

    Posted Mon May 24, 2021 01:08 PM
    Insofar as the security / data restrictions is concerned, the design principle is "work execution".  That principle when envisioned is now eight years old.  Technology and connectivity capabilities has moved somewhat, and more customers are expecting to do more that just work execution.  (Keep in mind that when we say work execution we are talking about performing work that has already been planned and approved.) Thus when it comes to permissions to approve work, that situation is not a scenario that was originally within the design scope for the large percentage of work orders expected to be downloaded or made available on the device.  

    The idea of being able to "approve" work lies mostly (in a work execution scenario,) with emergent work which we all know just gets done and we capture the "what" of what was done after the fact.  If technicians are a) expected to do emergent work (i.e. create new work orders and set them in progress and then complete them) but then b) prohibited from doing so (i.e. changing to INPRG,) then that is a human problem and not a technology problem.

    It is entirely inconsistent to say "Here is a tool to do work", and then subsequently prevent the user from doing so at a programatic perspective.  Technically you can modify the WorkOrderStausHandler.js to provide the matrix necessary to model the rules surrounding the approval paradigm.  When you do that you can provide a methodology to enable the human issue to be resolved. So the tooling is there.  The Anywhere implementer just needs to be able to model the correct business rules into the software.

    The programming approach that I have been quite successful with my customers comes with the understanding of "gotta-musta".  If the users have to have certain data and must be able to do certain things, whilst they are touching the asset they are working on, then we code the business rule into the tool, such that if they are offline then they will pass validated transactions to the server when the user gets back on-line.  this includes data restrictions, automation scripts, conditional expressions, and status change rules.  

    Encoding many rules into the tool gets expensive because the of a) the volume and b) the duplication costs.  So only do what you MUST HAVE in order to ensure offline transactions are validated and can be uploaded to the system.  If any business rules are not absolutely necessary for field processing and are "back-office" processing validations (like most of Maximo work-flow) then you can "safely" ignore them. Hope this helps..

    Bradley K. Downing , MBA
    IBM Certified Adv. Deployment Prof. Maximo v7.6.1