Part 2: Process Vulnerability Assesment : Commercial Parking Lot Sta. Pondok Cina

Tulisan ini adalah lanjutan post sebelumnya mengenai analisa kelemahan proses bisnis yang ada di Penitipan X (Process Vulnerability Assesment : Commercial Parking Lot Sta. Pondok Cina)

Dalam paparan sebelumnya dijelaskan bahwa pintu masuk parkir hanya ada satu berukuran 1.5m, pintu tersebut juga menjadi pintu keluar sehingga PIC dapat dengan mudah mengontrol keluar masuknya kendaraan dan pengendara. Kita akan sedikit membuat perubahan proses disini, terkait adanya indikasi bottleneck yang jika terjadi pada jam “sibuk” akan membuat kemacetan kecil di sekitaran stasiun. Kenapa dikatakan indikasi? Karena statemen saya diatas memang belum valid sebab belum didukung data-data yang pasti. Untuk kondisi seperti ini, kita dapat menggunakan asumsi—tepatnya asumsi logis/ bisa juga dikatakan hitungan kasar yang make sense—sehingga saya bisa mengeluarkan statement diatas. Mari kita mulai hitung-hitungannya ☺

• Perkiraan luas penitipan adalah 600m2 (20x30m). bagilah area tersebut menjadi 2 besaran, yaitu area okupansi (space yang dihabiskan untuk penempatan kendaraan), dan space non-okupansi(space yang tidak terpakai untuk penempatan kendaraan—misalnya area helm, area selasar, dan area staff).
• Area penitipan helm dan area staff sendiri menghabiskan 10m2, jalan pemisah antar barisan motor ada 5 dengan lebar masing-masing 1 meter. Total area non-okupansi adalah 15m2.
• Sisanya 590m2 akan kita bagi ke 6 barisan motor, dimana 1 baris terdiri dari 2 kendaraan. (lihat gambar)

• Panjang sepeda motor standar(bebek/skuter) rata-rata adalah 1,4m dengan lebar 0.7m. jika dalam 1 baris ada 2 motor maka okupansi baris tsb adalah 1.96m2 untuk 2 motor. Untuk mempermudah 2 motor sebaris tersebut dapat kita sebut bundle saja. Jika kita bagi sisa area okupansi dengan okupansi 1 bundle maka akan didapat 301 bundle dalam 590m2, yang artinya penitipan X dapat menampung maksimal 301x2= 602 kendaraan per hari.
• Rule di penutupan X adalah, Buka Jam 5.00, tutup jam 8.00 pagi karena sudah penuh. Berarti setiap menit pintu tersebut akan dilalui rata-rata 3 kendaraan/min.
• Karena secara real pasti ada peak time(waktu dimana pengendara datang dengan jumlah massive), maka kita set peak timenya adalah 5.30-6.30, dimana 85% (perkiraan) dari kendaraan yang ditampung akan melewati pintu. Jadi hitungannya menjadi berubah yaitu 9 kendaraan/menit atau 1 kendaraan per 7 detik.

1 kendaran tiap 7 detik terdengar sangat mudah di handle, sepertinya ada yang saya lewatkan disini. Oh, kita terlewat menganalisa pengendara yang keluar dari pintu yang sama dan harus mengambil tiket parkir. Sederhananya setiap kendaraan yang masuk pengendaranya akan keluar, oleh sebab itu perhitungan diatas kita kali 2 maka “transaksi” yang terjadi di pintu tersebut menjadi 1 transaksi per 3.5 detik. Transaksi disini maksudnya adalah ada kendaraan masuk atau ada pengendara yang keluar, karena kendaraan yang masuk tidak dapat dibarengi dengan pengendara yang keluar, maka tiap transaksi harus dilakukan secara seri, satu per satu. Hal ini yang menjadi pemicu terjadinya bottleneck pada pintu masuk, karena tiap pengendara yang masuk mau tidak mau harus menunggu 3.5 detik sampai bisa masuk ke area parkir, menunggu pengendara yang sudah selesai parkir menyelesaikan urusannya di dalam dan keluar kembali agar okupansi area kembali menjadi maksimal. Hitungan diatas mungkin akan lebih jelas lagi jika menggunakan Queueing Theory, yang mana akan kelihatan berapa leadtime yang dibutuhkan oleh kendaraan yang mengantri, berapa total waktu yang dibutuhkan sampai motor ke X dapat masuk, dan menjawab pertanyaan yang paling krusial, apakah dengan 1 transaksi/ 3.5 detik tersebut dapat mengakibatkan kemacetan di pintu masuk penitipan. (mungkin hal ini akan kita singgun di lain waktu)

Saran sederhana yang bisa diterapkan disini adalah :

1. Buatkan 1 pintu keluar, yang dibuka hanya untuk pengendara yang ingin keluar/ selesai menitipkan kendaaran. Bagaimana pengadaan pintu keluar tersebut tidak ada menimbulkan operational cost, karena yang kita lakukan hanyalah pengalihan resource yang tadinya stay di satu pintu masuk, sekarang stay di pintu keluar.

Resiko bottleneck dalam paparan diatas dapat lebih diminimalkan, selain itu juga dapat memperbaiki alur penitipan dan pengambilan agar lebih efektif.

2. Mengenai ide awal tidak diperbolehkannya penumpang ikut masuk yang menurut saya sangat tidak feasible, solusiproses ini dapat di perketat dengan melakukan double check pada saat pengambilan yaitu wajib pengecekan STNK. Ada trade off disini yang mau tidak mau harus dilakukan, yaitu mengorbankan kenyamanan dan kemudahan konsumen. Karena apapun yang terkait dengan security pada sebuah proses akan selalu mengorbankan kenyamanan dan kemudahan.

Part 3: How To Analy... (Cost VS Potential Loss Approach)

Postingan ini adalah lanjutan terakhir dari pembahasan How To Analyze and Improve Flow Process Part 1 dan Part 2. silahkan buka kembali link tersebut untuk lebih memahami postingan dibawah.

Mungkin dalam setiap analisa proses bisnis—terutama bila sektor anda adalah swasta—faktor cost dalam setiap improvement merupakan elemen yang tidak boleh dilewatkan. Intinya, benefit yang didapatkan harus lebih besar dari cost yang dikeluarkan, dari margin cost dan benefit tersebut service level dari setiap improvement dapat diukur.

Melanjutkan postingan saya sebelumnya, inilah rangkaian akhir dari analisa dan propose solusi untuk problem yang kita dapati di Tim X (link) yang membahas bagaimana perhitungan cost-benefit dalam setiap improvement. Contoh yang saya berikan disini dibuat sesederhana mungkin untuk menghindari kompleksitas case yang mungkin muncul.

Pendekatan yang saya gunakan adalah Cost VS Potential Loss, dimana dalam hal ini kita akan membandingkan cost yang terpakai untuk menjalankan to-be process (proposed process), dan potential loss yang terjadi bila menggunakan as-is process (current process).

Asumsikan bahwa data-data dan informasi untuk menjawab pertanyaan dibawah telah kita dapatkan dari Tim X.

1. Berapa rata-rata ongkos perbaikan tiap device?
2. Apakah ada jenis-jenis perbaikan? Misalnya service only atau service+penggantian?
3. Berapa rata-rata device yang rusak selama 1 minggu, 1 bulan?

Untuk data dibawah dapat dimintakan dengan Tim terkait yang menangani Operasi Lapangan, misalnya supervisor cabang, coordinator area lapangan dsb. Datanya adalah sbb:

1. Rata-rata jumlah pekerjaan yang menggunakan device selama 1 hari
2. Harga per 1 aktifitas yang menggunakan device yang dimasukkan ke billing

Dari data-data tersebut lakukan pengolahan sederhana, hingga didapatkan summary sebagai berikut :

Table diatas adalah summary jumlah device yang rusak dalam sebulan. Mulai dari November 2013 s/d September 2014. Semakin banyak history data yang dikumpulkan semakin baik, saya biasa menggunakan data 4-5 bulan kebelakang untuk menganalisa history dan habit di tiap proses.

Perlu saya jelaskan bahwa header internal service, service + repair, repair only sebelumnya tidak ada pada raw data yang diberikan oleh Tim X. Di bagian-bagian seperti inilah jam terbang Data Analyst diuji, untuk menggali lebih dalam berlian apa yang terkandung dalam data tersebut. Saya secara sederhana menggunakan asumsi dan sedikit konfirmasi dari Tim X untuk membuat header diatas bernilai valid.

Lebih jelasnya, coba perhatikan dua data pada table berikut :

Terdapat perbedaan sparepart fee yang cukup signifikan antara kedua table. Feeling saya pasti salah satu dari ini adalah ongkos service saja, tanpa penggantian part. Tinggal konfirmasikan dugaan tersebut ke Tim X untuk membuat hipotesa anda valid.

Selanjutnya, buatkan marking pada tiap baris untuk menandakan bahwa baris tersebut termasuk kategori Service Only atau dengan Service+Penggantian Part. Untuk marking dapat gunakan logic berikut di row Excel anda (di sebelah kiri kolom no PR, jika gunakan sample saya) :

IF {sparepart fee} > 75000, THEN “Service+Penggantian Part” ELSE “Service Only”

Bandingkan juga data tersebut dengan data lain yang anda dapatkan, misalnya Tim X dalam wawancara mengatakan bahwa ada perbaikan device yang bisa dilakukan sendiri secara Internal di Tim X sehingga tidak harus dikirim ke Vendor Perbaikan, buatkan juga remarks “Perbaikan di Internal” tersebut dalam data anda, sehingga perhitungan jumlah device yang benar-benar dikirim ke Vendor semakin akurat. Dalam olahan data kali ini saya representasikan header Internal Service adalah perbaikan di internal Tim X (dapat dilihat kembali di table Summary). Setelah selesai rapi-rapi data, create pivot tablenya ☺

Masih dengan sumber data di table yang sama, buatlah hitungan rata-rata biaya perbaikan baik untuk service only ataupun dengan penggantian. Kemudian lakukan kalkulasi sederhana sehingga didapatkan hasil sebagai berikut :

Dari summary diatas didapatkan bahwa dibutuhkan deposit sebesar 13juta sebagai dana cadangan agar to-be process yang dapat menghemat waktu penyediaan device 3 minggu lebih cepat (link) dapat diimplementasikan.. ☺

Kembali ke pendekatan yang saya singgung diatas, selanjutnya kita akan menghitung potential loss bila as-is process masih tetap dijalankan. Mohon lihat sejenak table berikut :

Informasi diatas didapat dari hasil olahan data dari coordinator lapangan yang dicombine dengan rata-rata device unavaible pada hitungan sebelumnya.

• Unavailable device : jumlah device yang tidak dapat digunakan oleh member operasional karena berada di Tim X untuk perbaikan
• Average Activity/day : aktifitas rata-rata yang didapatkan 1 member operasional selama satu hari, yaitu di kisaran 20 aktifitas
• Dengan perkalian dan penjumlahan sederhana akan didapatkan bahwa dalam 1 hari operasional kehilangan kesempatan untuk mencetak rupiah sebanyak 27 juta/days. Jika dikonversi ke jumlah hari kerja selama satu bulan, maka rata-rata jumlah device yang rusak akan mengakibatkan perusahaan kehilangan potential income sebesar 600 juta selama sebulan!

Silahkan bandingkan cost yang dibutuhkan sebesar 13 juta dengan potential loss yang muncul sebanyak 600 juta, jika management bersikeras masih menggunakan proses perbaikan device model terdahulu.. ☺

Dalam perhitungan cost-benefit menggunakan Excel, ada baiknya untuk menguasai beberapa fungsi dan formula yang berlaku di Excel. Fungsi vital yang harus dikuasai adalah VLOOKUP dan Pivot Table (Pivot Tutorial). selain itu juga, asah kemampuan untuk melihat data lebih dalam dengan membaca pola-pola yang ada. kumpulkan semua data yang relevan kemudian buatkan sebuah mindmap untuk mempermudah kita dalam mengeksplorasi data yang ada dan melihat keterhubungannya.

==========

Post ke depan saya akan sedikit cerita mengenai Personal Grooming dalam business process improvement. Insight ini saya dapat ketika berada dalam angkot jurusan Pasar Minggu - Depok, seorang pengamen tiba-tiba masuk dan bernyanyi dan selesai bernyanyi dengan belasan ribu di tangannya. silahkan sabar menunggu cerita menarik ini :)

Process Vulnerability Assesment : Commercial Parking Lot Sta. Pondok Cina

Saya adalah anker. Mungkin para pembaca yang dari Bogor, Depok, Tangerang dan kota satelit lainnya tahu istilah ini. Anker adalah singkatan dari Anak Kereta, semacam sebutan bagi para orang2 yang melakukan perjalanan shuttle menggunakan Commuter Line ke Jakarta untuk bekerja.

Pada tulisan kali ini, saya iseng mau buat paparan singkat mengenai analisa kelemahan bisnis proses di salah satu usaha yang ada di sekitar stasiun. Hasil analisa kecil ini mungkin bisa dijadikan acuan oleh para pemilik bisnis sebagai dasar improvement ke depannya bagi usaha yang mereka jalankan.

Overview

Saya biasa menitipkan kendaraan di penitipan motor sekitaran stasiun Pondok Cina sebelum menyambung perjalanan ke Tangerang menggunakan kereta, kita namai saja tempat tersebut dengan Penitipan X. SOP Operasional yang dijalankan oleh Penitipan X adalah sebagai berikut :

1. Menitipkan Kendaraan
1. Pengendara Masuk ke Area Parkir penitipan X melalui satu-satunya pintu masuk yang dibuka.
2. Pengendara memarkirkan sendiri motornya secara rapi, atau dapat juga memarkirkan di baris yang telah disediakan, nantinya motor-motor tersebut akan dirapikan kembali oleh staf Penitipan X setelah pengendara meninggalkan motornya
3. Pengendara dapat menaruh helm di area yang tersedia, atau tetap menaruh helm di motor
4. Staf Administrasi akan menunggu di pintu masuk tadi kemudian memberikan satu kartu parkir kepada setiap pengendara yang keluar dari area parkir.
5. Proses penitipan kendaraan selesai dan pengendara melanjutkan kegiatan masing-masing
2. Mengambil Kendaraan
1. Pengendara masuk ke area parkir penitipan X
2. Pengendara mencari motornya sendiri, atau meminta bantuan kepada staf penitipan yang ada untuk mencarikan kendaraan yang dimaksud dengan menyebutkan nopol dan jenis kendaraan. Pengendara juga dapat mengambil helm (jika dititipkan)
3. Setelah kendaraan ditemukan, pengendara menuju kearah pintu keluar dengan membawa kendaraan, serta menyiapkan kartu parkir dan biaya penitipan Rp. 4000
4. Staf Penitipan X menerima kartu dan uang dari pengendara, memberi kembalian uang bila ada.
5. Bila pengendara menghilangkan kartu parkir, pengendara akan didenda Rp. 10.000, kemudian staf Penitipan X akan mencatat informasi kendaraan yang tertera di STNK. Bila STNK tidak ada, pengendara yang kehilangan tiket tidak bisa mengeluarkan motor yang dimaksud dari area parkir.

Dalam assessment sederhana kali ini yang menjadi concern saya adalah security issue yang sangat rentan di beberapa poin berikut :

1. Pintu Masuk Parkir

Pintu masuk Penitipan X SAMA dengan pintu keluarnya, hal ini tentu akan mempermudah monitoring oleh staf penitipan untuk mengenali siapa yang masuk dan keluar. Namun, ada beberapa kelemahan yaitu sbb :

1. Tidak terdapat rule mengenai apakah penumpang boleh diikutkan masuk atau tidak di depan pintu Masuk

In case, jika penumpang diperbolehkan masuk maka pada saat pemberian tiket parkir, staf penitipan akan memberikan 2 tiket parkir. 1 tiket dengan motor, dan satu tiket tanpa motor. Note: Asumsikan bahwa jeda keluar area parkir antara si pengendara dan penumpangnya adalah 5 menit, sehingga staf penitipan tidak mengetahui bahwa tiket sudah diberikan ke pengendara yang membawa motor tersebut

2. Ukuran pintu sekitar 1.5 meter dapat mengakibatkan kemacetan pada saat load masuk/keluar tinggi. Load tinggi berkisar pada jam 5.30 sd 8.00, para pengendara akan masuk dengan kendaraan dan keluar membawa satu tiket parkir. Crowd seperti ini akan semakin memperbesar kemungkinan kartu terdistribusi bukan ke pengendara atau mungkin orang yang iseng masuk tanpa kendaraaan.

2. Kartu Parkir

Saya paham bahwa pemberian kartu untuk setiap pengendara adalah salah satu bentuk security concern dari pihak penitipan untuk customernya. Akan tetapi, ada satu hal yang mungkin belum terpikirkan solusi tepatnya oleh pihak pengelola, yaitu SOP Penanganan Kartu yang Hilang. Kita andaikan kartu yang saya pegang terjatuh entah dimana, kartu tersebut kemudian ditemukan oleh seseorang yang niatnya tidak baik. Seseorang tersebut memahami proses pengambilan motor di Penitipan X. Kemudian dengan bermodalkan kunci T dan uang 4000, ia dapat masuk dan leluasa mengambil motor manapun dan keluar dengan aman tanpa dicurigai.

Mungkin beberapa temuan diatas adalah hal-hal kasat mata yang dapat saya lihat. Dengan observasi fullday, bisa jadi ada celah2 kelemahan lainnya yang bisa kita tambal pada bisnis prosesnyang berjalan di Penitipan X.

Next action dalam kerangka perbaikan proses ini, tinggal tentukan apakah akan dilakukan BPR (business process re-engineering) atau Continues Improvement?  BPR akan membuat perubahan total pada SOP dan proses kerja, sementara Continues Improvement lebih kepada peningkatan proses kerja saat ini dengan mengubah/ membelokkan proses-proses yang ada saat ini agar lebih efektif dan waste-free. Menurut saya approach continues improvement lebih cocok diterapkan di SOP ini, karena perubahan yang dilakukan tidak mesti harus fundamental. Lalu, apakah improvement apa yang akan kita terapkan di Penitipan X berdasarkan observasi sederhana diatas? Nantikan tulisan saya selanjutnya dalam merancang model2 solusi pada kerangka Continues Improvement..