Those of us who build Managed Business Process solutions for a living have to spend a lot of time thinking about data. Our BPM suites (like Teamworks) make it a snap to define Process Flow and Routing, but we still have to make sure that each Participant in the process has access to all the data that they need to accomplish their tasks.
I always insist that folks implement their process flow first. Build a place-holder for each Activity in the process, connect them up with flow lines and any necessary Decision Gateways, and add in just enough process data and build just enough user interface to make sure that you can play back each step through every path in the process with your business folks.
Building this much of your process first has huge paybacks - There's nothing like stepping through a process to validate whether or not the business folks agree that you've got the process right. Validate the process requirements first - worry about everything else later.
Once you have this first playback of the process done you've got to turn your attention to defining the rest of the process data... and suddenly it's not as clear how to proceed. Where do you start?
The data aspects of a Process encompasses many things that you might not consider when developing other types of applications. There are several common process data patterns to consider - processes gather, transport and transform data across activities that are performed by multiple participants. Data models often dynamically evolve and transform as the process proceeds.
I've had several recent discussions with Fahad Osmani and some of my other Lombardi colleagues about how to effectively develop process data models. We've all implemented a number of managed business processes - We've all thoroughly mastered the craft of implementing processes - But we haven't really formalized our approach for designing process data models. Knowing in your gut what to do is great, but formalizing that into something that you can share with others is better.
Here's what we've come up with so far:
In every business process you've got a variety of actors with a variety of perspectives that you have to deal with - we've abstracted this into the following list:
1. Process Owners
2. Process Analysts
3. Process Participants
4. Process Builders
We've found it best to design a process data model from each perspective in this order, and then consolidate those models into a consistent unified model.
The Owner's Perspective of Process Data:
Start with the owner's perspective of process data - the folks with overarching concerns to make sure that the outcome of a process is achieved. If you're working with a Bank on a Loan Application process, these are the managers of the Loan Department who are held accountable for efficient and effective handling of the loan applications.
Owners have a business perspective on the process data. They've got the big picture business view of the process payload - What are the basic business objects that the process deals with? What data is being gathered? How is the data transformed during the process? What happens to the data when the process ends?
Owners often see process payload data as starting points and outcomes. Their major concern is with the state of the business data "now". They care about the state of the business objects when the process starts, the state of the business objects at key milestones, and the state of the business objects when the process finishes. The owner's data model provides that information.
Beyond the payload data, owners also perceive data in terms of process rules - What data determines which activities to perform? What data determines when a task is due? What data determines who should perform a task? The owner's data model answers these questions.
The Analyst's Perspective of Process Data:
Process Analysts are the folks who look at historical process metrics to figure out if the process can be tweaked to work better. In some cases the Owner may also be the Analyst - but the Analyst perspective really is different. In a Loan Application process, the analysts are the folks who evaluate the effectiveness of the process itself in the hopes it can be improved in the future.
Analysts deal with understanding the past to improve the future.
Analysts view the process data as snapshots in an album. Their view of data is intricately linked to the process diagram - The snapshots are meaningless to them unless they know where the snapshots were taken.
Analysts care about how long things take and why some things take longer than other things. Analyst care about "rework" (tasks that have to be redone). They don't really care much about what's happening now - they care about what happened over some time period. To meet the analyst's needs, process context data (and time stamps) are stored at specific points in the process. Making sure that the right snapshot is taken at the right time is their major concern. The analyst's data model works in conjunction with "snapshot events" in the process flow to capture the information the analyst needs.
The Participant's Perspective of Process Data:
Participants in the process are the folks who are tasked to perform specific tasks. Sticking with a Loan Application process, these 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.
Some information is passed to the participant when they are assigned a task, and some information they look up - but it's all information that is necessary to accomplish a task. Making sure that they can access data and modify the data that they need is their major concern.
One special caveat when considering the Participant's view of data is to ask whether or not any of the data that the Participant changes must be "immediately" seen by others. Data visibility requirements like this are critically important to the Process Builders.
The Builder's Perspective of Process Data:
Finally we get down to the Process Builder's view of the process data - that's us. We really can't do our work until we understand what the Owners, Analysts and Participants need.
Builders care about the actual structure of the data. What data are we going to pass around and how are we going to pass the data around? What data needs to be stored an retrieved and how are we going to store and retrieve the data? How are we going to meet the data visibility requirements?
The Owner's perspective helps the Builder define the major business objects that the process will deal with. The owner's data model also identifies the data that is used to determine which paths are taken, how long each task should take, and who should perform each task.
The Analyst's perspective helps the Builder define the data structures for the snapshots that are taken throughout the process - and informs the Builder where in the process the snapshot needs to be taken.
The Participant's perspective helps the Builder define the process payload (the data that is passed to and from tasks) and it helps them define the data system architecture that is required to retrieve and modify data within activities.
The Payoff:
The end result of this multi-perspective approach is a model for process data that just plain works.
It takes a bit more up-front effort, but you are less likely to get blind-sided by unanticipated data requirements popping up late in your development cycle. The data requirements may change, and any requirement change may still require substantial rework - but odds are the rework will be much easier for you to accomplish.
Clearly understanding requirements from the perspectives of your the process actors always pays off - and this axiom is doubly true when data is involved.
No comments:
Post a Comment