RTDC

Operating ICT Systems Through Structured Service Management

Commissioning is not the end of an ICT system’s lifecycle. After go-live we monitor infrastructure, manage incidents, perform preventive maintenance, control changes and maintain asset and configuration records throughout the operating period.

Technician working inside a communications cabinet with orange and white fibre cabling

Beyond go-live

After go-live:

  • User volumes change
  • Applications evolve
  • Security vulnerabilities emerge
  • Equipment fails
  • Software versions age
  • Storage consumption grows
  • Network patterns change
  • Integration dependencies increase
  • Support arrangements change
  • Technology reaches end of life

Our managed operations framework is designed to maintain performance throughout the system lifecycle. After go-live we maintain visibility across infrastructure, applications and devices through monitoring, incident management, preventive maintenance, configuration control, field support and lifecycle planning.

The framework includes:

  • Monitoring
  • Incident handling
  • Preventive maintenance
  • Capacity management
  • Configuration control
  • Security update coordination
  • Asset tracking
  • Root-cause analysis
  • Field support
  • Spares management
  • Upgrade planning
  • Obsolescence management

Our role is to ensure that different technologies, vendors, applications, locations and operational teams function as one coherent system.

Incident, problem and change managementThree connected processes. Incident management detects, logs, assesses, prioritises, diagnoses, escalates, restores, validates and closes. Recurring incidents pass to problem management: trend analysis, root-cause analysis, known-error records, corrective and preventive action, and engineering change. Engineering changes pass through change management: request, assess, approve, schedule, test, implement, validate and document, with back-out to the previous state where needed. Asset records, spares, field support, preventive maintenance and reporting underpin all three.Incident management: restore serviceDetectLogAssess impactPrioritiseDiagnoseEscalateRestoreValidateCloseRecurring incidents are treated as problemsTrend analysisRoot-cause analysisKnown-error recordCorrective andpreventive actionEngineering changeProblem management: remove underlying causesEngineering change is raised through change controlRequestAssessApproveScheduleTestImplementValidateDocumentChange management: controlled, reversible where necessaryBack out to previous stateUnderpinned by asset and configuration records, spares, field support, preventive maintenance and reporting
Incidents, problems and changes. Incident management restores service. Recurring incidents go to problem management, whose corrective actions pass through change management.

Operating processes

Nine processes make up the operating model. Each is defined before handover and documented in the runbooks the operations team receives.

Service desk

The service desk is the single point where events become tracked work, with an owner and a clock.

The service desk may provide:

  • Ticket registration
  • Classification
  • Prioritisation
  • Assignment
  • Escalation
  • Communication
  • Closure
  • Reporting

Incident management

An incident is closed when service is restored and validated. Diagnosing why it happened is the job of problem management.

Incident management should focus on restoration of service. It should include:

  • Detection
  • Logging
  • Impact assessment
  • Priority assignment
  • Technical diagnosis
  • Escalation
  • Restoration
  • Validation
  • Closure

Problem management

Repeated incidents are treated as evidence of an underlying cause. Root-cause analysis ends in corrective and preventive action, and sometimes an engineering change.

Problem management should identify underlying causes of recurring incidents. It may include:

  • Trend analysis
  • Root-cause analysis
  • Known-error records
  • Corrective action
  • Preventive action
  • Engineering change

Change management

Every change to a running system follows the same path, so the configuration record stays true and failed changes can be reversed.

Changes should be:

  • Requested
  • Assessed
  • Approved
  • Scheduled
  • Tested
  • Implemented
  • Validated
  • Documented
  • Reversible where necessary

Preventive maintenance

Scheduled inspection and review find degradation — dust, failing cables, ageing firmware, shrinking capacity — before it causes an outage.

Preventive maintenance may include:

  • Physical inspection
  • Cleaning
  • Power checks
  • Environmental checks
  • Cable checks
  • Device-health review
  • Firmware review
  • Log review
  • Capacity review
  • Backup review
  • Security update review
Racks with dense network cabling beside a floor-standing UPS power management module in a data centre

Asset management

The asset record answers what is installed, where, in what configuration, under what support, and when it must be replaced.

Asset management should maintain:

  • Equipment identity
  • Serial number
  • Location
  • Configuration
  • Warranty
  • Support status
  • Software version
  • Maintenance history
  • Replacement status
  • End-of-life date
Close view of rack-mounted servers with small status screens and labelled Ethernet cabling

Spares management

Spares policy is derived from which failures would stop service and how long a replacement would take to reach site.

Spares management should define:

  • Critical spares
  • Quantity
  • Storage location
  • Reorder level
  • Compatibility
  • Issue process
  • Return process
  • Repair process

Field support

Dispatch decisions weigh severity against distance, access, safety and whether the right spare is on the vehicle.

Field support should be organised around:

  • Fault severity
  • Location
  • Travel time
  • Technician availability
  • Access
  • Spare availability
  • Safety
  • Restoration target
  • Closure evidence

Reporting

Reports show how the system and the service are performing, and what is likely to need attention next.

Operational reporting may include:

  • Availability
  • Incident volume
  • Response time
  • Resolution time
  • Repeat incidents
  • Device health
  • Capacity
  • Preventive maintenance
  • Open risks
  • Changes
  • Asset status
Wall-mounted facility monitoring and alarm panels seen through a window in a data-centre monitoring room

Lifecycle and obsolescence

Operations is also where lifecycle planning is done. Asset records carry end-of-life dates, preventive maintenance records show equipment approaching the end of its useful life, capacity reviews show where growth will exceed current design, and security update reviews show where software is falling out of support. Together they let upgrades and replacements be planned ahead of failure, and feed the next assessment in the engineering lifecycle.

Monitoring and ObservabilityHow operational visibility is designedEdge and Field SystemsDesigning field equipment for maintainabilityAsset registersTechnical note on long-term operationsMaintainabilityTechnical note on field infrastructure

Discuss an operations and maintenance requirement

Describe the systems, locations and support period, and we will respond with the questions that shape the operating model.

Discuss an ICT Requirement