Modeling your processes: a trick or a treat?

I recently attended an online webinar about how to boost your processes with no-code.

The speaker was a person that started his career as a designer. Nowadays he owns his own company whose goal is to help businesses automate their internal processes without coding. I will call him Jack.

With my developer background and my current position at Bonitasoft, I was very interested in hearing about Jack’s approach.

Jack was well-known by the audience and I could tell he had a lot of experience on this topic. He gave some examples of no-code automation tools. Some of them were familiar to me and I appreciated the enthusiasm he demonstrated for automating processes.

At the end, I was able to ask one question: what do you think of using the Business Process Management (BPM) discipline for modeling your processes? He gave me an interesting answer about how discipline was important, but nothing related to BPM. I believe that Jack didn’t know what I was talking about.

Which made me wonder: is process modeling a trick or a treat? I mean, is it necessary? Is it worth it?

In computer science, we often hear that it is preferable to discover design issues during the design phase instead of during the implementation phase. You might be familiar with the "tree swing" cartoon. Personally it puts a smile on my face every time I see it. When you’ve already experienced going through a definition phase with a client and yourself on the technical side, this cartoon makes so much sense!

I remember once the client was asking to include the internet on the product. I didn’t try to argue with that but just translate it as "the product needs to connect to the internet". And at the end, I left with a set of functional (and even technical) requirements from the client that I’d translated myself.

My takeaway is: do not just stay with the translation that you’ve got. Document it and come back to the client to verify if you’re still on the same page. Then do not just document it, model it and come back again to verify. Go for a proof of concept, and come back again. Iterate. It’s an exercise of back and forth to try to avoid communication pitfalls and achieve the expected results on both sides.

Also, remember that erasers are wonderful…as The Oatmeal says in his comic with the same title. Consider drawing with pencils, using construction lines and erasers! And I would add: remember that it is cheaper to use your eraser while you’re still writing with a pencil than when you’ve already added the ink or paint.

Back to Jack. He shared his success stories. He was able to deliver what his clients were expecting from him. He did mention that a very important point was observation and being in contact with the client to be able to automate the processes with no-code.

This is the moment when you might think hey I’ve got the answer, then it is just a trick!

Not that fast!

I believe that you can indeed achieve to boost your processes without modeling them first. Much likely how you can just code without going through a design phase.

And then, the day arrives when you need to change something or optimize it. Like...when you have just arrived at a new development team and your task is to fix a bug on the legacy that was written years ago. If you’re lucky enough, the person who wrote that code also documented it. If not, you have to read e-v-e-r-y-t-h-i-n-g hoping to understand what that person wanted to achieve. Does it sound familiar? Yes, been there, done that. Not impossible but painful.

When the modeling step becomes an investment for the future, that’s more like a treat! Don’t you think?

Up til now I have concentrated on talking about modeling during the design phase. What about specifically process modeling?

I recently discovered this type of visual modeling in my current job. The interesting part about this approach is that it is a collaborative exercise between the business side and the technical side. It means that there is no longer the need to have a translation that only the technical side understands. It is all about collaboration. You both end up with a visual model that was built together and thus it’s understandable at both levels: business and technical.

Process modeling uses BPMN - Business Process Model and Notation, which is a standard -part of the BPM discipline- used worldwide. You use it to represent actions, flows and behaviors in a process. Behind the visual model there’s an XML that will allow process engines to convert them into executable processes.

It looks like this:

It might make you think of a flowchart or a UML activity diagram. There are indeed several similarities between them and also some differences. You can check them in detail on the Ultimate Guide to BPMN 2.0.

The interesting part about this standard is that it allows us to have a common ground, so communication flows easily and thus collaboratively initiates improvements. Because not all improvements are done technically, they can also be done on the process itself. This last part is up to the business analyst or the expert on the matter, which is not necessarily the developer.

In conclusion, in my experience I believe that modeling is worth it. I see the business process modeling as a promising common ground that allows two different universes to talk the same language and collaborate. It might be sometimes tempting to skip this step, because anyway there will be iterations and so the opportunity to fix mistakes. However, the time spent on this step will for sure save time in the future. What works right today doesn’t mean that it will in a few years from now. So, go for the treat!

…and happy Halloween!