SlideShare a Scribd company logo
1 of 21
Download to read offline
SLM Series | Page—1
SLM Series | Page—2
“Any change of state that has significance for the management of IT
service” (ITIL – Information Technology Infrastructure Library)
“setiap perubahan status yang berdampak/tidak berdampak
terhadap layanan IT”
Event ada tiga:
• Informational  event yang tidak mengganggu layanan
• Warning  mungkin bisa menjadi trigger yang dapat mengganggu
layanan
• Exceptional  hampir dapat dipastikan merupakan sebuah trigger
yang mengganggu layanan
SLM Series | Page—3
“any event which is not part of the standard operation of a service
and which causes or may cause an interruption to, or a reduction
in, the quality of that service” (ITSM, 2007)
“setiap kejadian yang bukan bagian dari layanan operasional
standar yang menyebabkan atau berpotensi menyebabkan
interupsi/gangguan atau penurunan kualitas layanan”
“an unplanned disruption or degradation of service”
(ITIL – Information Technology Infrastructure Library)
“gangguan yang tidak direncanakan atau penurunan (kualitas)
layanan”
SLM Series | Page—4
“the cause of one or more incidents”
(ITIL – Information Technology Infrastructure Library)
“penyebab dari satu atau lebih insiden – suatu insiden
dapat pula disebabkan oleh masalah yang tak
terselesaikan”
The cause is not usually known at the time a Problem Record is created, and the
Problem Management Process is responsible for further investigation.
SLM Series | Page—5
Akar penyebab suatu masalah (root cause of the problem) dapat diketahui atau
tidak.
Tindakan yang harus diambil terhadap suatu masalah:
 Do nothing (tidak melakukan apa-apa)
Tindakan ini dipilih jika masalah tidak berpengaruh terhadap bisnis atau
biaya untuk memperbaiki masalah melebihi manfaat yang didapat
 Deploy work around (membuat solusi sementara)
Ini dipilih jika penentuan akar penyebab masalah melebihi manfaat yang di
dapat
 Determine root cause and fix the problem (menentukan akar
penyebab dan memperbaiki masalah)
Ini dipilih jika manfaat yang didapat melebihi biaya untuk memperbaiki
masalah atau masalah tersebut layak diperbaiki (worth it)
SLM Series | Page—6
• Kata kunci untuk ‘event’  perubahan status (Up to
Down, Active to Inactive)
• Kata kunci untuk ‘incident’ 
mengganggu, interupsi, tidak direncanakan
• Kata kunci untuk ‘problem’  kerusakan, akar
penyebab
Lantas GANGGUAN termasuk kategori yang mana?
Dari definisi yang ada, GANGGUAN lebih tepat atau
lebih dekat dengan „incident‟
SLM Series | Page—7
ProblemIncidentEvent
• Event yang bersifat informational bukanlah ‘incident’
• Setiap ‘problem’ belum tentu menjadi ‘incident’
• Setiap ‘incident’ pasti merupakan ‘problem’
Dalam operasional sehari-hari, istilah “incident/insiden” dan
“problem/masalah” sering kali dipertukarkan (interchangeably)
SLM Series | Page—8
Occurence Event Incident Problem
Server crash di jam kerja dan
mengganggu proses bisnis   
Server crash di luar jam kerja   
Pemeliharaan terencana
(schedule maintenance)   
Schedule outage melebihi
waktu yang direncanakan   
SLM Series | Page—9
• Availability (ketersediaan) adalah kemampuan untuk
menjalankan fungsi pada saat dibutuhkan atau untuk
menjalankan fungsi selama suatu periode waktu
tertentu
• Faktor penentu Availability:
• Reliability (keandalan)
• Maintainability (kemudahan pemeliharaan)
• Serviceability (kemudahan perbaikan)
SLM Series | Page—10
Availability
Reliability Maintainability
Serviceability
SLM Series | Page—11
MTBSI (Mean Time Between Service Incidents)
MTBF (Mean Time Between Failures)
MTRS (Mean Time to Restore Service)
(Agreed Service Time (AST) – Downtime)
Agreed Service Time (AST)
X 100 %Availability (%) =
Service time in hours
Number of breaks
Reliability (MTBSI in hours) =
Service time in hours – Total downtime in hours
Number of breaks
Reliability (MTBF in hours) =
Total downtime in hours
Number of breaks
Maintainability (MTRS in hours) =
SLM Series | Page—12
Sebuah penyedia layanan jaringan 24/7 telah beroperasi
selama 1 bulan (720 jam). Catatan pada Problem Record
menunjukkan bahwa jaringan telah mengalami gangguan
sebanyak dua kali (masing-masing selama 1 jam dan 2
jam), maka:
• Availability = ((720–(1+2)) / 720) x 100% = 99.58%
• Reliability (MTBSI) = 720 / 2 = 360 jam
• Reliability (MTBF) = (720–(1+2)) / 2 = 358,5 jam
• Maintainability (MTRS) = (1+2) / 2 = 1,5 jam
MTBSI (Mean Time Between Service Incidents)
MTBF (Mean Time Between Failures)
MTRS (Mean Time to Restore Service)
SLM Series | Page—13
• Detection time  NMS Red Icon
Waktu dimana penyedia layanan mengetahui/mendeteksi
adanya insiden
• Diagnosis time  1st Level Troubleshooting
Waktu dimana penyedia layanan melakukan diagnosis
untuk menentukan penyebab terjadinya insiden
• Repair time  Data Link Layer UP
Waktu yang diperlukan untuk memperbaiki insiden
• Recovery time  Network Routing UP
Waktu yang diperlukan untuk pemulihan insiden
• Restoration Point  Application UP
Titik dimana layanan bisnis normal kembali
Resolution time
SLM Series | Page—14
Tangible Cost Intangible Cost
Biaya perbaikan gangguan
(transport, man-days)
Penurunan reputasi perusahaan
Denda atau penalty dari customer karena
terganggunya layanan
Kehilangan kepercayaan customer
Penurunan pendapatan karena customer
berhenti berlangganan
Kehilangan kepercayaan strategic
partner (integrator, vendor)
Biaya perbaikan perangkat yang rusak Kehilangan peluang bisnis
Biaya lembur jika gangguan terjadi saat
after office hour
Penurunan kepercayaan diri dari front
liner (operator, field technician)
Tangible cost : biaya yang dapat diukur dengan jelas secara finansial
Intangible cost : biaya yang tidak dapat/sulit diukur secara finansial
Source: Bob Hardian, Availability Management (2011), telah diolah kembali
SLM Series | Page—15
• Semaikin tinggi Availability yang
diinginkan, semakin besar biaya
preventive maintenance dan
resilience yang dibutuhkan (kurva
logaritmik)
• Semakin tinggi
Availability, semakin kecil biaya
corrective maintenance yang
dibutuhkan (kurva linier)
• Total cost optimum dicapai untuk
Uptime/Availability 70%-85%
• Kebutuhan akan tingkat Availability
melebihi nilai optimum akan
membuat total cost naik secara
drastis atau signifikan
• Untuk mencapai Availability 99%
dibutuhkan biaya sekitar 10 kali
dari biaya optimum
Source: Bob Hardian, Availability Management (2011)
SLM Series | Page—16
Source: Kailash Jayaswal, Administering Data Centers: Servers, Storage, and Voice over IP (2006)
SLM Series | Page—17
Source: Kailash Jayaswal, Administering Data Centers: Servers, Storage, and Voice over IP (2006)
Server
software,
30%
Environment,
5%
Planned
downtime,
30%
People,
15%
Hardware,
10%
Network
software,
5%
Client
software,
5%
SLM Series | Page—18
• Untuk memastikan kinerja perangkat berjalan normal
maka harus dipastikan perangkat tersebut bekerja di
bawah ambang batas (threshold). Jika kapasitas
perangkat telah mencapai atau melebihi ambang
batas, maka solusi yang bisa dilakukan:
• Scaling Up
Melakukan penggantian dengan perangkat yang memiliki
kapasitas lebih besar.
• Scaling Out
Melakukan penambahan unit perangkat dengan kapasitas yang
sama (load-balancing, active-active redundancy, parallel run).
• Solusi Scaling Up atau Scaling Out yang dipilih bisa
berdasarkan CBA (Cost-Benefit Analysis)
SLM Series | Page—19
• Agar dapat kompetitif, pilihan infrastruktur untuk masa depan
haruslah memiliki sifat adaptif (Adaptive Infrastructure)
• Ciri infrastruktur adaptif
• Efisien
Tersedianya komponen yang dapat dimanfaatkan secara bersama
oleh berbagai sistem baik oleh sistem lama maupun sistem baru
• Efektif
Tersedianya komponen yang mudah dipadukan (interoperable) dan
diintegrasikan (integrated)
• Fleksibel (agile)
Tersedianya komponen yang mudah dirombak, di-upgrade atau diganti
• Adaptiveness dari infrastruktur diukur dari:
• Time to Market: kecepatan implementasi layanan baru
• Scalability: mampu mengakomodasi peningkatan penggunaan
• Extensibility: kemudahan penambahan komponen baru
SLM Series | Page—20
Contact us at: ins.saputra@gmail.com
Follow our : @SujanaSaputra

More Related Content

Similar to Service Level Management

Analisa software pembuatan perencanaan bisnis untuk persewaan aset
Analisa software pembuatan perencanaan bisnis untuk persewaan asetAnalisa software pembuatan perencanaan bisnis untuk persewaan aset
Analisa software pembuatan perencanaan bisnis untuk persewaan aset
JMMI ITS
 
Manajemen Operasi - Pemeliharaan
Manajemen Operasi - PemeliharaanManajemen Operasi - Pemeliharaan
Manajemen Operasi - Pemeliharaan
Resty Wahyu Pertiwi
 
Business Process Design in SOA
Business Process Design in SOABusiness Process Design in SOA
Business Process Design in SOA
Farid Er
 
DC Pengendalian Kualitas UTS 2023.pdf
DC Pengendalian Kualitas UTS 2023.pdfDC Pengendalian Kualitas UTS 2023.pdf
DC Pengendalian Kualitas UTS 2023.pdf
eerlangga26
 

Similar to Service Level Management (20)

Pemeliharaan dan Keandalan kelompok 4
Pemeliharaan dan Keandalan kelompok 4Pemeliharaan dan Keandalan kelompok 4
Pemeliharaan dan Keandalan kelompok 4
 
Pertemuan 13 14 manajemen pemeliharaan
Pertemuan 13 14 manajemen pemeliharaanPertemuan 13 14 manajemen pemeliharaan
Pertemuan 13 14 manajemen pemeliharaan
 
Piti 09-manajemen ketersediaan-infrastruktur_ti
Piti 09-manajemen ketersediaan-infrastruktur_tiPiti 09-manajemen ketersediaan-infrastruktur_ti
Piti 09-manajemen ketersediaan-infrastruktur_ti
 
2321118 presentation.ppt
2321118 presentation.ppt2321118 presentation.ppt
2321118 presentation.ppt
 
Analisa software pembuatan perencanaan bisnis untuk persewaan aset
Analisa software pembuatan perencanaan bisnis untuk persewaan asetAnalisa software pembuatan perencanaan bisnis untuk persewaan aset
Analisa software pembuatan perencanaan bisnis untuk persewaan aset
 
Manajemen operasi : Pemeliharaan dan Keandalan
Manajemen operasi : Pemeliharaan dan KeandalanManajemen operasi : Pemeliharaan dan Keandalan
Manajemen operasi : Pemeliharaan dan Keandalan
 
Pertemuan 07 strategi proses
Pertemuan 07 strategi prosesPertemuan 07 strategi proses
Pertemuan 07 strategi proses
 
KULIAH 3 . Koree
KULIAH 3 . KoreeKULIAH 3 . Koree
KULIAH 3 . Koree
 
Kelompok 2 bab 17
Kelompok 2 bab 17Kelompok 2 bab 17
Kelompok 2 bab 17
 
PerawatanSoftware_MM.ppt
PerawatanSoftware_MM.pptPerawatanSoftware_MM.ppt
PerawatanSoftware_MM.ppt
 
Keandalan sistem tenaga listrik
Keandalan sistem tenaga listrikKeandalan sistem tenaga listrik
Keandalan sistem tenaga listrik
 
Manajemen Operasi - Pemeliharaan
Manajemen Operasi - PemeliharaanManajemen Operasi - Pemeliharaan
Manajemen Operasi - Pemeliharaan
 
Maintenance Practices
Maintenance PracticesMaintenance Practices
Maintenance Practices
 
02-DRP-KUMHAM-2.1.pdf
02-DRP-KUMHAM-2.1.pdf02-DRP-KUMHAM-2.1.pdf
02-DRP-KUMHAM-2.1.pdf
 
Business Process Design in SOA
Business Process Design in SOABusiness Process Design in SOA
Business Process Design in SOA
 
DC Pengendalian Kualitas UTS 2023.pdf
DC Pengendalian Kualitas UTS 2023.pdfDC Pengendalian Kualitas UTS 2023.pdf
DC Pengendalian Kualitas UTS 2023.pdf
 
PRINSIP PELACAKAN KERUSAKAN.pptx
PRINSIP PELACAKAN KERUSAKAN.pptxPRINSIP PELACAKAN KERUSAKAN.pptx
PRINSIP PELACAKAN KERUSAKAN.pptx
 
Pengantar Pengendalian kualitas
Pengantar Pengendalian kualitasPengantar Pengendalian kualitas
Pengantar Pengendalian kualitas
 
Materi six sigma
Materi six sigmaMateri six sigma
Materi six sigma
 
PPT TUGAS TEKNIK KEANDALAN.pptx
PPT TUGAS TEKNIK KEANDALAN.pptxPPT TUGAS TEKNIK KEANDALAN.pptx
PPT TUGAS TEKNIK KEANDALAN.pptx
 

Service Level Management

  • 1.
  • 2. SLM Series | Page—1
  • 3. SLM Series | Page—2 “Any change of state that has significance for the management of IT service” (ITIL – Information Technology Infrastructure Library) “setiap perubahan status yang berdampak/tidak berdampak terhadap layanan IT” Event ada tiga: • Informational  event yang tidak mengganggu layanan • Warning  mungkin bisa menjadi trigger yang dapat mengganggu layanan • Exceptional  hampir dapat dipastikan merupakan sebuah trigger yang mengganggu layanan
  • 4. SLM Series | Page—3 “any event which is not part of the standard operation of a service and which causes or may cause an interruption to, or a reduction in, the quality of that service” (ITSM, 2007) “setiap kejadian yang bukan bagian dari layanan operasional standar yang menyebabkan atau berpotensi menyebabkan interupsi/gangguan atau penurunan kualitas layanan” “an unplanned disruption or degradation of service” (ITIL – Information Technology Infrastructure Library) “gangguan yang tidak direncanakan atau penurunan (kualitas) layanan”
  • 5. SLM Series | Page—4 “the cause of one or more incidents” (ITIL – Information Technology Infrastructure Library) “penyebab dari satu atau lebih insiden – suatu insiden dapat pula disebabkan oleh masalah yang tak terselesaikan” The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.
  • 6. SLM Series | Page—5 Akar penyebab suatu masalah (root cause of the problem) dapat diketahui atau tidak. Tindakan yang harus diambil terhadap suatu masalah:  Do nothing (tidak melakukan apa-apa) Tindakan ini dipilih jika masalah tidak berpengaruh terhadap bisnis atau biaya untuk memperbaiki masalah melebihi manfaat yang didapat  Deploy work around (membuat solusi sementara) Ini dipilih jika penentuan akar penyebab masalah melebihi manfaat yang di dapat  Determine root cause and fix the problem (menentukan akar penyebab dan memperbaiki masalah) Ini dipilih jika manfaat yang didapat melebihi biaya untuk memperbaiki masalah atau masalah tersebut layak diperbaiki (worth it)
  • 7. SLM Series | Page—6 • Kata kunci untuk ‘event’  perubahan status (Up to Down, Active to Inactive) • Kata kunci untuk ‘incident’  mengganggu, interupsi, tidak direncanakan • Kata kunci untuk ‘problem’  kerusakan, akar penyebab Lantas GANGGUAN termasuk kategori yang mana? Dari definisi yang ada, GANGGUAN lebih tepat atau lebih dekat dengan „incident‟
  • 8. SLM Series | Page—7 ProblemIncidentEvent • Event yang bersifat informational bukanlah ‘incident’ • Setiap ‘problem’ belum tentu menjadi ‘incident’ • Setiap ‘incident’ pasti merupakan ‘problem’ Dalam operasional sehari-hari, istilah “incident/insiden” dan “problem/masalah” sering kali dipertukarkan (interchangeably)
  • 9. SLM Series | Page—8 Occurence Event Incident Problem Server crash di jam kerja dan mengganggu proses bisnis    Server crash di luar jam kerja    Pemeliharaan terencana (schedule maintenance)    Schedule outage melebihi waktu yang direncanakan   
  • 10. SLM Series | Page—9 • Availability (ketersediaan) adalah kemampuan untuk menjalankan fungsi pada saat dibutuhkan atau untuk menjalankan fungsi selama suatu periode waktu tertentu • Faktor penentu Availability: • Reliability (keandalan) • Maintainability (kemudahan pemeliharaan) • Serviceability (kemudahan perbaikan)
  • 11. SLM Series | Page—10 Availability Reliability Maintainability Serviceability
  • 12. SLM Series | Page—11 MTBSI (Mean Time Between Service Incidents) MTBF (Mean Time Between Failures) MTRS (Mean Time to Restore Service) (Agreed Service Time (AST) – Downtime) Agreed Service Time (AST) X 100 %Availability (%) = Service time in hours Number of breaks Reliability (MTBSI in hours) = Service time in hours – Total downtime in hours Number of breaks Reliability (MTBF in hours) = Total downtime in hours Number of breaks Maintainability (MTRS in hours) =
  • 13. SLM Series | Page—12 Sebuah penyedia layanan jaringan 24/7 telah beroperasi selama 1 bulan (720 jam). Catatan pada Problem Record menunjukkan bahwa jaringan telah mengalami gangguan sebanyak dua kali (masing-masing selama 1 jam dan 2 jam), maka: • Availability = ((720–(1+2)) / 720) x 100% = 99.58% • Reliability (MTBSI) = 720 / 2 = 360 jam • Reliability (MTBF) = (720–(1+2)) / 2 = 358,5 jam • Maintainability (MTRS) = (1+2) / 2 = 1,5 jam MTBSI (Mean Time Between Service Incidents) MTBF (Mean Time Between Failures) MTRS (Mean Time to Restore Service)
  • 14. SLM Series | Page—13 • Detection time  NMS Red Icon Waktu dimana penyedia layanan mengetahui/mendeteksi adanya insiden • Diagnosis time  1st Level Troubleshooting Waktu dimana penyedia layanan melakukan diagnosis untuk menentukan penyebab terjadinya insiden • Repair time  Data Link Layer UP Waktu yang diperlukan untuk memperbaiki insiden • Recovery time  Network Routing UP Waktu yang diperlukan untuk pemulihan insiden • Restoration Point  Application UP Titik dimana layanan bisnis normal kembali Resolution time
  • 15. SLM Series | Page—14 Tangible Cost Intangible Cost Biaya perbaikan gangguan (transport, man-days) Penurunan reputasi perusahaan Denda atau penalty dari customer karena terganggunya layanan Kehilangan kepercayaan customer Penurunan pendapatan karena customer berhenti berlangganan Kehilangan kepercayaan strategic partner (integrator, vendor) Biaya perbaikan perangkat yang rusak Kehilangan peluang bisnis Biaya lembur jika gangguan terjadi saat after office hour Penurunan kepercayaan diri dari front liner (operator, field technician) Tangible cost : biaya yang dapat diukur dengan jelas secara finansial Intangible cost : biaya yang tidak dapat/sulit diukur secara finansial Source: Bob Hardian, Availability Management (2011), telah diolah kembali
  • 16. SLM Series | Page—15 • Semaikin tinggi Availability yang diinginkan, semakin besar biaya preventive maintenance dan resilience yang dibutuhkan (kurva logaritmik) • Semakin tinggi Availability, semakin kecil biaya corrective maintenance yang dibutuhkan (kurva linier) • Total cost optimum dicapai untuk Uptime/Availability 70%-85% • Kebutuhan akan tingkat Availability melebihi nilai optimum akan membuat total cost naik secara drastis atau signifikan • Untuk mencapai Availability 99% dibutuhkan biaya sekitar 10 kali dari biaya optimum Source: Bob Hardian, Availability Management (2011)
  • 17. SLM Series | Page—16 Source: Kailash Jayaswal, Administering Data Centers: Servers, Storage, and Voice over IP (2006)
  • 18. SLM Series | Page—17 Source: Kailash Jayaswal, Administering Data Centers: Servers, Storage, and Voice over IP (2006) Server software, 30% Environment, 5% Planned downtime, 30% People, 15% Hardware, 10% Network software, 5% Client software, 5%
  • 19. SLM Series | Page—18 • Untuk memastikan kinerja perangkat berjalan normal maka harus dipastikan perangkat tersebut bekerja di bawah ambang batas (threshold). Jika kapasitas perangkat telah mencapai atau melebihi ambang batas, maka solusi yang bisa dilakukan: • Scaling Up Melakukan penggantian dengan perangkat yang memiliki kapasitas lebih besar. • Scaling Out Melakukan penambahan unit perangkat dengan kapasitas yang sama (load-balancing, active-active redundancy, parallel run). • Solusi Scaling Up atau Scaling Out yang dipilih bisa berdasarkan CBA (Cost-Benefit Analysis)
  • 20. SLM Series | Page—19 • Agar dapat kompetitif, pilihan infrastruktur untuk masa depan haruslah memiliki sifat adaptif (Adaptive Infrastructure) • Ciri infrastruktur adaptif • Efisien Tersedianya komponen yang dapat dimanfaatkan secara bersama oleh berbagai sistem baik oleh sistem lama maupun sistem baru • Efektif Tersedianya komponen yang mudah dipadukan (interoperable) dan diintegrasikan (integrated) • Fleksibel (agile) Tersedianya komponen yang mudah dirombak, di-upgrade atau diganti • Adaptiveness dari infrastruktur diukur dari: • Time to Market: kecepatan implementasi layanan baru • Scalability: mampu mengakomodasi peningkatan penggunaan • Extensibility: kemudahan penambahan komponen baru
  • 21. SLM Series | Page—20 Contact us at: ins.saputra@gmail.com Follow our : @SujanaSaputra