Selasa, 18 September 2012

System Overview

Sistem ini adalah sebuah sistem informasi untuk salah satu perusahaan kontraktor telekomunikasi dengan scope menengah. Kenapa disebut menengah? Karena memang pelayanan tidak menyeluruh, produknya hanya meliputi: jasa pembangunan infra-structure, commisioning dan resource di bidang telekomunikasi. Perusahaan tidak menyediakan material dan pelayanan monitoring setelah site on air.

Aktor

Seperti biasa, dalam pembangunan sistem (sederhana) selalu dibutuhkan aktor dalam 2 jenis: human dan non human. Untuk jenis human biasanya dibutuhkan dua jenis user berikut: Administrator dan End User, mereka adalah user yang berinteraksi langsung dengan sistem nantinya.

Gambar: Aktor yang dibutuhkan

Ada hal yang cukup unik dalam sistem ini, yaitu: kebutuhan untuk mendaftarkan stakeholder sumber daya eksternal. Stakeholder yang berkepentingan nantinya yaitu: External Audit, Staff Bank dan Pemohon. Mereka tidak berinteraksi langsung dengan sistem, tapi dibutuhkan dalam beberapa scenario nantinya. Sebut saja:

External Audit: untuk keperluan scenario dalam pelaporan,
Staff Bank: juga untuk keperluan scenario dalam pelaporan dan terakhir,
Pemohon: berperan sebagai requestor dalam scenario permohonan pengajuan uang keluar.

Demikian ulasan dari kebutuhan aktor yang akan berperan dalam sistem nantinya, baik human maupun non human dan stakeholder.

Penggunaan Sistem

Scenario dari penggunaan sistem ini cukup sederhana, end user cukup melakukan login terlebih dahulu untuk dapat menggunakan sistem. Proses login juga cukup mudah, user hanya tinggal memasukkan user name dan password yang telah diberikan oleh system administrator.

Alternate Flow untuk scenario ini biasanya adalah: pada saat user login, system membaca hak privileges dari user tersebut. Hal ini untuk menentukan apakah user adalah operator biasa atau memang berperan sebagai user tertentu yang memiliki hak istimewa dalam sistem, interface pun dapat dibedakan pada alternate flow ini.

Gambar: pattern penggunaan sistem.

Karena proses penggunaan sistem ini memiliki pattern yang selalu sama, proses ini dapat dibuat class yang nantinya akan selalu digunakan di semua sistem informasi.

Gambar: contoh perancangan formulir login.

Seperti terlihat pada gambar, user tinggal memasukkan user name dan password kemudian klik tombol OK. Alternate flow dapat digunakan setelah user mengklik tombol OK tersebut, baca privileges user kemudian tentukan apakah user dapat mengakses interface tertentu atau tidak.

Demikian overview penggunaan sistem ini.

Privileges pada Sistem

Seperti yang disebutkan pada sesi sebelumnya, bahwa sistem digunakan berdasarkan privileges tertentu untuk masing-masing user. Seperti biasa, untuk hak yang tertinggi diberikan hanya pada administrator. Setelah menentukan siapa administrator dari sistem, baru pengguna yang lain dapat didaftarkan.

Gambar: privileges hanya diberikan pada user yang berinteraksi langsung pada sistem.

Untuk sistem ini supaya dapat mudah menentukan privileges sebaiknya user dikelompokkan menurut tanggung jawab dalam pekerjaan. Dalam sistem ini pengelompokan dibagi menjadi:

Teknik,
Finansial,
General Affair dan,
Personalia.

Untuk user dengan note stake holder tidak perlu dibuat apalagi diberikan privileges, mereka hanya user eksternal sistem yang memiliki kepentingan pada scenario tertentu saja.

Anggota Kelompok

Dari beberapa kelompok di atas, berikut adalah daftar anggotanya. Hal ini diCapture sesuai dengan pembagian kerja di lapangan.

Gambar: anggota kelompok pengguna.

Sebenarnya hanya ada dua departemen yang rencananya akan menggunakan sistem, selebihnya mereka membaginya ke dalam divisi. Seperti terlihat pada gambar, bahwa: divisi teknik merupakan child dari parent bagian umum dan finansial merupakan child dari departemen personalia.

Gambar: kebutuhan mendasar dari sistem.

Dari sekian banyak pengguna, kebutuhan jika dilihat garis besarnya adalah seperti yang terlihat pada gambar. Penuhi kebutuhan di atas terlebih dahulu, baru kemudian kebutuhan akan berkembang dengan sendirinya setelah sistem terbentuk.

Untuk penjelasan global dari kebutuhan kiranya cukup sampai di sini, sekarang kita telah memiliki daftar baik dari user maupun scenario.

Masih di hari Selasa, 18 September 2012 22:42 WIB

Prioritas Pekerjaan

Dari beberapa kebutuhan di atas:

Pengelolaan Keuangan,
Pengelolaan Sumberdaya Manusia,
Pengelolaan Inventory, dan
Pengelolaan Proyek.

Hanya 3 (tiga) modul pekerjaan yang akan kita prioritaskan terlebih dahulu, yaitu:

Pengelolaan Keuangan,
Pengelolaan Proyek (Monitoring), dan terakhir
Pengelolaan Inventory.

Sisanya: Pengelolaan Sumberdaya Manusia direncanakan akan menyusul. Kita akan mencoba mengupas satu per satu modul pekerjaan di atas.

Rabu, 19 September 2012

Pengelolaan Keuangan

Kita akan memulainya dari pengelolaan keuangan, yang dibutuhkan di lapangan juga masih sangat sederhana lingkupnya. Yang penting, dalam menjalankan usahanya; perusahaan mampu merekam riwayat transaksi keuangan mereka.

Gambar: Kebutuhan pengelolaan keuangan di perusahaan ini.

Beberapa aktor di bagian keuangan tidak semua menjalankan operasi rutinitas, sebagian dari mereka hanya berperan dalam otoritas. Hanya kasir yang menjalankan rutinitas entry data transaksi harian. Beberapa scenario yang dibutuhkan juga dikelompokkan dalam paket agar lebih mudah dalam proses perancangannya. Seperti biasa, flow dalam akuntansi: dimulai dari pembuatan daftar akun hingga pelaporan keuangan akan dirancang untuk membantu proses pengelolaan keuangan ini.

Pada siklus akuntansi yang dibutuhkan di sini tidak dimulai dari budgeting, tetapi ada scenario permohonan pengajuan pengeluaran uang yang mengawali kegiatan transaksi keuangan internal. Sisanya: penjurnalan dan pembukuan besar diproses seperti biasa.

Gambar: anggota scenario dari tiap kelompok.

Demikian, kenapa dikelompokkan. Karena memang agar perancangan nantinya dapat lebih terfokus pada proses pengerjaan yang dapat lebih mudah dilaksanakan dibanding mengerjakan secara acak. Silakan memulai dari scenario yang dianggap paling sederhana, tapi disarankan untuk memulainya dari perancangan chart of account, karena chart ini adalah entitas yang paling sering muncul nantinya dalam setiap transaksi keuangan.

Proses pencatatan ke dalam jurnal dibagi menjadi 2 (dua), yaitu: khusus dan umum. Dari beberapa event yang menyebabkan transaksi keuangan perusahaan, ada yang memang memiliki akun tertentu yang memang harus digunakan, dan proses itu akan dikerjakan setiap harinya. Contoh: pembiayaan operasional proyek, event keuangan ini adalah event yang akan mendominasi jurnal. Akun yang digunakan tetap, sebut saja:

Biaya Bahan Bakar,
Biaya Transportasi atau Sewa Transportasi,
Biaya Komunikasi,
Biaya Akomodasi,
Biaya ATP, dan
Biaya Lain-lain.

Untuk itu proses ini akan dibuatkan jurnal khusus, selebihnya jika event transaksi keuangan perusahaan yang menggunakan akun secara acak (random) maka proses pencatatan jurnalnya akan ditangani oleh jurnal umum. Cukup berikan enumerasi pada jurnal, flag unik yang menandakan apakah proses pencatatan ini masuk dalam event khusus atau event umum.

Dalam teori akuntansi, ada kaidah event transaksi apa saja yang masuk ke dalam kategori jurnal umum. Silakan untuk merujuk pada referensi standar tersebut, dan hal ini sangat direkomendasikan.

Permohonan Pengajuan Uang Keluar

Event transaksi yang mengawali event lainnya dalam transaksi keuangan internal perusahaan, mungkin scenario ini yang akan kita angkat terlebih dahulu.

Berikut adalah rekaman proses pengajuan uang keluar yang terjadi di lapangan:

Gambar: overview proses pengajuan uang keluar.

Ada 3 (tiga) main scenario dalam hal ini:

Pada saat uang diajukan,
Pada saat pengajuan diVerifikasi, dan
Pada saat uang dikeluarkan.

Pengeluaran diajukan

Kita akan mengupasnya satu per satu, dimulai dari event pertama: pada saat uang diajukan. Perhatikan ilustrasi pada diagram aktifitas berikut:

Gambar: scenario pada saat pengeluaran diajukan.

Perusahaan menyediakan formulir manual untuk para pelaksana lapangan dalam memenuhi kebutuhan keuangan mereka, formulir inilah yang menjadi dasar masukan dari sistem. Formulir ini akan bergulir ke setiap aktor yang memiliki peran di bagian keuangan untuk memprosesnya.

Gambar: hasil keluaran dari sub system pengajuan uang keluar.

Kurang lebih layout-nya sama dengan hasil keluaran dari sub system ini, hanya saja: untuk mengisi formulir tersebut, para pelaksana lapangan menulis menggunakan alat tulis biasa. Sebut saja: pulpen misalnya. (kayanya ga mungkin pensil deh..)

Proses ini akan direkam oleh aktor yang berperan sebagai petugas keuangan yang menerima pengajuan ini, perhatikan ilustrasi berikut:

Gambar: untuk merekam proses tersebut diperlukan formulir ini.

Formulir inilah yang mencetak hasil keluaran dari sub system seperti contoh di atas, proses pemasukan datanya cukup sederhana: petugas tinggal melengkapi requirement dari field yang dibutuhkan. Sederhana bukan? =)

Break dulu ya sbentar..

Supaya ga bosen:

Trend blogging konon katanya dimulai dari para mahasiswa inggris yang merekam kegiatan perkuliahan mereka di web, catatan mereka supaya ga ilang. Makanya blogging itu sebenarnya dari kata be log disingkat jadi blog, supaya tetep konek ke web di manapun kapanpun.

Terima kasih nih buat para pekerja keras di Microsoft yang udah ngewujudin untuk bisa tetep blogging baik on maupun offLine.

Masih di Hari Rabu, 19 September 2012. Kita lanjutkan pada 08.10 WIB

Pengeluaran diVerifikasi

Data yang diterima kemudian diolah, proses pengolahan adalah verifikasi apakah pengajuan layak untuk dikeluarkan atau justru ditolak. Ada beberapa alternate flows untuk scenario ini, dapat dilihat pada ilustrasi berikut:

Gambar: alternate flows untuk pengajuan uang keluar.

Berikut adalah kemungkinan yang dapat terjadi ketika permohonan pengeluaran diajukan:

Disetujui,
Tidak disetujui,
Dikeluarkan,
Ditolak, dan terakhir
Dibatalkan.

Based on those alternates oleh karena itu digeneralisasikan menjadi assignment pengajuan, bentuknya adalah child form yang dibuka ketika aktor yang berperan sebagai pemberi otoritas mengklik tombol assign pada formulir pengajuan. Perhatikan ilustrasi berikut:

Gambar: assignment dibuat untuk memenuhi alternate flows.

Seperti yang diceritakan pada sesi sebelumnya, aktor yang berperan sebagai pemberi otoritas tidak melakukan kegiatan rutinitas setiap hari, mereka hanya berperan pada scenario tertentu. Contoh untuk alternate scenario ini:

Prepared: diperankan oleh Bagian Operasional,
Approved: diperankan oleh Kepala Operasional,
Checked: diperankan oleh Manajer Keuangan,
Verified: diperankan oleh Kepala Keuangan, dan terakhir
Paid: dimainkan perannya oleh kasir yang mengeluarkan uang.

Uang dikeluarkan

Dan akhirnya, yang menutup scenario dari permohonan pengajuan uang keluar ini adalah: pada saat uang dikeluarkan oleh kasir kepada yang membutuhkan. Ada baiknya pada rancangan keluaran dapat diberikan stamp pada printout-nya.

Gambar: alternate flows pada saat uang dikeluarkan.

Sebenarnya alternate flows itu memberikan flag pada pengajuan, tujuannya agar diketahui status dari pengajuan tersebut. Sudah sampai pada proses mana, diperiksa, diverifikasi, disetujui atau bahkan ditolak. Prosesnya sederhana, cukup buat satu field pada table dan berikan nilai emunerasi seperti yang disebutkan. Jangan lupa untuk menampilkan TimeStamp dan CurrentUser yang menTrigger alternate tersebut.

Demikian untuk scenario dari pengajuan uang keluar ini, kita akan lanjutkan dengan scenario yang lain dalam kebutuhan bagian keuangan. Daftar Akun..

Chart of Account

Gambar: pengelolaan Chart of Account.

Yang dibutuhkan sampai dengan akun yang akan dipakai pada transaksi adalah 4 (empat) parent, di antaranya adalah:

Kelompok,
Golongan,
Jenis,
Tipe, dan terahir adalah
Daftar Akun itu sendiri.

Ada baiknya untuk memanipulasi kebutuhan ke 3 (tiga) parent sebelumnya diInclude-kan Privileges Administrator, sebab: dikhawatirkan dapat mengganggu perancangan sistem yang ada. Untuk keperluan ini, daftar table akun yang diperoleh dari client harus benar-benar disepakati, agar perubahan pada daftar akun dapat diminimalisir.

Gambar: karena scenario kebutuhan sudah jelas, maka entitas pun dapat dibentuk.

Entitas dan pengelolaan tersebut ditempatkan pada Menu Paket Data Master untuk Sub Menu Akuntansi, dan jangan lupa untuk mempertimbangkan hal berikut:

Gambar: Family RelationShip pada Chart of Account..

Jadi, untuk menghasilkan Daftar Akun: hubungan keluarga sebelumnya harus dideskripsikan terlebih dahulu. Dulu, sebenarnya perancangan tidak demikian, namun karena request dari client; maka relasi dibuat seperti ini. Dulu relasi dibangun dengan prinsip fungsi dari akun itu sendiri. Perhatikan ilustrasi berikut:

Perancangan Akun sebelumnya

Jika mengikuti pola perancangan objek menurut UML, jika suatu objek memiliki behavior yang sama, maka diGeneralisaikan. Karena identitas seperti flag dapat membedakan 1 (Satu) entitas dengan lainnya, lebih sederhana namun tetap ada kekurangannya: pada perancangan pelaporan aga susah membuat tampilan relasi dengan format seperti keturunan keluarga.

Gambar: Chart of Account memiliki beberapa flag enumerasi.

Perancangan ini sebenarnya lebih flexible, cukup berikan beberapa flag berikut:

Tingkat: identifikasi level dari akun,
hasTransaction: apakah akun memiliki transaksi? Jika Ya, maka ini adalah child terakhir,
isDebet: identifikasi saldo normal pada akun,
isKredit: identifikasi jika saldo normal bukan debet,
isReal: flag untuk menandakan akun digunakan dalam pelaporan neraca,
isNominal: untuk menandakan bahwa akun digunakan dalam pelaporan Laba-Rugi.

Beberapa flag di atas masih tetap digunakan, hanya saja untuk flag Tingkat mungkin sudah tidak digunakan lagi karena relasi dibentuk dengan Family RelationShip seperti yang dijelaskan pada sesi sebelumnya.

Gambar: masih dipakai beberapa flag berikut pada akun.

Revisi pada hubungan keluarga akun ini tidak terlalu mengubah keseluruhan perancangan, yang ada justru penambahan anggota keluarga 4 (empat) orang tua sebelumnya. Masih dapat digunakan flag lainnya untuk keturunan akun terakhir nanti: Saldo Normal (is it debet or kredit), Fungsi pada pelaporan (is Real or Nominal).

Kekurangan dari konsep ini pada pelaporan

Gambar: kekurangan pada konsep ini dalam layout pelaporannya.

Memang kekurangan pada konsep ini adalah: untuk perancangan seperti pada umumnya, yaitu membentuk hubungan keluarga agak sulit. Tetap, setiap konsep memiliki konsekuensinya masing-masing.

Masih dalam kumpulan scenario keuangan, kita akan lanjutkan lagi.

Penjurnalan

Kita akan lanjutkan setelah ini mengenai perekaman transaksi keuangan ke jurnal, so.. don’t go anywhere!

Sekarang udah Hari Kamis, 20 September 2012 Jam 02:15 WIB

Coffee Break:

Kita lanjutkan lagi ya? Kalo mo bikin kopi dulu ya silakan..

Hubungan Back Street itu..

Hm.. seperti yang pernah dibicarakan sebelumnya, bahwa proses pencatatan ke jurnal dibagi menjadi 2 (dua) jenis; yaitu: umum dan khusus. Sesuai dengan referensi standarnya bahwa: jika ada suatu transaksi yang berulang dengan behavior dan business rule yang sama maka dibuatkan jurnal khusus, mungkin akan ada lebih dari 1 (Satu) jurnal khusus nantinya; selebihnya jika transaksi dilakukan secara acak, maka dilakukan pencatatan pada jurnal umum.

Contoh dalam hal ini adalah: transaksi permohonan pengajuan uang keluar, transaksi ini selalu menggunakan akun yang sama dan transaksi dilakukan secara rutin setiap harinya; oleh karena itu pengajuan uang keluar ini akan dibuatkan jurnal khusus nantinya. Akan tetapi, business process dari pengajuan uang keluar ini tidak langsung dicatat sebagai jurnal, transaksi ini baru diakui oleh perusahaan setelah uang benar-benar telah dikeluarkan. Demikian prosedur yang ditetapkan oleh perusahaan.

Oleh karena itu, setelah user melakukan pencatatan uang keluar; untuk pemindahan ke dalam jurnal dilakukan setelah user mengKlik tombol paid pada sub-form assignment. Perhatikan ilustrasi berikut:

Gambar: click this to create a journal.

Otomasikan saja nilai yang ada pada pencatatan di pengajuan uang keluar ke dalam jurnal, behavior dan value yang dibutuhkan adalah sama. Jadi, operator nantinya tidak akan membuat pencatatan lagi hanya untuk membuat jurnal ini.

Gambar: alternate flow paid pada pengajuan uang keluar merupakan jurnal khusus.

Perhatikan ilustrasi di atas, salah satu instant dari alternate flows pada pengajuan uang keluar: paid merupakan jurnal khusus. Akan ada banyak otomasi nantinya pada proses pencatatan ke jurnal, namun untuk saat ini baru event ini yang akan kita prioritaskan, kita akan mengupas jika ada temuan baru lagi.

Bisa dimengerti?

Gambar: beberapa event transaksi pencatatan jurnal.

Dari dua spesialisasi jurnal: umum dan khusus, berikan satu flag pada table: typeJurnal misalnya; untuk membedakan apakah ia umum atau khusus, jadi tidak perlu membuat table yang berbeda untuk masing-masing jurnal. Demikian generalisasinya. Kemudian, pada formulir perancangan jurnal; gunakan formulir yang sama, membedakannya juga cukup memberikan properties pada form untuk membedakan apakah ia digunakan untuk event umum atau khusus.

Gambar: field no bukti juga harus diFormat untuk keperluan tracing nantinya.

Ada request dari pihak client untuk memFormat nomor bukti referensi jurnal dengan memberikan beberapa prefix identifier, contoh:

AMS-SA-20120801-001: bukti datang dari saldo awal,
AMS-AJU-20120812-001: bukti datang dari pengajuan uang keluar.

Ada beberapa suku kata nomor bukti:

Digit suku kata pertama adalah kode perusahaan: AMS,
Digit suku kata berikutnya adalah identifier transaksi: AJU (pengajuan), SA (saldo awal) dan sebagainya,
kemudian tanggal event transaksi dilakukan: 20120801, dan terakhir
Sequencial Number dari transaksi: 001.

Sebenarnya untuk identifier transaksi tidak diberikan rule khusus dari client, hanya saja untuk menyederhanakannya agar tidak memberikan banyak digit. Demikian beberapa business rules dalam proses pencatatan jurnal ini.

Kita break sebentar ya..

Kamis, 20 September 2012 Jam 15.27 Sore..

Perlukah membuat bukti jurnal? Jika dirasakan perlu silakan untuk membuat, dalam hal ini lebih baik dibuat saja. Toh hanya laporan harian sederhana sebagai bukti fisik bahwa transaksi sudah dicatat ke dalam jurnal, jika diperlukan pelaporan yang lebih spesifik dapat dikembangkan nantinya.

Gambar: Bukti Jurnal Harian.

Setelah memiliki hasil keluaran dari sub system jurnal, kiranya cukup sampai di sini mengenai proses pencatatan transaksi keuangan perusahaan. Selebihnya kita akan lanjut ke proses pembukuan besar, masih di sesi keuangan.

Pembukuan Besar

General Ledger adalah bahasa asingnya, bahasa Indonesianya adalah: Buku Besar. Bukan berarti sebuah buku dengan ukuran besar yang biasanya digunakan oleh para petugas administrasi di sebuah kantor, tapi lebih tentang istilah. Sebuah buku yang memuat transaksi yang dipisahkan menurut akun yang digunakan pada transaksi, masing-masing memiliki satu buah buku (pencatatan terpisah). Kita dapat melihat hasil rekaman transaksi keuangan per akun:

Gambar: event transaksi keuangan per akun.

Pencatatan ke buku besar dimulai dengan mengisi saldo awal untuk tiap akun, bagaimana jika akun tidak memiliki saldo awal? Tidak perlu diisi, dibiarkan tetap kosong. Karena memang tidak semua akun memiliki saldo awal, sebut saja untuk perusahaan yang baru memulai usahanya sudah tentu belum memiliki piutang pelanggan bukan?

Gambar: Saldo Awal untuk tiap akun.

Untuk mengisi saldo awal ini caranya cukup mudah, tinggal pilih akun mana yang akan diisi pada grid; lalu klik tombol saldo awal. Masukkan jumlah saldo pada TextBox yang tersedia kemudian tekan simpan! Cukup, akun Anda sudah memiliki saldo awal sekarang.

Masih mengenai Saldo Awal untuk Akun, apakah event ini merupakan transaksi keuangan diperlakukan selayaknya proses pencatatan pada jurnal atau memang sebuah event tersendiri?

Gambar: rincian dari akun kas kecil.

Untuk dapat mengetahui rekaman event dari akun dapat diakses dengan memilih akun yang ingin dilihat kemudian klik tombol rincian, kita dapat melihat dari sumber mana saja event transaksi itu terjadi. Dalam contoh yang diberikan; perusahaan belum memiliki transaksi apa pun dan kas kecil baru saja diisi saldo awalnya, oleh karena itu pada kolom referensi hanya terdapat transaksi dari saldo awal (SA).

Sistem Informasi Monitoring