In The Zero Code Hypothesis, Scott Francis observes the contrast between 2 trends in BPM right now. On the one hand there is Camunda explicitly saying the zero coding ambition is broken. Scott comments:
It is kind of a fascinating counter-point to the movement to make BPM “more accessible” to the business, and I think it represents a pretty sizable chunk of the open source market that is in strong agreement.On the other hand, there is the trend to further simplify process design for non-technical people. Several BPM vendors concluded that BPMN is too complex for simple processes and started experimenting with process builders for people that don’t know BPMN.
Key passages from their presentation included “Enabling people who normally couldn’t do BPM or BPMN”. BPMN was described as the invisible hand surrounded by UI.Scott concludes that this is a contrast:
And to think that these sessions were all on day 1 of the same conference – totally different hypotheses on how to approach BPM and BPMN.
BPM always has been about automating people tasks and combining those with technical system integration steps. As such, BPM serves 1) non-technical business people that work out concrete steps how the organization should accomplish larger goals. And 2) technical people weaving in the automatic steps and integration with other systems.
At Effektif, we take those two stakeholders as the starting point, and both types of users must get a tailored user experience.
In my opinion, it only takes a well-aimed Fruit Ninja move from the vendors to slice BPM so that both stakeholders are served well. Meaning, with the right approach both business people and technical people can be served properly.Slicing BPM becomes obvious if you consider all people related aspects separate from the technical aspects. All people aspects in a process can be configured by non-technical business people. Things like sending simple notification emails and filling out a form to complete a task don’t require technical knowledge. By default, all processes should have the ability to attach documents, links and have a discussion. With these capabilities, non technical people can already build a broad range of useful processes that don't require technical integrations.
Fruit Ninja precision is required to resist the temptation of adding small technical aspects that enable the next interesting feature. I believe that is where traditional BPM vendors fail miserably. In order to keep simplicity, a BPM system must cut out rigorous any technical aspect from business person’s user experience.
That slicing between technical and non-technical aspects is applied rigorously throughout the Effektif product. It ensures a superior user experience for the non technical managers automating people processes.
To my experience, business people are not trained to work with the extreme rigor that's needed handling automatic processes. They tend to mask all the odd things that seem "unlikely" to them. All I've seen was to let them develop proposels and give these propsals to a team of IT-engineers to check and correct them. And there is hardly one passing unmodified into production.
ReplyDeleteI agree it's impossible to build one generic BPM system that includes integration for technical people and still keep it simple enough for business people.
ReplyDeleteBut imagine a tool that only allows to specify tasks with forms, handovers and escalations. By restricting the featureset offered to business people, it can become simple enough so that business people can build meaningfull and executable processes.
Once people get started with the simple approach, then there is indeed often the desire for further customization. That still needs to be possible and that always requires tech skills to put it in production. But at the moment, a lot of processes are just ignored because it takes an IT project to automate a process. Even if there are some limitations to it, it makes sense for business people to start to automating processes.