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.
Here are some closely related postings for those of you who may want to delve deeper:
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.
Here are some closely related postings for those of you who may want to delve deeper:
7 comments:
Hi John, first of all: Great Post!
I'm right now working in a framework that is basically what are you describing. We are focused on reduce the effort of the developers when they want to create UI for business process (Human Activities inside the business processes). I would like to establish a dialogue with you in order to know what you think about some specific topics around these topics. The project that we are starting is called smart-tasks and the source code (very unstable and uncomplete) can be found in github.com/salaboy/smart-tasks
Please, let me know if you can and want share some thoughts about these topics in more detail.
Greetings!
Best of luck with your efforts - anything that makes it easier to build UIs for process activities will have a huge and positive impact on our ability to manage all of the processes out there that desperately need to be managed.
IBM's making great strides in simplifying the creation of business processes - but as we both know clever startups often lead the way (Case in point, IBM did buy Lombardi).
John,
Not surprising that 80% of the time spent implementing business processes is on the human interface - that number is sort of the rule of thumb for any application that involves and has been accepted as true by the CHI (computer human interaction community) for a while.
Another reason it doesn't surprise me is that BPMS vendors focus much more on the mechanics of the process, then the user - which I think is a mistake. I posted on that subject here:
ActionBase blog - Process Simplicity
Jacob Ukelson - CTO ActionBase
Jacob... just goes to prove that great minds think alike ;-)
Great post John; it nails down the kind of experience we get from real projects.In OutSystems' BPT that was exactly the case. We were used to implement the applications in our platform (with all the benefits of the integrated modeling, deployment, etc) and, when BPM was required we used to integrate with external platforms. The problem is that, as you mention, the interface is one of the most important bits. So we decided that our BPM engine should be really well integrated (you can see a demo of the "Embedded Process Automation").
But that was not enough... A lot of developers wanted to customize that. They are used to build applications the way they want... so they need BPM platforms that behave the way they want, not the way the tool thinks it is better. The advantage of OutSystems' BPT is that the BPM API is so open and you keep your productivity when you need to customize inboxes, showing process history embedded in the LOB application, etc.
The feedback we had is that usability was key. Having full integration between the application and BPM was one of the most important things to boos usability, project acceptance, process "awareness" and really ensured that people followed the process, instead of using the applications ad-hoc
Gonçalo,
Thank you for sharing... Long term, let's hope that all BPM engines expose APIs such as you describe.
I am a huge fan on integrated BPM suites... but the problem with any suite is that aspects of it will not be "best of breed". Being able to choose is a good thing.
Post a Comment