## PERANCANGAN DOKUMEN STANDARD OPERATING PROCEDURE
(SOP) PADA PROSES INCIDENT MANAGEMENT DI PT. XYZ
*Indah Nur Rachmawati 1 , Sri R. Natasia 2 , I Putu Deny Arthawan Sugih Prabowo 3 1, 2, 3 Program Studi Sistem Informasi Jurusan Matematika dan Teknologi Informasi Institut Teknologi Kalimantan E-mail : * 10161045@student.itk.ac.id
ABSTRAK- PT. XYZ adalah perusahaan yang secara professional mengelola dan menyediakan berita secara online di  Kalimantan.  Permasalahan  di  PT.  XYZ  adalah  beberapa  insiden  terkait  TI  sering  terjadi.  Proses penanganan  insiden  saat  ini  dengan  belum  adanya  panduan  baku  masih  dilakukan  hanya  berdasarkan pengetahuan dan pengalaman  yang dimiliki. Hal tersebut  menyebabkan beberapa dampak  negatif  yang  muncul diantaranya alur penanganan insiden tidak sistematis, sulitnya melakukan monitoring seluruh kegiatan dari awal hingga  selesai  terkait  pengelolaan  insiden  dan  tidak  adanya  informasi  mengenai  permasalahan  insiden  yang pernah  terjadi  serta  hasil  penanganannya.  Selain  itu,  masih  ada  laporan  insiden  yang  masuk  tidak  langsung disampaikan  ke  bagian  IT.  Hal  ini  mengakibatkan  penanganan  insiden  menjadi  lambat  dan  berpotensi  tidak langsung  ditangani.  Berdasarkan  permasalahan  tersebut,  maka  dilakukan  perancangan  dokumen Standard Operating Procedure (SOP) menggunakan kerangka kerja Information Technology Infrastructure Library (ITIL) di  PT.  XYZ.  Perancangan  dokumen  SOP  fokus  pada  proses incident  management .  Perancangan  dilakukan menggunakan  metode  analisis  kesenjangan  dengan  membandingkan  kondisi  saat  ini  yang  terdapat  pada  PT. XYZ terhadap kondisi ideal pada proses incident management ITIL versi 3. Produk akhir yang dihasilkan dalam penelitian adalah 3 jenis dokumen SOP dan 3 formulir pendukung sesuai dengan standar ITIL Versi 3 yang telah diverifikasi dan valid bagi kebutuhan PT. XYZ.
Kata kunci : Information Technology Infrastructure Library (ITIL), Incident Management, Standard Operating Procedure (SOP)

## 1. PENDAHULUAN
PT.  XYZ  adalah  perusahaan  yang  secara professional  mengelola  dan  menyediakan  berita secara online di  Kalimantan.  PT.  XYZ  dalam menjalankan  operasional  bisnis  bertumpu  pada beberapa  layanan  yaitu  layanan  berita online , layanan  iklan  serta  layanan  televisi  dan  radio online .  PT.  XYZ  menggunakan  layanan  TI  dalam menjalankan operasional bisnisnya.
PT.  XYZ  dalam  mengelola  layanan  TI  yang ada, memiliki unit teknologi informasi. Permasalahan  di  PT.  XYZ  yaitu  insiden  terkait  TI sering  terjadi.  Insiden  yang  sering  terjadi  di  PT. XYZ  terdapat  beberapa  kategori  insiden  yaitu hardware ,  jaringan, software dan database .  Pada kategori hardware terdapat  insiden server  down dan  kabel  jaringan  putus.  Kategori  jaringan terdapat insiden  internet lambat, internet mati total dan  pengguna  tidak  dapat  masuk  ke  jaringan. Insiden  tidak  berfungsinya  fitur  pada  sistem, pengguna  tidak  dapat  membuka  aplikasi  dan software bug terdapat pada kategori software . Pada kategori database terdapat  insiden  konflik  IP address .  Hal  ini  menyebabkan  penurunan  kinerja karyawan  dan  terganggunya  operasional  bisnis utama perusahaan.
Proses  penanganan  insiden  saat  ini  dengan belum  adanya  panduan  baku  masih  dilakukan hanya  berdasarkan  pengetahuan  dan  pengalaman yang dimiliki. Hal tersebut menyebabkan beberapa
dampak  negatif  yang  muncul  diantaranya,  alur penanganan  insiden  tidak  sistematis,  sulitnya melakukan  monitoring  seluruh  kegiatan  dari  awal hingga selesai terkait pengelolaan insiden dan tidak adanya  informasi  mengenai  permasalahan  insiden yang  pernah  terjadi  serta  hasil  penanganannya. Selain  itu,  masih  ada  laporan  insiden  yang  masuk tidak  langsung  disampaikan  ke  bagian  IT.  Hal  ini mengakibatkan penanganan insiden menjadi lambat dan berpotensi tidak langsung ditangani.
Pada  penelitian  yang  dilakukan  oleh  Susanti terdapat  permasalahan  belum  adanya  panduan dalam  pengelolaan  insiden,  solusi  yang  diberikan dengan melakukan manajemen insiden menggunakan  kerangka  kerja  ITIL  Versi  3  dan hasil  penelitian  yang  dilakukan  berupa  dokumen standard  operating  procedure (SOP)  mengenai manajemen  insiden  [1].  Pada  penelitian  yang dilakukan oleh Fransiska, terdapat kesamaan dalam permasalahan  dan  hasil.  Permasalahan  yang  sama dengan  penelitian  kali  ini  yaitu  layanan  IT  belum melaksanakan  program service  desk yang  bertugas dalam  melakukan incident  management .  Hasil penelitian berupa prosedur untuk incident management dan rekomendasi  struktur  organisasi [2].  Perencanaan  manajemen  insiden  dengan  ITIL versi 3 pada penelitian terdahulu menjadi kerangka kerja  yang  paling  banyak  digunakan  dibandingkan kerangka  kerja  yang  lain.  Hal  ini  dikarenakan, proses incident  management pada  ITIL  versi  3 memiliki  tahapan  yang  lebih  spesifik  dan  lengkap
dibandingkan  kerangka  kerja  yang  lain  [3].  Pada penelitian  yang  dilakukan  oleh  Santoso  &  Saleh, kerangka kerja COBIT digunakan untuk mengukur tingkat  kapabilitas  tata  kelola  pengelolaan  insiden dengan  keluaran  berupa  saran  terkait  pengelolaan insiden  agar  lebih  baik  lagi  dan  sesuai  dengan standar  COBIT  5  [4].  Dibandingkan  dengan kerangka kerja ITIL versi 3, kerangka kerja COBIT 5  tidak  menjelaskan  konsep  ataupun  proses penanganan  insiden  tetapi  menyediakan  faktor untuk  mengukur  kesuksesan  penanganan  insiden yang  ada  [4].  ITIL  saat  ini  telah  memperbaharui ITIL  Versi  3  menjadi  ITIL  Versi  4.  Namun, kerangka  kerja  ITIL  VERSI  4  saat  ini  masih mengeluarkan  versi  fundamental  saja,  sehingga informasi  yang dibutuhkan dalam penelitian  masih sangat kurang terkait ITIL versi 4 [5].
Oleh  karena  itu,  pada  penelitian  ini  digunakan ITIL versi 3 dengan lingkup penelitian perancangan SOP service desk pada proses incident management . Diharapkan dengan adanya perancangan  dokumen  SOP  yang  sudah  tertata dapat meningkatkan alur penanganan  insiden  lebih terstruktur sesuai dengan standar yang telah dibuat. Dengan demikian, kualitas  layanan TI  yang  ada  di PT. XYZ dapat mendukung berjalannya operasional bisnis perusahaan secara optimal.

## 2. ISI PENELITIAN
2.1 Tinjauan Pustaka
2.1.1 Information Technology Infrastructure Library (ITIL) VERSI 3
Layanan  adalah  sarana  untuk  memberikan nilai  kepada  pelanggan  [6].  Manajemen  layanan mempertimbangkan strategi, desain, transisi, operasi dan peningkatan berkelanjutan dari layanan TI [7]. ITIL VERSI 3 adalah kerangka kerja publik yang  berfokus  untuk  manajemen  layanan  TI,  tata kelola  TI,  pengukuran  dan  peningkatan  kualitas layanan  TI  yang  disampaikan  melalui  perspektif bisnis maupun pelanggan [6].

## 2.1.2 Proses Incident management
Incident management adalah proses penanganan  terhadap  semua  insiden  yang  dapat terjadi,  yang  bertujuan  agar  layanan  TI  dapat kembali  berjalan  normal  secepat  mungkin  dengan menekan  dampak  sekecil  mungkin.  Berikut  adalah alur  dari  proses incident  management pada  ITIL Versi 3 [6].
1. Incident Identification
Pada  tahap  awal  ini,  dilakukan  identifikasi insiden  terhadap  laporan  yang  masuk  dari pengguna layanan.
2. Incident Logging
Pada tahap ini, semua insiden harus sepenuhnya dicatat. Pencatatan insiden bertujuan  untuk  memastikan  bahwa  informasi terkait  terjadinya  insiden,  proses  penanganan dan  bukti  pekerjaan  yang  dilakukan  karyawan
dapat  dipantau  dengan  mudah  dan  menjadi evaluasi perusahaan.
3. Incident Categorization
Pada  tahap  ini  dilakukan  proses  pembuatan kategorisasi  untuk  setiap  insiden  yang  terjadi. Setiap  laporan  insiden  yang  terjadi  harus dianalisis  berdasarkan  kategori  yang  telah dibuat.
4. Incident Prioritazation
Pada  tahap  ini,  setiap  prioritas  biasanya  dapat ditentukan dengan mempertimbangkan urgensi insiden  (seberapa  cepat  bisnis  membutuhkan penanganan)  dan  tingkat  dampak  yang ditimbulkannya.
5. Incident Diagnosis Pada  tahap  ini service  desk harus  melakukan diagnosis  awal,  biasanya  saat service  desk masih  terhubung  dengan  pengguna.  Diagnosis awal  digunakan  untuk  menemukan  gejala lengkap  dari  insiden  tersebut  dan  untuk menentukan  dengan  tepat  apa  yang  salah  dan bagaimana memperbaikinya.
6. Incident Escalation
Tahap  ini  adalah  tahap  dimana  menaikkan level suatu  insiden  yang telah terjadi. Eskalasi insiden  dalam  ITIL  Versi  3  terbagi  menjadi dua  tipe  yaitu Functional  escalation dan Eskalasi  hierarkis. Functional  escalation adalah  menaikkan  level  insiden  dalam  hal teknis.  Sedangkan  eskalasi  hierarkis  adalah menaikkan level insiden dalam hal manajemen
7. Investigation and Diagnosis Pada  tahap  ini  dilakukan  investigasi  dan diagnosis  penyebab  terjadinya  insiden.  Pada saat  melakukan  investigasi  dan  diagnosis, semua  tindakan  apa  pun  yang  diambil  untuk mencoba  menyelesaikan  insiden  itu  harus sepenuhnya  didokumentasikan  dalam incident record .
8. Resolution and Recovery Pada tahap ini dilakukan pengambilan tindakan  spesifik  yang  harus  dilakukan tergantung  pada  sifat  insiden  yan  dapat melibatkan  pengguna, service  desk ,  bagian teknisi  maupun  pihak  ketiga  eksternal  seperti vendor atau provider .
9. Incident Closure Pada  tahap  ini service  desk harus  memeriksa bahwa insiden tersebut sepenuhnya diselesaikan  dan  bahwa  pengguna  puas  dan bersedia  menyetujui  insiden  tersebut  dapat ditutup.
2.1.3 Standard Operating Procedure (SOP) SOP  adalah  dokumen  yang  menjelaskan berbagai  aktivitas  operasional  yang  dilakukan sehari  –  hari  oleh  suatu  perusahaan  atau  instansi pemerintahan.  Adanya  pembuatan  SOP  membantu agar  proses  yang  berjalan  dilaksanakan  dengan benar,  tepat  dan  konsisten  sehingga  produk  atau
layanan  yang  dihasilkan  sesuai  dengan  standar yang  ditetapkan  [8].  Selain  itu,  dengan  SOP diharapkan  berbagai  bentuk  penyimpangan  yang terjadi  dapat  dihindari  dalam  penerapannya. Dengan demikian, secara bertahap kualitas layanan pemerintahan  kepada  masyarakat  akan  lebih profesional, cepat dan mudah [9].

## 2.2 Metodologi
Gambar 1. Metodologi Penelitian
2.3 Hasil dan Pembahasan
2.3.1 Analisis Kondisi Saat Ini
Kondisi  saat  ini  adalah  kondisi  yang menjelaskan mengenai kondisi saat ini yang terjadi pada  unit  IT  PT.  XYZ  terutama  terkait  dengan pengelolaan  insiden  layanan  TI.  Kondisi  saat  ini dilakukan menggunakan metode wawancara dengan manager  IT yaitu  Bapak  Rahman.  Berikut adalah  hasil  dari  tahap  analisis  kondisi  saat  ini  di PT. XYZ.
1. Portofolio Layanan ( Service Portofolio ) Portofolio  layanan  adalah  daftar  layanan  yang menjelaskan  rincian  semua  layanan  yang  ada  di suatu  perusahaan.  Berdasarkan  hasil  wawancara yang  telah  dilakukan,  Tabel  1  adalah  layanan  TI yang ada di PT. XYZ.
Tabel 1. Identifikasi Layanan
Layanan TI Deskripsi Layanan User
Website prokal.co Website sebagai layanan utama digunakan untuk manajemen  proses  layanan berita, iklan, televisi dan radio online kepada masyarakat. Masyarakat Bagian redaksi Sistem Informasi Iklan Sistem informasi ini digunakan  untuk  manajemen kegiatan  operasional  terkait Bagian iklan
Layanan TI Deskripsi Layanan
User transaksi  pemasangan  iklan  di PT. XYZ Sistem Informasi human  resource general affair (HRGA) Sistem informasi ini digunakan  untuk  manajemen terkait data – data karyawan. Seluruh karyawan PT. XYZ Sistem Informasi Keuangan (Sibiru) Sistem informasi ini digunakan  untuk  manajemen terkait  keuangan  perusahaan baik  data  pemasukan  maupun pengeluaran  hingga  laporan keuangan. Bagian keuangan Web mail Layanan  yang  digunakan  oleh karyawan  untuk  mengakses email  dan  bertukar  pesan terkait  informasi  dan  data  - data perusahaan Seluruh Karyawan PT. XYZ
Tabel  1  menjelaskan  tentang  daftar  layanan yang terdapat di PT. XYZ. Kategori layanan di PT. XYZ  terbagi  menjadi  dua  yaitu core  service dan enabling service . Core service adalah layanan yang menyediakan  kebutuhan  utama  dari  pengguna  dan sangat  berpengaruh  terhadap  proses  bisnis  utama pada suatu perusahaan. Layanan TI  yang termasuk core  service di  PT.  XYZ  adalah website prokal.co dan sistem informasi iklan. Enabling service adalah layanan  yang  dibutuhkan  untuk  mendukung core service .  Layanan  TI  yang  termasuk enabling service di PT. XYZ adalah sistem informasi human resources general affair, sistem informasi keuangan (sibiru) dan web mail.
2. Identifikasi Configuration Item Identifikasi  c onfiguration  item adalah  tahap mengidentifikasi komponen layanan, elemen infrastuktur  dan  item  lainnya  yang  mendukung berjalannya  suatu  layanan  pada  suatu  perusahaan. Fokus  utama  identifikasi configuration  item pada tahap  ini  yaitu  mengidentifikasi setiap server yang terhubung dengan layanan, lokasi server , memastikan server memiliki server backup atau tidak,  konektifitas  setiap server dan  spesifikasi setiap server .  Tahap  ini  dilakukan  dengan melakukan  wawancara  dengan manager  IT. Hasil dari wawancara dalam mengidentifikasi configuration item di PT. XYZ terdapat pada Tabel 2.
Tabel 2. Identifikasi Configuration Items Service Server Primary Server Backup Website Prokal.co Nama server : Server Prokal
Lokasi: Data Center Telkom,  Batu  Ampar, Balikpapan Nama server : Server
Prokal Lokasi:  Data  Center
Telkom,  Batu  Ampar, Balikpapan Sistem informasi iklan Nama server : Server JSI Lokasi: Surabaya Nama server : Server JSI Lokasi: Gedung Kaltim Post Lantai 3 Sistem informasi
Human
Resources General Affair
(HRGA)
Nama server : Server JSI Lokasi: Surabaya Nama server : Server JSI Lokasi: Gedung Kaltim Post Lantai 3 Sistem Informasi
Keuangan
Nama server : Server JSI Lokasi: Surabaya Nama server : Server JSI Lokasi: Gedung
Service Server Primary Server Backup (Sibiru) Kaltim Post Lantai 3 Web mail Nama server : Server email
Lokasi: Data Center Telkom,  Batu  Ampar, Balikpapan
Nama server : - Lokasi: -
Tabel  2  menjelaskan  hubungan  antara  setiap layanan  dengan server yang  digunakan.  Layanan yang memiliki server backup dengan layanan yang tidak  memiliki server  backup akan  berpengaruh pada  penentuan  prioritas  penanganan  insiden. Layanan  yang  tidak  memiliki server  backup lebih diprioritaskan penanganannya dibandingkan dengan layanan yang memiliki server backup.
Gambar 1. Topologi Jaringan
Gambar  2  menjelaskan  topologi  jaringan  yang ada  di  PT.  XYZ.  Informasi  mengenai  topologi jaringan  diperoleh  dengan  melakukan  melakukan wawancara dengan manager IT . Topologi  jaringan yang  ada  di  PT.  XYZ  terdiri  dari  dua router yang masing  –  masing  memiliki  fungsi  yang  berbeda. Router ip public digunakan untuk menghubungkan jaringan dari Astinate dengan server melalui switch distribution. Router  ip  public digunakan  untuk akses dari jaringan luar. Sedangkan Router gateway digunakan untuk akses internal seperti internet dan office. Masing  –  masing router memiliki firewall mikrotik yang  berfungsi  sebagai  pelindung router dari hak akses yang tidak diinginkan baik dari luar maupun  dari  internal.  Baik router  ip  public dan router  gateway hanya  terhubung  oleh  satu switch distribution dan satu switch access.
Tabel 3. Spesifikasi Configuration Item
Configuration Item Spesifikasi Jaringan LAN Topologi ring extended Server Prokal Primary dan Secondary Processor: Intel Xeon
RAM: 16 GB Merek: HP
Hardisk: 100 GB (Virtual) Hardisk: 4 Tera (Fisik)
Sistem operasi: Ubuntu
Server JSI Primary
Processor: Intel Xeon RAM: 16 GB Hardisk: 4 Tera Merek: IBM Sistem operasi: Centos
Configuration Item
Spesifikasi Server JSI Secondary
Processor: Intel Xeon
RAM: 8 GB
Hardisk: 500 GB
Merek: IBM
Sistem operasi: Centos
Server email Processor: Intel Xeon RAM: 8 GB
Hardisk: 500 GB Merek: HP Sistem operasi: Ubuntu
Tabel  3  merupakan  informasi  detail  terkait spesifikasi  setiap  server  di  PT.  XYZ.  Fokus pembahasan configuration  item yaitu  topologi jaringan  serta  spesikasi  terkait  masing  –  masing server yang  digunakan  di  PT.  XYZ.  Informasi tersebut  digunakan  dalam  penentuan  prioritas penanganan  insiden  dan  menjadi  pertimbangan mengenai  urgensi  dan  dampak  jika  terjadi  insiden dari sisi configuration item tersebut. 2.3.2 Analisis Kesenjangan Berikut adalah hasil dari analisis kesenjangan  dan  identifikasi  perubahan  yang  telah dilakukan.  Hasil  kesenjangan  diperoleh  dari perbedaan  kondisi  saat  ini  dengan  kondisi  ideal. Perubahan dilakukan sebagai upaya untuk berpindah  dari  kondisi  saat  ini  ke  kondisi  ideal yang  sesuai  dengan  kerangka  kerja  ITIL. Diharapkan  dengan  adanya  perubahan  dapat meningkatkan  layanan  IT  dalam  berjalan  lebih optimal terutama dalam hal pengelolaan insiden.

## Tabel 4. Hasil Analisis Kesenjangan dan Identifikasi Perubahan
Aktivitas Kesenjangan Perubahan dan Kebutuhan Dokumen Incident Identification Belum sesuai dengan kondisi ideal, dimana tidak  semua  pengguna bisa menyampaikan laporan  insiden.  Media yang digunakan sejauh ini masih berbatas pada telepon saja. Adanya kegiatan yang mengarahkan pengguna untuk melaporkan  insiden melalui telepon, website prokal, maupun email maupun sistem service desk Incident Logging Belum dilakukan pencatatan  secara  manual maupun  dengan  sistem terkait  laporan  insiden yang masuk Adanya kegiatan pencatatan setiap laporan  insiden  yang masuk Incident Categorizatio n Tidak  dilakukan  proses kategorisasi insiden sehingga  sulit  mengetahui jenis  insiden  apa  yang sering terjadi dan kategori mana  yang  memerlukan penanganan khusus. Adanya proses kategorisasi saat laporan  insiden  telah diterima Incident Prioritazatio n Belum  dilakukan  proses pembuatan prioritas secara  tertulis  sehingga tidak  dapat  menentukan secara  pasti  insiden  mana yang  harus  lebih  dahulu ditangani  atau  mendapat prioritas utama. Adanya proses prioritas terhadap laporan  insiden  yang masuk
Incident Diagnosis Belum sesuai dengan kondisi  ideal,  karena belum ada  dokumentasi  diagnosis awal. Adanya  dokumentasi diagnosis  awal  yang dilakukan oleh service desk Incident Escalation Proses eskalasi insiden belum berdasarkan Adanya  dokumentasi proses eskalasi
Aktivitas Kesenjangan Perubahan dan Kebutuhan Dokumen peraturan dan prosedur yang tertulis jelas.. insiden yang dilakukan Investigation and Diagnosis Belum  dilakukan  proses pendokumentasian dari kegiatan  investigasi  dan diagnosis  insiden  dalam incident record. Adanya proses dokumentasi kegiatan  investigasi dan  diagnosis  yang dilakukan Resolution  and Recovery Penyelesaian  insiden  masih hanya  sebatas  pengetahuan dan pengalaman belum berdasarkan  prosedur  yang terstandarisasi.  Selain  itu belum  adanya  dokumentasi terkait  proses  penyelesaian insiden pada tahap ini. Adanya proses penyelesaian  insiden berdasarkan proses eskalasi yang tepat Incident Closure Tidak ada proses pencatatan dan pendokumentasian terkait penutupan insiden. Tidak dilakukan survei terkait  kepuasaan pengguna terhadap penanganan insiden. Tidak ada proses perubahan status  insiden  yang  ditelah ditangani. Tidak adanya survei kepuasaan pengguna terhadap proses penanganan insiden yang telah dilakukan. Perlu adanya proses pencatatan dan pendokumentasian terkait penutupan insiden.  Melakukan survei terkait kepuasaan  pengguna terhadap  penanganan insiden. Perlu adanya proses perubahan status  insiden  yang ditelah ditangani.
Tabel  4  adalah  tabel  yang  menjelaskan perubahan  yang  perlu  dilakukan  untuk  mengatasi kesenjangan  kondisi  saat  ini  dengan  kondisi  ideal di  ITIL versi  3.  Setelah mengidentifikasi perubahan,  maka  dilakukan  identifikasi  kebutuhan dokumen untuk mendukung terlaksananya perubahan  yang dilakukan. Pada tabel 5 dijelaskan lebih  detail  masing  –  masing  fungsi  dan  kegunaan dari setiap dokumen yang telah diidentifikasi dapat mendukung perubahan.
Tabel 5. Kebutuhan Dokumen Penanganan Insiden
Dokumen Keterangan Prosedur Pencatatan Insiden Prosedur  yang  digunakan  untuk  melakukan pencatatan terkait insiden yang sedang terjadi atau  yang  dilaporkan  oleh  unit  internal  dan eksternal pada PT. XYZ Formulir Pencatatan Insiden Formulir  yang  menjadi  bukti  adanya  laporan masuk  terkait  insiden  yang  terjadi  dan  bukti proses  penanganan  insiden  yang  telah dilakukan service desk
Prosedur Penanganan Insiden
Prosedur  yang  digunakan  untuk  melakukan penanganan  apabila  terjadi  insiden  yang dilaporkan  oleh  pengguna  kepada service desk ,  mulai  dari  proses  kategorisasi  hingga penanganan dan penyelesaian insiden Formulir Eskalasi Insiden Formulir yang menjadi bukti adanya eskalasi proses  penanganan  insiden dari  satu  level  ke level  berikutnya  bukti  proses  penanganan insiden yang telah dilakukan service desk, IT engineer maupun vendor/provider Prosedur Penutupan Insiden Prosedur  yang  digunakan  untuk  melakukan proses penutupan insiden yang telah
ditangani  ataupun  insiden  yang  tidak  bisa ditangani  dan  dipaksa  ditutup  sementara kasus penanganan insidennya Formulir Survei Kepuasan Pengguna Formulir  yang  menjadi  bukti  kepuasaan pengguna  terhadap  layanan service  desk
terutama dalam penanganan insiden
Tabel 5 adalah penjelasan setiap dokumen yang dibutuhkan  dalam  mendukung  perubahan  menuju kondisi  ideal  pada  ITIL  versi  3.  Terdapat  enam
jenis  dokumen  yang  berbeda  –  beda.  Dari  total enam  jenis dokumen tersebut, terbagi  menjadi tiga dokumen  prosedur  dan  tiga  dokumen  formulir. Setiap dokumen memiliki fungsi masing – masing.

## 2.3.3 Merancang Dokumen SOP
Pada  proses  perancangan  dokumen  SOP terbagi menjadi dua hal yaitu perancangan struktur dan  konten  dokumen  SOP  dan  perancangan prosedur.
1. Perancangan Struktur dan Konten

## Dokumen SOP
Struktur  dan  konten  dokumen  SOP  yang  ada pada PT. XYZ terdiri dari dua bagian yaitu bagian legalitas  dan  bagian  alur  prosedural.  Bagian legalitas, merupakan bagian identitas dari dokumen SOP  yang dibuat. Bagian legalitas terdiri dari logo dan  nama  perusahaan,  nomor  dokumen  SOP, tanggal  selesai  pembuatan  dokumen  SOP,  tanggal revisi  SOP,  tanggal  efektif  diberlakukan  dokumen SOP,  pengesahan  penandatangan  dokumen  SOP dan  judul  SOP.  Bagian  alur  prosedural  merupakan bagian dokumen SOP yang berisi penjelasan urutan prosedur  yang  harus  dilakukan  dan  pelaksana  dari prosedur tersebut.

## 2. Perancangan Prosedur
Dalam perancangan prosedur dilakukan beberapa  proses  sebelumnya  yaitu  pembuatan kategori  insiden,  prioritas  insiden,  eskalasi  insiden dan status penanganan insiden. Pembuatan kategori insiden juga dirincikan dengan insiden pada masing – masing kategori seperti pada Tabel 6.
Tabel 6 . Kategori Insiden
Kategori Insiden Hardware Server down Kabel jaringan putus Jaringan Internet lambat/ Traffic Padat Internet mati total Pengguna tidak bisa masuk jaringan Software Tidak berfungsinya fitur dari suatu system Pengguna tidak dapat membuka aplikasi Software bug Database
Konflik IP Address
Tabel  6  adalah  tabel  kategori  insiden  yang digunakan sebagai acuan untuk mempermudah saat penanganan  insiden.  Kategori  insiden  dibuat berdasarkan  dari  riwayat  insiden  dalam  6  bulan terakhir  di  PT.  XYZ.  Proses  kategori  insiden kedepannya  dapat  ditambahkan  sesuai  dengan kebutuhan  dan  bertambahnya  insiden  baru  di  PT. XYZ.  Selanjutnya,  pendefinisan  prioritas  pada level urgensi dan dampak seperti pada Tabel 7.
Tabel 7. Prioritas Insiden
Dampak High Medium Low Urgensi High P1 P2 P3 Medium P2 P3 P4 Low P3 P4 P5
Tabel 7 adalah pemetaan prioritas insiden yang dilakukan  untuk  menilai  prioritas  insiden  secara keseluruhan  yaitu  dari  sisi  level  urgensi  dan  juga sisi  level  dampak.  Misalnya,  jika  level  urgensi adalah high dan  level  dampak  adalah high maka level  prioritas  adalah  P1  yang  artinya critical . Penggunaan  kode  prioritas  mengacu  pada  ITIL versi  3  untuk  memudahkan  dan  menjadi  tanda urutan  prioritas  insiden  dari  yang  terbesar  hingga yang  prioritas  yang  direncanakan  seperti  pada Tabel 8.
Tabel 8 . Keterangan Kode Prioritas P1 P2
P3 P4 P5 Critical High Medium Low Planning
Tabel  8  adalah  keterangan  penggunaan  kode prioritas  pada  Tabel  7.  Dimana  kode  P1 menandakan prioritas insiden bersifat critical, kode P2  menandakan  prioritas  insiden  bersifat high, kode  P3  menandakan  prioritas  insiden  bersifat medium, kode  P4  menandakan  prioritas  insiden bersifat low dan  kode  P5  menandakan  prioritas insiden bersifat planning.
Tabel 9 . Prioritas Kasus (Issue) Layanan
Kasus
( Issue ) Domain Kasus ( Issue ) Priority Level Keterangan Website prokal.co Database (DB) Issue P1 Jika database bermasalah pada server prokal primary , maka server prokal secondary dapat melakukan backup. Tetapi server primary dan server secondary berada di lokasi yang sama. Sistem informasi iklan,  Sistem
informasi keuangan, Sistem informasi HRGA Database (DB) Issue P1 Jika database bermasalah pada server JSI primary , maka server JSI secondary dapat melakukan
backup.
Tetapi dalam  satu server terdapat  beberapa layanan yang berjalan  sehingga ini sangat berisiko.
Selain
itu, kapasitas server secondary tidak cukup besar. Web mail Database (DB) Issue P2 Jika database bermasalah pada server email , maka server email
tidak memiliki backup, hal  ini akan berdampak pada terganggunya karyawan untuk mengakses email. Switch Distributin dan Switch Access Network Security Issue P1 Hanya  ada  satu switch  distribution
dan access, jika switch bermasalah maka  akan  semua layanan akan
Kasus ( Issue ) Domain Kasus ( Issue ) Priority Level Keterangan terganggu dan berdampak pada keberlangsungan bisnis PT. XYZ Router dan Firewall Network Security Issue P1 Ada  dua router dan  satu firewall pada masing –
masing router , satu router untuk akses  internal  dan satu router untuk akses eksternal. Tidak  ada backup pada masing – masing router, jika router bermasalah  maka akan terganggu operasional  bisnis keberlangsungan bisnis PT. XYZ
Tabel  9  adalah  tabel  prioritas  penanganan insiden  di  PT.  XYZ  secara  keseluruhan.  Prioritas penanganan  insiden  dibuat  berdasarkan  kasus antara  lain  layanan  dan configuration  item .
Prioritas penanganan insiden dengan mengacu pada level urgensi dan level dampak yang dibuat.
Setelah  membuat  prioritas  penanganan  insiden, selanjutnya  membuat  target  waktu  berdasarkan prioritas  penanganan  insiden.  Target  waktu  terdiri dari  target  mulai  dari  waktu  respon  dan  waktu resolusi.  Setiap  prioritas  memiliki  target  waktu yang berbeda – beda.
Tabel 10. Waktu Respon dan Resolusi
Prioritas Respon Resolusi Critical Respon  harus  diambil saat itu juga Resolusi  atas  insiden harus ada dalam waktu 1 jam High Respon  harus  diambil saat itu juga Resolusi  atas  insiden harus  ada  dalam  waktu 12 jam Medium Respon  harus  diambil dalam  waktu  1  jam  sejak laporan insiden masuk Resolusi  atas  insiden harus  ada  dalam  waktu 24 jam Low Respon  harus  diambil dalam  waktu  24  jam sejak laporan insiden masuk Resolusi  atas  insiden harus  ada  dalam  waktu 2x24 jam Planning Respon  harus  diambil sesuai dengan perencanaan Resolusi  atas  insiden dijalankan atas perencanaan  yang  telah dibuat
Tabel  10  adalah  target  respon  dan  target resolusi  penanganan  insiden  pada  setiap  level prioritas.  Target  respon  adalah  target  waktu  dalam merespon  dan  menerima  laporan  insiden  maupun waktu  untuk  mendeteksi  adanya  insiden  yang terjadi.  Target  resolusi  adalah  target  waktu  dalam menangani insiden yang terjadi.
Tahap selanjutnya adalah pendefinisian eskalasi  insiden.  Eskalasi  insiden  didefinisikan dalam dua jenis yang berbeda yaitu eskalasi insiden tingkat  fungsional  dan  eskalasi  insiden  tingkat hirarki seperti pada Tabel 11 dan Tabel 12.
Tabel 1 1. Eskalasi insiden tingkat fungsional Level Deskripsi 1 st Line Support (Service Desk) Bertanggungjawab menerima informasi insiden dari pengguna dan hasil pengawasan dari  bagian event  management ,  melakukan pencatatan  insiden,  melakukan  diagnosis awal,  melakukan  eskalasi  jika  ditemukan proses  penanganan  tidak  akan  memenuhi standar  waktu  penanganan.,  menerima konfirmasi status penanganan insiden dari IT Engineer dan Vendor/Provider ,  melakukan konfirmasi  kepada  pengguna  yang  melapor jika insiden telah selesai ditangani
2 nd Line  Support  (IT Engineer) Menerima  eskalasi  insiden  yang  tidak mampu  ditangani service  desk ,  melakukan proses penanganan insiden, menginformasikan status penanganan
insiden kepada service desk
3 rd Line Support (Vendor/Provider) Menerima  eskalasi  insiden  yang  tidak  yang terjadi  karena  gangguan  IT  di  pihak vendor/provider , melakukan proses penanganan insiden, menginformasikan status  penanganan  insiden  kepada service desk
Tabel  11  adalah  tabel  acuan  untuk  melakukan eskalasi  insiden ke level yang lebih tinggi. Masing –  masing  level  memiliki  tugas  yang  berbeda  – beda.  Setiap  level  pada  tingkat  dukungan fungsional  memberikan  dukungan  teknis  dalam penanganan insiden.
Tabel 12. Proses eskalasi pada tingkat dukungan hirarki Level Deskripsi 1 st Level Support (Manager IT) Bertanggungjawab mengambil keputusan terkait tindakan  penanganan  insiden  skala  kecil  yang berdampak pada perorangan atau pengguna tertentu
2 nd Level Support ( General Manager ) Bertanggungjawab mengambil keputusan terkait tindakan  penanganan  insiden  skala  sedang  dan berdampak pada suatu unit atau bidang di PT. XYZ
3 rd Level Support (Dewan Direktur) Bertanggungjawab mengambil keputusan terkait tindakan  penanganan  insiden  skala  besar  yang berdampak pada seluruh perusahaan
Tabel  12  adalah  tabel  acuan  untuk  melakukan eskalasi  insiden  ke  level  yang  lebih  tinggi.  Pada Tabel  12,  setiap  level  pada  tingkat  dukungan hirarki  memberikan  dukungan  manajemen  dalam penanganan  insiden.  Setelah pendefinisian  eskalasi insiden,  dilakukan  pendefinisan  status  penanganan insiden  untuk  mempermudah  pelaporan  setiap proses penanganan insiden.
Tabel 13 . Status penanganan insiden Status
Penanganan Insiden Deskripsi Open Status yang menunjukkan bahwa laporan insiden telah masuk In Progress Status yang menunjukkan bahwa laporan insiden masih dalam proses penanganan Completed Status yang menunjukkan bahwa laporan insiden yang masuk telah ditangani Closed Status yang menunjukkan bahwa laporan insiden yang masuk telah ditutup Tabel  13  adalah  pendefinisian  beberapa  status penanganan insiden. Tujuan dari adanya
pendefinisian tersebut untuk mempermudah service desk dalam  mengetahui  informasi  progress  dari setiap  insiden  yang  ditangani  dan  mempermudah setiap  pihak  yang  terlibat  dalam  penanganan insiden  untuk  menginformasikan  kembali  proses penanganan  insiden  ke service  desk maupun pelapor  insiden.  Setelah  itu,  dilakukan  proses perancangan  prosedur.  Gambar  3  dan  Gambar  4 adalah hasil dari dokumen SOP yang dihasilkan.
Gambar 3. Bagian legalitas prosedur
Gambar  3  merupakan  bagian  legalitas  dari prosedur  pencatatan  insiden.  Pada  bagian  legalitas tersebut  terdiri  dari  logo  dan  nama  perusahaan, nomor dokumen SOP, tanggal pembuatan dokumen SOP, tanggal  revisi  dokumen  SOP,  tanggal  efektif diberlakukan dokumen SOP, pengesahan penandatangan  dokumen  SOP,  nama  dokumen SOP.
Gambar  4  menjelaskan  tahapan  alur  untuk prosedur  pencatatan  insiden.  Pada  prosedur  ini terdapat  dua  pelaksana  yaitu  pelapor  insiden  dan service  desk .  Pelapor  insiden  dapat  berasal  dari karyawan ataupun pengguna dari eksternal perusahaan.  Kegiatan  dimulai  dari  pelapor  yang melakukan  pelaporan  insiden  kepada service  desk. Pelaporan  insiden  dapat  melalui  telepon,  email maupun  secara  langsung  menemui service  desk . Jika laporan insiden melalui telepon ataupun email, maka service  desk akan  mencatat  laporan  insiden yang masuk. Jika laporan insiden dengan menemui secara  langsung service  desk ,  maka service  desk akan  mengarahkan  pelapor  mengisi  formulir pencatatan insiden.
Setelah  pelapor  mengisi  formulir  tersebut, service  desk akan  memeriksa  apakah  laporan insiden  tersebut  insiden  atau  bukan.  Jika  bukan insiden,  maka  tidak  akan  dilakukan  penanganan insiden  berdasarkan  proses incident  management dan  akan  ditangani  sebagaimana  proses  –  proses lain  dalam  kerangka  kerja  ITIL  versi  3  selain proses incident  management .  Jika  laporan  yang masuk  termasuk  dalam  insiden  maka  akan dilakukan penanganan berdasarkan prioritas penanganan  insiden  yang  telah  ditetapkan  pada perusahaan. Service  desk akan  membuka  status penanganan  insiden  menjadi open sebagai  tanda bahwa  laporan  insiden  telah  diterima.  Setelah  itu, service desk akan mengirimkan nomor tiket insiden kepada  pelapor  melalui  email  pelapor  yang  dapat diketahui  saat  pengisian  formulir  pencatatan insiden.

## 2.3.4 Hasil Verifikasi dan Validasi
Dokumen SOP dan formulir pendukung yang telah  dibuat  kemudian  diverifikasi  dan  divalidasi oleh manager  IT selaku  pihak  yang  bertanggung jawab  dalam  pengelolaan  layanan  TI  terutama penanganan  insiden.  Proses  verifikasi  dilakukan secara online dengan manager IT . Proses verifikasi dilakukan dengan cara melakukan review rekomendasi dokumen  SOP  dan  formulir yang telah  dibuat  dan  melakukan  wawancara  terkait beberapa  pertanyaan  mengenai  dokumen  SOP  dan formulir untuk  memastikan  dokumen  SOP  dan formulir  tersebut  telah  sesuai  dengan  kebutuhan perusahaan.  proses  validasi  atau  persetujuan dokumen  SOP  dan  formulir dilakukan  secara offline.

## 3 KESIMPULAN
Hasil  dari  perancangan  dokumen  SOP  yaitu terbentuknya  kategori  insiden,  prioritas  insiden, eskalasi  insiden  dan  status  penanganan  insiden. Dokumen  SOP  yang  dihasilkan  antara  lain prosedur  pencatatan  insiden,  prosedur  penanganan insiden  dan  prosedur  penutupan  insiden.  Formulir pendukung  dokumen  SOP  yang  dihasilkan  yaitu formulir  pencatatan  insiden,  formulir  eskalasi
insiden  dan  formulir  survei  kepuasan  pengguna. Hasil  dari  merancang  dokumen  SOP  adalah dokumen SOP dan formulir yang telah terverifikasi dan valid.

## DAFTAR PUSTAKA
[1] S.  D.  Susanti,  “Pembuatan  Standard Operating  Procedure  (SOP)  Service  Desk Berbasis ITIL V3 2011 dengan
Menggunakan Analisis Kesenjangan (Studi Kasus:  DPTSI  ITS),”  Institut  Teknologi Sepuluh November, 2017.
[2] A.  Fransiska,  Murahartawaty  &  Karma, “Perancangan  Service  Operation  Pada Layanan IT PT. XYZ Dengan Menggunakan  Framework  ITIL  Versi  3,” e-Proceeding Eng. , pp. 5079–5093, 2015.
[3] D.  Wibowo,  A.  S.,  Selo  &  Adipta, “Kombinasi  Framework  COBIT  5,  ITIL DAN  ISO/IEC  27002  untuk  Membangun Model Tata Kelola Teknologi Informasi di Perguruan Tinggi,” Semin. Nas. Teknol. Inf. dan  Komun.  2016  (SENTIKA  2016) ,  pp. 122–128, 2016.
[4] A.  A.  Santoso,  C.  B.  &  Saleh,  “Penerapan
Metode  COBIT  5.0  Domain  DSS02  dan DSS03 untuk Mengukur
Tingkat Kapabilitas  Tata  Kelola  Sistem  di  PT. Indofood  CBP  Sukses  Makmur  Tbk,” J. Ilm.  Teknol.  -  Inf.  dan  Sains ,  pp.  13-26., 2017.
[5] AXELOS, ITIL  Foundation  ITIL  4  Edition . Inggris:  AXELOS  Global  Best  Practices, 2019.
[6] Office  of  Government  Commerce  (OGC), ITIL  Service  Operation .  London:  The Stationery Office (TSO), 2011.
[7] I.  International, Foundations  of  IT  Service Management Based on ITIL V3 . Van Haren Publishing., 2007.
[8] A.  Tathagati, Step  by  step  membuat  SOP. Jakarta: Efata Publishing, 2014.
[9] A. P. Kilis, “Penerapan Standar Operasional Prosedur Dalam Pelaksanaan Tugas
Pemerintah  Kecamatan  Malalayang  Kota Manado,” . e-journal Unsrat , 2015.