If you were to compile a checklist for the success of a BPM project, what steps would be essential?
Senior management's sponsorship and [quote][u]sustained involvement[/u]
Business and IT's consensus on what the
[u]measurable[/u]goals are and keep track of them.
Educate, educate, educate. If the expertise doesn't exist in-house get it outside, but go with a proven consultancy, not only on the platform, but on the business verticals - be it the vendor's professional services group, an SI or a consultancy. DO NOT pony up for the full enchilada coming out of the gate.
Engage the front-line, end-users and authorize and empower them to speak on behalf of and define the functionality.
Monitor, measure, refine, rinse repeat in tactical, manageable bites with an eye towards the tactical solutions incrementally and iteravely building out to the strategic end-state defined in points 1 and 2.
Don't listen to any GFFUD.
Just my tuppence.
My top 3:
1. Management support
2. Organizational culture awareness
3. Solid knowledge of BPM methodologies, standards and tools
Step 1. DO NOT CALL IT A BPM PROJECT All other steps have already been covered. But are irrelevant if you miss step 1
In our experience, the top 5 are:
People. Get sponsors and top level alignment.
People. Identify retractors, evangelize and convice them.
People. Build a Strong team, with experience in BPM and change management.
Technology. Choose the right BPMS for your needs. Do not buy 'any' or 'the best'. Buy the most suitable for your kind of business processes.
Structure. Adequate HR structure to support a process driven organization.
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.
In my opinion you suck or you don't. And if you suck you should be aware of it, understand the causes and change.
But go ahead to give me a score on a bpm scale
What they do care about is their customers they serve each day by doing their job. So that's why I think BPM is daily business. Every company is trying to bring it's processes (they probably don't call it that way) to a good end. And some suck in it, but they are doing BPM. That's why I also don't like the 'levelization of BPM'
Customers don't care whether are not a company is on level 4 on some kind of BPM maturity thing. That's BPM world talk; not daily business talk. Daily business is about delivering promises or not.
And in my opinion BPM is never a project. Implementing stuff to make your processes better might be executed as a project, but bpm is just getting the best out of your processes each day.
And maybe my english is not so good, but everyone can do verbs each day: work, do , improve, discuss, collaborate etc.
And btw, I do not understand why BPM cannot be a project. It is a project. When it ends becomes BAU with KPIs. Do you need / want to adjust your KPIs to dominate the market? Ok, call for another BPM project. Only a process oriented company (maturity level 4 / 5) can say BPM is not a project. For the rest... come back to the real world.
Imagine you go to the doctor and you receive a wrong diagnosis. The wrong diagnosis is because the doctor is not having a sound understanding of his job, meaning the doctor did not reached level 4 on the competence scale (let's assume 5 is the highest).
Now make an analogy and think about the customers not caring about the company's maturity level. If really the case, customers are naive and they will bite the dust later on when the company's maturity level will cost them receiving something else than expected ;-). So, better to be informed than sorry.
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.
+44 (0) 1491 874368
+44 (0) 7590 677232
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
Absolutely get the team co located business and technical
Get crystal clear about objectives scope and requirements
Get a technical team with a proven track record in the technology you are using
Make the project small and manageable - deliver success early and often
Choose the right technical solution for you not just the market leader
Get a really strong and passionate business sponsor
[url="#reply-1988"]What Patrick said[/url]. 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
[b]intentionally half-baked[/b](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.
But I do pay my external consultants to deliver the half-baked solution + the change management during the transition of the whole organisation to the fully baked solution :-)
- Bogdan Nafornita
- 2 years ago
- Bogdan Nafornita
- 2 years ago
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
[b]mandatory but not sufficient[/b].
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.
- Dr Alexander Samarin
- 2 years ago
I would add as a mandatory step... graduate an emotional intelligence course before starting the BPM project :-) Never neglect the human side of the business.
There’s another way to look at this:
[i]What makes a BPM Project Fail?[/i]
Peter Schooff contributed an excellent chapter to “[url="http://futstrat.com/Passports.php"]Passports to Success in BPM[/url]” 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
[b]wrong[/b]. BPM done
[b]right[/b]empowers an enterprise to compete at the highest level in any marketplace. “
While BPM being a project or not is depending on the organizational culture (in the end, you deploy a solution that becomes BAU; if BAU is approached as continuous improvement or not is another story), management support is not debatable. You have it or not. And I assume you all know what happens when it's missing.
Therefore, stop selling BPM as a continuous effort. It can be an one off very well too.
If correctly applied, BPM will sell itself ;-)
But serious, I think it has to do with what we think is BPM. To me it is (what's in a name) managing Business processes. To me that cannot be a project; it happens every day.
But to be sure, can you give us some examples of what you consider a 'BPM project'?
A project introduces change. If you want to get from A to B, you need to follow the change, hence complete the project. But once the project is done and you get to B, therefore into the comfortable position, there's no need to change again. BPM asks for change, either it's just BPI, software reengineering or a combination of both. No need to change, no need for BPM. Executing tasks is not BPM.
But ok, let's agree we don't agree on project vs daily business (or at least have another view, maybe with the same result)
mmm.. I'm getting very mild since I have my eco friendly 918 ;-)
There are three vitally important components for successfully implementing BPM:
Analysis and Design– Assessing and re-engineering “as-is” processes to eliminate waste while capturing business and technical requirements into realistic and attainable objectives, specifications, and solutions (“to-be”) aligned with strategic objectives and metrics
Program Management– Aligning strategy with solution design and human resources to guide development and on-going change management to ensure on-time in-budget delivery
Training and Talent Development– Developing skills to analyze, design, implement, deploy, administer, and change solutions
Following are 5 keys to the success of BPM project:
1. Qualify Your Goals Beforehand
2. Obtain Buy-In from Up and Down the Org Chart
3. Select Your BPM Software Carefully
4. Monitor and Measure After Implementation
5. Don’t Think of BPM as a “Project”
- Page :
However, you are not allowed to reply to this post.