MIS Quarterly Executive Vol. 10 No. 2 Jun 2011 81© 2011 U.docx

MIS Quarterly Executive Vol. 10 No. 2 / Jun 2011 81© 2011
University of Minnesota
IT-Led Process Reengineering
IT-Led Process reengIneerIng: How
sLoan VaLVe redesIgned ITs new ProducT
deVeLoPmenT Process1
S. Balaji
Bentley University
(U.S.)
C. Ranganathan
University of Illinois at
Chicago (U.S.)
Tom Coleman
Sloan Valve Company
(U.S.)
Executive Summary
Firms across many industries are focusing on product
innovation as a critical source
of competitive advantage. While redesigning their new product
development (NPD)
processes is a top priority for most companies, the need for
faster cycle times and time-
to-market pressures has re-emphasized the critical role of IT
organizations in such
reengineering efforts. Based on the multi-year experiences of

the Sloan Valve Company,
we illustrate how an IT-led initiative successfully reengineered
the company’s NPD
process. We describe key governance and process changes that
Sloan Valve made and
highlight the role of IT capabilities in enabling the process
redesign. From our analysis of
Sloan Valve’s experiences, we provide some valuable lessons
that can be applied by other
companies as they reengineer their critical business processes.
THE NEED TO REENGINEER NEW PRODUCT
DEVELOPMENT PROCESSES
After years of retrenchment and cost-cutting, senior executives
across many industries
are increasingly focusing on the product innovation process—
the ability to define
and create new products and services and quickly bring them to
market—as a critical
source of competitive advantage.2 Faced with intense
competition and rapidly
changing customer preferences, companies are forced to
innovate and introduce new
products and services at an increasing pace.3 In fact, Gartner
Group predicts that
creation of new products and services will be ranked as the top
senior management
priority by 2012.
Over the past two decades, organizations have developed their
own new product
development (NPD) processes and the associated IT support
systems, based on
traditional approaches to timelines, design reviews, and
multiple levels of decision-
making hierarchies. The commonly followed approach to NPD

is to use six-sigma
DMAIC (Define, Measure, Analyze, Improve, and Control)4
procedures, along with
best practices in an ERP system.5 These home-grown processes
have largely focused
on tweaking existing NPD activities using six-sigma techniques
and other continuous
improvement methodologies.
While these traditional approaches to NPD worked in the past,
they are unable to
meet today’s need for a tightly integrated NPD process. NPD
typically spans multiple
departments, involving processes that have strong cross-
functional interdependencies.
Continuous improvement methodologies—while suitable for
incrementally improving
silo-processes—are ineffective for addressing cross-functional,
end-to-end NPD
1 Jeanne Ross is the accepting senior editor for this article.
2 Bonabeau, E., Bodick, N., and Armstrong, R. W. “A More
Rational Approach to New-Product Development,”
Harvard Business Review (86:3), 2008, pp. 96-102.
3 Chandy, R. and Tellis, G. J. “The Incumbent’s Curse?
Incumbency, Size and Radical Product Innovation,”
Journal of Marketing (64:3), 2000, pp. 1-17.
4 McCarty, T., Daniels, L., Bremer, M., and Gupta, P. The Six
Sigma Black Belt Handbook, 2005, The
McGraw-Hill Companies Inc., New York.
5 Hammer, M. “Process Management and the Future of Six
Sigma,” Sloan Management Review, (43:2), 2002,
pp. 26-32.
MISQE is
Sponsored by

82 MIS Quarterly Executive Vol. 10 No. 2 / Jun 2011 © 2011
Balaji et al. / IT-Led Process Reengineering
processes. Moreover, faster cycle times, time-to-
market pressures, and the need for rapid innovative
solutions demand that a company must not just tweak
but reengineer its NPD process. Senior management
has realized that radical innovations in NPD can
be ably fostered and executed only by using IT
solutions. Companies are waking up to the reality that
technological advances and superior collaborative
capabilities have placed IT at the forefront of NPD
processes.6 They need to exploit and deploy IT in
clever ways to raise product development processes to
a higher level. As a result, CIOs are increasingly being
asked to oversee and facilitate innovation efforts,
including new product development.
Although many companies have failed in this
endeavor, some have been successful in IT-led
reengineering of their NPD processes. In this article,
we describe the successful NPD reengineering
experiences of one such company—the Sloan Valve
Company, a leading manufacturer of plumbing
products. Through in-depth interviews with top
executives, study of internal reports and white papers,
secondary data reports, presentations, and direct
observations over a period of three years (2007-
2009), we identified several IT-led change initiatives
that make Sloan Valve’s effort a compelling case
study. Our specific focus is on the reengineering of

the NPD process, which was carried out as part of
an ongoing enterprise process redesign program. Our
research findings from this case study have important
implications for companies facing a variety of process
reengineering challenges, including changing the role
of IT from being a support function to one that drives
business innovation initiatives.
RECOGNIZING THE ROLE
OF IT IN OVERCOMING NPD
CHALLENGES
New product development is a complex activity that
involves conceptualizing, designing, producing,
and introducing a new product to the market. The
process begins by collecting ideas for new products
from multiple sources followed by a thorough review
of the business cases for the products and creating
prototypes. Viable prototypes are further reviewed,
with some progressing to successful final products.
6 Cash, J., Earl, M. and Morison, R. “Teaming Up to Crack
Innovation and Enterprise Integration,” Harvard Business
Review
(86:11), 2008, pp. 90-100.
Companies typically face three major challenges in
their NPD. The first is the number of departments
involved in the NPD process.7 Inputs may be required
from the manufacturing, engineering, marketing, sales
and distribution, and design departments, and from
business units such as finance, purchasing, and project
management. This raises complex coordination issues
among the various departments, which delays the
time to market. Such delays can drastically affect the
competitiveness of the company.

Second, managing the idea-generation process is a
critical bottleneck in the NPD process.8 Choosing
the group responsible for idea generation, capturing
and managing diverse ideas, and tracking the status
of each idea is problematic for many companies.
Communication gaps could result in huge delays or
even in potential product ideas being abandoned.
Resources can also be wasted on prototyping
unwanted products.
The third major challenge is process accountability.
Traditionally, each functional department is
responsible only for its own set of activities in the
NPD process. Given the cross-functional nature of the
NPD process, there is no one department or individual
who is held accountable for all issues, resulting in
confusion about process ownership.
NPD reengineering addresses these challenges by
radically overhauling the NPD process to generate
greater business value for the firm. It involves
revamping non-viable and less-optimal processes
and unifying disparate, siloed processes into a single,
integrated NPD process. While companies perceive
NPD reengineering as an important business strategy,
they also widely recognize the prominent role of IT
in bringing about the process change. IT capabilities
are one of the fundamental drivers that promote
a firm’s business agility and product innovation,
leading to distinctive competitive advantages.9 The
IT department can also help break the functional
mindset and play a complementary role in enabling
7 Majchrzak, A. “Breaking the Functional Mind-Set: The Role
of Information Technology,” in Grover V. and Markus, M. L.
(eds.)

Business Process Transformation, 2007, M. E. Sharpe, Inc., pp.
125-
139.
8 Massey, A. P., Montoya-Weiss, M. M. and O’Driscoll, T. M.
“Transforming the New Product Development Process:
Leveraging and
Managing Knowledge,” in Grover V. and Markus, M. L. (eds.),
2007,
M.E. Sharpe, Inc., pp. 185-206.
9 Pavlou, P. A. and El Sawy, O. “From IT competence to
competitive
advantage in turbulent environments: The case of new product
development,” Information Systems Research (17:2), 2006, pp.
198-
227.
© 2011 University of Minnesota MIS Quarterly Executive Vol.
10 No. 2 / Jun 2011 83
reengineering.10 The Sloan Valve case illustrates this
critical role of IT capabilities in NPD reengineering.
As companies realize the gains from transforming
their NPD strategies and processes through IT
capabilities, they can apply the valuable lessons
learned from Sloan Valve on how best to use IT
resources and capabilities to achieve IT-led process
reengineering.
REENGINEERING SLOAN
VALVE’S NPD PROCESS
Founded in 1906, Sloan Valve is a mid-sized
manufacturer of plumbing products with headquarters

at Franklin Park, IL. In 2010, the company had over
1,000 employees with revenues under $1 billion.
A family business, Sloan is organized into multiple
business divisions and design sites in various locations
around the world.11 The IT department employs less
than 50 full-time staff, with very little IT operations
and activities outsourced.
Sloan Valve’s product line includes faucets,
flushometers, shower heads, and sinks. The company
is a pioneer in water-efficient technology-based
products, with customers in various industries (e.g.,
petroleum, chemical, utility, residential housing)
and large establishments (e.g., airports, hospitals,
educational institutions). Most of its products are
made-to-stock or configure-to-order. However, there
are some special made-to-order products that are sold
through distributors around the world.
NPD is a core process at Sloan Valve, because it
strives to launch a range of new products every year.
The company’s mission statement emphasizes the
importance of NPD:
“To effect a quantum improvement in the
Company’s ability to develop, manufacture,
market, and distribute breakthrough products
and services. These offerings will leap-frog the
competition and help ensure the Company’s
continued prosperity.”
10 See Majchrzak, A., op. cit., 2007; and Fichman, R. G. and
Nambisan, S. “Deriving Business Value from IT Applications
in Product Development: A Complementarities-Based Model,”
Information Technology and Product Development, Chapter 2,
Satish

Nambisan (ed.), Annals of Information Systems Series, Vol. 5,
New
York: Springer Inc., 2010, pp. 19-47.
11 Sloan Valve Water Technologies (Suzhou, China), Arichell
Technologies (West Newton, Massachusetts), Sloan de Mexico
(Ramos
Arizpe, Mexico), Sloan Flushmate (New Hudson, MI), Sloan
Plumbing
Division (Franklin Park, IL, Redondo Beach, CA.,
Mechanicsburg,
PA).
Problems with the Old NPD Process
Sloan Valve’s reputation depends on establishing a
robust and mature NPD process that drives a culture
of innovation. But the company faced a series of
challenges in its old NPD process (see Table 1),
which spanned 16 functional units. The old process
included marketing and sales for processing ideas,
and manufacturing and production for delivering
the products. Other departments, such as design
engineering, were also involved in ensuring the
product design complied with specified standards.
Most of the products involved electronics, so electrical
engineers had to be involved in NPD, and the finance
department had to keep tabs on the cost.
Table 1: Key NPD Challenges Faced by
Sloan Valve
1. Over 16 functional units involved
Complex coordination
Slow time to market (18–24 months)
2. Immature process for initiating and screening
new product ideas

High idea attrition rate (over 50%)
Poor idea acquisition
Huge prototyping costs, resulting in
considerable wastage of resources
3. Lack of process ownership
No accountability or dedicated responsibility for
NPD
Because 16 functional units were involved, the time-
to-market was a slow 18–24 months. The process
for initiating and screening new product ideas was
ad hoc, leading to about half the ideas eventually
being dropped. Sometimes, the dropped ideas had
been prototyped, resulting in unnecessary costs
and subsequent wastage. In addition, there was no
single person or department responsible for the NPD
process, underscoring a significant challenge with
accountability. These challenges prevented Sloan
Valve from delivering quality new products.
The Beginnings of Transformation
Prior to 1998, the divisions used Sloan Valve’s
internal network to transfer information among them.
The company believed that investing in an ERP
system would solve some of its communication and
coordination challenges because it would not only
provide a common database but also replace multiple
legacy applications. Sloan Valve chose SAP and
spent about 11 months implementing the ERP system.
However, Sloan did not realize any significant returns

from its ERP investment. Several bottlenecks were
encountered in the ERP system, and when one was
rectified, the problem shifted to other areas. The lack
of satisfactory results had senior management worried:
“The ERP system very vaguely supported
the business as it existed. It was not crafted
to support any new business process that
we wanted, especially in new product
development.” (CEO)
The troublesome ERP implementation caused top
management to decide that the IT function needed a
new direction, and a new CIO was hired in early 2000.
Among his responsibilities were to not only resolve
the ERP problems but also to set a new agenda for
the IT function, by integrating the IT function with
responsibility for business processes.
The CIO soon realized that the ERP system was
functioning as specified. Instead, the problems were
actually with the processes surrounding the ERP
system. As is common in many firms, Sloan Valve had
tweaked the ERP system to fit the existing processes;
as a result, the system did not provide the anticipated
benefits. So the CIO turned to fixing the business
processes and set about overhauling them through
process reengineering.
“At the time, the company had many folks
reporting directly [to the CEO] from multiple
silos. I immediately started talking about how
we had to look at cross-functional business

processes as a way to get value from the ERP
system.” (CIO)
The CIO was a strong advocate of process
reengineering, but another senior executive preferred
an incremental approach to changing the processes.
He envisioned a continuous improvement approach
where incremental improvements are made to a
particular process until it became perfect.
“This senior executive wanted to tweak
the process and believed that would equal
reengineering over time. [However,]
‘improvement’ is different from ‘redesign.’”
(CIO)
Top management accepted this senior executive’s
plans and decided to improve the outbound logistics
process as a trial, using the continuous improvement
approach. After seven months, the results were
far from what had been expected. The reason was
simple: as parts of a process become enmeshed in
a network of processes, multi-level dependencies
manifest themselves. Improving just one process
in isolation would never solve the problem. Top
management now realized there was a clear need to
completely reengineer the enmeshed processes. It was
also essential to integrate disparate activities across
multiple departments, through a common IT platform.
Enabling Reengineering by Appointing
the CIO as Chief Process Officer
Integrating multiple departments and processes
through a common IT platform was easier said than
done. The conventional mindset at Sloan Valve

was to view IT as a support function for individual
departments, which led to strong boundaries between
IT and other functions. Realizing the perils of
these boundaries, top management gave the CIO
the additional role of Chief Process Officer (CPO),
making him responsible for overseeing process
changes across the entire organization. In 2004, the
CEO announced the amalgamation of the IT and
process roles under the singular leadership of the CIO/
CPO.
“It was a clear signal from top management.
The CIO is typically seen as a person in-
charge of technology. By combining the CIO
and CPO roles, management sent a clear
message that the CIO would from now on lead
as a business executive and take on the role of
a business leader as well.” (Business Process
Management [BPM] Manager)
The CIO/CPO initiated a series of measures to
champion process changes across the enterprise,
with NPD as one of the first large-scale processes
to be redesigned. One immediate initiative was to
encourage senior managers to attend formal business
process reengineering (BPR) training courses. After
attending a BPR training camp led by Michael
Hammer (a recognized BPR guru), the owners of the
organization were convinced of the potential of BPR
and had the entire senior management team attend
the training. Over a period of time, all the senior
and middle managers, IT business analysts, and IT
program managers underwent formal training in BPR,
which helped develop a process-oriented mindset in
the organization.

As in any major organizational change initiative,
a few executives at Sloan Valve resisted the
reengineering effort. Senior management, along with
the CIO/CPO, worked directly with these executives
to educate them and gain their commitment. Despite
their best efforts, a few remained reluctant and even
opposed the plans. Some of these left the company,
and others were moved into different functions. The
10 No. 2 / Jun 2011 85
CIO/CPO and the senior management now embarked
on a set of sweeping changes at Sloan Valve.
Governance Structure for Process
Redesign
Sloan Valve embraced the process redesign initiative
by implementing a two-level governance structure.
The strategic-level structure oversaw all of the process
redesign efforts across the entire organization, while
the process-level structure focused on individual
processes (see Table 2).
The CIO/CPO brought key members from different
functional departments together to create the strategic-
level governance structure. Both IT and business
executives were part of this governance level, to
enable better communication and coordination across
the entire organization. The CEO led the strategic-
level governance structure. The process council
comprised the company’s president and senior vice

presidents from different units. They had the ultimate
authority for driving the reengineering efforts,
allocating resources, assessing key performance
metrics, and approving all the organizational changes.
The CIO/CPO took on the role of architect and
visionary for the process initiatives. His role was to
raise awareness in the organization about process
initiatives, present the business cases for modifying
processes, and ultimately set forth the agenda for
implementing the changes. An IT manager with
considerable knowledge of business functions was
assigned as BPM manager. Together with the CIO/
CPO, the BPM manager coordinated with the process
council to implement the envisioned business process
changes.
At the process level, there were three structural
components for governing the redesign and
implementation of changes to specific business
processes. First, for each process, a process owner
was identified to execute the redesign and to oversee
the change effort. Second, a cross-functional process
redesign team, led by the BPM manager, was
responsible for reviewing and redesigning the various
processes. This team had members from multiple
departments related to the specific process and also
had an IT-business analyst. Third, the sustaining
improvement team was responsible for analyzing
the redesigned process and examining key metrics to
determine opportunities for continuous improvement
after the process had been reengineered. Some of the
members from the process redesign team were also
members of the sustaining improvement team. This
team was charged with designing creative solutions
to fix and prevent problems in the process, while

ensuring the process improvements stayed on track.
The CPO/CIO and the BPM manager developed a
home-grown method for process reengineering by
combining and adapting techniques from multiple
reengineering frameworks, such as DMADV (Define,
Measure, Analyze, Design, Verify),12 to suit Sloan
Valve’s context. This method was further refined and
ratified by the process council. The company also
employed continuous improvement techniques for
post-BPR process improvement. Once a process has
been redesigned, it can be further improved through
continuously tweaking it.
Redesigning the NPD Process
Given the strategic importance of NPD at Sloan Valve,
it was only natural that senior management and the
process council identified the NPD process as one of
the initial areas for implementing BPR. The Director
12 McCarty, T., Daniels, L., Bremer, M., and Gupta, P. The Six
Sigma
Black Belt Handbook, New York: The McGraw-Hill Companies
Inc.,
2005.
Table 2: Strategic-level and Process-level Governance Structure
Strategic-level Governance Structure Process Governance
Structure
• CEO: Leads and motivates the redesign effort and
sets overall expectations
• Process Council: Governing body responsible for
driving the redesign efforts

• CIO/CPO: Acts as architect and visionary
for redesign; guides steps for reengineering;
responsible for scheduling efforts
• BPM Manager: Leads process redesign team;
oversees and coordinates multiple BPR projects;
liaises with functional units
• Process Owner: Executes process redesign;
provides oversight for the process changes
• Process Redesign Team: Cross-functional team
assigned to assess and redesign existing processes
• Sustaining Improvement Team: Cross-functional
team assigned to tweak a process using continuous
improvement techniques
of Design Engineering was made the process owner.
The NPD process redesign team, led by the BPM
manager, had members from the manufacturing,
design engineering, IT, finance, marketing,
operations, and quality assurance departments. One
of the company owners also participated in this
team, signaling the importance of the NPD process
reengineering initiative. The team also included a
business analyst from the IT department.
The NPD process redesign team spent about nine

months assessing the current process, mapping
sub-processes and associated activities, identifying
bottlenecks and documenting interdependencies, and
proposing a new end-to-end NPD process. To map the
current process, the team used a process visualization
tool to depict and assess the process. This tool
visually depicted the processes and the process flows
among the 16 business functions involved in the
old NPD process. The process map also acted as a
communication tool to educate management and other
organizational members about the complexities and
deficiencies of the old process.
During the initial stages of redesigning the NPD
process, some managers were still skeptical about the
“end-to-end process thinking” approach. Although
buoyed by the prospect of radical process changes,
they still found it hard to understand how exactly the
changes would work and what the new process would
look like. Years of silo-based thinking posed a huge
barrier, and a drastic shift from the silo-mindset to
end-to-end process thinking was needed.
The NPD process redesign team relied on the process
visualization tool to achieve this shift. The iGrafx
software that was utilized allows users to model
processes in real time and drill down to the sub-
process level on the fly and also centrally manages
diagram files. By using a technique called “process
decomposition,” the team decomposed the NPD
process into sub-processes to visually represent the as-
is state and the to-be state of the process. They then
made a presentation to top management.
“This technique typically shocks senior
management in terms of how the company

actually runs.”13 (CIO/CPO)
“When the to-be diagram goes up, I take
the printed as-is diagram [which shows 16
functional units] off the wall and tear it up in
front of everybody. At that point, the change
13 iGrafx Sloan Case Study, 2007, available at
http://www.igrafx.
com/resources/casestudies/index.html.
process is universally understood.” (BPM
Manager)
By cleverly exploiting a simple process visualization
tool, the process redesign team not only mapped the
current state of the NPD process but also used it as the
basis of its “sales pitch” to management to shift to the
end-to-end process.
“When we put those big diagrams up on the
wall, it’s really the first glimpse most people
have of a process in action. The diagrams
become a central rallying point that focuses
us on customer results rather than functional
departments.” (BPM Manager)
To measure the results from reengineering the NPD
process, several key performance indicators (KPIs)
were identified.14 Important metrics such as time-
to-market and innovation rate were decided by the
process council, while others were developed by the
NPD process redesign team. Some of the critical KPIs
were:
• Time-to-market: The time taken from idea

creation to launch of new products
• Innovation rate: Revenue generated from new
products (less than three years old) compared
to total revenue
• Total new products: Number of new products
developed per year
• Portfolio metrics: Set of metrics that capture
the usage of cross-functional teams and
resources across all new product development
projects.
The NPD process redesign team also used a
combination of strategy maps and balanced scorecards
to align strategy with process metrics. These maps and
scorecards translated a strategic plan into quantifiable
targets for the NPD process. By establishing a clear
line-of-sight from the evolution of strategy to the
corresponding metrics, each strategic plan could be
cross-tabulated from the top down and bottom up.
The strategy maps and balanced scorecards also
provided a clear picture of the existing blocks in the
process. In fact, during strategy meetings, the different
stakeholders could see how each strategic initiative
and process metric corresponded with and impacted
one another.
14 Hammer, M. “The Process Audit,” Harvard Business Review
(85:4), 2007, pp. 111-143.
10 No. 2 / Jun 2011 87

Upgrading the ERP System
As a part of its NPD reengineering efforts, Sloan
Valve sought to better exploit the capabilities of
its ERP system, which until then had yielded poor
returns. The CIO/CPO decided to upgrade the system
to MySAP business suite, with customer relationship
management, supply chain management, and product
lifecycle management (PLM) components. To support
the NPD redesign initiative, the basic components of
the PLM module were put in place in early 2006, with
additional components added in 2007.
However, upgrading the ERP system was not
without challenges. A fundamental challenge was
to implement the changes concurrently with the
process redesign efforts. Since the NPD process
was continually being redesigned, the IT team was
faced with an uphill task of continually customizing
the PLM module. Moreover, as with any ERP
implementation, Sloan Valve faced significant change
management problems. The IT team needed to educate
lower-level employees about the potential of the new
PLM module and gain their support. Employees had
to be trained to use different components of the PLM
module, such as concurrent manufacturing, design for
manufacturability, and quality function deployment.
“The major issues we faced with NPD (and
other process efforts) were leadership,
change management, and slow organizational
changes needed to make process work ‘sing.’
The technology issues are challenging but

not nearly as difficult as the human side of
change.” (CIO/CPO)
The Reengineered NPD Process
The NPD process redesign team proposed a set of six
key sub-processes as shown in Figure 1. The process
was overhauled into an end-to-end process, with each
sub-process representing a logical set of activities:
• Ideation: Create and develop new product
ideas and perform feasibility assessment
• Business case development: Conduct market
analysis and analyze resource needs for the
product
• Project portfolio management: Prioritize and
rank projects that maximize business value and
maintain optimal mix of company resources
• Product development: Develop the prototype
and design for the manufacturing process
• Product and process validation: Validate
pilot manufacturing and testing, perform
manufacturing process validation
• Launch: Release product and conduct post-
launch activities.
Employees from individual departments were
reassigned from individual departmental units to one
of the sub-processes, and their incentive structures
were aligned with their new roles. For instance,
employees assigned to the Ideation sub-process dealt

Figure 1: Sloan Valve’s Redesigned NPD Process Comprises
Six Sub-processes
with the “fuzzy front end”—generating, capturing, and
filtering ideas.
For each new product idea, a cross-functional team
(also called a Tiger Team) was created with members
from manufacturing, design, marketing and sales,
engineering, production, and quality assurance units.
The team members’ mixed skill sets and functional
roles helped gather varied perspectives on a product
idea. The company also invested in training the Tiger
Teams to coordinate their activities and to adjust to
the new role. For team members, working toward a
common goal of delivering a new product contrasted
sharply with their earlier silo goals of serving
individual departments.
A program management office (PMO) was established
to coordinate the product initiatives that were in the
NPD cycle. The purpose of this office was to review
the number of new products in the pipeline and assign
appropriate human and technological resources to the
projects. In addition, the PMO prioritized projects and
took care of additional resource assignments. It also
coordinated with other teams in Sloan Valve’s global
development centers.

“Our largest design site has mostly mechanical
engineers, a few electrical engineers, and
some laboratory technicians. We have cross-
functional co-located teams. There are some
manufacturing and purchasing people up there
to support that group. We also have project
managers and engineering directors to lead
the team and act as stage-gates.” (VP, Product
Development)
In implementing the reengineered NPD process,
Sloan Valve adopted two distinct process management
mechanisms:
1. The stage-gate methodology to provide
necessary controls at the end of each NPD sub-
process
2. The funnel approach to filter out less
promising ideas before they reached the
expensive prototyping stage.
1. Stage-gate Methodology. Sloan used the stage-
gate15 approach as a mechanism to assess the outputs
from each of the six NPD sub-processes. The gates
were the checkpoints between each NPD stage, where
15 Cooper, R. G. and Edgett, S. J. “Stage Gate and the Critical
Success Factors for New Product Development,” 2006, BP
Trends,
Product Development Institute. Available at
http://www.bptrends.
com/publicationfiles/07-06-ART-Stage-GateForProductDev-
Cooper-
Edgett1.pdf.

the process council met and reviewed the outcomes.
Through the stage-gate model, Sloan effectively
established the hierarchical structural overlay
necessary for NPD process coordination.
“There are six stages in the NPD process, and
each stage has a stage contract. Each gate
signs off on the particular stage contract, and
these documents are maintained in a central
repository.” (VP, Product Development)
2. Funnel Approach. The funnel approach
complemented the stage-gate methodology. It
mimicked the best practice implementation of the
NPD process adopted by other successful companies.
This approach conceptually split the NPD process
into front-end and back-end activities so that all ideas
passed through and were filtered in these two parts.
The front-end activities belonged to the marketing and
sales domains, whereas the back-end activities were in
the product development domain.
The front-end filtering ensured that only appropriate
ideas for new products were identified and put forward
to the cross-functional team for further discussion.
The ideas were further reviewed by a panel of top
executives to ensure that they were aligned with
the company’s vision and strategy. Business cases
were then developed to identify projected revenues
from the products. Next, during the project portfolio
management sub-process, priorities were set for the
various projects, and resources were allocated. The
three back-end sub-processes then developed and
launched the products. Prior to reengineering the NPD
process, many ideas fell by the wayside after they
had been prototyped. Now, only the best ideas are

taken forward to prototyping, with most proceeding
to product development, validation of the product, and
product launch.
Executive Oversight of the
Reengineered NPD Process
The redesigned NPD process was accompanied by
changes to executive oversight of the process and IT
capabilities at Sloan Valve. Sensing an imminent need
for a senior executive to lead product development
in 2008, top management decided to create a new
role of Vice President, Product Development. The
VP hired was also assigned the role of Executive
Process Owner (EPO) for the NPD process. The
EPO had the ultimate responsibility for the new end-
to-end NPD process, with primary accountability to
achieve the NPD goals. The functional heads of the
16 units that carried out different NPD activities were
brought under the new EPO. The EPO also focused
10 No. 2 / Jun 2011 89
on communicating the NPD process outcomes to top
management. The business process owner (who was
part of the NPD process redesign team) worked under
the EPO to oversee the NPD process activities.
Technology Capabilities Underpinning
the New Process
Since Sloan Valve’s NPD challenges started with the
failure to deliver the expected benefits from the ERP

implementation, the CIO/CPO was keen to develop
strong IT capabilities at Sloan. His efforts resulted
in the exploitation of two important technologies for
NPD—the implementation of a new “Ideation Portal”
and the effective use of the PLM module in the ERP
system.
1. Ideation Portal. Sloan Valve’s Ideation Portal is
an intranet platform deployed to manage new product
ideas until they are commercially launched. Prior
to implementing this portal, ideas were managed
in a haphazard manner. New ideas were passed on
as documents to senior management, with no way
of tracking their progress as they moved through
multiple stages. However, after the launch of the
portal, any stakeholder—internal employee or external
stakeholders (suppliers, customers)—could directly
input a new product idea, with its associated details
and potential impact on the marketplace.
The Ideation Portal was principally designed to
keep track of new product ideas progressing through
the NPD sub-processes (market study, feasibility
assessment, business case, prototyping, launch, etc.).
The portal therefore supported the funnel approach
to NPD. It enabled multiple business units to use a
single platform to discuss, collaborate, and exchange
viewpoints and knowledge on new product ideas.
Moreover, the portal also helped Sloan Valve connect
with external stakeholders, such as suppliers and
customer groups that provided key inputs on new
product ideas.
“The market research is all done by the front
end. It’s a huge change from what we used to
do before! We are now getting a better match

of resources and products in the pipeline.”
(CIO/CPO)
The Ideation Portal helped Sloan Valve shift its NPD
focus from managing individual ideas to managing a
portfolio of NPD projects. Post-BPR, it became easier
to track the status of each product idea and compute
its ROI. The portal tied in closely with the end-to-end
process thinking approach, as key stakeholders could
contribute to and work on an idea, and obtain all the
details about it, in a single snapshot.
2. PLM Module. The PLM module, which faced
some challenges during the NPD process redesign
effort, now formed the backbone of the new NPD
process. The module was effectively used to support
each of the six sub-processes (as shown in Figure 1
above). At the strategic level, the PLM module acted
as an executive information system, assimilating all
details about the functioning of the NPD process. It
provided a dashboard capability to the top executives,
with tracking capabilities for defining and capturing
the KPIs. Further, it also supported the balanced
scorecards, with its integration with other ERP
modules and Excel.
At the process level, the PLM module enabled the
NPD process owner to keep track of the NPD targets
and to look at the efficiencies in the NPD process. If
one or more of the stages were lagging behind, the
PLM module could be used to understand the process
deficiencies at that stage. It enabled the PMO to track
and allocate resources for each new product idea. It
also supported the stage-gate methodology, as all the
stage contracts were stored in a centralized system.

“We have a central repository [in the PLM
system] called ‘cFolders’ for managing files.
The ideas and the other documents related
to ideas, such as business cases, reports, and
other documents, are available through a
single system. People can see this anywhere
in the world as long as you’re connected
to the Sloan network. This is important for
collaboration around the world.” (VP, Product
Development)
The PLM module also enabled the cross-functional
team to coordinate with each other, improving overall
NPD effectiveness.16 Before this module, product
descriptions and other documents were managed on
individual computers. The implementation of the PLM
module created a centralized repository for storing
documents, reports, design templates, and other files.
The module also integrated with the Ideation Portal,
to map the ideas and the corresponding documents.
As the system was web enabled, the stored documents
were accessible from any location across the globe.
Further, computer-aided design (CAD)/computer-
aided manufacturing (CAM) systems were also
integrated with the PLM module, improving the
16 Chen, C. “Information Technology, Organizational Structure,
and
New Product Development: The Mediating Effect of Cross-
Functional
Team Interaction,” IEEE Transactions on Engineering
Management
(54:4), 2007, pp. 687-698.

coordination of the design and prototyping sub-
processes. Together with the Ideation Portal, the PLM
Module significantly improved Sloan Valve’s NPD
redesign efforts.
BENEFITS FROM THE
REENGINEERED NPD PROCESS
Table 3 compares the old and reengineered NPD
processes. Time-to-market was reduced from 18–24
months to less than 12 months. After the redesign,
customer feedback was easily available via the
system. The reengineered process also filtered out
early the ideas for new products that were unlikely
to succeed. This ensured that ideas that proceeded
to the prototyping stage had a better chance of
moving to market, thus yielding better ROI. The
quality, timing, and synthesis of product and process
information throughout the NPD cycle also improved.
Notably, there was increased accountability for the
NPD process. This also resulted in a better match of
projects and IT resources, and avoided having an
excess of projects in the pipeline.
LESSONS FROM THE SLOAN
VALVE CASE
Reengineering any critical business process is
challenging for firms entrenched in traditional ways
of performing business. Gaining acceptance to the
idea, obtaining buy-in from top management and other

leaders, and finding a champion could be difficult to
accomplish for such companies. However, the Sloan
Valve experience shows that by developing key IT
capabilities and through effective IT leadership, even
mid-sized companies can rapidly transform critical
processes. Based on our analysis of the Sloan Valve
case, we present five important lessons for companies
seeking better ways to utilize their IT resources and
capabilities for reengineering their critical business
processes.
Table 3: Comparison of Old and Reengineered NPD Processes
Characteristic Old NPD Process Reengineered NPD Process Key
Benefits from IT-led
NPD Reengineering
Time-to-Market 18–24 months Less than 12 months Significant
reduction in time-
to-market for a new product
Governance
Structure
16 functional units Strategic and process-level
governance structure
Better governance of the NPD
process
Systems and
Methodology
Informal continuous
improvement
End-to-end approach; key

performance indicators to
measure outputs
Holistic perspective of the
NPD process; reduction
in process bottlenecks and
uncertainties
Process
Accountability
No clear accountability Well established process
ownership (executive process
owner, stage-gate model)
Better accountability;
assignment of clear-cut
responsibility
Front-End
Processes
Poorly managed and
fuzzy front end
Cross-functional team owns
the front-end processes
Better management of
ideas; availability of varied
perspectives
Prototyping Huge investments in
prototyping, since ideas
were not managed well

More emphasis on the idea-
generation stage, resulting in
less prototyping
Significant cost, time, and
effort savings due to efficient
prototyping
Idea Generation Internal group generates
ideas
Everyone can contribute ideas
(including customers)
Better match between
customer expectations and
features in the end product
Management
Focus
Focus on selective
ideas generated by top
management
Focus on managing project
portfolios filtered through the
front end
Better match of projects and
available resources; avoidance
of excess projects in the
pipeline

10 No. 2 / Jun 2011 91
1. Recognize the Potential of the IT
Organization to Play a Transforming
Role
In many companies, the IT organization has
traditionally played a support role in business
innovation processes and initiatives. However, the
Sloan Valve experience shows how the IT function
can play a transforming role in driving process
changes—by helping the firm take an end-to-end
process perspective, by providing able leadership, and
by cleverly exploiting IT in the redesign effort.
2. Assign Executive Accountability for
the End-to-End Process Redesign Effort
Process redesign is a complicated exercise, fraught
with uncertainties, risks, and pitfalls. Sloan Valve’s
experience shows that without top management
commitment and active involvement, process
reengineering would have been nearly impossible.
Appointing a technology executive—the CIO—
as Chief Process Officer (CPO) who understood
both technology and processes was key to success.
The CIO/CPO built bridges between the functional
executives, worked with them, and acted as the
catalyst for change. The two-level governance
structure (strategic and process) helped to clearly
specify the accountability of all the stakeholders
involved in the redesign effort. Once the redesign
was completed, Sloan Valve brought in a functional
executive (VP, Product Development) as the executive
process owner.

3. Leverage and Extend Existing
Technology Capabilities in the
Reengineered Process
A key lesson from Sloan Valve’s experience is that,
for end-to-end cross-functional processes to be
implemented, it is not sufficient to make changes to
governance and processes. Corresponding changes
must also be made to the technologies underpinning
the processes. Platforms like ERP systems can provide
the fundamental capabilities that can be a powerful
launch pad for implementing effective enterprise
processes. At Sloan Valve, the PLM module, process
visualization tool, and Ideation Portal played crucial
roles in enabling the governance and redesign
activities at various stages of process reengineering.
Understanding the linkages between the different
aspects of reengineering and cleverly exploiting
technology capabilities to enable transformation are
crucial for a successful reengineering endeavor.
4. Design and Govern an Enterprise-
wide Process Redesign Methodology
Without a well-thought-out enterprise-wide process
redesign methodology, companies run the risk of
falling into the “continuous improvement spiral,”
where minimal tweaks are made to multiple processes.
Minor changes to processes might provide some
incremental short-term gains, but greater returns will
be elusive without a radical overhaul of the processes.
5. Bridge the IT-Business Divide to
Achieve a Process-oriented Mindset
Even experienced experts find the concept of IT-led
process thinking challenging. To fully understand
and appreciate the potential of IT to enhance

collaboration and the exchange of ideas requires that
employees in the business receive effective training
and are engaged in cross-functional teams. Sloan
Valve’s efforts to create process thinking across all
levels of the organizational hierarchy proved to be
crucial in creating a favorable climate for its process
reengineering efforts. This ensured that both senior
management as well as operational employees made
effective contributions to the reengineering effort.
CONCLUDING COMMENTS
The Sloan Valve case described in this article
illustrates that IT-led process reengineering can be
successful and provides valuable lessons for other
companies. In particular, Sloan Valve successfully
changed the perception of the IT organization from a
support function to one that drives business innovation
efforts, which enabled IT capabilities to play a critical
role in process reengineering. Other companies
can apply these lessons to make the best use of IT
resources and capabilities in achieving IT-led process
reengineering. Sloan Valve’s experience shows that
even mid-sized companies can rapidly transform
critical business processes by developing key IT
capabilities and through effective IT leadership.
ABOUT THE AUTHORS
S. Balaji
S. Balaji ([email protected]) is an assistant
professor in the Information and Process Management
department at Bentley University. Balaji holds a
Ph.D. degree in Information Systems from Indiana
University, Bloomington, and a master’s degree in
computer science from the University of Illinois at
Chicago. His research interests include IS outsourcing,

strategic management of information systems,
and healthcare IT. His research has appeared in
Communications of the ACM and MIS Quarterly
Executive, conference proceedings of the International
Conference on Information Systems and Hawaii
International Conference on System Sciences, and as
teaching cases and book chapters.
C. Ranganathan
C. Ranganathan ([email protected]) is Associate
Professor and Director of Graduate Studies at the
Department of Information and Decision Sciences,
University of Illinois at Chicago. He holds a doctorate
degree from the Indian Institute of Management,
Ahmedabad, and a master’s degree from BITS,
Pilani, India. His current interests include strategic
management of information systems, healthcare
IT, IT-enabled business transformation, and social
networks. His research has appeared in several top-tier
journals and conference proceedings. He is the winner
of the Best Doctoral Dissertation and Teaching Case
awards at the International Conference on Information
Systems and is a three-time award winner of SIM’s
Paper Awards Competition.
Tom Coleman
Tom Coleman ([email protected]) is
the Chief Information and Process Officer at Sloan
Valve Company. Prior to joining Sloan, he worked

in top manufacturing and IT positions in companies
such as Motorola and Western Digital. He currently
leads the IT group at Sloan and is responsible for
process transformation and the strategic planning
process. A veteran of various process initiatives, he
has successfully led several enterprise-wide systems
implementation, process redesign, and continuous
improvement activities. He is a frequent speaker at
various events on process transformation and has
presented on a variety of topics for Gartner Research,
Forrester Research, and CIO forum, among others.
Copyright of MIS Quarterly Executive is the property of MIS
Quarterly Executive and its content may not be
copied or emailed to multiple sites or posted to a listserv
without the copyright holder's express written
permission. However, users may print, download, or email
articles for individual use.
Volume 24 Article 33
Information Systems and Healthcare XXXI: Improving Infection
Control
Process Efficiency to Reduce Hospital Acquired Infections
Christian Janiesch

SAP Research CEC Brisbane, SAP Australia Pty Ltd
[email protected]
Robin Fischer
Karlsruhe Institute of Technology (KIT), Universität Karlsruhe
(TH)
Inconsistent and incomplete information due to the diversity of
isolated information systems is one of the major
problems information technology faces in the healthcare sector.
The insufficient integration of actors results in
delays in clinical processes. However, due to strict constraints
in health care such as health regulations, clinical
processes cannot be modified freely. The approach of this work
is to apply the less radical principles of Business
Process Management to medical information systems to provide
reliable and timely access to relevant patient
information and to decrease process lead time. In particular, this
work outlines the impact of optimization for
administrative processes. To substantiate our research, we
performed a case study in collaboration with a
healthcare provider and a regional healthcare facility in the U.S.
We report on the workflow implementation of a
clinical infection control process which integrates disparate
systems and automates clinical decision making
according to clinical knowledge. The post-metrics clearly
emphasize the capability of Business Process
Management to improve the integration of information, increase
the quality of patient care, reduce health worker's
stress, and ease costs of treatment by significantly shortening
process lead time. We conclude with a generalization
of the results for other healthcare enterprises.

Keywords: business process management, workflow
management, healthcare, infection control, hospital acquired
infections
Volume 24, Article 33, pp. 557-570, June 2009
The manuscript was received 10/22/08 and was with the authors
2 months for 1 revision.
Control Process
Efficiency to Reduce Hospital Acquired Infections
Control Process
Efficiency to Reduce Hospital Acquired Infections
558
I. INTRODUCTION
Hammer and Champy [1993] see the practice of automating
existing processes as paving cow path compared to
major Business Process Reengineering (BPR). However, the
rather radical approach of BPR is not suitable for all
business fields. It requires the freedom to modify organizational
structures and free core business processes from
non-value adding activities. In business sectors like healthcare,

there are a variety of legal restrictions and treatment
guidelines practitioners have to comply with [The Medical
Letter Inc. 2004; The Medical Letter Inc. 2006]. Hence,
freedom to reorganize the organization and to omit non-value
adding activities is heavily compromised.
The approach of this work is to introduce the less-radical
principles of Business Process Management (BPM)
[Becker et al. 2003; van der Aalst et al. 2003] to healthcare and
employ those principles to existing medical
information systems [Borst et al. 1999; Gardner et al. 1999;
Teich et al. 1999]. We performed a case study to show
how BPM and information technology contribute to lower the
frequency of human errors in healthcare [Institute of
Medicine 2001; Kohn et al. 2000]. The case study originates
from a customer project in the U.S. The goal of the
project was to improve efficiency of the existing controlling
process for hospital acquired infections (HAI). Our work
outlines the potential for process improvement in administrative
processes without reengineering the enterprise.
Despite a restrictive environment and legal prerequisites, we
show that it is possible to reduce cost, free staff from
routine work, and improve patient safety even without changing
initial medical treatment processes.
The structure of the paper is as follows: First, in Section II, a
short literature review familiarizes the reader with
relevant facts on BPR and BPM as well as workflow
management. In Section III, we give an introduction to
healthcare and clinical processes as characterization of the
project. Section IV comprises the case study including
details on restrictions in process design as well as a quantitative
and qualitative process improvement analysis. The
paper closes with conclusions and an outlook on possible
further improvements and a generalization to other
healthcare facilities.

II. HEALTHCARE AND CLINICAL PROCESSES
Processes
Processes are generally seen as activities performed within a
company or an organization [Object Management
Group Inc. 2006]. Activities are considered to be the smallest
entity used to build a process. These entities may be
seen as complex chunks, which do not need to be analyzed
further, or atomic activities, which cannot be divided any
more. Furthermore, an activity can either refer to work that
needs to be done manually, or to work that can be done
automatically. Other definitions of processes [Davenport 1993;
Johansson et al. 1993] emphasize the timely and
local order of activities and also regard different kinds of inputs
and value-added outputs. Harmon [2003] considers
business goals, which processes are tied to, to be significant for
the definition of a process. In the context of this
work, we define a process as a completely closed, timely and
logical sequence of activities that are required to work
on a process-oriented business object [Becker et al. 2003], as
this definition integrates the relevant perspectives.
Consequently, we consider a business process as a special
process that is directed by business objectives of a
company and by the business environment. We further classify
business processes into value-creating core
processes and not value-adding supplementary processes.
Whereas core processes contain corporate expertise
and creates products or services that are delivered to customers
[Harmon 2003; Porter 1985], supplementary
processes facilitate the ongoing operation of core processes
[Becker et al. 2003]. This differentiation of core and
supplementary processes is not always selective, as one
business process might be a core process for one product

and a supplementary process for another.
The practice of business process reengineering, which emerged
in the early 1990s, employs fundamental rethinking
and radical redesign of business processes. In doing so,
dramatic improvements in critical, contemporary measures
of performance, such as cost, quality, service, and speed can be
achieved [Hammer and Champy 1993]. This kind
of Greenfield project, however, does not consider any existing
operational sequences or organizational structures
during the construction of new processes at all. Furthermore, it
lacks granularity with respect to process hierarchies.
BPR targets the overall process perspective in one single shot
rather than iteratively and continuously optimizing
processes’ performances. Business process management, on the
other hand, plans, controls, and monitors intra-
559
and interorganizational processes with regard to existing
operational sequences and structures in a consistent,
continuous, and iterative way of process improvement [Becker
et al. 2003].
Workflows
In dependence to processes, workflows can be seen as part of a
work process that contains the sequence of
functions and information about the data and resources involved
in the execution of these functions [zur Muehlen
2004]. This close linkage of a workflow being an automated

representation of a business process is also supported
by the Workflow Management Coalition (WfMC). The WfMC
considers workflows to be an automated representation
of a whole or part of a business process. Procedural rules define
documents, information or tasks which are to be
passed from one participant to another for action [Workflow
Management Coalition 1999].
To-be process models are used as sources to implement the
workflows; therefore, process models need to be
transformed into workflow models. Process models, however,
primarily serve organizational (re-)design whereas
workflow models focus on implementing IT support. That is
why process models integrate functions in a lower level
of granularity than workflow models.
While creating workflow models, workflow relevant data is
required for the refinement of functions. Consequently,
the necessity for a detailed specification of data needed during
the execution of activities and data needed to creat e
mathematic routing conditions emerges. In order to assign
activities to either people or applications, user roles must
be created and parameters for application calls need to be
defined.
Finally, criteria for when to initiate and when to
terminate a workflow and how to handle errors are to be defined
[zur Muehlen 2004].
Workflow Management (WfM) aims at providing this automated
process execution where the transitions between the
individual activities are controlled by a Workflow Management
System (WfMS). So-called business rules may be
used to evaluate the state of the workflow and enable

appropriate activities by computation or inference based on
the data available. Rules can also be used to implement
guidelines or mandatory constraints in the overall workflow
[Herbst 1997; von Halle 2001]. If an activity cannot be
automated, a WfMS is concerned with demanding input from
users while providing all necessary information needed to make
a decision to those users.
III. HEALTHCARE AND CLINICAL PROCESSES
Healthcare Sector
Healthcare providers are under constant pressure to reduce costs
while the quality of care needs continuous
improvement [Institute of Medicine 2001]. While expenses for
patient treatment and pharmaceuticals rise
relentlessly, reimbursements refunded by insurance providers
are fixed and coupled to diagnosis-related groups
[DiMasi et al. 2003]. Diagnoses related groups allow classifying
of patients in segments of comparable diseases.
Every group has an assigned basis value for reimbursement. The
actual reimbursement is calculated by taking the
actual severity of the illness into account [Mast et al. 2004].
Despite these efforts, the healthcare system in the U.S.
is the most expensive healthcare system in the world. Health
spending as a share of the Gross Domestic Product
(GDP) in 2004 has been 16.3 percent, which is almost double
the average (8.9 percent) of all countries listed by the
Organization for Economic Cooperation and Development
[2006].
Information Systems in Healthcare
The historical evolvement of heterogeneous information systems
in healthcare may be due to a lack of expertise in
implementing systems and missing investment abilities. On the

other hand, the rapid development of information
technology may also be a reason for the heterogeneous IT
landscape in healthcare [Magruder et al. 2005;
Wisniewski et al. 2003]. The wish to provide a minimum level
of data integration resulted in standards like Health
Level Seven (HL7). HL7 defines a standard for the exchange of
data between clinical applications. Therefore, HL7
describes clinical events and allows the definition of relevant
data, which needs to be interchanged, when the
defined clinical events actually occur [Health Level Seven
1998]. In addition, Arden Syntax was also developed
under the umbrella of HL7. Arden Syntax defines complex
clinical conditions in clinical rules called Medical Logic
Modules (MLM) [Shwe et al. 1992]. Each MLM is written in a
procedural programming language and stored in single
files to enable intra- and interorganizational exchange of
medical knowledge [Health Level Seven 2005; Pryor and
Hripcsak 1993]. Each MLM consists of multiple slots. The
invocation slot, for instance, defines which event triggers
the execution of the MLM. Whereas the logic slot defines the
criteria that are to be evaluated before an action is
executed.
560
Clinical Processes
We divide clinical processes into generic process patterns and
medical treatment processes [Lenz and Reichert
2005; Panzarasa and Stefanelli 2006]. Both types of processes
may be designed and executed cross-department as

well as cross-company. Generic process patterns help to
coordinate healthcare processes among different people
and organizational units. They are essentially administrative
processes. Medical treatment processes are the
representation of an actual care process, which we consider the
core processes of healthcare facilities. These
clinical processes highly depend on medical knowledge and case
specific decisions [Panzarasa and Stefanelli
2006]. Interpreting patient specific data according to clinical
knowledge is the key component of making decisions in
clinical processes.
Therefore, medical information systems must supply a
recallable representation of clinical knowledge and a
consolidated database of patient specific data to provide clinical
decision support. The cooperation of clinical
knowledge and complex decision support allows the
implementation of treatment guidelines in highly flexible
clinical
processes. Flexibility is required since treatment of patients is
likely to differ from patient to patient. Consequently,
medical treatment processes need to be quickly adaptable.
Medical treatment processes are seen as a diagnostic-
therapeutic cycle. Main components of the diagnostic-
therapeutic cycle are: observation, reasoning, and action.
These stages are iterated until no further action needs to be
taken, i.e. the patient no longer requires treatment
[Lenz and Reichert 2005].
Infection Control
Infection Control (IC) is the process of preventing hospital
acquired infections (HAI) by isolating sources of infections
and limiting their spread. Today, HAI are by far the most
common complications affecting hospitalized patients or
intensive care patients [Borst et al. 1999; Centers for Disease

Control and Prevention (CDC) 2004; Teich et al.
1999]. In the U.S. approximately 2 million patients acquire this
kind of infections each year and costs are estimated
at $4.5 to $5.7 billion per year [Burke 2003]. More importantly,
up to 90 percent of deaths caused by HAI are
considered preventable [Ricks 2007]. Identification of HAI
typically involves testing of specimen in a laboratory.
Therefore, nurses need to get a specimen and physicians need to
order tests of the specimen. Then if tests are
positive, Infection Control Practitioners (ICP) need to ensure
that all precautions are occasioned and physicians
need to prescribe treatment for the infections.
IV. A CASE STUDY IN BUSINESS PROCESS
MANAGEMENT IN HEALTHCARE
Case Study Environment
The present case was performed by Siemens Medical
Solution
s USA, Inc. (Siemens MED) and a major healthcare
facility in the U.S. The facility consists of multiple independent
hospitals. More than 7,500 employees are employed
at four sites, medical staff consists of about 1,000 physicians
throughout the organization. Overall, almost 1,000
beds are available for inpatient care. In the following, the
organization is referred to as “customer.”

The scope of the project was to analyze the current IC process,
suggest possible improvements through workflow
enhancement, and finally advance the current IT solution to
increase process efficiency. The uniqueness of this
project was rooted in the application service providing (ASP)
environment [Dewire 2000; Tao 2001]. Siemens MED
does not only provide the clinical software but also the
comprehensive IT infrastructure required by the customer,
who had never implemented a workflow onsite before.
Analogous to the theoretical exploration in the previous
sections, the actual freedom to restructure processes or the
organization was found to be heavily compromised by legal
restrictions and healthcare guidelines. Although this
already became apparent during the first stage of analysis,
consensus was achieved to pursue the project even
though potential for optimization could not be fully exploited. It
was agreed that a workflow focused pilot project
would provide essential knowledge for more complex projects
to come.
The project started in April with an analysis of the existing
processes. Also, pre-measurements were taken from this
date. It ended in September with the completion of post-
measurements. We designed measurements in a way that

enables comparison of turnaround times before and after the
implementation of the automated workflow. Build, test,
and integration of the workflow needed to be done in just 12
weeks. Table 1 provides an overview of the project
phases and the collection of data.
As outlined earlier, this project was done in an ASP
environment where the IT equipment for the customer has been
provided by Siemens MED. The medical information system
used in this project is called Soarian®, developed and
distributed by Siemens MED [Siemens AG 2007]. For
information on clinical data sources cf. Wisniewski [2003].
561
Table 1. Project Plan
Timeline

Phase April May June July Aug. Sept.
Analysis (as-is modeling)
Design (to-be modeling)
Implementation
Testing
Evaluation
Data collection: pre-metrics
Data collection: post-metrics
The Soarian® architecture is a three-tier, client-server
architecture built according to principles of a service oriented
architecture (SOA). The top layer, web application tier,
comprises Soarian® web application servers running the
Soarian® User Interface (UI). The application tier, the middle
layer, is constituted by Soarian® application servers, a
rules engine, and the WfMS. The Soarian® application servers

are running the application logic, which is provided
by so-called Soarian® Common Components (SCC). The rules
engine is a system implemented in Arden Syntax to
evaluate medical conditions and recommend possible treatment
options. Hence, it represents clinical knowledge
stored in MLM. The WfMS used in the Soarian® environment is
the third party product TIBCO Staffware Process
Suite. Core of this suite is the so called iProcess Engine, which
is responsible for the execution and the
management of workflow instances. The process suite further
consists of a process definer, monitor, and an
administration tool to provide a client application development
environment. Thus, it enables distributed workflow
management. Finally, the third layer, the data tier, is constituted
by database servers.
In the project environment, the WfMS can use services provided
by SCC to either add and remove items to/from
work-lists or add and remove users to/ from census lists. Work-
lists and census lists are components of the
Soarian® UI enabling the WfMS to alert users in case of
required user actions. On the other hand, users of the
Soarian® UI are able to trigger events, hence invoke the
workflow engine to perform actions on demand. Whereas
simple routing conditions can be evaluated by the WfMS itself,

complex clinical conditions need to be evaluated with
respect to clinical knowledge and patient specific data.
Therefore, the WfMS is also integrated with the rules engine.
Finally, a Workflow (WF) Event Handler keeps workflows
status synchronized with other applications and treatment
progress (e.g. recognition of discharge, new order entries, new
lab results). Figure 1 illustrates the integration of the
TIBCO Staffware Process Suite and the Soarian® environment.
As-Is Analysis
According to the project plan we presented earlier, the first
project phase comprised the analysis of the current IC
process. Therefore, we conducted interviews with all involved
actors (e.g. clinicians, nurses, laboratory workers, and
ICPs). The combination of all expert interviews resulted in a
comprehensive as-is process model (cf. Figure 2 and
Figure 3).
The customer’s infection control process consists of two
separate process fragments, synchronized over paper
reports. The first part of the process starts as soon as a
specimen is tested, if the patient to which the specimen is
assigned to is an inpatient at the customer. First, the laboratory
needs to screen the test result whether it indicates a

positive statement of an HAI. In the laboratory a different
information system supports workers to perform this task.
Once a worker at the laboratory identifies a lab result indicating
a positive infection statement, he directly calls the
floor the patient is located on. In doing so, the nurse station is
notified about an infectious patient and the
responsibility for putting the patient in isolation is passed to the
nurse station. Next, the nurse station initiates all
necessary tasks to isolate the patient. The first part of the IC
process ends, as soon as the laboratory completes the
documentation of the lab result in the lab information system.
The diagram in Business Process Modeling Notation
(BPMN) [Object Management Group Inc. 2006] depicted in
Figure 2 illustrates a structured overview of this part of
the IC process.
562

TIBCO Staffware Process Suite
Process Definition
Tool
Administration
Tool
Monitoring
Tool
Workflow Engine(s)
SCC, WF Event
Handler
Soarian® UI Rules Engine

Figure 1. Integration of WfMS into Project Environment
N
u
rs
e
s
ta
ti
o
n
/
b
e

d
m
g
m
n
t
L
a
b
o
ra
to
ry Check lab
result for
infection
statement

yes Notify floor
Incoming
lab result
Complete
documenta-
tion of lab
result
Take isolation
precautions
Lab result
documented
Isolation

initiated
Lab result
Lab result
positive?
no
Figure 2. As-Is Notification Process
The second part of the IC process is rather a controlling
process, as each hospital must report the amount of
infection occurrences on a yearly basis [Weber et al. 2007]. As
for this customer, specific reports for each infectious
disease were created on a weekly or even daily basis. These
reports are the starting point of the second fragment of
the IC process (cf. Figure 3). Once an ICP receives a weekly or
daily report of infectious diseases, he screens the
report for infectious statement. This task results in a list of
patients that need follow-up ensuring that isolation
prerequisites are actually taken. During daily tours, the ICP

does not only check if infection precautions have been
taken for infectious patients but also controls, if the infection
statement is transferred to the patient’s chart. If a
patient is not put in isolation, the ICP immediately initiates
isolation. The ICP does not use any cues to determine the
patients, which are to be put in isolation, but follows the report
result.
563
N
u
rs
e
s
ta

ti
o
n
/
b
e
d
m
g
m
n
t
IC
P
Check report

for positive
statement
yes
Verify if
patient is put
in isolation
Every Friday /
weekday afternoon
Initiate
isolation
no
no
All infectious

patients are
isolated
Infection report
Take isolation
precautions
yes
Statement
positive?
Patient in isolation?
Figure 3. As-Is Follow-Up Process
Through the as-is analysis, we externalized the following
intrinsic problem domains:

Lack of synchronization: Since reports of infectious diseases
are generated only in the afternoon, even on
weekends, an ICP only recognizes infections on the weekday the
morning after the report has been
generated. However, these reports are triggering the execution
of the second part of the IC process. Hence,
they are critical in time.
No use of information technology: The analysis of the IC
process clearly showed that no information
technology is used after the ICP has received infection reports.
In addition, further investigations indicated
that ICP did not have any access to Soarian®, yet.
Excessive time spent screening infection reports and charts:
The review of reports and patient charts needs
to be done manually as infection reports are printed and
corresponding patient charts are not at hand
instantly. A sample inquiry performed in collaboration with ICP
indicated that screening all necessary
documents takes almost 30 percent of ICP’s daily work time.
Involvement of ICP in notification tasks: Even though ICP have
responsibility for the handling of infectious

diseases, they are not directly participating in the IC process.
Further inquiry showed that the former
process was to leave a voicemail for the ICP, assigned to the
nurse station the patient was located at, as
soon as an infection disease was stated. Once the ICP received
the voicemail, the isolation of infectious
patients was initiated and controlled by the ICP. However, since
ICP do not work nights or at weekends this
process was changed to directly call the floor and notify ICP
only through reports. In doing so, the customer
reported faster turnaround times in putting patients in isolation
even though notification of ICP was delayed,
i.e. the follow-up processes started delayed.
To-Be Design
It became obvious that we could not change personnel
capacities. Neither could we increase the involvement of ICP
in notification tasks nor could we transfer the controlling
responsibilities of ICP to Soarian® due to legal restrictions.
The laboratory will still have to notify the nurse station
directly, as ICP will not (yet) work during night hours or on
weekends. In addition, the customer agreed to not work on
further improving the turnaround time for putting patients
in isolation, but on the elimination of time wasted while

generating, delivering, and reading reports as well as
screening patient charts. In doing so, the customer agreed to
optimize IC tasks done by ICP without affecting
existent clinical and business processes.
Therefore, we focused mainly on synchronizing the infection
notification (cf. Figure 2) and the follow-up (cf. Figure 3)
fragments of the as-is IC process. We suggested the
introduction of a new workflow supported IC process. The
564
workflow screens new and modified lab results for statements of
infectious diseases. Therefore, we used events
defined by HL7. In doing so, we subscribed the workflow to
new and modified lab result events (HL7_R01 and
HL7_R02). As the case study was a pilot project, the customer
agreed to limit the workflow to only cover two
infections: Clostridium difficile (CDIFF) and vancomycin
resistant enterococcus (VRE). However, the workflow could

be extended easily to cover other HAI, such as methicillin-
resistant staphylococcus aureus (MRSA), once clinical
conditions are identified and MLM are created for an automated
evaluation of those conditions.
Figure 4 illustrates both parts of the IC process. According to
the agreement made with the customer, we did not
change the notification part of the IC process at all; however,
the linkage between the notification process and the
infection follow-up is made explicit in the to-be process
models. We integrated the interface of the notification
process and the follow-up process. In doing so, the follow-up
process starts immediately after the notification
process. Thereby, we save valuable process time by
synchronizing both process parts.
More significant changes have been made to the infection
follow-up process also shown in Figure 4. We streamlined
this process in order to allow efficient automation through the
use of a workflow. To achieve the requested level of
automation we integrated a WfMS to the process. In addition,
the process takes advantage of the fact that ICP are
able to access Soarian®, as further IT support is provided in the
remaining manual tasks.

The follow-up process is triggered every time a lab result is
documented in the lab system. The workflow
immediately evaluates the new or modified lab result. Only if
the lab result either indicates a positive CDIFF or VRE
statement, the workflow will notify the ICP assigned to the
nurse station where the infectious patient is located.
Hence, ICP will instantly see a new task on their worklist in
Soarian®. ICP still need to manually verify whether a
patient has been put in isolation, but ICP are now able to access
medical records electronically in Soarian®. This
enables ICP to work independently of any paper reports or
patient charts. Unfortunately, we could not design the
workflow to initiate and monitor the isolation of patients
automatically due to a missing integration of participating
actors (i.e. bed management).
The system could be designed in such a way as no separation of
concerns was deemed necessary. The ICP used
to check only for positive statements on the lab results. He did
not use any additional indicators to determine if a
particular patient has to be put in isolation which would have
been eliminated with the new setup. In fact, the current
system is able to apply much more sophisticated metrics than an
ICP would have been able to perform in his daily
routine.

Consequently, we established new possibilities for further
process enhancement. We designed the to-be infection
follow-up process to be executed not only every time a lab
result has been documented, but also every time a
patient is admitted as inpatient, an inpatient is pre-admitted, an
outpatient is kept in hospital for observation or a
patient requires emergency care (cf. Figure 4). In each case, the
workflow screens the last six months of the
patient’s medical record for an occurrence of an infection. If the
workflow is able to identify an infection statement
within the past six months, the patient is considered to require
isolation and the workflow initiates infection
precautions. These new characteristics increased the process
quality and patient safety in addition to the increase of
process efficiency, since many HAI are likely to reappear, if the
last infection is more recent than six months.

565
IC
P
W
fM
S
N
u
rs
e
s
ta
ti
o
n
/

b
e
d
m
g
m
n
t
L
a
b
o
ra
to
ry
Check lab

result for
infection
statementIncoming
lab result
Patient
admitted*
Complete
documenta-
tion of lab
result
Take isolation
precautions

All infectious patients
are isolated
Lab result
Check report
for positive
statement
yes
Alert ICP
Initiate
isolation
no
Check history
for positive

statement
* covering admissions, pre-admissions, observation patients,
and emergency patients
yes Notify floor
Lab result
positive?
Lab results
Statement
positive?
no
Infection report
Verify if
patient is put

in isolation
no
yes
Lab result
documented
Figure 4. To-Be Notification Process and To-Be Follow-Up
Process
Implementation
We implemented the IC workflow based on a hierarchical model
of procedures and sub-procedures. Thereby, the
top level procedure coordinates the overall process flow (cf.
Figure 5). The functionality to initiate new workflow
instances (e.g., inpatient admit) and terminate existing instances
(e.g., patient discharge) is built upon the WF event
handler. So called subscriptions, which are basically rules that
filter and evaluate selected HL7 events, allow the

definition of case generation and case termination respectively.
We implemented this workflow according to the to-
be process models. Thus, a workflow case is initiated the first
time a patient is admitted, pre-admitted, put in an
observation bed or in the emergency department. The workflow
instance will terminate as soon as the patient is sent
home (e.g., discharged).
The purpose of the infection control model workflow is to alert
users of Soarian® Clinicals of patients having
infectious diseases (i.e. CDIFF, VRE). Therefore, the workflow
is designed to immediately check new and modified
lab results for patterns indicating a positive statement of an
infectious disease. In addition, this workflow checks the
medical record for a history of an infectious disease. Alerts on
the work lists are created and patients are put on the
census list of selected users (e.g. ICP), if a patient has an active
indication for isolation. According to the to-be
process the infection control workflow is required and triggered
by multiple events.
Since every event provides a different set of data, the first three
activities (e.g. Start, Get HCU Abbreviation, initialize
field values) deal with consolidating data. This ensures that all
workflow relevant data is available instantly. The sub-

procedures Pt discharge and Pt Discharge Cancelled are used to
perform a delayed workflow termination, if the
patient was discharged and the discharge was not cancelled
within eight hours.
566
Figure 5. Infection Control Main Procedure Workflow
Following the path to the VRE infection checking activities, a
conditional router (e.g., invoked by VRE result?)
evaluates whether a lab result needs to be checked for VRE
patterns (e.g., check VRE result) or a patient’s medical
record needs to be screened for positive VRE statements (e.g.,
check VRE history). We encapsulated both, the
checking of a lab result and the screening of a historical patient
data for infectious statements, in sub-procedures.
Thus, relevant data like patient identifiers, visit identifiers, or
result values must be passed to the called sub-

procedure. Values returned by the sub-procedure must be
mapped in the calling procedure. Once the VRE lab result
has been evaluated automatically or the medical records have
been screened for previous infections without human
intervention, another conditional router examines, if a clinical
user needs to be alerted or if the patient needs to be
added to the user’s census list. We used another call to a sub-
procedure to alert users and adding infectious
patients to the user’s census (e.g., send VRE notification).
Since the notification sub-procedure stays active until the
alerted user confirms the infection alert (e.g., user
releases the worklist alert), new lab results may be submitted in
between. This behavior creates cases where the
alert message needs to be changed or the alert needs to be
withdrawn entirely due to new information provided by
new lab results. Therefore, we provided functionality to remove
or replace alerts. We implemented this functionality
by withdrawing created alerts (e.g., withdraw connection of
send VRE alert? and send VRE notification) before
creating a new alert (e.g., wait for withdraw). Every time the
hospital discharges a patient all alerts will be removed
and the patient will drop off the user’s census list. If the
hospital cancels the discharge for any reason, the workflow
restores the status of the last notification.

567
Project Controlling
Concurrent to the project realization, data was collected for a
detailed analysis of the project outcome. We designed
pre- and post-metrics to measure the performance of the IC
process before and after the implementation of the
workflow supported IC process. Our key metric is time to
notification. Time to notification represents the time spent
notifying an ICP of a newly identified infectious patient. In
doing so, we started the measurement as soon as the
laboratory documents a positive lab result. We stopped our time
measurement as soon as the ICP had been
notified. The ascertainment of notification dates needed to be
done manually. Before the implementation of the IC
workflow, we asked ICP to write down their dates of
notification as soon as they had been notified of infectious
patients. After we implemented the workflow, the date of

notification was considered to be the date when an ICP
acknowledged the automatically created infection alert in
Soarian®. Nevertheless, we needed to extract this
manually out of workflow audit trails, as there was no
automated controlling functionality available. Also, ICP forgot
to write down the times or to clear their work-list when they
received the notification. Thus, we had to go back and
ask for approximate times or had to estimate the time to
notification by assuming an ICP’s standard daily routine.
Independent of the measurements of time to notification, we
collected additional data in order to identify how much
time ICP spent while screening paper reports or patient charts.
Therefore, we asked the ICP to additionally write
down their hours spent on reading reports and screening patient
charts before the implementation of the workflow.
Data collection took place over the course of about two and a
half months each.
The pre-metrics we report are higher than expected. The post-
metrics are still high. This is mainly due to the fact
that in particular VRE reports have only been created every
Friday afternoon. This means that only those VRE
occurrences of past Saturday to Friday would appear on
Friday’s report, which is read on the following Monday at

the earliest.
Our comparison of pre- and post-metrics shows that we reduced
time to notification by more than 75 percent after
the implementation of our workflow (cf. Table 2). Time to
notification averaged out at 70 hours before the
implementation and has reduced to an average of 17 hours after
the implementation of the IC workflow. While the
time to notification of VRE infections could be shortened
considerably, 17 hours on average is still a long time. This
is, however, due to process limitations in matters of personnel
capacity. There is still no ICP available on weekends
or during night hours. Also, ICP are not continuously signed in
their Soarian®. So delays for both, CDIFF and VRE,
still occur. Nevertheless, we can clearly conclude that
substituting the old paper reports based IC process for the
new workflow supported IC process greatly increased
efficiency.
Table 2. Comparison of Post- and Pre-measurements: Time to
Notification (Hours)
N Mean Std. Dev.

Difference
Mean
t Sig. (2-tailed)
VRE (pre) 17 150.00 42.71 129.33
(86.22 %)
9.107 .000
VRE (post) 10 20.67 16.88
CDIFF (pre) 34 29.68 17.64 14.00
(47.17 %)
3.498 .001
CDIFF (post) 28 15.68 12.91
Combined (pre) 51 69.79 63.80 52.80
(75.66 %)
5.006 .000
Combined (Post) 38 16.99 13.99

VRE = Clostridium difficile
CDIFF = Vancomycin resistant enterococcus
The reported univariate skewness and kurtosis statistics for each
scale item are not exceeding the
thresholds (skewness < 2 and kurtosis < 7) as suggested by
Stevens [2001] and point to a normal
distribution. Equal variances are assumed.
ICP spent an average of 30 percent of their daily work time on
screening infection reports and patient charts. We
decreased this effort to almost zero after the implementation of
the workflow, since required patient information is
now available instantly through Soarian®.
We want to accentuate, that we not only significantly improved
the IC process on a quantitative perspective but also,
and maybe even more importantly, on the qualitative
perspective. We achieved major improvements to patient
safety through the implementation of HAI history screening, as
the workflow now screens every patient for a positive
history (in the last six months) of infection statements.
Furthermore, the process quality has been improved through
reducing the risk of human errors, since ICP no longer rely on

manually generated paper reports or voicemails.
Finally, with the implementation of the workflow, we greatly
contribute to the process of getting health workers,
568
especially ICP, online. The automated IC process functioned as
an incentive to overcome the negative attitude some
health workers have concerning IT in inpatient care [Doolin
2004].
V. CONCLUSION AND NEXT STEPS
In this paper, we presented reasons for the inappropriateness of
Greenfield project approaches, like BPR, for the
optimization of clinical processes in healthcare. Both from on a
conceptual and a practical perspective, BPM
appeared to provide the desired cost reduction, increase in
patient safety, and relief for health workers in matters of
routine tasks. Furthermore, we discovered significant potential

for automating coordination and evaluation tasks (e.g.
calling floors and screen charts) and consequently contributed
to patient safety, too.
As we presented in our process analysis, the implementation of
the new workflow supported IC process improved
quality greatly and increased efficiency as well as patient
safety. However, the average time to notification of 17
hours is still high. This is mainly due to two facts: First, ICP do
not work during night hours or on weekends; second,
ICP are not continuously signed on to Soarian® during work
hours as they need to be on the floor as well.
A simple solution to uncouple ICP from being continuously
signed on is to use pagers, cell phones, or even personal
digital assistants (PDA) to notify ICP of infectious patients.
This could be used in addition to the work-list of
Soarian®. We see additional possibilities to further decrease the
time to notification in the implementation and
delegation of on-call duties for ICP once paging. ICP could take
their pagers home and perform simple follow-up
tasks over the phone while working from home.
Finally, we see additional space for process improvement in
integrating more actors into the IC process. Currently,

the laboratory still needs to call the floor directly. This process
could be handled by an extended IC workflow which
would automatically notify nurse stations through pagers, PDA,
or tablet computers. Other follow-up tasks could be
integrated: Reminding the floor to put the patient in isolation
after a given amount of time; or escalating the order for
isolation to the designated physicians. Extending the workflow
to more and more participants of the IC process
could, finally, result in a companywide standardized automated
IC process. In a more comprehensive approach,
even digital door plates could be used to indicate isolation of
infectious patients at the entry of every room. In doing
so, the implementation IC workflow could actively reduce the
risk of infection of nonclinical actors like visitors or
patients.
With an enhancement like this, additional patient safety
measures would be possible such as screening for a
Typhoid Mary. If it was possible to extract traces and/ or
contacts of a patient or nurse, an infectious (though
eventually healthy) person could be singled out. This would
further stop preventable infections. In our case,
generating a list of patient contacts may have been possible but
was not attended to.

The results from this case study can be generalized to other
healthcare facilities and HAI. First, the results are rather
independent of the HAI. As long as the specimen can be tested
and infections can be inferred in a similar way, it
does not matter whether we look at CDIFF, VRE, MRSA or any
other HAI. The improvement in IC, quantitatively and
qualitatively, was not achieved by testing infections more
efficiently but by shortening and enhancing the generic
process patterns around the realization of an infection. While
we only looked at IC processes, there are other
generic process patterns in healthcare which have potential for
process improvement. Examples in related projects
included but were not limited to patient discharge processes
including discharge letters and risk factor analysis for
congestive heart failure. Second, the results can be transferred
to any healthcare facility with a similar organizational
setup. The significant improvement in process lead time was
achieved by applying BPM principles to an already
existing clinical process which has to exist in every U.S.
healthcare facility. Thus, we would assume similar savings
for any facility with a comparable setup of the ICP. This
implies in particular ICP, who do not work 24/7 shifts but
have a regular eight-hour working routine without night or
weekend duty. We deem generalizing the results to IC
processes outside the U.S. possible, if similar IC measures to an

ICP are in place.
REFERENCES
Becker, J., M. Kugeler, and M. Rosemann. (eds.) (2003).
Process Management: A Guide for the Design of Business
Processes, (1st edition), Berlin: Springer.
Borst, F., R. Appel, R. Baud, Y. Ligier, and J. R. Scherrer.
(1999). "Happy Birthday DIOGENE: A Hospital
Information System Born 20 Years Ago," International Journal
of Medical Informatics (54)3, pp. 157-167.
Burke, J. P. (2003). "Infection Control: A Problem for Patient
Safety," New England Journal of Medicine (348)7, pp.
651-656.
569
Centers for Disease Control and Prevention (CDC). (2004).

"National Nosocomial Infections Surveillance (NNIS)
System Report, Data Summary from January 1992 through June
2004, Issued October 2004," American
Journal of Infection Control (32)8, pp. 470-485.
Davenport, T. (1993). Process Innovation: Reengineering Work
Through Information Technology, Boston, MA:
Harvard Business School Press.
Dewire, D. T. (2000). "Application Service Providers,"
Information Systems Management (17)4, pp. 14-19.
DiMasi, J. A., R. W. Hansen, and H. G. Grabowski. (2003).
"The Price of Innovation: New Estimates of Drug
Development Costs," Journal of Health Economics (22)2, pp.
151-185.
Doolin, B. (2004). "Power and Resistance in the Implementation
of a Medical Management Information System,"
Information Systems Journal (14)4, pp. 343-362.
Gardner, R. M., T. A. Pryor, and H. R. Warner. (1999). "The
HELP Hospital Information System: Update 1998,"
International Journal of Medical Informatics (54)3, pp. 169-182.

Hammer, M. and J. Champy. (1993). Reengineering the
Corporation: A Manifesto for Business Revolution, New
York, NY: HarperBusiness.
Harmon, P. (2003). Business Process Change: A Manager's
Guide to Improving, Redesigning, and Automating
Processes, San Francisco, CA: Morgan Kaufmann.
Health Level Seven. (1998). Health Level Seven Implementation
Support Guide for HL7 Standard Version 2.3,
http://www.hl7.org/special/ig/final.pdf (current 2008-10-20).
Health Level Seven. (2005). Arden Syntax for Medical Logic
Systems, Version 2.5, http://www.hl7.org (current 2008-
10-20).
Herbst, H. (1997). Business Rule-Oriented Conceptual
Modeling, Heidelberg: Physica.
Institute of Medicine (2001) Crossing the Quality Chasm: A
New Health System for the 21st Century, Washington,
DC: National Academies Press.
Johansson, H. J., P. McHugh, A. H. Pendlebury, and W. A.
Wheeler. (1993). Business Process Reengineering:

Breakpoint Strategies for Market Dominance, Chichester: Hohn
Wiley & Sohns.
Kohn, L. T., J. M. Corrigan, and M. S. Donaldson. (eds.)
(2000). To Err Is Human: Building a Safer Health System,
Washington, DC: National Academy Press.
Lenz, R. and M. Reichert. (2005). "IT Support for Healthcare
Processes," in Proceedings of the 3rd International
Conference on Business Process Management (BPM). Lecture
Notes in Computer Science Vol. 3649, W.M.P.
van der Aalst, B. Benatallah, F. Casati, and F. Curbera (eds.),
Nancy, pp. 354-363.
Magruder, C., M. Burke, N. E. Hann, and J. A. Ludovic. (2005).
"Using Information Technology to Improve the Public
Health System," Journal of Public Health Management and
Practice (11)5, pp. 123-130.
Mast, P., U. Ochs, W. Loewe, and K. Weise. (2004). "Aktueller
Stand in der Fallkostenabrechnung nach DRG: Sicht
des Finanzcontrollers," Trauma und Berufskrankheit
(6)Supplement 1 May, pp. 95-96.
Object Management Group Inc. (2006). Business Process

Modeling Notation (BPMN) Specification 1.0,
http://www.bpmn.org/Documents/OMG%20Final%20Adopted%
20BPMN%201-0%20Spec%2006-02-01.pdf
(current 2008-10-20).
Organisation for Economic Cooperation and Development
(OECD). (2006). OECD Health Data 2006: How Does the
United States Compare?
http://www.oecd.org/dataoecd/29/52/36960035.pdf (current
2008-10-20).
Panzarasa, S. and M. Stefanelli. (2006). "Workflow
Management Systems for Guideline Implementation,"
Neurological Sciences (27)Supplemental 3, pp. 245-249.
Porter, M. E. (1985). Competitive Advantage: Creating and
Sustaining Superior Performance, New York, NY: The
Free Press.
Pryor, T. A. and G. Hripcsak. (1993). "The Arden Syntax for
Medical Logic Modules," International Journal of Clinical
Monitoring and Computing (10)4, pp. 215-224.
Ricks, D. (2007). "Germ Warfare," Ms. Magazine (31)2, pp. 43-
45.

Shwe, M., W. Sujansky, and B. Middleton. (1992). "Reuse of
Knowledge Represented in the Arden Syntax," in
Proceedings of the 19th Annual Symposium on Computer
Applications in Medical Care, Washington, DC, pp.
47-51.
570
Siemens AG. (2007). Soarian®, http://www.soarian.com/
(current 2007-06-20).
Stevens, J. P. (2001). Applied Multivariate Statistics for the
Social Sciences, 4th edition, Hillsdale, NJ: Lawrence
Erlbaum Associates.
Tao, L. (2001). "Shifting Paradigms with the Application
Service Provider Model," IEEE Computer (34)10, pp. 32-39.
Teich, J. M., J. P. Glaser, R. F. Beckley, M. Aranow, D. W.

MIS Quarterly Executive Vol. 10 No. 2 Jun 2011 81© 2011 U.docx

Recommended

Recommended

More Related Content

Similar to MIS Quarterly Executive Vol. 10 No. 2 Jun 2011 81© 2011 U.docx

Similar to MIS Quarterly Executive Vol. 10 No. 2 Jun 2011 81© 2011 U.docx (20)

More from raju957290

More from raju957290 (20)

Recently uploaded

Recently uploaded (20)

MIS Quarterly Executive Vol. 10 No. 2 Jun 2011 81© 2011 U.docx