DOKUMEN TATAKELOLA TI LABORATORIUM JURUSAN SISTEM INFORMASI ITS BERDASARKAN COBIT 5

(1)

DOKUMEN TATAKELOLA TI LABORATORIUM JURUSAN SISTEM INFORMASI ITS

BERDASARKAN COBIT 5

BAI02 – Mengelola Definisi Kebutuhan

Disusun oleh Mahasiswa Kelas Tatakelola TI Nanda Puji Nugroho 5213100023 Adnan Mauludin Fajriadi 5213100103 Robithah Hidayatullah 5213100123

Stezar Priansya 5213100131

(2)

Dokumen Tatakelola TI Jurusan Sistem Informasi Berdasarkan COBIT 5 BAI02 : Mengelola Definisi Kebutuhan 2

Daftar Isi

I. PENDAHULUAN ... 3

II. MAPPING OF CONTROL ... 3

2.1 Key Management Practice ... 3

2.2 Dokumen Tata Kelola ... 3

2.3 Interview Protokol ... 4

III. MAPPING DOKUMEN ... 6

IV. Hasil ... 6

Lembar Pengesahan ... 8

Pedoman ... 9

Panduan ... 16

Kebijakan ... 22

Kebijakan BAI02.01 ... 22

Prosedur ... 29

Prosedur BAI02.01 ... 29

Formulir ... 45

Catatan Usulan Perubahan BAI02.01 ... 45

Catatan Solusi Alternatif BAI02.02 ... 46

Register Risiko Kebutuhan BAI02.03 ... 47

Persetujuan Stakeholder Atas Kebutuhan dan Solusi yang Diajukan BAI02.04 ... 48

(3)

I. PENDAHULUAN

Dokumen ini berisikan mapping of control, pemilihan Key Management Practice , dan hasil rumusan pedoman, panduan, kebijakan, prosedur dan formulir. Secara keseluruhan isi pada dokumen ini mengacu dari COBIT 5: Enabling Process.

II. MAPPING OF CONTROL

2.1 Key Management Practice

Dalam pelaksanaan pembutan dokumen tata kelola teknologi informasi Mengelola Definisi Kebutuhan di Laboratorium Jurusan Sistem Informasi ini, kami menggunakan Key Management Practice sebagai berikut :

No KMP Alasan

1 BAI02 - Mendefinisikan dan mengelola

fungsional bisnis dan kebutuhan teknis

Karena proses tersebut menjelaskan sebuah set kegiatan prosedural yang hendaknya dilakukan oleh penanggung jawab proyek tatakelola di Laboratorium Jurusan Sistem Informasi untuk dapat menghasilkan definisi awal terkait kebutuhan informasi bisnis, fungsional, prasyarat teknis, dan kontrol untuk solusi bisnis yang diajukan.

2 BAI02 - Melakukan studi kelayakan dan membuat formulasi solusi

alternatif

Karena setiap bentuk pendefinisian kebutuhan perlu

dilakukan pengecekan ulang dari setiap alternatif solusi yang telah ada hingga pada akhirnya didapat solusi yang layak dan terbaik.

3 BAI02 - Mengelola Risiko Kebutuhan

Karena setiap solusi alternatif yang diajukan untuk memenuhi kebutuhan pasti memiliki risiko, entah itu risiko yang

berdampak tinggi maupun risiko berdampak rendah. Oleh karena itu dibutuhkanlah pengelolaan risiko untuk

mengidentifikasi risiko dan merencanakan tindakan penanganannya

4 BAI02 - Memperoleh persetujuan atas kebutuhan dan solusi

Karena setiap proses usulan solusi terhadap kebutuhan yang dilakukan memerlukan persetujuan agar dapat dilaksanakan usulan solusinya dan juga sesuai dengan kebutuhan

terhadap stakeholder terkait

2.2 Dokumen Tata Kelola

Dokumen yang dihasilkan yakni berupa pedoman, panduan, kebijajian, prosedur dan formulir untuk melakukan aktivitas – aktvitas yang diperlukan dalam Mengelola Definisi Kebutuhan.

(4)

2.3 Interview Protokol

Interview kami lakukan dengan Bapak Radityo sebagai Ketua Laboratorium di Studio Sistem Operasi dan Jaringan pada tanggal 12 Mei 2016. Interview protokolnya dapat dilihat pada tabel dibawah:

No Pertanyaan Jawaban

1. Pak, apakah selama ini sudah terdapat prosedur requirement di Laboratorium Jurusan Sistem Informasi?

Untuk prosedur requirement di Laboratorium Jurusan Sistem Informasi belum ada mas.

2. Terus pak kalau tidak ada prosedur, bagaimana Jurusan memenuhi kebutuhan yang dibutuhkan Laboratorium Jurusan Sistem Informasi?

Ya ketika Ketua Laboratorium sudah menentukan dan tahu apa saja kebutuhan yang diperlukan tinggal bilang ke Ketua Jurusan untuk meminta persetujuan

pemenuhan kebutuhan dan meminta form ke Sekretaris Jurusan. Setelah form terisi dengan benar maka

selanjutnya kita berikan kembali kepada Sekretaris Jurusan untuk di koreksi dan disampaikan kepada pihak ITS yang bersangkutan.

3. Kemudian apakah Ketua Laboratorium menentukan sendiri kebutuhan yang diperlukan dari laboratorium tersebut pak?

Ya tidak mas, bisanya akan ada diskusi gitu terkait pemenuhan kebutuhan laboratorium dengan laboran di awal semester.

4. Diskusinya biasanya dilaksanakan dimana pak?

Walah mas kalau diskusinya biasanya kami lakukan secara online gitu saja.

5. Untuk laboratorium yang lainnya apakah juga belum ada prosedur pemenuhan kebutuhannya pak?

Setahu saya semua laboratorium di Jurusan Sistem Informasi belum memiliki prosedur untuk pemenuhan kebutuhannya mas.

6. Terus menurut bapak prosedur kebutuhan itu perlu gak sih pak?

Ya perlu mas, kalau bisa kalian bikin yang bagus dan sesuaikan dengan keadaan yang ada di jurusan.

Dari hasil interview protokol tersebutlah kami memiliki landasan dasar untuk pembuatan prosedur kebutuhan Laboratorium Jurusan Sistem Informasi agar nantiya Jurusan Sistem Informasi memiliki prosedur yang jelas dalam pemenuhan kebutuhan laboratoriumnya.

Sehingga pemenuhan kebutuhan laboraturium sesuai dengan tujuan yang ingin dicapai dan kemampuan yang dimiliki Jurusan Sistem Informasi.

(5)

MAPPING KONTROL

Key Management

Practices

Prosedur Kontrol Aktivitas Formulir Acuan

BAI02.01 Mendefinisik an dan mengelola fungsional bisnis dan kebutuhan

teknis

Preventif dan Reaktif

Melakukan diskusi terhadap stakeholder terkait untuk menentukan

kebutuhan Laboratorium

Jurusan Sistem Informasi

Catatan Usulan Perubahan

BAI02.01

Tatakelola BAI02

BAI02.02 Melakukan studi kelayakan dan membuat

formulasi solusi alternatif

Preventif Pelaksanaan diskusi atau rapat untuk menentukan solusi-solusi alternatif dari

kebutuhan yang ada

Catatan Solusi Alternatif BAI02.02

-Tatakelola BAI02

BAI02.03 Mengelola risiko kebutuhan

Preventif Pelaksanaan diskusi atau

rapat identifikasi analisis risiko

kebutuhan

Register Risiko Kebutuhan

BAI02.03

-Tatakelola BAI02 - ISO 31000

- PMBOK Project Risk BAI02.04 Memperoleh

persetujuan atas kebutuhan dan solusi

Reaktif Pelaksanaan diskusi atau rapat untuk menentukan solusi dan pemenuhan

kebutuhan dengan stakeholder

Persetujuan Stakeholder

Atas Kebutuhan

dan Solusi BAI02.04

- Tatakelola BAI02

(6)

III. MAPPING DOKUMEN

Kebijakan Mendefinisikan dan mengelola fungsional bisnis dan kebutuhan teknis.

Kebijakan Melakukan studi kelayakan dan membuat formulasi solusi alternatif

Kebijakan Mengelola risiko kebutuhan.

Kebijakan Persetujuan atas kebutuhan dan solusi

Prosedur mendefinisikan dan mengelola fungsional bisnis dan kebutuhan teknis.

Prosedur melakukan studi kelayakan dan membuat formulasi solusi alternatif

Prosedur mengelola risiko kebutuhan.

Prosedur persetujuan atas kebutuhan dan solusi

Formulir Catatan Usulan Perubahan BAI02.01

Formulir Catatan Solusi Alternatif BAI02.02

Formulir Register Risiko Kebutuhan BAI02.03

Formulir persetujuan atas kebutuhan dan solusi

IV. Hasil

Berikut ini hasil dari dokumen tata kelola teknologi informasi Mengelola Definisi Kebutuhan di Laboratorium Jurusan Sistem Informasi berupa rumusan pedoman, panduan, kebijakan, prosedur dan formulir:

(7)

PEDOMAN

(8)

Laboratorium Jurusan Sistem Informasi

Lembar Pengesahan

PEDOMAN

Judul : Pedoman No. Dokumen : PDLSI-01 Revisi :

Dibuat oleh Disahkan oleh

Manajemen

Representatif Ketua Jurusan

Tanggal Tanggal

(9)

Pedoman

Laboratorium Jurusan Sistem

Informasi No Revisi

PDLSI-01

Tanggal Terbit Halaman 1. Pendahuluan

Laboratorium Jurusan Sistem Informasi dalam melangsungkan aktivitas operasionalnya membutuhkan penyesuaian terhadap kebutuhan TI. Oleh karena itu diperlukan tatakelola didalamnya. Tatakelola ini berfokus dilakukan untuk membantu Laboratorium Jurusan Sistem Informasi dalam melakukan pendefinisian dan manajemen kebutuhan TI yang ada dalam proses bisnis dan aktivitas operasionalnya.

2. Dasar dan Acuan

Dasar dan acuan dari pembuatan dokumen tatakelola ini adalah sebagai berikut.

Dasar:

Peraturan pemerintah nomor 11 tahun 2008 mengenai UU Informasi dan Transaksi Elektronik.

Acuan :

1. COBIT 5 : APO01.06, APO03.01, APO03.02, APO03.05, APO10.02,

APO11.03, BAI02.09 2. IEEE Standar 830 – 1998, ISO 31000, PMBOK Project Risk

(10)

Informasi No Revisi

PDLSI-01

Tanggal Terbit Halaman 3. Tujuan

Tujuan dari pembuatan dokumen tatakelola definisi kebutuhan Laboratorium Jurusan Sistem Informasi ITS adalah :

1. Mendefinisikan dan mengelola kebutuhan yang ada pada Laboratorium JSI.

2. Melakukan studi kelayakan dan menyusun solusi alternatif.

3. Mengelola resiko kebutuhan yang ada pada Laboratorium JSI.

4. Memperoleh persetujuan terkait kebutuhan dan solusi yang ada.

4. Ruang Lingkup

Ruang lingkup tatakelola yang terkait terhadap proses BAI02 Manage Requirement Definition yang terkait dengan COBIT 5 adalah sebagai berikut:

● Data integrity procedures, Data security, Control guidelines dan Data classification guidelines dari APO01.06

● Architecture principles dari APO03.01

● Solution development guidance dari APO03.05

● Quality management plan dari BAI02.09

● Supplier RFIs dan RFPs dari APO10.02

● Acceptance criteria dari APO11.03

● Information architecture model, Baseline domain descriptions dan Architecture definition dari APO03.02

(11)

Adapun ruang lingkup dari tata kelola yang dilakukan terhadap proses BAI02 Manage Requirements Definition sendiri ialah :

1. Mendefinisikan dan mengelola fungsional bisnis dan kebutuhan teknis.

2. Melakukan studi kelayakan dan menyusun solusi alternatif.

3. Mengelola resiko kebutuhan.

4. Memperoleh persetujuan terkait kebutuhan dan solusi.

5. Istilah dan Definisi

Berikut ini beberapa istilah yang terdapat dalam dokumen tatakelola Laboratorium Jurusan Sistem Informasi ITS.

KJ = Ketua Jurusan SJ = Sekretaris Jurusan KP = Kepala Program Studi KL = Kepala Laboratorium LB = Laboran

AL = Asisten Lab

(12)

Informasi No Revisi

PDLSI-01

Tanggal Terbit Halaman 6. Struktur Organisasi

Berikut adalah struktur organisasi Laboratorium Jurusan Sistem Informasi sebagai pedoman dalam melakukan tatakelola.

(13)

7. Penanggung Jawab

Berikut ini merupakan penanggung jawab dalam melakukan tatakelola Laboratorium Jurusan Sistem Informasi ITS.

Jabatan Penanggung Jawab pada Perusahaan

Business Executive Ketua Jurusan

Chief Information Officer Sekretaris Jurusan

Business Process Owners Kepala Program Studi

Head Architect Kepala Laboratorium Jurusan Sistem

Informasi

Architect Manajer Laboran

Architect Assistant Manajaner Asisten Lab

(14)

PANDUAN

(15)

Lembar Pengesahan

PANDUAN

Judul : Panduan No. Dokumen : PNLSI-01 Revisi : 00

Manajemen

Tanggal Tanggal

(16)

Panduan

Informasi No Revisi

PNLSI-01

Tanggal Terbit Halaman 1. Deskripsi Proses

Proses tata kelola yang akan dilakukan ialah identifikasi terhadap kebutuhan yang ada serta melakukan pencarian solusi sebelum pengambilan keputusan terkait proses bisnis, aplikasi, informasi/data, infrastruktur serta layanan yang ada di dalam organisasi, lalu menganalisis risiko terhadap usulan kebutuhan, hingga mendapatkan persetujuan atas kebutuhan dan solusi yang diajukan. Hal - hal tersebut berkaitan dan melibatkan stakeholder yang saling bekerjsama hingga mendapatkan hasil optimal yang diharapkan dari adanya tata kelola yang sudah dibuat.

2. Maksud Proses

Proses tata kelola dilakukan untuk membuat solusi optimal untuk memenuhi kebutuhan perusahaan dan meminimalisir resiko - resiko yang bisa terjadi dalam proses yang berlangsung dalam pepenuhan kebutuhan perusahaan dan proses pelaksanaannya.

(17)

Informasi No Revisi

PNLSI-01

Tanggal Terbit Halaman 3. Tujuan dan Indikator

Bagian ini berisi tujuan diadakannya tatakelola beserta indkatornya.

Tujuan Indikator

Fungsional bisnis dan kebutuhan teknis mencerminkan ekspektasi dari perusahaan

 Presentasi kebutuhan sudah sesuai dengan fungsional bisnis

 Tingkat kepuasan stakeholder terhadap kebutuhan

Solusi yang diajukan dapat

memenuhi fungsional bisnis, teknik dan juga pemenuhan kebutuhan

 Presentasi dari kebutuhan yang dapat dipenuhi oleh solusi yang diajukan

Resiko yang berhubungan dengan kebutuhan sudah mempunyai solusi yang tepat

 Presentasi masing - masing kebutuhan yang memiliki risiko dapat teridentifikasi mitigasinya

 Presentasi pengambilan tindakan dari risiko, baik berupa penagangan berupa Mitigasi (Treat), Pengambilan (Take), pemusnahan (Termintate), dan melibatkan pihak ketiga (Transfer).

Kebutuhan dan solusi yang

disarankan sudah dapat memenuhi tujuan dari bisnis (nilai yang diinginkan dan juga biaya)

 Presentasi tujuan dari bisnis yang terpenuhi oleh solusi yang diajukan

 Presentasi jumlah solusi yang disetujui berdasarkan kebutuhan

(18)

Informasi No Revisi

PNLSI-01 Tanggal Terbit

Halaman 4. Kunci Praktek Manajemen

Berikut ini pemetaan RACI berdasarkan istilah dan definisi pada pedoman sebelumnya.

Manajemen Kunci Praktik KJ SJ KP KL LB AL

BAI 02.01

Mendefinisikan dan mengelola fungsional bisnis dan kebutuhan teknis

I C C R R R

BAI 02.02

Melakukan studi kelayakan dan formulasi solusi alternative

I C A R R R

BAI 02.03

Mengelola risiko kebutuhan

I C C R R R

BAI 02.04

Mendapatkan persetujuan kebutuhan dan solusi

I C A R R R

(19)

Informasi No Revisi

PNLSI-01

Tanggal Terbit Halaman 5. Istilah Definisi

Berikut ini istilah dan definisi yang ada dalam dokumen tatakelola ini.

KJ = Ketua Jurusan SJ = Sekretaris Jurusan KP = Kepala Program Studi KL = Kepala Laboratorium LB = Laboran

AL = Asisten Lab

(20)

KEBIJAKAN

(21)

Lembar Pengesahan

KEBIJAKAN

Judul : Kebijakan No. Dokumen : KBLSI-01 Revisi : 00

Manajemen

Tanggal Tanggal

(22)

Kebijakan

Informasi No Revisi

Kebijakan BAI02.01

Mendefinisikan dan mengelola fungsional bisnis dan kebutuhan teknis.

Tanggal Terbit

Halaman

Bagian ini berisi kebijakan manajemen Jurusan Sistem Informasi ITS yang diberikan untuk menjalankan aktivitas dalam proses yang menjadi fokus tatakelola.

Berikut ini kebijakan pada setiap kunci praktek manajemen berdasarkan setiap aktivitasnya.

1. Mendefinisikan dan mengimplementasikan definisi kebutuhan serta merawat prosedur dan kebutuhan yang sesuai dengan ukuran, kompleksitas, tujuan dan risiko dari inisiatif yang diambil.

1.1 Definisi dan implementasi kebutuhan harus dilakukan dengan persetujuan seluruh pemangku kepentingan terkait.

1.2 Perawatan prosedur dan kebutuhan harus dilakukan sesuai dengan prosedur yang ditetapkan.

2. Mendefinisikan kebutuhan bisnis akan gap antara kemampuan bisnis saat ini dan yang diharapkan, serta bagaimana setiap peran akan berinteraksi dan menggunakan solusi.

2.1 Definisi kebutuhan bisnis harus memperhatikan tujuan bisnis perusahaan.

3. Mengelisitasi, menganalisis, dan mengkonfirmasi seluruh pemangku kepentingan telah diperhitungkan dan diprioritaskan dengan tujuan memahami pemangku kepentingan, sponsor bisnis serta personil teknisi implementasi.

3.1 Elisitasi, analisis dan konfirmasi harus dilakukan berdasarkan prosedur yang ditetapkan.

4. Menspesifikkan dan memprioritisasi informasi, fungsional dan kebutuhan teknis berdasarkan konfirmasi kebutuhan pemangku kepentingan, termasuk kebutuhan kontrol inforkasi dalam proses bisnis, automasi proses dan lingkungan TI untuk mendapatkan risiko informasi dan untuk menyesuaikan dengan hukum, aturan dan kontrak komersial.

(23)

4.1 Spesifikasi dan prioritisasi informasi dilakukan mengacu pada pedoman yang telah ditetapkan.

5. Memvalidasi seluruh kebutuhan melalui pendekatan seperti peer review, validasi model atau prototipe operasional.

5.1 Validasi kebutuhan dilakukan berdasarkan persetujuan para pemangku kepentingan.

6. Mengkonfirmasi aspek kunci penerimaan kebutuhan, termasuk peraturan perusahaan, kontrol informasi, keberlanjutan bisnis, legalitas dan regulasi kepatuhan, auditabilitas, ergonomis, dan dokumentasi.

6.1 Konfirmasi seluruh aspek kunci penerimaan kebutuhan dilakukan sesuai dengan pedoman dan prosedur yang ditetapkan.

7. Menapak jejak dan mengontrol ruang lingkup, kebutuhan serta perubahan melalui siklus hidup solusi pada seluruh proyek.

7.1 Kontrol ruang lingkup didasarkan pada ruang lingkup yang ada dalam dokumen pedoman.

8. Mempertimbangkan kebutuhan yang berhubungan dengan kebijakan perusahaan dan standar, arsitektur perusahaan, rencana strategi dan taktik IT, kebutuhan keamanan, kebutuhan regulasi, kompetensi sumber daya, struktur organisasi, kasus bisnis serta penerapan teknologi.

7.1 Pertimbangan kebutuhan dilakukan dengan melibatkan seluruh pemangku kepentingan terkait.

(24)

Informasi No Revisi :

Melakukan studi kelayakan dan membuat formulasi solusi alternatif

Tanggal Terbit : Halaman :

Bagian ini berisi kebijakan birokrasi yang diberikan untuk menjalankan aktivitas dalam proses yang menjadi fokus tatakelola.

1. Kebutuhan - kebutuhan Laboratorium JSI harus telah di didefiniskan terlebih dahulu.

2. Proses diskusi kelayakan solusi alternatif dari kebutuhan-kebutuhan harus dihadiri oleh pemangku kepentingan.

3. Proses penentuan kriteria mempertimbangkan aspek-aspek yang lain serta proses bisnis Laboratorium di JSI.

4. Solusi – solusi yang ditawarkan harus mempertimbangkan penggalian kebutuhan arsitektur dari Laboratorium di JSI.

5. Penentuan solusi yang ditawarkan berdasakarkan kriteria yang telah dibuat harus melibatkan pemangku kepentingan.

6. Review solusi alternatif harus berdasarkan kesepakatan para pemangku kepentingan.

7. Rencana pengembangan harus mendukung visi Laboratorium di JSI.

(25)

Laboratorim Jurusan Sistem

Informasi No Revisi

Kebijakan BAI02.03 Mengelola risiko kebutuhan.

Tanggal Terbit Halaman

1. Melibatkan pemangku kepentingan untuk menentukan konteks serta kebutuhan teknis dan risiko yang berhubungan dengan pengelolaan informasi sesuai dengan prosedur yang telah ditetapkan.

2. Mengidentifikasi hal – hal yang terkait dengan solusi kebutuhan yang bisa berpotensi munculnya risiko dan penyebabnya.

3. Menganalisis dan memprioritisasi kebutuhan risiko berdasarkan probabilitas dan dampak. Dilakukan dengan menggunakan standar perhitungan risiko tertentu.

4. Mengidentfikasi cara penanganan terkait risiko baik secara mengontrol, menghindari, mentransfer, dan memitigasi risiko kebutuhan untuk prioritisasi.

(26)

Informasi No Revisi

Memperoleh persetujuan terkait kebutuhan dan solusi.

1. Memastikan bahwa Stakeholder membuat keputusan akhir dengan pendekatan akuisisi dan rencana high-level berdasarkan kasus bisnis.

1.1 Pendekatan akuisisi harus dilakukan dengan persetujuan seluruh pemangku kepentingan proses bisnis perusahaan.

2. Mendapatkan review kualitas pada setiap stage proyek, iterasi atau rilis untuk penilaian hasil terhadap pemenuhan kriteria penerimaan.

2.1 Review kualitas didasarkan pada hasil prioritisasi kebutuhan.

(27)

\

PROSEDUR

(28)

Lembar Pengesahan

PROSEDUR

Judul : Prosedur No. Dokumen : PSDRLSI-01 Revisi : 00

Manajemen

Tanggal Tanggal

(29)

Prosedur

Informasi No Revisi

Prosedur BAI02.01

Mendefinisikan dan mengelola fungsional bisnis dan kebutuhan teknis

Bagian ini mendeskripsikan prosedur tatakelola sesuai proses yang sedang dibahas.

Berdasarkan kondisi nyata organisasi, pada Laboratorium Jurusan Sistem Informasi dilakukan identifikasi, pembuatan prioritas, spesifikasi dan kesepakatan tentang informasi bisnis, fungsional, prasyarat teknis dan kontrol yang meliputi cakupan dan/atau pemahaman dari setiap hal-hal yang dibutuhkan untuk mencapai luaran yang diharapkan dari solusi bisnis berbasis Teknologi Informasi.

Bagian ini menjelaskan tentang alasan spesifik mengapa dan tujuan proses ini dalam tahapan tatakelola.

Maksud proses adalah untuk menjelaskan sebuah set kegiatan prosedural yang hendaknya dilakukan oleh penanggung jawab proyek tatakelola di Laboratorium Jurusan Sistem Informasi untuk dapat menghasilkan definisi awal terkait kebutuhan informasi bisnis, fungsional, prasyarat teknis, dan kontrol untuk solusi bisnis yang diajukan.

3. Standar yang Berlaku

Dokumen Pedoman Tatakelola BAI02.

(30)

4. Indikator Kerja

Bagian ini berisi indikator umum yang menandakan proses tata kelola berjalan.

Dapat disesuaikan kembali sesuai kondisi existing organisasi. Yang disebutkan dibawah adalah indikator minimal yang harus ada.

1. Dokumen yang memuat list repository definisi kebutuhan dapat diselesaikan.

2. Stakeholder melakukan persetujuan terhadap kriteria penerimaan.

3. Terdapat catatan atau dokumen yang memuat rekaman usulan perubahan kebutuhan.

(31)

Informasi No Revisi

Tanggal Terbit Halaman 5. Masukan

No Sumber Masukan Deskripsi Masukan No & Nama Dokumen

1 APO01.06

• Data prosedur integritas

• Data panduan

keamanan dan kontrol

• Data panduan klasifikasi

2 APO03.01 Prinsip arsitektur

3 APO03.02

• Model arsitektur informasi

• Deskripsi domain dasar dan definisi arsitektur

4 APO03.05 Pedoman pengembangan

solusi

5 APO10.02 RFI dan RFP Supplier 6 APO11.03 Kriteria penerimaan 6. Luaran

No Sumber Keluaran Deskripsi Keluaran Ke

1 APO01.06 Repositori definisi kebutuhan

BAI03.01 BAI03.02 BAI04.01 BAI05.01

2 APO03.01

Kriteria penerimaan dari stakeholder yang telah dikonfirmasi

BAI03.01 BAI03.02 BAI04.03 BAI05.01 BAI05.02 3 APO03.02

Catatan usulan perubahan

kebutuhan BAI03.09

4 APO03.05 5 APO10.02 6 APO011.03

(32)

Informasi No Revisi

Tanggal Terbit Halaman 7. Peralatan dan Perlengkapan

Bagian ini berisi peralatan dan perlengkapan yang dibutuhkan untuk menjalankan prosedur hingga selesai.

1. Notebook dan kertas 2. Papan tulis dan spidol 3. Alat tulis

4. Laptop atau PC 8. Aktivitas

Bagian ini merupakan serangkaian kegiatan prosedural yang dilakukan oleh penanggung jawab dalam proses tatakelola.

1.1 KP melakukan diskusi kepada Mahasiswa Jurusan Sistem Informasi untuk melakukan survey kebutuhan pada Laboratorium JSI.

1.2 LB bersama dengan KL dan KP melakukan diskusi untuk menentukan kebutuhan Laboratorium JSI yang disesuaikan dengan kebutuhan stakeholder jurusan, kondisi kekinian jurusan, dan tujuan yang ingin dicapai.

1.3 KL bersama dengan SJ melakukan diskusi penyesuaian kebutuhan Laboratorium JSI dengan kemampuan yang dimiliki jurusan.

1.4 LB bersama dengan KL dan/atau KP melakukan diskusi untuk menyepakati penyesuaian kebutuhan Laboratorium JSI yang terjadi.

1.5 LB bersama dengan KL dan/atau KP membuat prioritas terhadap kebutuhan Laboratorium JSI.

1.6 LB bersama dengan KL melakukan diskusi untuk menentukan cara maintenance kebutuhan Laboratorium JSI.

1.7 LB membuat dokumentasi kebutuhan Laboratorium JSI.

1.8 KL bersama KJ melakukan pertemuan untuk persetujuan dan validasi dokumen kebutuhan Laboratorium JSI.

1.9 KL melakukan pengecekan ulang terhadap dokumen kebutuhan Laboratorium JSI . 1.10KL melakukan pertemuan dengan stakeholder untuk mensosialisasikan dokumen

kebutuhan Laboratorium JSI.

1.11KL melakukan revisi final dokumen kebutuhan Laboratorium JSI atas saran yang diberikan stakeholder jurusan.

(33)

Tanggal Terbit : Halaman : 1. Deskripsi Proses

Bagian ini mendeskripsikan prosedur tatakelola sesuai proses yang sedang dibahas

Proses yang dilakukan yaitu sebuah studi kelayakan tentang solusi alternatif potensial, menilai daya gunanya dan memilih opsi yang lebih disukai dari solusi awal kebutuhan Laboratorium Jurusan Sistem Informasi. Jika cocok, implementasikan opsi yang dipilih sebagai penunjuk untuk menentukan kemungkinan perbaikan.

Maksud dari proses ini adalah untuk mengidentifikasi dan melakukan studi kelayakan terhadap alternatif dari solusi bisnis dari kebutuhan yang diajukan di awal. Aktivitas prosedural dilakukan oleh penanggung jawab tata kelola untuk menghasilkan kemungkinan rekomendasi solusi bisnis lain yang dapat dilakukan.

1. Dokumen laporan uji kelayakan dari alternatif solusi dapat diselesaikan terhitung dari jangka waktu tertentu sejak dokumen repositori definisi prasyarat diterima dan disetujui oleh stakeholder.

2. Terdapat pernyataan dalam bentuk surat kebijakan atau dokumen terkait rencana pengembangan dan/atau akuisi tingkat tinggi yang dikeluarkan oleh aktor tertentu.

(34)

Tanggal Terbit : Halaman : 5. Masukan

No Sumber Masukan Deskripsi Masukan No & Nama Dokumen 1 APO03.05 Panduan pengembangan

solusi

2 APO10.01 Katalog pemasok

3 APO03.02

• Hasil keputusan dari evaluasi pemasok

• Evaluasi RFI dan RFP

• RFI dan RFP pemasok

4 APO11.03 Kriteria penerimaan 6. Luaran

No Sumber Keluaran Deskripsi Keluaran Ke 1 APO03.05 Laporan studi kelayakan BAI03.02

BAI03.03 2

3 4

APO10.01 APO10.02 APO11.03

Rencana pengembangan dan/atau akuisi High-level

APO10.02 BAI03.01 7. Peralatan dan Perlengkapan

1. Notebook atau kertas 2. Papan tulis dan spidol 3. Alat tulis

4. Laptop atau PC

(35)

Tanggal Terbit : Halaman : 8. Aktivitas

a. KL menyusun kriteria-kriteria kelayakan untuk membedakan tingkat kecocokan dari pihak-pihak yang akan menawarkan solusi .

b. KP bersama dengan KL dan LB mendefinisikan solusi – solusi alternatif yang dapat memenuhi kebutuhan Laboratorium Jurusan Sistem Informasi.

c. KL bersama dengan LB menentukan tindakan yang akan dilakukan untuk mengembangkan solusi arsitektur untuk Laboratorium Jurusan Sistem Informasi.

d. KP bersama dengan KJ dan KL meninjau solusi – solusi alternatif yang diajukan.

e. KP memilih solusi alternatif yang sesuai dengan kriteria yang dibutuhkan.

f. KL membuat rencana pengembangan dari solusi terpilih sebagai bentuk lanjutan untuk mengidentifikasi tahap selanjutnya.

(36)

Informasi No Revisi

Prosedur BAI02.03 Mengelola risiko kebutuhan

Pada bagian ini mendeskripsikan prosedur tata kelola sesuai proses yang sedang dibahas

Aktivitas yang dilakukan pada prosedur ini adalah manajemen risko pada definisi kebutuhan yang terdiri dari: penentuan konteks, identifikasi, analisis, evaluasi, dan penanganan; terhadap risiko fungsional dan teknis terkait dengan kebutuhan perusahaan dan solusi yang diajukan.

Pada bagian ini menjelaskan tentang alasan spesifik mengapa dan tujuan proses ini dilakukan dalam tahapan tatakelola.

Setelah merumuskan solusi yang dipilih untuk memenuhi kebutuhan pada Laboratorium Jurusan Sistem Informasi, berikutnya, penanggung jawab tata kelola melakukan sebuah aktivitas manajamen risiko terhadap solusi - solusi yang dipilih untuk dapat mengetahui risiko apa saja yang mungkin terjadi dari solusi yang dipilih dan tindakan apa yang akan diambil.

Pada bagian ini menjelaskan tentang Standar yang digunakan sebagai acuan dalam pelaksanaan proses ini.

Dokumen Pedoman Tatakelola BAI02, ISO 31000, PMBOK Project Risk 4. Indikator Kerja

1. Dokumen risk register telah dimulai pengerjaannya ketika memasuki proses BAI02.03 dan berhasil diselesaikan ketika menjelang proses BAI02.03 berakhir.

2. Adanya hasil analisis terhadap risiko dan dftar penanganan terhadap masing – masing risiko yang mungkin terjadi.

3. Terdapat dokumentasi aktivitas mitigasi risiko yang berhasil dijalankan.

(37)

Informasi No Revisi

Mengelola risiko kebutuhan

No Sumber Masukan Deskripsi Masukan No & Nama Dokumen 1 BAI02.02 Solusi pilihan terhadap

definisi kebutuhan Catatan Solusi Alternatif

6. Luaran

No Sumber Keluaran Deskripsi Keluaran Ke

1 Register risiko kebutuhan

BAI03.10 BAI03.02 BAI04.01 BAI05.01

2 Tindakan mitigasi risiko

BAI01.10 BAI03.02 BAI05.01

7. Peralatan dan Perlengkapan

4. Laptop atau PC

5. Dokumen masukan daftar solusi pilihan BAI02.02

(38)

Informasi No Revisi

Mengelola risiko kebutuhan

Tanggal Terbit Halaman 8. Aktivitas

1. KL dan LB berdiskusi bersama – sama untuk menentukan konteks, ruang lingkup dan batasan mengenai manajamen risiko terhadap usulan solusi yang dipilih.

2. KL memutuskan konteks yang telah didiskusikan bersama tadi.

3. KL dan LB berdiskusi untuk mengidentifikasi hal – hal yang terkait seperti nama risiko, deskripsi risiko, penyebab risiko, pemicu risiko dalam segi teknis, strategis, dan asset dari usulan Solusi

4. LB menyusun hasil diskusi identifikasi risiko kedalam dokumen risk register 5. KL dan LB berdiskusi untuk menganalisa probabilitas dan dampak yang akan terjadi terkait risiko yang muncul dari usulan risiko.

6. LB menyusun hasil diskusi analisis risiko kedalam dokumen risk register.

7. KL menyerahkan risk register kepada KP untuk mengevaluasi dari pandangan orang lain diluar laboratorium yang masih berkaitan terutama dalam hal akademik yang berhubungan dengan usulan solusi

8. KP melakukan evaluasi dan review terhadap risk register, dan hasilnya akan dikembalikan kepada KL.

9. KL dan LB melakukan pembahasan dan jika ada kesalahan perlu pebaikan terkait hasil evaluasi yang dilakukan oleh KP

10. KL dan LB berdikusi bersama menentukan perencanaan langkah yang akan diambil baik berupa mengontrol, menghindari, mentransfer maupun mengurangi dampak terhadap risiko kebutuhan.

11. LB menyusun hasil diskusi penanganan kedalam risk register

12. KL mengoreksi risk register akhir yang telah dibuat dan menyerahkan hasil akhir risk regirester kepada KJ

13. KJ melakukan review terhadap dokumen risk register akhir

(39)

14. KJ melakukan persetujuan terhadap dokumen risk register akhir 15. LB dan AL menerapkan hasil dokumen risk register berupa tindakan penanganan kedalam operasional usulan Solusi

(40)

Informasi No Revisi

Memperoleh persetujuan atas kebutuhan dan solusi

Bagian ini mendeskripsikan prosedur tata kelola sesuai proses yang sedang dibahas

Mengkoordinasikan kembali umpan balik dari stakeholder yang bersangkutan dan pada tahapan kunci yang telah ditetapkan, menerima persetujuan dari stakeholder bisnis atau pemilik bisnis dan penandatanganan kebutuhan fungsional dan teknis, studi kelayakan, analisa risiko dan rekomendasi solusi 2. Maksud Proses

Menjelaskan sebuah set kegiatan prosedural yang hendaknya dilakukan oleh Jurusan Sistem Informasi untuk mencapai persetujuan dari stakeholder dari pihak eksternal seperti stakeholder, fakultas, atau orang tua/ wali mahasiswa terkait kebutuhan fungsional dan teknis studi kelayakan, analisa risiko, dan rekomendasi solusi.

1. Seluruh stakeholder dan elemen eksternal jurusan menyetujui kebutuhan dan solusi yang diajukan; dibuktikan dengan penandatanganan dokumen charter, MoU, dan sejenisnya.

2. Dokumen tinjau ulang kualitas dapat diselesaikan dan disetujui oleh stakeholder bersangkutan.

(41)

Informasi No Revisi

No Sumber Masukan Deskripsi Masukan No & Nama Dokumen 1 BAI01.09 Rencana manajemen

kualitas

6. Luaran

No Sumber Keluaran

Deskripsi Keluaran Ke

1 BAI01.09

Persetujuan stakeholder atas kebutuhan dan solusi yang diajukan

BAI03.02 BAI03.03 BAI03.04

7. Peralatan dan Perlengkapan

4. Laptop atau PC

(42)

Informasi No Revisi

Tanggal Terbit Halaman 8. Aktivitas

1.1 KJ dan KP bekerjasama memastikan bahwa stakeholder dan/atau orang tua/wali mahasiswa membuat keputusan akhir dengan menghormati pilihan solusi dengan melakukan pertemuan.

1.2 KJ dan KL bekerjasama mengoordinasikan umpan balik dari stakeholder yang bersangkutan dan mendapatkan tanda tangan daripihak- pihak yang berwenang.

1.3 LB membuat prosedur untuk pelaksanaan tambahan dan saran – saran dari umpan balik stakeholder yang bersangkutan termasuk mendapatkan kesepakatan bersama pihak teknis yang terlibat

1.4 KL memberikan persetujuan akan prosedur yang telah dibuat LB

1.5 KL membuat prosedur dalam melakukan penilaian terhadap hasil laporan yang akan diberikan pada stakeholder lainnya

1.6 LB dan AL melakukan penilaian terhadap proses berjalannya proyek 1.7 LB membuat laporan terkait keseluruhan proses pelaksanaan proyek

1.8 Laporan diterima dan disetujui oleh KL; lalu dikomunikasikan pada dan KP dan KJ

1.9 KP dan KJ memberikan penilaian hasil sesuai dengan kriteria penerimaan yang dibuat diawal

(43)

FORMULIR

(44)

Lembar Pengesahan

FORMULIR

Judul : Formulir No. Dokumen : FMRLSI-01 Revisi : 00

Manajemen

Tanggal Tanggal

(45)

Formulir

Informasi No Revisi

Catatan Usulan Perubahan BAI02.01

Surabaya, ... 2016 (Jabatan Penanggung Jawab)

(Nama Terang) NIP.

Penjelasan :

Form ini untuk mencatat usulan perubahan kebutuhan yang ada pada Laboratorium Jurusan Sistem Informasi ITS.

No Tanggal

Usulan Kebutuhan yang Diubah

Perubahan Usulan Kebutuhan

Alasan

Pengubahan Pengusul

(46)

Catatan Solusi Alternatif BAI02.02

Tanggal Terbit : Halaman :

(Nama Terang) NIP.

Penjelasan :

Form ini untuk mencatat solusi-solusi alternatif beserta solusi apa yang kemudian dipilih untuk memenuhi kebutuhan Laboratorium JSI.

No Usulan Kebutuhan

Usulan

Solusi Solusi Alternatif Pengusul Solusi Terpilih

(47)

Informasi No Revisi

Register Risiko Kebutuhan BAI02.03

(Nama Terang) NIP.

Penjelasan :

Form ini digunakan untuk menulis daftar risiko, penyebab, probabilitas, dampak, dan Penanganan.

Pengidentifikasian risiko menggunakan risk register dari PMBOK Project Risk yang telah disederhanakan

No

Risiko Rank Nama Risiko

Deskripsi

Risiko Penyebab Probabilitas Dampak Penanga nan

(48)

Informasi No Revisi

Persetujuan Stakeholder Atas Kebutuhan dan Solusi yang Diajukan BAI02.04

(Nama Terang) NIP.

Penjelasan :

Form ini digunakan sebagai bukti penerimaan atau persetujuan kriteria kebutuhan oleh pihak stakeholder

No Tanggal Kebutuhan Deskripsi Kebutuhan Keterangan

Disetujui/

Tidak Disetujui

(Jabatan Stakeholder)

Nama Terang