Embed Size (px)
Citation preview
23
BAB IV
HASIL DAN PEMBAHASAN
Pada bab 4 ini akan membahas hasil analisis untuk pembuatan dokumen-
dokumen yang dibutuhkan Service Level Management seperti: (1) Service
Level Agreement, (2) Service Level Requirement, (3) Operation Level
Agreement, (4) Service Improvement Plan, (4) Mekanisme yang dibutuhkan
Service Level Management. Dalam bab ini juga menjelaskan hasil dari tahap
awal, tahap pengembangan hingga tahap akhir.
4.1 Hasil Tahap Awal
Seperti yang telah dijelaskan dalam bab 3, dalam tahap awal ini
menggunakan 4 tahapan yaitu: (a) studi literatur, (b) wawancara (c) observasi.
4.1.1 Studi Literatur
Sebelum memproses data yang didapatkan dari pihak PPTI, sebagai
acuan dan pengolahan data diperlukan teori-teori pendukung sehingga lebih
memahami dan memperkuat pengertian tentang Service Level Management.
Berdasarkan studi literatur yang diperlukan untuk memperkuat pengertian,
maka pada penelitian ini terdapat beberapa hasil yaitu:
1. IT Sevice Management
2. ITIL V3
3. Service Design
4. Service Level Management
5. Service Level Agreement
6. Service Level Requirement
24
7. Operational Level agreement
8. Service Improvement Plan dan
9. Standar Operation Prosedur
4.1.2 Wawancara
Pada proses wawancara yang dilakukan di PPTI, terdapat 3 bagian yang
diwawancarai yaitu Ibu Sri Suhandiah selaku Kepala Bagian PPTI, Bapak
Slamet selaku Kepala Sie Pengembangan Jaringan, dan Ibu Lina Indrawati
selaku Kepala Sie Pengembangan Sistem Informasi. Berdasarkan proses
wawancara, data yang diperoleh yaitu:
1. Tugas dan Pokok per bagian yang ada di PPTI yang dapat dilihat pada Tabel
4.8
2. Proses Bisnis PPTI
3. Layanan dominan yang diteliti yang dapat dilihat pada Tabel 4.2
4. Target per layanan yang diteliti yang dapat dilihat pada Tabel 4.4
Berdasarkan data yang diperoleh dari wawancara, diketahui bahwa PPTI
merupakan salah satu unit kerja Stikom Surabaya yang berfungsi menjamin
berlangsungnya semua kegiatan operasional yang menggunakan perangkat TI
serta menerapkan teknologi baru untuk mendukung proses bisnis Stikom
Surabaya.
Pada profil PPTI ditemukan bahwa PPTI dibagi menjadi dua sie yaitu (a)
Sie Pengembangan Jaringan dan Sie Pengembangan Sistem Informasi seperti
yang tertera pada Gambar 4.1 struktur organisasi PPTI.
25
Gambar 4. 1 Struktur Organisasi PPTI
Dalam Gambar 4.1 terlihat bahwa PPTI dikepalai oleh Kepala Bagian.
Kepala Bagian membawahi 2 bagian yaitu:
1. Bagian Pengembangan Jaringan, bertanggung jawab terhadap ketersediaan
jaringan untuk pelaksanaan teknologi komunikasi seluruh sivitas akademika
yang memiliki Sub.Bag Administrasi Jaringan
2. Bagian Pengembangan Sistem Informasi, bertanggung jawab terhadap
penyediaan sistem informasi yang diperuntukkan bagi seluruh sivitas
akademika yang memiliki Sub.Bag sebagai berikut:
a. Database Programmer
b. Web Programmer
c. Data Center
Berdasarkan data yang diperoleh dalam PPTI terdapat 81 layanan
aplikasi yang dibagi terbagi menjadi 2 kategori yaitu manajerial dan
operasional yang dapat dilihat pada tabel 4.1 kategori dan deskripsi kategori
layanan.
26
Tabel 4. 1 Kategori dan Deskripsi Kategori Layanan
Kategori Deskripsi
Manajerial
Layanan aplikasi yang digunakan untuk mengambil
keputusan dan mengelola Institut Bisnis dan Informatika
Stikom Surabaya.
Operasional
Layanan aplikasi yang digunakan untuk melakukan
untuk mendukung kebutuhan pengguna yang dalam hal
ini adalah karyawan, dosen dan mahasiswa serta
kegiatan keseharian sebagai pendukung proses bisnis.
Terdapat layanan yang paling dominan yang ditemukan dan digunakan
pada penelitian ini sebagai bahan perencanaan Service Level Management ada
lima layanan yang dapat dilihat pada tabel 4.2.
Tabel 4. 2 Deskripsi Layanan
Layanan Deskripsi
Stikomapps Adalah sebuah layanan aplikasi web portal untuk mengakses
aplikasi keseluruhan yang ada dalam domain stikom.edu,
beberapa aplikasi GAFE (GoogleApps For Education)
tersebut seperti: email, drive, serta akses informasi untuk
mendukung kegiatan mahasiswa.
Sicyca Adalah aplikasi berbasis web untuk memberikan informasi
kepada mahasiswa STIKOM Surabaya seputar kehidupan
kampus, baik itu perkuliahan, perpustakaan, keuangan, dan
lain-lain.
Brilian Adalah sebuah aplikasi berbasis web untuk mendukung
pembelajaran mahasiswa.
Jaringan via
kabel
Adalah sebuah layanan akses data untuk menghubungkan dari
komputer ke komputer sebuah jaringan melalui perantara
kabel (LAN).
27
Layanan Deskripsi
Jaringan via
nirkabel
Adalah sebuah layanan akses data untuk menghubungkan dari
komputer ke sebuah jaringan melalui perantara nirkabel
(WLAN).
4.1.3 Observasi
Untuk mendukung hasil wawancara dilakukan observasi secara langsung
pada bagian PPTI sehingga mengetahui jalannya proses bisnis yang dilakukan
PPTI dan mengetahui bagaimana setiap data yang diperoleh pihak PPTI
diproses. Terdapat dua macam proses bisnis yang ber berjalan di PPTI, yaitu
proses bisnis utama dan proses bisnis pendukung. Proses bisnis utama dari
PPTI yaitu:
1. PPTI menyediakan layanan STI (Stikomapps, Sicyca, Brilian, jaringan dan
sebagainya).
2. PPTI mengembangkan sistem informasi yang berjalan di Stikom Surabaya.
28
3. PPTI mengelola data center.
4. Proses fitur dan aktifitas layanan yang dapat dilihat pada Tabel 4.8.
Sedangkan proses bisnis pendukung PPTI adalah penanganan keluhan
yang terjadi pada layanan STI yang disediakan.
4.2 Hasil Tahap Pengembangan
Tahap ini menjelaskan proses pengolahan data yang diperoleh dari hasil
tahap awal. Tahap ini menjelaskan beberapa proses yaitu (a) Merumuskan
Service Level Agreement, (b) Merumuskan Service Level Requirement, (c)
Merumuskan Operational Level Agreement, (d) Merumuskan Service
Improvement Plan, (e) Merumuskan Mekanisme pengelolaan Tingkat Layanan.
4.2.1 Mendesain Service Level Agreement Framework
Penyedia layanan harus menentukan framework yang akan dipakai dalam
mendesain SLA yang dibutuhkan. Dalam observasi serta wawancara terkait
dengan pelayanan yang ada dalam PPTI Stikom Surabaya, maka Framework
SLA yang paling cocok untuk penyedia layanan seperti PPTI Stikom Surabaya
adalah Service Based SLA yang dapat di ilustrasikan pada Gambar 4.3 sebagai
berikut:
29
Gambar 4. 2 Service Based SLA
Dalam gambar 4.2 adalah gambaran dari framework SLA berbasis
layanan, framework ini membuat SLA dalam setiap layanan yang dibuat.
framework ini paling cocok dipakai oleh PPTI Stikom Surabaya dikarenakan
bagian PPTI membuat suatu layanan berdasarkan kebutuhan layanan yang
diperlukan untuk menunjang proses bisnis yang lain, dan bagian PPTI Stikom
Surabaya tidak membuat suatu layanan berdasarkan kebutuhan tiap-tiap
pengguna. Ini membuat layanan menjadi terasa adil serta lebih efektif.
4.2.2 Perumusan Service Level Reqirement (SLR)
Dalam perumusan Service Level Requiremet (SLR), dapat diperhatikan
bahwa tidak semua layanan memerlukan dokumen SLR dan untuk layanan
yang sudah ada sebelum dibuatnya Service Level Management, maka dokumen
ini tidak perlu dibuat atau dapat dilewati. Ini dikarenakan bahwa dokumen ini
hanya sebagai draft pembantu dalam merancang SLA, sehingga SLR berisi
kebutuhan-kebutuhan pengguna untuk aspek layanan TI. SLR mengacu pada
30
tujuan bisnis organisasi dan digunakan untuk menegosiasikan kesepakatan
untuk membuat target layanan seperti seberapa besar target layanan tersebut,
bagaimana cara penyediaan layanan tersebut, seberapa tinggi tingkat
keamanannya, hingga seberapa cepat data harus di backup/restore.
Dalam hal ini 5 layanan PPTI yang dibahas, SLR digunakan untuk
mengetahui kebutuhan-kebutuhan apa saja untuk membuat layanan tersebut.
A. Memilih dan menentukan kebutuhan layanan
Berdasarkan layanan yang paling dominan yang dipunyai PPTI adalah
lima layanan yaitu:
1. Stikomapps
2. Sicyca
3. Brilian
4. Jaringan via kabel
5. Jaringan via nirkabel.
Meskipun dokumen SLR dibuat hanya untuk layanan yang belum ada,
namun dokumen ini tetap diperlukan sebagai acuan untuk mendukung
dokumen SLA. Setelah layanan telah terpilih, kebutuhan layanan dibuat untuk
mengetahui bagaimana layanan tersebut akan dibangun dengan langkah
sebagai berikut:
a. Mendeskripsikan layanan, berfungsi untuk memperjelas dan meminimalisir
kesalah pahaman pengguna layanan yang dapat dilihat pada Tabel 4.2.
b. Memberi batasan yang jelas pada layanan, hal ini berguna sebagai acuan
agar layanan dapat konsisten sesuai dengan kebutuhan awal yang dapat
dilihat pada Tabel 4.3 batasan layanan SLR.
31
Tabel 4. 3 Batasan Layanan SLR
Layanan Batasan
Stikomapps STIKOMAPPS mencakup portal layanan semua link
yang terdaftar pada domain stikom.edu yang
dikategorikan menjadi 3 yaitu: Akademik, Unit
Kegiatan Mahasiswa dan Unit Kegiatan Kerohanian.
Sicyca Sicyca memiliki fungsi untuk memantau akademis
dan non akademis sivitas Institut Bisnis dan
Informatika Stikom Surabaya.
Brilian Brilian hanya diakses oleh mahasiswa dan dosen
yang mempunyai kesamaan kelas.
Jaringan via kabel Hingga ke pengguna, namun dalam penanganannya
PPTI berkoordinasi dengan Administrasi Umum
untuk teknisnya PPTI menangani mulai dari server
hingga titik switch dan Administrasi Umum
menangani dari titik switch hingga komputer
pengguna.
Jaringan via nirkabel Hingga ke pengguna, namun dalam penanganannya
PPTI berkoordinasi dengan Administrasi Umum
untuk teknisnya PPTI menangani mulai dari server
hingga titik switch dan Administrasi Umum
menangani dari titik switch hingga komputer
pengguna.
c. Membuat target untuk layanan, berguna sebagai acuan sebesar apa target
dari layanan yang harus PPTI penuhi yang dapat dilihat pada tabel 4.4 target
layanan. Target layanan ini terdapat 4 aspek yaitu: (1) Ketersediaan, (2)
Load Time, (3) Keamanan dan (4) Kompabilitas. Pada target ini pada aspek
ketersediaan didapatkan melalui hasil dari service availibility management,
lalu untuk load time didapatkan dari proses pengetesan load time yang
32
dilakukan melalui sebuah website tools.pingdom.com yang menghitung load
time menggunakan jaringan stikom surabaya dengan kecepatan up to
100kbps/user sebanyak 5 kali yang dapat dilihat pada Tabel 4.4
Tabel 4. 4 Hasil Percobaan untuk load time
Uji kolom
Layanan 1 2 3 4 5 maks
Stikomapps 3,09
detik
2,86
detik
2,81
detik
3,72
detik
2,43
detik
3,72 ≈
4
detik
Sicyca 6,96
detik
5,18
detik
5,79
detik
7,29
detik
7,65
detik
7,65 ≈
8
detik
Brilian 3,81
detik
2,85
detik
3,59
detik
3,02
detik
3,92
detik
3,92 ≈
4
detik
lalu untuk keamanan dan kompabilitas didapatkan berdasarkan wawancara
dengan sie pengembangan sistem informasi
Tabel 4. 5 Target Layanan
Layanan Target
Stikomapps Menjadi portal dari semua layanan yang ada di
stikom.edu serta GAFE (google for education) dan
memberikan informasi link yang terdaftar pada
domain stikom.edu.
Ketersediaan: 99%
Load time: < 4 detik
Keamanan: login menggunakan password yang
dienkripsi
Kompatibilitas: semua browser yang bisa
menjalankan java
Sicyca Memberikan fitur berdasarkan kebutuhan pengguna
yaitu: SIIS LAMA, Dashboard, Menu Akademik,
33
Layanan Target
Menu Keuangan, Menu Perpustakaan, E-Resource,
Menu PPTA, Menu Komunitas, Feedback.
Ketersediaan: 99%
Load time: < 8 detik
Keamanan: login menggunakan password yang
dienkripsi
Kompatibilitas: semua browser yang bisa
menjalankan java
Brilian Memberikan fitur yang berguna untuk pendukung
proses belajar mengajar dikelas dan berdasarkan
kebutuhan.
Ketersediaan: 99%
Load time: < 4 detik
Keamanan: login menggunakan password yang
dienkripsi
Kompatibilitas: semua browser yang bisa
menjalankan java
Jaringan via kabel Target dari layanan jaringan via kabel:
1. Memiliki Up Time sebesar 95,89% per tahun.
2. Kecepatan yang tersedia untuk jaringan lokal
100Mbps/User.
3. Kecepatan yang tersedia untuk jaringan internet
100Kbps/User.
Jaringan via nirkabel Target dari layanan jaringan via kabel:
1. Memiliki Up Time sebesar 95,89% per tahun.
2. Kecepatan yang tersedia untuk jaringan internet
100Kbps/User.
34
d. Menentukan pengguna, ini berguna untuk mengetahui siapa saja yang dapat
menggunakan layanan yang dapat dilihat pada tabel 4.6 pengguna layanan
SLR.
Tabel 4. 6 Pengguna Layanan SLR
Layanan Pengguna
Stikomapps Mahasiswa, Dosen, Karyawan.
Sicyca Dosen, Karyawan dan Mahasiswa.
Brilian Mahasiswa, Dosen.
Jaringan via kabel Dosen, Karyawan, mahasiswa (Laboratorium).
Jaringan via nirkabel Mahasiswa, Dosen, Karyawan, Tamu.
e. Membuat batasan waktu operasional untuk menggunakan layanan yang
dapat dilihat pada tabel 4.7 batasan waktu operasional SLR.
Tabel 4. 7 Batasan Waktu Operasional SLR
Layanan Waktu Operasi
Stikomapps beroperasi setiap hari selama 24 jam.
Sicyca beroperasi setiap hari selama 24 jam.
Brilian beroperasi setiap hari selama 24 jam.
Jaringan via kabel beroperasi selama jam operasional kerja yaitu:
Senin - jumat mulai jam 07:00 hingga 19:00. Dan
sabtu mulai jam 07:00 hingga 12:00
Jaringan via nirkabel beroperasi setiap hari selama 24 jam.
B. Menyetujui kebutuhan
Proses ini adalah proses yang sangat penting karena dalam proses ini
pihak PPTI harus me-review kebutuhan yang telah disiapkan serta menyetujui
kebutuhan yang diperlukan untuk membuat layanan tersebut. Berdasarkan hasil
35
dari proses tersebut ditaruh pada formulir service level requirement seperti
pada tabel 4.8
Tabel 4. 8 Hasil form Service Level Requirement
Form Service Level Requirement
Service Level Requirement
Nama Layanan STIKOMAPPS
Deskripsi Adalah sebuah layanan aplikasi web portal untuk
mengakses aplikasi keseluruhan yang ada dalam domain
stikom.edu, beberapa aplikasi tersebut seperti: email,
drive, serta akses informasi untuk mendukung kegiatan
mahasiswa.
Kebutuhan Layanan
Fungsi Layanan TI Fitur ini berisi berisi layanan aplikasi GAFE
(GoogleApps for Education), link layanan aplikasi
akademik, unit kegiatan mahasiswa, unit kegiatan
kerohanian dan link yang terdaftar pada domain
stikom.edu
Cakupan STIKOMAPPS mencakup semua link yang terdaftar
pada domain stikom.edu yang dikategorikan menjadi 3
yaitu: Akademik, Unit Kegiatan Mahasiswa dan Unit
Kegiatan Kerohanian
Fitur Fitur GAFE yang tersedia dalam layanan ini:
1. Email
2. Drive
3. Calender
4. Site
5. Google+
Fitur link yang tersedia dalam layanan ini:
36
1. Academic Application:
a. Sistem Informasi Cyber Campus – Sicyca
b. Pusat Pelayanan Tugas Akhir – PPTA
c. Electronic Resources Stikom Surabaya – E-
Resource
d. Aplikasi Saran dan Keluhan
2. Unit Kegiatan Mahasiswa:
a. Tari
b. Musik
c. Generasi Fotografi Stikom (G-FORST)
d. Silat Tauhid Indonesia (STI)
e. Stikom Jiu Jitsu
f. Capoeira
g. Stikom English Community (SEC)
h. Pasukan Pengibar Bendera Pusaka
(PASKIBRA)
i. Korps Suka Rela (KSR)
j. Himpunan Mahasiswa Pecinta Alam Stikom
Surabaya (HIMAPASTI)
k. Stikom Futsal Club (SFC)
l. Bulu Tangkis
3. Unit Kegiatan Kerohanian:
a. Unit Kerohanian Persekutuan Doa (UKPD)
37
(Kristen Protestan)
b. Unit Kegiatan Kerohanian Budha (UKKB)
c. Unit Kegiatan Kerohanian Islam (UKKI)
d. Unit Kegiatan Kerohanian Hindu (UKKH)
e. Kelompok Mahasiswa Katolik (KMK)
4. Stikom Links:
a. Official Website STIKOM Surabaya
b. Open Course Ware
c. Prodi S1 Sistem Informasi
d. Prodi S1 Sistem Komputer
e. Prodi S1 SI Kekhususan Komputerisasi
Akuntanasi
f. Prodi S1 Desain Komunikasi Visual
g. Prodi DIV Komputer Multimedia
h. Prodi Diploma III Komputerisasi Perkantoran
Dan Kesekretariatan
i. Prodi Diploma III Komputer Grafis Dan
Cetak
j. Prodi Diploma III Manajemen Informatika
Kebutuhan Layanan
TI
Spesifikasi hardware minimal pemakaian layanan:
1. PC/Laptop
a. Prosessor: Pentium 4 atau setara keatas
b. RAM: 512 MB
38
c. Operating System: Windows XP atau setara
keatas
2. Handphone/Smartphone Web Browser yang
dapat menjalankan java
Spesifikasi hardware dan tool selama pembangunan
layanan:
1. Prosessor: Core 2 Duo
2. RAM: 2 GB
3. Komputer dengan OS windows 7
4. LAN Card / NIC minimal 100 Mbps dengan
Switch 100Mbps atau 1 Gbps
5. Database server Oracle 10g
6. Server dengan OS windows server/linux
7. Dreamweaver 8
8. TOAD
9. Oracle client oo4o
10. SQLyog
11. Database Oracle
12. Database MySql
13. API Google
14. WinScp
15. Putty
16. Windows remote dekstop
39
Target Memberikan daftar alamat yang terdaftar dalam domain
stikom.edu
Ketersediaan: 99%
Load time: < 4 detik
Keamanan: login menggunakan password yang
dienkripsi
Kompatibilitas: semua browser yang bisa menjalankan
java
Pengguna Layanan
TI
Dosen, Karyawan, dan Mahasiswa
Waktu Operasi Layanan SICYCA beroperasi setiap hari selama 24 jam
4.2.3 Perumusan Service Level Agreement (SLA)
Setelah framework SLA telah dibuat dan disetujui, langkah selanjutnya
adalah membuat SLA sesuai dengan layanan yang disediakan. Pembuatan atau
penentuan SLA sebaiknya melibatkan seluruh pihak terkait dalam suatu
organisasi, agar diperoleh kesepakatan bersama. Pembuatan SLA ini melalui
beberapa tahapan sebagai berikut:
a. Untuk membuat SLA yang perlu dipahami adalah tidak semua
produk/layanan harus memiliki SLA. Buatlah SLA untuk produk/layanan
yang benar-benar critical, dominan terhadap kebutuhan pengguna.
b. Menentukan pihak-pihak yang terlibat, karena SLA merupakan kesepakatan
antara pengguna dengan penyedia layanan.
c. Menetapkan harapan pengguna / target layanan
d. Memetakan Proses dan aktifitas layanan.
A. Menentukan layanan yang dominan terhadap kebutuhan pengguna
Dalam tahap ini layanan yang dipilih dari 81 layanan yang ada pada
bagian PPTI hanya dipilih lima layanan. Lima layanan ini adalah layanan-
40
layanan yang memiliki peran penting bagi pengguna yaitu mahasiswa serta
karyawan yang berada pada Stikom Surabaya. Lima layanan tersebut dapat
dilihat pada tabel 4.2
Dalam 5 layanan tersebut yang akan dibuat dokumen Service Level
Agreement yang berguna sebagai target dan jaminan dari penyedia layanan
dalam hal ini PPTI pada pengguna yaitu semua civitas Stikom Surabaya.
B. Menentukan pihak-pihak yang terlibat (Stakeholder)
Setelah mendapatkan layanan apa saja yang paling kritis dan dominan
terhadap kebutuhan pengguna, dalam SLA harus menentukan pihak-pihak
mana saja yang terlibat. Contoh pengguna dalam layanan jaringan dalam hal ini
pihak-pihak yang terkait dibagi menjadi 2 yaitu:
1. Karyawan yang meliputi dosen dan semua yang ada Stikom Surabaya.
2. Mahasiswa yang telah terdaftar di Stikom Surabaya.
C. Menetapkan harapan pengguna atau target
Pada tahap ini mengacu pada desain framework untuk SLA dimana pada
perencanaan ini pihak PPTI menggunakan framework Service Based sehingga
dalam penentuan harapan pengguna tidak perlu dilaksanakan, namun tetap
harus memberikan target layanan yang akan dijamin oleh penyedia layanan ke
pengguna. Setelah pengguna ditentukan, dalam hal ini langkah selanjutnya
adalah mengetahui keinginan/membuat target layanan yang diberikan pada
pengguna. Dalam tahap ini pembuatan dokumen SLA harus menjelaskan
definisi per layanan secara jelas untuk menghindari kesalahpahaman tentang
suatu layanan. Dalam mendeskripsikan layanan harus mencakup tentang fungsi
yang ada dalam layanan tersebut.
41
Setelah definisi dari layanan telah disebutkan dengan jelas, berikutnya
adalah menetapkan pengguna yang terkait dengan layanan. Penetapan
pengguna ini berguna untuk mendetailkan siapa saja yang dapat memakai
layanan, sehingga selain pengguna yang telah ditetapkan tidak dapat memakai
dan jika terdapat pertanyaan serta komplain yang hadir untuk layanan yang
mempunyai SLA dapat memberikan jawaban sesuai dengan isi SLA yang ada.
Setelah menetapkan pengguna, proses yang selanjutnya dilakukan adalah
menetapkan harapan (target) dan syarat-syaratnya yang terdapat pada Tabel
4.5. Proses ini berguna untuk jaminan layanan yang akan diberikan pada
pengguna, dalam proses ini penyedia layanan harus membuat sesuai dengan
realita serta memberikan batasan atau ketergantungan terhadap sesuatu yang
membuat layanan dapat berjalan optimal sehingga target jaminan yang akan
disuguhkan pada pengguna dapat tercapai sesuai dengan SLA yang telah
ditetapkan nantinya.
D. Memetakan Proses dan Aktifitas Layanan
Berdasarkan data yang diperoleh dari wawancara, proses dan aktifitas
layanan dapat dilihat pada tabel 4.9 pemetaan dan aktifitas layanan
Tabel 4. 9 pemetaan proses dan aktifitas layanan
Layanan Fitur Aktifitas
Stikomapps
Agenda
Pengumuman: Memberikan pengumuman
tentang hal-hal yang ada di Stikom.
Agenda: adalah jadwal acara yang dibahas di
Stikom Surabaya.
Setting Mengubah password layanan aplikasi
stikomapps
42
Layanan Fitur Aktifitas
Mengirim dan menerima E-mail melalui Gmail
yang dikelola langsung oleh google, layanan
aplikasi ini adalah hasil kerjasama dengan
google.
Calender
Membuat peringatan tentang acara yang akan
dilakukan, layanan aplikasi ini adalah hasil
kerjasama dengan google.
Drive Menyimpan file dalam cloud network bahkan
membagi file secara langsung.
Site
Daftar layanan aplikasi brilian yang ada di
stikom surabaya, dalam aktifitas ini dapat
membuat pengguna dapat membuat site
sendiri, menghapus site dan mencari site yang
terdaftar dalam domain stikom.edu.
Google+
Sosial media yang dikelola oleh google, dalam
hal ini akun yang terdaftar tetap dalam domain
stikom.edu yang langsung dikelola oleh
google. Layanan aplikasi ini adalah hasil
kerjasama dengan google.
Academic
Application
Berisi daftar alamat layanan aplikasi akademik
yang dikelola oleh Stikom Surabaya. Daftar
layanan aplikasi akademik ini adalah Sistem
Informasi Cyber Campus (Sicyca), Pusat
Pelayanan Tugas Akhir (PPTA), Digital
Library (Digilib), Electornic Resources
STIKOM Surabaya (E-Resources) dan aplikasi
dan saran keluhan
Unit Kegiatan
Mahasiswa
Daftar aplikasi web unit kegiatan mahasiswa
(UKM) yang terdaftar dalam Stikom Surabaya.
Daftar layanan ini adalah Tari, Musik,
Generasi Fotografi STIKOM, Silat Tauhid
43
Layanan Fitur Aktifitas
Indonesia, STIKOM Jiu Jitsu, Capoeira,
STIKOM English Community, Pasukan
Pengibar Bendera Pusaka, Korps Suka Rela,
Himpunan Mahasiswa Pecinta Alam STIKOM
Surabaya, STIKOM Futsal Club dan Bulu
tangkis
Unit Kegiatan
Kerohanian
Daftar aplikasi web unit kegiatan Kerohanian
(UKK) yang terdaftar dalam Stikom Surabaya.
Daftar layanan ini adalah
Sicyca
DashBoard
Untuk menampilkan sub nilai SKS pada masa
studi, SKS yang di tempuh, SKS perbaikan,
batas studi normal, jadwal matakuliah, nilai
ujian, nilai praktikum, dan SSKM. Ada pun
beberapa sub yang di tampilkan dalam
dashboard seperti detail SSKM, angket dosen
kuliah, dan download.
Akademik
Untuk menampilkan sub berupa jadwal
kegiatan dan jadwalkuliah. Akademik juga
menampilkan sub lain seperti: kartu rencana
studi, sisa matakuliah, jadwal ujian, histori,
materi kuliah, kalender akademik, dan
administrasi mahasiswa.
Keuangan
Untuk sebagai informasi kepada mahasiswa
berupa info keuangan. Adapun tampilan sub
keuangan seperti SPP, SP(sumbangan
pembangunan), Sema, dan Denda Pelanggaran.
Perpustakaan
Untuk menampilkan halaman berupa
pepustakaan dalam bentuk info perpustakaan,
peminjaman buku, rata-rata kunjungan, dan
rata-rata peminjaman.
E-Resource Untuk Memuat file yang berupa dokumen
44
Layanan Fitur Aktifitas
dokumen penting berjenis video, jurnal, dan
audio.
PPTA
Fitur ini berfungsi sebagai acuan untuk melihat
perkembangan Tugas Akhir mahasiswa yang
telah mendaftarkan Tugas Akhirnya. Fitur ini
mempunyai aktifitas yang berisi: Status TA,
Status proposal/buku, jadwal pembimbing,
dokumen pendukung, usulan topik, judul TA,
daftar proposal TA dan daftar sidang TA
Komunitas
Fitur ini berfungsi untuk menampilkan
pencarian mahasiswa atau karyawan yang ada
di STIKOM Surabaya. Fitur ini mempunyai
aktifitas yang berisi: cari (untuk pencarian data
mahasiswa dan staff Stikom Surabaya),
Mahasiswa (khusus untuk pencarian data
mahasiswa), staff (khusus untuk pencarian data
staff), ulang tahun staff (daftar ulang tahun
para staff Stikom Surabaya bulan ini), ulang
tahun mahasiswa (daftar ulang tahun para
mahasiswa Stikom Surabaya bulan ini)
Feedback Mengirim saran dan kritik tentang layanan
Sicyca.
Brilian
Course
Material
berisi kontrak pembelajaran, materi kuliah,
sumber belajar yang mendukung proses
pembelajaran
Forum diskusi secara online dan dirancang interaksi
peserta didik dengan pendidik
Assignment
pemberian dan pengumpulan tugas serta quiz,
pendidik dapat memberikan feedback terhadap
tugas tersebut
Announcement pemberitahuan tentang kuliah bagi peserta
45
Layanan Fitur Aktifitas
didik yang ikut mata kuliah
Score List daftar nilai quiz dan tugas peserta didik
Lecture
minutes
catatan realisasi pembelajaran dan pendidik
saat melakukan perkuliahan
Synchronous
Learning
pembelajaran jarak jauh menggunakan aplikasi
“hangout” dari google
Jaringan
Via
Nirkabel
Pendaftaran
mac address
Pendaftaran mac address pengguna khususnya
karyawan dan mahasiswa untuk dapat
menghubungkan dengan berbagai access point
yang ada di Stikom Surabaya
4.2.4 Perumusan Operational Level Agreement (OLA)
Dokumen Operation Level Agreement (OLA) berfungsi sebagai bahan
untuk penyelarasan bagian-bagian internal dalam sebuah organisasi untuk
mendukung layanan yang diberikan pada pengguna. Dalam perumusan
dokumen OLA.
Dalam proses menyusun dokumen Operational Level Agreement
diperlukan beberapa langkah yaitu:
a. Mengindikasikan pihak-pihak yang bekerja sama.
b. Menjelaskan tugas dan tanggung jawab per bagian yang terlibat.
c. Memberi informasi penanggung jawab bagian yang terlibat.
d. Menjelaskan tentang pengelolaan permintaan layanan.
e. Menjelaskan manajemen kendala.
A. Mengindikasikan Pihak-Pihak Yang Bekerja Sama
Pada proses ini hanya terfokus pada bagian PPTI Stikom Surabaya,
sehingga pihak-pihak yang terlibat dalam dokumen operational level
46
agreement hanya terdapat dua sie, yaitu sie pengembangan jaringan dan sie
pengembangan sistem informasi. Berdasarkan tahap ini dokumen operasional
level agreement hanya terdapat 3 dokumen layanan yaitu layanan Stikomapps,
Sicyca dan Brilian.
B. Menjelaskan Tugas Dan Tanggung Jawab Per Bagian Yang Terlibat
Pada proses ini lebih merincikan tentang tugas dan tanggung jawab dari
sub sie pengembangan jaringan dan sub sie pengembangan sistem informasi.
Berikut adalah tugas dan tanggung jawab sub sie pengembangan jaringan dan
sub sie pengembangan sistem informasi yang dapat dilihat pada tabel 4.8 tugas
dan tanggung jawab sub sie.
Tabel 4. 10 Tugas dan Tanggung Jawab sub Sie
Bagian Tugas dan Tanggung Jawab
Bag.
Administrasi
jaringan
a. Menganalisis sistem log dan mengidentifikasi potensi
masalah dengan sistem komputer.
b. Memperkenalkan dan mengintegrasikan teknologi baru
ke dalam lingkungan pusat data yang ada.
c. Melakukan audit rutin sistem dan perangkat lunak.
d. Menerapkan pembaruan sistem operasi, patch, dan
perubahan konfigurasi.
e. Menambah, menghapus, atau memperbarui informasi
akun pengguna, reset password, dll
f. Tanggung jawab untuk keamanan.
g. Mengatasi masalah yang dilaporkan.
h. Sistem kinerja tuning.
i. Memastikan bahwa infrastruktur jaringan dan berjalan.
j. Melakukan backup dan restore.
Bag
Database
a. Mendesain database yang sesuai dengan kriteria layanan
aplikasi.
47
Bagian Tugas dan Tanggung Jawab
Programmer b. Menangani backup layanan aplikasi.
c. Melakukan backup dan restore.
Bag Web
Programmer
a. Mendesain layanan aplikasi sesuai kebutuhan bisnis
Stikom Surabaya.
b. Membuat aplikasi.
c. Memastikan jalan layanan aplikasi telah sesuai dengan
alur yang diinginkan.
d. Mengatasi masalah yang ada serta perbaikan aplikasi.
Bag Data
Center
a. Mencatat laporan kendala dari pengguna
b. Menyampaikan pada sie yang berhubungan dengan
kendala
c. Mengkonfirmasi pada pengguna yang memberi laporan
kendala bahwa kendala telah diselesaikan
C. Memberi Informasi Penanggung Jawab Bagian Yang Terlibat
Pada proses ini memberikan kontak bagian yang bertanggung jawab pada
setiap sub sie pengembangan jaringan yaitu bagian administrasi jaringan serta
sie pengembangan sistem informasi yaitu (a) bagian database programmer, (b)
bagian web programmer, (c) bagian data center. Namun dalam pemberian
informasi ini, penanggung jawab sub bagian adalah kepala sie dari sub bagian
tersebut yaitu Bapak Slamet selaku sie pengembangan jaringan dan Ibu Lina
Indrawati selaku sie pengembangan sistem informasi.
D. Menjelaskan Tentang Pengelolaan Permintaan Layanan
Pada proses ini adalah hal yang mendeskripsikan tentang layanan apa
saja dokumen OLA dibuat. dalam tahap ini adalah menjelaskan tentang
48
pengelolaan layanan yaitu: permintaan pelayanan standar dan permintaan
perubahan layanan.
E. Menjelaskan Manajemen Kendala
Pada proses ini berguna sebagai pemrosesan kendala yang terjadi pada
layanan stikomapps, sicyca, brilian, jaringan via kabel dan via nirkabel. Pada
proses ini pemrosesan kendala hanya dihitung pada jam operasional kerja yaitu
jam 07:00 hingga 16:30 pada hari senin hingga jumat. Pemrosesan kendala
juga mengacu pada kriteria kendala yang ada yaitu:
Tabel 4. 11 Kriteria Kendala dalam PPTI
Kriteria Pemrosesan Kendala
Tinggi Respon kendala pada layanan ini adalah “< 1 jam” dihitung
dari mulai melapor pada bagian PPTI.
sedang Respon kendala pada layanan ini adalah “≤ 3 jam” dihitung
dari mulai melapor pada bagian PPTI.
Rendah Respon kendala pada layanan ini adalah “< 8 jam” dihitung
dari mulai melapor pada bagian PPTI.
Berdasarkan Tabel 4.11 tentang kriteria kendala masih belum memenuhi
standar yang diperlukan dalam ITIL dan perlu disesuaikan dengan standar yang
dipakai dalam ITIL, pada form Penilaian Prioritas Insiden pada Layanan
Sistem Informasi dan Jaringan didapat hasil seperti Gambar 4.3.
49
Gambar 4. 3 form Penilaian Prioritas Insiden pada Layanan Sistem Informasi
Setelah penilaian prioritas insiden telah ada, maka diperlukan prosedur
dan alur untuk eskalasi yang berdasarkan prosedur pelaksanaan eskalasi hirarki
seperti Gambar 4.4 yang telah sesuai dengan standar ITIL dan sudah telah
dikonfirmasi oleh PPTI.
50
Mulai
Memberikan laporan kegagalan penanganan insiden pada layanan
sistem informasi dan jaringan
Formulir pelaksanaan
diagnosis awal
Menangani insiden pada layanan sistem informasi dan jaringan
Berhasil?Mengisi laporan kegagalan
penanganan pada layanan sistem informasi dan jaringan
Menjadikan solusi yang diperoleh sebagai solusi penanganan insiden pada layanan sistem informasi dan
jaringan
Mengisi laporan eskalasi hierarki
Formulir pelaksanaan
hierarki
Verifikasi formulir pelaksanaan
eskalasi hierarki
Pelaksanaan eskalasi hierarki
selesai
Tidak
Formulir kegagalan penanganan insiden pada layanan sistem
informasi dan jaringan
Gambar 4. 4 Bagan alir prosedur pelaksanaan eskalasi hierarki
4.2.5 Merumuskan Service Improvement Plan
Dalam merumuskan dokumen Service Improvement Plan yang mengacu
pada data kendala yang terjadi selama setahun terakhir. Pada tahap ini proses
yang digunakan untuk menyusun dokumen Service Improvement Plan adalah
sebagai berikut:
a. Mendefinisikan tanggung jawab per bagian yang ada di PPTI.
b. Membuat rencana perbaikan yang mengacu pada data kendala per tahun
yang ada di PPTI.
c. Menjadwalkan pelaksanaan perbaikan.
51
d. Menentukan Critical Succes Factor dan Key Performance Indicator.
e. Membuat metrik sebelum dan sesudah perbaikan
f. Membuat pengukuran yang sesuai serta frekuensi pengukuran dari
perbaikan layanan.
A. Mendefinisikan Tanggung Jawab Tiap Bagian
Berdasarkan data yang diperoleh dari profile PPTI didapatkan tanggung
jawab perbagian yang ada di PPTI yaitu:
1. Bagian Pengembangan Jaringan, bertanggung jawab terhadap ketersediaan
jaringan untuk pelaksanaan teknologi komunikasi seluruh sivitas
akademika. Yang memiliki Sub.Bag Administrasi Jaringan
2. Bagian Pengembangan Sistem Informasi, bertanggung jawab terhadap
penyediaan sistem informasi yang diperuntukkan bagi seluruh sivitas
akademika. yang memiliki Sub.Bag sebagai berikut:
a. Database Programmer
b. Web Programmer
c. Data Center
B. Membuat Rencana Perbaikan
Pada tahap ini rencana perbaikan lebih mengacu pada data kendala pada
PPTI selama tahun 2015 hingga akhir bulan april 2016, berdasarkan data
kendala tersebut dapat disimpulkan bahwa pelaporan data kendala dapat dilihat
pada tabel 4.12
52
Tabel 4. 12 Total Laporan Kendala mulai Januari 2015 – April 206
No Layanan Total laporan kendala
2015 Jan-Des 2016 Jan-Apr
1 Stikomapps 2 laporan / 365 hari Tidak ada laporan
2 Sicyca Tidak ada laporan 2 laporan / 121 hari
3 Brilian 8 laporan / 365 hari 4 laporan / 121 hari
4 Jaringan Via
Nirkabel
324 laporan / 365 hari 146 laporan / 121 hari
5 Jaringan Via Kabel Tidak ada laporan Tidak ada laporan
Berdasarkan data kendala tersebut maka diperlukan perbaikan untuk
meningkatkan layanan. Perbaikan pada periode tersebut diambil hanya
berdasarkan prioritas serta layanan yang paling dominan mengalami kendala.
Dalam dokumen Service Improvement Plan, rencana perbaikan dapat disusun
seperti contoh pada tabel 4.13
Tabel 4. 13 Contoh Tabel Rencana Perbaikan
Dokumen: Rencana Peningkatan Pelayanan Dari: dd-mm-
yy
Organisasi: Penyedia Layanan Untuk: dd-mm-
yy
jawab: Service Level Manajer
Tujuan 1: Meningkatkan Layanan Jaringan Via Nirkabel
# Tindakan tanggung jawab Mulai Akhir
II.A
Membuat list kendala
yang paling sering
terjadi
Sie Pengembangan
Sistem Informasi
dan Sie
Pengembangan
Jaringan
dd-mm-
yy
dd-mm-
yy
53
II.B Membuat dokumen
incident management
Sie Pengembangan
Sistem Informasi
dan Sie
Pengembangan
Jaringan
dd-mm-
yy
dd-mm-
yy
II.C Memonitor segala
insiden
Sie Pengembangan
Sistem Informasi
dan Sie
Pengembangan
Jaringan
dd-mm-
yy
dd-mm-
yy
Hasil: waktu untuk menyelesaikan insiden berkurang
Pengukuran: Waktu penyelesaian insiden diselesaikan kurang dalam waktu
yang telah disepakati
C. Menjadwalkan Pelaksanaan Perbaikan Layanan
Seperti contoh pada Tabel 4.13 dapat dilihat bahwa terdapat jadwal
pelaksanaan untuk perbaikan sehingga pihak-pihak penyedia layanan dapat
mempersiapkan kebutuhan perbaikan serta dapat menyelesaikan sesuai yang
tertera pada jadwal.
D. Menentukan Critial Success Factor dan Key Perfomance Indicator
Dalam tahap ini sangat penting sebagai acuan pengukuran apakah
perbaikan layanan benar-benar membawa perubahan yang signifikan.
Tabel 4. 14 Contoh tabel pengukuran perbaikan layanan
Tujuan Mengurangi waktu untuk menyelesaikan insiden.
Critical Success
Factor (CSF) Mengurangi waktu untuk menyelesaikan insiden.
Key Performance
Indicator (KPI)
Meningkatkan penyelesaian insiden lebih cepat 96
persen dari target penyelesaian kendala.
54
Berdasarkan tabel 4.14 digunakan sebagai acuan untuk membuat
pengukuran dari pengukuran layanan yang telah direncanakan.
E. Membuat Metrik Sebelum dan Sesudah Perbaikan
Proses ini berguna untuk mengetahui apakah perbaikan ini memberikan
dampak perubahan yang signifikan, berdasarkan contoh pada tabel 4.15, adalah
mencari hasil perbaikan serta membandingkan antara sebelum dan sesudah
perbaikan.
Tabel 4. 15 contoh tabel untuk metrik perbandingan perbaikan
Metrik Persen dari insiden diselesaikan dalam waktu lebih
dari target penyelesaian kendala.
Persen dari insiden diselesaikan dalam waktu kurang
dari target penyelesaian kendala.
F. Membuat Pengukuran yang Sesuai serta Frekuensi Pengukuran dari
Perbaikan Layanan
Proses ini berguna untuk mengukur perbaikan yang dilakukan, seperti
contoh tabel 4.16 dengan membandingkan waktu pemecahan setiap masalah
dari sebelum perbaikan untuk setiap kendala serta mengukur seberapa efektif
perbaikan yang telah dilaksanakan.
Tabel 4. 16 Contoh tabel pengukuran dan laporan
Pengukuran Waktu untuk memecahkan setiap insiden
dibandingkan dengan waktu yang telah disepakati
untuk setiap kategori insiden
Frekuensi: Diperbarui setiap hari
Laporan Laporan kejadian
Frekuensi: Bulanan
55
4.2.6 Perumusan Mekanisme Pengelolaan Tingkat Layanan
Berdasarkan studi literatur ITIL Servicel Level Management
membutuhkan suatu standar untuk mengelola dokumen SLM seperti kapan
dilakukan peninjauan, kapan direvisi dan apa saja yang harus ada dalam
dokumen – dokumen SLM. Dalam perumusan mekanisme pengelolaan tingkat
layanan TI dibutuhkan mekanisme-mekanisme yaitu berupa:
1. Standar peninjauan periodik dokumen Service Level Agreement, dokumen
Operation Level Agreement.
2. Standar perevisian dokumen Service Level Agreement, dokumen Operation
Level Agreement.
3. Standar pembentukan dokumen Service Level Requirement, dokumen
Service Level Agreement, dokumen Operation Level Agreement, dan
dokumen Service Improvement Plan.
Pembuatan dokumen ini mengacu pada template SPMI yang berasal dari
Bagian Kendali Mutu pada Stikom Surabaya.
4.2.7 Forum Group Discussion
Pada hasil Forum Group Discussion, dilakukan diskusi mengenai
identifikasi analisis pada tahap Service Level Agreement, Service level
Requirement, Opertional Level Agreement, Service Improvement Plan dan
Mekanisme pengelolaan tingkat layanan. Setiap identifikasi dan analisis
dilakukan berdasarkan data yang didapatkan melalui wawancara, dan studi
literatur. Data didapatkan secara langsung dari kepala bagian, kepala sie
jaringan, dan kepala pengembangan aplikasi. Hasil dari forum group discussion
dapat dilihat pada lampiran 3.
56
4.3 Hasil Tahap Akhir
Hasil dari penelitian ini berupa dokumen yang dibutuhkan untuk
mengelola tingkat layanan. Dalam hasil tahap akhir ini terdapat 4 dokumen
utama yaitu: (a) dokumen Service Level Requirement, (b) dokumen Sevice
Level Agreement, (c) dokumen Operational Level Agreement, (d) dokumen
Service Improvement Plan dan mekanisme sebagai acuan dalam pengelolaan
dokumen tingkat layanan.
4.3.1 Service Level Requirement
Hasil dari sub bab perumusan service level requirement adalah dokumen
Service Level Requirement berbentuk template form tabel sehingga
memudahkan layanan lain untuk mengetahui kebutuhan-kebutuhan sebelum
merumuskan SLA. Dokumen ini dibuat untuk lima layanan yaitu:
1. Stikomapps
2. Sicyca
3. Brilian
4. Jaringan via Kabel
5. Jaringan via Nirkabel
4.3.2 Service Level Agreement
Hasil dari sub bab perumusan service level agreement adalah dokumen
Service Level Agreement dibuat seminimalis mungkin namun tak mengurangi
keterangan yang dibutuhkan pengguna. Dokumen ini dibuat untuk lima layanan
yaitu:
1. Stikomapps
2. Sicyca
57
3. Brilian
4. Jaringan via Kabel
5. Jaringan Via Nirkabel
Contoh hasil dari dokumen ini dapat dilihat pada lampiran 5
4.3.3 Operational Level Agreement
Hasil dari sub bab perumusan operational level agreement adalah
dokumen Operational Level Agreement berbentuk dokumen perjanjian antara
Sie pengembangan jaringan dan Sie Pengembangan Sistem Informasi.
Dokumen ini dibuat hanya pada 3 layanan yaitu:
1. Stikomapps
2. Sicyca
3. Brilian
4.3.4 Service Improvement Plan
Hasil dari sub bab perumusan service improvement plan adalah dokumen
Service Improvement Plan yang mencakup perencanaan untuk peningkatan
lima layanan yang ada di PPTI. Dokumen ini mengacu pada laporan kendala
yang terjadi selama periode 2015 hingga 2016.
4.3.5 Mekanisme Pengelolaan Tingkat Layanan
Hasil dari tahap pengemabangan bagian merumuskan mekanisme
pengelolaan tingkat layanan adalah dokumen:
1. Kebijakan Dokumen Tingkat Layanan
2. Standar Membuat Dokumen Tingkat Layanan
3. Standar Meninjau Dokumen Tingkat Layanan
4. Standar Merevisi Dokumen Tingkat Layanan
58
5. Prosedur Membuat Dokumen Service Level Requirement
6. Prosedur Membuat Dokumen Service Level Agreement
7. Prosedur Membuat Dokumen Operational Level Agreement
8. Prosedur Membuat Dokumen Service Improvement Plan
9. Prosedur Meninjau Dokumen Service Level Agreement
10. Prosedur Meninjau Dokumen Operational Level Agreement
11. Prosedur Merevsi Dokumen Service Level Agreement
12. Prosedur Merevisi Dokumen Operational Level Agreement
Hasil dari mekanisme ini dapat dilihat pada lampiran 1 dan 2.
a. Pembahasan Hasil
Dalam poin ini akan dijelaskan bagaimana penyusunan dokumen yang
telah dihasilkan untuk proses Service Level Management, dimana penelitian ini
menghasilkan 5 dokumen Service Level Requirement yang berfungsi sebagai
acuan pembuatan dokumen pembuatan 5 dokumen Service Level Agreement
sebagai jaminan tingkat layanan yang diberikan pada pengguna, lalu 3
dokumen Operational Level Agreement sebagai perjanjian antar bagian di
PPTI, 1 dokumen Service Improvement Plan yang mengacu pada data kendala
2015 – 2016, lalu 1 dokumen kebijakan, 3 standar, 8 prosedur dan 3 form yang
dapat dilihat pada gambar 4.5 dan gambar 4.6
Merevisi Dokumen Tingkat Layanan
Membuat Dokumen SLR
Membuat Dokumen SLA
Membuat Dokumen OLA
Membuat Dokumen SIP
Form Service Level Requirement
Stikomapps
Sicyca
Brilian
Jaringan Via Kabel
Jaringan Via Nirkabel
Stikomapps
Sicyca
Brilian
Jaringan Via Kabel
Jaringan Via Nirkabel
Stikomapps
Sicyca
Brilian
Membuat Dokumen Tingkat Layanan
Meninjau Dokumen Tingkat LayananMeninjau Dokumen SLA
Meninjau Dokumen OLA
Meninjau Dokumen SLA
Meninjau Dokumen OLA
Merevisi Dokumen SLA
Merevisi Dokumen OLA
Form Revisi Service Level Agreement
Form Revisi Operational Level Agreement
Form Peninjauan Service Level Agreement
Form Peninjauan Operational Level Agreement
Gambar 4. 5 Hasil pemetaan keluaran dokumen Service Level Management
59
Pemetaan proses hingga hasil proses Service Level Management
Perumusan SLR Perumusan SLA Perumusan OLA MekanismePerumusan SIP
Phas
e
Data Kendala
Dokumen SIP
Dokumen SLR Stikomapps
Dokumen SLR Sicyca
Dokumen SLR Brilian
Dokumen SLR Jaringan via Kabel
Dokumen SLR Jaringan via
Nirkabel
Dokumen SLA Stikomapps
Dokumen SLA Sicyca
Dokumen SLA Brilian
Dokumen SLA Jaringan via Kabel
Dokumen SLA Jaringan via
Nirkabel
Dokumen OLA Stikomapps
Dokumen OLA Sicyca
Dokumen OLA Brilian
Berdasarkan ITIL untuk pengelolaan
dokumen SLM
Kebijakan pengelolaan
dokumen SLM
Standar
Prosedur
Form
Gambar 4. 6 Pemetaan Hingga Hasil Proses Service Level Management
60
