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

Do you need BPMS to drive real process change?

Vote 0 Votes
Clay Richardson brought up this interesting question on his Twitter feed: Do you need BPMS to drive real process change?

17 Replies

| Add a Reply
  • In my postgraduate years long ago we used to say: "all that can be done without computers has already been done".

    The same is true for the process improvements: most of what can be done without BPMS is already done.

  • Do we need BPMS to drive real process change? Do we need traffic lights to control traffic flow? Of course in an ideal world we'd need neither. Drivers would be courteous, patient and accommodating. People in processes would be results oriented, constantly optimizing and always measuring.

    Alas drivers will never reach the levels of safety awareness and altruism needed for a traffic light free world.

    We might get there with process users: one day. In the meantime BPMS has so much more to offer us than just managing the process. It can alert us to bottlenecks so we can optimize the process and our organizational structure that supports it. It can record metrics so we can see the effect of our changes in policy real-time in the data. It can notify us when levels of service fall below desirable limits so we can switch resources and maintain business continuity. All factors that change and improve the process.

    To drive real process change we need passionate and energetic people with a clear vision of where we can get to ... but we need BPMS to get us there.

  • I submit a qualified "no." In the strictest definition of BPMS, certainly no. I have seen plenty of real process change with non-BPMS software, such as CRM packages or SAP.

    Even without a software system, I have seen significant process change. Small workgroups, sales teams, etc. But it certainly is harder, and as a practical consideration it is difficult to scale.

    I like Kevin's traffic light example; let me add to it. If one of your requirements is to strictly enforce the new process, you can't easily scale to roads full of cars without an automated system. You could theoretically have a traffic cop at each intersection (analogous to scaling without a BPMS). But of course that is impractical.

  • I propose that there is an unavoidable interaction between business styles and used technology that can help a business to grow without a priori changing how a company is managed. Using process monitoring and enforcement sends a clear and loud neagtive message about management style to employees that no HR motivation program can undo. Technology can however be used as a change disabler or provide the opportunity for change.

    It is thus a substantial misjudgment to see technology as secondary for BPM, because even if you don’t use it your competition will, causing a shortening of time scales in the economy, which challenges today’s slow strategic planning cycles if you like it or not. It voids the proposition of BPM methodology that process analysis will ensure optimization and innovation in realistic timescales and provide agility through a governance bureaucracy. Rather than relying on analysis, we need to rely on technology empowerment for social business process execution, which is not addressed by today’s Social BPM approaches. Real-world social processes emerge and adapt continuously and holistically from all aspects of hierarchy: top-down, bottom-up, inside–out and outside-in.

  • Kevin almost had it right, "To drive real process change we need passionate and energetic people with a clear vision of where we can get to ..." but we don't need BPMS to get us there, we need to educate those people to have that vision and passion that will drive the change to get us there.

    Clay's question points at 'real' process change. You have to remember that people reengineering processes were here well before BPMS showed up as an enabler (note the word). It may help us identify bottlenecks, help us manage processes and operating models, notify us when SLAs are failing, but where does the data come from ? The people who design the process in the first instance. Yes you can plug in all manner of 3rd party systems but someone still has to design the process in the first place, talk with the business, create the as-is scenario with which to improve. BPMS is just another tool in a process expert's rucksack they can call upon to help them.

    You cannot substitute an astute, intuitive and perceptive process user or BPM expert with 2m lines of code, no matter how predictive or adaptive it claims to be.

    So, I'll throw down the gauntlet, just like the man vs. horse race, let's have a man vs. BPMS and settle the question......who's in ?


  • Most certainly: you do NOT need a BPMS to effect real process change. Remember, a BPMS is all about automating processes, and offers some advantages, there are many other ways to automate, but more importantly there are many processes that are not automated, and can not be automated.

    I often speak on the subject of "Process Mining" which is a technique for uncovering you actual processes from evidence in your current running IT system. One well documented use case we mined their order-quote-delivery process, and found enough quantitative evidence of inefficiency that the company followed through with 17 process improvement efforts. These projects did not involve automation through a BPMS, but ended up causing real process change that saved the company millions of dollars.

    To effect real change in process, you only need visibility to how well your processes are running now, and have ideas on how to improve them.

    Keven's stoplight analogy does not fit in my opinion. In parts of Germany they turn the traffic lights off at night, because it has been shown that when the amount of traffic is low, a simple stop sign is more effective than a traffic light. You certainly can not say that a stoplight ALWAYS improves the situation, and the same is true with BPMS.

  • Yes, you need a BPMS to drive real process change (and I'm not talking about analysis or automation).

    - To make any change meaningful, process content must be treated like any other enterprise data, and must be centralized
    - For change to be managed, ownership must be assigned and a change workflow created
    - For end users to adopt the change, you must enable a role-based search capability that demystifies process and makes it relevant

    While you may not NEED a BPMS to drive real process change, the level of effort and cost required to centralize, give ownership and deploy content to end users without having a BPMS makes not having one a costly mistake.

  • No, you certainly don't need BPMS.

    Ultimately, it's the people that make the change happen and many cases "systems" have become more of a roadblock than an "enabler". If the people have not bought into the change, don't feel ownership for it and haven't been empowered to make things happen, then systems only make things worse. The use of systems to do process improvement can create the perception that they systems will actually make the change happen. Consequently, management may not realize until it's too late that the change isn't actually happening. The systems are running, the reports are being generated, but the processes may have actual gotten worse because the people (who haven't bought into the change) are working around the system as a human form of rebellion. Again, systems cannot make process change happen, only people can make it happen.
    There are a lot of changes that cannot be made with systems. The more knowledge based a process, the less it lends itself to automation.

    It is important to look at technology and systems as a part of process change. There are a lot of good things that technology can do to make improved processes even better but it is not the solution.

  • (Why am I always the one with the negative comment?!)

    In the light of how long it takes to define process objectives, design the technical specs, implement, test and run BPMS I'd venture that BPMS actually prohibit process change...at least the small changes that would so often provide real benefits.

    As it is, as long as BPMS itself is regarded as a process change, content (the process itself) will only play second fiddle...if it's invited into the orchestra pit at all.


    • Thomas, for too long of a time BPMSs have been focusing on the IT people. With the introduction of BPM offerings that are cloud based, not only are you now seeing the time to value significantly drop, but you're also seeing a lot more of the people that traditional BPMSs have left out come on board and drive process change without IT intervention.

  • I think we need to define "real" in "real process change".
    My "reality" consists of process change that is lasting, profound and that gets to the core of what an organization is all about. If you agree with this definition of "real" than indeed a BPMS is essential as it provides a safety net in which organizations can experiment and "play" with process change on a continuous basis.
    Process change is not easy and a BPMS will not make it any easier, especially in the beginning. What it will give you is a lot of comfort and reassurance that you're following the right methodology for the right reasons.

  • We have the classic challenge of agreeing on what a BPMS is and what it does. Mihnea's comment is spot on...to make it last, process change needs to be captured, owned and distributed intelligently (and I'm not talking about automation). Doing that without a BPMS is an effort level that doesn't make sense given today's business-facing and not IT-facing technologies.

    For those who say, "absolutely not," if we consider only the BPMS systems that are not business-managed, I would agree. If we consider all that's available, I wouldn't. Take a look at the ThyssenKrupp Steel business case from August BP Trends:


  • Let me tell you about an actual company I worked with. We went through a process mining exercise. They saw how inefficient their processes were, but many things could be fixed easily. There were 17 process improvements the resulted directly from measurements produced by the mining, and none of those 17 process improvement efforts requires a BPMS.

    One specific example: they found out that 6 people were involved in "approving" an order, and that this was delaying every order by two weeks or more. They also found that the last four approvers were never disagreeing with the first two. The change to the process was to eliminate the last four approvers, and to instead send them a "courtesy email" informing them of the order. If they had an objection, they could of course jump in an rescue thing, but they essentially never did.

    By changing the number of approvers from 6 to 2, they saved almost 2 weeks of unnecessary delay in each order. This was done WITHOUT a BPMS. It was a real, and substantial change to the process, with significant business results.

    Clearly a BPMS provides value and can be a good tool for implementing process change, but it is absolutely NOT REQUIRED for a company to implement real substantial process improvement.


  • All depends (as usual) on your BPM reference model (or absence of it), your BPM architecture (or absence of it), the client, their processes (or absence of them) and their EA (or absence of it).

    My observation is the following: in general, BPMS is NECESSARY, but not SUFFICIENT to bring a disruptive improvement in managing by processes.


  • Wow Peter you struck a nerve with this one...Thomas I'm the odd woman out this time...

    BPMS is a tool,(tool being the operative word) that encompasses the tracking, mining and monitoring of processes, providing value in identifying process problems. To that extent BPMS is crucial for indepth visiability for managing and driving real process change. It facilitates drafting of policy, i.e. governance, inside out-outside in collaboration and change management strategies for correction and management. To answer the question, yes BPMS is needed, however, it is not the end all be all for driving real process change. Keeping in mind change has many facets.

  • We talk about changing a process here. Change is difficult most of the time, so the first question that comes up to me is: why should I change a process at all?

    The only reason I can think of is that there is something wrong with the process. That can mean a lot of things. Customers don't like the result that's produced by the process.Competitors ar doing better.
    Government doesn't agree with the process. The process is not generating profit etc.

    So not changing the process will make our company perform worse (that's why I am bigger fan of Improving by process than improving a process)

    In these cases there is a reason to change. And I think, the common understanding we have to change (actually better: improve) the process is the best drive for change. So people and their passion are a greater driver for change than any bpms.

    Oh yes, and tools like BPMS might support you, but if you don't want to change, it will not help you. If you want to change, they can make change happen faster. It's like with any tool; if I want to get the job done, I will search for tools that really help me.

    That's why I bought an expensive chainsaw last week; I must cut my costs.

Add a Reply

Recently Commented On

Monthly Archives