Assign the Right Tasks to the Right Participants at the Right Time
Let This Be Known as 'The Process Functionality Mantra'
Pretty easy to understand... and conceptually pretty easy to implement a Process Engine that can "chant this mantra".
The second mantra of BPM is the following:
Pretty easy to understand... and conceptually pretty easy to implement a Process Engine that can "chant this mantra".
The second mantra of BPM is the following:
Expose the Right Process Information to the Right Parties at the Right Time
Let This Be Known as 'The Process Visibility Mantra'
Note that the mantra chants "Right Parties" rather than "Right Participants". A Participant (in BPM) is someone who performs a task in a process... in many cases there are many additional Parties who need to have process visibility (the Process Owners, the Managers, etc.).
The Process Visibility Mantra is a bit harder to chant convincingly than the Process Functionality Mantra: "Right Process Information" is very hard to pin down, and it can vary widely from process to process. In general, every Participant in a Process is going to want to have an idea of "What already happened and what is left to do?" Process Owners and Managers usually want additional Overview Information about all process instances, Historical Trends, etc. I call these "god views" of the Process (also known as UPS Envy).
I recently came across a new (for me) requirement for Process Visibility... Show Me My Future Tasks.
Here is the scenario: Participant are assigned Tasks... but those Tasks should not start until some date in the future.
For example: "Call the Client" should be performed 30 days from now.
The Participant's (normal) Task List (inbox) should not show the "Call the Client" task (since it's in the future), but they do need to be able to see all "Scheduled Tasks" to allow them to plan ahead (for vacations, etc.)
To anybody with a Calendar, this doesn't seem like a big deal. Look up the Participant's future appointments (tasks).
From a BPMN perspective there's a bit of a problem with displaying "Future Tasks".
It's not a big deal to model an Activity (task) that will start in the future... You simply insert an Intermediate Timer into the Process Flow before the Activity... The Timer keeps the Process from advancing until the correct amount of time has elapsed, and then the Activity is assigned to the appropriate Participant.
Note that the mantra chants "Right Parties" rather than "Right Participants". A Participant (in BPM) is someone who performs a task in a process... in many cases there are many additional Parties who need to have process visibility (the Process Owners, the Managers, etc.).
The Process Visibility Mantra is a bit harder to chant convincingly than the Process Functionality Mantra: "Right Process Information" is very hard to pin down, and it can vary widely from process to process. In general, every Participant in a Process is going to want to have an idea of "What already happened and what is left to do?" Process Owners and Managers usually want additional Overview Information about all process instances, Historical Trends, etc. I call these "god views" of the Process (also known as UPS Envy).
I recently came across a new (for me) requirement for Process Visibility... Show Me My Future Tasks.
Here is the scenario: Participant are assigned Tasks... but those Tasks should not start until some date in the future.
For example: "Call the Client" should be performed 30 days from now.
The Participant's (normal) Task List (inbox) should not show the "Call the Client" task (since it's in the future), but they do need to be able to see all "Scheduled Tasks" to allow them to plan ahead (for vacations, etc.)
To anybody with a Calendar, this doesn't seem like a big deal. Look up the Participant's future appointments (tasks).
From a BPMN perspective there's a bit of a problem with displaying "Future Tasks".
It's not a big deal to model an Activity (task) that will start in the future... You simply insert an Intermediate Timer into the Process Flow before the Activity... The Timer keeps the Process from advancing until the correct amount of time has elapsed, and then the Activity is assigned to the appropriate Participant.
The BPMN problem with respect to showing Scheduled Tasks is that the Activity isn't really assigned to anyone until the Timer has completed. This usually makes sense... the Right Participant in the future may not be the Right Participant now, so it's generally better to wait to make the assignment.
To display the "Future Tasks" you need to travel up the Process Diagram to find out where you'll go in the future. This only works if you have enough information now to know which branches are going to be followed in the future, and if you have enough information to satisfy any routing logic that you will encounter. If a future decision is going to be based on information that you don't know yet, then you'll have to guess. If your guesses are accurate, then you'll get the right "Future Tasks". If your guesses are wrong... well... you're screwed (pardon my French).
In many cases, you can make accurate educated guesses, and your predictions about the future will be good enough... but sometimes it's just a wild guess.
There's a very similar problem in estimating how long it will take for the Process to complete. Since you may not be sure exactly which Activities will be required you've got the same basic problem... You have to guess.
It's always possible to hand-craft "something" that can satisfy the most demanding Process Visibility requirements... but there aren't any general solutions for dealing with "Future Tasks" that I am aware of. As BPM matures, I expect that we'll see some very elegant solutions to challenges like this (producing a project plan from a BPMN diagram perhaps)... but in the mean time just keep chanting those Mantras ;-)
To display the "Future Tasks" you need to travel up the Process Diagram to find out where you'll go in the future. This only works if you have enough information now to know which branches are going to be followed in the future, and if you have enough information to satisfy any routing logic that you will encounter. If a future decision is going to be based on information that you don't know yet, then you'll have to guess. If your guesses are accurate, then you'll get the right "Future Tasks". If your guesses are wrong... well... you're screwed (pardon my French).
In many cases, you can make accurate educated guesses, and your predictions about the future will be good enough... but sometimes it's just a wild guess.
There's a very similar problem in estimating how long it will take for the Process to complete. Since you may not be sure exactly which Activities will be required you've got the same basic problem... You have to guess.
It's always possible to hand-craft "something" that can satisfy the most demanding Process Visibility requirements... but there aren't any general solutions for dealing with "Future Tasks" that I am aware of. As BPM matures, I expect that we'll see some very elegant solutions to challenges like this (producing a project plan from a BPMN diagram perhaps)... but in the mean time just keep chanting those Mantras ;-)
No comments:
Post a Comment