SKRIPSI PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI KASUS: DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN KOTA TANGERANG SELATAN)
Disusun Oleh: Ines Putri Karunia NIM: 1110093000041
PROGRAM STUDI SISTEM INFORMASI FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2015M/1435H
i
SKRIPSI PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI KASUS: DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN KOTA TANGERANG SELATAN)
Disusun Oleh: Ines Putri Karunia NIM: 1110093000041
PROGRAM STUDI SISTEM INFORMASI FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2015M/1435H
i
SKRIPSI PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI KASUS: DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN KOTA TANGERANG SELATAN)
Oleh: Ines Putri Karunia NIM: 1110093000041
Skripsi Sebagai Salah Satu Syarat Untuk Memperoleh Gelar Sarjana Sistem Informasi Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah
PROGRAM STUDI SISTEM INFORMASI FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA 2015M/1435H
ii
PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN TOGAF ARCHITECTURE DEVELOPMENT METHOD (STUDI KASUS: DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN KOTA TANGERANG SELATAN)
Skripsi Diajukan kepada Fakultas Sains dan Teknologi Untuk Memenuhi Persyaratan Memperoleh Gelar Sarjana Sistem Informasi (S.SI) Oleh : Ines Putri Karunia NIM : 1110093000041
Menyetujui, Pembimbing I
Pembimbing II
Elvi Fetrina, MIT NIP. 19740625 200901 2 005
Evy Nurmiati, MMSI NIP.
Mengetahui, Ketua Program Studi Sistem Informasi
Nia Kumaladewi, MMSI NIP. 19750412 200710 2 002
iii
PENGESAHAN UJIAN Skripsi yang berjudul “Perancangan Enterprise Architecture Menggunakan TOGAF Architecture Development Method (Studi Kasus: Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan)” telah diuji dan dinyatakan lulus dalam sidang munaqosyah Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta pada hari 6 Agustus 2015. Skripsi ini telah diterima sebagai salah satu syarat untuk memperoleh gelar sarjana strata (S1) pada program studi Sistem Informasi. Jakarta, 26 Agustus 2015 Menyutujui, Penguji I
Penguji II
A’ang Subiyakto, M.Kom NIP. 1976021920070 1 002
Suci Ratnawati, MTI NIP.
Pembimbing I
Pembimbing II
Elvi Fetrina, MIT NIP. 19740625200901 2 005
Evy Nurmiati, MMSI NIP. Mengetahui,
Dekan Fakultas Sains dan Teknologi
Ketua Prodi Sistem Informasi
Dr. Agus Salim, S.Ag, M.Si NIP. 197208161999031003
Nia Kumaladewi, MMSI NIP. 1975041200710 2 002
iv
PERNYATAAN
DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENARBENAR HASIL KARYA SENDIRI DAN BELUM PERNAH DIAJUKAN SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI ATAU LEMBAGA MANAPUN.
Jakarta, 9 Juli 2015
Ines Putri Karunia
v
ABSTRAK Ines Putri Karunia (1110093000041), Perancangan Enterprise Architecture Menggunakan TOGAF (Studi Kasus: Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan). Dibawah Bimbingan ELVI FETRINA, MIT dan EVY MURMIATI, MMSI. Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan (DTKBDP) merupakan instansi milik pemerintah dibawah pimpinan pemerintahan daerah kota Tangerang Selatan. DTKBDP mempunyai peran penting dalam melaksanakan kegiatan pembangunan dan perbaikan sarana pemerintahan dan non pemerintahan kota Tangerang Selatan, serta mempunyai tanggung jawab dalam memberikan pelayanan perizinan pada setiap bangunan atau permukiman yang akan dibangun di Tangerang Selatan. Dalam perkembangannya, DTKBDP telah memiliki infrastruktur teknologi yang cukup bagus, namun aplikasi yang digunakan dalam mendukung pelaksanaan tugasnya hanyalah aplikasi standar yang tidak saling terintegrasi. Hal ini disebabkan karena tidak adanya perencanaan teknologi informasi dan sistem informasi yang selaras dengan proses bisnis dalam DTKBDP. Tidak adanya database management system mejadikan penyimpanan dokumen, data serta informasi tidak tersusun dengan baik. Oleh karena itu dibutuhkan suatu perancangan enterprise architecture sebagai kerangka dasar solusi bisnis untuk menyelesaikan masalah dalam mengoptimalkan penggunaan TI yang dimiliki. Penelitian ini menggunakan TOGAF (The Open Group Architecture Framework) yang terdiri dari fase preliminary, arsitektur visi, arsitektur bisnis, arsitektur sistem informasi, arsitektur teknologi peluang dan solusi, serta rencana migrasi. Dari semua fase tersebut akan dihasilkan blueprint arsitektur dan roadmap implementasi aplikasi untuk DTKBDP.
Kata Kunci : DTKBDP, enterprise architecture, teknologi informasi, sistem informasi, database management system, TOGAF
V Bab + 204 Halaman + 55 Gambar + 40 Tabel + 22 Pustaka + Lampiran Pustaka Acuan (20, 2005-2013)
vi
KATA PENGANTAR
Alhamdulillahhirobal’alamin. Dengan mengucapkan puji dan syukur kehadirat Allah SWT yang telah memberikan rahmat dan hidayah-Nya sehingga penulis dapat menyelesaikan skripsi ini. Shalawat serta salam tak lupa tersirah untuk Nabi Muhammad SAW beserta keluarga dan sahabatnya. Amiin. Skripsi
yang
berjudul
“Perancangan
Enterprise
Architecture
Menggunakan TOGAF Architecture Development Metod (Studi Kasus: Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan-DTKBDP) ini disusun sebagai salah satu syarat untuk mendapatkan gelar Sarjana Sistem Informasi pada Universitas Islam Negeri Syarif Hidayatullah Jakarta, dan akhirnya telah rampung diselesaikan oleh penulis dengan sebaik-baiknya. Berkenaan dengan selesainya penyusunan skripsi, maka dengan rasa syukur serta hormat penulis mengucapkan terima kasih pada semua pihak yang telah memberikan bantuan, bimbingan, dan pengarahan serta dukungan moril dan materil. Oleh karena itu, dalam kesempatan ini penulis mengucapkan terima kasih yang sebesar-bersanya kepada: 1. Bapak Dr. Agus Salim, M.Si selaku Dekan Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta. 2. Ibu Nia Kumaladewi, MMSI selaku Ketua Program Studi Sistem Informasi.
vii
3. Ibu Elvi Fetrina, MIT selaku Dosen Pembimbing I yang dengan sabar membimbing penulis, memberikan ilmu dan motivasi selama proses penyusunan skripsi. 4. Ibu Evi Nurmiati, MMSI selaku Dosen Pembimbing II yang dengan sabar membimbing penulis, memberikan ilmu dan motivasi selama proses penyusunan skripsi. 5. Seluruh dosen prodi Sistem Informasi yang telah memberikan ilmunya. 6. Bapak Heri Asari S.Kom, Msi, selaku pembimbing dari Bidang IT DTKBDP. 7. Untuk semua staff dan pegawai DTKBDP yang telah membantu penulis dalam memperoleh kelengkapan data yang dibutuhkan. 8. Ayah dan mama, H. Abi Sindu Harto dan Marlina, kedua orangtuaku yang sangat aku cintai dan sayangi, terimakasih telah merawat dan membimbingku hingga sekarang atas cinta dan kasih sayang serta motivasi dan doa yang selalu diberikan kepada anakmu ini. Tanpa kalian aku bukanlah apa-apa. 9. Terimakasih juga kepaa adik-adikku, Ira dan Anya yang secara tidak langsung
turut
membantu
dan
memberikan
dukungan
dalam
menyelesaikan skripsi ini. 10. Untuk Pulung Wibowo, SE terimakasih atas semangatnya serta dukungan untuk penulis, sehingga skripsi ini bisa selesai. 11. Untuk SIB wati, omah, alep, putri, minyi, tiwi, ika, ibon dan nda. Terimakasih selama 5 tahun ini kalian sudah menjadi sahabat bahkan lebih
viii
dari sahabat, suka dan duka kita lewati ebrsama. Semoga kita bisa meraih kesuksesan dimasa depan. Amin. 12. Seluruh teman kelas Sistem Infromasi B 2010, semga kekompakkan kita bisa bertahan hingga selamanya. 13. Terimakasih untuk keluarga serta sahabat-sahabat sepermainan yang juga turut memberikan dukungan kepada penulis. 14. Dan pihak-pihak yang terkait dan berjasa dalam proses pembuatan skripsi ini yang mungkin tidak dapat disebutkan satu persatu tanpa mengurangi rasa hormat terimakasih untuk kalian semua dari penulis. Akhir kata, penulis berharap skripsi ini bermanfaat bagi semua pihak terutama kawan-kawan Sistem Informasi UIN Syarif Hidayatullah Jakarta, baik sebagai karya tulis berupa informasi, perbandingan maupun dasar penelitian materi lebih lanjut.
Jakarta, 29 Juni 2015
Ines Putri Karunia
ix
DAFTAR ISI
HALAMAN SAMPUL....................................................................................
I
HALAMAN JUDUL......................................................................................... ii HALAMAN PERSETUJUAN PEMBIMBING............................................. iii HALAMAN PENGESAHAN UJIAN ............................................................ iv HALAMAN PERNYATAAN.......................................................................... V ABSTRAK .......................................................................................................... Vi KATA PENGANTAR .................................................................................. Vii DAFTAR ISI .................................................................................................... X DAFTAR GAMBAR ..................................................................................... Xiii DAFTAR TABEL ........................................................................................... Xiv
BAB I PENDAHULUAN 1.1 Latar Belakang ........................................................................................
1
1.2 Rumusan Masalah ....................................................................................
6
1.3 Batasan Masalah .......................................................................................
7
1.4 Tujuan Penelitian .......................................................................................
8
1.5 Manfaat Penelitian .....................................................................................
9
1.6 Metode Penelitian .....................................................................................
10
1.6.1 Metode Pengumpulan Data ..............................................................
10
1.6.2 Metode Perancangan .......................................................................
10
1.7 Sistematika Penulisan ...............................................................................
13
x
BAB II LANDASAN TEORI 2.1 Pengertian Perancangan .................................................................................... 15 2.2 Konsep Dasar Sistem Informasi....................................................................... 15 2.2.1 Pengertian Sistem............................................................................... 15 2.2.2 Pengertian Informasi........................................................................
16
2.2.2.1 Kualitas Informasi................................................................ 17 2.2.3 Pengertian Sistem Informasi ............................................................ 17 2.3 Konsep Dasar Enterprise Architecture......................................................... 18 2.3.1 Pengertian Enterprise ...................................................................... 18 2.3.2 Pengertian Architecture.................................................................... 19 2.3.3 Pengertian Enterprise Architecture.................................................. 19 2.4 The Open Group Architecture Framework (TOGAF)............................... 21 2.4.1 TOGAF Architecture Development Method (ADM)....................... 22 2.4.2 Preliminary .....................................................................................
24
2.4.3 Requirement Management...............................................................
26
2.4.2.1 Phase A : Architecture Vision.............................................. 27 2.4.2.2 Phase B : Business Architecture .........................................
28
2.4.2.3 Phase C : Information Systems Architecture.......................
31
2.4.2.4 Phase D : Technology Architecture..................................... 33 2.4.2.5 Phase E : Opportunities and Solution ................................. 35 2.4.2.6 Phase F : Migration Planning.............................................
36
2.4.2.7 Phase G : Implementation Governance............................... 37 2.4.2.8 Phase H : Architecture Change Management.....................
xi
39
2.4.3 Kelebihan dan Kekurangan TOGAF................................................ 40 2.5 Tools Perancangan Arsitektur .................................................................... 41 2.5.1 Principle Catalog............................................................................
41
2.5.2 Flowchart........................................................................................
44
2.5.3 Value Chain ..................................................................................... 48 2.5.4 Stakeholder Map Matrix .................................................................
50
2.5.5 Archimate........................................................................................
51
2.5.6 Rich Picture.....................................................................................
52
2.5.7 Data Dissemination Diagram..........................................................
53
2.5.8 Unified Modelling Laguage (UML) ............................................... 55 2.5.8.1 Sejarah UML.......................................................................
63
2.5.9 Principle Catalog ............................................................................ 64 2.5.10 Technology Portofolio Catalog ....................................................
65
2.5.11 Communication Engineering Diagram ........................................
66
2.5.13 Matriks Analisis Gap.....................................................................
69
2.6 Metode Pengembangan Sistem rapid Application Development (RAD)..
69
2.6.1 Perencanaan Syarat (Requirement Planning)..................................
71
2.6.2 Proses Desain (Design Project).......................................................
72
2.6.3 Implementasi (Implementation).......................................................
73
2.7 Penelitian Sejenis....................................................................................... 73
BAB III METODOLOGI PENELITIAN 3.1 Metode Pengumpulan Data ...................................................................
47
3.1.1 Metode Observasi ...........................................................................
47
xii
3.1.2 Metode Wawancara ......................................................................... 48 3.1.3 Metode Studi Pustaka ...................................................................... 50 3.1.4 Metode Studi Literatur .................................................................... 50 3.2 Metode Perancangan Enterprise Architecture ........................................... 55 3.2.1 Tahapan TOGAF.............................................................................. 55 3.2.2 Alasan Penulis Menggunakan TOGAF............................................ 60 3.3 Kerangka Berpikir Penelitian.....................................................................
61
BAB IV PERANCANGAN ENTERPRISE ARCHITECTURE 4.1 Preliminary Phase.....................................................................................
91
4.1.1 Prinsip-prinsip Perancangan Enterprise Architecture......................
92
4.1.2 Identifikasi 5W+1H........................................................................
96
4.2 Requirement Management........................................................................ 98 4.2.1 Kondisi Sistem Berjalan...................................................................
98
4.2.2 Issue Organisasi................................................................................ 110 4.2.3 Solusi Aktivitas................................................................................. 113 4.2.4 Data Inventaris Sarana dan Prasarana Pendukung TIK................... 115 4.3 Phase A : Architecture Vision................................................................... 115 4.3.1 Profil Instansi................................................................................... 115 4.3.2 Visi dan Misi Instansi.....................................................................
116
4.3.3 Struktur Organisasi dan Tupoksi DTKBDP...................................
117
4.3.4 Analisis Value Chain......................................................................
121
4.3.5 Struktur Organisasi Usulan............................................................
128
4.3.6 Pelatihan yang Diusulkan...............................................................
131
xiii
4.3.7 Hubungan Stakeholder dengan Aktivitas Organisasi...................... 133 4.4Phase B: Business Architecture................................................................ 136 4.4.1 Pemetaan Layanan Bisnis, Proses Bisnis, dan Fungsi Bisnis di DTKBDP.................................................................................................... 136 4.4.2 Rancangan Architecture Business.................................................... 145 4.5Phase C: Information System Application................................................. 154 4.5.1 Application Architecture.................................................................. 154 4.5.5.1 Arsitektur Aplikasi Permohonan Rekomendasi IMB........... 158 4.5.5.2 Arsitektur Aplikasi Rekomendasi SLF................................. 160 4.5.5.3 Arsitektur Aplikasi SPK Lelang........................................... 161 4.5.5.4 Arsitektur Aplikasi Progress Bangunan............................... 163 4.5.5.5 Arsitektur Aplikasi E-inventaris........................................... 164 4.5.5.6 Arsitektur Aplikasi E-keuangan........................................... 165 4.5.2 Data Architecture............................................................................. 166 4.5.2.1 Data Dissemination Diagram................................................ 167 4.5.2.2 Class Diagram....................................................................... 168 4.6Phase D: Technology Architecture............................................................. 174 4.6.1 Infrastruktur Jaringan....................................................................... 174 4.6.2 Platform Teknologi........................................................................... 178 4.6.3 Konfigurasi Hardware dan Software............................................... 180 4.6.4 Technolgy Portofolio Catalog........................................................... 182 4.7Phase E: Opportunities and Solution......................................................... 183 4.7.1 Analisis Gap..................................................................................... 183 4.8Phase E: Migration Planning.................................................................... 194 4.8.1 Urutan Implementasi........................................................................ 194
xiv
4.8.2 Roadmaps......................................................................................... 198 4.8.2.1 Penjelasan Roadmaps........................................................... 199
BAB V PENUTUP 5.1 Kesimpulan................................................................................................ 203 5.2Saran........................................................................................................... 204
DAFTAR PUSTAKA LAMPIRAN-LAMPIRAN
xv
Daftar Gambar Gambar 2.1
ADM Process (The open Group, 2009).................................. 23
Gambar 2.2
Diagram Value chain (Porter, 1985).....................................
Gambar 2.3
Contoh Rich Picure................................................................ 52
Gambar 2.4
Data Dissemination Diagram................................................. 54
Gambar 2.5
Contoh Model Use Case Diagram........................................
59
Gambar 2.6
Contoh Model Class Diagram...........................................
62
Gambar 2.7
Contoh Communication Engineering Diagram....................
67
Gambar 2.8
Platform Decomposition Diagram......................................... 68
Gambar 2.9
Fase Rapid Application Development (RAD)....................... 71
Gambar 3.1
Kerangka Penelitian..............................................................
89
Gambar 4.1
Sistem Berjalan.................................................................
99
Gambar 4.2
Flowchart Sistem Berjalan Level 0...................................
102
Gambar 4.3
Flowchart Sistem Berjalan Bagian Rekomendasi IMB......... 104
Gambar 4.4
Flowchart Sistem Berjalan Bagian Rekomendasi SLF.......... 105
Gambar 4.5
Flowchart Sistem Berjalan Bagian Pendataan Hasil
49
Musrembang......................................................................... 106 Gambar 4.6
Flowchart Sistem Berjalan Bagian Design........................... 107
Gambar 4.7
Flowchart Sistem Berjalan Bagian Progress Bangunan......
Gambar 4.8
Flowchart Sistem Berjalan Bagian Keuangan...................... 109
Gambar 4.9
Flowchart Sistem Berjalan Bagian Inventaris.....................
Gambar 4.10
Struktur Organisasi DTKBDP................................................ 117
Gambar 4.11
Value Chain............................................................................ 122
Gambar 4.12
Struktur Organisasi Usulan DTKBDP.................................... 128
Gambar 4.13
Tree Diagram Pemetaan Layanan, Proses Bisnis dan Fungsi
108
110
Bisnis DTKBDP............................................................................... 138 Gambar 4.14
Layanan Bisnis di DTKBDP................................................. 139
Gambar 4.15
Proses Bisnis Pada Layanan IMB DTKBDP......................... 139
Gambar 4.16
Proses Bisnis Pada Layanan Pembangunan DTKBDP.......... 140
xvi
Gambar 4.17
Fungsi Bisnis pada Proses Bisnis Pendaftaran.................... 140
Gambar 4.18
Fungsi Bisnis pada Proses Bisnis Persidangan..................... 141
Gambar 4.19
Fungsi Bisnis pada Proses Bisnis Verifikasi Berkas SLF..... 142
Gambar 4.20
Fungsi Bisnis pada Proses Bisnis Pendataan....................... 142
Gambar 4.21
Fungsi Bisnis pada Proses Bisnis Design.............................. 143
Gambar 4.22
Fungsi Bisnis pada Proses Bisnis Progress Bangunan......... 144
Gambar 4.23
Solusi Arsitektur Bisnis.......................................................... 147
Gambar 4.24
Solusi Arsitektur Bisnis Rekomendasi IMB&SLF..................148
Gambar 4.25
Solusi Arsitektur Bisnis SPK Lelang........................................149
Gambar 4.26
Solusi Arsitektur Bisnis Solusi Bisnis Progress Bangunan...151
Gambar 4.27
Solusi Arsitektur Bisnis E-inventaris...................................... 152
Gambar 4.28
Solusi Arsitektur Bisnis E-keuangan....................................... 153
Gambar 4.29
Arsitektur Aplikasi................................................................. 157
Gambar 4.30
Arsitektur Aplikasi Permohonan Rekomendasi IMB............. 158
Gambar 4.31
Arsitektur Aplikasi Rekomendasi SLF................................
160
Gambar 4.32
Arsitektur Aplikasi SPK Lelang.........................................
161
Gambar 4.33
Arsitektur Aplikasi Progress Bangunan................................ 163
Gambar 4.34
Arsitektur Aplikasi E-inventaris........................................... 164
Gambar 4.35
Arsitektur Aplikasi E-keuangan........................................... 165
Gambar 4.36
Data Dissemination Diagram.............................................
Gambar 4.37
Arsitektur Data Aplikasi IMB dan SLF................................ 169
Gambar 4.38
Arsitektur Data Aplikasi SPK Lelang................................... 170
Gambar 4.39
Arsitektur Data Aplikasi Progress Bangunan........................ 171
Gambar 4.40
Arsitektur Data Aplikasi E-inventaris.................................. 172
Gambar 4.41
Arsitektur Data Aplikasi E-keuangan................................... 173
Gambar 4.42
Arsitektur Jaringan Awal Keseluruhan DTKBDP................ 176
Gambar 4.43
Arsitektur Jaringan Usulan Keseluruhan DTKBDP.............. 177
Gambar 4.44
Platform Teknologi..............................................................
Gambar 4.45
Roadmap Aplikasi................................................................. 198
xvii
167
178
DAFTAR TABEL
Tabel 2.1
Contoh Principle Catalog..............................................................................
41
Tabel 2.2
Simbol Penghubung Flowchart......................................................................
45
Tabel 2.3
Simbol Proses Flowchart...............................................................................
46
Tabel 2.4
Simbol Input-Output......................................................................................
47
Tabel 2.5
Contoh Stakeholder Map Matrix....................................................................
50
Tabel 2.6
Daftar Simbol Use Case Diagram.................................................................
57
Tabel 2.7
Daftar Simbol Class Diagram........................................................................
61
Tabel 2.8
Principle Catalog...........................................................................................
64
Tabel 2.9
Technology Portofolio Catalog......................................................................
66
Tabel 3.1
Perbandingan Penelitian Sejenis....................................................................
79
Tabel 3.2
Daftar Simbol Kerangka Penelitian................................................................
90
Tabel 4.1
Principle Catalog...........................................................................................
94
Tabel 4.2
5W+1H...........................................................................................................
96
Tabel 4.3
Permasalahan dalam Aktivitas Organisasi.....................................................
111
Tabel 4.4
Solusi Aktivitas..............................................................................................
113
Tabel 4.5
data Inventaris Sarana dan Prasarana Pendukung TIK..................................
115
Tabel 4.6
Target Value Chain........................................................................................
126
Tabel 4.7
Daftar Pelatihan Usulan.................................................................................
131
Tabel 4.8
Stakeholder Map Matrix................................................................................
133
Tabel 4.9
Penjelasan Keterlibatan Stakeholder di Setiap Aktivitas...............................
134
Tabel 4.10 Pemetaan Kendala..........................................................................................
145
Tabel 411
Application Portofolio.................................................................................... 154
xviii
Tabel 4.12 Konfigurasi Hardware...................................................................................
180
Tabel 4.13 Konfigurasi Software.....................................................................................
181
Tabel 4.14 Technology Portofolio Catalog...................................................................... 182 Tabel 4.15 Analisis Gap Arsitektur Bisnis IMB dan SLF...............................................
186
Tabel 4.16 Analisis Gap Arsitektur Bisnis SPK Lelang..................................................
187
Tabel 4.17 Analisis Gap Arsitektur Bisnis Progress Bangunan......................................
188
Tabel 4.18 Analisis Gap Arsitektur Bisnis E-keuangan..................................................
189
Tabel 4.19 Analisis Gap Arsitektur Bisnis E-inventaris..................................................
189
Tabel 4.20 Analisis Gap Arsitektur Aplikasi DTKBDP..................................................
190
Tabel 4.21 Analisis Gap Arsitektur Data DTKBDP........................................................
191
Tabel 2.22 Analisis Gap Arsitektur Bisnis Teknologi DTKBDP....................................
192
Tabel 2.23 Analisis Gap Matriks Aplikasi Terhadap Data..............................................
194
Tabel 2.24 Front Office System........................................................................................ 195 Tabel 4.25 Back Office System.........................................................................................
195
Tabel 4.26 Urutan Implementasi......................................................................................
197
Tabel 4.27 Roadmap Aplikasi Tahun 2015...................................................................... 199 Tabel 4.28 Roadmap Aplikasi Tahun 2016...................................................................... 201 Tabel 4.29 Roadmap Aplikasi Tahun 2017...................................................................... 202
xix
Simbol Use Case Diagram (Sugiarti, 2013)
Simbol Use Case
Deskripsi Fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor; biasanya dinyatakan dengan menggunakan kata kerja di awal frase nama use case.
Nama Use Case
Orang,
proses,
atau
sistem
lain
yang
berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri; biasanya dinyatakan menggunakan kata benda di awal frase nama aktor. Asosiasi (association)
Komunikasi antara aktor dan use case yang berpartisipasi pada use case.
Ekstensi (extend)
Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan dapat berdiri
<<extend>>
sendiri
walau
tanpa
tambahan; biasanya use case
use
case
tambahan
memiliki nama depan yang sama dengan use case yang ditambahkan.
xx
Generalisasi (generalization)
Hubungan
generalisasi
dan
spesialisasi
(umum – khusus) antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari lainnya. Menggunakan (include) <
>
Relasi use case tambahan ke sebuah use case dimana
use
case
yang
ditambahkan
memerlukan use case ini untuk menjalankan fungsinya atau sebagai syarat dijalankan use case ini. Dua sudut pandang mengenai include di use case, yaitu : 1. Include berarti use case yang ditambahkan akan selalu dipanggil saat use case tambahan dijalankan. 2. Include berarti use case yang tambahan akan selalu melakukan pengecekan apakah use case yang ditambahkan telah dijalankan sebelum use case tambahan dijalankan. Kedua
sudut
digunakan
pandang
salah
satu
tersebut atau
dapat
keduanya,
tergantung pada pertimbangan dan sudut pandang yang dibutuhkan.
xxi
Simbol Use Case Diagram (Sugiarti, 2013)
Simbol
Deskripsi
Kelas
Kelas pada struktur sistem.
nama_kelas +Attribute +Operation()
Antarmuka (interface)
Sama seperti
konsep
interface
dalam pemrograman berorientasi objek. Asosiasi (association)
Relasi antar kelas dengan makna umum; biasanya disertai dengan multiplicity.
Asosiasi berarah (directed
Relasi antar kelas dengan makna
association)
kelas yang satu digunakan oleh kelas yang lain; biasanya disertai dengan multiplicity.
Generalisasi (generalization)
Relasi antar kelas dengan makna generalisasi – spesialisasi (umum – khusus).
Kebergantungan (depedency)
Relasi antar kelas dengan makna
xxii
kebergantungan antar kelas.
Simbol Business Service, Business Process, Business Function (The Open Group, 2009) Simbol
Keterangan
Business Service
Layanan yang memenuhi kebutuhan bisnis untuk customer internal atau eksternal organisasi.
Business Process
Elemen tindakan berdasarkan pada urutan aktivitas. Proses bisnis dimaksudkan untuk menetapkan sekumpulan produk atau layanan bisnis.
Business Function
Elemen tindakan berdasarkan pada sekumpulan kriteria yang dipilih (kriteria yang dibutuhkan sumber daya bisnis).
Triggering
Triggering menjelaskan tentang hubungan sebab-akibat antara proses-proses.
Flow
Flow menjelaskan tentang pertukaran informasi diantara proses bisnis dan fungsi bisnis.
xxiii
i
BAB I PENDAHULUAN
1.1
Latar Belakang
Peranan sistem informasi dan teknologi dalam menjalankan proses bisnis di era informasi saat ini sangat diperlukan. Teknologi merupakan salah satu solusi terpenting untuk mengatasi dan membantu manusia dalam kehidupannya. Semakin tinggi kebutuhan manusia akan teknologi, semakin tinggi pula kualitas teknologi yang diharapkan. Perkembangan teknologi informasi dalam dunia bisnis, ini akan menuntut organisasi untuk melakukan perubahan dengan diterapkannya suatu perencanaan bisnis yang matang agar dapat berjalan sesuai yang diharapkan perusahaan. Agar suatu perencanaan bisnis bisa berjalan dengan baik, maka diperlukan sebuah tool yang dapat digunakan untuk menyediakan struktur
dasar organisasi pada
perusahaan secara menyeluruh serta dapat menggambarkan hubungan antar aspekaspek yang ada didalamnya. Tool yang dimaksudkan dalam hal ini adalah Enterprise Architecture (EA). Dinas Tata Kota, Bangunan dan Permukiman (DTKBDP) Kota Tangerang Selatan terbentuk berdasarkan peraturan walikota No.59 Tahun 2009. Dinas Tata Kota, bangunan dan Permukiman merupakan instansi milik pemerintah dibawah pimpinan pemerintahan daerah kota Tangerang Selatan. Dinas Tata Kota, Bangunan dan Permukiman mempunyai peran penting dalam melaksanakan
1
2
kegiatan pembangunan atau pemeliharaan sarana dan prasarana pemerintahan atau non pemerintahan yang berada di kota Tanggerang Selatan, serta mempunyai tanggung jawab dalam memberikan pelayanan perizinan pada setiap bangunan atau permukiman yang akan dibangun disekitar daerah kota Tangerang Selatan. Dalam menjalankan tupoksi tersebut, Dinas Tata Kota, Bangunan dan Permukiman dituntut untuk menyiapkan kebutuhan-kebutuhan yang diperlukan, salah satunya adalah infrastruktur SI/TI untuk membantu mencapai tujuan yang telah ditetapkan. Namun dalam pelaksanaannya Dinas Tata Kota, Bangunan dan Permukiman belum menggunakan perencanaan
Enterprise Architecture.
Sehingga proses bisnis tersebut belum berjalan secara optimal. Dinas Tata Kota, Bangunan dan Permukiman mempunyai lebih dari satu perangkat komputer yang dimiliki oleh setiap bagian di dalam organisasi, namun investasi tersebut dirasa belum mampu menunjang proses bisnis seperti yang terjadi pada pelayanan proses bisnis untuk pengajuan permohonan perizinan mendirikan bangunan (IMB) di daerah Tangerang Selatan yang masih menggunakan ms.office, dikarenakan mereka belum mempunyai suatu aplikasi khusus untuk melaksanakan kegiatan pelayanan pada IMB. Selain menyediakan pelayanan IMB, DTKBDP juga melaksanakan pembangunan dan perbaikan di Tangerang Selatan, namun dalam pelaksanaan proses pencatatan pembangunan, pemeliharaan bangunan, dana untuk proses pembangunan dan perbaikan bangunan, serta pada proses pelaksanaan lelang juga masih menggunakan ms.office, pada pelaksanaan lelang DTKBDP masih harus mencari sendiri kontraktor yang nantinya akan membangun bangunan
3
tersebut. Serta untuk mengetahui progress bangunan, pencatatan BMN (Barang Milik Negara) dan keuangan, DTKBDP belum mempunyai sistem khusus, sehingga pencatatan tersebut dilakukan hanya menggunakan ms.office. Hal ini juga disebabkan oleh tidak adanya database management system yang dimiliki. Maka dari itu diperlukan suatu perancangan arsitektur TI dalam Dinas Tata Kota, Bangunan
dan
Permukiman
Kota
Tangerang
Selatan
untuk
dapat
mengintegrasikan sistem informasi dan database dalam DTKBP Tangsel. EA merupakan suatu perencanaan, perancangan dan pengelolaan infrastruktur SI/TI, serta mampu mengintegrasikan SI/TI didalam suatu arsitektur. Menurut The Open Group (2009), dapat disimpulkan Enterprise Architechture
adalah blueprint organisasi yang menentukan bisnis, informasi, dan teknologi yang digunakan agar tercapai misi organisasi. Enterprise Architecture berfungsi sebagai penyedia cetak biru atau kerangka dasar (blueprint) untuk sistem dan selama proses berlangsungnya proyek pengembangan sistem tersebut. EA dikonsentrasikan pada infrastruktur yang meliputi hardware, software dan network untuk dapat bekerja secara bersama dengan misi, sasaran, dan tujuan organisasi untuk menjalankan proses bisnis organisasi dengan didukung oleh Teknologi Informasi. Berbagai macam paradigma dan metode dapat digunakan dalam perancangan enterprise architecture diantaranya adalah Zachman, TOGAF, FEA dan gartner. The Open Group Architecture Framework (TOGAF) merupakan salah satu acuan kerangka kerja untuk melakukan pengembangan, penerapan, dan pengelolaan
arsitektur
di
bidang
Teknologi
Informasi
pada
sebuah
4
organisasi/perusahaan. TOGAF berupa panduan tahapan-tahapan dan prinsipprinsip yang memberikan keleluasaan dalam memilih teknik pemodelan yang digunakan dan merupakan panduan gabungan dari berbagai framework pengembangan arsitektur (FEAF, TEAF, DoDAF, dsb). “TOGAF memberikan metode yang detail mengenai bagaimana membangun, mengelola dan mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan Architecture Development Method (ADM) (Surendro, 2009)”. Menjelaskan bagaimana menemukan sebuah arsitektur perusahaan/organisasi secara khusus berdasarkan kebutuhan bisnisnya dan proses. Selain itu TOGAF memiliki Resource Base yang memberikan sumber-sumber informasi berupa guidelines, templates, checklists, latar belakang informasi dan detil material pendukung yang membantu arsitek di dalam penggunaan ADM. Resource Base juga menyediakan banyak material referensi. Berbeda dengan TOGAF, framework Zachman adalah framework EA yang menyediakan enam sudut pandang yang dijelaskan dalam sebuah cube. Keenam sudut pandang tersebut adalah planner, owner, designer, builder, subcontractor, builder, dan functioning. Sedangkan FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan mengimplementasikan lingkungan operasional di top-level dan mendukung implementasi dari sistem TI, namun FEAF tidak memiliki proses arsitektur yang detil dan tidak ada standarisasinya.
5
Terdapat beberapa penelitian di bidang EA menggunakan TOGAF yang mendukung kesiapan dan kemampuan menggunakan TI, diantaranya oleh Vivi Vydiani (2013) yang membuat Perancangan Model enterprise Architecture Dengan Menggunakan TOGAF ADM Pada PT. SATYA KARYA UTAMA, Riffa Ruffaida (2012), Perancangan Arsitektur Teknologi Informasi Rumah Sakit dengan TOGAF (The Open Group Architecture Framework), dan Syafrizal (2013), Perencanaan Arsitektur Enterprise Menggunakan Kerangka Kerja Togaf Pada Kantor Pelayanan Umum dan Perizinan Kabupaten Solok Selatan). Ketiga penelitian ini dilakukan untuk menganalisis kebutuhan dari infrastruktur teknologi informasi secara menyeluruh dan terpadu untuk mencapai visi dan misi lembaga menggunakan TOGAF. Dengan permasalahan dan fakta yang sudah diuraikan diatas, maka penulis tertarik untuk membuat perancangan Enterprise Architecture dalam perencanaan SI/TI di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan dengan menggunakan framework TOGAF ADM (The Open Group Architecture Framework). Oleh sebab itu, penulis mengajukan penelitian sesuai dengan latar belakang yang telah diuraikan diatas dengan judul “PERANCANGAN ENTERPRISE ARCHITECTURE MENGGUNAKAN TOGAF ARCHITECTURE DEVELOPMENT METHOD
(STUDI KASUS
DINAS TATA KOTA, BANGUNAN DAN PERMUKIMAN KOTA TANGERANG SELATAN)”.
6
1.2
Rumusan Masalah Berdasarkan latar belakang yang sudah dipaparkan di atas, maka dapat
diidentifikasi masalah sebagai berikut. 1) Dinas Tata Kota, Bangunan dan Permukiman belum memiliki arsitektur sistem informasi untuk menyelaraskan strategis SI/TI dengan strategi bisnis. 2) DTKBP belum memiliki arsitektur sistem informasi untuk merancang proses integrasi aplikasi DTKBP dan sistem basis data. 3) DTKBP belum memiliki arsitektur bisnis untuk merancang kegiatan di dalam DTKBP yang meliputi, pelayanan permohonan perizinan serta proses pembangunan sarana dan prasarana pemerintahan dan non pemerintahan serta administrasi. 4) DKTBP belum memiliki arsitektur teknologi yang berguna untuk kepentingan investasi hardware, software, dan networking. Dari masalah yang telah diidentifikasi, maka dapat dirumuskan masalah “Bagaimana
membuat
perancangan
enterprise
architecture
untuk
mengoptimalkan kegiatan dan layanan di dalam Dinas Tata Kota, Bangunan dan Permukiman agar dapat berjalan dengan efektif dan efisien?”
7
1.3
Batasan Masalah Berdasarkan dari rumusan masalah di atas, maka batasan dari penelitian
ini adalah : 1) Penelitian ini dilakukan di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan pada keseluruhan divisi organisasi. 2) Bisnis proses yang dilakukan hanya membahas proses tahapan awal melakukan permohonan mendirikan pembangunan, survei lokasi proyek sampai mendapatkan surat perizinan pembangunan. Serta untuk internal DTKBDP sampai pada tahap proses pembangunan dan perbaikan sarana dan prasaran di Tangerang Selatan. Dan tidak membahas bagian SDM. 3) Framework yang digunakan pada penelitian ini adalah The Open Group Framework (TOGAF) dengan menggunakan Architecture Development Method (ADM) sebagai metode pengembangan arsitektur. Penelitian ini dibatasi hanya pada fase preliminary, arsitektur visi, arsitektur bisnis, arsitektur sistem informasi, arsitektur teknologi, peluang dan solusi, serta perencanaan migrasi. Penelitian ini tidak membahas fase implementasi dan manajemen perubahan arsitektur. 4) Tools yang digunakan dalam penelitian ini untuk menggambarkan model arsitektur, yaitu UML (Unified Model Language), Principle Catalog, Technology Portfolio Catalog, Communication Engineering Diagram, Matrix Gap Analysis dan Analisis Value Chain. Diagram UML yang digunakan, yaitu Use Case Diagram, Activity Diagram, dan Class Diagram.
8
1.4
Tujuan Penelitian Tujuan umum dari penelitian ini adalah menghasilkan rancangan
Enterprise Architecture pada Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Sedangkan tujuan khusus dari penelitian ini menghasilkan: 1.
Rancangan suatu kerangka kerja berdasarkan konsep EA dengan menggunakan metode TOGAF Architecture Development Method.
2.
Analisis kebutuhan dari EA secara menyeluruh dan terpadu yang dibutuhkan oleh perusahaan.
3.
Rancangan Arsitektur Visi Perusahaan untuk melakukan identifikasi dan memprioritaskan komponen dari arsitektur saat ini.
4.
Rancangan Arsitektur Bisnis Perusahaan yang menggambarkan strategi produk dan layanan serta aspek lingkungan bisnis (organisasi, fungsi, proses, dan informasi) berdasarkan pada prinsip bisnis, tujuan bisnis, dan penggerak strategi.
5.
Rancangan Arsitektur Sistem Informasi yang terdiri atas arsitektur data yang menetapkan tipe dan sumber utama data yang diperlukan untuk mendukung proses bisnis dan arsitektur aplikasi yang menetapkan jenis sistem aplikasi utama yang dibutuhkan untuk mengolah data dan mendukung bisnis.
6.
Rancangan Arsitektur teknologi yang memetakan komponen aplikasi yang telah ditetapkan pada fase arsitektur aplikasi ke dalam satu set komponen teknologi yang mewakili komponen software dan hardware.
9
7.
Rancangan Peluang dan Solusi untuk menghasilkan sebuah implementasi keseluruhan dan strategis migrasi dan sebuah rencana implementasi.
8.
Rancangan Perencanaan Migrasi untuk memilih proyek implementasi yang bervariasi menjadi urutan prioritas.
1.5
Manfaat Penelitian Diharapkan dengan adanya penelitian ini dapat memberikan manfaat
berikut : 1. Memberikan gambaran tentang keselarasan proses bisnis dengan teknologi untuk pengembangan arsitektur SI/TI pada Dinas Tata Kota, Bangunan dan Permukiman. 2. Memberikan blueprint sebagai landasan untuk pengembangan SI/TI. 3. Memberikan Architecture
pemahaman
terhadap
Development
Method
penggunaan dalam
metode
merancang
TOGAF Enterprise
Architecture. 4. Sebagai referensi utuk penelitian selanjutnya dibidang kajian Enterprise Architecture.
10
1.6
Metodologi Penelitian
1.6.1
Metode Pengumpulan Data Metodologi ini terdiri dari dua macam, yaitu metodologi pengumpulan
data dan perancangan Enterprise Architecture. Metodologi pengumpulan data-data yang telah dilakukan penulis adalah sebagai berikut : 1. Observasi dengan cara mengamati langsung objek untuk mendapatkan data responden (Hartono, 2008). 2. Wawancara, merupakan komunikasi dua arah untuk mendapatkan data responden (Hartono, 2008). 3. Studi Pustaka, dengan mencari sumber data sekunder yang akan mendukung penelitian (Nazir, 2005).
1.6.2
Metode Perancangan Untuk
metodologi
perancangan
Enterprise
Architecture
adalah
menggunakan metodologi TOGAF ADM. Ada 7 tahapan yang akan dilakukan pada skripsi ini, yaitu:
1.
Preliminary Phase Fase
preliminary
merupakan
tahap
awal
untuk
persiapan
perencanaan arsitektur enterprise. Tahapan ini dilakukan agar proses pemodelan
arsitektur
dapat
terarah
dengan
baik.
Tahapan
ini
menghasilkan prinsip-prinsip arsitektur yang merupakan bagian dari
11
kebijakan teknologi informasi perusahaan yang akan mempengaruhi keseluruhan proses desain dan untuk meyakinkan setiap orang yang terlibat di dalamnya bahwa pendekatan ini berkomitmen untuk kesuksesan proses arsitektur.
2.
Phase A : Architecture Vision Fase A bertujuan untuk menciptakan keselarasan pandangan
bagaimana pentingnya EA untuk pencapaian tujuan perusahaan dan menentukan lingkup dari arsitektur yang akan dikembangkan dan memetakan strategi. Visi arsitektur adalah kesempatan utama untuk menjual keuntungan dari pengembangan yang disarankan kepada pembuat keputusan enterprise sehingga memungkinkan tujuan bisnis tanggap kepada penggerak strategis, sesuai dengan prinsip dan mencapai maksud dan tujuan stakeholder, klarifikasi tujuan tersebut dan menunjukkan bagaimana tujuan dapat dicapai oleh pengembangan arsitektur yang disarankan.
3.
Phase B : Business Architecture Pada fase B, aspek bisnis dari proyek akan diperiksa. Fase ini
melibatkan pemodelan secara ekstensif dari arsitektur saat ini menggunakan alat bantu seperti model business use case.
12
4.
Phase C : Information System Architecture Fase C berfokus pada arsitektur data dan arsitektur aplikasi. Pada
arsitektur data, harus ditentukan tipe dan sumber data utama yang diperlukan untuk mendukung bisnis. Pada arsitektur aplikasi, ditentukan jenis aplikasi penting untuk memproses data dan mendukung bisnis. Kemudian, dibuat matriks dari aplikasi saat ini dan arsitektur aplikasi tujuan, melakukan analisis gap dan melakukan korelasi fungsi bisnis dengan aplikasi tujuan.
5.
Phase D : Technology Architecture Fase D berupa untuk memetakan komponen aplikasi yang
didefinisikan dalam arsitektur aplikasi menjadi satu set komponen teknologi yang mewakili komponen software, hardware, dan jaringan, dengan cara membeli ke pihak luar atau dikonfigurasi sendiri oleh perusahaan ke dalam platform teknologi.
6.
Phase E : Opportunities dan Solutions Pada fase E akan dievaluasi model yang telah dibangun untuk
arsitektur saat ini dan target. Identifikasi proyek utama akan dilaksanakan untuk mengimplementasikan arsitektur tujuan dan klasifikasi sebagai pengembangan baru atau penggunaan kembali sistem yang sudah ada.
13
7.
Phase F : Migration Planning Pada fase F akan dilakukan analisis risiko dan biaya. Tujuan fase ini
untuk memilih proyek implementasi yang bervariasi menjadi urutan prioritas. Aktivitasnya mencakup penaksiran ketergantungan, biaya, manfaat dari proyek migrasi yang bervariasi.
1.2
Sistematika Penulisan Dalam penyusunan skripsi ini, dilakukan pembahasan dengan membagi
kedalam 5 bab. Pembagian tersebut dapat dijelaskan dengan struktur sebagai berikut : BAB I
PENDAHULUAN Bab ini menguraikan tentang latar belakang masalah, rumusan masalah, batasan penelitian,
metode
masalah, tujuan dan manfaat
penelitian
yang
digunakan
dan
sistematika penulisan. BAB II
LANDASAN TEORI Dalam bab ini akan diuraikan mengenai landasan teori yang digunakan dalam pembahasan penulisan skripsi ini dan sumber landasan teori tersebut.
BAB III
METODOLOGI PENELITIAN Pada bab ini berisi uraian metode penelitian yang mencakup
metode
pengumpulan
data
dan
metode
14
perancangan pada Dinas Tata Kota, Bangunan dan Permukiman. BAB IV
PERANCANGAN ENTERPRISE ARCHITECTURE Bab ini menjelaskan perancangan Enterprise Architecture Dinas Tata Kota, Bangunan dan Permukiman menggunakan TOGAF berdasarkan analisis dari data data yang telah diperoleh.
BAB V
PENUTUP Bab ini berisikan beberapa kesimpulan dan saran serta rekomendasi atas penelitian yang telah dilakukan.
i
15
BAB II LANDASAN TEORI
2.1
Pengertian Perancangan Perancangan adalah sebuah proses untuk mendefinisikan sesuatu yang akan
dikerjakan dengan menggunakan teknik yang bervariasi serta di dalamnya melibatkan deskripsi mengenai arsitektur serta detail komponen dan juga keterbatasan yang akan dialami dalam proses pengerjaannya (Rizky, 2011). Proses perancangan memiliki tiga unsur penting yakni : pengetahuan mengenai teknik perancangan, kebutuhan sistem, serta kendala yang mungkin terjadi (Rizky, 2011).
2.2 2.2.1
Konsep Dasar Sistem Informasi Pengertian Sistem Menurut Jogiyanto (2005), “Sistem adalah suatu kumpulan komponen
yang saling berhubungan satu dengan yang lainnya untuk mencapai sebuah tujuan tertentu”. Menurut Agus Mulyanto (2009), “Sistem adalah kumpulan elemenelemen yang berinteraksi untuk mencapai suatu tujuan tertentu sebagai satu kesatuan”. Selain itu ada pengertian lain tentang sistem menurut Sanyoto Gondodiyoto (2007), “Sistem adalah kumpulan elemen-elemen atau sumber daya yang saling berkaitan secara terpadu, dan bertujuan untuk mencapai tujuan tertentu”.
15
16
Dari beberapa pengertian diatas, dapat disimpulkan bahwa sistem adalah suatu jaringan kerja dari prosedur-prosedur yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau menyelesaikan suatu sasaran tertentu.
2.2.2
Pengertian Informasi Definisi
informasi
menurut
Agus
Mulyanto
(2009),
“Informasi
merupakan pengetahuan dari hasil pengolahan data-data yang berhubungan menjadi sebuah kesimpulan, pengolahan data yang dibentuk agar berguna bagi pemakainya”. Menurut Sanyoto Gondodiyoto (2007), “Informasi adalah merupakan data yang sudah diolah menjadi bentuk yang lebih berguna dan lebih berarti (bermanfaat) bagi penerimanya, menggambarkan suatu kejadian dan kesatuan nyata yang dapat dipahami dan dapat digunakan untuk pengambilan keputusan, sekarang maupun untuk masa depan”. Dari beberapa
pengertian diatas,
dapat
disimpulakan informasi
merupakan hasil dari pengolahan data. Sedangkan data merupakan kenyataan yang menggambarkan suatu kejadian-kejadian yang nyata. Data sering kali disebut sebagai bahan mentah dari informasi. Melalui proses transformasi, data dibuat menjadi bermakna.
17
2.2.2.1
Kualitas Informasi Menurut Jogiyanto (2005) untuk dapat berguna, maka informasi harus
didukung oleh tiga pilar sebagai berikut: 1. Relevan (Relevance), informasi harus mempunyai manfaat bagi pemakainya. 2. Tepat Waktu (Timeliness), informasi harus tepat waktu datang kepada penerima, dan tidak boleh terlambat. 3. Akurat (Accurate), informasi harus benar-benar nyata, dan tidak boleh terjadi kesalahan-kesalahan yang nantinya akan menyesatkan penerima informasi. Informasi yang disampaikan harus jelas maksud dan tujuannya.
2.2.3
Pengertian Sistem Informasi Menurut Agus Mulyanto (2009), “Sistem informasi merupakan suatu
komponen yang terdiri dari manusia, teknologi informasi, dan prosedur kerja yang memproses, menyimpan, menganalisis, dan menyebarkan informasi untuk mencapai suatu tujuan”. Adapula pengertian lain tentang sistem informasi menurut Jogiyanto (2005), “Sistem informasi adalah suatu sistem di dalam suatu organisasi yang merupakan kombinasi dari orang-orang, fasilitas, teknologi, media, prosedurprosedur dan pengendalian yang ditujukan untuk mendapatkan jalur komunikasi penting, memproses tipe transaksi rutin tertentu, memberi sinyal kepada
18
manajemen dan yang lainnya terhadap kejadian-kejadian internal dan eksternal yang penting dan menyediakan suatu dasar informasi untuk pengambilan keputusan yang cerdik.” Dari beberapa pengertian diatas, dapat disimpulkan bahwa sistem Informasi mencakup sejumlah komponen (manusia, komputer, teknologi informasi dan prosedur kerja), ada sesuatu yang diproses yaitu data menjadi informasi, dan dimaksudkan untuk mencapai suatu sasaran atau tujuan.
2.3 2.3.1
Konsep Dasar Enterprise Architecture Pengertian Enterprise Enterprise merupakan kumpulan perusahaan atau organisasi yang
memiliki beberapa tujuan tertentu. Menurut para ahli, enterprise dapat didefinisikan sebagi berikut : 1.
“Enterprise bukan hanya perusahaan (company) yang berorientasi kepada profit saja, tetapi juga bisa berupa organisasi non-profit atau nirlaba. Seperti pemerintah, institusi pendidikan ataupun organisasi amal” (Surendro, 2009).
2. “Enterprise diartikan sebagai semua kumpulan organisasi yang memiliki sekumpulan tujuan. Enterprise dapat merupakan sebuah agen pemerintahan, sebuah korporasi keseluruhan, divisi korporasi, departemen tunggal atau sebuah rantai organisasi yang berhubungan tetapi berjauhan secara geografis” (The Open Group, 2009).
19
Menurut definisi diatas, dapat disimpulkan bahwa enterprise adalah suatu kumpulan perusahaan atau organisasi yang mempunyai tujuan bisnis untuk mencapai tujuan perusahaan/organisasi.
2.3.2
Pengertian Architecture Menurut Surendro (2009), “Architecture merupakan suatu perencanaan
yang diwujudkan dengan model dan gambar dari bagian/komponen dari sesuatu dengan berbagai sudut pandang”. Enterprise Architecture diperlukan karena merupakan sebagai dasar sistem organisasi yang terdiri dari sekumpulan komponen yang memiliki hubungan satu sama lainnya serta memiliki keterhubungan dengan lingkungan sistem, dan memiliki aturan untuk perancangan dan evaluasi (The Open Group, 2009). Architecture pada awalnya hanyalah sebuah prinsip dan istilah yang digunakan untuk membuat bangunan, tetapi didalam konteks teknologi informasi, architecture diperlukan untuk membangun sebuah sistem.
2.3.3 Pengertian Enterprise Architecture Enterprise Architecture merupakan perancangan proses bisnis dan teknologi disetiap organisasi dan perusahaan, dan kemudian diintegrasikan untuk mencapai suatu tujuan tertentu. Menurut Surendro (2009), Enterprise Architecture merupakan kumpulan prinsip, metode, dan model yang bersifat masuk akal yang
20
digunakan untuk mendesain dan merealisasikan sebuah struktur organisasi enterprise, struktur organisasi, sistem informasi dan sistem infrastrukturnya”. Menurut The Open Group (2009) dapat disimpulkan Enterprise Architechture adalah blueprint organisasi yang menentukan bisnis, informasi, dan teknologi yang digunakan agar tercapai misi organisasi. Enterprise Architecture dikonsentrasikan pada infrastruktur yang meliputi hardware, software dan network untuk dapat bekerja secara bersama dengan misi, sasaran, dan tujuan organisasi untuk menjalankan proses bisnis organisasi dengan didukung oleh Teknologi Informasi. Berbagai macam paradigma dan metode dapat digunakan dalam perancangan enterprise architecture diantaranya adalah Zachman, TOGAF, FEAF dan gartner. The Open Group Architecture Framework (TOGAF) merupakan salah satu acuan kerangka kerja untuk melakukan pengembangan, penerapan, dan pengelolaan
arsitektur
di
bidang
Teknologi
Informasi
pada
sebuah
organisasi/perusahaan. TOGAF berupa panduan tahapan-tahapan dan prinsipprinsip yang memberikan keleluasaan dalam memilih teknik pemodelan yang digunakan dan merupakan panduan gabungan dari berbagai framework pengembangan arsitektur (FEAF, TEAF, DoDAF, dsb). “TOGAF memberikan metode yang detail mengenai bagaimana membangun, mengelola dan mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan Architecture Development Method (ADM) (Surendro, 2009)”. Menjelaskan bagaimana menemukan sebuah arsitektur
21
perusahaan/organisasi secara khusus berdasarkan kebutuhan bisnisnya dan proses. Selain itu TOGAF memiliki Resource Base yang memberikan sumber-sumber informasi berupa guidelines, templates, checklists, latar belakang informasi dan detil material pendukung yang membantu arsitek di dalam penggunaan ADM. Resource Base juga menyediakan banyak material referensi. Berbeda dengan TOGAF, framework Zachman adalah framework EA yang menyediakan enam sudut pandang yang dijelaskan dalam sebuah cube. Keenam sudut pandang tersebut adalah planner, owner, designer, builder, subcontractor, builder, dan functioning. Sedangkan FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan mengimplementasikan lingkungan operasional di top-level dan mendukung implementasi dari sistem TI, namun FEAF tidak memiliki proses arsitektur yang detil dan tidak ada standarisasinya.
2.4
The Open Group Architecture Framework (TOGAF) The Open Group Architecture Framework (TOGAF) merupakan sebuah
framework dan sebuah metode untuk mengembangkan data dan melaksanakan Enterprise Architecture. TOGAF memegang peranan penting membantu proses pengembangan arsitektur, memungkinkan pengguna TI membangun solusi berbasis sistem terbuka untuk kebutuhan bisnis mereka.
22
Menurut The Open Group (2009), ada empat jenis arsitektur yang umumnya diterima sebagai bagian dari keseluruhan Enterprise Architecture, yaitu : a.
Business architecture, yaitu mendefinisikan bagaimana proses bisnis untuk mencapai tujuan organisasi.
b.
Data architecture, adalah penggambaran bagaimana penyimpanan, pengelolaan, dan pengaksesan data pada perusahaan.
c.
Application architecture, merupakan pendeskripsian bagaimana suatu aplikasi dirancang dan bagaimana interaksi dengan aplikasi lain.
d.
Technology architecture, yaitu gambaran mengenai infrastruktur perangkat lunak dan perangkat keras yang mendukung aplikasi dan bagaimana interaksinya.
2.4.1
TOGAF Architecture Development Method (ADM) TOGAF Architecture Development Method meyediakan teruji dan
berulang dalam pengembangan arsitektur yang dibutuhkan perusahaan (The Open Group, 2009). ADM merupakan hasil kerjasama generik yang berisikan sekumpulan aktifitas yang mempresentasikan progresi dari setiap fase ADM dan model arsitektur yang digunakan dan dibuat selama tahap pengembangan Enterprise Architecture (Surendro, 2009). Prinsip pengembangan enterprise dengan menggunakan metodelogi TOGAF ADM terdiri dari tiga bagian, yaitu :
23
1.
Prinsip-prinsip enterprise, mendukung keputusan bisnis di seluruh bagian organisasi/perusahaan.
2.
Prinsip-prinsip teknologi informasi, mengarahkan penggunaan sumber
daya
teknologi
informasi
di
seluruh
bagian
arsitektur
proses
organisasi/perusahaan. 3.
Prinsip-prinsip
arsitektur,
mengembangkan
organisasi/perusahaan dan arsitektur implementasinya. Pada prinsip ini dipengaruhi oleh rencana organisasi/perusahaan, strategi, faktor pasar, sistem dan teknologi yang ada dalam organisasi/perusahaan. ADM mempunyai 9 fase seperti gambar berikut :
Gambar 2.1 ADM process ( The Open Group, 2009)
24
2.4.2
Preliminary Fase preliminary
merupakan tahap awal yang merupakan persiapan
arsitektur enterprise. Tahapan ini dilakukan agar proses pemodelan arsitektur dapat terarah dengan baik. Tujuan dari fase preliminary adalah untuk meyakinkan setiap orang yang terlibat didalamnya bahwa pendekatan ini berkomitmen untuk kesuksesan dari setiap arsitektur yang akan dibuat. Pada fase preliminary dilakukan identifikasi “who”, “what”, “why”, “when”, dan “where” dari arsitektur itu sendiri (The Open Group, 2009). 1.
“What” adalah ruang lingkup dari usaha arsitektur.
2.
“Who” adalah siapa yang akan memodelkannya, siapa orang yang bertanggung jawab untuk mengerjakan arsitektur tersebut, di mana mereka akan dialokasikan dan bagaimana peranan mereka.
3.
“How” adalah bagimana mengembangkan Enterprise Architecture, menentukan Framework dan metode yang akan digunakan untuk menangkap informasi.
4.
“When”” adalah kapan tanggal penyelesaian arsitektur.
5.
“Why” adalah mengapa arsitektur ini dibangun, hal ini berhubungan dengan tujuan organisasi yaitu bagaimana arsitektur dapat memenuhi tujuan organisasi.
6.
“Where” adalah menunjukkan lokasi kerja dari organisasi. Memungkinkan organisasi berada di satu bangunan, beberapa kantor
25
atau di sekeliling dunia. Jika semua lokasi organiasi saling terkoneksi maka diperlukan identifikasi terlebih dahulu. Preliminary Phase memiliki input, serta langkah-langkah, dan berupa output sebagai berikut: a. Input 1. Prinsip-prinsip dan tujuan aktivitas. b. Langkah-Langkah 1. Mendefinisikan dan membuat prinsip-prinsip arsitektur. 2. Menentukan ruang lingkup setiap unit-unit inti yang terlibat secara langsung dalam perencanaan strategis sitem informasi. c. Output 1. Prinsip-prinsip perencanaan strategis sistem informasi (principles catalog).
Prinsip-prinsip
tersebut
akan
menjadi
dasar
dalam
pengembangan perencanaan startegis sistem informasi yang akan menghasilkan beberapa arsitektur. Prinsip-prinsip tersebut akan dijelaskan dalam principle catalog. 2. Tabel identifikasi 5W (What, Who, Why, When, Where) + 1H (How), yang nantinya tabel ini akan menjelaskan dan menguraikan apa saja yang akan dilakukan pada objek penelitian, siapa saja yang akan mengerjakan serta bertanggung jawab dengan objek penelitian, bagaimana cara kerja pada objek penelitian, kenapa pekerjaan dalam objek dilakukan dan dimana tempat penelitian tersebut. Dalam
26
penelitian ini, objek penelitian penulis dilakukan di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan (DTKBDP)
2.4.3
Requirement Management Reuqirement Management adalah proses pengelolaan kebutuhan
arsitektur di seluruh fase TOGAF ADM. Tujuan dari proses ini adalah untuk menentukan kebutuhan arsitektur enterprise, kebutuhan itu disimpan lalu dimasukkan ke dalam fase yang sesuai (The Open Group, 2009) Sumber daya yang harus dikembangkan dalam tahapan ini adalah skenario aktivitas. Skenario aktivitas mencakup process business (alur aktivitas) dan issue (permasalahan dalam organisasi). Process business yang dimaksud adalah penjelasan sistem yang sedang berjalan pada organisasi. Requirement Management memiliki input, serta langkah-langkah, dan berupa output sebagai berikut: a. Input 1. Keadaan sistem pada saat ini. 2. Data inventaris sarana dan prasarana pendukung TIK. b. Langkah-langkah 1. Menganalisa kekurangan dan kelebihan dari kondisi sistem pada saat ini. 2. Identifikasi permasalahan dari kondisi sistem pada saat ini. 3. Membuat solusi dari setiap permasalahan pada kondisi sistem saat ini.
27
c. Output 1. Tabel permasalahan organisasi, yang menjelaskan daftar permasalahan dari setiap aktivitas organisasi. 2. Tabel solusi aktivitas, yang berisi tentang permasalahan dari setiap aktivitas beserta solusi yang akan mengatasi permasalahan tersebut. 3. Tabel solusi sistem informasi, pada tabel ini hampir sama dengan tabel solusi altivitas. Tetapi, perbedaannya ada pada kolom solusi. Pada tabel ini, solusi yang akan diberikan sudah menyebutkan sistem atau aplikasi apa saja yang nantinya seharusnya digunakan dalam mengatasi permasalahan organisasi.
2.4.4
Phase A : Architecture Vision Fase
ini
untuk menciptakan
keselarasan pandangan bagaimana
pentingnya EA untuk pencapaian tujuan organisasi. Elemen kunci dalam fase ini adalah visi, misi, strategi, serta tujuan perusahaan yang telah didokumentasikan. Kesemuanya itu dibutuhkan untuk menetapkan visi arsitektur yang baru. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menentukan/menetapkan proyek. 2. Mendefinisikan tujuan dan penggerak bisnis. 3. Review prinsip arsitektur termasuk prinsip bisnis. 4. Mendefinisikan apa yang di dalam dan luar ruang lingkup. 5. Mendefinisikan batasan-batasan.
28
6. Mengidentifikasi kebutuhan bisnis dan visi arsitektur. Fase visi arsitektur memiliki input, langkah-langkah dan output sebagai berikut: a. Input 1. Prinsip aktivitas, sasaran aktivitas dan penggerak aktivitas. b. Langkah-langkah 1. Menguraikan tujuan aktivitas, penggerak aktivitas, dan kendala aktivitas. 2. Mendefinisikan apa saja yang ada di dalam dan di luar ruang lingkup arsitektur pada saat ini. 3. Mengembangkan visi arsitektur. c. Output 1. Mengidentifikasi semua aktivitas yang ada di dalam organisasi. identifikasi tersebut dihasilkan dalam value chain, diagram yang mengidentifikasi dan mengelompokkan seluruh aktivitas mana saja yang nantinya akan masuk ke dalam kelompok aktivitas utama dan aktivitas pendukung. 2. Hasil identifikasi stakeholder dengan aktivitas yang ada dalam organisasi untuk mengetahui keterlibatan setiap stakeholder dalam organisasi, dan untuk mengetahui kebutuhan stakeholder dalam pembuatan arsitektur. Identifikasi ini nantinya akan dijelaskan dalam stakeholder map matrix, matriks yang akan
29
menjelaskan hubungan antara stakeholder dengan aktivitas dalam organisasi.
2.4.5
Phase B : Business Architecture Pada fase ini bertujuan untuk menguraikan deskripsi arsitektur bisnis
dasar, mengembangkan tujuan arsitektur bisnis dari proyek. Mengembangkan target arsitektur bisnis yang menjelaskan bagaimana pelaksanaan kebutuhan perusahaan untuk mencapai tujuan bisnis dalam mendukung visi arsitektur yang telah disetujui. Mendefinisikan kondisi awal arsitektur bisnis, menentukan pemodelan dari arsitektur saat ini serta yang diinginkan menggunakan alat bantu seperti model proses bisnis atau model business usecase. Beberapa tahap yang dilakukan di fase ini adalah: 1. Melengkapi arsitektur bisnis. 2. Melakukan Gap analysis. 3. Mengembangkan deskripsi arsitektur bisnis saat ini untuk mendukung arsitektur bisnis target. 4. Mengidentifikasi reference model, sudut pandang dan tools. 5. Menentukan kandidat calon roadmap. 6. Membuat dokumen definisi arsitektur. 7. Menyelesaikan arsitektur bisnis.
30
Fase arsitektur bisnis memiliki input, langkah-langkah, dan output sebagai berikut : a. Input 1. Kondisi aktivitas pada saat ini. b. Langkah-langkah 1. Mengembangkan deskripsi arsitektur aktivitas dasar. 2. Melakukan analisis gap. 3. Membuat arsitektur bisnis (aktivitas). c. Output 1. Pemodelan arsitektur bisnis menggunakan archimate. 2. Rancangan arsitektur bisnis yang digambarkan menggunakan rich picture. 3. Struktur organisasi usulan, merupakan rancangan struktur organisasi yang baru untuk menunjang kinerja organisasi dan kinerja sistem informasi agar dapat berjalan dengan baik. Arsitektur bisnis dapat dijelaskan meggunakan beberapa konsep tambahan berdasarkan orientasi layanan, yaitu konsep business service (layanan bisnis), business process (proses bisnis), dan business function (fungsi bisnis). a. Business Service Business Service merepresentasikan kemampuan yang menawarkan nilai tambah untuk lingkungan dan kemampuan ini direalisasikan secara internal dan independen (The Open Group, 2009).
31
b. Business Process Business Process merepresentasikan alur kerja atau aliran nilai yang terdiri atas proses atau fungsi lebih kecil. Tujuan dari business process adalah untuk memuaskan customer (The Open Group, 2009). c. Business Function Business Function menetapkan elemen perilaku berdasarkan pada sekumpulan kriteria terpilih. Business function mengelompokkan perilaku berdasarkan
pada sumber daya
bisnis,
kemampuan,
kompetensi dan pengetahuan yang dibutuhkan. Busniess function adalah tugas-tugas khusus yang dilakuan dalam sebuah organisasi The Open Group, 2009).
2.4.6
Phase C : Information Systems Architecture Pada fase ini bertujuan untuk mendefinisikan tipe dan sumber utama
data yang diperlukan untuk mendukung bisnis. Pada tahap ini tidaklah memperhatikan perancangan database, hanya menjelaskan pengembangan dari arsitektur sistem informasi untuk mendukung fase A yang telah disetujui. Beberapa tahap yang dilakukan di fase ini adalah: 1.
Arsitektur data, tujuannya adalah mendefinisikan entitas data yang relevan dengan enterprise yang
berhubungan dengan perusahaan, tetapi tidak
memperhatikan perancangan database.
32
Arsitektur data memiliki input, langkah-langkah, dan output sebagai berikut: a. Input 1. Data principles saat ini, berisi prinsip-prinsip mengenai data yang mendukung bisnis pada organisasi seperti prinsip penggunaan data tersebut. b. Langkah-langkah 1. Mengembangkan deskripsi dasar arsitektur data. 2. Mengembangkan deskripsi target arsitektur data. 3. Melakukan analisis gap. 4. Menyelesaikan arsitektur data. c. Output 1. Rancangan diagram yang mengubungkan data, layanan bisnis dan aplikasi. Rancangan tersebut menggunakan data dissemination diagram. 2. Rancangan tipe data dan hubungan antara entiti data penting untuk mendukung
aktivitas
pada
organisasi.
Rancangan
tersebut
digambarkan dalam class diagram.
2.
Arsitektur aplikasi, tujuannya adalah mendefinisikan berbagai jenis sistem aplikasi utama yang diperlukan untuk memproses data dan bisnis, tidak berhubungan dengan rancangan sistem aplikasi.
33
Arsitektur aplikasi memiliki input, langkah-langkan, dan output sebagai berikut : a. Input Application principles, berisi tentang prinsip-prinsip yang mengenai aplikasi yang digunakan pada organisasi, seperti prinsip penggunaan aplikasi tersebut. b. Langkah-langkah 1. Melakukan analisis gap. 2. Mengembangkan deskripsi dasar arsitektur apikasi 3. Mengembangkan deskrispi target arsitektur aplikasi. 4. Menyelesaikan arsitektur aplikasi. c. Output 1. Hasil identifikasi tersebut dijelaskan menggunakan
application
portofolio catalog. 2. Rancangan penempatan distribusi aplikasi yang digunakan user di dalam organisasi. rancangan tersebut digambarkan oleh application and user location diagram. 3. Rancangan penggambaran interaksi antara aktor (user) dan perannya dalam setiap aplikasi. Rancangan ini akan digambarkan dalam usecase diagram.
34
2.4.7
Phase D : Technology Architecture Tujuan dari fase ini adalah untuk mengembangkan arsitektur teknologi
yang diinginkan yang sesuai dengan arsitektur data dan aplikasi, yang mewakili perangkat lunak dan komponen perangkat keras, alternatif teknologi sampai pelaksanaan analisis kesenjangan. Beberapa tahap yang dilakukan di fase ini adalah: 1. Mengidentifikasi model, sudut pandang dan tools yang digunakan. 2. Mengembangkan baseline arsitektur teknologi. 3. Mengembangkan deskripsi target arsitektur teknologi. 4. Membuat analisis gap. 5. Menentukan kandidat roadmap. 6. Menanggulangi seluruh dampak arsitektur. 7. Membuat review untuk stakeholder. 8. Menyelesaikan arsitektur teknologi. 9. Membuat dokumen definisi arsitektur. Fase arsitektur teknologi memiliki input, langkah-langkah, dan output sebagai berikut : a. Input 1. Technology principles saat ini, berisi prinsip-prinsip mengenai teknologi yang digunakan untuk mendukung aktivitas pada organisasi. b. Langkah-langkah 1. Melakukan analisis gap.
35
2. Menyelesaikan arsitektur teknologi. 3. Mengembangkan deskripsi dasar arsitektur teknologi. 4. Mengembangkan deskripsi target arsitektur teknologi. c. Output 1. Rancangan komunikasi dalam arsitektur teknologi, seperti rancangan jaringan yang melibatkan hardware untuk membuat suatu komunikasi jaringan. Rancangan tersebut digambarkan dalam communication engineering diagram. 2. Platform decomposition diagram menggambarkan platform teknologi yang mendukung sistem informasi. 3. Identifikasi teknologi yang sudah digunakan dalam sistem yang berjalan pada organisasi. hasil tersebut dapat dijelaskan menggunakan technology portofolio catalog.
2.4.8 Phase E : Opportunities and Solution Pada fase ini bertujuan untuk berkonsentrasi pada rencana pembuatan implementasi awal dan identifikasi penyampaian arsitektur yang telah ditetapkan pada fase sebelumnya. Pada tahapan ini pula akan dievaluasi model yang telah dibangun untuk arsitektur saat ini dan target, identifikasi proyek utama yang akan dilaksanakan untuk mengimplementasikan arsitektur tujuan dan klasifikasi sebagai pengembangan baru atau penggunaan kembali sistem yang sudah ada.
36
Beberapa tahap yang dilakukan di fase ini adalah: 1.
Menentukan atribut key corporate change.
2.
Menetapkan batasan-batasan bisnis.
3.
Menggabungkan hasil analisis gap dari fase Business Architecture sampai Technology Architecture.
4.
Membuat ulasan persyaratan fungsi bisnis yang terkait.
5.
Menggabungkan persyaratan operasi.
6.
Mengesahkan ketergantungan.
7.
Menetapkan kesiapan dan resiko transformasi bisnis.
8.
Merumuskan implementasi dan migrasi.
9.
Mengidentifikasi paket kerja kelompok utama.
10.
Mengidentifikasi arsitektur transisi.
11.
Membuat roadmap arsitektur dan implementasi migrasi.
Fase peluang dan solusi memiliki input, langkah-langkah dan output sebagai berikut : a. Input 1. Hasil analisis gap dari arsitektur bisnis, data, aplikasi dan teknologi. b. Langkah-langkah 1. Merumuskan implementsi dan strategi migrasi. 2. Menentukan kendala aktivitas untuk implementasi. 3. Meninjau kembali dan menggabungkan hasil analisis gap dari fase B sampai fase D.
37
c. Output 1. Hasil analisis gap gabungan dari fase arsitektur bisnis sampai arsitektur teknologi
2.4.9 Phase F : Migration Planning Pada fase ini bertujuan untuk memilih proyek implementasi yang bervariasi menjadi urutan prioritas. Aktivitas mencakup penilaian ketergantungan, biaya, manfaat dari proyek migrasi yang bervariasi. Prioritas proyek akan berjalan untuk membentuk dasar dari perencanaan implementasi detail dan rencana migrasi. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menetapkan nilai bisnis untuk setiap paket kerja. 2. Memperkirakan kebutuhan sumberdaya, waktu proyek dan waktu pengiriman. 3. Mengutamakan migrasi proyek berdasarkan perkiraan biaya dan resiko. 4. Menyelesaikan rencana implementasi dan migrasi. Fase rencana migrasi memiliki input, langkah-langkah dan output sebagai berikut: a. input 1. Implementation and migration plan, suatu rencana untuk menjadwalkan migrasi data dan implementasi aplikasi.
38
b. Langkah-langkah 1. Menetapkan model bisnis pada setiap proyek. 2. Membuat roadmap implementasi arsitektur dan perencanaan migrasi. 3. Memastikan interaksi kerangka kerja manajemen untuk rencana implementasi dan migrasi. 4. Lebih memprioritaskan proyek migrasi melalui pelaksanaan penilaian biaya. c. output 1. Roadmap implementasi aplikasi.
2.4.10
Phase G : Implementation Governance Pada fase ini, proyek dilaksanakan sebagai program
rencana kerja,
serta pengelolaan proyek untuk mencapai keberhasilan arsitektur yang diinginkan. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menetapkan ruang lingkup dan prioritas implementasi dengan manajemen pengembangan. 2. Mengidentifikasi sumberdaya dan kemampuan. 3. Melakukan
penetapan
solusi
pengembangan
pada
setiap
implementasi. 4. Menjalankan Enterprise Architecture yang telah dibuat/dirancang. 5. Mengimplementasikan manajemen bisnis dan operasi IT.
39
6. Mengadakan
post-implementation
dan
menyelesaikan
implementasi. Fase tata kelola implementasi memiliki input, langkah-langkah dan output sebagai berikut : a. Input 1. Architecture roadmap b. Langkah-langkah 1. Mengidentifikasi sumber daya. 2. Menerapkan bisnis operasi dan IT. 3. Melaksanakan tinjauan pasca implementasi dan menutupnya. c. Output 1. Kontrak arsitektur yang telah ditandatangani
2.4.11
Phase H : Architecture Change Management Tujuan fase ini adalah untuk memastikan bahwa arsitektur mencapai
target bisnis serta untuk menentukan/menetapkan proses manajemen perubahan arsitektur untuk Enterprise Architecture yang baru. Proses ini menyediakan monitoring berkelanjutan dari hal-hal seperti pengembangan teknologi baru dan menentukan apakah akan dilakukan siklus pengembangan Enterprise Architecture berikutnya. Beberapa tahap yang dilakukan di fase ini adalah: 1. Menetapkan nilai realisasi proses.
40
2. Menetapkan monitoring tools. 3. Mengelola resiko. 4. Menyediakan analisis untuk manajemen arsitektur. 5. Menyediakan kebutuhan perubahan. 6. Mengelola proses tata kelola. 7. Mengaktifkan proses untuk menerapkan perubahan. Fase manajemen perubahan arsitektutur memiliki input, langkah-langkah, dan output sebagai berikut : a. Input 1. Inovasi teknologi bisnis dan perubahan strategi. b. Langkah-langkah 1. Mengelola resiko 2. Menyebarkan tools monitoring. c. Output 1. Kontrak arsitektur yang telah diperbarui. 2. Perubahan kerangka arsitektur dan prinsip-prinsip. 3. Arsitektur yang diperbarui untuk proses pemeliharaan.
41
2.4.12
Kelebihan dan Kekurangan TOGAF Salah satu kelebihan menggunakan TOGAF adalah karena sifatnya yang
fleksibel dan bersifat open source. TOGAF memandang enterprise architecture ke dalam empat kategori. Keempat kategori tersebut adalah business architecture, application architecture, data architecture, dan technology architecture (Setiawan, 2009). Secara umum TOGAF memiliki struktur dan komponen sebagai berikut: 1. Architecture Development Method (ADM) Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci bagaimana mementukan sebuah enterprise architecture secara spesifik berdasarkan kebutuhan bisnisnya. 2. Foundation Architecture Merupakan sebuah framework-within-a-framework dimana didalamnya tersedia gambaran hubungan untuk pengumpulan arsitektur relevan, juga menyediakan bantuan petunjuk pada saat terjadinya abstraksi level yang berbeda. foundation Architecture dapat dikumpulkan melalui ADM. 3. Resource Base Pada bagian ini terdapat informasi mengenai guidelines, templates, checklist, latar belakang informasi dan detail material pendukung yang membantu arsitek dalam penggunaan ADM. Kekurangan framework TOGAF:
42
1. Tidak adanya template standar untuk seluruh domain (misalnya untuk membuat blok diagram). 2. Tidak ada artefak yang dapat digunakan ulang (ready made).
2.5
Tools Perancangan Arsitektur 2.5.1
Principle Cataloga Bertujuan dari katalog ini adalah untuk menangkap bisnis dan prinsip-
prinsip yang menggambarkan solusi atau arsitektur yang seharusnya seperti apa. Nantinya prinsip-prinsip ini digunakan untuk mengevaluasi dan menyetujui hasil dari arsitektur bisnis. Prinsip ini juga digunakan sebagai tools untuk membuat tata kelola arsitektur yang mempunyai inisiatif perubahan. (The Open Group, 2009). Tabel 2.1 Contoh Principle Catalog No
Prinsip
Tujuan
1.
Keputusan arsitektur harus
Mendukung kemampuan adaptasi
mengacu
pada
tujuan
strategis dan proses bisnis pada
Dinas
Tata
terhadap proses bisnis Memperkuat
hubungan
antara
Kota,
infrastruktur dan proses bisnis
Bangunan dan Pemukiman.
serta lebih mudah menyelaraskan proses bisnis ketika perubahan terjadi.
2.
Pengelolaan arsitektur ini
Meningkatkan kemampuan untuk
43
diusahakan mudah.
berbagi data dan sumber daya lain dalam
pelayanan
pengguna
kepada
dan
membantu
kerjasama antar divisi. 3.
Arsitektur
yang
dikembangkan harus aman.
Dapat meminimalisasi dampak atas bencana alam. Mampu bertahan dari serangan eksternal seperti virus, worm, hack, syware, crack, phising, denial of service.
4.
Data
Previlege
(Perlindungan Data)
Untuk melindungi pihak-pihak
dari akses
yang
tidak
berwenang. Mengatur
stakeholder
dalam
mengolah data. 5.
Arsitektur dirancang agar mudah penambahan
melakukan
cepat apabila ada perubahan yang
dan
dapat berakibat pada infrastruktur
pengembangan. 6.
Memungkinksn respon yang lebih
yang bersifat adaptif.
Penerapan arsitektur multi-
Memudahkan
tier dan arsitektur berbasis
penggantian
komponen.
rusak availability).
kegiatan komponen
yang
(meningkatkan
44
Memudahkan
duplikasi
dan
upgrading modul. 7.
Menggunakan technology.
open
Menghindari ketergantungan pada vendor. Menjamin dukungan produk yang kuat terhadap teknologi. Meminimalisasi training manusia yang harus dilakukan setiap kali ada perubahan dalam
pilihan
vendor. 8.
Data yang konsisten.
Tersedianya kebutuhan bagi pihak yang membutuhkan. Meminimalkan kerancuan pengembangan
resiko jika yang
akan ada akan
dikerjakan.
2.5.2 Flowchart Flowchart merupakan gambar atau bagan yang memerlihatkan urutan dan hubungan antar proses beserta intruksinya. Gambaran ini dinyatakan dengan simblo. Setiap simbol menggambarkan proses tertentu, sedangkan
45
hubungan antar proses digambarkan dengan garis penghubung. Flowchart merupakan cara penyajian dari suatu algoritma (Ladjamudin, 2005). Terdapat dua macam flowchart yang menggambarkan prosess komputer, yaitu : 1.
System Flowchart Bagan yang menggambarkan proses dalam sistem dengan menunjukkan alat media input, output serta jenis media penyimpanan dalam proses pengolahan data.
2.
Program flowchart Bagan yang memperlihatkan urutan intruksi yang digambarkan dengan simbol tertentu untuk emmecahkan masalah dalam suatu program.
Flowchart disusun dengan simbol. Simbol ini dipakai sebagai alat bantu menggambarkan proses di dalam program. Simbol-simbol yang akan digunakan dapat dibagi menjadi tiga bagian, yaitu simbol penghubung/alur (flow direction symbols), simbol proses (processing sysmbols), dan simbol input-output (inputoutput symbols). Dengan uraian sebagai berikut. 1. Simbol penghubung/alur (Flow Direction Symbols) Simbol yang digunakan untuk menghubungkan antara simbol yang satu dengan yang lain. Simbol ini disebut juga connecting line. Simbol-simbol tersebut adalah sebagai berikut:
46
Tabel 2.2 Simbol Penghubung Flowchart Simbol Arus/Flow
Penjelasan Untuk menyatakan jalannya arus suatu proses.
Communication Link
Untuk menyatakan bahwa adanya transisi suatu data/informasi dari satu lokasi ke lokasi lainnya.
Connector
Untuk
menyatakan
sambungan
dari suatu proses ke proses lainnya dalam halaman/lembar yang sama.
Off-line Connector
Untuk
menyatakan
sambungan
dari satu proses ke proses lainnya dalam
halaman/lembar
yang
berbeda.
2. Simbol Proses (Processing Symbols) Simbol yang menunjukkan jenis operasi pengolahan dalam suatu proses/prosedur. Simbol-simbol tersebut adalah sebagai berikut.
47
Tabel 2.3 Simbol Proses Flowchart Simbol Proses/penugasan
Penjelasan Untuk kegiatan pemrosesan input, pada simbol ini dapat menuliskan operasioperasi yang dikenakan pada input.
Manual
Untuk
menyatakan
suatu
tindakan
(proses) yang tidak dilakukan oleh komputer (manual).
Decision/logika
Untuk
menunjukkan
suatu
kondisi
tertentu yang akan menghasilkan dua kemungkinan jawaban, ya atau tidak.
Predefined Process
Pengolahan untuk member harga awal.
Terminal
Untuk menyatakan permulaan atau akhir suatu program.
48
Keying Operation
Untuk menyatakan segala jenis operasi yang diproses dengan menggunakan suatu
mesin
yang
mempunyai
keyboard. Offline-Line Storage
Untuk menunjukkan bahwa data dalam simbol ini akan disimpan ke suatu media tertentu.
Manual Input
Untuk memasukkan data secara manual dengan menggunakan online keyboard.
3. Simbol Input-Output (Input-Output Symbols)
Tabel 2.4 Simbol Input-Output Flowchart Simbol Input-Output
Penjelasan Untuk menyatakan proses input dan output tanpa tergantung dengan jenis peralatannya.
Punched Card
Untuk menyatakan input berasal dari kartu atau output ditulis ke kartu.
49
Magnetic-tape Unit
Untuk menyatakan input berasal dari pita magnetic atau output disimpan ke pita magnetic.
Disk Storage
Untuk menyatakan input berasal dari disk atau output disimpan disk.
Document
Untuk mencetak laporan ke printer.
Display
Untuk menyatakan peralatan output yang digunakan berupa layar (video dan komputer).
2.5.3
Value Chain Porter (1985), dalam buku karangan Jogiyanto (2005), value chain
meliputi kegiatan-kegiatan yang terdiri dari kegiatan-kegiatan atau aktivitasaktivitas, yaitu:
1. Aktivitas utama, yang meliputi penanganan dan penyimpanan bahan mentah yang berupa inbound logistics, operations, outbond logistics, marketing and sales, dan services.
50
2. Aktivitas pendukung yaitu infrastruktur perusahaan, yang berupa firm infrastructure, human resources management, technology development, dan procurement. Untuk mencapai keunggulan kompetitif, dua aktivitas besar yang terdiri dari sembilan kegiatan tersebut harus mempunyai nilai yang efektif dan efisien. Nilai disetiap kegiatan harus dapat menciptakan nilai dimasing-masing kegiatan.
Gambar 2.2 : Diagram Value Chain (Porter, 1985)
2.5.3
Stakeholder Map Matrix Tujuan dari Stakeholder Map Matrix ini adalah untuk mengidentifikasi
stakeholder untuk keterlibatannya di dalam aktivitas utama dan aktivitas pendukung (The Open Group, 2009).
51
Tabel 2.5 Contoh Stakeholder Map Matrix
Non Pemerintah
Pemerintah
Kepala Dinas
Bag. Keuangan
Pemohon
Subbag. Tata Usaha
Bid. Teknik
Aktivitas
Bid. Bangunan
Tata Ruang
Stakeholder
Aktivitas Utama 1. Rekomendasi
IMB &SLF
2. Hasil Musrembang
3. Sidang 4. Survey Lokasi 5. DPA 6. Lelang Proyek 7. Rekomendasi IMB &SLF 8. Bangunan
Aktivitas Pendukung 1. Manajemen Keuangan 2. SDM 3. Inventaris 4. Perencanaan Bisnis Strategis
Pada tabel 2.5 digambarkan keterlibatan stakeholder terhadap aktivitas yang ada di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang
52
Selatan. Kolom pada matriks tersebut merupaka stakeholder yang ada di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Baris pada matriks tersebut merupakan aktivitas-aktivitas yang ada pad DTKBDP. Warna biru yang ada dalam matriks tersebut menandakan siapa saja stakeholder yang terlibat dalam setiap aktivitas.
2.5.4
Archimate Archimate adalah bahasa pemodelan untuk menggambarkan enterprise
architecture. ada standarisasi archimate, terbagi menjadi 3 layer, yaitu layer teknologi, layer bisnis, dam layer aplikasi. a.
Layer bisnis 1.
Konsep struktural antara peran bisnis, pelaku usaha dan entitas yang melakukan prilaku seperti proses bisnis atau fungsi. Proses bisnis disini menandakan tanggung jawab untuk satu atau lebih proses bisnis atau fungsi bisnis.
2.
Peran bisnis ditetapkan pada pelaku usaha. Pelaku usaha bisa berupa individu atau kelompok masyarakatdan sumber daya yang memiliki status permanen dalam organisasi.
b.
Layer aplikasi Konsep untuk layer ini adalah komponen aplikasi. Konsep ini digunakan untuk memodelkan entitas struktural dalam lapisan aplikasi dari perangkat lunak lengkap atau sistem informasi.
53
c.
Layer teknologi Konsep struktural untuk lapisan teknologi ini adlaah node. Konsep ini digunakan untuk memodelkan entitas struktural dlaam lapisan teknologi.
2.5.5
Rich Picture Merupakan penggambaran sistem atau situasi dengan menggunakan
gambar-gambar. Gambaran keseluruhan dari orang, objek, proses, struktur, dan maslah pada keseluruhan proses bisnis yang ada di organisasi.
2. Kelola Data Inventaris
1. Input Data Inventaris
Subbag. Rumah Tangga Bidang Teknik
3. View Laporan Inventaris
1a. Input Data Inventaris
Aplikasi E-inventaris Bagian Keuangan
Bidang Bangunan
Gambar 2.3 Contoh Rich Picture Menjelaskan bahwa pada pencatatan penggunaan inventaris di DTKBDP, setiap bidang harus melakukan login terlebih dahulu kedalam sisem, kemudian setiap bidang harus menginput data inventaris yang mereka gunakan setiap bulan. Subbag. Rumah tangga melakukan login kedalam sistem untuk mengelola data inventaris yang digunakan setiap bidang di DTKBDP. Bagian keuangan melihat laporan inventaris melalui sistem E-inventaris.
54
2.5.6
Data Dissemination Diagram Data Dissemination Diagram menunjukkan hubungan antara entitas data,
layanan bisnis dan komponen aplikasi. Diagram ini menunjukkan bagaimana entitas logis secara fisik diwujudkan dengan komponen aplikasi. Kemudian, menggambarkan replika data dan sistem uta,a untuk data (The Open Group, 2009).
Gambar 2.4 Data Dissemination Diagram Pada gambar 2.4 menggambarkan hubungan layanan Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan, aplikasi, dan data. Di aplikasi IMB dan SLF terdapat data level, data user, data pegawai, data customer, data tanah, data SLF, data IMB dan data bangunan. Aplikasi SPK Lelang terdapat
55
data level, data user, data pegawai, data kontraktor, data material, data DPA, data design proyek dan data lelang. Aplikasi progress bangunan terdapat data level, data user, data pegawai, data proyek, data pengawas, data progress, dan data kontraktor. Aplikasi E-inventaris terdapat data user, data level, data pegawai dara registrasi_BMN, data peralatan, data kendaraan, data tanah, data bangunan dan data aset_tak_berwujud. Aplikasi E-keuangan terdapat data level, data pegawai, data periode, data klasifikasi_pengeluaran, data user, data pengeluaran dan data general_ledger.
2.5.7
UML Unified Modelling Laguage (UML) adalah salah satu alat bantu yang
sangat handal di dunia pengembangan sistem yang berorientasi objek. Hal ini disebabkan karena UML menyediakan bahasa pemodelan visual
yang
memungkinkan bagi pengembang sistem untuk membuat cetak biru atas visi mereka dalam bentuk yang baku, mudah dimengerti serta dilengkapi dengan mekanisme yang efektif untuk berbagi dan mengkomunikasikan rancangan mereka dengan yang lain. UML merupakan kesatuan dari bahasa pemodelan yang dikembangkan oleh Booch, Object Modelling Technique (OMT) dan Object Oriented Engineering (OOSE). Metode Booch dari Grady Booch sangat terkenal dengan nama metode Design Object Oriented. Metode ini menjadikan proses analisis dan design ke dalam empat tahapan iteratif, yaitu: identifikasi kelas-kelas dan obyek-
56
obyek, identifikasi semantik dari hubungan obyek dan kelas tersebut, perincian interface dan implementasi. Desain sistem pada UML disusun oleh simbol-simbol yang terbentuk menjadi diagram model. Berikut adalah simbol yang digunakan pada desain sistem ini. UML memiliki beberapa diagram diantaranya (Munawar, 2005): 1.
Diagram Use Case Use Case adalah deskripsi fungsi dari sebuah sistem dari perspektif
pengguna. Use case bekerja dengan cara mendeskripsikan tipikal interaksi antara user (pengguna) sebuah sistem dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai (Munawar, 2005). Usecase merupakan konstruksi untuk mendeskripsikan bagaimana sistem akan terlihat di mata pengguna potensial. Use case terdiri dari sekumpulan skenario yang dilakukan oleh seorang actor (orang, perangkat keras, urutan waktu atau sistem yang lain). Use case adalah alat bantu terbaik guna menstimulasi pengguna potensial untuk mengatakan tentang suatu sistem dari sudut pandangnya. Diagram use case mempunyai 3 notasi yang menunjukkan aspek dari sistem, yaitu actor (pengguna), use case dan relationship (Munawar, 2005). Berikut adalah simbol-simbol yang ada pada diagram use case: (sugiarti, 2013):
57
Tabel 2.6 Daftar Simbol Use Case Diagram Simbol Use Case
Deskripsi Fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor, biasanya dinyatakan dengan menggunakan kata kerja di awal frase nama use case.
Nama Use Case
Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan di buat itu sendiri ; biasanya dinyatakan menggunakan kata benda di awal frase nama aktor.
Asosiasi (Association)
Komunikasi antara aktor dan use case yang berpartisipasi pada use case.
Ekstensi (Extend) <<extend>>
Relasi use case tambahan ke sebuah use case
dimana
ditambahkan walau
tanpa
use
dapat use
case berdiri
case
yang sendiri
tambahan;
biasanya use case tambahan memiliki nama depan yang sama dengan use case
58
yang ditambahkan.
Generalisasi (Generalitation)
Hubungan generalisasi dan spesialisasi (umum-khusus) antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari lainnya.
Menggunaan (Include)
Relasi use case ke sebuah use case dimana use case yang ditambahkan memerlukan
use
case
ini
untuk
menjalankan fungsinya atau sebagai syarat dijalankan use case ini. Dua sudut pandang mengenaik use case, yaitu : 1.
Include berarti use case yang ditambahkan
akan
selalu
dipanggil saat use case tambahan dijalankan. 2.
Include berarti use case
yang
tambahan akan selalu melakukan pengecekan apakah use case yang
ditambahkan
telah
59
dijalankan sebelum use case tambahan
dijalankan.
Kedua
sudut pandang tersebut dapat digunakan
salah
satu
keduanya,
tergantung
atau pada
pertimbangan dan sudut pandang yang dibutuhkan.
Log Out <> Log in Manajemen User
Admin
Input Hasil Musrembang
Bagian Keuangan
Input DPA Input Design Proyek Pemerintah Kota
Input Proposal Proyek Memilih Kontraktor
Kontraktor
Pengesahan Proyek Bidang Teknik
View Laporan Proyek Kepala Dinas
Sekretariat
Gambar 2.5 Contoh Model Use Case Diagram Pada gambar 2.5 menjelaskan use case diagram di sistem SPK lelang. Arsitektur bisnis SPK Lelang memiliki 7 aktor dan 10 use case yang dapat dilakukan dalam sistem SPK lelang. Aktor yang terlibat yaitu, admin, bagian
60
keuangan, pemerintah kota, kontraktor, bidang teknik, kepala dinas dan sekretariat. Use case yang terlibat dalam SPK lelang yaitu, login,logout, manajemen user, input hasil musrembang, input DPA, input design proyek, input proposal proyek, memilih kontraktor, pengesahan proyek, dan view laporan proyek.
2. Diagram Kelas Class Diagram adalah deskripsi objek-objek dengan property, perilaku (operasi) dan relasi yang sama. Disamping itu class diagram bisa memberikan pandangan global atas sebuah sistem. Class dalam notasi UML digambarkan kotak. Nama class menggunakan huruf besar di awal kalimatnya dan diletakkan di atas kotak. Bila class mempunyai nama yang terdiri dari 2 (dua) suku kata atau lebih, maka semua suku kata digabungkan tanpa spasi dengan huruf awal tiap suku kata menggunakan huruf besar. Atribute adalah property dari sebuah class. Atribute ini melukiskan batas nilai yang mungkin ada pada obyek dari class. Sebuah class mungkin mempunyai nol atau lebih atribute (Munawar, 2005). Operation adalah sesuatu yang dilakukan oleh sebuah class atau yang anda (atau class yang lain) dapat lakukan sebuah class. Responsibility adalah keterangan tetang apa yang akan dilakukan class yaitu apa yang akan dicapai oleh atribute dan operation (Munawar, 2005).
61
Tabel 2.7 Daftar Simbol Class Diagram Simbol
Penjelasan
Kelas
Kelas pada struktur sistem.
Antarmuka (Interface)
Sama seperti konsep interface dalam
pemrograman
berorientasi objek.
Asosiasi (Assosiation)
Relasi
antar
kelas
dengan
makna umum; biasanya disertai dengan multiplicity. Asosiasi
berarah
(Directed Relasi
Association)
makna
antar kelas
kelas yang
dengan satu
digunakan oleh kelas yang lain; biasanya
disertai
dengan
multiplicity. Generalisasi (Generalization)
Relasi makna
antar
kelas
dengan
generalisasi
spesialisasi (umum – khusus)
–
62
Kebergantungan (Depedency)
Relasi
antar
kelas
dengan
makna kebergantungan antar kelas.
User +Nip +Username +Password +Tambah() +Hapus() +Ubah()
Level +id_level +nama_Level +tambah() +hapus()
*
1 Pegawai
SLF +No_SLF +Tanggal_SLF +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_SLF +Pengesahan +Tambah() +Hapus() +Ubah() +Print()
1..*
1
+NIP +Nama_Pegawai +TTL +Alamat 1 +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah()
Customer
Tanah
+Id_Customer 1..* +Nama_Customer +TTL +Telp +Alamat +KTP 1 +Akta
1 1
1
1
+Tambah() 1..* +Hapus() +Ubah()
+Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah 1..*
+Tambah() +Hapus() +Ubah() 1
1
1 IMB +No_IMB 1..* +Tanggal_IMB +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_IMB +Pengesahan +Tambah() +Hapus() +Ubah() +Print()
Bangunan
1..*
+Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan +Tambah() +Hapus() +Ubah()
Gambar 2.6 Contoh Model Class Diagram
Pada gambar 2.6 menjelaskan Class Diagram di sistem IMB dan SLF. Arsitektur data IMB dan SLF memiliki 8 kelas, yaitu Level, user , Pegawai, Customer, Tanah, Bangunan, SLF, dan IMB. Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas pegawai. Kelas pegawai memiliki multiplicity 1 1..* (satu ke antara satu sampai
63
banyak) terhadap kelas tanah dan bangunan. Kelas bangunan memilik multiplicity 11 (satu ke satu) terhadap kelas tanah.
Kelas IMB dan SLF memiliki
multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas pegawai. Kelas user memiliki multiciply 11 (satu ke satu) terhadap pegawai dan kelas user juga memiliki multiciply 1 1..* (satu ke antara satu sampai banyak) terhadap kelas customer.
2.5.6.1
Sejarah UML Pada akhir tahun 80-an dan awal 90-an, di gunakan beberapa metode
berorientasi objek yang berbeda-beda. Yang paling terkenal adalah metode Booch dari Grady Booch Object Modeling Technique (OMT) dari James Rumbaugh (OMT), dan Object Oriented Software Engineering (OOSE) dari Ivar Jacobson. Banyaknya teknik yang di gunakan membatasi kemampuan untuk memakai model-model pada proyek lain (mengurangi reuse) dan tim pengembang. Konsekuesinya, teknik ini menghambat komunikasi antara anggota tim dan pengguna, yang mengakibatkan banyak terjadi error di dalam proyek. Masalah ini dan lainnya mendorong di lakukannya usaha untuk mendesain bahasa pemodelan standar (Whitten et al. 2006). Pada tahun 1994, Grady Booch dan James Rumbaugh sepakat bergabung untuk menggunakan metode pengembangan berorientasi objek dengan tujuan membuat proses standar tunggal untuk mengembangkan sistem berorientasi objek. Ivar Jacobson bergabung pada tahun 1995, dan mereka bertiga fokus membuat sebuah bahasa pemodelan objek standar sebagai ganti dari pendekatan atau
64
metode berorientasi objek standar. Berdasarkan keja mereka dan hasil kerja lainnya pada industri, Unified Modeling Language (UML) versi 1.0 di rilis pada tahun 1997 (Whitten et.al, 2006).
2.5.7
Principle Catalog Catalog ini digunakan untuk menetapkan beberapa prinsip bisnis dan
arsitektur perusahaan dalam memberikan solusi arsitektur yang tepat untuk perusahaan. Catalog ini juga dapat digunakan untuk mengevaluasi implementasi arsitektur serta menilai perubahan tata kelola arsitektur yang terjadi. (The Open Group, 2011). Tabel 2.8 Principle Catalog No
Prinsip
Tujuan
1.
Keputusan arsitektur harus
Mendukung kemampuan adaptasi
mengacu
pada
tujuan
strategis dan proses bisnis pada
Dinas
Tata
terhadap proses bisnis Memperkuat
hubungan
antara
Kota,
infrastruktur dan proses bisnis
Bangunan dan Pemukiman.
serta lebih mudah menyelaraskan proses bisnis ketika perubahan terjadi.
2.
Pengelolaan arsitektur ini diusahakan mudah.
Meningkatkan kemampuan untuk berbagi data dan sumber daya lain dalam
pelayanan
kepada
65
pengguna
dan
membantu
kerjasama antar divisi. 3.
Arsitektur
yang
dikembangkan harus aman.
Dapat meminimalisasi dampak atas bencana alam. Mampu bertahan dari serangan eksternal seperti virus, worm, hack, syware, crack, phising, denial of service.
4.
Data
Previlege
(Perlindungan Data)
Untuk melindungi pihak-pihak
dari akses
yang
tidak
berwenang. Mengatur
stakeholder
dalam
mengolah data.
2.5.8
Technology Portofolio Catalog Catalog ini digunakan untuk mengidentifikasi daftar teknologi yang
digunakan dalam perusahaan, seperti hardware, infrastructure software, dan application software. Technology portfolio yang sudah disetujui akan menjadi dasar standar teknologi perusahaan yang dapat mendukung siklus hidup produk menajemen teknologi dan beberapa versi teknologi selanjutnya (The Open Group, 2011).
66
Tabel 2.9 Technology Portofolio Catalog
Pada tabel 2.9 dijelaskan teknologi apa saja yang dibutuhkan dan akan digunakan DTKBDP dalam arsitektur teknologi usulan untuk setiap aplikasi yang akan dibangun.
2.5.9
Communications Engineering Diagram Diagram ini menjelaskan maksud komunikasi antar aset dalam arsitektur
teknologi. Adanya koneksi logis antara clienT dan server dalam mengidentifikasi batasan jaringan dan jaringan infrastruktur yang diperlukan secara fisik untuk mengimplementasikan koneksi tersebut. Diagram ini tidak menjelaskan format informasi ataupun konten, tetapi menjelaskan alamat protokol dan kapasitas (The Open Group, 2009).
67
Gambar 2.7 : Contoh Communication Engineering Diagram
2.5.10
Platform Decomposition Diagram
Menurut The Open Group (2009), platform decomposition diagram menggambarkan platform teknologi yang mendukung operasional arsitektur sistem informasi. Diagram ini mencakup semua aspek platform infrastruktur dan menyediakan gambaran platform teknologi pada organisasi.
68
Gambar 2.8 platform Decomposition Diagram Pada gambar 2.8 menjelaskan platform teknologi menggambarkan bahwa keseluruhan sistem yang diusuljan sudah berbasis web. Pada level client interface, user eksternal dapat mengakses aplikasi yang berada di website DTKBDP melalui web browser dan internet. User internal dapat mengakses keseluruhan sistem aplikasi di website DTKBDP melalui internet atau jringan lokal (LAN) Apache web server digunakan untuk mendukung berjalannya aplikasi berbasis web. Aplikasi berbasis web dibangun menggunakan bahasa pemrograman PHP (Hypertext Preprocessor). Bahasa pemrograman ini akan mengambil data dari data storage.
69
2.5.11
Matriks Analisis Gap Menurut The Open Group, 2009 matrik ini menunjukan suatu ruang
lingkup dari sebuah paket pekerjaan yang harus diimplementasikan sebagai bagian dari transformasi Road Map yang lebih luas dengan penggambaran baseline architecture yang ada pada saat ini dan pergambaran target arsitektur target. Premis dasar adalah untuk menyoroti kekurangan antara Arsitektur Dasar dan Arsitektur Sasaran, yaitu item yang telah sengaja dihilangkan, sengaja ditinggalkan, atau belum ditetapkan. Sebuah langkah penting dalam mengevaluasi arsitektur adalah untuk mempertimbangkan apa yang mungkin telah dilupakan. Arsitektur harus mendukung semua kebutuhan pengolahan informasi penting dari organisasi. Sumber yang paling penting dari gaps yang harus dipertimbangkan adalah kekhawatiran stakeholder
yang belum dibahas dalam karya arsitektur
sebelumnya.
2.6
Metode Pengembangan Sistem Rapid Application Development (RAD) Metodologi pengembangan sistem adalah suatu aktivitas, metode, praktik
terbaik dan peralatan terotomatisasi yang digunakan para stakeholder untuk mengembangkan dan secara berkesinambungan memperbaiki sistem informasi dan perangkat lunak (Whitten et al, 2006). Pengembangan sistem informasi merupakan penyusunan suatu sistem untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki sistem yang telah ada.
70
Rapid
Application
Development
(RAD)
yaitu
suatu
pendekatan
berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak (Kendall & Kendall, 2006). Rapid Application
Development
(RAD)
adalah
sebuah
model
proses
perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan adaptasi “kecepatan tinggi” dari model
sekuensial
linier
dimana
perkembangan
cepat
dicapai
dengan
menggunakan pendekatan konstruksi berbasis pada komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 45 sampai 90 hari). Model pengembangan ini melingkupi aktivitas-aktivitas sebagai berikut : 1. Fase Perencanaan Syarat (Requirement Planning) 2. Fase Proses Desain (Workshop Design) 3. Fase Implementasi (Implementation)
Model pengembangan software tradisional memiliki tahapan-tahapan yang harus diselesaikan secara bertahap, sedangkan pada pengembangan menggunakan Rapid Application Development (RAD), pengembang sistem dapat menyelesaikan sebuah modul sampai diimplementasikan tanpa harus menunggu seluruh sistem selesai. Berikut ini adalah gambaran mengenai perbedaan dari model
71
pengembangan sistem secara tradisional dan dengan menggunakan Rapid Application Development (RAD).
Gambar 2.9 Fase Rapid Application Development (RAD)
2.6.1 Perencanaan Syarat (Requirement Planning) Pada tahap ini, user dan analis melakukan semacam pertemuan untuk melakukan identifikasi tujuan dari aplikasi atau sistem dan melakukan identifikasi kebutuhan informasi untuk mencapai tujuan. Pada tahap ini hal terpenting adalah adanya keterlibatan dari kedua belah pihak, bukan hanya sekedar persetujuan akan proposal yang sudah dibuat. Untuk lebih jauh lagi, keterlibatan user bukan hanya dari satu tingkatan pada suatu organisasi, melainkan beberapa tingkatan organisasi sehingga informasi yang dibutuhkan untuk masing – masing user dapat terpenuhi dengan baik. Di samping itu, dapat juga melakukan koordinasi dengan Chief Information Office (CIO) atau bagian perencana strategis terutama untuk mengembangkan suatu aplikasi untuk mendapatkan informasi yang lebih detail
72
akan tujuan dari suatu organisasi. Pertemuan semacam ini seringkali disebut Joint Aplication Development. 2.6.2
Proses Desain (Design Workshop) Pada tahap ini adalah melakukan proses desain dan melakukan perbaikan –
perbaikan apabila masih terdapat ketidaksesuaian desain antara user dan analyst. Untuk tahap ini maka keaktifan user yang terlibat sangat menentukan untuk mencapai tujuan, karena user bisa langsung memberikan komentar apabila terdapat ketidaksesuaian pada desain. Biasanya, user dan analyst berkumpul menjadi satu dan duduk di meja melingkar dimana masing-masing orang bisa melihat satu dengan yang lain tanpa ada halangan. Apabila memungkinkan, maka masing-masing user diberikan satu komputer yang terhubung satu dengan yang lain, sehingga masing-masing bisa melihat desain yang dibuat dan langsung memberikan komentar. Hal ini sering kali disebut dengan Group Decision Support System (GDSS). Pada beberapa kasus, GDSS ini merupakan suatu langkah yang ideal, karena user dan analyst dapat menyetujui desain yang dibuat untuk kemudian dilanjutkan oleh programmer dalam pembuatan prototype dari aplikasi yang dimaksud dengan langsung menampilkan kepada user hasilnya dengan cepat. Pada tahap desain ini membutuhkan waktu beberapa hari, akan tetapi bisa semakin lebih lama, tergantung dari besar kecilnya sistem yang dibuat. Pada selang waktu tersebut, user bisa memberikan tanggapan akan sistem yang sudah dikembangkan untuk selanjutnya dilakukan perbaikan- perbaikan. Dengan demikian proses pengembangan suatu sistem membutuhkan waktu yang cepat.
73
2.6.3
Implementasi (Implementation) Setelah desain dari sistem yang akan dibuat sudah disetujui baik itu oleh
user dan analyst, maka pada tahap ini programmer mengembangkan desain menjadi suatu program. Setelah program selesai baik itu sebagian maupun secara keseluruhan, maka dilakukan proses pengujian terhadap program tersebut apakah terdapat kesalahan atau tidak sebelum diaplikasikan pada suatu organisasi. Pada saat ini maka user bisa memberikan tanggapan akan sistem yang sudah dibuat serta persetujuan mengenai sistem tersebut. Adapun hal terpenting adalah bahwa keterlibatan user sangat diperlukan supaya sistem yang dikembangkan dapat memberikan kepuasan kepada user, dan di samping itu, sistem yang lama tidak perlu dijalankan secara paralel dengan sistem yang baru.
2.7
Penelitian Sejenis
1.
“Perencanaan Strategis Sistem informasi/Teknologi
Informasi
Menggunakan Kerangka The Open Architecture framework (TOGAF) (Studi Kasus: Pemda kabupaten Sumba Barat)”. Skripsi ini disusun oleh Raimond Lukito Widiatmo pada tahun 2012. Tujuan pembuatan skripsi ini adalah untuk menyusun enterprise Architecture pada Pemda Kabupaten Sumba Barat agar tata kelola dan administrasi berjalan dengan efektif dan efisien. Kekurangan pada skripsi ini adalah penulis hanya menggunakan 4 phase dalam penelitiannya.
74
Dirasa sangat tidak optimal, karena Pemda Sumba Barat dipastikan membutuhkan usulan sistem yang maksimal.
2.
“Perencanaan Infrastruktur Teknologi Informasi di
Lembaga
Penelitian (UIN) Syarif Hidayatullah Jakarta Menggunakan TOGAF Architecture Development Method (ADM)”. Skripsi ini disusun oleh Aenun Jariyatul Umami (Fakultas Sains dan Teknologi Informasi, UIN Syarif Hidayatullah Jakarta, 2013) dengan tujuan menganalisis kebutuhan dari infrastruktur teknologi Informasi secara menyeluruh dan terpadu untuk mencapai visi dan misi Lemlit menggunakan TOGAF. Kelebihan dari penelitian ini adalah perencanaan Enterprise Architecture menghasilkan suatu dokumentasi perencanaan infrastruktur teknologi informasi yang terintegrasi untuk mendukung kebutuhan organisasi dan memberikan pensejajaran antara proses bisnis Lemlit dengan teknologi informasi yang mengiringinya. Kekurangan dari penelitian ini adalah analisis dan perencanaan infrastruktur teknologi informasi dibatasi hanya pada fase Preliminary Phase, Architecture vision (Tahapan A), Bussiness architecture (Tahapan B), Information system architecture (Tahapan C), dan Technology architecture (Tahapan D).
75
3.
Menggunakan TOGAF Architecture Development method Pada PT. Satya Karya Utama”. Skripsi ini disusun oleh Vivi Fyandiani Pratiwi pada tahun 2013
dengan tujuan memberikan usulan enterprise architecture agar proses bisnis pada PT. Satya Utama yang bergerak dalam bidang property, design interior, furniture dan jasa konsultan dapat berjalan dengan efektif dan efisien. Adapun kelebihan pada penelitian ini adalah tingkat analisis yang dinilai sangat detail. Dimulai dari pendahuluan sampai arsitektur teknologi, sehingga memudahkan para stakeholder untuk memahami rancangan arsitektur TI tersebut. Kekurangan pada skripsi ini adalah tidak adanya relasi antara entitas
data-data
yang
akan
digunakan
sehingga
menyulitkan
pekembangan lebih lanjut yang terkait dengan hubungan data-data.
i
76
BAB III METODOLOGI PENELITIAN
3.1
Metode Pengumpulan Data Pembuatan penelitian ini dilakukan menggunakan beberapa metode yang
dapat membantu penulis baik dalam hal pengumpulan data maupun informasi yang diperlukan untuk mendapatkan kebenaran materi uraian pembahasan. Oleh karena itu, riset atau penelitian dilakukan guna mendapatkan data dan referensi yang diperlukan. Teknik pengumpulan data ini dilakukan agar data-data yang dibutuhkan dalam penelitian ini dapat terpenuhi dan supaya tercapainya tujuan penelitian. Teknik pengumpulan data yang dipilih tergantung pada faktor utama dan jenis data. Berikut merupakan metode dari pengumpulan data yang dilakukan untuk mendapatkan data dan referensi yang dibutuhkan. 3.1.1
Metode Observasi Menurut (Jogiyanto, 2008) , “Observasi (observation) merupakan teknik
atau pendekatan untuk mendapatkan data primer dengan cara mengamati langsung obyek datanya”. Pengamatan ini dilakukan dengan melihat langsung proses dan kegiatan bisnis yang berjalan pada studi kasus Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Observasi dilakukan pada bulan Agustus 2014 yang bertempat di Jl. Raya Puspiptek, Setu, Ruko Boulevard No.A1 & A2
76
77
Serpong-Tangerang Selatan. Kegiatan ini dilakukan untuk melihat proses bisnis yang terjadi, dan segala kegiatan atau mencari data yang diperlukan untuk penelitian. Hasil observasi yang didapat adalah: a.
Sejarah singkat Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan, visi dan misi yang ada.
b.
Profil Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan.
c.
Sistem berjalan yaitu bagaimana proses pengajuan permohonan perizinan dan perencanaan penataan kota di Tangerang Selatan.
Teknik observasi ini dimulai dengan melakukan pengamatan langsung terhadap proses bisnis dan strategi bisnis yang ada pada Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan, apa saja yang menjadi dukungan agar proses bisnis bisa berjalan sesuai dengan yang diinginkan perusahaan. Lalu mengamati apakah teknologi informasi sudah digunakan secara selaras dengan proses bisnis tersebut.
3.1.2
Metode Wawancara Metode ini dilakukan untuk membantu mencari informasi yang berkaitan
dengan kegiatan di Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Dalam hal ini wawancara dilakukan dengan pihak yang dianggap mengetahui semua hal yang bertujuan untuk mendapatkan data dan informasi yang berkaitan dengan proses bisnis Dinas Tata Kota, Bangunan dan Permukiman
78
Kota Tangerang Selatan. Penelitian ini menggunakan wawancara untuk mengumpulkan data yang diperlukan berkaitan dengan proses bisnis perusahaan dan aliran input-proses-output untuk mempertahankan dan mengembangkan bisnis serta untuk meningkatkat profit perusahaan. Dari hasil wawancara tersebut, kemudian dikumpulkan data dan informasi berupa tugas dan fungsi tiap-tiap unit kerja, permasalahan apa saja yang dihadapi dalam pelaksanaan tugas dan fungsi unit kerja, serta pemanfaatan TI terhadap tiap-tiap unit kerja. Berikut beberapa daftar pertanyaan yang dimaksud: 1.
Bagaimana gambaran secara umum mengenai aktifitas bisnis yang ada pada Dinas tata Kota, Bangunan dan Permukiman?
2.
Bagaimana dengan pengelolaan Sistem informasi yang ada pada Dinas tata Kota, Bangunan dan Permukiman?
3.
Apa yang menjadi fokus bisnis utama pada Dinas tata Kota, Bangunan dan Permukiman?
4.
Apakah Dinas tata Kota, Bangunan dan Permukiman sudah memiliki Enterprise Architecture?
5.
Bagaimana mengenai infrastruktur jaringan yang ada pada Dinas tata Kota, Bangunan dan Permukiman?
Tabel transkrip wawancara yang dilakukan di Dinas tata Kota, Bangunan dan Permukiman dengan dua narasumber dalam wawancara ini akan dilampirkan pada halaman lampiran 1.
79
3.1.3
Metode Studi Pustaka Metode studi pustaka ini dilakukan dengan cara mencari sumber data
sekunder yang akan mendukung penelitian. Metode ini dilakukan dengan mengumpulkan data dan informasi yang dijadikan sebagai acuan perancangan model Enterprise Architecture, referensi-referensi tersebut berasal dari buku-buku terkait maupun publikasi dari hasil penelitian, artikel, situs internet serta sumber informasi lain yang berkaitan dengan penelitian ini diantaranya mengenai konsep sistem informasi, enterprise architecture, TOGAF, TOGAF ADM, serta meliputi tools yang digunakan dalam perancangan enterprise architecture ini. 3.1.4
Studi Literatur
Tabel 3.1 Perbandingan Penelitian Sejenis
Penulis/Tahun Vivi Pratiwi
Judul
Kekurangan & Kelebihan
Keterangan
Fidyani Perancangan
Kelebihan
Menghasilkan
Model
sebuah prinsip dalam
penelitian
Enterprise
pembuatan arsitektur
menghasilkan
Architecture
perusahaan
sebuah
dengan
menghasilkan
dalam pembuatan
Menggunakan
blueprint rancangan
arsitektur
TOGAF Satya Utama
PT. arsitektur, Karya perancangan enterprise
dan
namun
prinsip
perusahaan, dan menghasilkan blueprint
80
architecture
hanya
rancangan
sampai pada tahap ke empat saja, yaitu tahap
arsitektur
technology
Kekurangan perancangan
architecture.
enterpeise architectire hanya
sampai
dengan taha[ ke empat saja.
Anis
Perancangan
Merancang
Khairunnisa
Strategis
perencanaan
Sistem
strategis
Informasi
menghasilkan
menggunakan
blueprint
dan
TOGAF pada roadmap.
Namun
Kelebihan penelitian
dan
menghasilkan perencanaan strategis
dan
menghasilkan
PT. Dian Nikel penempatan
hanya
blueprint
Mining
dalam
roadmap.
dilakukan
ini
beberapa
fase
arsitektur
bisnis,
dan
Kekurangan ada di
penempatan
sistem informasi dan
hanya dilakukan
teknologi,
belum
dalam
beberapa
dijelaskan
dalam
fase
arsitektur
fase TOGAF ADM.
bisnism
sistem
81
informasi teknlogi
dan namun
belum dijelaskan dalam
fase
ADM. Muchtar Aham
Rancang
Merancang
dan
Kelebihan
pada
Bangun
mengimplementasika
penelitian
ini
Arsitektur
n
adalah penelitian
Teknologi
teknologi informasi
areitektur
Informasi pada menggunakan Pelayanan
TOGAF
dilakukan mengenai
ADM,
arsitektur
Rumah Makan namun sistem hanya
teknologi
menggunakan
informasi
terfokus
pada
TOGAF ADM. pelayanan
dan
pembayaran saja.
menggunakan TOGAF. Kekurangan sistem terfokus pelayanan
hanya pada dan
pembayaran saja. Raimond Lukito Perencanaan
Meyusun
Widiatmo
Strategis
SI/TI
Sistem
Kabupaten
bagi
ususlan
Kelebihan
pada
emda
penelitian
ini
Sumba
adalah
82
Informasi/Tek
Barat
agar
tata
menghasilkan
nologi
laksana dan sistem
model enterprise
Informasi
administrasi
architecture yang
menggunakan
pemerintahan dapat
dapat digunakan
kerangka
berjalan lebih efektif
sebagai pandual
TOGAF (Studi dan efisien, namun
pengelolaan
Kasus: Pemda perancangan
SI/TI
EA
dalam
Kabupaten
hanya pada sampai
jangka waktu 5
Sumba Barat)
tahap
tahun kedepan.
technology
architecture saja.
Kekurangannya adalah perancangan EA hanya
sampai
dengan tahap ke empat saja.
83
3.2
Metode Perancangan Enterprise Architecture Untuk metodologi perancangan Arsitektur Teknologi Informasi adalah
menggunakan metodologi TOGAF ADM. Ada enam tahap dalam metodologi TOGAF ADM yang digunakan penulis yaitu: 3.2.1
1.
Tahapan TOGAF
Fase Preliminary Fase ini tentang mendefinisikan bagaimana melakukan perancangan
diperusahaan yang bersangkutan. Pada fase ini akan dilakukan beberapa tahapan sebagai berikut: 1.
Menentukan prinsip-prinsip sebagai acuan pengembangan arsitektur. Prinsip-prinsip tersebut juga memodelkan karakteristik dari arsitektur teknologi informasi yang akan dikembangkan.
2.
Menentukan scope dari apa yang akan dibuat (What).
3.
Menentukan siapa saja actor yang terlibat dalam pengembangan arsitektur (Who).
4.
Menentukan dimana lokasi objek perancangan enterprise architecture yang akan dibuat (Where).
5.
Menentukan kapan tanggal mulai dan target penyelesaian arsitektur (When).
6.
Menetapkan mengapa arsitektur ini dibangun (Why).
84
7.
Mendefinisikan bagaimana (How) rancangan enterprise architecture ini dibuat.
2.
Architecture Vision (Phase A) Dalam fase ini bertujuan untuk menciptakan keseragaman pandangan
mengenai pentingnya enterprise architecture untuk mencapai tujuan organisasi yang dirumuskan dalam bentuk strategi serta menentukan lingkup dari arsitektur yang akan dikembangkan, untuk itu penulis menguraikan beberapa langkah untuk menentukan visi arsitektur, yaitu: 1.
Menentukan dan mendefinisikan visi perusahaan.
2.
Menentukan seluruh aktifitas proses kerja perusahaan.
3.
Menentukan dan mendefinisikan actor.
4.
Merancang solusi visi arsitektur.
Tools yang digunakan pada fase ini adalah Value chain diagram.
3.
Business Architecture ( Phase B ) Dalam fase ini bertujuan untuk membuat model bisnis (proses, fungsi dan
aktifitas) yang diinginkan berdasarkan skenario bisnis yang sudah didefinisikan pada tahapan Visi arsitektur. Untuk penjelasan alur bisnis ini dapat menggunakan salah satu modeling UML yaitu Business Use Case Diagram. Adapun keluaran atau hasil dari fase ini adalah: 1.
Mengidentifikasi sejarah perusahaan.
85
2.
Menjelaskan struktur organisasi usulan beserta definisinya.
3.
Rancangan arsitektur bisnis dengan menggunakan model use case.
Tools yang digunakan pada fase ini adalah: Business Use Case Diagram, Organization Catalog. 4.
Information Systems Architecture (Phase C)
Pada fase arsitektur bisnis sistem informasi ini membahas arsitektur data dan arsitektur aplikasi yang didefinisikan berdasarkan hasil keluaran dari Arsitektur bisnis yang sudah dibuat. Fase ini menekankan bagaimana arsitektur sistem informasi dibangun meliputi arsitektur data dan arsitektur aplikasi yang akan digunakan oleh Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan.
Arsitektur Aplikasi Pada arsitektur aplikasi, dilakukan dengan mengidentifikasi kandidat
aplikasi, menentukan jenis aplikasi yang dibutuhkan untuk memproses data dan mendukung bisnis, serta membuat pemodelan arsitektur aplikasi. Beberapa tahapannya yaitu sebagai berikut: 1.
Mengidentifikasi aplikasi-aplikasi yang akan dirancang.
2.
Memodelkan aplikasi-aplikasi yang akan dirancang.
3.
Menjelaskan manfaat atau fungsi aplikasi yang dirancang.
4.
Pemodelan menggunakan Activity Diagram.
86
Tools yang digunakan yaitu: Activity Diagram, Aplication Portfolio Catalog.
Arsitektur Data Pada arsitektur data, dilakukan dengan mengidentifikasi seluruh
komponen data yang akan digunakan oleh aplikasi untuk menghasilkan informasi yang dibutuhkan organisasi. untuk fase arsitektur data diuraikan beberapa tahapan sebagai berikut: 1.
Memodelkan data yang digunakan setiap aplikasi yang akan dirancang pada arsitektur aplikasi.
2.
Pada arsitektur data, perancangan menggunakan Class Diagram. Dalam Arsitektur Data digunakan tools: Class Diagram.
5.
Technology Architecture (Phase D) Tujuan fase arsitektur teknologi adalah untuk mendefinisikan teknologi-
teknologi utama yang dibutuhkan. Untuk fase arstektur teknologi diuraikan beberapa tahapan sebagai berikut: 1.
Mendefinisikan konfigurasi jaringan awal.
2.
Menetapkan konfigurasi jaringan usulan.
3.
Menentukan jenis kandidat teknologi dari sisi software dan hardware yang diperlukan.
4.
Mempertimbangkan alternatif-alternatif yang diperlukan dalam usulan pemilihan teknologi.
87
Tools yang dipakai dalam fase ini yaitu: Communications Engineering Diagram, Platform Technology, Technology Portofolio Catalog.
6.
Opportunities & Solutions (Phase E)
Pada tahapan ini akan diuraikan tahapan sebagai berikut: 1.
Mengevaluasi model yang telah dibangun untuk semua arsitektur (Bisnis, Aplikasi, Data, dan Teknologi.
2.
Mengidentifikasi hubungan arsitektur data antar aplikasi.
3.
Dalam tahapan ini rancangan dibuat menggunakan Matrik Analisis Gap.
Tools yang digunakan pada fase ini yaitu: Matrix Analysis GAP. 7.
Migration Planning (Phase F)
Pada fase ini bertujuan untuk perencanaan migrasi untuk menghasilkan pemahaman aplikasi yang nantinya akan digunakan oleh user. Pada tahapan fase perencanaan migrasi ini akan dilakukan beberapa tahap berikut: 1.
Melakukan penyusunan proyek-proyek berdasarkan prioritas dari berbagai perspektif (perspektif manajemen dan operasional) dan manfaat dari proyek migrasi.
2.
Membuat daftar urutan prioritas proyek yang akan berjalan untuk membentuk dasar dari perencanaan implementasi detail dan rencana migrasi.
88
3.
3.2.2
Menetapkan roadmap aplikasi perusahaan.
Alasan Penulis Menggunakan TOGAF ADM TOGAF merupakan kerangka kerja arsitektur yang memberikan
gambaran-gambaran diantaranya desain, perencanaan, implementasi dan tata kelola arsitektur pada perusahaan. Alasan penulis menggunakan TOGAF ADM karena pada TOGAF terdapat metode-metode yang detail (fase-fase), serta memiliki tools yang dapat membantu dalam perencanaan enterprise architecture pada Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan.
89
3.3
Kerangka Berpikir Penelitian Adapun kerangka berpikir penelitian yang dilakukan pada penulisan
skripsi ini adalah sebagai berikut:
Mulai
Tahap Pengumpulan Data
Tahap Perancangan Enterprise Architecture (TOGAF ADM)
Melakukan Observasi
Metode Observasi (Jogiyanto, 2008)
Melakukan Wawancara
Metode Wawancarai (Nazir, 2005)
Melakukan Studi Literatur
Metode Studi Literaturi (Nazir, 2005)
Melakukan Studi Pustaka
Metode Studi Pustaka (Nazir, 2005)
TOGAF 9, The Open Group (2009)
TOGAF 9, Architecture Development Methodology F. Migration Planning
A. Architecture Vision REQUIREMENTS
E. Opportunities And Solutions
B. Business Architecture
D. Technology Architecture
C. Information Systems Architecture
Blue Print
Selesai
Gambar 3.1 - Kerangka Berpikir
90
Tabel 3.2 Daftar Simbol Kerangka Penelitian
No
Nama Simbol
1.
Mulai / Selesai
Gambar Simbol
Keterangan Mendeskripsikan permulaan penelitian
2.
Tahapan
Mendeskripsikan tahapan penelitian yang akan dilakukan
3.
Metode
Mendeskripsikan metode yang digunakan perproses
4.
Proses
Mendeskripsikan
proses
penelitian. 5.
Relasi
Mendeskripsikan proses
6.
Petunjuk
Menunjukkan yang digunakan.
aliran
metode
i
91
BAB IV PERANCANGAN ENTERPRISE ARCHITECTURE
Bab ini berisi tentang analisis yang dilakukan pada Dinas Tata Kota Bangunan Dan Permukiman serta perancangan Enterprise Architecture (EA) menggunakan framework TOGAF ADM yang dimulai dari preliminary phase, architecture vision, architecture business, information system architecture, technology architecture, opportunities and soutions, sampai migration planning. 4.1
Preliminary Phase Fase preliminary pada tahap ini merupakan tahap persiapan perusahaan
arsitektur enterprise, ini dilakukan agar proses pemodelan arsitektur dapat terarah dengan baik. Pada tahap ini didefinisikan bagaimana arsitektur enterprise akan dibuat. Prinsip-prinsip dimaksudkan untuk menyediakan suatu panduan bagi pengambilan keputusan arsitektur teknologi informasi, menentukan struktur dan komposisi komponen-komponen arsitektur, menentukan kriteria pemilihan teknologi dan produk, serta dalam perencaaan dan pengimplementasian arsitektur. Selain itu prinsip-prinsip arsitektur juga menggambarkan karakteristik dari arsitektur teknologi informasi yang akan dikembangkan. Sebagai acuan pengembangan, akan digunakan prinsip-prinsip arsitektur sebagai berikut: Keputusan arsitektur harus mengacu pada tujuan strategis dan proses bisnis pada Dinas Tata Kota, Bangunan dan Permukimanan.
91
92
2.
Dalam pengelolaan arsitektur ini diusahakan mudah. Hasil dari kerja prinsip ini adalah dapat membantu kerjasama antar divisi.
3.
Arsitektur yang dikembangkan harus aman.
4.
Data dan informasi harus dilindungi dari akses oleh pihak-pihak yang tidak berwenang.
5.
Arsitektur
dirancang
agar
mudah
melakukan
penambahan
dan
pengembangan. 6.
Penerapan arsitektur multi-tier dan arsitektur berbasis komponen.
7.
Menggunakan open technology.
8.
Definisi dari data harus konsisten di semua bagian organisasi, harus dikelola sebagai suatu aset, data harus tersedia bagi pihak yang membutuhkan dalam tugasnya, serta harus ada pemilik yang bertanggung jawab atas kualitasnya.
Setelah kerangka dibuat, maka tahap selanjutnya adalah menetapkan prinsip-prinsip yang akan digunakan. Pada tabel 4.1 menggambarkan segala principle yang akan
dipakai. Ini dapat dilihat jelas pada principle catalog
dibawah ini: 4.1.1
Prinsip-prinsip Perancangan Enterprise Architecture (EA) Prinsip-prinsip berikut ini untuk memberikan bimbingan kepada proses
pengambilan keputusan arsiteltur teknologi informasi, menentukan struktur dan komposisi dari komponen arsitektur, menentukan kriteria untuk memilih
93
teknologi dna produk yang akan digunakan, dan juga dalam desain arsitektur dan implementasi. Prinsip-prinsip yang akan digunakan sebagai acuan dalam perancangan adlaah sebagai berikut: 1. Keputusan arsitektur yang dibuat harus sesuai dengan tujuan, aktivitas, serta proses bisnis di Dinas Tata Kota, Bangunan, dan Permukiman Kota Tangerang Selatan. 2. Arsitektur yang dikembangjan harus mendukung kesinambungan bisnis. 3. Arsitektur yang dikembangkan harus aman. 4. Dara (informasi) dan sistem harus dilindungi dari akses oleh pihak-pihak yang tidak berwenang. 5. Data yang mudah diakses. 6. Perancangan arsitektur aplikasi yang mudah digunakan. 7. Penerapan arsitektur multi-tier dan arsitektur berbasis komponen. 8. Independensi teknologi.
Setelah prinsip-prinsip sudah ditetapkan maka dibuat tabel principle catalog untuk lebih menggambarkan prinsip-prinsip yang akan dipakai oleh Dinas Tata Kota, Bangunan, dan Permukiman Kota Tangerang Selatan dan menjelaskan tujuan dari setiap prinsip-prinsipnya.
94
Tabel 4.1 Principle Catalog No
Prinsip
Tujuan
1.
Keputusan arsitektur harus
Mendukung kemampuan adaptasi
mengacu
pada
tujuan
strategis dan proses bisnis pada
Dinas
Tata
terhadap proses bisnis Memperkuat
hubungan
antara
Kota,
infrastruktur dan proses bisnis
Bangunan dan Pemukiman.
serta lebih mudah menyelaraskan proses bisnis ketika perubahan terjadi.
2.
Pengelolaan arsitektur ini diusahakan mudah.
Meningkatkan kemampuan untuk berbagi data dan sumber daya lain dalam
pelayanan
pengguna
kepada
dan
membantu
kerjasama antar divisi. 3.
Arsitektur
yang
dikembangkan harus aman.
Dapat meminimalisasi dampak atas bencana alam. Mampu bertahan dari serangan eksternal seperti virus, worm, hack, syware, crack, phising, denial of service.
4.
Data
Previlege
(Perlindungan Data)
Untuk melindungi pihak-pihak
dari akses
yang
tidak
95
berwenang. Mengatur
stakeholder
dalam
mengolah data. 5.
Arsitektur dirancang agar mudah
melakukan
cepat apabila ada perubahan yang
dan
dapat berakibat pada infrastruktur
penambahan pengembangan. 6.
Memungkinksn respon yang lebih
yang bersifat adaptif.
Penerapan arsitektur multi-
Memudahkan
tier dan arsitektur berbasis
penggantian
komponen.
rusak
kegiatan komponen
yang
(meningkatkan
availability). Memudahkan
duplikasi
dan
upgrading modul. 7.
Menggunakan technology.
open
Menghindari ketergantungan pada vendor. Menjamin dukungan produk yang kuat terhadap teknologi. Meminimalisasi training manusia yang harus dilakukan setiap kali ada perubahan dalam
pilihan
vendor. 8.
Data yang konsisten.
Tersedianya kebutuhan bagi pihak
96
yang membutuhkan. Meminimalkan kerancuan
resiko
akan
jika
pengembangan
yang
ada akan
dikerjakan.
4.1.2
Identifikasi 5W+1H
Setelah prinsip-prinsip beserta tujuannya sudah sudah ditentukan, maka langkah berikutnya adalah mengidentifikasi 5W+1H dalam perancangan arsitektur ini untuk Dinas Tata Kota, Bangunan dan Pemukiman.
Tabel 4.2 5W+1H No
Driver
1.
What
Deskripsi Objek: Lingkup arsitektur
Deskripsi:
Membuat
perancangan
model
enterprise architecture 2
Who
Objek: Siapa saja actor utama yang terlibat dalam pemodelan enterprise arsitektur ini
Deskripsi:
Pemodelan: Ines Putri Karunia
97
3.
How
Tanggung Jawab: Staff TI dan Organisasi
Objek: Menentukan bagaimana rancangan dibuat
Deksripsi: menggunakan motodologi TOGAF ADM 4.
When
Objek: Waktu penyelesaian framework
Deksripsi: Oktober 2014 5.
Why
Objek: Mengapa arsitektur ini dibangun
Deskripsi:
Agar
perusahaan
mempunyai
landasan dalam pembuatan kebijakan yang meliputi tujuan dan sasaran, penyusunan strategi, pelaksanaan program dan fokus kegiatan serta langkah-langkah atau implementasi yang harus dilaksanakan oleh perusahaan 6.
Where
Objek: Menunjukkan lokasi kerja dan organisasi
Deskripsi: Dinas Tata Kota, Bangunan dan Pemukiman Kota Tangerang Selatan
98
4.2
Requirement Management Pada fase requirement management mempunyai tujuan untuk menentukan
kebutuhan proses dalam perancangan enterprise architecture pada Dinas Tata Kota, Bangunan, dan Permukiman Kota Tangerang Selatan. Dalam fase requirement management dibutuhkan skenario aktivitas yang menckup core business, proces business, dan issue organisasi. Tetapi, sebelum mengembangkan skenario aktivitas, terlebih dahulu untuk menganalisa sistem yang sedang berjalan di DTKBDP.
4.2.1
Kondisi Sistem Berjalan Pada bagian ini akan menggambarkan sistem yang sedang berjalan dengan
rich picture untuk masing-masing aktivitas di DTKBDP, yaitu, permohonan IMB dan SLF, pembangunan bangunan, proses lelang proyek, manajemen keuangan, sumber daya manusia, inventaris dan perencanaan bisnis strategis.
99
28. Menerima Laporan Inventaris 27a. Menyerahkan data inventaris 27. Menyerahkan data inventaris
Bagian Rumah Tangga 31. Pengajuan Rekomendasi SLF Pemkot 25. Meminta laporan progress bangunan
24.Memberikan data progress pembangunan
Sie. Pengawasan Bangunan
29. pencatatan akuntansi
Sie. Data dan Informasi
26. Memberikan laporan progress pembangunan
16. Pengesahan surat rekomendasi SLF
Kepala Dinas
11. Pengesahan surat rekomendasi IMB
15. Proses pemerikasaan bangunan gedung
Pemerikasaan lapangan
Subbag. Tata Usaha
13. Pemeriksaan berkas administrasi SLF
17. Memberikan surat rekomendasi SLF
Bag. Keuangan
Tim panitia SLF
10. Menyerahkan rekomendasi IMB
19. Menyerahkan DPA
14. Konfirmasi kelengkapan berkas administrasi SLF 6. Pemeriksaan berkas administrasi
1. Menyerahkan berkas administrasi IMB
18. Memberikan hasil musrembang
2. konfirmasi kelengkapan Berkas administrasi IMB
7. Konfirmasi kelengkapan berkas
30. Pengajuan IMB Musrembang
12. Menyerahkan Surat rekomendasiIMB
pemohon
sekretariat
Pemerintah Kota
3. Melakukan proses Sidang 1
5. Mendapat rekomendasi Site plan
20. Menyerahkan daftar proyek
4. Melaksanakan pemeriksaan lapangan/survey
TABG Tim survey
8. melakukan proses Sidang 2 9. pemeriksaan berkas administrasi
Proses Sidang
Bidang Teknik 21. Menyerahkan hasil design
22. Melaksanakan proses lelang
23. Pembangunan
Kontraktor Proses Lelang
Gambar 4.1 Sistem Berjalan
Bidang bangunan
100
Pemohon yang ingin membuat sertifikat permohonan IMB dan SLF, datang ke kantor DTKBDP dan mengisi formulir IMB serta menyerahkan berkasberkas pengajuan rekomendasi IMB, apabila berkas dianggap sudah lengkap dan memenuhi syarat maka bagian sekretariat akan mengkonfirmasi berkas tersebut, tetapi apabila berkas belum lengkap berkas akan dikembalikan kepada pemohon untuk dilengkapi. Apabila berkas tersebut sudah lengkap, maka bagian sekretariat akan melakukan sidang pertama, sidang pertama berisikan tentang kelengkapan berkas IMB. Setelah selesai melaksanakan sidang, maka tim survey akan melakukan survey pada lokasi yang nantinya akan didirikan bangunan, survey tersebut menghasilkan site plan dan diberikan kepada pemohon.
Setelah itu akan
dilakukan proses pemeriksaan berkas administrasi yang diberikan kepada TABG, setelah dikonfirmasi maka akan dilakukan proses sidang kedua yang merupakan revisi dari kelengkapan berkas pada sidang pertama kemudian diberikan kepada TABG untuk ditindak lanjuti. Setelah itu memberikan rekomendasi IMB kepada bagian sekretariat dan disahkan oleh kepala dinas kemudian diberikan kepada pemohon. Setelah rekomendasi IMB diberikan, maka pemohon memberikan berkas administrasi SLF (Sertifikat Layak Fungsional), kepada panitia SLF dan dikonfirmasi kepada pemohon. Dilakukan pemeriksaan bangunan gedung oleh pemeriksa lapangan, disahkan oleh kepala dinas dan panitia SLF memberikan rekomendasi SLF kepada pemohon. SLF berisi tentang kecocokkan bangunan yang sudah dituliskan pada isi rekomendai IMB sebelumnya.
101
Pada proses pembangunan atau perbaikan gedung atau sarana dan parasaran pemerintahan atau non pemerintahan, maka pemerintah kota Tangerang Selatan memberikan hasil musyawarah rembuk bangunan (Musrembang) yang didapat dari keluhan dari internal pemerintahan atau eksternal dari masyarakat sekitar tentang sarana dan prasarana didaerah kota TangSel yang harus diperbarui atau dibangun untuk kebutuhan masyarakat atau pemerintah. Setelah hasil musrembang didapat dan diberikan kepada bagian sekretariat, kemudian pemerintah kota memberikan daftar anggaran (DPA) kepada bagian keuangan. DPA tersebut nantinya akan disesuaikan dengan bangunan yang akan dibangun. Pemerintah kota
menyerahkan daftar proyek kepada bidang teknik untuk
dibuatkan design sesuai yang diharapkan, kemudian design tersebut diberikan kepada bidang bangunan untuk melaksanakan proses lelang. Apabila kontraktor sudah sesuai dengan perjanjian dengan DTKBDP, maka kontraktor tersebut bisa langsung mendirikan bangunan sesuai design yang sudah diberikan. Setelah mendapatkan kontraktor yang sesuai, dan proses pembangunan sedang berjalan, maka bidang bangunanan mengajukan rekomendasi IMB untuk pembangunan pemerintahan ke sekretariat. Seiring berjalannya proses pembangunan atau bahkan pembangunan bangunan yang sudah selesai, diperlukan pemeriksaan bangunan secara berkala. Pemeriksaan bangunan dilakukan untuk mengetahui kondisi detail setiap bangunan, dari kondisi fisik atau kondisi material yang harus diperbaiki. Data progress bangunan dikelola oleh pengawas bangunan dan data tersebut diberikan kepada sie. Data dan informasi dan diberikan kepada kepala dinas sebagai laporan
102
progress bangunan didaerah Tangerang Selatan. Setelah progress bangunan selesai, maka bagian sie. Data dan Informasi mengajukan SLF ke sekretariat, karena SLF berisi tentang kondisi fisik bangunan yang harus disesuaikan dengan isi IMB. Bagian Subbag. Tata Usaha melakukan pencatatan akuntansi dan membuat laporan periode keuangan kemudian diberikan kepada bagian keuangan. Pencatatan masih menggunakan ms.office kemudian di print, sehingga terkadang laporan tersebut terselip oleh berkas-berkas lainnya.
1.
Flowchart Level 0
Rekomendasi IMB & SLF
Pendataan Hasil Musrembang
Design
Lelang Proyek
Pembangunan Pengecekkan Progress Bangunan
Keuangan
Inventaris
Gambar 4.2 Flowchart Sistem berjalan Level 0
Flowchart pada level 0 menggambarkan semua proses grup yaitu aktivitas utama dan aktivitas pendukung yang ada pad Dinas Tata Kota, Bangunan, dan
103
Permukiman Kota Tangerang Selatan. Proses grup untuk aktivitas utama, yaitu, rekomendasi IMB dan SLF, pendataan hasil musrembang, design, lelang proyek dan pembangunan. Proses grup untuk aktivitas pendukung adalah keuangan dan inventaris. Pada gambar di atas, terdapat arah dan warna tanda panah yang menunjukan apakah proses group tersebut saling berkaitan dengan proses group lainnya dengan alur aktivitas searah atau bolak balik. Pada proses group rekomendasi IMB dan SLF memiliki tanda panah berwarna hitam menuju proses pendataan hasil musrembang, design, lelang proyek dan sampai pada proses group pengecekkan progress bangunan. Laporan yang dikirim hanya akan menjadi laporan pasif alur aktivitasnya adalah satu arah. Pada proses group aktivitas pendukung mempunyai panah berwarna merah, yaitu proses group keuangan dan inventaris yang hanya terlibat pada pendataan hasil musrembang untuk melakukan pencatatan laporan DPA (detail pagu anggaran) pada setiap proyek yang nantinya di bangun. Sedangkan inventaris hanya untuk melakukan pencatatan BMN (barang milik negara) yang digunakan di DTKBDP.
104
2. Flowchart Level 1 a. Rekomendasi IMB Mulai
Pendaftaran
Upload Berkas IMB
Pengecekkan berkas IMB
Konfirmasi kelengkapan berkas IMB
Sidang
Survey lapangan
Mendapat siteplan
Cetak rekomendasi IMB
Selesai
Gambar 4.3 Flowchart Sistem Berjalan Bagian Rekomendasi IMB.
105
Pada flowchart
sistem berjalan bagian rekomendasi IMB di level 1,
digambarkan bahwa ada 8 proses yaitu pendaftaran, upload berkas IMB, pengecekkan berkas IMB, konfirmasi kelengkapan berkas IMB, sidang, survey lapangan, mendapat siteplan, cetak rekomendasi IMB. b. Rekomendasi SLF
Mulai
Upload berkas SLF
Pengecekkan berkas SLF
Konfirmasi kelengkapan berkas SLF
Pengecekkan kontruksi bangunan
Cetak rekomendasi SLF
selesai
Gambar 4.4 Flowchart Sistem Berjalan Bagian Rekomendasi SLF
106
Pada flowchart sistem berjalan rekomendasi SLF di level 1, digambarkan bahwa ada 5 proses yaitu proses upload berkas SLF, pengecekkan berkas SLF, konfirmasi berkas SLF, engecekkan kontruksi bangunan dan cetak rekomendasi SLF. c. Pendataan Hasil Musrembang Mulai
Pengecekkan hasil musrembang
Penyerahan data proyek
Mendapat DPA (Detail Pagu Anggaran)
Selesai
Gambar 4.5 Flowchart Sistem Berjalan Bagian Pendataan Hasil Musrembang
Pada flowchart sistem berjalan bagian pendataan hasil musrembang di level 1, digambarkan bahwa ada 3 proses yaitu proses pengecekkan hasil musrembang, penyerahan data proyek dan mendapat DPA. Pada proses pertama hasil musrembang di dapat dari rapat antar warga atau bagian pemerintahan yang
107
nantinya akan dilakukan perbaikan atau pembangunan sarana dan prasarana pemerintahan dan non pemerintahan di Tagsel. Setelah pengecekan hasil musrembang, maka akan didaptkan DPA yang sudah di sesuaikan dengan anggaran pembangunan yang nantinya akan dibangun. d. Design Mulai
Pembuatan design sesuai proyek
Pelaksanaan lelang
Pembangunan
Selesai
Gambar 4.6 Flowchart Sistem Berjalan Bagian design Pada flowchart sistm berjalan bagian design di level 1, digambarkan bahwa ada 3 proses yaitu proses pembuatan design seuai proyek, pelaksanaan lelang dan pembangunan.
108
e. Progress Bangunan
Mulai
Pengamatan progress bangunan
Pengecekkan kontruksi bangunan
Pembuatan laporan progress bangunan
Selesai
Gambar 4.7 Flowchart Sistem Berjalan Bagian progress bangunan Pada flowchart sistem berjalan bagian progress bangunan di level 1, digambarkan bahwa ada 3 proses, yaitu pengamatan progress bangunan, pengecekkan kontruksi bangunan dan pembuatan laporan progress bangunan. Progres bangunan dilakukan pada saat pembangunan sedang dilaksanakan, fungsinya adalah untuk mengetahui secara rinci setiap tahapan proses pembangunan.
109
f. Keuangan Mulai
Penyusunan rencana anggaran
Membuat dokumen pelaksanaan anggaran
Pengesahan dokumen pelaksanaan anggaran
Melaksanakan akuntansi keuanagan
Membuat laporan keuangan
Selesai
Gambar 4.8 Flowchart Sistem Berjalan Bagian Keuangan Pada flowchart sistem berjalan bagian keuangan level 1, digambarkan bahwa ada 5 proses, yaitu penyusunan rencana anggaran, membuat dokumen pelaksanaan
anggaran,
pengesahan
dokumen
pelaksanaan
anggaran,
melaksanakan akuntansi keuangan dan membuat laporan keuangan. Laporan keunagn tersebut nantinya akan dilaporkan kepada bagian administrasi DTKBDP.
110
g. Inventaris Mulai
Melakukan pencatatan BMN (Barang Milik Negara)
Menyusun laporan barang pengguna inventaris
Membuat laporan pengelola pengguna inventaris setiap bagian
Selesai
Gambar 4.9 Flowchart Sistem Berjalan Bagian Inventaris pada flowchart sistem berjalan bagian inventaris level 1, terdpat 3 proses yaitu, melakukan pencatatan BMN, menyusun laporan barang pengguna BMN dan membuat laporan pengelola pengguna inventaris setiap bagian.
4.2.2
Issue Organisasi
Berdasarkan dari hasil pengamatan dan analisis yang dilakukan pada seluruh aktivitas, maka didapatan beberpaa permasalahan yang dia alami DTKBDP untuk memberikan dukungan SI/TI, seperti yang ditampilkan pada tabel 4.3 seperti berikut :
111
Tabel 4.3 Permasalahan dalam Aktivitas Organisasi No 1.
Aktivitas
Permasalahan
Pelayanan rekomendasi
IMB
dan SLF
Pengelolaan
Deskripsi
Pencatatan,
data
penyimpanan
dan
pendaftaran
pelaporan
data
rekomendasi
rekomendasi IMB dan
IMB dan SLF
SLF masih manual, dan terkadang terjadi redudancy data.
2.
Musrembang
Pelaporan
proyek
Pelaporan
proyek
masih
dicatat
menggunakan ms.office, mempunyai
belum suatu
aplikasi khusus dan terkadang data tidak tersimpan dengan baik dan sulit utuk dicari. 3.
Design
Penggambaran proyek
Pada
penggambaran
proyek penyimpanan gambar
hanya
menggunakan aplikasi seadanya,
terkadang
112
gambar banyak yang hilang karena tidak adanya penyimpanan data yang baik. 4.
Progress Bangunan
Pelaporan
Belum
adanya
progress
fasilitas
untuk
proyek
pengelolaan
data
progress
bangunan,
karena
pendataan
masih menggunakaan proses manual. 5.
Keuangan
Pencatatan
Keuangan
Proses
pencatatan
keuangan
masih
bersifat manual
Kesulitan mebuat
dalam laporan
keuangan yang cepat dan akurat 6.
Inventaris
Pendataan
inventaris barang
Pendataan
inventaris
barang masih manual
Kesulitan
dalam
pencatatan inventaris jika
ada
banyak
113
perubahan.
4.2.3
Solusi Aktivitas Pada bagian ini akan dianalisis solusi aktivitas untuk mengatasi
permasalahan-permasalahan pada setiap aktivitas Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan. Solusi yang diberikan pada bagian ini ditinjau dari sudut pandang proses kerja. Sasaran perbaikannya terfokus hanya pada alur kerja agar menjadi lebih baik. Solusi aktivitas yang sudah dianalisis dapat dilihat dalam tabel 4.4. Tabel 4.4 Solusi Aktivitas No. 1.
Aktivitas Pelayanan
Deskripsi Pencatatan,
Solusi Aktivitas
penyimpanan Perancangan aplikasi
rekomendasi
dan
IMB dan SLF
rekomendasi IMB dan SLF
pelaporan
masih
manual,
data IMB dan SLF.
dan
terkadang terjadi redudancy data. 2.
Musrembang
Pelaporan
dicatat ms.office,
proyek
masih Penyediaan fasilitas
menggunakan untuk pelaporan data belum proyek bangunan
mempunyai suatu aplikasi yang saling khusus dan terkadang data terintegrasi agar data
114
tidak tersimpan dengan baik dapat disimpan dan sulit utuk dicari.
3.
Design
dengan baik.
Pada penggambaran proyek Penyediaan fasilitas penyimpanan gambar hanya untuk pengelolaan menggunakan
aplikasi data design agar data
seadanya, terkadang gambar tersimpan dengan banyak yang hilang karena baik. tidak adanya penyimpanan data yang baik. 4.
Progress Bangunan
Belum untuk
adanya
fasilitas Penyediaan data untuk
pengelolaan
fasilitas pelaporan
progress bangunan, karena progress
bangunan
pendataan
masih yang nantinya mudah
menggunakaan
proses di
akses
perbagian
manual.
oleh didalam
organisasi 5.
Keuangan
Proses pencatatan keuangan Penyediaan fasilitas masih bersifat manual Kesulitan
dalam
laporan
keuangan
untuk pencatatan
mebuat keuangan yang saling yang terintegrasi.
cepat dan akurat 6.
Inventaris
Pendataan inventaris barang Penyediaan fasilitas
115
masih manual Kesulitan dalam pencatatan inventaris jika ada banyak
pelaporan data inventaris yang saling terintegrasi.
perubahan.
4.2.4
Data Inventaris Sarana dan Prasarana Pendukung TIK Pada saat ini, Dinas Tata Kota, Bangunan dan Permukiman Kota
Tangerang Selatan memiliki inventaris prasarana pendukung TIK yang terdapat dalam tabel 4.4 sebagai berikut : Tabel 4.5 Data Inventaris Sarana dan Prasarana Pendukung TIK No
Barang
Fungsi
Jumlah
1.
Komputer
Operasional
30
2.
Printer
Operasional
20
3.
Laptop
Operasional
10
4.
Mobile Modem
Operasional
5
4.3 Phase A : Architecture Vision 4.3.1 Profil Instansi Dinas Tata Kota, Bangunan dan Pemukiman terbentuk Berdasarkan Peraturan walikota No.59 Tahun 2009 dan terdiri atas 4 Bidang dan 1 Sekretariat yaitu :
116
4.3.2
Visi dan Misi Instansi Visi Instansi “Terwujudnya tata ruang, bangunan dan lingkungan pemukiman yang
modern, religius dan berkelanjutan pada tahun 2015 ”.
Misi Instansi a. Mewujudkan perencanaan yang transparan, efektif dan aplikatif b. Meningkatkan pelayanan perencanaan teknis sesuai standar mutu c. Meningkatkan kualitas manajemen dalam perumusan kebijakan pembangunan kota d. Mewujudkan perencanaan tata ruang yang modern dan serasi dengan lingkungan e. Mewujudkan dan mengendalikan ruang sesuai dengan fungsi dan peruntukannya f. Mewujudkan pusat pemerintahan yang handal dan berjati diri g. Mewujudkan pelayanan bidang bangunan yang aspiratif dan optimal h. Meningkatkan kualitas sanitasi lingkungan pemukiman i. Meningkatkan prasarana dan sarana dasar serta utilitas umum di pemukiman j. Mewujudkan pengelolaan sampah terpadu k. Mewujudkan hunian yang layak dan sehat
117
4.3.3
Struktur Organisasi dan Tupoksi DTKBDP
KEPALA DINAS Ir. DENDI PRYANDANA, MT (IV/b) NIP. 19661230 199603 1 00 1 SEKRETARIAT Ir. LISHERNI, M.Si (IV/B) NIP. 19660226 199303 2
KASI UMUM Ir. Hj. DENIWATI, MM (IV/a) NIP. 19650401 199803 1 006
SUBBAGIAN TATA USAHA DAN SDM
KASUBAG KEUANGAN Dra. IIS HASTATI ROCHIMAT (III/c) NIP. 19641213 200501 2 001
KASUBAG PEP RIKAS DIRGANTARI, ST, MT (IV/a) NIP. 19691130 200501 1 007
SUBBAGIAN RUMAH TANGGA
Bidang Tata Ruang TONNY SOEWANDI, ST (III/d) NIP. 19701030 199803 1 005
Bidang Perumahan CARSONO, S.ST, MM (III/d) NIP. 19691105 199101 1 001
Bidang Bangunan MUKODDAS SYUHADA, ST, MT (III/d) NIP. 19761028 200112 1 007
Bidang Teknik DEDENG DASA, ST (III/d) NIP. 19740420 200112 1 003
Seksi Perencanaan Tata Ruang H. BUDI FIRMANSYAH, ST, M.Si, M.Ak (III/c) NIP. 19690123 200212 1 002
Seksi Perumahan BUWANA MAHARDDIKA, ST (III/ d) NIP. 19780811 200112 1 003
Seksi Bangunan Gedung Pemerintahan HERI ASARI S.Kom, M.Si (III/b) NIP. 19800210 201001 1 001
Seksi Perenanaan ADI HERMAWAN, ST, MT (III/c) NIP. 19741005 200112 1 003
Seksi Pemetaan FARAH DIBA, ST, M.Si (III/c) NIP. 19790531 200604 2 002
Seksi Penataan Kawasan DIAN NUGRAHA, S.Kom (III/c) NIP. 19730124 200604 1 006
Seksi Bangunan Non Pemerintahan ASEEP HERMAWAN, ST (III/c) NIP. 19750807 200212 1 004
Seksi Pengawasan ACHMAD NASUHI, ST, MT (III/c) NIP. 19700416 199703 1 010
Seksi Pengendalian Pemanfaatan Ruang MUHAMMAD HAFIZ, ST (III/c) NIP. 19730707 200604 1 002
Seksi Penyehatan Lingkungan Permukiman (PLP) DEWAN RIDWAN, SE, MM (III/d) NIP. 19730923 200112 1 004
Seksi Pemeliharaan Gedung H. HERRY SURYADRMAWAN, S.Sos, MM (III/d) NIP. 19671226 200501 1 004
Seksi Data Informasi dan Pengujian TEGUH SUGARWONO, S.Sos (IV/d) NIP. 19691130 200501 1 007
Gambar 4.10 Struktur Organisasi DTKBDP
Dinas Tata Kota Bangunan dan Pemukiman mengepalai Sekretariat, Bagian Umum, Bidang Tata Ruang, Bidang Perumahan, Bidang Bangunan dan Bidang Teknik. Berikut ini merupakan tupoksi dari masing-masing bidang : 1.
Sekretariat, mempunyai tugas merencanakan, melaksanakan membina dan mengkoordinasikan serta melakukan pengendalian pada urusan umum, kepegawaian keuangan serta program, evaluasi dan pelaporan. Sekretariat menyelenggarakan fungsi:
118
a.
Pelaksanaan Bagian Umum yang meliputi Subbagian Tata Usaha dan SDM serta Subbagian Rumah Tangga.
b.
Pelaksanaan Bagian Keuangan
c.
Pelaksanaan Bagian PEP
Sekretariat terdiri dari: 1) Subbagian Umum dan Kepegawaian, mempunyai tugas merencanakan, melaksanakan pembinaan dan mengkoordinasikan serta pengawasan dan pengendalian sertifikat menyurat, kearsipan, urusan rumah tangga perlengkapan, pengelolaan administrasi dan kepegawaian. 2) Subbagian Keuangan, mempunyai tugas merencanakan, melaksanakan, pembinaan dan koordinasi serta pengawasan dan pengendalian penyusunan rencana anggaran dan belanja dinas. 3) Subbagian Program Evaluasi dan Pelaporan, mempunyai tugas Merencanakan, melaksanakan pembinaan dan koordinasi serta pengawasan dan pengendalian program, evaluasi dan pelaporan.
2.
Bidang Tata Ruang Merencanakan,
melaksanakan
pembinaan
dan
koordinasi
serta
pengawasan dan pengendalian program bidang pemanfaatan dan ruang, informasi dan bina masyarakat, perencanaan Tata Kota dan Informasi.
119
a.
Seksi Pemanfaatan dan Pengendalian kota Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi dan pembinaan penyelenggaraan Perencanaan, Pelaksanaan, pembinaan dan koordinasi, pengawasan serta pengendalian bidang pemanfaatan dan pengendalian Ruang.
b.
Seksi Informasi dan Bina Masyarakat Merencanakan,
melaksanakan
pembinaan
dan
koordinasi
serta
pengawasan dan pengedalian program Informasi dan Bina Masyarakat. c.
Seksi Perencanaan Penataan Kota Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi dan pembinaan, di bidang Perencanaan Penataan Ruang.
3.
Bidang Bangunan Merencanakan, melaksanakan pembinaan dan koordinasi serta pengawasan
dan pengendalian kegiatan tugas tata bangunan. a. Seksi Data dan Informasi Merencanakan, melaksanakan pembinaan koordinasi serta pengawasan dan pengendalian kegiatan pengolahan data dan informasi perencanaan bangunan dan Pemukiman b. Seksi Pengawasan Bangunan Merencanakan,
melaksanakan
Pengawasan Bangunan.
pembinaan,
koordinasi
kegiatan
120
c.
Seksi Pemeliharaan Gedung Merencanakan, melaksanakan pembinaan dan koordinasi, serta pengawasan dan pengendalian kegiatan pemeliharaan gedung.
4.
Bidang Perumahan dan Pemukiman Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi
dan pembinaan di Bidang Perumahan dan Pemukiman. a.
Seksi Perumahan Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi dan pembinaan di bidang Perumahan.
b. Seksi Air Bersih Perencanaan, pelaksanaan, pembinaan dan koordinasi, pengawasan dan pengendalian di Bidang Pengendalian Air bersih. c.
Seksi Penyehatan Lingkungan Pemukiman (PLP) Merencanakan, melaksanakan, pembinaan dan koordinasi, pengawasan dan pengendalian, pengkajian penyehatan lingkungan pemukiman.
5.
Bidang Teknik Penyusunan bahan perumusan kebijakan umum, penyelenggaraan fasilitasi,
pembinaan dan koordinasi perencanaan di bidang teknik.
121
a.
Seksi Perencanaan Penyusunan bahan perumusan kebijakan umum, penyelenggaraan fasilitasi dan pembinaan penyelenggaraan di bidang perencanaan.
b.
Seksi Pengawasan Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi dan pembinaan penyelenggaraan di bidang pengawasan.
c.
Seksi Pengujian/Laboratorium Penyusunan bahan perumusan kebijakan umum, penyelenggaraan, fasilitasi dan pembinaan penyelenggaraan di bidang pengujian / laboratorium.
4.3.4
Analisis Value Chain
Visi dari Dinas Tata Kota, Bangunan dan Pemukiman adalah terwujudnya tata ruang, bangunan dan lingkungan pemukiman yang modern, religius dan berkelanjutan pada tahun 2015. Sebelum membuat visi arsitektur-arsitektur yang akan dirancang, maka perlu mendefinisikan dan menganalisis seluruh proses kerja yang ada di Dinas Tata Kota, Bangunan dan Pemukiman menggunakan analisis value chain. Analisis value chain dilakukan untuk memetakan seluruh proses kerja yang terjadi dalam organisasi menjadi dua kategori aktifitas, yaitu aktivitas utama dan aktivitas pendukung. Aktivitas utama adalah aktivitas yang berhubungan sehingga proses
122
kerja dapat berjalan. Sedangkan aktivitas pendukung digunakan untuk mendukung dan mengawasi aktivitas utama.
Berikut diagram value chain pada DTKBDP :
Support Activities
m
Manajjhh
Manajemen Keuangan Sumber Daya Manusia
Inventarisvvh
Inventaris Perencanaan Bisnis Strategis
Primary Activities
Inbound Logistics : 1. Rekomendasi IMB 2. Hasil = Musrembang
Kepuasan Stakeholder
Operation:
Outbond:
Marketing:
Service:
1. Sidang 2. Survei Lokasi 3. DPA 4. Lelang Proyek
1. Rekomendasi IMB 2. Bangunan
1. Web
1. SLF 2. Pengecekan Progress Bangunan
Gambar 4.11 Value Chain
Aktivitas bisnis pada DTKBDP menurut analisa value chain sebagai berikut: 1.
Aktivitas Utama, yang terdiri dari: a. Inbound Logistic, pada DTKBDP aktivitas yang termasuk dalam inbound logistic
adalah
rekomendasi
permohonan
pembuatan
IMB
(Izin
Mendirikan Bangunan), DTKBDP menerima permohonan IMB dari pemohon yang akan mendirikan bangunan didaerah Tangerang Selatan. Pembuatan IMB dan SLF bisa dilakukan oleh pihak internal dan eksternal. Untuk pihak ekternal pembuatan IMB dan SLF tidak mencapai tahap
123
pembangunan oleh DTKBDP. Namun untuk internal DTKBDP dilakukan sampai tahap pembangunan sampai bangunan selesai. Pemerintah kota Tangerang Selatan menyerahkan hasil Musrembang (Musyawarah Rembuk Bangunan) pada bagian sekretariat yang kemudian akan mendata dan menyiapkan perencanaan bangunan didaerah tangsel. b.
Operation, aktivitas yang dilakukan untuk proses pelaksanaan dalam melakukan pembuatan rekomendasi IMB dan pembangunan bangunan sesuai hasil musrembang. Dalam tahap ini ada 4 langkah yang dilakukan: 1.
Sidang Aktivitas ini dilakukan pada saat pembuatan rekomendasi IMB, sidang dilakukan dengan beberapa tahapan utuk memerikasa kelengkapan berkas dan mengetahui rincian setiap bangunan yang nantinya akan didirikan.
2.
Survey Lokasi DTKBDP melakukan survey lapangan pada lahan yang nantinya akan didirikan bangunan, survey dilakukan oleh tim survey. Hasil dari survey lapangan ini berupa site plan atau gambaran kondisi pada lahan yang akan didirikan bangunan.
3.
DPA (Detail Pagu Anggaran) DPA ini merupakan detail pagu anggaran yang diberikan kepada DTKBDP. Anggaran ini didapatkan melalui BAPEDA (Badan Pengawas Daerah), anggaran ini diberikan sesuai rincian dari rapat
124
musrembang.
Dan
anggaran
ini
nantinya
digunakan
untuk
pembangunan bangunan dan fasilitas didaerah Tangerang Selatan. 4.
Lelang Proyek Aktivitas ini dilakukan pada saat bangunan yang akan dibangun sudah selesai didesign oleh bidang teknik, dan kemudian bidang bangunan melaksanakan proses lelang degan cara mencari kontraktor yang bersedia melaksanakan proses pembangunan bangunan sampai selesai.
c.
Outbound Logistic, aktivitas ini merupakan hasil akhir, setelah melakukan beberapa tahapan maka akan didapatkan rekomendasi IMB yang akan diberikan kepada pemohon dan hasil bangunan yang sudah didirikan.
d.
Marketing dan Sales, aktivitas ini berhubungan dengan informasi kepada masyarakat tentang DTKBDP kota Tangerang Selatan. Informasi melalui website merupakan aktivitas dalam rangka pengenalan tentang konsep kerja DTKBDP.
e.
Services, aktivitas yang dirancang untuk meningkatkan atau memelihara nilai produk/jasa. Pada DTKBDP, SLF merupakan sertifikat layak fungsional yang nantinya akan diberikan kepada pemohon apabila bangunan sudah sesuai dengan isi pada IMB. Pengecekkan progress bangunan dilakukan untuk mengontrol proses bangunan yang sedang dibangun.
2.
Aktivitas pendukung Aktivitas di DTKBDP (Dinas Tata Kota Bangunan dan Pemukiman) yang
termasuk ke dalam aktivitas pendukung dalam analisis value chain, yaitu
125
manajemen keuangan, sumber daya manusia, inventaris, perencanaan bisnis dan strategis. Berikut ini penjelasan aktivitas pendukung : a.
Manajemen Keuangan Merupakan aktivitas pendukung pada perusahaan, dimana sebuah perusahaan pada umumnya memiliki bagian atau divisi yang membidangi aktivitas-aktivitas ini. Aktivitas keuangan meliputi penyusunan rencana dan program anggaran, pengelolaan keuangan dan pembuatan laporan keuangan.
b.
Sumber Daya Manusia Aktivitas ini mempunyai fokus kepada usaha recruiting SDM yang mempunyai potensi, kemudian untuk sumber daya manusia yang sudah dimiliki diberi pelatihan-pelatihan untuk peningkatan kualitas SDM.
c.
Inventaris Aktivitas ini meliputi pencatatan dan pengelolaan barang milik negara, pengamanan sarana dan prasarana yang digunakan oleh DTKBDP. Pengelolaan dan pencatatan barang milik negara dilakukan oleh Subbagian Rumah Tangga. Tetapi, menjaga dan memelihara sarana dan prasarana dilakukan oleh seluruh pegawai DTKBDP yang sudah menggunakan sarana-prasarana tersebut.
d.
Perencanaan Bisnis dan Strategis Aktivitas ini mempunyai tujuan melakukan perencanaan bisnis dan strategis untuk menunjang rencana kegiatan yang akan dianggarkan satu
126
tahun kedepan dalam rangka memperbaiki sektor pembangunan didaerah Tangerang Selatan.
Tabel 4.6 Target Value Chain
Langkah dalam value chain Inbound Logistic
Aktivitas
Output yang diharapkan
1. Rekomendasi IMB
Penerapan pendaftaran online
2. Hasil Musrembang
Hasil akurat,
musrembang serta
yang
management
penyimpanan
musrembang
yang baik Operation
1. Sidang
Penerapan
penggunaan
2. Survey Lokasi
sistem pada proses sidang,
3. DPA
survey lokasi dan DPA
4. Lelang Proyek
Penerapan
penggunaan
sistem pada lelang proyek, agar mendapatkan kontraktor yang sesuai Outbond Logistic
1. Rekomendasi IMB
Hasil rekomendasi IMB yang akurat
serta
management
penyimpanan yang baik 2. Bangunan
Hasil
bangunan
sesuai
IMB
dan
dengan musrembang Marketing & Sales
Website
Pemberitahuan
informasi
127
tentang
DTKBDP
kota
Tangerang Selatan meluas kepada masyarakat Service
1. SLF
Sertifikat untuk kesesuaian pembangunan
dengan
isi
IMB 2. Pengecekkan Progress Proses pengecekkan untuk Bangunan
mengetahui
kondisi
pembangunan secara detail
Aktivitas Pendukung
1. Manajemen Keuangan
Laporan
keuangan
yang
tepat, akurat, terintegrasi dan real time
2. Sumber Daya Manusia
Pengembangan
kompetensi
setiap pegawai 3. Inventaris
Pencatatan dan pengelolaan barang
milik
pengamanan prasarana
negara,
sarana
dan
yang digunakan
oleh DTKBDP menggunakan sistem 4. Perencanaan Bisnis Strategis
Pengembangan strategis
untuk
bisnis
dan
menujang
rencana kegiatan yang akan dianggarkan
128
4.3.5
Struktur Organisasi Usulan Jika melihat struktur organisasi saat ini, DTKBDP belum memiliki
bagian yang khusus melakukan pengembangan dan perawatan untuk TI di DTKBDP. Sedangkan, jika akan mengimplementasikan arsitektur-arsitektur yang akan dibuat, maka sangat dibutuhkan peran bagian TI dalam proses tersebut. Oleh karena itu, maka terdapat penambahan bagian dan subbagian untuk struktur organisasi usulan, yaitu menambahkan bagian baru, yaitu bagian IT. Berikut ini adalah gambar untuk struktur organisasi yang diusulkan.
KEPALA DINAS Ir. DENDI PRYANDANA, MT (IV/b) NIP. 19661230 199603 1 00 1 SEKRETARIAT Ir. LISHERNI, M.Si (IV/B) NIP. 19660226 199303 2
KASI UMUM Ir. Hj. DENIWATI, MM (IV/a) NIP. 19650401 199803 1 006
SUBBAGIAN TATA USAHA DAN SDM
KASUBAG KEUANGAN Dra. IIS HASTATI ROCHIMAT (III/c) NIP. 19641213 200501 2 001
KASUBAG PEP RIKAS DIRGANTARI, ST, MT (IV/a) NIP. 19691130 200501 1 007
SUBBAGIAN RUMAH TANGGA
Bidang Tata Ruang TONNY SOEWANDI, ST (III/d) NIP. 19701030 199803 1 005
Bidang Perumahan CARSONO, S.ST, MM (III/d) NIP. 19691105 199101 1 001
Bidang Bangunan MUKODDAS SYUHADA, ST, MT (III/d) NIP. 19761028 200112 1 007
Seksi Perencanaan Tata Ruang H. BUDI FIRMANSYAH, ST, M.Si, M.Ak (III/c) NIP. 19690123 200212 1 002
Seksi Perumahan BUWANA MAHARDDIKA, ST (III/ d) NIP. 19780811 200112 1 003
Seksi Bangunan Gedung Pemerintahan HERI ASARI S.Kom, M.Si (III/b) NIP. 19800210 201001 1 001
Seksi Perenanaan ADI HERMAWAN, ST, MT (III/c) NIP. 19741005 200112 1 003
Seksi Pemetaan FARAH DIBA, ST, M.Si (III/c) NIP. 19790531 200604 2 002
Seksi Penataan Kawasan DIAN NUGRAHA, S.Kom (III/c) NIP. 19730124 200604 1 006
Seksi Bangunan Non Pemerintahan ASEEP HERMAWAN, ST (III/c) NIP. 19750807 200212 1 004
Seksi Pengawasan ACHMAD NASUHI, ST, MT (III/c) NIP. 19700416 199703 1 010
Seksi Pengendalian Pemanfaatan Ruang MUHAMMAD HAFIZ, ST (III/c) NIP. 19730707 200604 1 002
Seksi Penyehatan Lingkungan Permukiman (PLP) DEWAN RIDWAN, SE, MM (III/d) NIP. 19730923 200112 1 004
Seksi Pemeliharaan Gedung H. HERRY SURYADRMAWAN, S.Sos, MM (III/d) NIP. 19671226 200501 1 004
Seksi Data Informasi dan Pengujian TEGUH SUGARWONO, S.Sos (IV/d) NIP. 19691130 200501 1 007
Bidang Teknik DEDENG DASA, ST (III/d) NIP. 19740420 200112 1 003
System Administrator
Bagian IT
Application
System Analyst
Programmer
Technological Support
Database Administrator
Gambar 4.12 Struktur Organisasi usulan DTKBDP
Helpdisk
129
Adapun penjelasan terhadap pembagian sub-sub pada divisi teknologi informasi adalah sebagai berikut: 1.
Application a. Sistem analyst System analyst berperan dalam mendesain sistem secara keseluruhan, baik dari segi basis data, aplikasi, dan teknologi informasi pendukung. Dalam merancang sistem, system analyst yang telah mengumpulkan informasi yang dibutuhkan dari pengguna. Dengan adanya system analys maka diharapkan pengembangan dan pembangunan aplikasi yang baru dapat berjalan dengan baik dan sesuai dengan rencana. System analyst juga berfungsi untuk memberikan gambaran yang baik kepada programmer untuk membangun aplikasi agar sesuai dengan apa yang dibutuhkan. b. Programmer Programmer
berperan
dalam
tahap
pembangun
dan
pengembangan aplikasi-aplikasi yang telah didesain oleh system analyst. Dengan adanya acuan desain sistem yang berasal dari system analyst diharapkan programmer dapat mengerjakan dan menyelesaikan pembuatan aplikasi secara tepat dan sesuai dengan perencanaan yang telah dibuat.
130
2.
Technological Support a.
System administrator System administrator berperan dalam melakukan konfigurasi
terhadap sistem jaringan komputer, baik server, client, dan system software yang membentuk sebuah infrastruktur dimana terdapat aplikasi dan data perusahaan. Sistem yang dimaksud adalah sistem mail server, file sharing, proxy server dan application server. Selain melakukan konfigurasi, system administrator juga bereperan dalam hal maintenance dan melakukan control sistem agar dapat berjalan dengan baik.
b.
Database administrator Database administrator berperan dalam mendesain arsitektur
database, melakukan install dan konfigurasi database software, berpartisipasi pada desain dan pengembangan dengan programmer, menjamin keamanan data, dan mengawasi serta meningkatkan performansi
database.
Dinas
Tata
Kota,
Bangunan,
dan
Pemukiman membutuhkan tenaga yang mampu melakukakn semua tugas diatas untuk mendukung aplikasi yang berjalan serta aplikasi yang diusulkan. Sehingga basis data yang menyimpan data selalu aman. Mem-backup, restore, authentication, dan role dari pengguna juga merupakan tanggung jawab dari Database administrator.
131
c.
Helpdisk Helpdisk atau teknisi bertugas melakukan perawatan dan
perbaikan perangkat keras/perangkat lunak komputer, instalasi perangkat keras/lunak, pemasangan jaringan LAN, Internet dan Intranet dan menangani tindak lanjut atas keluhan dan pengguna layanan dalam DTKBDP.
4.3.6
Pelatihan yang Diusulkan Pelatihan ini diusulkan kepada bagian yang baru diusulkan dalam struktur
organisasi usulan di DTKBDP agar nantinya dapat melaksanakan tugasnya dengan baik. Berikut ini adalah daftra pelatihan usulan yang diperlukan oleh pegawai DTKBDP.
Tabel 4.7 Daftar Pelatihan Usulan No 1.
Jabatan System Analyst
Tugas
Jenis Pelatihan
Berperan dalam
Pelatihan yang diberikan
mendesain sistem secara
adalah untuk
keseluruhanm baik dari
mengembangkan kemampuan
segi basis data, aplikasi
untuk menganalisis dalam
dan teknologi.
perencanaan dan pengembangan sistem
2.
Programmer
Perannya adalah untuk
Pelatihan ini diberikan untuk
tahap oembangunan dan
mengembangkan kemampuan
132
3.
pengembangan aplikasi
programming sehingga dapat
yang telah didesain oleh
mengembangkan aplikasi
system analyst.
sesuai dengan tujuan bisnis.
System
Berperan dalam
Pelatihan yang diberikan
Administrator
melakukakan konfigurasi
adalah untuk kemampuan
terhadap sistem jaringan
membuat, mengembangkan
komputer.
dan memelihara infrastruktur jaringan yang ada.
4.
Database
Berperan dalam
Pelatihan yang diberikan
Administratir
mendesain arsitektur
adalah untuk
database, melakukan
mengembangkan kemampuan
install dan konfigurasi.
dalam mengelola keamanan
Dan juga untuk
sistem untuk melindungi
menjamin keamanan
sistem informasi dari hal-hal
data, dan mengawasi
yang dapat merusak
serta meningkatkan
informasi.
performansi database. 5.
Help Disk
Berperan dalam
Pelatihan yang diberikan
melakukan perawatan
adalah untuk mengatur
dan perbaikan perangkat
pengaduan pengguna
keras/lunak komputer
mengenai masalah dan
apabila mendapat suatu
kendala penggunaan sistem
masalah.
tersebut.
133
4.3.7
Hubungan Stakeholder dengan Aktivitas Organisasi Pada tahapan ini akan dijelaskan mengenai proses bisnis di DTKBDP
memiliki beberapa stakeholder yang memiliki kepentingan terhadap proses bisnis utama dan pendukung yaitu : 1. Bidang Tata Ruang 2. Bidang Bangunan 3. Bidang Teknik 4. Subbag Tata Usaha dan SDM 5. Pemohon 6. Bagian Keuangan 7. Pemerintah 8. Non Pemerintah 9. Kepala Dinas Tabel 4.8 Stakeholder Map Matrix
Aktivitas Utama 1. Rekomendasi
IMB &SLF
2. Hasil Musrembang
3. Sidang
Non Pemerintah
Pemerintah
Kepala Dinas
Bag. Keuangan
Pemohon
Subbag. Tata Usaha
Bid. Teknik
Aktivitas
Bid. Bangunan
Tata Ruang
Stakeholder
134
4. Survey Lokasi 5. DPA 6. Lelang Proyek 7. Rekomendasi IMB &SLF 8. Bangunan
Aktivitas Pendukung 1. Manajemen Keuangan 2. SDM 3. Inventaris 4. Perencanaan Bisnis Strategis
Tabel 4.9 Penjelasan Keterlibatan Stakeholder di Setiap Aktivitas No
Aktivitas
Stakeholder
Keterlibatan
1.
Rekomendasi IMB
Pemohon
Memberikan berkas
dan SLF
Tata Ruang
Mengkonfirmasi kelengkapan berkas
2.
3.
Hasil Musrembang
Sidang
Bidang Bangunan
Mengecek kondisi tanah
Bidang Teknik
membuatkan siteplan
Kepala Dinas
Mengesahkan rekomendasi
Tata Ruang
Mengecek hasil muerembang
Kepala Dinas
Mengesahkan musrembang
Bidang Bangunan
Melaksanakan sidang berkas
135
Bidang Teknik
Membuat gambaran kondisi lahan (siteplan)
4.
Survei Lokasi
Bidang Bangunan
Pelaksanakan survei lapangan
Bidang Teknik
untuk mengetahui kondisi lahan yang nantinya akan dibangun dan dibuatkan IMB
5.
DPA
Bag. Keuangan
Mengatur keuangan untuk pembangunan sarana dan prasarana pemerintah dan non pemerintah yang sudah disesuaikan dengan hasil musrembang
6.
Lelang Proyek
Bidang Bangunan
Mencari kontraktor untuk melaksanakan pembangunan
7.
8.
Rekomendasi IMB
Tata Ruang
Mencetak rekomendasi
dan SLF
Pemohon
Mendapatkan rekomendasi
Kepala Dinas
Mengesahkan rekomendasi
Bidang Bangunan
Mendapatkan hasil bangunan
Bangunan
yang sesuai Pemerintah
Menyelesaikan pembangunan untuk pemerintah
Non Pemerintah
Menyelesaikan pembangunan untuk non pemerintah
136
9.
Manajemen
Bagian Keuangan
Keuangan
Mengelola penggunaan keuangan dan pencatatan keuangan
Kepala Dinas
Menerima semua laporan aktivitas keuangan
10. SDM
Subbag Tata Usaha
Melakukan pelatihan kepada setiap pegawai
11. Inventaris
Subbag Tata Usaha
Mengelola penggunaan inventaris disetiap bagian DTKBDP
12. Perencanaan Bisnis
Bagian Keuangan
Mencatata laporan inventaris
Subbag Tata Usaha
Pelaksanaan proses perbaikan
Strategis
4.4
berjangka setiap 5 tahun sekali
Phase B : Buseiness Architecture
4.4.1 Pemetaan Layanan Bisnis, Proses Bisnis, dan Fungsi Bisnis di Dinas Tata Kota Bangunan dan Permukiman Kota Tangerang Selatan Pemetaan layanan bisnis, proses bisnis, dan fungsi bisnis digambarkan dengan bentuk seperti diagram pohon. Top Level dalam pemetaan ini adalah layanan bisnis. Setiap layanan bisnis mempunyai beberapa proses bisnis dan sub proses bisnis. Terakhir, setiap proses bisnis akan mempunyai beberapa fungsi bisnis dan sub fungsi. Sub fungsi bisnis merupakan untuk aktivitas terkecil.
137
Berikut ini adalah tree diagram untuk pemetaan gabungan layanan bisnis, proses bisnis, dang fungsi bisnis di Dinas Tata Kota Bangunan dan Permukiman KotaTangerangSelatan.
138
Gambar 4.13 Tree Diagram Pemetaan Layanan Bisnis, Proses Bisnis dan Fungsi Bisnis DTKBDP
139
1. Layanan Bisnis
Gambar 4.14 Layanan Bisnis di DTKBDP Pada gambar 4.14 menjelaskan bahwa layanan pada DTKBDP terdapat pelayanan yaitu IMB dan pembangunan.
1. Proses Bisnis
Gambar 4.15 Proses Bisnis Pada Layanan IMB DTKBDP
Pada gambar 4.15 menjelaskan bahwa pada layanan IMB memiliki beberapa proses bisnis seperti proses pendaftaran, persidangan dan verifikasi SLF.
140
Gambar 4.16 Proses Bisnis Pada Layanan Pembangunan DTKBDP Pada gambar 4.16 menjelaskan pada layanan pembangunan DTKBDP memiliki beberapa proses bisnis seperti proses pendataan, design dan progress bangunan. 2. Fungsi Bisnis a. Pendaftaran
Gambar 4.17 Fungsi Bisnis pada Proses Bisnis Pendaftaran
141
pada gambar 4.17 menjelaskan pada proses bisnis pendaftaran terdapat beberapa fungsi bisnis seperti penyerahan berkas IMB dan SLF, pengecekkan kelengkapan berkas, dan pengkonfirmasian kelengkapan berkas. b. Persidangan
Gambar 4.18 Fungsi Bisnis pada Proses Bisnis Persidangan Pada gambar 4.18 menjelaskan pada proses bisnis persidangan terdapat beberapa fungsu bisnis seperti sidang, survey lapangan, siteplan, pemeriksaan berkas administrasi, konfirmasi kelengkapan berkas, rekomendasi IMB dan pelaporan IMB.
142
c. Verifikasi SLF
Gambar 4.19 Fungsi Bisnis pada Proses Bisnis Verifikasi Berkas SLF Pada gambar 4.19 menjelaskan pada proses bisnis verifikasi berkas SLF terdapat beberapa fungsi binsis seperti pemeriksaan berkas SLF, konfirmasi kelengkapan berkas, pemeriksaan gedung bangunan, pengesahan rekomendasi SLF dan rekomendasi SLF. d. Pendataan
Gambar 4.20 Fungsi Bisnis pada Proses Bisnis Pendataan
143
Pada gambar 4.20 menjelaskan pada proses bisnis pendataan terdapat beberapa fungsi binsis seperti pengecekkan hasil musrembang dan penyerahan data proyek. e. Design
Gambar 4.21 Fungsi Bisnis pada Proses Bisnis Design Pada gambar 4.21 menjelaskan pada proses bisnis design terdapat beberapa fungsi binsis seperti pembuatan design sesuai proyek, pelaksanaan lelang dan pembangunan.
144
f. Progress Bangunan
Gambar 4.22 Fungsi Bisnis pada Proses Bisnis Progress Bangunan Pada gambar 4.22 menjelaskan pada proses bisnis Progress Bangunan terdapat beberapa fungsi binsis seperti pengamatan Progress Bangunan, pengecekkan kontruksi bangunan dan pembuatan laporan Progress Bangunan.
145
4.4.2
Rancangan Architecture Business Tabel 4.10 Pemetaan Kendala
No 1.
Bagian
Kendala
Solusi
Pelayanan IMB dan
Pelayanan masih
Perancangan aplikasi
SLF
dilakukan papper
IMB dan SLF
based, dan terlalu banyak sidang 2.
Tim survey IMB dan
Survey lokasi masih
Perancangan sistem
SLF
dilakukan secara
pemetaan lokasi
manual 3.
DPA
Belum ada
Membuat DBMS
management database 4.
5.
Sekretariat
Bangunan
Pertukaran data masih
Sistem terintegrasi antar
papper based
bidang
Proses lelang masih
Pembuatan Sistem
manual
Pendukung Keputusan (SPK)
6.
Keuangan
Proses pencacatan
Pembuatan sistem
keuangan masih
keuangan
bersifat manual
kesulitan dalam membuat laporan
146
keuangan yang cepat dan akurat
7.
Inventaris
Pendataan inventaris barang
Pembuatan sistem Einventaris
masih manual Kesulitan dalam pencatatan inventaris jika ada banyak perubahan
Solusi visi arsitektur sesuai dengan solusi dari kendala yang ada sebagai berikut:
147
8. Menyerahkan rekomendasi IMB
Pemohon
1. Daftar IMB 2. Upload berkas
Informasi Publik
Sekretariat
13. Cetak SLF
Portal DTKBDP
9. Upload SLF
terintegrasi
13. Input hasil musrembang
7. Cetak rekomendasi IMB
3. Cek Berkas 4. Survey Lapangan
TABG 5. Cek berkas site plan
Tim Survey 10. Pemerikasaan berkas SLF Aplikasi 11. Konfirmasi kontruksi bangunan
Pemerintah Kota
6. Input rekomendasi
E-IMB dan SLF
26. Input Rekomendasi IMB Musrembang
12. Input berkas SLF 16. Input spesifikasi proyek
Panitia SLF
Kontraktor
14. Input DPA
15. Input design
Bagian Keuangan 27. Input Rekomendasi SLF Pemkot
SPK Lelang 19. View laporan pembangunan
17. Manage data pembangunan
Kepala Dinas
18. Input progress pembangunan
Pengawasan Bangunan
Bidang Teknik
Aplikasi Progress Bangunan
20. Input Data Inventaris
22. View Laporan Inventaris 21. Manage Data Inventaris
20a. Input Data Inventaris
Aplikasi E-Inventaris
Bidang Bangunan
Subbag. Rumah Tangga
23. Melakukakn pencantatan akuntansi
Subbag Tata Usaha
24. Mengatur periode pembuatan Laporan keuangan
Aplikasi E-Keuangan
Bagian Keuangan 25. Melihat laporan keuangan
View Laporan Pengesahan
Gambar 4.23 Solusi Arsitektur Bisnis
148
1.
Permohonan Rekomendasi IMB dan SLF
8. menyerahkan Rekomendasi IMB
1, Daftar IMB 13. menyerahkan IMB musrembang
2. Upload Berkas
Bidang Bangunan
14. Input SLF pemkot
9. Upload SLF
Pemohon
Portal DTKBDP
12. Cetak SLF
Sekretariat
Integrasi
Panitia SLF
10. Pemeriksaan Berkas SLF 11. Konfirmasi Kontruksi Bangunan
16. cetak SLF pemkot
Pengawas Bangunan
7. Cetak Rekomendasi IMB 15. cetak IMB musrembang 5. Cek Berkas Site Plan
3. Cek Berkas 4. Survey Lapangan
Aplikasi E-IMB dan SLF
Tim Survey
TABG
Gambar 4.24 Solusi Arsitektur Bisnis Rekomendasi IMB & SLF
Solusi arsitektur bisnis rekomendasi IMB dan SLF ini akan mengubah sistem pengelolaan data rekomendasi yang masih menggunakan ms.offfice menjadi sistem terkomputerisasi melalui aplikasi E-IMB dan SLF. Pemohon harus upload berkas IMB kedalam portal DTKBDP dan akan terintegrasi kedalam aplikasi E-IMB dan SLF. Tim survey harus melakukan log in kedalam aplikasi EIMB dan SLF untuk mengecek berkas kemudilan melakukan survey lapangan sesuai dengan isi IMB melalui gps. Bagian bidang bangunan memberikan IMB musrembang dan bagian pengawas bangunan memberikan SLF pada saat bangunan internal DTKBDP sudah dibangun.
149
Setelah melakukan survey lokasi, maka akan didapatkan hasil siteplan yang berisi kondisi lapangan yang nantinya akan didirikan bangunan. Sekretariat log in ke aplikasi, kemudian mencetak rekomendasi IMB dan diserahkan kepada pemohon. Setelah rekomendasi IMB selesai, makn dibuat SLF (Sertifikat Layak Bangunan). Pemohon harus upload berkas SLF kedalam portal DTKBDP, panitia SLF akan mengecek berkas, dan melakukan konfirmasi kontruksi bangunan kedalam sistem. Apabila isi kontruksi bangunan sudah sesuai dengan isi IMB, sekretariat mencetak rekomendasi SLF dan diberikan kepada pemohon. Sekretariat juga memberikan berkas IMB dan SLF pada bangunan non pemerintahan atau pemerintahan didaerah Tangerang Selatan setelah design bangunan didapatkan dari hasil musrembang. 2.
SPK Lelang
1. Input Hasil Musrembang
Pemerintah Kota
Portal DTKBDP
Integrasi
4, Input Spesifikasi Proyek
2. Input DPA
Bagian Keuangan
Kontraktor
3. Input Design
Aplikasi SPK Lelang
Bidang Teknik
Gambar 4.25 Solusi Arsitektur Bisnis SPK Lelang
150
Solusi arsitektur bisnis
SPK Lelang ini akan mengubah sistem
pengelolaan data SPK Lelang yang masih menggunakan ms.offfice menjadi sistem terkomputerisasi melalui aplikasi SPK Lelang. Pemerintah kota harus terlebih dahulu menginput data musrembang (Musyawarah Rembuk Bangunan) yang didapat dari hasil rembuk dari masyarakat atau pemerintah mengenai pembangunan atau perbaikan sarana dan prasaran didaerah TangSel. Setelah diinput maka akan terintegrasi kedalam aplikasi SPK Lelang. Setelah hasil musrembang didapat, maka bagian keuangan harus login dan menginput DPA (Detail Pagu Anggaran) kedalam sistem, yang nantinya DPA tersebut disesuaikan dengan rencana pembangunan atau perbaikan bangunan di TangSel. Bidang teknik harus login kedalam sistem dan input design bangunan kedalam sistem. Kemudian kontrakor bisa masuk kedalam sistem dengan melakukan login dan menginput spesifikasi proyek yang sedang dicari oleh pihak kontraktor, apabila dirasa proyek di DTKBDP sesuai, maka DTKBDP akan melakukan konfirmasi melalui sistem kepada kontraktor.
151
3.
Progress Bangunan
1. kelola data bangunan 2. input progress bangunan
Pengawas Bangunan
3. View Laporan Pembangunan
Aplikasi Progress Bangunan
Kepala Dinas
Gambar 4.26 Solusi Arsitektur Bisnis Progress Bangunan Solusi arsitektur bisnis Progress Bangunan ini akan mengubah sistem pengelolaan data progress bangunan
yang masih menggunakan ms.offfice
menjadi sistem terkomputerisasi melalui aplikasi Progress Bangunan. Pengawas bangunan harus terlebih dahulu melakukan login kedalam aplikasi, dan melakukakn kelola data bangunan kemudian menginput kedalam sistem. Kepala dinas melihat laporan progress bangunan dan melakukan login kedalam sistem.
152
4.
E-inventaris
2. Kelola Data Inventaris
1. Input Data Inventaris
Subbag. Rumah Tangga Bidang Teknik
3. View Laporan Inventaris
1a. Input Data Inventaris
Aplikasi E-inventaris Bagian Keuangan
Bidang Bangunan
Gambar 4.27 Solusi Arsitektur Bisnis E-inventaris Solusi arsitektur bisnis E-inventaris ini akan mengubah sistem pengelolaan data
inventaris
yang
masih
menggunakan
ms.offfice
menjadi
sistem
terkomputerisasi melalui aplikasi E-inventaris. Pada pencatatan penggunaan inventaris di DTKBDP, setiap bidang harus melakukan login terlebih dahulu kedalam sisem, kemudian setiap bidang harus menginput data inventaris yang mereka gunakan setiap bulan. Subbag. Rumah tangga melakukan login kedalam sistem untuk mengelola data inventaris yang digunakan setiap bidang di DTKBDP. Bagian keuangan melihat laporan inventaris melalui sistem E-inventaris.
153
5.
Keuangan
1. Melakukan Pencatatan Akuntansi
Subbag. Tata Usaha
2. Mengatur Periode Pembuatan Laporan Keuangan
Aplikasi E-keuangan
Bagian Keuangan
3. Melihat Laporan Keuangan
Kepala Dinas
Gambar 4.28 Solusi Arsitektur Bisnis E-keuangan
Solusi visi arsitektur keuangan akan menggunakan aplikasi E-keuangan. Aplikasi
E-keuangan
mengubah
sistem
keuangan
sebelumnya
hanya
menggunakan microsoft excel, dimana penggunaan tersebut rawan untuk menjaga kualitas data keuangan. Bagian keuangan dan Tata Usaha yang terlibat dalam aplikasi E-keuangan harus terlebih dahulu melakukan login. Bagian keuangan mengelola periode pembuatan laporan keuangan, menginput pemasukan keuangan. Aplikasi E-keuangan akan menghasilkan laporan keuangan yang merupakan hasil dari pengelolaan terhadap pengeluaran dan pemasukan keuangan tiap periodenya. Laporan keuangan tersebut akan dilihat oleh kepala dinas sebagai bentuk pertanggungjawaban data keuangan.
154
4.5
Phase C: Information System Application
4.5.1
Application Architecture Portofolio ini dibuat untuk memudahkan dalam melakukan identifikasi
aplikasi berdasarkan proses bisnis. Tabel 4.11 Application Portofolio No 1.
Aplikasi Portal DTKBDP
Fungsi Aplikasi berbasis web yang memudahkan pemohon untuk mengajukan permohonan rekomendasi IMB dan SLF
2.
Aplikasi IMB & SLF
Mengkonfirmasi
permohonan
rekomendasi IMB dan SLF, pencatatan pemohon,
pencatatan
laporan
pendaftaran rekomendasi IMB dan SLF 3.
Aplikasi SPK Lelang
Mengkonfirmasi didaerah
hasil
Tangsel,
anggaran Memberikan
musrembang
dan
mengetahui
sesuai
musrembang.
keputusan
kepada
kontraktor yang nantinya terpilih untuk membangun bangunan yang sudah disesuaikan
dengan
design,
anggaran dari DTKBDP Tangsel
dan
155
4.
Aplikasi Progress
Pencatatan hasil progress bangunan
Bangunan
yang
sedang
Tangsel
serta
dibangun mengetahui
didaerah grafik
pembangunan bangunan 5.
Aplikasi E-inventaris
Pencatatan penggunaan BMN (Barang Milik Negara) tersebut akan selalu terupdate
pada
setiap
periode
semesteran atau pertahun. 6.
Aplikasi Keuangan
Melakukan pencatatan keuangan, untuk mengetahui DTKBDP.
laporan Dan
keuangan
mengatur
di
periode
pembuatan laporan keuangan di dalam sistem keuangan.
156
Rancangan ini mencakup model bisnis usulan berdasarkan skenario bisnis yang sudah diidentifikasikan berdasarkan fase sebelumnya. Berikut penggambaran skenario bisnis dalam use case diagram.
157
Log Out
System
<>
Log in
Daftar Rekomendasi IMB Tim Survey
Upload Berkas IMB
Pemohon
View Berkas Survey Lapangan TABG
Cek Berkas Site Plan Input Rekomendasi IMB Cetak Rekomendasi IMB Upload Berkas Surat Layak Fungsional
Sekretariat
Periksa Berkas Surat Layak Fungsioanal Konfirmasi Kontruksi Bangunan
Panitia SLF
Input Rekomendasi Surat Layak Fungsional Cetak Rekomendasi Surat Layak Fungsional Input Hasil Musrembang Input DPA Pemerintah Kota Input Design Proyek Input Proposal Proyek
Kontraktor
Memilih Kontraktor
Bidang Teknik
Input Rekomendasi IMB Musrembang Approve Proyek Manage Data Bangunan
Bidang Bangunan
Input Progress Bangunan Input Rekomendasi SLF Pemkot Pengawas Bangunan View Laporan Progress Bangunan View Laporan Pengesahan Subbag Rumah Tangga
Kepala Dinas
Manage Data Inventaris Input Pengguna Data Inventaris View Laporan Inventaris Mencatat Laporan Keuangan Manage Data Keuangan View Laporan Keuangan
Admin
Bagian Keuangan Manajemen User
Gambar 4.29 Arsitektur Aplikasi
158
4.3.5.1
Arsitektur Aplikasi Permohonan Rekomendasi IMB
Log Out <> Log in Manajemen User Daftar Rekomendasi IMB
Admin
Upload Berkas IMB
Bidang Bangunan
View Berkas
Pemohon
Survey Lapangan Cek Berkas Site Plan Input Rekomendasi IMB
Tim Survey
Input Rekomendasi IMB Musrembang
TABG
Cetak Rekomendasi IMB
Sekretariat
Pengesahan Permohonan Sertifikat Layak FUngsional
Kepala Dinas
View Laporan Rekomendasi IMB
Gambar 4.30 Arsitektur Aplikasi Permohonan Rekomendasi IMB
Arsitektur bisnis permohonan rekomendasi IMB memiliki 7 aktor dan 12 usecase yang dapat dilakukan dalam sistem permohonan rekomendasi IMB. Aktor yang terlibat yaitu admin, pemohon, TABG (Tenaga Ahli Bangunan Gedung), kepala dinas, bidang bangunan, tim survey, dan sekretariat. Use case yang terlibat dalam sistem permohonan rekomendasi IMB yaitu, login, logout, manajemen user, daftar rekomendasi IMB, upload berkas IMB, view berkas, survey lapangan, cek berkas siteplan, input rekomendasi IMB, cetak
159
rekomendasi
IMB,
pengesahan
permohonan
rekomendasi
IMB,
input
rekomendasi IMB musrembang dan view rekomendasi IMB. Aktivitas dan fungsi bisnis Permohonan rekomendasi IMB dimulai dari pemohon yang membuka website DTKBDP dan melakukan pendaftaran rekomendasi IMB, kemudian pemohon mengupload berkas IMB. Tim survey akan melihat kelengkapan berkas IMB, kemudian setelah berkas dirasa sudah lengkap, maka tim survey mulai melakukan survey lapangan di lahan yang nantinya akan dibuatkan IMB dan akan didirikan bangunan. Setelah tim survey sudah melaksanakan survey lapangan, akan didapatkan siteplan yang berisi gambaran kondisi lahan dan diberikan kepada bagian Tenaga Ahli Bangunan Gedung (TABG) dan menginput rekomendasi IMB tersebut. kemudian rekomendasi IMB dicetak oleh bagian Tenaga Ahli Bangunan Gedung (TABG) dan disahkan oleh kepala dinas dan kepala dinas juga mempunyai wewenang untuk melihat laporan rekomendasi IMB tersebut. Bidang bangunan juga membuat rekomendasi IMB untuk musrembang di Dinas Tata Kota, Bangunan dan Pemukiman Kota Tangerang Selatan.
160
4.3.5.2
Arsitektur Aplikasi Rekomendasi SLF
<>
Log Out
Log in Manajemen User
Admin
Upload Berkas SLF
Pengawas Bangunan
Periksa Berkas Surat Layak Fungsioanal Pemohon
Konfirmasi Kontruksi Bangunan Pemeriksa Lapangan
Input Rekomendasi SLF Pemkot Cetak Rekomendasi Surat Layak Fungsional Panitia SLF
Pengesahan Permohonan Sertifikat Layak FUngsional View Laporan Proyek
Sekretariat
Kepala Dinas
Gambar 4.31 Arsitektur Aplikasi Rekomendasi SLF
Arsitektur bisnis rekomendasi SLF memiliki 7 aktor dan 9 use case yang dapat dilakukan dalam sistem rekomendasi SLF. Aktor yang terlibat yaitu admin, pemohon, panitia SLF, kepala dinas, pengawas bangunan, pemeriksa lapangan dan sekretariat. Use case yang terlibat dalam sistem rekomendasi SLF yaitu , logout, manajemen user, upload berkas SLF, periksa berkas sertifikat layak fungsional, konfirmasi kontruksi bangunan, cetak rekomendasi sertifikat layak fungsional, pengesahan
sertifikat
layakfungsional.
layak
fungsional
dan
view
laporan
sertifikat
161
Aktivitas bisnis pada proses rekomendasi SLF yaitu pemohon mengupload berkas SLF, berkas SLF tersebut didapatkan dari hasil rekomendasi IMB. Panitia SLF memerikas kelengkapan berkas kemudian bagian panitia lapangan mengkonfirmasi kontruksi bangunan yang sebelumnya sudah tertulis didalam rekomendasi IMB, hanya untuk memastikan kesesuaian antara isi dari IMB dan bangunan yang sudah dibangun. Bagian sekretariat mencetak rekomendasi SLF dan disahkan oleh kepala dinas. Pengawas bangunan membuat rekomendasi SLF untuk pemerintah kota. SLF dibuat setelah bangunan sudah selesai dibangun.
4.3.5.3
Arsitektur Aplikasi SPK Lelang
Log Out <> Log in Manajemen User Input Hasil Musrembang
Admin
Bagian Keuangan
Input DPA Input Design Proyek Pemerintah Kota
Input Proposal Proyek Memilih Kontraktor
Kontraktor
Pengesahan Proyek Bidang Teknik
View Laporan Proyek Kepala Dinas
Sekretariat
Gambar 4.32 Arsitektur Aplikasi SPK Lelang
Arsitektur bisnis SPK Lelang memiliki 7 aktor dan 10 use case yang dapat dilakukan dalam sistem SPK lelang. Aktor yang terlibat yaitu, admin, bagian
162
keuangan, pemerintah kota, kontraktor, bidang teknik, kepala dinas dan sekretariat. Use case yang terlibat dalam SPK lelang yaitu, login,logout, manajemen user, input hasil musrembang, input DPA, input design proyek, input proposal proyek, memilih kontraktor, pengesahan proyek, dan view laporan proyek. Untuk melaksanakan pembangunan dan perbaikan didaerah Tangerang Selatan maka pemerintah kota harus menginput hasil musrembang yang sudah didapatkan dari rapat warga untuk pembangunan non pemerintahan dan rapat oleh pemerintah untuk pembangunan pemerintahan. Hasil musrembang tersebut berisi tentang perbaikan dan pembangunan sarana dan prasarana didaerah kota Tangerang Selatan. Bagian keuangan menginput dana yang sudah disesuaikan untuk pembangunan didaerah TangSel. Kemudian bidang teknik menginput hasil design project pembangunan. Setelah design telah diinput, maka beberapa kontraktor mulai menginput proposal project yang nantinya proposal tersebut dijadikan bahan pertimbangan oleh pihak dinas. Apabila proyek pembangunan memerlukan dana dibawah 200 juta, maka pihak DTKBDP sudah mempunyai kontraktor sendiri. Akan tetapi apabila dana yang diperlukan lebih dari 200 juta maka pihak DTKBDP mencari kontraktor yang bersedia membangun proyek tersebut sampai selesai. Kontraktor akan dipilih oleh sekretariat, apabila kontraktor tersebut dirasa sudah memenuhi persyaratan, dan sudah melakukan perjanjian kontrak maka kepala dinas akan melakukan pengesahan dan kemudian melihat laporan.
163
4.3.5.4
Arsitektur Aplikasi Progress Bangunan
Log Out <<extend>> Log in Manajemen User Manage Data Bangunan Admin Input Progress Bangunan View Laporan Progress Bangunan
Pengawas Bangunan
Kepala Dinas
Gambar 4.33 Arsitektur Aplikasi Progress Bangunan
Arsitektur bisnis progress bangunan memiliki 3 aktor dan 6 use case yang dapat dilakukan dalam sistem progress bangunan. Aktor yang terlibat yaitu admin, pengawas bangunan dan kepala dinas. Use case yang terlibat dalm sistem progress bangunan yaitu login, logout, manajemen user, manage data bangunan¸input progress bangunan dan view laporan progress bangunan. Aktivitas dan fungsi bisnis pada progress bangunan adalah untuk mengetahui progress setiap bangunan yang sedang dibangun. Tujuannya adalah untuk mengetahui bagaimana proses detail setiap bangunan yang dibangun. Pengawas bangunan mempunyai tugas untuk mengelola data bangunan dan menginputnya, dan kepala dinas melihat laporan progress bangunan.
164
4.3.5.5
Arsitektur Aplikasi E-inventaris
Log Out <<extend>> Log in Admin Manajemen User Input Data Inventaris
Bagian Keuangan
Manage Data Inventaris Bidang Bangunan View Laporan Inventaris Bidang Teknik
Subbag. Rumah Tangga
Kepala Dinas
Gambar 4.34 Arsitektur Aplikasi E-Inventaris
Arsitektur bisnis E-inventaris memiliki 6 aktor dan 6 use case yang dapat dilakukan dalam sistem E-inventaris. Aktor yang terlibat yaitu admin, bagian keuangan, bidang bangunan, bidang teknik suubag rumah tangga dan kepala dinas. Use case yang terlibat dalam sistem E-inventaris yaitu, login, logout, manajemen user , input data inventaris, manage data inventaris dan view laporan inventaris. Aktivitas bisnis dan fungsi bisnis pada E-Inventaris adalah untuk mengelola data penggunaan Barang Milik Negara (BMN) yang dikelola oleh bagian Subbag rumah tangga dan diinput kedalam sistem e-inventaris agar data
165
penggunaan Barang Milik Negara (BMN) tersebut akan selalu terupdate pada setiap periode semsesteran atau pertahun. Kemudian, sistem E-inventaris akan menghasilkan laporan inventaris per periode yang sudah ditentukan. Subbag rumah tangga dapat melihat laporan inventaris tersebut untuk keperluan pemerikasaan Barang Milik Negara (BMN) yang digunakan oleh DTKBDP secara berkala. Bagian keuangan juga dapat melihat laporan inventaris untuk keperluan pembuatan laporan keuangan.
4.3.5.6
Arsitektur Aplikasi E-keuangan
Log Out <<extend>> Log in Manajemen User pencatatan akuntansi
Admin
Manage periode pelaporan View Laporan Keuangan
Kepala Dinas
Bagian Keuangan
Gambar 4.35 Arsitektur Aplikasi E-Keuangan
Arsitektur bisnis E-keuangan memiliki 3 aktor dan 6 use case yang dapat dilakukan dalam sistem E-keuangan. Aktor yang terlibat yaitu admin, bagian keuangan dan kepala dinas.
166
Use case yang terlibat dalam sistem E-keuangan yaitu login, logout, manajemen user, pencatatan akuntansi, manage periode pelaporan dan view laporan keuangan. Aktivitas bisnis dan fungsi bisnis pada bisnis E-keuangan adalah untuk mengetahui laporan keuangan di DTKBDP. Subbag tata usaha akan melakukan pengelolaan keuangan untuk memenuhi kebutuhan DTKBDP. Staff tersebut juga akan melakukan pencatatan akuntansi keuangan, serta mengatur periode pembuatan laporan keuangan di dalam sistem keuangan. Sistem keuangan akan menghasilkan output berupa laporan keuangan. Laporan keuangan tersebut dapat dilihat oleh kepala dinas DTKBDP. 4.5.2
Data Architecture Pada tahapan ini akan dilakukan perancangan data architecture yang
bertujuan untuk mendefinisikan kebutuhan data yang berupa entitas-entitas yang akan digunakan pada application architecture tetapi tidak berhubungan dengan rancangan database. Rancangan data architecture akan menggunakan tools data dessemination diaram dan class diagram.
167
4.5.2.1 Data Dissemination Diagram
Pelayanan IMB
Pembangunan
dan SLF
Gambar 4.36 Data Dessemination Diagram Pada gambar 4.36 menggambarkan hubungan layanan Dinas Tata Kota, Bangunan dan Permukiman Kota Tangerang Selatan, aplikasi, dan data. Di aplikasi IMB dan SLF terdapat data level, data user, data pegawai, data customer, data tanah, data SLF, data IMB dan data bangunan. Aplikasi SPK Lelang terdapat data level, data user, data pegawai, data kontraktor, data material, data DPA, data design proyek dan data lelang. Aplikasi progress bangunan terdapat data level, data user, data pegawai, data proyek, data pengawas, data progress, dan data
168
kontraktor. Aplikasi E-inventaris terdapat data user, data level, data pegawai dara registrasi_BMN, data peralatan, data kendaraan, data tanah, data bangunan dan data aset_tak_berwujud. Aplikasi E-keuangan terdapat data level, data pegawai, data periode, data klasifikasi_pengeluaran, data user, data pengeluaran dan data general_ledger.
4.5.2.2 Class Diagram Class Diagram digunakan untuk menggambarkan model konseptual data yang berupa entitas, atribut, dan relasi. Class diagram juga berguna untuk menunjukkan hubungan antar kelas dalam suatu sistem yang bertujuan untuk mendefinisikan kebutuhan data yang berupa entitas-entitas yang akan digunakan pada application architecture tetapi tidak berhubungan dengan rancangan database. Class diagram digunakan sebagai tools dalam pendefinisian entitas ini.
169
1.
Rekomendasi Permohonan IMB dan SLF User +Nip +Username +Password +Tambah() +Hapus() +Ubah()
Level +id_level +nama_Level +tambah() +hapus()
*
1 Pegawai
SLF +No_SLF +Tanggal_SLF +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_SLF +Pengesahan +Tambah() +Hapus() +Ubah() +Print()
1..*
1
+NIP +Nama_Pegawai +TTL +Alamat 1 +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah()
Customer
Tanah
+Id_Customer 1..* +Nama_Customer +TTL +Telp +Alamat +KTP 1 +Akta
1 1
1
1
+Tambah() 1..* +Hapus() +Ubah()
+Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah 1..*
+Tambah() +Hapus() +Ubah() 1
1
1 IMB +No_IMB 1..* +Tanggal_IMB +Id_Customer +Id_Tanah +Id_Bangunan +Masa_Berlaku_IMB +Pengesahan +Tambah() +Hapus() +Ubah() +Print()
Bangunan
1..*
+Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan +Tambah() +Hapus() +Ubah()
Gambar 4.37 Arsitektur Data Aplikasi IMB dan SLF Arsitektur data IMB dan SLF memiliki 8 kelas, yaitu Level, user , Pegawai, Customer, Tanah, Bangunan, SLF, dan IMB. Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas pegawai. Kelas pegawai memiliki multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas tanah dan bangunan. Kelas bangunan memilik multiplicity 11 (satu ke satu) terhadap kelas tanah.
Kelas IMB dan SLF memiliki
multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas pegawai. Kelas user memiliki multiciply 11 (satu ke satu) terhadap pegawai dan kelas
170
user juga memiliki multiciply 1 1..* (satu ke antara satu sampai banyak) terhadap kelas customer.
2.
Sistem Penunjang Keputusan Lelang Level +id_level +nama_Level +tambah() +hapus()
User +Nip +Username +Password +Tambah() +Hapus() +Ubah()
1 * 1
1
Pegawai
kontraktor
+NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian
+Id_Kontraktor +Nama_Kontraktor +TTL +Alamat +Telp
+Tambah() +Hapus() +Ubah()
+Tambah() +Hapus() +Ubah()
Material +Id_Material +Jenis_Material +Satuan_Material +Jumlah_Material +Harga_Material 1..*
+Tambah() +Hapus() +Ubah()
1
1 DPA +id_DPA +nama anggaran +budget +Tambah() +Hapus() +Edit()
Lelang
Design_Proyek 1
1..* +Id_Proyek +Nama_Design +Jenis_Design +Tambah() +Hapus() +Ubah()
1..* 1
1
+Id_Lelang +Nama_Proyek +Jenis_Proyek +Nomer_Lelang +Total_Biaya +Operation1()
Gambar 4.38 Arsitektur Data Aplikasi SPK Lelang Arsitektur data SPK Lelang memiliki 7 kelas, yaitu, Level, user, Lelang, Design_Proyek, Pegawai, Kontraktor dan Material. Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas pegawai. Kelas user lelang memiliki multiplicity 1 1 (satu ke satu) terhadap kelas pegawai. Kelas pegawai memiliki multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas lelang. Kelas lelang memiliki multiplicity 1 1 (satu ke satu) terhadap kelas design proyek. Kelas lelang memiliki mulplicity 1
171
1..* (satu ke antara satu sampai banyak) terhadap kelas kontraktor dan kelas kontraktor generalisasi dengan kelas material. 3.
Progress Bangunan Proyek Level
Pegawai
+id_level +nama_Level +tambah() +hapus()
+Id_Proyek +Nama_Proyek +Nilai +Alamat +Status +Tanggal_Mulai +Tanggal_Selesai
+NIP +Nama_Pegawai +TTL +Alamat +Telp * +Id_Level +Id_Jabatan +Kode_Bangunan 1 +Kode_Subbagian
1
1 User
1
+Tambah() +Hapus() +Ubah()
1 * Pengawas
1 Progress 1 *
1 1..* kontraktor
+Nip +Username +Password +Tambah() +Hapus() +Ubah()
+Tambah() +Hapus() +Ubah()
+Id_Progress +Rencana_Progress +Realisasi_Progress +Tambah() +Hapus() +Ubah()
+Id_Kontraktor +Nama_Kontraktor +TTL +Alamat +Telp +Tambah() +Hapus() +Ubah()
+Id_Pengawas +Nama_Pengawas +Alamat +Telp +Email +Tambah() +Hapus() +Ubah()
Gambar 4.39 Arsitektur Data Progress Aplikasi Bangunan Arsitektur data Progress Bangunan memiliki 7 kelas, yaitu, Level, Pegawai, Proyek, User, Progress, Kontraktor, dan Pengawas. Kelas level memiliki multiplicity 1 * (satu ke banyak) terhadap kelas pegawai. Kelas pegawai memiliki multiplicity 1 1 (satu ke satu) terhadap kelas user. Kelas user memiliki multiplicity 1 * (satu ke banyak) terhadap kelas pengawas. Kelas user memiliki multiplicity 1 * (satu ke banyak) terhadap kelas progress. Kelas progress memilik multiplicity 11 (satu ke satu) terhadap kelas
172
proyek. Kelas proyek memiliki multiplicity 1 1..* (satu ke antara satu sampai banyak) terhadap kelas kontraktor. 4.
E-Inventaris Pegawai Level +id_level +nama_Level +tambah() +hapus()
1
*
1
+NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian
Registrasi_BMN
1
+Tambah() +Hapus() +Ubah()
User 1
+Nip +Username +Password
1
1
+id_peralatan +nama_peralatan +merk +tipe +harga_peralatan +harga_perolehan +jumlah +kondisi +Tambah() +Hapus() +Ubah()
1 1
1
1 1 Tanah
Kendaraan +id_kendaraan +merk +tipe +warna +mesin +thn_buat +thn_beli +no_polisi +tgl_bpkb +jumlah +kondisi
1
1..* +Tambah() +Hapus() 1 +Ubah()
1
+Tambah() +Hapus() +Ubah()
Peralatan
+no_Registrasi +golongan +bidang +kelompok +id_kendaraan +id_peralatan 1..* +id_tanah +id_bangunan
1
Bangunan
+Id_Tanah +Status_Tanah +Status_Penggunaan +Pemilik_Tanah +Batas_Tanah
+Id_Bangunan +Nama_Bangunan +Fungsi_Bangunan +Jenis_Bangunan +Luas_Bangunan +Lokasi_Bangunan
+Tambah() +Hapus() +Ubah()
+Tambah() +Hapus() +Ubah()
Aset_Tak_Berwujud +id_ATB +nama_ATB +merk +jumlah +Tambah() +Hapus() +Ubah()
+Tambah() +Hapus() +Ubah()
Gambar 4.40 Arsitektur Data Aplikasi E-inventaris Arsitektur data E-Inventaris memiliki 9 kelas, yaitu, Level, user, Pegawai, Registrasi_BMN, Peralatan, Kendaraan, Tanah, Bangunan, Aset_Tak_Berwujud. Kelas level memiliki multiplicity 1* (satu ke banyak) terhadap kelas pegawai. Kelas user memiliki multiplicity 1 1 (satu ke satu) terhadap kelas pegawai dan memiliki multiplicity 11..* (satu ke antara satu sampai banyak) terhadap kelas registrasi_BMN. Kelas pegawai memiliki multiplicity 11..* (satu
173
ke antara satu sampai banyak) terhadap kelas registrasi_BMN. Kelas peralatan, kendaraan, tanah, bangunan dan aset_tak_berwujud memiliki multiplicity 1 1 (satu ke satu) terhadap kelas registrasi_BMN. 5.
E-Keuangan Pegawai Level
+id_level +nama_Level +tambah() +hapus()
1
*
Periode
+NIP +Nama_Pegawai +TTL +Alamat +Telp +Id_Level +Id_Jabatan +Kode_Bangunan +Kode_Subbagian +Tambah() +Hapus() +Ubah()
+id_periode +klasifikasi_periode +tgl_awal_periode +tgl_akhir_periode 1
+Tambah() +Hapus() +Ubah()
*
*
1..*
1
General_Ledger
1 1
Klasifikasi_Pengeluaran
User +Nip +Username +Password
+id_klasifikasi_pengeluaran +klasifikasi_pengeluaran
+Tambah() +Hapus() +Ubah()
+Tambah() +Hapus() +Ubah()
+id_jurnal +id_periode +id_pengeluaran +jumlah_pendapatan +jumlah_pengeluaran +keterangan
1
1
1
+Tambah() +Hapus() +Ubah()
Pengeluaran 1
*
+id_pengeluaran +nominal_pengeluaran +tanggal +id_klasifikasi_pengeluaran
1 1..*
+Tambah() +Hapus() +Ubah()
Gambar 4.41 Arsitektur Data Aplikasi E-Keuangan Arsitektur data E-Keuangan memiliki 7 kelas, yaitu, Level, user, Pegawai, Periode, Klasifikasi_Pengeluaran, Pengeluaran,General_Ledger. Kelas level memiliki multiplicity 1* (satu ke banyak) terhadap kelas pegawai. Kelas user memiliki multiplicity 1 1 (satu ke satu) terhadap kelas pegawai dan multiplicity 1* (satu ke banyak) terhadap kelas periode dan juga kelas user memiliki multiplicity
1 1 (satu ke satu) terhadap kelas
general_ledger. Kelas pegawai memiliki multiplicity 1* (satu ke banyak)
174
terhadap kelas periode. Kelas periode memiliki multiplicity 1..*1 (antara satu sampai banyak ke satu) terhadap kelas general_ledger. Kelas pengeluaran memiliki multiplicity 1..*1 1 (antara satu sampai banyak ke satu) terhadap kelas general ledger. Kelas klasifikasi_pengeluaran memiliki multiplicity 1* (satu ke banyak) terhadap kelas pengeluaran.
4.6
Phase D: Technology Architecture
Arsitektur teknologi menggambarkan dan menjelaskan infrastruktur jaringan serta hardware dan software yang terlibat didalam jaringan tersebut untuk mendukung pelayanan, arus data dan informasi, serta jalannya aplikasi yang menunjang kegiatan di DTKBDP. Dalam arsitektur teknologi akan dijelaskan infrastruktur jaringan awal dan usulan untuk DTKBDP, platform teknologi yang digunakan dalam infrastruktur jaringan, serta konfigurasi hardware dan software yang diperlukan dalam infrastruktur jaringan.
4.6.1
Infrastruktur Jaringan a.
Jaringan Awal Pada gambar 4.21 merupakan arsitektur jaringan saat ini di DTKBDP
yang hanya mengandalkan router agar terhubung dengan internet. Router tersebut berfungsi sebagai gateway untuk akses internet di DTKBDP saat ini. Router menghubungkan internet ke lantai 3 melalui 1 switch,
175
sedangkan untuk menghubungkan internet ke lantai ke lantai lain hanya melalui wireless. Switch yang digunakan dilantai 3 di ruang bidang bangunan yang menghubungkan dengan ruang seksi pembangunan pemerintahan, ruang seksi pembangunan non pemerintahan dan ruang seksi pemeliharaan gedung. Terdapat wireless disetiap gedung 1 dan 2 yang tersebar disetiap ruangan.
176
Lantai 3 Bidang Bangunan Ruang Bidang Bangunan
Internet Service Provider Lantai 3 Sekretariat
Ruang Seksi Pembangunan Pemerintahan
Ruang Kasubag Keuangan
Ruang Kasi Umum
Firewall Ruang Seksi Pembangunan Non Pemerintahan
Ruang SeksiPemeliharaan Gedung
Ruang Subbag Rumah Tangga
Ruang Kasubag PEP
Router
Lantai 2 Bidang Perumahan dan Permukiman Ruang Seksi Perumahan
Ruang Bid. Perumahan dan Permukiman
Ruang Penataan Kawasan
Ruang Seksi Penyehatan Lingkungan
Lantai 1 Bidang Tata Kota Ruang seksi pengendalian dan pemanfaatan ruang
Ruang kepala Bidang Tata Kota
Ruang Perencanaan Tata Ruang
Lantai 2 Bidang Teknik Ruang Seksi Perencanaan
Ruang Bidang Teknik
Ruang Seksi Pengawasan
Ruang Data Informasi dan Pengujian
Lantai 1 Lobby Ruang Tunggu
Ruang Resepsionis
Ruang seksi pemetaan
Gambar 4.42 Arsitektur Jaringan Awal Keseluruhan DTKBDP
177
Lantai 3 Bidang Bangunan Ruang Bidang Bangunan
Ruang Seksi Pembangunan Non Pemerintahan
Ruang Seksi Pembangunan Pemerintahan
Lantai 3 Sekretariat
IDC (Internet Data Center) Web Server DTKBDP
Ruang Kasubag Keuangan
Ruang Kasi Umum
Ruang SeksiPemeliharaan Gedung
Ruang Subbag Rumah Tangga
Ruang Kasubag PEP
Internet Service Provider
Lantai 2 Bidang Perumahan dan Permukiman Ruang Seksi Perumahan
Lantai 2 Bidang Teknik
Ruang Bid. Perumahan dan Permukiman
Ruang Seksi Perencanaan
Ruang Bidang Teknik
Local Server DTKBDP
Router Ruang Penataan Kawasan
Ruang Seksi Penyehatan Lingkungan
Ruang Seksi Pengawasan
Ruang Data Informasi dan Pengujian
Server
Printer
Lantai 1 Bidang Tata Kota Ruang seksi pengendalian dan pemanfaatan ruang
Ruang kepala Bidang Tata Kota
Ruang Perencanaan Tata Ruang
Scanner
Lantai 1 Lobby Ruang Tunggu
Ruang Resepsionis
Ruang seksi pemetaan
Gambar 4.43 Arsitektur Jaringan Usulan Keseluruhan DTKBDP Jaringan usulan menggunakan 2 sambungan yaitu, wireless dan LAN yang terhubung ke tiap gedung dan ruangan. Terdapat IDC (Internet Data Center) sebagai alat penyimpanan data di DTKBDP. Terdapat juga server aplikasi untuk menyimpan data-data aplikasi.
178
4.6.2
Platform Teknologi Dari Platform teknologi gambar 4.21, dapat dilihat keseluruhan sistem
sudah berbasis web. Pada level client interface, user dapat mengakses sistem melalui web browser. Pengguna dapat mengakses portal perusahaan melalui jaringan internet. Sedangkan pengguna dari internal organisasi dapat mengakses keseluruhan sistem melalui internet maupun jaringan lokal. Keamanan jaringan menggunakan firewall untuk mengakses server aplikasi. Platform teknologi meliputi client interface, network, network security, presentation, application, dan database. Berikut usulan platform teknologi:
Gambar 4.44 Platform Teknologi
179
Pada gambar diatas, dapat dilihat pemanfaatan teknologi sesuai dengan layer tempat
teknologi tersebut berada. Berikut penjelasan pembagian layer
teknologi : 1. Layer client interface, pengguna dapat mengakses sistem melalui web browser sebagai interface antara pengguna dan sistem. 2. Layer network, menghubungkan antara lingkungan sistem dengan lingkungan pengguna. Pemohon dapat mengakses pendaftaran melalui jaringan internet dan pengguna dari internal dapat mengakses Sistem Informasi DTKBDP melalui jaringan lokal. 3. Layer Network Security, keamanan jaringan menggunakan firewall untuk mengakses server aplikasi. 4. Layer presentation, bagian aplikasi yang menampilkan content aplikasi untuk memudahkan interaksi dengan pengguna sistem. Apache web server digunakan dalam layer ini. 5. Layer application, merupakan tempat dilakukannya pemrosesan aplikasi bisnis. Hypertext Prepocessor (PHP) digunakan untuk memproses data menjadi informasi yang dibutuhkan pengguna. 6. Layer database, merupakan layer tempat disimpannya data hasil pemrosesan informasi.
180
4.6.3
Konfigurasi Hardware dan Software Pada tahapan ini akan diusulkan konfigurasi hardware dan software
untuk mendukung arsitektur teknologi yang diusulkan. Berikut usulan konfigurasi hardware: Tabel 4.12 Konfigurasi Hardware Hardware
Spesifikasi
Server
IBM System
Processor
Intel Xeon 5500 series
Memory
192 GB
Storage
1 Terra Byte
Graphic Card
SVGA 8Mb
Input Device
mouse , keyboard
Ouput Device
monitor LCD
Jumlah server yang diusulkan berjumlah 10 server utama yang terdiri dari : 1.
Web server terdiri dari 1 server dan 1 back up server ( jumlah total 2 server).
181
2.
Email server terdiri dari 1 server dan 1 back up server ( jumlah total 2 server).
3.
Database server terdiri dari 1 server dan 1 back up server ( jumlah total 2 server).
4.
Proxy server terdiri dari 1 server dan 1 back up server ( jumlah total 2 server).
5.
FTP server terdiri dari 1 server dan 1 back up server ( jumlah total 2 server).
Tabel 4.13 Konfigurasi Software Software
Spesifikasi
Operating System
Windows Server 2008
Web Server
Apache
Web Browser
Google Chrome, Mozilla Firefox
DBMS
MySQL
Coding
PHP
Word Processing
Microsoft Word 2013
Speadsheet
Microsoft Excel 2013
182
Presentation
Microsoft Power Point 2013
4.6.4 Technology Portfolio Catalog Pada tahapan ini berisi catalog untuk mengidentifikasi daftar infrastruktur hardware, software, aplikasi software, dan jaringan. Tabel 4.14 Technology Portfolio Catalog Domain
Portal DTKBD
Sistem Informasi DTKBDP
Client interface
Web Browser
Web Browser
Presentation
Apache Web server
Apache Web Server
DBMS
MySQL
MySQL
Web Platform
Windows Server
Windows Server
Application
Windows Server
Windows Server
Windows Server
Windows Server
Platform Database Platform
Gigabit Ethernet
Local Area Network Wide Area Network Infrastruktur
Internet TCP/IP
183
Gigabit Ethernet, LAN, Wireless LAN
Jaringan
Access Point
4.7
Phase E: Opportunities and Solution
Pada
pembahasan
sebelumnya
telah
dilakukan
pengelompokan
berdasarkan arsitektur bisnis, sistem informasi, dan teknologi. Selanjutnya pada subbab ini dilakukan analisis terhadap peluang dan solusi dengan menggunakan analisis gap terhadap komponen-komponen arsitektur bisnis, sistem informasi dan teknologi. 4.7.1
Analisis Gap Analisis gap berguna menjelaskan komponen-komponen apa saja yang
harus dipertahankan (retain) atau dihilangkan (remove) dari sistem yang sedang berjalan di DTKBDP dan untuk menjelaskan komponen-komponen apa saja yang harus diganti (replace) atau ditambahkan (add) dengan komponen baru dari arsitektur usulan. Analisis gap dibuat dalam bentuk matriks, dengan ketentuan sebagai berikut ini: 1. Komponen sistem yang sedang berjalan (existing) ditempatkan pada kolom pertama paling kiri dan matriks. Komponen arsitektur usulan (future) ditempatkan pada baris pertama paling atas dari matriks.
184
2. Tambahkan keterangan “new” (komponen baru) pada baris pa;ing terakhir dan ditempatkan pada kolom komponen sistem yang sedang berjalan (existing). Tambahkan keterangan “eliminated” (komponen yang akan dihapus) pada kolom paling kanan dan ditempatkan pada baris komponen arsitektur usulan (future). 3.
Jika komponen sistem yang sedang berjalan (existing) masih ada dalam komponen arsitektur usulan (future), maka tandai sel yang saling berpotongan tersebut dengan keterangan “retain” (komponen lama masih dipertahankan dan digunakan). Jika komponen sistem yang sedang berjalan (existing) mengalami pengembangan versi pada komponen arsitektur usulan (future) maka tandai sel yang saling berpotongan dengan keterangan “replace” (komponen yang lama dikembangkan sehingga mempunyai versi baru).
4.
Jika komponen sistem yang sedang berjalan (existing) tidak digunakan lagi pada komponen arsitektur usulan (future), maka tandai dengan keterangan “remove” pada kolom “eliminated”. Jika komponen arsitektur usulan (future) tidak terdapat dalam komponen sistem yang sedang berjalan (existing),maka tandai dengan keterangan “add” pada baris “new”. Semua komponen yang diberi ketrangn “add” merupakan gap yang harus dipenuhi.
185
a.
Analis Gap Rekomendasi IMB dan SLF
186
Tabel 4.15 Analisis Gap Arsitektur Bisnis IMB dan SLF
187
Penyerahan hasil musrembang sistem manual Penyerahan DPA sistem manual Penyerahan daftar proyek pembangunan sistem manual Penyerahan hasil design proyek pembangunan sistem manual Pelaksanaan proses lelang Pembangunan oleh kontraktor terpilih
Replace
Replace
Replace
Replace
Replace
NEW
Tabel 4.16 Analisis Gap Arsitektur Bisnis SPK Lelang
Reta in
ELIMINATED
Pemilihan spesifikasi kontraktor melalui sistem Pembangunan oleh kontraktor terpilih
Input design proyek kedalam sistem
EXISTING
Input daftar proyek kedalam sistem
FUTURE
Input DPA kedalam isistem
Analisis Gap SPK Lelang
Input musrembang online
b.
188
c.
Analisis Gap Progress Bangunan
Penyerahan data progress bangunan sistem manual Penyerahan laporan data bangunan sistem manual View laporan data bangunan sistem manual NEW
ELIMINATED
View laporan data bangunan melalui sistem
EXISTING
Input progress laporan bangunan kedalam sistem
Manage data pembangunan kedalam sistem
FUTURE
Replace
Replace
Replace
Tabel 4.17 Analisis Gap Arsitektur Bisnis Progress Bangunan
Penyusunan anggaran program & anggaran Penarikan dana
Retain Retain
ELIMINATED
Pembuatan laporan keuangan pada sistem komputer
Pencantatan akuntansi keuangan pada sistem komputer
EXISTING
Pengelolaan data
FUTURE
Penarikan dana
Analisis Gap Keuangan
Penyusunan rencana program & anggaran
d.
189
Retain
Pengelolaan dana Pencatatan akuntansi secara manual
Replace
Pembuatan laporan keuangan sistem manual
Replace
NEW
Tabel 4.18 Analisis Gap Arsitektur Bisnis E-Keuangan
Pencatatan inventaris BMN sistem manual Penyusunan laporan penggunan BMN sistem manual Pengumpulan laporan sistem manual Penyusunan laporan pengelola inventaris sistem manual Penyerahan laporan pengguna & pengelola sistem manual
ELIMINATED
Penyerahan laporan pengguna && pengelola pada sistem komputer
EXISTING
Penyusunan laporan pengguna BMN pada sistem komputer
FUTURE
Penyusunan laporan pengelola inventaris pada sistem komputer
Analisis Gap E-Inventaris
Pencatatan inventaris pada sistem komputer
e.
Replace Replace
X Replace
Replace
NEW
Tabel 4.19 Analisis Gap Arsitektur Bisnis E-Inventaris
190
Portal DTKBDP NEW
Add
ELIMINATED
Add
Aplikasi E-Inventaris
Add
Aplikasi Keuangan
Aplikasi Progress Bangunan
EXISTING
Aplikasi SPK Lelang
Portal DTKBDP
FUTURE
Aplikasi IMB &SLF
2. Analis Gap Arsitektur Aplikasi
Replace Add Add
Tabel 4.20 Analisis Gap Arsitektur Aplikasi DTKBDP
191
3.Analisis Gap Arsitektur Data
: Replace : New : Delete
Tabel 4.21 Analisis Gap Arsitektur Data DTKBDP
192
4. Analisis Gap Arsitektur Teknologi Tabel 4.22 Analisis Gap Arsitektur Bisnis Teknologi DTKBDP
193
C,R,U,D
R
Bangunan
C,R,U,D
R
IMB
C,R,U,D
SLF
C,R,U,D
Tanah
C,R,U,D
Pegawai Pemohon
DPA
C
R
R
R
R
R
C,R,U,D
Design Proyek
C,R,U,D
Lelang
C,R,U,D
Kontraktor
C,R,U,D
R
Material
C,R,U,D
R
Proyek
C,R,U,D
C,R,U,D
R
Progress
C,R,U,D
Pengawas
C,R,U,D
Periode
R
C,R,U,D
Aplikasi Inventaris
R
EXISTING
Aplikasi Keuangan
Aplikasi SPK Lelang
C,R,U,D
Portal DTKBDP
Aplikasi IMB & SLF
FUTURE
Aplikasi Progress Bangunan
5. Aplikasi Matriks Terhadap Data
194
Pengeluaran
C,R,U,D
Klasifikasi Pengeluaran
C,R,U,D
General Ledger
C,R,U,D
Registrasi BMN
C,R,U,D
Peralatan
C,R,U,D
Aset Tak Berwujud
C,R,U,D
Kendaraan
C,R,U,D
Tabel 4.23 Analisis Gap Matriks Aplikasi Terhdap Data
4.8
Phase E: Migration Planning Tahapan perencanaan migrasi bertujuan untuk merencanakan proses
peralihan teknologi dari sistem lama (existing system) menuju ke sistem baru (future system). Rencana migrasi yang dimaksud adalah membuat suatu rencana untuk urutan pengimplementasian aplikasi sistem informasi sesuai prioritas serta roadmap aplikasinya. 4.8.1
Urutan Implementasi Untuk menentukan urutan implementasi aplikasi, maka diperlukan
perspektif organisasi dari sisi operasional.
Perspective operational dibagi
menjadi dua bagian, yaitu kelompok sistem aplikasi yang orientasi fungsinya langsung memberikan pelayanan kepada penggunanya (Front Office System) dan kelompok sistem aplikasi yang orientasi fungsinya lebih banyak ditujukan untuk
195
memberikan bantuan pekerjaan yang bersifat administrasi dan umum (Back Office System). a.
Front Office System Sesuai dengan orientasi fungsinya, maka kandidat aplikasi untuk
Front Office System dapat dilihat pada tabel 4.24 berikut : Nama Aplikasi
Fungsionalitas
Portal DTKBDP
Pengajuan permohonan rekomendasi IMB dan SLF, pencatatan untuk kemudahan tracking masalh dan FAQ, memberikan informasi publik tentang DTKBDP
b.
Back Office System Sesuai dengan orientasi fungsinya, maka kandidat aplikasi
untuk Back Office System dapat dilihat pada Tabel 4.25 berikut : Nama Aplikasi
Fungsionalitas
Aplikasi IMB dan SLF
Mengkonfirmasi permohonan rekomendasi IMB dan SLF serta
196
pembuatan laporan pendaftaran rekomendasi IMB dan SLF Aplikasi SPK Lelang
Pencatatan tentang daftar tempat didaerah tangsel yang akan diperbaiki, serta pencatatan daftar DPA (Detail Pagu Anggaran) serta pemilihan kontraktor yang sesuai
Aplikasi Proress Bangunan
Pencatatan laporan proses bangunan yang sudah berdiri atau masih dibangun disekitar tangsel
Aplikasi E-Inventaris
Pencatatan laporan penggunaan BMN (Barang Milik Negara) yang digunakan di DTKBDP
Aplikasi E-Keuangan
Pencatatan laporan keuangan di DTKBDP serta mengatur periode pembuatan laporan keuangan
197
Berdasarkan perspective diatas, maka urutan implementasi kandidat aplikasi adalah sebagai berikut :
No
Nama Aplikasi
1
Portal DTKBDP
2
Aplikasi IMB dan SLF
3
Aplikasi SPK Lelang
4
Aplikasi Progress Bangunan
5
Aplikasi E-Inventaris
6
Aplikasi E-Keuangan
Tabel 4.26 Urutan Implementasi
198
4.8.2
Roadmaps Roadmaps merupakan arahan pengembangan aplikasi yang bersifat
strategis. Urutan implementasi aplikasi dapat dilihat pada gambar berikut :
TAHAP 1
TAHAP 2
PORTAL DTKBDP
APLIKASI SPK LEANG
APLIKASI IMB & SLF
2015
APLIKASI PROGRESS BANGUNAN
2016
Gambar 4.45 Roadmap Aplikasi
TAHAP 3
APLIKASI E-INVENTARIS
APLIKASI E-KEUANGAN
2017
199
4.8.2.1 Penjelasan Roadmaps Metode pengembangan sistem dalam pembuatan aplikasi pada Dinas Tata Kota, Bangunan dan Pemukiman Kota Tangerang Selatan menggunakan metode RAD (Rapid Application Development). Pada metode ini, terdapat 3 tahapan yang dilakukan, yaitu requirements planning yaitu analisis sistem berjalan dan usulan, Desain workshop RAD yaitu tahapan perancangan sistem dan database, dan implementasi sistem yaitu tahapan pembuatan sistem diantaranya coding, testing dan revisi. Berikut ini merupakan tabel-tabel penjadwalan dan rincian dari roadmap aplikasi portal dan aplikasi IMB dan SLF pada Dinas Tata Kota, Bangunan dan Pemukiman Kota Tangerang Selatan: Tabel 4.27 Roadmap Aplikasi Tahun 2015
Pada pembuatan aplikasi yang pertama yaitu pembuatan portal Garda. Portal DTKBDP bisa digunakan untuk membantu pihak eksternal seperti
200
pemohon untuk membuat rekomendasi permohonan IMB dan SLF, portal juga bisa digunakan oleh pihak eksternal dinas. Pada tahapan requirement planning, analisis sistem berjalan mulai dilakukan pada bulan januari di minggu pertama selama 2 minggu, yang kemudian dilanjutkan dengan analisis sistem usulan mulai dari minggu ketiga januari sampai dengan minggu pertama februari. Selanjutnya pada tahapan desain sistem, perancangan sistem dan perancangan database dilakukan dimulai dari minggu kedua februari sampai dengan minggu ketiga maret atau dilakukas selama 6 minggu. Dilanjutkan dengan tahapan selanjutnya yaitu tahapan implementasi, coding dimulai dari minggu terakhir maret sampai dengan minggu ketiga mei. Setelah coding selesai dilakukan, dilanjutkan dengan pelaksanaan testing aplikasi selama dua minggu, dan jika ada perbaikan bisa dilakukan dimulai dari minggu kedua juni sampai dengan akhir juni 2015. Pada tabel roadmap aplikasi pada tahun 2016 terdapat perancangan aplikasi SPK Lelang dan aplikasi Progress Bangunan. Tabel roadmap aplikasi 2016 dapat dilihat dibawah ini:
201
Tabel 4.28 Roadmap Aplikasi Tahun 2016
Pada tabel 4.26 diatas, dijelaskan mengenai perencanaan penjadwalan roadmap aplikasi SPK Lelang dan aplikasi progress bangunan yang dilakukan pada tahun 2016. Pada awal tahun, dilakukan pembuatan aplikasi SPK Lelang, hal ini dilakukan dengan pertimbangan, karena pencatatan bangunan baru atau lama masih menggunakan ms.office sehingga terkadang data-data terselip atau menumpuk di file, serta memudahkan untuk mencari kontraktor yang sesuai, maka dari itu dengan harapan dibuatnya terlebih dahulu aplikasi ini memudahkan piha DTKBDP untuk mencari data yang diperlukan serta memudahkan untuk mendapatkan kontraktor yang sesuai. Analisis sistem berjalan dilakukan selama dua minggu di awal tahun, lalu dilanjutkan dengan analisis sistem usulan selama tiga minggu. Lalu ditahapan desain sistem, perancangan sistem dan perancangan database dilakukan selama tujuh minggu dimulai dari minggu kedua februari sampai dengan minggu keempat maret. Setelah
perancangan
tersebut
selesai
dibuat,
dilanjutkan
tahap
pembangunan aplikasi selama tujuh minggu untuk tahapan coding, dua minggu
202
untuk pelaksanaan testing sistem, dan tiga minggu untuk pelaksanaan revisi. Begitu pula pembuatan aplikasi progress bangunan, pembuatan aplikasi progress bangunan dilakukan setelah pembuatan aplikasi SPK Lelang selesai dibuat. Dimulai dari awal bulan juli, sampai dengan bulan desember 2016. Tabel 4.29 Roadmap Aplikasi Tahun 2017
Dan untuk perancangan penjadwalan roadmap aplikasi selanjutnya, dilakukan untuk perencanaan dua aplikasi yaitu aplikasi E-inventaris dan aplikasi E-keuangan. Aplikasi E-inventaris dimulai dengan analisis sistem berjalan selama dua minggu, dilanjutkan dengan analisis sistem usulan selama tiga minggu. Lalu pada tahapan desain perancangan sistem dan database dilakukan selama sembilan minggu dimulai di minggu kedua bulan februari sampai dengan minggu kedua bulan april. Pada tahapan implementasi sistem, coding dilakukan selama tujuh minggu dimulai akhir bulan april sampai dengan minggu pertama bulan juni. Pelaksanaan testing di duaminggu setelahnya dan tahapan revisi selama tiga minggu yaitu sampai dengan akhir bulan juni.
i
203
BAB V KESIMPULAN DAN SARAN 5.1 Kesimpulan Berdasarkan hasil pembahasan pada penelitian ini dalam bab sebelumnya, maka dapat disimpulkan sebagai berikut ini: 1. Berdasarkan hasil observasi dan analisis yang diperoleh dalam penelitian ini menggambarkan bahwa DTKBDP belum memiliki perencanaan arsitektur enterprise. Oleh karena itu, penelitian ini membuat suatu perencanaan arsitektur enterprise menggunakan framework TOGAF 9 agar dapat menyelaraskan strategi aktivitas. Perencanaan arsitektur enterprise berupa blueprint (cetak biru) dari arsitektur utama pada TOGAF, yaitu arsitektur bisnis, arsitektur aplikasi, arsitektur data, dan arsitektur teknologi. 2. DTKBDP belum memanfaatkan SI/TI secara maksimal untuk membantu aktivitas disana, seperti untuk pegeloaan data. DTKBDP hanya mengandalkan Microsoft Office untuk membantu aktivitas pengelolaan data. Oleh karena itu, pada perencanaan arsitetur enterprise akan dirancang arsitektur bisnis dan arsitektur sistem informasi untuk memaksimalkan penggunaan SI/TI dengan cara mengomatisasi sistem disana menggunakan aplikasi yang saling terintegrasi.
203
204
5.2 Saran Berdasarkan dari hasil penelitian yang sudah diperoleh, maka ada beberapa saran agar pengembangan penelitian ini di kemudian hari menjadi lebih baik, yaitu : 1. Pada
penelitian
selanjutnya,
fase-fase
TOGAF
ARCHITECTURE
DEVELOPMENT METHOD perlu dilanjutkan sampai fase tata kelola teknologi
informasi
dan
fase
manajemen
perubahan
agar
pengimplementasian arsitektur pada perusahaan menjadi lebih mudah. 2. Setelah menyelesaikan setiap arsitektur, diharapkan penelitian selanjutnya dapat membuat pengukuran ROI (return of investment) yang berguna sebagai analisis biaya investasi yang harus dikeluarkan perusahaan untuk seluruh proses perencanaan strategis sistem informasi ini.
i
DAFTAR PUSTAKA
Aham, Muchtar. 2012 Rancang Bangun Arsitektur Teknologi Informasi Pada Pelayanan Rumah Makan (Studi Kasus : Rumah Makan Pecel Lele Lela Cabang ke-33) Menggunakan TOGAF ADM. Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta. Anggana, Ari. 2012 Perancangan Arsitektur Enterprise Berbasis Web dengan TOGAF ADM di RSUD Dr. Soegiri Lamongan. Bandung : Informatika Gondodiyoto, Sanyoto. 2007. Audit Sistem Informasi + Pendekatan Cobit. Jakarta : Mitra Wacana Media. Jakarta. Jogiyanto. 2005. Analisis dan Desain Sistem Informasi : Pendekatan Terstruktur Teori dan Praktik Aplikasi Bisnis. Yogyakarta : Andi. Jogiyanto. 2008, Sistem Teknologi Informasi : Edisi III. Yogyakarta: ANDI. Internal Staff Workshop, 2008. TOGAF For IT Planning. Pusat Ilmu omputer Universitas Indonesia. Khairunisa, Anis. 2013 Perancangan Strategis Sistem Informasi Menggunakan TOGAF ADM pada PT. Dian Nikel Mining. Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta. Moh, Nazir 2009. Metode Penelitian. Bogor : Ghalia Indonesia. Mulyanto, Agus. 2009. Sistem Informasi Konsep & Aplikasi. Yogyakarta : Pustaka Pelajar. Munawar. 2005. Pemodelan Visual dengan UML, Yogyakarta : Graha Ilmu
Pratiwi, Vivi Fydiani. 2013. Perancangan Model Enterprise Architecture dengan Menggunakan TOGAF Architecture Development Method pada PT. Satya Karya Utama. Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta. Rizki, Soetam. (2011). Konsep Rekayasa Perangkat Lunak. Prestasi Pustaka: Ruffaida, Ridda. 2012. Perancangan ArsitekturTeknologi Informasi Rumah Sakit dengan TOGAF (The Open Group Architecture Framework). Setiawa, Erwin Budi. 2009. Perancangan Strategis Sistem Informasi IT Telkom untuk Menuju World Class University. Yogyakarta : Seminar Nasional Aplikasi Teknologi Informasi 2009 (SNATI 2009). Surendro, Krisdanto, 2009. Pengembangan Rencana Induk Sistem Informasi, Syafriza, 2013. Perancangan Architecture Enterprise Menggunakan Kerangka Kerja Togaf Pada Kantor Pelayanan Umum dan Perizinan Kabupaten Kota Solok. The Open Group. 2009. TOGAF : Sample Catalog, Metrices and Diagram. San Fransisco : The Open Group The Open Group. 2009. TOGAF Version 9.1. San Fransisco : The Open Group. Umami, Aenun Jariyatul. 2013. Perencanaan Infrastruktur Teknologi Informasi di Lembaga Penelitian (Lemlit) UIN Syarif Hidayatullah Jakarta. Fakultas Teknolgi Informasi Universitas Islam Negri. Whitten JL,Bentley LD, Dittman KC. (2006). Tim Penerjemah Andi. Widiatmo,
Raymod
Lukito.
2012.
Perencanaan
Strategis
Sistem
Informasi/Teknologi Informasi Menggunakan Kerangka The Open Group Architecture Framework (TOGAF) (Studi Kasus : Pemda Kabupaten Sumba Barat. Universitas Kristen Satya Wacana Salatiga. Yogyakaerta:Andi.
i
Transkip wawancara I Nama : Heri Asari S.Kom, Msi Jabatan : Staff Bidang IT DTKBDP Tanggal : 18 Agustus 2014
1. Bagaimana proses bisnis utama pada DTKBDP? Proses bisnis utama dari DTKBDP adalah melakukan pelayanan permohonan rekomendasi IMB dan SLF pada setiap bangunan yang nantinya akan dibangun disekitar TangSel. Pelayanan tersebut ditujukan untuk pihak eksternal, yaitu hanya pada sampai tahap pembuatan IMB dan SLF. Namun pihak internal dinas juga memerlukan IMB dan SLF pada setiap bangunan di TangSel. Selain melakukan pelayanan IMB, DTKBDP juga melakukan proses pembangunan sarana dan prasarana pemerintahan atau non pemerintahan didaerah TangSel. 2. Bagaimana alur kerja dari pelayanan IMB dan proses pembangunan didaerah Tangerang Selatan itu sendiri? Pemohon yang ingin membuat IMB harus datang ke DTKBDP serta membawa berkas-berkas yang sudah ditentukan, berkas tersbut akan disidangkan untuk mengethui kelengkapan berkas tersebut, setelah berkas diras lengkap, maka pihak DTKBDP akan melakukan survey pada lahan yang nantinya akan dibangun, dari hasil survey tersebut akan didapatkan siteplan, apabila siteplan sudah sesuai maka akan dicetak rekomendasi
IMB. SLF akan dicetak setelah bangunan sudah didirikan. Dan untuk proses pembangunan di daerah Tangsel, pemerintah kota akan melakukan musrembang pada masyarakat, tujuannya untuk mengetahui bangunan apa saja yang natinya akan dibangun atau diperbaiki, setelah musrembang didapat, maka akan keluar DPA dari bapeda, kemudian bidang design akan membuat gambar dan DTKBDP akan mencari kontraktor yang nantinya akan membangun bangunan tersebut. 3. Apakah DTKBDP sudah mempunyai aplikasi khusus? Untuk saat ini, DTKBDP hanya menggunakan Microsoft Exel dan word untuk melakukan transaksi. 4. Apakah DTKBDP sudah memiliki suatu perencanaan strategis sistem informasi? DTKBDP belum memiliki perencanaan SI dan TI. 5. Bagaimana gambaran besar sistem informasi secara keseluruhan? Kami disini sebagian besar hanya menggunakan Microsoft word maupun Microsoft exel untuk mengolah data dan informasi. Belum ada sistem informasi secara keseluruhan. 6. Bagaimana infrastruktur jaringan yang ada di DTKBDP? Saat ini, agar semua bagian terkoneksi dengan internet maka DTKBDP mengandalkan router
di lantai 1 yang berfungsi sebagai gateway.
Kemudia, router tersebut akan terhubung dengan jaringan LAN dan terhubung dengan wireless. 7. Aplikasi apa saja yang sudah dimiliki DTKBDP?
Yang khusus dikembangkan oleh DTKBDP sendiri belum ada. DTKBDP hanya mempunyai website. 8. Bagaimana pengelolaan data pada DTKBDP saat ini? Untuk pengelolaan data, kami hanya menggunakan aplikasi dasar yang seperti microsoft word dan icrosoft exel. 9. Bagaimana rencana pengembangan sistem teknologi informasi kedepannya? Untuk kedepannya kami menginginkan pelayanan IMB dan SLF bisa dilakukan secara online, begitu juga pada proses pembangunan agar memudahkan DTKBD untuk memdapatkan kontraktor yang sesuai dan juga adanya suatu sistem terintegrasi, sehingga memudahkan dalam pertukaran data dan informasi.
