1 Motivation

Enterprise information systems (EIS) have been important enablers of crossfunctional processes within businesses since the 1990s. Often referred to as enterprise resource planning (ERP) systems, they were extended in line with electronic businesses to integrate with suppliers as well as customers. Today, EIS architectures comprise not only ERP, supply chain, and customer relationship management systems, but also business intelligence and analytics. Recently, the move towards decentralized technologies has created new perspectives for EIS. Information systems (IS) research has already addressed opportunities and challenges of these developments quite well, but what will be the pressing opportunities and challenges for supporting enterprises with IS in the coming years? The remainder of this discussion focuses on the future of EIS from diverse but complementary perspectives.

We open the discussion by debating how decentralization dynamics impact EIS and how such dynamics must be controlled but also harnessed to make future EIS more efficient and useful. These insights are complemented with a discussion of EIS research challenges from a design science research (DSR) perspective. The next two sections place a stronger focus on implications for practice. The first essay portrays how technological evolution will benefit and challenge EIS. The following essay discusses the value of composable business processes to improve the flexibility of EIS. The penultimate essay offers an outlook on how future EIS can allow for enough heterogeneity to facilitate business logic diversification while retaining sufficient homogeneity to enable interoperability. The final essay wraps up the discussion with a call for more research articles on EIS implementation and usage in IS journals.

2 Enduring Enterprise Information Systems Decentralization

Ali Sunyaev and Tobias Dehling

2.1 Introduction

EIS decentralization (EISD) does not attract much interest from enterprises due to its lack of clear performance advantages and potential risks involved. However, EISD should be of interest to enterprises because it can impact all businesses whether they want it or not. The blockchain space represents a nice example where exaggerated, misguided, and exploited expectations of decentralization benefits have led to millions of dollars lost and gained (Kutera 2022).

EISD appears to be able to serve as a new beginning for some companies just as well as a harbinger of the end of others. A prominent risk of EISD is loss of control, which can have detrimental consequences. The company Napster, with its eponymous peer-to-peer file-sharing service, learned this, for example, the hard way, when it was forced to shut down its service in July 2001 due to its inability to sufficiently curb copyright infringements (Carlsson and Gustavsson 2001). Entrepreneurs in the Chinese cryptocurrency industry were also negatively affected by the ban of cryptocurrency transactions in China, which was enacted to prevent a potential loss of control over the Chinese financial system (Lyons 2021). On the flipside, a salient advantage of EISD is quicker IS adaptation to dynamic demands of their environment due to parallelism (Siggelkow and Levinthal 2003). Traditional encyclopedias realized such benefits of EISD too late and were driven out of the market by Wikipedia, which gave its community of users, instead of a group of experts, control over the content. While this appears to be a risk for content quality, the openness of Wikipedia promotes diverse contributions and, in combination with effective conflict resolution processes, results in sufficient content quality in practice (Arazy et al. 2011). This way, Wikipedia performs well in practice by evolving with the norms of its users instead of goals stipulated and opinions held by a centralized governing body of experts.

From an economic perspective, EISD appears to be akin to a make-or-buy decision, where companies decide based on a cost–benefit analysis whether it is more cost-efficient to buy a product or to produce it themselves (Walker and Weber 1984). When implementing IS components, companies can, for instance, decide whether to leverage open-source or proprietary software. Open-source software is often even made available for free by supporting communities, but it can be influenced by an increasing diversity of needs the broader the communities become (Crowston and Howison 2005). Proprietary software, on the other hand, gives companies more control over software development and use, but requires them to expend the associated resources to make-or-buy the software on their own. Thinking about EISD in a binary cost-driven fashion is, however, somewhat shortsighted.

EISD requires more nuanced assessments than binary decisions on whether to decentralize or centralize an IS. Beyond trivial findings, such as that decentralized IS are more costly to implement and maintain due to increased complexity and lessened economies of scale, cost-based analyses are hard to be conducted in an unambiguous and comprehensive manner due to many intangible costs and revenues (e.g., emergent changes to corporate culture, employee motivation, or privacy concerns) involved in EISD (Alstyne et al. 1995; Bakos et al. 2021). The idea we encourage here is that it may be a fruitful complementary perspective to see EISD in essence as a question of alignment between externally present (e.g., socially desirable) and internally stipulated IS objectives. More centralized IS rely on the expertise of a centralized governing body to get the IS objectives right; more decentralized IS can adapt more dynamically due to increased local decision making, parallelism, and feedback loops relying on community input.

To prepare for the future of EIS, a long-term perspective on EISD appears to be warranted. Instead of merely worrying about the costs and risks of EISD, corporate decision makers may rather benefit from critically embracing EISD as an opportunity by reflecting more on how to best maintain the alignment between externally desirable and internally stipulated IS objectives. In cases where quick adaptation to user needs is not required (e.g., an accounting software where staff can be trained for quite static business processes and purposes) or not desirable (e.g., in behavioral targeted advertising where the goal is to shape consumer needs), more centralized IS are opportune. In such cases, corporate decision making is unlikely to be significantly improved or may even be negatively affected by allowing for more open external input. However, accepting short-term risks of suboptimal performance fluctuations and engaging with the more complex and higher coordination efforts which EISD entails may be worthwhile in dynamic environments because better organizational configurations can be found in the long run (Siggelkow and Levinthal 2003). Put simply, making IS more decentralized fosters a better fit with user needs at the cost of greater complexity; making IS more centralized reduces complexity in order to achieve a fit with corporate objectives. Hence, a key challenge to getting EISD right may be to figure out when and how long the higher cost for maintenance of more decentralized IS is justified to achieve a more perennial alignment between externally-desired and internally-stipulated IS objectives.

The key takeaway for readers of this essay and, hopefully, future thinking about EISD in research and practice, is that it seems helpful to consider EISD to be a process, or rather a tendency, inevitably occurring in an IS, instead of an IS property. Whether an EIS is more or less decentralized at a certain point in time is often not an informative question without paying attention to the purposes of the IS. It should usually be more informative to ask whether IS will remain decentralized enough to maintain alignment between the IS objectives and the evolving needs of the environment. In the remainder of this essay, we outline three interesting considerations (rejuvenating properties, systemic impacts, and impulsive dynamics of EISD) that deserve more attention in practice and future research if we are to harness the value creation opportunities offered by EISD, while avoiding its imaginary and actual pitfalls in future EIS.

2.2 Consideration I: Rejuvenating Properties of Enterprise Information Systems Decentralization

Without targeted interventions, IS will become more centralized over time. This is due to the fact that every change to an IS represents an optimization effort towards a selection of objectives which is done, necessarily, at the expense of chosing alternative objectives to optimize for, which there are an infinitive number of. Apart from ignoring the input and needs of IS stakeholders not involved in decision making, an even more serious issue caused by the tendency of IS to centralize over time is that erroneous decisions will inevitably be made as long as the future remains unpredictable.

An example for an IS optimized for an inappropriate selection of objectives is Microsoft’s Tay chatbot (Neff and Nagy 2016). Tay was optimized to learn from and perform on Twitter feeds. A goal overlooked was that IS should also remain aligned with societal norms (Spiekermann et al. 2022). This was a detrimental oversight for the Tay chatbot because this then lacked mechanisms to discriminate between benign and malign user feedback to learn from. As a consequence, Tay was prematurely terminated, after only less than a day of operation, due to racist and misogynistic responses it had learned (Neff and Nagy 2016). A couple of years later, ChatGPT (another chatbot learning from information on the internet) appears to fare better; however, in light of first national ban initiatives and calls for a global moratorium on training unpredictable black-box models (Clarke 2023), the verdict is still out whether ChatGPT can be aligned sufficiently well with societal expectations.

The Microsoft Tay chatbot represents an extreme example where an IS was quickly and irremediably compromised due to the reputation loss entailed when IS clash too strongly with societal expectations (Royakkers et al. 2018). In most IS, problematic consequences of erroneous decisions will slowly accumulate over time. Nevertheless, errors will inevitably be made in the long run, and eventually a tipping point will be reached where increasing centralization has detached an IS to an intolerable degree from the needs of its environment – that is, either the IS or the needs of the environment have to change to avoid failure of the IS. Companies with surveillance-capitalist business models have, for example, been criticized for deviating so far from value propositions made to consumers that they end up rather overriding than serving consumer needs (Dehling and Sunyaev 2023; Zuboff 2019). To prevent such aberrant outcomes, it may be useful to think of EISD as a rejuvenating effort supporting IS in evolving with the changing demands of their environment instead of allowing for a continuously widening gap between internal IS objectives and external demands on the IS. In other words, interesting questions for future EISD may not lie along the lines whether to decentralize or to centralize an IS but when to decentralize an IS or how to automatically trigger decentralization efforts when IS start to stray too far from the paths envisioned by the hard-to-ascertain entirety of their stakeholders.

2.3 Consideration II: Systemic Impacts of Enterprise Information Systems Decentralization

In the previous section, we argued for the value of seeing EISD as a rejuvenating effort allowing IS to better evolve with the changing demands of their environment. It would, however, be ill-advised to interpret this to mean that EISD is always a positive development. Apart from the increased costs due to the increased coordination complexity EISD entails, EISD can also go too far and break constitutive system-subsystem interrelationships in an IS – simply put, EISD can break IS.

As Chatterjee et al. (2020) suggest, IS are purposive systems that foster multi- and equifinality and are open to inputs from the environment to reciprocate with, which are not IS properties at risk through EISD. Such properties are all goals which EISD supports, because more decentralized IS are more open to user input which implies an increase in multi- and equifinality properties of an IS. However, Chatterjee et al. (2020) also suggest that IS consist of interrelated and permeable subsystems that adapt to each other. Here, EISD will go too far if constitutive subsystem relationships are not only diversified but actually broken through EISD, which may prevent an IS from fulfilling its purpose, hence, from being useful and having a reason to exist.

The DAO incident in 2016 (Morrison et al. 2020) created, for example, environmental turbulence for EIS building on the Ethereum blockchain because the Ethereum community split their user base with a hard fork due to irreconcilable differences in envisioned purposes of the IS. This was a risky maneuver due to its potential to reduce the security properties of the IS through an unintentionally large reduction of the node operators’ diversity. Diversity of node operators is a key requirement that must be met to maintain the security properties of a blockchain-based IS like Ethereum (Kannengießer et al. 2020). However, in the DAO incident, the centralized ledger reset was, apart from remaining ethical disagreements, largely successful, which made the fork persistent. Nevertheless, as also evidenced by the public reaction to the propriety violations by Tay or the copyright infringements questioning the social desirability of Napster, it is ill-advised to see EISD as beneficial in its own right. For the future of EIS, it would be interesting to investigate in more depth how EISD impacts different IS subsystems and to see how EISD efforts impact IS in unforeseen ways in practice. Improvements in the detection and prediction of unfavorable outcomes of EISD and of corresponding light-weight coordination mechanisms would be useful to harness the promises of EISD, while being better equipped to circumvent adverse consequences.

2.4 Consideration III: Impulsive Dynamics of Enterprise Information Systems Decentralization

Finally, decentralization processes have been illustrated as a pendulum that swings back and forth between states of more decentralization and more centralization (Evaristo et al. 2005). It may be insightful to slightly adapt the analogy and envision EISD as possessing impulsive rather than oscillatory dynamics. Considering that increases in centralization are inevitable in order to benefit from lessened complexity and associated efficiency gains, and that they are only rational across the lifetime of an IS, it may be misleading to assume that an IS will gradually decentralize at some point. There could also be an impulsive dynamic at play, where decentralization pushes emerge suddenly for various and hard-to-foresee reasons once IS become too centralized, that is, too detached from the needs of their environment. More research is required to be able to predict whether an IS is, or when it will be, too centralized in relevant EISD dimensions with respect to its environment (E. Rossi and Sørensen 2022).

What the impulse analogy adds to the pendulum analogy and may be worthwhile considering for EISD in future EIS, is that there may be situations where the pendulum swings back so fast that it is hard to notice, representing a sudden decentralization push instead of a gradual development. So far, we have luckily not seen sudden decentralization pushes with noticeable impacts in practice. For example, the free and open source software (FOSS) movement is only gradually increasing its influence, one motivation behind cryptocurrencies may have actually been to replace fiat currencies but this did not suddenly happen, and there are also efforts to replace centralized social networking services but initiatives are only gradually increasing their influence. Nevertheless, it may be advantageous for corporate decision makers to prepare for situations where they have to be able to proactively counter, or rather deal with, decentralization pushes – even sudden ones. The success of Wikipedia, which drove traditional encyclopedias out of the market, may serve as a cautionary tale.

2.5 Outlook

For the future of EIS, and EISD in particular, it would definitely be helpful to work from a more thorough and holistic understanding of EISD instead of having to rely on largely disconnected insights and EISD efforts. Three considerations that seem to be interesting for furthering and obtaining a more holistic understanding of EISD, and IS decentralization in general, appear to be the rejuvenating properties, systemic impacts, and potentially impulsive dynamics of EISD (Table 1).

Table 1 Future research opportunities on enterprise information systems (EIS) decentralization

We hope this brief essay motivates future research on less trodden – albeit potentially insightful – aspects of EISD. EISD is a multi-facetted and complex phenomenon, where change initiatives can easily misfire due to the poorly understood complexity entailed (Sunyaev et al. 2021). For future EIS, it may be helpful if we had fewer recurring discussions about the top of the decentralization iceberg whenever decentralization pushes become too apparent and instead started to more holistically investigate EISD beyond the surface (Fig. 1). Management of EISD could be significantly improved and prove even more useful, once it becomes possible to ascertain whether EIS are, and will keep being, decentralized as well as centralized to an appropriate degree in relevant dimensions. The future of EIS will show which enterprises can redeem first mover advantages due to EISD, which enterprises can adapt early enough, which enterprises will be lucky enough to remain largely unaffected by adverse effects of EISD, and which enterprises will be driven out of their market – just like many former competitors of Wikipedia.

Fig. 1
figure 1

The enterprise information systems decentralization iceberg needs to be explored in more detail beyond the surface

3 Enterprise Information Systems from a Design Science Research Perspective – Opportunities Long Gone, Will They Ever Come Back?

Susanne Strahringer

3.1 Introduction

Many researchers and scholars would probably agree that EIS research seems to have lost much of its former appeal. Trends such as the consumerization of information and communication technologies, EIS' status as state-of-the-art technology, and organizational concepts such as bimodal or two-speed information technology (IT) have pushed these systems into the backyard of business and IS engineering (BISE) research, where they may be seen as boring, old-fashioned, dusty, and, most of all, no longer promising attractive research opportunities compared to all the trendy and important topics we need to address as we move towards a digital society.

Behavioral researchers, especially those conducting research at the individual level, may encounter attractive research opportunities related to these systems as part of a workplace environment where they still induce interesting user behaviors or work habits, not despite their dusty image but rather because of it (e.g., Malaurent and Karanasios 2020; Sykes 2020; Sykes and Venkatesh 2017; Vos and Boonstra 2022). Also, these systems' broad user base with respect to user numbers and user diversity makes them a relevant and fruitful research object for researchers investigating human–computer interaction (Nissen et al. 2023). Considering that this research could and should inspire design science researchers and encourage them to continue their work on EIS, it seems that this fruitful "food chain" from behavioral to DSR and ideally back again does not or no longer work in this field. Almost two decades ago, there were calls for more behavioral EIS-related research (Arnold 2006; Sutton 2006), and today it seems that calls for more DSR would be more appropriate and that opportunities for design science researchers seem to be long gone. Is that the case? I will try to answer this question from my perspective as a researcher who has conducted EIS-related DSR, and – I must admit – with changing enthusiasm for it. In my discussion of the topic, I will use three perspectives on EIS: the vendor perspective (that is, viewing the system as a product built by a vendor), the client perspective (that is, viewing the system as one that is implemented and used in a client organization), and the perspective in between.

3.2 The Vendor Perspective

Although the vendor perspective may be the least important one from a non-DSR perspective, it is probably the one that design science researchers are thinking of when they work on concepts that they want to see materialized in real-world EIS. In the 80s and early 90s, when I was studying BISE at a German university with a not-yet world-leading but already promising vendor around the corner, there were BISE researchers, but also researchers in fields like management accounting who had strong personal ties to that vendor and who successfully developed concepts and prototypical functionality that found their way into those systems. This is long gone and over because of the functional maturation of these systems, their complexity, and the research resources needed in a BISE lab to come up with something that these vendors could or would be impressed with. With the growth of these vendors came the era of their professionalization by building up innovation processes and structures as well as research and development departments. This reopened perspectives on a larger scale by either driving externally funded (European level) research projects in which vendors participated or by building collaborative environments where vendors' research units worked in close cooperation with university departments. But according to my observation, this did not create only research opportunities for the BISE community; I would even go so far as to say that this created predominantly research opportunities for computer science departments. With BISE research being more on the client side and at the end of the development chain of new products, larger vendors became more interested in more fundamental technologies and integration of these into software products that were saturated in domain functionality. In addition, the technology-related research that computer scientists were doing in their university labs independently of these vendors had the potential to be attractive to them. BISE DSR, on the other hand, was then only possible in very close collaboration with the vendor, where the researchers were (almost) part of the vendor team since access to their resources and development environments was a prerequisite. I would not argue that such a collaboration was or is not fruitful (e.g., Lück and Leyh 2017; Walter et al. 2017), but it comes with all the problems and drawbacks of research done with dependency on a vendor with commercial interests. From a research perspective, the opportunities, such as access to a large user and client base, and disadvantages that emerge with results being tied to a specific product as well as a stronger need for design theorizing to become valuable for a larger research community must be balanced.

The design science researcher's painful last mile problem (Nunamaker et al. 2015) may be solved in such settings as the vendor takes care of it. Theoretically, this promises evaluations in naturalistic settings (Venable et al. 2016), even on larger scales. However, the cycles needed for a tiny bit of BISE research to show up in some kind of related functionality in a real-world system and productive use will exceed the time of a regular research project, so that BISE design science researchers can hardly exploit these opportunities.

Overall, opportunities such as those mentioned above may still exist, but they will certainly not entice the next wave of EIS-related BISE DSR. Is there still a viable path?

Yes, and this path is better than ever. A plethora of smaller vendors exists, as admittedly was also the case decades ago. But, ten to twenty years ago, only a few were at the technological forefront with strong research interest and potential. These were mainly smaller ERP vendors building FOSS who knew how to combine the FOSS innovation potential with competitive business models (e.g., Wölfel 2015; Wölfel and Smets 2012). But today, even new vendors are successfully entering the market with software-as-a-service (SaaS) systems built from scratch, in many cases without the burden of legacy code, and at the forefront of SMACIT (social, mobile, analytics, internet of things (IoT), cloud) technologies that are waiting to embrace even newer technologies in ever shorter product cycles. Again, the question arises whether this creates better opportunities for BISE or for computer science. I would argue for both. The difference for the BISE community today compared to opportunities with larger vendors in the past are the cloud-driven, very short release cycles, technological access to the entire customer base, and systems where technological innovation directly impacts how work is done, and processes are run in client organizations with almost no time lag. BISE research, which is more on the client side of the product rather than on the technology infrastructure side, is what is needed from the perspective of these vendors to incorporate technological innovation that may drive their customer base. Design science researchers may find environments here where the last research mile is closed in a way that the naturalistic evaluation setting comes for almost free. The problem of producing artifacts bound to a commercial product remains, and in this case, this is – unfortunately – not the product of a market-leading vendor but of a niche vendor, which may result in dismissing the respective research as being "in the niche" as well. Skipping this problem is not the answer, but instead this problem could be regarded as an opportunity. The need for better abstraction, stronger design theorizing, and better integration of design and behavioral research in DSR that creates instantiations is undoubtedly part of the answer. Thus, research opportunities and methodological developments concur. Embracing this ideal situation today and in the years to come is an opportunity for design science researchers in the BISE community that should not be missed.

3.3 The Client Perspective

EIS-related DSR opportunities on the client side have not changed fundamentally over the decades but have clearly lost attractiveness when applying a narrower scope, that is, when looking at how to implement such a system in organizational environments (see for an overview on research in the implementation phase Eden et al. 2014). The lack of attractiveness is not due to the progress BISE research has created in practice through research on implementation success factors, customization, and implementation strategies, along with useful DSR artifacts for the implementation process. It is instead the opposite, we still see projects failing, and we as a community have not been able to contribute much to this problem. Therefore, I refrain from jumping on the bandwagon again only because of all the cloud transformations ahead of us. Even if a focus on small and medium-sized enterprises (SMEs) and businesses in developing countries may still call for this type of research from the BISE community, I do not believe that we will be able to come up with solutions that make a real difference (apart from a few exceptions, e.g., van Beijsterveld and van Groenendaal 2016). SMEs are rewarding research contexts also in other BISE fields (e.g., Drechsler et al. 2022; Kratzer et al. 2022; Li et al. 2018; Mandviwalla and Flanagan 2021), and there may be more fruitful ways in which our community can contribute to the developing world (e.g., Ameen et al. 2023).

But considering the EIS as the backbone of an organization's digital infrastructure is what makes it still a relevant research object in a variety of BISE topics, with or without DSR opportunities. Here I want to focus on those that may be interesting to design science researchers on the more technical side who typically create instantiations. What BISE seems to be no longer able to do on the vendor side (see prior section), that is, integrate new functionality and affording technologies into the larger vendors' products, can today be done on the customer side. Some larger customer organizations today are at the forefront of exploring new technologies, even if their adoption and exploitative use are still years away. EIS now have modern architectures and thus lend themselves better to being and staying the backbone of such endeavors. In this vein, manufacturers may explore the use of blockchain technology in order to refrain from centrally organized marketplaces or intermediaries (e.g., Linke and Strahringer 2018), they may want to improve user guidance over system and technology boundaries (e.g., Babaian et al. 2018; Morana et al. 2013), they may explore higher degrees of artificial intelligence (AI)–based automation in process steps and may compare it with traditional execution, they may explore better integration of EIS functionality with quickly evolving workplace technology, etc. Doing this on the client side comes with the direct potential of either traditional DSR with excellent evaluation opportunities or ideal environments for conducting long-term action design research projects (Sein et al. 2011). A trend that will push these client-side DSR opportunities even further is the advent of low-code development platforms as an integral part of EIS offerings, following Saleforce's example as a pioneer in this field. Client-side low-code ERP app design on top of the EIS as the digital backbone will create research opportunities for an even broader research community.

3.4 The Perspective In-Between

The very simplistic, probably oversimplifying perspectives I took before need adjustments to the dimensions in which complex software products are built today. This happens in larger ecosystems of vendors working with complementary vendors of different sizes (Foerderer et al. 2019; Schreieck et al. 2021), where customers are not only user organizations but also players driving their vendors' innovation (Pollock and Hyysalo 2014). Technical platforms and platform business models play major roles. Thus, what I have discussed as different perspectives may not be as separate as assumed. The anchor points for BISE researchers in the EIS realm have become broader and more diverse than ever. At first sight, this organizational complexity may look like a stumbling block. Still, I would argue for the opposite: more entry points and lower entry barriers are an advantage if BISE design science researchers want to become part of such a universe. It remains to be seen how and whether they will make use of it or leave it to others.

4 Enterprise Information Systems and Technological Evolution

Li Da Xu

4.1 Introduction

ERP systems have become the prevalent type of EIS (Xu 2011). With the help of computer networks and databases, ERP integrates the data generated by various departments of the enterprise and comprehensively applies IT, management technology, manufacturing technology, et cetera to integrate the information flow and material flow related to the four elements of people, technology, equipment, and operation management in the process of enterprise production and operation in an orderly manner. ERP/EIS is an interdisciplinary subject aiming at realizing the overall optimization of enterprises, which can solve a series of problems faced by enterprises in competition. It has also emerged as a promising tool for integrating and extending business processes across business functions’ boundaries at both intra-organizational and inter-organizational levels. In recent years, there have been significant developments in ERP/EIS and actual applications to various industrial sectors. We introduce a number of new technologies which will have significant impacts on the future development of ERP.

4.2 Industry 4.0

Industry 4.0 is revolutionizing the way companies manufacture, improve, and distribute their products as manufacturers are integrating new technologies, including IoT, cloud computing, AI, and machine learning into their production facilities and throughout their operations. Research shows that Industry 4.0 has sparked a discussion on whether ERP will still remain the dominant software system in the Industry 4.0 era, although studies have not yet given a clear-cut answer to this question. However, it is agreed that ERP will have to address new challenges from Industry 4.0 (Xu et al. 2018). There are indications that IoT, cyber-physical systems (CPS), cloud computing, and other related technologies can greatly impact future ERP. It has been predicted that a new generation of ERP would emerge from new information and communication technologies with the capacity of IoT, CPS, cloud computing, and other technologies.

4.3 Internet of Things

IoT is expected to offer promising solutions to transform the operation of many existing industrial systems, including ERP. IoT can be considered a global network infrastructure composed of numerous connected devices that rely on sensory, communication, networking, and information processing technologies. One of foundational technologies for IoT is radio-frequency identification (RFID) technology, which allows microchips to transmit identification information to a reader through wireless communication. By using RFID readers, it is possible to identify, track, and monitor any objects attached to RFID tags automatically. Another fundamental technology for IoT are wireless sensor networks (WSN), which mainly use interconnected intelligent sensors to sense and monitor. The advances in both RFID and WSN significantly contribute to the development of IoT.

IoT is a key enabling technology in the Industry 4.0 and has been revolutionizing the existing industrial systems. IoT can enable the creation of virtual networks to support the smart factory in Industry 4.0 (Xu et al. 2018). What are the benefits of integrating ERP with IoT? One of the main advantages is better decision-making due to improved data quality and availability. Other advantages include real-time analytics, better operational efficiency, and improved forecasting.

Currently, more and more IoT devices are being connected to the internet. This means the amount of data available to companies is growing rapidly. This quality and quantity of the data collected by the internet and IoT devices is essential for successful digital enterprise transformation. Integrating ERP with IoT can improve data quality and availability, ensuring that any changes in data are directly reflected in the ERP system in real-time (Xu et al. 2018).

Integrating ERP with IoT data helps organizations to gain vital business insights instantaneously. The continuous stream of data from IoT sensors and devices allows businesses and industries to perform real-time analysis, helping them gain insights which improve decision-making.

4.4 Cyber-Physical Systems

CPS presents a higher level of mutual integration and coordination of physical and computational elements (Xu 2020). In CPS, physical and software components are deeply intertwined, each operating on different spatial and temporal scales and interacting with each other. With the introduction of CPS, machines can communicate with each other, and decentralized control systems will be able to optimize production. The integration of CPS is essential in ERP functioning. The integration of CPS systems also leads to complexities emerging from the interactions between cyber systems and the dynamic behavior of physical systems. The integration of CPS is a challenge.

CPS are increasingly interconnected with metasystems. Their behavior depends on interactions with other system components. Numerous interactions of different characteristics may be involved, such as interactions within a system or a subsystem, between systems and/or subsystems, and between a system and its environment. Such interrelated subsystems are capable of dynamic change. Interactions can occur between interactions as well, and some interactions only emerge when the system as a whole is considered.

If ERP is to be employed successfully, these interactions must be understood. Currently, these complex interactions are not being thoroughly investigated. One of the challenges we face is to understand such complex interactions. New methods must be developed to study such complexities.

4.5 Cloud Computing

Cloud computing is the on-demand availability of computer system resources, especially data storage and computation power. Cloud computing relies on sharing resources with high performance and at low cost. A large volume of data can be uploaded to a cloud computing center for storage and computation.

An enterprise’s operation involves numerous decision-making activities, which require a large amount of information and intensive computation. Cloud computing provides an effective solution to such tasks. All data can be stored in private or public cloud servers, and in this way complex decision-making tasks can be supported by cloud computing. ERP systems can be cloud-based. Cloud-based applications have increased in recent years.

4.6 Industrial Information Integration

As ERP systems become more interconnected, efficient real-time integration of data/information must be ensured to support a higher level of automation. Therefore, industrial information integration demand has increased.

Lessons have been learned in the past. Due to the lack of industrial information integration technology, problems such as the incompatibilities in information exchange and coordination have caused production delays in Airbus 380 and Boeing 787 production and assembly lines (Rachuri et al. 2008). The key issue of these incidents was “the apparent lack of fundamental progress in areas of information integration” (Regli 2007, p. 24), partially caused by the existing ERP software.

Industrial information integration engineering (IIIE) is a new discipline (Xu 2014; Xu et al. 2016). IIIE is a set of foundation concepts and techniques that facilitate the industrial information integration process. IIIE comprises methods and techniques for information integration in industries.

Industrial information integration has attracted much attention in the industries. In 2016, an intensive literature review on industrial information integration was conducted by examining literature from 2006 to 2015 that was included in the Web of Science. All in all, 497 papers related to industrial information integration were reviewed (Chen 2016). Industrial information integration has been applied to a variety of industrial sectors or areas, including aerospace, agriculture, food, automated factory, biology, chemical engineering, construction, disaster, ecosystem, energy, enterprise integration, environment, general engineering, geology, healthcare, information and communication technologies, industrial control, instrumentation and measurement, large industrial projects, life science, machinery, management, manufacturing, marine transportation, math modeling, mechanical industry, medical pharmaceutical, microbiology, mining, navigation, security, supply chain, telecommunications, as well as transportation. This provides evidence that industrial information integration techniques have been widely applied in industries.

In recent years, many new technologies have appeared such as industrial IoT, smart grids, and smart manufacturing. With these new technologies, relevant industrial information integration techniques have emerged. A literature survey has been conducted regarding industrial information integration-related literature published from 2016 to 2019 that was included in IEEE Xplore and Web of Science (Chen 2020). Altogether 970 related papers grouped into 27 application categories were reviewed.

Recent advances in industrial information integration offer powerful approaches for effective and efficient information integration, a basic requirement for the success of industry. The current ERP systems may be limited by the sophistication of the relevant technologies or by the lack of industrial information integration techniques, and this is a crucial problem because the successful execution of industrial processes relies upon more sophisticated industrial information integration than what is currently available in existing ERP.

4.7 Summary

ERP is referred to as a category of industry software, typically a suite of integrated applications that an organization or numerous organizations can use to collect, store, manage, and interpret data from many industrial operation activities. ERP is the integrated management of industrial processes, often in real-time and mediated by software and technology. There are many challenges and issues that need to be resolved for ERP to become more applicable. Designing ERP involves complexity which mainly stems from their high dimensionality and complexity. Despite advancements in the field of ERP, significant challenges remain. They need to be dealt with to fully realize the potential of ERP.

5 Composable Business Processes for Flexible Enterprises

Martin Heinig and Michael Perscheid

5.1 Introduction

ERP systems have become an integral part of modern-day businesses, but they also come with many challenges. On the one hand, ERP systems provide standardized and value-adding digital business processes that are implemented globally, enabling companies to streamline their operations efficiently (Asprion et al. 2018). But on the other hand, this also makes ERP systems complex, and we need to differentiate between two types of complexity. First, there is an essential complexity of the business domain that cannot be reduced because it is always part of the problem we want to solve. However, we also see a lot of accidental complexity and technical debt that has grown over decades of building and customizing ERP systems. Especially this kind of complexity hinders flexibility in the sense that it can be hard to change or modify the system to meet new requirements or address specific issues that arise frequently (Hvolby and Trienekens 2010). In the last years, we have seen many such circumstances from timely establishing new business models due to a pandemic to leaving markets over night because of political situations. On the customer’s side, we see that this accidental complexity and the corresponding missing flexibility lead to challenges such as limited process adaptability, tedious upgrade projects, and complex adjustments (Bender et al. 2021; Elmonem et al. 2016; Gozukara et al. 2022). But even in stable periods complex process changes and migration projects can be time-consuming and resource-intensive (Bender et al. 2021; Yusuf et al. 1999), and they generally occur several times in a company's life cycle, repeatedly exposing the company to risk due to disruptions to the entire operations and IT infrastructure.

To address these challenges, research and industry must work closely together to understand and probably question whether today's all-in-one, highly integrated, and customized software architecture of ERP systems is still suitable to support the necessary flexibility of enterprises. Based on numerous interviews (Böhme et al. 2023) with a wide variety of companies, our most important finding is that customers do not “want” ERP systems, but instead digital, flexible, and integrated business processes. In this essay, we outline the importance of composability in running businesses (Gartner 2020) and how this thinking will change the way we will build ERP systems in the future.

We propose a new approach to building business software that focuses on composable architecture and business processes as first-class entities. While rethinking ERP systems with modular and independent components can reduce the accidental complexity and ideally make business capabilities interchangeable, the idea behind explicit business processes is that they outgrow their mere existence as documentation and become directly executable. Thus, the difference between target and actual processes in business, which causes huge adjustment problems, is eliminated and the flexibility is satisfied by the direct editability of processes. Finally, both concepts in connection with a semantic data layer and the latest cloud technology will make it possible to create a scalable, integrable, and adaptable platform that is far better suited for changing requirements of markets and companies.

The following discussion presents a joint view of research, innovation, and practice, showing how these three perspectives can work together to highlight guiding research questions and to develop the next generation of enterprise software.

5.2 Challenges of ERP Systems that Hinder Flexibility

To better understand why ERP systems are often not considered flexible enough and to derive requirements for a future generation of business software, we recently conducted several interviews with companies from start-ups via grown-ups to enterprises (Böhme et al. 2023) and validated our findings with other customers. As a result, we identified three main challenges of current ERP systems (see Fig. 2): First, business processes are implicit and offer insufficient transparency, allowing only a small group to understand the underlying business logic. Second, ERP systems have a high entry barrier due to their overload of business capabilities and costly implementations. Especially for smaller companies, ERP systems offer vast quantities of components that some perceive as irrelevant to their current needs or hinder the company's development due to their non-transparent and interdependent procedures. Finally, ERP systems pose many integration challenges since business processes often span multiple IT systems and even cross company boundaries.

Fig. 2
figure 2

Observed challenges of ERP systems (taken from Böhme et al. 2023)

5.2.1 Insufficient Transparency in Business Processes

We learned that ERP transactions' control and data flow is only implicitly represented by the successively generated documents required in business processes, for example, sales orders, delivery notes, and invoices. This sequence of documents is described as the document flow. However, none of our interviewees mentioned that implemented control and data flows of processes are graphically represented in ERP systems. Instead, the underlying business process is hidden in the respective implementation, limiting the comprehensibility of the ERP business processes, especially for non-technical users. Furthermore, we observed that textual documentation of business processes often becomes outdated since they are only created during initial implementation or migration projects. When processes change, usually the documentation is not adapted due to high manual effort. This can be mitigated later on with the use of process mining tools.

5.2.2 High Entry Barrier

We identified three main reasons contributing to a high entry barrier for implementing ERP systems: limited modularity, the lack of tailored processes, and costly implementation projects.

Limited modularity Each software component of an ERP system introduces further internal dependencies. State-of-the-art ERP systems offer software components that represent sets of functions for different lines of business, such as asset management or finance. The software components have dependencies, resulting in an increased configuration effort if new features are added. In addition, the components often include excessive functionality exceeding the requirements of the company's current state, and a high degree of redundant functionality hinders the company from focusing on its value-adding business.


Lack of tailored processes Another reason for the high entry barrier of ERP systems is the adoption of standard processes and their customization (Quiescenti et al. 2006). Most ERP systems impose a concrete process the company must comply with. Even if standard processes imply advantages such as cost minimization and improved process coordination, they provide only a limited opportunity to achieve competitive differentiation (Seddon 2005). While this is sufficient for supporting processes, for example, in human resources or finance, key processes that serve the company's unique goal usually need to be highly individual.


Costly implementation projects Introducing an ERP system has a reputation for being expensive and time-consuming. Most ERP systems implementations require a large upfront project to identify required processes, configurations and data that must be migrated (Khanna and Arneja 2012). While this phase allows the company to streamline its existing processes, it is costly since the required competence often comes from external consultancy (Dunaway 2012) and poses the risk of disrupting daily business (Ahmad and Cuenca 2013). The fear of disruption of the business and the costly upfront project were the top two reasons mentioned in the interviews that delayed the implementation or migration to a new ERP system.

5.2.3 Lack of Interoperability

As not every ERP vendor can offer all required functionality for a company as well as to prevent vendor lock-ins, larger enterprises follow a best-of-breed IT strategy by implementing function-specific SaaS systems from selected strategic partners. However, an increasingly heterogeneous IT landscape consisting of systems in multiple cloud environments from multiple vendors often comes with integration challenges and redundant data storage. We observed that current business systems often do not support efficient interoperability with external applications, resulting in considerable effort required for data migration and integration of processes. In addition, today's end-to-end processes span entire value chains and go beyond company boundaries, making integration possibilities with external systems increasingly important. The fact that current ERP systems only focus on one enterprise instead of supporting the complete value chain of the business increases this problem. The development of interfaces between these ERP systems is often associated with considerable communication overhead.

We are aware of the fact that there are even more challenges, but from our experience we see the three presented challenges as the most pressing ones since they hinder business flexibility. As companies are constantly evolving due to various factors, such as market changes, technological advancements, and organizational growth, flexibility is required to ensure that the software can adapt to changing business needs in a short time and continue to provide value.

5.3 The Future of Business Processes Is Composable

We envision a business platform that defines itself through a number of chosen, created, and customized business processes that satisfy the specific needs of a particular company.

To solve these challenges of ERP systems, we are currently working on several prototypes (Böhme et al. 2023; Heinig 2022) in order to rethink the architecture of business software and to evaluate this new kind of flexibility with our customers. All our prototypes have four major concepts in common: Composability, business processes as first-class entities, a semantic data layer, and a cloud-native technology platform. In the following, we will discuss where we stand and what the open questions are which remain to be solved.


Composability The term “composability” describes the ability of a system to allow selection, assembly, and rearrangement of components to fit specific and changing user requirements (Gartner 2020). Applied to enterprises, it describes an organization’s processes that are made from interchangeable building blocks and corresponding IT systems. A composable setup enables a business to reassemble features dynamically and rearrange them as needed depending on external or internal factors. Just think of adding a carbon tracker to a supply chain process or integrating a new infection protection act in response to a pandemic, to name two very recent examples. Today, this would require a long-term integration project, whereas a composable setup might enable a process expert to adapt and change processes easily and quickly – ideally in a low-code/no-code environment.

Still, there are open questions, such as: what does a reusable business component look like; how to carve out functionality from existing ERP systems; or which functionality is part of a stable, minimal core and which not?


Business processes as first-class entities Our vision is clear–creating a composable platform that enables customers and partners to not only model or document their processes but also to create end-to-end processes from building blocks and execute them directly. In the long run, enterprises can only achieve flexibility by creating environments that enable them to build and consume business processes in a composable fashion and orchestrate them across system boundaries. We envision a process-driven platform that offers a diverse range of solutions under one roof which are developed by all kinds of businesses. As a reconfigurable system of interoperable business capabilities, it shall enable end-to-end process integration. It should operate all processes within and across enterprises seamlessly. Core benefits for customers would be new levels of efficiency, more time for value-creating work, compliance by default, and finally agility and resilience in a rapidly changing business world.

Both research and practice need to clarify the right granularity for executable business processes and which questions to address, including what functionality cannot be covered (e.g., analytics), what does a scalable architecture to execute and monitor business processes look like, and how will user experience change if processes are in the focus of business software?


Semantic Data Layer Since end-to-end processes go beyond the borders of single components and even companies (Bender et al. 2021), it must also be possible to execute cross-system processes. As different business components will use different domain models, we argue that an extra semantically enriched data and process layer will be necessary to address the interoperability challenge of current ERP systems. Following the example of the semantic web, we envision data schemas used in business processes to be enriched with standardized descriptions that enable true semantic integration of different systems' data across businesses. A first step in this direction is SAPs One Domain Model (SAP 2023a) in combination with our work on knowledge graphs (Glenk 2023).

We are aware that this will be a huge challenge, but we argue that the benefit will be worth it. Questions include how to define and align a complete semantic ontology for the business domain with different vendors, how to include a seamless extension mechanism for customized data, or how to adapt current business software to it.


Cloud-native technology To combine the three aforementioned concepts, a cloud-native platform is the natural fit. Cloud-native infrastructure offers everything to fulfill the needs for business components and processes as a service but also comes with scalability, high availability, elasticity, and fault tolerance. Furthermore, it addresses the challenges of a high entry barrier for companies and the lack of interoperability by leveraging similar technological concepts. Finally, an additional online marketplace and ecosystem would enable customers and partners to participate in the value chain of providing and consuming modular process components on a joint platform.

Open questions arise, including what a platform needs to provide, who the stakeholders are, and what the business model of such a platform looks like, as well as how to integrate existing (on-premise) business solutions. At SAP, we answer these questions with our SAP Business Technology Platform and regard it as suitable foundation for building our vision of a composable enterprise platform (SAP 2023b).

5.4 Conclusion

The history of enterprise systems has resulted in an accumulation of different architectural decisions. However, some of these decisions no longer align with today's highly decoupled software service landscape and the need for flexible processes. Especially the last years have shown us how important agility is. By moving in the discussed direction of composability, we think there is a large potential to solve these and future customer challenges and to rethink ERP systems even if there are many open questions and a long way to go.

6 The Challenge of Heterogeneity in Enterprise Systems

Rainer Alt

6.1 Introduction

As elaborated above, EIS are IS that digitally support an organization's business functions and are at the heart of most businesses today. In fact, EIS have become a competitive necessity and yield convincing improvements, in particular if their design has gone hand in hand with business redesign. Since EIS embody an organization's business logic, they typically comprise a large degree of customizing. On the one hand, standard out-of-the-box (reference) configurations are diluted during customization and lead to the situation that one implementation of a Microsoft, Oracle or SAP EIS is usually incompatible with another implementation of the same vendor. On the other hand, most organizations face the reality that even a broadly integrated EIS will require connections to other EIS. Interoperability has thus been named a key challenge for the future of EIS (also see the discussion above on ERP flexibility).

Significant potential especially awaits leverage when multiple organizations interact. For example, it has been estimated that paperless trade facilitation could increase exports by $6 trillion and reduce costs by 76% across the G7 countries by 2026 (UK International Chamber of Commerce 2021). The digitalization of electronic bill of lading documents (eBL) alone is expected to annually save $6.5 billion in direct costs and enable an additional volume of $30–40 billion due to reduced trade friction (Casanova et al. 2022). This is remarkable since the potential is far from new: initiatives for electronic data interchange (EDI) as well as interorganizational systems date back to the 1970s (Alt and Zimmermann 2014) and authors like Venkatraman (1994) have emphasized that business network redesign promises larger benefits than internal integration. In the same vein, Champy (2002) pointed out more than twenty years ago that “billions and billions could be saved if companies collaborated and shared the processes that are now essentially redundant” (p. 26). What are the reasons behind this obviously limited progress and why might we see this changing? This essay argues that managing heterogeneity is key to leveraging the potential and that, in addition to standardization endeavors, novel IT developments should be applied for coordination purposes.

6.2 Managing Heterogeneity Within Organizations

First of all, the EIS vision is closely linked to a centralized system within an organization that enables accessing multiple business functions via a single user interface based on a single database and cross-functional processes (see Davenport 1998). It thus aims at a high degree of homogenization across the entire organization although the various organizational units often differ depending on their local markets (e.g., US and European country organizations), on the supported products (e.g., sales and after-sales products), on functional specificities (e.g., marketing and production), or simply on path dependencies (e.g., legacy designs). This organizational heterogeneity is reflected in the heterogeneity of EIS, which emanates from differing designs at various levels, in particular a technical (e.g., hardware platforms, operating systems, database management systems, programming languages) and a conceptual (e.g., models of data and the same real-world concepts for products, processes, data and the like) level (Hasselbring 2000).

The typical approach pursued in many integrated EIS (or ERP) projects to contain this heterogeneity is standardization. Key elements, such as data, processes and roles, are standardized organization-wide and then implemented during the customization of a commercial off-the-shelf EIS solution. Especially the conceptual level has proven to be challenging since it involves the standardization of design elements that directly affect the business (e.g., standardized numbering for products and organizational units, standardized functions and cross-functional processes). Many reports of EIS introduction projects (e.g., Scheer and Habermann 2000) have confirmed that shaping and agreeing on these intraorganizational standards is more demanding than the technical implementation itself. At the same time, an integrated EIS is rarely the sole solution to containing heterogeneity.

A second approach acknowledges the existence of multiple heterogeneous EIS and aims at the interoperability among these systems (or components). Integration technologies such as messaging services, integration platforms, workflow management systems, and robotic process automation solutions have emerged for this purpose. They may be conceived as interfacing layers that facilitate coordination between multiple heterogeneous EIS and contribute to the agility of an organization’s EIS architecture. This increased flexibility has become an important development in the EIS field (see also the discussion above). It recognizes that organizations are open and living systems (Vargo et al. 2017), which constantly have to adapt to market, customer or government requirements. If EIS are rather seen as configurations of multiple components instead of a single integrated EIS, these individual EIS could belong to the organization or to external partners.

6.3 Managing Heterogeneity Among Organizations

Traditionally, an EIS was governed by a specific organization where, by virtue of their hierarchical power, executives decide on standards and organization-wide conventions. As soon as heterogeneity needs to be addressed on a value chain (or network) level, comparable structures are typically missing and the lack of such a network-wide governance body has been referred to as the "organizational gap" (Kubicek 1992). Since the early research on the organizational gap, it has been emphasized that with the ISO/OSI- and the TCP/IP-standards, technological interoperability was seldom the problem. Similar to the intraorganizational domain, achieving interoperability on the more business-oriented conceptual level was recognized as more challenging. Research on EDI has pointed out that transferring business documents from an analog to a digital format is only one element within the digitalization among organizations. The goal, however, should be "the automation of coordination among companies, not cheaper communication” (Brousseau 1994, p. 330). For this to happen, it was emphasized that a shared syntax needs to be complemented with a common understanding on semantics and the context (pragmatics) of the interaction.

In view of the organizational gap, attaining homogeneity on such comprehensive issues has been an endeavor since the 1980s. Despite standardization bodies and intermediaries (e.g., clearing centers and integration hubs) emerged for EDI, linkages of EIS required tedious negotiations of interchange agreements since most standards remained on a syntactical level. With the rise of e-business systems in the early 2000s, more standards as well as functional modules for customer and supplier interaction were developed. It is reflected in the notions of extended ERP (Romero and Vernadat 2016), collaborative enterprise (Unhelkar and Arntzen 2020) and electronic business systems. Today, a variety of standards exist that contribute to reducing the heterogeneity in the interorganizational setting. Within the large field of EIS interoperability (see Romero and Vernadat 2016, p. 9f) and e-business standardization (see Rebstock et al. 2008, p. 31ff), three main approaches are:


Data standards Many EIS comprise converters for EDI message standards (e.g., EDIFACT, EANCOM or SWIFT) and use semantic data standards in their functional modules (e.g., GTIN, GLN, IBAN, eClass). Due to their long history, especially message standards are available today in many industries with subsets covering industry-specific peculiarities. Since the mappings are defined and maintained manually, these standards are usually focused on large-volume, routine transactions.


Functional Modules More recently, EIS evolved towards platforms where functional modules (or components) could be linked via defined interfaces. These approaches are known to cope with heterogeneity through the combination of standardized modules (Baldwin and Woodard 2008). Consortia frameworks may be found in the banking (BIAN), insurance (BiPRO), or the health sector (FHIR). While these solutions are promising regarding their potential reusability, they are focused on specific industries and require significant consensus among the participants regarding the overall architecture.


Process Designs Reducing the heterogeneity of cross-organizational business processes is the domain of business process standardization (Goel et al. 2023). Such standardized collaborative processes define the business logic and comprise use cases and/or swimlane diagrams (e.g., BRSs from UN/CEFACT, PIPs from RosettaNet), which are implemented in the participating EIS. As with RosettaNet’s PIPs, each organization maintains their internal process definitions and manually maps these private (heterogeneous) processes to (homogeneous) public process definitions.

6.4 Coordination Technologies to Manage Heterogeneity

The good story from the availability of existing standards is that standardization has already produced solutions for certain interoperability aspects and industries. They contribute to formalization and reduce the possible solution space. On the downside, existing standards appear piecemeal and involve substantial effort for configuration and maintenance. While more standardization will be valuable for mastering heterogeneity among organizations, the need for compatible standards and homogeneity regarding data, functions and processes presents a profound conflict with the heterogeneous reality in a dynamic and competitive business world. In view of the heterogeneity of standards from various standardization bodies, the coordination among standards seems an additional approach. Defined as "managing dependencies among activities" (Malone and Crowston 1994, p. 90), coordination pertains to how information from one EIS is used in another EIS. Although interorganizational coordination will always involve human decision makers, today’s technological potentials could enhance traditional coordination mechanisms, such as interchange languages and standards. Three enablers of future coordination technologies in EIS shall be mentioned:

First, a wealth of semantic technologies has been proposed in computer science that could be applied to achieve semantic compatibility among heterogeneous EIS. On the one hand, novel data federation approaches like data fabric and data mesh (Hechler et al. 2023) could be used to derive common meaning of heterogeneous data as well as of functional modules (ie, services) and replace many manual activities involved in matching data messages and functional interfaces. For example, ontologies have been created for certain application domains (e.g., the OSLO standard for the public sector) and have also been used to enable automatic negotiations prior to the exchange of EDI messages (e.g., Lehmann 1996). On the other hand, data and process mining techniques have been applied to extract business information and to identify events and process instances for deriving interorganizational process designs (e.g., Engel et al. 2011). Both directions have also been proposed for describing, discovering, and negotiating semantic web services (e.g., Klusch 2008) and for integrating data from decentralized (or federated) databases (e.g., Jhingran et al. 2002).

Second, AI technologies that have a long tradition to support planning purposes in EIS (e.g., in demand and production planning) have been suggested for coordination purposes. This comprises communication, artifact, and task management (Sarma and van der Hoek 2010) as well as system integration (Panetto et al. 2016). On the one hand, coordination among heterogeneous messages links to the mapping of heterogeneous messages as mentioned above. Algorithms could help in recognizing patterns in transaction messages and in proposing mappings for metadata, which are then confirmed or modified in the converters or integration layers of EIS. If ontologies and process structures are used as input data to train AI models, ontologies could be continuously improved and create further benefits in automating the exchange of structured business messages. On the other hand, compliance management systems could include learning skills to check whether data or process structures originating from heterogeneous EIS comply with defined standards and where modifications are necessary.

Third, distributed ledger technologies (DLT) have a long history as distributed databases and have spread with the rise of blockchain technology since the late 2000s. They trustfully store and process transactions among multiple nodes, which may be hosted by different organizations. Since the data structure in these ledgers and the functionality embedded in the ledger software are identical for the participating nodes, these systems create interorganizational homogeneity within the same ledger. However, the systems are focused on specific enterprise functions (e.g., supply chain tracking, payments, purchases), which would require either more functions to be included in one distributed ledger or the integration among distributed ledgers. This need for integration has been recognized with solutions for cross-ledger integration (CLI) and for linking with off-chain EIS. They are still at an early stage. Coordination logic in the ledger software (e.g., smart contracts, dApps) could be applied to map transaction records to intraorganizational data structures as well as for verifying compliance to interorganizational standards (e.g., Fatz et al. 2019).

Since the three coordination technologies are not mutually exclusive, it will be interesting to see, how they converge and further automate coordination. Some perspectives exist already: EIS are expected to integrate with distributed ledgers (see EISD above) for entire value chains as shared industry ledgers (Swan 2018) where multiple consortium companies are using the same private blockchain (O’Leary 2017), which may reach from customers to raw suppliers (Kim and Yao 2023). For example, FHIR health EIS modules could connect to health records held on blockchain infrastructures. As to be observed in the initially mentioned eBL case, multiple blockchains may emerge per domain. Here, eight out of today’s ten eBL solutions are based on blockchain technology (Ledger Insights 2023). While these could be aligned via a common eBL data standard, aiming for interoperability among the individual systems could be more straight-forward. Together with existing CLI approaches, smart blockchains (Cao 2022) seek the convergence with AI. This intelligence in blockchain transactions could render them more active for coordination purposes. It is already the case in Web3 solutions like the Boson Protocol for dispute resolution in mutual agreements. If the ledger nodes are further conceived as agents as known from distributed AI (Jennings 1996), more diverse coordination scenarios could be supported that not only focus on running operational business processes, but also on changing business processes and relationships. They could take over functionalities of intermediaries, who are typically conducting coordination functions.

6.5 Conclusion

In summary, an important aspect of future EIS will be their ability to master heterogeneity. This results from the living nature of organizations and their embeddedness in larger interorganizational settings. However, the need for (re-)integration and (re-)adjustment is opposed to the desire to have stable and homogeneous structures to digitalize processes within and especially between businesses. In this regard, traditional approaches that stipulate the harmonization and standardization of existing structures (e.g., industry consortia, meta-standards like ISO/IEC 33071) should be complemented with coordination approaches that enable more automation. This direction accepts heterogeneity as a fact of business reality and mediates between heterogeneous structures via digitalization. If current converging technologies such as AI, DLT, and data standards are increasingly conceived as coordination technologies, it may be expected that many manual activities in establishing and conducting business relationships become fully or at least partially automated to not only “promise the integration of all the information flowing through a company” (Davenport 1998, p. 121), but also through the entire network of EIS from customer to suppliers. Ultimately, meeting the challenges of heterogeneity will lead to new EIS architectures and enable interorganizational information infrastructures that bear the potential for substantial business transformation as envisaged some thirty years ago.

7 Enterprise Information System Implementation Impact on People and Organizations


Matti Rossi

EIS have been seen as a means for global and local companies to integrate and standardize their core business processes and information resources (Davenport 1998; Strong and Volkoff 2010). It is claimed that EIS provide huge benefits, such as lower costs, better customer service, improved resource management and performance control, as well as better connections between supply chain partners and better visibility across production and complex supply chains.

The main argument of this essay is that we have a plethora of studies about critical success factors (CSF) of EIS implementations (Shaul and Tauber 2013) and a lot of literature reviews of the said factors and of benefits of ERP, but it is hard to publish practical studies of ERP implementation and usage in IS journals. I posit that there is more of a need to still learn from the success and failure of these systems’ implementation and use, than there is a need for theoretical accounts of EIS. The understanding of how these systems are implemented and function in practice helps the implementors and users of the systems and thus provides benefits for the society at large.

If the implementation of EIS is successful it can lead to large efficiency gains, but the reported rates of failure remain high (Wong et al. 2005). This can have a considerable impact on organizations and the people who work with these systems. Despite the high failure rates, organizations are implementing the systems and spending enormous amounts of time and money on them, as modern organizations rely on the accurate and timely data that is collected and organized through EIS. The increased automation of corporate operations, reliance on AI and real-time decision making will make integrated EIS and their data resources vital for the functioning of the organizations.

Against this backdrop it is surprising that there have been similarly high failure or rather rejection rates for research papers that seek to understand the EIS implementations and impact on organizations. The often-cited reason for the rejection by reviewers is that they do not contain much new theoretical development on EIS studies. I believe that there is still value in case descriptions of large-scale implementations and that we should study the successes and failures so that we can make life easier for those who must implement the systems and use them.

Studies on the use of EIS highlight the challenges of accommodating EIS to organizational routines and work practices. EIS implementation has been plagued by challenges of dealing with the mismatch between strategic intents and the EIS use at the local level. There are good reasons for cementing and globally standardizing routines, but at the same time it can have negative effects on performance of the operations and production if the standards hamper daily routines (Mattila et al. 2015). We posited in (M. Rossi et al. 2020) that the tension between the global and local needs should not be seen as something that should be dealt with by means of stricter control and removal of workarounds, but rather as a source of innovation that can lead to better work practices and user satisfaction with the systems.

What are the reasons for the frequent cases where the system fails to live up to its promises? In our previous research frequent changes of key users or the building and retaining of a competent ERP project team was seen as a key challenge for the implementation projects. Due to long implementation times, the implementor’s business environment would change (e.g., switching operating model or outsourcing operations) which added challenges to ERP development (Alanne et al. 2014; Momoh et al. 2010). ERP implementation became challenging as new people joined or old ones left the project. According to a study in Finland of a very large industrial implementation (Nandhakumar et al. 2005), an astonishing amount of trust regarding business processes was placed on the shoulders of the vendor and outside consultants. If the user organization wants to outsource the implementation details to the consulting partners and expects the system to work without too much consideration of the practices and local needs, this is a recipe for disaster (Berente et al. 2016; M. Rossi et al. 2020).

So, what could the IS research community do to help the organizations and users? This is in many ways a problem for which we can provide workable solutions that have a strong research grounding. In EIS implementation research you can find a considerable number of best practices (Holland and Light 1999; Shaul and Tauber 2013) that can be used as guidance for what to do. We should not see it as a weakness that this is largely already known, but as a strength. If we as IS researchers participate in an EIS implementation project from an early phase, we can draw from the CSFs and from previous case studies and actively help the practitioners to avoid the most common pitfalls. Furthermore, as there is a good deal of research about EIS implementation projects and what the resources and extra planning should be targeted at, we can help people in the organizations to avoid burnout and “death march” type of projects (Schneider 2000). We often lament that we are several steps behind the practice, especially with new technologies, but here we have an area of practice which is vital for the functioning of enterprises and public sector organizations and where we know what should be done. We should use this knowledge and work with practitioners from a position of strength.

I understand that this does not sound very advanced or like a path to a lot of top publications, but what we might lose on peer recognition we should be able to gain in practitioner praise. There are however some issues which could be interesting for both practitioners and researchers in EIS implementation and use. Here are some possible future topics that could be studied:


EIS data quality. EIS provide the data for decision making and artificial intelligence solutions in organizations and if the data cannot be trusted, or is not reliable, the decisions and AI tools will simply not work as intended.


EIS and stream data and non-structured data. Current EIS work best with traditional rows and columns of discrete data items that change according to well established transaction protocols and adhere to strict metadata definitions. Enterprises are dealing with increasing amounts of data streams from devices and non-structured data, and this needs different types of processes and data management.


EIS data as a source of AI training material and AI powered analytics of EIS data Enterprise systems provide vital data for AI systems training and use. How do the user organizations deal with this? Will they share the data with AI vendors, or will they use internal AI systems to maintain competitive advantage? What are the best practices of using the EIS data for AI powered analytics?

These are topics with which we can gain funding and publications, but I still call for further research on how to make the EIS implementation projects and day-to-day EIS use as pain free as possible. If we can help users to avoid some of the obvious pitfalls of the projects and make the systems easier to use and maintain, we have contributed to the society’s, companies’, and users’ wellbeing.