Beyond predictable workflows: enhancing productivity in artful business processes.

The widespread use of ad hoc collaboration and personal information management tools to help execute business processes is already documented. (12-17) In the next section, we present two additional user studies that we conducted to learn how business people get their work done. The first study provides a cross-sectional view of a range of changeable and flexible processes in five companies. The second study looks in detail at the interactions involved in the hiring process at a small company and identifies specific "pain points" (impediments to productivity) that need to be addressed. In particular, this study illuminates the pivotal role of the lead actor in this process as an integrator of people and information across organizational and system boundaries. Using anecdotes from customers, we confirm that this is not an isolated pattern, but a common concern in many processes.

In the following section, we examine some important bottom-up forces that shape business processes. We need to understand and embrace these forces in order to design an architecture to enhance artful processes. We examine the increasing role of end users in IT decision making, the importance of ad hoc collaboration tools in artful processes, and the rise of decentralized IT services.

In view of these forces, companies need to redesign and reassemble their business processes in a more flexible way that better reflects the way that people really work. The modern business process touches many IT capabilities, including ad hoc collaboration tools, departmental solutions, enterprise applications, and online services. A walled-garden approach in which all services are contained within one software system is unacceptable. Maximizing choice is important, and centralizing all process definitions in enterprise applications is counter-productive.

However, if process definitions are no longer centralized, what alternative organizing principles can be used to avoid a descent into chaos? An activity-centric approach promises the ability to organize artful work productively while preserving user choice over the services employed. (18-23) The core idea of activity-centric computing is to organize computer-based work in terms of the activities that people are doing rather than in terms of the tools used. We devote a section to presenting some design principles for an activity-centric solution, with particular focus on the need for a decentralized architecture.

There is a long history of attempts to make the computing environment more modular and service-oriented, with the goal of bringing power over service selection closer to the end user. Generally, these attempts have not lived up to expectations. So why is the time right now? Many previous attempts failed because the cost and complexity of the engineering approach proved too great for widespread adoption. However, the recent emergence of sophisticated applications and integration methods on the Web, known collectively as "Web 2.0," (24) shows new promise because the methods are generally simple and have already proven that they can be widely adopted in the decentralized environment of the Web. We identify enabling technologies that will permit users to capture, share, and reuse work practices, and link them to the widest possible range of supporting services while allowing for their decentralized design, development, and deployment. This approach will provide a foundation for more productive work environments that users can incrementally adapt and refine as their needs evolve.

USER STUDIES

In this section, we first summarize a user study aimed at understanding how people who do knowledge work manage their processes. We also present a detailed use-case analysis of the hiring process in a small consulting firm, and we summarize some related customer anecdotes.

Ethnographic study of business processes

In 2003-2004, we conducted user research at five different companies to learn how knowledge workers get their work done. We did an observational study, shadowing people as they did their work and then interviewing them at the end of the session. At least two people from each site were interviewed, and each visit lasted approximately three hours. Participants were all from the Boston area and included IBM customers, non-customers, and business partners. All were knowledge workers and considered to be subject-matter experts in their field.

After observing participants as they did their work, we asked about the processes and procedures they used to get their work done and how they collaborated with others to get work done. We took note of all the checklists, procedures, and flowcharts. Table 1 offers a sample of the processes observed and discussed. Many of these were printed and hanging on a wall or bulletin board, some were handwritten, and all were annotated. The annotations made reference to exceptions, so there were several versions of each checklist to be used under certain conditions.

Some processes were simple, such as how to schedule the monthly meeting or how to buy a book. Others were more complex, such as reporting and tracking adverse events in a clinical trial. We also found that some processes were occurring exclusively by e-mail or instant messaging. Recreating the process or tracking it involved searching and filtering e-mail many different ways to ensure that the latest information was available.

Processes were hard to track, difficult to monitor, and hard to reuse. Some participants felt that each time a new instance was initiated, they had to start over from scratch. They described their processes as idiosyncratic and always under modification. One participant said that his work is always the exception--and that's the rule. Most of the communication was happening asynchronously and was partly paper-based. The workflow modeling tools available were considered too complex for these types of processes and were inaccessible to these knowledge workers.

We also collected artifacts from the study, such as a new employee checklist and a work request form. Several versions of the new employee checklist were posted: one for new hires from the United States and another for non-U.S. citizens. Another version was for people working offsite. This work is described in more detail by Kogan and Muller in this issue. (25) Here we briefly summarize some key findings:

* Collaboration tools are often used for processes involving time management and meeting logistics.

* Use of formal process systems is supplemented with personal information management tools, such as reminders.

* Use of formal process systems is reserved for enterprise-level processes, not personal or department-level work.

* Participants identified a diverse set of business processes, such as design reviews, requests for proposals, and clinical trial protocol development.

* Participants described their work as idiosyncratic and frequently modified--there are always exceptions, and processes need to be flexible to accommodate these conditions.

Use-case analysis for the hiring process in a small company

The following use case was obtained from interviews with an HR employee at a small information services company. We conducted it to examine in detail how the process really works. The names are fictitious.

Overview

Lucy works in the HR department of a small company. Hiring is one of her main responsibilities. The hiring process at her company varies substantially from one case to the next. The level of the position being filled and the current economic conditions affect the approach taken. For example, hiring decisions for lower-band positions can be made within the HR group, while more senior positions involve the candidate preparing and delivering a presentation to senior analysts within the organization. If the company is in a period of growth, managers are automatically allowed to backfill vacated positions, whereas in leaner times, backfilling is subject to approval.

To execute the hiring process, Lucy and her team expend significant manual effort bridging disparate IT systems, including dedicated tools, such as a vacancy-posting system, and ad hoc collaboration tools, such as e-mail and the phone. The pain points experienced in doing this work are localized to the HR team and, in this small company, are largely invisible to the IT department. Even if they were noticed, while it might in theory be possible to run this process as a workflow in an enterprise application, doing so would probably not be cost-effective nor would it fully support the kinds of communication and collaboration required.

The following partial use case describes a portion of the hiring process at Lucy's firm. It starts with the decision to post a vacancy and finishes with the first candidate being screened by phone.

Actors and goals

The following actors participate in this use case:

* Frank, the hiring manager (manager of the group with a vacancy)--Makes the ultimate decision as to whether to hire a candidate

* Lucy, HR hiring specialist--Performs the initial filter of candidates and only forwards to Frank those that she deems appropriate

* Debra, Lucy's assistant--Performs administrative functions for Lucy

* Emma, Lucy's boss

Use case steps

A summary of the use case is given in text form below and visually in Figure 2.

1. Emma informs Lucy that Frank has a vacancy.

2. Lucy and Frank exchange e-mails on the text of the job description and then meet to finalize.

3. Lucy posts the vacancy in the online service with the text from the e-mail.