ITOps

WHAT IT IS ITOps is the operation of information technology as a service to the wider organisation: a route for people to ask for help, a defined way requests are fulfilled, and the change, incident and problem processes that keep enterprise systems dependable. It is the discipline most directly descended from IT service management frameworks. **Not this:** ITOps is not SysOps: it owns the service relationship with the organisation — intake, prioritisation, change control and service levels — not the hands-on administration of the machines that deliver it. WHY IT EXISTS Every organisation past a certain size depends on systems that are nobody's product: identity, email, endpoints, finance systems, the network in the building. Without an operating discipline these are supported by whoever knows how, requests arrive through personal messages, and no one can say whether service is getting better or worse. ITOps exists to give that work a front door, a queue and a measurement. WHEN TO USE IT Adopt it when requests arrive by tapping someone on the shoulder, when nobody can say how long a laptop request takes, or when a change to a shared enterprise system surprised the people who depend on it. It applies whether or not the organisation builds software. WHO OWNS IT An IT or internal services function owns the processes and the service desk. Service owners own individual enterprise systems and the change decisions about them. Senior management owns the service levels, because a target nobody funded is a wish. Where the same organisation runs product infrastructure, keep the boundary explicit — applying enterprise change control to product deployment pipelines is a well-documented way to make both worse. WHAT GOOD LOOKS LIKE There is one discoverable way to ask for help and it is used. Requests have categories and stated expectations, and attainment against them is measured and published. Changes to shared systems are recorded, assessed proportionately, and communicated to those affected. Incidents and problems are distinguished — recurring incidents trigger problem investigation rather than repeated restoration. A service catalogue and asset inventory exist and are current enough to be trusted. HOW TO IMPLEMENT Establish the single intake route first and insist on it, including for senior people, because an exception culture makes measurement meaningless. Categorise requests and publish realistic expectations rather than aspirational ones. Record changes to shared systems with a lightweight assessment proportionate to risk. Separate incident restoration from problem investigation so recurring failures get root-cause attention. Build the asset inventory incrementally. Keep the process proportionate — heavy ITSM ceremony applied to a twenty-person company is the classic failure of this discipline. The security side of enterprise change belongs with /secops. HOW TO ASSESS YOURSELF Ask how someone in finance gets help and whether that route is the same one everyone uses. Ask how long the last ten requests of one type took. Ask whether last quarter's repeated failure got a problem investigation or ten restorations. Take the scored self-assessment at /assess and plan with /roadmaps.