BPM.com

Over the last 12 years, I've seen – and helped drive – a lot of change in the BPM market.  First, I watched BPM move from a heavy focus on integration to a greater focus on collaboration and social interaction.  And then, BPM expanded from highly structured and ‘automate-able’ processes to address unstructured, more dynamic business processes.  It is safe to say that over the last decade, demand for BPM was driven by key characteristics of the "Information Age" - a relentless drive towards improving the flow and sharing of information across people and systems.

Now, the most compelling business cases powering fresh demand for BPM focus on characteristics of the new age we are moving into - what Forrester calls the "Age Of The Customer."  If you look closely at most of today’s BPM initiatives, they tend to hide behind an imaginary firewall that separates what external customers experience and what internal business operations feel they need to be efficient. In this new age, business leaders are waking up to the realization that they can no longer divorce process improvement from the people and systems that touch customers, partners, and customer-facing employees. 

Over the years, organizations have created "business processes" mainly to rein in the chaos that has proliferated inside their operations. They have installed BPM tools to automate their processes and make sure tasks can be repeated successfully over and over again.

This practice does a good job of restoring order, but it also has a downside. Installing a rigid process can create a system where an organization gets too locked into certain procedures and ends up repeating the same mistakes. What organizations need is a less static, more iterative approach that sets rules to bring order from chaos, but allows them to make changes easily when parts of the process become outdated, irrelevant, unnecessary.

As BPM suites mature, they have become more accessible to a broader range of users. Whereas in the past, the design of business processes was reserved to .NET and Java developers only, now user friendly wizards and drag-and-drop canvases have made it possible for non-developers to jump in and design BPM processes as well. Today, there is a dichotomy (certainly among our customers), with approximately 60% of processes still being built by more advanced developers, but a healthy 40% being assembled (for the most part) by what has become known as "Power Users". A Power User, for lack of a better definition, is a user who is technically oriented, but does not have coding skills or experience. My question is - should Power Users be designing processes? Is this optimal or efficient for a business?

Naturally, much depends on each individual user, and it's difficult to generalize. Some Power Users just get it, and some don't and should be left for the modelling sessions only. But if we take the average Power User, I think we can come to some conclusions. First off, in most cases, a Power User does need some setup and help from a Developer to get started. Form and Activity templates may need to be created, not to mention integration with external systems such as ERP and CRM. But once the environment has been set up sufficiently, our experience is that Power Users can and do succeed in building processes. Additionally, Power Users often have a broader view of the business (they are often also Business Analysts) and that actually gives them an advantage when designing processes for the business.

The major difference is in the complexity of the customization. If the requirements of the project include complex form functionality and/or a significant amount of integration, Developers are almost always needed. If the processes and their forms are relatively straightforward, Power Users can usually overcome most challenges alone - with some help from time to time where coding is necessary.

Another major factor is cost. It's a fact that a team of Developers is more costly than a handful of Power Users. BPM suites today (at least the more advanced ones) are much easier to learn than .NET projects. Power Users can usually be trained in a space of weeks, as opposed to the years it takes to master programming in Visual Studio. So a business that has Power Users at the heart of its process development will save costs, though it might have to compromise on some complex functionality.

Perhaps the most important result of this discussion is the trend. BPM Suites, just like most enterprise software, are moving toward the Power User. We can expect that that within 3 - 5 years, this trend will continue, to the extent that there will be fewer limitations for Power Users working on BPM projects, and less reason to touch the code. Does this mean the end of an era for Developers? Hardly. I believe that just as BPM products become simpler to use, so too business requirements will become more and more complex, and there will always be a healthy chunk of work for Developers going into the future. As such, the right strategy for a BPM roadmap is to plan for teams which incorporate both Power Users and Developers among their ranks.

Eli Stutz

Head of Knowledge and Collaboration, PNMsoft

www.pnmsoft.com

A process exists for a purpose: meet or exceed customer expectations of the customer experience.

Fine and dandy, but what does this mean and how do we operationalize the definition? What strategic and tactical levers do we have to craft, operate and evolve a predictable customer experience?

This line of thinking is taking us towards a model for process quality of outcomes.

The field of business process management (BPM) is broad and has been approached in a number of ways:

Business process improvement focuses on improving the effectiveness and efficiency of individual processes for results that benefit the customer and the organization from a business perspective.

Process automation is an IT-centric approach that seeks to improve internal efficiency, control, and business agility by applying technology to speed the workflow, integrate heterogeneous systems and databases, and enforce business rules.

BPM as a management discipline seeks to manage and measure enterprise business performance from an “end-to-end” (customer-facing) process perspective and create a process culture for the organization as a whole.

Author: Prof Mark von Rosing, Prof. Paul Buhler and Henrik von Scheel

Since 2008, the Global University Alliance, consistent of +300 universities, academics and researcher have compared, analyzed and developed Best and LEADing Practices around process modelling and process architecture concepts. This includes process mapping, process relations, process rules, process measurements, process monitoring, process scorecards, process notations, linking business model and process model, process governance as well as aspects like link to strategy and goals. In this context the Global University Alliance conducted an extensive and wide-ranging research comparing existing process modelling, process engineering and process architecture concepts, method, approaches and standards. The Global University Alliance research analysis revealed the need for a fundamental shift in approach and thereby the need to totally rethink process modelling and process architecture. The foundation for this reconceptualization was to understand the objects that link and relate to the process aspects. Using ontology and semantic concepts and principles, this article describes short the results and the work that lead to the development of a new breed of process modelling capabilities that are collectively known as the eXtended Business Process Model and Notation (X-BPMN).