The Value of Process Design, Illustrated
- May 31, 2017
- 1 Comments
For those who love to geek out on BPMN, you could do worse than to follow Anatoly Belaychuk’s BPM blog. In a recent post he wrote about message flows, events, and tasks. Message flows are an under-utilized and somewhat misunderstood element of BPMN because some of the early entrants in the space still don’t implement message flows in their design tools, though the underlying engine supports the concepts just fine. What does that mean? well, it means you can implement the functionality, but your abstract thinking skills have to be more advanced to creatively build the processes to implement the message flow patterns.
I love how, in this post, Anatoly shows the subjective and creative power of good judgment in modeling. He starts with a complex diagram that accurately represents the problem but obscures understanding.
And then he progressively shows how you can simplify the diagram to something infinitely easier to grasp and implement.
These are great examples of the value of a skilled expert in process design. It isn’t just that they get the job done faster:
- they understand the job to be done
- they produce better designs with less complexity to solve the same problem
- they produce designs that are easier to maintain and improve into the future
- they avoid common pitfalls that will cost you money and time and risk in testing, UAT, and production
A great process design expert (BPM expert) can save millions and a mediocre expert can cost your business millions with a process going into production badly. It is often believed that a less capable process designer or developer will just get the job done more slowly – but that isn’t the half of it. They won’t get the job done more slowly – they will actually destroy value along the way by:
- introducing complexity
- missing requirements
- misunderstanding requirements
- incomplete work
- defective implementation
- breaking other team members’ work, causing re-work in the development and testing cycles
- inability to maintain their own work, let alone the work of others’.
It’s a bad bargain, but you see it all the time. Now imagine not a diagram, but a software program. In the same way, someone without the expertise required will design something dramatically more complex, and they’ll break other team members’ work, and struggle to maintain their own work… and it is buried in code, which it is unlikely any manager, business person, nor expert will ever review or validate. It is hard for people to accept that 1 expert can outperform 4 or more people who lack expertise. Psychologically you just want to believe that 4 people can do it at least as fast as one person, even if they’re not as good. But you can’t put four normal people together to play tennis and get a Roger Federer.