We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

What is the secret to BPM end-user adoption?

Vote 0 Votes
End-user adoption is clearly the key to any BPM deployment.  So what do you think is the secret to BPM end-user adoption?

13 Replies

| Add a Reply
  • Transparency, value, ease.

    Any BPM solution should be immediately available and accessible for an end user, it should be transparent to the user what the solution is intended to do for them and the enterprise, so in other words the value is crystal clear and not just a set of buzz words to excite the CTO into a frenzy.

    If solution providers built their software products with the same UI and ease of use as an Apple product we wouldn't be having this debate. My 5 year old has been using the Macbook for almost 18 months now, an iPod Touch for over a year.

    Many people in an organisation are still reluctant (or afraid) to embrace technology and software because of the false perception that their job is on the line, quite the reverse, or that it's actually a chore to use and adds complexity (not another system to learn *sighs*)

    Make BPM fun, I get a kick from it so why shouldn't the end user.

  • Theo-- you took the words out of my mouth with "ease of use", excellent post!

    I would add: Low learning curve or Required training/hand holding so they learn how to use the technology and process output to their advantage (similar to our iPod example-- it's simple and easy to learn and become a master at repeatable tasks).

    What's great about a well architected BPM is the visualization aspects. The "blinking light" affect tends to resonate very well with the business community and human adoption in general.

    Lastly, I will add the KISS rule (Keep it Simple..) with your first few processes. Don't try to solve world hunger with your first few processes. Demonstrate, ingratiate, and then govern. This will help adoption before tackling the more complex process requirements in the enterprise.

  • As is often the case, I find myself agreeing with Theo. Great minds I suppose.

    I recently visited a customer who took ease of use to a much higher level. A new, slick, easy to use UI wasn't an option here, the project called for the customer to process- and case-enable an existing customer service portal / application. What he did differently was after getting the baseline requirements and a semi-finished set of functionality in place in a Test environment, he brought in 2-4 end users at a time to work through the processes.

    What was unique to this approach and using a process tool rather than straight code was that the users provided feedback, the customer made changes to the process and case models, and then asked them for their feedback again, all within the span of minutes. This much more rapid approach to gathering end-user feedback (as opposed to typical UAT cycles) was that in some cases, the changes the end-users requested actually got rolled back when they actually tried them. In a more typical custom development style roll-out with fewer feedback cycles, these changes might not have been found to be tedious until AFTER the roll-out was complete, limiting user adoption even after they had been involved.

    Not entirely unique to a BPMS or ACM solution, however definitely a good approach given the limitations of the application environment the customer was trying to process improve.

  • How does an organization ensure adoption with its user community? Answer the questions that they are all asking: "What does this mean for me and my work? How do I benefit?" Communicate the answers frequently through a variety of channels.

    Make certain that:
    * Senior management leads the change
    * Everyone's questions and concerns are addressed
    * Training is timely and appropriate

  • This is a great question. Sadly it seems to be a question that is rarely asked at the beginning of a BPM project. "Who is the audience and how do we engage them?"

    Too often BPM = technology = IT. The IT guys are so excited about getting the technology out of the box and playing with it, an end user or business focus is rapidly lost. And with it any chance of success.

    So, great question, which we need to get project sponsors, hired consultants/SI and the IT department asking BEFORE they start.

  • Ease of use is good, but to accomplish what? Frequently, BPM is introduced for its benefits to managers (visibility, consistency, etc) rather than to line workers. For the line worker, they have a job that they need to get done. If the BPMS is easy to use and provides great visibility to their manager, but it doesn't improve their ability to get their job done, then they will resist adoption. For them, the key is being shown that they can get their job done faster and better with the BPMS than they could without it, because the BPMS can be used to automate much of the time-consuming busywork of their job.

  • Our BPM projects consider the end-user as early as possible in the project timeline. We plan Awareness Campaigns (emails , workshops, posters etc.) to address any fears of change such as using new technology, redundancies, or perceived loss of independence by the workforce. We all agree that the solution needs to be easily understood, contain relevant information and have high levels of transparency, however, the support of senior management is crucial to the on-going success.
    Management commitment to the project objectives will driving home the benefits of BPM , ...how boring but true.
    Early adoption by the workforce will increase ownership of the processes and therefore embed the work routines within daily operations and become the `norm`.
    The adoption of BPM is not about technology which is why the focus should be people-centric, not a piece of code.

  • Here's a great article for those wanting to understand how a simple UI and UX wins hands down for adoption on the iPhone and iPad. Learn it and adapt it for BPM. Please. Someone.....


  • Without specifying what BPM brings to different types of users, in my experience the key factor was the real agility demonstrated. BPM-enabled projects are lighter to start, faster to implement and easier to evolve in comparison with existing IT practices. Of course, a proper architecture enables this.

  • While agreeing with everything said above, I'd like to add 2c from my article http://mainthing.ru/item/412/

    In order to gain users' trust and adoption one should aim not at controlling them by applying rigid process schemes (people don't like to be controlled) but on helping people control complex processes they are responsible for.

  • The key to effective end-user adoption of BPM is insuring that user themselves "own it." This means soliciting and heeding input from the stakeholders in the processes and in the business at the outset, before tools or applications are selected, before UI is discussed or designed and before the memo from management goes out; when the concept of process change, improvement or intervention is first broached.
    Enabling users to own the BPM solution requires facilitation throughout the deployment, from selection through training. In addition, the focus of the BPM initiative should always be on improving measurable business outcomes with the company's mission and objectives in mind, i.e. increasing profitability, reducing manufacturing costs, reducing risk exposure, etc. What matters is the mission, not the application or tools chosen. As Michael noted, BPM initiatives frequently lose focus on true purpose: enabling the stakeholders, the "do-ers" to more effectively use their bandwidth to meet or exceed clear business objectives against which their performance is evaluated. In addition, insuring that line, management and other representative business stakeholders are chosen as trainers, specifically for cross-training, BPM adoption is greatly enhanced.
    If the BPM initiative involves the business users from outset, is focused on removing obstacles or reducing low-value operations from functions and leverages the knowledge of the business users for training, adoption is implicit.

  • As I noted in a previous discussion thread understanding and acknowledging the value of BPM is the secret to adoption. You can only appreciate the value when you understand it. End users need educating on the BPM methodology, how it consist of processes, analysis, constant improvement, measurement, collaboration, control and automation; how effective management of business processes impact the customer experience and is strategic for sustainability. Process training facilitates adoption through the user developing an understanding and awareness of processes and the relationship to rules; that processes are continuous, crossing business units and based on the organization structure may cross organizational boundaries.

    As stated above ease of use is important, however a tool that is easy to use without understanding the reason why it is being used or the benefit of using it renders it useless.

    I'm noticing a trend with the BPM threads, responses are system/application oriented. Lets not forget BPM is a methodology first, the foundation for defining the s/w and resolving challenges. S/W will only do what it has been designed to do...computer science 101.

    Happy 4th and be safe.

Add a Reply

Recently Commented On

Monthly Archives