When you start implementing a managed business process, your first focus is probably on the definition of the process itself - What activities need to be performed to complete the process?
Once you've defined the activities, then your focus will probably turn to the information that the process deals with - What information is needed to perform each activity, and what information is gathered or transformed by each activity?
Assuming that you've gotten this far, your focus will now probably turn to building the user interfaces for the activities in the process that will be performed by people - the human tasks.
Over the years, my colleagues (from IBM and Lombardi) and I have evolved a process for building Task Focused User Interfaces that we've found to be quite successful. It's a simple process that may seem like common sense to many, but it's worthwhile to follow this process. It will help you focus on addressing the right things first - and help you to get your managed business process deployed as quickly as possible.
Here's a "Discovery Map" diagram of our process for implementing Task Focused UIs:
A typical business process contains many human activities - that's very important to keep in mind at all times. You have to build a functional task UI for every human activity in the process before you're done. If you get tunnel vision and focus in on making a single human task as "perfect" as it can be, then you'll delay the initial roll-out of your solution.
With this in mind, you'll see the logic of the process that we've adopted:
Here are some closely related postings for those of you who may want to delve deeper:
Once you've defined the activities, then your focus will probably turn to the information that the process deals with - What information is needed to perform each activity, and what information is gathered or transformed by each activity?
Assuming that you've gotten this far, your focus will now probably turn to building the user interfaces for the activities in the process that will be performed by people - the human tasks.
Over the years, my colleagues (from IBM and Lombardi) and I have evolved a process for building Task Focused User Interfaces that we've found to be quite successful. It's a simple process that may seem like common sense to many, but it's worthwhile to follow this process. It will help you focus on addressing the right things first - and help you to get your managed business process deployed as quickly as possible.
Here's a "Discovery Map" diagram of our process for implementing Task Focused UIs:
A typical business process contains many human activities - that's very important to keep in mind at all times. You have to build a functional task UI for every human activity in the process before you're done. If you get tunnel vision and focus in on making a single human task as "perfect" as it can be, then you'll delay the initial roll-out of your solution.
With this in mind, you'll see the logic of the process that we've adopted:
- Build "Just Enough" human interface to give you the ability to "step through" this activity and all of the paths of your process
- Define "Just Enough" of your interfaces to underlying integrations to give your integration developers the information that they need to start building the "real" integrations
- Get a fully functional task UI working as soon as your "real" integrations are ready
- After everything is functional, then (and only then) work on making the task UI "pretty"
On that last point (step 4) - remember that "everything functional" goes beyond a specific human task - All the human tasks should be functional before you worry about making any of them pretty.
The real driving point (and the factor that makes this process successful) is constantly building "just enough" to let the other members of your implementation team start working on their tasks. You won't be able to step through all of the paths of the process until you have "just enough" UI to do so. Your integration developers won't be able to start until they know the interfaces that your tasks will require. Your functional testers can't sign off on the process until all of the tasks in the process are functional.
Common sense... but often we lose our senses in the heat of battle, so it's best to have a process definition to fall back on.
Here are some closely related postings for those of you who may want to delve deeper:
No comments:
Post a Comment