The about description is divided into the following sections:
The new Aurena Native apps introduces a new user experience for Mobile based on the Aurena framework. With the new Aurena Apps, two apps are delivered for work execution.
The apps supports the following processes:
In mobile this refers to the process of processing Pool Task and Work Assignment.
In addition there are a set of supporting processes:
The IFS Service MWO and IFS Maintenance MWO apps are two apps closely tailored to the demands of the Service Management and Enterprise Asset Management industries.
IFS Service MWO app supports both Work Order and Request based Service Management
solutions and IFS Maintenance MWO app supports Work Order based Asset Management
solution.
The apps are available for download via the public stores
i.e. Appstore, Google Play and Microsoft Store
IFS Mobile Work Order is integrated with the following components and product areas within IFS Cloud:
A Permission Set must be created to grant access to IFS Service MWO
and IFS Maintenance MWO features and functions. All access is controlled
via Activities.
For IFS Service MWO the module listed in Activities
is named "TouchApp ServiceEngApp 1".
For IFS Maintenance
MWO the module listed in Activities is named "TouchApp MaintEngApp
1".
The Activities listed are all prefixed with "ServiceEngApp 1" or "MaintEngApp 1". The Activities either give access to features or functions.
User must also have access to the functional role permission set TOUCHAPPS_RUNTIME to be able to logon to IFS Mobile Work Order.
To administrate IFS Mobile Work Order an end user role permission set TOUCHAPPS_ADMIN has been created that will give administrator full admin access to the Solution Manager > Touch Apps features.
It is possible to create Permission Set Filters that give row level security to any data entity that is synchronized with the mobile client. These filters can easily be created via the RMB "Create Filter..." from Permission Set Activities by selecting the relevant ...EngApp 1 activities.
In order to work with IFS Service MWO and IFS Maintenance MWO, employees need to be defined as mobile users. This is done in two parts. One where you need to define whether the user will use mobile work orders or not in Resource Detail > Maintenance Employee and the second where the employee is defined automatically as a mobile user when the corresponding user is activated on a mobile client.
To manage automatic time transactions on the mobile work order will
use primary parent group (work time transactions) and/or a travel resource group
(travel time transactions) defined for the employee.
All objects on the site(s) that the user is connected to, are sent to the
device using group push. Group Push requires
that the system user running the background job for group push must have full
access to all required sites. The system user of "MaintEngApp" and "ServiceEngApp"
are "IFSMAINTENGAPP" and “IFSSERVICEENGAPP" respectively. The
objects can however be limited by using permission set filters. The maximum
no.of sites that can be connected to a user is 80. If this exceeds 80, no objects
will be synchronized to mobile device.
The parts which are required to synchronize to mobile client should be registered
in mobile part basic data. In this data set up it is possible to connect a mobile
user to an assortment so that all the parts in the assortment will be available
in the mobile application. In addition to this, all the parts registered in
warehouses connected to the mobile user as well as spare parts registered against
equipment objects will be synchronized to the mobile device.
Once the Part Basic data has been set-up then the Refresh All Inventory
Parts Schedule Tasks must be run to generate the part data that is used to filter
the Inventory Parts to sync to the mobile user.
It is recommended to configure this schedule task to run on a schedule
that matches the frequency that parts will change, and ideally run overnight
so the schedule tasks do not impact the system during normal operating hours.
It is possible to configure integrations with IFS Mobile Work Order and
third party apps (on the Android platform) or Web pages. These can be registered
in Mobile Integrations and it is possible to specify whether the integration
should appear on the Home screen or as a Work Task Action.
On calling an App or Web page screen a set of parameters are outputted
containing mobile user and work order information depending on where the integration
is being called from. These parameters consist of any field listed against
the entities MobileUserInfo, ActiveWorkOrder and JtTaskAddress.
For exampel https://www.google.co.uk/search?q=${MchCode}+manual
as value in the field "Uniform Resource Locator" will search for the
Object value and the text Manual. (If
the Screen field is set to Work Task
if an Object exist)
Workflow Configuration is a way to enable or disable actions and processes available for mobile users. It is possible to hide some actions (e.g. Returns or Media) or make them mandatory (i.e. signature must be provided before work assignment can be completed).
A workflow configuration will be applied only when the workflow criterias are met. For instance when the Object Type of an Object is "Boiler" ,when the Work Type of a task is "Corrective" or when the Maint Org of an Employee is "Electrical Department". On Filter cirteria, "Exclude Task Leader" is a Filter that can be used to differentiate work task assignee from Task Leader or not, when applying workflow configuration.
Action flow can be defined in a sequence order in Workflow Configuration in Aurena client such that mobile user is guided through that predefined workflow. Action flow configuration is enabled for Workflow Configuration type "Configured Work Task".
There is a flexibility to define action flow with many combinations of actions in Aurena client and there are only a few client validations. Therefore, it is up to the administrator to define the action flow in a correct and sensible way to suit own work flows.
Maintenance surveys are configured in IFS Aurena under Maintenance Survey
Data filters can be specified to identify when an eForm should be triggered:
Before the eForm can be used in IFS Service MWO and IFS Maintenance
MWO it should be published and can be changed at a later stage by using
the replan option.
When this is done, the eforms needs to be connected to
a workflow in order for it to be transferred to the relevant mobile users as
part of the batch synchronization.
Once the work is planned in IFS/Work Order Management it can be transferred to IFS Service MWO and IFS Maintenance MWO.
If Work Assignment is created for a Work Task, it can be transferred
directly to user assigned to Work Assignment. If multiple Work Assignments for
Work Task are created it is possible to transfer all assignments in one action
from Task level. If Work Task is planned but no active Work Assignments exist,
it is possible to transfer and assign work to a user in one action from Task
level. Mobile user must be selected in the process and Work Assignment for the
user is created.
Work can be transferred to a particular mobile user or to a common
pool of work tasks . When a work task is transferred to the pool, it will be
synchronized with the mobile users that have access to the task site.
Work
If Work Task is planned but no active Work Assignments exist, it is
possible to transfer it to pool. There are two options supported:
While accepting a Task from Pool, the user has possibility to set Allocated Start and Finish dates of the Assignment created.
Note: If the site is scheduled by the Planning and
Scheduling Optimization, it will not be possible to transfer tasks in this site
to the common pool of work tasks.
The Transferred Tasks/Work Assignments page allows review of all Work Assignments transferred to mobile users as well as Tasks that has been transferred to pool. It is possible to cancel selected Tasks and Work Assignments directly in the screen.
Only the Work Assignment status is can be updated in Mobile Client; Work Task statuses cannot be updated in mobile, but are updated by the work assignments status changes. Some Task information such as Reported Object, Work Type, Priority etc. can be modified by mobile user. The user can also replan the Assignment by modifying Allocated Start and Allocated Finish. The mobile user will execute the work assignment by processing the assignment through the status chain of the work assignment.
Automatic time transaction will created (if configured to do so) between the following state changes:
There are a number of different actions available to the mobile user for the following areas during work execution:
In My Work Calendar Work, Breaks etc can be displayed, the following types of information can be displayed:
The data can be presented using different views
Work can be handled in the same way as in My Work list meaning that the most common command buttons are available directly in the calendar card. From the Work calendar card there is a navigation button that opens the Work Detail form.
Breaks can also be handled directly in the calendar, Breaks can be started and ended.
Absences, Trainings, Projects, and Misc. Allocations are displayed in the calendar, no action buttons.
Shifts are displayed using different background colors, off-shift time is displayed as a grey background, on-shift time is displayed as a white background
My Work Calendar is by default turned on, the Application Parameter CALENDAR_VIEW
set to FALSE will disable it in the menu.
The following two Application
Parameters for fetching Absence, Training and Projects has been added.
The new work and additional work process can be initiated from different places in the apps:
The new work process creates a new work order with a task, a resource demand
and an assignment. Creating new work should be used if the user wants to create
new separate work, not included in the current work scope.
Report
a problem: A new work order is created including a task. This will
automatically be returned after finishing the assistant.
Request
Work that needs to be done: A new work order, including a task with
a resource demand is created. If the user needs to plan this work further, the
user can select to keep the task on the device for planning.
These tasks
can be found in a separate entry in the Home Screen, called Work to
Prepare.
The options to create work that I will
perform or report work that I have done, result in
a new work order, including a task and an assignment that belongs to the user.
The assignment in this scenario can be in different statuses (accepted, work
started or completed) depending on more options available within the assistant.
The assignments in status accepted or started create work that I will
perform will be kept on the device. The assignments in status complete
report work that I have done will launch a question in the
last step of the assistant whether to keep or return the work.
When
selecting the Additional Work assistant, the executor will have almost the same
user guidance but the outcome differs compared to New Work.
In Additional
Work, an additional task is created for the current work order. This means that
the current work (order) scope is extended.
The option to request additional
work that needs to be done creates an unassigned task for the current work order
(including a resource demand). If the user needs to plan this work further,
the user can select to keep the task on the device for planning. These tasks
can again be found in a separate entry in the Home Screen, called Work
to Prepare.
The options for creating additional work that I will
perform or have done, result in a task on the current work order and an assignment
to the user. The assignment in this scenario can be in different statuses (accepted,
work started or completed) depending on more options available within the assistant.
The assignments in status accepted or started (“Create work that I will perform”)
will be kept on the device. The assignments in status complete (“Report work
that I have done”) will launch a question in the last step of the assistant
whether to keep or return the work.
The Additional Work assistant can
be launched from different places in the apps:
The new work and additional work process can be initiated from different places in the apps:
The new work process started from Home Screen and Object creates new Service Request with Request Scope and Tasks. Crating new Request should be used if the user wants to create completely new work not connected to current work.
The process creating new Service Request creates Request in state New with Scope and Tasks and Resource Demands created based in Service selected by the user. New Service Requested is intended to be prepared and scheduled by backoffice and mobile user has no option to created new Request for her/himself.
The new work process started from Work detail and Task Step pages creates new Scope within current Service Request as well as Tasks and Work Assignment. Crating new Scope should be used if the user wants to create new work that is separate but connected to current work.
When adding new Scope, the user is presented with following options.
Request work that needs to be done: A new scope is created in state New
and includes tasks based on Service selected in the process. The Scope and Tasks
are not available for mobile user.
Create work that I will perform
creates new Scope in state Released as well as Tasks based on selected Service
and Work Assignments assigned to the user. The actual process is done in backoffice
and resulting Tasks/Assignments are transferred to the mobile user. They will
be available in mobile client after synchronization is completed; it means that
if mobile device is offline or in area of weak connection, the Tasks will not
be immediately available to the user for processing.
In Additional Work, an additional task is created for the current Request/Scope.
This means that the current work scope is extended.
The option to
Request additional work that needs to be done creates an unassigned
task within current scope (including a resource demand).
The option to
Create additional work that I will perform, results in a task
added to the current scope and assigned to the user. If new task is created
using Standard Task then the actual process is done in backoffice and resulting
Task/Assignment are transferred to the mobile user. They will be available in
mobile client after synchronization is completed; it means that if mobile device
is offline or in area of weak connection, the Tasks will not be immediately
available to the user for processing. The assignment in this scenario can be
in different statuses (accepted, work started) depending on options available
within the assistant.
The option to Report additional work that
I have done, results in a task added to the current scope and assigned
to the user. The assignment in this scenario is in status Completed and the
user will have an option to either keep the Task in mobile client or return
it immediately. There is no option to use Standard Task in this process.
A quick way of purchasing parts from a registered supplier and perform receipt over the supplier's counter. This is applicable for service technicians working with work task originating from Work Order and Service Request in IFS Service MWO. This is an on-line only solution.
This is mainly to support ad-hoc (unplanned) purchasing demands of service technician who executes work task.
In order make this feature enabled for a mobile technician in MWO Service Management, there are few basic data should have been defined in Ad-hoc Purchasing Basic Data page in Aurana.
Service Technician can initiate Ad-hoc Purchasing in mobile client by registering an Ad-hoc Purchase request header. New Ad-hoc Request command is available in Ad-hoc Purchase action in work task. Request header is created upon a registered supplier and system generated Order Reference with supplier prefix is created. This is the reference number which can be produced to trade counter when actual purchasing is taken place. Saved request header facilitates either user to add Part and Unregistered part to the request or to retrieve purchase part records to the pending request through EDI (Electronic Data Interchange) or someone else (ex. Service Manger) to add Part and Unregistered part to the request at a later stage. While registering parts, if total order amount exceeds the maximum purchase amount defined for user/user group upon supplier, Limit Exceeded badge appears on the request header. However, this is not a hard restriction but just an alert for the user in the case of over purchasing. User is also allowed to keep the pending request and can continue later. The request can be completed atter entering part records. Upon completion, a Purchase order is created and set to closed in back-office whereas relevant cost is also updated against the work task.
Mobile user can access pending and completed Ad-hoc purchase requests which are connected to the tasks those are in user device through Ad-hoc Purchase (Task Action) or through Purchase Handling (Home Screen).
Read-only view of a completed request is also available in mobile client to see the details.
Mobile user can find Ad-hoc Purchase request which is created by someone else in back-office for a task that is assigned to him.
Pending request can be found in Purchase Handling (Home Screen) or Ad-hoc Purchase (Task Action) in IFS Service MWO client. . Technician can make the purchases by producing the order reference to the trade counter. Then either technician can add part lines or retrieve part records through EDI or back-office person can enter part records and complete the request.
When it comes to the material handling , the Mobile user is not only restricted to issue and return material in the execution process. But can also maintain their own stock and move and receive stock
During the execution process the user will be able to issue and unissue materials required for the task.
This feature is only available on IFS Service MWO. If the required Part for a service work is unavailable or deficient in technician's van, the technician can use Find Part to locate the part from nearby warehouses. Those warehouses can either be another technician's van (mobile warehouse) or a warehouse in a fixed location. In order to have this feature available in the mobile client, GPS settings on User-Device level should be enabled in backend. Device Location setting should be ON, Device should be Online and Location tracking Enabled in Application level. This feature is supported only when adevice is online.
Eligibility of a warehouse for Find Part
Eligibility of a warehouse for Find Pat should be predefined. It should be defined in Warehouse Set up for Service page in aurena which is based on Warehouse Type that is defined in Warehouse Basic Data. Therefore it is a prerequisite to have a WareouseType for a warehouse in Find Part. This feature is supported for the following types of warehouses,
Warehouse Set up for Service in aurena (example)
Criteria for locating warehouse in Find Part
Find Part can be accessed through,
Following are the 3 Application Parameters effecting Part search
Maximum Hits
Status of a warehouse in Find Part
Results are displayed on Map, with Green/Yellow pins indicating,
Results have a card view with following information
During the execution process the service technician can receive and use material that have been delivered directly to place of service – i.e. to Service Location. Material can be delivered by external supplier (on Purchase Order) or by service organization (on Shipment Order). The Material Order Receipts page under Work Task actions shows all parts that have been delivered directly to service location. The feature is available in ServiceEngApp only.
The following actions are possible.
Use of Service Location imposes some restrictions on material flow:
During and inbetween execution processes the user will also be able to keep
track of their stock and stock levels
Information shown in My Stock:
In addition user can perform following action :
During and inbetween execution processes the user will also be able to perform
following actions related to moving stock:
During and in between execution processes the user will also be able to view and update stock count reports in mobile which are generated in IFS Warehouse Management. This is implemented as an online only feature in IFS MWO Service and following actions will be available during the process.
In terms of handling Object Information the user may not only view object information but also update information about objects and report in measurements etc.
In Objects user can identify all objects that is associated with work that
they have recieved but also all objects connected to their site(s) can be seen.
(Object related information can also be found when directly navigated to from
a Work Assignment).
Once the Object has been identified the user can take a set of actions from there:
Report in Measurements through LiDAR Scanner.
From time-to-time, remote workers require assistance from an expert to complete their task. So, the capability to give/receive Remote Assistance has been embedded within IFS Aurena and the IFS Aurena Native Mobile Work Order Apps (MWO Service & MWO Maintenance).
Provided that the end user is configured as an active Remote Assistance user, the option to make/receive Remote Assistance calls will be always available.
And by design or by configuration, it is possible to pass context information regarding the business object the calling user is viewing when requesting help (Note: context viewing is only available in IFS Aurena).
Call Logs are visible in both IFS Aurena and IFS Aurena Native. Video recording of the call is attached to the Call Log and can be viewed from there in IFS Aurena.
Mobile users can start and end shifts in the mobile client. This is done via a side out menu option labeled “Work Status”. If current shift status is “off shift”, user can go “on shift”. Likewise, if current shift status is “on shift”, the user can go “off shift”. All shifts for a configurable number of days are synchronized to mobile using the Application Parameter “SHIFT_BREAK_LIMIT”, which is set to 10 days by default.
The status of the last transacted shift will be appeared for the user once he logs in to the mobile application. The status of the shift is graphically visualized by an icon placed on top of the mobile client.
Shift status updates in mobile are used by the automated scheduling and dispatch services to make decisions around scheduling and dispatch of work for the resource. These shift statuses are critical in order to allow the scheduling engine to make the best possible decisions.
Mobile users can start and end the same shift multiple times during the shift period in mobile client, but in back end only the first start and end transactions are considered when log onto or off of the shift. Subsequent “on shift” or “off shift” transactions will not consider additional shifts unless another valid shift exists for the same day.
Starting the shift can be enforced via an Employee Workflow Configuration. If it is enforced, the user will not be allowed to start travel or start any existing work in mobile until starting their shift. If it is not enforced, a warning will appear if the user starts travel or work prior to starting their shift. This warning will only appear once per session.
When a shift is started or ended, a check list may be triggered in order to allow the mobile user to record important start or end of shift information. This is enabled via Maintenance Survey and Employee Workflow Configuration. There are two types of surveys
Once connected to an active Employee Workflow Configuration, these surveys are triggered when mobile user starts or ends their shifts. These check lists are triggered once per shift. The user is required to complete the survey in order to successfully start or end their shift. If that is not done, the user’s work status will not be updated and, depending on the system configuration, the user may not receive assigned work.
Survey answers are stored in back end in the Survey Answer table and will contain the respective Shift ID value.
The user can start and end breaks in a list of breaks. This list is started by clicking on Show Breaks in the header of My Work. The breaks and shifts for a configurable number of days is fetched using the Application Parameter “SHIFT_BREAK_LIMIT” by default set to 10 days.
Only breaks for the current shift and not ended breaks will be displayed. If a break isn’t ended and a new break is started the non-ended break will not be displayed. When a break is started it changes state to On Break and the user can see when the break was started.
If on break and the user ends the break, it will be removed from the list When on break and the user starts to work again ex. presses Work Start, Travel, Continue or Continue Travel the break is automatically ended and it is also removed from the list.
When the shift is ended, if there is a started break that is ended too.
The assets (objects) can move over time. In addition, mobile technicians may often find that the location given in a task is not totally accurate. In such scenarios, mobile technicians can update the position of tasks and assets (objects) that they are working on while they are at work location. The default map position of the task or the object is set by retrieving current mobile device location.
The following conditions must be met to retrieve the current device location.