Not listening to them. A lot of consultants, particularly Big Four systems integrators, are notorious for this. Want employees to go dark in a heartbeat? Don't involve them, don't listen to them, don't engage them directly, ram through what you want to do no matter what and ignore their collective institutional knowledge out on the cubicle floor. They're only, just the ones who do the actual work, what do they know?

In accordance with popular PM practices, all stakeholders must be classified into those who are critical to the progress and success of a project, and those who simply care (if we have time for this). By default, employees are in this second category.

Not in my world. In my world the cube dwellers are first class citizens. Every client, every site, every project I seek out those individuals who have been there forever, have held every job, know every thing about process, including inter-departmental glue. That individual and his or her counterpart(s) throughout the organization touched by the initiative who've been there, done that and know all about the processes, their pro's, con's, capabilities and limitations.

Then I tell senior management "This is the individual I want in the room (whether it be a formal JAD or just user stories) and I want you to empower them to speak to the functionality and define what's required, needed. You can be in the room, but you are an observer, not a participant." If management lets the people who do their jobs speak frankly, candidly, openly about what does and doesn't work, what they would like to see changed and why, and then that is applied in a diligent manner to the process improvement effort, these people are gold.

Depends on the listener. I'm not going to talk about jazz with a hardcore lover either. A teacher at school has learned to adapt to the level of his scholars also. You cannot expect to teach schrodingers equation in the first year of chemistry in sec. school.

A real example. An initiative group prepared an excellent proposal for a strategic and process-based overhaul of all core business systems. The top management was very impressed, fully endorsed this strategy, gave a green light for its implementation and classified this document to avoid that competitors can access it. Of course, all the employees cannot see this document as well.

Employees, unless they are all shareholders in an organization that has a flat organizational structure, work in these organizations because "it's a job".

You can send them to all manner of weekend motivational sessions but all-in-all they come into the organization, sign up, receive a job description and work within their job description.

A BPM project is typically interesting to all participants, given appropriate working tools and audiences receptive to change (more likely not overly resistant to change), - the team gets satisfaction out of discovery, mapping, improving, simulating/modeling and roll-out.

Engagement of users of BPM run-time environments, on the other hand, needs things to be such that it is easier, less tedious, more productive, to use the environment as opposed to not using it.

If the organization gets this right, then onboarding and ongoing engagement of employees is easy. A bad/awkward UI will kill most BPM initiatives.

Karl hit the nail on the head. The tricky part, when analyzing any shortfall in engagement or adoption, is distinguishing between the natural reluctance of humans to embrace change, and pushback arising from bona fide shortcomings of the application or its UI. Both merit response, but of course the nature of the remedies may differ substantially.

I recall visiting the accounting department of the organization of which I was part; in addition to their regular responsibilities, our staff was also busy training off-shore staff on how to do the job. Correct approach from the company perspective for sure, but one can hardly imagine alignment of motivations, regardless of one's personal ethics and professionalism.

Employees are hired to do a job, and compensated for time spent. Any given employee is probably there because of perceived skills; a significant part of the value of any work is tacit, that is to say an expression of the personal capital of the employee. This is the "as-is" world of work.

But as-is is no longer, if it ever was, always-will-be. There was a time in mid-20th century North America (circa the 1950's and portrayed negatively in The Man in the Gray Flannel Suit) when personal identity was aligned with corporation identity. However since then, memorably signalled byIBM's first ever layoff in February 1993, un-rewarded engagement by enthusiastic employees has been harder to come by. (Out-of-scope for this discussion is the wider perception among all "walks of life" concerning how the benefits of technology are shared; such concerns nevertheless show up though at work where high levels of engagement not guaranteed.)

BPM is fundamentally about changing the way that work is done. The work-of-BPM itself is a lot of work, and most successful certainly when employees are willing to share their insights concerning the work that needs automation, especially the tacit or undocumented parts of as-is work. Consider though that the work-of-BPM pursuing to-be changes will be supported on top of existing work commitments. Exactly how will employee engagement be obtained from employees around 100% engaged? (The challenge of employee engagement explains part of the motivation for top-down or consultant-driven change; such change may be viable and even recommended in cases where some specific tacit knowledge is no longer relevant -- for example paper business forms manufacture.)

Cui bono? Comments on this BPM.com topic above capture many excellent insights concerning how to ensure employee engagement in a BPM project - or better, a BPM programme. We can step back though and ask about economics and ownership. Want employee engagement in your BPM programme? Then consider the real economic costs and benefits from the employee's perspective and figure out how to better align.

Setting aside idealistic, matrix workforce organizations for a moment, the user engagement typically dies or fails to start even, as soon as a BPM implementation get's organized rigidly "top-down", limiting or ignoring hierarchically mid- and low ranking personnel. That's especially true for strongly human-centric processes, which represent higher task volumes (hence process definitions) for lower ranking users than for their higher ranking peers. Failing to make these users an integral part of the implementation from start to finish not only eliminates internal engagement but is even likely to endanger an entire BPM endeavor.

Agree with principle put out by Patrick and Kay - if users get genuinely involved throughout the implementation, they become part of the solution, not part of the problem. And they "own" it. It's "their" system, not something smelly rained on them when they weren't looking.
And of course there's nuances on how you actually make these principles work in practice: - the methodology must allow them to individually contribute, not just attend some committees;
- everything they need to do must be fast and simple, as they get drawn from their day-to-day activities and might be put off by long distractions which impact their measured performance; - the implementation technology must be friendly enough so they don't require any special training upfront (BPMN barely cuts it).

I agree with "Individually contribute" so, if an organization can see the logic/cost savings of bringing in a facilitator for a couple of days, a key element of the facilitation is the occasional handing over of the keyboard/mouse to one of the stakeholders and letting them advance a portion of the work. This increases the level of confidence of the stakeholders and allows subsequent work to be done at-a-distance.

The reason "a couple of days" works is, in part, attributable to active engagement of stakeholders when the facilitator is on site.

GoToMeeting is excellent after this as it removes the need to bring people together in one room, one city.

Your point about "fast and simple" and "long distractions" is worthy of comment.

There seems to be a correlation between smartphone use (instant gratification) and reduced attention spans (or maybe it's just something they eat) - ANY distraction greatly takes away from productivity and results.

"Fast and simple", of course, means different things to different people.

An obvious avenue to "fast and simple" is to avoid taking on too large of a scope when mapping/compiling/rollling out/testing a process.

Committees, sadlly, should have gone away a long time ago. Many of the "why are we here?" meetings should be cut back - I worked in the Far East out of Singapore for 9 years and had good success with stand-up meetings (Learning Circles?). My agents in Japan/Korea hosted one of these each morning. These meetings usually lasted no more than 15 minutes.

Another trick that works to reduce visitor time in your office is low chairs with no cushions and a low air con setting. I did get a few side glances wearing a sweater in the tropics.

Nicely and succinctly said. Worth exploring in more depth is the concept of "employees 'owning' a process". Big implications here if "owning" is to have any substance beyond rhetoric. As you know, your neighbours in the former Yugoslavia tried out something like this (workers self-management) back when Yugoslavia was Yugoslavia. It would be interesting to know what is today's assessment of the success of that approach. And if there is any relevance to the question of BPM and staff engagement.

Our experience with the no code approach to build by engaging business has seen old IT as the biggest barrier. So many times they just could not understand or not want to and likely saw as a threat to their empires? Another interesting experience was where front end mining surveyors/engineers suddenly realised that they had to "release" the knowledge in their "black books" and withdrew their support ....a project that compliance really wanted.

In summary corrupt self interest is a challenge which lies in hands of senior management to fix. However few feel comfortable in taking on "experts" in technical arenas IT being the biggest. Great pity the industry analysts seem reluctant to break away from their friends in supply chains and express themselves in business language just how it all actually works......

@David. The logical folks to want to put spanners in the works are indeed IT but we find them to be cooperative and helpful within the constraints of their policy/procedure.

The usual corporation policy/procedure is that you cannot install an executable or a standalone utility or make changes to Tables\fields other than on the corporation's Test Server. The agency moves an image of the production environment (data only) to the Test Server, their IT runs test transactions, and then comes formal committee approval to upgrade the executables/utilities at the Production Server.

The problem is with the "data" - following copyover of data and testing, we clearly cannot move the data snapshot from test -back to production because it changes minute-by-minute.

In low code apps, some changes can be done within the apps as opposed to having to effect structural changes.

Take forms design- you can have an an app where forms design/changes to forms requires no express changes to structure; you can have forms where the app makes background changes to structure; or, you can have a form that the app views and processes as "data"

All of this tends to be perplexing to IT as they may want to view forms as requiring structural change where, in fact, they do not.

If "forms" are "data" then changes made at Test Servers need to be made twice (given that data cannot be moved from test servers to production).

Our preference clearly would be to make form changes on production, then move the production image to test but, IT does not always "get it" that you can add a form but hide it from production users.

Support at military installations is ten times more difficult - here you have to physically arrive at the site, leave your laptop / cell phones at the front door, then try to work on an app. No GoToMeetings allowed at these sites and no staff can even go on site if they do not have top secret clearance.

Since testers frequently need to tweak forms during testing, they then end up having to repeat the tweaks at the production server.

IT understands perfectly changes that normally require and result in structural changes but they have issues with apps that auto-generate structural change from within the app or, in respect of activity that they traditionally expect to require structural change, they have problems authorizing that activity.

Rollout of new process templates, curiously, is not regarded as "structural change" even though it can dramatically impact procesing results.

Which is more disruptive, a bug that a new executble introduces or a processing error that a new process template introduces? Unless your bug causes looping Access Violations, hang ups or unwanted exits from the app, to me, the results are no different (data in -> bad data out).

@Karl, how correct are your observations! There is no chance to sell a new platform as a total replacement. Every organization has own ecosystem, good or bad but functional. IT are quite wise in their caution. Productive way is a way of incremental changes. This is why governance sells much easier than a monolith.

By virtue of definition, BPM initiatives always touch organizational core of the enterprise. People, technology, IT: all are involved. It requires outstanding wisdom, tact and awareness to reconcile all contradicting forces and factors, which meet in BPM implementation. Lack of attention (or excessive focus) on any single factor or component inevitably undermines the whole initiative.

Alas, management is typically looking for a single magic recipe, while an idea of perfect balance is not so vivid and evident. It is an art to avoid domination of any single group of interests in favor of their weighted mutual reinforcement. Harmonizing an enterprise is among most fundamental challenges for BPM practice.

@Karl yes very valid observations but where the creation of new adaptive solutions handles front and back office which can orchestrate legacy as required then the game can and will change. IT's job is to supply secure infrastructure and assist with legacy connectivity. The next decade is going to be very interesting truly putting business in control of their processes....!

Obvious answer to engagement is involvement...but what does this mean in practice in the context of BPM. By human nature we are more conservative than revolutionary. We want keep our own way to work and hope that all other change their practices to support our habit. There is no difference between manager or employee. To adopt BPM we need change management... this means personal learning process for everybody. The change management is about how to organize this learning process. Some key aspects of change management are such as sense of urgency, early wins, role planning followed by designing activities personal, team and organizational levels.

One kind of handicap in BPM is that it is very rational approach to the business and change. People are mostly emotional.... how deal with fear, ambition, sense of loosing control, risk avoidance or ignorance...

The short answer to the question of engagement is dialogue and experimenting.

" Keep our own way" works if you provide users with an environment that lets them work the way they like.

All the organization needs to do is adopt a "no verbal orders" policy (reasonable and straightforward from an implementation protocol).

It can be no-tech (here is a piece of paper the user fills in and signs, the form is imaged and put into a BPM runtime environment) or high-tech where the user has handy a device that auto-synchs with what they happen to be doing (e.g. bar code reader wand).

A corporation won't have a problem with a user waving a bar code reader wand at a part/assembly where the alternative is to take a photo of the sticker, upload the image to a file, then e-mail the file as an attachment.

Things really are no different in office/services (the usual BPM scenario, right?) - staff don't want to have to do a walkabout to find out what next they should do, nor do they want to have to take output they create and hand carry this to some staff member who needs their output as input.

So, if the organization gives staff a proper UI, they will use it PROVIDING it is easier to use the system than to not use the system.

Your point re "no difference between manager or employee" is key - it turns out we all work the same way.

We go into the office, check to see what our fixed time appointments are and we then look at our to-do list and decide which tasks we can take on between two meetings and whether (subjective), today, we prefer to perform a couple of high priority small tasks or advance the status of a large task.

Total flexibility, within the context of set priorities (that the user sets or some manager has set).

The UI needed is ONE split screen with a calendar on one side and the user's to-do list on the other. That is it.

A very good question! There indeed seems to be a delta when it comes to technical advances, tendencies and, ultimately, real-life benefits from process optimization and automation. For the extended f...