Analisis Sistem, Salah Satu Penyebab Kekacauan Proyek

Analisis sistem :) Waktu ngedenger itu, sejujurnya kepala gw bingung. Bingung, apa yang musti dilakukan duluan? Gimana menyimpulkan bahwa si pengguna kebutuhannya adalah modul ini, ini, ini dan itu? Kalau softwarenya kecil, dan dipake oleh sedikit orang masih gak masalah. Tapi gimana kalo softwarenya besar, dipake oleh banyak orang yang tersebar di divisi-divisi? Software yang dibuat, harus bisa mengintegrasikan proses-proses yang ada. Gimana kita bisa memulai ngumpulin kebutuhan untuk bikin software "raksasa" itu?

Nah, kepusingan ini muncul pada saat dapet proyek ERP perusahaan manufaktur, dan yang terakhir Sistem Informasi Hotel. Nah Sistem Informasi Hotel, bagian Front Officenya aja udah besar dan kompleks, ditambah lagi Back Office, yang kalo diliat-liat kebutuhanya udah kayak ERP buat perusahaan manufaktur. Cuma gak ada modul untuk Produksinya. Pusing lah sudah..

Di buku Robert L. Glass, judulnya Facts And Fallaces Of Software Engineering, di Fact no 23, dia bilang gini,

One of the two common causes of runaway projects is unstable requirments.

Ternyata bener banget :) Gw ngalamin masalah di proyek-proyek besar itu.

Beberapa waktu ini, gw lagi sering belajar manajemen. Tadi malem mulai belajar tentang Software Project Planning. Yang dibutuhin dari planning, salah satunya adalah data-data dari masa lalu. Akhirnya mulai mikir, kalo untuk programming, bisa kita ukur waktunya, untuk disain juga bisa. Karena ada framework, jadi lebih mudah antisipasinya. Waktu mulai mikir analisis........ deng deng..... pusing pun datang. Karena memang gak pernah dipikir sampe tuntas, tahapan-tahapan untuk analisis yang kita pake di kantor.

Akhirnya sepanjang jalan dari rumah ke kantor (jalan kaki nih, kan deket), gw mikirin langkah apa aja yang musti dikerjain. Sampe kantor, gw tambahin di file software_dev_workflow.xls (file yang isinya hasil mikir tentang step-step pengembangan software), begini isinya,

1. Pahami struktur organisasi customer. Dengan memahami struktur organisasi, dapat membantu kita buat mecah-mecah masalah menjadi lebih kecil. Contoh, hotel terdiri dari departemen Front Office, Food And Beverage, Accounting, Marketing dan HRD.
   
2. Pahami proses yang terjadi di setiap departemen dan hubungannya dengan departemen lain. Contoh, untuk melakukan pembelian, bagian gudang membuat Purchase Requisition dan diberikan ke bagian Procurement, bagian Procurement membuat Purchase Order, lalu dikirimkan ke Vendor...dst dst.
   
3. Kumpulkan dokumen-dokumen yang digunakan di setiap departemen. Sewaktu proses terjadi di dalam dan antar departemen, ada dokumen-dokumen yang digunakan. Dokumen ini digunakan sebagai landasan dikerjakannya sesuatu, atau dasar pencatatan akuntansi. Dengan mempelajari dokumen-dokumen tersebut, kita bisa memahami data-data yang digunakan, dan persetujuan yang diperlukan oleh tingkatan yang lebih tinggi. Contoh, untuk proses pembelian tadi bisa dilihat dokumen-dokumenya di contoh di atas. Lalu di Purchase Order, perlu ditandatangani oleh Departement Head Accounting.
4. Pahami pencatatan-pencatatan yang dibuat oleh komponen-komponen yang ada. Contoh, pelajari pencatatan utang yang dibuat oleh bagian Account Payable.
5. Pelajari laporan-laporan yang dibuat. Dengan mempelajari laporan-laporan yang dibuat, kita dapat menyimpulkan data-data tambahan yang perlu disimpan yang data tersebut tidak ada di dokumen dan pencatatan. Lalu, kita juga dapat menyimpulkan kebutuhan laporan mereka. Contoh, laporang Aging AP berisi informasi hutang yang kita miliki per periode tertentu (3 bulan, 6 bulan, > 12 bulan).
6. Buat Use Case. Setelah kita pahami beberapa komponen di atas, kita sudah mulai dapat simpulkan gimana kira-kira nanti pengguna akan mengakses sistem.
7. Definisikan modul-modul yang perlu dibuat dan integrasinya dengan modul lain. Kalo udah ada use case, mudah untuk menentukan modul-modul apa saja yang perlu dibuat. Contoh, perlu dibuat modul Invoice, modul ini akan terintegrasi dengan Incoming Payment.
   
8. Buat aturan untuk setiap modul. Contoh, di modul Point Of Sales, dilarang ada penghapusan bill. Pembatalan bill harus dilakukan dengan mekanisme void, di mana sistem akan membuat transaksi pembalik dari bill yang di-void.

Baru segini yang kepikiran nih. Hmm, ntar di perjalanan disempurnain lagi deh :)

Para Project Manager dan System Analyst, harus sangat merhatiin masalah prosedur analisis sistem. Karena kesuksesan dan kegagalan proyek software, bisa disebabkan oleh yang satu ini.

NB:
Karena sejauh ini pekerjaan yang gw dapet adalah ngembangin sistem informasi, jadi yang disebutin di atas adalah langkah-langkah untuk analisis software Sistem Informasi.