News & Insights
How IT Service Management Improves Uptime and Experience in Malaysia
IT service management in Malaysia is the discipline of running technology as a set of defined, measured services rather than a string of one-off fixes, and it is what separates a team that reacts to outages from one that prevents them. This explainer sets out the four processes at the centre of ITSM (incident, problem, change and service request management), how each one moves uptime and user experience, and a practical way to start maturing a practice that is currently ad hoc. Strateq delivers ITSM as a named service, so this is written from that operating position.
Nothing here depends on which platform or provider runs it. The processes and the maturity model below apply whether the ticketing system is ServiceNow, Freshservice, Jira Service Management, or something built in-house.
ITSM and ITIL: What the Terms Actually Mean
IT service management (ITSM) is the practice of designing, delivering, managing and improving how IT services are provided to an organisation’s users. It is the discipline, not a product.
ITIL, the IT Infrastructure Library, is the most widely adopted framework for doing ITSM, now in its fourth version. It is guidance, not a certification a company holds. ISO/IEC 20000-1:2018 is different: it is the international standard for IT service management systems, and it specifies the actual requirements an organisation is audited against to be certified. A provider can follow ITIL loosely while holding no certification at all, so if certification matters to you, ask for the standard by name rather than the framework.
The 4 Core Processes of ITSM
- Incident management: Restoring a service that has failed or degraded, as fast as possible, even before the root cause is known. This is triage, not diagnosis.
- Problem management: Finding and removing the underlying cause of incidents, including recurring ones that keep generating the same ticket under a different number.
- Change management: Assessing, approving and scheduling changes to the IT environment so that the fix for one problem does not become the cause of the next incident.
- Service request management: Handling routine, pre-approved requests, such as a new laptop or an access change, through a defined path instead of an ad hoc favour asked of whoever is free.
Each process solves a different failure mode. A team with strong incident management but no problem management gets fast at firefighting and never reduces the number of fires.
How Each Process Moves Uptime and Experience
The connection between process and outcome is direct, not aspirational.
| Process | What breaks without it | Outcome it drives |
|---|---|---|
| Incident management | Outages run longer because nobody owns the restoration, and users find out from each other instead of a status page | Shorter time to restore service |
| Problem management | The same incident recurs every few weeks because nobody was ever tasked with the root cause | Fewer repeat incidents, so uptime compounds over time |
| Change management | Unreviewed changes cause a share of outages themselves, at an unpredictable time nobody planned for | Fewer self-inflicted incidents |
| Service request management | Routine requests queue behind emergencies indefinitely, with no visibility into how long a “quick favour” will actually take | Predictable turnaround, which is most of what user satisfaction is measured on day-to-day |
User experience, in an ITSM context, is mostly this: knowing what is happening, and knowing how long it will take. A defined process produces both, even before it produces a faster resolution.
Maturing IT Service Management in Malaysia: 4 Stages
Most organisations do not move from nothing to a fully automated practice in one step. Four stages, in order:
- Ad hoc: Requests and incidents arrive by whatever channel is fastest- chat, email, a phone call- and get resolved by whoever picks it up. Nothing is measured because nothing is logged consistently.
- Defined: Incident, problem, change and service request management exist as named, documented workflows with an owner each, and every request or incident goes through a single intake channel instead of a personal one.
- Measured: Time to restore, time to resolve, and request turnaround are tracked against a target, and the numbers are reviewed, not just collected.
- Automated: Routine classification, routing and even some resolution steps run without a person triggering each one, freeing the team for the incidents and problems that actually need judgement.
Skipping a stage does not work. Automating a process nobody has defined just automates the inconsistency.
5 Things to Check in Any ITSM Platform
The platform is secondary to the process, but a platform that fights the process undoes months of process work. Five things to check before choosing one, or before accepting whichever tool the current IT team already has:
- Single system of record: Every incident, problem, change and service request is logged in one place, not split across a ticketing tool, a shared inbox and a spreadsheet that only one person updates.
- Workflow automation: Routine classification, routing and status updates run without a person triggering each step, so headcount does not have to grow at the same rate as ticket volume.
- Integration with monitoring tools: An alert from a monitoring system creates an incident automatically, rather than waiting for a user to notice and report it first.
- Self-service and a knowledge base: Users can raise a request or check ticket status themselves, and can often resolve a routine issue from a knowledge article before a ticket is needed at all.
- Reporting against a target, not just activity: The platform tracks time to restore and turnaround against a defined target, not just a count of tickets closed.
A platform missing most of these can still support a young practice. It becomes the constraint once that practice tries to measure and automate its own performance.
4 Reasons ITSM Efforts Stall
ITSM programmes rarely fail because the framework was wrong. They fail for operational reasons that are avoidable once named.
- No named process owner: A process without a named owner has no one accountable when it stops being followed, so it quietly reverts to whoever is available that day.
- Tooling bought before the process is defined: A platform configured around undocumented habits automates the inconsistency instead of removing it, and the licence cost buys very little.
- Treated as an IT-only initiative: Change and service request management touch every department that raises a request or asks for a change, so a process designed without their input gets worked around rather than followed.
- Success measured by volume, not outcome: Counting tickets closed rewards speed of closure, not whether the same incident stops recurring, and a team manages to whichever number is being watched.
Each of these is a process failure, not a technology failure, and each is fixed the same way: name an owner, document the process, then choose or configure a platform around it.
Where Are You Today? A Quick Self-Assessment
Answer these six questions honestly before choosing where to invest first.
- Do incidents and requests arrive through one defined channel, or however the user can reach someone?
- When an incident closes, does anyone check whether the same one has happened before?
- Are changes to the IT environment reviewed before they go live, or applied directly by whoever made them?
- Do you know your current average time to restore a service, or would you have to guess?
- Do routine requests, such as a new laptop or an access change, move through a defined path, or does someone have to know who to ask?
- Is there one system of record for every incident and request, or do some still arrive by chat and email outside it?
Two or more “no” answers mean the basics- a single intake channel, a system of record, and review of both root causes and changes- are not yet in place. That is where to invest before automation is worth discussing at all.
Where Strateq Fits
Strateq has delivered enterprise IT in Malaysia since 1983, and ITSM & Automation is a named platform pillar within its wider enterprise infrastructure practice, not a bolt-on service.
Strateq’s own ITSM practice is certified to ISO/IEC 20000-1:2018, the international standard for IT service management systems, and is delivered on the ServiceNow platform with support from the ServiceNow AI Centre of Excellence and close collaboration with the ServiceNow Impact Squad. That pairing of a certified management system with a named platform is what a measured, automated service management practice looks like in production, rather than in theory.
Reach out to Strateq’s ITSM team to talk through how each of these four stages is delivered in practice.