The Other Side of the Business Process

Many web-based applications are designed around the idea of automating a business process. This simply means using the web, databases, e-mail, and workflow engines to make something happen in a way that is more efficient or more convenient.

Designing such an application usually includes an analysis of the business process. This can produce a variety of guideline documents to aid the programmer, such as state diagrams, flowcharts, entity relationship tables, or perhaps even a complete program specification. This analysis is often done by someone with a programming or systems analysis background, a technical person to translate business needs into a simplified model leading to a technical solution.

But in doing this analysis, the personal processes surrounding the business process are often forgotten.

Take for instance a system for online enrollment in classes at a university. Weeks may be spent understanding how to read the database of available classes, determine which are full, allow registration at the correct times, fill class rosters, and generate tuition billing statements. Every facet of the enrollment is tracked on its path through various systems, with careful consideration for each critical step.

But what about the student? What about their process for registration?

Let's look at an oversimplified example. Our rough analysis of the registration system might be something like:

1. Student logs into system.
2. Student searches for available classes.
3. Student enrolls in classes.
4. Student name is added to class rosters.
5. Tuition billing system is updated with number of units.

That's very tidy, but let's look at what might happen from the point of view of the student:

1. Student logs into system.
2. Student searches for available classes.
3. Student enrolls in two classes, but can only get on a wait list for the third.
4. Student checks system daily, but cannot tell how many others are ahead of them on the wait list.
5. Student decides to sacrifice a morning study group to take a different section of the same class.
6. Student tries to enroll in different section, but cannot without dropping themselves from the wait list for the first section.
7. Student enrolls in second section of the class.
8. Student talks to friend who works in department office and discovers that they were first on the original wait list, and would probably have gotten into original section of the class.

Much of this could have been avoided by simply providing the student some idea where they stood in the wait list order, and perhaps offering an e-mail notification if their status changed.

The truth is, most business processes worth automating are fairly complex, involving the routing of requests to be filled, verifying availability, perhaps getting various approvals, updating stock levels, and handling the interfaces of various backend subsystems. To be fair, the analyst often has their hands full just understanding these requirements.

This can mean that consideration for the person (or persons) involved in a process is limited to trying to understand the points at which they are interacting with the application.

Even those focused on the user experience and usability of web applications tend to concentrate their efforts on nothing more than the times when the humans are interacting with the application itself. Most usability tests begin by giving the test subject a task, and end when the task has been completed.

Why is the human process not fully analyzed? The biggest reason is that it is very difficult.

In our registration example above, interviews with students about the registration process would probably have only determined a bit about selection of classes and completion of any forms involved. Observing them at the task of interacting with a prototype application would only have revealed any flaws in the application interface. 

Determining what people will do just isn't easy. First of all, simply asking someone about their process for accomplishing something will usually not yield a very accurate model of their actions. We humans are not very good at reporting our own behavior. Second, we tend to have wide variation in the way we individually handle similar situations. Our personal goals, outlook, and past experiences tend to make us act and think in all sorts of odd ways.

So, how can we do a better job of analyzing the other side of the business process? A good first step is simply embracing the idea that the people side of the process is important, and deserves as much effort and thought as that applied to determining the technical and business relationships.

Once you are committed to the idea that the people process is important, begin your analysis by trying to observe those who will interact with the business process. In particular try to observe them as they accomplish work similar to that to be handled by your application. 

Make sure you include the entire process, beginning well before the actual interaction with any planned application, and ending after the overall process has been completed. For instance, the designers of our registration system outlined above might have learned much by observing a few students through the entire registration process, all the way through the period for late schedule changes. Chances are, their analysis was based mostly on observation of a few students filling out the paper registration form.

It is also worthwhile to examine subtle feedback mechanisms. Look around for the actions someone might take if they are having trouble with a process. In the registration process example, a quick check with department offices might have revealed a large number of students calling to find out their position on a class wait list. One further advantage of this technique is that it can be used to improve an online interaction that has already been developed and deployed. 

It is certainly important to gain a thorough understanding of any business interaction before trying to apply automation through use of the web and other technologies. But the best results are obtained when we remember to fully analyze the human side of the process.

The original work contained throughout this
web site is licensed by Elton Billings under a
Creative Commons Attribution 2.5 License.