I’m sitting in a meeting typing a blog.  Shoot me.  However, there is a discussion going on about how a process may flow differently depending on the level of information that may be made available. 

Earlier I described different levels of abstraction in workflow.  Recap: Business Unit View is high level-Unit-to-Unit.  Very document and message based.  Business Process View is mid level: items move from stage to stage based on conditions, and Work Step View, which is describable at the technical level (petri nets and workflow diagrams that techies tend to wrap themselves up in).

The problem comes when there are a set of steps that need to occur in a workflow where the workflow has Business Unit implications, but where one unit doesn’t want to expose the Process View details.  In other words, if group 1 sends a request to group 2, and then calls three weeks later asking about the status of the request, they shouldn’t get detailed information about the person in group 2 who is stuck.  In a B-to-B scenario, for example, a hospital may send an insurance claim to a payer, and then call up in a few days asking if the claim will be paid.  Should the payer respond that there is a data or systems issue, or should they respond in the generic: “we are working on it.  Should be done in 10 days.”

The latter is more useful to business. 

This only works if our systems allow for us to actually drive these levels of abstraction into our workflow execution systems.  Literally, an process should live within a “container” that provides information to external requesters.  That way, if the process changes within the container, or a particular step represents a process that is of strategic value, those process steps are not exposed.

It’s data hiding at the workflow level.  It’s useful.  It is uncommon.  Let’s fix this.