By Kunal Sancheti | Director, Comprint Tech Solutions
A familiar problem in enterprise IT begins with an apparently reasonable answer: “That falls outside our scope.”
The supplier delivered what was ordered. The deployment team completed the installation. The support provider met its contractual obligations. Yet the business still has a problem, and someone inside the organisation must reconstruct how it happened and decide who should resolve it.
In my view, this exposes a weakness in how we manage enterprise hardware. We assign responsibility for individual activities far more clearly than we assign responsibility for what happens between them.
An asset may be accounted for financially, covered by a maintenance contract and listed in an inventory. None ofthose things, on its own, establishes who is accountable for its useful life.
When every stage makes sense in isolation
Consider the journey of a server. It is specified and purchased against a business requirement, configured for a particular environment, maintained through several years of operation, perhaps upgraded or reassigned, and eventually retired.
Each decision can be perfectly reasonable when it is made. Procurement secures a competitive price. The deployment team works towards a deadline. Support restores service when something fails. A business unit requests more capacity. Finance questions the replacement budget.
The difficulty is that these decisions depend on one another. A configuration change during deployment can affect later troubleshooting. A repair history can influence whether an upgrade is worthwhile. A change in workload can alter when replacement becomes sensible.
When the records and reasoning behind those decisions fail to travel with the asset, the next team inherits the equipment without its full history.
The information lost between responsibilities
The consequences can remain hidden while equipment is working. They become visible when someone asks a question that crosses several functions: Why is this machine underperforming? Has this component failed before? Can we safely extend its service life? What evidence will confirm that its data has been dealt with when it leaves?
An invoice establishes what was purchased. An inventory establishes what is recorded. A closed service ticket establishes that an incident was addressed. Answering a lifecycle question requires those records to connect.
Without that connection, organisations repeatedly pay to rediscover what they once knew. Engineers reconstruct configurations. Managers revisit earlier decisions without understanding their assumptions. Replacement proposals proceed without a complete view of condition or repair history. I believe this loss of continuity deserves more attention in vendor and infrastructure reviews. It affects the quality of decisions long before it appears as a visible failure.
Accountability cannot be inferred from vendor count
It is tempting to treat this as a supplier consolidation problem. Fewer providers may simplify coordination, but the number ofcontracts does not tell us whether responsibility is clear.
A single provider can have disconnected teams, separate systems and subcontractors. Several specialist providers can work effectively when the enterprise defines ownership, maintains accessible records and makes handovers explicit.
The important question is whether someone remains answerable when an issue crosses a boundary.
That requires a named owner within the enterprise, with the authority to coordinate the relevant functions. This person need not approve every repair or maintain every record. Their responsibility is to ensure that the assetʼs history remains usable, decisions have an identifiable owner and unresolved issues do not disappear between contracts.
External providers can carry substantial delivery responsibility. The enterprise still needs to own the business outcome.
Make continuity part of the work
In practical terms, I would start by treating a handover as a deliverable. Deployment should leave behind an accepted record of what was installed and changed. Support should update the history when repairs or modifications occur. An upgrade or replacement recommendation should explain the condition, workload needs and costs on which it rests.
Where a supplier also benefits from selling the replacement, that reasoning should be open to scrutiny. A recommendation becomes useful when the customer can examine its basis.
Retirement needs the same discipline. Moving equipment out of the building should close a documented process covering asset identity, custody, data sanitisation and final disposition.
These records must remain accessible to the enterprise when personnel or providers change. A history that cannot be retrieved or transferred offers little continuity. At our company, we help customers with procurement, support, upgrades, refurbishment and retirement. Working across these stages shapes my view ofwhat useful lifecycle support should deliver: recommendations that connect an assetʼs history with the customerʼs next requirement. The real test is whether the customer has a clearer basis for deciding what to retain, repair, repurpose or replace.
Ask the question before the failure
This does not require an immediate overhaul of the vendor list. It requires a closer look at how responsibility works today.
Choose one asset that has been in service for several years. Can the organisation explain why it was configured as it was, what has changed, how it has performed and who will decide its next step?
If answering depends on locating a former employee or piecing together several suppliersʼ accounts, the gap already exists.
Every enterprise asset has a continuous life. Our responsibility for it should be equally continuous.