Don't listen to any GFFUD.
Just my tuppence.
In our experience, the top 5 are:
I think above comments are more prerequisites than actual steps.
Although I don't believe BPM is a project, I think steps should be answering questions like:
- What process are we talking about?
- Is that really a process?
- Is that really a usefull process?
- What needs to come out of that process and what are the goals?
- Does the process meet that goal?
- Does the process really need attention?
- What aspects of the process are responsible for not performing as wanted?
- What needs to be done to improve those aspects?
Oh wait, this sounds like a project while I think BPM is daily business, so is all about creating process awareness and empowering employees.
So, I would start with making clear the performance of processes and visualize it to everyone. Make process teams and make them completely responsible for the continuing performance of the process. Don't threat BPM or process improvement as something separate from the workfloor. So it's more about changing the management culture than applying bpm tricks.
When employees feel responsible for customer outcomes and are rewarded for that, finally they end up with improving processes. If you force them to work in 'the new process', will it work you think?
So maybe the above comments about 'culture', engagement etc aren't so crazy at all.
Process management is not a position. It's a verb. And everyone can do verbs.
There is one step - and only one - essential to a BPM Project.
Would you even consider doing management as a project?
Having only six weeks, say, in which changes to the company can be made then locking it down for all time.
Perhaps you could have a CRM where you can only put in new people for six weeks.
Same with HR - only hiring for a fixed period.
Ridiculous isn't it?
So why do we consider it for process?
You will have heard of Lean Startup and its core task - Product Market Fit.
It leans on some outdated thinking - thinking we should recognise as such.
Because a company isn't just about Product and Market.
It is also about Profit. People. And Process.
The modern 4Ps which define a company.
We need to create - and constantly re-iterate - a link between each of these and the market.
In process terms, ensuring customers get the process they demand - a level many companies fall below. Adding value, so expectations are exceeded. Making sure the process is efficiently, effectively, reliably and profitably deliverable. All other processes are subservient to that one.
Markets change. Fast and continually. Partly because by offering something we change expectations. Competitors also set expectations and their influence changes over time. You cannot set a process up and assume the market need is the same 5 days, never mind 5 years hence.
That's why a project will always fail. It assumes that the trade-offs you make in setting it up will still hold good months, even years down the line.
Getting Fit isn't a short term thing. If you really want to be fit, build a continual Process Fitness Programme, with market intelligence and a simple and democratic means to change the process regularly. Turn it from project to culture.
BPM is journey that brings digitization of the processes that create any business. It will be one where change becomes the norm as better ways or new circumstances emerge. The term "project" is too limiting.
So first step is understand the supporting software capabilities and how it actually works in language that users can understand and thus they have confidence their ideas will be taken seriously. Build a first cut /prototype in days show their ideas coming to life. Once that happens no turning back; the new journey has started.
Also important that "legacy" does not interfere with thinking and is the "slave" to the operational processes as required. So best not to have build driven by "IT".
1. Get the top management's sponsorship;
2. Understand the business strategy to decide what business processes are really critical and what goals are really important to achieve;
3. Design a value chain and a process architecture;
4. Do the alignment of strategic goals with key processes from value chain, and model the main steps as As-Is situation;
5. Compare planned goals with achieved goals as As-Is situation in one process, and identify process improvements;
6. Do the analysis of improvements implementation costs and business benefits. If positive, implement the improvements as To-Be situation;
7. Compare again planned goals with achieved goals after the improvements implementation, and put them in evidence, in order to help to convince the people who are involved in next process.
With these steps we have a way to start small but with what is really critical to the business, involving only the necessary people, easier to convince, and create a basis to expand BPM across the company, process by process, benefit by benefit.
In no particular order
What Patrick said. Also, this always seems obvious when said aloud, but: pick a winner. Do something small that you know you can get your hands around and conquer. Success breeds success. Get in trouble on that first project, though, and there isn't going to be a second one.
All the points above are valid and I will not repeat just for the sake of chiming in.
I have a different approach, maybe at first it looks a bit controversial but it has worked every time for me (I already gave some examples in other discussions here).
Situation: you lead an organization that has never heard (or cared) about BPM, deeply entrenched manual culture, enthusiastic but clueless.
1. start with something small - a quick win (as E Scott Menter said)
2. bring people with the right attitude
3. launch the improved process intentionally half-baked (or incomplete anyway), just as a sample
Something magic happens then, everytime: as you sample a superior work technology to business people with the right attitude, their minds get seeded with a fresh perspective and they get excited. They quickly fill in the blanks in the initial process deployment. Then they come with a huge number of constructive improvement ideas, which they never suspected they had. They become part of the solution, rather than of the problem (org resistance).
It's all downhill from there.
All of a sudden, out of a small invoice passing project, I have a 2 years pipeline for EA projects, mostly BPM but including portal, SoA integration with existing tools. Every week an improvement in the IT landscape occurs and they key achievement is that it is not initiated, tested and run by me anymore, but by my people.
Mainly, align with Bogdan.
I “translate” the original question as “what must be added to perfect project conditions and management for the success of a BPM-centric project”
Unfortunately for many of BPM-centric projects just adding excellent knowledge of BPM discipline, BPMS tools, business process analysis techniques and process architecture is mandatory but not sufficient.
Remember that BPM is 50% of EA. Because of its enterprise-wide nature BPM touches many things in an enterprise, a BPM-intensive project is just a tip of the iceberg. For example, for one of my current clients, I have to support an initial BPM project by new data architecture, modernisation of an in-house ERP, new guidelines for governance, management and operations for the IT department, making security explicit, creating business analysis practice, changing project management and SDLC practices, etc.
There’s another way to look at this: What makes a BPM Project Fail?
Peter Schooff contributed an excellent chapter to “Passports to Success in BPM” in which he examined the top 5 reasons why a BPM project fails.
His report was based on many conversations in this very forum.
And what’s the TOP Reason for BPM failure? Treating BPM as a Project.
He concluded that …”it is absolutely essential to understand and avoid the key ways of doing BPM wrong. BPM done right empowers an enterprise to compete at the highest level in any marketplace. “