Manajemen perubahan (change management)

Informasi Dokumen

Atribut	Keterangan
Kode Dokumen	DTSI-SOP-OPS-02
Kode LPM	—
Revisi	1.0
Tanggal Efektif	— (ditetapkan saat persetujuan Kepala DTSI)
Pemilik Dokumen	Departemen Teknologi dan Sistem Informasi (DTSI), Universitas Harapan Bangsa
Pemilik Proses	Kepala Departemen Teknologi dan Sistem Informasi (DTSI)
Kelas	Wajib
Status	DRAFT — siap peninjauan pimpinan

1. Tujuan

Mengendalikan risiko terhadap layanan TI dan keamanan informasi dengan cara merencanakan, menilai, menyetujui, mengimplementasikan, dan meninjau setiap perubahan pada infrastruktur, aplikasi, atau konfigurasi produksi—selaras ISO/IEC 20000-1 dan aspek ISO/IEC 27002 (perubahan terkendali).

2. Ruang lingkup

Berlaku untuk perubahan pada aset di bawah kendali DTSI, termasuk:

• Server, jaringan, firewall, DNS, cloud subscription.
• Aplikasi produksi (kode, skema basis data, parameter keamanan).
• Integrasi antar sistem dan alur data.

Pengecualian (tetap dicatat ringkas): perubahan yang telah didefinisikan sebagai standar dalam katalog DTSI-SOP-OPS-10 dengan runbook terukur dan risiko rendah—daftar pengecualian disetujui Kepala DTSI dan ditinjau semesteran.

3. Dokumen terkait

Dokumen	Relasi
DTSI-SOP-OPS-09	Rilis ke produksi
DTSI-SOP-OPS-06	Pembaruan CMDB pasca perubahan
DTSI-SOP-INC-02	Perubahan dari insiden / hotfix
DTSI-SOP-ACC-01	Dampak akses
DTSI-SOP-ADM-01	Rekaman RFC

4. Definisi

Istilah	Makna
RFC (Request for Change)	Dokumen/tiket perubahan berisi latar belakang, cakupan, risiko, rencana, rollback.
CAB (Change Advisory Board)	Forum keputusan perubahan; anggota diisi institusi.
ECAB	CAB darurat untuk perubahan mendesak.

5. Model klasifikasi perubahan

Tipe	Kriteria ringkas	Persetujuan	Jadwal
Standar	Rendah risiko, prosedur teruji, dalam daftar resmi	Pelaksana + verifikasi otomatis/manajer	Kapan saja sesuai runbook
Normal	Risiko sedang/tinggi, dampak multi-pengguna	CAB atau delegasi sesuai matriks	Jendela maintenance
Darurat	Ancaman keamanan atau outage besar; penundaan membahayakan	ECAB minimal: Kepala DTSI + pemilik layanan + ahli teknis	Segera, PIR wajib

[Diisi institusi: matriks detail jenis sistem → tingkat persetujuan.]

6. Komposisi CAB (indikatif)

• Kepala DTSI (ketua) atau wakil berwenang.
• Manajer infrastruktur / aplikasi terkait.
• Perwakilan keamanan informasi.
• Pemilik layanan bisnis terdampak.

Notulen CAB disimpan bersama RFC.

7. Peran dan tanggung jawab

Peran	Tanggung jawab
Pemohon perubahan	Mengajukan RFC lengkap, UAT bila diminta.
Manajer perubahan	Menjadwalkan CAB, memantau backlog, memastikan PIR.
Pelaksana	Implementasi sesuai rencana, dokumentasi langkah.
Kepala DTSI	Keputusan akhir eskalasi dan perubahan darurat strategis.

8. Prosedur — perubahan normal

1. Buat RFC di ITSM: judul, lingkup, alasan bisnis/teknis, jendela waktu, daftar sistem terdampak, pemilik layanan.
2. Analisis dampak & risiko: termasuk keamanan (kerentanan baru, permukaan serangan), kinerja, dan ketersediaan; lampirkan rencana rollback atau titik pemulihan.
3. Konsultasi pemilik layanan bisnis untuk perubahan yang mempengajar proses akademik/keuangan.
4. Jadwalkan review CAB; distribusikan materi minimal [Diisi: mis. 48 jam] sebelum rapat.
5. Keputusan CAB: Setuju / Tolak / Tunda / Setuju bersyarat—catat syarat dan penanggung jawab.
6. Komunikasikan jadwal ke DTSI-SOP-OPS-01 / pengumuman resmi jika ada downtime terencana.
7. Implementasi sesuai DTSI-SOP-OPS-09 bila melibatkan rilis; atau langkah teknis langsung dengan checklist.
8. Verifikasi pasca-implementasi: uji fungsi, pemantauan [Diisi: durasi].
9. Perbarui CMDB (DTSI-SOP-OPS-06).
10. Tutup RFC dengan status dan lampiran bukti.
11. PIR (Post-Implementation Review) untuk perubahan normal berisiko tinggi: dalam [Diisi: 5–10 hari kerja]; dokumentasikan pembelajaran.

9. Prosedur — perubahan darurat

1. Aktifkan ECAB (rapat singkat atau persetujuan berantai terdokumentasi).
2. Implementasi dengan kontrol minimal yang tetap mencakup: siapa yang menyetujui, apa yang diubah, rollback cepat.
3. PIR wajib dalam 5 hari kerja: apakah darurat bisa dicegah, perbaikan proses.

10. Integrasi insiden

1. Hotfix dari insiden tetap memerlukan RFC bertipe Normal/Darurat sesuai risiko; referensi tiket insiden wajib.

Diagram alur ringkas

flowchart TD
  rfc([RFC_masuk]) --> cls{Klasifikasi}
  cls -->|Standar| run[Runbook_dan_tutup]
  cls -->|Normal| cab[CAB_review]
  cls -->|Darurat| ecab[ECAB_cepat]
  cab --> dec{Keputusan}
  dec -->|Setuju| impl[Implementasi_dan_verifikasi]
  dec -->|Tolak| tutup1[Tutup_ditolak]
  ecab --> impl
  impl --> cmdb[Update_CMDB]
  cmdb --> pir{PIR_perlu}
  pir -->|Ya| pir_do[PIR_dokumentasi]
  pir -->|Tidak| tutup2[Tutup_RFC]
  pir_do --> tutup2
  run --> tutup2

11. Rujukan ISO (indikatif)

• ISO/IEC 20000-1 — change management.
• ISO/IEC 27002 — kontrol perubahan dan konfigurasi terkait keamanan.

12. Rekaman wajib

• RFC lengkap, notulen CAB/ECAB, log implementasi, bukti verifikasi, PIR jika wajib.

13. Indikator kinerja

Indikuran	Definisi	Target
RFC tanpa rollback darurat	% perubahan normal tanpa kegagalan kritis	[Diisi]
Kepatuhan PIR	% PIR selesai tepat waktu	100% untuk risiko tinggi
Backlog CAB	Usia RFC menunggu keputusan	[Diisi hari maks]

14. Tinjauan dokumen

Minimal tahunan atau setelah insiden besar akibat perubahan, merger sistem, atau audit.

---

Register SOP: Daftar SOP Operasional