🇯🇵 日本語 🇬🇧 English 🇨🇳 中文 🇲🇾 Bahasa Melayu

Whose Failure is IT Fragmentation?

Management & IT

Introduction

The causes of IT fragmentation are often attributed to the proliferation of tools at the frontline, the conservative posture of IT departments, or vendor dependency. However, these are merely symptoms that have manifested as a result. This article clarifies the fundamental cause by framing IT fragmentation not as a question of “whose fault is it?” but from the perspective of “the structure of management decisions.”

Fragmentation is Not an “Unintended Accident”

The first point to confirm is that IT fragmentation is not a random accident. The optimal IT was chosen for each business unit, and rational decisions were made for each department. The accumulation of choices that were correct at the time resulted in fragmentation. In other words, it happened not because someone made a mistake, but because there was no entity responsible for integrating and taking ownership of the whole.

The Frontline Consistently Chose the “Optimal Solution”

The frontline makes decisions within the constraints of keeping daily operations running, maintaining revenue, and not halting customer service. As a result, choosing solutions that are quick to implement, immediately usable, and locally optimal was an extremely rational course of action. The frontline did not intentionally create fragmentation.

The IT Department Protected What Needed to Be Protected

The IT department (Information Systems) has traditionally been evaluated based on expectations to prevent system failures, protect information, and control costs. Within this evaluation framework, there is little incentive to intervene for enterprise-wide optimal design or to engage with business speed. The IT department also became part of the fragmented structure as a result of faithfully fulfilling its assigned role.

The Vendor Did the “Requested Work”

The vendor’s role is to meet the requested specifications, fulfill responsibilities within the contract scope, and complete the project. It is not in a position to take ownership of enterprise-wide integration or long-term management structure. Vendor dependency becomes a problem when decisions that management should inherently own are delegated to them.

So, Who Failed?

As clarified by the analysis so far, the frontline acted rationally, the IT department acted according to its role, and the vendor acted according to the contract. If IT fragmentation still occurred, there is one reason: there was no entity within the organization responsible for integrating the fragmented IT.

The Reason for Lack of Integration Lies in “Management Decisions”

To integrate IT as a whole, irreversible decisions are required, such as “which IT to keep, where to standardize, and what to discard.” These are not decisions that the frontline, IT department, or vendor can individually own; they are decisions that only management can and should own.

The Failure of IT Fragmentation is “Management Inaction”

It is crucial not to conclude this as merely “a lack of capability of individual managers.” IT fragmentation is the result of “inaction as a management structure”—failing to define IT, postponing decisions, and not making integration a core subject of responsibility. It is not the failure of any single person; it is the visualization of fragmentation in an area that the decision-making system called “management” failed to take ownership of.

Taking Responsibility Means Taking Ownership of the Structure

The “management failure” referred to here is not about blaming individuals. It is about clarifying: “Which decisions were not made?”, “Why were they not made?”, and “Who will take ownership from now on?”. Only when this is achieved can IT fragmentation transform from a past failure into a redesignable management challenge—the essential challenge of DX.

Conclusion of Chapter I

IT fragmentation is not caused by frontline recklessness, IT department negligence, or vendor dependency. It is the result of management failing to define IT, make decisions, and take responsibility. The next chapter will examine the “objective function of IT” that management failed to define and specify what needs to be owned going forward.

Comments

Copied title and URL