In your experience, what is usually the biggest obstacle to process improvement in an enterprise?
I find that enterprises usually know what changes and improvements they would like to make to a process. However, once the enterprise starts looking at the details of the process, they often find lots of old systems, connectors, and reports that will need to change as a result of changing the process. So, although the desire to change is present, and although the understanding of what the final outcome should look like is present, when the enterprise digs deeper, leadership realizes that there are usually a number of connected systems and data points that cause unwanted "stickiness" with regards to the old process. At this point, we often here things like, "well, we will need to still have this report," or "and this system will still need to be get updated." The stakeholders then realize that the change will have a cost in terms of time and other resources besides simply the cost of the resource that is redesigning the process. And many times these "other" human resources are very specialized (only one person in the organization understands how a certain connector or edge system works) and those resources tend to be busy on other projects with more immediate or higher priorities.
Methodology is the simple answer here.
Process improvement is done as a project.
Initiated by the C Suite.
And whose success affects someone's career prospects.
All three of those set it up for failure.
Let's take the project first...
If Karl Benz had set out to create the LaFerrari or the McLaren P1, he would have failed. But subsequent engineers have built on his work, until those are now possible.
The idea that you can get it right in one iteration is simply arrogance. Or the lie you have to tell to get the contract.
In a data-driven world this is even more true. As Edwards Deming put it - "without data, you're just another person with an opinion".
The greatest strength of BPM over Lean or Six Sigma is that the software generates rich data.
You can see instantly, from a coffee-shop half way round the world, where you are losing time, whether your exceptions are too high, or where you are dangerously close to capacity (or not close enough).
It is easy to set up what-if scenarios and even AB test alternative methods, structures and stress loadings.
But a project doesn't allow you the time to do this. So the project is locked down at usually less than 50% effective.
Backed of course by the lie that that is as good as it can be.So the company limps on with sub-standard processes for years, usually until a new management team realises the process is not "as good as it can be".
Now let's look at the C-Suite.
By their very nature, these people are several steps removed from the customer interface, where data is transferred from customer to company.
Now every person - and I mean every - is selective about what they tell others. They like to pass on information which makes them look good, which doesn't lead to awkward questions and which they can defend if asked. So even one level removed, the data is corrupt.
Add a few extra levels and just how good is it? Let's say 50% gets through each time. Take it through 3 levels of management and only 12.5% is getting through. How good is a process designed on 12.5% of the data likely to be?As Ross Brawn put it "Bad Data is worse than no Data".
Ah but, I hear you say, part of the project involves getting the project team to ask questions from the people at the front end. OK - their questions are informed by the 12.5%, taken to another level - now 6%. And people will say what they think you want to hear. If you ask me "How are you today" do I tell you? Same if I ask what would you fix about your job - they will have framed it around what they do now and don't know what they don't know.
So you design a process around uninformed opinions and flawed intelligence. Expecting to produce a perfect process, straight out of the box. Really?
Last, but not least, this is someone's baby. It is something they feel passionately about - enough to push it through the "we have a problem" stage and the "we need a budget to fix this" to the "let's get a project team together" stage. At each one of those stages they will have defined the shape of a solution. So they won't want you to dig into the data and create the best solution - they want you to create their solution. Otherwise they will have to go back to their bos and explain why their solution was worng and they didn't know as much as they thought they did. Hard, especially if, as is usually the case, doing it the more considered way is more expensive.
And for every person who thinks X is the right solution, there will be someone else who thinks Y or Z is better. Often their reasoning isn't even rational - it is simply that they hadn't thought of it first, because they always oppose suggestions from this person, or because they have their own competing pet scheme. And they have a field of influence for their opinions. So you build up two or more opposing teams and each spends 80% of their resource undermining the other (look at parliament for a template). That escalates the cost, the time and the amount of effort you need to put into persuading people of the benefits of your solution.
The answer, by the way, is to share the problem, not the solution. Get all management levels involved, with skills training and knowledge sharing if necessary. Get all the opposing factions working together to set up a Minimum Viable Product. More importantly create success parameters and a method for analysing the data and crowd-sourcing solutions (for example, taking the biggest problem identified each day). Share the results, visible management style, with everyone, in experimental fashion (-we tried this, here are the stats, without blame or approbation). People will start to accept the data, rather than argue. Slowly people will get excited about seeing the numbers change as the result of their efforts. They will start talking about it, and asking others, even in their free time.
All you need to do then is keep the enthusiasm up. Call it employee engagement if you must.
Quickly the MVP will go from 50% efficient to 80% efficient. But keep going - it will reach a lot higher (often well over a 100% of what was thought possible) - and it will evolve as needs change. That means you'll never have to go through this painful process again. And because employees are engaged, they'll share insights on what's coming up and you can actually out-evolve the market.
In my experience, the main obstacles are usually the very actors of the process, when they feel afraid of losing power.
In abstract terms, everyone wants to improve the efficiency of their processes, until the moment they realize that increasing transparency thereof may jeopardize some of their own practices which may not be willing to change.
Unfortunately, I have had cases where even proving the evidence of the benefits of a change from the "as-is" situation to a "to-be" scenario, appeared the most unexpected resistance coming from the less suspicious people when the project starts.
So the lesson is that the choice and the commitment of sponsors and also the managing of expectations along the project, are critical success factors, even if we have the best technical solutions.
Process improvement competes for time, attention, and resources with delivering day-to-day work. Unless an organization has a management system of 15% time, or 20% time, or daily huddles, where time and resources are set aside for improvement, the urgent whirlwind of today's activities will squeeze out the merely important of tomorrow's improvement.
For example, see my Harvard Business Review article, "How to Sustain Front Line Process Improvement Activities".
To crystalize this tradeoff,we introduced a diagnostic tool that confirms that the battle between today and tomorrow rages on, and that tomorrow is losing. See my Harvard Business Review article, "How to Prioritize Your Innovation Budget." We offer some ideas on how to shift and protect resources for tomorrow.
I think the biggest problem is continuous improvement. I think that BPM projects can be improved and implemented, but then they are done, and companies are on to the next project. The U.S. is a project oriented culture. Ask: does the redesigned process get monitored? What needs to be done to sustain the results? Weknow that the initial improvements from the project are just the beginning. If a group revisits the process again ( either short term for daily to weekly small improvements) or for another project in 6 months to a year, there can be further improvements because the onion has been peeled away with the first project and now we can see more possibilities. But often companies are on to other things.
I’ve seen many obstacles for process improvement like:
But the biggest obstacle is, like Peter said above, that improvement often is locker room talk. Everybody wants to talk about improvement, but that is not the same as improve.
as-is has-been process maps into to-be might-be-done process maps, that is not processimprovement.
Of course it is depending on the type of people in an organization, but I believe that improvement can only be successful when it is it initiated and done by the people who do the work. They know what's going on. what are the constraints. But than you have to see those people as improvers and don't treat improvement as a project on the sixth floor by those cool guys with ties from the process excellence center thing.
And yes as selfsteering, improvement oriented workforce; that cost time, they need coaching and they need information. But by using technology that informs on what is happening, performance, etc they can get more and more enabled.
It doesn’t work everywhere. That’s not because the people are not able, but they are constrained by 15 layers of hierarchy, 16 tons of procedures and 34 managers with a mortgage.
I agree with most of the comments, but I am most aligned with Shelley. And from that perspective, I add an obstacle that in my experience is very hard to overcome.
After improving the process and putting a new version in production, the process, or the whole system, goes unstable. Errors might appear, unwanted results, broken integration with other systems, and so on. The problem usually is that we don’t know WHAT could fail. In testing and preproduction environments everything goes well, but when we put it into production, something fails.
These unwanted and unpredicted errors produce several consequences:
So, in sum, improving a process and delivering a new version could arise unwanted errors, and this could avoid people from continue improving it. It is fundamental to use a tool and a methodology that assures than new process versions will be deployed smoothly.
Our research has found the biggest obstacles to process improvement within the enterprise are as follows:
Process optimization projects should improve a specified set of parameters and ensure that they are aligned with business goals. An organization needs to adopt a series of best practices including: defining proper KPIs, keeping the lines of communication open and staying focused on the end game.
In this comment, a perfect project management practice and ideal conditions for process execution are implied to concentrate on process-improvement specific problems.
Process improvement projects are usually the best candidates for implementation as a process-centric digital business solution with the use of BPM (as a trio: discipline, tools and practices/architecture). Advantage of BPM are well-know and very attractive for quick delivery: rapid prototyping, low coding and easy evolution.
At one of my current clients, the EA team was considered to use BPM for process improvement projects and they found that the first process improvement project its cost structure is the following:
25 % is to solve the unique business problem,
25 % is to create process components which can be reused in other process improvement projects;
50 % is about operationalisation of some common COST tools.
The risk is high and the impact is considerable for the whole IT department. Certainly, this is not acceptable by any project manager who would prefer to implement his/her projects with traditional technologies (thus adding more legacy applications).
The fact that the common part (which is about 75 % of efforts) being done once will allow implementing further process improvement projects with only for 25 % of efforts is out of the responsibility of project managers.
Fortunately, the client’s EA team have managed to make a case for an Integration and Implementation Platform which will allow implementing digital business solutions in 6 weeks not in 6 months. (See also http://bpm.com/bpm-today/in-the-forum/what-changes-do-you-see-in-the-bpm-market-over-the-next-5-years#reply-2136).
So the biggest obstacle for process improvement in an enterprise is that process improvement must be understood as enterprise-wide not project-wide initiative which must be properly supported by EA.
The word "process". It sounds boring, constricting, techy, unengaging.
A long time ago I wrote this blog about "process discrimination" https://iangotts.wordpress.com/2010/10/22/process-discrimination-and-living-with-prejudice-bpm/
It has a fantastic video which really brings it home to you.