I've probably mentioned before that there's anecdotal "evidence" that when implementing a Managed Business Process folks will spend about 80% of their time building the human interfaces to the process. That sounds like a very bad thing, but in reality it's just a testament to how good the BPM Suites are at building the Process Choreography and Orchestration pieces.
Given that building your human interfaces is going to consume a big chunk of your development effort, it's helpful to step back and consider just what sorts of human interfaces a business process needs.
Task Notification Interfaces
Folks can't be expected to complete their tasks unless they know that they have tasks that they need to complete.
In many cases you will want to send email to a participant to notify them that they have work to do. That's actually a very good approach when you have a participant who only does work for you infrequently. Checking email is something that folks do all the time, so an email notification that there's work to do will probably get noticed.
Email notification isn't a good approach if the participant frequently has lots of tasks to do. Their email inbox will quickly become overloaded, and they'll have difficulty keeping track of the work that they are supposed to do.
For participants who frequently have a lot of tasks to perform, you'll want to build some flavor of a "To Do List" interface.
"To Do List" interfaces have three goals:
That last bullet is (of course) the hard one to implement. A specific task may be very important to the completion of a specific process - But that specific process may be far less important than another specific process. Often times the participant will need to consult Process Status information (see below) in order to determine which task they really ought to work on next.
Task Completion Interfaces
Folks can't complete their tasks unless you provide them with interfaces that let them do their work.
I've blogged a lot over the years about implementing Human Powered Services - probably because I've met a lot of folks who haven't thought enough about how to effectively build them. I'll ask you to Google for my past blogs on the subject and just warn you that you can waste a heck of a lot of time on these interfaces if you don't concentrate on providing only the functionality that's absolutely required.
Process Status Interfaces
It's good to know the state of a process - Knowing what tasks have been accomplished and what tasks are left to be performed can be very helpful information.
Improved process visibility is one of the key promises of BPM, so think these screens through very carefully. If you don't do them well, then you probably won't meet your BPM objective.
You will often build Process Status Interfaces for the folks that "own" some operational aspect of the process.
For example, if a supervisor is responsible for the completion of specific processes, then that supervisor will want a "dashboard" that presents the current status of all the running processes. The supervisor will be particularly interested in any processes that are "at risk" - those processes that may not complete "on time".
When you build a process status interface, you will almost always incorporate functionality that will allow the user to "do something" to influence the running processes. For example, if the user can see that a specific process is "at risk", they may need to initiate an escalation process or reassign some of the tasks to other participants.
Process Status Interfaces have the following purpose:
Process History Interfaces
Being able to review the history of a process is key if you want to know whether or not the process has been running smoothly.
As mentioned before, improved process visibility is a key goal of BPM, and visibility into how well (or how poorly) instances of the process ran in the past is crucial. Without this information you can't really hope to improve the process in the future.
Process history interfaces are essentially reports - and it's should come as no surprise that you may need to produce many reports for each type of process. These reports are usually cumulative - What were the average execution times for the process? Once norms have been established, then seek out the "unusual" process runs and try to figure out why those instances were outside the norm.
Given the nature of reporting, count on generating a lot of process history interfaces for a lot of audiences. It's really hard to anticipate all of the reports the business may want, but start with the most obvious and insure that you're capturing all the data that's necessary to generate those reports.
If you're stumped on what "the most obvious reports" are for a process, then start by considering what you need to "remember" from the Process Status and Participant Workload interfaces that I described. If a supervisor ever has to intercede in a specific process - by reassigning tasks or initiating an escalation procedure - then you probably need to remember "why" they needed to intercede. As the saying goes, "Those who forget the past are doomed to repeat it".
Business Process Interface Snippets
Perhaps I've left out some aspect of Human Interface that your Business Process will need - but I think you will find that most of the interfaces that you need will fall into one of the categories that I've described. Thoughtfully consider the interface functionality that you really need, and I think that you will find it a lot easier to build out your user interfaces.
My final offering is this: Don't confuse the human interfaces that I have described with specific screens.
Many of the human interface aspects that I have described will routinely be combined together on a single screen, or you will find a need to incorporate an aspect of a Business Process on an existing screen.
Consider building out each "aspect" of your Business Process Interface as a "snippet" or "panel", and you'll find it much easier to tailor your interfaces for each of the audiences that you need to serve.
Given that building your human interfaces is going to consume a big chunk of your development effort, it's helpful to step back and consider just what sorts of human interfaces a business process needs.
Task Notification Interfaces
Folks can't be expected to complete their tasks unless they know that they have tasks that they need to complete.
In many cases you will want to send email to a participant to notify them that they have work to do. That's actually a very good approach when you have a participant who only does work for you infrequently. Checking email is something that folks do all the time, so an email notification that there's work to do will probably get noticed.
Email notification isn't a good approach if the participant frequently has lots of tasks to do. Their email inbox will quickly become overloaded, and they'll have difficulty keeping track of the work that they are supposed to do.
For participants who frequently have a lot of tasks to perform, you'll want to build some flavor of a "To Do List" interface.
"To Do List" interfaces have three goals:
- Make sure the participant knows what tasks they are responsible for
- Make sure the participant knows when each task is due
- Help the participant prioritize which task to work on next
That last bullet is (of course) the hard one to implement. A specific task may be very important to the completion of a specific process - But that specific process may be far less important than another specific process. Often times the participant will need to consult Process Status information (see below) in order to determine which task they really ought to work on next.
Task Completion Interfaces
Folks can't complete their tasks unless you provide them with interfaces that let them do their work.
I've blogged a lot over the years about implementing Human Powered Services - probably because I've met a lot of folks who haven't thought enough about how to effectively build them. I'll ask you to Google for my past blogs on the subject and just warn you that you can waste a heck of a lot of time on these interfaces if you don't concentrate on providing only the functionality that's absolutely required.
Process Status Interfaces
It's good to know the state of a process - Knowing what tasks have been accomplished and what tasks are left to be performed can be very helpful information.
Improved process visibility is one of the key promises of BPM, so think these screens through very carefully. If you don't do them well, then you probably won't meet your BPM objective.
You will often build Process Status Interfaces for the folks that "own" some operational aspect of the process.
For example, if a supervisor is responsible for the completion of specific processes, then that supervisor will want a "dashboard" that presents the current status of all the running processes. The supervisor will be particularly interested in any processes that are "at risk" - those processes that may not complete "on time".
When you build a process status interface, you will almost always incorporate functionality that will allow the user to "do something" to influence the running processes. For example, if the user can see that a specific process is "at risk", they may need to initiate an escalation process or reassign some of the tasks to other participants.
Process Status Interfaces have the following purpose:
- Display the current status of the running processes that are of interest to the user.
- Clearly identify any processes that are "at risk"
- Provide interfaces for the user to intercede in any process that is "at risk"
Optionally, a process status interface may also provide a estimates on when specific process instances may be completed. These estimates are based on the remaining tasks that must be performed and estimates for how long each task is expected to take. For more accurate estimates, historical information about the past performance of the process can be used.
Participant Workload Interfaces
Participant workoad interfaces are closely related to the process status interfaces that I've just described... but they focus on the workload for each participant rather than on the status of specific running processes.
If you are a manager who is responsible for assigning work, then it's very important for you to know what everyone is already working on. An interface that shows the user "who is working on what" is very important when new work must be assigned, or when uncompleted work has to be reassigned.
In a sense, these workload screens are a roll-up of the Task Notification "To Do List" interfaces I mentioned earlier, but they're meant for the supervisors rather than the workers.
Process History Interfaces
Being able to review the history of a process is key if you want to know whether or not the process has been running smoothly.
As mentioned before, improved process visibility is a key goal of BPM, and visibility into how well (or how poorly) instances of the process ran in the past is crucial. Without this information you can't really hope to improve the process in the future.
Process history interfaces are essentially reports - and it's should come as no surprise that you may need to produce many reports for each type of process. These reports are usually cumulative - What were the average execution times for the process? Once norms have been established, then seek out the "unusual" process runs and try to figure out why those instances were outside the norm.
Given the nature of reporting, count on generating a lot of process history interfaces for a lot of audiences. It's really hard to anticipate all of the reports the business may want, but start with the most obvious and insure that you're capturing all the data that's necessary to generate those reports.
If you're stumped on what "the most obvious reports" are for a process, then start by considering what you need to "remember" from the Process Status and Participant Workload interfaces that I described. If a supervisor ever has to intercede in a specific process - by reassigning tasks or initiating an escalation procedure - then you probably need to remember "why" they needed to intercede. As the saying goes, "Those who forget the past are doomed to repeat it".
Business Process Interface Snippets
Perhaps I've left out some aspect of Human Interface that your Business Process will need - but I think you will find that most of the interfaces that you need will fall into one of the categories that I've described. Thoughtfully consider the interface functionality that you really need, and I think that you will find it a lot easier to build out your user interfaces.
My final offering is this: Don't confuse the human interfaces that I have described with specific screens.
Many of the human interface aspects that I have described will routinely be combined together on a single screen, or you will find a need to incorporate an aspect of a Business Process on an existing screen.
Consider building out each "aspect" of your Business Process Interface as a "snippet" or "panel", and you'll find it much easier to tailor your interfaces for each of the audiences that you need to serve.
No comments:
Post a Comment