Tips for the Business Process Developer - Activity Data from the Participant's Perspective

This posting is a continuation of the ongoing Process Data Perspectives conversation that I have been having with my Teamworks BPM colleagues...  In a nutshell, we think that you'll create a better process data model if you consider the data from the perspectives of the folks who are actually engaged in the process.  We've identified the following perspectives that are common to most Business Processes:

• Process Owner
• Process Analyst
• Process Participant
• Process Builder

Today I'll be focusing on the Process Participant's perspective, particularly how they see data within a single Activity:

Participants in the process are the folks who are asked to perform specific tasks. For example, in a Loan Application process, the participants would include the Loan Officers who review and make approval decisions about loan applications.

Participants care about now. Their perspective of process data is immediate. What forms do they need to fill out? What fields are on each form? What are the acceptable values for each field on a form? Participants view data from a task level - What information do they need to consult and what information do they need to gather and modify to accomplish their task.

Given this understanding, let's delve a bit deeper to help translate the Participant's perspective into terms that are more familiar to Professional Programmers.

From the Participant's perspective: When performing a specific activity, the data (information) falls into the following categories:

1. Information that I am required to provide
2. Information that I can optionally provide
3. Information that I am required to verify
4. Information that I am required to correct
5. Information that is presented to me to help me with all of the above

There seems to be a lot of nuance in the above list because there is a lot of nuance in the above list.  The deeper you get into process activities, the more likely you are to encounter nuance.

"Information that is presented to me to help me with all of the above":

Let's start our journey at the end of the list: "Information that is presented to me to help me with all of the above".  Tell that to a programmer and they'll cringe.  We need to break it down a bit further into Instructions and Context.

Instructions:

All Activities need instructions. You need to tell the Participant what to do.  Some instructions are "static" - they don't change from instance to instance.  Other instructions are "context sensitive" and only displayed when appropriate.

Here's a static instruction: "Verify that the Postal Code is valid for the City."

Here's a context sensitive instruction: "Because the loan amount is over $200, you must record a co-signer."

Instructions aren't generally thought of as part of a software application's data model (by programmers) since they're generally "hard coded" on screens.  We programmers usually don't worry about where or how they are stored - they're just "part of the code".   In a Process Application we really ought to worry a bit more - The instructions need to come from the Business folks, and those folks really ought to be able to change the instructions when they need to.  This is particularly true when you have "localization" needs (instructions translated to multiple languages)... but there's a wider opportunity here for us to explore.

Wouldn't it be great if the Participants who perform the Activities could collaboratively improve the Instructions that are presented to them?

Phil Gilbert is always talking about BPM on every desktop - and this is a simple example of what that might look like.  Lousy instructions can make a simple task hard to perform.  Great instructions can simplify a complex task.  Give the users a mechanism to provide feedback, and over time they'll transform lousy instructions into great instructions, and process performance improvements might follow.

Context:

All Activities need context.  The Participant needs to know exactly what it is that they are working on.

Here's an example of context information: "The applicant is John Q. Public."

Context information has to come from somewhere... and that's why it's a crucial part of the data model.  Some context information comes from the Process Payload - that's information that's "passed" from Activity to Activity as the process progresses (think of this as an analog to the stuff inside the envelopes that are routed from worker to worker).  Other context information is retrieved from a System Of Record (SOR) when the Activity needs it (think of this as an analog for retrieving something from a filing cabinet when the worker actually starts the task).

Determining which context information should be part of the Process Payload and which should be retrieved from an SOR is both a science and an art that we'll leave for another discussion - for now just be aware that you'll need to iron out these details.

Determining the proper context information to display is on par with determining the right instructions to display - which means that you really need to validate context information with the users.  Paradoxically, context information is often "context sensitive" - Complex relationships on what to display often occur, based not only on the instance data of the Activity, but on attributes of the Participants themselves (a Manager may see more or less context data than a Worker).

Once again, this would be a great opportunity for BPM on every desktop - Give the Participants the power to define the context information that they need to see to efficiently perform their tasks.

"Information that I provide, modify, verify or correct":

From our original list of information types I've collapsed several entries for the sake of brevity...  Activities (with very few exceptions) require the user to provide, modify, verify or correct information.  Let's lump all of this data under the term "Manipulated Data".  There's often a blurry line, or no distinction at all, between Context data and Manipulated data, so it might be best to just think of this as the mutable (things that can be changed) subset of the Context data.

As with Context data, Manipulated data can either be part of the Process Payload, or it can reside in Systems Of Record... this is where the underlying architecture of your data systems is really going to come into play... If the Activity involves legacy systems, then System Integrations may be in your future.

Data Validation Rules:

From the Participant's perspective, they may or may not be aware of where specific information comes from, but they should be moderately aware of "what the rules are" around that data.  For example, the Participants must know whether or not a field is required or optional.  They must also know whether or not they are supposed to correct information (or ignore mistakes).

Validation of information that users supply or manipulate is a crucial concern that must be addressed - and you should start addressing this concern while defining the process data model.  Each field may have its own validation rules.  Collections of fields may have inter-dependencies.  The rules that are applied to fields may change as the process progresses, and they may change based on "who" is manipulating the field.

Purists may not consider the rules that apply to the data to be part of the data model, but pragmatists don't really care about distinctions.  The data requirements of a process are just as much about the data validation rules as they are about the data fields.

The Payoff:

That's a lot of stuff to consider when defining the Data Model for a single Process Activity, but you have to admit that it's mostly common sense from the perspective of the Participant who will be performing the Activity.  If you don't work with the Participants to define the data requirements to this level of detail "up front", then you're likely to have problems crop up when you least expect them.

Walking a mile in the shoes of the Participant at the beginning of your journey will probably make your journey shorter ;-)