Is Process Design for Power Users?
- Published: November 29, -0001
- Written by Nathaniel Palmer
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.
Head of Knowledge and Collaboration, PNMsoft