A hiccup or a rift? ERP implementation success in Jordan

Like many other developing countries, Jordan is adopting Enterprise Resource Planning (ERP) systems in both its public and private sectors. Jordan's emerging private sector has historically close ties to the public sector, though a global market orientation requires a shift in its organisational culture. ERPs however embed business processes which do not necessarily fit with traditional cultural practices, and implementation success is not assured.. This study looks at the perceptions of both public and private sector ERP implementations in Jordan and assesses these on various measures of success. There were few differences between public and private sectors, but the benefits actually realized in Jordanian ERPs fell short of claims made for the technology in other cultures. Considerable customisation was required in both sectors, and the traditional style of management in Jordan did not fit well with the requirements for successful implementation. This is consistent with recent studies from various countries that show cultural fit is a particularly neglected factor in assessing ERP success.

Transaction mining for fraud detection in ERP Systems

Despite all attempts to prevent fraud, it continues to be a major threat to industry and government. Traditionally, organizations have focused on fraud prevention rather than detection, to combat fraud. In this paper we present a role mining inspired approach to represent user behaviour in Enterprise Resource Planning (ERP) systems, primarily aimed at detecting opportunities to commit fraud or potentially suspicious activities. We have adapted an approach which uses set theory to create transaction profiles based on analysis of user activity records. Based on these transaction profiles, we propose a set of (1) anomaly types to detect potentially suspicious user behaviour, and (2) scenarios to identify inadequate segregation of duties in an ERP environment. In addition, we present two algorithms to construct a directed acyclic graph to represent relationships between transaction profiles. Experiments were conducted using a real dataset obtained from a teaching environment and a demonstration dataset, both using SAP R/3, presently the predominant ERP system. The results of this empirical research demonstrate the effectiveness of the proposed approach.

Fraud detection in ERP systems using scenario matching

ERP systems generally implement controls to prevent certain common kinds of fraud. In addition however, there is an imperative need for detection of more sophisticated patterns of fraudulent activity as evidenced by the legal requirement for company audits and the common incidence of fraud. This paper describes the design and implementation of a framework for detecting patterns of fraudulent activity in ERP systems. We include the description of six fraud scenarios and the process of specifying and detecting the occurrence of those scenarios in ERP user log data using the prototype software which we have developed. The test results for detecting these scenarios in log data have been verified and confirm the success of our approach which can be generalized to ERP systems in general.

ERP systems implementation and organizational culture : the case of Jordan

Jordan is adopting Enterprise Resource Planning (ERP) systems in both its public and private sectors. Jordan's emerging private sector has historically close ties to the public sector; though a global market orientation requires a shift in its organizational culture. ERPs however embed business processes which do not necessarily fit with traditional cultural practices, and implementation success is not assured. This study looks at the perceptions of both public and private sector ERP implementations in Jordan and assesses these on various measures of success. There were few differences between public and private sectors, but the benefits actually realized in Jordanian ERPs fell short of claims made for the technology in other cultures.

What is ERP?

Though enterprise resource planning (ERP) has gained some prominence in the information systems (IS) literature over the past few years and is a significant phenomenon in practice, through (a) a historical analysis, (b) meta-analysis of representative IS literature, and (c) a survey of academic experts, we reveal dissenting views on the phenomenon. Given this diversity of perspectives, it is unlikely that at this stage a broadly agreed definition of ERP can be achieved. We thus seek to increase awareness of the issues and stimulate further discussion, with the ultimate aim being to: (a) aid communication amongst researchers and between researchers and practitioners; (2) inform development of teaching materials on ERP and related concepts in university curricula and in commercial education and training; and (3) aid communication amongst clients, consultants and vendors. Increase transparence of the ERP concept within IS may also benefit other aligned fields of knowledge.

The maintenance implications of the customization of ERP software

Enterprise resource planning (ERP) software is a dominant approach for dealing with legacy information system problems. In order to avoid invalidating maintenance and development support from the ERP vendor, most organizations reengineer their business processes in line with those implicit within the software. Regardless, some customization is typically required. This paper presents two case studies of ERP projects where customizations have been performed. The case analysis suggests that while customizations can give true organizational benefits, careful consideration is required to determine whether a customization is viable given its potential impact upon future maintenance. Copyright © 2001 John Wiley & Sons, Ltd.

Identity, addressing, authenticity and audit requirements for trust in ERP, analytics and big/open data in a “Cloud” computing environment : a review and proposal

Enterprises, both public and private, have rapidly commenced using the benefits of enterprise resource planning (ERP) combined with business analytics and “open data sets” which are often outside the control of the enterprise to gain further efficiencies, build new service operations and increase business activity. In many cases, these business activities are based around relevant software systems hosted in a “cloud computing” environment. “Garbage in, garbage out”, or “GIGO”, is a term long used to describe problems in unqualified dependency on information systems, dating from the 1960s. However, a more pertinent variation arose sometime later, namely “garbage in, gospel out” signifying that with large scale information systems, such as ERP and usage of open datasets in a cloud environment, the ability to verify the authenticity of those data sets used may be almost impossible, resulting in dependence upon questionable results. Illicit data set “impersonation” becomes a reality. At the same time the ability to audit such results may be an important requirement, particularly in the public sector. This paper discusses the need for enhancement of identity, reliability, authenticity and audit services, including naming and addressing services, in this emerging environment and analyses some current technologies that are offered and which may be appropriate. However, severe limitations to addressing these requirements have been identified and the paper proposes further research work in the area.

Trust in merged ERP and open data schemes in the “Cloud”

Enterprise resource planning (ERP) systems are rapidly being combined with “big data” analytics processes and publicly available “open data sets”, which are usually outside the arena of the enterprise, to expand activity through better service to current clients as well as identifying new opportunities. Moreover, these activities are now largely based around relevant software systems hosted in a “cloud computing” environment. However, the over 50- year old phrase related to mistrust in computer systems, namely “garbage in, garbage out” or “GIGO”, is used to describe problems of unqualified and unquestioning dependency on information systems. However, a more relevant GIGO interpretation arose sometime later, namely “garbage in, gospel out” signifying that with large scale information systems based around ERP and open datasets as well as “big data” analytics, particularly in a cloud environment, the ability to verify the authenticity and integrity of the data sets used may be almost impossible. In turn, this may easily result in decision making based upon questionable results which are unverifiable. Illicit “impersonation” of and modifications to legitimate data sets may become a reality while at the same time the ability to audit any derived results of analysis may be an important requirement, particularly in the public sector. The pressing need for enhancement of identity, reliability, authenticity and audit services, including naming and addressing services, in this emerging environment is discussed in this paper. Some current and appropriate technologies currently being offered are also examined. However, severe limitations in addressing the problems identified are found and the paper proposes further necessary research work for the area. (Note: This paper is based on an earlier unpublished paper/presentation “Identity, Addressing, Authenticity and Audit Requirements for Trust in ERP, Analytics and Big/Open Data in a ‘Cloud’ Computing Environment: A Review and Proposal” presented to the Department of Accounting and IT, College of Management, National Chung Chen University, 20 November 2013.)

ERP stakeholders’ perceptions of data quality and utility

While data quality has been identified as a critical factor associated with enterprise resource planning (ERP) failure, the relationship between ERP stakeholders, the information they require and its relationship to ERP outcomes continues to be poorly understood. Applying stakeholder theory to the problem of ERP performance, we put forward a framework articulating the fundamental differences in the way users differentiate between ERP data quality and utility. We argue that the failure of ERPs to produce significant organisational outcomes can be attributed to conflict between stakeholder groups over whether the data contained within an ERP is of adequate ‘quality’. The framework provides guidance as how to manage data flows between stakeholders, offering insight into each of their specific data requirements. The framework provides support for the idea that stakeholder affiliation dictates the assumptions and core values held by individuals, driving their data needs and their perceptions of data quality and utility.

Individual innovative use of ERP systems

Although many studies have discussed Enterprise Resource Planning (ERP) use at the organizational level, no study according to our knowledge, has identified the factors influencing innovative use of ERP by the end users (Sudzina, 2010). This research-in-progress paper describes the preliminary findings of a survey, which is designed to recognize the factors which can influence the end user innovative use of ERP systems. Moreover, this study argues that the innovative use on individual levels could impact the productivity of organizations.

Contradictions and the Appropriation of ERP Packages

Enterprise Resource Planning (ERP) software typically takes the form of a package that is licensed for use to those in a client organisation and is sold as being able to automate a wide range of processes within organisations. ERP packages have become an important feature of information and communications technology (ICT) infrastructures in organizations. However, a number of highly publicised failures have been associated with the ERP packages too. For example: Hershey, Aero Group and Snap-On have blamed the implementation of ERP packages for negative impacts upon earnings (Scott and Vessey 2000); Cadbury Schweppes implemented plans to fulfil 250 orders where normally they would fulfil 1000 due to the increased complexity and the need to re-train staff post implementation (August 1999) and FoxMeyer drug company’s implementation of an ERP package has been argued to have lead to bankruptcy proceedings resulting in litigation against SAP, the software vendor in question (Bicknell 1998). Some have even rejected a single vendor approach outright (Light et. al. 2001). ERP packages appear to work for some and not for others, they contain contradictions. Indeed, if we start from the position that technologies do not provide their own explanation, then we have to consider the direction of a technological trajectory and why it moves in one way rather than another (Bijker and Law 1994). In other words, ERP appropriation cannot be predetermined as a success, despite the persuasive attempts of vendors via their websites and other marketing channels. Moreover, just because ERP exists, we cannot presume that all will appropriate it in the same fashion, if at all. There is more to the diffusion of innovations than stages of adoption and a simple demarcation between adoption and rejection. The processes that are enacted in appropriation need to be conceptualised as a site of struggle, political and imbued with power (Hislop et. al. 2000; Howcroft and Light, 2006). ERP appropriation and rejection can therefore be seen as a paradoxical phenomenon. In this paper we examine these contradictions as a way to shed light on the presence and role of inconsistencies in ERP appropriation and rejection. We argue that much of the reasoning associated with ERP adoption is pro-innovation biased and that deterministic models of the diffusion of innovations such as Rogers (2003), do not adequately take account of contradictions in the process. Our argument is that a better theoretical understanding of these contradictions is necessary to underpin research and practice in this area. In the next section, we introduce our view of appropriation. Following this is an outline of the idea of contradiction, and the strategies employed to ‘cope’ with this. Then, we introduce a number of reasons for ERP adoption and identify their inherent contradictions using these perspectives. From this discussion, we draw a framework, which illustrates how the interpretive flexibility of reasons to adopt ERP packages leads to contradictions which fuel the enactment of appropriation and rejection.

ERP and best of breed : a comparative analysis

Enterprise Resource Planning (ERP) software is the dominant strategic platform for supporting enterprise-wide business processes. However, it has been criticised for being inflexible and not meeting specific organisation and industry requirements. An alternative, Best of Breed (BoB), integrates components of standard package and/or custom software. The objective is to develop enterprise systems that are more closely aligned with the business processes of an organisation. A case study of a BoB implementation facilitates a comparative analysis of the issues associated with this strategy and the single vendor ERP alternative. The paper illustrates the differences in complexity of implementation, levels of functionality, business process alignment potential and associated maintenance.

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

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.

An ERP-client benefit-oriented maintenance taxonomy

The worldwide installed base of enterprise resource planning (ERP) systems has increased rapidly over the past 10 years now comprising tens of thousands of installations in large- and medium-sized organizations and millions of licensed users. Similar to traditional information systems (IS), ERP systems must be maintained and upgraded. It is therefore not surprising that ERP maintenance activities have become the largest budget provision in the IS departments of many ERP-using organizations. Yet, there has been limited study of ERP maintenance activities. Are they simply instances of traditional software maintenance activities to which traditional software maintenance research findings can be generalized? Or are they fundamentally different, such that new research, specific to ERP maintenance, is required to help alleviate the ERP maintenance burden? This paper reports a case study of a large organization that implemented ERP (an SAP system) more than three years ago. From the case study and data collected, we observe the following distinctions of ERP maintenance: (1) the ERP-using organization, in addition to addressing internally originated change-requests, also implements maintenance introduced by the vendor; (2) requests for user-support concerning the ERP system behavior, function and training constitute a main part of ERP maintenance activity; and (3) similar to the in-house software environment, enhancement is the major maintenance activity in the ERP environment, encompassing almost 64% of the total change-request effort. In light of these and other findings, we ultimately: (1) propose a clear and precise definition of ERP maintenance; (2) conclude that ERP maintenance cannot be sufficiently described by existing software maintenance taxonomies; and (3) propose a benefits-oriented taxonomy, that better represents ERP maintenance activities. Three salient dimensions (for characterizing requests) incorporated in the proposed ERP maintenance taxonomy are: (1) who is the maintenance source? (2) why is it important to service the request? and (3) what––whether there is any impact of implementing the request on the installed module(s)?