In your experience, which key step is most often overlooked in achieving success with BPM?
Defining success itself. What are OUR goals for this initiative and HOW do we know if we've met them?
S - specific, significant, stretching < (5)
M - measurable, meaningful, motivational < (3)
A - agreed upon, attainable, achievable, acceptable, action-oriented < (1)
R - realistic, relevant, reasonable, rewarding, results-oriented < (2)
T - time-based, time-bound, timely, tangible, trackable < (4)
In my experience; making very clear what process(es) we talk about and what are the result and goals of this process.
I've seen too many NBPM projects; NoBusinessProcessManagement projects where a lot of effort is wasted on modelling, improving, automating and changemanaging of useless processes.
There are three steps overlooked, pretty much equally...
The first is intelligence.
In a hierarchical company, intelligence on what customers need comes in at a different level than the decision makers work at.
Imagine you have five tiers.
The people at the "coal-face" find out what the customer actually wants.
They totally honestly feed this to their supervisors.
Do the supervisors pass this on exactly?
Or do they select the information which flatters them and the information which hides their failings?
So the information which reaches the next level is flawed.Same next time.
By the time it reaches the decision makers, this information is so selective that it sends everyone entirely the wrong direction.
Bad data is worse than no data. Because you think you know what's going on.
So the problem is misdiagosed, and fortunes spent on a solution to a different problem than actually exists.
The second is involvement.
People love change. They go out at weekends to buy stuff just to change their lives. Or to see new places, meet new challenges.
What they don't like is having someone else's idea imposed on them.
So they commit all their resources to undermining it...
or reshaping it to put themselves at the centre of it...
or diluting it so it either fails or fails to have an impact.
In most change projects, 80% of the work done by the peopole involved is to undermine, reshape or dilute.
And there are more of them than there are of you.
So management spends 80% of its time fighting off objections, rather than enabling projects, shaping good ideas and handling enthusiasm.
All because they were too arrogant to involve the people who knew what was really going on in the first place.
The third is evolution.
Because any change only meets the problems identified at that point in time.
Often locking people into a process designed to meet a different problem in a different era.
Markets and businesses evolve. So processes must too.
Not builidng in a process to improve and evolve the process is the biggest failing of BPM.
I'll bet most people are doing all three.
But still expecting their change to be the right answer, enthusiastically received and to give lasting benefits.
Oops. Not our fault, though is it?
Not to disagree with previous responses (I am in agreement!) but to take a different slice at it -
If we consider BPM broadly, and not just the IT project, one of the most overlooked steps is getting into production. How many consultant recommendations and powerpoints are laying around collecting dust (some, maybe for good reason), how many projects fail because the sponsors haven't pulled together the right team and conditions for success? I talk to lots of consultants with lots of projects on their resume, but i always want to know about taking their projects to production and maintaining them after they're live - that's where the rubber meets the road.
I guess it is the difference between "done" as in "works on my machine" and "done done" as in works for the whole company and creates value.
Another overlooked success factor: saying no to the bad ideas (some of those proposals from consultants sitting on the shelf). Investing money in the bad team that is failing, isn't helping you invest in the good team that is winning and creating value. I don't see companies do this very often, but they probably should starve the teams that aren't performing and put more resources behind the ones that ARE performing (often/usually, companies do the opposite... ironic!)
Remember that BPM was coined in the IT world so the start point is understanding how the desired outcomes (whatever they are) will be delivered. This will give confidence as the business starts talking about how they need/want to work. How often has a project started off with an enthusiastic "consultant" in hopes that IT will deliver and then the project becomes part of the 70% of IT project failures?
Really wanted to disagree with somebody... but these are all good points.
The most common overlooked steps in roughly all of the troubled projects I've run across:
Basic... shouldn't be a surprise.
Root cause is generally fallout from a gap in process-management skills. Something of a "first-contact" scenario, when asking about business practice and value-add analysis within/without business units (and cross-functional as-a-process reorganization).
Basic skills? Well, knowing your business well enough to understand, and improve on, value creation (just remembered that famous hamburger commercial, "where's the beef!").
- Process analysts understand and able to articulate process and task/activity values and relationship (context) to overall business strategy (i.e. tactics)?
- Reporting... the absence of measurable business value (metrics) from any BPM project just isn't good. However, forgiveness is due here mostly because BPM, as an IT project, knows zilch about value-metrics. If you see only performance and reliability in your reports, then you have a problem - though it's reasonable (forgiveness) to fall back to BPM as-an-application and simply drop "process management" from the near-term deliverables.
- Business IT, ontology/domain, transaction, and general state management (integration with with business and application service stack). Well, at least we can hope for a decent BPMN process model... However, a BPM analyst who isn't working closely with the information architect (business object domain) leads to extended cycles to account for transformation management. Though missing the importance of semantics/ontology is often a lethal blow to the project.
Without considering all universal PM factors (management support, user involvement, goals, etc.), the most overlooked step for achieving BPM success is architecture.
Any BPM project/program/initiative is “touching” the iceberg of processes within an enterprise (see http://improving-bpm-systems.blogspot.ch/2015/02/iceberg-of-processes-within-enterprise.html). Thus dealing only with its visible part will be as dangerous as asking a captain to navigate close to an iceberg.
Apparently, there are several potential key steps that can be overlooked. I agree with all the above, and will add that there should be a "let's get real" step that involves the task of managing expectations. I have had to let down clients several times when we get to a "the product you purchased does not do that" kind of requirement. Nine times out of ten, they reply (with great disbelief), "but the salesguy told us it could!" This is most problematic when the product cost a lot of money. And then you have to do a lot of custom coding that will expand the construction schedule...more managing expectations. Or when they are really convinced the product can do "anything," you have to tell them "No," hopefully with some alternatives.
What is the AUDIENCE?
You wouldn't write a book, a film, a play or presentation without considering the audience. What do they want? What do they need? How do you give it to them so that they receive (use) it? How open are they to the ideas?
Get this right and you start to answer a number of the questions that have been highlighted in the earlier comments; architecture, implementation, change management, tooling, involvement, methodology/approach.
I can't disagree with any previous post. But I've got a typical and very hard to fix error: selecting the wrong first process to automate
If it is too simple: not enough value to worth the effort/investment.
If it is too complex: high failure risk, long deployment time .
Both sceneries ➡ lack of success ➡ lack of support to continue improving other processes.
I have found that many organizations skip over the importance of proper resourcing/training. They tend to think anyone can do BPM, whether figuring out how to make processes more efficient, gathering requirements, implementing solutions, or moving a solution into production. Leaders need to get away from thinking BPM is a tool like a hammer that anyone can pick up and use. No, BPM is a suite of tools and methodologies that when used by thoughtful, trained, and experienced people can completely transform business operations. The more workflow improvement participants (stakeholders, business analysts, project managers, UX designers, developers) know about methodology and product capabilties, the better questions they can ask that lead to more efficient/effective process and cleaner use experience. Training matters! Experience matters! If you don't have the right people, partner with vendors and/or system integrators. Learn from them. Also, please consider hiring PMs, business analysts, and developers who know methodology and functionality. You might pay more up front, but the benifits will be seen in a project done on time with greater functionality and usability.
Without disagreeing with anyone above, I'd like to answer to this question from a deceivingly pragmatic viewpoint. I am not a consultant (although unfortunately I will have to do that as well), just a customer who has experienced the power of BPMS, with upsides and downsides.
But I'd like to start with an analogy.
I am an amateur photographer (but a pretty good one, at least from a technical standpoint). A lot of beginners are asking me the typical question: "If you were to give one single advice that would improve my photographs overnight, what would that be?". Professionals tend to give highly inspirational answers to this: "believe in yourself" "love what you do" "give your 120% every day" and all the typical crap successful professionals pour unto unsuspecting new entrants.
I am not a professional therefore I can afford to get away with second-hand advice, grounded in my limited real-life experience: "Mind the borders". Simply put, as opposed to painting, photography is the art of exclusion - the artist gets to choose what does not make it into the frame. Do that carefully, watch for objects being cut off from the frame - and your photographs will suddenly look more carefully framed. If you apply this advice, you will start thinking about how and why you take a picture. This makes a world of difference - at least it made for me.
So translating this to BPM projects, my limited amateur advice would be: "Mind the business rules".
So many BPM projects engulf complexity by embedding (or worse - hard coding) business rules into the process flow itself. That is wrong because then your process gets ossified and is not scalable. Work with a rules engine. Yes, it is complex - the modern ones are already expert systems, already with a bit of artificial intelligence in them - but the payout is tremendous. Effectively separating business rules into a rules engine gets you thinking about how your business ticks and makes process design one order of magnitude simpler -- this enhances the chance of BPM success.
I missed this point - and, apologies if this was already mentioned.
But... what about configuration management and software development life-cycle?
"BPM Success" doesn't imply a once-and-done solution. We must leave behind a sustainable, ongoing BPM program - meaning there will be follow-up maintenance, upgrades, and configuration adjustments.
The BPM run-time model cross-cuts the organization. What was once a set of single purpose point solutions, now driven by BPM systems, becomes coordinated – something more than an aggregate. Thinking in terms of a process-aware application with its accompanying retinue of support personnel and dedicated configuration tools... implies additional attention on configuration management and software development life-cycle (SCM, SDLC, etc.)
Once stand-alone groups and applications now become reusable, cross-enterprise business services. We have business domain, knowledge, application-services, and supporting infrastructure all requiring rules and procedure around derivation and extensibility. With process applications, each point within their evolved composite require cohesion at the process level. This cohesion insures accurate meaning and interpretation throughout their communication channels.
A sustainable BPM program requires: