ERP Failure Is Not a Technology Problem. It Is a Structuration Problem.

I have written three posts about ERP failure. One about why CIOs get fired after implementation, drawing on sociotechnical theory and DeSanctis and Poole's Adaptive Structuration Theory. One about only 16% of digital transformations succeeding, which is really about the gap between deploying technology and changing organizations. And one about why the same system produces different outcomes in different organizations, which laid out Giddens and Orlikowski's framework. None of those posts applied structuration theory directly to ERP failure as its own argument. This post does that, because I think the connection is the most important thing IS theory can say about why enterprise systems keep failing.

Giddens (1984) built structuration theory around one claim that sounds simple and is actually hard to hold in your head for more than a few minutes. Social structures are both the medium through which people act and the outcome of that action. People draw on existing rules, resources, and norms to do things. By doing those things, they reproduce or modify those same structures. There is no structure without action that enacts it, and there is no action that is not shaped by structure. He called this the duality of structure. Not a dualism, two separate things in tension, but a duality, one thing that has two aspects at once. The three modalities that link structure to agency in any particular interaction are signification, which is the dimension of meaning, domination, which is the dimension of power, and legitimation, which is the dimension of moral order. Every interaction draws on and reproduces all three simultaneously.

Orlikowski (1992) took this framework and pointed it at technology. Her argument is that technology is both a product of human action and a medium of human action. It is a product because people designed, built, configured, and deployed it through organizational and social processes that reflect existing structural conditions. It is a medium because once it exists in an organization, it shapes what users can do and how they can do it. This duality mirrors Giddens directly. Orlikowski called the enacted outcome "technology-in-practice," meaning the structural properties of a technology are not fixed at the design stage. They emerge through recurrent use. Two departments running the same SAP instance can develop completely different technologies-in-practice because their patterns of use differ, and those patterns differ because the structural conditions they operate in differ.

DeSanctis and Poole (1994) extended this specifically to group technology use through Adaptive Structuration Theory. Their key move was to say that technologies carry structural features, which are the rules and resources embedded in the system, and a spirit, which is the general intent for how those features should be used. Groups can appropriate the structures faithfully, using the system consistent with its spirit and feature design, or unfaithfully, departing from that spirit. This is where ERP failure becomes legible in structurational terms. ERP systems carry an unmistakable spirit: process standardization, data integration, cross-functional visibility. Their structural features embed assumptions about approval hierarchies, data flows, role definitions, and reporting lines. When an organization adopts SAP, it is not just installing software. It is importing a set of structural assumptions about how work should be organized.

The failures I wrote about before, CIOs getting fired, projects running over budget, organizations living with workarounds for years after go-live, are not technology problems in any meaningful sense. They are what happens when the structural assumptions inscribed in the system collide with the structural conditions of the adopting organization. Consider what happens across the three modalities when an ERP system meets an organization where it does not fit.

Signification: the system encodes interpretive schemes about what counts as a completed transaction, what data fields matter, what granularity of reporting is meaningful. When the people using the system do not share those interpretive schemes, they enter data in ways the system was not designed to handle, or they create shadow systems alongside the official one and populate both, or they ignore outputs that do not match their understanding of what is real. The system becomes unreliable, not because the software is buggy, but because the interpretive schemes of the organization and the system are misaligned.

Domination: the system allocates resources. It decides who sees what data, who approves what transactions, whose dashboard shows which metrics. When these allocations conflict with existing power distributions, the resistance is not irrational. It is structural. Finance teams that had approval authority over certain budget lines find those lines reassigned. Regional managers who controlled local procurement discover that the system centralizes vendor relationships. The resistance is the existing domination structure asserting itself against the new one inscribed in the software. I think most change management advice misses this entirely. It frames resistance as a people problem to be overcome rather than a structural conflict to be understood.

Legitimation: the system enforces norms through mandatory fields, approval workflows, and process controls that cannot be bypassed without workarounds. When the norms embedded in those controls conflict with what the organization's members consider legitimate, the workaround becomes the actual system. People find ways to skip steps, enter dummy data in required fields, or maintain parallel processes outside the system. The legitimation modality is the organization saying, through its behavior, that the norms the system enforces are not legitimate here.

What makes this a structuration problem rather than a change management problem is the recursive loop. The structural conflict does not resolve itself once. It reproduces itself through use. The finance team creates a workaround to preserve their approval authority. The workaround becomes the way finance does things. New hires learn the workaround as standard practice. After a few years, nobody remembers it was a workaround. The technology-in-practice has solidified. The original structural conflict is now embedded in the organization's enacted structures. Orlikowski described this precisely: the structural properties of technology are enacted through recurrent use, and the patterns of that use reproduce or transform the structural conditions that shaped them in the first place.

This is why the same SAP instance can succeed in one organization and fail in another. It is not because one organization has better project management or more committed executives, though those things help. It is because the structural conditions into which the system is introduced differ. Where the existing interpretive schemes, power distributions, and norms roughly align with what the system inscribes, the technology-in-practice that emerges supports the system's spirit. Where they conflict, the technology-in-practice that emerges undermines it. The system has not changed. The enacted structure has. DeSanctis and Poole would call the first case faithful appropriation and the second unfaithful appropriation, and I think that vocabulary is useful, but it can make it sound like the problem is that people are not following instructions. Structuration theory reframes it: the problem is that the structural conditions of the organization and the structural assumptions of the system are in conflict, and that conflict plays out through the three modalities every time someone logs in and does their work.

I think the practical implication is something most ERP implementation plans get backwards. They start with the technology, configure it, and then try to change the organization to fit. A structurational approach would start with the existing structural conditions and ask whether the system's inscribed assumptions align with them, and if not, where and how the conflicts will manifest across signification, domination, and legitimation. This does not mean avoiding ERP implementations where misalignments exist. It means knowing where the fractures are going to appear before the go-live date, so the organizational work of alignment begins before the technology arrives rather than in the chaotic aftermath.

The organizations that succeed with ERP are not the ones with the best change management programs. They are the ones whose existing structural conditions already approximate what the system inscribes, or the ones that deliberately reshape those conditions before the system arrives. Everyone else gets to discover the duality of structure the hard way.