Permintaan akses aplikasi, instalasi software, atau perubahan konfigurasi sering terlihat sederhana sampai antrean tiket menumpuk dan keputusan approval tidak konsisten. Di titik itu biasanya terjadi bolak-balik klarifikasi, eskalasi mendadak, dan risiko akses diberikan ke orang yang salah. Panduan ini membantu Anda membangun alur persetujuan yang jelas, terukur dengan SLA, dan mudah dijalankan oleh helpdesk serta pemilik layanan tanpa menambah birokrasi.
Mulai dari definisi request, kategori, dan batas kewenangan
Approval yang rapi dimulai dari definisi yang jelas. Pastikan semua pihak setuju mana yang termasuk IT request (misalnya akses, perubahan, pengadaan), mana yang incident (gangguan), dan mana yang problem (akar penyebab). Dengan definisi yang tepat, tiket tidak “nyasar” dan approver bisa mengambil keputusan berdasar konteks.
Buat taksonomi request yang cukup rinci untuk mengarahkan approval, tetapi tidak membuat pelapor bingung. Untuk organisasi menengah, 10–20 jenis request inti biasanya sudah memadai; kembangkan bertahap berdasarkan data tiket. Tambahkan atribut sederhana yang menentukan jalur persetujuan, seperti klasifikasi data, tingkat risiko, dan biaya.
Agar kewenangan tidak tumpang tindih, tetapkan siapa boleh menyetujui apa. Contoh: akses email dan akun kolaborasi cukup disetujui atasan langsung, sementara akses ke sistem keuangan perlu persetujuan pemilik aplikasi dan tim keamanan bila relevan. Jangan andalkan ingatan individu; dokumentasikan aturan dan buat mudah dicari.
- Definisikan kategori request dan contoh konkretnya.
- Tentukan data yang wajib diisi pada form (misalnya tujuan, durasi akses, unit kerja).
- Petakan pemilik layanan (service owner) dan pemilik aplikasi (application owner).
- Tetapkan batas biaya dan risiko yang memicu approval tambahan.
- Susun aturan pengecualian (misalnya kondisi darurat) dengan jejak audit.
Rancang tahapan approval yang ringan, tapi aman dan auditable
Banyak workflow gagal karena semua request diperlakukan sama dan berakhir dengan approval berantai yang panjang. Desain yang baik memisahkan jalur cepat untuk permintaan berisiko rendah dan jalur ketat untuk permintaan berdampak tinggi. Prinsipnya: minimal langkah, maksimal kontrol di titik yang tepat.
Petakan perjalanan request dari intake sampai fulfill. Di organisasi menengah, pola efektif biasanya: validasi helpdesk, persetujuan bisnis (atasan/pemilik anggaran), persetujuan teknis (pemilik aplikasi/infra), lalu eksekusi dan konfirmasi. Jika semua tahapan diwajibkan untuk semua request, waktu tunggu akan membengkak dan tim operasional terdorong mencari jalan pintas.
Gunakan pendekatan berbasis risiko untuk menentukan kapan perlu multi-approval. Misalnya instalasi software standar di katalog bisa auto-approve setelah validasi lisensi, sementara software baru harus melewati review keamanan dan persetujuan biaya. Untuk akses data sensitif, tambahkan durasi akses terbatas dan review berkala agar akses tidak tetap tanpa alasan.
SLA approval perlu dipisah dari SLA penyelesaian teknis agar bottleneck terlihat jelas. Tentukan target realistis, misalnya persetujuan atasan 1 hari kerja untuk request standar dan 3 hari kerja untuk request yang butuh review keamanan. Dengan target jelas, penyebab keterlambatan lebih mudah diidentifikasi.
- Tier 1: validasi form dan kelengkapan (helpdesk/service desk).
- Tier 2: persetujuan bisnis (atasan, pemilik anggaran, atau manajer unit).
- Tier 3: persetujuan teknis (pemilik aplikasi, infra, security bila perlu).
- Eksekusi: implementasi oleh tim terkait dengan checklist.
- Penutupan: konfirmasi pengguna dan pencatatan bukti kerja.
Jangan lupa mekanisme delegasi dan fallback. Approver sering cuti atau sibuk; tanpa delegasi tiket akan menggantung. Tetapkan eskalasi otomatis: misalnya jika tidak ada respons dalam 8 jam kerja, notifikasi dikirim ulang; setelah 16 jam kerja, eskalasi ke atasan approver atau pemilik layanan. Pastikan eskalasi tercatat, bukan lewat chat tanpa jejak.
Implementasi di tool, kontrol kualitas, dan perbaikan berkelanjutan
Setelah desain disepakati, implementasi di sistem tiket atau ITSM harus fokus pada pengalaman pengguna dan keterlacakan. Form yang terlalu panjang membuat pengguna mengisi asal-asalan, sementara form yang terlalu pendek memaksa helpdesk menanyakan ulang. Uji dengan 5–10 skenario nyata: karyawan baru minta akses, rotasi jabatan, vendor butuh akses sementara, atau tim proyek butuh resource tambahan.
Bangun guardrail di level workflow. Contoh: tidak bisa memilih aplikasi A tanpa memilih peran (role) yang tersedia; akses berakhir otomatis setelah tanggal tertentu; atau permintaan pengadaan memerlukan lampiran penawaran. Guardrail mengurangi beban review manual dan mempercepat keputusan approver karena konteks sudah tersedia.
Komunikasi rollout sering menentukan keberhasilan penerapan. Selain mengumumkan ada workflow baru, jelaskan perubahan perilaku yang diminta dan berikan contoh pengisian yang benar, serta siapkan template jawaban helpdesk untuk pertanyaan umum. Jika Anda butuh referensi cara menyosialisasikan perubahan workflow lintas fungsi, pendekatan dari rencana rollout workflow yang terkomunikasi dengan baik bisa diadaptasi untuk konteks layanan TI.
Untuk menjaga kualitas, ukur metrik yang tepat sejak hari pertama. Pantau waktu tunggu di tiap tahap, persentase tiket yang ditolak (dan alasannya), serta jumlah rework karena informasi kurang. Dari metrik ini, Anda bisa mengetahui apakah masalah ada di desain kategori, form, atau disiplin approver.
- Lead time end-to-end per jenis request (bukan rata-rata gabungan saja).
- Approval latency per approver/unit.
- Rasio tiket “need more info” dari helpdesk.
- Rasio bypass/penanganan di luar sistem (indikator friksi).
- Temuan audit: akses tanpa approval, approval tanpa data pendukung, atau log tidak lengkap.
Terakhir, buat siklus perbaikan yang ringan tapi rutin. Jadwalkan review bulanan 30–45 menit bersama perwakilan helpdesk, pemilik aplikasi utama, dan keamanan informasi untuk membahas lima masalah teratas dan keputusan perbaikan. Anda tidak perlu merombak workflow tiap bulan; sering cukup memperbaiki satu field form, menyesuaikan jalur approval untuk satu kategori, atau menambahkan template penjelasan yang mengurangi penolakan.
Dengan definisi request yang rapi, jalur persetujuan berbasis risiko, dan metrik yang tepat, tim dapat menurunkan waktu tunggu tanpa mengorbankan kontrol.
Jika perlu, mulai dari satu layanan paling sering diminta dan kembangkan bertahap.
Pelajari lebih lanjut: https://epruvo.com