With the speed of today's business environment, does it make sense to take the time to try and build the perfect business process?
Absolutely not! By the time you have finished creating perfection the business imperative will have been long gone. In today's world it's better to build good enough, and then iterate from that basis. This isn't an excuse for no design or poor design, there is just little or no need for"gilding the lilly".
With the exception of Nasa and where lives are at serious risk, absolutely not. This world is about speed, failing fast and learning. Today's innovation would not have happened with ol'waterfall design for perfection. Today's successes are the result of iterative design.However, it goes without saying you can'tjust put anything out there willy-nilly.
Logically, Yes; Physically, No. Your design of the logical system will remain relatively static. For example, Payroll is Payroll. However, how we decide to physically implement it will change based on the best method of implementation of the day.
"If anything in life is constant, it is change" - Bryce's Law
Logical systems will change if information requirements change due to such things as government regulations, economics, competition.
The physical aspects will change more dynamically due to changing technology.
For an article on this, see my attached link.
"Perfect" business processes? Yes..and no.
Yes, from the get-go, you should set out an accurate high-level view of the work to be done. What is it? What are the outcomes? What are the stages or milestones through which it must go to reach those outcomes? It's a fairly simple picture, and one which you and your busines leadership can and should define up-front. This much I can agree to call the "perfect" part.
But at the same time, no, you mustn't seek to nail down all the details of the process, rules, UI, integration, etc., etc., that must be worked out to get work done perfectly. This elaboration on the high-level model should be done iteratively. Phased delivery should focus on improving outcomes, adding detail that will move the needle. Even a skeletal system will generate metrics that can guide goals for iterative development. How close you approach perfection is up to you and the value on the diminishing returns as you wring out inefficiencies.
As I read through the responses, it seems everyone interpreted the question to be "should you strive to create the perfect process to the extent that it impacts your project?"
The question I read was, "should you TRY to create the perfect process?" To which I would say, "Yes, as long as you do not impact the project with Analysis Paralysis."
We have seen projects for the same process take 3 months and take 12 months. The difference was the amount of time arguing over the analysis and design, or as-is and to-be.
The corallary to this question is, "Should you implement a bad, (or, less than perfect process)?" To which I always reply, "Yes, if you will improve it iteratively in the future."
Deploy. Improve. Repeat.
The trick is to set expectations appropriately. If your users expect a flawless, complete solution right out of the gate, well, they're going to wait a while. More commonly, though, it's best to get something delivered quickly to address key pain points, and then progressively improve that application over time.
What is the difference between a picture and a Movie. The answer is simple – time. What is the perfect picture for frame 1 of a movie is not the perfect picture for ten minutes in, nor for the final frame.
Our arrogance and belief we can design the perfect process means we make this error all the time when designing process. We design around a snapshot in time – usually the one when the CEO okays the project. We forget the timeline after the project we’re being paid for has finished.
A process has an aim - to achieve the best possible result for the customer of that process. But the needs of that customer change continually – expectations, trade-offs and possible solutions all evolve over time.
So the only perfect process is one which is in touch with the customer need, gathers data constantly and uses it continually to optimise itself and change to suit the changing needs of the customer.
That changes the way we design it. It must be social - involving everyone to develop better intelligence on how the process is doing currently and how it can be improved, to create hard data. It must be dynamic - moving from hard coding to something the users can change. It must be objective, building in testing so the data, not the people, drive changes. Feedback loops ensure that it keeps happening, spiralling towards a better and better process and moving with needs as they change. This is Dynamic Social Process (DSP).
It is about as far from the way we currently design processes as it is possible to get. But DSPs reach 80% of the effectiveness of a “normal” project within days and outperform it within a few weeks. They keep on getting better at optimising and adapting – getting closer and close to perfection with time.
Dynamic Social Processes are the route to perfection.
Perfect is a glimmering mirage. For the top 15-20% of processes the answer in continual innovation and reinvention. For the other 80%, commodity processes as good as the industry / function are adequate. The challenge is identifying which processes fall into these categories and then putting in place the governance that will properly manage processes to this broad intent. See paper we have written on Targeting Value athttp://bpm-d.com/targeting-value/ - happy reading.
The beauty about process design is that there is no ideal, optimal design for a process. This makes BPM less of a science, hopefully more of an art. So we shouldn't aim for perfect processes because they do not exist.
As for continuous improvement (which is the next logical step of this discussion), I believe we should aim to improve process design as part of a larger design thinking framework, not just shoot for incremental process improvements towards some perfect metrics (which are just as illusory as perfect processes).
As one that goes right now through the teething pains of designing processes that are both business-friendly and technically accurate (huge challenge, because I want to reconcile in the same flowchart both the customer story and the technical stack integration details, down to Java class calls and data objects properties), I find myself brutally changing every day large chunks of already acceptable process flows. We had to plug into a DVCS to keep track of those changes (and to keep my dev team sane), because those flowcharts publish BPMN 2.0-compliant XMLs to the project...
In this context, aiming for incremental improvement is pointless. The questions that I keep asking myself are: "have I done enough to get the customer to interact with that screen?" "how is this fixing the real problem of my customer?" "what analogue behaviour is this action replacing?". The answers do not push me towards perfection, but towards relevance. Maybe we should aim for that, for starters.
Per Bogdan's comment, "we should aim to improve process design as part of a larger design thinking framework."
Perfection may not exist explicitly in BPMN form. It should however exist as an expression of its accompanying metrics, measures, and reports (etc.). Perfection is therefore an idea placed into the minds of our process owners and is both shaped and a reflection of our methods applied towards the collection and presentation of data.
(Repeated from reply above to @Peter Franz; editing and formatting not available in comments)
@Peter: I have downloaded th BPM-D paper referred to in your note and it's very good -- and nicely based on some research.
And as you have pointed out, 80% of processes for any industry or function are typically commodity processes, and only the remaining 20% relate to value creation, differentiation etc. (Let's assume that we have some proxy for "counting processes", perhaps "process steps".) [I will comment that the foundational 20% of processes is most likely instantiated in whatever ERP system is in place.]
On this basis the original question can be addressed with some interest. All the answers above are very good -- and even poetic. Clearly the "Platonic process" is a glimmering mirage; but our suspicion of perfection should not blind us to doing our job.
North Americans can be accused of an excess of pragmatism; on the other hand the prejudice is that Europeans are afflicted by an excess of theory.
But the job in either case or wherever you are is this:
(1) for commodity processes, you should know your processes! Aberdeen Group and others benchmark various processes, and we always see a wide range between best-in-class and laggards. There is a huge room for improvement even in so-called commodity processes!
(2) And for the differentiating 20%, one has the obligation to "understand the edge" and the "innovation frontier" that will make process-based wins possible. This is a challenging objective.
So, "the best is the enemy of the good". But let's not let this truism be an excuse for not "doing our best"!