A picture tells a thousand words, and a workflow Activity Diagram does just this when trying to describe business processes to BOTH IT and knowledge workers.  This is an amazingly easy way to communicate what the process is, who the participants are, and the logic behind when different activities come into being.

This was proven in spades while working with one of my client’s accounting department.  None of them had any IT/programming background.  In just a minute our two they were able to easily understand what the diagram meant, and then engage with me in meaningful discussion about what worked and didn’t work.  It was at this point that real corporate structure, decision points and business rules became apparent, even though discussions about the purchase order process had taken place during an in-depth management meeting.

What I found was that there were more levels of management, and different departments had different rules about what dollar value authorization each role had.  This resulted in further management discussion and agreement about corporate-wide purchasing levels and exceptions to the rule, all of which were quickly added to the workflow.  As a result the business was easier to understand and Accounting no longer needed to play the cop when requests came to them via paper.

The lesson to be learned is that true requirements aren’t found solely by discussion and interview.  The come about through an iterative process using discussion tools that are well understood by all parties. 

The good news is that not only can the workflow designer that we use be used as an activity diagramming tool, it IS the “programming tool” for the resulting workflow that reflects the business process.  They are one and the same.  What this means is that there is no translation between tools.

Another huge advantage is that modifications to existing processes (whether in development or production) are simple and straightforward.  This owes to the fact that the workflow simply needs to be downloaded from the development or production site, modified with the workflow designer, and then uploaded.  The turn around time can be a minute or two.  This gives the advantage of agility and quick response times to changing business rules and consensus building.

Perhaps the most significant reason why I became a workflow consultant was that tools had reached a level of maturity and integration wherein it became far easier to express business processes as a workflow, rather than making compromises on process based on technology.  In the late 90s and early part of this millennium (and with some products still to this day), workflows were really only understood by programmers using tools such as Visual Studio.  This created a huge gap between what business leaders and subject matter experts knew needed to happen, and the ability for programmers to express those needs in a functioning system. 

Lotus notes is an example of a system that had promise but failed to deliver.  The underlying use and development model simply could not keep up with the ever changing and expanding business rules.  Beyond this, the support of client-side software put more burdens on IT, rather than less burden on SMEs.

When Microsoft introduced SharePoint in the late 90s, it became apparent to me that it was only a matter of time until they added workflow to SharePoint.  SharePoint was quickly becoming the repository for documents and other disparate information, and process technology to manage this information was sure to follow.  What I didn’t appreciate at the time was that Microsoft would take the programmer (rather than programmer-less) route with Windows Workflow Foundation.  This simply put them back into the Lotus notes conundrum.  While it is a great business model for increasing sales of development tools and forms servers, as well as keeping their consultants (who sell their software for them) happy.  But it doesn’t help business get to where they need to be:  increased operational efficiency and agility.

Several workflow products no exist that take a different tack.  The tool that is used to define the workflow is the same tool used to communicate the business rules to SMEs, AND is the same tool used to transform the business process into a functioning workflow.  What this allows is dramatic:  everyone is on the same page, as there are no transformations between, say, UML and whiteboard (lay) diagrams, or between UML and code.  The workflow IS the business process…simply expressed as a diagram that business leaders, SMEs, and IT staff can understand; and it IS the coding of the workflow.

Capability Maturity Model and Workflow

This technology trend is something that we’ll see continue as businesses seek to increase the speed with which they climb Capability Maturity Model levels.  Organizations do this simply because the investment payback is so high in terms of organizational efficiency and business intelligence.  Given this, they will seek tools that get them “up level” more efficiently and cost effectively.

I just finished reading ShareVis’ white paper entitled “Full Enterprise PLM” through model-based workflow using ShareVis/SharePoint.  They’re on to something here.  As many of you know I’m a big fan of iterative and incremental development that I picked up on while at Menlo Innovations. 

I also feel very strongly about the need for knowledge workers to not have to spend an exhaustive amount of time learning whole new systems.   PLM, ERP, etc., while extremely valuable to the enterprise, can often be quite esoteric.  Knowledge workers often ONLY need a focused view of the data presented through a front-end that is familiar and focused on the “data at hand”, while others need in-depth PLM/ERP data that only PLM systems and their GUI can provide in a cost-effective manner.  Building and entire PLM system incrementally through forms and workflow on SharePoint has merit, but huge investments made in PLM should be leveraged as back-ends first.

SharePoint as a front-end to these systems makes a great deal of sense, but only if data can be fed into and out of them to populate these often disparate systems.  Workflow systems like ShareVis makes this job easy.  While one of the advantage as ShareVis states in their paper is that overall systems can be brought online incrementally, what they didn’t delve deep enough into was the human-computer interaction of such a scheme.  With users interfacing only through a familiar web browser and a familiar portal like SharePoint, they can spend more of their mental cycles on the meaning of the data, rather than the interface through which they interact with the data. 

Beyond this, the data that they are interested in, and only these data, can be presented to them.  The workflows the ShareVis paper discusses provides for what I would term “filtering to role”. 

Furthermore, at each stage of a workflow different roles need reports on the data surrounding their node of the overall workflow.  SharePoint/ShareVis helps here as well, with out of the box reporting on data available to the participant.

I see a great advantage to their methodology here, which can be widely and easily adopted by all manner of product development companies.