It used to be that Five S implementations relied on behind the scenes Business Process Management (BPM) orchestration.
Some of the BPMs did have issues with variations from best practice protocols. With the advent of ACM and more particularly ACM/BPM run-time environments, these restrictions no longer exist.
ACM/BPM totally changes the corporate culture regarding the performance of work (both management and workers).
Protocols now exist for the convenience of users. Use them/don’t use them. The corporate message has changed from “…. do this, this way” to “….do what you like”
Most users find that the alternative of trying to achieve an outcome via a series of ad hoc interventions is more stressful/time consuming than following published protocol, where most of the heavy lifting is done by software.
Ad hoc interventionists are very quick to discover that as they try to engage certain processing, there are roadblocks that post (due to the presence of background rule sets at key process points). i.e. Welcome to in-line QA with a sampling rate of 100% at key process points.
Progress beyond these roadblocks requires either a) remedying deficiencies or b) supervisory override.
An example of how a roadblock is raised plays out like this
The ad hoc user goes to the Menu of Services and clicks on “Request for Shipment”. There is a presumption that the user knows when to do this – clicking results in posting of a form where the user indicates what he/she wants the Shipping Department to ship etc.
Unfortunately, if the user or some other user has not previously completed “Submit Item to QA” (something they would never have to worry about when following a protocol), a rule set will say ‘Sorry, Shipping does not accept requests that have not gone through QA”).
Contrast this with the user who follows published protocol – this user does not have to worry about when to ship what, Request to Ship orders post immediately after the last pre-requisite (work done by others) along an instance of a published protocol is declared to be complete.
The curious finding in all of this is I can be sitting at my desk happily following all available best practices, you can be sitting a few feet away, refusing to follow any of these best practices and it does not matter. Rule sets at key process points add Governance to the Orchestration provided by the ACM/BPM environment both of us use.
Management reasonably does not care nor should it care, so long as we both get the same outcome.
Metrics would, over time, start raising eyebrows as to why you take 5 times longer to do things than I do, but so far as the quality of deliverables is consistent, there is peace and harmony. No one has the impression of top down imposition of “how” to do work.
There is one thing left to discuss in an e-environment such as this. What about the “user” who refuses to roll up to a PC and either follow a protocol or not follow protocol?
The obvious scenario is no one knows what this “user” has done or is about to do.
Not to worry.
This WILL not happen because in a flow through e-environment, the recalcitrant user will never receive any tasks to perform because all tasks assignments come to everyone via the software system. With nothing to do, the situation will self-correct itself over a very short timeframe (i.e Hmm, how do I fill in my timesheet with no project numbers to charge my time to?)