(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.
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 sales question.
For a BPM-curious business manager, also a BPM neophyte, what would be a good answer? An answer that would not cause the manager to flinch? (Because any reference to a "process process" is likely to cause a business person to "reach for their revolver".)
So here it is.
WHAT IS THE KEY TO PROCESS IMPROVEMENT?
1. First of all acknowledge that we even want to do systematic process improvement.
2. The key is "systematic", which is about taking responsibility and requires investment.
3. Because otherwise process improvement is just lip service or apple pie.
SO WHY IS SYSTEMATIC PROCESS IMPROVMENT SO IMPORTANT FOR ENTERPRISE?
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 taking responsibility for how we work is not important. That work will organize itself. That work is a black box and it should stay that way.Which is a kind of magical thinking. And the result is that our work is organized according to prevailing norms only. And work process change will only be ad hoc. 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.
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.
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)
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:
Let the knowledge flow and it will grow; keep it for yourself and it will die.
So the first thing to do is share the knowledge about the process:
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 transform tacit knowledge into explicit knowledge at this stage. 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 implement changes in the automated business processes.
And finally, start again ;) Yes, it never ends, that’s the idea.
Ahhh, one more thing, of course, the whole cycle will work well if and only if, implementing the improvements is easy and fast, so an agile BPMS is required to establish a process improvement culture.
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.
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.