Sunteți pe pagina 1din 18

IDEA GROUP PUBLISHING

Building Automation into Existing Business Processes 177


701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USA IT5700
Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com

Building Automation into


Existing Business
Processes
David Paper
Utah State University, USA

Wai Mok
University of Alabama at Huntsville, USA

James Rodger
Indiana University at Pennsylvania, USA

EXECUTIVE SUMMARY
We embarked on a case study with the University Research Foundation (URF)1 to
document how a novel information system can automate information flow and streamline
inefficient business processes. The research methodology chosen was the action
research approach, as the researchers, along with three additional parties, were intimately
involved with the development and implementation of a novel information system we call
process manager technology (PMT). The goal of PMT was to automate discovery
disclosure (inventions and discovery of new methods) tracking. The results of the PMT
are mixed. Discovery disclosure tracking involves contract establishment, research and
development, ongoing monitoring, and close out of inventions and discoveries made by
principal investigators (PIs) working for URF. PMT development for the contract
establishment process has not yet begun. The research and development process is still
underway, but should be fully automated within the year. Ongoing maintenance has not
yet begun. Full automation of the “close out” process is in place and the manager in
charge of that process designed the system. The CEO of URF continues to champion
PMT for discovery disclosure. Once PMT has proven to be viable for discovery
disclosure, he wants to expand the scope to other processes within URF.

This chapter© appears


Copyright in the
2004, Idea book,Inc.
Group Annals of Cases
Copying on Information
or distributing in printTechnology 2004,
or electronic Volume
forms 6, edited
without writtenby
Mehdi Khosrow-Pour.
permission Copyright
of Idea Group Inc. is©prohibited.
2004, Idea Group Inc. Copying or distributing in print or electronic
forms without written permission of Idea Group Inc. is prohibited.
178 Paper, Mok & Rodger

ORGANIZATION BACKGROUND
Management of the discovery disclosure process is focused on the Space Research
(SR)2 entity within the aegis of the University Research Foundation (URF). This is
because SR houses the majority of principal investigators (PIs) involved in notable
(fundable) inventions and discoveries. SR is a not-for-profit research corporation owned
by URF. The URF is responsible for executive management, government/commercial
reporting, and operational management of SR (Dave Norton, personal communication,
March, 2002). SR has designed, fabricated and operated over 400 payloads, including
shuttle experiments, small satellites and satellite-based sensor systems. Core competen-
cies include infrared and hyperspectral sensor development, data compression and
processing, cryogenic systems, and sensor calibration. SR generates approximately $50
million dollars of funding (see Appendix A) for its various research projects (URF Annual
Report, 2002). The sources of funding by agency (see Appendix B) include the Ballistic
Missile Defense Organization (BMDO) 39.7%, Air Force 20.6%, Navy 18.6%, NASA
15.5%, Private 2.0%, Other DoD 1.5%, Other Federal 1.4%, National Science Foundation
(NSF) 0.4%, and state funding 0.4% (URF Annual Report, 2002).
Government agencies such as the Department of Defense (DoD), U.S. Space and
Missile Command, Naval Research Laboratory, Air Force Research Laboratory, Office of
Naval Research, and NASA require its funded recipients to report on project status
periodically (SR Corporate Compendium, 2002). Also, each time a project is officially
closed, the funding agencies require proper documentation and notification. Since the
existing information systems (IS) infrastructure is not capable of accurately dealing with
the SR status reporting complexities, URF management is constantly under extreme time
pressure to develop accurate and complete reports to project sponsors.

SETTING THE STAGE


Discovery disclosure involves tracking the progress of inventions and discoveries
made by PIs. Discovery disclosure is actually four major activities % contract establish-
ment, research and development, ongoing monitoring, and close out. Contract establish-
ment involves registering the discovery or invention with the funding agency and all of
the associated paperwork. Research and development involves all of the support
provided by URF management to PIs before and during the contract or grant period.
Ongoing monitoring involves tracking the progress of a contract or grant on a periodic
reporting basis. Close out involves properly reporting evidence of promised discoveries
and inventions to the funding agency and all the associated paperwork.
Twelve months ago, URF had no automated means of tracking the discovery
disclosure process. Managers had to manually track down PIs to inquire about the status
of various projects.
It is the responsibility of research and development managers to help PIs secure
information about related contracts and grants to maintain a continuous flow of funding.
Research and development is therefore involved before contracts and grants are secured
as well as during the project activity period. However, the information they need to do
their jobs requires them to personally contact PIs on an ongoing basis even though PIs
are recording their activities on the system. The reason for this problem is that the

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 179

systems don’t talk with each other and are not integrated. Hence, management cannot
use the power of technology to secure even the simplest project information in a reliable
manner.
Once PIs secure a contract or grant, management assists with all of the associated
paperwork involved in proper establishment. Once the contract or grant is established,
PIs are supposed to systematically record all of their activities associated with a specific
contract or grant including deliverables and deadlines. However, lack of an integrated
system to query and monitor these activities from a management standpoint force
personal contact with PIs for reliable information. This routine becomes tiresome due to
the large number of PIs, each with multiple contracts and grants.
Management is also responsible for project close out. Close out of a project was
difficult at best because information from the PI was not necessarily complete and had
to be trusted at face value because there was no means to verify the information. Also,
it was impossible to track projects on an ongoing basis because there was no means to
push PIs to record progress on a contract or grant.
The CEO of USF (Dave Norton) therefore decided to undertake an IS development
project to facilitate automation of discovery disclosure tracking. He approached us
because he had heard that we were working on a novel information system called process
manager technology (PMT). PMT is based on a tree-based architecture that utilizes a
relational database and a directory system. The database stores relational records while
the directory stores profile information. PMT uses a tree traversal approach (similar to
directory traversal upon which UNIX/Linux is built). PMT is designed so that a non-
technical person can either work with a designer or design a process or set of processes.
PMT allows the designer to set up a set of actions at each stage of a process. The catalyst
for the actions is based on a question or set of questions at each node of the tree. The
actions can be calculations, queries to a database, searches in a directory, and/or asking
another set of questions. The actual user of the system (once the processes are designed
using PMT) then moves through the trees based on his or her answers to the questions
presented. Since PMT is designed to work with a centralized database and directory,
everyone in the organization is traversing the processes (implemented through a series
of tree decisions) in the manner intended by the designer. The real value of PMT lies in
its ability to enable actual processes to be readily built into the system. The manager who
best understands the process either builds the trees with PMT or works directly with a
designer to build the trees. No programming is involved.

CASE DESCRIPTION
We situated this study in the business process redesign (BPR) literature, as the goal
of the research is to facilitate automation and streamlining of the discovery disclosure
tracking process. BPR literature is oriented toward practice in organizations (Sarker &
Lee, 2002). However, there exists a call to the academic community to strive toward
“understanding models and attributes of successful BPR” (Grover & Kettinger, 1995, p.
viii). In its existing state, BPR literature largely represents a form of knowledge (theoreti-
cal perspectives or theories-in-use) falling within the realm of practitioners (Sarker &
Lee). The theories-in-use include technocentric, sociocentric, and sociotechnical (Sarker
& Lee).

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
180 Paper, Mok & Rodger

Technocentric theory views information technology as an independent force


determining aspects of an organization at different levels of analysis (Markus & Robey,
1988; Orlikowski, 1992). As such, BPR adopts a technology-driven methodology to lead
initiatives (Hammer & Champy, 1993; Lucas & Baroudi, 1994). Markus & Benjamin (1997)
argue that managers involved in BPR think that IT itself has the power to create
organizational change.
Sociocentric theory assumes that organizational outcomes occur not due to the
technology but due to human motives and human action (Sarker & Lee, 2002). Within the
sociocentric perspective, BPR is believed to be influenced by the process vision of
redesign leaders and the composition of the reengineering team. The BPR leader should
act as the visionary and motivator of the effort (Hammer & Champy, 1993). To ensure a
variety of perspectives and to reduce resistance from different functional areas, cross-
functional representation is considered good practice when building a BPR team
(Davenport, 1993; Hammer & Champy, 1993).
Sociotechnical theory assumes that the dynamic interplay between the actors,
context, and technology should be the focus of BPR (Markus & Robey, 1988). The
assumption is one of balance between the technocentric and sociocentric views of BPR.
As such, social and technical design must be performed in conjunction (Manganelli &
Klein, 1994).
We embrace the sociotechnical perspective in this research. We are introducing a
technology (PMT), but are aware of the social ramification involved in such an under-
taking.
The research concerning the URF discovery disclosure process began in early
October 2001. We were charged with developing an information system to automate the
discovery disclosure process. The scope of the “intended” system was limited to the
discovery disclosure process, but the CEO desires to expand the boundaries of the
system to all URF processes over time.
The legacy (existing) system was unable to credibly track the discovery disclosure
process. As a result, URF management found it extremely difficult to assimilate and
compile an accurate accounting on the status of federally funded research projects.
When reports to funding agencies were due, URF management found itself physically
tracking down PIs to find out project status because disclosure information stored in
database records could not be trusted for accuracy. That is, there was no mechanism in
place to force PIs to disclose when a project was completed. Not only is this manual
process a waste time and money, it is in violation of the guidelines set forth by funding
agencies. PIs were not disclosing inventions in a timely manner, if at all. This was
especially stressful in that URF is responsible for contract disclosure, not the PIs (even
though PIs are the discoverers).
The legacy system was developed over fifteen years ago and is not integrated.
Modifications to the system are done from an applications rather than a database
perspective. That is, the database schema does not drive development. Development is
thereby not well-structured and poorly aligned with higher-level business objectives.
Human resource information processing is handled outside the URF IS department by
the Human Resource Department. Personnel and financial information processing are
handled within the IS department, but on different systems. Operations information
processing is also within the auspices of IS, but on yet another system. Human resource

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 181

information is queried from the Human Resources Department at the end of the month
and manually fed into applications built on one of the URF databases. The database
schema to handle processing is spread out to almost two hundred separate database
tables and is very complex. Personnel, financial, and operations information is pulled
together by applications to consolidate for month and year-end reporting purposes. Each
time a new report is needed, an application must be written because the database schema
is not truly relationally sound. Without a relationally sound database, an ad hoc report
cannot be created with a simple SQL query.
The CEO was interested in PMT because it offers a means to centrally store
organization-wide data while enabling user access to the data they require (given the
proper security clearance). The CEO’s long-term vision is to eventually move all URF data
to a central database repository and directory system with PMT as the interface tool for
process design and tree traversal. The other systems (legacy) may still exist in some form,
but the data needed to support the discovery disclosure tracking process will be in the
central repository. That is, PMT, the central database, and central network will be the only
place where discovery disclosure data is accessed and stored. In addition, the profiles
for all URF personnel will be stored in a central directory system. A profile record contains
descriptive information (e.g., name, address, phone, etc.), security information (e.g.,
clearance level, node access within the set of trees that represent the processes,
identifiers by job title, etc.), and employment history.

Implementation Specifications
Over the past 18 months, we were involved in numerous meetings at the IS systems,
middle management, and executive levels. Weekly meetings with the IS team were held
to make sure that we adhered to URF technology implementation protocols. We also
discussed obstacles to implementation such as security firewall coordination, encryp-
tion/decryption matching, and phasing issues involved in development to production
technology movement. Periodic meetings with contracts and R& D managers were held
to obtain process flow information to properly design the system to URF business
specifications. Bi-weekly meetings with the CEO and other managers were held to discuss
change management issues, technical roadblocks, and progress. To better address
unforeseen bottlenecks, special meetings were held. These meetings were split into two
categories – technical and managerial. Technical issues were addressed in special
meetings with our team, the CEO, and the IS team. Managerial issues were addressed in
special meetings with our team, the CEO, and managers involved in the bottleneck.
Testing the early PMT was conducted from early June 2002 through August 2002.
By early September 2002, PMT was fully functional and ready to move to production. A
culmination of intense and ongoing work with the IS team, management, and the CEO
allowed us to meet our goals as scheduled. PMT successfully enabled business
managers at URF, the CEO, and PIs to develop their processes. That is, they can now
request their own information from the system when and where it is needed. Their
information is returned by SQL queries on the database engine (DB2/IDS, formerly known
as Informix). The IS team handles all query programming.
PMT is continuously tested with managers involved with discovery disclosure. We
are also working very closely with the IS team to ensure proper integration with existing
protocols. The IS team is charged with making sure that PMT works seamlessly with

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
182 Paper, Mok & Rodger

existing database, networking, security, and intranet production systems within URF. Of
course, the future plan is to have PMT replace the legacy system. However, the legacy
system cannot be replaced in the short run so PMT must work with it for the time being.
PMT is currently being moved out of the development phase into “production.” The
timeline for making production is tentatively scheduled for September 2002. At URF,
“production” means that the system is a working part of the URF IS infrastructure and
that system components are “safe” behind security firewalls and encrypted passwords
and identifiers. The goal of the CEO is to have PMT working, completely functional, and
being used by key managers to track discovery disclosure by the end of the year 2003.

Research Methodology
We were hired by the CEO of URF to design, develop, and implement PMT to
automate and streamline the discovery disclosure process. As such, we were “active
participants” in the project. According to Creswell (1998), a qualitative approach is
necessary when research must be undertaken in a natural setting where the researcher
is an instrument of data collection, data is analyzed inductively, the focus is on the
meaning of participants, and a process needs to be described. Qualitative researchers
want to interpret phenomena in terms of the meanings people bring to them (Lincoln,
1995). Selection of a qualitative approach should flow from research questions that
attempt to answer why or how questions (Yin, 1994), so that initial forays into the topic
describe what is going on (Creswell).
The intention of the research was to introduce an IS that automates and stream-
lines the discovery disclosure process at URF. We were also responsible for the
education and training of managers to assist them in using the system to develop their
own processes based on their own needs. From a problem solution perspective, we were
hired to automate and streamline processes associated with discovery disclosure
tracking.
Based on the research question, we adopted the qualitative tradition of action
research. Action research is a “deliberate, group or personally owned and conducted,
solution oriented investigation” (Boomer, 1987, p.8). Anderson, Herr, & Nihlen (1994)
define it as “insider research done by practitioners using their own site as the focus of
their study ... [it] is oriented to some action or cycle of actions that practitioners wish to
take to address a particular situation” (p.2). Action research is problem focused, context
specific, and future oriented, and aims at improvement and involvement (Hart & Bond,
1995). It is continual disciplined inquiry conducted to inform and improve practice
(Calhoun, 2002). According to Kember & Kelly (1993), action research is a practical
research methodology that requires three conditions to be met. First, its subject matter
normally is situated in a social practice that needs to be changed. Second, it’s a
participatory activity where the researchers work in equitable collaboration. Third, the
project proceeds through a spiral of planning, acting, observing, and reflecting in a
systematic and documented style.
Our study adheres to the principles of action research. Our research was conducted
on site where the project was taking place. We focused on a specific problem that was
context specific with the goal of improving information flow related to disclosure. Our
goal was to inform those involved and improve practice. We worked equitably in
collaboration with all parties. We approached the project and research in a systematic

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 183

manner in accordance to the “spiral” approach touted by Kember & Kelly. We took
copious notes at all meetings, shared and discussed such notes with our research team,
and reflected on activities, problems, and solutions throughout the entire project.
Consistent with Swan (2002), we adopted an iterative approach to the design of our
system during our action research activities. We adhered to a constant process of
revisiting the problem(s), re-analyzing processes, and synthesizing revised solutions.
We faced another challenge in that we were dealing with scientists and engineers.
Dave Norton (URF CEO) helped us better understand how scientists perceive the
discovery disclosure process, which aided our design. “Scientists want to get to the
bottom of things. They want to create optimal solutions to tangible problems. Managers
and designers want to reach consensus and solve problems in a way that adds value to
the enterprise. That is, they look at providing an holistic solution in contrast to an optimal
one” (Dave Norton, June, 2002).

Interview Methodology
We used all six sources of evidence – documentation, archival records, interviews,
direct observation, participant observation, and physical artifacts – to collect data as
advocated by Yin (1994). Documentation includes letters, memoranda, agendas, an-
nouncements, proposals, reports, studies, clippings, and other internal/external docu-
ments. Archival records include service records, organizational records, database
records, maps, charts, lists, survey data, and personal records. Interviews are face-to-
face interactions where researchers directly question respondents to collect primary
information within the context of a study. Direct observation is when researchers make
a site visit and watch people in action. Participant observation is when the researcher is
actually engaged in the project. Physical artifacts include technical devices or other
physical evidence. In our case study, the computer systems were our artifacts. Although
we used all six sources of evidence, the two main vehicles for data collection were
interviews and participant observation.
Consistent with Patton (1987), we triangulated the data based on evidence sources
and idea comparison/evaluation among the researchers. That is, the researchers met on
a weekly basis to discuss project progress, compare and evaluate notes from interviews
and observations, and revise/formulate research strategies. Data triangulation increased
the overall quality of our findings because multiple patterns of evidence are collected and
analyzed (Yin, Bateman, & Moore, 1983).
We formerly interviewed the CEO on at least a dozen occasions. Each interview
lasted from 1-3 hours depending on the topic and problems at hand. Interview notes
were subsequently transcribed within two days to reduce inaccuracies that can be
caused by memory fade (Yin, 1994). Transcribed notes were read, re-read, and indepen-
dently evaluated by the researchers to reduce biases and increase confidence in the
results. Informal interviews were conducted with managers, PIs, and technical people on
numerous occasions. Notes from these interviews were treated in the same manner as the
formal interviews. We gleaned massive amounts of information from our participation in
the project. As participant observers, we were able to work closely with managers, the
CEO, and IS people on almost a daily basis for almost one year. This method of data
collection is consistent with Swan’s (2002) spiral approach to action research because

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
184 Paper, Mok & Rodger

we were able to clarify issues through repeated interactions (iterations) with respon-
dents.
We had formal discussions, meetings, and interviews with Dave Norton (CEO,
URF), Keith Paskett (Networking Infrastructure Manager), Laurie Littledyke (DBA), Jerry
Poulsen (Manager of IS), Pat Patterson (R&D manager), Rick Shelton (Web Coordinator),
and Jon Baxter (Contracts Manager). We had informal discussions with all the above and
Melanie Pond (HR manager) and Brent Miller (member, URF Board of Directors).
Due to the confidential nature of the contracts and grants awarded to SR, we were
always diligent with the use of our data. Dave Norton formally cleared the contents of
this report. Melanie Pond formally cleared the human resource (HR) information we
needed to test our prototype with production data. She educated us on the use of HR
information at URF.

Data such as employee title, start date and termination date, SSN, is consid-
ered to be HR Confidential ... We ask that you insure that HR Confidential/
Protected Information is controlled from unauthorized disclosure. By policy,
each employee will disclose or transfer only to authorized individuals or
entities government and/or URF Protected Information or material (personal
communication, Melanie Pond, August 2002).

Automation and Streamlining with PMT


PMT allows managers to automate their own processes because they either design
the trees themselves or work with designers to accomplish the same thing. PMT
streamlines the process because managers can get the information they need from PIs
through a system of their own design. Once the manager designs the process, the
centralized nature of PMT enables PIs to very easily enter project data from their
locations. The data is stored centrally so that anyone with proper access clearance can
see the data. This is in sharp contrast to the legacy system because the data was stored
multiple times in multiple locations making access difficult and data accuracy (synchro-
nization) even more difficult. Legacy data access was so difficult because the lack of
system integration made it almost impossible for the manager to know where a particular
PIs data was stored. Data accuracy was also a problem because PIs were asked to store
data in multiple locations making data synchronization very difficult. If a PI or manager
was lucky enough to find the data they needed, access was still difficult because then
one had to identify who was responsible for the data in that particular database and then
get clearance from that individual to the data.
PMT required dramatic changes to the existing technology infrastructure, it also
required a paradigm shift in the way managers interact with technology. The PMT
infrastructure uses a centralized repository that is by nature integrated because there is
only one database and one directory. The paradigm shift offers a drastic streamlining in
the legacy infrastructure: from multiple, non-integrated servers with a variety of data-
bases and directories to one centralized database and directory. Dave Norton realizes
that the infrastructure change will take several years. Hence, legacy systems must stay
in place until conversion is complete. “Conversion to an integrated infrastructure will
take at least four years. In the meantime, people must still be able to access the system

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 185

so we must keep the legacy operating with all its faults and inefficiencies” (Dave Norton,
March 2003).
Process change is a multiyear endeavor because it requires years to change legacy
systems and the supported processes. Core processes are not streamlined because a
contract still must be researched, established, monitored, and closed out. Streamlining
is occurring with supporting processes. With contract close out, managers can now use
PMT to track activities rather than physically tracking down PIs and data owners.
Research and development is not completely converted to PMT because the managers
in this area are still refining process design. Contract establishment and ongoing
monitoring are the next processes to be targeted for automation. “My vision is to convert
discovery disclosure to the new system within the next 2 or three years. These things take
time” (Dave Norton, October 2002).
Besides automation of data entry and retrieval by PIs and managers, PMT provides
managers with direct control over the design of their processes without the need for
computer programming. As a result, both the IS team and management had to rethink the
way they operated. Managers are beginning to understand the power of PMT because
they have the knowledge of their processes. “In the past, we would bypass the system
if we could get the information we wanted elsewhere because it was hard to use,
sometimes not accurate, and IS was difficult to work with” (Jon Baxter, June 2002). The
IS team is still struggling with the new paradigm but is beginning to grasp the vision of
the CEO. Laurie is now in charge of PMT development from an IS perspective. We
therefore believe that she is much more comfortable with the change because she has
ownership.
Change is difficult in any setting, but radical change is even more difficult to
manage. In pursuing the edicts of the research question, we explored both the technical
and social aspects of the case. We first discuss the technical and then the social issues.
This sociocentric approach is consistent with Sarker & Lee (2002).

Technocentric Issues
The CEO was instrumental in helping us “think through” the complexities of the
various layers of technology, management, actual processes versus perceived pro-
cesses, politics, and how the various players interact with each other and the system.
He also designed a chart that illustrates the entire discovery disclosure process from his
perspective. However, the actual process activities as they occur at URF may have many
variations. The CEO doesn’t mind these variations as long as the job gets done. “My goal
is to automate, as much as possible, discovery disclosure and other URF processes over
time. PMT provides a paradigm and tool to do this in my estimation. Of course this will
take patience and people management” (Dave Norton, January 2003).
At URF there are three main technology layers – hardware, software, and database.
Hardware includes servers, workstations, desktop PCs, controllers, routers, switches,
power lines, hardware firewalls, wires, and connectors. Software includes business
applications, Intranet applications, software firewalls, password protection, encryption,
and software authentication. Database includes users, roles, profiles, tables, scripts,
backup/recovery, replication, query authentication, and database authentication. “Man-
aging the complexities involved with our technology infrastructure are enormous, but

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
186 Paper, Mok & Rodger

they pale in comparison to complexities involved in managing people, politics, and their
interactions with complex technology” (Dave Norton, August 2002).
The IS department culture is “legacy-oriented.” That is, each area (database,
networking, and applications) has their own systems and does not naturally share
information or technical schemas. Management does not control (or even attempt to
control) the political climate of the IS department. Hence, IS has the freedom to implement
systems as they choose. As such, system proliferation without a sense of integration has
emerged over time. “New applications, especially those that potentially breach our
firewall must go through my system” (Laurie, October 2002). “My job is to control
network traffic. If you have a problem with an account check with Laurie but I also manage
security accounts, so we may have to create one here too” (Keith, July 2002). “If we
implement PMT, I need a new server to handle the extra load. We are almost at capacity
now” (Jerry, August 2002). Testing PMT with managers was very easy, but testing with
IS was a nightmare. Each time we needed access to data, a user account, security
clearance or any other action, we encountered resistance, subterfuge, stalling, and
hostility with the IS group. In our opinion, they were only concerned with their particular
system. Laurie, Keith, and Jerry were each in charge of multiple systems. We also noticed
tremendous overlap in data, accounts, and security protocols. That is, user information
was stored multiple times in multiple locations without a systematic schema to synchro-
nize the information.
PMT provides a deviation from the status quo. It incorporates a relationally sound
database schema and is designed in a way that fosters easy alignment with high-level
business objectives. We had an argument with Laurie concerning the relational sound-
ness of “her” database. “My system is relational sound for Informix” (Laurie, November
2002). We retorted by informing her that relational soundness is independent of any
database. It is a theoretical construct. We gave up on the argument to reduce hostilities.
Our system also incorporates a directory structure to store people profiles. In this way,
it is much easier to handle security and customization for people because all of this
information is stored in a directory. The database stores ideas and discoveries while the
directory stores information about PIs and managers. We are still confused about who
is responsible for regular user accounts and profile accounts. Laurie is responsible for
some user accounts, but Keith is responsible for others. Keith is responsible for profile
accounts, but it seems that Laurie is also involved with creation of these accounts even
though this is definitely not her job responsibility. Laurie also develops and maintains
several non-integrated applications, but again this is not her responsibility.
In this case, we found that legacy systems are much more than hardware and
software. Without system integration they provide fertilizer for system proliferation, data
overlap, and data/application dependence. As such, data accuracy is always a question,
data access is very difficult, and systematic reporting is very undependable.

Sociocentric Issues
Emergent social issues included politics, resistance to change, and managerial
dynamics. Each emergent issue is now discussed.

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 187

Politics
Implementation involved four groups of constituents. Namely, the CEO, business
managers, researchers (consultants), and the IS team. As consultants, we were charged
with PMT introduction and follow through at the behest of the CEO (Dave). We had to
work closely with business managers (Pat and Jon) and the IS team (Jerry, Keith, and
Laurie) to make the system work.
Working with business managers was a lesser challenge because PMT was devised
to benefit managers directly. The novelty of PMT is in its design that enables non-
technical people to build their own process structure. That is, it allows them to design
a process or set of processes with no programming. Their process set is able to branch,
set variables, execute queries, and even do calculations through an easy-to-use graphi-
cal interface.
Both Pat and Jon were asked to design a process that would be optimal to get their
work accomplished. Jon completed his contracts process within a few days and was
excited at the prospect that his design could be implemented exactly to his wishes. “This
is great. I never thought that I could build a process by myself” (Jon, June 2002). Pat took
at least two weeks to design his process for R&D, but told us “It took me a bit longer
because I wanted to discuss the design with my engineers. I am excited that it seems to
work” (Pat, July 2002). Actually, we had no political issues with these two managers.
However, they expressed issues with IS. “We have to beg the IS people to give us data.
This isn’t right” (Pat, June 2002). “I try not to ask IS for much because I know that I never
get what I want. I just have to chase people (PIs) down as necessary” (Jon, June 2002).
Working with the IS team was a completely different story. We found that each IS
person had their own “turf.” That is, Laurie was in charge of databases. Keith was in
charge of networking and security. Jerry was the IS manager. Each controlled every
aspect of their respective realms. To get access to a database, network or any other aspect
of IS required approval by the person in charge of that area. On the surface, this doesn’t
appear to be a problem, but even after we secured approval from the CEO to gain access
to a resource we still had to get another approval from one or more of the IS people. We
were under the impression that the IS team worked for the CEO, but our perception was
that the IS team had final approval of any mandate. Keep in mind that we were forced to
go through this approval process each and every time we needed something that had
already been cleared by the CEO. On several occasions, we were actually told that there
was no way for us to gain access to the resource. As such, we had to go back to the CEO
and convey to him our problems with IS. Dave (the CEO) would always diffuse the tension
by saying “they just need time so be patient.”
Our frustration was typically high because, although we had the mandate from the
CEO, we had no real authority to obtain access to the resource. The control by IS was
absolute. This circuitous process of gaining access to IS resources continued through-
out the project and continued to frustrate us. Specifically, we were faced with denials on
every request we made for access to the existing systems. “You cannot get behind our
firewall because this is a prototype” (Laurie, June 2002). “The security database is not
set up for this system” (Keith, July 2002). “It’s not my problem” (Jerry, August 2002). Of
course comments like these were made on numerous occasions. Without help from the
CEO, we never would have gotten any access to any resources.
In addition, we faced overlapping issues. For instance, Laurie kept a database of
users, but Keith kept his own database of users. As such, data was duplicated and not

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
188 Paper, Mok & Rodger

synchronized. As such, it was very difficult to keep the data up-to-date and accurate.
Also, applications were accessing the same data from more than one database. We
believe that this is very dangerous because the data used by these applications involves
salaries, grant and contract monies, and secure information. Also, Laurie had student
workers program applications for URF, but this was not her charge. She was responsible
for database administration. She therefore became involved in areas where (we believe)
she lacks the appropriate expertise. As an example, she criticized our system during
almost every meeting with no real understanding of what the system intended to
accomplish and how we envisioned the system to be integrated with legacy systems.
Keith and Jerry also built programs, but with no overall organizational schema. As a
result, we believed the root problem to be that there existed no overall design for the
database and systems. Moreover, the existing systems were not aligned with the
business objectives at URF.
Dave understood all of these problems very well, but gave us no real authority to
push the IS team into the best direction (in our opinion and Dave’s) to get PMT
implemented properly and on time. Keep in mind that Dave was the person who brought
us in to implement the system in the first place. We admit that Dave was instrumental in
moving the project along, but we wished on numerous occasions that we had the political
clout to make things happen faster.
In all, we discovered that Dave already knew of the chaotic nature of database
design and systems maintenance. “It’s why I was intrigued with your system. I have
already designed the entire process flow for URF, but IS is not on board yet. Actually,
my experience is that business is 99% politics. Change is very hard on people so we do
need some patience” (Dave, September 2002).

Resistance to Change
“Resistance to change is typical. People feel threatened and perceive that their job
is at stake or at least that they are not doing something right” (Dave, September 2002).
It took our team less than three months to build and implement the prototype in a quasi-
production environment. The remaining nine months to move the prototype to a secure
production environment was due to politics and resistance to change. Laurie was fearful
that our prototype would compromise the existing databases and programs. Keith was
afraid that the network would be compromised if our system concepts were implemented.
Jerry just wanted a new server from Dave. Of course, we knew that we were on the correct
path because Dave was leading us and the IS team.
“How will your database schema fit with ours? What is your migration proposal?
Please come talk to me” (Laurie, September 2002). Questions like these came up at every
meeting. Moreover, even questions addressed several times seemed to keep reoccurring.
The schema and migration proposal were mandated by Dave so we merely did what we
were told to do. However, we lacked any real authority to move the IS team to our wishes.
Needless to say, lack of power is very frustrating especially when one is under
tremendous time pressure.
“Go talk to Keith. Keith has the user accounts” (Laurie, August 2002). “No, Jerry
is responsible for this. You probably should talk to Laurie first because she has the users
even though Jerry is in charge” (Keith, August 2002). “Laurie is in charge of users. Talk
to her” (Jerry, August 2002). This “runaround” was common throughout the project.

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 189

Many times, we had meetings with Dave to get advice on how to deal with the IS team.
We believe that the structure of IS was not systematic. We also believe that running us
around was an attempt to deflect criticisms.
We concluded that the IS team was so resistant because they felt threatened. It is
true that our system forces some semblance of structure and logic onto the existing
system. Since the IS team is responsible for the system, we believe that their perception
of the situation could be construed as outsiders calling them incompetent. In all honesty
we believe that incompetence, lack of planning and design, and lack of proper oversight
exists in this area and should be addressed.

Managerial Dynamics
Management was very excited about the new system. The reason for this in our
opinion is that our system was designed to help management obtain the information they
need when they need it. Once we explained the potential of our system and how it works
conceptually, we faced little resistance. Of course, we did face resistance from one
manager (not listed because he chose to remain anonymous). He wanted nothing to do
with our system and only said “Your system cannot work. It doesn’t follow established
systems implementation principles.” He refused to participate. Dave was reticent to push
this manager into doing something he was uncomfortable doing. As such, we made no
further effort to include him in the prototyping process.

CURRENT CHALLENGES/PROBLEMS
FACING THE ORGANIZATION
The main challenge was dealing with resistance to change. The IS department was
very resistant to PMT because historically they have controlled design, development,
implementation, and maintenance of all IS at URF. PMT rests some control from IS and
gives it to management. IS is still charged with management of the database and directory,
but (with PMT) managers are able to design their own processes consistent with their
needs.
PMT would not have been developed without a strong mandate from the CEO. Even
with this mandate, resistance from IS was fierce until ownership of PMT development was
passed to Laurie. In truth, IS does lose power because they cannot coerce management
into accepting “their” view of what applications can and cannot deliver. With PMT, the
IS team is responsible for system development, maintenance, and keeping it running.
They are no longer responsible for process design. Managers have been much more
receptive to the changes PMT has brought and will bring about. Their receptivity is most
likely because PMT is geared toward helping them do their jobs better by saving them
time and energy. That is, PMT puts process design into the hands of management. Of
course, it took us a few hours of explanation and training to help the managers understand
what PMT offers and how they can be a part of the design and development process.
Another challenge was educating managers. Managers are not used to having
control of any kind when it comes to the design and development of IS. As a result, we
worked with managers to show them how PMT works and how easy it is to design
processes. One of the managers (Jon) was able to successfully design the “close out”

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
190 Paper, Mok & Rodger

of a discovery in a matter of hours. We spent less than two hours training him and then
he went back to his office and designed his processes through a web interface that we
provided to easily interface with our system. His design, as currently built, works with
real (production) data. Another manager (Jon) is in the process of mapping the design
for research and development activities. The design is incomplete only because he is still
trying to get buy-in from some of his workers and has been distracted by other duties.
A third process is underway concerning development of tracking discoveries from
inception until right before “close out.” This process (ongoing monitoring) is incomplete
because the manager assigned to this task has left the organization. The CEO (Dave)
hasn’t yet made a new assignment to fill this void. Dave has put contract establishment
on hold until research and development is complete.
Stemming the tendency to go back to the “old process” is another very important
challenge. We perceive that the IS team wants PMT to fail because they feel it is a threat.
However, since the appointment of Laurie as PMT project manager, the threat seems to
have dissipated pointedly. Although managers like what PMT does for them, they are
not in a position to force IS to continue development. The CEO believes strongly in the
potential of PMT, but we hope that he is willing to continue expending political capital
to keep PMT on track into the future.
The CEO seems to be non-confrontational when it comes to making hard decisions
related to IS policy. He used us as the liaison between IS and management, but gave us
no authority to enact change. However, his appointment of Laurie as PMT project
manager has taught us that he may know much more about dealing with change than we
do. After all, he is the CEO.
A more abstract challenge is that managers tend to accept what IS tells them at “face
value.” That is, they don’t question the flaws in an IS because they are used to IS not
working as promised. Our research team (either individually or as a group) has experi-
enced this to be the case with at least a dozen other IS development projects. Every
business manager that we have spoken to over the years has relayed a story to us about
how “their” IS never met budget and never delivered as promised. As this project
unfolded, we have noticed a change in manager’s attitudes toward the capabilities of IS.
Because managers are able to easily and successfully build their own processes into the
system, they now believe that IS can deliver what they expect. The manager of
commercialization is the only exception, but he decided to not become involved in the
project from the beginning. We believe that his aversion to our project is politically
motivated based on e-mails shared with us from the commercialization manager to the
CEO regarding our project. The e-mails were very negative about our project even though
the commercialization manager had no involvement in our project.
Our mandated goal from this project was to automate the discovery disclosure
tracking process. As such, we were charged with streamlining the existing process and
using PMT to automate. We have had some successes and some failures, but the CEO
has told us that he is committed to PMT for the long run. In his mind, we need to be more
patient. “I have been in the business for over 40 years. It takes time to enact change. In
my experience, people react with hostility to change at first. They do there best to stop
it or ignore it. But after some time, they get used to it” (Dave, March 2003).
In the end, proper tracking of discoveries is critical to the overall health of the
organization. “My goal is to double the size of URF in a few years. We can’t do this unless

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 191

we can leverage our inventions for profit. If we have poor tracking, our documentation
will be poor. This opens the door for others to effectively steal our ideas for money. We
can’t fight this if we can’t document inventions properly. Also, the existing system
wastes management time, which effectively reduces profits” (Dave, April 2003).

CONCLUSION
The patterns that emerged from the bounded case validate those in the literature.
Politics has been cited as a major issue in change projects. This case is no exception.
Political turf battles, especially within the IS team, caused many delays and problems with
the implementation. One very interesting finding of our study was the very low resistance
from management. Of course, this is logical because we made every attempt to convince
management a priori of the potential benefits of the system to help them obtain
information they need for reporting in an easier and faster manner. Resistance to change
was another dynamic that paralleled the literature. When people fear that their job is in
jeopardy or that their daily activities may change in anyway, they tend to resist. Our
system is causing changes to the way work is done, especially in the IS realm. This is
probably why they are the most resistant to the new system. Dave understands this
resistance but is mandating these changes to update the problems with existing systems
and prepare for future growth of his organization. Finally, top management is paramount
to successful change. Without continuous support from Dave, PMT wouldn’t have had
any chance of success. Again, this issue is consistent with the literature. Our results are
consistent with Sarker & Lee (2002) in that process redesign requires a sociotechnical
theoretical lens to be documented and perceived accurately.
An interesting and important move Dave made in the past few months was to
appoint Laurie to spearhead PMT development efforts. It took us some time to figure out
why Dave made this move. Our work is now “winding down” and someone internally is
needed to continue implementation for new processes. As Laurie was forced to accept
the new system, we believe that her resistance naturally faded because she really had no
choice. Since she is the DBA and will continue to be in this position, Dave wants to move
ownership of PMT to the IS team. He figured that Laurie is the best qualified and was the
most resistant to change. We’ve noticed that her attitude is much better now as she gains
ownership of the project. Again, our findings match the literature.
We asked Dave why he didn’t appoint her sooner. “In my experience, resistance to
change is not a bad thing necessarily. It is only bad if it is not recognized and dealt with.
I believe that people need to have some jolts to their routine to wake them up. However,
if they don’t understand what is happening, the project will fail. So, this is why I waited.
Now Laurie has a better grasp on the project and can lead” (Dave, February 2003).
With resistance to change, fear, turf battles, and assorted political forays, PMT
continues toward full production status. The process built by Jon is in production,
research and development will be in production soon, and development of the two
remaining processes (contract establishment and ongoing monitoring) is continuing as
of March 4, 2003. Resistance to change has lessened since Laurie was appointed PMT
project manager. Dave still believes in the PMT vision and continues to promote his
vision for the future. In addition, we learned that we have a lot to learn about change
management as evidenced by our impatience to see change happen more quickly.

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
192 Paper, Mok & Rodger

REFERENCES
Anderson, G., Herr, K., & Nihlen, A. (1994). Studying your own school: An educator’s
guide to qualitative practitioner research. Thousand Oaks, CA: Corwin Press,
Inc.
Boomer, G. (1987). Addressing the problem of elsewhereness: A case for action research
in schools. In D. Goswami & R. Stillman (eds.), Reclaiming the Classroom: Teacher
Research as an Agency for Change (pp. 4-13). Portsmouth, NH: Boynton/Cook
Publishers.
Creswell, J. W. (1998). Qualitative inquiry and research design: Choosing among five
traditions. Thousand Oaks: Sage.
Cross, N. (1989). Engineering design methods. England: John Wiley.
Calhoun, E. F. (2002). Action research for school. Educational Leadership, 59 (6, 18-24.
Davenport, T. H. (1993). Process innovation: Reengineering work through information
technology. Boston: Harvard Press.
Grover, V., & Kettinger, W. J. (1995). Business process change: Reengineering concepts,
methods,and technologies. Hershey, PA: Idea Group Publishing.
Hammer, M., & Champy, J. (1993). Reengineering the corporation. New York: Free Press.
Hart, E., & Bond, M. (1995). Action-research for health and social care: A guide to
practice. Open University Press.
Kember, D., & Kelly, M. (1993) Improving teaching through action research.
Campbelltown Australia: Higher Education Research and Development Society of
Australasia Inc.
Lincoln, Y. S. (1995). Emerging criteria for quality in qualitative and interpretive research.
Qualitative Inquiry, 1, 275-289.
Lucas, H. C., & Baroudi, J. (1994). The role of information technology in organizational
design. Journal of Management Information Systems, 10 (4), 9-23.
Magnelli, R. L., & Klein, M. M. (1994). The reengineering handbook: A step-by-step
guide to business transformation. New York: AMACOM Books.
Markus, M. L., & Benjamin, R. I. (1997). The magic bullet theory in IT-enabled transfor-
mation. Sloan Management Review, 38 (2), 55-68.
Markus, M. L., & Robey, D. (1988). Information technology and organizational change:
Casual structure in theory and research. Management Science, 34 (5), 583-598.
Orlikowski, W. J. (1992). The duality of technology: Rethinking the concept of technol-
ogy in organizations. Organization Science, 3 (3), 398-427.
Patton, M. Q. (1987). How to use qualitative methods in evaluation. Newbury Park: Sage.
Sarker, S., & Lee, A. S. (2002). Using a positivist case research methodology to test three
competing theories-in-use of business process redesign. Journal of the Associa-
tion for Information Systems, 2 (7), 1-74.
SR Corporate Compendium. (2002).
Swann, C. (2002). Action research and the practice of design. Design Issues, 18 (1), 49-
61.
Valacich, J. S., George, J. F., & Hoffer, J. A. (2001). Essentials of systems analysis and
design. New Jersey: Prentice-Hall.
URF 2001 Annual Report. (2001).
URF 2002 Annual Report. (2002).

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Building Automation into Existing Business Processes 193

Yin, R. K. (1994). Case study research: Design and methods (2nd ed). Thousand Oaks:
Sage Publications.
Yin, R. K., Bateman, P. G., & Moore, G. B. (1983). Case studies and prganizational
innovation: Strengthening the connection. Washington, DC: COSMOS Corpora-
tion.

APPENDIX A
Statements of Revenues, Expenses, and Changes in Fund Balance June 30, 2001 June 30, 2000

Revenues
Project revenues $40,891,609 26,453,789
Project facility and administrative costs 8,242,852 7,055,289
Administrative reimbursement, USF 228,987 266,649
Project fees 1,544,358 1,372,379
Interest Income 360,258 242,462
Donations 159,500 8,149,636
Other 81,210 119,976
Total Revenues 51,508,774 43,660,180

Expenses
Research and development 40,540,754 26,790,322
Management and general 9,599,520 6,791,465
Other
Facility and administrative costs to USF 752,922 925,563
Interest 188,183 85,566
Total Expenses 51,081,379 34,592,916

Excess of revenues over expenses 427,395 9,067,264


Fund balance at beginning of year 14,484,874 5,417,610
Fund balance at end of year 14,912,269 14,484,874

APPENDIX B
Major Sources of Funding

15.50% BMDO
39.70% Air Force
18.60%
Navy
NASA
20.60%

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
194 Paper, Mok & Rodger

ENDNOTES
1
A pseudonym is used to mask the name of the organization.
2
A pseudonym is used to mask the name of the entity.

BIOGRAPHICAL SKETCHES
David Paper is an associate professor at Utah State University in the Business
Information Systems department. He has several refereed publications appearing in
journals such as Communications of the ACM, Information & Management, Journal of
Information Technology Cases and Applications, Communications of the AIS, Long
Range Planning, Creativity and Innovation, Accounting Management and Informa-
tion Technologies, Journal of Managerial Issues, Business Process Management
Journal, Journal of Computer Information Systems, and many others. He has worked
for Texas Instruments, DLS, Inc., and the Phoenix Small Business Administration. He
has performed IS consulting work for the Utah Department of Transportation and is
currently consulting with the Space Dynamics Laboratory in Logan, UT. His teaching
and research interests include process management, database management, e-com-
merce, business process reengineering, and organizational transformation.

Wai Yin Mok is an Assistant Professor of at University of Alabama in Huntsville in the


Management Information Systems department. His papers appear in ACM Transac-
tions on Database Systems, IEEE Transactions on Knowledge & Data Engineering,
Data & Knowledge Engineering, and Information Processing Letters. Currently he is
on the Editorial Review Board of the Journal of Database Management. He serves as
a program committee member for ER 2003 and a track chair for 2004 GITM. He received
a B.S., a M.S., and a Ph.D. in Computer Science from Brigham Young University in 1990,
1992, and 1996 respectively.

James A. Rodger is an Associate Professor of Management Information Systems at


Indiana University of Pennsylvania. He received his Doctorate in MIS, from Southern
Illinois University at Carbondale, in 1997. Dr. Rodger teaches Network Administra-
tion, System Architecture, Microcomputer Applications and Intro to MIS at IUP. He has
worked as an Installation Coordinator for Sunquest Information Systems, and pres-
ently does consulting work on Telemedicine Connectivity for the Department of Defense
and Management Technology Services, Inc. Dr. Rodger has published several journal
articles related to these subjects. His most recent article, “Telemedicine and the
Department of Defense” was published in Communications of the ACM.

Copyright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.

S-ar putea să vă placă și