BPM vs. BPMS: How To Think Big and Act Small

Before I get into the actual HOW-TO part, let me reiterate another perspective as to why current BPM approaches and/or BPMS are so lacking. Rather than being upset about my critical observations, the BPM community should use the opportunity for discussion (TED: Dare to Disagree) and try to validate and prove BPM theory. Therefore I do not understand the lack of response after I provided a simple formula two years ago as to why flow-charted processes won’t deliver BPM benefits in a larger business. Not a single expert or vendor has brought forward a single counter-statement. Does that not make you wonder?

There is on the other hand a huge library of books, white papers, blogs and seminar programs of how to implement BPM in large corporations. They all boil down to a few key messages that are repeated over and over again with no more than anecdotal proof that any of this works. I am referring primarily to BPM methodology, but also to its eventual implementation via a BPMS of some kind. BPM should always be an enterprise effort, while BPMS are mostly localized projects. One can say that BPMS are managed by BPM governance.

Even with the best-of-breed BPMS, most large businesses struggle to identify current processes and model them towards some desired end-state. Users perceive BPMS to be restrictive and the offered participation in the governance as a smoke screen to hide that the ROI is mostly achieved through manpower reductions. Ultimately, vendors propose that the savings of small, local BPMS projects can simply be applied to the larger business.

To implement BPM successfully supposedly requires …

  • … an executive sponsor who will enforce the use of BPM.
  • … governance to avoid scope creep and increase business agility.
  • … first a culture change within the organization.
  • … to prove its return on investment in a short time.
  • … that BPM methodology is more important than BPM software.
  • … the ability for business endusers and stakeholders to create processes.
  • … BPM software that matches corporate needs and maturity level.
  • … stages of analyze as-is, model to-be, implement, monitor and improve.
  • … tools for: business strategy, process analysis and design or mining,
  • … flow-execution, rules, analytics, monitoring, content, and security.
  • … the integration with systems of record, Social, Mobile and Cloud.

Most people involved in BPM will not dispute those above requirements. They seem to be a common consensus. If all of them would be easily achievable I would have not much of an issue with them in principle. But that is not my main point. I propose that in the real world they are actually contradictory, because BPM and BPMS mean very different things. But then there is no way to sensibly do BPM without a BPMS …

The NINE Contradictions in BPM Implementation Principles.

  • If BPM would be capable of being business-driven then there is no need for executive enforcement.
  • If the implementation of processes would really happen through users there is no need for governance.
  • As business users can maybe draw a flow-diagram but can’t make it executable, the BPM stages are all performed by experts, actually reducing agility.
  • Both BPM methodology and BPMS ignore that users understand processes in terms of content and context and not in flow-diagrams.
  • To change business culture is a long term prospect and collides with short ROI time frames.
  • What kind of culture change should be necessary to motivate people to follow flow-diagrams all day.
  • To reduce scope creep and ensure ROI, governance limits end-user requirements and achievable quality.
  • A holistic BPM methodology is fragmented over different software products (BPMS, rules, events, content, integration) for implementation.
  • As the fragmentation requires governance, any change requires long-term planning and therefore reduces actual business agility.
  • If a BPMS is chosen to match current needs and maturity level then it has to be replaced frequently as the business matures.

I could go into a long explanation of why I see each of those contradictions, but for once I will try to keep my posts shorter and less philosophical. If you know how business and IT really works then you know that these contradictions are correct. But how come that no one has yet pointed those contradictions out? You will find ‘experts’ that speak about the ‘Triple Crown’ of BPM implementations, when they increase revenue, increase quality AND reduce costs, all at the same time!

Supposedly BPM – simply by following the methodology – is able to balance organizational assets and resources to provide differentiating services to the customer, ensuring maximum value at the lowest cost throughout the value chain. I want to evaluate that claim. Differentiation and individualization can increase perceived value, but cost money and need manpower to increase revenue and improve the bottom line. BPM is an investment in the future and ROI can only be long-term. But during implementation, BPM standardization freezes processes into average happy paths that then are very difficult to change because of the software fragmentation I pointed out above. There is actually no differentiation and individualization possible and it becomes much harder to do as it has to go through the governance cycle.

How To Think Big and Act Small in BPM

BPM methodology and BPMS implementation must go hand-in-hand or at least have the opportunity to do so. Adequate technology must support the BPM enterprise effort, even if it might only be used locally at first. BPM must think big, but BPMS must allow small scale perspectives on the business user level. Considering them separately is a huge mistake. While the adage of ‘Small is Beautiful’ has lost its luster it is still as valid. Even in Taichi Ohno’s Toyota Production System (the grandfather of LEAN) it was the worker cell on the factory floor that was responsible for quality and outcome and not the business strategy or a monitoring software. Methodology does not change your business; only people do.

Once the BPMS has been setup there must be no further process implementation stages. They alone kill the promised agility. Install it and let the business have a go. If they struggle, don’t enforce a useless standard but figure out with them what UI functions they will need to describe their processes intuitively by picking resources from library menus. Different business units will have different ideas about that. Forget process or UI standardization if you really want to empower the business. Standardization is only needed because implementing processes in flow-diagram BPMS is so expensive and the BPM governance is so slow.

I propose that the key aspects of implementing BPM successfully are quite different once someone understands the issues of social complexity, workplace psychology and people motivation. These define what weapons to choose and not revenue, quality and cost. They are consequences and outcomes, driven by people and can’t be enforced as immediate targets. Henry Ford said: “A business absolutely devoted to service will have only one worry about profits. They will be embarrassingly large.”

But how can one bring the larger organization together to work for commonly understood objectives, targets and goals and ensure that the customer perceived value is truly delivered? BPM methodologists tell me all the time that it really isn’t about flow-diagrams.

I propose that the following is needed to make BPM work:

  • Chose (buy, build or integrate) a homogeneous ‘System of Engagement’.
  • Create Top-Down transparency through a business-architectured value stream visible in the software.
  • Define budget responsible process owners and their outcomes and/or handovers. (Authority, goals and means)
  • Define with IT the ‘Language of Business (Process)’ that non-technical users can use to create processes.
  • Link with ‘Systems of Record’ and refine UI’s until the business units really want to use the system.
  • Define with process owners the targets for ‘bottom-up transparency’ that enables management reporting.
  • Let business units define how to execute and achieve the defined process goals and outcomes.
  • Business users collaborate freely to assemble resources (data, content, rules, forms, tasks) into goals. (NO UPFRONT DESIGN)
  • Successful goal-achieving work can be stored as templates and reused and still be modified for each execution. (=ADAPTIVE)
  • Motivate business users through autonomy, job security and recognition and forget monetary rewards.
  • Enable users and customers to vote and rate each aspect of the process in real-time.
  • Continuous improvement is enabled by user empowerment and the embedded project and program management.

Now clearly, I do not have any proof that this works as a BPM theory in itself. But the above (and thus concepts of ACM) is based on a broad set of accepted scientific knowledge about systems theory, complex adaptive systems, and behavorial economics. BPM/BPMS as currently promoted by huge advertizing budgets have NO scientific basis at all!

In the ‘Age of Complexity’, BPM methodology and ‘governance’ must be embedded in technology. The resilience required in this dynamic age can’t be achieved through a command and control attitude. Executives have to provide the perspectives and principles of the ‘Big’ while the people who actually do it, utilize their experience to execute and innovate in the ‘Small’.

The experiences of Mobile and social networks prove that technology is the enabler of change that brings them together.

13 Comments on “BPM vs. BPMS: How To Think Big and Act Small

  1. “Flowcharting” processes have been around for decades long before the “BPM” tag. I was doing it 40+ years ago as an auditor to identify weaknesses to focus the audit and recommend improvements. I actually found 2 frauds by doing this; a routine “misuse” of expenses but also a big systemic one worth many £ms that one that had been overlooked for years. It was talking to people and joining up the “dots” that uncovered these issues. Then such flowcharting had no relevance to “IT” but today a good flowcharting design build can make that connection very well. The other issue is that people work in relatively small teams irrespective of size of business. Yes big businesses have big issues to handling the legacy mess so that needs clever Mastering Data Management but the fundamentals are the same in any business?

    The old model as you describe is well past its sell by date! There is a new object model driven capability where the build takes place without code generation or compiling see very good perspective here http://infullbloom.us/?p=3222 the “object model driven” future for enterprise software creating a “moat” for vendors to cross. This model and object driven approach need a good business architecture and needs to address the requirements as you indicate to move forward the “BPM” discipline to the 21st century.

    The supporting technology needs a multi dimensional approach that needs to include within the “flowchart” graphical design and build

    1. BPM focus on people and their processes
    2. Process engine to ensure all works to plan
    3. Rules engine reflecting real world of compliance
    4. Calculation engine automating system work
    5. State/ instance engine real time feed back
    6. Workflow that includes asynchronous capability everything connected in right order
    7. Events in built triggering as required
    8. Audit trail, events, escalations = supporting control = empowerment
    9. Time recording supports activity based costing
    10. Real time reporting become predictive

    Your comment on “flow charting” does not reflect today’s capabilities. Other than that you are right in that that old model needs to move on as you describe

    Like

    • David, thanks for reading and commenting. I completely subscribe to the object-model-driven future of processes that must include rules, events, auditing and real-time reporting. Flow-diagrams can be helpful as I pointed out previously but they are not sufficient. But what you describe seems not to be a process environment that enables the business users to create their processes, but something that is a lot more complex and requires experts.

      A business architecture actually must define the objectives, targets and process goals that business users must work towards in their execution. Empowerment is not about control but about performer autonomy to decide on how to achieve goals. BPM can only succeed if the business users can create and modify processes with embedded content and rules.

      Thanks again, Max

      Like

  2. Max
    I am a supporter of “systems thinking” and totally support empowerment with measurement which by default brings “self” control. As I think we agree “IT” has failed in past to deliver this and needs to be addressed. I see also now big vendors pushing standardisation of processes which runs counter to empowerment – but it is what they sell!
    Build is very simple driven by business driven developers not technical ones. Where change is anticipated this can be built in but few users want to go too deep for building processes – it is not their day job! What is important is removal of fear of change as they become confident they can discuss ideas knowing they can be delivered quickly by someone speaking the same language!
    Keep up the good work
    David

    Like

    • Thanks David, but you are still referring to orthodox process design and delivery. That is the part that we must move away from and it is the key distinction of ACM compared to BPM. IN ACM the business performers create the processes by doing them. No design work. It is not just about users being able to modify current execution.

      The fear if change comes from someone else making a change that may or may not be good for me. If I as a business performer am the one to make the change, I have neither fear nor do I need someone else who speaks the same language. The software UI needs to speak MY LANGUAGE OF BUSINESS. If all users can collaborate on their processes then they only need to go as deep as is their responsibility.

      It is the process owners responsibility to collaborate with the performers to ensure that the work done fulfills the goals. In difference to current BPMS the goals are defined explicitly and everyone knows them.

      All the best, Max

      Like

  3. Hi Max
    Process design has been embedded in work forever good and bad. “Orthodox” applies to how supported in the past and IT as as evolved has failed? Any digitised support should have no barriers to ideas being considered and then adopted quickly – that is not orthodox! I agree BPMS as sold even with some configuration does not support this and is another imposed solution. I think we are agreed the future of custom coding and inflexible packaged apps to support people at work needs to be confined to IT history? Great debate on ebizQ on this…
    Cheers
    David

    Like

  4. Hi David, thanks again. The ability to create processes and all their resources must be in the power of the business. IT or some process experts must have nothing to do with it. They provide the infrastructure … no more. If someone else than the business performer is needed to create the processes that the business needs … this is orthodox process analysis and design.

    Regards, Max

    Like

    • Hi Max
      Someone needs to have knowledge of the process outside the users – it is the
      real world of compliance and business intelligence? I agree you should not need formal process analysis a waste of time for users. The process “owner” just gets the “performers” round the table and agree between them the best way to do the job bearing in mind the goals required which may include reporting results and metrics to internal and external interests. We have found an external mentor with knowledge of the possible can often stimulate such discussion. Effective empowerment cannot exist without measurement! With good supporting technology then build in front of them and should be in action in days!
      Despite clearly coming from completely different backgrounds I do not think we are far apart. It is just a pity that the divide between business and IT is as big as ever. The real question is why? Is it that such debates rarely take place or is it the self interest of the big vendors to keep the mystic and complexity of IT in their control – probably a mixture of both!
      Regards
      David

      Like

      • Hi David, I agree that we want the same thing but we look at it from different angles. I even take it a step further to say (also in this post);

        “Define with process owners the targets for ‘bottom-up transparency’ that enables management reporting.”

        This is however a business management issue and has nothing to do with IT. The definitions of objectives (outcomes), goals (i.e. handovers), rules (for compliance) are a precursor to let the performers execute the process. I recommend that all the above are made explicit in the system and thus ‘top-down transparent’.

        The process owner just gives the performers the explicitly defined goals as process structure and asks them to execute. There is no need to agree on anything else. Once the process has been done ‘as-is’, then there is no longer a discussion needed. Everyone sees the ‘as-is’. It is then easy to verify if it fulfills both goals and targets. If not then you simply change the process as you perform next time and then save it as a recommended template.

        Why would anyone want IT to build it in front of them. It is a waste of time and resources and the process is still rigid. If the user wants a change he needs to go to IT and they will say that they have no time or it is too complex and other rubbish. it is no longer a process it is now an application maintained by IT. That is what we need to get away from.

        Compliance is easy, because each process instance can be audited and where necessary the PO can add compliance rules to the templates.

        Like

      • Misunderstanding “IT” do not build this the users can do it. Skills set is quickly acquired.Instead of usual papers on wall or “spec” collate ideas and put direct into build envireonment that users understand. They can maintain as required. However as I have said most users do not want to do this it is not their day job! But cerainly the wide spread use will see that attitude change. We are on the same page! We just have a different architecture as I have described. Let’s respect each approach it achieves the same “goal”? Business logic belongs to the business IT is about secure delivery ….and helping handle legacy connections!

        Like

  5. Pingback: BPM Quotes of the week « Adam Deane

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: