Panduan Penggunaan
Konsep & cara input setiap layar
Panduan ini menjelaskan konsep ITIL 4 dan data model iTop di balik setiap layar Simpul, langkah-langkah pengisian, serta arti setiap kolom. Setiap bagian dilengkapi tangkapan layar dari data demo dan ilustrasi konsep.
Memulai
Konsep
Simpul adalah aplikasi IT Service Management (ITSM) dan Configuration Management Database (CMDB). Data modelnya mengikuti iTop (Organization, Location, Contact, FunctionalCI, Service, SLA, Ticket) dan alur kerjanya mengikuti praktik ITIL 4.
Aplikasi berisi data demo tiga organisasi: PT Blue Bird Tbk (transportasi), PT Medco Energi Internasional Tbk (energi), dan UIN Sunan Kalijaga Yogyakarta (pendidikan tinggi). Profil organisasi diambil dari sumber publik; perangkat, IP, orang, dan tiket adalah simulasi.
Cara menggunakan / input
- 1Di halaman utama, bagian Demo Perusahaan, klik kartu salah satu perusahaan: PT Blue Bird Tbk, PT Medco Energi, atau UIN Sunan Kalijaga.
- 2Klik Masuk sebagai Tamu (tombol baru aktif setelah perusahaan dipilih). Anda langsung masuk tanpa registrasi, dan seluruh layar hanya menampilkan data perusahaan itu.
- 3Untuk pindah perusahaan, klik nama perusahaan di kanan atas → Ganti ke. Data perusahaan lain tidak pernah tercampur.
- 4Atau klik Masuk, isi email & password akun (admin/agen), lalu klik Masuk.
- 5Setelah masuk Anda diarahkan ke Dashboard. Pita kuning di atas menandakan mode tamu dan menyebut perusahaan demo yang aktif.
- 6Untuk keluar, klik avatar di kanan atas → Keluar.
Keterangan isian & kolom
| Perusahaan demo | Pilihan wajib untuk akun Tamu; menentukan data yang tampil. |
| Alamat email akun terdaftar. | |
| Password | Kata sandi akun. |
| Ingat saya | Sesi tetap aktif setelah browser ditutup. |
💡 Mode tamu tetap bisa membuat tiket dan menjalankan alur kerja, jadi seluruh fitur dapat dicoba pada perusahaan yang dipilih.
Konsep
Data induk (organisasi, lokasi, orang, tim, CI, layanan, SLA, kontrak, FAQ, Known Error) dimuat oleh seeder mengikuti data model iTop. Di aplikasi, layar-layar tersebut bersifat telusur & analisis (lihat, saring, dan klik ke detail).
Data yang diinput langsung oleh pengguna adalah data operasional: tiket (Insiden, Permintaan, Problem, Perubahan), transisi status tiket, dan catatan aktivitas (log publik/privat).
Cara menggunakan / input
- 1Untuk mencatat gangguan, permintaan, problem, atau perubahan: klik + Tiket Baru di kanan atas.
- 2Untuk memproses tiket: buka detail tiket → panel Langkah berikutnya.
- 3Untuk menambah percakapan: kotak Aktivitas & Komunikasi di detail tiket.
- 4Untuk mencari data induk: gunakan filter & kotak cari di tiap layar (CMDB, Kontak, Basis Pengetahuan).
- 5Administrator dapat memuat ulang seluruh data demo dengan perintah
php artisan demo:reset.
Keterangan isian & kolom
| Diinput pengguna | Tiket, transisi status, catatan aktivitas. |
| Dimuat seeder | Organisasi, lokasi, orang, tim, CI, layanan, SLA, kontrak, pengetahuan, event. |
💡 Tombol Bantuan di kanan atas selalu membuka panduan layar yang sedang Anda buka.
Operasional
Konsep
Dashboard adalah ringkasan kesehatan layanan: insiden & permintaan terbuka, kepatuhan SLA 30 hari, MTTR (Mean Time To Resolve), CSAT, jumlah CI, event monitoring aktif, perubahan terjadwal, dan tiket yang sudah melewati SLA.
Grafik menampilkan tren 12 bulan, distribusi prioritas, layanan dengan tiket terbanyak, komposisi CMDB per kelas CI, dan sebaran merek perangkat (multi-vendor).
Cara menggunakan / input
- 1Klik kartu KPI mana pun untuk membuka daftar detailnya (mis. Insiden Terbuka membuka Service Desk dengan filter insiden terbuka).
- 2Lihat tabel Antrean Prioritas: diurutkan dari prioritas tertinggi dan tenggat SLA terdekat. Bilah warna menunjukkan sisa waktu SLA (hijau aman, kuning >70%, merah terlewati).
- 3Klik nama organisasi pada Volume per Organisasi untuk memfokuskan dashboard ke organisasi tersebut.
- 4Arahkan kursor ke grafik untuk melihat nilai detail.
Keterangan isian & kolom
| Kepatuhan SLA | Persentase tiket selesai sebelum batas TTR. |
| MTTR | Rata-rata waktu dari tiket dibuat hingga diselesaikan. |
| CSAT | Rata-rata kepuasan pelapor (1–5) saat tiket ditutup. |
Konsep
Service Desk adalah titik kontak tunggal (Single Point of Contact). Satu antrean memuat empat tipe tiket ITIL: Insiden (gangguan layanan), Permintaan Layanan (hal standar yang diminta pengguna), Problem (akar penyebab insiden berulang), dan Perubahan (penambahan/modifikasi/penghapusan yang berdampak pada layanan).
Setiap tipe memiliki siklus status sendiri (lihat diagram). Tiket terbuka diurutkan di atas tiket yang sudah ditutup.
Ilustrasi konsep
Insiden · Incident Management
Permintaan Layanan · Service Request Management
Problem · Problem Management
Perubahan · Change Enablement
Cabang lain: Insiden → Eskalasi; Permintaan/Perubahan → Ditolak / Tidak Disetujui; Selesai → Buka Kembali.
Cara menggunakan / input
- 1Pilih tab tipe tiket di atas (Semua / Insiden / Permintaan Layanan / Problem / Perubahan).
- 2Saring dengan kotak Cari, status (Terbuka / Selesai / Lewat SLA), Prioritas, dan Tim, lalu klik Filter.
- 3Klik nomor referensi atau judul untuk membuka detail tiket.
- 4Klik Buat Tiket di kanan atas untuk membuat tiket baru dengan tipe yang sedang aktif.
Keterangan isian & kolom
| Ref | Nomor unik: I- (insiden), R- (permintaan), P- (problem), C- (perubahan). |
| SLA | "Lewat" bila batas TTR terlampaui; "Tercapai" bila selesai tepat waktu; durasi = sisa waktu. |
| Tim / Agen | Grup penugasan dan orang yang menangani. |
Konsep
Prioritas tidak dipilih manual, tetapi dihitung otomatis dari matriks Dampak × Urgensi ITIL. Dampak = seberapa luas pengaruhnya (departemen, satu layanan, individu); Urgensi = seberapa cepat harus ditangani.
Dari prioritas, sistem menetapkan batas SLA: TTO (Time To Own — tiket harus diambil agen) dan TTR (Time To Resolve — tiket harus selesai). Permintaan layanan mendapat batas 2× lebih panjang dari insiden.
Ilustrasi konsep
| Dampak ↓ / Urgensi → | 1 Kritis | 2 Tinggi | 3 Sedang | 4 Rendah |
| 1 — Departemen / banyak layanan | P1 | P1 | P2 | P3 |
| 2 — Satu layanan | P1 | P2 | P3 | P4 |
| 3 — Individu | P2 | P3 | P4 | P4 |
TTO 15 mnt
TTR 4 jam
TTO 30 mnt
TTR 8 jam
TTO 2 jam
TTR 24 jam
TTO 4 jam
TTR 72 jam
Cara menggunakan / input
- 1Pilih Tipe tiket: Insiden, Permintaan Layanan, Problem, atau Perubahan.
- 2Pilih Organisasi (atau entitas anak) dan Pelapor / Pemohon. Daftar layanan & CI mengikuti organisasi aktif di pemilih kanan atas.
- 3Pilih Layanan & subkategori — ini menentukan tim yang otomatis ditugaskan.
- 4Isi Judul yang singkat dan spesifik, lalu Deskripsi (gejala, sejak kapan, dampak, langkah yang sudah dicoba).
- 5Pilih CI terdampak bila diketahui (aplikasi, perangkat jaringan, server, PC).
- 6Atur Dampak dan Urgensi di panel kanan; kotak gelap menampilkan prioritas hasil hitung dan sel matriks ikut tersorot.
- 7Untuk Perubahan: pilih jenis (Standard/Normal/Emergency) dan jadwal implementasi.
- 8Klik Simpan Tiket. Anda diarahkan ke halaman detail tiket baru.
Keterangan isian & kolom
| Tipe tiket | Insiden / Permintaan / Problem / Perubahan. |
| Organisasi | Pemilik tiket; entitas anak ditandai "—". |
| Pelapor | Orang yang melapor atau meminta. |
| Layanan & subkategori | Dari katalog layanan; menentukan tim & SLA. |
| Judul / Deskripsi | Wajib / opsional (maks. 5.000 karakter). |
| CI terdampak | Opsional, menghubungkan tiket ke CMDB. |
| Dampak (1–3) | 1 Departemen/banyak layanan, 2 Satu layanan, 3 Individu. |
| Urgensi (1–4) | 1 Kritis, 2 Tinggi, 3 Sedang, 4 Rendah. |
| Jenis perubahan | Standard = pra-disetujui; Normal = lewat CAB; Emergency = lewat ECAB. |
💡 Insiden P1 memiliki TTO 15 menit dan TTR 4 jam (SLA default).
Detail Tiket & Alur Kerja
Konsep
Halaman detail menampilkan semua informasi tiket: deskripsi, CI terdampak, SLA, problem induk/insiden terkait, event monitoring, dan riwayat aktivitas.
Panel Langkah berikutnya hanya menampilkan transisi yang sah untuk status saat ini, sesuai siklus ITIL (mis. insiden: Baru → Ditugaskan → Selesai → Ditutup; perubahan: Baru → Tervalidasi → Menunggu Persetujuan → Disetujui → Terjadwal → Diimplementasi → Dipantau → Ditutup).
Ilustrasi konsep
Insiden · Incident Management
Permintaan Layanan · Service Request Management
Problem · Problem Management
Perubahan · Change Enablement
Cabang lain: Insiden → Eskalasi; Permintaan/Perubahan → Ditolak / Tidak Disetujui; Selesai → Buka Kembali.
Cara menggunakan / input
- 1Klik tombol aksi di panel Langkah berikutnya (mis. Tugaskan). Form konfirmasi muncul.
- 2Untuk Tugaskan: pilih agen dari anggota tim. Untuk Selesaikan: tulis solusi pada kolom catatan.
- 3Klik Konfirmasi. Status berubah, waktu & pelaku tercatat di log, dan status SLA dihitung ulang.
- 4Tulis balasan di kotak Aktivitas & Komunikasi: pilih Log publik (terlihat pelapor) atau Log privat (catatan internal tim), lalu klik Kirim.
- 5Klik CI pada panel CI Terdampak untuk melihat analisis dampaknya, atau klik ref problem induk untuk melihat akar masalah.
Keterangan isian & kolom
| TTO | Batas waktu tiket diambil/ditugaskan. |
| TTR | Batas waktu tiket diselesaikan. |
| Log sistem | Dicatat otomatis setiap perubahan status (abu-abu, miring). |
💡 Status "Selesai" belum berarti ditutup — pelapor/agen menutup setelah solusi dikonfirmasi; tiket bisa dibuka kembali.
Konsep
Event adalah perubahan keadaan yang terdeteksi alat monitoring (Zabbix, PRTG, SolarWinds, Wazuh, PI System, LibreNMS). Severity: info, warning, minor, major, critical.
Event kritis dikorelasikan menjadi insiden (asal tiket "monitoring") sehingga tim dapat bertindak sebelum pengguna melapor.
Cara menggunakan / input
- 1Klik kartu severity untuk menyaring event pada tingkat tersebut (angka = 24 jam terakhir).
- 2Gunakan tab Open / Acknowledged / Closed untuk menyaring status penanganan.
- 3Klik nama CI untuk membuka detail perangkat, atau ref insiden untuk melihat tiket hasil korelasi.
- 4Grafik bertumpuk menunjukkan pola event 7 hari per severity.
Keterangan isian & kolom
| Severity | info, warning, minor, major, critical (merah = kritis). |
| Pesan | Teks alarm dari alat monitoring. |
| CI | Perangkat/aplikasi sumber event; klik untuk detail CI. |
| Sumber | Alat monitoring pengirim event (Zabbix, PRTG, Wazuh, dll.). |
| Status | open (belum ditangani), acknowledged (sedang ditangani), closed. |
| Insiden | Tiket insiden hasil korelasi event, bila ada. |
Konsep
ITIL 4 menyebut praktik ini Change Enablement: memaksimalkan perubahan yang berhasil dengan menilai risiko dan mengotorisasi perubahan.
Tiga jenis: Standard (risiko rendah, pra-disetujui — hijau), Normal (dinilai & disetujui CAB — ungu), Emergency (mendesak, disetujui ECAB — merah). Kalender membantu menghindari bentrok jadwal dan periode rawan.
Cara menggunakan / input
- 1Gunakan tombol ← / → untuk berpindah bulan. Hari ini diberi bingkai biru.
- 2Klik entri pada kalender untuk membuka detail perubahan.
- 3Klik Ajukan Perubahan untuk membuat Request for Change (RFC) baru.
- 4Gulir ke bawah untuk daftar seluruh perubahan beserta risiko, downtime, dan status.
Keterangan isian & kolom
| Warna entri | Hijau = Standard, ungu = Normal, merah = Emergency. |
| Risiko | Tingkat risiko perubahan hasil penilaian. |
| Downtime | Perkiraan waktu layanan tidak tersedia selama implementasi. |
| Jadwal | Diisi pada kolom "Jadwal implementasi" saat membuat tiket Perubahan. |
Konfigurasi (CMDB)
Konsep
Configuration Item (CI) adalah komponen yang perlu dikelola untuk menyediakan layanan. Kelas CI mengikuti hierarki iTop: Physical Device (perangkat jaringan, server, storage, rack, UPS, PC, printer, IP phone, CCTV), Virtualization (hypervisor, VM), Software Instance (DB server, web server, middleware), dan Application (web app, application solution, business process).
Setiap CI memiliki organisasi, lokasi, merek/model, status siklus hidup (implementation, production, stock, obsolete), kritikalitas bisnis, dan tim pendukung.
Ilustrasi konsep
FunctionalCI › PhysicalDevice
Perangkat Jaringan
Server
Storage System
Rack
Enclosure
Power Source / UPS
PC / Laptop
Printer
IP Phone
Periferal / CCTV
FunctionalCI › Virtualization
Hypervisor
Virtual Machine
FunctionalCI › SoftwareInstance
Database Server
Web Server
Middleware
FunctionalCI › Application
Web Application
Application Solution
Business Process
Relasi: Business Process → Application Solution → Software Instance → Virtual Machine → Server (Hypervisor) → Storage/UPS.
Cara menggunakan / input
- 1Pilih kelas CI pada panel kiri untuk menyaring daftar (angka = jumlah CI per kelas).
- 2Cari berdasarkan nama, serial number, atau IP; saring merek, status, dan lokasi, lalu klik Filter.
- 3Klik nama CI untuk membuka detail & analisis dampak.
- 4Klik Lihat Topologi untuk melihat CI jaringan dalam bentuk pohon.
Keterangan isian & kolom
| Kritikalitas | high / medium / low — dampak ke bisnis bila CI gagal. |
| Status | production (aktif), implementation (dipasang), stock (cadangan), obsolete (pensiun). |
Detail CI & Analisis Dampak
Konsep
Detail CI memuat atribut teknis (IP, serial, OS/firmware, CPU/RAM, rack, garansi), layanan & kontrak terkait, serta kontak.
Analisis Dampak menelusuri secara rekursif CI apa saja yang ikut terdampak bila CI ini gagal — melalui relasi dependensi (aplikasi → software → VM → host) dan topologi uplink (core → distribusi → akses → endpoint).
Cara menggunakan / input
- 1Baca breadcrumb di atas judul: jalur uplink dari WAN hingga perangkat ini.
- 2Buka tab Analisis Dampak untuk melihat pohon CI downstream; klik node untuk menelusuri.
- 3Tab Relasi memisahkan upstream (bergantung pada) dan downstream (digunakan oleh).
- 4Tab Interface menampilkan port, IP, MAC, kecepatan, VLAN; tab Tiket & Event menampilkan riwayat operasional.
- 5Klik Laporkan Insiden untuk membuat tiket yang berkaitan dengan CI ini.
💡 Label "Garansi habis" muncul otomatis bila tanggal garansi telah lewat — berguna untuk perencanaan peremajaan.
Konsep
Topologi dibangun dari relasi uplink setiap perangkat (kolom parent pada CI). Hasilnya pohon bertingkat: Internet/ISP → WAN Edge Router → Firewall → Core Switch → Distribusi/ToR → Router site (pool, site lapangan, gedung) → Distribusi → Access Switch → Access Point & Endpoint.
Warna isi node = peran perangkat; warna garis tepi = merek (Cisco, Huawei, MikroTik, Fortinet, Juniper, Ruijie, dll.).
Mode Lokasi menampilkan pohon kantor pusat/kampus → data center, wilayah, gedung → pool/site beserta jumlah CI.
Ilustrasi konsep
Internet / ISP
Telkom, Biznet, Telkomsat
WAN Edge Router
Cisco ASR · Juniper MX · MikroTik CCR
Firewall (HA)
FortiGate · Palo Alto · Sangfor
Core Switch
Catalyst 9500 · QFX · CloudEngine
Distribusi / ToR / Router site
Nexus · Arista · S6730 · ISR/IR1101
Access Switch
Aruba CX · RUGGEDCOM · Ruijie
AP & Endpoint
UniFi · Meraki · Ruckus · PC · CCTV · IP phone
Cara menggunakan / input
- 1Pilih organisasi pada tombol di kiri atas (Blue Bird, Medco, UIN).
- 2Klik satu kali pada node untuk membuka/menutup cabangnya dan menampilkan kartu ringkasan (peran, IP, lokasi, jumlah turunan).
- 3Klik dua kali pada node untuk membuka halaman detail CI.
- 4Scroll untuk zoom, drag untuk menggeser. Gunakan Buka semua, Ringkas, dan Pas layar.
- 5Centang Tampilkan endpoint untuk menyertakan PC, printer, CCTV, IP phone, dan server.
- 6Ganti ke mode Lokasi untuk melihat hierarki lokasi.
Keterangan isian & kolom
| Organisasi | Tombol di kiri atas; topologi selalu per satu organisasi induk. |
| Mode Jaringan / Lokasi | Pohon uplink perangkat atau pohon hierarki lokasi. |
| Tampilkan endpoint | Centang untuk menambah PC, printer, CCTV, IP phone, dan server. |
| Warna isi / tepi node | Isi = peran perangkat; tepi = merek. |
Konsep
Lokasi bersifat hierarkis: kantor pusat/kampus memiliki data center, wilayah, dan gedung; wilayah memiliki pool atau site lapangan. Setiap CI dan orang ditempatkan pada satu lokasi.
Cara menggunakan / input
- 1Telusuri pohon lokasi per organisasi.
- 2Klik angka CI untuk membuka CMDB yang tersaring ke lokasi tersebut.
- 3Gunakan pemilih organisasi kanan atas untuk menampilkan satu organisasi saja.
Keterangan isian & kolom
| Tipe | hq, campus, datacenter, region, office, building, pool, site. |
Konsep
Tipologi Brand → Model (iTop) memudahkan standarisasi perangkat, perencanaan suku cadang, dan negosiasi kontrak vendor di lingkungan multi-vendor.
Cara menggunakan / input
- 1Baca matriks merek × organisasi: angka = jumlah perangkat; warna makin pekat = makin banyak.
- 2Klik nama merek untuk membuka CMDB tersaring ke merek tersebut.
- 3Kartu di bawah merinci model per merek beserta kelas CI-nya.
Keterangan isian & kolom
| Angka matriks | Jumlah perangkat merek tersebut di organisasi itu. |
| Model | Tipe perangkat per merek beserta kelas CI-nya. |
Layanan
Konsep
Struktur katalog iTop: Service Family → Service → Service Subcategory. Subkategori bertipe insiden (merah) atau permintaan layanan (biru) dan dipakai saat membuat tiket.
ITIL 4 menambahkan sudut pandang value stream — rangkaian langkah penciptaan nilai, mis. "Pemesanan Perjalanan", "Produksi Migas", "Siklus Akademik".
Cara menggunakan / input
- 1Pilih tampilan Per Service Family atau Per Value Stream.
- 2Klik kartu layanan untuk melihat subkategori, CI pendukung, kontrak & SLA, statistik 90 hari, dan tiket terbaru.
- 3Klik Ajukan Tiket dari halaman layanan.
Keterangan isian & kolom
| Service Family | Kelompok layanan (Konektivitas, Aplikasi Bisnis, Keamanan, dst.). |
| Value stream | Rangkaian penciptaan nilai yang didukung layanan. |
| Subkategori merah / biru | Merah = untuk insiden, biru = untuk permintaan layanan. |
Detail Layanan
Konsep
Halaman ini menyatukan semua yang menopang satu layanan: subkategori (jenis insiden/permintaan yang dapat diajukan), CI pendukung (aplikasi, server, perangkat jaringan), kontrak & SLA yang mengikat, statistik 90 hari, dan tiket terbaru.
Dengan melihat CI pendukung dan tiket sekaligus, pemilik layanan dapat menilai apakah gangguan berasal dari komponen tertentu.
Cara menggunakan / input
- 1Baca panel Subkategori: label merah untuk insiden, biru untuk permintaan layanan.
- 2Klik CI pada panel CI pendukung untuk membuka detail & analisis dampaknya.
- 3Periksa panel Kontrak & SLA untuk mengetahui target TTO/TTR yang berlaku.
- 4Klik Ajukan Tiket untuk membuat tiket; di form, pilih layanan ini pada isian Layanan & subkategori.
- 5Klik ref pada Tiket terbaru untuk membuka detail tiket.
Keterangan isian & kolom
| Subkategori | Pilihan \"Layanan & subkategori\" saat membuat tiket; menentukan tim penanganan. |
| CI pendukung | Komponen CMDB yang menjalankan layanan. |
| Kartu statistik | Jumlah insiden & permintaan 90 hari terakhir, tiket lewat SLA, dan jumlah CI pendukung. |
Konsep
SLA (Service Level Agreement) berisi sekumpulan SLT (Service Level Target). Setiap SLT = prioritas × tipe permintaan × metrik (TTO/TTR) × nilai. Demo menyediakan SLA Gold (24×7 untuk layanan kritis) dan SLA Standar (jam kerja, 1,5× lebih longgar).
Cara menggunakan / input
- 1Bandingkan target TTO/TTR per prioritas untuk insiden dan permintaan.
- 2SLA dihubungkan ke layanan melalui kontrak pelanggan/OLA (layar Kontrak).
Keterangan isian & kolom
| Prioritas | P1 Kritis s.d. P4 Rendah, hasil matriks Dampak × Urgensi. |
| TTO | Time To Own: batas tiket diambil/ditugaskan. |
| TTR | Time To Resolve: batas tiket diselesaikan. |
| Insiden / Permintaan | Target dibedakan per tipe tiket; permintaan lebih longgar. |
Konsep
Customer contract / OLA mengikat layanan + SLA kepada pelanggan internal (induk & entitas anak). Provider contract adalah kontrak vendor: konektivitas (Telkom, Telkomsat, Biznet), dukungan perangkat (Cisco, Fortinet, Juniper, Huawei), dan lisensi (Microsoft, SAP) — praktik Supplier Management.
Cara menggunakan / input
- 1Pantau kolom status: Berakhir N hari (kuning) muncul bila kontrak habis < 90 hari.
- 2Lihat CI yang tercakup oleh setiap kontrak vendor.
- 3Gulir ke bawah untuk daftar OLA per entitas.
Keterangan isian & kolom
| Tipe | Konektivitas, dukungan perangkat, atau lisensi (kontrak vendor). |
| Periode | Tanggal mulai s.d. berakhir kontrak. |
| Nilai | Nilai kontrak dalam Rupiah. |
| CI tercakup | Perangkat/aplikasi yang didukung kontrak vendor. |
| Status | Aktif, atau "Berakhir N hari" (kuning) bila kurang dari 90 hari. |
| Pelanggan / Penyedia / SLA | Pada OLA: siapa menerima layanan, siapa menyediakan, dan SLA yang berlaku. |
Pengetahuan & Orang
Konsep
FAQ untuk self-help pengguna (mengurangi tiket level-1). Known Error adalah problem yang akar masalah dan workaround-nya sudah diketahui — hasil Problem Management. Dokumen memuat kebijakan, prosedur, dan runbook.
Cara menggunakan / input
- 1Ketik kata kunci di kotak pencarian (mis. "eduroam", "VPN", "SAP") lalu klik Cari.
- 2Klik kartu FAQ untuk membaca langkah penyelesaian. Bila tidak membantu, klik Tidak, buat tiket.
- 3Klik Known Error untuk melihat gejala, akar masalah, workaround, solusi, dan problem terkait.
Keterangan isian & kolom
| Kotak pencarian | Kata kunci dicocokkan ke judul, ringkasan, dan kata kunci artikel. |
| FAQ | Panduan swalayan untuk pengguna. |
| Known Error | Masalah dengan akar penyebab & workaround yang sudah diketahui. |
| Dokumen | Kebijakan, prosedur, runbook. |
Artikel FAQ
Konsep
FAQ adalah artikel swalayan (self-help) yang memandu pengguna menyelesaikan masalah umum tanpa membuat tiket — praktik Knowledge Management dan shift-left ke level 0.
Cara menggunakan / input
- 1Baca Ringkasan untuk memastikan artikel sesuai masalah Anda.
- 2Ikuti Langkah penyelesaian secara berurutan.
- 3Bila masalah belum selesai, klik Tidak, buat tiket di bagian bawah artikel untuk membuat Insiden/Permintaan.
Keterangan isian & kolom
| Kategori | Kelompok topik FAQ (Akun & Password, Jaringan & Wi-Fi, Keamanan, dst.). |
| Kata kunci | Istilah yang dipakai pencarian Basis Pengetahuan. |
| Dilihat | Jumlah kali artikel dibuka (indikator topik yang sering ditanyakan). |
Known Error
Konsep
Known Error adalah problem yang akar masalah dan workaround-nya sudah diketahui. Agen memakai Known Error untuk memulihkan insiden serupa dengan cepat sambil menunggu solusi permanen.
Cara menggunakan / input
- 1Cocokkan Gejala dan Kode error dengan insiden yang sedang ditangani.
- 2Terapkan Workaround untuk memulihkan layanan, lalu catat di log tiket.
- 3Klik Buka problem P-… untuk melihat analisa dan progres solusi permanen.
Keterangan isian & kolom
| Gejala | Tanda yang dilihat pengguna/agen. |
| Kode error | Pesan/kode teknis bila ada. |
| Akar masalah | Penyebab hasil Problem Management. |
| Workaround | Cara sementara memulihkan layanan. |
| Solusi permanen | Perbaikan tuntas; \"Belum tersedia\" bila problem masih dianalisa. |
Konsep
Person mencakup pelapor, agen, dan manajer. Team adalah grup penugasan tiket (Service Desk, Network, Data Center, Security, dst.). Satu orang dapat menjadi anggota beberapa tim dengan peran (Team Lead, Agent L1/L2/L3).
Cara menggunakan / input
- 1Lihat kartu tim: anggota (arahkan kursor ke avatar untuk nama & peran) dan jumlah tiket terbuka.
- 2Klik N tiket terbuka untuk membuka antrean tim tersebut.
- 3Cari orang berdasarkan nama atau jabatan pada tabel di bawah.
Keterangan isian & kolom
| Cari | Ketik nama atau jabatan, lalu Enter. |
| Jabatan | Fungsi orang di organisasinya. |
| Tim | Grup penugasan tempat orang itu menjadi anggota. |
| Kontak | Email/telepon kerja. |
Konsep
Organisasi adalah pemilik data (multi-tenant). Organisasi induk dapat memiliki entitas anak (mis. PT Big Bird Pusaka di bawah PT Blue Bird Tbk; PT Medco Power Indonesia di bawah Medco).
Cara menggunakan / input
- 1Bandingkan jumlah lokasi, orang, tim, CI, layanan, dan tiket per organisasi.
- 2Klik Fokus ke organisasi ini untuk mengaktifkan filter organisasi di seluruh aplikasi.
Keterangan isian & kolom
| Entitas anak | Organisasi di bawah induk; ikut tersaring saat induk dipilih. |
| Angka ringkasan | Jumlah lokasi, orang, tim, CI, layanan, dan tiket milik organisasi. |
ITIL 4
Konsep
ITIL 4 memandang manajemen layanan sebagai Service Value System: peluang/permintaan diubah menjadi nilai melalui Service Value Chain (Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support), dipandu 7 guiding principles, dan dijalankan oleh 34 praktik.
Layar ini memetakan setiap aktivitas value chain dan praktik ITIL 4 ke modul aplikasi, serta modul data model iTop ke praktik ITIL 4.
Ilustrasi konsep
Dipandu 7 guiding principles · didukung 34 praktik · ditingkatkan terus-menerus.
Cara menggunakan / input
- 1Klik kotak aktivitas value chain untuk membuka modul terkait.
- 2Praktik bertanda ✓ hijau dapat diklik menuju layar pendukungnya; lingkaran putus-putus = belum didukung modul.
- 3Gulir ke tabel pemetaan iTop → ITIL 4 untuk memahami asal data model.
Keterangan isian & kolom
| Value chain | Enam aktivitas: Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support. |
| Praktik ✓ | Didukung modul aplikasi (dapat diklik). |
| Lingkaran putus-putus | Praktik belum didukung modul. |
Konsep
Continual Improvement adalah praktik yang menyelaraskan layanan dengan kebutuhan bisnis yang berubah. Setiap inisiatif dicatat di register (CIR) dengan praktik terkait, guiding principle, manfaat, pemilik, progres, dan target — dijalankan dengan model 7 langkah CI.
Cara menggunakan / input
- 1Baca papan kanban: Diusulkan → Disetujui → Berjalan → Selesai.
- 2Bilah progres menunjukkan persentase penyelesaian; nama pemilik dan target bulan tertera di bawahnya.
- 3Gulir ke bawah untuk model 7 langkah Continual Improvement.
Keterangan isian & kolom
| Kolom kanban | Status inisiatif: Diusulkan, Disetujui, Berjalan, Selesai. |
| Praktik / prinsip | Praktik ITIL 4 dan guiding principle yang terkait. |
| Manfaat | Hasil yang diharapkan dari inisiatif. |
| Progres | Persentase penyelesaian. |
| Pemilik & target | Penanggung jawab dan bulan target selesai. |
Konsep
Praktik Measurement & Reporting: kepatuhan SLA (TTO & TTR) bulanan terhadap target 90%, MTTR bulanan, kanal masuk tiket, kode resolusi, heatmap beban (hari × jam), dan kinerja per tim.
Cara menggunakan / input
- 1Bandingkan kartu SLA, CSAT, dan volume per organisasi di bagian atas.
- 2Gunakan heatmap untuk merencanakan jadwal shift agen (warna pekat = jam sibuk).
- 3Tabel kinerja tim menampilkan tiket selesai, SLA TTR, MTTR, dan CSAT 90 hari.
Keterangan isian & kolom
| Kepatuhan SLA | Persentase tiket memenuhi TTO/TTR per bulan, dibanding target 90%. |
| MTTR | Rata-rata jam penyelesaian per bulan. |
| Kanal masuk | Asal tiket: portal, email, telepon, monitoring. |
| Kode resolusi | Cara tiket diselesaikan (fixed, workaround, dll.). |
| Heatmap | Jumlah tiket per hari × jam; makin pekat makin sibuk. |
Profil organisasi bersumber dari Laporan Tahunan 2025 PT Blue Bird Tbk & PT Medco Energi Internasional Tbk serta uin-suka.ac.id. Seluruh perangkat, IP, nama orang, dan tiket adalah data simulasi.