TUGAS AKHIR KS151601 PEMBUATAN STANDARD …repository.its.ac.id/2813/7/5212100021-Undergraduate-Theses.pdf · Gambar 2.4 Contoh Bagian Identitas SOP ... administrasi kontrak dan pencairan

i

TUGAS AKHIR – KS151601

PEMBUATAN STANDARD OPERATING PROCEDURE

MANAJEMEN PERUBAHAN PADA KEBUTUHAN APLIKASI

GOVERNMENT RESOURCE MANAGEMENT SYSTEMS (GRMS)

BERDASARKAN KERANGKA KERJA ITIL V3 (STUDI KASUS:

PEMERINTAH KOTA SURABAYA BAGIAN BINA PROGRAM)

DEVELOPING STANDARD OPERATING PROCEDURE CHANGE

MANAGEMENT FOR GOVERNMENT RESOURCE

MANAGEMENT SYSTEMS (GRMS) APPLICATION BASED ON

ITIL V3 (CASE STUDY : SURABAYA MUNICIPALITY BAGIAN

BINA PROGRAM)

Erron Trivianto Hudyono

NRP 5212 100 097

Dosen Pembimbing:

Tony Dwi Susanto, S.T, M.T, Ph.D.

Anisah Herdiyanti, S.Kom. M.Sc, ITIL

JURUSAN SISTEM INFORMASI

Fakultas Teknologi Informasi

Institut Teknologi Sepuluh Nopember

Surabaya 2017

ii

TUGAS AKHIR – KS 141501


MANAJEMEN PERUBAHAN PADA KEBUTUHAN APLIKASI

GOVERNMENT RESOURCE MANAGEMENT SYSTEMS

BERDASARKAN KERANGKA KERJA ITIL V3 (STUDI KASUS :

PEMERINTAH KOTA SURABAYA BAGIAN BINA PROGRAM)


5212 100 097

Dosen Pembimbing


Anisah Herdiyanti, S.Kom, M.Sc, ITIL

JURUSAN SISTEM INFORMASI

Fakultas Teknologi Informasi

Institut Teknologi Sepuluh Nopember

Surabaya 2017

iii

FINAL PROJECT – KS 141501

DEVELOPING STANDARD OPERATING PROCEDURE

CHANGE MANAGEMENT FOR GOVERNMENT

MANAGEMENT SYSTEMS (GRMS) APPLICATION BASED ON

ITIL V3 (CASE STUDY : SURABAYA MUNICIPALITY BAGIAN

BINA PROGRAM)


5212 100 097

Academic Promotors


Anisah Herdiyanti, S.Kom, M.Sc, ITIL

INFORMATION SYSTEMS DEPARTMENT

Information Technology Faculty

Sepuluh Nopember Institut of Technology

Surabaya 2017

iv

v

v

PEMBUATAN STANDARD OPERATING PROCEDURE MANAJEMEN PERUBAHAN PADA KEBUTUHAN APLIKASI GOVERNMENT MANAGEMENT SYSTEMS BERDASARKAN

KERANGKA KERJA ITIL V3 (STUDI KASUS : PEMERINTAH KOTA SURABAYA BAGIAN BINA

PROGRAM)

Nama Mahasiswa : Erron Trivianto Hudyono

NRP : 5212100021

Jurusan : Sistem Informasi FTIf – ITS

Dosen Pembimbing 1 : Tony Dwi Susanto, ST, MT, Ph.D.

Dosen Pembimbing 2 : Anisah Herdiyanti, S.Kom, M.Sc,

ITIL

ABSTRAK

Government Resources Management System (GRMS) yang

dikelola oleh bina program Pemerintah Kota Surabaya

merupakan salah satu sistem informasi manajemen sumber

daya pemerintahan dalam hal pengelolaan keuangan daerah

yang terintegrasi. Secara berkelanjutan, pengembangan

terhadap GRMS yang terus dilaksanakan guna penyempurnaan

dan penyesuaian terhadap perundang-undangan dan

kebutuhan pengguna akan menghasilkan suatu perubahan pada

sistem. Dalam hal pengembangan aplikasi GRMS masih belum

terstandarisasi sehingga terdapat poin-poin penting yang

terlewatkan dalam proses pengembangan aplikasi GRMS.

Dalam pengembangan aplikasi GRMS, manajemen perubahan

TI diperlukan untuk mengatur dan mengelola perubahan-

perubahan tersebut terhadap kondisi sebelum dan setelah

dilakukannya perubahan tersebut. Untuk melakukan

pengelolaan terhadap perubahan tersebut, diperlukan

Standard Operating Procedure (SOP) mengenai manajemen

perubahan terhadap kebutuhan aplikasi GRMS yang telah

berdasarkan standar ITIL V3.

vi

Penelitian ini menggunakan metode analisis kesenjangan untuk

mengetahui kesenjangan yang terdapat antara kondisi kekinian

dan kondisi ekspetasi dengan kondisi ideal yang diharapkan.

Kondisi ideal yang diharapkan didapatkan melalui kerangka

kerja ITIL V3 mengenai manajemen perubahan. Hasil akhir

dari penelitian tugas akhir ini adalah dokumen Standard

Operating Procedure (SOP) mengenai manajemen perubahan

terhadap kebutuhan aplikasi GRMS berdasarkan standar ITIL

V3. Pembuatan dokumen SOP diharapkan dapat memberikan

standarisasi terhadap kinerja Bina program dalam

pengelolaan pengembangan aplikasi GRMS.

Kata Kunci: Government Resource Management Systems

(GRMS), Standard Operating Procedure (SOP), ITIL V3,

Manajemen Perubahan, Analisis Kesenjangan

vii

DEVELOPING STANDARD OPERATING PROCEDURE

CHANGE MANAGEMENT FOR GOVERNMENT

RESOURCE MANAGEMENT SYSTEMS (GRMS)

APPLICATION BASED ON ITIL V3 (CASE STUDY : SURABAYA MUNICIPALITY BAGIAN BINA PROGRAM)

Student Name : Erron Trivianto Hudyono

NRP : 5212100097

Department : Sistem Informasi FTIf – ITS

Supervisor 1 : Tony Dwi Susanto, ST, MT, Ph.D.

Supervisor 2 : Anisah Herdiyanti, S.Kom, M.Sc, ITIL

ABSTRACT

Government Resources Management System (GRMS) managed

by the Surabaya Municipality Bina Program is one of

management information system of government resources in

term of an integrated financial management area. Continously,

the development of GRMS which continue to be implemented in

order to improve and adapt to the legislation and user

requirement will result a change in the system. In terms of

GRMS application development is still not standarized so that

there are important points overlooked in the process of GRMS

application development. Within the process of GRMS

application development, IT change management is required to

set up and manage the changes of the conditions before and

after the changes have been implemented. In order to do

management of the changes, standard operating procedure

(SOP) about change management for GRMS application

requirement is needed which is based on ITIL V3.

This study uses gap analysis to determine the gap that exists

between the present condition and the expected condition with

the ideal condition. The ideal condition is obtained through

ITIL V3 about change management. The last results of this

research is the standard operating procedure (SOP) document

viii

about change management for GRMS application based on

ITIL V3.. The Composing of SOP document is expected to

provide a standarization to Bina Program perfomance in

managing GRMS application development.

Keywords: Government Resource Management Systems

(GRMS), Standard Operating Procedure (SOP), ITIL V3,

Change Management, Gap Analysis

ix

KATA PENGANTAR

Segala puji dan syukur penulis panjatkan pada Tuhan Yang

Maha Esa yang telah memberikan rahmat dan kekuatan kepada

penulis sehingga dapat menyelesaikan buku tugas akhir dengan

judul:


MANAJEMEN PERUBAHAN TERHADAP

KEBUTUHAN APLIKASI GOVERNMENT RESOURCE

MANAGEMENT SYSTEMS BERDASARKAN

KERANGKA KERJA ITIL V3 (STUDI KASUS : PEMERINTAH KOTA SURABAYA BAGIAN BINA

PROGRAM)

Pada kesempatan ini, saya ingin menyampaikan terima kasih

kepada semua pihak yang telah memberikan dukungan,

bimbingan, arahan, bantuan, dan semangat dalam

menyelesaikan tugas akhir ini, yaitu kepada:

1. Tuhan Yang Maha Esa yang telah memberikan rahmat dan

karuniaNya sehingga penulis dapat menyelesaikan tugas

akhir tepat waktu.

2. Orangtua penulis yang telah mendoakan dan senantiasa

mendukung penulis.

3. Dosen pembimbing saya yang senantiasa membimbing dan

mengarahkan saya dalam pengerjaan buku tugas akhir.

Penyusunan laporan ini masih jauh dari sempurna, untuk itu

saya menerima adanya kritik dan saran yang membangun untuk

perbaikan di masa mendatang. Semoga buku tugas akhir ini

dapat memberikan manfaat pembaca.

x

DAFTAR ISI

ABSTRAK ...............................................................................v

ABSTRACT .......................................................................... vii

KATA PENGANTAR ............................................................ ix

DAFTAR ISI ............................................................................x

DAFTAR GAMBAR ............................................................ xiv

DAFTAR TABEL ..................................................................xv

BAB I PENDAHULUAN .......................................................1

1.1. Latar Belakang .........................................................1

1.2. Perumusan Masalah .................................................3

1.3. Batasan Masalah .......................................................3

1.4. Tujuan Tugas Akhir .................................................3

1.5. Manfaat Tugas Akhir ...............................................4

1.6. Relevansi ..................................................................4

BAB II TINJAUAN PUSTAKA ..............................................5

2.1. Penelitian Sebelumnya ..................................................5

2.2. Dasar Teori ....................................................................8

2.2.1. Pemerintah Kota Surabaya Bagian Bina Program ......8

2.2.2. Government Resource Management Systems

(GRMS) ..................................................................10

2.2.3. Manajemen Perubahan Menurut ITIL V3 ................15

2.2.4. Gap Analysis (Analisis Kesenjangan) ......................17

2.2.5. Standard Operating Procedure (SOP) .....................18

xi

2.2.5.1. Kriteria dan Format SOP ................................ 19

2.2.5.2. Dokumen Standard Operating Procedure

(SOP) ............................................................. 21

BAB III METODOLOGI ....................................................... 27

3.1. Diagram Metodologi ................................................... 27

3.2. Uraian Metode Pengerjaan Tugas Akhir ..................... 29

3.2.1. Tahap Penyusunan Interview Protocol ................. 29

3.2.2. Tahap Pengumpulan Data dan Informasi ............. 29

3.2.3. Tahap Analisis Kesenjangan ................................ 30

3.2.4. Tahap Perancangan dan Pembuatan Dokumen SOP

....................................................................... 31

3.2.5. Tahap Penyusunan Dokumen Akhir ..................... 31

BAB IV PERANCANGAN ................................................... 33

4.1. Perancangan Studi Kasus ............................................ 33

4.1.1. Tujuan Studi Kasus .............................................. 33

4.1.2. Subjek dan Objek Penelitian ................................ 34

4.2. Perancangan Penggalian Data ..................................... 35

4.2.1. Data yang Diperlukan ........................................... 35

4.2.2. Teknik Penggalian Data ....................................... 35

4.3. Perancangan Interview Protocol ................................. 35

4.4. Perancangan Analisis Data .......................................... 40

4.4.1. Metode Pengolahan Data ..................................... 40

4.4.2. Penentuan Pendekatan Analisis ............................ 40

4.5. Perancangan Standard Operating Procedure.............. 41

xii

4.5.1. Verifikasi ..............................................................41

4.5.2. Validasi .................................................................43

BAB V IMPLEMENTASI .....................................................45

5.1 Analisis Kondisi Kekinian dan Kondisi Ideal ..............45

5.1.1 Hasil Wawancara ...................................................45

5.1.2 Pendefinisian Aktor dan Role GRMS....................45

5.1.3 Kategorisasi Perubahan Layanan TI ......................47

5.1.4 Kondisi Kekinian Manajemen Perubahan Terhadap

Aplikasi GRMS ..............................................48

5.1.5 Kondisi Ideal Manajemen Perubahan Terhadap

Kebutuhan GRMS ..........................................64

5.2 Hambatan ......................................................................71

BAB VI HASIL DAN PEMBAHASAN ................................73

6.1 Analisis Kesenjangan ...................................................73

6.2 Identifikasi Dampak dan Solusi ....................................80

6.3 Perancangan Dokumen SOP .........................................83

6.3.1 Deskripsi Usulan SOP ...........................................83

6.3.2 Struktur dan Konten SOP ......................................85

6.4 Hasil Pembuatan Dokumen SOP ..................................87

6.4.1 Prosedur Manajemen Perubahan TI.......................87

6.4.2 Prosedur Penanganan Standard Change ................95

6.4.3 Prosedur Penanganan Normal Change ..................98

6.4.4 Prosedur Penanganan Emergency Change ..........104

6.4.5 Formulir ...............................................................111

xiii

6.5 Verifikasi SOP ........................................................... 112

6.6 Validasi SOP .............................................................. 112

BAB VII KESIMPULAN DAN SARAN ............................ 115

7.1. Kesimpulan ......................................................... 115

7.2. Saran .................................................................... 116

DAFTAR PUSTAKA .......................................................... 119

BIODATA PENULIS .......................................................... 123

A LAMPIRAN A – Interview Protocol ................... A-1

B LAMPIRAN B – Hasil Interview ........................ B-1

C LAMPIRAN C – Verifikasi SOP ......................... C-1

D LAMPIRAN D – Validasi SOP ........................... D-1

E LAMPIRAN E - BUKTI VERIFIKASI DAN

VALIDASI SOP ................................................................... E-1

xiv

DAFTAR GAMBAR

Gambar 2.1 Struktur Organisasi ...............................................8

Gambar 2.2 Aktivitas Bina Program ......................................10

Gambar 2.3 Halaman Judul sebuah Dokumen SOP ...............22

Gambar 2.4 Contoh Bagian Identitas SOP .............................24

Gambar 2.5 Contoh Bagian Flowchart SOP ...........................25

Gambar 3. 1 Metodologi .........................................................28

Gambar 5.1 Alur pengembangan aplikasi e-budgeting ..........50

Gambar 5.2 Alur pengembangan aplikasi e-project dan e-

controlling...............................................................................52

Gambar 5.3 Alur pengembangan aplikasi e-delivery .............54

Gambar 5.4 Alur pengembangan aplikasi e-performance ......56

Gambar 5.5 Struktur Organisasi Bina Program ......................58

Gambar 5.6 Struktur Organisasi Bina Program ......................69

Gambar 6. 1 SOP-Perubahan-001 ..........................................91

Gambar 6. 2 Alur Prosedur SOP-Perubahan-001 ...................94

Gambar 6. 4 SOP-Perubahan-002 ..........................................96

Gambar 6. 5 Alur Prosedur SOP-Perubahan-002 ...................97

Gambar 6. 6 SOP-Perubahan-003 ........................................101

Gambar 6. 7 Alur Prosedur SOP-Perubahan-003 .................103

Gambar 6. 8 SOP-Perubahan-004 ........................................107

Gambar 6. 9 Alur Prosedur SOP-Perubahan-004 .................110

Gambar 6. 10 Formulir RFC.................................................112

xv

DAFTAR TABEL

Table 2.1 Penelitian Sebelumnya ............................................. 5

Table 2.2 Sub Aktivitas Bina Program ................................... 10

Table 4.1 Pencatatan Informasi Saat Wawancara .................. 36

Table 4.2 Tampilan Interview Protocol .................................. 36

Table 4.3 Poin Pertanyaan Interview Protocol 1 .................... 37

Table 4.4 Poin Pertanyaan Interview Protocol 2 .................... 38

Table 4.5 Detail Verifikasi SOP ............................................. 41

Table 4.6 Detail Validasi SOP ............................................... 43

Table 5.1 Kategori Perubahan Menurut pengalaman Admin

Bina Program berdasarkan tiap aplikasi ................................. 47

Table 5.2 Tipe Pengguna ........................................................ 58

Table 5.3 Manajemen E-trac Tiap GRMS.............................. 60

Table 5.4 Kondisi Ideal Manajemen Perubahan ITIL V3 ...... 66

Table 5.5 Usulan Peran Tambahan ........................................ 69

Table 6.1 Analisis Kesenjangan ............................................. 74

Table 6.2 Identifikasi Dampak dan Solusi ............................. 81

Table 6.3 Deskripsi Usulan SOP ............................................ 84

Table 6.4 Usulan Formulir ..................................................... 85

Table 6. 5 Struktur dan Konten SOP ...................................... 86

Table 6. 6 Kategori Perubahan Menurut ITIL V3 .................. 88

Table 6. 7 Pertanyaan 7R ....................................................... 99

Table 6. 8 Hierarki Autorisasi Perubahan .............................. 99

Table 6. 7 Pertanyaan 7R ..................................................... 105

Table 6. 8 Hierarki Autorisasi Perubahan ............................ 106

1

BAB I

PENDAHULUAN

Pada bab ini, akan dijelaskan mengenai latar belakang masalah,

perumusan masalah, batasan masalah, tujuan tugas akhir, dan

manfaat tugas akhir, serta relevansi penelitian tugas akhir

dengan bidang keilmuan sistem informasi

1.1. Latar Belakang Pemerintah Kota Surabaya telah menerapkan sistem GRMS

(Government Resources Management System) atau sistem

infomasi manajemen sumber daya pemerintahan dalam hal

pengelolaan keuangan daerah yang terintegrasi dari aktivitas

birokrasi hulu sampai hilir [1]. GRMS dikelola oleh divisi Bina

Program dan aktivitas-aktivitasnya meliputi proses penyusunan

anggaran (e-budgeting), perencanaan pekerjaan (e-project

planning), pelelangan secara elektronik (e-procurement),

administrasi kontrak dan pencairan pekerjaan (e-delivery),

pemantauan pelaksanaan kegiatan (e-controlling) dan

pengukuran kinerja PNS (e-performance). Sistem yang telah

dibangun dan diterapkan sejak tahun 2004 dapat diakses dimana

pun dan kapan pun melalui media internet [1]. Secara

berkelanjutan, Pelaksanaan pengembangan sistem yang

dilakukan secara berkelanjutan bertujuan untuk penyempurnaan

dan penyesuaian terhadap peraturan perundangan-undangan

dan kebutuhan para pengguna [1].

Aktivitas pengembangan aplikasi yang telah diterapkan oleh

Bina Program selama ini yaitu berawal dari pengguna

memberikan sebuah usulan perubahan terhadap sistem yang

nantinya diberikan kepada admin. Kemudian, admin

merapatkan pengusulan perubahan yang berpengaruh besar

dengan kepala sub bagian (kasubag) dan programmer dan

apabila disetujui, admin akan melakukan pencatatan detail

perubahan ke dalam sebuah aplikasi pencatatan dimana

programmer dapat melihat untuk mengetahui bagaimana

pengeksekusian perubahan dilakukan. Untuk perubahan yang

berpengaruh kecil, biasanya ditangani langsung oleh admin atau

2

programmer. Setelah pengeksekusian dilakukan, terdapat

aktivitas untuk pengimplementasian hasil eksekusi perubahan

ke lingkungan kerja sebenarnya.

Dari paparan kondisi kekinian terkait aktivitas pengembangan

aplikasi GRMS yang diterapkan oleh Bina Program masih

terdapat beberapa permasalahan yang ditemukan berdasarkan

manajemen perubahan ITIL V3, antara lain : tidak terdapat

pencatatan permintaan perubahan yang dilakukan terhadap

seluruh usulan perubahan pada tahap awal mengenai deskripsi

perubahan, alasan perubahan, keuntungan perubahan,

konsekuensi adanya perubahan, risiko perubahan, dan detail

lainnya sehingga memudahkan admin dalam meninjau

perubahan; tidak terdapat aktivitas dalam mengkategorikan

perubahan yang perlu ditangani secepatnya atau perubahan

yang hanya perlu ditangani oleh pihak tertentu; dan tidak ada

pensosialisasian terhadap para pengguna mengenai

pengimplementasian perubahan apakah perubahan telah

mencapai tujuan dan keuntungan yang dicapai.

Untuk mengatasi masalah terkait pengelolaan perubahan

terhadap kebutuhan aplikasi, penerapan manajemen perubahan

TI atau IT Change Management bagi Bina Program dalam

pengelolaan pengembangan sistem akan menjadi penting dalam

mengatur dan mengelola perubahan-perubahan terhadap

kondisi sebelum dan setelah dilakukannya perubahan tersebut.

Proses manajemen perubahan TI antara lain mengontrol siklus

hidup dari seluruh perubahan dan memungkinkan seluruh

perubahan yang bermanfaat yang akan dibuat tanpa adanya

gangguan sekecil apapun terhadap layanan IT yang ada.

Berangkat dari permasalahan, bentuk prosedur yang akan

diusulkan adalah dokumen standard operating procedure

(SOP). Bina Program membutuhkan standard operating

procedure (SOP) manajemen perubahan TI yang digunakan

untuk menjalankan tugasnya terkait pengelolaan

pengembangan aplikasi GRMS. Prosedur standard akan dibuat

berdasarkan hasil analisis kesenjangan antara kondisi kekinian

dan kondisi ekspetasi dengan kondisi ideal sesuai dengan

kerangka kerja ITIL v3 mengenai manajemen perubahan yang

3

memastikan bahwa semua perubahan yang akan dilakukan telah

tercatat, terencana, dan tersetujui. Dokumen SOP yang akan

dibuat diharapkan dapat menjadi pedoman yang terstruktur

dalam pengelolaan pengembangan sistem secara terintegrasi.

1.2. Perumusan Masalah Berdasarkan uraian latar belakang di atas, maka berikut

merupakan rumusan permasalahan yang menjadi fokus

penyelesaian dalam Tugas Akhir ini antara lain :

1. Apa hasil analisis kesenjangan yang terjadi antara kondisi

kekinian manajemen perubahan terhadap kebutuhan GRMS

dengan kondisi ideal berdasarkan manajemen perubahan

ITIL V3?

2. Seperti apa hasil pembuatan usulan dokumen Standard

Operasi Prosedur (SOP) manajemen perubahan terhadap

kebutuhan GRMS yang dihasilkan?

3. Apa hasil verifikasi dan validasi SOP manajemen

perubahan terhadap kebutuhan aplikasi GRMS?

1.3. Batasan Masalah Dalam pengerjaan tugas akhir ini, ada beberapa batasan

masalah yang harus diperhatikan, yaitu sebagai berikut:

1. Dokumen SOP dihasilkan dengan mengacu pada hasil

analisis kesenjangan untuk menentukan kesenjangan yang

terjadi antara kondisi kekinian dan kondisi ideal

manajemen perubahan terhadap kebutuhan GRMS

berdasarkan kerangka kerja ITIL V3.

2. Penelitian ini hanya sampai pada proses pengujian

dokumen SOP dan tidak sampai pada tahapan

pengimplementasian SOP.

1.4. Tujuan Tugas Akhir Tujuan pembuatan tugas akhir ini adalah:

1. Mengetahui hasil kesenjangan yang terjadi antara kondisi

kekinian manajemen perubahan terhadap kebutuhan GRMS

yang dikelola Bina Program dengan kondisi ideal menurut

manajemen perubahan ITIL V3.

4

2. Menghasilkan dokumen SOP manajemen perubahan

terhadap kebutuhan GRMS berdasarkan hasil analisis

kesenjangan dan kerangka kerja ITIL V3.

3. Mengetahui hasil verifikasi dan validasi dari dokumen SOP

manajemen perubahan terhadap kebutuhan aplikasi GRMS

untuk digunakan oleh pihak Bina Program.

1.5. Manfaat Tugas Akhir Manfaat dari pengerjaan tugas akhir ini adalah:

1. Bagi dunia akademis, tugas akhir ini diharapkan mampu

menambah referensi penelitian dalam pembuatan dokumen

SOP yang mengacu pada ITIL V3 mengenai manajemen

perubahan dan menjadi acuan untuk penelitian selanjutnya.

2. Bagi Bina Program, dokumen Standard Operating

Procedure (SOP) yang dihasilkan diharapkan mampu

menjadi acuan bagi pihak Bina Program untuk

meningkatkan kualitas proses pengembangan terhadap

kebutuhan yang lebih baik dan terstandarisasi.

1.6. Relevansi Penyusunan tugas akhir ini bertujuan untuk memenuhi salah

satu syarat kelulusan pada Jurusan Sistem Informasi ITS

Surabaya. Penelitian ini berelevansi dengan bidang minat pada

laboratorium Manajemen Sistem Informasi (MSI) Jurusan

Sistem Informasi ITS. Penelitian terkait sesuai dengan mata

kuliah Manajemen Layanan Teknologi Informasi (MLTI), Tata

Kelola Sistem Informasi/Teknologi Informasi (SI/TI), dan

Rekayasa Kebutuhan Perangkat Lunak (RKPL).

5

5

BAB II

TINJAUAN PUSTAKA

Sebelum melakukan penelitian tugas akhir, penulis melakukan

tinjauan terhadap tulisan dari beberapa penelitian sebelumnya

yang sesuai dengan yang diambil. Hasil tinjauan tersebut adalah

sebagai berikut.

2.1. Penelitian Sebelumnya Sebelum melakukan penelitian tugas akhir, penulis melakukan

tinjauan terhadap beberapa penelitian sebelumnya yang sesuai

dengan tema yang diambil. Berikut merupakan hasil tinjauan

penelitian-penelitian tersebut :

Table 2.1 Penelitian Sebelumnya

Penelitian 1 Penelitian 2 Penelitian 3

Na

ma

Pen

elit

i Rizky Amalia

Cahya Ekaputri;

Ahmad Fajar

Prasetya;

Rully Agus

Hendrawan,

S.Kom, M.Eng.

Endang

Sulistiyani; Ir.

Ahmad Holil

Noor Ali,

M.Kom; Hanim

Maria Astuti,

S.Kom, M.Sc.

Ari Cahaya

Puspitaningrum;

Hanim Maria

Astuti, S.Kom,

M.Sc; Anisah

Herdiyanti,

S.Kom., M.Sc.

6

Penelitian 1 Penelitian 2 Penelitian 3 Ju

du

l P

enel

itia

n

Pembuatan

Standard

Operating

Procedure (SOP)

Change

Management

Pada Proyek

Pengembangan/

Implementasi

Aplikasi

Teknologi

Informasi

Berdasarkan

PMBOK dan

ITIL v3

Di PT.

Aplikanusa

Lintasarta

Perencanaan

Strategi

Manajemen

Perubahan

Penerapan

Sistem Informasi

Absensi Berbasis

Fingerprint pada

Jurusan Sistem

Informasi ITS

Menggunakan

Model ADKAR

Pembuatan

Standard

Operating

Procedure

Pengembangan

Sistem Informasi

Manajemen (SIM)

Berdasarkan

Analisis

Kesenjangan

Dengan

Menggunakan

Kerangka Kerja

COBIT 5 dan

ITIL v3. (Studi

kasus : Lembaga

Pengembangan

Teknologi Sistem

Informasi ITS

Surabaya)

Ha

sil

Pen

elit

ian

Menghasilkan

dokumen

Standard

Operating

Procedure

berdasarkan

kerangka kerja

ITIL V3 dan

PMBOK

Menghasilkan

roadmap

manajemen

perubahan

penerapan sistem

informasi

absensi berbasis

fingerprint di

Jurusan Sistem

Informasi ITS

menggunakan

model ADKAR

Menghasilkan

dokumen SOP

pengembangan

SIM pada LPTSI

mengacu pada

hasil analisis

kesenjangan dan

berdasarkan

kerangka kerja

ITIL V3, COBIT 5

7

Penelitian 1 Penelitian 2 Penelitian 3

Rel

evan

si P

enel

itia

n

Output yang

dihasilkan sama,

yaitu berupa

dokumen SOP

terkait

pengembangan

SIM. Salah satu

kerangka kerja

yang digunakan

sebagai acuan

juga sama, yaitu

ITIL V3

mengenai

manajemen

perubahan

Kerangka kerja

yang digunakan

sama, yaitu ITIL

V3 mengenai

manajemen

perubahan

Output yang

dihasilkan sama,

yaitu berupa

dokumen SOP

terkait

pengembangan

SIM

8

2.2. Dasar Teori

2.2.1. Pemerintah Kota Surabaya Bagian Bina Program

Bina Program merupakan salah satu bagian dari Pemerintah

Kota Surabaya yang melaksanakan sebagian urusan

pemerintahan bidang otonomi daerah, pemerintahan umum,

administrasi keuangan daerah, perangkat daerah, kepegawaian

dan persandian. Dapat dilihat dari struktur organisasi

Pemerintah Kota Surabaya bagian Bina Program merupakan

bagian dari sekretariat daerah yaitu asisten perekonomian dan

pembangunan pada Gambar 2.1.

Berdasarkan peraturan Walikota Surabaya Nomor 43 Tahun

2011 tentang Rincian Tugas dan Fungsi Sekretariat Daerah

Kota Surabaya, Tugas dan Fungsi Bina Program meliputi [2]:

Gambar 2.1 Struktur Organisasi

9

Tugas:

(1) Perumusan bahan penetapan kebijakan implementasi

rencana tindak kota;

(2) Pengendalian rencana tindak kota;

(3) Perumusan bahan penetapan standar satuan harga dan

analisis standar belanja daerah kota;

(4) Penyelenggaraan monitoring dan pengendalian

implementasi rencana tindak kota;

(5) Pembinaan implementasi rencana tindak kota;

(6) Pelaksanaan fasilitasi pembinaan jasa konstruksi dan

pengadaan barang/jasa;

(7) Pelaksanaan evaluasi implementasi rencana tindak kota;

(8) Pelaporan implementasi rencana tindak kota;

(9) Penilaian unjuk kerja pengelola implementasi rencana

tindak kota.

Fungsi:

(1) Penyusunan rencana program dan petunjuk teknis di

bidang bina program;

(2) Pelaksanaan program dan petunjuk teknis di bidang bina

program;

(3) Pengawasan dan pengendalian di bidang bina program;

(4) Pelaksanaan evaluasi dan pelaporan pelaksanaan tugas;

(5) Pelaksanaan koordinasi bagian kerjasama dengan

lembaga/instansi lain di bidang bina program;

(6) Pelaksanaan tugas-tugas lain yang diberikan oleh

Asisten Perekonomian dan Pembangunan sesuai dengan

tugas dan fungsinya.

Berdasarkan tugas pokok dan fungsi serta penjelasan mengenai

Pemerintah Kota Surabaya, penelitian ini berfokus pada bagian

Bina Program. Bina Program mengelola sistem yang digunakan

untuk mengelola keuangan daerah yang ada di Pemerintah Kota

Surabaya.

Adapun program kegiatan Bina Program, antara lain:

Program Perencanaan Pembangunan Daerah

Program Peningkatan Sistem Pengawasan Internal dan

Pengendalian Pelaksanaan Kebijakan KDH

Program Pelayanan Administrasi Perkantoran

10

Program Peningkatan Sarana dan Prasarana Aparatur

2.2.2. Government Resource Management Systems

(GRMS)

Pemerintah Kota Surabaya bagian Bina Program berada

dibawah naungan E-Government pada sub proses Pengelolaan

Keuangan Daerah yang ada di Pemerintah Kota Surabaya.

Dalam Bina Program terdapat beberapa aktivitas umum yang

dikerjakan pada unit kerja ini. Dan aktivitas-aktivitas tersebut

dapat digambarkan pada Gambar 2.2 [3]:

Gambar 2.2 Aktivitas Bina Program

Berikut ini adalah penjelasan ke-tujuh sub aktivitas dari Bina

Program:

Table 2.2 Sub Aktivitas Bina Program

Aplikasi Definisi Tujuan

E-Budgeting

Bagian awal dari

skenario besar E-

Government di

Pemerintah Kota

Surabaya, melalui

1. Maksud

penerapan E-

Budgeting adalah

mempermudah

Tim Anggaran

11


konsep GRMS

(Government

Resource

Management System).

Sistem e-Budgeting

adalah sistem

penyusunan anggaran

yang didalamnya

termasuk aplikasi

program komputer

berbasis web untuk

memfasilitasi proses

penyusunan APBD

(Anggaran

Pendapatan dan

Belanja Daerah),

Revisi, dan PAK

(Perubahan Anggaran

Kegiatan) Pemerintah

Kota Surabaya.

Eksekutif (TAPD)

dalam Menyusun /

Proses Anggaran

2. Tujuan

penerapan E-

Budgeting adalah

untuk tingkatkan

kualitas APBD

dari sisi

kesesuaian dengan

RPJMD,

keakuratan nilai

dan rekening, dan

akuntabilitas

alokasi belanja

E-Project

Bertujuan untuk

memudahkan

pegawai dari satuan-

satuan kerja di

lingkup Pemerintah

Kota Surabaya dalam

merencanakan paket-

paket pekerjaan yang

telah disetujui alokasi

anggarannya.

1. Tersedianya

sistem untuk

perencanaan

pelaksanaan

anggaran secara

terintegrasi, antara

lain :

a. Data input

otomatis dari E-

Budgeting (tidak

manual)

b. Meminimalisasi

tingkat kesalahan

c. Meningkatkan

efisiensi dan

efektivitas

12


2.Mengalokasikan

anggaran ke

dalam paket-paket

pekerjaan

3. Merencanakan

pelaksanaan

anggaran kegiatan

selama 1 (satu)

tahun anggaran

4. Tersedianya

data pelaksanaan

anggaran kegiatan

secara triwulan

5. Dokumen

pendukung dalam

Kontrak Kinerja

E-

Procurement

Digunakan untuk

menyelenggarakan

system pelayanan

pengadaan barang

atau jasa secara

elektronik serta

memfasilitasi ULP

atau pejabat

pengadaan dalam

melaksanakn

pengadaan barang

atau jasa secara

elektronik.

Pengadaan barang

atau jasa secara

elektronik akan

meningkatkan

transparansi dan

akuntabilitas,

meningkatkan

akses pasar dan

persaingan usaha

yang sehat,

memperbaiki

tingkat efisiensi

proses pengadaan,

mendukung proses

monitoring dan

audit dan

memenuhi

kebutuhan akses

pasar dan

persaingan usaha

13


yang sehat,

memperbaiki

target efisiensi

proses pengadaan,

mendukung proses

monitoring dan

audit dan

memenuhi

kebutuhan akses

informasi yang

real time.

E-Delivery

Sistem pendukung

administrasi kegiatan

yang didalamnya

termasuk program

komputer berbasis

web. Dijalankan

setelah proses pada E-

Procurement

Memfasilitasi

kebutuhan

pembuatan

kontrak

pengadaan barang

atau jasa dan

penyediaan

dokumen-

dokumen

kelengkapan.

E-Controlling

E-Controlling

digunakan untuk

melakukan proses

controlling terhadap

proyek yang akan

dibuat.

Hasil kegiatan dari

masing-masing

PA, KPA, PPTK

akan

dibandingkan

dengan rencana

yang dibuat pada

proses E-Project

Planning, dan

permasalahan

tersebut akan

dijaring dengan

menggunakan sms

getaway dan

14


penjelasan SKPD

pada website E-

Controlling.

E-

Performance

Sistem informasi

manajemen kinerja

dalam rangka

penilaian prestasi

kinerja pegawai yang

lebih objektif,

terukur, akuntabel,

partisipasif dan

transparan

Mewujudkan

pembinaan

pegawai

berdasarkan

prestasi kerja dan

sistem karier kerja

pegawai Negeri

Sipil (PNS) di

lingkungan

Pemerintah Kota

Surabaya sesuai

dengan Peraturan

Walikota No. 21

Tahun 2015

tentang Petunjuk

Teknis Pemberian

Uang Kinerja pada

Belanja Langsung

kepada PNSD di

Lingkungan

Pemerintah Kota

Surabaya.

Penelitian ini berfokus terhadap manajemen perubahan

kebutuhan pada seluruh aplikasi, kecuali aplikasi e-

procurement. Pihak Bina Program telah menerapkan berbagai

macam prosedur yang telah terstandarisasi pada aplikasi e-

procurement, termasuk prosedur manajemen perubahan

kebutuhan sistem. Sedangkan aplikasi lainnya masih belum

memiliki prosedur manajemen perubahan kebutuhan sistem

yang telah terstandarisasi.

15

2.2.3. Manajemen Perubahan Menurut ITIL V3

Manajemen perubahan yang diuraikan dalam ITIL v3 adalah

proses utama dalam service transition untuk memastikan setiap

perubahan-perubahan TI yang terjadi dalam pengendalian

pengguna. Proses manajemen perubahan antara lain mengontrol

siklus hidup dari seluruh perubahan dan memungkinkan seluruh

perubahan yang bermanfaat yang akan dibuat tanpa adanya

gangguan sekecil apapun terhadap layanan IT yang ada

[4].Change atau perubahan mencakup penambahan, modifikasi,

atau penghilangan apapun yang dapat mempengaruhi layanan

TI. Perubahan TI yang dimaksud dapat mencakup perubahan

arsitektur, proses, tool, dokumentasi, layanan TI, sistem TI,

infrastruktur TI, hingga perubahan setting-up sebuah sistem TI.

Kategori perubahan dibagi menjadi tiga, yaitu [5] :

Standard Change

Standard change merupakan perubahan-perubahan yang secara

default sudah disetujui dapat dilakukan. Ciri-cirinya adalah

biasa terjadi dalam aktivitas bisnis sehari-hari, tidak kompleks,

dan berisiko rendah, sehingga untuk penanganannya hanya

tinggal mengikuti prosedur atau petunjuk operasional yang

telah ditetapkan sebelumnya. Contohnya adalah me-reset

password, instalasi peralatan komputer untuk karyawan baru,

mengganti harddisk laptop karyawan

Emergency Change

Emergency change merupakan perubahan yang harus

diimplementasikan sesegera mungkin karena memiliki

pengaruh besar ke bisnis, yang umumnya diinisiasi oleh sebuah

accident (misal server crash) atau mengimplementasikan

sistem keamanan.

Normal Change

Normal change merupakan perubahan-perubahan yang tidak

termasuk standard change atau emergency change dimana

penyedia layanan dapat merencanakan di depan, sebagai contoh

rencana migrasi layanan email dari server lokal menjadi

layanan email cloud.

16

Menurut ITIL v3, manajemen perubahan memiliki aktivitas-

aktivitas yang perlu dilakukan terhadap suatu perubahan antara

lain [5]:

Create and record the RFC (Request for Change)

Perlu adanya pencatatan terhadap setiap perubahan yang

diperlukan oleh individu atau organisasi. Perubahan memiliki

beberapa tipe yang berbeda dan setiap perbedaan tipe

perubahan akan memerlukan tipe permintaan perubahan yang

berbeda-beda. Misalnya, sebuah perubahan besar (change

major) memerlukan proposal perubahan yang biasanya dibuat

oleh proses manajemen portofolio layanan. Apabila perubahan

bersifat normal atau kecil, maka diperlukan adanya aktivitas

Request for Change.

Review the RFC

Manajemen perubahan akan menyediakan segala informasi

yang dibutuhkan dan menyaring segala permintaan yang

kelihatan seperti :

o Tidak berguna, tidak praktis, dan tidak dapat dijalankan

o Pengulangan RFC sebelumnya, telah diterima atau ditolak,

atau masih dalam pertimbangan

o Pengajuan yang tidak lengkap

Asses and evaluate the change

Suatu perubahan layanan memiliki dampak potensial yang

bersifat macam-macam. Aktivitas ini menilai dan mengevaluasi

perubahan-perubahan yang perlu dilakukan untuk menghindari

gagalnya perubahan layanan. Terdapat tujuh pertanyaan untuk

menilai perubahan tersebut yang juga disebut sebagai the seven

‘rs’, antara lain :

o Who raised the change?

o What is the reason for the change?

o What is the return required from the change?

o What are the risks involved in the change?

o What resources are required to deliver the change?

o Who is responsible for the build, test and implementation

of the change?

o What is the relationship between this change and other

changes?

17

Authorize the change

Aktivitas autorisasi formal didapatkan dari setiap perubahan

melalui sebuah tingkat aturan autorisasi perubahan (seperti

peran, seseorang). Tingkat autoritas untuk perubahan jenis

tertentu harus diputuskan berdasarkan jenis, ukuran, risiko, dan

dampak bisnis potensial dari perubahan.

Plan updates

Aktivitas pembaharuan rencana memastikan apa saja perubahan

yang perlu dilakukan dan apa saja tugas-tugas yang perlu

dilakukan dalam proses manajemen perubahan.

Coordinate change implementation

Aktivitas perbaikan dan perawatan yang perlu dipersiapkan

untuk setiap perubahan yang berwenang apabila terjadi

kesalahan selama/setelah implementasi. Pelaksanaan

perubahan tersebut harus dijadwalkan ketika dampak pada

layanan benar-benar terjadi.

Review and close change

Aktivitas mengevaluasi kembali perubahan yang perlu

dilakukan untuk mengetahui apakah perubahan yang telah

dilakukan telah memenuhi kebutuhan dan tujuan organisasi.

2.2.4. Gap Analysis (Analisis Kesenjangan)

Analisa gap atau kesenjangan adalah perbandingan kinerja

aktual dengan kinerja potensial atau yang diharapkan [7].

Metode ini merupakan alat evaluasi bisnis yang

menitikberatkan pada kesenjangan kinerja perusahaan saat ini

dengan kinerja yang sudah ditargetkan sebelumnya. Analisa

gap juga mengidentifikasi tindakan-tindakan apa saja yang

diperlukan untuk mengurangi kesenjangan atau mencapai

kinerja yang diharapkan pada masa datang [7]. Selain itu,

analisa ini memperkirakan waktu, biaya, dan sumber daya yang

dibutuhkan untuk mencapai keadaan perusahaan yang

diharapkan [7]. Pentingnya mengetahui sebuah gap yang

terdapat antara kondisi kekinian dan kondisi ideal adalah untuk

mendapatkan dukungan dari sumber daya manusia yang akan

terpengaruh oleh perubahan yang akan terjadi agar

meminimalisir pertentangan dan perasaan berat dari mereka.

18

Manfaat dari analisa gap antara lain [8] :

Menilai seberapa besar kesenjangan antara kinerja aktual

dengan suatu yang diharapkan

Mengetahui peningkatan kerja yang diperlukan untuk

menutupi kesenjangan tersebut

Menjadi salah satu dasar pengambilan keputusan terkait

prioritas waktu dan biaya yang dibutuhkan untuk

memenuhi standar pelayanan yang telah ditetapkan

Mengetahui kondisi terkini dan tindakan apa yang akan

dilakukan di masa mendatang

Langkah-langkah menganalisis kesenjangan untuk

mengoptimalkan proses bisnis GRMS pada Bina Program [9]:

Mengidentifikasi current status

Tahap ini merupakan aktivitas menganlisis proses bisnis GRMS

yang telah dan sedang diterapkan oleh pihak Bina Program saat

ini

Mengidentifikasi expectations

Tahap ini merupakan aktivitas menganalisis proses bisnis yang

ideal menurut sebuah standar/kerangka kerja. Kerangka kerja

yang digunakan adalah ITIL V3

Mengidentifikasi gaps

Tahap ini merupakan aktivitas membandingkan kondisi

kekinian dengan kondisi ideal dan mencari kesenjangan dan

perubahan yang diperlukan di antara kedua kondisi tersebut

Mengidentifikasi problems

Tahap ini merupakan aktivitas menganalisis dampak atas

perubahan yang diperlukan untuk menutupi kesenjangan yang

telah terjadi

Mengidentifikasi recommendations

Tahap ini merupakan aktivitas menganalisis solusi untuk

mengatasi dampak-dampak dari perubahan yang diperlukan

2.2.5. Standard Operating Procedure (SOP)

Standar Operasional Prosedur menurut [10] yaitu:

19

SOP adalah serangkaian instruksi yang menggambarkan

pendokumentasian dari yang dilakukan secara berulang

pada sebuah organisasi.

SOP adalah panduan yang menjelaskan secara terperinci

bagaimana suatu proses harus dilaksanakan.

SOP adalah serangkaian instruksi yang digunakan untuk

memecahkan suatu masalah

Sedangkan fungsi dan tujuan standard operating procedures

(SOP) adalah untuk mendefinisikan semua konsep dan teknik

yang penting serta persyaratan yang dibutuhkan, yang ada

dalam setiap kegiatan yang dituangkan ke dalam suatu bentuk

yang langsung dapat digunakan oleh karyawan dalam

pelaksanaan kegiatan sehari-hari [10].

Selain itu manfaat dari membuat standard operating procedures

adalah:

Dapat menjelaskan secara detail semua kegiatan dari proses

yang dijalankan

Dapat menstadarkan semua aktivitas yang dilakukan pihak

yang bersangkutan

Membantu untuk menyederhanakan semua syarat yang

diperlukan dalam proses pengambilan keputusan

Dapat meningkatkan komunikasi antara pihak-pihak yang

terkait, terutama pekerja dengan pihak manajemen.

Tahapan dalam penyusunan SOP antara lain: adanya analisis

sistem. Analisis tugas serta fungsi dan adanya analisis prosedur

kerja [11]. SOP dibuat sesuai dengan kebutuhan organisasi.

Begitu juga dalam pembuatan SOP untuk masing-masing unit

kerja.

2.2.5.1. Kriteria dan Format SOP

Kriteria dan format SOP dapat memudahkan pembuatan SOP

agar lebih jelas, terstruktur dan mudah diterapkan oleh sebuah

organisasi. Penentuan kriteria dan format SOP dapat

disesuaikan dengan kebutuhan organisasi. Berikut ini

merupakan tujuh keriteria SOP yang baik sesuai dengan aturan

permenpen adalah [12]:

Specific;

20

Complete;

Understable;

Applicable;

Controllable;

Auditable;

Changeable.

Dalam penentuan format penyusunan SOP dapat didasarkan

oleh empat faktor, antara lain [13]:

Berapa banyak keputusan yang akan dibuat dalam suatu

prosedur?

Berapa banyak langkah dan sub langkah yang diperlukan

dalam suatu prosedur?

Siapa yang dijadikan target sebagai pelaksana SOP?

Apa tujuan yang ingin dicapai dalam pembuatan SOP?

Format SOP yang baik ditunjukkan dengan adanya kemudahan

dalam menyalurkan informasi sesuai dengan kebutuhannya

sehingga dapat dilaksanakan secara konsisten. Empat format

yang dapat digunakan, antara lain [13]:

1. Langkah Sederhana (Simple Steps)

Langkah sederhana merupakan penyusunan prosedur yang

hanya memuat sedikit kegiatan dan memerlukan sedikit

keputusan. Dalam situasi dimana hanya ada beberapa orang

yang akan melaksanakan prosedur yang disusun maka dapat

menggunakan format langkah sederhana. Kegiatan yang akan

dilaksanakan cenderung singkat dan sederhana.

2. Langkah Berurutan (Hierarchical Steps)

Tahapan berurutan merupakan pengembangan dari langkah

sederhana. Tahapan ini berisi prosedur dengan susunan panjang

dengan lebih dari 10 langkah serta membutuhkan informasi

detail. Langkah-langkah yang telah diidentifikasi dapat

dijabarkan kedalam sub-sub langkah dengan lebih rinci.

3. Grafik (Graphic)

Grafik digunakan apabila prosedur yang disusun mempunyai

kegiatan yang panjang dan spesifik. Dari langkah yang panjang

dapat dijabarkan melalui sub-proses yang lebih pendek dan

21

berisi langkah singkat. Pegawai lebih mudah melaksanakan

prosedur menggunakan format grafik. Dengan adanya sebuah

grafik dapat menggambarkan prosedur kedalam foto atau

diagram.

4. Diagram Alir (Flowcharts)

Flowcharts digunakan apabila SOP diperlukan dalam

pengambilan keputusan kompleks dan membutuhkan jawaban

iya dan tidak. Hal ini dapat mempengaruhi sub langkah

selanjutnya. Flowcharts memberikan langkah mudah untuk

diikuti dan diterapkan oleh para pegawai melalui sususan

langkah sesuai dengan keputusan yang telah diambil. Dalam

penerapan format ini perlu menggambarkan proses dengan

symbol-simbol. Setiap simbol memiliki fungsi dan makna

teknis yang khas. Pada dasarnya flowcharts dikembangkan dari

simbol dasar seperti, simbol kapsul (terminator), simbol kotak

(process), simbol belah ketupat (decision) dan anak panah

(arrow).

2.2.5.2. Dokumen Standard Operating Procedure (SOP)

Penelitian ini menghasilkan produk berupa dokumen SOP yang

berisi prosedur-prosedur yang distandarkan. Berdasarkan pada

peraturan pemerintah (Menteri Pendayagunaan Aparatur

Negara dan Reformasi Birokrasi Republik Indonesia Nomor 35

tahun 2012), format SOP merupakan bagian dari penyusunan

dokumen SOP. Tidak ada format SOP yang baku atau standar,

format SOP dipengaruhi oleh tujuan dari pembuatan SOP

sehingga apabila tujuan penyusunan berbeda maka format SOP

akan berbeda [14].

Sesuai dengan anatomi dokumen SOP pada hakekatnya

merupakan dokumen yang berisi prosedur-prosedur yang

distandarkan secara keseluruhan dapat membentuk satu

kesatuan proses sehingga informasi yang dimuat dalam

dokumen SOP meliputi: Unsur Dokumentasi dan Unsur

Prosedur. Informasi yang terdapat dalam Unsur dokumentasi

dan unsur prosedur adalah sebagai berikut [14]:

1. Unsur Dokumentasi

22

Merupakan unsur dari dokumen SOP yang berisi hal-hal terkait

dengan proses pendokumentasian SOP sebagai sebuah

dokumen. Hal ini dilakukan agar sebuah SOP lebih tercata dan

dapat dijadikan acuan melakukan aktivitas terstandar. Unsur

dokumentasi tersebut mencakup [14]:

Halaman Judul; berisi judul SOP, instansi/satuan kerja,

tahun pembuatan dan informasi lain yang diperlukan.

Halaman judul dapat disesuaikan dengan kebutuhan

instansi yang membuat. Adapun contoh halaman judul

sebuah dokumen SOP berikut ini :

Keputusan Pimpinan Kementrian / Lembaga/

Pemda; Dengan adanya dokumen SOP sebagai

pedoman setiap pegawai structural, fungsional atau

Gambar 2.3 Halaman Judul sebuah Dokumen SOP

23

operasional, maka dokumen perlu mempunyai dasar

hukum yang kuat. Setelah halaman judul, disajikan

halaman yang berisi keputusan atau kebijakan

Pimpinan Kementerian/Lembaga/Pemda mengenai

penetapan dokumen SOP.

Daftar isi dokumen SOP; merupakan daftar isi yang

digunakan untuk membantu mempercepat pencarian

informasi.

Penjelasan singkat penggunaan; dokumen SOP

sebaiknya memuat penjelasan bagaimana membaca dan

menggunakan dokumen tersebut. Isi dari bagian ini

antara lain mencakup: Ruang Lingkup, menjelaskan

tujuan prosedur dibuat dan kebutuhan organisasi;

Ringkasan, memuat ringkasan singkat mengenai

prosedur yang dibuat; dan Definisi umum, memuat

beberapa definisi yang terkait dengan prosedur yang

distandarkan.

2. Unsur Prosedur

Terdapat dua unsur prosedur yaitu bagian identitas dan bagian

flowchart. SOP dapat diklasifikasikan sesuai kebutuhan

organisasi. Bagian identitas tersebut dapat dilihat pada Gambar

2.4. Keterangan-keterangan lengkap dari setiap nomor pada

Gambar 2.4 :

1. Logo dan Nama Instansi/Satuan Kerja/Unit Kerja,

nomenklatur satuan/unit organisasi pembuat;

2. Nomor SOP, berisi nomor prosedur SOP

3. Tanggal pembuatan, tanggal pembuatan SOP

4. Tanggal Revisi, tanggal SOP apabila dilakukan revisi 5. Tanggal Efektif, tanggal mulai diberlakukannya SOP

6. Pengesahan oleh pejabat yang berkompeten pada

tingkat satuan kerja, berisi pengesahan dengan

mencantumkan jabatan, tanda tangan, nama pejabat, NIP

dan stempel/cap instansi

7. Judul SOP, judul prosedur yang akan dibuat SOP

8. Dasar Hukum, peraturan yang mendasari prosedur serta

aturan pelaksanaannya.

24

9. Keterkaitan, berisi penjelasan mengenai keterkaitan

prosedur yang distandarkan

10. Peringatan, berisi penjelasan jika prosedur tidak

dijalankan

11. Kualifikasi Pelaksana, berisi penjelasan mengenai

kualifikasi pelasana yang dibutuhkan dalam melaksanakan

SOP

12. Peralatan dan Perlengkapan, berisi penjelasan mengenai

kualifikasi pelaksana yang dibutuhkan dalam

melaksanakan perannya.

13. Pencatatan dan Pendataan, berisi berbagai hal yang perlu

didata dan dicatat.

Sedangkan bagian flowchart, merupakan uraian mengenai

langkah-langkah prosedur kegiatan beserta mutu baku dan

keterangan yang diperlukan. Berikut adalah contoh bagian

flowchart seperti Gambar 2.5. Berdasarkan penjabaran di

Gambar 2.5, kaitannya kriterian dan format serta penyusunan

Gambar 2.4 Contoh Bagian Identitas SOP

25

dokumen SOP terhadap penelitian ini dapat memudahkan

penulis dalam memberikan acuan perancangan SOP

manajemen perubahan pada GRMS. Dokumen SOP sebagai

bukti tertulis telah disusunnya proses yang distandarkan. Hal

tersebut diletakkan dan diberikan kepada penanggung jawab

dan pelaksana proses agar dapat diperhatikan dan dilaksanakan.

Gambar 2.5 Contoh Bagian Flowchart SOP

26

(halaman ini sengaja dikosongkan)

27

BAB III

METODOLOGI

Bab ini menjelaskan metode penelitian yang digunakan dalam

pengerjaan tugas akhir.

3.1. Diagram Metodologi Secara garis besar, metode penelitian dijabarkan di dalam

Gambar 3.1 :

28

Gambar 3. 1 Metodologi

29

3.2. Uraian Metode Pengerjaan Tugas Akhir Poin-poin di bawah ini merupakan uraian dari rencana

metodologi yang digunakan oleh penulis.

3.2.1. Tahap Penyusunan Interview Protocol

Tahap ini merupakan tahap pendahuluan yang perlu

dipersiapkan sebelum memulai penyusunan SOP. Sebelum

memulai melakukan penggalian data, dilakukan penyusunan

daftar interview protocol melalui proses penggalian data yang

berdasarkan standar acuan untuk mengkategorikan tujuan dan

area dari setiap pertanyaan. Acuan-acuan tersebut berupa

metode analisis kesenjangan dan ITIL v3 mengenai manajemen

perubahan. Hasil akhir dari tahap ini yaitu daftar interview

protocol yang nantinya digunakan untuk melakukan tahap

pengumpulan data.

3.2.2. Tahap Pengumpulan Data dan Informasi

Tahap ini merupakan tahap dimana penulis melakukan

pengumpulan data dan informasi yang akan digunakan untuk

bahan analisis dalam penyusunan dokumen SOP. Pengumpulan

data dan informasi dilakukan dengan dua metode, yaitu

wawancara dan observasi. Hasil akhir dari tahap ini yaitu

kondisi kekinian dan proses kondisi kekinian serta kondisi ideal

yang diharapkan.

A. Wawancara

Wawancara dilakukan dengan mengajukan pertanyaan-

pertanyaan dari daftar interview protocol untuk mengetahui

kondisi kekinian dan kondisi yang diharapkan pada organisasi.

Wawancara akan dilakukan terhadap pihak yang berhubungan

dengan proses pengelolaan pengembangan aplikasi teknologi

informasi. B. Observasi

Observasi dilakukan dengan memperhatikan kondisi yang

sedang berlangsung pada lokasi organisasi. Kondisi tersebut

dapat berupa media-media yang mendukung proses manajemen

perubahan terhadap kebutuhan aplikasi GRMS. Metode ini

30

secara tidak langsung akan memvalidasi dan memverifikasi

terhadap setiap hasil wawancara yang telah didapatkan.

3.2.3. Tahap Analisis Kesenjangan

Tahap ini merupakan tahap dimana penulis melakukan analisis

kesenjangan antara kondisi ideal pengembangan aplikasi

teknologi informasi menurut manajemen perubahan ITIL v3

dengan kondisi kekinian pengembangan aplikasi teknologi

informasi yang berlangsung oleh pihak Bina Program. Dengan

menemukan kesenjangan antara keduanya, maka hasil analisis

kesenjangan tersebut akan digunakan dalam penyusunan isi

dokumen SOP terkait pengelolaan pengembangan aplikasi yang

dapat digunakan untuk mencapai kondisi ideal yang

diharapkan.

A. Analisis Kondisi Kekinian dan Kondisi Ideal

Analisis kondisi kekinian didapatkan dari hasil wawancara dan

observasi yang telah dilakukan sebelumnya untuk mendapatkan

gambaran manajemen perubahan terhadap kebutuhan GRMS

yang telah diterapkan oleh pihak Bina Program selama ini.

Kondisi kekinian yang didapat antara lain aktivitas

pengembangan GRMS, kebijakan yang ada, dan jumlah pihak

yang menangani. Sedangkan analisis kondisi ideal didapatkan

berdasarkan kerangka kerja ITIL V3 mengenai manajemen

perubahan. Kondisi ideal manajemen perubahan menurut ITIL

V3 menguraikan tujuh aktivitas utama yang wajib dilakukan

antara lain membuat dan merekam permintaan perubahan,

meninjau permintaan perubahan, menilai dan mengevaluasi

perubahan, mengautorisasi perubahan, memperbaharui

rencana, mengkoordinasikan implementasi, dan mengevaluasi

dan menutup proyek.

B. Analisis Kesenjangan

Kesenjangan didapatkan dari adanya kekurangan atau

ketidakcocokan antara kondisi kekinian dengan kondisi ideal.

Setelah kesenjangan telah ditemukan, maka akan dilakukan

analisis kesenjangan dengan tujuan untuk mengevaluasi

kesenjangan antara kondisi kekinian dengan kondisi ideal

tersebut. Hasil analisis kesenjangan akan diuraikan dalam

bentuk tabel kesenjangan.

31

3.2.4. Tahap Perancangan dan Pembuatan Dokumen SOP

Tahap ini merupakan tahap dimana penulis akan melakukan

perancangan isi SOP terkait pengelolaan pengembangan

aplikasi yang berdasarkan hasil analisis kesenjangan antara

kondisi kekinian dengan kondisi ideal yang diharapkan dan

pedoman penyusunan SOP yang berdasarkan standar yang

mengatur isi dan struktur SOP. Setelah itu, penulis melakukan

penyusunan dan pembuatan dokumen SOP yang berisi prosedur

pengelolaan pengembangan aplikasi teknologi informasi

berdasarkan standar. Setelah selesai dibuat, dokumen SOP akan

dilakukan tahap verifikasi dan tahap validasi terlebih dahulu. A. Menyusun Dokumen SOP manajemen perubahan

untuk kebutuhan aplikasi GRMS

Penyusunan dokumen SOP manajemen perubahan untuk

kebutuhan aplikasi GRMS dilakukan berdasarkan hasil analisis

kesenjangan yang telah didapat sebelumnya. Dokumen SOP ini

akan memuat prosedur yang mencakup aktivitas-aktivitas

utama manajemen perubahan. Dokumen SOP yang telah selesai

disusun akan diserahkan kepada pihak Bina Program untuk

dilakukan verifikasi dan validasi.

B. Verifikasi

Tahap ini dilakukan untuk mengetahui apakah prosedur yang

telah dihasilkan telah sesuai dengan kebutuhan organisasi

berdasarkan standar acuan dan pihak dari Bina Program yang

bersangkutan, yaitu pihak admin dan pihak kasubag dari

masing-masing aplikasi GRMS. Verifikasi dilakukan dengan

menggunakan metode wawancara.

C. Validasi

Tahap ini dilakukan untuk mengetahui ketepatan prosedur

ketika telah diimplementasikan dalam organisasi dan dilakukan

oleh penyusun SOP tersebut. Apabila masih terdapat

ketidaksesuaian, maka akan dilakukan perbaikan terhadap

prosedur SOP tersebut.

3.2.5. Tahap Penyusunan Dokumen Akhir

Tahap ini merupakan tahap akhir dimana dokumen prosedur

SOP telah selesai diverifikasi dan divalidasi oleh pihak Bina

32

Program. Penulis akan melakukan penyusunan dokumen akhir

dan menarik kesimpulan akhir dari perumusan masalah yang

telah dibentuk sebelumnya dan berdasarkan hasil akhir

penelitian. Setelah itu, penulis juga akan membuat dan

merekomendasikan saran bagi organisasi yang diperlukan

untuk perbaikan proses pengelolaan pengembangan aplikasi

teknologi informasi dan saran bagi penelitian selanjutnya

mengenai apa yang perlu dilakukan dan yang perlu diperbaiki.

Dokumen SOP kemudian akan diberikan pada organisasi.

33

BAB IV

PERANCANGAN Bagian ini menjelaskan proses perancangan penelitian tugas

akhir yang digunakan sebagai panduan dalam melakukan

penelitian tugas akhir.

4.1. Perancangan Studi Kasus Pada bagian ini merupakan perancangan yang digunakan dalam

penetapan studi kasus dalam penelitian tugas akhir

4.1.1. Tujuan Studi Kasus

Studi kasus memungkinkan peneliti untuk meneliti data dalam

konteks tertentu. Pada penelitian ini dilakukan penyusunan

dokumen SOP manajemen perubahan pada kebutuhan aplikasi

GRMS yang dapat dijadikan masukan dalam pengelolaan

pengembangan sistem. Studi kasus didefinisikan sebagai

penyelidikan sebuah proses nyata dengan menggunakan cara-

cara yang sistematis dalam pengumpulan data, seperti obervasi

dan wawancara [15].

Menurut Yin, terdapat 3 tipe dari studi kasus, antara lain [11] :

Eksplorasi (menggali) : tipe studi kasus yang

mengeksplorasi fenomena dalam data yang berfungsi

sebagai tempat tujuan untuk peneliti

Deskriptif : tipe studi kasus yang menggambarkan

fenomena yang terjadi di dalam data dalam bentuk

narasi

Explanatory (memperjelas) : tipe studi kasus yang

menjelaskan fenomena yang terjadi secara jelas mulai

dari hal yang mendasar hingga yang paling dalam

secara lebih detail

Dalam pengerjaan tugas akhir ini, penulis menggunakan tipe

studi kasus eksplorasi (menggali). Eksplorasi dilakukan pada

studi kasus untuk penggalian data dan melihat fenomena

mengenai gambaran umum layanan dan proses bisnis yang

terkait dengan manajemen perubahan pada kebutuhan aplikasi

GRMS dan fenomena tersebut dapat dijadikan dasar dalam

34

pembuatan SOP. Tujuan dari penggunaan studi kasus untuk

menyelesaikan rumusan masalah dalam penelitian tugas akhir.

Perancangan fokus studi kasus terbagi menjadi 2 jenis, yaitu

single case design yang berfokus pada satu kasus dan multiple

case design yang berfokus pada berbagai kasus. Perancangan

studi kasus yang digunakan dalam penelitian tugas akhir ini,

peneliti adalah single case design yang akan berfokus pada

Bagian Bina Program Pemerintah Kota Surabaya sebagai objek

penelitian. Terdapat 2 tipe dalam single case design, yaitu yaitu

single unit of analysis dan multiple units of analysis.

Single unit of analysis dapat digunakan pada penelitian dimana

terdapat kasus unik, kritis ataupun penyimpangan kasus.

Sementara, multiple units of analysis dapat digunakan pada

penelitian yang melakukan replikasi temuan di seluruh studi

kasus dengan cara membandingkan sub-units.

Pada tugas akhir ini menggunakan single unit of analysis. Unit

of analysis dalam tugas akhir ini adalah melakukan analisis

terhadap aktivitas pengembangan terhadap kebutuhan aplikasi

GRMS oleh Bina Program Pemerintah Kota Surabaya.

4.1.2. Subjek dan Objek Penelitian

Subjek penelitian ini adalah Bagian Bina Program Kota

Surabaya yang merupakan pihak pengelola dari sistem GRMS

di lingkungan Pemerintah Kota Surabaya. Sedangkan objek

penelitian ini adalah proses dan layanan manajemen perubahan

terhadap kebutuhan aplikasi yang terdapat dalam alur

pengembangan GRMS. Proses tersebut akan disesuaikan

dengan kerangka kerja Change Management ITIL V3 dan

metode analisis kesenjangan sehingga proses manajemen

perubahan dapat diterapkan dengan baik. Dalam penelitian ini

penulis mendapatkan dukungan penuh dari pihak Bagian Bina

Program Kota Surabaya yang merupakan penanggung jawab

pengelolaan perubahan terhadap kebutuhan aplikasi GRMS.

35

4.2. Perancangan Penggalian Data Pada bagian ini merupakan perancangan perangkat yang

digunakan untuk menggali data kondisi kekinian.

4.2.1. Data yang Diperlukan

Pada bagian ini merupakan perancangan perangkat yang

digunakan dalam penggalian data kondisi kekinian mengenai

gambaran umum aktivitas manajemen perubahan terhadap

kebutuhan aplikasi GRMS oleh Bina Program Pemerintah Kota

Surabaya.

Berikut merupakan poin-poin mengenai data yang dibutuhkan

dalam penelitian tugas akhir :

1. Proses bisnis pengembangan setiap aplikasi GRMS

2. Kebijakan Bina Program dalam pengembangan

terhadap kebutuhan aplikasi GRMS

3. Kondisi kekinian manajemen perubahan terhadap

kebutuhan aplikasi GRMS

4. Kondisi Ekspektasi manajemen perubahan terhadap


4.2.2. Teknik Penggalian Data

Pada bagian ini merupakan persiapan penggalian data dan

perancangan metode penggalian data yang akan dilakukan.

Persiapan penggalian data dilakukan dengan menyusun

interview protocol yang berisi daftar pertanyaan yang akan

diajukan. Metode penggalian data yang akan dilakukan adalah

wawancara dan observasi.

4.3. Perancangan Interview Protocol Interview protocol merupakan daftar pertanyaan yang

digunakan sebagai panduan penelitian ketika melakukan

wawancara agar jelas dan terarah. Daftar pertanyaan tersebut

harus sesuai dengan tujuan wawancara yaitu data dan informasi

yang ingin didapatkan. Interview protocol digunakan untuk

menggali kondisi kekinian terkait pengelolaan manajemen

akses saat ini. Berikut merupakan tampilan dari interview

36

protocol mengenai pencatatan informasi saat melakukan

wawancara :

Table 4.1 Pencatatan Informasi Saat Wawancara

Tujuan Interview : (Contoh: Mendapatkan informasi

terkait kondisi kekinian

manajemen perubahan terhadap

kebutuhan aplikasi GRMS)

Tanggal : (Contoh: 14 April 2016)

Waktu : (Contoh: 11.30 WIB)

Lokasi : (Contoh: Ruang Bina Program

Lantai 3)

Narasumber : (Contoh: Sam Joe)

Jabatan : (Contoh: Kepala Sub Bagian

Bina Program)

Topik : (Contoh: Manajemen Perubahan

terhadap Kebutuhan Aplikasi

GRMS)

Berikut merupakan tampilan pertanyaan yang tertera dalam

interview protocol terdapat pada table dibawah ini:

Table 4.2 Tampilan Interview Protocol

Topik : (Contoh:Manajemen Perubahan terhadap

Kebutuhan Aplikasi GRMS)

No. Uraian Pertanyaan

1. Pertanyaan: (Contoh:Siapa saja pihak yang terlibat

dalam proses manajemen perubahan terhadap

kebutuhan aplikasi GRMS selama ini?)

Jawaban: (Contoh:Pengguna, Admin, Kasubag, dan

Programmer)

2. Pertanyaan:

Jawaban:

3. Pertanyaan:

Jawaban:

37

4. Pertanyaan:

Jawaban:

5. Pertanyaan:

Jawaban:

Dalam menyusun interview protocol, penulis menggunakan

standar acuan kerangka kerja aktivitas dalam proses manajemen

perubahan ITIL V3. Beberapa poin penting yang akan diajukan

kepada interviewee adalah:

1. Aktor dan peran yang terlibat dalam manajemen

perubahan terhadap kebutuhan aplikasi GRMS

2. Kondisi kekinian manajemen perubahan terhadap

kebutuhan aplikasi GRMS yang diterapkan oleh Bina

Program

3. Kondisi ekspektasi manajemen perubahan terhadap

kebutuhan aplikasi GRMS yang diterapkan oleh Bina

Program

Penyusunan poin-poin pertanyaan pada interview protocol

menggunakan standar acuan kerangka kerja aktivitas dalam

proses manajemen perubahan ITIL V3. Berikut ini adalah

kaitan antara poin-poin pertanyaan dan penjelasannya:

Table 4.3 Poin Pertanyaan Interview Protocol 1

Pertanyaan Referensi

Pendefinisian Aktor dan Role manajemen perubahan

terhadap kebutuhan GRMS

Siapa saja pihak yang

terlibat dalam

aktivitas

pengembangan

aplikasi GRMS?

Single unit of analysis

Apakah terdapat

pembentukan tim

khusus untuk

penanganan


38

pengembangan

aplikasi GRMS

Bagaimana

pembagian peran dari

masing-masing pihak

yang terlibat?


Table 4.4 Poin Pertanyaan Interview Protocol 2


Identifikasi Kondisi Existing

Bagaimana proses

penanganan Bina Program

terhadap permintaan

perubahan? Apakah terdapat

aktivitas :

Membuat dan

mencatat

permintaan

perubahan

Meninjau

permintaan

perubahan

Menilai dan

mengevaluasi

perubahan

Autorisasi

perubahan

Memperbaharui

rencana

Mengkoordinasikan

implementasi

Mengevaluasi dan

menutup perubahan

Create and record RFC

Review the RFC

Assess and Evaluate the

change


Plan updates

Coordinating change

implementation

Review and close

change

39


Siapa sajakah yang dapat

mengajukan permintaan

perubahan?


Apakah terdapat aplikasi

pencatatan permintaan

perubahan yang masuk?

Apabila ada, apa bentuk

pencatatannya?


Bagaimana pengkategorian

perubahan yang diterapkan

oleh Bina Program?

Review the RFC

Apakah pernah terjadi

permasalahan selama proses

pengembangan aplikasi

GRMS mulai dari

pengajuan permintaan

perubahan hingga

penutupan perubahan?

Apabila ada, apa sajakah

itu?


Identifikasi Kondisi Ekspektasi

Bagaimana harapan

kedepan terkait proses

pengelolaan pengembangan

aplikasi GRMS?


Review the RFC

Assess and Evaluate the

change


Plan updates

Coordinating change

implementation

Review and close

change

Hasil penyusunan interview protocol dapat dilihat pada

LAMPIRAN A.

40

4.4. Perancangan Analisis Data

pada bagian ini merupakan perancangan yang digunakan dalam

melakukan analisis data

4.4.1. Metode Pengolahan Data

Metode pengolahan data yang digunakan adalah analisa

deskriptif yang berasal dari hasil wawancara ,observasi dan

review dokumen terkait terhadap kondisi kekinian serta kondisi

ideal berdasarkan standar acuan mengenai pengelolaan

manajemen perubahan terhadap kebutuhan aplikasi GRMS.

Selain itu digunakan pula tools dalam wawancara yaitu

recorder sebagai media pendukung dalam melakukan analisa

deskriptif terhadap kondisi kekinian. Untuk memvisualisasikan

kondisi kekinian dari hasil penggalian data dapat menggunakan

bizagi modeler. Tujuan digunakannya metode pengolahan data

untuk memberikan informasi yang sesuai dengan kebutuhan

penelitian tugas akhir. Hasil dari pengolahan data dapat

dianalisis lebih lanjut untuk digunakan dalam pembuatan

dokumen SOP manajemen perubahan terhadap kebutuhan

aplikasi GRMS.

4.4.2. Penentuan Pendekatan Analisis

Pendekatan analisis digunakan untuk mengetahui hubungan

antara data yang sudah diolah dengan tujuan dari penelitian

tugas akhir. Sehingga, analisis dapat dilakukan dengan

melakukan pendekatan terhadap standar acuan dan analisis

kesenjangan. Berikut penjelasan terhadap masing-masing

pendekatan yang digunakan :

4.4.2.1 Pendekatan Analisis Standar Acuan

Pendeketan analisis menggunakan standar ITIL V3 mengenai

Manajemen Perubahan. Analisis dengan pendekatan ITIL yang

berfokus pada proses manajemen perubahan untuk

menggambarkan kondisi kekinian sesuai dengan aktivitas

dalam manajemen perubahan, mulai dari proses membuat dan

merekam permintaan perubahan, meninjau permintaan

perubahan, menilai dan mengevaluasi perubahan,

mengautorisasi perubahan, memperbaharui rencana,

41

mengkoordinasi implementasi, dan mengevaluasi dan menutup

perubahan.

4.4.2.2 Pendekatan Analisis Kesenjangan

Analisis dengan pendekatan analisis kesenjangan yang

digunakan untuk mengetahui kesenjangan antara standar

layanan dan proses penyediaan layanan aplikasi GRMS yang

terkait dengan manajemen perubahan terhadap kebutuhan

aplikasi. Analisis kesenjangan berguna untuk mengetahui

adanya ketidaksesuaian antara kondisi kekinian dengan kondisi

ideal sehingga perlu dilakukan adanya standarisasi berdasarkan

suatu kerangka kerja. Hasil dari analisis kesenjangan akan

dijadikan input untuk perancangan dokumen standard

operating procedure.

4.5. Perancangan Standard Operating Procedure Perancangan dokumen SOP dilakukan berdasarkan hasil

analisis kesenjangan yang telah didapat sebelumnya. Dokumen

SOP yang telah selesai dirancang dan dibuat akan diserahkan

kepada pihak organisasi untuk diverifikasi dan divalidasi pada

lingkungan organisasi.

4.5.1. Verifikasi

Verifikasi diajukan kepada pihak pengelola aplikasi GRMS

yakni Bina Program Pemerintah Kota Surabaya. Didalam tahap

verifikasi ini ada beberapa aktivitas verifikasi yang dilakukan,

yaitu tujuan verifikasi, sasaran verifikasi, metode verifikasi dan

tahap pengujian verifikasi.

Table 4.5 Detail Verifikasi SOP

Tujuan Memverifikasi dokumen untuk

mengecheck kebenaran dari

informasi-informasi yang

didefinisikan dan termuat dalam

dokumen SOP.

Metode Wawancara secara langsung

Sasaran Kepala sub Bina Program

42

Alur

Verifikasi

1. Penulis mengirimkan

dokumen SOP

2. Penulis meminta penanggung

jawab untuk mereview

dokumen SOP yang telah

dikirim dan memberikan

feedback

3. Penulis mengadakan

wawancara langsung dengan

penanggung jawab

4. Penulis melakukan

wawancara secara langsung

terkait dengan istilah kata

yang digunakan dalam SOP

dan informasi-informasi yang

dimasukkan ke dalam

dokumen SOP

5. Penanggung jawab

memberikan review dan

tanggapan dari pertanyaan

penulis dan memberikan

revisi (jika ada)

6. Penulis melakukan

pembenahan konten dokumen

7. Penulis mengirim ulang hasil

revisi kepada penanggung

jawab

8. Penanggung jawab menerima

dokumen SOP yang telah

diperbaiki

9. Penanggung jawab

menyutujui dokumen SOP

yang telah diperbarui

43

4.5.2. Validasi

Validasi diajukan pada pihak yang menggunakan aplikasi

GRMS dan kepala sub bagian Bina Program. Saat validasi akan

berlangsung proses uji coba simulasi penggunaan SOP selama

3 hari. Di dalam tahap validasi terdapat aktivitas validasi yang

dilakukan, yaitu tujuan, sasaran validasi, metode validasi dan

tahap pengujian validasi.

Table 4.6 Detail Validasi SOP

Tujuan Memvalidasi dokumen dengan melihat

apakah SOP depat berjalan sesuai dengan

kondisi yang ada dan untuk menemukan

kekurangan dari SOPyang telah dibuat

sehingga dapat dibenahi dan diterapkan

Metode Wawancara

Sasaran Kepala Sub Bagian Bina Program

Alur

Validasi

1. Penulis mengirimkan satu SOP dan

form-form terkait kepada penanggung

jawab atau teknisi untuk melakukan

pengujian SOP

2. Pelaksana menerima dokumen SOP,

kemudian memahami SOP yang dibuat

penulis.

3. Pelaksana mensimulasikan SOP yang

dikirim, termasuk melakukan

pengisian form dengan menggunakan

salah satu permintaan perubahan yang

masuk

4. Setelah dilakukan simulasi SOP dan

pengisian form-form yang ada,

selanjutnya adalah meminta feedback

dari pelaksana.

5. Setelah selesai, maka dengan

persetujuan penanggung jawab, SOP

yang dibuat telah valid dan dapat

diterapkan.

44


45

BAB V

IMPLEMENTASI

Bab ini menjelaskan hasil dari proses perancangan studi kasus

yang didapatkan melalui wawancara dan review dokumen.

5.1 Analisis Kondisi Kekinian dan Kondisi Ideal

5.1.1 Hasil Wawancara

Berdasarkan perancangan perangkat penggalian data,

narasumber yang akan dituju merupakan admin pada setiap

aplikasi GRMS yang berjumlah 5 orang antara lain:

1. Ibu Galuh Ayu Jendrawati, selaku admin aplikasi e-

Controlling dan aplikasi e-Project. Wawancara

dilakukan pada tanggal 13 April 2016.

2. Ibu Pratiwi Sri Hadi, selaku admin aplikasi e_delivery.

Wawancara dilakukan pada tanggal 13 April 2016.

3. Ibu Dian Septiani Santoso, selaku admin aplikasi e-

Budeting. Wawancara dilakukan pada tanggal 14 April

2016.

4. Ibu Enik Supristiyowati, selaku admin aplikasi e-

Performance. Wawancara dilakukan pada tanggal 18

April 2016.

Hasil wawancara terdapat pada LAMPIRAN B. Poin-poin

penting yang ditanyakan dalam wawancara dan observasi antara

lain :

Pendefinisan aktor dan peran manajemen perubahan

terhadap aplikasi GRMS

Gambaran umum layanan pengembangan aplikasi

GRMS

Proses pengembangan aplikasi GRMS

5.1.2 Pendefinisian Aktor dan Role GRMS

Masing-masing aplikasi pada GRMS umumnya memiliki satu

penanggung jawab yang berperan sebagai admin. Akan tetapi,

terdapat pengecualian untuk dua aplikasi. Pada aplikasi e-

Budgeting memiliki lebih dari satu admin. Selain itu, aplikasi

46

e-Performance memiliki 2 admin, yaitu super admin dan admin

SKPD. Berdasarkan dari hasil wawancara pada poin pertanyaan

2 dan 3 mengenai aktivitas yang menjadi tanggung jawab dalam

pengembanan GRMS, maka dapat disimpulkan bahwa tugas

dan fungsi setiap role adalah sebagai berikut:

1. Super Admin/Admin Bina Program

Administrator yang bertanggung jawab atas

manajemen pengelolaan GRMS untuk seluruh SKPD.

Fungsinya dalam manajemen perubahan antara lain:

o Menerima adanya permintaan perubahan dari

user dan meninjau ulang detail permintaan

perubahan untuk persetujuan esksekusi

perubahan terhadap sistem

o Menjabarkan alur dan detail perubahan kepada

pihak programmer untuk tidak menimbulkan

kesalahpahaman

o Memeriksa hasil eksekusi perubahan yang

telah diselesaikan oleh pihak programmer

2. Admin SKPD

Administrator memiliki kewenangan untuk

bertanggung jawab atas kendali yang berkaitan dengan

SDM di masing-masing SKPD. Mereka bertugas untuk

menerima adanya permintaan perubahan dari user

(SKPD) dan akan disampaikan kepada pihak super

admin / admin Bina Program.

3. Kasubag

Kasubag memiliki kewenangan paling besar untuk

menyetujui setiap permintaan perubahan yang diajukan

oleh pengguna. Persetujuan permintaa perubahan

dilakukan berdasarkan kebutuhan, hukum, atau

undang-undang yang berlaku.

4. User

Merupakan pengguna layanan GRMS yaitu SKPD,

admin, penyedia layanan (karyawan Bina Program)

maupun masyarakat umum. User merupakan pihak

yang dapat melakukan permintaan perubahan kepada

pihak admin.

47

5.1.3 Kategorisasi Perubahan Layanan TI

Jenis perubahan layanan TI pada GRMS dikategorisasikan

mejadi 2 kategori menurut pihak admin Bina Program, yaitu:

1. Besar: Perubahan yang berpengaruh besar dan

membutuhkan jangka waktu panjang

2. Kecil: Perubahan yang tidak berpengaruh besar dan

tidak membutuhkan jangka waktu panjang

Isi pada Table 5.1 adalah permasalahan layanan TI yang sering

terjadi didalam kelima aplikasi berdasarkan hasil wawancara

yang ada pada LAMPIRAN B:

Table 5.1 Kategori Perubahan Menurut pengalaman Admin Bina

Program berdasarkan tiap aplikasi

Aplikasi Kategori Besar Kategori Kecil

e-Budgeting

Penambahan

fitur baru

dalam aplikasi

Penambahan

alur proses

bisnis dalam

aplikasi

Penambahan

laporan dalam

aplikasi

Penambahan

fitur verifikasi

pengguna dalam

aplikasi

e-Project dan e-

Controlling

(Pihak admin

yang menangani

adalah orang

yang sama)

Penambahan

fitur baru

dalam aplikasi

Penambahan

fitur notifikasi

dalam aplikasi

Perubahan data

dalam aplikasi

Perubahan alur

proses bisnis

dalam aplikasi,

contohnya

Penambahan

fitur validasi

dalam aplikasi

48

e-Delivery

Perubahan data

dalam aplikasi

Pemberian hak

akses dalam

aplikasi

Penambahan

fitur baru

dalam aplikasi

Penambahan

fitur verifikasi

pengguna dalam

aplikasi

e-Performance

Pengaturan

bobot kerja

dalam aplikasi

Perubahan

status data

pegawai dalam

aplikasi

Perubahan alur

proses bisnis

dalam aplikasi

Perubahan tata

letak fitur dalam

aplikasi

5.1.4 Kondisi Kekinian Manajemen Perubahan Terhadap

Aplikasi GRMS

Pada bagian ini akan membahas mengenai kondisi kekinian

terhadap pengembangan aplikasi GRMS. Kondisi kekinian

didapatkan dari hasil wawancara dengan para admin GRMS.

Untuk hasil wawancara lengkap, terlampir pada LAMPIRAN

B.

Dalam melakukan analisis kondisi kekinian, berdasarkan

tahapan service design ITIL V3 terdapat 4 aspek penting dalam

mendesain sebuah layanan TI. Keempat aspek tersebut

merupakan aspek penting yang digunakan karena sesuai dengan

standar ITIL dalam melakukan persiapan dan perencanaan yang

efektif dan efisien. Keempat aspek tersebut antara lain adalah:

People: merupakan pihak yang terlibat dalam layanan

TI dan memiliki peran maupun tanggung jawab

masing-masing

Processes: merupakan aktivitas, kebijakan, prosedur

dan tindakan dari layanan TI

49

Product: merupakaan aspek aplikasi, infrastruktur,

sistem manajemen dan teknologi yang digunakan untuk

menyediakan layanan TI

Partners: merupakan Pihak pendukung yang terlibat

dalam penyediaan layanan TI seperti manufactures,

suppliers dan vendor.

Dalam penelitian ini, peneliti menggunakan dua dari empat

aspek yang ada yaitu people dan processes karena berdasarkan

standar terhadap kebutuhan suatu organisasi. Organisasi dapat

merasakan keuntungan dari penggunaan ITIL ketika terdapat

kesesuaian dan kejelasan terhadap proses dan pihak yang terkait

dengan proses. Sedangkan di dalam studi kasus yang berfokus

adanya manajemen perubahan terhadap aplikasi GRMS,

kesesuaian proses dan sumber daya menjadi hal yang penting.

Oleh karena itu, peneliti menggunakan kedua aspek yaitu

people dan processes dari empat aspek yang digunakan. Selain

itu aspek ini digunakan berdasarkan hasil wawancara terhadap

kondisi kekinian.

A. Aktivitas (Processes)

Berdasarkan standar ITIL V3 mengenai manajemen perubahan

terdapat 7 aktivitas utama dalam melakukan manajemen

perubahan, antara lain membuat dan merekam permintaan

perubahan, meninjau permintaan perubahan, menilai dan

mengevaluasi perubahan, mengautorisasi perubahan,

memperbaharui rencana, mengkordinasikan implementasi, dan

mengevaluasi dan menutup proyek. Berikut adalah gambaran

aktivitas manajemen perubahan pada ITIL V3 berdasarkan

kondisi kekinian manajemen perubahan GRMS untuk setiap

aplikasi pada Bina Program

50

5.1.4.1 Proses Manajemen Perubahan pada aplikasi e-

Budgeting

Gambar 5.1 Alur pengembangan aplikasi e-budgeting

Alur manajemen perubahan dimulai dari user. User merupakan

segala pihak yang menggunakan atau terlibat pada aplikasi e-

Budgeting. User mengajukan permintaan perubahan terkait e-

51

Budgeting kepada pihak admin e-Budeting. Pengajuan

dilakukan melalui walk-in. Admin akan meninjau permintaan

perubahan tersebut dan mengkategorisasikan jenis perubahan

tersebut. Sebelumnya, admin juga berhak untuk menolak

permintaan perubahan tersebut dengan alasan perubahan tidak

berpengaruh signifikan atau perubahan tidak sesuai dengan

kebijakan yang ada.

Jenis perubahan tersebut terbagi menjadi dua, yaitu perubahan

besar dan perubahan kecil. Contoh dari perubahan besar adalah

penambahan laporan, penambahan fitur verifikasi, dan

penambahan fitur. Sedangkan contoh dari perubahan kecil

adalah penambahan alur bisnis. Apabila perubahan

terkategorisasi besar, maka pihak admin harus mendiskusikan

terlebih dahulu kepada pihak kasubag penyusunan untuk

persetujuan. Diskusi biasanya dilakukan melalui sebuah rapat

yang diikuti oleh pihak kasubag dan pihak admin serta pihak

programmer apabila memang dibutuhkan. Apabila perubahan

terkategorisasi kecil, maka pihak admin tidak akan

mendiskusikan dengan pihak kasubag.

Setiap hasil persetujuan perubahan yang ada akan dicatat oleh

pihak admin ke dalam aplikasi TRAC sebagai media

pencatatan dan penyimpanan perubahan. Aplikasi TRAC dapat

diakses oleh pihak admin untuk pencatatan dan oleh pihak

programmer untuk melihat detail eksekusi perubahan yang

perlu dilakukan. Setelah itu, pihak programmer akan melakukan

eksekusi perubahan kebutuhan terhadap sistem dari penjabaran

detail permintaan perubahan dari pihak admin. Sistem yang

telah selesai dieksekusi oleh pihak programmer akan ditinjau

ulang oleh pihak admin untuk divalidasi apakah telah sesuai

dengan permintaan.

Apabila disetujui, maka pihak admin akan menyerahkan hasil

eksekusi tersebut kepada pihak kasubag terlebih dahulu untuk

persetujuan. Apabila disetujui, maka pihak admin atau pihak

programmer akan menyerahkan hasil eksekusi perubahan

kebutuhan kepada pihak user.

52


Project dan aplikasi e-Controlling

Gambar 5.2 Alur pengembangan aplikasi e-project dan e-controlling



Project dan e-Controlling. User mengajukan permintaan

perubahan terkait e-Project dan e-Controlling kepada pihak

penyelia admin e-Project dan e-Controlling terlebih dahulu.

53

Pengajuan dilakukan melalui walk-in. Kemudian pihak

penyelia admin menyampaikan permintaa perubahan terhadap

pihak admin e-Project dan e-Controlling. Pihak admin akan

meninjau permintaan perubahan tersebut dan

mengkategorisasikan jenis perubahan tersebut. Sebelumnya,

admin juga berhak untuk menolak permintaan perubahan

tersebut dengan alasan perubahan tidak berpengaruh signifikan

atau perubahan tidak sesuai dengan kebijakan yang ada.



perubahan alur proses bisnis dan penambahan validasi.

Sedangkan contoh dari perubahan kecil adalah penambahan

fitur, penambahan notifikasi, dan perubahan data. Apabila

perubahan terkategorisasi besar, maka pihak admin harus

mendiskusikan terlebih dahulu kepada pihak kasubag

penyusunan untuk persetujuan. Diskusi biasanya dilakukan

melalui sebuah rapat yang diikuti oleh pihak kasubag dan pihak

admin serta pihak programmer apabila memang dibutuhkan.

Apabila perubahan terkategorisasi kecil, maka pihak admin

tidak akan mendiskusikan dengan pihak kasubag.











dengan permintaan.






54


Delivery

Gambar 5.3 Alur pengembangan aplikasi e-delivery



Delivery. User mengajukan permintaan perubahan terkait e-

Delivery kepada pihak admin e-Delivery. Pengajuan dilakukan

melalui walk-in. Admin akan meninjau permintaan perubahan

tersebut dan mengkategorisasikan jenis perubahan tersebut.

55

Sebelumnya, admin juga berhak untuk menolak permintaan

perubahan tersebut dengan alasan perubahan tidak berpengaruh

signifikan atau perubahan tidak sesuai dengan kebijakan yang

ada.



perubahan alur proses bisnis dan penambahan fitur. Sedangkan

contoh dari perubahan kecil adalah perubahan data dan

pemberian hak akses. Apabila perubahan terkategorisasi besar,

maka pihak admin harus mendiskusikan terlebih dahulu kepada

pihak kasubag penyusunan untuk persetujuan. Diskusi biasanya

dilakukan melalui sebuah rapat yang diikuti oleh pihak kasubag

dan pihak admin serta pihak programmer apabila memang

dibutuhkan. Apabila perubahan terkategorisasi kecil, maka

pihak admin tidak akan mendiskusikan dengan pihak kasubag.











dengan permintaan.






56


Performance

Gambar 5.4 Alur pengembangan aplikasi e-performance



Performance. User mengajukan permintaan perubahan terkait e-

Performance kepada pihak admin e-Performance. Pengajuan

dilakukan melalui walk-in. Admin akan meninjau permintaan

perubahan tersebut dan mengkategorisasikan jenis perubahan

tersebut. Sebelumnya, admin juga berhak untuk menolak

57

permintaan perubahan tersebut dengan alasan perubahan tidak

berpengaruh signifikan atau perubahan tidak sesuai dengan

kebijakan yang ada.



penambahan laporan, penambahan fitur verifikasi, dan

penambahan fitur. Sedangkan contoh dari perubahan kecil

adalah penambahan alur bisnis. Apabila perubahan

terkategorisasi besar, maka pihak admin harus mendiskusikan

terlebih dahulu kepada pihak kasubag penyusunan untuk

persetujuan. Diskusi biasanya dilakukan melalui sebuah rapat

yang diikuti oleh pihak kasubag dan pihak admin serta pihak

programmer apabila memang dibutuhkan. Apabila perubahan

terkategorisasi kecil, maka pihak admin tidak akan

mendiskusikan dengan pihak kasubag.











dengan permintaan.






B. Kebijakan (Processes)

Kebijakan penggunaan aplikasi GRMS ada berdasarkan

Peraturan Walikota Surabaya Nomor 73 Tahun 2012. Selain itu,

sesuai dengan hasil wawancara bahwa penggunaan ITIL V3

sebagai acuan dalam pelaksaan e-government yang

58

terstandarisasi akan meningkatkan nilai dari penerapan tata

kelola TI di lingkungan Pemerintah Kota Surabaya.

C. Struktur Organisasi (People)

Bina Program merupakan sebuah bagian yang berada di bawah

Asisten Perekonomian dan Pembanguan Kota Surabaya yang

menangani perencanaan keuangan daerah Kota Surabaya.

Gambar 5.5 Struktur Organisasi Bina Program

Tupoksi dari masing-masing pegawai disesuaikan dengan

tupoksi yang telah diterbitkan oleh Perwali Kota Surabaya.

D. Sumber Daya Manusia (People)

Terdapat beberapa tipe pengguna yang berperan dalam

manajemen user GRMS. Masing-masing pengguna memiliki

peran masing-masing sesuai dengan Table 5.2 dibawah ini.

Table 5.2 Tipe Pengguna

Tipe Pengguna Peran

Super Admin/Admin Bina

Program

Pihak yang bertanggung

jawab terhadap manajemen

pengelolaan aplikasi GRMS

59

Admin SKPD


jawab terhadap kendali

pengelolaan aplikasi yang

sesuai dengan masing-

masing SKPD dan

bertanggung jawab sebagai

penengah antara user dan

super admin / admin Bina

Program

Pengguna Aplikasi

Pihak pengguna atau pihak

yang terlibat pada aplikasi

GRMS dalam lingkup

Pemerintah Kota Surabaya

Developer Aplikasi


jawab dalam pengembangan

aplikasi

Kepala Sub Bagian

(Kasubag)


jawab dalam pengambilan

keputusan pada tingkat

manajemen

Berdasarkan hasil wawancara, Bina Program memiliki 6 orang

pegawai yang menjabat sebagai admin. Rinciannya sebagai

berikut:

E-Budgeting: 3 admin

E-Project : 1 admin

E-Controlling: 1 admin

E-Delivery: 1 admin

E-Performance: 1 admin.

Aplikasi e-project dan e-controlling ditangani oleh pihak admin

yang sama.

Bina Program memiliki 10 orang tenaga kontrak sebagai

programmer untuk membantu Bina Program dalam menangani

bagian operasional dalam mengeksekusi perubahan kebutuhan

GRMS. Setiap aplikasi GRMS memiliki 2 programmer.

60

Dari penjelasan kondisi kekinian di atas, diketahui bahwa

terdapat penempatan jumlah admin yang tidak merata pada

beberapa aplikasi GRMS. Misalnya, Ibu Galuh Ayu

Jendrawatu, ST, adalah satu-satunya admin yang menangani

aplikasi e-project dan e-controlling sekaligus, sedangkan

aplikasi e-budgeting memiliki lebih dari satu admin. Padahal,

setiap aplikasi sebaiknya ditangani oleh minimal 1 admin yang

berbeda.

E. Produk

Bina Program memiliki produk dalam bentuk elektronik yaitu

e-trac. E-trac merupakan aplikasi pencatatan perubahan yang

masuk dan telah disetujui. Setiap aplikasi GRMS memiliki

manajemen e-trac yang berbeda-beda. Berikut penjelasannya

Table 5.3 Manajemen E-trac Tiap GRMS

Government Resource

Management Systems Aplikasi e-Trac

e-Budgeting

e-Project

e-Controlling

Aplikasi e-trac dipakai untuk

pencatatan daftar perubahan

yang telah disetujui oleh

admin/kasubag. Pencatatan

tersebut berisikan

pengkategorisasian

perubahan, prioritas

perubahan, deskripsi

perubahan, dan pihak yang

bertanggung jawab terhadap

perubahan. Jenis-jenis

pengkategorisasian tersebut

antara lain:

1. Defect: terkait

dengan kecacatan

software dan harus

segera dikerjakan

2. Enhancement:

penyempurnaan

61

Government Resource


software dan tidak

terlalu mendesak

3. Task: terkait dengan

penambahan fitur

atau proses dan

sebaiknya

dikerjakan

Adapun prioritas yang telah

dilakukan dalam aplikasi ini,

yaitu:

1. Blocker: software

tidak bisa beroperasi

apabila tidak ada

penanganan atau

pembenaran

2. Critical: software

masih dapat berjalan

dan tetap penting

untuk dikerjakan

apabila ada

kerusakan

3. Major: tidak

sepenting critical

tetapi masih dalam

kategori bahaya

4. Minor: bahaya

software tidak

terlalu signifikan

dan penanganannya

tidak terlalu terburu-

buru

5. Trivial: tidak ada

efeknya secara

langsung untuk

proses bisnisnya

62

Government Resource


e-Delivery

e-Performance

Aplikasi e-trac selalu

digunakan admin untuk

melakukan pengembangan

GRMS. Admin selalu

mencatat perubahan yang

telah disetujui oleh

admin/kasubag. Pencatatan

tersebut berisikan

kategorisasi perubahan,

prioritas perubahan status

pengerjaan perubahan,

deskripsi perubahan, pihak

siapa yang bertanggung

jawab terhadap perubahan.

Jenis-jenis

pengkategorisasian

perubahan antara lain:

1. Penambahan Fitur:

apabila request yang

masuk terkait

dengan permintaan

penambahan fitur

2. Pengecualian:

apabila request yang

masuk berkaitan

dengan

penyimpangan

terhadap alur proses

bisnis ataupun

kebijakan

3. Perbaikan: apabila

request yang masuk

berkaitan dengan

permasalahan

63

Government Resource


Adapun prioritas yang telah

dilakukan dalam aplikasi ini,

yaitu:

1. Rendah: dampak

dengan proses bisnis

tidak terlalu terlihat

dan waktu

pengerjaan juga bisa

kapan saja

2. Normal: bahaya

software tidak

terlalu signifikan

untuk proses bisnis,

software masih

dapat berjalan dan

penanganannya

tidak terlalu terburu-

buru

3. Tinggi: masih dalam

kategori bahaya,

layanan masih dapat

digunakan tetapi

tidak semua menu

dapat diakses,

dampak tidak begitu

terasa dan

penanganannya

tidak disegerakan

4. Penting: masuk

dalam kategori

bahaya, dampak

terasa secara

signifikan dan

merugikan banyak

pihak dan

64

Government Resource


penanganannya

termasuk sesegera

mungkin

5. Segera: dalam

kategori bahaya,

dampak sangat

terasa oleh semua

pengguna, proses

bisnis terhenti dan

penanganannya

sesegera mungkin

F. Permasalahan

Permasalahan yang muncul pada kondisi kekinian berdasarkan

hasil wawancara antara lain sebagai berikut:

Letak alur pencatatan permintaan perubahan

Kategorisasi dan prioritas jenis perubahan tidak dapat

dibedakan dengan baik oleh admin GRMS karena

setiap jenis permasalahan yang memerlukan perubahan

selalu dikategorisasikan sebagai perubahan besar dan

diprioritaskan mendesak untuk dikerjakan.

5.1.5 Kondisi Ideal Manajemen Perubahan Terhadap

Kebutuhan GRMS

Pada bagian ini akan membahas mengenai kondisi ideal

pengembangan aplikasi GRMS. Kondisi ideal didapatkan dari

hasil wawancara dengan para admin GRMS dan standar ITIL

V3.

Dalam melakukan analisis kondisi ekspektasi, berdasarkan

tahapan service design ITIL V3 terdapat 4 aspek penting dalam

mendesain sebuah layanan TI. Keempat aspek tersebut

merupakan aspek penting yang digunakan karena sesuai dengan

standar ITIL dalam melakukan persiapan dan perencanaan yang

efektif dan efisien. Keempat aspek tersebut antara lain adalah:

65

People: merupakan pihak yang terlibat dalam layanan

TI dan memiliki peran maupun tanggung jawab

masing-masing

Processes: merupakan aktivitas, kebijakan, prosedur

dan tindakan dari layanan TI

Product: merupakaan aspek aplikasi, infrastruktur,

sistem manajemen dan teknologi yang digunakan untuk

menyediakan layanan TI

Partners: merupakan Pihak pendukung yang terlibat

dalam penyediaan layanan TI seperti manufactures,

suppliers dan vendor.

Dalam penelitian ini, peneliti menggunakan dua dari empat

aspek yang ada yaitu people dan processes karena berdasarkan

standar terhadap kebutuhan suatu organisasi. Organisasi dapat

merasakan keuntungan dari penggunaan ITIL ketika terdapat

kesesuaian dan kejelasan terhadp proses dan pihak yang terkait

dengan proses. Sedangkan di dalam studi kasus yang berfokus

ada manajemen perubahan terhadap kebutuhan GRMS,

kesesuaian proses dan sumber daya menjadi hal yang penting.

Oleh karena itu, peneliti menggunakan kedua aspek yaitu

people dan processes dari empat aspek yang digunakan. Selain

itu aspek ini digunakan berdasarkan hasil wawancara terhadap

kondisi ekspektasi.

A. Aktivitas (Processes)

Berdasarkan standar acuan manajemen perubahan ITIL terdapat

tujuh aktivitas dalam melakukan manajemen perubahan

terhadap kebutuhan GRMS, yaitu: membuat dan merekam

permintaan perubahan, meninjau permintaan perubahan,

menilai dan mengevaluasi perubahan, autorisasi perubahan,

pembaharuan rencana, mengkoordinasikan implementasi, dan

mengevaluasi dan menutup perubahan

66

Table 5.4 Kondisi Ideal Manajemen Perubahan ITIL V3

Change Management

ITIL V3 Analisis Kondisi Ideal

Membuat dan

Merekam Permintaan

Perubahan

Menurut ITIL V3, pihak

yang bertanggung jawab

(pihak admin) harus

membuat request for change

(RFC). RFC merupakan

dokumen atau proposal resmi

untuk mengajukan sebuah

perubahan yang di dalamnya

mencakup detail perubahan

yang akan dibuat. Setiap

perubahan yang dilakukan

harus tercatat dalam sebuah

sebuah configuration

management system (CMS).

CMS menyediakan catatan

sejaah (log) perubahan-

perubahan yang pernah

dilakukan terhadap sebuah

sistem atau layanan TI.

Meninjau Permintaan

Perubahan

Menurut ITIL V3, diperlukan

adanya pemeriksaan RFC

apakah semua bagian

pengisian telah diisi dengan

benar, apakah tidak terrjadi

duplikasi permintaan

perubahan, dan apakah

permintaan tidak melampaui

cakupan proses manajemen

perubahan Menilai dan

Mengevaluasi

Perubahan


adanya penilaian dan

pengevaluasian perubahan

apakah usulan perubahan

tersebut dan pengambilan

67

Change Management


keputusan untuk menyetujui

atau tidak. Untuk melakukan

aktivitas ini, disarankan

menanyakan pertanyaan 7R,

yakni :

Raised : Siapa yang

mengangkat usulan

perubahan?

Reason : Apa alasan

perubahan?

Return : Apa keuntungan

bisnis yang diperoleh dari

perubahan?

Risk : Apa resiko jika

melakukan atau tidak

melakukan perubahan?

Resources : Apa saja

sumber daya yang

diperlukan untuk

perubahan?

Responsible : Siapa yang

bertanggung jawab

terhadap perubahan?

Relationship : Apa

hubungan perubahan ini

dengan perubahan lain?

Mengautorisasi

Perubahan

Menurut ITIL V3,

manajemen harus mengambil

keputusan siapa orang yang

diberikan autoritas

melakukan perubahan

Memperbaharui

Rencana


adanya pembaharuan

rencana untuk memastikan

perubahan yang perlu

68

Change Management


dilakukan. Dalam hal ini,

perubahan-perubahan berupa

kebutuhan aplikasi TI.

Mengkoordinasikan

Implementasi

Menurut ITIL V3, aktivitas

ini mencakup pelaporan ke

manajemen atas dan

komunikasi terhadap

stakeholder tentang

perubahan dan rencana

perubahan serta

mensosialisasikan terhadap

pengguna

Mengevaluasi dan

Menutup Proyek

Menurut ITIL V3, di akhir

proses semua perubahan

harus dievaluasi dalam hal

apakah perubahan telah

mencapai tujuan dan

keuntungan yang ingin

dicapai.

B. Kebijakan (Processes)

Kebijakan penggunaan aplikasi GRMS berdasarkan Peraturan

Walikota Surabaya Nomor 73 Tahun 2012. Selain itu sesuai

dengan hasil wawancara bahwa penggunaan ITIL V3 sebagai

acuan dalam pelaksaan e-government yang terstandarisasi.

Adanya penggunaan ITIL V3 akan meningkatkan nilai dari

penerapan tata kelola TI di lingkungan Pemerintah Kota

Surabaya.

C. Struktur Organisasi (People)

Bina Program merupakan sebuah bagian yang berada di bawah

Asisten Perekonomian dan Pembanguan Kota Surabaya yang

menangani perencanaan keuangan daerah Kota Surabaya.

69

Gambar 5.6 Struktur Organisasi Bina Program

Tupoksi dari masing-masing pegawai disesuaikan dengan

tupoksi yang telah diterbitkan oleh Perwali Kota Surabaya.

D. Sumber Daya Manusia (People)

Terdapat beberapa usulan peran pada pengguna dalam

manajemen user GRMS. Masing-masing pengguna memiliki

peran masing-masing sesuai dengan Table 5.5.

Table 5.5 Usulan Peran Tambahan

Tipe Pengguna Peran

Usulan

Tanggung

Jawab

Super

Admin/Admin Bina

Program

Sebagai orang

yang bertanggung

jawab terhadap

manajemen

pengelolaan

aplikasi

Mengontrol

siklus hidup

segala

perubahan,

memungkinkan

perubahan dapat

menjadi

keuntungan tanpa

Kepala Bagian Bina Program

Kepala Sub Bagian Penyusunan

Pelaksanaan Program

Admin

Developer

Kepala Sub Bagian Pembinaan dan Pengendalian

Admin

Developer

Kepala Sub Bagian Evaluasi dan Pelaporan

Admin

Developer

70

Tipe Pengguna Peran

Usulan

Tanggung

Jawab

menimbulkan

gangguan

terhadap layanan

lainnya, dan

memiliki

autorisasi

pembentukan

change advisory

board.

Admin SKPD

Sebagai orang

yang bertanggung

jawab terhadap

kendali

pengelolaan

aplikasi yang

sesuai dengan

masing-masing

SKPD

Pengguna Aplikasi

Sebagai pengguna

aplikasi GRMS

dalam lingkup

Pemerintah Kota

Surabaya

Developer Aplikasi

Sebagai orang

yang bertanggung

jawab dalam

pengembangan

aplikasi

Kepala Sub Bagian

Sebagai pihak

manajemen yang

bertanggung

jawab dalam

pengambilan

keputusan pada

Memonitoring

segala aktivitas

implementasi

perubahan

hingga tahap

71

Tipe Pengguna Peran

Usulan

Tanggung

Jawab

tingkat

manajemen

evaluasi dan

penutupan

E. Harapan

Harapan mendatang terkait manajemen perubahan terhadap

kebutuhan aplikasi GRMS yang disampaikan saat wawancara

oleh narasumber antara lain sebagaia berikut:

Penambahan tenaga kerja

Adanya SOP dalam manajemen perubahan untuk

pengembangan aplikasi

Penyamaan persepsi antara pihak admin dan kasubag

dengan pihak programmer sebagai bagian operasional

untuk mengeksekusi perubahan kebutuhan tersebut

5.2 Hambatan

Dalam melakukan wawancara dan observasi, penulis

mengalami beberapa hambatan yang dialami. Adapun beberapa

hambatan yang dialami oleh penulis, antara lain:

Keterbatasan waktu narasumber dalam wawancara

maupun obervasi sehingga dalam melakukan proses

penggalian kondsi kekinian manajemen perubahan

terhadap GRMS, penulis perlu mengalokasikan waktu

dan jadwal dengan narasumber terkait secara tepat

Terdapat perbedaan penjelasan informasi yang didapat

antara admin dengan programmer dan menyebabkan

penulis perlu melakukan validasi dengan pihak yang

terkait lainnya untuk memperoleh informasi yang lebih

jelas

72


73

BAB VI

HASIL DAN PEMBAHASAN Pada bab VI ini akan dijelaskan mengenai hasil dan penelitian

tugas akhir, yaitu keluaran dari setiap tahapan yang ada dalam

metode penelitian yang terdapat pada bab III.

6.1 Analisis Kesenjangan

Analisis kesenjangan dilakukan dengan cara mengidentifikasi

hasil analisis kondisi kekinian yang telah dilakukan terhadap

pengelolaan permintaan perubahan GRMS dan kemudian

membandingkannya dengan kondisi yang diharapkan dan

kondisi ideal pada standar acuan. Analisis ini dilakukan karena

masih terdapat aktivitas proses bisnis manajemen perubahan

yang masih belum diterapkan. Dari perbandingan tersebut dapat

dicari kesenjangan yang terjadi dalam proses permintaan

perubahan GRMS. Penemuan kesenjangan tersebut dapat

dilihat dari kelemahan atau kekurangan yang ada di kondisi saat

ini yang belum memenuhi kondisi ideal. Dari kesenjangan yang

ada akan didefinisikan usulan-usulan yang nantinya akan

digunakan sebagai input untuk membuat dokumen Standard

Operating Procedure (SOP) manajemen perubahan GRMS.

Berikut hasil analisis kesenjangan dapat dilihat pada Table 6.1

.

74

Table 6.1 Analisis Kesenjangan

Aspek Aktivitas Kondisi Kekinian Kondisi Ideal Kesenjangan

Proses Perubahan

Proses Create and

Record RFC

Pengguna

melakukan

permintaan

perubahan

terhadap pihak

admin. Apabila

perubahan

berpengaruh

signifikan / besar

terhadap aplikasi

GRMS, maka

pencatatan

permintaan

perubahan

dilakukan oleh

pihak admin ke

dalam aplikasi

pencatatan TRAC

Pencatatan

dilakukan oleh

pengguna pada

tahap awal ketika

pengguna

mengajukan

permintaan

perubahan.

Pencatatan

dilakukan di

dokumen request

for change yang

memuat detail

perubahan dan

diserahkan kepada

admin

Pencatatan

dilakukan pada

tahap awal

ketika

pengguna

mengajukan

permintaan

perubahan

1. Terdapat

perbedaan alur letak

aktivitas pencatatan

permintaan

perubahan yang

dilakukan

2. Pencatatan

dilakukan oleh

pengusul perubahan

pada formulir RFC

75


Proses Perubahan

setelah adanya

persetujuan dari

pihak kasubag

melalui sebuah

rapat. Apabila

perubahan tidak

terlalu

berpengaruh besar

terhadap sistem,

maka pihak admin

akan langsung

melakukan

pencatatan

permintaan

perubahan ke

dalam aplikasi

pencatatan TRAC.

Review the

RFC

Pemeriksaan

mengenai apakah

Pemeriksaan

dokumen

Pemeriksaan

lebih berfokus

1. Adanya

pemeriksaan RFC

76


Proses Perubahan

permintaan

perubahan dari

pengguna tidak

melampaui

cakupan proses

bisnis

pencatatan

permintaan

perubahan apakah

pengisian telah

valid dan tidak

melampaui

cakupan proses

bisnis

ke arah isi

RFC yang

diajukan oleh

pengusul

perubahan,

berupa

ketepatan

pengisian

dengan log

perubahan yang

pernah diusulkan

sebelumnya

2. Admin wajib

mengisikan formulir

log yang berisi RFC

yang pernah

diajukan

Assess and

Evaluate The

Change

Admin membuat

rapat yang

menghadirkan

admin, kasubag,

dan programmer

(bila diperlukan)

untuk

mengevaluasi

apakah perubahan

perlu dilakukan

Menurut ITIL V3,

terdapat 3

pembagian

kategori perubahan

: standard change,

normal change,

dan emergency

change. Apabila

perubahan

terkategori

Jenis-jenis

perubahan

memiliki

prosedur

penilaian dan

pengevaluasian

yang berbeda

1. Diperlukan

rincian alur dalam

penilaian dan

pengevaluasian

perubahan sesuai

ITIL V3

2. Pengusul

perubahan/pengguna

wajib mengikuti

forum CAB

77


Proses Perubahan

dan bagaimana

perubahan

dilakukan

standard change,

maka tidak ada

aktivitas ini.

Apabila perubahan

terkategori normal

change, maka

admin wajib

membentuk change

advisory board

yang wajib

menghadirkan

pengguna, admin,

kasubag,

programmer, dan

kabag. Apabila

perubahan

terkategori

emergency change,

maka admin wajib

3. Admin akan

melengkapi formulir

RFC apabila

perubahan disetujui

atau ditolak disertai

alasan

78


Proses Perubahan

membentuk

emergency change

advisory board.

Pihak yang dapat

menghadiri tetap

sama dengan CAB,

hanya tidak seluruh

pihak wajib

menghadirinya.

Aktivitas penilaian

terhadap usulan

perubahan

dilakukan dengan

menanyakan

pertanyaan 7R.

Authorize The

Change

Autorisasi

diberikan oleh

admin sendiri pada

Autorisasi

diberikan kepada

kasubag apabila

perubahan

Autorisasi

perubahan

dilakukan oleh

pihak yang

1. Adanya hierarki

khusus untuk

autorisasi perubahan

79


Proses Perubahan

saat pencatatan

perubahan.

terkategori

standard change.

Apabila perubahan

terkategori lainnya,

maka autorisasi

diberikan melalui

forum CAB/ECAB

dengan

menggunakan

hierarki autorisasi

perubahan

berbeda dan

tempat yang

berbeda

80

6.2 Identifikasi Dampak dan Solusi

Berdasarkan hasil analisis kesenjangan, dapat dilakukan

identifikasi dampak yang diakibatkan dari hasil identifikasi

perubahan pada analisis kesenjangan. Identifikasi dampak

diperlukan untuk mengetahui akibat dari perpindahan kondisi

saat ini ke kondisi ekspektasi atau kondisi ideal berdasarkan

standar acuan. Selanjutnya akan diidentifikasi solusi dari

dampak perubahan yang terjadi pada Table 6.2, sehingga akan

didapatkan manfaat dari perubahan yang terjadi.

81

Table 6.2 Identifikasi Dampak dan Solusi

Aspek Aktivitas Dampak atas Proses Solusi

Create and

Record RFC

Adanya pendetailan mengenai usulan

perubahan yang harus diajukan oleh

pengguna

Pembuatan formulir RFC yang

berisi detail permintaan

perubahan dari pengusul

Review RFC

Adanya pemeriksaan terhadap

dokumen RFC terkait pengisian dan

cakupan permintaan perubahan

Pembuatan usulan peran

tambahan terhadap admin untuk

meninjau dokumen RFC

Asses and

Evaluate the

Change

Adanya pembentukan change

advisory board untuk penanganan

perubahan normal change yang wajib

mengundang berbagai pihak, seperti

pengguna, manajer, dewan direksi,

kontraktor, developer atau emergency

change advisory board untuk

penanganan perubahan emergency

change yang berisi anggota khusus

Adanya pembentukan jadwal

khusus setelah perubahan telah

siap untuk dirapatkan

berdasarkan kategori perubahan

82

Aspek Aktivitas Dampak atas Proses Solusi

Authorize the

Change

Adanya pembagian autorisasi

perubahan untuk implementasi

perubahan

Pembentukan hierarki autorisasi

perubahan berdasarkan risiko

implementasi perubahan

83

6.3 Perancangan Dokumen SOP

Pembuatan Standard Operating Procedure disusun

berdasarkan hasil analisis kesenjangan yang telah dilakukan.

Pembuatan SOP mengacu pada Peraturan Menteri

Pendayagunaan Aparatur Negara dan Reformasi Birokrasi

Republik Indonesia Nomor 35 Tahun 2012 Tentang Pedoman

Penyusunan Standar Operasional Prosedur Administrasi

Pemerintahan dan Peraturan Walikota Surabaya Nomor 73

tahun 2012. Adapun dalam penyusunan format SOP didasarkan

pada tujuan dari pembuatan SOP dan tidak terdapat format baku

dalam penyusunan format SOP. Apabila terdapat perbedaan

tujuan pembuatan SOP, maka format SOP juga akan berbeda.

6.3.1 Deskripsi Usulan SOP

SOP yang dihasilkan untuk melakukan manajemen perubahan

terhadap aplikasi GRMS adalah sebagai berikut :

SOP manajemen perubahan TI

Prosedur yang memaparkan aktivitas untuk melakukan

pencatatan permintaan perubahan dalam dokumen

secara benar dan tepat berdasarkan ITIL V3.

SOP penanganan standard change

Prosedur yang memaparkan aktivitas untuk

penanganan permintaan perubahan yang terkategorisasi

standard change

SOP penanganan normal change



normal change

SOP penanganan emergency change



emergency change

84

Berikut merupakan penjelasan dari masing-masing prosedur

pada Table 6.3.

Table 6.3 Deskripsi Usulan SOP

Usulan SOP Aktivitas

Manajemen

Perubahan TI

Prosedur ini dibuat dengan tujuan untuk

untuk mengelola aktivitas dalam

memastikan apakah perubahan-

perubahan TI telah tercatat, terevaluasi,

terautorisasi, dan terimplementasi ke

lingkungan kerja yang sebenarnya

dengan penuh kontrol. Prosedur

manajemen perubahan memungkinkan

penyedia layanan merealisasikan

manfaat-manfaat dari sebuah perubahan

dengan seminimal mungkin

menginterupsi layanan TI yang telah ada

dan sedang berjalan.

Penanganan

standard

change


menangani perubahan-perubahan yang

secara default sudah disetujui untuk

dapat dilakukan. Perubahan-perubahan

yang dimaksud merupakan perubahan

yang terkategori standard change.

Penanganan

normal change



terkategori normal change. Prosedur ini

mencakup aktivitas penilaian dan

pengevaluasian perubahan serta

pemberian autorisasi perubahan apabila

perubahan disetujui.

Penanganan

emergency

change



terkategori emergency change. Prosedur

ini mencakup aktivitas penilaian dan

pengevaluasian perubahan serta

85

Usulan SOP Aktivitas

pemberian autorisasi perubahan apabila

perubahan disetujui

Selain SOP, peneliti juga mengusulkan beberapa formulir yang

dapa melengkapi beberapa SOP. Formulir yang diusulkan

antara lain :

Table 6.4 Usulan Formulir

6.3.2 Struktur dan Konten SOP

Dalam menentukan struktur dan konten SOP, penulis mengacu

kepada Peraturan Menteri Pendayagunaan Aparatur Negara dan

Reformasi Birokrasi Republik Indonesia Nomor 35 Tahun 2012

Tentang Pedoman Penyusunan Standar Operasional Prosedur

Administrasi Pemerintahan. Namun tidak semua struktur dan

konten yang ada dalam acuan digunakan dalam penelitian tugas

akhir ini karena disesuaikan dengan kebutuhan penelitian.

Berikut adalah struktur dan konten SOP dalam kerangka

dokumen SOP manajemen perubahan terhadap aplikasi GRMS

pada Table 6.5

Nomor

SOP Nama SOP

Nomor

Formulir

Nama

Formulir

SOP-

Perubahan-

001

SOP

Manajemen

Perubahan TI

1. FRM-

Perubahan-

001

Formulir

RFC

SOP-

Perubahan-

003

SOP

Penanganan

Normal

Change

1. FRM-

Perubahan-

001

Formulir

RFC

SOP-

Perubahan-

004

SOP

Penanganan

emergency

change

1. FRM-

Perubahan-

001

Formulir

RFC

86

Table 6. 5 Struktur dan Konten SOP

RUANG LINGKUP SUB BAB

PENDAHULUAN

Latar Belakang

Tujuan

Ruang Lingkup

Ruang Lingkup Konten SOP

Struktur Organisasi

SOP Manajemen Perubahan TI

Definisi

Tujuan Utama

SOP Manajemen Perubahan TI

Alur Tahapan Prosedur

Indikator Pengukuran Kinerja

SOP Penanganan Standard Change

Definisi

Tujuan Utama

SOP penanganan standard

change


SOP Penanganan Normal Change

Definisi

Tujuan Utama

SOP penanganan normal change


SOP Penanganan Emergency Change

Definisi

Tujuan Utama

SOP penanganan emergency

change


Formulir Formulir RFC (FRM-Perubahan-

001)

87

6.4 Hasil Pembuatan Dokumen SOP

Pada bagian ini akan dipaparkan penjelasan mengenai setiap

prosedur yang tertera dalam SOP manajemen perubahan

terhadap kebutuhan GRMS. Dalam melakukan penyusunan

SOP manajemen perubahan terhadap kebutuhan GRMS,

penulis menggunakan panduan SOP menurut Peraturan Menteri

Pendayagunaan Aparatur Negara dan Reformasi Birokrasi

Republik Indonesia Nomor 35 Tahun 2012 Tentang Pedoman

Penyusunan Standar Operasional Prosedur Administrasi

Pemerintahan. Di dalam SOP, model prosedur akan dijabarkan

dalam bentuk flowchart karena terdapat banyak aktivitas dan

keputusan yang terkait. Hasil keseluruhan dokumen SOP akan

dilampirkan pada buku produk SOP manajemen perubahan

terhadap kebutuhan. Berikut adalah pemaparan masing-masing

prosedur :

6.4.1 Prosedur Manajemen Perubahan TI

Prosedur manajemen perubahan TI merupakan panduan yang

digunakan oleh Bina Program untuk mengelola proses

pengembangan terhadap kebutuhan aplikasi GRMS secara

berurutan. Harapan dari penerapan SOP ini adalah mampu

menyelesaikan permasalahan secara efektif dan efisien dalam

pengelolaan pengembangan terhadap kebutuhan aplikasi

GRMS.

6.4.1.1 Definisi

A. Manajemen Perubahan TI

Manajemen perubahan TI yang diuraikan dalam standar ITIL

V3 adalah proses mengontrol siklus hidup semua perubahan-

perubahan dalam layanan TI dan memastikan perubahan benar-

benar memberi keuntungan bagi bisnis organisasi. Perubahan

dalam manajemen layanan TI mencakup :

Penambahan (add)

Modifikasi (modify)

88

Penghilangan (remove)

Contoh-contoh perubahan TI antara lain perubahan arsitektur,

proses, tool, indikator pengukuran, dokumentasi, layanan TI,

sistem TI, infrastruktur TI, hingga perubahan setting-up sebuah

sistem TI.

B. Kategori Perubahan

Tabel berikut memaparkan kategori perubahan layanan TI

berdasarkan standar ITIL V3

Table 6. 6 Kategori Perubahan Menurut ITIL V3

KATEGORI DESKPRISI CONTOH

STANDARD

CHANGE

Merupakan

tindakan-tindakan

perubahan yang

dapat terjadi dalam

aktivitas bisnis

sehari-hari dan

berisiko rendah,

sehingga untuk

melakukannya

hanya tinggal

mengikuti prosedur

yang telah

ditetapkan

sebelumnya atau

petunjuk

operasional

Mengganti

password

Penambahan

laporan

dalam

aplikasi

Penambahan

fitur

verifikasi

pengguna

dalam

aplikasi

Penambahan

fitur validasi

dalam

aplikasi

Perubahan

tata letak fitur

dalam

aplikasi

EMERGENCY

CHANGE

Merupakan

perubahan yang

harus

Perubahan

sistem untuk

mengatasi

89

KATEGORI DESKPRISI CONTOH

diimplementasikan

segera mungkin

karena memiliki

pengaruh besar ke

bisnis, yang

umumnya diinisiasi

oleh sebuah acciden

accident

besar seperti

server crash

Implementasi

sistem

keamanan

NORMAL

CHANGE

Merupakan

perubahan-

perubahan yang

tidak termasuk

standard change

atau emergency

change

Penambahan

fitur baru

dalam

aplikasi

Penambahan

alur proses

bisnis dalam

aplikasi

Perubahan

data dalam

aplikasi

Pemberian

hak akses

dalam

aplikasi

Pengaturan

bobot kerja

dalam

aplikasi

Perubahan

status data

pegawai

90

C. Request For Change

RFC merupakan sebuah dokumen/proposal resmi untuk

mengajukan sebuah perubahan, dimana di dalamnya mencakup

detail perubahan yang akan dibuat, dampak dan keterangan

klasifikasi perubahan yang diusulkan. RFC dapat berupa

dokumen fisik/kertas atau elektronis.

6.4.1.2 Tujuan Utama

Tujuan utama dari prosedur manajemen perubahan TI adalah

untuk mengelola aktivitas dalam memastikan apakah

perubahan-perubahan TI telah tercatat, terevaluasi,

terautorisasi, dan terimplementasi ke lingkungan kerja yang

sebenarnya dengan penuh kontrol. Prosedur manajemen

perubahan memungkinkan penyedia layanan merealisasikan

manfaat-manfaat dari sebuah perubahan dengan seminimal

mungkin menginterupsi layanan TI yang telah ada dan sedang

berjalan.

91

6.4.1.3 Deskripsi dan Informasi SOP

Gambar 6. 1 SOP-Perubahan-001

92

6.4.1.4 Alur Prosedur

93

94

Gambar 6. 2 Alur Prosedur SOP-Perubahan-001

95

6.4.2 Prosedur Penanganan Standard Change

Prosedur standard change merupakan panduan yang digunakan

oleh Bina Program untuk menangani perubahan-perubahan

yang secara default sudah disetujui untuk dapat dilakukan.

Harapan dari penerapan SOP ini adalah agar dapat memberikan

arahan yang terurut mengenai penanganan perubahan yang

terkategori standard change.

6.4.2.1 Definisi

A. Standard Change

Perubahan yang terkategori standard change biasanya

merupakan perubahan yang biasa terjadi dalam aktivitas bisnis

sehari-hari dan dapat terjadi berulang dan berkali-kali.

Perubahan ini juga tidak kompleks dan berisiko rendah

sehingga untuk melakukannya hanya tinggal mengikuti

prosedur atau petunjuk operasional yang telah ditetapkan

sebelumnya, yakni disebut change model.

B. Change Model

Change model merupakan urutan langkah-langkah standar yang

sudah ditetapkan dan disetujui sebelumnya untuk menjalankan

perubahan tertentu dengan kategori standard change. Standard

change yang terjadi pada Bina Program meliputi penambahan

laporan dalam aplikasi, penambahan fitur baru dalam aplikasi,

dan perubahan tata letak fitur dalam aplikasi.

Isi change model dapat berupa langkah-langkah standar untuk

mengatasi permasalahan terkait perubahan, siapa yang

berwenang dan tanggung jawabnya, durasi waktu standar

pengerjaan, dan prosedur esklasi permasalahan yang tidak

mampu diselesaikan.


Tujuan utama dari proses penanganan standard change adalah

untuk mengetahui prosedur yang perlu dilakukan dalam

menangani perubahan yang terkategori standard change.

96



97



98

6.4.3 Prosedur Penanganan Normal Change

Prosedur penanganan normal change merupakan panduan yang

digunakan oleh Bina program dalam menilai dan mengevaluasi

seluruh perubahan yang terkategori normal change. Harapan

dari penerapan SOP ini adalah agar dapat membantu Bina

Program dalam memberikan persetujuan terhadap pengusulan

perubahan yang terkategori normal change.

6.4.3.1 Definisi

A. Change Advisory Board

Perubahan yang terkategori normal change merupakan

perubahan yang umumnya memerlukan jangka waktu panjang

dalam penanganannya dan tidak bersifat mendesak. Perubahan

ini berpengaruh besar dan tidak terjadi pada sehari-hari.

Perubahan ini mencakup penambahan fitur baru dalam aplikasi,

penambahan alur proses bisnis dalam aplikasi, perubahan data

dalam aplikasi, pemberian hak akses dalam aplikasi, pengaturan

bobot kerja dalam aplikasi, dan perubahan status data pegawai.

B. Change Advisory Board

Change Advisory Board (CAB) adalah sebuah forum

membantu memberikan dukungan kepada pihak-pihak

berkepentingan yang terlibat dalam membantu penilaian

perubahan dan menyetujui atau menolak permintaan perubahan

tersebut. Tujuan utama CAB adalah menyetujui/tidak sebuah

perubahan atau memutuskan sebuah perubahan

diteruskan/tidak. CAB direncanakan untuk perubahan yang

terkategori normal change. Pihak-pihak yang dapat terlibat

dalam CAB antara lain :

Pengguna

Change Manager (admin)

Teknisi/ Programmer

Kepala Sub Bagian Bina Program


C. Menilai dan Mengevaluasi Perubahan

99

Berdasarkan standar ITIL V3, untuk menilai dan mengevaluasi

sebuah RFC disarankan menggunakan pertanyaan 7R yakni :

Table 6. 7 Pertanyaan 7R

Pertanyaan Isi Pertanyaan

Raised Siapa yang mengangkat

permintaan perubahan ini?

Reason Apa alasan perubahan?

Return Apa keuntungan bisnis yang

diperoleh dari perubahan?

Risk Apa risiko jika melakukan atau

tidak melakukan perubahan?

Resources Sumber daya apa saja yang

dibutuhkan untuk perubahan ini?

Responsible Siapa yang akan bertanggung

jawab terhadap perubahan?

Relationship Apa hubungan perubahan ini


D. Autorisasi Perubahan

Manajemen perlu mengambil keputusan siapa orang yang

diberikan autoritas melakukan perubahan (change autority).

Tingkat autoritas untuk pelaksanaan perubahan dapat berupa

peran atau kedudukan seseorang. Tingkat pembagian autoritas

untuk perubahan jenis tertentu juga harus diputuskan

berdasarkan jenis, ukuran, risiko, dan dampak bisnis potensial

dari perubahan.

E. Hierarki Autorisasi Perubahan

Tingkat dalam penentuan autorisasi perubahan akan dibagikan

berdasarkan risiko bisnis dan lingkup perubahan. Berikut

adalah pembagian tingkat untuk pihak autorisasi perubahan :

Table 6. 8 Hierarki Autorisasi Perubahan

Tingkat Pihak yang Bertanggung

Jawab

Deskripsi Perubahan

100

Level 1 Kepala Bagian Bina

Program

Perubahan yang

berisiko besar atau

membutuhkan biaya

besar, dimana

membutuhkan

keputusan dari para

eksekutif

Level 2 Kepala Sub Bagian Bina

Program

Perubahan yang

berdampak terhadap

berbagai layanan

atau divisi organisasi

Level 3 CAB / ECAB Perubahan yang

berpengaruh kecil

terhadap lokal

Level 4 Change Manager Perubahan yang

berisiko rendah


Tujuan utama dari proses penanganan normal change adalah

menilai dan mengevaluasi apakah permintaan perubahan (yang

diusulkan dalam RFC) dan mengambil keputusan apakah

menyetujuinya atau tidak.

101



102


103


104

6.4.4 Prosedur Penanganan Emergency Change

Prosedur penanganan emergency change merupakan panduan

yang digunakan oleh Bina program dalam menilai dan

mengevaluasi seluruh perubahan yang terkategori emergency

change. Harapan dari penerapan SOP ini adalah agar dapat

membantu Bina Program dalam memberikan persetujuan

terhadap pengusulan perubahan yang terkategori emergency

change.

6.4.3.1 Definisi

A. Emergency Change

Perubahan yang terkategori emergency change merupakan

perubahan yang ditangani sesegera mungkin. Meskipun

perubahan ini bersifat mendesak, proses penanganan

emergency change yang perlu dilakukan tetaplah ada. Proses

penanganannya mirip dengan normal change. Perubahan ini

mencakup perubahan sistem untuk mengatasi accident besar

seperti server crash, implementasi sistem keamanan, dan

perubahan-perubahan lainnya yang terdapat dalam kategori

normal change, tetapi bersifat sangat mendesak.

B. Emergency Change Advisory Board

Emergency Change Advisory Board (ECAB) adalah sebuah

forum membantu memberikan dukungan kepada pihak-pihak

berkepentingan yang terlibat dalam membantu penilaian

perubahan dan menyetujui atau menolak permintaan perubahan

tersebut. Tujuan utama ECAB adalah menyetujui/tidak sebuah

perubahan atau memutuskan sebuah perubahan

diteruskan/tidak. ECAB direncanakan untuk perubahan yang

terkategori emergency change. Pihak-pihak yang dapat terlibat

dalam ECAB antara lain :

Pengguna


Teknisi/Programmer

Kepala Sub Bagian Bina program


105

Pihak-pihak yang wajib terlibat dalam ECAB meskipun

perubahan bersifat mendesak antara lain :

Pengguna


Teknisi/Programmer

C. Menilai dan Mengevaluasi Perubahan

Berdasarkan standar ITIL V3, untuk menilai dan mengevaluasi

sebuah RFC disarankan menggunakan pertanyaan 7R yakni :

Table 6. 9 Pertanyaan 7R

Pertanyaan Isi Pertanyaan

Raised Siapa yang mengangkat

permintaan perubahan ini?

Reason Apa alasan perubahan?

Return Apa keuntungan bisnis yang

diperoleh dari perubahan?

Risk Apa risiko jika melakukan atau

tidak melakukan perubahan?

Resources Sumber daya apa saja yang

dibutuhkan untuk perubahan ini?

Responsible Siapa yang akan bertanggung

jawab terhadap perubahan?

Relationship Apa hubungan perubahan ini


D. Autorisasi Perubahan

Manajemen perlu mengambil keputusan siapa orang yang

diberikan autoritas melakukan perubahan (change autority).

Tingkat autoritas untuk pelaksanaan perubahan dapat berupa

peran atau kedudukan seseorang. Tingkat pembagian autoritas

untuk perubahan jenis tertentu juga harus diputuskan

berdasarkan jenis, ukuran, risiko, dan dampak bisnis potensial

dari perubahan.

106

E. Hierarki Autorisasi Perubahan

Tingkat dalam penentuan autorisasi perubahan akan dibagikan

berdasarkan risiko bisnis dan lingkup perubahan. Berikut

adalah pembagian tingkat untuk pihak autorisasi perubahan :

Table 6. 10 Hierarki Autorisasi Perubahan

Tingkat Pihak yang Bertanggung

Jawab

Deskripsi Perubahan

Level 1 Kepala Bagian Bina

Program

Perubahan yang

berisiko besar atau

membutuhkan biaya

besar, dimana

membutuhkan

keputusan dari para

eksekutif

Level 2 Kepala Sub Bagian Bina

Program

Perubahan yang

berdampak terhadap

berbagai layanan

atau divisi organisasi

Level 3 CAB / ECAB Perubahan yang

berpengaruh kecil

terhadap lokal

Level 4 Change Manager Perubahan yang

berisiko rendah


Tujuan utama dari proses penanganan emergency change

adalah menilai dan mengevaluasi apakah permintaan perubahan

(yang diusulkan dalam RFC) dan mengambil keputusan apakah

menyetujuinya atau tidak. Permintaan perubahan yang dinilai

dan dievaluasi adalah perubahan yang terkategori emergency

change.

107



108


109

110


111

6.4.5 Formulir

Dalam dokumen SOP, terdapat satu formulir yang digunakan,

yaitu Formulir RFC (FRM-Perubahan-001)

Formulir ini digunakan oleh change manager untuk melengkapi

pada pengisian bagian kolom persetujuan/penolakan terhadap

usulan RFC setelah selesai diputuskan hasil

persetujuan/penolakan.

112

Gambar 6. 9 Formulir RFC

6.5 Verifikasi SOP Kegiatan verifikasi SOP dilakukan untuk mengetahui ketepatan

dan kesesuaian aktivitas maupun struktur dan konten formulir

yang ada di dalam dokumen SOP. Penulis melakukan verifikasi

SOP dengan melakukan wawancara kepada Admin/Super

Admin Bina Program dan Kepala Sub Bagian Pembinaan dan

Pengendalian Bagian Bina Program. Hasil wawancara tersebut

memberikan informasi terkait isi dari dokumen SOP yang perlu

diubah atau diperbaiki. Hasil verifikasi SOP secara lengkap

dilampirkan pada LAMPIRAN D.

6.6 Validasi SOP Kegiatan validasi SOP dilakukan untuk mengetahui apakah

SOP dapat berjalan sesuai kondisi yang ada dan untuk

menemukan kekurangan dari SOP yang telah dibuat untuk

dapat dibenahi. Dalam melakukan validasi SOP, peneliti

melakukan metode simulasi yang berdasarkan skenario yang

telah dibuat. Simulasi dilakukan oleh admin sebagai change

113

manager dan kasubag sebagai change ownerHasil dari validasi

memberikan informasi bahwa alur prosedur yang berkaitan

dengan pengisian formulir dapat disimulasikan tanpa ada

masalah. Hasil validasi SOP secara lengkap dilampirkan pada

LAMPIRAN E.

114

(halaman sengaja dikosongkan)

115

BAB VII

KESIMPULAN DAN SARAN Berdasarkan hasil analisis yang telah dilakukan dan

perancangan dokumen produk akhir dari pengerjaan tugas akhir

ini, terdapat kesimpulan dan saran terkait hasil tersebut, yakni

sebagai berikut:

7.1. Kesimpulan Kesimpulan yang dibuat adalah jawaban dari perumusan

masalah yang telah disusun dan berdasarkan hasil penelitian

yang telah dilakukan. Kesimpulan yang didapat dari penelitian

ini antara lain :

1. Kesenjangan yang terjadi antara kondisi kekinian

pengembangan aplikasi GRMS dengan kondisi ideal

menurut manajemen perubahan ITIL V3

Berdasarkan analisis kesenjangan yang telah dilakukan antara

kondisi kekinian pengembangan aplikasi GRMS dengan

kondisi ideal menurut manajemen perubahan ITIL V3,

didapatkan bahwa terdapat beberapa aktivitas yang belum

dikerjakan sesuai standar yaitu peninjauan permintaan

perubahan, penilaian dan pengevaluasian perubahan, dan

terdapat peletakkan aktivitas yang berbeda seperti pencatatan

permintaan perubahan. Selain itu, pengkategorian permintaan

perubahan juga tidak dilakukan secara maksimal oleh admin

karena seluruh usulan perubahan dikategorisasikan sebagai

perubahan yang penting untuk dikerjakan dan menyebabkan

para teknisi atau programmer tidak mampu membedakan

usulan perubahan mana yang paling prioritas untuk dikerjakan.

2. Hasil pembuatan dokumen SOP manajemen perubahan


Berdasarkan hasil analisis kesenjangan, didapatkan empat

usulan prosedur berdasarkan ITIL V3 yaitu :

Prosedur manajemen perubahan TI

Prosedur penanganan standard change Prosedur penanganan normal change

Prosedur penanganan emergency change

116

Usulan prosedur manajemen perubahan TI merupakan alur

proses bisnis manajamen perubahan TI pada Bina Program

secara keseluruhan, dimana di dalam prosedur tersebut akan

mencakup tiga prosedur penanganan yang berbeda-beda

berdasarkan pada kategori perubahan yang diusulkan, yaitu

prosedur penanganan standard change, normal change, dan

emergency change.

Di dalam prosedur tertentu terdapat formulir yang mendukung

pelaksanaan prosedur. Keseluruhan isi dokumen SOP

dibukukan secara terpisah dari buku tugas akhir dan berjudul

Dokumen Standard Operating Procedure Manajemen

Perubahan Terhadap Kebutuhan Aplikasi Government

Resource Management Systems (GRMS) Bagian Bina Program

Pemerintah Kota Surabaya.

3. Hasil verifikasi dan validasi SOP manajemen perubahan


Verifikasi SOP dilakukan dengan mewawancarai Kepala Sub

Bagian (Kasubag) Pembinaan dan Pengendalian bagian Bina

Program terkait isi dokumen SOP. Sedangkan validasi SOP

dilakukan dengan menerapkan sebuah simulasi berdasarkan

sebuah skenario yang telah dibuat. Simulasi dilakukan di Bina

Program yang melibatkan admin e-project dan e-controlling,

dan kepala sub bagian pembinaan dan pengendalian bagian

Bina Program,. Hasil verifikasi dan validasi SOP adalah

perbaikan isi dokumen SOP terkait proses dan aktivitas yang

masih perlu ditambahkan atau dikurangi dan persetujuan

pemilihan tanggung jawab setiap peran yang diusulkan serta

alokasi waktu yang perlu diberikan untuk setiap aktivitas.

7.2. Saran

Saran yang dapat disampaikan oleh peneliti terkait dengan

penelitian tugas akhir ini antara lain :

Penelitian ini terbatas pada perancangan dan pembuatan

dokumen SOP serta pengujian dokumen SOP tanpa adanya

aktivitas pemantauan terhadap pengimplementasian SOP

dan pengaruh pengimplementasian SOP tersebut pada

lingkungan kerja sehingga dapat digunakan untuk

117

penelitian selanjutnya dalam melakukan evaluasi

penerapan dokumen SOP terhadap proses manajemen

perubahan terhadap kebutuhan aplikasi GRMS.

118


119

DAFTAR PUSTAKA

[1] “GRMS(Government Resources Management System)

Sistem Informasi Manajemen Sumber Daya

Pemerintahan-Surabaya,” 29 December 2014. [Online].

Available: http://www.yipd.or.id/en/public-

administration-and-management/grms-government-

resources-management-system-sistem-informasi-

manajemen-sumber-daya-pemerintahan-sura. [Diakses

28 January 2016].

[2] B. Program, Profil Bagian Bina Program, Surabaya.

[3] T. Gunarni dan A. F. Rizky, “PENILAIAN DAN

MITIGASI RISIKO APLIKASI E-BUDGETING, E-

PROJECT, E-CONTROLLING DAN E-DELIVERY

PADA BAGIAN BINA PROGRAM PEMERINTAH

KOTA SURABAYA MENGGUNAKAN

FRAMEWORK OCTAVE DAN FMEA,” Surabaya,

Jurusan Sistem Informasi, 2015, pp. 43-47.

[4] T. D. Susanto, dalam Manajemen Layanan Teknologi

Informasi, 2016, pp. 90-111.

[5] ITIL V3 2011 Service Transition ST, TSO, 2011.

120

[6] D. Galin, “Software Quality Assurance from Theory to

Implementation,” England, Pearson Education Limited,

2004.

[7] “Teknik Analisis Masalah: Gap Analysis dan SWOT

Analyis,” January 2015. [Online]. Available:

http://pena.gunadarma.ac.id/teknik-analisis-masalah-

gap-analysis-dan-swot-analysis/.

[8] “Gap Analysis,” 2015. [Online]. Available:

http://www.id.lrqa.com/what-we-do/gap-analysis/.

[9] J. Mineraud, O. Mazhelis, X. Su dan S. Tarkoma, “A

Gap Analysis of Internet-of-Things Platforms,”

Computer Communications, Vol. %1 dari %289-90, pp.

5-16, 2016.

[10] T. 9. Store, “Process vs. Procedure vs. Work

Instruction,” [Online]. Available:

http://the9000store.com/iso-9000-tips-process-

procedure-work-instruction.aspx. [Diakses 16 Januari

2016].

[11] Y. R. K, Case Study Research: Design and Methods,

Beverly Hills: Sage Publications, 1984.

[12] “Kriteria SOP yang Baik,” [Online]. Available:

https://drive.google.com/file/d/0Bzw6_qVmUk8_TERo

c FlMYWwtT3c/view. [Diakses 16 Januari 2016].

[13] B. T. Kota, “Standard Operating Procedure (SOP),”

Peraturan Menteri, vol. I, no. 44, pp. 7-12, 2008.

121

[14] P. Menteri, “Pedoman Penyusunan Standar Operasional

Prosedur Administrasi Pemerintah,” 2012. [Online].

Available:

http://www.kopertis3.or.id/html/wpcontent/uploads/201

1/04/permenpan2012_035.pdf. [Diakses 16 Januari

2016].

[15] C. Schell, The Value of The Case Study as a Research

Strategy, Manch. Bus. Sch., Jan. 1992.

[16] R. Thayer dan M. Dorfman, Software Requirements

Engineering, IEEE, 1997.

[17] P. Zave, “Classification of Research Efforts in

Requirements Engieering,” ACM Computing (CSUR),

vol. 29, no. 4, pp. 315-321, 1997.

[18] Y.R.K, Case Study Reasearch: Design and Methods,

Beverly Hills: Sage Publications, 1984.

122


124


-A-1

A LAMPIRAN A – Interview Protocol

INTERVIEW PROTOCOL 1

Tujuan Interview : Untuk mendapatkan informasi

terkait pendefinisian aktor dan

peran yang terlibat dalam



Tanggal :

Waktu :

Lokasi :

Narasumber :

Jabatan :

Topik : Pendifinisian aktor dan role



Notes:

Perkenalkan diri

Mengucapkan terima kasih atas kesempatannya

Menjelaskan durasi interview

Sasaran:

o Detail aktor dan role yang terlibat dalam

manajemen perubahan terhadap kebutuhan

aplikasi GRMS

Tabel A. 1 Hasil Interview Protocol (1)

Pendefinisian aktor dan peran manajemen perubahan terhadap


1. Pertanyaan:

Siapa saja pihak yang terlibat dalam aktivitas

pengembangan aplikasi GRMS?

2. Pertanyaan:

Apakah terdapat pembentukan tim khusus untuk

penanganan pengembangan aplikasi GRMS?

A-2

3. Pertanyaan:

Bagaimana pembagian peran dari masing-masing pihak

yang terlibat?


Tujuan Interview : Mendapatkan informasi terkait

kondisi kekinian dan kondisi

ekspektasi dari manajemen

perubahan terhadap kebutuhan

aplikasi GRMS yang dikelola oleh

Bina Program

Tanggal :

Waktu :

Lokasi :

Narasumber :

Jabatan :

Topik : Identifikas kondisi kekinian dan

kondisi ekspektasi

Notes:

- Perkenalkan diri

- Mengucapkan terima kasih atas kesempatannya

- Menjelaskan durasi interview

- Sasaran:

o Kondisi kekinian pengembangan aplikasi

GRMS

o Kondisi ekspetasi pengembangan aplikasi

GRMS

A-3

Tabel A. 2 Hasil Interview Protocol (2)


1. Pertanyaan:

Bagaimana proses penanganan Bina Program terhadap

permintaan perubahan? Apakah terdapat aktivitas :

Membuat dan mencatat permintaan perubahan

Meninjau permintaan perubahan

Menilai dan mengevaluasi perubahan

Autorisasi perubahan

Memperbaharui rencana

Mengkoordinasikan implementasi

Mengevaluasi dan menutup perubahan

2. Pertanyaan:

Siapa sajakah yang dapat mengajukan permintaan

perubahan?

3. Pertanyaan:

Apakah terdapat aplikasi pencatatan permintaan perubahan

yang masuk? Apabila ada, apa bentuk pencatatannya?

4. Pertanyaan:

Bagaimana pengkategorian perubahan yang diterapkan

oleh Bina Program?

5. Pertanyaan:

Apakah pernah terjadi permasalahan selama proses

pengembangan aplikasi GRMS mulai dari pengajuan

permintaan perubahan hingga penutupan perubahan?

Apabila ada, apa sajakah itu?


6. Bagaimana harapan kedepan terkait proses pengelolaan


B-1

B LAMPIRAN B – Hasil Interview

Hasil wawancara I







Tanggal : 13 April 2016

Waktu : 13.30

Lokasi : Bina Program

Narasumber : Galuh Ayu Jendrastuti, ST

Jabatan : Admin e-project dan e-controlling




Notes:

Perkenalkan diri



Sasaran:



aplikasi GRMS

Tabel B.1 Hasil Interview Protocol (1)



1. Pertanyaan:

B-2



Pengusul perubahan (mulai dari pengguna GRMS, admin Bina

Program, kepala sub bagian Bina Program), admin Bina Program,

penyelia admin, kepala sub bagian Bina Program, Programmer

2. Pertanyaan:



Selama ini tidak ada. Hanya terdapat perapatan persetujuan antara

admin, kepala sub bagian, dan programmer (apabila diperlukan)

3. Pertanyaan:


yang terlibat?

Pengusul perubahan sebagai inisiator perubahan terhadap sistem,

admin Bina program sebagai pihak penjabaran detail perubahan

terhadap kepala sub bagian dan programmer, pencatatat detail

perubahan ke e-trac, penyelia admin sebagai penerima permintaan

perubahan dari pengguna, kepala sub bagian sebagai pihak untuk

menyetujui/menolak segala permintaan perubahan yang

berpengaruh besar, programmer sebagai pihak eksekutor

perubahan






aplikasi GRMS yang dikelola oleh Bina Program


Waktu : 13.40


B-3

Narasumber : Galuh Ayu Jendrastuti, S.T

Jabatan : Admin e-project dan e-controlling


kondisi ekspektasi

Notes:

- Perkenalkan diri



- Sasaran:


GRMS


GRMS



1. Pertanyaan:










Selama ini, pencatatan permintaan perubahan dilakukan apabila

telah disetujui oleh admin sendiri (apabila berpengaruh kecil) atau

oleh kepala sub bagian (apabila berpengaruh besar). Setelah itu,

biasanya programmer akan melihat detail pencatatan perubahan

tersebut untuk mengetahui apa yang akan dikerjakan. Pada hal ini,

B-4

apabila dirasa ada kesalahan dalam pendetailan permintaan

perubahan, programmer akan mengganti detail perubahan yang

masih salah. Setelah itu, programmer mengeksekusi perubahan

tersebut. Pengeksekusian juga dapat dilakukan oleh admin sendiri

bila memang bisa ditangani oleh admin. Pengimplementasian

hasil eksekusi dilakukan setelah hasil eksekusi divalidasi oleh

admin dan kepala sub bagian (apabila diperlukan). Terakhir,

programmer akan memberi status selesai pada halaman

pencatatan perubahan.

2. Pertanyaan:


perubahan?

Pengguna GRMS, admin Bina Program, Kepada sub bagian Bina

Program

3. Pertanyaan:



Ada, bentuknya dalam media elektronik yang dinamakan e-trac

4. Pertanyaan:


oleh Bina Program?

Dalam e-trac terdapat perbedaan untuk jenis perubahan dan

prioritas perubahan yang harus diimplementasikan. Akan tetapi,

saya merasa bahwa pengkategorian perubahan terbagi menjadi

dua saja, yaitu perubahan yang berpengaruh besar dan

berpengaruh kecil. Contoh besar adalah perubahan proses bisnis

dan penambahan validasi. Sedangkan kecil adalah penambahan

notifikasi, penambahan fitur, pembukaan paket data

5. Pertanyaan:





Saya rasa tidak pernah ada permasalahan yang terjadi, semua

berjalan dengan lancar


B-5



Mungkin lebih menginginkan untuk penambahan tenaga kerja

dalam menangani aktivitas pengembangan aplikasi GRMS

daripada untuk penambahan dari aktivitas yang ada

HASIL WAWANCARA II







Waktu : 14.00


Narasumber : Pratiwi Sri Hadi, ST

Jabatan : Admin e-delivery




Notes:

Perkenalkan diri



Sasaran:



aplikasi GRMS

B-6




1. Pertanyaan:



Pengguna GRMS, admin Bina Program, kepala sub bagian Bina

Program, Programmer

2. Pertanyaan:



Tidak ada tim khusus karena segala keputusan paling utama hanya

akan bergantung dari kepala sub bagian masing-masing aplikasi

3. Pertanyaan:


yang terlibat?

Pengguna GRMS sebagai pengusul perubahan, admin Bina

program sebagai penerima permintaan perubahan dari pengguna,

pencatatat detail perubahan ke e-trac, dan pihak penengah antara

kepala sub bagian dan programmer, kepala sub bagian sebagai

pihak untuk menyetujui/menolak segala permintaan perubahan

yang berpengaruh besar, programmer sebagai pihak eksekutor

perubahan






aplikasi GRMS yang dikelola oleh

Bina Program


B-7

Waktu : 14.15


Narasumber : Pratiwi Sri Hadi, ST

Jabatan : Admin e-delivery


kondisi ekspektasi

Notes:

- Perkenalkan diri



- Sasaran:


GRMS


GRMS



1. Pertanyaan:










Pencatatan permintaan perubahan dilakukan setelah dinyatakan

setuju untuk diimplementasikan oleh kepala sub bagian atau

admin sendiri (apabila dirasa bisa ditangani sendiri), tetapi

B-8

biasanya jarang untuk dilakukan pencatatan. Untuk peninjauan

perubahan sudah otomatis dilakukan saat perapatan dengan

kepala sub bagian untuk mengetahui apakah perubahan dapat

dilakukan dan apa saja tujuan dan manfaatnya. Setelah itu,

programmer bertugas mengeksekusi perubahan tersebut.

Pengeksekusian akan terus dimonitoring oleh admin. Setelah itu,

akan diimplementasikan langsung ke lingkungan kerja apabila

eksekusi selesai dilaksanakan. Implementasi juga kadang-kadang

harus divalidasi oleh kepala sub bagian apabila dirasa

memerlukan autorisasi penerapan dari kepala sub bagian.

2. Pertanyaan:


perubahan?

Pengguna GRMS, admin Bina Program, Kepada sub bagian Bina

Program

3. Pertanyaan:




4. Pertanyaan:


oleh Bina Program?

Pengkategoriannya lebih ke arah prioritas perubahan harus

dilakukan. Tetapi pada akhirnya tetap melihat apakah perubahan

berpengaruh besar atau kecil. Contoh besar adalah penambahan

fitur, perubahan proses bisnis. Contoh kecil adalah perubahan

data dan pemberian hak akses

5. Pertanyaan:





Selama ini belum pernah ada




B-9

Membutuhkan standar sendiri untuk prosedur yang lebih jelas,

seperti halnya dengan aplikasi e-procurement yang telah berjalan

menurut standar ISO 27002

HASIL WAWANCARA III







Waktu : 10.30


Narasumber : Enik Supristiyowati

Jabatan : Admin e-performance




Notes:

Perkenalkan diri



Sasaran:



aplikasi GRMS

B-10




1. Pertanyaan:



Pengguna SKPD, admin SKPD, super admin Bina Program,

kepala sub bagian Bina Program, Programmer

2. Pertanyaan:



Tidak ada tim khusus karena penanganan dari admin SKPD dan

super admin sudah dirasa cukup untuk mengatasi permintaan

perubahan dari para pengguna

3. Pertanyaan:


yang terlibat?

Pengguna SKPD sebagai pengusul perubahan, admin SKPD

sebagai penengah antara pengguna SKPD dan super admin, super

admin Bina program sebagai penerima permintaan perubahan dari

admin SKPD, pencatatat detail perubahan ke e-trac, dan pihak

penengah antara kepala sub bagian dan programmer, kepala sub

bagian sebagai pihak untuk menyetujui/menolak segala

permintaan perubahan yang berpengaruh besar, programmer

sebagai pihak eksekutor perubahan






B-11



Waktu : 11.00


Narasumber : Enik Supristiyowati

Jabatan : Admin e-performance


kondisi ekspektasi

Notes:

- Perkenalkan diri



- Sasaran:


GRMS


GRMS



1. Pertanyaan:










B-12

Pencatatan permintaan perubahan dilakukan setelah dirapatkan

dan disetujui oleh kepala sub bagian (apabila perubahan

berpengaruh besar) dan memang dicatat ke aplikasi e-trac. Untuk

penanganan permintaan perubahan yang dapat ditangani oleh

admin SKPD dan super admin, biasanya dicatatat ke dokumen

khusus lainnya karena jumlahnya bisa mencapai ratusan.

Perubahan tersebut antara lain pemberian hak akses, perubahan

status data pegawai, penilaian pegawai. Untuk perubahan yang

telah disetujui oleh kepala sub bagian, admin akan menyampaikan

detail perubahan kepada programmer dan programmer bertugas

mengeksekusi perubahan tersebut. Pengeksekusian akan terus

dimonitoring oleh admin. Setelah itu, akan diimplementasikan

langsung ke lingkungan kerja apabila eksekusi selesai

dilaksanakan. Implementasi juga kadang-kadang harus divalidasi

oleh kepala sub bagian apabila dirasa memerlukan autorisasi

penerapan dari kepala sub bagian.

2. Pertanyaan:


perubahan?

Pengguna SKPD, admin SKPD, super admin Bina Program,

Kepada sub bagian Bina Program

3. Pertanyaan:




untuk perubahan yang besar. Untuk perubahan sehari-hari

dimasukkan dalam dokumen khusus lainnya.

4. Pertanyaan:


oleh Bina Program?

Pengkategorian perubahan melihat apakah tergolong teknis yang

perlu dilakukan oleh programmer atau non-teknis yang dapat

dilakukan oleh admin sendiri. Untuk teknis, dibagi menjadi dua

yaitu perubahan yang berpengaruh besar dan berpengaruh kecil.

5. Pertanyaan:

B-13





Selama ini belum pernah ada




Pengguna SKPD diharapkan dapat mengetahui apa saja cakupan

perubahan yang dapat mereka ajukan

HASIL WAWANCARA IV







Waktu : 11.00


Narasumber : Dian Septiani Santoso

Jabatan : Admin e-budgeting




Notes:

Perkenalkan diri



B-14

Sasaran:



aplikasi GRMS




1. Pertanyaan:



SKPD, admin Bina Program, kepala sub bagian Bina Program,

programmer

2. Pertanyaan:



Tidak ada tim khusus karena segala keputusan akhir akan kembali

lagi kepada kepala sub bagian Bina program masing-masing

aplikasi

3. Pertanyaan:


yang terlibat?

SKPD sebagai pengusul perubahan, admin Bina program sebagai

penerima permintaan perubahan dari SKPD, pencatatat detail

perubahan ke e-trac, dan pihak penengah antara kepala sub bagian

dan programmer, kepala sub bagian sebagai pihak untuk

menyetujui/menolak segala permintaan perubahan yang

berpengaruh besar, programmer sebagai pihak eksekutor

perubahan




B-15





Waktu : 11.00


Narasumber : Dian Septiani Santoso

Jabatan : Admin e-budgeting


kondisi ekspektasi

Notes:

- Perkenalkan diri



- Sasaran:


GRMS


GRMS



1. Pertanyaan:








B-16



Biasanya, pencatatan permintaan perubahan dilakukan setelah

dirapatkan dan disetujui oleh kepala sub bagian. Untuk perubahan

yang telah disetujui oleh kepala sub bagian, admin akan

menyampaikan detail perubahan kepada programmer dan

programmer bertugas mengeksekusi perubahan tersebut.

Pengeksekusian akan terus dimonitoring oleh admin. Setelah itu,

hasil eksekusi wajib diserahkan kepada kepala sub bagian untuk

diperiksa dan diberi autorisasi penerapan ke lingkungan kerja.

Setelah selesai diimplementasikan, programmer atau admin

memberi tanda status penutupan pada pencatatan perubahan.

2. Pertanyaan:


perubahan?

SKPD, admin Bina Program, Kepada sub bagian Bina Program

3. Pertanyaan:




4. Pertanyaan:


oleh Bina Program?

Pengkategorian perubahan melihat dari aplikasi e-trac yang ada.

Tetapi pada umumnya, perubahan dibagi menjadi dua yaitu yang

berpengaruh besar dan berpengaruh kecil terhadap sistem dan

bisnis.

5. Pertanyaan:





Kadang-kadang terjadi miskomunikasi antara perubahan yang

disetujui dengan hasil eksekusi oleh programmer


B-17



Diharapkan adanya aktivitas yang memudahkan untuk

penyamaan persepsi antara admin/kasubag dengan pihak

programmer agar tidak terjadi kesalahan dalam pengeksekusian

C-1

C LAMPIRAN C – Verifikasi SOP

Verifikasi SOP diajukan kepada Kepala Sub Bagian Bina

Program untuk melakukan verifikasi terhadap dokumen SOP

Manajemen Perubahan terhadap kebutuhan aplikasi GRMS

yang telah dihasilkan. Verifikasi SOP telah dilaksanakan pada :

Tanggal wawancara : 24 Juni 2016

Nama Narasumber : Ika Tisnawati

Peran narasumber : Kasubag Pembinaan dan Pengendalian

Tujuan wawancara : Melakukan verifikasi SOP

No Pertanyaan Jawaban

1 Apakah terdapat

penulisan kalimat pada

alur prosedur yang perlu

diperbaiki?

Ada sebagian. Kalimat

pertama : “menyerahkan

RFC yang telah terisi dan

change proposal apabila

ada kepada change

manager” sebaiknya pada

kata-kata “apabila ada”

ditambah dengan tanda

kurung. Kalimat kedua :

“meninjau dan

melengkapi informasi

RFC apabila diperlukan”

sebagiknya pada kata-

kata “apabila diperlukan”

ditambah dengan tanda

kurung. Sebagian akhir

kata-kata pada aktivitas

menggunakan tanda titik

dan sebagian tidak. Lebih

baik semuanya

menggunakan tanda titik.

C-2

2 Apakah terdapat alur

aktivitas dalam prosedur

yang perlu diperbaiki atau

ditambah?

Dirasa cukup karena

aktivitas yang ada

semuanya telah

berdasarkan standar dan

sesuai untuk menjadi

masukkan bagi Bina

Program

3 Apakah terdapat

pelaksana dalam prosedur

yang perlu ditambah?

Dirasa cukup

4 Apakah seluruh struktur

dan isi formulir telah

sesuai?

Menurut saya sudah

sesuai

D-1

D LAMPIRAN D – Validasi SOP

Tanggal : 24 Juni 2016

Validator : Ika Tisnawati

Jabatan : Kasubag Pembinaan dan Pengendalian


Tujuan : Melakukan validasi SOP

Checklist Skenario Hasil Simulasi Keterangan

√ Pengguna mencatat usulan perubahan di dalam dokumen formulir RFC

Simulasi sudah dilakukan dengan baik

Kurang jelas terkait pengisian area bisnis

√ Change manager menerima dan meninjau formulir RFC (kelengkapan pengisian dan

Simulasi sudah dilakukan dengan baik dan cukup jelas

-

D-2


cakupan perubahan yang diusulkan)

√ Change manager mencatat seluruh usulan RFC ke dalam formulir log perubahan


√

Change manager mengklasifikasi perubahan yang telah disetujui (standard change, normal change, emergency change)


-

√

Design analyst mengisikan spesifikasi kebutuhan di formulir deskripsi kebutuhan perubahan


-

√ Change Owner mencatat hasil evaluasi implementasi dalam formulir log perubahan

Simulasi sudah dilakukan dengan baik dan jelas

-

D-3


√ Change Owner memverifikasi RFC yang telah selesai diimplementasikan

Simulasi sudah dilakukan dengan baik dan jelas

-

E-1

E LAMPIRAN E - BUKTI VERIFIKASI DAN

VALIDASI SOP

Bukti verifikasi dokumen SOP :

E-2

Bukti validasi dokumen SOP :

1. Hasil Simulasi

A. Pengisian RFC

E-3

E-4

Pengisian hasil simulasi :

E-5

Bukti validasi dengan admin e-project dan e-controlling :

Bukti validasi dengan kepala sub bagian pembinaan dan

pengendalian :

123

BIODATA PENULIS

Penulis yang lahir di Surabaya

pada tanggal 18 Setember 1994 ini

merupakan anak ketiga dari tiga

bersaudara. Penulis telah

menempuh pendidikan formal di

SD Petra 9 Surabaya, SMP Petra 5

Surabaya, SMA Petra 5 Surabaya,

dan akhirnya masuk menjadi

mahasiswa Sistem Informasi

angkatan 2012 melalui Jalur

SNMPTN tertulis. 5212 100 097

adalah NRP dari penulis sebagai

mahasiswa JSI-ITS. Selama

menempuh masa perkuliahan, penulis aktif dalam organisasi

UKM Bridge ITS dan aktif mengikuti turnamen olahraga

Bridge tingkat kota, provinsi, nasional, maupun internasional di

Malaysia. Pada tahun terakhir penulis mengambil bidang studi

Manajemen Sistem Informasi (MSI) dengan topik tugas akhir

manajemen perubahan ITIL V3. Penulis juga pernah menjalani

Kerja Praktik selama 2 bulan di kantor OJK Surabaya. Penulis

dapat dihubungi melalui e-mail: [email protected]

Documents

TUGAS AKHIR KS151601 PEMBUATAN STANDARD …repository.its.ac.id/2813/7/5212100021-Undergraduate-Theses.pdf · Gambar 2.4 Contoh Bagian Identitas SOP ... administrasi kontrak dan pencairan