Building Automation into Existing Business Processes

IDEA GROUP PUBLISHING Building Automation into Existing Business Processes 701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com

177

IT5700

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 in the book,Inc. Annals of Cases on Information 2004, Volume 6, edited Copyright 2004, Idea Group Copying or distributing in printTechnology or electronic forms without writtenby Mehdi Khosrow-Pour. Copyright 2004, Idea Group Inc. Copying or distributing in print or electronic permission of Idea Group Inc. is©prohibited. 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 competencies 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 establishment, research and development, ongoing monitoring, and close out. Contract establishment 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 nontechnical 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 (theoretical 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, crossfunctional 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 undertaking. 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, encryption/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 streamlines 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, announcements, proposals, reports, studies, clippings, and other internal/external documents. Archival records include service records, organizational records, database records, maps, charts, lists, survey data, and personal records. Interviews are face-toface 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 independently 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 respondents. 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 considered 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 (synchronization) 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 databases 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 processes, 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. “Managing 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 synchronize 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 soundness 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 nontechnical 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 graphical 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 throughout 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 quasiproduction 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 experienced 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 transformation. 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 technology 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 Association 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), 4961. 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 Corporation.

APPENDIX A Statements of Revenues, Expenses, and Changes in Fund Balance

June 30, 2001

June 30, 2000

$40,891,609 8,242,852 228,987 1,544,358 360,258 159,500 81,210 51,508,774

26,453,789 7,055,289 266,649 1,372,379 242,462 8,149,636 119,976 43,660,180

40,540,754 9,599,520

26,790,322 6,791,465

752,922 188,183 51,081,379

925,563 85,566 34,592,916

427,395 14,484,874 14,912,269

9,067,264 5,417,610 14,484,874

Revenues Project revenues Project facility and administrative costs Administrative reimbursement, USF Project fees Interest Income Donations Other Total Revenues Expenses Research and development Management and general Other Facility and administrative costs to USF Interest Total Expenses Excess of revenues over expenses Fund balance at beginning of year Fund balance at end of year

APPENDIX B Major Sources of Funding 15.50% 18.60% 20.60%

BMDO 39.70%

Air Force Navy NASA

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 2

A pseudonym is used to mask the name of the organization. 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 Information 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-commerce, 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 Transactions 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 Administration, System Architecture, Microcomputer Applications and Intro to MIS at IUP. He has worked as an Installation Coordinator for Sunquest Information Systems, and presently 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.