Workflow and the self-checkout lane

The other day, I was patiently waiting for help at the grocery self-checkout lane and began to wonder how this process may have similar issues to those that arise with workflow processes in an Enterprise Resources Planning (ERP) implementation. These “self-checkout” stations are designed to save the stores money and to add convenience for shoppers, but my observation is that fewer than half of all shoppers choose to use them. I prefer self-checkout, despite the frequent starts and stops due to the various weight or scan issues encountered, so I lean toward being a frequent user. Other shoppers avoid these lanes and prefer to have an employee perform the checkout. Frequent self-checkout users recognize some downsides to this automation:

1.             Being behind someone who is unfamiliar with the technology who slows down progress
2.            Scale checks for items with negligible weight (the bag platform scale cannot confirm the bag weight has increased and that the item was bagged)
3.            Item purchase constraints to adults (alcohol, etc.)
4.            For a grocery store, a produce item without a four or five digit item code (I cannot remember whether the item lookup for green peppers is under “G” for green or “P” for peppers)

For many of these exceptions, an attendant must be called to reset or over-ride the station, which somewhat defeats the purpose of the automation. So when I stand there waiting for help due an item weight not registering, I wonder whether the store really reduces shrinkage with these irritating weight checks (my assumption of the purpose for checking the weight of each item scanned)? My observation during a recent Walmart visit is that an attendant can monitor and support close to 10 stations, so there must be labor savings for the stores. Anyways, that is the policy and how the systems were programmed, so we are stuck with it.

So what does this have to do with workflow? Well, workflow has both admirers and critics for similar reasons, so it may be interesting to see how organizations either adopt or avoid workflow during an ERP implementation. Since many people are familiar with self-checkout, it makes an interesting comparison.

For those considering workflow controls for business processes the objectives typically are to streamline processes while enforcing adherence to policy. So workflow performs various checks and approvals required for specific transactions, such as a purchase requisition. A sample business process may be something like this:

•          User initiates a requisition for a new chair, since their current one is old and broken.
•          The user is presented a selection of chairs that may be selected
•          Once the requisition is complete, the user submits to workflow
•          A budget check is performed and if the department budget has not been spent, the requisition proceeds to the manager; if the budget is spent, then the requisition is returned to the user.
•          The user’s manager receives the requisition with a workflow action to approve
•          Manager may approve, reject or request modification.
•          There may be dollar limits for manager approvals that require additional approvals or may be approvals to procure certain groups of items.
•          Once approved, the requisition is routed to Finance to check for proper tax and department coding.
•         After Finance approval, Purchasing receives the requisition and can auto-create a purchase order to the appropriate vendor. If the item price was incorrect on the requisition and the budget check is no longer satisfied, then the requisition is returned to the user

This is a rather simple workflow example that is one of the most common. For the workflow to succeed the following data must be accurate and complete in the ERP system:

•       Department budgets
•       Organization hierarchy
•       Current departmental expenditures, including open encumbrances (Purchase orders, etc.)
•       Vendor catalogs: items, allowable items, and prices
•       Workflow rules for escalations
•       Personnel in the organization who review or approve transactions may require an ERP system license

So what can go wrong? The vendor catalog, prices, and budgets must be right. But also consider that delegations to alternate approvers must be setup for vacation and other absences for a department manager, Finance, and Purchasing buyers should be setup to route the requisition without delay. So for a new chair small delays may not be a concern, but for other transactions workflow delays may create problems most users are ill equipped to address. Chasing down this requisition within the workflow should be easy and corrective action straightforward, but this may not be the case.

So how do workflow processes relate back to the self-checkout lane? First, the constraints (like budget available) must be readily verifiable. If department budgets are not accurate or up to-date, then many exceptions may occur or expenses approved in error. Second, there must be ready access to override absences and other workflow stoppages by team members with the visibility into the workflows and authority to take action. Third, there should be metrics and reporting to visually identify the status of all workflows in order to adjust workflow parameters to maintain the proper balance between tight controls and acceptable numbers of exceptions, like the roving checkout attendant who looks for the red light on top of a station or a bewildered customer with an issue. Lastly, the organization hierarchy should be specified using titles wherever possible to avoid workflow changes for each change in personnel and role.

Coming back to the self-checkout lane, what improvements would we like to see? The store should skip weight checks on items with negligible weight. This one change would reduce a lot of errors and time spent waiting for the system and then requiring an override (either the “I do not want to bag this item” selection or an attendant). Improve the bag supports so it is easier to place items in your own bags, since the frames are primarily designed for the store supplied plastic bags and do not readily accommodate customer supplied bags. The focus should be on customer convenience and not auditing to the detriment of the customer experience.

For workflows, designs should balance policy enforcement with ease of use and organizational efficiency. Start with some limited controls and routes in order to minimize complexity. If the workflows are complex at system go-live, there may be too many exceptions and work may grind to a halt! This is the concern I hear most frequently and spend the most time addressing during an implementation.

I have had clients with both numerous workflows at go-live and those who delayed implementing workflows until after the initial implementation was stabilized. If you do go forward with many workflows, especially complex ones, extensive testing for the organization hierarchy, security roles and exception scenarios should be included prior to user acceptance and go-live. Just keep in mind the self-checkout attendant on a busy Saturday!

About Kirk:

During his 30 year consulting career he has led many ERP selections and implementations, primarily in the manufacturing, distribution and high technology industries. During a recent two year respite from consulting, he was an executive leading a global supply chain organization using Microsoft Dynamics. As the global supply chain director, he appreciated the opportunity to “eat his own dog food” by running the business processes and technology he helped the company select and implement.

Kirk’s published works include this monthly blog, magazine articles, conference presentations, and the book Lean Distribution, which focuses on the relationship between ERP and lean operations in the supply chain.