This article was originally published in Greek in Netweek magazine (June 2026). Author: Panagiotis Mastrogiannis, Board Member, itSMF Hellas.
Five questions that reveal whether your service management is solving IT’s problems or the business’s problems. The answer usually stings.
BY PANAGIOTIS MASTROGIANNIS, BOARD MEMBER, ITSMF HELLAS
Your ITSM is probably built backwards. You’ve optimised things for IT’s comfort, not business outcomes. And you’re not alone — most Greek companies have done exactly the same thing. Here’s how you tell.
A manufacturing company in Thessaly spent three years building a flawless change management process. Perfect governance. Every change documented, risk-assessed, planned well in advance. Thirty-day change windows. Predictable, controlled, safe for IT operations.
Then their biggest customer asked for a feature enhancement. Three-week turnaround. The company’s ITSM said no. The process didn’t allow it. The customer left. Six months later, IT was celebrating its flawless change record while the business bled revenue.
The question isn’t whether you have ITSM. You do. The question is: who does it serve?
Five Questions
1: When a business unit needs something fast, does your change process slow it down or empower it? If your answer is “we have a fast-track process,” you’re admitting the default process is designed for IT’s comfort, not business speed. Your process should be risk-calibrated, not time-calibrated. A low-risk change should move in days. A high-risk change may need more time. But the starting point doesn’t change: what does the business need?
2: Do your incident priorities align with business impact or IT’s workload? If Priority One means “lots of tickets are coming in” or “senior IT management is annoyed,” you’re measuring the wrong thing. Business-aligned priorities measure impact on revenue, customers, operational risk. An email outage affecting five hundred customers is priority one because the business is bleeding, not because IT is inconvenienced. A vague database alert affecting no one should be low priority, even if it’s technically “critical.”
3: Who owns SLAs — IT or the business? If IT owns the SLAs, you’re protecting IT. If the business owns them, you’re protecting customers and revenue. A business-owned SLA says “our customers get a response within four hours.” An IT-owned SLA says “our team responds within four hours.” One commits to an outcome. The other commits to an effort.
4: When you measure ITSM success, do you measure activity or impact? Ticket closure rates, process compliance, governance checkboxes — those are activity metrics. They feel good because they’re easy to measure. But they’re backwards. A business-aligned metric asks: did this ITSM practice reduce downtime? Did it speed up time-to-market? Did it lower total cost of ownership? Did it free IT to focus on strategy instead of firefighting? If you can’t answer these questions, your ITSM is measuring the wrong thing.
5: How much of your ITSM’s complexity exists because IT needs it? Most service management frameworks carry layers of process that exist purely because “best practice says so” or “we’ve always done it this way.” Twelve-person change advisory boards when decisions need three. Ticket categorisation so granular users don’t know which box to pick. All of this is friction. It slows the business. It frustrates IT. And it exists because no one asked whether the business actually needed it.
The Cost of Getting It Wrong
Your competitors aren’t building ITSM for IT. They’re building it for the market — risk-calibrated, outcome-focused, ruthlessly simple. They use service management as a competitive weapon, not a safety harness for IT operations. The uncomfortable truth: if your ITSM still feels heavy, bureaucratic, or slow for the business, it’s because it was designed by IT, for IT. And fixing that is leadership’s responsibility.
In upcoming articles, we’ll talk about how. Stay tuned.