Monthly Archives: May 2013

Produk, Project dan Prakarya

Beberapa tahun lalu saya dan kawan-kawan sedang berdiskusi mengenai kerjaan masing-masing. Ada yang menarik dalam diskusi itu, kawan saya mengatakan kepada timnya bahwa “kita ini bikin produk, bukan prakarya”. Dari situ pembicaraan mengenai produk vs prakarya ini membantu kami dalam mendefinisikan dengan jelas, mana produk, mana prakarya, mana proyek.

Prakarya

Prakarya dedefinisikan sebagai hasil karya yang belum jadi, baru sekedar proof of concept, atau sebuah prototipe. Prakarya tidak punya definisi target market yang jelas, oleh sebab itu belum ada penggunanya atau konsumennya. Satu-satunya penggunanya mungkin si developer atau desainer itu sendiri. Kualitas belum menjadi perhatian sebab yang penting bentuk dasarnya saja. Harga sebuah prakarya ditentukan sangat subyektif sebab belum tahu potensi pasarnya.

Project

Proyek kami definisikan sebagai hasil karya yang ditujukan untuk 1 single client, biasanya datang berdasarkan pesanan orang atau perusahaan yang membutuhkan. Satu orang, satu perusahaan, satu instansi tetap dihitung satu. Delivery modelnya juga langsung antara developer dan client. Fungsi yang dibangun dalam proyek mengikuti kebutuhan client, dan sangat customized. Sebuah proyek software keuangan untuk instansi A belum tentu bisa dipakai di instansi B. Karena penggunanya cuma 1, biasanya harganya juga mahal sebab seluruh biaya pembuatan proyek dibebankan kepada 1 client tersebut. Aspek kualitas mulai jadi perhatian sebab proyek yang kualitasnya jelek akan menimbulkan kekecewaan client dan akhirnya bisa dibatalkan/tidak dibayar.

Produk

Produk didefinisikan sebagai hasil dari sebuah proses yang distandarisasi. Produk ditujukan untuk target market yang jelas, baik itu niche market atau consumer market. Satu segmen pasar berpotensi mendapatkan minimal 1000 atau 1.000.000 pengguna, tergantung segmen pasarnya. Karena produk ini akan digunakan oleh pengguna yang demikian banyak, kualitas sangat kritikal. Sebab produk yang kualitasnya jelek akan ditolak oleh pasar dan menimbulkan kerugian akibat retur atau refund.

Produk memiliki fitur atau fungsi yang standar atau baku. Customisasi tidak menjadi perhatian. Harga yang ditawarkan harus murah, setidaknya terjangkau oleh target market yang dituju. Tidak boleh lebih mahal dari willing to pay mereka.

Kerancuan

Dalam percakapan sehari-hari tentu kita sering salah komunikasi mengenai hal ini. Banyak orang bilang dia bikin produk, padahal dia bikin prakarya atau project. Namun saat ditanya target marketnya siapa, tidak bisa dijelaskan. Oleh sebab itu penting kiranya kita menyamakan persepsi mengenai hal ini. Poin pembedanya adalah Target Market dan Standar Kualitas yang diperlukan.

Nah, berdasarkan definisi tersebut, semoga cukup membantu menjelaskan apakah kita bikin produk, proyek atau prakarya?

 

Niat yang Benar dalam Melakukan Perbaikan Proses

 

dmaic

dmaic

Seperti yang saya sebutkan beberapa kali sebelumnya, bahwa salah satu tugas saya di Sandiloka adalah memperbaiki proses, melakukan perbaikan proses. Prinsipnya sederhana saja, Right Process brings Great Results. Kalau prosesnya benar, maka hasilnya bagus. Ujung-ujungnya, yang diharapkan adalah hasil yang bagus.

Lalu apa itu hasil yang bagus? Di sinilah banyak kesalahan orang dalam mendefinisikan, apa itu hasil yang bagus. Sebagian dari kita mengharapkan dari perbaikan proses itu maka profit meningkat. Pendapat ini memang benar sebab perbaikan proses menimbulkan efisiensi. Tapi kalau tidak hati-hati, akan timbul kekacauan.

Mengapa? Mari kita lihat faktor-faktor berikut

1. Reduksi Biaya

Katakanlah dari perbaikan proses tersebut, memberikan efisiensi dalam bentuk reduksi biaya sebesar 1% dari total biaya produksi atau biaya software development yang totalnya Rp. 100.000.000. Maka, anda memperoleh efisiensi sebesar Rp. 1.000.000.

Tapi di saat yang bersamaan, ada kenaikan biaya bahan bakar akibat pengurangan subsidi BBM sebesar 30% dari bulan sebelumnya. Misal biaya bahan bakar juga Rp 100.000.000, maka Anda mengalami kenaikan biaya sebesar Rp 30.000.000 menjadi Rp 130.000.000.

Di laporan keuangan, semua biaya itu kan ditotalkan. Sehingga efek dari perbaikan proses itu tidak signifikan sebab relatif terhadap total seluruh biaya. Di sinilah kita perlu hati-hati dalam menentukan indikator. Jika berdasarkan reduksi biaya, maka harus ada pengukuran biaya yang terpisah.

2. Profit adalah Opini

Anda mungkin sudah pernah dengar ungkapan “Omset adalah Kesombongan, Profit adalah Kesenangan, Kas adalah Kenyataan”. Laporan Laba-Rugi adalah salah satu instrumen dalam melakukan kontrol dan perbaikan. Namun kita harus hati-hati sebab, untung atau rugi adalah sebuah opini, belum tentu menggambarkan keadaan sebenarnya. Apakah kita bisa mengukur pekerjaan perbaikan proses itu berdasarkan opini? Bisa saja, tapi tidak valid 100%.

Selain itu motifasi yang dilandasi oleh profit atau penghasilan itu sangat berbahaya pengaruhnya dalam kontinuitas. Sebab, jika Anda tidak memperoleh profit yang diharapkan, besar kemungkinan Anda tidak akan melanjutkan proses perbaikan. Sama seperti karyawan yang mengharapkan bonus atau kenaikan gaji, jika tidak ada bonus atau tidak ada kenaikan gaji, maka besar kemungkinan proses perbaikan berhenti. Padahal perbaikan proses itu kegiatan yang butuh kontinuitas, harus dikerjakan terus-menerus.

Kalau motifasi kita hanya profit, buat apa capek-capek melakukan perbaikan, toh profit/penghasilan kita segitu-gitu aja? Hati-hati, jika Anda mengharapkan profit besar kemungkinan Anda mudah kecewa dan hilang semangat. :p

3. Bottleneck

Di setiap proses yang membutuhkan lintas grup, lintas departemen, lintas organisasi, lintas perusahaan, maka di situlah ada bottleneck. Ada kemacetan proses. Jika output dari proses di pihak A harus diproses lebih dulu di pihak B, ada peluang terjadinya kemacetan proses antara dua proses tersebut.

A dan B belum tentu punya kesamaan kecepatan. Jika A mengalami kemacetan, maka B ikut menderita kemacetan proses akibat kurang input dari A. Jika kita mengukur kinerja B, hati-hati sebab akar masalahnya ada di A. Contoh, orang sales menderita penurunan penjualan akibat macetnya proses produksi atau software development.

A dan B belum tentu punya kesamaan kualitas. Jika A menghasilkan output berkualitas rendah, maka B menderita penurunan kualitas akibat buruknya kualitas input dari A. Jika kita mengukur kualitas produk B, bisa jadi kurang relevan sebab akar masalahnya dari A. Contoh, bagian technical support menderita banyak komplain akibat software tidak stabil atau banyak bug.

Hati-hati, jika proses yang kita ukur banyak melewati intersection atau lintas organisasi, biasanya ditemukan bottleneck atau kemacetan proses.

Pentingnya Niat yang Benar

Pesan moral yang ingin saya sampaikan adalah pentingnya punya niat yang benar dalam melakukan perbaikan proses. Tujuan utama dari perbaikan proses adalah menghasilkan produk yang superior dengan effort yang lebih ringan.

Jika motifasi kita semata-mata untuk mengejar omset atau profit, atau kenaikan gaji, besar kemungkinan kita akan kecewa. Sebab ada jarak yang membentang antara kualitas dan profit. Jika kita tidak mendapatkan profit yang diharapkan, besar kemungkinan kita akan berhenti melakukan perbaikan.

Nabi Muhammad pernah berpesan: Luruskan Niat Anda!

Semoga bermanfaat dan Salam Perbaikan!

Sumber gambar: http://business901.com/six-sigma-marketing/storyboards/

Automasi Proses Bisnis Administrasi di Sandiloka

Automasi Proses Bisnis Administrasi di Sandiloka

Automasi Proses Bisnis Administrasi di Sandiloka

Salah satu tugas saya di Sandiloka adalah memperbaiki seluruh proses bisnis yang kami jalankan. Bagian Administrasi & Keuangan adalah bagian yang selama 3 tahun terakhir ini paling banyak proses manualnya seperti pembuatan invoice, pengiriman invoice lewat email, menerima konfirmasi pembayaran, melakukan validasi pembayaran, memproses pembayaran, mencatat dalam pembukuan, menerbitkan voucher penerimaan & pengeluaran, menyetorkan dana ke bank, menarik dana dari bank, mentransfer dana lewat internet banking, menerbitkan lisensi, melakukan provisioning smartcard, mengirim paket, dan masih banyak proses yang tidak bisa disebutkan di sini.

Proses-proses tersebut memang mudah dikerjakan dan kami cukup menggunakan Microsoft Excel, Microsoft Word dan browser. Namun karena jumlahnya banyak (ratusan item) tentu perlu ketelitian yang tinggi. Tapi perlu diingat bahwa tidak semua orang punya ketelitian yang tinggi. Tidak selamanya orang bisa teliti 100% setiap saat. Ada kalanya orang salah tulis, salah ketik, salah input, salah baca, dan semua jenis kesalahan manusiawi lainnya. Di sinilah pentingnya automasi proses (jidoka) untuk menekan kesalahan proses (defect) dan resiko yang ditimbulkan.

Selain itu manusia juga harus istirahat. Jika tidak istirahat, ketelitian justru menurun dan tingkat kesalahan proses makin tinggi. Oleh sebab itu Sabtu-Minggu wajib libur. Tapi ternyata mitra-mitra kami banyak yang tidak libur pada hari Sabtu-Minggu. Seringkali terjadi tiap bulan, ada customer yang lisensinya jatuh tempo pada hari Sabtu/Minggu atau hari libur nasional. Karena libur akhirnya tidak bisa dilayani sampai hari Senin atau hari kerja selanjutnya.

Memang jumlah customer seperti ini tidak banyak. Hanya satu atau dua saja. Tapi sangat mengganggu sebab mereka biasanya akan menelepon, sms atau bbm saya di waktu yang sangat tidak tepat, yaitu pada saat saya sedang tidur, sedang ada acara keluarga, sedang olahraga, sedang dirawat di rumah sakit, sedang dalam perjalanan, bahkan ketika saya sedang akad nikah pada 1 Desember 2012 yang lalu.

Bayangkan saja, waktu saya sedang menunggu proses akad nikah dimulai di Cirebon. Sudah dandan rapi, dan rombongan sudah berbaris di belakang. Lalu salah satu customer di Makassar menghubungi saya via BBM mau bayar lisensi karena sudah lewat jatuh tempo. Customer yang satu ini memang tergolong ‘istimewa’, sebab semua tagihannya dibayar setelah lewat jatuh tempo. Tidak ada yang tepat waktu apalagi lebih awal. Termasuk dalam kelompok Slow-Payer. Mungkin dia saking sibuknya atau ada penyebab lain sehingga email invoice tidak ditanggapi, telepon tidak diangkat, sms tidak direspon. Pas lewat jatuh tempo baru teriak-teriak. Waktu itu ingin rasanya saya sudahi saja hubungan bisnisnya sebab tidak mampu menjalankan kewajibannya dengan baik.

Pada saat lebaran idul fitri, saya pernah mentolerir keterlambatan lisensi ini. Rupanya itu tidak memperbaiki perilaku mereka, malah menjadi excuse. Jadi saya pikir lagi, buat apa pusing? Toh kita sudah menjalankan kewajiban kita sampai maksimal. Invoice sudah dikirim tepat waktu. Ada reminder sampai 3x. Jika mereka tidak mau merespon, buat apa kita repot-repot memberikan toleransi? Handphone saya titipkan ke adik saya, blackberry saya non-aktifkan. Akad nikah saya harus berjalan dengan lancar.

Mengapa tidak tambah karyawan dengan sistem shift?

Pertama, merekrut karyawan baru dan melakukan seleksi butuh waktu 1-2 bulan. Sudah direkrut belum tentu bisa langsung lancar, perlu ditraining. Masa percobaannya 3 bulan. Kalau lulus, kontraknya dilanjutkan. Kalau tidak lulus, saya perlu cari dan seleksi lagi. Kedua, penambahan karyawan tidak selalu menghasilkan penambahan prodiktifitas. Saya sudah banyak melakukan kesalahan rekrut karyawan di mana hasilnya bukan penambahan produktifitas, tapi justru penurunan produktifitas.

Sebetulnya rencana untuk automasi proses bisnis administrasi ini sudah ada sejak Januari 2011. Tapi karena kami terlalu sibuk membuat fitur untuk para mitra pengguna Voucha, akhirnya pekerjaan tersebut terlantar. Baru pada bulan November 2012, saya ada waktu untuk berpikir dan melakukan langkah-langkah perbaikan. Dimulai dengan menyewa dedicated server khusus dan membeli lisensi software billing.

Mengapa beli, bukannya bisa bikin sendiri?

Alasannya simpel saja, biaya dan waktunya tidak sepadan. Jika saya buat sendiri, saya perkirakan butuh 6 bulan dengan biaya di atas 75 juta. Tapi kalau saya beli, cukup bayar sekitar USD 600. Selain itu saya orangnya tidak suka membuat ulang roda (reinvent the wheel), saya lebih suka memakai yang sudah ada sampai maksimal. Jadi pilihan ini best values for money.

Setelah server billing kami beroperasi, tidak langsung bisa dioperasikan. Saya butuh waktu untuk mempelajari dan membuat modul-modul tambahannya. Setelah 3 bulan, barulah saya paham apa yang paling dibutuhkan dan bagaimana cara membuatnya. Bagian ini perlu kemampuan programming.

Satu persatu, proses bisnis administrasi ini diautomasi. Pertama proses invoicingnya, lalu proses provisioning, suspend, renewal, sampai terminasi. Sekarang sudah masuk ke automasi proses validasi pembayaran. Sehingga idealnya, semua pembayaran bisa langsung diproses tanpa diperiksa manual oleh admin. Dengan begitu, pembayaran yang dilakukan pada hari Sabtu-Minggu atau hari libur bisa diproses otomatis juga.

Hasil yang diharapkan dari ‘proyek’ ini adalah berkurangnya aktifitas/kesibukan yang tidak memberi nilai tambah, terutama yang rutin. Biasanya 80% dari seluruh proses itu sudah rutin dan bisa diautomasi. Sisanya 20% masih perlu campur tangan dan kontrol manusia. Dari efisiensi proses yang ditimbulkan, tentu saja akan semakin banyak pekerjaan yang bisa diselesaikan dengan biaya yang sama, bahkan bisa lebih sedikit. Inilah yang kami sebut dengan peningkatan produktifitas dengan menerapkan teknologi informasi.

Saya bersyukur dikaruniai Allah kemampuan programming, membuat model dari sebuah masalah, memetakan seluruh proses bisnis, sampai melakukan rekayasa prosesnya. Dengan karunia tersebut, saya bisa menciptakan manfaat yang lebih besar untuk mempermudah pekerjaan orang.

Prinsip yang saya terapkan cuma satu yaitu U-S-A (Understand, Simplify, Automate). Kita hanya bisa melakukan automasi jika kita memahami prosesnya dan bisa membuatnya jadi lebih sederhana. Bukan jadi lebih rumit. Untuk memahami prosesnya, ya prosesnya harus sudah ada. Kita tidak bisa melakukan automasi kepada proses yang belum ada atau masih ghoib.

“You can’t automate process which doesn’t exists” (Bill Gates)

Semoga bermanfaat dan menginspirasi.