Lately I've seen several references to the process of process improvement. How would you define this process, and what are the keys to making the process of process improvement successful?
The most important process. The last process, that rarely gets defined.
Here's a [url="https://en.wikipedia.org/wiki/BASIC"]basic[/url] version of the [url="https://en.wikipedia.org/wiki/Lean_startup#Origins"]the lean principle[/url]
40 Goto 10
(BPMN version upon request as I don't see how to include images :)
Think about what you want to learn. Then build the minimal thing you can for you to learn what you want to know. You can avoid many unnecessary cycles.
You're right; there have been a lot of references and articles about that lately.
We ourselves wrote a piece about that ([url="http://www.flokzu.com/blog/en/documents-and-processes/automate-document-workflow/"]7 steps to automate a document workflow[/url]). The idea was to guide someone who has never used BPM or automated one of their processes and needs help with the basics.
We wrote it as a checklist and the main items are:
Choosing the first workflow
Modelling it quickly
Linking related forms
Selecting the right tool and automating
The first sub-clause “1.1 The issue is about improving the business performance of your enterprise” of my book explains this process – see ref 1 for the full version. Below is a small fragment.
Because of the enterprise complexity, it is necessary that improvements be achieved incrementally, continuously and with some verification, in accordance with the classic Deming wheel  – Plan, Do, Check, Act:
• [Plan] measure how the work is done,
• [Plan] observe the business environment,
• [Plan] decide in what areas the enterprise should advance,
• [Do] implement the decisions taken,
• [Check] validate the effect of those decisions, and
• [Act] refactor both the control and the operations parts of the enterprise business system to adopt internally the improvements.
For me, the process begins with making it clear that nearly every job includes a certain percentage of responsibility for constantly looking for a better way to do things. The tools used will vary based on the organization, but the first (and on-going) step is constantly questioning how things are done today.
Good question about the process of process improvement. It's almost a
For a BPM-curious business manager, also a BPM neophyte, what would be a good answer? An answer that would
[u]not cause the manager to flinch[/u]? (Because any reference to a "process process" is likely to cause a business person to "reach for their revolver".)
So here it is.
[b]WHAT IS THE KEY TO PROCESS IMPROVEMENT?[/b]
1. First of all acknowledge that we even
[u]want to do systematic process improvement[/u].
2. The key is "
[b]systematic[/b]", which is about taking responsibility and requires investment.
3. Because otherwise process improvement is just lip service or apple pie.
[b]SO WHY IS SYSTEMATIC PROCESS IMPROVMENT SO IMPORTANT FOR ENTERPRISE?[/b]
1. Process concerns the work of enterprise.
2. Process improvement is about doing that work better.
3. And process improvement has to be organized systematically.
4. Failure to support and manage process improvement is to say that
[u]taking responsibility for how we work is not important[/u]. That work will
[u]organize itself[/u]. That work is a
[u]black box and it should stay that way[/u].Which is a kind of
[u]magical thinking[/u]. And the result is that our work is organized
[u]according to prevailing norms only[/u]. And work
[u]process change will only be ad hoc[/u]. Leading to degradation of work processes and entropy. And ultimately we will fail.
Work processes aren't sufficient for successful enterprise of course. One can have great work processes which are poorly resourced or producing a product or service no one wants.
But to valorize process improvement is to acknowledge that management has a responsibility to lead.
Process improvement is the application of management art and science to existing ways of work.
[b]Process improvement is the ultimate in practical modernism. We do not accept the status quo. We can do better. And we will do it systematically.[/b]
For the business executive, what could be more exciting or more important?
Some readers might suggest that saying "process improvement is important" is a trivial statement and that I've tried to prove the obvious. And yet systematic process improvement is not widely applied. And magical thinking regarding work processes is common.
So the answer to the question is, "management must make process improvement a central concern of leadership".
There's a good section in BPM, the third wave, on this subject.
1. running the process (instance)
2. set of process instances (managing the execution of a set of processes)
3. improving the process definitions for the future ...
I always saw these as axes on a plane - X, Y, Z - each orthogonal to the other. People do #3 all the time when they kick off a BPM project... but they have a harder time sustaining it over time (Program, culture, institutionalized)
The process for process improvement? You and me. It's that simple. You can throw in zillions of methods, if you and I however don't adopt, it's useless.
From a Knowledge Management (KM) perspective, “process innovation” has a lot of coincidences with Nonaka & Takeuchi’s classic KM approach. I like to resume it like this:
[b][quote][i]Let the knowledge flow and it will grow; keep it for yourself and it will die.[/i][/b][/quote]
So the first thing to do is share the knowledge about the process:
Its graphic diagram
Involved users and related stakeholders
Relevant attributes (such as pre conditions, post conditions, constraints)
KPI’s (how is it running, involved times in each step, how many instances are being created, and so on)
And, you should use the most effective tools to do it, called them intranet, mails, slack or any sharing tool you prefer and is suitable for YOUR team.
Next step is share, discuss and grow the knowledge, what translates into improvements for the processes. It is important to
[b]transform tacit knowledge into explicit knowledge at this stage[/b]. A really productive meeting must be explicitly documented to avoid losing the new knowledge. Not too little, not too much. Just the necessary documentation to later
[b]implement changes in the automated business processes[/b].
And finally, start again ;) Yes, it never ends, that’s the idea.
Ahhh, one more thing, of course, the whole cycle will work well
[i] if and only if,[/i]implementing the improvements is easy and fast, so an
[b]agile BPMS is required to establish a process improvement culture[/b].
Our experience, based upon our early early adopters, suggests that once a user regains confidence in supporting software then that encourages ready change direct from their ideas and then that new door on continuous improvement opens up. The challenge then moves to curtailing the wild ideas into practical solutions.... !
What you are ultimately asking for is a methodology for such work. In our "PRIDE" methodology, it is Phases 3 - 7.
In reading the comments above, I find it interesting there is little consideration for specifying information requirements as a prelude to design.
No amount of elegant programming or technology will solve a problem if it is improperly specified or understood to begin with. Even a manually implemented business process that accurately satisfies the user's information needs is better than an automated implementation that does not.
The first step of process improvement is to suspect that your process can be improved.
Hi all !
I'm not sure if I understood the objective of the question, but here we go....
Thinking in a process as a flow and structured set of activities, I would suggest a flow process as follow :
Confirm -> Define -> Plan -> Analyse -> Simulate -> Validate -> Develop -> Implement -> Execute -> Monitor
1- Confirm if process truly needs a formal improvement's project or just need small adjustment to attend his objective. Avoid unnecessary effort.
2- Define the target outcome and KPI, the scope of the project and stakeholders involded to concentrate the effort;
3- Plan the deliveries, timelines and how to approach the improvement considering resources and stakeholders involved in the process;
4- Analyse the current state of scenario of the process flow, maps, data, KPI, etc
5- Simulate new scenarios which best reaches the targeted outcomes and also to satisfy stakeholders.
6- Validate the proposed scenarios and get approval with process owner and stakeholders.
7- Develop the improved process which includes simulate and testing it.
8- Implement the improved process and testing it.
9- Execute the improved process.
10- Monitor the improved process to ensure it is reaching the targeted outcomes and KPI. Formal delivery of improved process for process owner.
When do you (let) repair your car? When it's needed.
But, when is it needed? When it doesn't perform as expected and you are not happy with.
How do you know the car doesn't perform?
There might be indicators on your dashboard, it might be checked against legal standards (MOT) or it might just be a feeling (I feel it lost some power)
And when something indicates 'lower performance' then you still can decide to fix it or not, depending on the fact if it is really urgent or not. A broken timing chain is a little bit more urgent than a window that doesn't go down.
I hope this little car story makes you understand that it's weird that many companies still start process improvement with modeling, analysing, valuestreammapping, redesigning, etc of their process, without a proper understanding of:
- Is this really a (useful) process?
- What promise does this process has to fulfill?
- Does it do that?
- Is it really urgent to fix it?
So, Process Improvement. To do that at least you need... processes.
And that's not a big deal, because every company has them. The only problem is that still many don't look at their company in a process oriented way.
So the first step would be something that could be called discovery. Actually, it doesn't matter how you call it, but the goal is to answer the question; ar we talking process?
Some seem to have trouble with answering that question. Actuallty it isn't, when you remember that processes are just the things that deliver what you promise, as an organization.
And those are probably services, products or solved problems that somebody wants. And I always make a distinction between process results and goals.
A process result might be: 'Permit granted' and some goals might be '< 5 days' 'compliant with laws' or 'doesn't cost more than 70 dollars'.
So you need to know if these goals are met. Otherwise you start improving things that might not be broken at all.
So these 2 first steps; I call them Discovery and Prioritize, prevent you from wasting time on things that don't need to be improved.
And after that it is trying to understand what causes bad performance and trying to fix it with modelling, process mining, wokshops, whatever. I think there is written more than enough about that.
Although I still apply above steps, I'd like to call it traditional process improvement. As said; processes already happen at your organization. So more and more I help to enable employees to improve processes during execution.
So that means:
- coaching them in 'process awareness'
- Set up indicators for process performance that really mean something
- But most important: Make them understand what makes a performing process and make them responsible for that
And to be honest; also this is nothing special, as it is the underlying principle of lean for example.
So, concluding; the most important step is deciding what kind of 'process improvement style' you want to apply in your organization:
Improving after the game or during the game? Oh wait; [url="http://bit.ly/1HGDt40"]didn't I write about that before[/url]?
- Page :
However, you are not allowed to reply to this post.