Creating Business Process for A Business Opportunity

Creating Business Process for A Business Opportunity

Saya gemar mempermainkan data. Kantor tempat saya bekerja saat ini bisa generate ratusan ribu baris data setiap bulan yang diolah menjadi bermacam laporan sesuai kebutuhan, benar-benar sebuah resource yang komplit untuk menarik informasi-informasi berharga yang sulit terlihat bila user tidak memahami bisnis proses dibalik semua data yang ter-generate tersebut.

Karena sering bermain dengan hal ini, saya sempat memikirkan suatu konsep yang mungkin sudah sebelumnya (atau bahkan belum ada) mengenai apa yang saya sendiri namai dengan Data Mutualism.

Konsep dasar dari Data Mutualism ini adalah setiap baris data yang di modify oleh pemilik data, akan selalu termanfaatkan dan sepenuhnya memberikan benefit kepada pemilik data maupun orang luar yang diberi akses melihat baris data tersebut (view only)

Ilustrasi dibawah akan menjelaskan konsep ini secara sederhana :

Penjelasan :

EDP-Application-DB User melakukan pemutakhiran data transaksi dan inventory secara realtime. Imbas dari kegiatan tersebut, EDP-Application-DB User akan mendapatkan dukungan dalam pengambilan keputusan terkait menajemen transaksi, stock, dan inventorynya.

Sementara itu, dengan adanya data yang terupdate, para Data Viewer yang kebetulan membutuhkan data tersebut untuk tujuan lainnya (misalnya pembelian/ order) dapat melakukan query ke Aplikasi dan mengontak Data Owner untuk melakukan transaksi.

Berangkat dari konsep tersebut, saya membangun opportunity yang akan menerapkan konsep tersebut menjadi sebuah proses bisnis dengan dukungan teknologi informasi.

Saya akan memberikan analogi hal diatas sbb:

Anggaplah Anda seorang pemilik apotik ABC yang dikelola oleh Anda sendiri, apotik ini belum memiliki cabang dimanapun. Anda mungkin belum memiliki Sistem Inventory Management yang baik, setiap obat yang terjual tidak anda catat berapa sisa stocknya, sehingga menyulitkan anda ketika akan re-order, karena harus stock opname dan update pencatatan, baru kemudian mempersiapkan list order ke Distributor.

Kemudian anda menyadari bahwa Manajemen Inventory merupakan hal yang mutlak Anda harus miliki, mungkin software database seperti untuk mencatat dan mengelola data inventory bisa anda dapatkan dengan harga <100 ribu di pasaran—dengan berbagai keterbatasan tentunya. Anda dengan rutin mencatat setiap pembelian di apotik ABC menggunakan software database tersebut. Pekerjaan anda sekarang lebih ringan, data pembelian dan re-order stock dapat dilakukan kurang dari 10 menit. Namun, sadarkah anda bahwa dari data-data yang anda input tersebut sebenarnya tersimpan informasi yang lebih dari sekedar berapa-banyak-stock-yang-berada-di-reorderPoint? Misalnya :

1. Fitur yang dapat menampilkan daftar item yang paling banyak dibeli orang di setiap hari, minggu atau bulannya dari apotik Anda? Sehingga anda dapat dengan mudah mengalokasikan modal anda untuk order item dengan arus jual-beli yang tinggi saja
2. Fitur yang dapat menunjukkan kepada Anda kapan anda harus mengejar target penjualan dan bagaimana diskon-diskon diberikan untuk item yang akan kadaluarsa (walaupun realnya di pemberian diskon yang besar di produk medis tidak akan serta merta mendongkrak penjualan :D )

itu hanya beberapa contoh yang dapat saya paparkan, semua jenis informasi yang dapat kita tarik tergantung dari apa dan selengkap apa data yang kita miliki.

Kembali ke topik yang Data Mutualism yang ingin saya sampaikan, saya coba gambarkan flow sederhana untuk hal ini.

Dari model diatas dapat disimpulkan bahwa, update yang dilakukan oleh owner data, selain dapat memberikan informasi internal bagi pemilik data, secara tak langsung juga membukan kesempatan bagi potential buyer untuk melakukan transaksi dengan pemilik data. Semakin data tersebut terupdate, maka informasi yang dimiliki owner terhadap keputusan dan action yang akan diambil selanjutnya akan semakin matang. Disamping itu, data yang terupdate tersebut akan dilihat oleh potential user dan juga memberikan kemungkinan yang besar bagi si potential user untuk melakukan transaksi pembelian kepada pemilik data (pemilik apotik).

Analogi lainnya :

Apotik X menggunakan Sistem M (proposed inventory system) untuk mengelola inventory-nya. Setiap ada perubahan dalam stock--baik itu terjadi penjualan/ re-stock--selalu dientry oleh Apotik X ke Sistem M, sehingga data inventory Apotik X yang terdapat pada database Sistem M selalu up-to-date.

Sistem M itu sendiri, selain menyedikan fitur inventory, juga mempunyai fitur query yang dikhususkan bagi pengguna mobile device, anggap namanya adalah Aplikasi X. User yang terdaftar di aplikasi X dapat melihat informasi obat di apotik yang menyimpan datanya di database Sistem M. Tentu saja definisi melihat yang saya maksudkan disini dibatasi hanya pada query yang diinginkan user Aplikasi X saja. Aplikasi X juga dapat memberikan komparasi harga antar Apotik, jarak dari user Aplikasi X ke Apotik terdekat yang menyedikan item yang dibutuhkan oleh user dsb. Karena perbandingan harga, ketersediaan stock dan rating yang tinggi terhadap Apotik X terekam dengan baik di database Sistem M, maka user memutuskan akan mengontak pemilik Apotik X untuk melakukan transaksi jual-beli sesuai kebutuhan user Aplikasi X.

Ide ini sangat sederhana. Ide ini memberikan pandangan bahwa, satu hal yang bagus diterapkan untuk kebaikan kita, pasti akan berguna juga bagi orang lain.

Sistem M yang saya kemukakan lewat beberapa cerita dan analogi diatas mempunyai beberapa benefit sbb :

Bagi Data Owner (Sistem M User)	Bagi Application User (Application X User)
Memberi insight terhadap kondisi inventory Memberi dukungan pengambilan keputusan terhadap kondisi inventory Membuka peluang transaksi yang lebih banyak dan lebih terbuka bagi pelanggan	Memberi jalan keluar yang paling efisien dan efektif untuk mendapatkan item yang diinginkan, antara lain dengan adanya info komparasi harga, jarak dan rating

The System Itself

Sebelumnya saya sudah sharing mengenai hal ini kepada beberapa rekan sejawat. Hal yang kami bahas disini memang lebih kepada teknikal. Kebanyakan dari mereka berpendapat bahwa paparan yang saya sebutkan dapat dibuat dengan sistem sederhana saja dan memang inilah yang saya tuju. saya tidak ingin ide yang sederhana ini seketika menjadi rumit ketika mulai berinteraksi dengan hal-hal teknis. Keep simple, as far as you can. Mungkin ulasan mengenai teknisnya, mulai dari analisa perancangan sistem dan aplikasi mobilenya akan saya berikan di tulisan selanjutnya, karena saya lebih tertarik membahas mengenai proses kerja, integrasi antar data, dan pendekatan bisnis untuk mengembangkan sistem ini. Detail Flow Processnya akan dijabarkan di tulisan berikutnya.

The Market and Business Opportunity

Pangsa pasar yang saya tuju untuk penggunaan sistem ini adalah spesifik jenis merchant yang mempunyai struktur item yang solid. maksud solid disini adalah item-item yang ada di inventory merupakan sesuatu yang sejenis. misalnya :

1. Apotik (non Holding/milik perseorangan) -- hanya menjual jenis obat dan alat kesehatan
2. Toko Bangunan -- hanya menjual alat bangunan
3. Petshop -- item lebih definitif;

dan mungkin beberapa model yang struktur datanya lebih dapat diarahkan. Untuk toko kelontong yang varian itemnya bisa jadi sangat luas dan sulit di mapping dalam struktur data, tentunya akan rumit. misalkan saja mie instan sendiri dapat dijual 1 kardus, dan 1 piece. belum lagi ada jika ada penjualan kelapa peras santan dsb :D

Selain itu juga, beberapa daftar yang saya buat diatas masih tergolong UKM, yang memang harus dibantu dan disokong oleh sistem agar mendongkrak penjualan dan keefektifan dalam pengambilan keputusan. Oh ya, perlu saya jelaskan bahwa sistem ini nantinya FREE, namun tentunya dengan melihat batasan yang dimiliki server/database. Tujuan saya hanya ingin menyediakan value yang bermakna bagi pemilik usaha. Yang saya yakini dalam setiap menjalani sebuah aktifitas adalah jika aktifitas tersebut dapat menjadi value bagi orang lain, maka percayalah bahwa materi dan hal-hal lainnya akan mengikut dibelakangnya.

Terus terang saya belum melakukan survey apapun terkait seberapa besar pangsa pasarnya karena terkendala dedikasi saya juga untuk perusahaan saat ini. Namun, bila melihat secara kasar, potensial market untuk ini masih sangat besar sekali, karena apotik-apotik kecil, toko-toko bangunan, menjamur dimana-mana. tinggal ajak mereka untuk sedikit melek IT dan beberkan semua benefit yang dapat mereka ambil bila dapat bekerja menggunakan komputer dan internet (walaupun hal ini sendiri bukan perkara yang mudah)

Sekian paparan singkat yang dapat saya tulis, mungkin ada diantara teman/rekan yang mempunyai visi sama untuk merealisasikan hal ini dapat kontak saya via email. kita bisa diskusi lebih lanjut dan tuangkan apa yang ada dalam pikiran kita untuk membuat Indonesia lebih maju.

BBM : 7B5E640A (invite subj : mutualism)

Mail : gie.posh(at)gmail.com

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..

Part 2: How To Analyze and Improve Flow Process

Tulisan ini adalah sambungan dari tulisan sebelumnya (How To Analyze and Improve Flow Process)

Step 4 – Present Solution

Kembali ke pembahasan beberapa hari lalu yang tertunda. Pertama-tama saya akan jabarkan beberapa kondisi dari Step 1 diatas, karena dengan melihat insight ini, pembaca akan lebih dapat memahami pertimbangan-pertimbangan atas solusi yang akan diambil.

1. Untuk pencairan dana perbaikan device, Tim Purchasing membutuhkan Dokumen Penawaran berupa perkiraan harga kepada Requestor (Tim X), problemnya adalah: Vendor Perbaikan TIDAK PERNAH mau membuat dokumen-dokumen semacam itu, semua komunikasi dan deal harga dilakukan by phone antara Tim X dan Vendor Perbaikan. Satu-satunya bukti valid atas harga perbaikan adalah Invoice dari Vendor yang diterima Tim X bila ongkos perbaikan sudah dibayarkan. Kita melihat ada lingkaran setan disini, yang saling bergantung namun tidak kusut.
2. Ada dua kebutuhan berbeda yaitu, kebutuhan administrasi pencairan dana dan kebutuhan device operasional yang “mungkin” dapat kita jalankan secara terpisah. Dengan kata lain, kita membuat fungsi parallel antara availability fisik device dengan administrasi pembayaran. Bahasa mudahnya begini: Dapatkah Tim X bayar dulu barangnya dengan CASH ke Vendor, kemudian administratif di Finance diurus di belakang setelah invoice kita terima?

The problem is clear, pengurusan administrative finance yang lama dan ketidakmauan Vendor menyediakan Dokumen Penawaran adalah sasaran kita. Agar Direktur Operational yang membawahi Tim X dan Direktur Finance mau menjawab pertanyaan di poin 2 dengan YA, dibutuhkan analisa cost-benefit yang memang benar-benar memberikan gambaran bahwa improvement proses tersebut dapat dijalankan dan menguntungkan.

Saya akan present flow yang akan di propose dengan memberikan big picturenya melalui Visio. Berikut screenshotnya :

Dari flow diatas dapat terlihat bahwa kita membagi 2 kebutuhan dengan membuat 2 proses parallel setelah pembayaran dilakukan. Dengan model seperti ini, Tim X akan lebih cepat men-deliver device yang telah selesai diperbaiki untuk kebutuhan operasional. Sementara untuk kebutuhan administrative akan diurus belakangan oleh Tim X. Dalam analisa dan membuat model seperti ini, saya menggunakan mindset operasional, dimana kebutuhan akan device sangat cepat karena itulah senjata mereka untuk mencapai SLA, Bedakan dengan kebutuhan administrative yang tidak urgent.

Hasil analisa setelah kita lakukan mapping ke Ms. Project adalah sebagai berikut :

Terdapat peningkatan leadtime yang sangat signifikan dalam Flow Availibility Device, yaitu 6 hari! Ini karena kita memisahkan flow penyediaan device dengan flow administrasi, dimana pada proses sebelumnya tidak ada device yang tersedia bila administrasi di Finance belum selesai akan memakan waktu 33 hari hingga device available kembali.

Seperti yang saya singgung sebelumnya, bahwa flow ini membutuhkan buffer yaitu, uang cash sebesar Rp. XXX yang harus dijaga jumlahnya untuk melakukan pembayaran segera jika device selesai diperbaiki oleh Vendor, maka kita juga harus memberikan hitung-hitungan berapa besaran nilai XXX tersebut yang dibutuhkan oleh Tim X. Pembahasan mengenai ini mungkin akan saya share secara terpisah, karena hitung-hitungan cost-benefit sendiri sebenarnya SEDERHANA bila hanya dibayangkan, dan menjadi TIDAK SEDERHANA bila anda mulai menghitungnya ☺..

Mungkin clue-clue berikut dapat membangun pikiran Anda agar lebih masuk di tulisan saya berikutnya mengenai cost-benefit dalam improvement process.

1. Kebutuhan Data dan informasi

1. Berapa rata-rata ongkos perbaikan?
2. Apakah ada jenis-jenis perbaikan? Misalnya service only atau service+penggantian?
3. Berapa rata-rata device yang rusak selama 1 minggu, 1 bulan?
4. Etc (get data selengkap mungkin dengan selalu melihat relevansi)

Sekian rangkaian tulisan ini, dan selamat siang ☺