UPRA RY Michigan State University This is to certify that the thesis entitled REA: A Process-Oriented Approach to Enterprise Systems presented by Sean C. Curry has been accepted towards fulfillment of the requirements for the Master of degree in Telecommunication, Arts Information Studies, and Media 4Q BM»? 1 Major Professor’s Sighature Mag “1 2001 J Date MSU is an Affirmative Action/Equal Opportunity Employer PLACE IN RETURN BOX to remove this checkout from your record. TO AVOID FINES return on or before date due. MAY BE RECALLED with earlier due date if requested. DATE DUE DATE DUE DATE DUE 5/08 K'IPrqlAcc8PresIClRC/DateDue indd REA: A PROCESS-ORIENTED APPROACH TO ENTERPRISE SYSTEMS By Sean C. Curry A THESIS Submitted to Michigan State University in partial fulfillment of the requirements for the degree of MASTER OF ARTS TELECOMMUNICATIONS, INFORMATION STUDIES, AND MEDIA 2009 Copyright by SEAN C. CURRY 2009 ABSTRACT REA: A PROCESS-ORIENTED APPROACH TO ENTERPRISE SYSTEMS By Sean C. Curry Enterprise systems seek to increase efficiencies by streamlining business processes throughout an organization. But most enterprise systems are perceived to be difficult to implement and are unable to reach this goal. The problem lies with current enterprise systems' use of a flawed accounting framework. This paper explores how the success of an enterprise system is influenced by the framework used in the system design process. By examining one organization’s implementation and use of an enterprise system built on the Resources, Events, Agents (REA) framework this paper is able to measure the implications of a process-oriented system. A case study approach is used, involving interviews, a focus group, and a survey to understand how REA systems affect an organization. This study demonstrates that REA creates a more flexible enterprise system needed both during implementation and throughout the evolution of an organization. Furthermore, REA enables an enterprise system to model an entire organization: a beneficial tool for upper management as well as lower-level employees. By using a framework which focuses on business processes instead of an accounting schema, an enterprise system can have a foundation that better fits organizational needs. ACKNOWLEDGMENTS There are many people who deserve thanks for their help throughout this entire process. They all played a part in the completion of this thesis and a page is not enough to express my gratitude. I greatly appreciate all the guidance my thesis committee has given me. Dr. Kurt DeMaagd, thank you for always being available to answer any questions I had during this foreign endeavor. I appreciate all your patience and ability to understand my goals for this thesis. Dr. Charles Steinfield, your advice on how to structure my research was greatly beneficial. And Dr. Steve Wildman, thank you for your broad economic knowledge of information technology. I appreciate the time and input you all have given me during this process. I would also like to thank my family for their support. Mom and Dad, I really would not be at this point in my life if it were not for you. You both have worked so hard to make sure I have opportunities to better myself and I am forever grateful. Bridget, your extensive grammatical skills have frequently helped me through the proofreading process and I thank you. Ed, you were always able to make me laugh when I needed it most. And Will, you gave me guidance only an older brother can offer. You are all always there for me and I never forget that. Last, but certainly not least, I appreciate all the support from Lexi. You were the first person I came to in times of difficulty and you never let me down. I could not have made it through this thesis without you. iv TABLE OF CONTENTS LIST OF TABLES .......................................................................................................... vii LIST OF FIGURES ....................................................................................................... viii INTRODUCTION .............................................................................................................. 1 CHAPTER 1 LITERATURE REVIEW ................................................................................................. 6 The Value of IT ........................................................................................................ 6 Project Charting ....................................................................................................... 8 Legacy Systems ........................................................................................... 8 Organizational Analysis ............................................................................... 9 The Project & Shakedown ..................................................................................... 10 End-users .................................................................................................... 1 1 Collaboration .............................................................................................. 1 3 Role Players ............................................................................................... 14 Onward and Upward .............................................................................................. 15 Flexibility ................................................................................................... 16 System Granularity .................................................................................... 18 CHAPTER 2 SYSTEM DESIGN ......................................................................... 21. Database Design ..................................................................................................... 21 REA Design ........................................................................................................... 24 Economic Event ......................................................................................... 25 Economic Agent ......................................................................................... 25 Economic Resource ................................................................................... 25 Packaged Systems .................................................................................................. 28 CHAPTER 3' RESEARCH QUESTIONS ............................................................................................. 31 CHAPTER 4 RESEARCH METHOD .................................................................................................. 35 REA System ........................................................................................................... 35 CHAPTER 5 RESEARCH FINDINGS ................................................................................................. 37 Company Background ........................................................................................... 37 Question 1 .............................................................................................................. 37 Question 2 .............................................................................................................. 40 User Alpha ................................................................................................. 41 User Beta .......................................... .......................................... 42 User Delta .................................................................................................. 43 User Gamma .............................................................................................. 44 Question 3 .............................................................................................................. 45 Question 4 .............................................................................................................. 47 CHAPTER 6 CONCLUSIONS .............................................................................................................. 51 Implementation ...................................................................................................... 51 User Reaction ......................................................................................................... 53 System Flexibility .................................................................................................. 53 Encompassing the Enterprise ................................................................................. 54 CHAPTER 7 LIMITATIONS AND FURTHER RESEARCH .......................................................... 56 REFERENCES ................................................................................................................. 58 vi . LIST OF TABLES Table 5.1 — Survey means and standard deviations by question ....................................... 4] vii LIST OF FIGURES Figure 2.1 — REA model of an economic exchange adapted from McCarthy (2009) ...... 27 viii INTRODUCTION IT investment by businesses has steadily grown, from 15 percent of firm capital expenditures in the early 1980’s to 50 percent by the turn of the century (Carr, 2004). As these investments increase, there is concern that there may be little return, and a competitive advantage may not be achieved. Nowhere is this more evident than with enterprise systems. These large systems promise to increase productivity and streamline business processes. But approximately 90 percent of all IT projects are over budget, delivered late, or do not include all originally specified features (Severance & Passino, 2002). Furthermore, if these systems find a way to survive they require frequent customization leading to greater complexity. It has become apparent that these current enterprise systems simply do not fulfill most organizational needs. To be successful, an enterprise system must serve all organizational needs and be easily adaptable to its business processes. The Resource, Events, Agents (REA) framework is a tool to reach these enterprise systems goals. Much research has been conducted to determine the success achieved by organizations implementing enterprise systems. Some scholars believe that after financial investments in these systems, there is no competitive advantage created (Carr, 2004). Instead, these systems are too heavy and rigid, and only put a firm on par with the rest of the industry by restricting adaptability. It is important to understand the purpose of enterprise systems before any further analysis. Enterprise systems attempt to integrate an entire organization’s processes. All business cycles such as payroll, logistics, conversion, and marketing should be thoroughly modeled. These systems will aid management with decision making, increase productivity, and reduce costs. Yet current systems are built with a myopic accounting vision, and thus fail to fulfill the needs of an organization - instead, they focus on accounting needs to provide financial reports (J. S. David, McCarthy, & Sommer, 2003). Ideally, enterprise systems should be constructed to model an entire organization. Enterprise systems Should focus on an organization, from the task level up to the value-chain of that company (Geerts & McCarthy, 2002). This way, all employees will benefit from the system. By having tasks built into a system, employees throughout the organization can use the system as a valuable tool to guide their own jobs. With these tasks being assigned to particular cycles, the system can then display a value-chain to give managers a snapshot of current organizational activities. Furthermore, with all this data within one massive system there is the ability for that system to have knowledge of all facets of a company. This ensures there will no missing links in the chain. An enterprise system should also track events which occur at all points in time (McCarthy & Geerts, 2000). Many current systems are concerned with events which have already occurred and some of those currently being processed. There is no emphasis on the events which are planned within an organization. These economic commitments can be very valuable to decision making. This same forecasting can also be beneficial with those on a task level. An economic event may be triggered by these tracked commitments that alerts employees involved of their applicable tasks. As mentioned earlier, by having all pertinent information stored within the system there is less analysis for the worker and more for the system. Current systems lack the flexibility needed to support organizations which are constantly changing (Allen & Boynton, 1991). Companies must frequently innovate to survive in the business world. An enterprise system is useless if it cannot stay on pace with innovation. For a system to continually evolve, it must be built on proper business semantics that do not constrict an organization. This is accomplished by focusing on a higher level and relying on procedural measures to derive business data. By having a system which is more adaptable, organizations can overcome the difficulties faced during system implementation (McCarthy & Geerts, 2000). Too often a company must change its own business process to accommodate the framework established by current enterprise systems (Hong & Kim, 2002). Such adaptation by an organization can be timely and costly. System reconfiguration to packaged software is considered very difficult, making it a very impractical option. Easy adaptation to an organization also prevents future errors within an enterprise system. Systems often are implemented which have inherent design flaws (McCarthy, 1982). An organization may believe that their system finally corresponds with its business processes when going live (which it may very well be, after much spending and time), but the system is built on a weak foundation. Departmental processes within an organization may not be in sync with one another, for instance, leading to possible data redundancy or inaccuracies. These design flaws will also lead to difficulties when updating the system. The system simply does not resemble what was initially designed. Furthermore, there are so many redundancies in the data structure of current systems that the amount of linked data grows exponentially (Rettig. 2007). It has become apparent that there needs to be a system which is rooted in business processes. A process-oriented system can allow the flexibility which current systems lack and organizations need. This can be accomplished by using a different framework than those currently used. Systems must initially use the proper ontology, which is a way _ of modeling concepts within a specific domain. In the case of enterprise systems, there must be a business domain specific ontology. One such domain specific ontology is REA (McCarthy, 1982). REA uses entities within business cycles to model business processes. Instead of taking accounting practices (i.e., double-entry bookkeeping) and trying to build a system around these principles, REA uses entities that are relevant to all organizations, no matter what their industry. This could help keep enterprise systems simple and adaptable, avoiding the pitfalls of current systems. Furthermore, these systems can incorporate all relative business processes and look beyond real-time reporting. The REA ontology was developed in 1982 by William McCarthy but has not picked up steam in the enterprise systems world until recently. This wait could be attributed to the previous difficulty in implementing REA technologically. The concept has finally caught the attention of system designers due to technological advances. Object—oriented systems are needed to properly model REA which have become prevalent in the programming world. These same object-oriented databases, though, require massive amounts of processing power which was not available 30 years ago. Furthermore, off-site enterprise systems have begun to emerge in the market, making these high processing systems more feasible. The customer will not be required to purchase the additional hardware needed to run an REA system — this can be maintained by the vendor. REA has the capability to be implemented technologically, but it is yet to be determined how it will perform in a real business environment. Due to the radical changes necessary, few vendors have built enterprise software with this ontology. Recently, there has been one vendor using REA. Using this vendor and one of its customers, this paper will attempt to assess REA performance in a real-world setting. This paper will look at implementation, further customization, and how well REA systems are able to serve an entire organization’s needs. Once this information is gathered we can determine the likelihood of REA as the future of enterprise systems. CHAPTER 1 Literature Review Much literature has been committed to the study of IT and more specifically Enterprise Resource Planning (ERP) systems. Researchers have been interested in the organizational impact of these technologies. The initial opinion was summarized well by Robert Solow (1987) in saying, “you can see the computer age everywhere but in the productivity statistics.” But later research found errors in the measurement of IT which ignored the significant increases in firm output due to IT capital investments (Brynjolfsson & Hitt, 1996). Once these productivity gains were realized, attention was given by researchers to why some organizations may benefit from IT while others may not. The literature has established a strong understanding of what is required to implement IT successfully and how its benefits can be realized over time. This paper will review how technology, and more specifically information systems, can positively influence organizations. The Value of IT Since the introduction of IT in businesses, researchers have tried to determine its impact on the bottom line. Looking at financial figures in comparison with competitors, one might conclude there has been little impact. This method of IT valuation has created the “productivity paradox,” where investments in IT occur, but with no evidence of an economic benefit to the organization (P. A. David, 1990). Valuation of IT based on financial data may seem logical, but there is more occurring within an organization which is left unnoticed. Using financial results to determine the impact of IT on an organization is a poor method of measurement. The mistake made by those subscribing to the old methods of IT valuation was their belief in a direct correlation between IT and profit. Lee (2001) noted that there are intermediate variables that IT directly affects, such as cycle time and product quality. Another mistake made in previous studies was analyzing aggregate IT data over industries. Only through valuation at a firm-level can we see the intangible benefits of IT (Brynjolfsson & Hitt, 2000). An intangible may be the implementation of a new system in an organization leading to better vertical integration with suppliers and producing a higher quality product in less time for customers. The decrease in time and increase in quality are items that will not appear on a balance sheet, but are assets of that company. Finally, because IT must first affect these intermediary variables it may take time to see an improvement in financial figures (Brynjolfsson & Hitt, 2000). From an organizational perspective, there is a desire to understand what is necessary to realize the value of IT. A company cannot simply implement the same system as their competitor and achieve Similar gains. Systems cannot be brought into firms where there has been little analysis of current business processes. Furthermore, the organization should understand the purpose of the system they wish to implement. Organizational strategies must align with the system being implemented to maximize their return. IT is intended to complement an organization’s needs, not function separately from business processes (Venkatraman, 1994). Before implementation there must be an analysis of what the technology can deliver and how the organization can use a system’s tools within its current and future objectives. By managing how IT directly affects organizational variables, a company can make its investment profitable (Lee, 2001). It is apparent that for IT to make an impact there must be a correlation between systems and the organization. But how does a firm ensure this relationship will exist? To answer this question one must understand that there are several phases which occur during the implementation and use of an information system: Project charting, the project, Shakedown, and onward and upward (Markus & Tanis, 2000). And within these phases there are elements which play a role in the success of that segment. By studying these elements researchers have given organizations the ability to map their own success. Once these phases are understood, a firm can find which technologies will follow these guidelines and complement their own business needs. Proiect Chartigg Before adopting or implementing an enterprise system, an organization must look at historical aspects and also the current organizational processes. The best historical data to analyze is an organization’s legacy systems, which are those systems already in place prior to system implementation. This analysis will help to identify an organization’s needs and measure how unique and specific its needs are in relation to others in its industry. Finally, an organization must analyze their organizational structure and employee demographic. It is, after all, the end user who will benefit from, and give purpose to, an enterprise system. Legacy Systems Legacy systems are the best tool to analyze current business processes of an organization. Using these systems to compare against the capabilities of a desired information system is essential. Most organizations ignore the historical data legacy systems possess and therefore have a misguided implementation strategy (Holland & Light, 1999). A common example is an organization having many segmented A departments leading to several different systems. If system implementers neglect these legacy systems, they will face the same problems of redundant data and lack of integration. Organizational Analysis After analyzing the legacy systems, an organization should evaluate itself based on its objectives for new ITs. The organization consists of human, business, and IT resources which should be measured to properly correlate with newly adopted technologies (Powell & Dent-Micallef, 1997). Characterizing an organization‘s identity will aid during the adoption of an enterprise system. Saarinen and Vepsalainen (1994) developed the procurement principle to establish such identities. Each organization was characterized by their legacy systems which were classified as routine systems, standard applications, or speculative investments. These systems are plotted between two axes, one measuring specificity of design and the other measuring uncertainty of requirements. The systems follow a diagonal progression from routine systems with common qualities and low uncertainty, to speculative investments that are rare in design and highly risky. To illustrate, consider three separate organizations in the manufacturing industry. Firm A produces a generic good and controls a relatively small market segment. Firm B is larger than Firm A and also produces a generic product but is involved in a joint . venture. Firm C produces a specialty good, is an international organization, and has many suppliers. These firms follow a progression from routine system to standard applications to speculative investments, respectively. Firm A has standard needs and would require only a routine system. Firm B has an increased level of uncertainty due to possible systems complications from their business partners and would need a standard application. F irm C is very complex and faces great uncertainty, establishing it as a speculative investment. The same system would therefore not be suitable for these three firms. A firm should be aware of its own identity to understand that what works for other organizations may not work for its own organization. Venkatraman (1994) also outlines the types of organizational system investments depending on the level of desired output from that system. The literature Shows that an organization must revolutionize its business processes to fit a system in order to reach the greatest benefit. This method is consistent with the idea that an organization must be congruent with the functionality of a system. It is important to measure your organizational goals and needs before ad0pting a new enterprise system. Measuring the business processes will aid in choosing the correct information system. '_I‘_he Proiect & Shakedown Every enterprise system will follow a dynamic process during implementation. Adaptation to an organization’s processes or the enterprise system will inevitably exist. There are ways an organization can prepare for such adaptation. First, collaboration between managers and end-users must be considered. For example, the decision of how much input an end user needs to contribute during the implementation process is debated in literature. Montazemi, Cameron, and Gupta (1996) sees end user involvement as a necessity, while Abdinnour-Helm, Lengnick-Hall, and Lengnick-Hall (2003) has found 10 involvement to have little effect on the end user. An organization must also establish different role players to the project. These role players will carry duties that will guide the success of an enterprise system. Implementation procedures will affect what enterprise system will work for an organization. The amount of communication and adaptation required also limits the enterprise system’s capabilities. End-users A well-constructed and properly implemented enterprise system can quickly fail if an organization neglects the power of their employees. Over time, users will shape the technology being manipulated in an organization (Orlikowski, Yates, Okamura, & Fujimoto, 1995). The case study of Rich-Con Steel, for instance, outlined how poor user preparation with a system can lead to a disastrous implementation. Employees of Rich- Con did not have confidence in their use of a newly implemented system and therefore returned to their old methods causing a catastrophic collapse of business functions (McAfee, 1999). A similar situation was also noted by Brynjolfsson & Hitt (1998) when a company’s employees relied on old habits and never embraced a new manufacturing system. The importance of user interaction with systems cannot be stressed enough. The responsibility rests not only on the management staff but also the system being implemented to diminish user apprehensions. The attitude of end-users toward technology is a significant factor in the success of an information system. If a system is difficult to modify, users will be forced to change their own processes to fit the newly implemented system, an often undesirable situation (Soh & Sia, 2005). Gurbaxani & Whang (1991) illustrate how employees have 11 an inherent, individualistic mindset, which an organization must maintain on some contractual basis. With the introduction of IT there will be another factor the organization must somehow encourage their employees to utilize. This can be costly since all users will have different views of technology which over time will all need to be congruent with the system being implemented (Orlikowski & Gash, 1994). The best way to circumvent these costs will be to implement technologies which are intuitive to most users. The size and structure of a workforce characterizes an organization. A firm which has thousands of employees will struggle more than a small firm to achieve improved efficiency with its enterprise system. Employees can also be segmented by demographic within a large firm, allowing a better picture of the difficulty of implementation. Studies by Abdinnour-Helm, et a1. (2003) have found that job tenure and classification have a correlation with attitudes towards ERP systems. It was noted that those with shorter tenure do not have reservations about a change in an organization’s ERP system. The study also found that managers typically have a more positive attitude about an ERP system than other “blue collar” workers. These factors will dictate the ease of implementing an ERP system in an organization. An organization’s employment structure must be identified to avoid negative attitudes that result in negative behaviors (Abdinnour-Helm, et al., 2003). The technical capability of an organization’s staff should also be noted. What an organization lacks in capability will need to be adapted in the enterprise system and an increase in training, which translates into an increase in cost. If an organization has a “computer savvy” staff they will have an easier process of implementation. The only 12 difficulty is measuring this organizational factor. Further research Should be done to identify the significance of staff technical capability. Collaboration Literature has had mixed opinions about the benefits of end-user involvement in the implementation process. All stages of the implementation process carry different levels of applicable knowledge. Earlier stages rely more on a technical understanding of the enterprise system and later stages require familiarity with business processes (Montazemi, et al., 1996). There is likely not a staff member who is involved in all stages. The early stages are conducted by those in the MIS department while the later stages are manipulated by many end-users. Such separation, or “knowledge gap”, can lead to the loss of organizational goals for an organization’s enterprise system (Soh, Kien, & Tay-Yap, 2000). It has been shown that an end-user may agree with MIS on an enterprise system’s ease of use but not on the usefulness of the system (Montazemi, et al., 1996). In this sense, it would seem beneficial to involve both M18 and end-users in every stage of implementation. An enterprise system is of no value if the end-user finds no purpose in the application (Montazemi, et al., 1996). Abdinnour-Helm, et a1. (2003) has dealt with end-user involvement early in the implementation process for success. In their research, Abdinnour-Helm, et. a1. (2003) have found that increased involvement does not affect end-user attitude. It is possible that employees may have a predisposition to an enterprise system being implemented and such collaboration efforts are considered pointless. An end-user cannot be expected to have an increased interest simply by making enterprise system session meetings mandatory. l3 Instead of encouraging end-users to be part of theimplementation as a whole, there should perhaps be an effort to measure end-users’ needs. By interviewing end-users earlier, the MIS department can establish a stronger grasp on its processes. This will avoid forcing employees to participate in system building sessions which may be considered useless. There should still be an outlet for end-users to communicate other concerns if the wish to increase their participation. There is no reason to avoid end-users, their opinions matter. Role Players Much literature has underlined the importance of identifying different role players in successful technology implementation. These role players have been given different titles in literature. There are titles applicable to the technical staff that develops an enterprise system as well as those on the implementation team. From a technical stand point there are several different levels of system complexity which require their respective levels of technical knowledge. The Procurement principle defines three types of developers to implement a system: innovator, analyst, and implementor (Saarinen & Vepsalainen, 1994). An innovator is a developer who has extensive knowledge of system development and business processes. An analyst has a generic understanding of system implementation and the organization, making him or her a fit candidate for most system implementation. Finally, an implementor has little technical skill and is also less familiar with business processes. An implementor would be fit for a very generic system implementation. Other literature has placed it as a necessity to establish roles for a system implementation team. Davenport (2000) outlines the titles of executive sponsor, project 14 leader, process owner, and super user. The executive sponsor is the senior staff member who is the pioneer of an enterprise system. A project leader manages all the changes that are created during implementation. The process owner must analyze the business processes and ensure a fit with the organization. A super user is involved with earlier testing and will aid other end-users after implementation. These roles are important to understand and identify prior to enterprise system adoption and implementation. The amount of adaptation or fixes an organization or system will require will determine how these roles must be filled. A system that necessitates more modification will require a team with a strong technical background. If an organization requires more adaptation there will be greater focus on role players familiar with company processes. Furthermore, if an enterprise system is higher maintenance during the Shakedown phase, an organization can expect higher labor costs. It seems the ideal is to have a system which is not too complex, lowering the need for more technical knowledge, but is still able to meet the needs of an organization. These roles also do not only apply to in-house employees. More often they are fulfilled by expensive consultants, depending on which system is adopted. _(_)__r_LwartI_arLd Upward After a successful implementation, an organization should utilize the power which the IT system possesses. To simply avoid failure after the previous phases is unacceptable. At this point, there should be noticeable benefits in the manner discussed earlier regarding the value of IT. To ensure a system is capable of reaching this potential it should have inherent qualities: flexibility and the ability to serve organizational needs on all levels of granularity. 15 Flexibility A business needs to differentiate from their competitors to establish a competitive advantage. This differentiation must occur at a relatively high frequency, depending on the industry, for an organization to have a recurring profit. A company is therefore constantly evolving. A system should follow this organizational evolution. It is pointless for an organization to Spend large amounts of time and money implementing a system which will not fit organizational needs within years or months. And since information systems tend to only cater to the status quo, there will be inevitable change required (Allen & Boynton, 1991). A system must be flexible after implementation so that a firm can be unique and maintain a competitive advantage (Byrd & Turner, 2001). The importance of flexibility relates to the idea of strategic alignment. As mentioned earlier, there is no value in IT if it does not align with an organization’s strategic goals. Henderson & Venkatraman (1993) went further to illustrate that an organization consists of internal and external forces of its business and IT components. The two external components are IT and business strategy, while the internal components are the business and IT infrastructure (Henderson & Venkatraman, 1993). A strategic component can be the driver of change for the other elements. This paper is concerned with an enterprise system responding to changes in business strategy to sustain a strategic alignment of all components. Over time, an organization may need to rearrange their business processes to increase efficiencies. This modification can be detrimental to a system which has already been implemented. Since a system is developed with business processes and the employees involved in those processes, there will need to be an overhaul of the system 16 structure. This has proven to be difficult with most enterprise systems. The modification of an enterprise system can begin a chain of events which results in greater complexity in the entire system (Rettig, 2007). A system which diverges from an organization in this way will stop serving organizational needs and also have increased maintenance issues. To avoid future complexities a system must focus on objects within business processes since they will remain constant (Byrd & Turner, 2001 ). Upgrades The common problem encountered with increased complexities in an enterprise system is during the upgrade process. Enterprise systems span several departments and have integrated modules which leads to a massive system after implementation (Markus, Petrie, & Axline, 2000). This fact alone can contribute to a lengthy and often costly upgrade process. Further exacerbating the problem is the need for a system to fit a company’s business process. To establish a fit with the system, the firm may alter the source code making the vendor’s upgrades more complicated (Soh, et al., 2000). By having a simple system which remains tied to organizational processes, a firm may avoid the pitfalls of the upgrade process. If a system were adaptable on a lower level while still maintaining its structural integrity, difficult upgrades could diminish. Workarounds An organization may turn to “workarounds” when a system does not meet its needs. A workaround is using a system’s components in a way not intended by the developers. This is used when a company needs to make a change to a system but does not want to be invasive enough to alter source code (Soh, et al., 2000). A system with many workarounds proves that there is a lack of flexibility in the system. The problem 17 workarounds create is applicable to upgrades as well as overall system use. Having data stored incorrectly will lead to inaccuracies as well as redundancy. Soh, et al. (2000) pointed out how ironic it is that these massive systems, capable of large computation, choose to ignore little details unique organizations may need. A unique organization is left to create their workaround and deal with the degradation of the system. A dd—ons A system should serve all business processes of an organization but occasionally this goal is not met. When this occurs, many users may turn to “add-ons” to fulfill their own departmental needs. An enterprise system may not address the needs of payroll processing, for instance, and an organization may use the best of other systems for a “best-of-breed” approach (Bendoly, Soni, & Venkataramanan, 2004). The problem this creates is that data is then segmented instead of being shared within one system. The concern will be whether an enterprise system is actually representing an organization. System Gran ularity To serve the needs of an entire organization an enterprise system should include all elements of an enterprise. If a system only covers a portion of an organization, i.e. upper management, then only part of the users will benefit. Without the entire organization using the system then all data will not be collected and the system will not fit the firm. This will lead to a system which does not tie to organizational goals and, therefore, the value of their investment will not be realized (Lee, 2001). Value Chain A value chain is used to illustrate how an organization creates value through their processes (Porter, 1985). An enterprise system would ideally cover all aspects of this 18 value chain since it is useful to upper management. Conversely, most current systems only focus inwardly and do not incorporate all external agents, such as suppliers or customers (I. S. David, et al., 2003). By focusing only inwardly, a system is missing these components which will aid in the supply chain of an organization. Bendoly, et a1. (2004) wrote how organizations have been trying to increase coordination with external agents to be more vertically integrated, so it is only logical that an enterprise system would follow the same path. In their paper they also note that a streamlined system is a valuable tool which is currently being accomplished using many add-ons to the core enterprise system. It would seem logical that to best streamline the system there should be an elimination of these add-ons. Having a single system which follows the progression of an organization’s product or service will give a better representation of firm performance. This will be beneficial for those in upper management who are concerned with the bottom line, bottle necks, or forecasting to aid with decision making. Task Level On a lower level from the value chain there are the tasks which are the elements of business processes. Just as information at the value chain level is important to upper management, the task level data is similarly beneficial for all staff involved in a business process. Current enterprise systems do not attempt to create unique interfaces for individual users. Instead, their system interfaces the same for all users and gives them the responsibility of finding their own data which can be time consuming and frustrating (Markus, et al., 2000). If a system were able to outline the tasks that are applicable to their job then the organization will have greater success with its enterprise system. There are a couple reasons for this success. First, employees will be more likely to use a system 19 which they actually find useful. A system that does not apply to their job or only covers a portion of their duties will seem to be satisfying only management and not their own needs. The second reason for success is more accurate data will be accumulated aiding other employees in their decision making. 20 CHAPTER 2 System Design It is important to consider the database design process when trying to conceptualize the fundamentals of the REA ontology to see how it contrasts against opposing enterprise system solutions. Next, this paper will analyze how REA is used throughout the design process. We will then view how current enterprise systems are designed to handle organizational needs. Database Desigg Understanding database design is essential to further analyze enterprise systems. The design of a database is the blueprint which a system will follow. A database management system (DBMS) will be defined by a schema created during the design process (Batini, Lenzerini, & Navathe, 1986). It is important to have an accurate representation of an organization in the database design to ensure a properly functioning system. The schema should mirror the organization it is modeling (Batini, et al., 1986). The better the design, the less future errors and maintenance the system will require. Data modeling simply attempts to model reality. This is done by looking at an organization’s entities and focusing on their relationships throughout different processes. There are three steps in the data modeling process: requirement analysis, View modeling, and view integration (Lum, et al., 1979). During requirement analysis, database designers will look at historical aspects and also current organizational processes to determine their needs. At this point the designers are trying to understand how an organization operates — they map out the workflow and business processes in order to see how information is shared and transferred. Historical 21 data for analysis can be an organization’s legacy data. Requirement analysis is also conducted through interviews with the current staff of an organization. Through interviews and legacy systems, database designers can better understand the processes of an organization, the entities within these processes, and any constraints in data usage (McCarthy, 1982). This analysis will help to identify an organization’s needs and prepare separate information views used in the proceeding stages of design (McCarthy, 1982). The next step in database design is to take the views created in the requirement analysis and model them. All entities involved in an organization’s events are classified and their attributes are listed. These classified entities will then hold instances of data within the DBMS. The relationships between these entities are also modeled. A binary relationship between entities is known as an “association” (McCarthy, 1982), which is given constraints (Ullman & Widom, 2002). To illustrate constraints, a student and class might be two entities, where a student can have one or many classes, while a class can have one to many students. Another association is generalization, where an entity has sub entities that relate to the parent entity (McCarthy, 1982). For instance, a pet could be an entity with several generalized entities such as cat, dog, fish, etc. This conceptual modeling process is iterative and emphasizes the elimination of redundancy which creates a schema that is “flat.” This means that there are no fields dependent on another within the same entity class. These dependent fields will be the key of another entity class. A schema that is not flat can lead to difficulty with future modifications. The final step in the design process is to integrate the views of an organization that have been modeled separately. These views are separated and integrated for two 22 reasons (Batini, et al., 1986). First, an organization may be too complex to model all at once. Second, organizations are typically divided by departments that handle different processes making separate views a logical step. The integration process is to build a schema which represents an entire organization’s processes, known as a “global schema.” Once this global schema is established it can then be applied to a DBMS. One of the greatest mistakes during this process is to make compromises with the system design. These compromises can be caused by weak investigation during the requirement analysis processes. An incomplete understanding of an organization’s processes can lead to the omission of critical entities. If, for instance, a clerk is not modeled in the payroll process there will be future difficulties with the system. There will be data which will accumulate for all payroll transactions that do not have a clerk associated with each. A user of the system would be unable to query what clerks have worked on payroll transactions. The organization will then have to go through the painstaking process of creating the relationship between clerk and the transactions and try to associate the historical data, if at all possible. Compromises can also occur when designers intentionally leave key components out ofthe system design. An organization, for instance, may decide that certain vendor type information is unnecessary and remove it from the schema. Again, sometime in the future a user may desire vendor data broken down by vendor type. This data will then have to be acquired by the user querying related data and manually reviewing and sorting the data. Not only is this very time consuming for the user, it is also completely unnecessary. 23 Another instance of this compromise may be to simply remove a key relationship among entities within the schema. If there is a sale event, it will involve a customer and inventory. The designers may opt to remove the relationship between customer and inventory which they deem unnecessary. The system would have to trace a customer through a sale and then to the inventory item(s). While the system may still be able to figure what customers purchased what specific items, it will have to be done in a much more inefficient way than going directly from customer to inventory. Designers may also choose to include items in the system design which are not necessary, or misplaced. As mentioned before, this leads to a schema which has redundancies and is not flat. For instance, a system design may have a table labeled “budget”. This table Should not exist because its data will be compromised of other historically data, leading to redundancies. It may seem that all systems are doomed for failure based on these simple mistakes that can occur. There is great difficulty in system design and all information and scenarios must be considered before going live. While some of these errors can be corrected using new technology, the concept of having the global schema completely certain will always exist. REA Design REA models economic phenomena to provide a template for all organizations to follow during these design steps. Because REA captures these phenomena which are prevalent throughout businesses, implementation of their systems is much simpler. The focus is for an organization to take these schemas and customize to its business 24 processes, whereas with current systems there is a need to reconfigure their current processes. AS the acronym suggests, REA uses resources, events, and agents to stereotype items within a business processes. Economic Event An economic event is any kind of transaction that involves an exchange between entities. These transactions may or may not be monetary. Basically, anytime something occurs which adds value to an organization, it is considered an economic event. There are hundreds or even thousands of these occurrences within an organization daily. The economic event can be considered the heart of REA because it is where either agents, resources, or other events interact. There will be instances of all events that record all pertinent data to that business process. Examples of an event may be a sale, cash disbursement, or raw material acquisition. Economic Agent Those individuals involved with a business process are economic agents. These agents can be either internal or external to an organization. Examples of agents may be customers, vendors, or employees. Economic Resource Economic resources. are the items which an organization acquires and subsequently disperses to add value to a good or service. Resources can go through many business processes resulting in greater value and different identification. Examples of economic resources are raw materials, cash, trucks for logistics, or finished goods. 25 A business cycle will consist of processes which will involve several events with different inputs and outputs, creating value for an organization. Agents will participate in economic events. Resources will have a stock-flow relationship with events as they are either increased or decreased by an event. Events will have a duality relationship with other events, where both events have a balance. During the conceptual modeling process a systems designer will review process data and classify them as attributes of these stereotypes within that business cycle. To illustrate, all businesses will have a revenue cycle which involves the exchange of goods or services for income. A system designer will analyze this cycle during requirement analysis and see documentation such as sales receipts, employee timecards. and purchase orders to find the entities and their attributes involved in the cycle. This cycle will have entities such as a sale or cash receipt for events, employee and customer as agents, and inventory and cash as resources. Economic events will have a “stock- flow” relationship with resources and a “participation” relationship with agents (McCarthy, 1982). System designers will model all the views of an enterprise by customizing the REA framework of each cycle. The following diagram helps explain the process of modeling a business process in REA. This model maps out the exchange of goods for payment by a customer, a simple concept which is prevalent throughout business. In this example, an organization has “widgets,” their economic resource, to be sold. Data may be stored for the widget inventory such as inventory number, cost, price, etc. The economic event of a sale takes place and draws from these economic resources. The sale event may record a sales number, item quantity, date of sale, etc. There are also agents who participate with the 26 sales event, a salesperson (internal), and a customer (external). All pertinent information for these agents such as employee number, or customer name is stored in their respective data tables. For each entity in this model that has a relationship with another, they will store the key data value from that corresponding table. For instance, if employee number is the key to salesperson then the sale event will record that employee number for each sale instance. I Economic Resou'ceJ Widgets I Economic Agent I participation Salesperson I Economic Event ’ Sale I Economic Agent I ° Customer I Grve - [Economic Agent I Customer I I Economic Event Cash Receipt I Economic Agent I Cashier I participation IEconomic ResourceI Cash Figure 2.1 — REA model of an economic exchange adapted from McCarthy (2009) The economic event of a sale is only one half of the processes in which the organization is foregoing some resource. The other half is when the organization creates value by receiving a resource in return. This economic event is the receipt of cash from a customer, noted here as a cash receipt. This half closely resembles the disbursing of 27 resources except that the incoming resource is cash and there is a different internal agent participant, which is the cashier. The REA approach is process driven throughout conceptual modeling. Where most current systems focus on accounting principles in their modeling process, REA sees this data as procedurally derived (McCarthy, 1982). By having all economic events of an organization, REA can query the necessary accounting data. For example, accounting gives great consideration to inventory measurements. The stock-flow relationship between sale and inventory, and purchase and inventory, will be used to determine items such as cost of goods sold, quantity on hand, and depreciation. All of these financial amounts will be computed by querying these tables. The REA ontology also incorporates economic commitments which can trigger other economic events. For instance, a lease agreement can be entered into a system and trigger cash disbursements over time to a vendor. This design allows a system to have forward thinking, which can be beneficial within multiple business processes. Packgged Systems After reviewing the design process it appears the ideal is to have a system built from scratch around a business’ well-tuned processes. This is rarely achieved, however, due to the massive amounts of time and development necessary to build and integrate such business components. As a result, there has been a rise in packaged enterprise systems. These systems are designed primarily before they are implemented, by using best practice processes. The system components are also built on accounting semantics by employing a general ledger in their design (O'Leary, 2004). By creating a system that forces business process adaption and commits conceptual design compromises due to an 28 accounting based schema, the implementation and sustainability will be cumbersome if not impossible. Due to the massive changes to business process needed, implementation of packaged enterprise systems can be costly and often unsuccessful. It is shown that 75 percent of ERP implementations have been considered failures (Hong & Kim, 2002). To abandon implementing a system of such magnitude can cost an organization millions of dollars. Companies such as Waste Management, for instance, spent $45 million on SAP and then opted out of implementation because it was too complicated (Abdinnour-Helm, et al., 2003). The key is that packaged ERP systems are not created with a specific organization in mind. The software providers are not doing requirement analysis for a specific customer until after the system is designed. They have no idea how segmented the business process may be, for instance. Furthermore, if an organization is significantly specialized they may spend a great deal of time and money adapting the system. Another problem with current packaged software is that it is very complex and only grows more complex over time. As discussed earlier, the design is flawed by not being “flat” due to an accounting schema. These initial design flaws can lead to difficult upgrades. To illustrate, SAP R/3 notes that their system has 8,000 tables (Blain & ASAP World Consultancy, 1999). Because there are dependencies within these tables - caused by a general ledger schema, the upgrade process can be a nightmare due to the massive amounts of data. Such complexities with data will lead to an increased probability of incorrect information (Rettig, 2007). 29 Limitations are also created by packaged software tying its design to a general ledger and other accounting instruments. The systems do not focus on economic commitments which can trigger other future economic events. By focusing only on real- time events these systems are not benefiting an organization. A system is useless in supply chain management, for instance, if it cannot forecast and alert based on inventory levels to aid in decision making. Finally, because packaged software is so homogenous and rigid there is no ability to differentiate and create a competitive advantage. Some have argued that IT investments will bring little return for this reason (Carr, 2004). There will be no difference in output or growth if a business is implementing software which the rest in their industry already use. A system must be unique and serve the specific needs of an organization to leap-frog its competitors. 30 CHAPTER 3 Research Questions A review of the applicable literature indicates that current enterprise systems do not follow the database design principles outlined. This has lead to systems that are difficult to implement and upgrade, and tend to be too constrictive and diminish any possible value IT can deliver an organization. Question 1: REA should allow adaptability to business processes leading to a better fit with an organization. How will this adaptability affect the system implementation process? REA is built on simple economic events that occur in all businesses which should allow more room for adaptability. Economic phenomena such as a sale, cash disbursement, and resource acquisition are prevalent throughout businesses and the starting blocks of an REA system. By being open-ended and allowing easy customization, REA systems may reduce the need for massive business process remodeling. This should enable an organization to establish its own strategic goals and easily align them with a newly implemented REA system. Current enterprise software is technologically deterministic and forces an organization to adapt to its general ledger constraints. Forcing an organization to change can slow the implementation process and withhold or even eliminate realizable value from their investment. Successful implementation is measured by meeting projected cost, time, and performance. A non-successful implementation will be any negative deviation from these projected goals. 31 Question 2: How likely are end-users to accept an REA system that focuses on real world semantics? Since REA systems focus on economic events and not accounting methods, there should be a radical change in how business information is gathered and perceived by those within an organization. The REA schema should be easier to grasp than accounting principles which people spend years studying to comprehend. Users may be inputting data which is relatable to their own jobs. The accounting data will be derived in a procedural manner therefore placing the emphasis on the processes and the tasks which comprise those processes. This should make financial reporting an afterthought, not the basis of a system. Therefore, a system should be relevant to each business cycle’s processes, which an end user is more likely to comprehend than the principles of accounting. An emphasis will be placed on improvements in job performance, ease of use of the system, user attitude, and facilitating conditions as outlined by Venkatesh, Morris, Gordon, & Davis (2003). User response to these categories will measure user acceptance of the REA system. Question 3: How flexible will an REA system be to structural organizational change, such as a reclassification of business units, after implementation? Enterprise systems must be flexible to handle any changes an organization may face. A flexible system will avoid workarounds and difficult updates/upgrades found in most packaged software. Since current enterprise systems are based on an accounting vision, a design flaw exists from the beginning. Double-entry accounting design can lead to much redundancy and unnecessary dependencies. This complexity will only grow 32 along with the system. After an organization spends endless amounts of money on these systems they will need to spend more just to upgrade due to these design flaws. This complexity is unacceptable, unnecessary, and should be avoided. A system which focuses on business processes should enable more flexibility throughout its existence. By focusing on the. objects within these processes at a higher lever than current systems (i.e., the general ledger), the design will not need to be modified. Only the procedures used to derive data will need to be altered. Flexibility is measurable by how easily an REA system is able to adapt to organizational change. The more time and money needed to adapt to the REA system, the less likely it is a flexible system. Question 4: How well does an REA system encompass an entire organization from the value chain down to the task level? Current enterprise systems are only focusing on a specific portion of business events. The desire to only track mid-level processes within organizational limits is severely limiting the possibilities of enterprise systems. REA systems could move away from double-entry accounting and do more than organize financial data. These systems can allow for the integration of all aspects of a business across the entire value chain to aid in managerial decision making. This should also be true for those employees who turn to an enterprise system to aid them on a task level. By encapsulating all business processes, a system designed using REA has the possibility of being a true enterprise system. 33 Reduced cycle times, increased productivity per employee, better information for managers to aid decision making, and improved cost allocations will Show how well REA systems focus on an entire organization. 34 CHAPTER 4 Research Method Because there is only one vendor producing an REA based system and because they are relatively new, their amount of customers is small. Therefore, this study will focus on one company’s use of the system through an exploratory case study approach. This study uses Yin’s (2003) approach of outlining “how” and “why” questions to illustrate what REA systems are capable of delivering to an organization. The approach uses interviews, surveys, and focus groups to gather data. Interviews will be the primary focus of this paper. These were conducted with staff involved with the implementation, role players such as subject matter experts, and a project leader. Interviews were also conducted with upper management to assess the system’s realizable value. Additionally, to determine the flexibility of REA systems interviews were conducted with staff responsible for changes such as upgrades. Next, a short survey was prepared which asks employees their impressions of the system. Finally, focus groups were created to get opinions of the users who had a deviation from others within the survey sample. REA System The REA framework can be very effective at modeling economic events that occur in organizations. But REA is only an ontology and needs the proper enterprise system’s physical design to succeed. REA is therefore not a panacea that can be run on any platform. REA must be implemented by a system that can handle its needs. A key aspect of the REA system is its focus on flexibility. While current packaged software comes with best business practices modeled, this system tries to be 35 open-ended. As mentioned earlier, REA models economic phendmena that exist in all businesses. A company should configure an REA system according to this framework and allow the built in procedures to handle the business logic. The system is able to model using REA and derives accounting data in a procedural manner due to the increase in current processing power. The ERP systems today were built on technical constraints of twenty years ago. This system does not use a DBMS in the same manner as packaged software. Instead, there are only three tables which hold data. The REA database design is built in core memory using this tagged data once the system is started. The system database design is built in core memory to improve upgrades and avoid workarounds. If a new business unit is added over time then an organization will tag it in the correct manner. Once the system data is instantiated the adjustments will be made. By opening the design in this manner it should stay “flat” and avoid the pitfalls of previous ERP systems. Whereas with packaged ERP systems there are many predetermined tables containing accounting dependencies which may not apply to a business, this REA system tries to allow customization to fit an organization’s processes. 36 CHAPTER 5 Research F indings This study focuses on the implementation and the realizable value of an REA system. By reviewing customers of a REA system vendor, an organization was chosen which implemented the proper modules for this study. A service-oriented enterprise (SOE) was chosen due to its use of the human resources (HR) and financial modules of the REA system. Company Background The SOE is an organization comprised of four different companies. These are either its start up companies or ones which they have acquired. The first company is a medical staffing company which places temporary as well as a few permanent employees. The employees are staffed in nursing homes, schools, as well as outpatient clinics. The second company is a business brokerage company which has been in existence for 20 years. The purpose of this company is to assist those interested in buying and selling businesses. Thirdly, the SOE owns a property management company whose purpose is to rent properties to other businesses. Finally, there is an IT consulting firm. This firm handles the implementation of enterprise software for other organizations. At the time of this study the company had been using the REA system’s HR module for approximately 22 months and the financial module for 17 months. Question 1 To research the implementation of the REA system, interviews were conducted with those involved with the process. Most data was gathered with the executive sponsor who is also the SOE’S executive vice president. Other data was acquired by interviewing 37 subject matter experts, one an accountant for the financial modules and the other the human resource director for the HR module. Focus was given to how operations were prior to the implementation of the REA system and what the SOE’S goals were for the system implementation. The study then inquired if the SOE met these implementation goals. Prior to the implementation of the REA system, the SOE was using Peachtree for their system of record. Peachtree was used because the SOE was a startup at the time and was not large enough to warrant anything beyond a transactional based system. When reports were needed, or anything that Peachtree could not provide, the SOE used spreadsheets. As the company grew so did their needs outside of Peachtree. This resulted in a heavy use of spreadsheets that became cumbersome and time consuming. It became apparent that their current system needed to be replaced to match the increased size and needs of the SOE. The SOE began the process of replacing their existing System. It looked at Great Plains and Net Suite but decided on the REA system because it felt the REA system would be best suited for its unique organizational structure. The REA system was able to work with its enterprise structure so that they could rollup or give separation for those entities within the SOE. The executive vice president of the SOE expressed how a traditional ERP system would be too rigid to meet their needs. Its Peachtree system ran parallel with the REA system for three months to ensure data accuracy. The team that implemented the REA system consisted of an executive sponsor, project manager, and subject matter expert. The executive sponsor is responsible for championing the project. The project leader’s role was to work with the executive 38 sponsor in determining the required reporting as well as, being responsible for system configuration. The subject matter expert’s role was to explain the business processes which were applicable to the module being implemented. The team analyzed the predetermined processes of the REA system and determined whether their current processes should be changed. The executive vice president attested that there were several processes of the SOE which had to be reorganized and decided to align them with the REA system. They felt that these processes were eventually going to be reorganized and that the implementation period seemed to be a logical transition point. But when changes were required of the REA system the HR director notes: “You’re able to mold it to what you need rather than, ‘Oh, we have to change how we do things in order to make it work in the system.’ So we’ve been able to do that. For me, that makes it much easier than to have to workaround what our processes are.” The HR director also went on to give an instance of how their temporary employees did not receive vacation, benefits, or seniority which was simple to make the changes to the REA system’s original structure. The executive vice president also illustrated that the expense reporting between the medical and consulting companies differed and that the SOE was able to make the changes within the REA system to match these processes. All team members seemed to agree that the REA system was designed to accommodate what the SOE’s needs were. The executive vice president summarized it well: “It’s very flexible because many of the items you’re just configuring....You can create a new business process, you don’t have to use the business processes delivered. It’s very easy to model it to your businesses. We have four different businesses, four different ways of doing things, we were able to configure each of the business needs to meet that particular business.” 39 The SOE was able to outline the goals they had prior to implementation. The company hoped to reduce their IT costs and have a system which was accessible to all staff. The implementation for the HR module took 21 days and the SOE was able to have performance evaluations completed the week after implementation. The financial module took longer, but still only 42 days. The executive vice president explains that the financial module took longer because of the REA system’s departure from the typical account based systems. Both of these implementations were done quicker than expected. The cost of implementation was also less than the SOE had anticipated and less, they feel, than if they had went with another system. The company did keep IT costs down without having to purchase additional hardware or add more IT staff. In the same respect the SOE noticed their company had grown but they did not have to add additional accountants which they directly attribute to the REA system. Overall, the SOE believes they will have a total cost of ownership (TCO) savings of $600,000. Question 2 To assess the level of user acceptance of the REA system the study created a survey which was distributed to users. The survey consisted of 15 questions relating to performance improvement (5), ease of use (3), user attitude and social influence (4), and facilitating conditions (3). The survey used a Leikert scale: l-strongly disagree, 2- disagree, 3-neutral, 4-agree, and 5-strongly agree. There were ten respondents and eight complete responses. Below is a summarization of the mean and standard deviation for each question. The survey also allowed for users to give their contact information if they were interested in participating in a focus group. If a user seemed to deviate from the sample 40 and their contact information was given they were then contacted by the researcher. A group of four users were chosen for the focus group. Their responses to interview questions are outlined below. Table 5.1 — Survey means and standard deviations by question Question Mean SD. + - Overall, the REA system has been very useful in my job. 4.00 0.94 4.94 3.06 The REA system has posrtlvely changed the way I work on a 3.70 0.95 4.65 2.75 daily basis. The REA system is often helpful with the tasks that I need to perform for my job. 4.00 1.00 5.00 3.00 The REA system gives Information which helps decrsron 3.40 0.97 437 2.43 making In my Job. My productivity has increased since using the REA system. 3.70 0.82 4.52 2.88 The REA system is not difficult to use, and requires little 4.70 0.48 5.18 4.22 training. Information is easily accessible and accurate within the REA 4. 40 0.70 5.10 3.70 system. I find the REA system to be logical and easy to follow. 4.40 0.70 5.10 3.70 I would rather use the system our company was using prior to 1.29 0.49 1.77 0.80 the REA system. I am reluctant to start using the REA system and rely on old methods to get my work done. 1'25 0'46 1'71 0'79 People that influence my behavior think I should use the REA 3.63 1.51 5.13 2.12 system. Our organization seems to generally accept the REA system. 4.88 0.35 5.23 4.52 In general, I have a strong grasp on accounting rules and 3.50 1.07 4.57 2.43 procedures. I am able to quickly and easily learn new computer software. 4.25 1.04 5.29 3.21 The REA system is compatible with the aspects of my job. 4.25 1.04 5.29 3.21 User Alpha This user deviated most of all survey respondents. User Alpha had a negative deviation in all measured categories except ease of use. Alpha is a senior client executive 41 who is responsible for new sales in the SOE’s IT consulting company. Alpha primarily uses the HR module of the REA system for inputting contact and profile information, expense reporting, requested time off, and performance appraisals. This user has been self described as an “old dog that needs to learn new tricks”, who does not embrace technology. Alpha certainly lacked enthusiasm for the transition before implementation of the REA system. But after implementation, Alpha felt that the system was a refreshing change because it was intuitive. Alpha appreciated that the system had a role-based presentation focused on their duties. User Alpha felt that improved performance was measurable by how a system could increase efficiencies to achieve a desired sales quota. In this respect Alpha saw the REA system as indirectly beneficial. The system, Alpha notes, is able to reduce administrative duties to free up time which can be spent with prospective customers. For instance, Alpha recalls having to manually create and monitor a paid time off (PTO) datasheet, but now the process is within the REA system and shows the progression throughout the approval process. Alpha also noted the REA system would notify if action was required from them regarding a particular business process. User Beta The responses of User Beta highlighted a negative deviation mostly in the performance category and partially within the facilitating conditions. After speaking with User Beta it became apparent there was a logical explanation for the deviation. Beta is the system specialist for the REA system and rarely uses it for their job tasks. And, as Beta noted, their time was spent configuring the REA system to improve the performance 42 of other staff. Furthermore, the deviation for facilitating conditions was a “disagree” for their knowledge of accounting. This is also attributable to Beta’s role within the SOE. User Beta noted that the REA system was very easy to use and “user-friendly”. Beta also felt that it was very easy to train users for the REA system. User Delta Delta is responsible for sales and client satisfaction at the SOE. They use the REA system primarily for HR (i.e., PTO and expense reporting). Delta had an overall positive opinion throughout the survey. The strongest positive deviations were in the area of job performance. Delta feels that the REA system has saved them time by reducing their administrative work, therefore allowing more time for sales. Delta used the expense reporting process as an instance. What used to be a cumbersome, time consuming process with excel spreadsheets has now been streamlined so that Delta can enter weeks worth of expenses in less than an hour and be reimbursed by direct deposit very quickly. Delta also finds it useful that they can monitor all stages of this process. In the eyes of Delta, the REA system had automated processes very well. Delta had used systems at other similar organizations which were “semi-automated” and would not cover all aspects of a particular process. This previous experience also helped to eliminate any possible apprehensions Delta would have with the implemented REA system. The user often noted how it was a very easy system to use and required little training. Delta went on to say that the training received was more than they needed. There was a clear feeling of confidence in the REA system when noting how it was “intuitive”. 43 User Gamma The final user of the focus group is the president of the IT consulting firm. Because Gamma is part of upper management their use of the REA system is focused on financial reporting, firm performance, and HR management. This user also positively deviated in the area of performance. From a management perspective Gamma was pleased with how accessible the data was from within the REA system. The user notes: “The fact that 1 can model the data without having to export it out to a business intelligence type tool or to a data warehouse is pretty powerful for us. Because we’re a small organization, I don’t want to have to spend all that money to then take and export this stuff and then start setting up data marts. That’s been very, very helpful for us to model the way our business actually works from a financial stand point and be able to drill in and see it.” Gamma also appreciated that they did not have to discuss their needs with accountants. The ability to get the data in real time and arrange it to fit their needs was the most beneficial for Gamma. Flexibility of system was also beneficial to Gamma’s managerial needs. Gamma notes: “. . ..a year later decide that we want to look at the business differently and not have to go back and financially re-architect everything we’ve done, but to set up a different way of looking at it. For a growing business, like ours, that’s really important for us to be able to do, versus to have to make decisions and live with those decisions forever.” Gamma went on to say that they had worked with other ERP systems and finds the REA system much more flexible. User Gamma also emphasized the ease of use of the REA system. They noted that the system required little to no training and was very intuitive. Overall, Gamma had 44 a very positive attitude about the REA system before and after implementation of the system. Question 3 To gauge the possible flexibility of the REA system within the SOE the study focused on upper management familiar with organizational changes as well as the team responsible for system modifications. Interviews covered the areas of upgrades, organizational workarounds, and sustained system synchronization with the SOE. After implementing the REA system, the SOE noticed a large change which could enable greater flexibility. As the SOE was growing prior to implementation, so was its general ledger. The staff accountant notes prior to implementation, the SOE had approximately 120—125 financial accounts within their general ledger. This was reduced by 60 % after implementation of the REA system, according to the executive vice president. Having this simplification on an upper level has focused modification on a lower level. For instance, there may be an account for “telephone” and when the SOE needs to specify an IT consultant cell phone it will be tagged to that “telephone” account instead of being added as a new account. This keeps the data structure flat and avoids future complexities. The study addressed the possible changes to the REA system which may originate from the SOE’S desire to fit their evolving organization. Through interviews with the executive vice president they were able to give instances of such changes. The first point made by the executive vice president was that their company contained different organizations with different processes which the REA system accommodated. On the HR side of the SOE there are changes happening often. Since implementing the REA 45 system there have been two major HR reorganizations. First, the medical staffing industry was originally modeled without concern for type. The organization then remodeled the system to allow staff to be defined by which type of business they were assigned. Next, a similar modification was made for their IT consultants. Initially, the SOE was arranging their consultants by type of service provided. After implementation, the company wanted to define the consultants by type of software they were implementing and then by service type. Both of these modifications were possible. Another instance involves the addition of an entire business. While implementing the REA system, the SOE had recently acquired their business brokerage company and did not model the business due to its late addition. Using the team responsible for system modifications, the company was able to add the business to the REA system in less than a day. This was all accomplished after the REA system had been running and without any outside consultants. Additionally, the system specialist partially responsible for a modification is self described as, “not a computer savvy person.” The SOE’s system specialist was able to explain the update process of the REA system. Every three months the REA system vendor launches a new version of their system. The SOE then is given a “sandbox”, the new version which has not been moved to production, to test all the new features. During this period, the update team goes through their business processes to ensure everything is properly aligned and that the data is accurate. The team will runireports to test data accuracy and log cases for the vendor to review if there are any issues with the update. The testing phase typically takes one week. The entire update process takes approximately two weeks. The study also addressed the possible complications system modification may have on updates. The 46 system specialist felt their changes to business processes or any customization did not affect system updates. Possible workarounds were also a concern with the REA system. There were a couple instances of workarounds that the accountant and HR director were able to explain. During year end financial statement preparation the accountant had to create a work around to meet IRS deadlines. This issue was resolved within a week. The HR director also noted how the system is currently not showing PTO balances so these have to be done manually. This functionality has now been built for the REA system and is currently being implemented by the SOE. All members of the update team as well as the executive vice president were asked their opinion of how well the system has stayed synchronized with their organization. The executive vice president indicated that the system has become even more aligned with their organization since implementation. The update team also felt that the system has continued to mirror their business. The system specialist explained that it is not difficult to keep the system tied to their organization since it is configurable. They also went on to explain that the only time the system was not matching their needs was when they did not review their current processes. After a review of what the SOE’S business processes were, the team made the adjustments. Question 4 To assess how well the REA system has served the needs of the organization, this study interviewed upper level managers, staff accountant, and also acquired data from the user focus group. Concern was placed on whether the system could give the proper value chain data to managers as well as aid other staff with their daily tasks. Realized value of 47 the REA system was also gauged by instances of increased productivity. Finally, the study looked for add-ons to the system and why they were being used. The staff accountant made an interesting observation about how the data is gathered in relation to how it aids financial reporting. For instance, in their REA system, a consultant may be filling out an expense report and detailing each expense. The consultants are assigning these costs to easily understandable fields (i.e., cell phone, mileage, etc.). All of these intuitive classifications are tied to a general ledger account. So, in reality, these consultants are doing accounting without even knowing it. This is much better than the previous method which involved the accountant reviewing and entering expense reports. These previous reports were also less accurate because consultants did not understand accounting and did not know how to assign expenses. The REA system has been able to relieve the burden on the SOE staff while improving data accuracy through task level awareness. While benefits were being realized on the task level, there were also noticeable differences in the SOE’s value chain reporting. When speaking with the staff of the SOE the phrase “multi-dimensional drill down” was often mentioned. This phrase was used to describe the ability to take upper level data within the REA system and see the detail arranged in any manner they desired. The staff accountant describes the benefits: “It’s a system that holds all your information that you’re able to look at the way you want. Instead of trying to jump through hoops to get one piece of information from six months ago, it’s all right there for you to see, it’s just how you work with it” For managers this is extremely beneficial because they can drill down on any aspect of the business. During implementation the team decided to wait and see what reports were needed. The managers noticed that report preparation was less than expected because of 48 the “multi-dimensional drill down” aspect. This has been integral in decision making because managers are able to get the data they need at any moment. The executive vice president describes how the REA system aids in making quick decisions: “The nice thing is you’re actually able to get true management information to run the companies. [With our medical staffing company], the type of facility that the individual works in is important to us. We track what percentage of our business is done in each type of a facility. And we also track the gross margin in each of those facilities. And we watch that constantly, because although we may be doing business in one type of facility, it may not be the highest profit margin for us in that particular facility. So we have to make sure that we have a good mixture in all of the different facilities.” The executive vice president also described how this ability in the REA system is much different from other systems they have worked with which were just looking at the past. Upper management was able to give instances of improved productivity within their organization. The SOE has doubled in Size in the previous year and foresees the same for this current year. The executive vice president notes that the implementation of their REA system has a direct correlation with this growth. The REA system, they believe, has decreased cycle times to reduce staff workload enabling their business to grow without acquiring additional staff. Instances of decreased cycle times would be their consultant expense reimbursement and financial statement preparation time. The expense reports used to take three weeks for processing. The cycle has been reduced to three days once reports are approved. For monthly financial statements, the company was fortunate to have them completed by the 25th of the month. These reports are now prepared within the first ten business days of each month. Close attention was given to the possibility of add-ons to the REA system as an indicator of needs not met. The SOE did have system add-ons, which all have a reason for existence. The first add-on is used for the invoicing of customers. This add-on was 49 used prior to the implementation and is currently integrated with the REA system. The REA system did not initially have the functionality to serve the invoicing needs of the SOE but has since developed these components. The SOE has continued to use the separate invoicing system out of what appears to be preference. The other add-on is a payroll system for employees. This is not even technically an add-on because the SOE does not process their payroll in-house, but instead uses another company. Upper management was able to confirm that the REA system does contain the payroll functionality but they do not have the necessary staff for processing. 50 CHAPTER 6 Conclusions This study attempted to illustrate how REA systems may be beneficial for an organization. By studying one organization’s implementation of a REA system, this paper tested whether these benefits were attainable. Focus was given to aligning an REA system with the strategic goals of an organization during the implementation phase. User reaction, a key component to system success, was also observed using a focus group. Detemtining how well a REA system could adapt to inevitable organizational change was another component of the study. Finally, the study examined how well the REA system was able to serve the needs of the entire organization. Implementation The REA ontology is focused on the processes prevalent throughout all organizations. This allows REA systems to be malleable to organizational needs. Other enterprise systems insist on business process remodeling by an organization to fit their system (Hong & Kim, 2002). In this respect, implementation of REA systems Should be simple. This study was able to confirm successful implementation by measuring how the SOE was able to meet their goals. The most striking evidence of a successful implementation is the amount of time spent to have the components of the REA system running. Implementing the HR and financial modules in 21 and 42 days respectively seems unbelievable in the enterprise system community. The fact that this organization was one of the first to implement this particular system also makes this timeframe more impressive. One must also take into account that the SOE does have a company which implements enterprise systems, giving 51 them an edge over other organizations. Notwithstanding this, there are usually professionals involved in other system implementations who rarely witness this turnaround. Another instance of how REA systems are able to easily fit an organization was apparent when assessing the unique identity of the SOE. This company is made up of ' four different organizations, all with different processes. To accommodate this unique organizational structure is a feat for any enterprise system. All of the staff involved in the implementation expressed that this was not an issue. The REA system was focused on what their needs were, and therefore made their implementation successful. This shows how adaptable IT can be beneficial when driven by an existing business infrastructure (Henderson & Venkatraman, 1993). Transforming to fit this unique organization shows promise that REA systems can benefit many different types of companies. The most important component of any business is the bottom line. This study determined that the SOE was able to implement their system under their anticipated cost. The projected TCO savings of $600,000 ($400,000 currently realized) after system implementation would be a highlight in almost any executive’s eyes. Such short-term realizable fiscal benefits may also Show that system design may affect the perception that gains are not noticed from IT investment for several years (Brynjolfsson & Hitt, 2000). In other words, properly designed systems may bring a positive financial change quicker for organizations. Implementing a system cheaply and having a significant return on investment makes an REA-driven system seem valuable. 52 User Reaction Throughout the study, users of the REA system used the word “intuitive”. This reinforces the philosophy of REA: a system design should be based on real world semantics. This way a system can avoid unnecessary confusion that makes a user’s job more difficult. This confusion seemed non-existent with the users of the REA system. Some users mentioned how they required little training. Even a user who seemed to strongly dislike new technologies found the system easily understandable. The REA system ran smoothly because of this ease of use. The data was even collected more accurately because the system related to their personal jobs. The ability to relate to a user specific job made the REA system more beneficial. Since the REA system is able to focus on employee specific processes it is able to create a role-based presentation for each user. This allows users to view the detail at the task level of their processes, giving the system purpose for each user. Giving an enterprise system purpose aligns individual objectives to achieve overall organizational goals. This further proves that users desire a system for their own unique needs (Markus, etaL,2000) Simian Flfltibilitv The REA ontology focuses on processes and the items within. By building a structure around objects and not accounting specific semantics a system can be flexible to change. One only has to see how simplistic the general ledger of the SOE has become to understand that REA relies on data derived in a procedural manner — thereby keeping structural integrity while allowing flexibility. 53 This flexibility was shown within the SOE on multiple occasions. The most dramatic example was the addition of an entirely new business to their system. To model this organization’s distinct business processes within a couple of days illustrates the flexibility of an REA system. Other instances include the need to rearrange the classification of consultants as well as medical staff. This flexibility allowed the SOE to view their organization in accordance with their own strategic goals. This should be the emphasis of enterprise systems: staying aligned with the goals of an organization. REA systems have shown in this study that they are capable of following the evolution of an. organization. Encompassithhe Enterprise An enterprise system should be a complete representation of how an organization operates. If certain components are left out of the design, then the system will not function at its potential. The REA system was able to serve employees of the SOE on the task level by showing their personal tasks. This enabled the system to aggregate data in an accurate way for all other users of the system. Since the tasks were tied to business processes mangers could “drill down” to the appropriate data they need. Evidence of the improved efficiencies through more organized data could be seen in the SOE after implementation. The company was able to grow without adding additional staff. This shows how the REA system was able to carry the weight that once rested on the SOE staff. This was partially accomplished by reducing cycle times. If an organization can get through a process quicker then they can focus their energy towards other areas of innovation and growth — growth which continues to occur at the SOE, 54 thanks to its REA system. Another instance of an intangible benefit produced by the implementation of a properly aligned IT (Brynjolfsson & Hitt, 2000). 55 CHAPTER 7 Limitations and Further Research Limitations existed in the study because only one vendor is currently using the REA ontology in their system design. Furthermore, the REA system is a relatively new enterprise system. This has lead to only part of the system modules being released for use. Because only the financial and HR modules have been released, this study had somewhat limited options for research. The study opted for the organization that had been using the most modules of the REA system for the longest amount of time. Having an organization with only part of the modules implemented affected aspects of the study, particularly question four. To compensate, the study followed the business processes applicable to the modules being studied. This way the study could analyze a portion of the system from the upper to lower levels without having to bring other business cycles into the framework. The presence of add-ons was also an issue since it is unknown whether they would exist in a fully implemented REA system. The amount of time the system has been used by the SOE also created a limitation. If the system had been used for more time then there may be more realized value. The system was still in its infancy and the study could not predict what future gains would occur. Further research could be done to gather empirical evidence of the differences between REA and traditional ERP system. The same areas could be of focus but with a greater sample size of organizations. The evidence could also be more concrete by allowing more time for organizations to implement REA systems. This study only 56 attempted to explore what is possible with REA systems, others should test that this value is achievable and sustainable in other organizations. 57 REFERENCES Abdinnour-Helm, S., Lengnick-Hall, M. L., & Lengnick-Hall, C. A. (2003). Pre- implementation attitudes and organizational readiness for implementing an enterprise resource planning system. European Journal of Operational Research, 146(2), 258. Allen, B. R., & Boynton, A. C. (1991). Information Architecture: In Search ofEfficient “Flexibility. MIS Quarterly, 15(4), 435-445. Batini, C., Lenzerini, M., & Navathe, S. B. (1986). A Comparative Analysis of Methodologies for Database Schema Integration. ACM Computing Surveys, 18(4), 323-264. Bendoly, E., Soni, A., & Venkataramanan, M. A. (2004). Value chain resource planning: Adding value with systems beyond the enterprise. Business Horizons, 47(2), 79- 86. Blain, J ., & ASAP World Consultancy. (1999). Using SAP R/3 (3rd ed.). Indianapolis, IN: Que. Brynjolfsson, E., & Hitt, L. (1996). Paradox Lost? F irrn-Level Evidence on the Returns to Information Systems Spending. Management Science, 42(4), 541-558. Brynjolfsson, E., & Hitt, L. M. (1998). Beyond the Productivity Paradox. Communications ofthe ACM, 41(8), 49-55. Brynjolfsson, E., & Hitt, L. M. (2000). Beyond Computation: Information Technology, Organizational Transformation and Business Performance. Journal of Economic Perspectives, 14(4), 23-48. Byrd, T. A., & Turner, D. E. (2001). An exploratory examination of the relationship between flexible IT infrastructure and competitive advantage. Information & Management, 3 9(1 ), 41 -52. Carr, N. G. (2004). Does 1T matter? : information technology and the corrosion of competitive advantage. Boston: Harvard Business School Press. Davenport, T. H. (2000). Mission critical .' realizing the promise of enterprise systems. Boston, MA: Harvard Business School Press. David, J. S., McCarthy, W. E., & Sommer, B. S. (2003). Agility---: the key to survival of the fittest in the software market. Commun. ACM, 46(5), 65-69. 58 David, P. A. (1990). The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox. The American Economic Review, 80(2), 355-361. Geerts, G. L., & McCarthy, W. E. (2002). An ontological analysis of the economic primitives of the extended-REA enterprise information architecture. International Journal of A ccounting Information Systems, 3(1), 1-16. Gurbaxani, V., & Whang, S. (1991). The impact of information systems on organizations and markets. Commun. ACM, 34(1), 59-73. Henderson, J. C., & Venkatraman, N. (1993). Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems Journal. 32(1), 4. Holland, C. P., & Light, B. (1999). A critical success factors model for ERP implementation. IEEE Software, 30-36. Hong, K.-K., & Kim, Y.-G. (2002). The critical success factors for ERP implementation: an organizational fit perspective. Information & Management, 40(1), 25-40. Lee, C. S. (2001). Modeling the business value of information technology. Information & Management, 39(3), 191-210. Lum, V. Y., Ghosh, S. P., Schkolnick, M., Taylor, R. W., Jefferson, D., Su, S., et al. (1979). I 978 New Orleans Data Base Design Workshop Report. Paper presented at the Fifth lntemational Conference on Very Large Data Bases. Markus, M. L., Petrie, D., & Axline, S. (2000). Bucking the Trends: What the Future May Hold for ERP Packages. Information Systems Frontiers, 2(2), 181-193. Markus, M. L., & Tanis, C. (2000). The enterprise systems experience—from adoption to success. In R. W. Zmud (Ed.), Framing the Domains of IT Research: Glimpsing the Future Through the Past (pp. 173-207). Cincinnati: Pinnaflex Educational Resources Inc. McAfee, A. P. (1999). Rich-Con Steel. Harvard Business School. McCarthy, W. E. (1982). The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment. The Accounting Review, 57(3), 554-578. McCarthy, W. E. (2009). An REA Model of an Economic Exchange, from mtp://www.n_1su.edu/user/mccartl_r_fl 59 McCarthy, W. E., & Geerts, G. L. (2000). The ontological foundations of REA enterprise information systems. Michigan State University. Montazemi, A. R., Cameron, D. A., & Gupta, K. M. (1996). An empirical study of factors affecting software package selection. Journal of Management Information Systems, 13(1), 89. O'Leary, D. E. (2004). On the relationship between REA and SAP. International Journal of A ccounting Information Systems, 5(1), 65-81. Orlikowski, W. J ., & Gash, D. C. (1994). Technological frames: making sense of information technology in organizations. ACM Trans. Inf Syst, [2(2), 174-207. Orlikowski, W. J ., Yates, J ., Okamura, K., & Fujimoto, M. (1995). Shaping Electronic Communication: The Metastructuring of Technology in the Context of Use. Organization Science, 6(4), 423-444. Porter, M. E. (1985). Competitive advantage .' creating and sustaining superior performance. New York: Free Press. Powell, T. C., & Dent-Micallef, A. (1997). Information technology as competitive advantage: The role of human, business, and technology resources. Strategic Management Journal, 18(5), 375. Rettig, C. (2007). The Trouble With Enterprise Software. MIT Sloan Management Review, 49(1), 21-27. Saarinen, T., & Vepsalainen, A. P. J. (1994). Procurement strategies for information systems. Journal of Management Information Systems, 11(2), 187-208. Severance, D. G., & Passino, J. (2002). Making I/T work .' an executive 's guide to implementing information technology systems (1 st ed.). San Francisco: J ossey- Bass. Soh, C., Kien, S. S., & Tay-Yap, J. (2000). Enterprise resource planning: cultural fits and misfits: is ERP a universal solution? Commun. ACM, 43(4), 47-51. Soh, C., & Sia, S. K. (2005). The Challenges of Implementing "Vanilla" Versions of Enterprise Systems. MIS Quarterly Executive, 4(3), 373-384. Solow, R. M. (1987, July 12). We'd Better Watch Out The New York Times Book Review, p. 36, Ullman, J. D., & Widom, J. (2002). A first course in database systems (2nd ed.). Upper Saddle River, NJ: Prentice Hall. 60 Venkatesh, V., Morris, M. G., Gordon, B. D., & Davis, F. D. (2003). User Acceptance of Information Technology: Toward a Unified View. MIS Quarterly, 27(3), 425-478. Venkatraman, N. (1994). IT-Enabled Business Transformation: From Automation to Business Scope Redefinition. Sloan Management Review, 35(2), 73. Yin, R. K. (2003). Case study research .' design and methods (3rd ed.). Thousand Oaks, Calif: Sage Publications. 61 “llillili1111111111111“