Achieving business and IT integration is strategic goal for many organisations – it has almost become the ‘Holy Grail’ of organisational success. In this environment Enterprise Resource Planning (ERP) packages have become the defacto option for addressing this issue. Integration has come to mean adopting ERP, through configuration and without customization, but this all or nothing approach has proved difficult for many organisations. In part 1 of a 2 part update we provide evidence from the field that suggests that whilst costly, if managed appropriately, customization can have value in aiding organisational integration efforts. In part 2, we discuss in more detail the benefits and pitfalls involved in enacting a non-standard based integration strategy

Light, Ben

Wagner, Erica

Queensland University of Technology ePrints Archive

This is the author’s version of a work that was submitted/accepted for pub-lication in the following source:Light, Ben &Wagner, Erica (2006) Achieving enterprise integration throughsoftware customization : part I-evidence from the field. Cutter ExecutiveUpdate.This file was downloaded from: http://eprints.qut.edu.au/75730/c© Copyright 2006 [please consult the author]Notice: Changes introduced as a result of publishing processes such ascopy-editing and formatting may not be reflected in this document. For adefinitive version of this work, please refer to the published source: 1Achieving Integration Through Selective ERP Customizations:  Part 1: Evidence From the Field   Ben Light and Erica Wagner    Introduction Achieving business and IT integration is strategic goal for many organisations – it has almost become the ‘Holy Grail’ of organisational success.  In this environment Enterprise Resource Planning (ERP) packages have become the defacto option for addressing this issue.  Integration has come to mean adopting ERP, through configuration and without customization, but this all or nothing approach has proved difficult for many organisations.  In part 1 of a 2 part update we provide evidence from the field that suggests that whilst costly, if managed appropriately, customization can have value in aiding organisational integration efforts.  In part 2, we discuss in more detail the benefits and pitfalls involved in enacting a non-standard based integration strategy. ERP packages are commonly seen as ‘the’ solution – they are sold on the basis of providing integrated support, through the standardization of work activities, for common business practices such as sales and distribution, manufacture and supply, human resources and finance.  The argument put forward by vendors, implementation intermediaries and even adopters is that achieving integration using an ERP package is a lifestyle choice that requires adherence to the design rationale inscribed within the software.  From this perspective the vanilla ERP represents the best practice and customization is discouraged.  The industry press reveals many war stories and quotes surrounding the implications of customizing for increasing the overall total cost of ownership (TCO) of ERP.  TCO accounts for lifecycle costs such as licenses, implementation, training, maintenance and upgrades.  Indeed, the VP of marketing for PeopleSoft Global Services suggests that customizing can cost almost 100% of its initial development cost, to maintain over its lifetime [1].  However, whilst acknowledging the TCO implications of customizing, we argue that sometimes customizations can be less expensive than adopting the standard model, for example where they usurp significant process change and improve the user experience.   Moreover, there is increasing evidence that many ERP projects are defined as failures (in terms of return on investment, time, budget and level of functionality in use post implementation) by those directly involved, despite the achievement of an integrated flow of organizational information.    Part of the problem appears to be that the desire for an integrated operating environment further creates what has been called ‘myths of integration’ [2].  In this case, myths of integration refer to the practices of users saying they are achieving integration solely through the standard model when they are also customizing to create a workable system.  Even the 80:20 (standardization:customization) ratio espoused by many implies this [3], a figure which has been  2further undermined by some studies which show standard fit as low as 30% in some areas [4].  Thus, whilst standards based integration is a valuable idea in theory, the best practice model that underpins ERP software can be problematic.  When firms have to facilitate multiple, and often conflicting agendas, modeling processes and system configurations based on 'flipping the switches' of configuration decisions means that many practices are overridden in favor of a standard way of working.  This means that integration ends up being achieved through homogeneity, or forced acquiescence [5].  In this article we argue that the standardization of practices through software design is not the only approach to achieving integration.  In fact, to perpetuate the notion that the former is a prerequisite for the latter is restrictive and potentially expensive for implementing organizations – consider Fox Meyer’s experience where bankruptcy proceedings were linked to the implementation of a standardised SAP package.  Instead, we argue for a rethinking of integration.  A dictionary definition of integration does not refer to the method by which integration must be achieved.  Rather, it is defined as an action or process focused on 'making up or composing a whole by adding together or combining separate parts or elements' (Oxford English Dictionary).  The implication - there might be multiple ways to 'make whole' or 'entire' previously disparate parts.  Of course, customization is going to add to the overall TCO, we would be remiss if we failed to acknowledge such work has varying degrees of organizational implications, but it may be essential or potentially valuable and thus worth paying extra for.  However, the approach has to be carefully managed if client organizations are to realize the promises of ERP in practice.  For this reason, we advocate selective negotiation with regards to such customization activities.  Thus, if done ‘strategically’ (meaning not for everyone and not accommodating every request) it can ease tensions, and sustain employees through the complex transitional phases that are usually part of such projects.  In the remainder of this article we draw primarily upon insights from two longitudinal case studies of ERP implementations to illustrate these points.  The first case, ‘Cable’ is an international conglomerate, and the second ‘Home’ a national building merchants.  The illustrative examples are drawn from project documentation and interviews conducted with a cross section of staff at both organizations.  Lessons from the field: Customization as Integration In this article, customization refers to changes or additions to the package beyond configuration.  To elaborate upon this, we use a synthesized set of those categories put forward by Brehm et. al. and Light [6,7] as shown in Table1.  Our fieldwork suggests that different types of customizations might be required to achieve integration and that they can be used as a negotiation tool to smooth the standards-based aspects of the ERP integration strategy – customizations help to broker with powerful end user groups who may acquiesce their preferences in one area if they are appeased in another.  We also point to some of the pitfalls of performing customizations with particular emphasis on the TCO.  Drawing upon examples of customization work at Cable and Home, these points are now discussed.     3Table 1. Customization Types Reporting The addition of reports not available in the standard package or changing existing ones.  Display Interface development in the form of field name changes or field layout rearrangement. Process Automation/Redesign  Processes inscribed into the software are automated or redesigned, sometimes known as workflow programming.  This may, for instance, involve changing the number of screens viewed or keystrokes performed. Functionality  The creation of new functionality that was absent from the original product, or changing what was there.  This may require creating ‘bolt-on’ applications or changes to source code.   Reporting: Customizing to Keep an Integrated Data Set  Historically, Home’s staff had used Key Performance Indicator (KPI) reports to monitor and manage business performance.  Although, many KPI reports were already available in the package, additional ones had to be created during the implementation.  These customizations were targeted at staff who were developing stand alone spreadsheet based systems, which was against the project objective of “an integrated view of the firm”.  The customizations aimed to satisfy the needs of these people so they would rely on the package and contribute to the integration of the firm.  The Business User Group Leader stated that the customizations had increased user acceptance of the single ERP data set because reporting was tailored to user requirements.  Display: Integration through Talking the Same Language At Home, in the early stages of implementation a number of user requests came through for changes to labels and descriptions in many of the sessions. To get the system integrated into their working lives, the staff wanted it to speak their language.  But these requests contradicted the objective of creating common ‘package-based’ terminology across the group. Thus, the project team refused these requests.  This led to problems as users perceived the changes as small, low cost solutions and didn’t understand why their requests were rejected.  However, over time, the project team became more knowledgeable and were able to negotiate with users in favor of the standard, especially because they selectively customized the product in other areas.  A few essential display customizations were performed towards the end of the project.  The project team felt it would have led to many more requests had they been done earlier.   This case illustrates the value of selectively choosing customization and leveraging social capital from within the organization.  Moving away from a ‘blanket’ strategy of pure vanilla implementation meant that users were willing to accept a ‘no’ decision when it was necessary.   4Process Automation/Redesign: Integration on the Shop Floor During implementation at Cable, it became clear that the package’s progress reporting screens were too complex.  A trial of the new shop floor procedures was undertaken - 17% of the data entered was inaccurate resulting in rework costs of 6,000 dollars.  So, the project team used an applications programming interface (API) tool to simplify the screens and make them look similar existing systems.  The error rate was reduced to 8% immediately and was virtually eliminated within two weeks.  This customization had explicit and implicit roles.  The simplified interface integrated with the needs of users so they could be more efficient in their work in the ERP-enabled environment.  However, because it was recognized that existing legacy practices were valued by this group, the project team strategically determined that it was right to continue working ‘as was’ because it would help during implementation – less training was required.    Functionality: The Integration of Policy and Package Home’s pricing policy incorporated three interrelated conditions: product, customer and location resulting in 26 million different prices.  Senior management recognized that changes would require negotiation with customers, adding an unacceptable level of complexity to the implementation.  Thus, the customization performs the necessary calculations to generate the prices in a small ‘bolt on’ custom development and then integrates these with the ERP package.  This customization was viewed as a form of ‘stop gap’ integration whereby it was seen as a temporary integration link, a means to an end, rather than the end.  The ‘end’ in this case being a reworking of the pricing policy of in line with the standard package.  Thus, the customization was performed with the intention of smoothing the implementation for employees and customers, but with a view to it being disposed of eventually.  However, the customization work took 5 months to complete; no invoices were sent out for three months after ‘go live’ and then 30% were incorrect.  Yet, despite these problems, the customization was essential.  Had it not been undertaken the project would have been even more severely delayed, other ERP related gains would not have been realized and a pricing policy change would have been forced onto the customer base which would have undoubtedly had a detrimental impact on sales.  Avoiding the standardization trap: What should organizations do? So how can an ERP package be more readily integrated with existing organizational arrangements?  A summary of some of the ways of approaching this difficult task, based on our findings from the field is shown in Table 2.  In the next update, the ways of integrating an ERP package with existing organizational arrangements will be discussed in more detail.  Table 2: Integrating Through Customization  Broaden the integration definition:   Recognize integration can be achieved in different ways.      5Bring legacy practices forward:   Solicit opinions from valued team members in order to recognize value in what you have already and the fact that there will be elements of integration in place before you implement ERP.    Based on power relations, determine which existing arrangements will be kept, replaced, modified and added to.  Realize that the old and new co-existing is sometimes a savvy approach.   Develop a ‘customization friendly’ integration strategy:    Realize there are costs and benefits where customization is performed and quantifying these is not a purely financial exercise.  Rather it will require input from multiple stakeholder groups by asking ‘what if’ type questions…what if we were to force this change….versus moving the legacy practices forward.  Publicize a realistic strategy on customization to help coordinate the activity.    Note the levels of invasiveness of customizations and their roll out strategy – these are key contributors to the TCO.  Use customizations politically to secure commitment for more difficult areas of a project.   References [1] McCall, J. (2003), "Seven Ways to Secure an Effective ERP Roll Out", Integrated Solutions, April, Accessed: 1 November 2005. [2] Alvarez, R. (2002), "The Myth of Integration: A Case Study of an ERP Implementation", in Hossain, L., Patrick, J. D. and Rashid, M. A. (Eds), Enterprise Resource Planning: Global Opportunities and Challenges, Idea Group, London, pp. 17-42. [3] Holland, C. and Light, B. (1999) “A Critical Success Factors Model for ERP Implementation”, IEEE Software, 16(3), pp. 30-36. [4] Sieber, T., Siau, K., Nah, F. and Sieber, M. (2000), "SAP Implementation at the University of Nebraska", Journal of Information Technology Cases and Applications, 2(1), pp. 41-72. [5] Wagner, E. L. and Newell, S. (2004), "Best for Whom?  The Tension Between 'Best Practice' ERP Packages and the Diverse Epistemic Cultures in a University Context", Journal of Strategic Information Systems, 14(4), pp. 305-328.  [6] Brehm, L., Heinzl, A. and Markus, M. L. (2001), "Tailoring ERP Systems: A Spectrum of Choices and their Implications", in Proceedings of the 34th Hawaii International Conference on System Sciences IEEE Press: Maui, Hawaii.  6 [7] Light, B. (2001), "The Maintenance Implications of the Customization of ERP Software", The Journal of Software Maintenance: Research and Practice, 13(6), pp. 415-430.  7  

Achieving enterprise integration through software customization: part I - evidence from the field

http://eprints.qut.edu.au/75730/3/75730.pdf

Achieving enterprise integration through software customization: part I - evidence from the field

Abstract

Similar works

Full text

Available Versions

Queensland University of Technology ePrints Archive