Knowledge Base

Process Automation & functions support aspects in Unorganized Retail Sales Context (URC)
 - Anupam Ahluwalia

In one of my previous blogs, I introduced cascading layers of characteristics a field automation solution must possess in unorganized retail based selling context-URC (e.g. via distribution network) and mentioned I would detail out on specifics of each layer for Unorganized retail context in separate blogs.

For sake of continuity, let me reproduce the cascading layers as below:

The focus of this blog is Process automation, Mobility nuances in URC

Process Automation with Mobility

This is usually a ‘bread and butter’ capability set, so most solutions will possess part of the capability sets, though you must watch out for subtle nuances that apply to unorganized retail context. Hence, I will restrict myself to highlighting some specifics that are relevant to URC.

Following is a rough guide of operational capabilities required as part of Process automation and mobility capability set expressed via examples:

I have selected a few of above to elaborate as follows.

Ability to define processes and continually add/edit

Following are some features that are important from URC perspective:

• Agility via process types addition/changes: Allows for adding new processes, activities, events for relevant field people without disrupting existing processes or them having to reset their devices or apps repeatedly. In other words, when they go on field, they simply discover there is a new process they need to perform, with all relevant information available on the app as they run through the process.
• Agility via individual process changes: It allows changing fields or data, for example in cases of reallocation of roles (e.g. shift from one region to another) seamlessly.
• Process Target based differences: The app is organized in a way where all functions are segregated by the target of his activity. For example, when he makes a visit to a retail counter, he should have access to functions he is authorized for a retailer. However, the functions should change, say, when he visits an end customer.

Ability to allocate access rights to field personnel

Though ability to allocate user rights sounds straight forward, URC scenarios demand variety of control options:

• Data based control- An example of data based control is when lets say two field personnel have the same hierarchy based authorization however say executive 1 can only deal in product 1 and executive 2 in product 2. These rules are centrally defined limiting the choices available to the users.
• Process type or target based control- Process type based control is relevant when say two field persons have different tasks and say different target end points too. It should be possible to manage rights in a configurable manner centrally.
• Processing difference based control- An example of this is: depending on who is collecting the order, you may turn on secure order (with OTP verification) or turn off (for example a senior member of sales team).
• Asset level control: Example of this type of control is say access to a report type. For example, only a manager can get credit details, or current location of other users etc.
• Frequency based control- There are other controls that must be paid attention to, for example restricting visit only once, reporting multiple times etc.

Support complete hierarchy controls exerted via the mobile device

Hierarchy control isn’t mentioned in above, and its for a good reason. For one, it’s an obvious control, second, some variations of hierarchy control require detailing separately:

• Simple Hierarchy based control- This is not a different from non URC scenarios. As per this, a person should be able to see and conduct transactions only on the field of area allocated to him/her.
• Hierarchy management- Because of frequent changes, the functions that enable easy management of hierarchy itself are crucial. It should be possible to view given a certain hierarchy which users are authorized to carry out what functions. It should be possible, for example, to temporarily add a person to a certain region, say for a day on visit, and remove without causing disruption to normal operations.
• DLS (Data Level Security): The other aspect is data level security. Its not just while executing a process such as collection of a sales order, but it applies to multiple functions- e.g. when accessing reports, making queries etc.
• Collaboration control: Besides access to data, field systems often include collaboration over mobile, for example, a manager can see his entire workforce last known locations and send an announcement to the field people that fall under his hierarchy.
• System workflows: While you should pay special attention to workflow support, hierarchy definitions once defined should be honored for workflow tasks automatically, for example, when a field personnel submits his schedule proposal, it should automatically land in the inbox of his manager based on hierarchy rules defined.

Agility: alter experience and process finer details

Although I have touched upon these earlier, a specific point is to be made regarding change in finer details of a process in a non-disruptive manner. Take examples below:

• You want a categorize end consumers further. E.g. earlier you had Customer as one category, now you want to have two categories- buying for someone else or consuming himself.
• You want to get some additional information about consumer depending on type of consumer. For example, you want to record his age bracket also when conducting a survey.
• You want to change a field to mandatory, for example, Date of Birth because you want birthday greetings to be sent out and wouldn’t leave this discretion to the field person.

Status tracking of operations carried out

Status tracking is not just about a tracking a process instantiated but covers other areas of audit history for comprehensive operations control. Below I give a few examples that are specific to URC:

• 'Days work': In most cases, users would like to see a single view of his/hers ‘days work’ view. Hence it should be possible for him/her to see on a single screen, all work he performed in terms of:
  
  • Customers/retailers visited
  • Travelled distance on a map with proposed route
  • All events, transactions he submitted over the day, categorized by types of transactions.
• Collated history: For managers, status tracking has a larger meaning from operations control perspective
  
  • Being able to view ‘Days work’ data for any field user falling under his hierarchy
  • Various reports for example being able to analyzed processed transactions in a particular region compared to another region over a date range.
  • Being able to see uncovered markets
• Beat plan and deviations: Beat plans and monitoring deviations is a quick and simple way for managers to analyze where operations are going off track. The system should support easy to analyze information as well as raise auto alerts in case of deviations.

Below diagram captures the summary of all aspects mentioned in this blog:

Conclusion

All solutions most likely include various form of Process Automation & Functions support capabilities. However, the alignment to URC scenario demands certain capabilities that may well make a huge difference in value you get from the system.

While it is possible to, of course, build all customized capabilities via use of a process automation platform, trick is to have the agility, flexibility as built in features of your choice of field automation system and, ideally, manageable via configurable customization as far as possible.