Optimising User Profiles
The risk and impact of trying to take too much
BlueWorx targets making the job of its Users easier, more effective and more efficient. To help optimise what data users get on their device we have created User Profiles. When these profiles are correctly structured and applied, users get the right data and optimum performance and UX from BlueWorx. Sub-optimal management of profiles can lead to very large recordsets with long sync times and the application performance may even be impacted. Poor performance can then lead to adverse user adoption and an erosion of targeted business benefits.
Important: For information on data limits see: Performance and Data Limits
For further information of User Profiles see: Maintain User Profiles
The release history of BlueWorx includes many optimisations. Examples include but are not limited to:
- Delta syncs to exchange only changed or new data and allow this to be send to the background
- Background syncs to limit the impact of longer sync times
- Multiple configuration settings to limit 'deep data' to Work Order objects - for example classification values
- Different profile types to allow more precise control over master data versus work and notification data
- Allowing users to select which of their assigned profiles they activate
- Promoting the use of SAP processing of Inspection results by batch job and not making the user wait while they are processed
- Selectively allowing the download of map data and documents
BlueWorx continues to evolve and improvements will continue around the topic of data optimisations. But like all solutions we are constrained by physical limits that means that customers must think about 'right sizing' the data they mobilise.
Profile design strategy
A common dilemma when evaluating the design for profiles is that 'edge cases' can increase the scope of the data required and overwhelm what might otherwise be a relatively straight forward profile design. We advocate creating a User Profile Design Strategy during your implementation and maintains its use through into production support. The strategy should cover:
- The basis for which you will divide the data according to business requirements and roles
- The targeted performance limits of the anticipated in profiles/ active profiles
The speed of the SAP system, the speed of the network, the performance and capacity of the the device and the speed at which BlueWorx can acquire and transfer the data are largely beyond your control. It's therefore important to understand that any performance limits you set will impact on the number of records you take to the device, rather than thinking they can influence any of these other factors.
With any change comes an opportunity to challenge
Any project where you are optimising business processes provides an opportunity to challenge existing processes. So it is with mobility. Many of the targeted business benefits of mobilising SAP Plant Maintenance specifically need changes in processes to occur so there is an opportunity to challenge and improve on your design. Questions you might ask include:
- What level you assign users to work orders, is this still optimal for mobile asset management?
- How you have structured your data (plants/ plant sections/ etc) the best way to allow for use with profiles?
- What's the quality of the data you have and, with mobility, is there an opportunity to specifically target improvements?
- What's your current approach to Inspections and how can you leverage BlueWorx functionality to best effect?
Rightsizing the data you mobilise
Spend some time analysing requirements before creating or modifying profiles. Consideration points include:
Getting your synchronisation config right
There's a number of options to control BlueWorx synchronisation. Effectively applied this can eliminate/ reduce the need for users to manually sync and hide from them wait times while syncing occurs. For more on these settings see Settings Tab - Synchronisation (Sync).
Create and assign multiple profiles
If workers are transient between areas or switch periodically between job functions then they can multiple profiles and be allowed to switch these on an off. So, for example, if you have shifts rotating between preventative maintenance and break-fix duties you might have profiles supporting both these roles assigned to the workers and they activate/ deactivate the profiles as the term of their shift changes.
Consider reducing occasionally used records
Often thousands of Equipment records are taken to the device for assets without directed work orders too allow faults (Notifications) or repairs (Field Orders). If the number of these types of records pushes data/ performance limits then consider allowing the users to log a notification or order against a higher level asset and then have this pushed down to the lower level asset at a later date. These notifications or orders can then be assigned to a lower level asset by the planner during the planning process as appropriate.
Taking only higher level assets in the hierarchy to the mobile device can dramatically reduce the amount of data (typically a 5-10 x increase in data for each additional level of the hierarchy that is downloaded). This may not be the perfect solution from an overall workflow perspective but for the end user it may provide a better user experience.
Rationalise classification values
Are all the classification values required? For example you might have administrations details maintained in the classification values that are never referred to in the field.
Work in the past/ work too far in the future
Is the window for Orders too far back/ too far forwards? How much backward visibility is required if the planner are keeping on top of overdue work; how much forward visibility is required to accommodate the 'self planning' nature of your workforce.
Rationalise SAP Measurement Points
Sometimes existing mobile users will have created large numbers of Measurement Points to support inspection response questions. Often many of these are not what might classically be accepted as Measurement Point and are filling a gap in the available functionality in SAP and the legacy mobile solution. BlueWorx Inspections allows you to rationalise your Measurement Points to only those needed for classic use - i.e. 'measures' and not 'yes/no' in response to inspection checks.
The importance of testing
When BlueWorx syncs on a mobile device it takes more information than the sync on a browsers. That's because browsers are connecting and we can retrieve more information from SAP at will. And while BlueWorx did not expressly start with this different handling of syncs, as we have reached the technical limits of browser storage, we increasingly make use of this on demand data technique.
Different devices (phone versus tablet, Apply versus Android) can differ widely in terms of their performance (speed of processing) and storage limits. They can be impacted when in use through other application use and data. Communication speeds can differ radically between browsers over in-office LAN/ WiFi and mobile units using factory Wi-Fi or cellular data. Cellular date can vary greatly between inner city and rural areas.
All profiles must be tested before deployment on all the the representative devices and communication methods and with anticipated combinations of profiles.