INTRODUCTION
In most companies, managers are under pressure to reduce costs and
improve productivity. In this paper, we give a practitioner's
perspective on some of the challenges of improving workforce
productivity and offer some emerging technical solutions that can be
used to support an activity-centric approach to managing work.
Industrialization of information work
Businesses have made enormous investments in enterprise
applications from vendors such as SAP AG and Siebel, Inc. We begin by
discussing the role of these solutions in enhancing productivity and the
limits of their capabilities.
In a complex business process, each actor performs only some of the
steps, and few people fully understand how the entire process works.
Enterprise applications codify and compartmentalize the steps to guide
users through the task at hand.
Although very expensive to implement, enterprise applications are
commercially successful. They are used by a great number of companies
and are considered to be mission-critical.
We consider processes managed by enterprise applications to be
industrialized when they are formalized enough to achieve consistent
results that are largely independent of the users. An enterprise
application can furthermore achieve economies of scale in a process when
the benefits it delivers increase with the number of employees involved
in the process. (Other important functions of enterprise applications
not directly concerned with employee productivity, such as rapid supply
chain communications, regularity, and compliance, are not considered
here.)
Prescriptive, highly formalized process applications have enjoyed
great success. There are, however, definite limits to this approach. One
immediate problem is how to enable business people to use enterprise
applications. To extend their value beyond a core group of highly
trained users, companies implement self-service user interfaces that
enable employees to quickly accomplish routine information-processing
tasks without intervention by specialists. Many human resource (HR)
processes, such as hiring, promotions, and performance reviews, are
candidates for self-service because they require the participation of
individual employees and the transmission of personal information.
To support the delivery of self-service user interfaces, IBM
enables users of IBM Lotus Notes * to access processes in SAP and other
systems, (1,2) and IBM WebSphere * Portal Server (3) can also integrate
a variety of systems, including SAP and Siebel. Microsoft is now working
with SAP to bring processes into the Microsoft Outlook ** client. (4)
These initiatives show that it is possible to significantly broaden
access to enterprise applications.
Limits on the industrialization of information work
As laudable as these efforts are, profitable use of enterprise
applications for enhancing productivity has its limits. When the cost of
formalizing a process is too high, an alternative approach is needed.
Some of the factors that limit the industrialization of information work
are scale, risk of lock-in, dependency on incumbent systems, and artful
processes. We discuss them in the following subsections.
Scale
Because of the high cost of entry, some companies, especially small
ones, cannot adopt enterprise applications. In an organization of any
size, the cost of implementing a particular process may outweigh the
productivity benefits for the users affected. Thus, at least when
considering productivity goals, the complexity of the process and the
size of the workforce involved need to be considered.
Risk of lock-in
Many companies, regardless of size, choose not to move certain
processes into an enterprise application because of the dangers of
locking in a process determined by a third-party vendor. For example,
rather than use a job-posting module that comes with an enterprise
application, a company might use a more efficient online service, such
as Monster.com, competing on the open market for new employees and
saving costs at the same time. As more compelling online services become
available, this consideration becomes more important. On the other hand,
the need to differentiate an aspect of customer service from that of
competitors may also lead a company to avoid a standard solution and
develop a more custom approach. (5)
Dependency on incumbent systems
Most large organizations have many incumbent legacy systems.
Because some processes depend on legacy systems that are too costly to
replace, the processes cannot be moved into the preferred enterprise
application, even if managers wanted to move them. Furthermore, many
processes cut across IT system boundaries. For example, to bring a newly
hired employee on board can involve such activities as transactions with
the HR system, an account request into the systems administration group,
bookings for education and training, and communication with the hiring
manager. Again, such processes may be too expensive to reimplement.
Artful processes
Aside from the issues of scale, lock-in, and dependency, certain
types of work simply cannot be formalized well enough to safely entrust
to an enterprise application. The goals and methods of some processes
change too quickly over time; for example, the process of designing
high-technology products. In some processes, it is primarily the content
in each process instance--rather than the process itself--that
determines the outcome; for example, a request for proposal (RFP)
process. (6) Most important, many highly specialized processes are
developed or refined locally at the individual or small-team level such
that the process cannot easily be separated from the specific people who
perform it; for example, managing client relationships in professional
services firms. While the framing process may be stable at an abstract
level, the key details are not. They depend on the skills, experience,
and judgment of the primary actors. We denote these kinds of processes
artful in the sense that there is an art to their execution that would
be extremely difficult, if not impossible, to codify in an enterprise
application.
Long tail of business processes?
In certain industries, such as professional services, artful
processes are clearly the norm. (7,8) However, artful work is not always
easy to detect. When enterprise applications were first deployed to
automate the sales process, over-reliance on the formalized aspects of
the process sometimes caused major business failures. With hindsight, no
one disputes that there is an art to selling that cannot be captured in
a process application. More generally, there are many difficulties
associated with accurately modeling business intentions in enterprise
applications. (5) Perhaps more work is artful than is readily apparent.
Indeed, we wonder if there is a long tail of business processes
(Figure 1). In certain statistical distributions, "... a
high-frequency or high-amplitude population is followed by a
low-frequency or low-amplitude population which gradually 'tails
off'. In many cases the infrequent or low-amplitude events--the
long tail--... can cumulatively outnumber or outweigh the initial
portion of the graph, such that in aggregate they comprise the
majority." (9) Were it possible to create a distribution of
business processes ordered by the amount of resources invested in them,
we wonder if the total investment in the many less formalized processes
far outweighs those implemented in enterprise applications. If so, a
renewed focus on enhancing productivity in these kinds of processes is
surely imperative.
[FIGURE 1 OMITTED]
Claims of the existence of a long tail of processes have in fact
been made before, (10,11) although we have not found any published data
to support the claims. This is an important area to address in future
empirical research. Meanwhile, one point of evidence supporting this
view is that enterprise application vendors are actively seeking to make
their systems more accessible to a larger proportion of the employee
base. It suggests that most employees today do not directly interact
with enterprise applications, and it suggests that the processes the
employees are executing are apparently largely unsupported by the
enterprise applications.
Outline of our current research
As artful work is clearly central to many businesses, we propose
that productivity will be increased by supporting and enhancing artful
processes rather than by stripping them down to highly formalized
industrial methods. The focus of our research is to find ways to improve
productivity by enabling the primary actors--regular business people--to
define and continually improve their processes rather than follow a
centrally planned model. We call this shift the democratization of
process. It means creating new decentralized IT architectures that
enable business people to more easily exploit a web of existing and
emerging IT services in their diverse daily activities. In the remainder
of this paper, we present our research into ways of achieving that
result.
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.
4. Lucy asks Debra to search the online service for viable
candidates (i.e., those who have not explicitly applied for the job but
have the necessary skills).
5. Debra searches the online service and sends Lucy e-mails with
viable candidates by detaching the resumes from the online service and
sending them as e-mail attachments.
6. Lucy reviews applicants from the online service (both those who
have applied for the position and those whom Debra found).
7. Lucy forwards the candidates whom she deems viable in an e-mail
to Frank.
8. Frank responds with an e-mail to inform Lucy of the candidates
whom he wishes to pursue and those whom he wishes to reject. He also
includes his initial thoughts on the candidates.
9. Lucy sets up interviews by phone for herself and the candidates.
10. Lucy takes notes during the interviews by phone.
11. Lucy informs Frank of the candidates whom she thinks Frank
should also interview by phone.
12. Frank sends back a list of the candidates whom he would like to
interview by phone.
13. Lucy forwards this list to Debra and asks Debra to set up
interviews by phone for the candidates with Frank.
14. Frank takes notes on the candidates during his interviews by
phone.
[FIGURE 2 OMITTED]
Lucy's pain points
The following impediments to productivity are identified in this
use-case analysis:
* Navigation across system boundaries--To fill a particular
vacancy, Lucy must interact with at least five different systems,
namely: her e-mail, her calendaring system, the job vacancy system, the
application used when new employees come on board, a word processor (for
taking notes), and her phone. There is no simple navigation available to
her that allows her to move items in one system to related items in
another.
When Lucy's calendaring system informs her that her next
meeting is an interview by phone with a potential job candidate, Lucy
needs to quickly locate the candidate's resume, the
candidate's phone number, and the e-mails from Frank pertaining to
the viability of the candidate. All of these documents form a single
logical work task: Determine if this candidate is the best candidate for
the open position. However, the system bounda