First of all a process should be effective; delivering what you promise.
And then the anwer to the question is 'it depends'
If the same effectiveness (the same process result) is required for a long time and for many cases, you don't have to bother about adaptability and could try to increase your margin by focusing on efficiency.
If "effectiveness" is different every minute, then adaptability is more important.
And this can differ from process to process. Internal processes like AP; what needs to be adaptable about that? Automate the hell out of it.
Primary processes in an ever changing market? Adaptiveness seems more important to me in that case.
And in fact; if the only way to earn money is making your primary processes more efficient (aka save costs), you might be in the wrong market.
(No I will not use the 'the only constant is change' quote)
I dont' think those are mutually exclusive. I am with Emiel as it should be effective. Some routine processes with absolutes should probably be more efficient and less adaptable while others definitely need adaptability for exceptions (there are always exceptions). Not matching the process to those requirements creates problems with acceptance, workarounds, alternatives, etc. and you are right back where you started with lots of money spent on ineffective processes.
You can be terrible efficient in executing the wrong things. Just have a look at our governmental institutes say...
So that basically rules out efficiency as a priority. Which leaves the concept of adaptive. If a process needs to be adaptive, as in: I can change the process quickly enough in order to anticipate a changing environment, that would be effective (as also Emiel states). Then I could try making the adapted, effective process more efficient. But avoid the pitfall mentioned above...
Adaptive has 2 key characteristics. First the system recognises the user their role and requirement for any instance of any task. Second the system has in built adaptability to allow easy change as business needs evolve with experience and market pressures. Implementation of these capabilities will bring efficiency and in our experience surprisingly quickly.
I would add that Adaptive Software should bring transparency across the organisation allowing knowledge distribution giving all comfort that all processes are in good shape encouraging efficiency. Sure you can have efficiency without Adaptive but may take a lot of effort to maintain constant change/efficiency but Adaptive just goes hand in hand with efficiency.
Hi team !
The design and the excution of business process must be whevener possible Efficient and Effective to accomplish with the stablished goals.
If the case management as also the business process is not well designed and executed the Efficiency will not be reached.
The case management may bring more flexibility and adherence for the execution for business process for some types of business.
With the modern rate of expected and unexpected changes it is practically impossible for a process to stay efficient and effective for some “long” time (yet another factor of uncertainly). Thus a process must be adaptive to be easy adjusted.
A process may become 1) “a performance error” or 2) “a point of the most leverage” or 3) “an area of least resistance for change”.
Obviously, after implementation of any change, all the processes must be re-evaluated again.
ADAPTIVE > EFFICIENT, because:
1/ Iteration beats planning.
2/ An adaptive process ultimately leads to efficiency gains. The reverse is not true.
3/ An adaptive process escapes local optima via mutation of the model towards the global optimum. An efficient model always locks in to a local optima (which may or may not be the global one).
I am with Emiel on this, plus any others who highlighted that the focus needs to be on "effectiveness”.
First of all, work as we know it today, is a mix of 5/95% structured/unstructured work to 95/5% structured/unstructured.
Pure research will be close to 5/95% (never 0/100% because you won’t get to do any research unless your grant application follows protocol).
Industrial fully-automated end-to-end processes fall into the 95/5% category (never 100/0% because every process will always accommodate at least one ad hoc intervention called “Stop/Exit”).
We have for years built processes where, plan-side, all pathways/sub-pathways conveniently dovetail to an “end” node where you can park an objective. The usual declaration at an end node is “Done!” (i.e. nothing left we would want/need to do).
Soon as a process owner admits that his/her process does not anticipate all possible interventions (i.e. the line starts here), we need to graduate to adaptive and what this means is the ability to re-visit already committed steps along a process, skip one or more steps that are “current”, record data (but not commit) at steps downstream from current steps, and insert steps that are not in the process.
The implications are that your “process” is now a “process fragment” (no point trying to build end-to-end processes if they are going to be interrupted by ad hoc interventions) – so it does not take long for process mappers to realize that the easy remedy is to build a Services Menu and let users, software and machines thread together "process fragments".
A Services Menu avoids having to embed short sequences of steps into multiple processes you may have and need to be improving/maintaining.
A run time Services Menu greatly reduces the complexity of flowgraphing.
If follows that with process fragments we can no longer entertain parking objectives at process end nodes, plan side, given that these end nodes no longer represent the “end” of work.
Accordingly, the parking of objectives needs to move from plan-side to the run-time environment which almost everyone today agrees is Case.
Martha Stewart would say this is “a good thing” because it lets Case Managers manage their Cases.
Process Fragment template instances can be efficient, but the route to effectiveness involves managing workflow, managing workload and periodically assessing progress toward Case objectives.
The rules for effectiveness are very simple.
· Don’t fund Cases that are not supportive of strategy (do the right things)
· Intervene at Cases when progress is off plan (do the right things the right way, using the right resources, at the right times and places).
So “. . . is it more important for a process to be adaptive than efficient?”
No, because you need both adaptive and efficient.
Except that adaptive and efficient together is not much better than neglecting one or the other because what we really need is effectiveness.
Think of processes like Olympic events.
A certain class of processes are like track & field: the goal is to get rapidly from point A to point B. The route—even the carefully designed obstacles—are mapped out well in advance. The only thing the participant has to worry about is to stay inside the lines, and to finish as quickly (or jump as high or throw as far) as humanly possible. The need for adaptability is minimal.
Other processes are more like, say, ice hockey. Sure, it's an advantage to be fast, but it's even more important to be able to make an appropriate adjustment as the 225-pound defenseman is about to check you into the 15th row. Sometimes the teams don't even have the same number of players on the ice. Sometimes you don't have a goalie in the net. Once in a while you even break the rules on purpose in order to gain an advantage.
So, if I were to ask you: in the Olympics, which matters more: speed or agility? you'd understandably want more information before answering.
In a world where distruptors and innovators are trying to find the new "it" factor, processes must be both. Do you NEED both? Not really. Efficiency is key to success. Adapability just helps you stay efficient when "ability to adapt" is the new longevity. I would pose that reliability may be more important than either.
What a melange of marvellous musings! And even if most posts are expressed in rhetorical terms (not a bad thing, in my books), the insights are hard-won and worthwhile.
But how do we go beyond "Management 101"?
Because a lot of what is said here could just as easily apply to any method for converting inputs into outputs efficiently and/or effectively. What can be said about the question of process adaptation versus process efficiency which is specific to BPM?
Along with several others, Mr. Nafornita's post stands out here as expressing via clear and concise systems-theoretic propositions the unambiguous superiority of adaptation > efficiency.
Such a formal expression of a business systems problem is valuable because sometimes rhetoric fails us. Specifically, the question of process adaptation versus process efficiency presupposes "that processes exist". We are mostly (and understandably) guilty of reifying the idea of process, in other words conjuring an idea out of a mess called reality. And certainly a reification or a concept is useful -- except until it isn't.
Keith Swenson and Scott Francis seems to have had a bit of a dialogue on the topic of reification, around 2009, focused on the distinction between SOA and BPM. The idea of reification can be pushed further though, in support of clarifying what the BPM business is all about. Specifically, this means getting beyond the reification of process, to the specifics of what makes BPM, BPM.
Compare to accounting again. For fun let's ask the following accounting question: "Is it important to close the books quickly at the end of a quarter, or wait longer to make sure we've caught every expense voucher and bill?" (The question probably makes more sense pre-computerized accounting.) In this case "books" is the reified concept. And we can debate (rhetorically) "speed" versus "accuracy" in relation to closing the books at the end of a quarter.
But I suspect that most people, knowing accounting in greater or lesser degree, will find the question somewhat unrealistic -- because we understand the underlying accounting concepts of debits and credits and journals and postings and legal requirements etc. And there are standard methods of handling uncertainty and late bills. We can just dial our accounting policies up or down as business requires.
This pretend accounting question is perhaps a little awkward. But the question still illustrates how in a more mature business discipline (accounting) fruitful discourse is based on a body of knowledge and rationality. Certainly there is accounting rhetoric (read any annual report). But accounting is as useful as it is in significant part because of the depth and specificity of the discipline.
BPM has such great sales rhetoric. The reality though on deployment is somewhat different. Being very, very specific about what BPM is and why it works can help us go beyond the dream.
Adopting to a new business in a effective way. Creating a new change in business all together in a different way. Technology has developed ours systems needs to be in place in such a way that our needs are improved in a different way, It's true adopting our self to the new changes is very much important to build the business.