2.2. Kerangka Pemikiran Berdasarkan landasan teori dan tinjauan pustaka diatas yang telah dipaparkan, maka kerangka pemikiran dari penelitian ini dapat digambarkan sebagai berikut :
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Sumber Daya Teknologi Informasi
-
Data Sistem aplikasi Teknologi Fasilitas Orang Keuangan Organisasi
Proses-proses Teknologi Informasi - Perencanaan dan organisasi - Akuisi dan implementasi - Penyampaian dukungan - Pengawasan dan evaluasi
Kerangka kerja Zachman Framework
Kebutuhan Bisnis
-
Keefektifan Efisiensi Kerahasiaan Integritas Ketersediaan Kepatuhan Kehandalan informasi
Metode EAP
TERCAPAINYA ARSITEKTUR ENTERPRISE STMIK SUMEDANG Gambar 2 Kerangka Pemikiran Penelitian
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
3. PEMBAHASAN Untuk melakukan penelitian ini, penulis melakukan langkah-langkah penelitian tata kelola teknologi informasi di STMIK Sumedang Jenis penelitian yang dilakukan oleh penulis yaitu sebagai berikut : a. Penelitian tentang perencanaan terhadap tata kelola penerapan teknologi informasi bersifat penelitian deskriptif, artinya hasil penelitian yang telah dilakukan disampaikan dalam bentuk deskripsi yang bersifat kualitatif. b. Penelitian yang dilakukan bersifat eksploratif artinya penelitian dilakukan dengan cara menggali informasi dan data penunjang teknologi informasi yang berlangsung di STMIK Sumedang. 3.1 Analisis Rantai Nilai STMIK Sumedang 3.1.1 Identifikasi Entitas Bisnis pada setiap Area Fungsi Rantai nilai STMIK Sumedang (STMIK SMD) pada gambar 3.1 diidentifikasikan dengan menggunakan pengelompokkan yang disarankan Porter. Sebagai sebuah institusi pendidikan, STMIK SMD menjalankan aktivitas-aktivitas bisnis utama yang berhubungan dengan penyelenggaraan fungsi pendidikan mahamahasiswa dan pemberdayaan alumni, dengan tujuan untuk menghasilkan lulusan-lulusan yang handal dan memiliki kompetensi tinggi. Dalam rantai nilai STMIK SMD, aktivitas-aktivitas tersebut berada pada area fungsi utama yang mengandung entitas-entitas bisnis. Untuk menunjang keberhasilan fungsi utama, maka STMIK SMD menjalankan aktivitas-aktivitas pendukung yang berada pada area fungsi penunjang. Entitas bisnis yang didefinisikan dalam rantai nilai STMIK SMD merupakan fungsifungsi yang menghasilkan produk dan informasi, serta menggunakan sumber daya, sehingga entitas bisnis yang didefinisikan dalam Tesis ini bisa juga disebut sebagai area fungsi bisnis. Setiap produk, informasi, dan sumber daya yang digunakan akan diuraikan pada bagian analisis katalog sumber daya informasi.
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Gambar 3 Rantai Nilai STMIK Sumedang Sumedang
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Entitas-entitas bisnis atau area fungsi bisnis yang berada pada area fungsi utama dan penunjang diuraikan dalam tabel 1 dan tabel 2.
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Tabel 1 Entitas Bisnis pada Area Fungsi Utama No. Entitas Bisnis Deskripsi 1. Penerimaan Mahasiswa Fungsi yang melaksanakan kegiatan penerimaan mahasiswa baru. 2. Operasional Akademik Fungsi yang melaksanakan kegiatan operasional akademik berkaitan dengan proses belajarmengajar. 3. Pelepasan Akademik Fungsi yang melaksanakan kegiatan pelepasan mahasiswa atau lulusan, dan mengupayakan pemberdayaan lulusan. Tabel 2 Entitas Bisnis pada Area Fungsi Penunjang No. Entitas Bisnis Deskripsi 1. Pengelolaan Sarana dan Fungsi yang menyediakan dan Prasarana mengelola kebutuhan sarana dan prasarana pendukung pelaksanaan kegiatan akademik. 2. Pengelolaan Sumber Daya Fungsi yang menyediakan, Manusia mengelola, dan memberdayakan sumber daya manusia pelaksana fungsi-fungsi enterprise. 3. Pengelolaan Keuangan Fungsi yang menyediakan dan mengelola keuangan enterprise. 4. Tatalaksana dan Organisasi Fungsi yang mengatur dan menentukan struktur organisasi dan tatalaksana fungsi-fungsi enterprise.
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
3.1.2. Dekomposisi Fungsi dan Proses Dekomposisi fungsi dilakukan untuk menguraikan area-area fungsi bisnis pada area fungsi utama dan penunjang ke dalam fungsifungsi yang lebih rinci hingga ke tingkatan operasional (proses bisnis). Dekomposisi fungsi dilakukan dengan mempertimbangkan keterhubungan antar fungsi dan proses, serta memperhatikan faktor efisiensi untuk menghindari terjadinya pendefinisian fungsi dan proses bisnis yang berulang (tumpang tindih). Hasil dekomposisi fungsi dapat dilihat pada tabel 3.
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Tabel 3. Hasil Dekomposisi Fungsi 1
Pendidikan 1.1 Penerimaan Mahasiswa 1.1.1 Penentuan Kebijakan 1.1.1.1 Penetapan Panitia 1.1.1.2 Standardisasi Seleksi 1.1.1.3 Penentuan Daya Tampung 1.1.1.4 Penjadwalan 1.1.2 Pemasaran 1.1.2.1 Riset Pasar 1.1.2.2 Penetapan Strategi 1.1.2.3 Pelaksanaan 1.1.2.4 Evaluasi dan Pelaporan 1.1.3 Seleksi 1.1.3.1 Pengadaan Undangan Seleksi Masuk 1.1.3.1.1 Seleksi Sekolah 1.1.3.1.2 Seleksi Siswa 1.1.3.2 Pengadaan Ujian 1.1.3.2.1 Penyusunan Materi Ujian 1.1.3.2.2 Penerimaan Pendaftaran 1.1.3.2.3 Pelaksanaan 1.1.3.2.4 Pengolahan Hasil 1.1.4 Registrasi Mahasiswa 1.2 Operasional Akademik 1.2.1 Penetapan Kurikulum 1.2.2 Penetapan Kalender Akademik 1.2.3 Herregistrasi Mahasiswa 1.2.3.1 Penawaran Kuliah 1.2.3.2 Pemrosesan Rencana Studi 1.2.3.3 Pembuatan KTM 1.2.4 Perubahan Rencana Studi 1.2.5 Perkuliahan Reguler 1.2.5.1 Penjadwalan 1.2.5.2 Pelaksanaan 1.2.5.3 Pelaporan 1.2.5.4 Ujian 1.2.6 Perkuliahan Nonreguler 1.2.6.1 Pengurusan Lokasi 1.2.6.2 Bimbingan dan Pengawasan 1.2.7 Perwalian 1.2.8 Penilaian 1.2.9 Perpindahan Program Studi 1.2.10 Cuti Akademik 1.2.11 Sidang Akademik 1.2.12 Pelaporan Akademik 1.3 Penglepasan Akademik 1.3.1 Drop Out 1.3.2 Pengunduran Diri 1.3.3 Pembuatan Ijazah 1.3.4 Pembuatan Transkrip
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
1.3.5 Wisuda 2 Manajemen Keuangan 2.1 Penganggaran 2.1.1 Persiapan Anggaran 2.1.1.1 Penginstruksian Anggaran 2.1.1.2 Persiapan Permintaan 2.1.1.3 Persiapan Pengesahan Anggaran 2.1.2 Dropping 2.1.3 Pengawasan dan Peninjauan Anggaran 2.1.4 Revisi Anggaran 2.2. Akuntansi 2.2.1 Akuntansi General Ledger 2.2.2 Pelaporan Keuangan 2.2.3 Penerimaan 2.2.4 Akuntansi Utang dan Pembayaran 2.2.4.1 Pengelolaan Pembayaran 2.2.4.2 Penggantian Biaya 3 Manajemen Sumber Daya Manusia 3.1 Persiapan Pembayaran Personil 3.1.1 Pengelolaan Potongan 3.1.2 Pengelolaan Cuti 3.1.3 Pengumpulan Laporan Waktu 3.1.4 Pengelolaan Tunjangan 3.1.5 Perhitungan Honor 3.1.6 Perhitungan Gaji 3.2. Manajemen Personil 3.2.1 Pengelolaan Informasi Personil 3.2.2 Pengelolaan Rekrutmen 3.2.3 Pembinaan 3.2.4 Pengembangan 4 Manajemen Logistik 4.1 Pengadaan 4.1.1 Pengelolaan Vendor 4.1.2 Pemesanan 4.1.3 Penerimaan Aset 4.2 Manajemen Inventaris 4.2.1 Penilaian Inventaris 4.2.2 Penelusuran Inventaris 4.2.3 Penghapusan Inventaris
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page v
3.1.3. Arsitektur Data Untuk mendefinisikan arsitektur data, pertama sekali didaftarkan kandidat entitas data dengan melakukan brainstorming terhadap Pimpinan, UPT, Biro, Program Studi, Staff yang memiliki makna (informasi) sehubungan dengan model bisnis STMIK Sumedang. Setiap informasi yang digunakan dalam pelaksanaan fungsi bisnis juga dikaji untuk dijadikan sebagai kandidat entitas data. Setiap kandidat entitas dibuat deskripsinya sehingga dapat diperiksa kelayakannya sebagai entitas data. Setiap entitas data akan dianalisis relasinya dengan entitas lain untuk memahami makna semantik dari data. Setiap entitas tersebut kemudian dibandingkan dengan daftar data (berupa file/tabel) yang dikelola sistem saat ini pada Katalog Sumber Daya Informasi. Pembandingan ini dilakukan untuk memeriksa apakah data dalam Katalog Sumber Daya Informasi telah tercakup dalam entitas arsitektur data berdasarkan deskripsi data. Dengan melaksanakan tahapan definisi seperti di atas didapatkan arsitektur data yang berkualitas atau baik. Arsitektur data yang baik memiliki karakteristik mudah dipahami definisinya, lengkap dalam arti tidak ada entitas data utama yang diabaikan, konsisten dalam arti tidak ada definisi yang tumpang tindih, dan stabil sebagai konsekuensi dari definisi yang didasarkan pada model bisnis yang juga diupayakan stabil. Arsitektur data disajikan dalam bentuk diagram E-R. Terlepas dari saran penggunaan diagram E-R dalam pedoman EAP, diagram E-R dipilih mengingat arsitektur data hanyalah mengidentifikasi dan mendefinisikan entitas data. Untuk keperluan memvisualkan entitasentitas data tersebut beserta makna konseptualnya, diagram E-R sudah memadai. Di samping itu, penggunaan diagram E-R yang relatif lebih sederhana dibanding diagram pemodelan data lainnya akan memudahkan orang-orang dalam enterprise untuk memahami arsitektur data. Untuk memudahkan pemahaman diagram, diagram E-R akan dipecah berdasarkan area fungsional utama dalam model bisnis. Pemecahan dalam beberapa diagram ini hanya bertujuan supaya diagram
lebih mudah dibaca dan dipahami. Berikut ini adalah diagram-diagram E-R tersebut: a. Diagram E-R yang pertama merepresentasikan penerimaan mahasiswa baru berdasarkan analisis dan kejadian yang berjalan terbentuk entitas sebagai berikut : 1. Personil 2. Media Massa 3. Program Studi 4. Analisis Kebutuhan 5. Jadwal PMB 6. Panitia PMB 7. Pemasaran 8. Kalender Akademik 9. Peserta PMB 10. SMU dan Sederajat 11. Peserta USMS 12. Peserta Ujian 13. Soal Ujian PMB.
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Dengan Gambar E-R Sebagai berikut :
Pindahann
Gambar 3 Diagram E-R penerimaan mahasiswa baru
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page v
b. Diagram E-R yang kedua adalah Akademik dan Penglepasan merepresentasikan penerimaan mahasiswa baru berdasarkan analisis dan kejadian yang berjalan terbentuk entitas sebagai berikut : 1. Mitra Kerjasama 2. Nilai 3. Jadwal Kuliah 4. Absensi Kuliah 5. Kalender Akademik 6. Registrasi Kuliah 7. Mata kuliah 8. Absensi Dosen 9. Program Studi 10. Jadwal Ujian 11. Mahasiswa 12. Dosen 13. Dosen Biasa 14. Alumni
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Dengan Gambar E-R Sebagai berikut :
Gambar 4 Diagram E-R akademik dan penglepasan Akademik
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page v
c. Diagram E-R yang ketiga adalah Manajemen Keuangan merepresentasikan penerimaan mahasiswa baru berdasarkan analisis dan kejadian yang berjalan terbentuk entitas sebagai berikut : 1. Anggaran 2. Realisasi 3. Asumsi 4. Pendapatan 5. Pengeluaran 6. Pesaing 7. Personil 8. Mahasiswa.
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Dengan Gambar E-R sebagai berikut :
Gambar 5 Diagram E-R manajemen keuangan
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page v
d. Diagram E-R yang keempat adalah Manajemen Sumber Daya Manusia merepresentasikan penerimaan mahasiswa baru berdasarkan analisis dan kejadian yang berjalan terbentuk entitas sebagai berikut : 1. Gaji 2. Cuti 3. Absensi personil 4. SKI 5. Tunjangan Lain 6. Honor 7. Pendidikan 8. Pelatihan 9. Personil 10. Pelamar 11. Tenaga Penunjang Akademik 12. Dosen 13. Dosen Biasa 14. Dosen Tamu 15. Dosen Luar Biasa
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Gambar 6 Diagram E-R manajemen sumber daya manusia
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
e. Diagram E-R yang kelima adalah Manajemen Logistik merepresentasikan penerimaan mahasiswa baru berdasarkan analisis dan kejadian yang berjalan terbentuk entitas sebagai berikut : 1. Rencana Kebutuhan 2. Pesanan Pengadaan 3. Vendor 4. Logistik 5. Faktur
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Gambar 3.6 Diagram E-R manajemen logistik Gambar 3.5
Diagram E-R Logistik
Gambar 7 Dagram E-R Manajemen Logistik
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
3.2. Arsitektur Teknologi 3.2.2. Prinsip dan Platform Teknologi Setelah data dan aplikasi didefinisikan, maka tiba saatnya untuk mendefinisikan jenis teknologi utama yang dibutuhkan untuk mengimplementasikan lingkungan berbagi pakai data dan aplikasi di STMIK Sumedang. Walaupun teknologi merupakan elemen SI enterprise yang paling tidak stabil karena perkembangannya yang sangat cepat, arsitektur teknologi harus diusahakan stabil sebagai bagian dari rencana strategis sistem informasi. Pertama sekali, prinsip-prinsip platform teknologi yang mendasari pemilihan suatu platform teknologi akan diidentifikasikan. Untuk memudahkan identifikasi dan supaya lebih fokus, prinsip platform teknologi dibagi dalam 7 (tujuh) area seperti pada gambar di bawah ini dengan tujuan untuk memfokuskan formulasi prinsip area.
Keamanan
Komputasi Pemakai
Komunikasi
Perangkat Keras
Aplikasi
Manajemen Data
Sistem Operasi
Arsitektur Teknologi
ditambahkan untuk menambah fungsionalitas, memberikan kemungkinan pengembangan, dan menghemat biaya pengadaan. Platform yang dipilih seharusnya bebas dari vendor. Akan tetapi, ini dimungkinkan jika sesungguhnya platform bersangkutan telah dimiliki oleh enterprise. Selain itu, bisa saja platform yang berlabel nama vendor itu memang telah dimanfaatkan secara penuh. Daftar platform teknologi yang akan digunakan sebagai lingkungan berbagi pakai data dan aplikasi Pada dasarnya, tidak terjadi perubahan platform yang terlalu signifikan. Akan tetapi, platform ini masih dimungkinkan bertambah atau bahkan berkurang dalam implementasi data dan aplikasi. Teknologi merupakan salah satu elemen enterprise yang keberadaan atau pengadaannya sering tidak sesuai dengan kebutuhan sebenarnya dari enterprise. Untuk itu platform teknologi yang telah diusulkan harus dijustifikasi keberadaan atau pengadaannya terhadap model bisnis dan arsitektur aplikasi. Bisnis dan aplikasi merupakan dua elemen yang secara langsung memanfaatkan aplikasi. Justifikasi akan disajikan dengan Matriks
Gambar 8 Tujuh area formulasi prinsip platform teknologi Prinsip platform teknologi diformulasikan dengan menilai tren dan perkembangan TI. Model bisnis, arsitektur data, arsitektur aplikasi, sistem dan teknologi yang sudah ada, temuan/masukan dari pelaku bisnis dalam enterprise juga ditinjau kembali untuk formulasi prinsip. Berdasarkan prinsip yang telah diformulasikan sebelumnya, platform teknologi yang sudah ada (salah satu elemen dalam Dokumen Katalog Sumber Daya Informasi) ditinjau kembali. Platform teknologi yang usang atau redundan dihapus. Beberapa platform teknologi baru Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
Dari kedua matriks tesebut didapatkan beberapa golongan platform teknologi berdasarkan justifikasinya dengan aplikasi dan fungsi bisnis: 1. Platform teknologi yang mendukung aplikasi maupun fungsi bisnis Platform teknologi yang demikian biasanya terkait dengan pemenuhan kebutuhan otomasi fungsi bisnis melalui keberadaan aplikasi dan data elektronik. Contoh platform teknologi yang demikian antara lain: PC IBM dan yang kompatibel (1.1.1), monitor (1.3.2), dan sebagainya. 2. Platform teknologi yang tidak mendukung suatu aplikasi tertentu namun mendukung fungsi bisnis Platform teknologi yang demikian merupakan sarana pendukung aktifitas bisnis yang tidak diotomasikan dengan aplikasi atau masih terkait dengan aktifitas manual. Platform teknologi ini biasanya merupakan perangkat Office Automation. Contoh platform teknologi yang demikian antara lain Microsoft Access (2.2.2), Microsoft Word (2.5.1), Microsoft Outlook (2.8.2), PABX (3.2.1), dan sebagainya. 3. Platform teknologi yang tidak mendukung aplikasi maupun fungsi bisnis Pengadaan platform yang demikian biasanya terkait dengan pemenuhan prinsip platform teknologi walaupun dalam praktiknya tidak secara langsung mendukung suatu aplikasi atau fungsi bisnis tertentu. Contoh platform yang demikian antara lain: Backup Device (1.4.2) dan Java (2.3.2). Penyediaan kedua platform teknologi ini masing-masing merupakan pemenuhan terhadap prinsip pengamanan kesinambungan pemakaian data/aplikasi dan penyediaan kemungkinan pengembangan.
yang dilaksanakan di sana. Lokasi bisnis juga akan memperlihatkan tempat di mana diperlukan data dan aplikasi tertentu. Hal ini diperlihatkan dengan Matriks. Dengan matriks ini jelas terlihat lingkungan berbagi data dan aplikasi. Matriks pada aplikasi dapat digunakan untuk membuat strategi penempatan data dan aplikasi, arsitektur komputasi yang akan dimanfaatkan sesuai prinsip platform teknologi adalah arsitektur client/server, tepatnya arsitektur WWW (World Wide Web). Aplikasi dan data akan ditempatkan pada satu lokasi dan dapat diakses oleh seluruh pemakai. Lokasi ini akan berada di bawah tanggung jawab UPT Lab dan pengembangan TI STMIK Sumedang. 3.2.4. Konfigurasi Teknologi Konseptual Konfigurasi teknologi konseptual akan memberikan pedoman bagaimana konfigurasi teknologi yang diharapkan dalam pemanfaatan teknologi. Konfigurasi konseptual hanya akan diwujudkan dalam dua tingkatan sebagai berikut:
3.2.3. Distribusi Data dan Aplikasi Setelah menentukan prinsip dan platform teknologi, selanjutnya akan ditentukan strategi distribusi data dan aplikasi dengan meninjau lokasi bisnis. Lokasi bisnis merupakan lokasi tiap unit organisasi dalam melaksanakan aktifitas bisnisnya. Suatu lokasi bisnis dengan demikian terkait dengan unit organisasi tertentu dan fungsi bisnis apa saja Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page v
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page iv
1. Jaringan enterprise konseptual Internet Files DB
Backup Device
Files
Backup Device
Files
Backup Device
Backup Device DB
Backup Device
Database Server
Mail Server Proxy Server File Server Web Server
Application Server
Switch
LAN
LAN WLAN
WLAN
Workstations & Printers Smart Card Device
Wireless Workstations
Gambar 9 Jaringan enterprise konseptual
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page v
1. Arsitektur sistem bisnis
Data
Applications
Operational Information Update
Operational Information Inquiry
Operational Report Review
Ad Hoc Information Review
Business Rules Inquiry/ Update
User Workstations
Gambar 10 Arsitektur sistem bisnis
Jurnal INFOMAN’S STMIK Sumedang Volume 4 Edisi 2 November 2011
Page vi
Pada Gambar 10, ditetapkan 5 (lima) tujuan pemakai mengakses sistem bisnis/aplikasi: 1. Operational Information Update: membuat, mengubah, dan menghapus data operasional secara interaktif 2. Operational Information Inquiry: memungkinkan aplikasi mengakses data secara interaktif dan melihat sajian data dalam berbagai format dan media yang bisa dipersiapkan selanjutnya 3. Operational Report Review: membantu pemakai untuk mendapatkan sajian laporan 4. Ad Hoc Information Review: menyediakan fasilitas untuk mengakses data dengan SQL atau bahasa 4GL lainnya 5. Business Rules Inquiry/Update: memungkinkan pemakai yang telah diotorisasi untuk mengubah aturan yang ditetapkan untuk operasi sistem bisnis. 4. Kesimpulan dan Saran Kesimpulan yang didapatkan dalam proses pengerjaan tesis ini adalah sebagai berikut: a. Sehubungan dengan hasil-hasil yang dicapai dengan pelaksanaan EAP 1. Cetak biru EAP dapat dijadikan sebagai pedoman untuk menghilangkan redundansi data, aplikasi, dan platform teknologi, serta mengendalikan belanja TI. 2. Terbentuknya model tingkat tinggi dan rencana implementasinya merupakan hal yang dibahas dalam tesis ini. b. Sehubungan dengan metodologi EAP itu sendiri 1. EAP dapat dimanfaatkan sebagai upaya menyelaraskan TI dengan bisnis. Setiap pekerjaan arsitektural yang berhubungan dengan bagaimana kebutuhan TI di masa mendatang selalu harus disesuaikan atau dijustifikasi dengan model bisnis baik secara langsung maupun tidak langsung 2. EAP merupakan metode yang sangat pragmatis. EAP mengandung langkah-langkah untuk mengatasi atau memperhatikan masalah-masalah praktis dan politis terkait dengan perencanaan SI Beberapa saran yang diajukan untuk kelanjutan kajian tesis ini adalah sebagai berikut: a. Perlunya pengkajian ulang terhadap model bisnis atau cetak biru yang telah dihasilkan dalam setiap tahapan EAP untuk prose pengembangan sistem lebih detail Model bisnis merupakan pondasi perencanaan. Setiap perubahan pada model bisnis sedikit banyak akan berdampak kepada cetak biru yang hendak dihasilkan. Untuk itu, model bisnis harus diupayakan sedemikian rupa sehingga stabil namun bukan berarti kaku. Model bisnis juga seharusnya tanggap terhadap perubahan bisnis selama proses EAP sehingga perlu dilakukan kaji ulang model bisnis dalam setiap langkah pembuatan cetak biru. Selain itu, pemahaman akan model bisnis dan cetak biru biasanya bertambah seiring dengan pelaksanaan EAP sehingga selain kaji ulang model bisnis juga disarankan kaji ulang cetak biru yang telah dihasilkan dalam setiap tahapan EAP. Di balik itu, hambatan waktu dan sumber daya harus diseimbangkan dengan kebutuhan kaji ulang ini. b. Pemanfaatan metodologi atau tool lain untuk meneruskan pengembangan arsitektur enterprise Cetak biru yang dihasilkan dalam EAP masih merupakan model tingkat tinggi yang dapat diterjemahkan ke bentuk yang lebih detil dalam perancangan dan implementasi sistem TI. Metodologi atau tool seperti EAB, UML, IDEF, dan sebagainya dapat dimanfaatkan untuk tujuan itu. c. Mengadopsi manajemen risiko dalam rencana implementasi EAP Rencana implementasi tak lain merupakan suatu rencana proyek berskala besar untuk mengimplementasikan cetak biru yang telah dihasilkan. Untuk itu, perlu diadopsi teknik manajemen risiko untuk meminimalkan risiko-risiko yang mungkin terjadi demi keberhasilan implementasi EAP, seperti risiko yang terkait dengan sumber daya manusia TI yang terkait, risiko jika jadwal implementasi EAP tidak dipenuhi, dan sebagainya.
7
DAFTAR PUSTAKA McGovern, James., Ambler W, Scott., Stevens E, Michael., Linn, James., Sharan, Vikas., Jo K., Elias. (2003), A Practical Guide to Enterprises Architecture, Prentice Hall PTR. Nebraska Information Technology Commission Strategic Initiatives (2005), Strategic Plan for Enterprise Architecture for State Government. PBGC (2005), Enterprise Architecture Plan – Baseline and Transition Planning, The Pension Benefit Guaranty Corporation. Riverton (2005), “What is Enterprise Architecture ?”, Riverton Corporation. IEEE, IEEE STD 610.12. Wikipedia (2007), Enterprise Architecture, www.wikipedia.org Cook, Melissa A. (1996), Building Enterprise Information Architectures (Reenginering Information Systems), Prentice Hall. Hagan, Paula J., Dr. (2004), Guide to the (evolving) Enterprise Architecture Body of Knowledge, Mitre Corporation. Zachman, John A. (1987), A Framework for Information System Architecture, IBM System Journal 26, No. 3, 276-292. Zachman, J. A. (1996), The Framework for Enterprise Architecture: Background, Description, and Utility, Zachman International, Inc. Spewak, S. H., Hill, S. C. (1992), Enterprise Architecture Planning: Developing a Blueprint for Data, Applications, and Technology, John Wiley & Sons, Inc. IBM (1981), Business System Planning : Information System Planning Guide. IT Governance Institute (2005), Control Objective for Information and Related Technology 4.0 (Control Objectives, Management Guidelines, Maturity Models), http://www.itgi.org. Ward, John., Peppard, Joe (2005)., Strategic Planning for Information Systems, John Wiley & Sons, Inc. Zachman, J. A. (1996), The Framework for Enterprise Architecture: Background, Description, and Utility, Zachman International, Inc. ANALISIS DAN PERANCANGAN SISTEM INFORMASI LAPORAN KEUANGAN HOTEL DENGAN PENDEKATAN RAPID APPLICATION DEVELOPMENT Oleh : Kiki Alibasah, M.Kom. Dosen Tetap Program Studi Manajemen Informatika STMIK Sumedang
ABSTRAK Sistem Informasi di hotel merupakan sarana agar semua informasi dapat di sajikan dengan cepat, saat ini banyak hotel melati yang tidak memiliki sistem informasi apalagi sistem informasi laporan keuangan yang menyajikan informasi tentang seluruh transaksi keuangan yang ada di hotel tersebut. Perkembangan teknologi informasi yang sedemikian cepat memberikan dampak yang cukup signifikan terhadap beberapa prinsip atau konsep manajemen yang telah ada. Solusi dengan adanya kondisi tersebut yaitu dengan memanfaatkan teknologi informasi yang sedang berkembang saat ini yaitu Sistem Informasi Laporan Keuangan. Penerapan Sistem Informasi Laporan Keuangan berguna sebagai solusi sistemik dalam proses perencanaan dan pengambilan kebijakan ke depannya agar menjadi lebih efektif, efisien dan transparant. Perancangan sistem informasi Laporan Keuangan dimulai dengan melakukan identifikasi kebutuhan sistem. Berdasarkan kebutuhan tersebut akan dibuat desain sistem, yang dimodelkan dengan menggunakan metode UML, dan pendekatan yang digunakan dalam menyusuntesis ini adalah RAD (Rapid Application Development). 8
Hasil dari penelitian ini berupa rancangan sistem informasi Laporan Keuangan yang memiliki fasilitas untuk mengelola data penerimaan kas, data pengeluaran kas, evaluasi terhadap pelayanan, penawaran dan tarif kamar hotel hingga mendapatkan pelanggan yang tetap. Selain itu terdapat fasilitas untuk menyajikan laporan keuangan berupa,penerimaan dan pengeluaran kas, laporan rugi laba, arus kas, perubahan modal dan neraca. Kata kunci : sistem informasi, keuangan, hotel,UML, RAD.
9
langsung dengan tujuan untuk mengotomasi pekerjaan dan mempercepat waktu proses serta menyederhanakan pekerjaan yang ada dan dapat menyajikan laporan keuangan dari transaksi yang ada. Beberapa Hotel memulai beroperasi dari manajemen dan pemilik yang baru terjun dalam bisnis hotel merasa kesulitan untuk mengetahui jumlah kamar yang dipesan dan terisi oleh pelanggan, padahal kecepatan informasi yang disajikan oleh front office kepada pelanggan sebuah bentuk pelayanan yang pertama kali jika informasi tersebut sulit didapat dan tidak akuratnya informasi tersebut membuat pelanggan kecewa karena pada dasarnya bisnis hotel adalah bisnis pelayanan, satu hal yang lebih penting pada saat bisnis sudah berjalan maka manager dan pemilik hotel sangat kesulitan mengetahui jumlah pendapatan dan pengeluaran kas hotel, serta menyajikan laporan keuangan.
1. PENDAHULUAN Hotel merupakan bisnis yang mengedepankan pelayanan dimana apabila pelayan hotel tersebut dapat memuaskan pelanggan maka pelanggan akan menginformasikan kepuasan tersebut kepada yang lainnya demikian pula sebaliknya jika pelayanan mengecewakan maka pelanggan akan memberitahukan hal yang negatif tersebut kepada yang lainnya, Pemanfaatan Sistem Informasi hotel sebagai sebuah alat bantu dalam melaksakan kegiatan bisnis sebuah hotel dimana informasi tentang pemesanan dan penjualan kamar hotel dapat di sajikan dengan cepat oleh front office kepada pelanggan. Dengan pemanfaatan sumber daya informasi secara maksimal akan dapat memberikan suatu alat bagi perusahaan guna menjaga proses yang dilakukan tetap berjalan secara lancar,mudah,cepat,akurat,dan efisien. Penggunaan Sistem Informasi berbasiskan komputer sekarang adalah suatu pilihan yang mau tidak mau harus diimplementasikan di perusahaan guna menjaga agar informasi yang didapatkan didalam perusahaan bisa memenuhi kebutuhan kebutuhan tersebut. Dengan semakin meningkatnya peran dari Sistem Informasi yang di dukung oleh Teknologinya dalam kegiatan penyajian laporan keuangan di sebuah hotel pada saat ini maka perlu bagi suatu hotel untuk menyusun suatu perencanaan strategis sistem informasi agar sistem informasi yang ada didalam organisasi tersebut bisa digunakan untuk mendukung pencapaian tujuan dari hotel tersebut yaitu penyajian laporan keuangan untuk mendukung kemudahan dalam pengambilan kebijakan dalam pengembangan selanjutnya.
Salah satu untuk mendukung pelayanan bagi konsumen di sebuah hotel adalah jumlah kamar yang tersedia untuk dipesan dan informasi yang dibutuhkan oleh manajemen adalah tingkat hunian setiap harinya yang dapat menggambarkan jumlah pendapatan kotor yang diperoleh, informasi tentang tingkat hunian juga dibutuhkan oleh bagian lainnya contoh bagian konsumsi atau restoran harus menyiapakan sarapan untuk setiap kamar adalah 2 orang, begitu pula bagian house Penelitian dilakukan dengan menggunakan metode Rapid Application Development (RAD) dengan studi kasus yang bertujuan untuk mendapatkan gambaran yang lebih mendalam dan lengkap dari subyek yang akan diteliti. Pengumpulan data dan informasi disini sangat terkait dengan user requirement yang akan memanfaatkan Sistem Informasi. Data dan informasi diperoleh dari data primer dan data sekunder. Data primer, diperoleh dengan melakukan wawancara dan observasi tentang model Sistem Infomasi. Sedangkan data sekunder diperoleh melalui studi pustaka, yaitu melalui studi literatur dan tulisan ilmiah tentang Sistem Informasi.
Beberapa Hotel saat ini memasuki dunia bisnis yang dinamis, hal tersebut memberikan kesempatan untuk menciptakan sistem kerja yang lebih efisien dan cara kerja yang lebih profesional untuk meningkatkan pelayanan kepada setiap Pelanggan. Sebuah hotel yang telah menerapkan sistem informasi penjualan jasa kamar hotel, sistem informasi ini ini di tempatkan pada front office kegiatan pemesanan dan penjualan kepada pelanggan secara
Masalah yang dihadapi saat ini adalah : 10
a. Belum tersedianya informasi jumlah pendapatan per hari dari jasa penjualan kamar hotel, jasa laundry dan pendapatan Restaurant. b. Belum tersedianya pencatatan biaya yang dikeluarkan untuk menunjang operasional hotel. c. Belum tersedianya laporan keuangan yang terdiri dari : laporan rugi laba, Laporan arus kas, perubahan modal, dan neraca. d. Belum tersedianya rekap pendapatan dan pengeluaran kas harian, mingguan, dan bulanan.
b. Tersedianya design sistem informasi yang berupa: jumlah penerimaan kas,jumlah pengeluaran kas,jumlah beban, laporan rugi laba, arus kas, perubahan modal pemilik, neraca, dan buku kas harian hotel per periode tertentu. Diharapkan dengan adanya deisgn Sistem Informasi Laporan Keuangannnya ini dapat memberikan manfaat sebagai berikut: a. Adanya gambaran dari design entry data penerimanaan dan pengeluaran kas dari semua transaksi yang ada di hotel untuk di evaluasi agar memudahkan Implementasi. b. Design yang tersedia sudah mencerminkan laporan keuangan yang di inginkan oleh user berupa: jumlah penerimaan dan penegluaran kas, jumlah beban, laporan rugi laba, arus kas, perubahan modal pemilik, neraca, dan buku kas harian hotel perperiode tertentu.
Untuk dapat menyelesaikan penelitian tepat waktu dan dengan sumberdaya yang terbatas, maka permasalahan yang akan dibahas harus dibatasi. Batasan masalah tersebut adalah : a. Pada penelitian ini dilakukan sebatas merancang sistem informasi laporan keuangan dengan menggunakan UML dan pendekatan RAD (Rapid Application Development). b. Pada pembuatan laporan keuangan banyak berinteraksi dengan Pemilik dan Manager tentang kebutuhan penyajian dari laporan tersebut. c. Membuat rancangan networking untuk pengembangan selanjutnya.
2. ANALISIS 2.1. Analisis Kebutuhan Analisis kebutuhan yang dilakukan adalah dengan metode observasi dan wawancara hal ini dikarenakan hotel baru berdiri bahkan pada saat sudah menerima tamu pun sistem belum terbangun sehingga mempersulit pengelolaan nya.Observasi dilakukan di beberapa hotel yang berada di sumedang, dengan mengamati bagian Front Office dan bagian Keuangan.Adapaun hasil dari wawancara yang telah dilakukan dapat diketahui kebutuhan informasi dari manajemen dan pemilik hotel : a. Jumlah kamar dan pemesanan kamar harus sudah terdaftar secara jelas setiap tanggalnya b. Jumlah pendapatan dari penjualan jasa kamar c. Jumlah beban yang dikeluarkan baikm untuk operasional pegawai dan hotel juga untuk konsumsi tamu d. Laporan keuangan hotel e. Penyajian penerimaan dan pengeluaran kas f. Penyetoran dan penarikan ke rekening bank pemilik hotel. Berdasarakan hasil wawancara tersebut maka dibuatlah penelitian supaya kebutuhan
Terkait dengan berbagai masalah dan pemanfaatan informasi di sebuah hotel maka penelitian ini merumuskan masalah yang akan di bahas, yaitu : a. Bagaimana melakukan analysis and design sistem informasi laporan keuangan dengan pendekatan Rapid Application Development. b. Bagaimana melakukan design yang sesuai dengan keinginan user agar dapat di implementasikan menggunakan salah satu bahasa Pemograman dan database nya. Suatu penelitian sudah tentu harus mempunyai tujuan dan manfaat penelitian, untuk itu disini akan dijelaskan mengenai tujuan dan manfaat penelitian ini. Tujuan yang ingin dicapai dari penelitian ini adalah : a. Tersedianya design sistem informasi untuk implementasikan dengan sebuah bahasa pemograman. 11
informasi dari manajemen dan pemilik hotel dapat terpenuhi.
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan. Metode yang digunakan dalam analisis dan perancangan pada prototype adalah metode Rapid Apllication Development Metode ini membagi proses pembangunan perangkat lunak kedalam fase-fase individu atau langkah-langkah. Fase atau langkah yang satu dengan yang lainnya terpisah secara kronologis dan fungsional. Adapun Fase-fase yang akan di design di sistem informasi Laporan Keuangan LaDiva Hotel adalah: 1. Laporan Rugi/Laba 2. Arus Kas 3. Neraca 4. Perubahan Modal Selain itu juga disediakan informasi berupa buku kas harian dan rekapnya, berikut adalah tahapan yang digunakan untuk membangun sistem informasi laporan keuangan LaDiva Hotel
2.2.
Bisnis Modelling Aliran informasi di antara fungsi – fungsi bisnis, dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan sebagai berikut : a. Informasi apa yang mengendalikan proses bisnis? 1. Informasi pendapatan dari hotel yang meliputi: jumlah pendapatan jasa kamar, laundry,restoran 2. Informasi jumlah beban dan pengeluaran kas baik untuk setiap jenis beban ataupun pengeluaran kas untuk pembayaran hutang. b. Informasi apa yang di munculkan? 1. Jumlah Pendapatan jasa kamar, restoran, dan laundry dari setiap kamar yang disewa 2. Jumlah kas yang keluar baik per jenis beban ataupun pembayaran cicilan pokok hutang per periode tertentu 3. Jumlah Penyusutan Aktiva Tetap yang ada di hotel yaitu : peralatan dan kelengkapan hotel, bangunan, dan kendaraan operasional. c. Siapa yang memunculkanya? 1. Yang Memunculkan dan memproses seluruh transaksi keuangan adalah Bagian Keuangan d. Ke mana informasi itu pergi? 1. Informasi yang tersedia sebagian besar untuk pimpinan dan memilik hotel agar bisa mengambil kebijakan dalam pengembangan hotel kedepannya. 2. Ke semua bagian yang ada di hotel untuk mengetahui apa yang harus di jadikan perencanaan untuk pelayanan tamu hotel. e. Siapa yang memprosesnya? 1. Yang memproses pendapatan dari masing-masing bagian (Front Office Untuk Jasa Kamar, Laundry, dan Restoran) semua masuk ke bagian keuangan. 2. Untuk beban atau pengeluaran kas lainnya di ajukan oleh setiap bagian ke bagian keuangan untuk di ketahui dan di setujui oleh Manager Hotel. 2.3.
3. PERANCANGAN 3.1. Perancangan Penelitian Perancangan penelitian yang dilaksanakan meliputi sebagai berikut: a. Analisis kebutuhan pemakai Dalam tahapan ini disiapkan berbagai kebutuhan informasi yang diinginkan oleh pemakai dari berbagai segi, baik entry data dan penyajian informasi yang berupa laporan. b. Perancangan Dalam tahapan perancangan disiap perancangan antarmuka. Algoritma,dan perangkat lunak nya yang memudahkan pemakai menggunakan aplikasi yang dibangun. Desain sistem dalam perancangan Rapid Appplication Development sistem informasi Keuangan Hotel ini menggunakan UML (Unified Modeling Language) yaitu suatu metode modeling generasi ketiga dan bahasa spesifikasi yang sifatnya nonproprietary. Sebenarnya penggunaan dari UML itu sendiri tidak terbatas hanya pada dunia software modeling, tetapi bisa pula
Data modeling 12
digunakan untuk modeling hardware (engineering systems) dan sering digunakan sebagai modeling untuk proses bisnis dan juga modeling untuk struktur organisasi. Perancangan sistem Informasi Laporan Keuangan Hotel hanya menggunakan beberapa jenis standar diagram UML saja karena dianggap sudah mencukupi untuk menyelesaikan kasus ini: a. Use case diagram b. Class Diagram c. Sequence diagram d. Activity diagram e. 3.2.Use case diagram Setelah selesai pada tahap analisa kebutuhan sistem, dan keinginan user sudah dipahami dengan benar, maka tahap berikutnya adalah menterjemahkan Rapid Appplication Development sistem informasi Keuangan Hotel ke dalam bentuk use case diagram untuk menjelaskan gambaran sistem dan aktor yang terlibat secara keseluruhan. Berbeda dengan class diagram yang lebih cocok dibaca oleh disainer/analis, use case diagram sangat cocok untuk dipahami oleh pemesan/pengguna sistem. Selain itu use case diagram hanya menggambarkan dilakukan oleh sistem dan tidak menggambarkan bagaimana sistem melakukannya.
13
Gambar 3.1 Use Case Sistem Informasi Keuangan Hotel
14
3.3.Class Diagram Setelah kita membuat usecase diagram, langkah selanjutnya adalah membuat Class Diagram berdasarkan usecase diagram tersebut. Class diagram ini harus berisikan objek-objek yang terdapat di dalam sistem informasi Keuangan Hotel ini. Berdasarkan pada kasus tersebut, fokus utama pada kasus ini adalah mendata penerimaan dan pengeluaran biaya-biaya hotel setiap harinya. Berikut adalah diagramnya.
15
Gambar 3.2 Class Diagram Sistem Informasi Keuangan Hotel
16
3.4.Sequence Diagram Sequence diagram menjelaskan interaksi antar obyek yang disusun dalam suatu urutan waktu yaitu urutan kejadian yang dilakukan oleh seorang actor dalam menjalankan sistem. Diagram ini secara khusus berasosiasi dengan use case. Berikut adalah rancangan sequence diagram yang dipetakan dari obyek-obyek yang ada pada class diagram sebelumnya. a. Sequence Diagram Login Sequence diagram ini menjelaskan urutan proses user untuk melakukan login sehingga apabila user tersebut memasukan data dengan benar maka nantinya user tersebut dapat menggunakan fasilitas dalam sistem, sedangkan apabila user tidak memasukan data dengan benar maka akan adanya peringatan.
17
Gambar 3.3 Sequence Diagram Login
18
b. Sequence Diagram Akses Petugas Sequence diagram ini menjelaskan urutan proses pengisian akses petugas yang akan menjadi user seperti tambah data, simpan data, ubah data, dan hapus data akses petugas.
19
Gambar 3.4 Sequence Diagram Akses Petugas
20
c. Sequence Diagram Penerimaan Harian Sequence diagram ini menjelaskan urutan proses pengisian penerimaan harian dimana setiap pendapatan hotel setiap harinya akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data penerimaan harian.
21
Gambar 3.5 Sequence Diagram Penerimaan Harian
22
d. Sequence Diagram Pengeluaran Harian Sequence diagram ini menjelaskan urutan proses pengisian pengeluaran harian dimana setiap pengeluaran hotel yang meliputi biaya-biaya(beban), pembayaran cicilan hutang, dan pengeluaran lainnya setiap harinya akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data pengeluaran harian.
23
Gambar 3.6 Sequence Diagram Pengeluaran Harian
24
e. Sequence Diagram Buku Kas Harian Sequence diagram ini menjelaskan urutan proses buku kas harian dimana setiap pendapatan hotel dan pengeluaran hotel akan dibandingkan setiap harinya apakah laba atau rugi lalu dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data buku kas harian.
25
Gambar 3.7 Sequence Diagram Buku Kas Harian
26
f. Sequence Diagram Input Aktiva Tetap Sequence diagram ini menjelaskan urutan proses input aktiva tetap dimana setiap aktiva baik itu berupa tanah, bangunan, kendaraan, dan inventaris hotel lainnya akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data aktiva tetap.
27
Gambar 3.8 Sequence Diagram Input Aktiva Tetap
28
h. Sequence Diagram Input Hutang Sequence diagram ini menjelaskan urutan proses input hutang dimana setiap hutang akan dimasukan ke dalam sistem dengan melakukan tambah data, simpan data, ubah data, dan hapus data hutang.
29
Gambar 3.9 Sequence Diagram Input Hutang
30
i. Sequence Diagram Input Beban Sequence diagram ini menjelaskan urutan proses input beban dimana setiap beban berdasarkan post bebannya masing-masing akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data beban.
31
Gambar 3.10 Sequence Diagram Input Beban
32
k. Sequence Diagram Penyusutan Aktiva Tetap Sequence diagram ini menjelaskan urutan proses penyusutan aktiva tetap dimana setiap aktiva setiap tahunnya akan disusutkan berdasarkan nilai ekomonisnya.
33
Gambar 3.11 Sequence Diagram Penyusutan Aktiva Tetap
34
l. Sequence Diagram Transaksi Pembayaran Hutang Sequence diagram ini menjelaskan urutan proses transaksi pembayaran hutang dimana setiap melakukan cicilan pembayaran hutang dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data cicilan hutang..
35
Gambar 3.12 Sequence Diagram Transaksi Pembayaran Hutang
36
n. Sequence Diagram Transaksi Cash Flow Sequence diagram ini menjelaskan urutan proses cash flow (arus kas) dimana setiap adanya penambahan modal, pembayaran hutang, dan yang mempengaruhi kas akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data cash flow.
37
Gambar 3.13 Sequence Diagram Transaksi Cash Flow
38
o. Sequence Diagram Penyimpanan Ke Bank Sequence diagram ini menjelaskan urutan proses penyimpanan ke bank dimana setiap pendapatan hotel yang disimpan di Bank akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data penyimpanan ke bank.
39
Gambar 3.14 Sequence Diagram Penyimpanan Ke Bank
40
q. Sequence Diagram Pengambilan Dari Bank Sequence diagram ini menjelaskan urutan proses pengambilan dari bank dimana setiap adanya pengambilan dari Bank akan dimasukan ke dalam sistem seperti tambah data, simpan data, ubah data, dan hapus data pengambilan dari bank.
41
Gambar 3.15 Sequence Diagram Pengambilan dari Bank
42
r. Sequence Diagram Pembuatan Laporan Sequence diagram ini menjelaskan urutan proses pembuatan laporan dimana setiap laporan akan dicetak dan diserahkan kepada manager
43
Gambar 3.16 Sequence Diagram Pembuatan Laporan
44
3.6.Activity Diagram Pada bagian ini dijelaskan mengenai urutan proses sistem yang akan dibuat melalui activity diagram, diagram ini muncul karena diagram use case tidak mampu menjelaskan bagaimana sistem melakukan proses. Diagram use case hanya mampu menjelaskan apa yang dilakukan sistem. Sedangkan class diagram hanya menjelaskan hubungan antar siapa dengan siapa (class to class) dan bagaimana hubungan itu, walaupun di dalam diagram kelas ada operation, tetapi tidak mendeskripsikan bagaimana langkah proses itu dilakukan. a. Activity Diagram Login Diagram ini menjelaskan urutan proses login petugas untuk masuk ke dalam sistem. Berikut activity diagramnya.
45
Gambar 3.17 Activity Diagram Login
46
b.
Activity Diagram Akses Petugas Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data akses petugas pada sistem. Berikut activity diagramnya.
47
Gambar 3.18 Activity Diagram Akses Petugas
48
c. Activity Diagram Penerimaan Harian Diagram ini menjelaskan urutan proses penginputan, link jumlah dari tabel pemesanan kamar yang berada pada sistem informasi pemesanan kamar, simpan data, ubah data, dan hapus data penerimaan harian. Berikut activity diagramnya.
49
Gambar 3.19 Activity Diagram Penerimaan Harian
50
d. Activity Diagram Pengeluaran Harian Diagram ini menjelaskan urutan proses penginputan, simpan data dan selanjutnya diinputkan kembali berdasarkan kategori pengeluaran, ubah data, dan hapus data pengeluaran harian. Berikut activity diagramnya.
51
Gambar 3.20 Activity Diagram Pengeluran Harian
52
e. Activity Diagram Buku Kas Harian Diagram ini menjelaskan urutan proses penginputan, link antar tabel, simpan data, ubah data, dan hapus data buku kas harian. Berikut activity diagramnya.
53
Gambar 3.21 Activity Diagram Buku Kas Harian
54
f. Activity Diagram Input Aktiva Tetap Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data aktiva tetap. Berikut activity diagramnya.
55
Gambar 3.22 Activity Diagram Input Aktiva Tetap
56
g. Activity Diagram Input Hutang Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data hutang. Berikut activity diagramnya.
57
Gambar 3.23 Activity Diagram Hutang
58
h. Activity Diagram Input Beban Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data beban. Berikut activity diagramnya.
59
Gambar 3.24 Activity Diagram Beban
60
i. Activity Diagram Penyusutan Aktiva Tetap Diagram ini menjelaskan urutan proses penginputan, mengambil data dari tabel aktiva tetap, simpan data, dan hapus data penyusutan aktiva tetap. Berikut activity diagramnya.
61
Gambar 3.25 Activity Diagram Penyusutan Aktiva Tetap
62
j. Activity Diagram Transaksi Pembayaran Hutang Diagram ini menjelaskan urutan proses penginputan, mengambil data dati tabel hutang dan mengupdate jumlah hutang, simpan data, dan hapus data pembayaran hutang. Berikut activity diagramnya.
63
Gambar 3.26 Activity Diagram Transaksi Pembayaran Hutang
64
k. Activity Diagram Transaksi Cash Flow Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data cash flow. Berikut activity diagramnya.
65
Gambar 3.27 Activity Diagram Cash Flow
66
l. Activity Diagram Penyimpanan Ke Bank Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data penyimpanan ke bank. Berikut activity diagramnya.
67
Gambar 3.28 Activity Diagram Penyimpanan Ke Bank
68
m. Activity Diagram Pengambilan Dari Bank Diagram ini menjelaskan urutan proses penginputan, simpan data, ubah data, dan hapus data pengambilan dari bank. Berikut activity diagramnya.
69
Gambar 3.29 Activity Diagram Pengambilan Dari Bank
70
n. Activity Diagram Pembuatan Laporan Diagram ini menjelaskan urutan proses cetak laporan. Berikut activity diagramnya.
71
Gambar 3.30 Activity Diagram Pembuatan Laporan
72
3.8.Database Design Pada bagian ini dijelaskan mengenai perancangan fisik tabel-tabel yang diperlukan untuk perancangan sistem yang semuanya dikumpulkan dalam satu database. Desain database fisiknya adalah seperti tampak pada gambar 3.5, dan diagram tersebut digambar menggunakan bantuan perangkat lunak Ms Acces.
73
Gambar 3.31 Entity Relationship Diagram Sistem Keseluruhan
74
3.9.Struktur Database Proses selanjutnya setelah perancangan Entity Relationship Diagram yang dibuat, adalah merancang struktur database untuk Sistem Keuangan La Diva Hotel yang digunakan. Tujuannya adalah untuk mempermudah dan menjaga kosistensi perangkat lunak yang akan dibuat. Adapun tabel-tabel yang digunakan adalah sebagai berikut:
75
a. Tabel Akses Petugas Nama Tabel Primary Key Foreign Key Struktur Tabel
: Tbl_Akses_Petugas : UserID ::
Tabel 3.1 Struktur Tabel Akses Petugas
Hal 76
b. Tabel Penerimaan Harian Nama Tabel : Tbl_Penerimaan_Harian Primary Key : No_Penerimaan Foreign Key :Struktur Tabel :
Tabel 3.2 Struktur Tabel Penerimaan Harian c. Tabel Pengeluaran Harian Nama Tabel : Tbl_Pengeluaran_Harian Primary Key : No_Pengeluaran Foreign Key :Struktur Tabel :
Tabel 3.3 Tabel Pengeluaran Harian d. Tabel Buku Kas Harian Nama Tabel : Tbl_Buku_Kas_Harian Primary Key :Foreign Key : No_Penerimaan dan No_Pengeluaran Struktur Tabel :
Tabel 3.4 Struktur Tabel Buku Kas Harian
Hal 77
e. Tabel Aktiva Tetap Nama Tabel Primary Key Foreign Key Struktur Tabel
: Tbl_Aktiva_Tetap : Kode_Aktiva ::
Tabel 3.5 Struktur Tabel Aktiva Tetap f. Tabel Hutang Nama Tabel Primary Key Foreign Key Struktur Tabel
: Tbl_Hutang : Kode_Kreditur ::
Tabel 3.6 Struktur Tabel Hutang g. Tabel Biaya Nama Tabel Primary Key Foreign Key Struktur Tabel
: Tbl_Biaya : No_Biaya ::
Tabel 3.7 Struktur Tabel Biaya
Hal 78
h. Tabel Penyusutan Aktiva Tetap Nama Tabel : Tbl_Penyusutan_Aktiva_Tetap Primary Key :Foreign Key : Kode_Aktiva Struktur Tabel :
Tabel 3.8 Struktur Tabel Penyusutan Aktiva Tetap i. Tabel Penyimpanan Ke Bank Nama Tabel : Tbl_Penyimpanan_Ke_Bank Primary Key : No_Penyimpanan Foreign Key :Struktur Tabel :
Tabel 3.9 Struktur Tabel Penyimpanan Ke Bank j. Tabel Pengambilan Dari Bank Nama Tabel : Tbl_Pengambilan_Dari_Bank Primary Key : No_Pengambilan Foreign Key :Struktur Tabel :
Tabel 3.10 Struktur Tabel Pengambilan Dari Bank
Hal 79
k. Tabel Pembayaran Hutang Nama Tabel : Tbl_Pembayaran_Hutang Primary Key : Kode_Bayar Foreign Key : Kode_Kreditur Struktur Tabel :
Tabel 3.11 Struktur Tabel Pembayaran Hutang l. Tabel Cash Flow Nama Tabel Primary Key Foreign Key Struktur Tabel
: Tbl_Cash_Flow : No_CF ::
Tabel 3.12 Struktur Tabel Cash Flow 4. PEMBAHASAN 4.1 Hirarki Perancangan Sistem Gambaran hirarki perancangan sistem informasi la diva hotel dimulai dengan adanya login, kemudian setelah login akan muncul menu utama aplikasi. Dalam menu utama aplikasi terdiri dari beberapa menu yaitu Master Data, Transaksi, Laporan, Bantuan, dan Keluar. Dari menu-menu itu terdapat sub-menunya masing-masing. Menu Master Data mempunyai sub-menu diantaranya Penerimaan Harian, Pengeluaran Harian, Buku Kas Harian, Beban-beban (Penyusutan Aktiva Tetap dan Beban Lainnya), Daftar Hutang, Daftar Aktiva Tetap, dan Akses Petugas. Menu Transaksi mempunyai sub-menu diantaranya Pembayaran Hutang, Cash Flow, dan Bank (Penyimpanan Ke Bank dan Pengeluaran Dari Bank). Menu Laporan mempunyai sub-menu diantaranya Penerimaan Harian, Pengeluaran Harian, Buku Kas Harian, Rekap Harian, Beban Akum Penyusutan, Beban Keseluruhan, Daftar Aktiva Tetap, Daftar Hutang, Pembayaran Hutang, Penyimpanan Ke Bank, Pengeluaran Dari Bank, Rugi Laba, Cash Flow, dan Neraca. Sedangkan menu Bantuan mempunyai sub-menu diantaranya Bantuan dan Pemandu Aplikasi. Untuk menu Keluar tidak mempunyai submenu.
Hal 80
Gambar 4.1 Hirarki Perancangan Sistem Informasi Keuangan La Diva Hotel 4.2 Perancangan User Interface Sebagai gambaran desain sistem informasi keuangan hotel adalah seperti tampak pada gambar berikut. Layout sistem seperti halnya aplikasi yang lainnya, dimana bagian atas merupakan pilihan menu yang bisa diguankan pemakai, bagian tengah merupakan MDI form, dan bagian bawah merupkan tempat identitas petugas yang menggunakan sistem. Panjang dan lebar ukuran form telah disesuaikan dengan setiap ukutan screen. 4.2.1 Menu Utama
Bagian Atas
Bagian Tengah
Bagian Bawah
Gambar 4.2 Layout Menu Utama SI Keuangan Hotel
Hal 81
4.2.2 Input Design a. Form Login Form login digunakan agar user dapat masuk ke dalam sistem, form login ini bisa digunakan oleh Staf Front Office, Staf Akuntansi, Kabag Keuangan, dan Manager. Berikut adalah tampilan desainnya.
Gambar 4.3 Desain Input Form Login b. Form Akses Petugas Form Akses Petugas digunakan untuk memasukan data berupa userid, password, nama, dan jabatan untuk setiap user yang nantinya akan diperuntukkan untuk masuk ke dalam sistem. Berikut adalah tampilan desainnya.
Gambar 4.4 Desain Input Form Akses Petugas
Hal 82
c. Form Penerimaan Harian Form Penerimaan Harian digunakan untuk memasukan setiap penerimaan/pendapatan harian baik dari pendapatan tamu hotel atau dari pendapatan lainnya. Berikut adalah tampilan desainnya.
Gambar 4.5 Desain Input Form Penerimaan Harian d. Form Pengeluaran Harian Form Pengeluaran Harian digunakan untuk memasukan setiap pengeluaran harian hotel baik dari pengeluaran untuk tamu hotel, ataupun biaya-biaya lainnya. Berikut adalah tampilan desainnya. Tanggapan pengguna untuk form ini adalah menu penerimaan dan pengeluran kas sudah cukup untuk di aplikasi di bahasa pemograman
Gambar 4.6 Desain Input Form Input Pengeluran Harian Hal 83
e. Form Buku Kas Harian Form Buku Kas Harian digunakan untuk memasukan rekapitulasi jumlah penerimaan dan pengeluaran harian hotel. Berikut adalah tampilan desainnya.
Gambar 4.7 Desain Input Buku Kas Harian
Hal 84
f. Form Aktiva Tetap Form Aktiva Tetap digunakan untuk memasukan semua aktiva tetap yaitu tanah, bangunan, dan inventaris hotel ke dalam sistem. Berikut adalah tampilan desainnya.
Gambar 4.8 Desain Input Daftar Aktiva Tetap g. Form Hutang Form Hutang digunakan untuk memasukan hutang. Berikut adalah tampilan desainnya.
Gambar 4.9 Desain Input Form Hutang
Hal 85
h. Form Input Biaya/Beban Form Input Biaya digunakan untuk memasukan setiap biaya-biaya berdasarkan kategori biayanya masing-masing. Berikut adalah tampilan desainnya.
Gambar 4.10 Desain Input Form Input Beban i. Form Penyusutan Aktiva Tetap Form Penyusutan Aktiva Tetap digunakan untuk melakukan penyusutan aktiva tetap setiap tahunnya berdasarkan tahun ekomonisnya, dengan hanya memasukan data aktiva tetap akan secara otomatis melakukan perhitungan untuk mendapatkan jumlah penyusutan, akumulasi penyusutan, dan nilai sekarangnya. Tanggapan user untuk input data aktiva tetap sudah mencerminkan nilai sekarang dan akumulasi penyusutan secara pertahun. Harapan user selanjutnya bisa dikembangkan agar penyusutan dapat dibuat perbulan sampai perhari. Berikut adalah tampilan desainnya.
Gambar 4.11 Desain Input Form Penyusutan Aktiva Tetap Hal 86
j. Form Pembayaran Hutang Form Pembayaran Hutang digunakan untuk melakukan setiap cicilan pembayaran hutang dan secara otomatis akan mengurangi jumlah hutang sebelumnya. Berikut adalah tampilan desainnya.
Gambar 4.12 Desain Input Form Pembayaran Hutang k. Form Cash Flow Form Cash Flow digunakan untuk melakukan setiap transaksi yang berhubungan dengan kas, diantaranya adanya penambahan modal, membayar cicilan hutang, dan transaksi lainnya. Berikut adalah tampilan desainnya.
Gambar 4.13 Desain Input Form Cash Flow l. Form Penyimpanan Ke Bank Form Penyimpanan Ke Bank digunakan untuk melakukan pencatatan penyimpanan pendapatan ke bank. Berikut adalah tampilan desainnya. Hal 87
Gambar 4.14 Desain Input Form Penyimpan Ke Bank
m. Form Pengambilan Dari Bank Form Pengambilan Dari Bank digunakan untuk melakukan pencatatan pengambilan uang dari bank. Tanggapan user untuk input dan pengambilan kas dari bank sudah cukup informatif. Berikut adalah tampilan desainnya.
Gambar 4.15 Desain Input Form Pengambilan Dari Bank 4.2.3 Output Design a. Laporan Penerimaan Harian Laporan penerimaan harian merupakan output dari hasil penginputan penerimaan harian dengan adanya laporan ini bisa melihat pendapatan setiap harinya tapi belum dikurangi biaya pengeluaran. Berikut adalah tampilan desainnya.
Hal 88
Gambar 4.16 Desain Output Laporan Penerimaan Harian
Hal 89
b. Laporan Pengeluaran Harian Laporan pengeluaran harian merupakan output dari hasil penginputan pengeluaran harian, laporan ini memberikan informasi tentang pengeluaran setiap harinya. Berikut adalah tampilan desainnya.
Gambar 4.17 Desain Output Laporan Pengeluaran Harian c. Rekap Penerimaan dan Pengeluaran Harian Rekap penerimaan dan pengeluaran harian merupakan output dari hasil rekapitulasi jumlah penerimaan dan pengeluaran harian, laporan ini akan menjadi slip untuk penyetoran ke bank. Tanggapan pengguna untuk output laporan dan penerimaan serta rekap nya sudah dapat memenuhi kebutuhan pengguna. Berikut adalah tampilan desainnya.
Gambar 4.18 Desain Output Laporan Rekap Harian
Hal 90
d. Laporan Buku Kas Harian Laporan buku kas harian merupakan output rincian dari pendapatan dan pengeluaran keseluruhan. Berikut adalah tampilan desainnya.
Gambar 4.19 Desain Output Laporan Buku Kas Harian e. Laporan Daftar Aktiva Tetap Laporan daftar aktiva tetap merupakan output dari hasil penginputan aktiva tetap, laporan ini memberikan informasi tentang seluruh data aktiva tetap hotel. Tanggapan user untuk output daftar aktiva tetap sudah cukup menggambarkan tentang aktiva tetap hotel saat ini. Berikut adalah tampilan desainnya.
Gambar 4.20 Desain Output Laporan Daftar Aktiva Tetap
Hal 91
f. Laporan Daftar Hutang Laporan daftar hutang merupakan output dari hasil penginputan hutang. Berikut adalah tampilan desainnya.
Gambar 4.21 Desain Output Laporan Daftar Hutang g. Laporan Biaya Keseluruhan Laporan biaya keseluruhan merupakan output dari hasil penginputan biaya-biaya, laporan ini memberikan informasi tentang seluruh biaya-biaya berdasarkan kategori biayanya masing-masing. Berikut adalah tampilan desainnya.
Gambar 4.22 Desain Output Laporan Biaya-biaya
Hal 92
h. Laporan Penyusuran Aktiva Tetap Laporan penyusutan aktiva tetap merupakan output dari proses penyusutan aktiva tetap. Berikut adalah tampilan desainnya.
Gambar 4.23 Desain Output Laporan Penysutan Aktiva Tetap i. Laporan Pembayaran Hutang Laporan pembayaran hutang merupakan output dari transaksi pembayaran hutang, laporan ini memberikan informasi tentang seluruh pembayaran hutang. Berikut adalah tampilan desainnya.
Gambar 4.24 Desain Output Laporan Pembayaran Hutang
Hal 93
j. Laporan Penyimpanan Ke Bank Laporan penyimpanan ke bank merupakan output dari pencatatan penyimpanan uang ke bank, laporan ini juga bisa disamakan dengan laporan jumlah uang di bank. Berikut adalah tampilan desainnya.
Gambar 4.25 Desain Output Laporan Penyimpanan Ke Bank k. Lapoaran Pengambilan Dari Bank Laporan pengambilan dari bank merupakan output dari pencatatan pengambilan uang dari bank. Berikut adalah tampilan desainnya.
Gambar 4.26 Desain Output Laporan Pengambilan Dari Hotel
Hal 94
l. Laporan Cash Flow Laporan cash flow merupakan output dari transaksi yang berhubungan dengan kas, yang nantinya total kas pada laporan cash flow ini akan mengisi jumlah kas di neraca. Berikut adalah tampilan desainnya.
Gambar 4.27 Desain Output Laporan Cash Flow m. Laporan Rugi Laba Laporan rugi laba merupakan output dari gabungan beberapa transaksi diantaranya transaksi pemesanan kamar di aplikasi pemesanan kamar dan input beban di aplikasi keuangan. Laporan ini menggambarkan rugi atau labanya hotel. Berikut adalah tampilan desainnya.
Gambar 4.28 Desain Output Laporan Rugi Laba n. Laporan Neraca Laporan neraca merupakan output dari gabungan beberapa transaksi di aplikasi keuangan Hal 95
diantaranya transaksi cash flow, transaksi penyimpanan dan pengambilan dari bank, penyusutan aktiva tetap, dan hutang. Laporan ini ada dua bagian yaitu aktiva dan passiva keduanya harus ”balance”. Berikut adalah tampilan desainnya.
Gambar 4.29 Desain Output Laporan Neraca Tanggapan pengguna untuk output laporan keuangan yang berisi : laporan rugi laba, arus kas,dan neraca sudah cukup untuk diaplikasikan dalam salah satu bahasa pemograman. 5. KESIMPULAN DAN SARAN 5.1 Kesimpulan Kesimpulan dari penerapan Sistem Informasi Laporan Keuangan di Hotel sebagai berikut : a. Hasil analisis Sistem informasi laporan keuangan hotel yang sedang berjalan saat ini dapat dijadikan bahan untuk membuat rancangan sistem informasi yang baru. b. Rancangan sistem informasi Sistem Informasi Laporan Keuangan ini dapat digunakan sebagai dasar untuk implementasi dan penerapannya di Ladiva Hotel c. Perancangan dari sistem informasi laporan keuangan ini manggunakan Pendekatan Rapid Application Development di mana setiap tahap penyelesaiannya di tanggapi oleh user dan pemodelan UML (Unified Modeling Language) dan untuk rancangan Interfacenya menggunakan Visual Basic.
Hal 96
5.2 Saran Ada beberapa hal yang dapat kami sarankan untuk menjadi bahan pertimbangan bagi peneliti yang akan datang, sebagai berikut : a. Dari hasil rancangan Sistem informasi laporan keuangan di ladiva hotel untuk dapat di implementasikan dengan sebuah bahasa pemograman visual basic 6.0 dengan database sql server 2000 b. Dan untuk penegembangan selanjutnya maka diharapkan dapat menerapkan sistem rancangan jaringan komputer dengan menggunakan topologi client server agar memudahkan pengentrian data dan penyampaian informasi ke setiap bagian.
EFEK POSITIF DAN NEGATIF JEJARING SOSIAL FACEBOOK Oleh : Iyat Ratna Komala, S.T., M.Kom. Dosen Tetap Program Studi Sistem Informasi jenjang S-1
ABSTRAK Facebook merupakan situs jejaring sosial yang saat ini banyak digunakan oleh masyarakat disemua kalangan.Facebook dirilis tepatnya pada 4 februari 2004, oleh Mark Zuckerberg, seorang Mahasiswa Harvard kelahiran 14 Mei 1984 dan mantan murid Ardsley High School. Facebook telah mengajak para penggunanya untuk berinteraksi dan berkomunikasi dengan teman dan kerabat di dunia maya. Jarak dan waktu tidak lagi menjadi sebuah masalah. Karena hanya dengan login ke akun Facebook pengguna dapat berbincang dengan teman, mengirimkan pesan, foto, hingga video. Tidak hanya itu, Facebook juga menyediakan beragam hiburan melalui feature grup dan game. Tujuan dari kajian ini adalah untuk mendapatkan gambaran efek positif dan negatif dari penggunaan situs jejaring sosial yang dinamakan facebook. Sehingga diharapkan dengan adanya paparan kajian ini tidak terjebak efek negatif pada penggunaan situs jejaring sosial tersebut dengan tidak mengesampingkan efek positifnya.
Hal 97