Is a graphical process designer really necessary?

In my role of 'sales support' I regularly get asked by customers to justify why a particular workflow product that is part of an overall solution being offered does not include a graphical process / workflow designer. After all, BPM products have been offering that type of pretty functionality for years.

The workflow in question is targeted at automating document driven processes, for example HR job application processing. With the workflow, documents are managed with end to end processing from the point of scanning paper documents in a mailroom, through automated delivery to appropriate users, follow-up correspondence creation, automatically matching additional documents to current cases, reviews, approvals and case archiving. Conditional routing, user forms and web services integration are all configurable out of the box.

Unlike many standalone BPM engines, this workflow provides seamless integration with the built in document management system and image capture subsystems. This leads to a system that requires zero integration effort, enabling configuration to focus on the business process and security requirements as defined by the business analysts.

What it does not have is a graphical process designer - there are no attractive flow-charts here. Instead, configuration is through a pure web-based tool that enables process steps, data model, and functionality to be defined alongside the data model and routing rules of the document management system.

So, how do I justify the lack of what seems to be an essential component of a workflow? And more importantly, do you think I'm right?

Look at it this way. Most business analysts have a tool of choice when analyzing and designing processes. Let's imagine that in a fairly typical environment this is a MS tool like Visio, or my tool of choice, Powerpoint (OK, I know!). Here is how my actual HR job application process looks to a business analyst:



Despite non-standard flowchart shapes, this process is understandable, and captures the key requirements of the process: route employee documents through process steps based on specific conditions being met.

With traditional graphical process design tools the actual business process becomes visually confused when the additional requirements of documents, security, roles, etc are added to the diagram. For example:



Here, the intention of the business process as originally depicted is less obvious. Now imagine how this would look if we added the steps and annotations required for implementing a specific workflow engine. OK, I tried to draw it, but it was a mess. In a real graphical process designer, a lot of the detail gets hidden in pop-up dialog boxes that hide implementation details, but also often hide the actual operation of the process.

Now imagine that the workflow system that I am justifying to a customer has all of these capabilities available at every step in the process:



In a traditional designer tool, each of these capabilities and routings adds to the complexity of the diagram and draws away from the overall business process. Let's guess at how this looks when there is a complex business process - the businessanalyst can barely see his or her design behind the clutter ofimplementation. In fact in my experience, this leads to about 5 process 'shapes' on screen for every one of the steps in the original process design.

So in my case, I have the first diagram pretty fully describe theprocess. The second diagram doesn't provide much more value in ensuringthat the key requirements of the process are met. A diagram that alsoincludes implementation details of the specific workflow engine isuseless to the business analyst, but perhaps holds some value to an implementationguy. Add in standard capabilities that are available at every step and the intention of the process diagram probably becomes unreadable.

So, like me, the business analyst ends up doing their design work in Visioand transferring it at the end to the workflow tool (see a discussionin the IT|Redux blog on how simulation may encourage this two step approach even more).

In the tool I try and justify to customers, the configuration is tuned to this fact - that the business process design has been completed in a design tool most appropriate to the task. The process steps are entered rapidly, with the capabilities listed in the final diagram enabled and disabled with check-boxes, all alongside the data-model, security and conditional routing.

There are several things that matter:

1. That the business analyst can accurately and effectively configure the process they have designed
2. The implementation of the process is rapid, without integrations and code being required for standard capabilities
3. The process runs as designed with reasonable hardware requirements
4. The users can effectively and efficiently use the final process
   

The system I talk about with customers achieves all of these. When the process configuration is demonstrated to the customer, and a complete workflow process is up and running in less than 15 minutes, many are surprised and impressed. But the FUD is still there - if there is no graphical designer, how can this be a true workflow tool?

My question to them (and you) is this: if you can meet and deploy the key requirements of the business process in a tool like this, faster than any other, why is a graphical process designer necessary?

Technorati tags: Financial Services Technology New Account Opening EDM BPM
workflow

(UPDATE: apologies for posting twice - I noticed straight after publishing that Zoho had messed up a bit of formating on transfering to Blogger. I'll check more carefully next time. Oops)