Process Optimization - A diamond in the rough

Refining your BPM process

Ah… The holiday season! Time to be with your family, eat like an elephant, getting stuck in endless traffic jams and moving in overcrowded shopping malls. No better time to write BPM articles, right? Actually, wrong! Curiously, a peak in activity actually absorbed me completely and we couldn’t do all the stuff that we wanted to. Anyway, we’re back.

Last time, we defined and modeled our first business process in BPMN. It modeled the “Request a parking space” process, with the behavior described in the textual process description. Now we’ll refine that process so that when we decide to implement it, we’ll take less time to do so.

Optimize before implementation VS implement before optimization

There’s an interesting debate as to whether or not should the first version of the BPM model be optimized before the implementation.

Some say “of course…why would you put a substandard process in production?”, while others argue “don’t worry and put the first version of the process in production ASAP, because the BPM lifecycle will guarantee an optimized version by itself in the second iteration, based on facts, not perceptions”.

Both approaches are valid and you can choose either one. Just don’t over do it if you go with the first one, or you’ll never get a version in production.

We typically choose the first approach, but we put a (half) day cap on the optimization work (one full day if the process is complex), to limit what we do. By the end of that (half) day the process goes on for implementation with whatever optimizations done in that time. This also help us focus and go for quick wins instead of nitpicking.
With our experience, we can look at a business process and quickly identify possible improvements. In time, you will too.

See any patterns?

If you look at the process version from the last article, you’ll see somethings that appear to be repeated. These are typically good candidates for optimization.
If you can factorize these into a reusable piece, you would only need to implement it once and then reuse it as many times as you want.
Check the notifications to the requester.

Some activities are repeated. A few are actually the same, others are very much alike with only small details different

Some activities are repeated. A few are actually the same, others are very much alike with only small details different

Most of them are basically the same, with only minor changes to the message itself. So, let’s start optimizing this.

No matter what the case, the notification task will send a message to a recipient of our choice. The content and recipient may differ, but the process will always send a message. This translates to a much cleaner process, because all of these notification tasks can be transformed into a single one.

Process after merging all notifications into a single one

Process after merging all notifications into a single one

much simpler, hum?

But now you may ask: “How will the notification know what message to send?”

If you notice the previous version, you already had the same issue. What determined which path the process followed was the result of the Check Parking Space Availability activity. No changes there. What changes is the logic behind the Check Parking Space Availability and the Notify Requester of result activities, so we’ll handle this in our next articles, trying to keep code at bay.

And with this simple optimization, the process became so simple, that there’s no need to perform any other optimizations… or is there?

At least for now, we’ll keep things as they are.

On the next post, we’ll start  working on process data, the first step towards process execution. Stay tuned.



Post header image by Jeff-o-matic

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *