Who Owns the System? (Hint: It's Usually Not IT)

What you'll learn

Match each big system to the department that actually owns it
Tell the business owner apart from the admin, the identity team, and the vendor
Know who to ask when something's wrong — and stop routing everything to IT

A report on your dashboard has shown the wrong sales region for a week. You do the obvious thing: raise a ticket with IT. Three days later it bounces back — “this isn’t an IT issue, please contact Sales Operations.” You didn’t even know Sales Operations existed. It turns out IT keeps the lights on, but the rule that decides which region a deal belongs to was set by someone in Sales. You spent three days asking the wrong door for a key it never had.

The myth: “IT owns everything”

It feels like IT owns all the software, because IT is who you email when a screen freezes. But in a real company, ownership is split by department, and IT owns a surprisingly small slice of it. The pattern is remarkably consistent across companies. Sales, usually through a team called Sales Operations (Sales Ops), owns the CRM — the customer system, Salesforce being the famous example. Finance, Operations and Supply Chain jointly own the ERP, the money-and-materials system like SAP. HR owns the HRIS, the people system such as Workday. IT owns and administers the ITSM platform — the ticket tool like ServiceNow — mostly because that one is IT’s own workbench.

Then there are the systems nobody “uses” but everybody depends on. A Security or Identity team runs the access layer — SSO (single sign-on, one login for many apps) and MFA (multi-factor authentication, the code on your phone). Data teams don’t own these systems; they consume data from all of them to build reports. And behind every product sits a vendor — the outside company that makes the software and provides support. So “who owns it” has a lot of possible answers, and IT is only one of them.

The business side and the technical side

Here’s the split that untangles almost everything: every system has a business side and a technical side. The business side owns the process and the decisions — what the system is for, what the rules are, what “done” looks like, and the budget that pays for it. The technical side configures it, integrates it with other systems, and keeps it running. Sales Ops decides the forecast should group deals by region (business side); an administrator adds the field that makes that possible (technical side); an integration engineer wires the CRM to the ERP so orders flow through (technical side, too).

Why does this matter to you? Because who owns a thing decides who you go to for a change — and asking the wrong side wastes weeks. A pricing rule is a business decision; no amount of IT effort will change it without the business owner’s sign-off. A broken login is a technical access problem; the business owner can’t help you at all. Knowing the split means your very first email lands on the right desk.

The roles that matter

Business owner: The person who owns the process, the outcomes, and the budget for a system — they decide what it’s for.
Product owner: Prioritizes what gets built or changed next — they decide the order of the to-do list.
System administrator: Handles day-to-day config, users, and access — the go-to for a settings or field change.
Technical owner: Owns the integrations, upgrades, and the plumbing that keeps a system connected and current.
Data owner: Also called a data steward — accountable for what a dataset means and whether it’s accurate.
Vendor: The outside company that makes the software and provides support — the one who fixes actual bugs.
End user: You, using the system to get a job done.

A Tuesday in the life of a broken report

Priya, three weeks into a marketing analyst job, notices the pipeline report shows deals under the wrong owner. Her instinct is to escalate to IT. Instead she asks a colleague, “who owns this report?” The answer routes her perfectly. The grouping rule is wrong on purpose-someone-forgot — that’s a business owner call, so Sales Ops signs off on the fix. The field that stores the owner needs a tweak — that’s a system administrator job. Two of her teammates couldn’t even open the report — that was an access problem for the identity team. And the export button that crashes every single time, for everyone? That’s a genuine bug, logged with the vendor. One symptom, four different owners. Priya solved in an afternoon what a single mis-routed ticket would have dragged out for a month.

Each system answers upward to a business owner and downward to the people who keep it running — and Security decides who gets in at all.

Text description of this diagram

The map has three stacked layers plus a band underneath. The top layer is the business owners — Sales / Sales Ops, Finance / Supply Chain, HR, and IT — the departments that own the decisions and the budget. Each one connects straight down to its system in the middle layer: Sales Ops to the CRM (e.g. Salesforce), Finance and Supply Chain to the ERP (e.g. SAP), HR to the HRIS (e.g. Workday), and IT to the ITSM tool (e.g. ServiceNow). Each system then connects down to a single wide “shared technical & admin layer” — the admins, integrations and upgrades that keep every system running. Beneath all of it, one band labelled Security / Identity spans the full width: SSO and MFA control who is allowed into any of the four systems. Green dots travel down from owners to systems; blue dots travel from systems to the shared technical layer — showing that a change flows from the business decision at the top to the technical work at the bottom.

Sort it: who owns what?

Drag each item into the team that owns it — or tap an item, then tap a bucket. Hit Check placement when you’re done.

Sales Opscustomers & pipeline

Finance / Supply Chainmoney & materials

HRpeople

IT & Identitytickets & access

Tip: drag with a mouse, or tap an item then tap a bucket on touch screens. Get one wrong and the answer key appears.

Spot it: who do you go to?

Read each problem, decide who owns the fix, then tap a card to check.

Common misunderstanding

“Any system problem? Raise it with IT.” IT is the right door for a crash, a login you can’t reach, or a device that won’t behave — but a huge share of “system problems” are actually decisions (the business owner), settings (the admin), or access (the identity team). Route everything to IT and you’ll get a lot of tickets bounced back with “not our system.” Ask “is this a decision, a setting, an access issue, or a bug?” first, and your request lands on the right desk the first time.

Quick check

1. You want the sales dashboard to calculate commission by a new rule. Who owns that decision?

2. After a reorg, a whole team can't log into any app. Who most likely fixes it?

3. The app crashes with the identical error for every customer, not just yours. Who ultimately fixes it?

Answers explained

B is correct — changing how commission is calculated is a business rule, and the business owner (Sales Ops here) owns those rules and the budget behind them. (If you picked A: IT might do the technical work, but only after the owner decides what the rule should be. If you picked C: the vendor builds the software, not your company’s specific pay rules.)
A is correct — “nobody can get in” is almost always an access problem, and access lives with the Security / Identity team who run SSO and MFA. (If you picked B: the business owner decides what the system does, not who’s allowed to log in. If you picked C: a login failure after a reorg is permissions, not a software defect.)
C is correct — the same error for every customer means the defect is in the product itself, so the vendor has to patch it. (If you picked A: an admin can configure your copy but can’t rewrite the vendor’s code. If you picked B: the data steward owns what data means, not whether the app crashes.)

Try this at work

Pick one system you use daily and find out, this week, who its business owner is and who its administrator is — a colleague or your manager will usually know. Next time something’s off, you’ll already know which door to knock on before you write a single ticket.

Key takeaway

Before you report a system problem, decide whether it’s a decision, a setting, an access issue, or a bug — that tells you whether to go to the business owner, the admin, the identity team, or the vendor.

Why it matters

Back in module 1 you learned that whoever owns the system of record wins arguments — this lesson tells you who that owner actually is. The four big systems you’ve met across the course each answer to a department, not to IT: the CRM to Sales, the ERP to Finance and Supply Chain, the HRIS to HR, the ITSM tool to IT itself, with Security holding the keys to all of them. Once you can see the split between the business side that owns the decisions and the technical side that keeps the plumbing running, you stop wasting weeks on bounced tickets and mis-aimed emails. You walk straight to the person who can actually say yes. In a company held together by dozens of systems, knowing who owns each one is quietly one of the most useful maps you can carry.