منطق حسابداری، پیکر بندی دوباره ی سیستم های ERP و ظهور شیوه های حسابداری جدید : چشم انداز مواد اجتماعی

This paper extends our knowledge on how software-based accounting tools might work effectively within an organization. The empirical data that we focus on are events that unfolded following the introduction of a new ERP system at an Ivy League University. We describe a negotiation process that occurred after roll-out that resulted in a reconfiguration of the ERP to integrate some of the legacy functionalities that were familiar to organizational participants and which were considered by them to provide a more effective way to manage their finances. Our contribution to the literature is not only to show the importance of such post-roll-out modifications for creating a working information system, but also to extend previous accounts of non-linear accounting change processes by emphasizing how these modifications are dependent on the particular entanglement of users and technology (the sociomaterial assemblage) rather than either features of the technology or the agency of the humans involved. Moreover, our analysis of the case data suggests that management accounting in particular may not be easily captured in ERP packages, even where the technology architectures are supposedly designed for a particular industry. The case data also points to issues of affordability and the power of communities of practice as mediating the extent to which these familiar accounting logics may become integrated within the ERP system.

In the face of competitive global markets and constant innovations in technology and business models, changes to accounting information systems are often implemented. In particular, many organizations adopt accounting software packages (as variants of Enterprise Resource Planning [ERP] systems) to improve the transaction processing capabilities (Booth et al., 2000 and Dechow and Mouritsen, 2005), co-ordinate record keeping (Chapman and Kihn, 2009), reduce costly duplications of data (Dillard and Yuthas, 2006 and Scapens and Jazayeri, 2003), enable centrally stored information, making it easier to create different types of financial reports (Chapman and Chua, 2003) and improve fiduciary control (Wagner and Newell, 2006). Much of the literature in accounting has assumed such technology to be an ‘exogenous’ force of change for accounting work routines (Granlund and Malmi, 2002, Rom and Rohde, 2006, Rom and Rohde, 2007 and Scapens and Jazayeri, 2003). From this view, the functionality of the system is set when the adopting organization “flips the switches” of thousands of embedded templates. These templates provide the organization with a catalogue of standard work practices – the so-called ‘best practice’ logic purportedly embedded within the product (O’Leary, 2000, Wagner and Newell, 2004, Wagner et al., 2006 and Sia and Soh, 2007). Once the configuration options are selected this will supposedly determine how accounting will be practiced. However, technology alone cannot force practice change, especially when the ‘best practice’ design logic is misaligned with the legacy practice logics. Where such incompatibility exists resistance is often encountered (Berente et al., 2007). These kinds of problems are prominent in relation to the implementation of ERP systems because their integrated nature means that the work processes of different groups and departments become more tightly coupled than was often the case in the legacy system environment when each department/function had its own stand-alone IT system. Research shows that often organizations only realize the incompatibility in practice logics once the configured system is rolled-out and users find that they can no longer carry out their legacy work practices and so begin to resist (Wagner et al., 2010 and Leonardi and Barley, 2008). This leads many organizations into a prolonged period of negotiation and may result in substantial customizations to the ERP (Wagner and Newell, 2006) or other adaptations, despite this practice being discouraged by vendors and traditional systems development theories (Boudreau and Robey, 2005, Berente et al., 2007, Berente et al., 2008 and van Fenema et al., 2007). For instance, prior field studies (Malmi, 2001 and Granlund and Malmi, 2002) have demonstrated that as ERP implementation projects unfold, and there is realization that the system is unable to cope with the accounting demands, organizations are prone to developing separate spreadsheet solutions or specialised software such as Cognos that can provide more flexible analysis of the accounts. These studies have shown that specialized software used to capture the specifications required of advanced management accounting techniques, such as the balanced scorecard and activity based costing, may over time be added to ERP-type technologies. That ERP systems might require such modification has led several scholars to be critical of using them for management accounting purposes arguing they are too complex for this type of architecture (see Rom and Rohde, 2007, p. 50). They suggest that ERP systems be viewed as transactional management systems that are not designed for strategic level management. Furthermore, stand-alone software systems, which can provide a more user-friendly and flexible basis for analysis and reporting and more ad hoc management accounting practices, may provide a less risky and more cost effective alternative (Rom and Rohde, 2006 and Hyvönen, 2003). But, evidence from scholars such as Chapman and Kihn (2009) suggest that managers can be satisfied with systems that possess high levels of integration even where they do not lead directly to improvements in performance. In keeping with the later cadre of research, we extend knowledge related to how ERP technologies are made to work as systems (Chapman, 2005) through a non-linear process of change (Quattrone and Hopper, 2001). We provide an analysis of a case that shows how ERP systems can be reconfigured to incorporate legacy practices and satisfy the flexibility (i.e. precision and frequency) demanded of managerial accounting. In doing this, we demonstrate not only the importance of post-roll-out modifications for creating a working information system, but also emphasize how these modifications are dependent on the particular entanglement of users and technology (the sociomaterial assemblage). In adopting this perspective, we seek to go beyond realist accounts that focus on the features of the technology determining structures or social constructionist accounts that emphasize the agency of the humans involved (Leonardi and Barley, 2010). We identify how contexts of use will differ in terms of the types and scope of modification that are made in the post-roll-out phase and thereby extend the literature on accounting change as non-linear and relational in nature (in particular, Andon et al., 2007, Dechow and Mouritsen, 2005 and Quattrone and Hopper, 2006). In this paper then, we do not reject the potential usefulness of an ERP system for management accounting but rather argue that the value of any information system, whether it be integrated or standalone, can only be understood by focusing on how accounting, IT and its users are entangled to produce managerial accounting practice. With this in mind we focus on two research questions: (1) what and how are accounting logics encoded within ERP systems? and (2) how, in the process of users interacting with the ERP and retrieving information, do new accounting practices emerge and does the system become reconfigured to support them? These questions allow us to consider how the logics underpinning practice are sensitive to local circumstances and cannot be fully specified in any “strongly determinant way” (Suchman, 2007, p. 53) even though ERP-architectures inscribe, in their vanilla-state, particular ideals about practice, i.e., particular practice logics. We explore the questions by examining the post-implementation negotiations of a troubled ERP project in an Ivy League university. The project was at risk of being abandoned because of the practice logics that were initially configured into its grant accounting module. The ERP was configured to support the financial accounting needs of the central administrative function composed of professional accountants. However, the integrated nature of ERP meant that these system architectures were not sufficiently flexible for enabling faculty to manage their research project budgets in their preferred ways. We thus identify how the ERP-system was customized to enable the university (hereafter ‘Ivy’) to accommodate the practices of both the financial accounting centre and the faculty managing their project budgets. The remainder of the paper is structured in 4 sections. In Section 2 we discuss the key concepts which inform the sociomateriality lens, enabling us to “see in the data” the process of negotiation that occurred within the case of a university in the post-implementation phase of their ERP project, ultimately resulting in that system drifting to eventually support some legacy-type practices even though initially these were explicitly excluded. Section 3 outlines our research methods. Section 4 presents the case description and analyzes two grant accounting practices and the negotiation process that ensued at go-live. In Section 5 we discuss the meaning and implications of our analysis for implementing enterprise-wide accounting functionality within organizations. The paper concludes with suggestions for future research.

The case of Ivy has a number of important theoretical and practical implications for our understanding of how accounting and information architectures are linked. From a theoretical perspective, our research demonstrates the applicability of the sociomateriality perspective for ERP systems in terms of explaining the links between accounting and information system development more generally. The resistance to the ERP system was instigated by individuals responsible for management accounting functions. We argue therefore that the sociomateriality perspective offers a suitable lens for exploring the links between management accounting practices and ERP systems because the nature of management accounting is such that it must be determined by managers’ local practice needs. Thus, it needs to be far more flexible than its financial accounting counterparts, which may face fewer problems in terms of expressing the parameters of a function by making reference to accounting standards or regulations and thus capable of working using an end-user model. Put another way, it may not be as easy to program management accounting practices thus many of the design decisions regarding the logics occur ex ante to the initial time when the ERP architecture is designed. It is interesting to see that this was the case even in the situation where the ERP architecture was being designed for the specific university. In other cases, where they are adopting a standard package, not trying to design an industry-specific package, this post-roll-out design modification may be even more likely in relation to the management accounting functionality. That being said, an important contribution of this study is to show that such post-roll-out design modification is neither as difficult as Dechow and Mouritsen (2005) indicate when they state that the accounting structure is ‘only plastic in the pre-practice project mode’ (i.e., before implementation), nor as easy as Quattrone and Hopper (2006) indicate with their concept of ‘heteromogeneous’. Rather, our analysis demonstrates that the scope of post-roll-out modification (the practices which get accommodated and those which do not) and the type of such modification (reconfigurations versus supplements) depends not on either the people involved (as social constructionists would emphasize) or features of the technology (as realists would emphasize) but rather on the sociomaterial assemblage. Thus, the technology may be customable but if there are no experts to undertake customizations, the package may as well be non-plastic so that only supplements (adaptations around) can be made. And, even if the package is customable and experts are on-hand, not all practice communities will be able to get the design changes that they request. Only selective accommodations were made at Ivy and these were made where the resistance was coming from powerful sources that ‘had to be listened to’. The social and material actors that make up a particular assemblage, in other words, are not all equal, something that is often ignored in the literature. Moreover, our findings also indicate that the process of accounting change may not always be best characterized as ‘relational drifting’ as emphasized by Andon et al. (2007). In a situation where the practices of a powerful community are ignored in the ERP configuration, experimentation may actually be rather minimal, and instead the modifications that are introduced may reinforce legacy practices. Following on from this point, the case study results also provide valuable insights into how legacy accounting systems can continue to operate at the margins when new systems are introduced and may become central to the workability of these systems when staff fail to accept them. This is different from other accounting studies, such as Hyvönen et al. (2008) which demonstrate instances where ERP systems are initially designed to mirror the prevailing practices rather than being seen as an opportunity to develop and implement a more sophisticated form of accounting. In Ivy, the ERP was designed specifically to try and enforce a more sophisticated, or as the VP of Finance saw it, a more ‘professional’ form of accounting. The result, however, was virtually opposite to what was being sought by the centre, with the backlash from faculty reinstating and indeed reinforcing their legacy accounting practices that were now part of the formal systems. This emphasizes that it is important to look not simply at what is intended when introducing ERP-type systems but also to examine how the system is configured and then subsequently reconfigured and supplemented. The Ivy case also highlights that even when an ERP is designed to mirror prevailing practices (whether immediately or through a post-roll-out modification) it is important to examine how accounting is performed. In Ivy, the routine of preparing commitment accounting information had changed post-implementation of the ERP system to involve two support centres in the process. In this sense, our findings go beyond those of Scapens and Jazayeri (2003) and Hyvönen et al. (2008) who conclude that ERP produces limited changes in the management accounting. At one level in Ivy one could conclude that there had been little change in the management accounting practice, but this would ignore the fact that there were now new ways of performing management accounting that were quite different compared to the legacy environment. Focusing on the performance of management accounting rather than simply the data that is used and produced, also enabled us to see how the extent to which the ERP system was able to work effectively was also bound up in the affordability of workaround solutions. Once the ERP system was in place and PIs were confronted with the poor information architectures for providing relevant grant information their ability to replicate their previous practices was in part limited by the affordability of the work-around solutions. Those departments with limited funding were forced to adopt solutions at a university level, while the more profitable schools benefited by developing solutions that were sensitive to their local circumstances. Andon et al. (2007) also identified how resource constraints influenced how participants found solutions to dilemmas following the introduction of new accounting practices. However, they did not emphasize how these constraints might vary considerably within an organization, leading potentially to exaggerated differences between ‘winners’ and ‘losers’ in terms of their ability to perform accounting. The case of Ivy University also has a number of interesting implications for our understanding of ‘best practice’ and ‘cutting edge’ ERP (see, Chapman and Chua, 2003 and Dillard and Yuthas, 2006). What is clear in the Ivy case is that even though the organization provided the opportunity to develop standardised information architectures for the industry, experience with developing packages and knowledge of general accounting conventions prevailed. The legacy assets and practices were ignored. Consequently, practices such as commitment accounting were customized for Ivy, but were not integrated in the industry-specific solution. This can in part be explained by the absence of ‘users’ (i.e. PIs) in the design of the industry specific solution. This absence meant that the scaffolding of the ERP system created barriers that prevented it from being useful to faculty. Furthermore, vendors who want to sell a standard ‘best practice’ product have not acknowledged the evolutionary nature of sociomaterial assemblages including accounting practices. On one level, this raises questions about whether many other institutions find themselves having to ‘bolt-on’ applications given their similarity in terms of the receipt of grant funding. On another, it raises questions about the hidden technology-human costs that arise because of the need to work around the simplified and partial ‘best practice’ methods that are inscribed in the ERP architectures. Finally, it also raises questions about the extent to which such systems can remove the need for any knowledge of accounting and expect such systems to provide accurate data for the financial accountants. These are important questions that could be analyzed in future research.