The Pitfalls of “Bridging Technology and Management” and the Truly Necessary Perspective

Services branding themselves as “IT Strategy / DX Support Partners that Bridge Technology and Management” are proliferating in the market. Just the other day, an article reported on Re-Jume LLC promoting support that “bridges technology and management.” At first glance, this seems like the ideal support model we should seek. However, I fear this very trend reveals a fundamental structure of “thought cessation” and “abdication of responsibility” when Japanese companies confront IT.

The term “bridge” inherently acknowledges that “technology and management are disconnected.” And the premise is that this gap is to be filled by an “external partner.” Isn’t this a mindset of trying to outsource the most critical task: for management to define and integrate IT under its own responsibility?

The Soil from Which “Bridging” Support Grows: Management’s Abdication of IT

Why has the need to “bridge technology and management” become so pronounced? The background lies in the structural problem we repeatedly highlight in our editorial policy: “management’s abdication of IT.”

Many executives have viewed IT as a “specialized and arcane technical domain,” delegating its purpose definition and design to technicians or external vendors. This is not “delegation” but “abdication.” In delegation, management clearly sets the objectives and evaluation criteria. In abdication, vaguely defined objectives are tossed to outsiders, resulting in the proliferation of “departmental IT,” “personalized IT,” and “non-integrable IT.”

Now, attempts are made to fill this massive chasm created by “abdication” with services under the banner of “bridging.” This is merely repeating symptomatic treatment without addressing the root cause: the “absence of IT definition by management.” Support partners can indeed provide useful insights, but what they can define are “means,” not the company-specific “purpose.” Introducing support without thinking about that “purpose” only creates new dependencies.

The Limits of “Bridging” Viewed from Three IT Classifications

At this media outlet, we categorize corporate IT into three types: “Business IT,” “Management IT,” and “Administrative IT.” Analyzing “bridging support” from this perspective clearly reveals its limits.

The Disconnect Between Business IT and Management IT Cannot Be “Bridged”

“Business IT” (IT directly linked to revenue and growth) prioritizes speed. A culture of rapid response to field needs and immediate SaaS adoption is dominant. On the other hand, “Management IT” (IT for decision-making and reproducibility) prioritizes integration and consistency. It aims to integrate company-wide data to enhance the quality of management decisions.

These two have fundamentally different objective functions. It is inherently difficult for an external partner to “bridge” speed-prioritized Business IT and integration-prioritized Management IT. Because it requires a “management decision” on which objective to prioritize. For management to avoid making this decision and instead ask a partner to “bridge them” is nothing but an abdication of management responsibility.

The “Stability” Doctrine of Administrative IT Hinders Everything

Furthermore, we cannot overlook the presence of “Administrative IT” (IT for stable operations and cost control). In many companies, the IT department is evaluated solely on “stability” and “cost reduction.” As a result, new attempts at “bridging” are often blocked as “too risky” or “having unclear costs.” Even if an external partner tries to “bridge technology and management,” they are often obstructed by this internal “Administrative IT” wall.

So, What Should Be Done? From “Bridging” to “Integrated Design”

So, what should executives, CTOs, and IT departments specifically think and do? The keyword is a shift from “bridging” to “integrated design.”

First Step: Define Your Company’s IT Objective Function

First, the management team must debate the fundamental question: “What is the purpose of IT in our company?” For example, verbalize “What business outcomes do we want to achieve through IT in the next three years?” There can be multiple answers: sales expansion, improved decision-making speed, ensuring reproducibility of business processes, etc. The key is to prioritize these, as speed and integration often involve trade-offs.

Once this objective function is defined, it becomes possible to make judgments like “how much to invest in which IT” and “how to balance Business IT and Management IT.” What should be sought from external partners is “proposals and execution support for the means” to achieve this defined objective function.

Practical Example: The Case of a SaaS Integration Dashboard

A retail client had various SaaS tools (sales management, inventory management, shift management) adopted haphazardly by each store, which were not utilized for management decisions. The steps they took were as follows:

1. Define Management Objective: Set the top priority as “Understanding the profitability of all stores in real-time and reflecting it in next month’s sales promotion strategies.”
2. Clarify Technical Constraints: Worked with the IT department to identify API connectivity and data formats of existing SaaS tools.
3. Select Tools: Introduced a data integration platform (utilizing Microsoft Power BI and connectors for each SaaS at the time) to achieve the objective. Expensive custom development was postponed.

In this process, external consultants were tasked with “building a specific data pipeline using Power BI.” However, the definition of the purpose—”what to connect for”—was done by the management team themselves. As a result, they created a system with clear ROI that continues to be used.

The “Right” Way to Engage with Support Partners

“Bridging technology and management” partners are by no means unnecessary. In fact, if used appropriately, they can be powerful drivers. The key points are the following three.

1. Never Outsource Purpose Definition

What you should first seek from a partner is not “helping us think about our IT purpose based on understanding our business,” but “concrete proposals on how to technically achieve and measure the purpose we have defined.” Many services sell purpose-setting workshops, but while you may borrow their facilitation, the resolve to derive the answer from the management team’s own conviction is essential.

2. Discern the Core “Bridging” Technology

Many support services are based on specific technology stacks (e.g., a particular cloud platform, integration tool). Determine whether your company’s existing environment (especially the SaaS suite where data originates) is compatible with the partner’s expertise. It would be counterproductive to have a proliferation of new tools driven by the partner’s convenience.

3. Agree on the Exit Strategy (Path to Internalization) from the Start

To avoid creating dependencies, set the goal of support as “knowledge and asset transfer.” For example, draft a roadmap from the outset where the partner handles the initial data pipeline construction, but from the second dashboard onward, your internal IT leads with the partner only involved in review. This makes the support a “temporary catalyst for self-reliance,” not a “permanent bridging agent.”

Conclusion: The Executive’s Role is Not to “Bridge” but to “Command Integration”

The phrase “bridging technology and management” certainly has a pleasant ring to it. However, if it occurs away from the hands of the executives themselves, it only fosters new technical personalization or external dependency.

What is truly needed is for executives to declare that “technology and management are inherently an inseparable whole” and take responsibility for its integrated design themselves. On that foundation, they should seek lacking technical execution power or know-how from partners, armed with a clear purpose definition and exit strategy. This order must not be mistaken.

DX is, ultimately, “the redesign of management using digital technology.” The one who holds the pen to draw that design is none other than the executives themselves.