Organizations strive for competitive advantage – they seek to build it, preserve it, improve it.
All organizations have best practices. They may exist only in the minds of stakeholders, they may be mapped to paper, they may be on-line, or in-line. A mapped process is better than an unmapped process. An on-line practice is better than an off-line practice and, for complex processes, you need to put processes in-line.
Operational best practices support organizational strategy. They increase staff productivity, improve throughput, decrease errors, and improve compliance with internal and external rules and regulations.
Many organizations have unrealistic notions regarding the time it takes to map out a best practice. Estimates range from days to weeks, to months.
Here is how you can reduce mapping time for a process to hours.
Face the facts
The first thing to recognize is that end-to-end processes are in short supply. Most of this low-hanging fruit has been harvested. Work today consists of a mix of structured and unstructured work. The mix can be 5/95% or 95/5%.
For all intents and purposes, you need to focus on “process fragments”, not processes.
This does not mean you have to go from high automation to where all work is done manually. Even in Office/Services not all work needs to be performed by humans – O/S work can be performed by humans, machines and software. The extent to which you automate is the domain of ROI submissions.
What is important in all of this is not to get to where you manage structured work separately from unstructured work because the work that needs to be performed typically is sourced from a common resource pool (skills sets that are needed across all projects/ initiatives, machines that have finite capacities, software transactions that can get backlogged).
Start at the right place, the right way
The place to start process mapping is at an electronic mapping canvas.
Map processes in real time, in front of stakeholders, such that a map can be extended as fast as stakeholders can say “.. and then we do this”. You may need to use a facilitator to help you through the learning curve. Any delays in mapping are likely to result in stakeholder dissatisfaction.
Forget whiteboards and post-its for any complex mapping initiatives. These have gone the way of buggy whips.
Keep mapping sessions short. One hour is about right and the easy way to do this is to not take on more than a 20-50 step process so that your process can be compiled and rolled out, modelled, tested and approved during the same session.
Park images of the forms that will be used at process steps to avoid having to initially “paint” real forms. Include a “notes” memo field below the images to accommodate stakeholder comments (i.e. wrong form, missing fields, unwanted fields, etc.).
Once you have a mapped, improved process fragment you need a run-time environment capable of providing guidelines and guardrails for the performance of work defined in your process.
Guidelines come from BPM (Business Process Management) processing of structured process fragments (few processes are end-to-end processes that can have a single start/end).
Guardrails come from rule sets that you set up. Make sure most of your guardrails issue alerts as opposed to causing hard stops.
Consider the example of data collection of a supplier address at a process step form. Designate the address field as “mandatory” if you like, but let the user move on if they do not wish to input the address or, more likely, if they do not have ready access to the address. Your rule sets will take care of the deficiency when the actual time comes to send a letter out to the supplier.
Your run-time environment must be capable of allowing users, machines and software to thread process fragments together and accommodate deviations (skipping steps, re-visiting already committed steps, recording data at steps that are not yet current) and inserting ad hoc steps.
Except in the case of end-to-end processes, there are no convenient process end points that can act as “objectives”
You need a Case environment as your run-time environment so that the focus can be on meeting Case objectives as opposed to meeting “process” objectives. Process fragments don’t have objectives. Most of the time, you will need to define multiple objectives at a Case and not all of these will have the same importance, so, one good approach is to set up “Figure of Merit” matrices at Cases to provide a framework for non-subjective weighting/consolidation of objectives.
When to close a Case becomes important. Case closure does not always occur “… when the fat lady sings”. Many times outside events prevail and require that a Case be closed (or significantly changed). It is not always essential to reach all defined objectives at a Case.
Managing Workflow
It is essential within any run-time environment to accommodate auto-resource allocation, leveling and balancing (RALB) so that structured steps post as these become current along a workflow and so that users, machines and software can insert ad hoc steps.
If you are practising 5S, make sure 5S tasks post to the environment (i.e. User InTrays) so that workers view 5S tasks as part of day-to-day operations, not as “special” tasks.
Users relate negatively to micro-management of their work (by others). Your run-time environment needs to accommodate micro-scheduling of tasks by users. Some people like to start their work day by clearing out a few simple tasks, others get satisfaction seeing progress with one or two long term initiatives. Let supervisors worry about workload across users. They will need a dashboard to do this.
The UI you provide to your users is all-important. In order to sustain a workflow management initiative, you need a setup that makes it easier for users to record progress of work at the run time environment than not. Avoid complex navigation. One screen with a calendar on one side and a to-list really is all you need for Case management.
Process Improvement Initiatives
Clearly, in an environment where, in theory, each Case can be unique, we need data collection capabilities for the later purpose of carrying out analytics. Discovery of repeating patterns of a particular set of ad hoc interventions can lead to new or improved process fragments.
Closing Commentary
There you have it, 360 coverage – on “best practices” starting with “why”, “what”, and then “how”.
Makes it all look quite simple and straightforward, doesn’t it? It makes me wonder, looking back at my rants for 2013, why it took a year to get everything right.
Click here below to hear what Peggy Lee’s interpretation of this blog post might have been.
“Is that all there is?”
http://www.youtube.com/watch?v=qe9kKf7SHco
Courtesy to Walter Keirstead. This blog is also available on http://kwkeirstead.wordpress.com/
Follow
