Feral Information Systems Creation as Sensemaking

Abstract

This paper discussed the role of actors in creating their own sensemaking devices as Feral Information Systems. In particular, we explore how Feral Information Systems (FIS) are actually a creative way to workaround complex information systems and need to be acknowledged as such. We use the sensemaking framework to explore how new FIS are developed as a sensemaking device in order assist in daily important tasks. We conclude with suggestions for future research.

1. Introduction

Organisational sensemaking is primarily about the creation of plausible narratives for understanding ambiguous situations ([1,2,3,4], A central tenant of sensemaking are the scripts [5] people use as part of their practices to justify the roles, expectations and decisions they make under ambiguous organizational situations. [6], demonstrates how often these decisions are made as part of a narrative that underpins the ‘story’ of a particular situation. This perspective is drawn from the narrative-as-sensemaking perspective that has emerged over the past decade [1,7,8]). A central assumption is that leaders use narratives to guide actions, decision making and problem solving [9] This is built on the idea that narratives give structure to problems and in turn guide heuristics for decision making under uncertainty [10,11]. That is, narratives provide the guidelines for taking action [8].

A central focus however, has been on the idea of institutional legitimacy through narrative construction by managers as ‘sensegivers’ [12,13,14]. This process entails managers constructing narratives that are part of the functional need to legitimize decisions carefully [13,15] noted two key enablers of sensegiving for leaders: process facilitation and issues related to organizational performance. These authors argue that sensegiving is enabled in highly complex environments in which critical issues arise or are anticipated. People often fall back onto ‘experts’ who can help structure or shape a narrative to close that gap so that appropriate action can be taken. The process of interaction between stakeholders and leaders in this environment is argued to create pattern for effective sensegiving. That is, in through the interactive processes involved in sensemaking [16] experts gain legitimacy. This legitimacy is used as a sensemaking narrative [17] that guides decision-making in complex environments.

1.1. Sensemaking and Enterprise Resource Planning (ERP) Implementations

In modern organizations, perhaps one of the most complex environments revolves around ICT implementations and this environment is where critical issues are most likely to occur. Perhaps the most controversial ICT implementations would be that of an Enterprise Resource Planning system (ERP). These systems have become well-known for process facilitation and have become a major driver of attempts to have a universal (best practice) process approach across all organizations. The exponential growth in the way these systems are managed, automated and made as a central part of most large organisations places them squarely in the frame as a critical ‘process’ facilitator. Around these critical systems, we argue, are narratives about what makes them key process facilitators and what makes them difficult to navigate for key workers. To date, research in ERP systems have largely been focused on the technical issues of ERP, as opposed to the social problems inherent with such a large and complex corporate investment [18]. For this reason we are directing our sensemaking approach to the implementations of ERP systems. In particular we are interested in why people create ‘alternative’ narratives as a response to ERP system implementations and seek to understand why people workaround the system.

A key piece of research into ERP workarounds is research conducted on Feral Information Systems (henceforth FIS). This research argues that in moments of high stress and ambiguity [19,20] users will often create workarounds to help management this system ambiguity. These systems evolve in organisations and are mainly created to help people cope with the state of affairs many find themselves in [21] after an ERP is implemented. FIS have been defined as “a computerised information system that is developed by individuals or groups of employees to help them with their work; it is not condoned by management nor is it part of the corporation’s accepted information technology infrastructure. Its development is designed to augment, or in some cases, circumvent existing organizational information systems.” [22]. This definition encompasses a socio-technical view of the systems created combining the problem solving aspects (discussed in [23], workflow processes and the need for technical proficiency [19].

Research into FIS [22] suggests that the lack of understanding of the functions of an ERP system can lead to employees to want to develop their own software application using development tools that they are comfortable and familiar with. These are typically tools such as Microsoft Excel. We are suggesting in this paper that it is a lack of sensemaking with respect to the true intent of the ERP implementation and a lack of understanding of the underlying assumptions and functions of the ERP system, could be a major problem and a reason that people develop FIS workarounds. That is, ERP systems could cause disruptions to work expectations thereby leading workers to create ways of working around systems. These workarounds are seen as necessary because they ease the stress [24] that is generated by poorly implemented ERP systems.

Spierings, Kerr, & Houghton, [25] argued that the desire to create an FIS comes from the skills and abilities with respect to the use and development of ICT products that a person has developed over their lifetime (referred to as life chances). They further argued that the FIS was a response to modes of domination instilled on employees through the installation of poorly implemented ERP systems that seek to normalise business processes. This research (see also [22]) indicates that FIS builders can block ERPs to the point where they can develop their own systems. What is not yet known is: what are the narratives they used to legitimise this behaviour? What scripts are used to develop these workarounds? Therefore these two questions form the basis of this research enquiry.

The rationale for exploring these questions is twofold. Firstly, the cost of FIS are on the rise and according to a recent article from CIO magazine [26] (they continue to be a rising cost. Secondly, if insights can be gained into the interpretive schemata used by FIS creators, the reasons why FIS were created and legitimised can be further explored. This would lead to a greater understanding of the context of FIS development. It would also lead to better insights into the development and use of FIS and how it affects the organization. Thereby reducing the need for post implementation training, reengineering and other related costs and factors [22].

The aim of this study is to further explore how sensemaking may influence the creation and maintenance of Feral Information Systems. Our objectives are therefore:

• To understand how FIS are influenced by sensemaking patterns.
• To develop a basis for future research implications.

The following section outlines the theoretical framework used to explore this problem in greater detail. Following this we provide two short case studies to demonstrate the nature of this problem.

2. Background—What is Sensemaking?

According to Weick [26] “The concept of sensemaking is well named because, literally, it means the making of sense or the creation of ‘sense’. Active agents construct sensible events meaning that we create our reality through the perceptions we have of it. Secondly, we generate those perceptions from the experiences we have had, our present understanding of events and the previous cognitive maps we have forged over time. It literally means that humans create explanations of things based on their existing mental maps of things or those that are readily available.

Underpinning sensemaking is an extension of the cognitive dissonance theory (discussed in Weick [4] which argues that in light of confusing or ambiguous events, actors are likely to create explanations of phenomena rather than live without a clear explanation of events. This means that the patterns we notice in our thinking come from our estimation of previous events. When we are presented with “cognitive dissonance”, the gap between what we expect and what happens, we fill that gap with a cognitive schema based on a causal map we have previously derived. To make sense is literally to create a casual frame to help us understand the events we have presently experienced.

In this way sensemaking seeks to explain how actors form logical explanations of events that do not have an existing explanation or where current explanations do not provide enough ‘sense’. Weick uses the term sensemaking to define how we comprehend situations that fail to make sense and how we use that process of comprehension to create actions in light of confusing information [27]. Sensemaking is retrospective [3] this means people are finding an interpretation that is an adequate representation of the situation at hand in order to offer meaning to on-going events. It is the single nature of humans to have to have an explanation of what’s happening in their daily lives. What happens when things do go the way we have come to expect?

2.1. Sensemaking Theoretical Framework

Sensemaking research grew out of a concern that social psychology was not explaining how actors enact meaning in the daily course of events. Weick’s [4] book on organising and enactment introduced the concept as a means of explaining the unusual way in which people develop ideas as concepts to help them understand “disruptive ambiguity”. Disruptive ambiguities are the patterns that emerge in daily events that cause us to have our cognitive and interpretative schema (the cognitive structures we use to assess and find meaning in daily life) re-evaluated. Human beings are meaning makers, according to Weick [4] because they simply cannot live without explanations of the daily things they experience. Ambiguity presents equivocality in our interpretations, which leads to needing to explain things that are ambivalent by nature. If we can explain them, we make sense by retrofitting our interpretations onto the events of our day-to-day lives. This retrospection is argued by Weick to be the way in which we come to grips with the disruptions to our routines and expected cognitive landscapes. When we don’t understand, or when something disrupts our thinking, we create a map in order to have an explanation rather than not have one.

Weick [7] argues that sensemaking occurs along seven major dimensions:

¹ 

Identity—In the Mann Gulch paper Weick [29] points to the sensemaking by firefighters during a disaster in which the failure to drop their tools formed part of the reason why they perished in the fire. He goes on to point out that identity, who we are and what we do, forms a central part of sensemaking.

² 

Retrospection—Sensemaking takes events that have happened in the past and uses them as a template for future storytelling, actions and sensegiving [30].

³ 

Extraction of Cues—Sensemaking relies on people to extract events and imbue them with meaning. This belief-supporting activity involves people noticing things that fit the template of their mental modelling [31]. They extract cues or meanings in order to match them with the expectations of their beliefs.

⁴ 

Plausibility—Sensemaking relies on the idea that we interpret things that “make sense” or are plausible as opposed to being accurate. Plausibility means that if we lack information, we settle for what is most likely. As Goffman [32] said, we would rather have some explanation than no explanation.

⁵ 

Enacting—Weick [4] describes this part of sensemaking as efferent or ongoing, “The person’s idea is extended outward, implanted, and then rediscovered as knowledge…” and “Action, perception, and sensemaking exist in a circular, tightly coupled relationship…” [4]. In other words, sensemaking is part of an ongoing, outwardly moving process of enactment where actors are continually co-creating the world they helped to create. However, enacting means they actively create that which they make sense of.

⁶ 

Social—Sensemaking is a social process relying on the interactions of people in terms of routines and interactions [29] sensegiving [11] and other social relations. For example, [13] highlight the day-to-day activities of strategic managers as they enact the future. They highlight the small things they do, in a social sense, which form part of the way they enact and make sense of strategy.

^7. 

Ongoing—Mills et al. [33] point out that sensemaking is an ongoing sequential process that flows on and on. That is, we are constantly making sense of what is going on around us and building on that sense to make more of it in the future.

The mental imagery created through sensemaking is argued to be hidden within the reasoning and explanations offered by sensemakers. These personal patterns form into imagery used in the process of daily sensemaking because organisational patterns are constructed over time [4,34,35]. The authors create the patterns to make sense of events that we eventually ‘enact’ (make real) through our actions. The previous enactments that the authors have made lead us to create stable patterns of sensemaking that can be observed in micro- and macro-level organisational cognitive dynamics. In this paper we explore these cognitive dynamics in an ERP implementation.

2.2. ERP Systems and Disruptive Ambiguity

While some authors have covered systems and sensemaking before [36] very few studies have looked at the impact of this sensemaking on either organisational performance or system integration. It is a critical feature of ERPs that they are argued to improve performance, when in fact they may be the source of reduced productivity for many organisations [37]. We argue here that ERP’s can cause ambiguity to workers and that creates problems for the patterning, expression and carrying out of tasks. That is, ERPs are supposed to create a standardised work pattern that reduces variance in tasks so that ‘productivity’ gains can be achieved. Our argument is twofold. Firstly, ERP’s can be a disrupter of productivity by introducing ambiguity into work processes thus increasing the need for actors to work around them. Secondly, the need to ‘workaround’ a process is provoking a kind of ‘sensemaking’ that drives users to create novel ways to approach and adapt to their work.

The first assumption is built on the idea that sensemaking is actors responding to disruptions in work patterns due to a new ICT implementation by filling that gap with something else, rather than simply living with this disruption [34] discusses this in a paper arguing that technical and social processes can never be effectively separated. That is, if we implement an ERP into an environment, Orlikowski argues, we are engaging with its materiality and in turn this creates templates enacting the behaviour built into the physical and logical design of the system (see also [35]). Sensemaking is about people reacting to their own stimuli in a retrospective manner [27] to comprehend present events. When an ERP is implemented perhaps the full affordances of the technology (what it can do for people and what kind of benefit it can bring) are not always immediately obvious [36]. As [35] points out it’s up to actors to explore the technology, find the affordances and use it to reach the maximum benefit in any situation.

This suggests that people can find value within an ERP implementation simply by finding the best way to utilize the in-built functions, and this may have been the case in previous ICT implementations, however in many cases ERP implementations are different. This difference is due to the nature of ERP implementations where the most effective way to implement is to modify organisational business processes to suit the software (called the vanilla implementation where a company tries to save costly modifications to software by making the business fit the software rather than the other way around). It is this approach that can lead to confusion amongst people because not only do they need to learn new software but they also have to learn new business processes. This confusion can also lead for a lack of understanding why the organization needs to change from the current system, in other words there are questions as to the need for new technology and change.

If the need for the technology is not immediately obvious or its “inherent value” has not been readily perceived, actors are likely to understand this kind of technology as a disruption to work [38,39] In some cases, ERPs cut across functional silos revealing organisational structural inefficiencies [22]. They also can duplicate existing process [40] because they are not considered a good ‘fit’ for the organisation. In these cases the system becomes the driver of ambiguity. We argue that this can lead to the creation of novel ways of working around systems and that the driving of ambiguity leads to the following three key points:

¹ 

ERP systems can create an ambiguous work environment and:

² 

This ambiguity leads to a decrease in productivity in some cases leading to:

³ 

An increase in unsanctioned systems that operate outside of management control.

To further explore these assumptions two case studies conducted. Using [31] sensemaking as a guideline, we explored two different contexts to see how these patterns influence the creation of FIS. Secondly, there is a history in sensemaking research of exploring actors’ ambiguity around processes where explanations are created to fill some kind of cognitive dissonance [41]. From this research we derived the concepts of sensemaking to explore ways in which actors were effected (or not) by these disruptions (the ERP implementation). We deliberately sourced case studies where ERPs had been implemented in large organisations. This was so we could explore in depth the responses of actors. In the following section we discuss how we conducted these case studies and we introduce the two case studies.

3. Methodology

The intention of this paper is to explore how FIS could emerge as a ‘sensemaking’ response to ambiguous information systems. To further explore this problem we argue that a case study approach is most suitable [42]. Following [43] we used a multi-case study design, explicitly to explore how people in these situations used sensemaking to create FIS. We also drew upon the ideas of Eisenhardt & Graebner [44] who argue that the process of using multiple cases can lead to theory building opportunities. This is built on the ideal of replication logic which connotes that over multiple opportunities to explore the same phenomenon, you are more likely to find repeatable patterns that afford some kind of generalisation. Each case is seen as a type of experiment in which extension to theory, new ideas and emergent theory can be explored. While traditional quantitative explorations can emphasise the paths between established constructs, a case study can look at the richness of the context in a situation. The process of building theory is argued to occur through ‘recursive’ cycling amongst the case data, emerging theoretical explanations and existing concepts from research. In short, this approach was used to explore our assumptions through two different contexts with the express aim of working towards a theoretical explanation.

This design was chosen because the phenomena under exploration are largely social in orientation and it was felt that a quantitative design was not possible because there have not been any studies on feral information systems that have effectively produced factors to this stage. As this is a relatively underdeveloped area, we chose to approach this research through an inductive frame of mind focusing on possible themes instead of testing statistical factors. We argue that while the quantitative method could be a valid approach if certain elements were known, it’s not possible to develop a model within the current field of research. By using the sensemaking framework we believe that steps can be taken toward a more generalizable model.

Data were analysed by applying the concepts of triangulation to moderate sources and make sure that the data was rigorous and consistent. Further, it should be noted that this is an interpretivist case study [45]. This means that while we are attempting to create a theoretical framework for discussion we are applying the lens that actors socially construct their reality and create meaning from social interactions. In this way we would like to suggest that the theoretical assumptions about generalisation cannot be applied to this case study. Instead, we recognise that any generalisation would be limited and therefore we urge caution.

This design is inductive inasmuch as the authors seek to learn from these cases what the major issues are to do with FIS creation as a sensemaking artefact. Although these contextual investigations make the data subjective, what emerges from this are ideas, concepts and testable notions that can be further deduced in other forms of empirical research. Therefore our aim in exploring two separate sites of FIS as sensemaking devices is to see if this localised phenomena (Case 1) is found within other contexts. The paper takes these findings and provides a discussion for future development. Each interview that was conducted in the case was analysed and moderated for consistency and patterns amongst the researchers. Therefore the analysis involved: triangulation of data sources and moderation of responses to ensure the patterns recognised where consistent. We also hired a research assistant to cross check our reference notes and field interpretations for bias.

In the cases that follow it should be noted that we collected data at the time of implementation. We are focused on issues to do with feral information systems as a response to ERP systems. It can be conjectured that this may be the result of a poor change management process. However, that is not the area of focus in these studies but it’s an interesting point that management scholars should investigate. We are instead choosing to focus on how sensemaking occurs in FIS as a response to disruptions and ambiguity. We are seeking to demonstrate how people, when faced with extreme levels of cognitive dissonance, respond to situations with disruptive ambiguity.

4. Case Studies

In this section we introduce and analyse the case studies. There were two case studies and Table 1 below provides details of the recorded participants in each case study.

Table 1. Interview profile summary table.

Case Study, Participant Number and Title	Management Level	ERP Experience	Specific Role
Case 1—General Manager Supply Division (P1)	Upper level	Limited hands on experience	This person manages the whole of the supply division
Case 1—administrator from accounts payable (P2)	Lower lever	Good level of ERP experience but with an earlier version of the software	This person has just been absorbed in to supply division and is currently in a stage of transition. The section is located in three main geographic areas. This person’s role is to oversee processes.
Case 1 Manager—commodities (P3)	Middle level	Limited level of ERP experience	This person’s job entails overseeing all of the commercial commodities and corporate contracts. Things such as hardware, electrical, consumables, all of the building services contracts, security, waste, things such as print services etc.
Case 1 Manager reclaims (p4)	Middle Level	Some experience in ERP software	This person’s job entailed the reclamation and disposal of material in the organization.
Case 1 Team Leader SAP implementation(P5)	Lower level	Extensive experience in ERP software	This person was the team leader of business solutions. His role is to be the first level of support for SAP for a lot of the procurement officers.
Case 1—Manager of Inventory (P6)	Middle Level	Limited experience in ERP software	This person’s role at the moment is a fairly limited because the organization no longer own inventory as the title suggests whereas five years or 10 years ago the organization owned an enormous amount of inventory. The current role is one of a consultant where people use this person as a source of knowledge for inventory and its process
Case 1—Contractor (P7)	Lower Level	No ERP experience	This person is a contractor and he was bought in to work on a project
Case 1—Change Manager (P8)	Middle Level	Extensive ERP software experience	This person’s job is to assist people in the organization handle change on their work
Case 1—Supply Chain Optimisation Manager (P9)	Middle Level	Little experience in ERP software	This person’s role was helping to wrap up in the inventory project. He also works in the property division. He describes himself as a jack of all trades.
Case 1—Process Design Adviser (P10)	Middle Level	Extensive ERP software experience	This person’s job involves helping people within the business to design and review processes, and manage and further improve them.
Case 1—Commodity Facilitator (P11)	Middle Level	ERP software experience but with the older version of the software	This person is responsible for all the commercial dealings for supply contracts between organizations.
Case 1—Performance and reporting coordinator (P12)	Middle level	Extensive experience in ERP software	This person is involved in the inventory side of reporting and performance at a corporate level.
Case 1—Business Improvement manager (P13)	Middle Level	Extensive experience in ERP software	This person is the middleman between the business and the technical people. He tries to help the business make a change to an existing process or bring in a new one. He talks to the technical people to make sure they can support the business process with the technology
Case 2—Deputy Director (P14)	middle Level	Little computer experience	This person’s job was as a human and materials resource allocator for one school in the training organization
Case 2—Head of Department (P15)	Upper Level	Extensive computer experience but with older technology	Head of Department—Responsible for resources both human and material. Whole of Department budget allocations
Case 2—Head of School (P16)	Middle to Upper level	Very limited experience in computer technology	Head of School—Academic leadership
Case 2—Lecturer (P17)	Lower Level	Very limited experience in computer technology	Lecturer in military training (bomb disposal)
Case 2—Lecturer (P18)	Lower Level	Very limited experience in computer technology	Lecturer in military training (logistics)
Case 2—Professor (P19)	Upper Level	Very extensive computer technology experience	Professor in Military training and former CIO of a large multinational company
Case 2—Research Fellow (P20)	Middle level	Limited computer knowledge	Research director for the school
Case 2—Professor (P21)	Lower Level	Limited Computer knowledge	Seasoned academic responsible for curriculum development and post graduate education
Case 2—Lecturer (P22)	Lower Level	Very limited experience in computer technology Extensive experience in computer technology	Lecturer in military history and culture
Case 2—Lecturer and IT manager (P23)	Lower Lever		One of several managers of IT for the Department, Part time lecturer in IT technology

Table 1. Interview profile summary table.

Case Study, Participant Number and Title	Management Level	ERP Experience	Specific Role
Case 1—General Manager Supply Division (P1)	Upper level	Limited hands on experience	This person manages the whole of the supply division
Case 1—administrator from accounts payable (P2)	Lower lever	Good level of ERP experience but with an earlier version of the software	This person has just been absorbed in to supply division and is currently in a stage of transition. The section is located in three main geographic areas. This person’s role is to oversee processes.
Case 1 Manager—commodities (P3)	Middle level	Limited level of ERP experience	This person’s job entails overseeing all of the commercial commodities and corporate contracts. Things such as hardware, electrical, consumables, all of the building services contracts, security, waste, things such as print services etc.
Case 1 Manager reclaims (p4)	Middle Level	Some experience in ERP software	This person’s job entailed the reclamation and disposal of material in the organization.
Case 1 Team Leader SAP implementation(P5)	Lower level	Extensive experience in ERP software	This person was the team leader of business solutions. His role is to be the first level of support for SAP for a lot of the procurement officers.
Case 1—Manager of Inventory (P6)	Middle Level	Limited experience in ERP software	This person’s role at the moment is a fairly limited because the organization no longer own inventory as the title suggests whereas five years or 10 years ago the organization owned an enormous amount of inventory. The current role is one of a consultant where people use this person as a source of knowledge for inventory and its process
Case 1—Contractor (P7)	Lower Level	No ERP experience	This person is a contractor and he was bought in to work on a project
Case 1—Change Manager (P8)	Middle Level	Extensive ERP software experience	This person’s job is to assist people in the organization handle change on their work
Case 1—Supply Chain Optimisation Manager (P9)	Middle Level	Little experience in ERP software	This person’s role was helping to wrap up in the inventory project. He also works in the property division. He describes himself as a jack of all trades.
Case 1—Process Design Adviser (P10)	Middle Level	Extensive ERP software experience	This person’s job involves helping people within the business to design and review processes, and manage and further improve them.
Case 1—Commodity Facilitator (P11)	Middle Level	ERP software experience but with the older version of the software	This person is responsible for all the commercial dealings for supply contracts between organizations.
Case 1—Performance and reporting coordinator (P12)	Middle level	Extensive experience in ERP software	This person is involved in the inventory side of reporting and performance at a corporate level.
Case 1—Business Improvement manager (P13)	Middle Level	Extensive experience in ERP software	This person is the middleman between the business and the technical people. He tries to help the business make a change to an existing process or bring in a new one. He talks to the technical people to make sure they can support the business process with the technology
Case 2—Deputy Director (P14)	middle Level	Little computer experience	This person’s job was as a human and materials resource allocator for one school in the training organization
Case 2—Head of Department (P15)	Upper Level	Extensive computer experience but with older technology	Head of Department—Responsible for resources both human and material. Whole of Department budget allocations
Case 2—Head of School (P16)	Middle to Upper level	Very limited experience in computer technology	Head of School—Academic leadership
Case 2—Lecturer (P17)	Lower Level	Very limited experience in computer technology	Lecturer in military training (bomb disposal)
Case 2—Lecturer (P18)	Lower Level	Very limited experience in computer technology	Lecturer in military training (logistics)
Case 2—Professor (P19)	Upper Level	Very extensive computer technology experience	Professor in Military training and former CIO of a large multinational company
Case 2—Research Fellow (P20)	Middle level	Limited computer knowledge	Research director for the school
Case 2—Professor (P21)	Lower Level	Limited Computer knowledge	Seasoned academic responsible for curriculum development and post graduate education
Case 2—Lecturer (P22)	Lower Level	Very limited experience in computer technology Extensive experience in computer technology	Lecturer in military history and culture
Case 2—Lecturer and IT manager (P23)	Lower Lever		One of several managers of IT for the Department, Part time lecturer in IT technology

4.1. Case Study 1

Case study one was a large, networked government owned corporation responsible for the transport of people and goods in Australia. We will use this case to illustrate the development of FIS from a sensemaking perspective. The study period was focused on the time period that the organization implemented an ERP. The implementation required minimal changes to the software, mainly due to the company’s experience with a previous SAP implementation, where a considerable amount of customization was undertaken which ultimately resulted in significant costs to the organization. A total of 13 interviews were conducted with managers at all level in the supply division of this organisation (see Table 1 for details). The interviews revealed a great deal of confusion as to why the ERP was being implemented and to the usefulness of the software itself. For example a General Manager from the supply division of the organization stated that:

The world has moved on and one of the struggles we have is how to convince senior management and a lot of parts of this organisation that by changing their way in a lot of the emergent technologies and revolution of supply chain management, that we can save a lot of money and we’ve had moderate success but I would say by and large the organisation has resistance. We’ve developed a lot of poor practices, particularly in inventory management. We need to change those practices in order to generate much more efficient practices. We have a strong intellectual lag from senior management down. (General Manager Supply Division—P1)

This “intellectual lag” between senior management and other staff appears to be very real in the eyes of this general manager; however it could be equally asked whether the manager is sufficiently knowledgeable in how the ERP can be used and it may be a lack of understanding and an inability to make ‘sense’ of the technology that could be the problem. Whatever the case, if senior staff are perceived to be “being out of step with emergent technologies”, this could lead the development by the general manager of a fertile breeding ground for more technologically aware employees to accept the manager’s opinion and make their own FIS in order to “circumvent” a perceived flawed system (the ERP).

In another example, an administrator expressed concerns that there was a general lack of understanding of the ERP by all staff. This administrator suggests that there will always be room for improvement but the majority of people are not sure why the ERP was implemented or how it could be of use in their daily lives. Across the organisation it was noticed that massive performance gaps were created through people who didn’t understand how the ERP was integrated. These cognitive gaps not only duplicated business processes, thereby having people using workarounds and FIS throughout the groups, it also led to massive amounts of process delays. In the post implementation phase, the organisation found caches of duplication and even in some cases triplication of processes based on these gaps.

We also found a tense dialectic between the groups involved in systems management, accounting and finance and operational staff. These ways of seeing clashed with what we learned from management groups and operational groups we interviewed. The following example outlines how those that deal with a more fixed version of the system or were perhaps more integrated into the processes, found the system to be more affording:

I guess that with any system people have their own issues and I guess the biggest problem in our respect is partly the lack of understanding of the system but I think it’s working relatively well. Plus I guess that means there can always be improvement and modifications over time which we will continue to do so. (Administrator from accounts payable P2).

Administrative groups in this organisation deal with a structured set of assumptions that are highly fixed. When dealing with daily work, there is little ‘variance’ in the tasks associated with the management of finance because the ERP system is rigid. It allows for accounting transactions that are very structured. Balance that perspective with the idea of a general manager who works within the framework of the system across multiple domains, in which clear process lag is evident, then you begin to see the major problem. Some groups perceive the system to produce efficiencies, while the great majority of people we interviewed, perceived an ‘iron collar’ that drives them towards a purpose that is not clear.

Another example of this kind of problem was found when an inventory manager was discussing his major problems in light of the system. A typical tendency of those in favour of ERP is to blame employees who are not ‘trained’. In the following example a commodities manager blames poor training for people not coding things correctly, however we contend that if the content of the ERP was fully understood, end-users would understand the importance of correct coding for the management of inventory and the forecasting of future stock levels.

It’s a matter of training I think now with the model that we’ve gone with of pushing out all this goods receipt and paying, the importance of correctly coding things is not at the forefront of people's mind all of the time. My understanding is that it doesn’t really there are no checks when you’re coding things that get the system to say no you can’t do this. (Manager—commodities P3)

Our interviews with people entering this data revealed that often they had not had proper training so his point is well made. However, it was the purpose of using the system that was lost on people. They simply failed to understand the reasons why they should enter data one way and not the other. Hence, they built complex workarounds to achieve set tasks. In another example a manager describes the process they use to pre-process the data for entry into the ERP. You can see below how an FIS is used as a way of understanding how to load data into the system. In this way, the FIS is used to “make sense” of not only the business process but the data enter and validation process itself:

So the new approach is to vet the data first in an Excel spreadsheet and only load into SAP what is valid catalogued material and I see that as a good process because we are not putting rubbish into SAP. Everything that gets put in has been vetted and approved. (Manager—commodities P3).

The need for a ‘pre-process’ shows that the gaps imposed on the work process by the ERP create more ambiguity. If the system produced a clear process for people to follow, why would they need to ‘pre-process’? This forms part of their cognitive pattern, part of the way they make sense of organisational life and data entry. Terms like process delay, lag and duplication are not really important in management language until customers become the output of these delays. Then managers have to wonder why are we so slow in responding to problems in our organisation? These lags can be traced, as in this organisation, to be people having to do the same thing two or three times because they believe this is the way to do things.

In this case we noticed that workers in this business consistently guess what the ‘process’ is supposed to be. Even senior managers we asked were not sure what the ERP was supposed to do. This creates cognitive dissonance, or a gap, in the minds of workers. If the process created by the ERP implementation is not clear, the natural response is to create something to fill the gap. Workarounds in the form of FIS are a cognitive response to the gaps created by ERP systems that are not properly matched or implemented to organisational needs. Consequently, organisations have poor processes.

4.2. Case Study 2

Case Study two is a training organization and is a university based training centre supplying postgraduate training and degrees in conjunction with a large UK department. A total of 10 interviews were conducted (see Table 1 for details). The organisation has three different sites working together, across various locations, offering private and public training across the organisation. This site was selected because it has recently implemented an ERP system. The point of this interview series and case study was to explore the development of FIS in relation to existing processes. There was an ongoing relationship between three organizations, a service organization, the teaching organization and the client who required the training to be conducted. Communications between all three organizations was somewhat difficult and this was the context of the interviews as shown below. Interviews were conducted with the Deputy Director of the organization other members of the department, including the head of department and the head of school as well as professors and lecturers (see Table 1) who provided educational content. The interviews demonstrated a problem with understanding between different organizations. Excerpts for the interview with the Deputy Director are shown below.

When the question—we have a minimum of three organisations trying to work together. Do you think their information technology systems integrate that well? The deputy director had concerns about the financial system and how the lack of formatting standards and feedback was particularly problematic for him. That is, the organisation had multifarious standards that were not integrated clearly:

Then they give us a printout which is designed to suit their purposes and not necessarily designed to suit our purposes in managing the team here. We are going through a process whereby we are going through the budget for the next year which starts in August. The finance department have produced an outline spread sheet which is very course in the way that the data is presented so we have short courses that we budget so much—then they ask us “does that look OK?” and we don’t know what assumption underpin that particular number what courses are included and what the associated risk of these courses. Does it include courses that are 100% certain to run or does it include aspirations and to what level so our interpretation of that can be difficult—it could also mean that other department’s interpretations can be different to ours which means that they’re not getting a good picture of what our financial situation is and as a result we are not getting the right information in which to manage our activities to best effect to deliver the financial performance targets.

This is an example of the frustration expressed through a lack of shared understanding and feedback. The ambiguity from the financial system creates stress for the manager which in turn leads to stress amongst the workers. When asked for a solution, the Director’s answer (shown below) was to make the assumptions about the management systems more clear, yet this apparently simple solution is extremely difficult to implement because there are no clear owners of the system.

Question—So what could be a solution to that do you think?

A solution is making sure we capture the assumptions anything when it comes to risk, performance management, planning scheduling estimating is to capture your assumption. So I suppose we should have access to a common form we can add stuff to that they can add stuff to it and we both have visibility and for comment on those assumptions and that can then be used to manage the risk. We haven’t got those processes in place at all at present.

When further pressed with regard the implications of this solution not being incorporated into the system, the deputy director’s response to the following question is as below.

Question—Could that be a precursor for you developing systems outside their system?

Well what are doing at the moment is we sort of reverse engineer their spread sheet and tend to second guess them so we capture our own assumptions and create our own spread sheet—when they send us their outputs we compare one with the other, identify deltas between the two and then have to somehow identify why there are deltas. What are the differences in the underpinning assumptions? This is very wasteful because we are duplicating work which we shouldn’t do if we had the right processes to capture the right sort of information in the first place.

This is an example of a lack of understanding and how sensemaking leads to a very important FIS being used to structure the organisation.

Again, the example of the deputy director above is the need to create a template or cognitive map of what the work process ought to look like. In this case the work process looks confusing, hard to read and almost impossible to comprehend. This is the product on an ERP system plus a series of other systems designed to ‘integrate’ business processes across the organisation. The pressure placed on the manager, by the interlocking mess of systems, forces him into a cognitive quandary. If he doesn’t make a clear case of what he has to do, he shows that he is incompetent. On the other hand there is real pressure to deliver results for the organisation because of their services. If the manager doesn’t resort to a creative workaround he will not be able to understand, complete or even manage set tasks. The system is the process in this case. It’s not part of it, it’s the driving force of the process.

The gap created by the system forces actors into sensemaking. Sensemaking drives actors into creating systems ancillary to existing processes, which can lead to disruptive ambiguity, problems and duplicate processes. In this case it leads to gaps across the organisation that are evident by its lack of dexterity. An organisation that has this kind of mismatch between the system and process will face delays and slow the whole cycle of business down. In this way the lack of integration between the systems and the director uses causes a cognitive gap that is “made sense” of through a worksheet. The gap in the process needs to be filled by a workaround in order to make sure that what needs to be done is actually done.

5. Findings

In reference to the seven dimensions of sensemaking described by Weick [40] we believe that the examples shown in both case studies relate to many of these dimensions. For example retrospection is a major contributor to individuals wanting to make sense of the new environment of the ERP implementation. In both case studies individuals related the past situation with their present circumstances and in many cases this lead to the development of an FIS. Another dimension relates to the extraction of clues and the ability of people to fit the template of their mental modelling to expectations is particularly important with many ERP implementations where not only do the employees have to adapt to the new software, but they also have to adapt to changed business processes. People will naturally attempt to fit past business process to the new reality. In many cases this can lead to the development of an FIS in order to fit their past mental model of the right way to do things.

Plausibility is another dimension that has direct impact on the development of an FIS. With this dimension, an employee may determine that the ERP does not make any sense at all, this could be due to many factors such as a lack of appropriate training or a lack of understanding of the context of the ERP. Whatever the case, the employee will attempt to explain their situation and this may involve the development of an FIS using software tools they are familiar with.

To help frame our discussion we have three key questions, introduced prior to the methodology section, used earlier. To recap these are restated below:

¹ 

ERP systems can create an ambiguous work environment and:

² 

This ambiguity leads to a decrease in productivity in some cases leading to:

³ 

An increase in unsanctioned systems that operate outside of management control.

While our explorations gave limited responses to number 3, we learned that ERP systems, at least in these two cases, produce several layers of ambiguity, if the processes to which they are mapped are not properly integrated. While this is not a surprise, what is surprising is the manner in which workers go about creating “gap filling” systems such as FIS to make sense of complex work tasks. Where a gap is apparent, the role of the workers to “fill that gap” with FIS that becomes problematic because these are ad-hoc, often guesswork processes that may be less than optimal. The concern is therefore that the processes around the system become convoluted with a patchwork quilt of systems designed to plug the cognitive gaps produced by a poorly implemented system.

The disruptive ambiguity of the system forces people to solve the problem by creating a mental schema of what should happen during the course of the development, not what actually happens. The gap between what is expected, in terms of decision making, and what is delivered to executives can be confusing and ambiguous. This may result in little or no productivity gains, less control and more and more silos being present in working systems. This in itself is a surprising outcome because ERP systems are meant to be a solution to the silo problem found in many organizations as ERPs are implemented in order to integrate information technology resources and provide a single point of truth with the same system being used by everyone.

As noted in our case studies there can be authentic innovation coming from FIS and this is usually in the form of spreadsheets that help all employees involved in the process make better sense of the situation. This was not necessarily what we found here but it’s clear that genuine creativity is taking place through these FIS. Why can’t there be some kind of bridge between the ERP developers and the FIS systems?

An example of this is shown in the transport organization by the commodities manager in their use of a spreadsheet to vet the data before entry into SAP. This process could in itself be problematic from a data quality viewpoint; however it could also be considered a worthwhile innovation that could even lead to a change in processes where ERP systems are augmented and improved. It was clear from our time with the organisation that the ‘actual’ process and the ‘mapped’ ERP process are worlds apart. Why is this the case? The ‘actual’ process is not clear. But putting a system into a process that already contains active sensemaking and enactment, actually makes it more ambiguous. As a caveat to both these cases it should be noted that these organisations are not typical but they are becoming more common place.

From this analysis, there is no real evidence to suggest that FIS are bad or indifferent towards organisational policy. There is a lot of evidence from these cases that FIS can drive ambiguous processes, duplication and confusion if there is no shared ‘sense’ of what they are about. One of the side effects of committing to the FIS, as noted in both cases, is the duplicated approval processes. In practice this means that people are clearly building systems that are on top of existing ‘approved’ business processes. Why? In our case it was because the context of the systems implementation allows it. The poor mapping of processes, the lack of attention to how work should be done, no training and so on are all factors that could be explored. Our findings lead us back to ambiguity, cognitive gaps, mismatched processes and duplication (or triplication in Case 1). This revolves around a core misunderstanding as to what is desired to be achieved.

A main finding of our study was that this ambiguity drives sensemaking which in turn leads to an increased chance of FIS development. Rather than try to adopt the system, they move towards workarounds as a reasonable alternative. This has all kinds of implications that others have already explored ([20,22]). What needs further development in ERP research is how important these cognitive boundaries are and how they impact the system.

A possible answer to this ambiguity is that systems needs to be built with shared understanding and ownership from the start. This is a difficult task for the ERP system because it’s built on a fixed production logic that has very little room for flexible processes. If a unique, perhaps novel, context arises and a system is implemented that has the fixed assumptions of manufacturing, lean processes or a fixed business model then there is no allowance for variability as part of the business process and this can drive ambiguity. The way to reduce this could be research into effective training and (more importantly) education but we suggest more value would be found in a community driven implementation and training processes along the lines of a community of practice [22]. This runs counter to many ERP systems implementation approaches, which are often implemented in an ‘off the shelf’ fashion. This is because they are designed to be a blunt instrument of process improvement through organizational change rather than flexible software.

When implementing ERP systems there needs to be a thorough understanding of the functionality of the system otherwise it leaves a fertile ground for the development of FIS. If actors do not agree on the purpose or expected use of the system then FIS development will ensue. We argue that this is because actors do not necessarily understand how systems develop through a social process of shared understanding. The ERP is scant on the cognitive and social factors that drive acceptance in such systems. This is especially the case with systems that are standardised across industries and regions. People need to make sense of the corporate information systems and to understand how and why they can be used; otherwise it could lead to FIS development as shown in our cases. This can lead to drastically reduced productivity and duplication of processes. More importantly it can lead to FIS’ that become data rich entities outside the current system and this could lead to a different kind of problem with “islands on information” being present even in a networked environment.

6. Conclusion

In conclusion, we discovered that where ERP systems produce higher levels of ambiguity in workflow there is likely to be an increase in the amount of “gap filling” required thereby sensemaking patterns emerge. The levels of ambiguity produced by such systems create ‘disruptions’ in the patterns of work. These in turn create the need to manage these disruptions and in many cases this includes the development of FIS as a means to an end. While this speaks to the poorly developed nature of modern complex systems, it also speaks to the resilience of human beings to adapt to complex situations, rapidly yet with a certain amount of forethought. When faced with extreme amounts of ambiguity, a lot of the people we observed plugged the cognitive dissonance they found with FIS just to be able to understand how to complete a work task successfully. More research is required to explore how these cognitive patterns and FIS development influence patterns on a larger scale.

This paper discussed how ERP systems can be a source of disruptive ambiguity for organisations. Using a sensemaking framework we argued that actors will create FIS in response to this ambiguity. This can lead to duplications of processes, isolated data entities, non-robust information system use and an overall decrease in productivity. In particular we asked researchers to think about the relationship between ERP systems and information use in organisations. We believe that research in this area needs to focus on how people make sense of systems and how that leads to problems for ERP implementations. The way people perceive the implementation of an ERP system can have great bearing on how sense is made of the new technology. If management introduces the system without providing a reason for doing it, many employees may look for the “hidden agenda” or perceive the management team is simply making things hard for them (or trying to replace them). All employees need to have an understanding of the need for the technology and of the benefits the technology could bring the company and themselves.

Future Studies

Future studies could explore how cognitive dynamics could play a pivotal role in ERP implementations. While this has been established, it has not yet been explored how further ideas could be developed to explore and explain how sensemaking and work routines influence daily work. In particular, this study revealed that many different researchers identify user acceptance as a core goal of information systems development. We would like to see a long term exploration on how thinking and cognition influence the development of workarounds.