We are the 99% is perhaps the most powerful slogan of this decade, popularized by occupy wallstreet movement. It originates from the idea – 99% of the human race have simple needs (food, shelter & family). Unfortunately, the rest 1% – rich & powerful decide policies for all. Workflows in an organization are no different. Majority (99%) of the workflows have simple needs. Yet, they are not automated. They run on emails and spreadsheets and are hard to track and report.
Building workflow is harder than it meets the eye. There is always a gap in the way the process owner explains workflow Vs the way workflow products implement that workflow. For example, if you take a simple Leave request workflow, the process owner will explain it as a straightforward 2-level approval. So, you will end up with a process like this in the first iteration:
Once the process owner starts to test the workflow, he will ask for the ability to reject a request. In the process owner’s mind, “rejection” is an implicit part of approval in his view and goes without saying. But, the same is not true in the case of workflow products. To handle rejection, you have to add a decision tree, 2 branches and 2 more activities to the workflow. Same is true for query functionality. Building this part of the workflow again involves substantial changes to the workflow.
Naturally, both rejection and query functionality is expected in the 2nd approval step as well. Before you realize, our “once simple” leave request workflow looks something like this on production:
If this is the case with a simple Leave request, think about a slightly more sophisticated workflow like Expense claim. Doesn’t look simple anymore. Does it?
Workflow products are based on programmers way of thinking. Developers are expected to think of all scenarios and handle all possibilities irrespective of its importance and usage. Throw some words like exception handling, you can become a BPM expert. The upside of this model is its flexibility. For example, if your workflow demands you to have a functionality to “put workflow on hold for 4 days”, you can do that with these workflow products. It allows 100% of workflows to be automated. The downside of this model is that, it makes majority of workflows horridly complex. In fact, it makes your workflows in production unrecognizable from the one you drew in paper or whiteboard.
We believe that the solution to workflow woes is not to invest in yet another hifi workflow engine like Oracle Fusion (& cause more confusion). Instead, in making smart trade-offs. By focusing on the 99% use cases in simple workflow such as “Approval”, we can make majority of workflows simple to build. For instance, Kissflow abstracts the relevant set of activities based on workflow behavior into process steps, letting the process owner focus only about the main flow. So, when you add “Approval” process step in Kissflow, it comes with Approval, Rejection and Query branches under the covers. So you can focus on just the main flow. There will always be that 1% of workflows that can not be built because of this abstraction. But, that’s the trade-off that makes the 99% of workflows tick. That’s the core of what Kissflow Workflow is all about – Keeping it Simple & Smart. Give it a try and let us know if we have hit that mark! We are listening!