Scott Francis, posted a quite relevant post after coming out of BPM Next Conference about the possibility of developing and deploying process applications with a “zero code” approach and how that can turn out to be very limiting when a company is designing applications of top of Business Process Systems.
In Scott’s post I argued that it’s possible to create applications on top of a business process system without any code, but using code offers much more design possibilities, as also, in most of the business environments it is mandatory you use code for solution delivery (otherwise it’s virtually impossible to implement).
I consider Scott’s post relevant, because this is the kind of discussion that most of the times are not included in conference agendas or do not make part of the discussions inside the community, once everyone likes to talk about the implementation success (that was done taking the thorns off the skin, sweating and screaming), when we should talk about how to guarantee success in process improvement initiatives, in a time were most of the customers are facing a trade off about cutting budget and try do implementation by themselves, with the promise that the system they bought allows with some hours of training make knowledge transfer, or, in the other hand, pay a huge amount of professional services fees to minimize the risk of the project.
Lately with the promise of the rise of knowledge workers I took care of projects that followed the former approach that have resulted in very poor implementations, simply because the customer over evaluated the skills of it’s own team, and they could not deliver what they committed to (like for example diagramming BPMN 2.0 processes).
What I think it’s also (most) important to the discussion, is as Scott pointed in a tweet, if zero code implementation is possible, and that kind of variant is at reach of business users, why it is not done?
I think there are two reasons for that:
- The first, is the scope of the projects. There is always a learning curve to transfer knowledge to the business users, factors like, we need to ramp up fast, we cannot wait to put it up and running by ourselves after a pilot of two, because we are going to loose market opportunities and operations need to resume to business as usual instead of developing applications during the day and perform the daily work during the night. This aspect is starting slowing to change, as more qualified workforce have the skills to put their hands on the tools, but still, it can turns out something like when you have a business intelligence project and you find in the customers team someone that did some good stuff based on ad-hoc sql queries and created some excel files with pivot tables and charts. This kind of approach, knowledge transfer, implies that your customer have a very strong team with governance guidelines, that have a huge experience in process improvement programs, that most of the times does not exist. Hence, in the end it’s cheaper and more effective to pay the professional fees to the provider, rather than take the risk and try to do implement internally. This variant also includes the fact that most of the customers are not experienced in process engineering, meaning that even if they master to use a BPM system they will fail how to design an optimized process operation, that simply laying down technology will not (also) make it.
- The other factor is the doom business people experience when talking about the other side of process implementation, technology. Like the turf wars about business architecture and technological architecture, business users, even the most experienced, only scratch the surface (they do scratch because it’s out of their domain expertise, it’s a cognitive limitation) when they need to understand the implications and technological interconnections, that makes virtually impossible, by themselves, to implement a “zero code” approach. If the in the future semantic oriented design starts making part of the enterprise architecture and tooling, probably it can be possible to reach this outcome.
This is the kind of discussion I think it’s worth to have and help managers to reach successful outcomes, and I apologize to Scott to tweet that his post should not be buried in a blog post (like this one). The challenge it’s to promote this discussion to a conference session or an independent webinar, but probably system vendors are not keen to talk about. Something like the spirit of BPM Next can slowly start to change.
What are your thoughts?