Managed IT Keeps the Laptops On. Managed Technical Operations Keeps the Systems Agreeing. Buy the One You Are Missing.
Updated: 3 days ago
A company of sixty people has a managed IT provider. The laptops work. The network works. New starters get accounts on day one, the backups run, the phishing training is done, the tickets are answered within the hour. By every measure in the contract, IT is handled.
The same company has a CRM, an accounting system, an inventory or project tool, a help desk and a shop, and last Tuesday the invoice feed from the CRM to accounting stopped, and nobody noticed until month-end. The managed IT provider was not asked and would not have known. It is not in the contract, and it should not be, because it is a different service. This post is about the difference, and about how to tell which of the two you are missing.
What managed IT is accountable for.
Managed IT, as the industry sells it and as we described it when we wrote about what IT managed services are, is accountable for the infrastructure a business runs on: devices, networks, identity, email, backup, security, licences and the help desk for all of that. Its unit of work is a user, a device or a ticket. Its scope ends at the login screen, and a good provider will tell you so.
That scope is the right one for that service. Nobody wants the person patching the firewall to also be the person deciding which system is the master for the customer record. But the line has a consequence that most companies discover late: everything on the far side of the login screen, the business applications and the joins between them, has no owner.
What sits on the far side of the login screen.
A mid-market company runs somewhere between six and twenty business applications. Each one was bought by a department for a reason. Each one was configured by whoever set it up, some by a partner, some by a person who has since left. Between them are joins: the shop sends orders to the inventory system, the CRM sends won deals to accounting, the help desk reads the CRM, payroll reads the time tracker, the bank feeds the ledger.
The joins are where the company actually runs. When they work, one fact typed once appears everywhere it should. When they break, and they break because a vendor changed an interface, a field was renamed, a token expired, a record arrived in a shape nobody expected, the fact stops travelling and people start retyping it, or worse, stop noticing it is missing.
Ask who is accountable for the joins and the answer, in most companies, is a list of people who touched them. The IT provider does not own them. The application vendors each own their own side. The partner who built one of them two years ago is on a project basis. The operations manager who understands three of them is not a technical person and did not ask for the job.
What managed technical operations is accountable for.
Managed technical operations is the service that owns the far side of the login screen: the business applications as configured, the joins between them, and the fact that they agree. Its unit of work is not a ticket. It is a system that stays correct.
In practice it is five things.
A named owner for every join. Each integration has a person accountable for it, a document that says what it carries and which system is the master, and a monitor that says whether it ran. A join that fails at two in the morning is known by seven.
Changes made with a read-back. Every change to a configuration or a join is written down before it is made, made, and read back afterwards, so that the state of the system is always the state in the document. This is the discipline that separates operations from heroics.
A plan, reviewed monthly. The service carries a written list of what will be improved next: a join to build, a manual step to remove, a report to make real. We give every retainer client a project plan because a retainer without one is a phone number, and a phone number optimises for being called.
Vendor changes absorbed before they land. Application vendors change interfaces, retire features and move fields on their own schedules. Someone reads the release notes and tests the joins before the change arrives rather than after the month-end that finds it.
An escalation path to design. When a join keeps breaking because two systems disagree about what a record is, the fix is a design decision, not a patch, and the service has a path to someone who makes those; for the companies we work with, that is the fractional CTO whose job is exactly that decision.
How to tell which one you are missing.
Most companies have one and need the other, and a few have neither. Here is the test, and it takes five minutes.
Ask when a laptop last failed, and how long it took to fix. If the answer is a number of hours and a ticket reference, managed IT is in place. If the answer is a story, it is not.
Then ask when a join last failed, and how it was found. If the answer is a monitor and a named person, managed technical operations is in place. If the answer is month-end, or a customer, or a story, it is not. Most companies fail the second question and pass the first, because managed IT is a mature market with a clear scope and managed technical operations is a service most companies have never been offered.
The two are not substitutes. A managed IT provider asked to own the joins will decline, or will accept and do it as tickets, which means fixing each break after it breaks. A technical operations provider asked to patch laptops will point you to a managed IT provider. Buy both, from providers who each know where their line is, and make sure the line is written down.
Where it fits with the project work.
Managed technical operations is what happens after the joins are built. The building is a project; we wrote about it as systems integration for a small business. The project has a scope and a guaranteed estimate and ends. The operations do not end, because the vendors keep changing and the business keeps changing, and a set of joins that nobody owns degrades in a year to the state the project was commissioned to fix.
So the sequence, for a company that has neither, is discovery, then the project that builds or repairs the joins, then the service that keeps them correct. For a company that has the joins and no owner, it is the service alone, starting with an inventory of what exists. For a company with a managed IT provider and the second question unanswered, it is the service alongside the provider, with the line between them on paper.
What we are accountable for.
We do not own your systems or your processes; you do. We are accountable for every join having an owner, a document and a monitor; for every change being read back; for the monthly plan making progress; for vendor changes being absorbed before they land; and for saying plainly when a repeated failure is a design problem that needs a decision rather than another patch. That is managed technical operations as we deliver it, and it is a different service from the one that keeps the laptops on.
The short version.
Managed IT owns everything up to the login screen and does it well. Nobody owns the business applications and the joins between them unless someone is hired to. Managed technical operations is that service: a named owner for every join, changes with a read-back, a monthly plan, vendor changes absorbed early, and a path to design when a patch is not the answer. Ask when a join last failed and how you found out. The answer tells you which service you are missing.
Find out what one connected Zoho system would change in the way you run.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments