When Technology Becomes Part of the Problem

SAI WHITE PAPER SERIES

WHEN TECHNOLOGY BECOMES PART OF THE PROBLEM

Why a technically successful implementation can still leave the governing condition untouched

Lawrence M. Schneider
Founder & CEO, Schneider Axiom Institute™

PUBLICATION IDENTITY

Original Publication: June 2026 · Current Revision: September 2026 · Version: 1.0 · Classification: Technology Fit · Operational Complexity · Diagnostic Reasoning · Publication Identifier: SAI-SCBC-10

Subject: Technology Investment · Process Design · Task-Technology Fit · Implementation Risk · Operational Complexity · Diagnostic Reasoning
Primary Audience: Business Owners · Executives · Operations Leaders · Technology Leaders · Advisors · Consultants · Business Educators
SAI Discipline Stage: IDENTIFY → PRIORITIZE → RESOLVE → CONFIRM
Evidence Orientation: Practitioner Observation · First-Person Operating Case · External Scholarship · Conceptual Diagnostic Illustration · SAI Proposition

Executive Abstract

Technology is usually purchased to solve a problem. That does not mean the problem has been correctly identified.

A CRM can improve visibility while missed follow-up continues. An ERP can integrate information while cross-functional decision problems remain. Automation can reduce labor cost and improve consistency while delivery performance remains unchanged. A scheduling system can allocate capacity more efficiently while the demand pattern creating the imbalance remains untouched.

In each case, the technology may work. The business problem may still remain.

That distinction matters because implementation success and diagnostic success are not the same thing.

Technology can also create new operating burdens: administration, customization, dependency, process rigidity, workarounds, integration complexity, switching costs, and organizational resistance. Those burdens may be tolerable. They may even be justified by the value created. Or they may become material enough to deserve priority.

The key question is therefore not simply:

“Did the system work?”

It is:

“DID THE TECHNOLOGY IMPROVE THE CONDITION THAT ACTUALLY DESERVED PRIORITY?”

Over decades of operating businesses, I learned to value technology most when it amplified operating understanding rather than substituted for it.

My experience with Sperry Univac at U.S. Lock in the 1970s remains one of the clearest examples. The technology did not create the operating logic from nothing. It helped scale a process architecture that had already been developed through direct operating experience.

That experience does not establish a universal technology-implementation rule. It does support a useful discipline:

UNDERSTAND THE OPERATING PROBLEM BEFORE ASKING THE TECHNOLOGY TO SOLVE IT.

THE CENTRAL PROPOSITION

A technology investment can be technically successful and still fail to improve the business condition that matters most if it is selected against the wrong problem. Technology can also introduce new burdens—complexity, administrative load, process distortion, dependency, or lock-in—that deserve separate diagnosis. The key question is not simply whether the system works, but whether it improves the condition that deserves priority.

Why This Paper Matters

Technology has an unusual status inside organizations. It often arrives carrying the authority of a solution.

Once the software is selected, the contract signed, the implementation team formed, the data migrated, the employees trained, and the integrations built, the organization becomes understandably invested in making the system succeed.

That commitment can be productive. It can also make the system harder to question.

The business may continue asking:

“How do we make the technology work better?”

when the more important question is:

“WAS THIS THE RIGHT PROBLEM TO SOLVE?”

Those are different questions. One examines implementation. The other reopens diagnosis.

Technology Can Succeed at the Wrong Level

One of the easiest mistakes to make is to treat technical success as business success.

The system launches on time. Users log in. The data migrate correctly. The workflows run. The reports populate. The implementation may therefore be technically successful.

But what if the condition that justified the investment does not materially improve?

The CRM works, but qualified prospects still disappear. The ERP works, but scheduling conflict remains. The inventory system works, but stockouts continue. The analytics platform works, but leadership still cannot determine what deserves priority.

The technology may be functioning exactly as designed.

THE BUSINESS PROBLEM CAN REMAIN EVEN WHEN THE SOFTWARE IS WORKING.

That is the distinction this paper examines.

Better Measurement Is Not the Same as Resolution

Technology often improves visibility. That can be extremely valuable. But visibility and resolution are not the same thing.

A CRM may show exactly which prospects were not contacted. An inventory system may document which SKUs stocked out and when. An ERP may reveal where the order stalled. An analytics platform may display the performance decline with far greater precision than the prior reporting process.

Better evidence can improve diagnosis. It can also expose weaknesses that were previously hidden.

But better measurement does not establish that the condition generating the measurement has been resolved.

A SYSTEM CAN MEASURE THE PROBLEM BETTER WITHOUT SOLVING IT.

That distinction becomes especially important when improved reporting begins to be mistaken for improved performance.

The Sperry Univac Experience

In the mid to late 1970s, Sperry Univac came to U.S. Lock because of the work I had been doing around picking, packing, and shipping.

At that time, I had already been developing the operating logic manually. The business was growing, the warehouse operation was becoming more complex, and the efficiency of the picking route mattered increasingly to throughput.

Sperry Univac did not arrive, in my recollection, with a finished operating answer that I was expected simply to adopt. They came because the operating problem was already being worked through inside the business.

U.S. Lock became a beta site.

What mattered to me was the sequence. The operating logic came first. The technology helped scale it.

I do not present that experience as proof that every successful technology implementation must follow the same path. Sometimes the existing process is inefficient, obsolete, or badly designed. Technology can introduce a better architecture than the business currently possesses.

But the Sperry Univac experience taught me a principle that remained important throughout my operating career:

TECHNOLOGY IS MOST USEFUL WHEN THE BUSINESS UNDERSTANDS WHAT IT IS ASKING THE TECHNOLOGY TO IMPROVE.

Technology Should Serve the Operating Need—But the Operating Need May Need to Change

There are two opposite mistakes.

The first is forcing the business to conform blindly to the technology. The second is forcing the technology to preserve a process that should have been redesigned.

Both happen.

A company may insist that its decades-old process is “how we do things” and customize a modern system until the new technology simply recreates old inefficiencies.

Another company may accept the vendor's default workflow without asking whether it fits its customers, risk profile, operating model, or decision structure.

Neither extreme is diagnostic.

The better question is:

WHAT SHOULD THE PROCESS BE—AND WHAT ROLE SHOULD THE TECHNOLOGY PLAY IN MAKING THAT PROCESS WORK?

That keeps the technology subordinate to the operating objective without assuming the existing process is correct.

Four Ways Technology Can Become Part of the Problem

Technology does not become problematic in only one way. Several distinct mechanisms deserve examination.

1. Misfit

The technology may not fit the actual operating requirement.

The issue could involve the workflow, data structure, level of complexity, integration, functionality, or assumptions embedded in the system.

A technically capable platform can still be a poor fit for a particular operating environment.

2. Complexity Burden

The system may require more administration, customization, maintenance, exception handling, or external support than the organization expected.

That does not automatically make it a constraint. But the burden can become material.

At some point, the organization may find itself supporting the system almost as much as the system supports the organization.

3. Process Distortion

Work may begin adapting to what the system permits rather than what the operating requirement calls for.

Sometimes that standardization is beneficial. Sometimes it creates unnecessary approvals, duplicated data entry, awkward handoffs, workarounds, or delays.

The question is whether the system is enforcing a better process—or merely a more rigid one.

4. Dependency and Lock-In

Technology can become difficult to change because the organization has accumulated:

integrations,
customizations,
training,
specialized staff,
data dependencies,
contractual commitments,
switching costs.

The system may still create substantial value. But its cost of replacement can make leadership reluctant to reconsider whether it remains the right fit.

THE MORE EMBEDDED THE TECHNOLOGY BECOMES, THE MORE IMPORTANT IT IS TO DISTINGUISH VALUE FROM DEPENDENCY.

Sunk Cost Can Make the System Harder to Question

Once an organization has invested heavily in a technology implementation, materially changing or abandoning it can feel like admitting that prior spending was wasted.

That pressure matters.

Research on sunk-cost effects has shown that prior investment can influence continued commitment even when future decisions should ideally be based on expected future value rather than unrecoverable past expenditure.

Technology implementations create fertile conditions for this problem because the investment is rarely only financial.

The organization may also have invested:

executive sponsorship,
employee training,
political capital,
process redesign,
data migration,
consulting fees,
time.

The more invested the organization becomes, the more difficult it may be to ask:

“WOULD WE MAKE THE SAME DECISION TODAY?”

That question should remain available.

Five Questions Before Blaming—or Defending—the Technology

These questions do not diagnose the governing constraint. They help prevent premature conclusions.

1. What business condition was the technology supposed to improve?

Not what feature was implemented. Not what workflow changed. What business condition justified the investment?

Lead time? Throughput? Conversion? Inventory availability? Error rate? Decision speed? Customer retention?

If that condition cannot be stated clearly, evaluation begins on unstable ground.

2. Did the intended business condition improve?

The system may be stable. Users may be active. Reports may be available.

But did the original performance condition improve materially?

IMPLEMENTATION COMPLETION IS NOT THE SAME AS PERFORMANCE IMPROVEMENT.

3. Did the technology solve the problem—or reveal it more clearly?

Sometimes the system does exactly what it should by exposing a problem the organization could not previously see. That is not necessarily implementation failure. It may be diagnostic progress.

A CRM that reveals persistent follow-up failure may be doing useful work even if the follow-up problem remains.

The next question is what the new evidence indicates.

4. What new operating burden did the technology create?

Every significant system creates some burden. Training. Administration. Maintenance. Exception handling. Data stewardship. Integration.

The question is not whether burden exists. It is whether the burden is proportionate to the value created.

5. What competing explanations could account for the original problem?

If software is assumed to be the answer from the beginning, alternative explanations may never be seriously tested.

The original symptom may reflect:

weak process design,
inadequate authority,
poor data,
insufficient capacity,
market mismatch,
training,
leadership,
incentives,
or another condition entirely.

Technology selection should follow examination of the operating need—not substitute for it.

Three Technology Investments. Three Diagnostic Questions.

The following scenarios are conceptual diagnostic illustrations. They are not presented as independently verified cases or proof that technology was or was not the governing constraint.

Their purpose is to show how technically successful systems can coexist with unresolved business problems.

The CRM That Documented the Follow-Up Failure

A business implements a CRM because qualified prospects are not being followed up consistently.

The system launches successfully. Contacts are centralized. Reminders fire. Managers can see overdue activity. And missed follow-up continues.

Several explanations remain possible. The workflow may be poorly configured. Salespeople may not use it consistently. Workload may be excessive. Incentives may discourage follow-up. Ownership may be unclear. Lead quality may be weak.

Or the CRM may have successfully exposed a problem that previously existed without visibility.

The diagnostic question is not:

“Did the CRM fail?”

It is:

“WHAT CONDITION IS PRODUCING THE MISSED FOLLOW-UP NOW THAT WE CAN SEE IT MORE CLEARLY?”

The system may have become evidence rather than resolution.

The ERP That Added Administrative Load

A growing manufacturer implements an ERP to improve coordination, inventory visibility, scheduling, and financial reporting.

The system works. But the company now requires substantial internal administration and recurring outside support.

Is the ERP the problem?

Maybe.

But several questions should come first.

Was the administrative burden expected? Did the ERP materially improve the original performance condition? Are the customizations necessary? Are employees using workarounds because the process design is weak? Does the company have enough scale to justify the system's complexity?

The relevant issue is not simply how many people administer the ERP. It is whether the total operating value exceeds the burden introduced.

TECHNOLOGY COST SHOULD BE EVALUATED AGAINST OPERATING VALUE—NOT AGAINST THE ASSUMPTION THAT TECHNOLOGY SHOULD REQUIRE NO MANAGEMENT.

The Automation That Worked—and the Delivery Problem That Did Not

A manufacturer automates part of production.

Labor cost declines. Consistency improves. The equipment performs as expected. Delivery performance does not materially improve.

That does not mean the automation failed. It may have succeeded at exactly what it was designed to do.

The larger question is whether labor cost and production consistency were actually governing delivery performance.

Perhaps the limiting condition sits in scheduling, demand variability, material availability, approvals, sequencing, supplier performance, or another part of the production flow.

The technology can be successful. The diagnosis can still be incomplete.

AN INTERVENTION CAN PRODUCE A REAL IMPROVEMENT WITHOUT IMPROVING THE CONDITION THAT DESERVED PRIORITY.

Sometimes the Technology Really Is the Problem

This safeguard matters.

A paper about misdiagnosed technology investments should not become an argument that technology is rarely at fault.

Sometimes it is.

The software may be unreliable. The architecture may not scale. The integration may be poor. The interface may generate errors. The vendor may not deliver required functionality. The implementation may be badly managed. The customization may become unmaintainable. The system may impose excessive operating friction.

Technology itself can become materially limiting.

The diagnostic discipline works both ways.

Do not blame technology merely because the business problem remains. Do not defend technology merely because the implementation was expensive. Examine the evidence.

Sometimes the Process Should Conform to the Technology

This safeguard matters just as much.

Businesses often believe their existing process is unique.

Sometimes it is.

Sometimes it is simply old.

A modern system may contain a standardized workflow because that workflow is more reliable, more scalable, or better controlled than the informal process the organization developed over time.

Adapting the business to the technology may therefore be the right decision.

The question is whether the change improves the operating requirement—not whether the new process feels unfamiliar.

“THE SOFTWARE MADE US CHANGE” IS NOT, BY ITSELF, EVIDENCE THAT THE SOFTWARE IS WRONG.

What the Technology Literature Adds

The broader technology and organizational literature provides useful context for these observations.

Research on task-technology fit has emphasized that technology performance depends partly on how well the capabilities of the technology match the tasks users must perform. That perspective matters because technical capability alone does not establish operational fit.

The socio-technical tradition has long emphasized the interaction between technical systems and the social organization surrounding them. Technology changes work, communication, authority, coordination, and roles; those organizational effects can matter as much as the software itself.

Research on process innovation has likewise emphasized that technology creates more value when considered together with process design rather than treated merely as automation layered over existing work.

Research on sunk-cost effects adds another caution: prior investment can influence willingness to continue with a course of action even when the relevant question should be future value.

These bodies of literature do not independently validate the SAI governing-constraint framework or establish that diagnosis before technology selection produces superior outcomes.

They do support a broader principle:

THE VALUE OF TECHNOLOGY DEPENDS NOT ONLY ON WHAT THE TECHNOLOGY CAN DO, BUT ON HOW WELL IT FITS THE WORK, THE PROCESS, AND THE PROBLEM BEING ADDRESSED.

Technology Can Be Evidence, Intervention, and a New Condition

Technology can occupy several roles at once.

It can be:

an evidence source — revealing patterns that were previously invisible.

an intervention — changing how work is performed.

an infrastructure layer — supporting multiple business processes.

a new operating burden — adding complexity, dependency, or administration.

Those roles should not be confused.

A system that reveals a problem has not necessarily caused it. A system that improves one process has not necessarily resolved the governing constraint. A system that creates administrative work has not necessarily become the governing constraint.

Each conclusion requires evidence.

A Technology Problem Is Not Automatically an Operational Constraint

A technology issue may appear operational while the underlying condition sits elsewhere.

The business may have selected the wrong system because of a Strategic decision. The system may be resisted because of a Leadership condition. Authority over implementation may be fragmented because of an Organizational condition. The investment may be unsustainable because of a Financial condition. The company may be automating a process that serves the wrong market because of a Market condition.

Or the technology itself may genuinely create an Operational limitation.

THE SYSTEM IS PART OF THE EVIDENCE. IT DOES NOT, BY ITSELF, ESTABLISH THE CONSTRAINT CLASS.

That distinction is essential.

IDENTIFY → PRIORITIZE → RESOLVE → CONFIRM

Identify

What business condition justified the technology investment?

What evidence indicates the technology is helping or hindering that condition?

What burdens did implementation create?

What competing explanations remain plausible?

Do not begin with:

“The software is the problem.”

Do not begin with:

“The software cannot be the problem.”

Begin with the evidence.

Prioritize

A technology issue may be real and still not deserve priority.

The system may be inefficient while inadequate demand is governing performance. The implementation may be cumbersome while a cash limitation is more consequential. The workflow may be awkward while the principal bottleneck sits elsewhere.

A REAL TECHNOLOGY PROBLEM IS NOT AUTOMATICALLY THE GOVERNING CONSTRAINT.

Priority must still be determined.

Resolve

If technology is materially contributing to the governing condition, resolution may include:

reconfiguration,
process redesign,
better integration,
reduced customization,
new governance,
improved training,
data cleanup,
replacement,
or abandonment.

If technology is not the governing condition, the appropriate response may be to keep the system and address the underlying problem it has made easier to see.

Confirm

Did the intended business condition improve?

Did the technology burden decline?

Did adoption improve?

Did the expected operating result occur?

Did another condition become limiting?

And if the original problem returns:

RECURRENCE MEANS REOPEN THE DIAGNOSIS.

Do not automatically blame the technology. Do not automatically blame the users. Look again.

What This Changes for Business Owners

Before approving a major technology investment, ask:

What condition are we trying to improve?

What evidence suggests technology is the appropriate intervention?

What would success look like operationally—not merely technically?

What new burden will the system create?

What happens if the system works exactly as designed and the business problem remains?

That last question is especially important. It forces diagnosis before commitment.

What This Changes for Executives

Do not let implementation metrics substitute for business metrics.

A successful rollout can still accompany an unsuccessful business outcome.

Executives should distinguish:

project completion,
system adoption,
technical performance,
operational performance,
strategic value.

Those are different measures.

A dashboard showing 98% user adoption does not answer whether the organization improved the condition that justified the investment.

What This Changes for Technology Leaders

Technology leaders should not be expected to diagnose the entire business.

But they should insist on clarity about the business problem the technology is expected to address.

A strong technology function can ask:

What business condition are we changing?

Who owns that condition?

What process will change?

What metric should move?

What evidence would tell us the technology is not the right intervention?

Those questions protect both the business and the technology team.

What This Changes for Advisors and Consultants

Do not recommend technology merely because the client presents a technology-shaped symptom.

A fragmented process may need a system. It may also need clearer ownership.

A reporting problem may need analytics. It may also need better decision discipline.

A capacity problem may need automation. It may also need better sequencing.

The advisor should distinguish the tool from the condition.

TECHNOLOGY IS A PRESCRIPTION. DIAGNOSIS SHOULD COME FIRST.

Implications / Applications

For business owners: Define the business condition before selecting the technology.

For executives: Separate implementation success from business-performance improvement.

For technology leaders: Clarify the intended operating outcome before committing to architecture.

For operations leaders: Determine whether the system improves flow or merely administers it more visibly.

For advisors and consultants: Treat technology as one possible intervention, not the default diagnosis.

For business educators: Teach technology investment as an organizational and diagnostic decision, not merely a systems-selection decision.

Across all six:

THE QUESTION IS NOT ONLY WHETHER THE TECHNOLOGY WORKS. THE QUESTION IS WHETHER IT IMPROVES WHAT ACTUALLY DESERVES PRIORITY.

Limitations and Questions for Further Examination

This paper advances a practitioner and conceptual proposition about technology selection, operating fit, complexity, and governing-constraint diagnosis.

It does not establish that technology implementations generally fail because diagnosis was inadequate.

It does not establish that technology should always adapt to existing processes rather than the business adapting to technology.

It does not establish that administrative burden makes a technology system a governing constraint.

It does not establish that successful implementations require the operating solution to exist before the technology is selected.

It does not establish that vendor methods are generally inferior to internal operating knowledge.

And it does not establish that the SAI Business Constraint Discipline™ or SAI diagnostic instruments have been independently validated as producing superior technology-investment outcomes.

Technology performance can depend on system design, implementation quality, configuration, data quality, process design, user adoption, training, governance, vendor capability, organizational readiness, and changing business conditions.

Questions deserving further examination include:

How should organizations distinguish task-technology misfit from weak adoption?

When should a business adapt its process to a standardized system rather than customize the system?

How should technology administration cost be evaluated against operating value?

At what point does switching cost become a material constraint?

How should business leaders evaluate sunk-cost pressure during a troubled implementation?

When does technology reveal the governing constraint rather than contribute to it?

How should technology-performance measures be connected to enterprise-performance measures?

These questions should remain open.

Conclusion

Technology is powerful. That is exactly why diagnosis matters before a major technology decision.

A system can work. Users can adopt it. Reports can improve. Automation can succeed. And the business can still be limited by the same condition that existed before implementation.

Technology can also create new burdens of its own.

That does not make technology the enemy. It makes technology something that should be examined with the same diagnostic discipline applied to every other material condition in the business.

The question is not:

“Did we implement the system correctly?”

It is not even:

“Did the technology improve something?”

The deeper question is:

“DID IT IMPROVE THE CONDITION THAT DESERVED PRIORITY?”

If the answer is no, do not automatically discard the system. Do not automatically blame the implementation. Do not automatically blame the users.

Reopen the diagnosis.

The lesson I took from the Sperry Univac experience remains useful:

Understand the operating problem clearly enough to know what the technology is being asked to improve.

Then let the evidence determine what should happen next.

WHEN TECHNOLOGY BECOMES PART OF THE PROBLEM, THE ANSWER IS NOT AUTOMATICALLY MORE TECHNOLOGY—OR LESS. THE NEXT STEP IS BETTER DIAGNOSIS.

IDENTIFY → PRIORITIZE → RESOLVE → CONFIRM

Diagnosis first. Improvement second.

Evidence Boundary

This White Paper combines several forms of material that should not be treated as equivalent.

Practitioner / Operating Observation

Observations regarding technology selection, operating fit, administrative burden, implementation, process distortion, and technology dependency reflect practitioner experience and operating interpretation.

First-Person Operating Case

The Sperry Univac / U.S. Lock account reflects Lawrence M. Schneider's first-person recollection of U.S. Lock serving as a beta site while technology was developed around operating processes he had been working to improve. It should not be interpreted as an independently audited technology-implementation study or proof of a universal implementation method.

Conceptual Diagnostic Illustrations

The CRM, ERP, and automation scenarios are conceptual diagnostic illustrations. They are not presented as independently verified cases, measured outcomes, or proof that technology was or was not the governing constraint.

Internal SAI Framework

The governing-constraint concept, the Seven Classes of Business Constraint™, and IDENTIFY → PRIORITIZE → RESOLVE → CONFIRM are components of the Schneider Axiom Institute Business Constraint Discipline™.

Independent External Scholarship

External literature provides intellectual context involving task-technology fit, socio-technical systems, process innovation, sunk-cost effects, implementation, and organizational fit. It does not independently validate the SAI Business Constraint Discipline™.

SAI Proposition / Interpretation

The proposition that technology selection should follow disciplined examination of the business condition being addressed is an SAI interpretation informed by practitioner experience, diagnostic reasoning, and related scholarship.

Independent Validation

This paper does not claim independent validation that the SAI Business Constraint Discipline™, its technology-fit interpretation, or SAI diagnostic instruments produce superior technology or organizational outcomes.

References

Arkes, H. R., & Blumer, C. (1985). The psychology of sunk cost. Organizational Behavior and Human Decision Processes, 35(1), 124–140.

Davenport, T. H. (1993). Process Innovation: Reengineering Work through Information Technology. Harvard Business School Press.

Goodhue, D. L., & Thompson, R. L. (1995). Task-technology fit and individual performance. MIS Quarterly, 19(2), 213–236.

Trist, E. L., & Bamforth, K. W. (1951). Some social and psychological consequences of the longwall method of coal-getting. Human Relations, 4(1), 3–38.

Related SAI Resources

The SAI Business Constraint Discipline™

A structured approach to identifying what appears to be limiting organizational performance, determining what deserves priority, resolving the priority condition, and confirming whether improvement occurred.

The Seven Classes of Business Constraint™

Market · Operational · Financial · Organizational · Strategic · Leadership · Credibility

Business Constraint Diagnostic™

An SAI diagnostic resource designed to support identification of a probable governing constraint class and the structural condition within that class that appears to be limiting performance.

The Solution Was Right. The Diagnosis Was Wrong.

A companion White Paper examining how technically sound interventions can improve a real problem while missing the condition that actually deserves priority.

The People Were Not the Bottleneck — The Work Was Taking the Wrong Route

A companion White Paper examining how the route through which work moves can limit performance even when employees are working hard.

The Process That Nobody Owns

A companion White Paper examining why unclear end-to-end accountability can create recurring gaps across functions and handoffs.

SAI Credential Programs

Programs designed to develop structured diagnostic capability for business owners, executives, advisors, and consultants.

These resources are supplementary.

The intellectual argument in this White Paper stands independently of any purchase or enrollment.

Lawrence M. Schneider

Founder & CEO
Schneider Axiom Institute™

Lawrence M. Schneider brings more than five decades of CEO-level operating experience across manufacturing, distribution, construction, land development, franchising, and multi-entity businesses.

Schneider Axiom Institute develops and teaches the Business Constraint Discipline™—a structured approach to identifying what is limiting organizational performance, determining what deserves priority, resolving the priority condition, and confirming whether improvement occurred.