Kami Menang iMulai 2.0

Alhamdulillah,

Tadi lagi meeting tetang rekrutmen programmer baru di kantor. Iseng-iseng cek email, barangkali ada email baru masuk. Ternyata betul, ada email baru judulnya "iMulai Winner (PT AMN)". Terus panggil anak-anak suru pada liat. Semuanya pada triak-triak kesenangan :).

Proposal yang kami ikutkan di iMulai 2.0 menang sebagai salah satu juara. Di kompetisi ini tidak ada juara satu, tapi tiga juara utama. Kami, Alhamdulilah, masuk sebagai salah satu dari tiga pemenang itu.

Tapi ada syarat-syarat yang harus kami penuhi terlebih dahulu. Kami harus revisi budget, karena gw buatnya kelebihan. Terus harus buat revisi jadwal juga. Terus harus buat business plan yang bagus juga.

Satu hal yang penting untuk disadari, kami menang bukan karena kami hebat. Kami menang, hanya karena Allah berkehendak kami menang.

Alhamdulillah

Pengalaman Ikut iMulai 2.0

Mulai tahun lalu, USAID dan Microsoft mulai mengadakan suatu kompetisi bernama iMulai. Kompetisi ini mengajak orang untuk mengirimkan proposal yang berisi inovasi di bidang IT. Pemenangnya akan mendapatkan dana hingga USD 25.000, hardware dan juga software. Nantinya dana itu harus digunakan untuk pengembangan inovasi yang dikirimkan oleh pemenang.

Sangat menarik. Tapi tahun lalu, kondisinya belum memungkinkan untuk ikut. Lalu tahun ini, mereka mengadakan iMulai 2.0. Alhamdulillah, kebetulan minggu ini kondisi kantor sedang memungkinkan untuk ditinggal dan membuat proposal. Akhirnya kami memutuskan untuk ikut.

Perjalanan dimulai dari tanggal 29 November 2008. Hari itu, kami ikut acara brieffing yang diadakan oleh USAID di McCafe, Thamrin. Di sana kami bertemu dengan Bapak Farid Ma'ruf. Orang yang menarik. Dia menceritakan kepada kami mengenai iMulai. Tujuan dari iMulai, manfaatnya, harapan akhirnya, tata caranya dan strusnya. Pak Farid terlihat betul-betul ingin peserta paham maksud dari iMulai. Dan dia sepertinya ingin kami semua bisa menang.

Pulang dari acara itu, rasanya makin semangat. Rasanya ditengah acara itu, pengen pulang ke Bogor dan langsung ngetik proposal. Setelah acara selesai, kami pulang ke Bogor. Hari itu sangat panas, dan gw bawa kendaraan jadi terasa sangat capek. Malemnya gak sempet buat proposal. Dan besok harinya, sakit kepala gw kambuh seharian. Dan proposal pun tak tersentuh.

Deadline proposal iMulai adalah tanggal 5 Desember 2008 jam 24.00.

Hari senin 1 Desember 2008, dimulailah pembuatan proposal. Diawali dari baca banyak artikel di internet, dan buku-buku tentang manajemen. Cukup sulit buat gw mendasari ide ini dengan konsep manajemen.

Lalu proses belajar dan diskusi berlanjut ke hari Selasa 2 Desember 2008. Pada hari itu, hasil brainstorming sudah menghasilkan tulisan, walaupun dengan struktur yang masih sangat kacau :).

Tanggal 3 Desember 2008, kami semua pergi ke Microsof Innovation Day. Betul-betul acara yang sangat menarik. Terutama presentasi2 tekonlogi dari engineer2 Microsoft. Presentasi teknologi yang diberikan adalah tentang WPF, Silverlight, Virtualizatin, dan last but not least Azure (luar biasa). Tulisan yang gw bikin, gw kasih ke temen-temen. Jadi mereka baca di laptop sepanjang perjalanan ke sana. Lalu munculah respond dari temen-temen.

Tanggal 4 Desember 2008, ini hari yang paling berat. Gw berniat membereskan seluruh proposal tersebut pada hari ini. Akhirnya mulailah diskusi intense via YM sama Mbak Tiko dan Hamdi. Mereka adalah konsultan-konsultan ERP yang jago secara teori maupun praktek. Banyak sekali yang didapat dengan diskusi dengan mereka. Tapi hari ini tidak mudah, gw kerja sampe jam 4 pagi keesokan harinya. Proposal teknis bagian terpenting sudah selesai. Gw kirim ke milis manajemen amn, supaya temen-temen bisa baca.

Tanggal 5 Desember 2008 baru tidur jam 4 lebih. Bangun jam 8.30 lalu mulai ngerjain lagi. Jam 11 siap-siap mandi untuk solat Jum'at. Setelah solat jum'at rencananya mau meeting tapi ga jadi. Pulang ke kantor, terusin proposal sampai jam 21.30. Proposal selesai, lalu dikirim melalui web imulai.com.

Ikutan iMulai 2.0 betul-betul memberikan pengalaman yang luar biasa buat gw. Gw dipaksa untuk mengeluarkan seluruh kemampuan gw dalam berinovasi tapi masuk akal dan menuangkan dalam tulisan yang profesional. Proposal yang dibuat harus cukup jelas, tidak terlalu rinci tapi menjelaskan fitur-fitur penting, jelas dampaknya untuk bisnis, dan jelas bahwa inovasi itu solusi dari masalah yang mana.

Kesimpulanya, ikutan iMulai 2.0 memaksa gw untuk berfikir keras tentang ide yang ada. Menuliskan ide itu dan memikirkanya secara lebih rinci. Ini sangat penting jika kita bertanggung jawab sebagai orang yang menentukan arah perusahaan.

Memang iMulai 2.0 menawarkan hadiah yang besar buat para pemenang. Tapi IMHO, the real price adalah pelajaran yang didapat sewaktu membuat proposal invoasi itu.

So, win or loose, I've already got the price :)

Ucapan Selamat Terbaik Lebaran Kemarin

Ini adalah ucapan terbaik, lebaran kemarin :) :

Kulihat Ramadhan dari kejauhan. Kudekati lalu kusapa, "Hendak ke mana?" Dengan lembut ia berkata, "Aku harus pergi, mungkin jauh dan sangat lama. Tolong sampaikan pesanku untuk si mukmin, Syawal akan tiba sebentar lagi.  AAjaklah sabar untuk temani hari-hari dukanya. Peluklah istiqomah saat dia kelelahan dalam perjalanan taqwa. Bersandarlah pada tawadhu saat kesombongan menyerang. Mintalah nasihat pada Al Qur An dan Sunnah di setiap masalah yang dihadapi. Sampaikan pula salam dan terima kasih untuknya karena telah menyambutku dengan suka cita. Kelak akan kusambut ia di Surga dari pintu Ar Rayyan."

Ismail Wafi Abdat

Ismail Wafi Abdat. Itu nama keponakan gw :) Alhamdulillah hari ini (17 September 2008) sekitar jam 12 siang Ismail lahir. Hari ini udah ditunggu-tunggu sama keluarga gw. Sewaktu dokter bilang tinggal nunggu hari, rasanya setiap hari kami tunggu-tunggu.

Dari tadi siang Wafi (kakak gw) nyoba ngirim MMS gak berhasil-berhasil. Sampe akhirnya ada sms dari INDOSAT yang isinya bahwa gw dikirimin MMS dan bisa diakses dar https dst dst. Akhirnya setelah nunggu MMS gak nyampe-nyampe. Gw coba buka pake koneksi Speedy di komputer Aan. Ini fotonya...


Foto-foto lainya bisa diliat di multiply-nya Aan.

Nonton Wall-E

Kemaren, buka puasa bareng temen-temen di PIM. Berangkat dari Bogor sekitar jam 15.00. Tadinya mau berangkat dari siang, karena mau nonton Wall-E dulu sambil nunggu Maghrib. Cuma, seperti biasa, ngaret dan brangkat jam 15.00-an.

Sampe di sana sekitar jam 16.00. Udah gak keburu nonton. Dan Wall-E udah gak ada di XXI, adanya di 21. Akhirnya diputusin nonton yang jam 21.00. Kemaleman si, cuman udah nunggu-nunggu pengen nonton ni film. Yang ada, kalo gak jadi, bakal kelewat lagi.

Ga bakal cerita detail tentang film itu, ntar takut ada yang belum nonton jadi kacau gara-gara gw ceritain.

Tapi gw bakal ceritain inti dari film itu. Intinya adalah, bumi sudah ditinggalkan oleh manusia selama 700 tahun karena dipenuhi sampah. Manusia-nya naik kapal luar angkasa pergi tinggal di angkasa luar. Wall-E adalah robot yang dulunya dibikin buat ngebersihin sampah-sampah itu. Sebenernya ada banyak, cuma yang selamat tinggal satu.

Sampai suatu hari, ada robot peneliti yang dikirim oleh manusia untuk neliti bumi. Namanya Eve. Dan akhirnya Wall-E jatuh cinta sama robot tersebut. Kedua robot itu gak bisa ngomong. Dan sepanjang film itu dicertain gimana kisah cinta mereka berdua. Singkat kata, film ini deadly romantic. Aneh gak? Film robot, gak bisa ngomong, tapi romantis. Nonton aja biar ngerti maksudnya :)

Waktu Serasa Berjalan Lebih Lama

Di luar bulan Ramadhan, waktu rasanya berjalan sangat cepat. Baru kerja dikit, udah Dzuhur, kerja dikit lagi udah Ashar dst dst. Aneh rasanya.

Tapi di bulan Ramadhan, waktu rasanya berjalan lambaat banget menit demi menit-nya. Istirahat siang aja rasanya waktunya gak abis-abis. Cuman, ada yang repot. Badan dan otak pun rasanya bekerja lebih lambat. Srasa lagi bergerak dan berpikir tapi slow motion. Hehehe...

Implementasi Sistem dan Pernikahan

Banyak orang yang kasih nasehat tentang pernikahan belakangan ini. Itu karena umur sekarang sudah mencapai hitungan yang pas untuk menikah :) Ada satu nasehat dari salah satu paman gw yang disampein bibi gw ke gw. Begini,

Kalau menikah, kita harus 50:50. 50 dari suami, 50 dari istri. Kalau tidak begitu, pernikahan kita susah untuk langgeng.

Maksudnya, kita gak bisa membawa 100% kemauan kita dalam berkeluarga. Tapi kita harus menegosiasikan kemauan pasangan kita, dan pasangan kita juga harus menegosiasikan kemauan kita (fifty - fifty). Tujuanya adalah agar terjalin keluarga yang baik.

Namun tentunya, kemauan tadi diterima dan ditolak juga didasari oleh prinsip berekeluarga yang benar. Dalam kasus gw, karena gw muslim, prinsip yang mendasari adalah prinsip Islam.

Jadi, kesimpulannya, kedua pasangan (suami dan istri) harus memiliki tujuan yang sama, yaitu membina keluarga yang baik. Dengan membela tujuan itu, masing-masing harus mengorbankan sebagian keinginannya.

Begitulah kira-kira yang gw pahamin dari pernikahan.

Mari kita sekarang bahas tentang implementasi sistem informasi. Implementasi sistem informasi ditujukan agar proses kerja dapat berjalan dengan lebih efisien dan efektif. Selain itu, bertujuan agar internal control menjadi lebih efisien.

Lalu, apa kaitanya dengan bahasan tentang nikah?

Kaitanya ada di konsep 50:50 tadi. Konsultan harus melihat kebutuhan customer akan sistem informasi. Lalu membuat sistem informasi yang tepat, sehingga tujuan di atas bisa tercapai. Di sisi lain, customer juga perlu menyesuaikan cara kerja mereka dengan cara kerja baru dengan bantuan sistem informasi. Bahasan ini rincinya bisa dipelajari di subject change management. Gw belum sempet belajar banyak, baru nanya-nanya ke Mbak Tiko aja waktu perjalanan ke Kerawang :)

Masalah yang sering terjadi disebabkan dari dua sisi. Pertama dari sisi konsultan. Konsultan tidak melakukan requirment gathering dengan tepat. Seringnya masih terpaku pada keinginan customer, bukan kebutuhan. Prinsip yang harus dipahami adalah, konsultan IT (seharusnya) lebih paham tentang sistem informasi dari customer. Jadi seharusnya, konsultan-lah yang menggali kebutuhan customer akan sistem informasi agar tujuannya bisa tercapai. Gw baru simpulkan ini setelah proyek BPMIGAS kemarin.

Permasalahan kedua adalah dari sisi customer. Mereka tidak mau mengubah cara mereka bekerja, dan tidak ingin mempelajari sesuatu yang baru. Ini masalah besar. Karena, sehebat apapun sistem informasi, akan sulit sekali diimplementasikan jika customer tidak ingin menyesuaikan cara kerja mereka. Di sinilah change management berperan. Jadi gw harus belajar change management nih :)

Namun ada alasan lain mengapa mereka tidak mau mengubah cara kerja mereka dan mempelajari sistem yang baru. Masalahnya di sistemnya itu sendiri. Kadang, sistem yang kualitasnya masih buruk sudah direlease ke customer. Pada akhirnya bermunculan-lah error-error yang tidak bijaksana :D. Kalo masalah ini, solusinya di proses quality control-nya. Nah masalah QC ini adalah masalah terbaru yang kami sadari.

Dalam dunia bisnis, inti dari semua proses adalah profit. Mengerjakan pekerjaan secara efisien dan efektif akan bermuara kepada peningkatan profit. Internal control yang baik, akan bermuara kepada bersihnya perusahaan dari praktek yang aneh-aneh, dan akhirnya bermuara pada peningkatan profit juga.

Kesimpulanya jika ingin implementasi sistem informasi berjalan baik, maka dari sisi konsultan dan customer harus sama-sama fokus pada tujuan. Konsultan mengerjakan keinginan yang juga kebutuhan customer, dan customer menerima hasil kerja yang dibutuhkan tapi tidak mereka inginkan. Dengan demikian ceritanya akan berakhir dengan hapily ever after....:)

Lagi stres ngerjain payroll process. Jadi nulis ginian dulu.

Menyadari Kesesatan Penggunaan Domain Model Pattern

Waktu diskusi terakhir tentang arsitektur framework software sama Harry dan Dankos, gw memulai diskusi masalah penggunaan model pattern di aristektur MVC yang kami gunakan. Martin Fowler menyebut model dalam MVC itu sebagai Domain Model pattern. Di diskusi itu kami diskusiin gimana seharusnya model itu diimplementasikan. Karena selama ini, logic aplikasi banyak terjadi di sisi controller atau DAO (kami pakai DAO untuk akses data). Hasil diskusi itu menyimpulkan perlu adanya perubahan.

Hari ini, lupa tadi nyari apa, tapi dapet artikel bagus banget. Tulisanya bisa dibaca di sini. Yang akhirnya di situ ada link ke tulisan Martin Fowler lagi, bisa dibaca di sini.

Martin Fowler (MF) membahas tentang anti-pattern yang namanya AnemicDomainModel. Anti-pattern adalah design pattern yang keliatanya benar tapi nyatanya jauh dari optimal jika digunakan. Anemic adalah salah satu anti-pattern.

Nah anemic ini yang ternyata selama ini banyaknya kami gunakan. Begitu juga di beberapa aplikasi yang orang lain buat yang gw pernah liat. Hmm, gw jelasin pake bahasa gw aja tentang anemic. Kalo mau baca penjelasan MF, liat di link tadi aja :)

Begini, di aplikasi yang terakhir kami buat, pada akhirnya model itu seperti struktur data struct (di C) atau type (di pascal). Model berisi kumpulan propoerty dan ada getter dan setternya. Tapi, behaviournya gak ada. Ataupun ada, hanya sedikit sekali. Business prosesnya ada di controller atau ada di DAO (banyaknya di DAO). Dan ada ganjelan di hati ini yang sangat luar biasa sekali disampaikan oleh MF di artikel itu.

The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together.

Begitulah, ternyata slama ini gw sesat :)) Untuk mengungkap kesesatan-kesesatan yang lain, dan memperbaikinya. Sekarang lagi baca dua buku tentang pattern, Head First Design Pattern dan Patterns of Enterprise Application Architecture (Martin Fowler). Untuk liat pattern-pattern Enterprise Apps punya MF bisa diliat di sini.

Saran buat yang sama-sama sesat, baca buku Patterns of Enterprise Application Architecture di situ, ada penjelasan berikut contoh tentang penggunaan Domain Model pattern.

Bis Non-AC Dan Macet

Walhasil,pulang dari BSI.Seudah nunggu lama di pinggir solokan berbau dajal akhirnya dapet juga bis.Dan ternyata bukan bis AC.

Ambil kursi paling blakang. Dan ternyata bapak2 di sebelah ngrokok.

Waktu bis jalan sedikit tiba2 berenti lagi. Ternyata macet.

Singkatanya panas, macet, bau asem, duduk gak enak.... Yah sudahlah, tidur aja.

Cara Pengusaha Muda Di Amerika Menjadi Kaya

Beberapa hari lalu baca artikel Twentysomething Entrepreneurs di businessweek. Di sana dibahas beberapa pengusaha di USA yang umurnya belum 30 tahun dan menghasilkan jutaan dolar dalam satu tahun. Ada beberapa hal yang menarik dari tulisan-tulisan itu. Berikut ini rincianya,

1. Mereka dibiayai oleh Venture Capitalist. Ini yang menjadi alasan orang-orang di Indonesia tidak mau berbisnis IT. Sering sekali muncul "kalo di Amerika, banyak angel VC", "di USA VC sangant mendukung..". Betul memang. Tapi dari cerita beberapa orang itu, bisa dilihat beberapa dari mereka bekerja tanpa VC terlebih dahulu, setelah berjalan baru mencari investor. IMHO, ini sangat penting tapi bukan hal utama.
2. Dari beberapa orang yang ada di list, sebagian besar dari mereka membuat software yang dapat digunakan orang secara gratis.

Dari beberapa orang di daftar tersebut (walaupun tidak semua) mereka memberikan software mereka untuk dapat digunakan gratis. Yang menurut gw paling menarik adalah Chaim Indig. Mereka membuat device touchpad + software yang digunakan di lebih dari 1000 dokter di USA untuk pasien melakukan registrasi. Device-nya mereka bagi-bagikan gratis ke semua dokter itu (bukan cuma software). Mereka mendapatkan pendapatan dari pemasangan iklan pada tampilan device tersebut. Iklan yang ditampilkan adalah iklan-iklan dari perusahaan farmasi. Beuh,... ide ini keren bener. Alasan gw tertarik banget sama yang ini, karena tidak perlu orang yang sering pake internet untuk melihat iklan yang ditampilkan. Tapi semua orang yagn sakit dan datang ke dokter.

Bisa dibayangin, kalo kita bisa bikin bukan cuma software buat registrasi. Tapi software itu digunakan juga untuk mencatat data rekam medis si pasien. Sehingga pada saat pasien tersebut registrasi kembali, sistem bisa menyimpulkan obat apa yang kira-kira paling dibutuhkan oleh si pasien. Tapi gak tau juga, apakah ini melanggar kerahasiaan data rekam medis :)

Kesimpulanya, para pengusaha IT di Amerika banyak yang menjadi kaya bukan karena menjual software-nya. Tapi melalui iklan yang mereka pasang di software-software mereka yagn mereka beri gratis buat para penggunanya.

Sebetulnya, gak perlu harus orang Amerika ya. Asal kita bisa punya ide yang mendunia, kita bisa juga kaya mereka :)

Bisnis IT Di Indonesia Itu Susah

Belakangan ini, salah satu buku yang lagi sering dibaca adalah "10 Pengusaha Yang Sukses Membangun Bisnis Dari 0". Kenapa buku ini menarik? Buku ini berisi cerita 10 orang yang berhasil membangun bisnis di Indonesia. Di pembuka buku itu dijelaskan, bahwa orang-orang yang dipilih ini bukan orang yang berhasil karena dari warisan atau korup :) Isinya adalah betul-betul orang yang membangun bisnis dari 0 di Indonesia. Sam, kok Indonesianya sampe dikasih tebel miring gitu? Ya, soalnya banyak buku-buku yang berisi biografi para pebisnis. Tapi buku ini lain, isinya orang-orang yang baru gw kenal dan bener-bener bisnis dari 0 dan di Indonesia. Di lingkungan yang sama di mana gw sedang berusaha. Ini sangat penting.

Di buku itu, ada orang namanya Heppy Trenggono. Dia adalah pendiri Balimuda Perkasa. Perusahaan yang bergerak dibidang pembukaan lahan dan perawatan lahan perkebunan kelapa sawit. Dia punya puluhan (atau ratusan ya?) alat-alat berat yang harganya dari ratus juta sampai puluh milyar. Serem bener ya :)

Yang menarik, Pak Heppy dulunya bekerja di bidang IT. Pekerjaan terakhirnya adalah kepala divisi IT di perusahaan Alativ (perusahaan Abdul LAtif yang dulu punya Lativi). Dia cerita bahwa gaji di sana besar dan bisa mendapat kemudahan di mana-mana. Sebelumnya juga dia bekerja di bidang IT. Hebatnya Pak Heppy ini, dia meninggalkan semua kemapanan dan usaha sendiri.

Kaitannya sama bisnis IT apa si Sam? Waktu masih kerja, Pak Heppy sering ngerjain proyek-proyek di luar. Dia sangat berhasil dalam hal nyambi. Pada saat keluar dari kantor, tentunya yang pertama kali di buka adalah perusahaan IT. Hanya saja, setelah beberapa lama dia tinggalkan dan pindah ke bisnis lain. Menurut beliau, susahnya perusahaan besar di Indonesia tentunya mencari perusahaan IT besar lagi, sedangkan perusahaan-perusahaan menengah dan kecil mereka butuh harga murah, akhirnya mahasiswa atau pekerja freelance. Pada saat Pak Heppy buka usaha kecil, dan pasang harga cukup, maka akhirnya sulit bagi dia untuk mendapatkan pekerjaan. Kesimpulan beliau, usaha IT itu sulit.

Cuma mau nambahin, sebetulnya sulit itu di Indonesia. Alasan pertama, tentunya seperti yang dibilang pak Heppy di atas. Alasan berikutnya, penggunaan IT di INdonesia belum sehebat di luar negri. Orang-orang di sini belum fasih dalam penggunaan IT. Sehingga sulit untuk bergerak jika kita punya ide-ide yang inovatif.

Begitulah kira-kira.

Selain itu, baru aja beres baca buku tentang Jeff Bezos (beli di gramedia bukunya), dia adalah pendiri Amazon.com. Ada paham menarik yang dia punya, walalupun agak OOT :D. Komputasi terdiri dari dua fase. Fase pertama adalah ketika manusia mengerjakan pekerjaan dengan cara lama tapi diefisiensikan dengan penggunaan IT. Contohnya penggunaan point of sales dan barcode reader di toko. Berikutnya adalah fase kedua, di mana manusia mengerjakan pekerjaan dengan cara yang baru sama sekali. Berdasarkan pemahaman itu, dia bikin Amazon.com, yang akhirnya mengubah cara orang untuk membeli barang-barang :)

Buat para pengusaha IT kecil di Indonesia, jangan menyerah. Jika berbisnis itu mudah, maka semua orang akan berbisnis. Hal pertama yang perlu disadari adalah susah adalah sesuatu yang harus kita nantikan, karena itu adalah hal alami dalam jalur yang kita ambil.

Dua Makhluk Penting Dalam Software Project

Makhluk? Iya, bukan cuma manusia. Sayangnya kita ga boleh minta bantuan jin :p

Bukan gitu maksudnya. Di dalam impian gw, mungkin saja sebagian pekerjaan dikerjakan oleh sistem yang sangat pintar. Sekarang sudah ada Case Tools, mungkin someday, cukup satu orang buat bikin software yang sangat advance :) Hmm, bukan cuma mimpi sebenernya.

Beberapa waktu ini, lagi ada kerjaan di Berlian Sistem Informasi. Di sini, project yang dikerjain canggih-canggih, dan buat perusahaan-perusahaan besar. Seru banget ngeliat fitur-fitur, teknologi, dan orang-orang yang ngerjain. Di sini, dokumentasi software development di sisi analisisnya bagus. Selama ngerjain kerjaan di sini gw berfikir tentang pembagian pekerjaan dalam software development (duh sam.. ga bosen sam?).

Menurut kesimpulan gw, ada dua makhluk yang sangat penting. Bahkan, nasib suatu project software ada di tangan mereka. Bukan artinya yang lain tidak penting, tapi dua makhluk ini yang terpenting.

Makhluk pertama bernama sistem analyst.

Apa yang seharusnya dikerjakan system analyst?
System analyst adalah penentu pertama dari gagal atau berhasilnya project software. IMHO, seorang system analyst adalah orang yang melakukan requirment gathering. Terjemahan sembaranganya, mengumpulkan kebutuhan. Yang sangat penting dipahami adalah kata "kebutuhan". Kebutuhan yang dikumpulkan sebetulnya bukan kebutuhan user akan software. Seorang sistem analyst harus bisa mengumpulkan kebutuhan calon user akan solusi.

Apa bedanya kebutuhan software dengan solusi? Kan solusi yang kita berikan ke calon user adalah solusi kan?

Betul. Begini rincinanya. Seorang analyst, harus mempelajari bagaimana suatu proses bisnis bekerja. Dan kenapa proses bisnis itu bekerja seperti itu. Setelah paham, barulah mereka berfikir, bagaimana caranya proses bisnis itu bisa dioptimasi. Sebetulnya, teknik optimasi ini dipelajari di Teknik Industri, bukan di Computer Science. Lalu sistem analyst berfikir, informasi apa yang dibutuhkan oleh setiap layer manajemen. Permasalahan informasi dari suatu bisnis adalah kebutuhan akan informasi yang cepat, akurat, dan pada waktunya.

Dengan begitu, kebutuhan calon user akan solusi dapat terpenuhi. Karena harus sangat dipahami, mereka implementasi IT itu karena mereka berfikir bahwa IT bisa menjadi solusi dari masalah mereka. Jika tidak, untuk apa? Akhirnya hanya menambah pekerjaan yang merepotkan.

Lebih baik implementasi sistem sederhana yang dapat digunakan untuk mencatat penjualan, lalu menampilkan report-report yang sangat variatif untuk kebutuhan pengambilan keputusan, daripada implementasi ERP dari A sampai Z tapi tidak memenuhi kebutuhan. Lebih baik lagi kalo implementasi ERP dari A sampai Z dan memnuhi kebutuhan :)

Yang perlu dipahami juga, kebutuhan <> keinginan. Seringkali calon user meminta bentuk report yang begini dan begitu. Sebenarnya yang perlu kita pahami adalah, kenapa calon user butuh report itu? Jika kita bisa memahaminya, mungkin kita dapat memberikan solusi yang lebih tepat untuk memenuhi kebutuhan dia. Wajar kan? System analyst ini adalah orang-orang yang berpengalaman dalam mengembangkan sistem informasi :)

Jadi, solusi = software dengan modul-modul yang tepat sasaran.

Inilah tugas system analyst. IMHO, karena tugas seberat ini, lebih baik tanggung jawab technical tidak diberikan kepada system analyst. Biarkan tugas technical diberikan pada makhluk lain.

Makhluk kedua bernama system designer atau di beberapa tempat disebut dengan senior programmer atau senior engineer. Bahkan di beberapa tempat ada yang namanya system architect yang merancang arsitektur teknologi (bukan cuma softwarenya). Namun di beberapa tempat, system designer ini tidak ada, akhirnya programmer merangkap system designer jg.

Apa yang seharusnya dilakukan system designer?
Software yang memenuhi kebutuhan user saja tidak cukup. Statement yang aneh, tapi itu bener. IMHO, software yang dibuat, selain harus memenuhi kebutuhan user, juga harus memenuhi kebutuhan tim development. Lebih aneh lagi statementnya :(

Maksudnya begini, jika suatu produk software dikerjakan, software itu pasti harus dimaintain. Memperbaiki erorr jika ada, menambah fitur jika dibutuhkan, integrasi dengan sistem lain dsb dsb dsb. Software dengan design yang baik, dan source code yang mengikuti standar akan memudahkan tim developer untuk memahami source code software tersebut. Dengan begitu, tahapan maintenance dan pengembangan berikutnya akan lebih baik. Penjelasan ini, berkaitan dengan atribut understandability dan modifiability di posting sebelumnya tentang kualitas software.

Pada saat mendisain software, system designer harus selalu berfikir tentang understandability dan modifiability ini. Hal ini bukan hal mudah. Namun sangat terbantu dengan adanya design pattern yang bisa kita temukan di banyak buku.

Kesimpulan dari tulisan ini, ada dua makhluk penting dalam software development, yang satu mikirin apa yang harus dibuat (system analyst), yang satu mikirin gimana dibuatnya (system designer).

Apakah selain dari mereka berdua penting? Ya sangat penting. Intinya, jika di dalam tim software ada dua makhluk di atas yang berkemampuan tinggi, maka pekerjaan software development kita akan lebih banyak dihiasi senyuman :)

NB:
Duh, bikin sistem informasi mulu, jadinya kalo ngomong software itu maksudnya sistem informasi. Semoga pembaca bisa mengerti. Hehe.

Kualitas Software

Menurut Robert L Glass (Facts and Fallacies od Software Engineering, Addison Wesley, 2002), kualitas software adalah mengenai sekumpulan atribut yang seharusnya dimiliki oleh suatu produk software. Atribut-atribut tersebut adalah:
1. Portability. Kemudahan pemindahan software ke platform lain.
2. Reliability. Software dapat diandalkan untuk melakukan apa yang seharusnya dilakukan.
3. Efficiency. Software dapat melakukan pekerjaan dengan waktu kerja dan penggunaan resource yang ekonomis.
4. Human Engineering. Software dapat digunakan dengan mudah dan nyaman.
5. Testability. Software mudah untuk diuji.
6. Understandability. Software mudah dipahami sehingga memudahkan proses pemeliharaan.
7. Modifiability. Software mudah dipelihara (maintain) dan diubah.

Portability pada software, sangat tergantung kepada teknologi yang digunakan. Pemilihan teknologi didasari oleh pertimbangan yang matang berdasarkan hasil analisis terhadap calon pengguna. Jika calon pengguna menggunakan platform yang heterogen, maka portability adalah hal yang sangat penting. Namun portability akan berkurang prioritasnya ketika calon pengguna menggunakan spesifikasi teknologi yang seragam.

Reliability adalah atribut yang tidak dapat ditawar. Hal ini dapat dicapai dengan melakukan proses analisis kebutuhan calon pengguna dengan baik. Proses analisis kebutuhan seringkali dipandang sebagai proses menyimpulkan kebutuhan calon pengguna terhadap software. Seharusnya, proses analisis dipandang sebagai proses yang dilakukan untuk menyimpulkan solusi untuk masalah pengguna. Perbedaan pandangan ini sangat penting, karena sering kali calon pengguna menjelaskan kebutuhan modul yang dibutuhkanya, namun modul tersebut bukanlah solusi yang terbaik dari masalah yang dihadapinya. Dengan menganalisa masalah calon pengguna, lalu menyimpulkan solusi dari sisi kita maka engineer dapat lebih menjamin reliability dari suatu software.

Efficiency seringkali tidak diperhatikan. Umumnya hal tersebut terjadi, karena tim fokus kepada spesifikasi fungsional sistem. Ketika spesifikasi fungsional sudah terpenuhi, maka modul software dianggap telah mencapai kualitas yang baik. Efficiency seringkali tidak terasa dibutuhkan pada aplikasi sistem informasi yang tidak melakukan proses yang rumit. Namun untuk proses yang rumit, efficiency menjadi hal yang sangat penting untuk diperhatikan. Efficiency dapat dicapai dengan disain yang baik dan code review terhadap hasil implementasi disain yang dilakukan. Selain itu, pada saat pengujian (testing), perlu dilakukan stress testing, suatu proses pengujian yang menekankan pada kemampuan software pada saat melakukan proses pada keadaan yang tersulit (e.g. data yang sangat banyak).

Human engineering dapat dicapai dengan melakukan perancangan antar muka software dengan baik. Hal ini juga berkaitan dengan efficiency jika software melakukan proses yang rumit, karena pengguna akan merasa tidak nyaman jika proses yang dilakukan terlalu lama.

Testability akan berpengaruh terhadap reliability. Engineer dapat menyimpulkan bahwa suatu software sudah cukup reliable untuk direlease adalah berdasarkan hasil pengujian. Karena itu, testability adalah atribut yang sangat penting dalam pengembagan software.

Understandability dan modifiability. Kedua atribut tersebut bisa diacapai dengan melakukan proses disain yang baik dan kontrol terhadap kode yang dihasilkan oleh programmer. Pada pengembangan software, terdapat suatu framework yang digunakan oleh seluruh engineer dalam mengembangkan modul. Kode program yang dihasilkan perlu direview agar dapat dipastikan bahwa programmer telah menulis kode sesuai dengan standar yang sudah ditetepakan di framework. Dengan perancangan dan penulisan kode yang sesuai dengan standar yang ada, maka disain dan kode yang dihasilkan oleh engineer akan mudah untuk dipahami oleh engineer lain. Hal ini menjadi atribut yang sangat penting untuk diperhatikan, terutama jika engineer yang mengerjakan sering berganti.

Kopi BSI

Semenjak ngerjain kerjaan bsi jd minum kopi tiap hari. Ini test blogging pake k530i.

6 Prinsip Bisnis Yang Harus Diketahui oleh Manajemen

Beberapa waktu belakangan ini, lagi baca buku judulnya The Complete Ideal's Guide MBA Basic, karangan Tom Gorman. Buku ini sudah dalam bahasa Indonesia. Yang ternyata, versi bahasa ingrris judulnya The Complete Idiot's Guide to MBA Basics (menyedihkan skali :( ). Tapi isi buku itu bener-bener bagus dan enak di baca. Memang Idiot's series itu emang didisain untuk mudah dibaca. Untuk liat bab-bab lengkapnya, silahkan masuk ke link amazon tadi dan klik link Search Inside The Book.

Di bab pertama buku itu, dijelaskan "6 prinsip bisnis yang harus diketahui oleh manajemen profesional". Sebetulnya bukan hanya enam, pasti masih banyak lagi. Tapi 6 prinsip ini sangat penting. Begini kira-kira prinsipnya,

1. Nilai (value). Bisnis melakukan perubahan dari sumber daya yang ada menjadi nilai. Sumber daya bisa berupa bahan mentah, tenaga kerja, tenaga listrik dan lain sebagainya. Pada dasarnya, nilai inilah yang dibeli oleh customer. Contoh yang ada di buku itu, Mc Donald membuka tempat makan yang murah yang mudah dijangkau. Itulah nilai yang mereka jual. Kami di sini, menjual kemampuan untuk membuat software, dan produk software yang telah kita buat untuk membantu pekerjaan orang.
2. Pengorganisasian (Organizing). Maksud dari pengorganisasian adalah mengatur. Manajemen perlu tau caranya mengatur seluruh proses perubahan nilai yang terjadi di dalam bisnis. Untuk memudahkan pengaturan, biasanya dibuat struktur perusahaan sehigga adanya manajer produksi, manajer keuangan, CEO, CFO, etc etc. Masalah struktur ini tergantung culture dari bisnisnya. Misalkan untuk perusahaan manufaktur, struktur yang hirarkis sangat penting. Namun untuk perusahaan yang lebih banyak kreatif, struktur yang lebih longgar lebih baik. Inti utamanya bukan pada struktur, tapi pada pengorganisasian.
3. Kontrol. Tidak pernah ada jawaban "tidak tahu". Artinya, seorang manajer harus dapat melakukan kontrol (mengendalikan) perusahaan-nya. Kontrol perusahaan dapat dilakukan berdasarkan informasi yang didapat. Bayangan-nya begini, andai kita sedang menyeetir mobil. Mobil dikendalikan dengan setir, gas, kopling, dan rem. Untuk dapat mengendalikan mobil kita perlu informasi yang kita dapat dari kaca mobil, speedometer, ukuran bensin dsb dsb. Dengan demikian, kita dapat sampai di tujuan kita.
4. Keunggulan kompetitif. Setiap perusahaan memiliki keunggulan kompetitif-nya masing-masing. Keunggulan kompetitif dapet beupa macam-macam bentuk. Keunggulan dari sisi kualitas, dari sisi harga, dari sisi service dan lain sebagainya. Namun tidak ada perusahaan yang memiliki seluruh komponen keunggulan kompetitif. Manager harus mengetahui ini, dan mengendalikan perusahaan untuk konsentrasi pada keunggulan kompetitif ini, sehingga bisa bersaing dengan perusahaan-perusahaan lain.
5. Profitabilitas. Tujuan bisnis adalah menghasilkan profit untuk pemilik bisnis. Sehebat apapun yang dilakukan, tidak ada manfa'atnya jika tidak menghasilkan profit. Tujuan utama dari bisnis adalah profit.
6. Etika. Masalah ini terjadi pada beberapa perusahaan di Amerika. Salah satu contohnya adalah Enron, yang dituntut karena praktek saham yang tidak benar. Masalah ini sering muncul karena godaan untuk menghasilkan profit yang lebih tinggi.

Begitulah, prinsip bisnis yang baru dibaca. Rasanya sangat bermanfaat, setidaknya buat manager pemula seperti sayah :)