Menyusun katalog layanan dan alur permintaan TI

Apa isi katalog layanan?

Katalog layanan menjelaskan layanan yang dapat diminta pengguna, bukan sekadar daftar aplikasi. Untuk setiap layanan, tulis manfaat, pengguna yang berhak, pemilik, jam dukungan, cara meminta serta pekerjaan yang termasuk dan dikecualikan.

Ringkasan publik ISO 20000-1 menjadi konteks pengelolaan layanan. Format dan alur berikut contoh Kompli; bukan isi lengkap standar atau jaminan sertifikasi. Dasar pengelolaan tetap di persiapan manajemen layanan.

Contoh tiga layanan berbeda

Organisasi fiktif memulai dari layanan yang sering ditanyakan. Tabel ini bukan komitmen dukungan nyata atau katalog layanan yang ditawarkan Kompli.

Layanan	Isi singkat katalog contoh
Akses aplikasi kerja	Pegawai yang memenuhi peran; pemilik aplikasi; permintaan melalui tiket, persetujuan pemilik data, masa berlaku dan pemeriksaan izin. Tidak mencakup akses admin otomatis.
Dukungan aplikasi pesanan	Pengguna internal; pemilik operasi; laporan gangguan, jam bantuan dan jalur eskalasi. Penambahan fitur memakai proses perubahan terpisah.
Permintaan ekspor laporan	Pengguna berizin; pemilik data; tujuan, rentang dan penerima diperiksa. Tidak mencakup pengiriman semua data pelanggan melalui grup umum.

Jam dan target dipilih sesuai kemampuan serta kebutuhan organisasi. Katalog menunjuk SLA dan pembagian tanggung jawab, bukan membuat angka SLA baru yang saling bertentangan.

Bedakan permintaan, gangguan dan perubahan

Permintaan akun baru mengikuti alur permintaan. Pengguna tidak bisa masuk padahal seharusnya berhak mengikuti penanganan gangguan. Penambahan metode login mengikuti penilaian perubahan. Jangan meminta pengguna membuat “permintaan biasa” untuk menyembunyikan gangguan dari pengukuran layanan.

Masalah berulang dirujuk ke manajemen problem. Masing-masing catatan mempunyai tujuan, meski bisa saling terhubung.

Contoh alur permintaan akses

REQ-DEMO-01 adalah permintaan buatan untuk akses sementara aplikasi pesanan. Tidak ada akun yang dibuat, persetujuan manusia atau tiket yang benar-benar dijalankan pada contoh ini.

1. Pemohon menyebut peran, pekerjaan, sistem dan masa akses; jangan menulis kata sandi di tiket.
2. Pemilik data/layanan memeriksa kebutuhan serta izin yang tepat. Keanggotaan grup percakapan tidak menjadi persetujuan.
3. Pelaksana yang berwenang menerapkan izin melalui prosedur sistem dan mencatat perubahan.
4. Pengguna memeriksa pekerjaan yang dibolehkan; petugas juga memeriksa batas yang harus ditolak.
5. Catat hasil, waktu selesai dan pemilik pencabutan saat masa akses berakhir. Permintaan ditutup jika kriteria yang disepakati terbukti.

Ini rencana kerja, bukan uji izin aplikasi. Gunakan checklist akses pegawai untuk pemeriksaan joiner, perubahan peran dan penutupan akses yang sudah dimiliki halaman tersebut.

Tentukan status dan alasan penundaan

Sediakan status yang dapat dipahami: diterima, menunggu informasi, menunggu persetujuan, dikerjakan, selesai atau ditolak. Catat pemilik dan alasan; balasan otomatis belum menunjukkan pekerjaan mulai ditangani.

Sepakati apa yang diukur, jam layanan dan aturan menunggu sebelum membuat laporan. Penundaan oleh vendor tidak boleh hilang dari catatan. Hindari memindahkan tiket ke status “menunggu pengguna” tanpa benar-benar meminta informasi.

Periksa katalog bersama pengguna

Minta pengguna mencoba menemukan satu layanan dan memahami alurnya. Catat pertanyaan yang belum terjawab, tautan yang sulit ditemukan dan permintaan yang sering salah kategori. Ini saran evaluasi; latihan manusia belum dilaksanakan dalam contoh.

Tinjau pemilik, jam, target, integrasi dan batas setelah perubahan. Katalog yang mudah dibaca membantu mengurangi kebingungan, tetapi tetap memerlukan petugas serta kemampuan pelaksanaan yang nyata.