Low Code BPM has promised to deliver business apps faster and make the process of Digital Transformation faster, easier and smoother. The problem Low Code BPM platforms have is that they are still largely targeted at the professional developer, and making their life faster, easier and smoother. But, what about the business user themselves, such as a Business Analyst who can see the need for change and knows what that change ought to be, but cannot execute and change the process itself because the tools are in the hands of the High Priests of Technology?
The current state of the Low Code BPM market is that there are platforms aimed at professional developers, such as Appian and Bizagi, and then there are solutions that can be used by the non-technical, non-coding business person, such as HighGear.
Gartner uses the term, “Citizen Developer” to describe the people we are increasingly coming to accept are the ones who actually need the power to create transformation: those closest to the work being carried out.
Does this resonate with you:
A business analyst embedded with a business unit identifies several ways to improve delivery of customer value through several process changes.
You review the findings, and come up with a statement of requirements which you then pass on to the IT department to implement.
The IT team then goes to work on delivering your requirements, but this can take months or longer. Meanwhile, while you are waiting, the improvements identified by your BA actually represent inefficiencies and loss in customer value while you continue with the “As Is” state.
You chase up on delivery with IT – they tell you they need more time and/or money to deliver, given how busy they are.
More months pass by. Perhaps, more money changes departmental hands.
Until finally, your requirements are developed.
Except those requirements are not exactly what you asked for, but are instead what might be easier to deliver.
Worse still, the customer environment has changed since your team first brought proposed improvements to light. What has been delivered is not quite the best solution for delivering customer value – you would like to make some tweaks, but you don’t have the ability to fix the solution that has been delivered.
The frustration felt by the business is that there is a significant delay between identifying change and creating the changes to the processes that require it, and in what IT delivers in fact rather than what the improvements actually call for.
Low Code BPM was developed to bridge that gap, but the promise has not lived up to the delivery.
There are still significant delays in implementing improvement, even though they may be less than those using a traditional BPM solution. There is still a culture of the High Priests of Technology who use the BPMS as an IT tool to make the changes the business asks for and who control the levers of work power and transformation. This moves us to an IT-led BPM initiative and imposes an extra set of layers between where work gets done and who is responsible for executing on changes to workflows and processes.
No matter whether we are using a traditional BPMS or a Low Code solution, if these are tools viewed as under the domain of the technical specialist, then we will always experience delay in executing change, and the frustration of actually getting a solution that does not fit what was requested.
No Code or Zero Code BPM seeks to resolve this issue: by allowing business users to wield BPM functionality to make change where they work. They have a problem in that while they deliver a tool that can be used by non-specialists, they are lightweight and difficult to scale. They are frequently little more than a set of process templates for workflows that are inflexible and do require coding skills to change in fact.
No Code either constrains business transformation because of the template inflexibility, or need such a heavy dev input that they are not No Code at all.
This still leaves the glaring issue of how do you get a BPM tool into the hands of those who need it?
Lean BPM seeks to deliver a practical alternative to traditional BPM solutions for changing and improving processes and accelerating business app development. The crucial difference between Lean BPM and other BPMS is that these tools are specifically designed to be used without coding or development skills – in other words, they are designed to be used by the ordinary business user who is the expert in their workflows and processes, but is not a coder.
This is what a Lean BPM transformation initiative looks like:
The business analyst or ‘someone’ identifies an improvement.
You or your team review the findings and agree upon implementation.
The business analyst, or ‘someone’, make the changes directly within the workflow or process managed by the Lean BPMS, which includes publishing them into a live state using visual drag-and-drop tools.
This takes anything from a few hours to a couple of weeks depending on the meetings you need to hold to gain buy in.
Now you have to monitor what the results are and see if your theoretical improvements translate into better customer value.
We cut out the need to map the “As Is” state, eliminate the handover to the IT department and totally remove the layers in between, where the work is taking place and the people responsible for making the relevant changes to the system.
This is why we call this Lean BPM: the changes being made to how work gets done are being performed by those closest to the Gemba.
The implications of this for transformative efforts are enormous and it goes way beyond cost and time savings.
Fundamentally, we are changing who is using the technology used for implementing BPM from the technical specialists to the business generalists. BPM suites no longer have to be the tool that is used to deliver change requirements, but a transformation platform which ordinary users can interact with to manage and improve how they get work done.