Asset Management Improvement Project Part 1

Few days ago, my co-worker telling me that our Director assign him to improving ways of work in branch's logistic and warehouse. Actually, the scope of this assignment is in my area, everything that related to workflow process in branch always comes from my department, the Field Operation & Standardization (FOS) department. So, the assignment transferred to me provided with general requirement. The request is very simple, just make the branch's warehousing area more comfortable to manage, because our customer's asset is there.

Before I tell you more how to plan and achieve this assignment, I'll give you brief explanation about what we means by asset and what is the problem there that makes we need to improve ways of work in branch logistic area. The asset itself is a EDCs, a transactional draft capturing machine. This machine works with magnetic tape that we called credit or debit card issued by bank. Merchants that using EDC just set the nominal purchase by customer in that machine, then inserting customer's credit or debit card, and voila! Customer bank account will be debited as much as nominal of purchasing that has been set by merchant (as much as the good's price, of course)

If our customer (bank, of course) giving EDC Installation order to us, they will send an EDC and its Job Order (contains information where the machine will be installed, due date, etc.) The EDC must stay at our logistic area first, and then will be issued a day before installation’s due date to the merchant. As well as EDC Withdrawal order, the bank just issued Withdrawal Job Order to us, and our technician will go to the merchant as Job Order stated, to take the EDCs from merchant and cutting off connectivity.

EDC Machine

In field operation, installation or withdrawal activity isn't simple as stated above. In our SOP, installation or withdrawal only can be done if merchant’s condition fulfill our SOP Terms and Condition (TC). The terms of installation job is like active phone line, merchant’s name and address is valid (same precisely with jobs order issued by Bank), etc. If Terms and Condition not apply by merchant, our engineer just set job status to pending. The machine will stay at branch’s logistic until job order is re-assigned. The problem arise when the TC-not-comply trend is growing up, logistic area become full with EDC and we need to sort EDC by its age. The old one MUST be forward to Bank’s Logistic because the follow-up respond is timed up. And we don’t have responsibility to manage it anymore.

After we know what kind of machine that we will manage and what the problems there, I set a team of two from my subordinate. Experiencing in leading team, I focused on what kind of personality that can handle this type of project. The team lead for this project assigned to Mr. Budi, he is a senior employee that formerly coordinating area in Jakarta area. The reason is simply, he has high respect from all field operational member in Jakarta that can be used to ease our project implemented in each branch. Besides that, Mr. Budi is compliance person and always obeying any standard that had been agreed by management. He experienced handling resistance issues that always rise when new ways of work being piloting (a thing that I MUST still learn more to him). Mr. Budi will assist by Dendy, a newly hired employee in my team. There are some reason I involve Dendy in this project, he have good logical-brain (A must HAVE ability in team that I recruit, especially when I directing a workflow process for each project), He also well-know about this asset much, because I assign him in other project as a supporting staff that handling branch office’s EDC database and its sub process. So, the composition for the team is: Mr. Budi as instructor and lead our member in branch, and Dendy as conceptor that must well-detail-explained why this improvement must be held in office's branch across Indonesia to each branch leader.

After we set the team to hold this project, we're going to create goal and its mission statement. My role here is to directing the Team to our goals and creating project concepts to meet the goals. The main goal of this project (as I state above) is to manage customer asset easily in Branch's Logistic Area. I break the goal into some mission statement that must be accomplished by me and my Team.

Usually, I try to make the mission statement with what-I-called Milestone Table. Milestone table contains: what will we do? When we do it? Who will do it? (I mean, who's have higher responsibility to doing it well), and when you show it off?

For this project, I invited my teams to attend kickoff and brainstorming meeting. Brainstorming meeting is very very very required. You can share our goal there, share your concept and let others to giving opinion and feedback, discuss and comparing the old ways and the new ways, (with each pros and cons table), at the end, you'll find better solution and its alternatives. At next paragraph I will tell you much about how my team accomplish the goals.

Comparation Old Concept and New Concept (Brainstorming Meeting, Omega Room, June 8 2015)

I'll tell you a little about our previous Branch's Asset Management. This previous project is one of my standardization improvement about 2 years ago. At that time, everything not so crowded like now, so our approach to handle that machine will be slightly different from now on. Want to know interesting thing about this change? Please wait for my second post J

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.

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 ☺

How to Analyze and Improve Flow Process

Di tempat kerja saat ini, saya banyak bersinggungan dengan Improvement Proses Kerja. Oleh sebab itu tools yang paling banyak saya gunakan adalah analysis tools, semacam Excel dan aplikasi spreadsheet lainnya. Lho? Kenapa malah ke Excel? Karena setiap improvement harus dibuatkan perhitungan cost-benefit sebelum dan sesudah improvement dilakukan. Setelah perhitungannya matang, barulah kami menerbitkan proposal perbaikan flow proses menggunakan tools Visio. Terkadang saya juga menggunakan Ms. Project bilamana unsur yang dihitung adalah leadtime, Ms. Project dapat dengan mudah mengidentifikasi berapa waktu/cost yang bisa dihemat dengan penerapan proses baru. Saya tidak tahu istilah pasti untuk pendekatan yang saya gunakan ini, Karena secara umum orang-orang biasanya menggunakan Ms. Project untuk me-manage project (baik one-time ataupun recurring), namun saya melihat adanya kesamaan flow Proses Kerja dengan Project, jadi tidak ada salahnya memanfaatkan Ms. Project untuk menganalisa apakah flow yang di propose lebih efektif-efisien atau tidak.

Kali ini saya kan share mengenai teknik yang biasa saya gunakan dalam analisa proses kerja, beserta contoh flow kerja yang pernah saya kerjakan. Flow yang saya share disini sifatnya masih sederhana dan umum, hanya saja ada sedikit “kerikil” yang harus kita singkirkan agar prosesnya lebih cepat dan efisien.

CASE 1

Tim X adalah tim yang ditugaskan khusus untuk menangani device yang rusak. Tim ini berkoordinasi langsung dengan Vendor Perbaikan(eksternal), Tim Purchasing(internal), dan Bagian Finance/Accounting(internal). Issue yang diblow up adalah proses penanganan device yang rusak sangat lama sehingga perusahaan terkadang melakukan pembelian baru terhadap device yang sama untuk cover kegiatan operasional. Target improvement kali ini adalah bagaimana agar proses penanganan device yang rusak ini dapat lebih cepat dari sebelumnya.

Step 1 – Collect Data and Information

1. Buat alur proses yang saat ini berjalan, konfirmasikan dengan PIC (Head di Tim X) bahwa proses ini valid
2. Lakukan wawancara singkat di Tim X untuk mencari titik yang membuat kemacetan ini terjadi. Ada dua kemungkinan sumber kemacetan, dari Tim X sendiri, atau dari tim lain (misal proses di Vendor, atau proses pencairan di Finance)
3. Collect data-data yang diperlukan. Contoh untuk case ini karena yang ingin kita ketahui adalah leadtime yang lama, maka data yang relevan adalah kapan device rusak diterima, berapa lama device tersebut di inspect di internal, kapan device tersebut dikirim ke Vendor Perbaikan, aging di Vendor Perbaikan, leadtime kurir dari Vendor Perbaikan ke gudang Tim X dan sebagainya. Ambil juga data lainnya misal Ongkos Perbaikan (mungkin akan dibutuhkan)
4. Pastikan data-data diatas ADA di Tim X, jika tidak ada, cukup laporkan temuan ini ke Tim Compliance/ Audit. Tugas anda selesai sampai disini. Namun jika semua/ sebagian besar data tersebut tersedia, bahasan dapat kita lanjutkan. Action pelaporan diatas sebenarnya bukan dari SOP perusahaan saya, saya hanya berinisiatif melaporkan temuan tersebut akan dapat diperbaiki ke depannya oleh tim Quality, karena hal ini terkait dengan Sertifikasi ISO 9001 yang kami miliki. Jika anda pernah baca sekilas beberapa klausul di 9001, anda akan mengerti maksud saya.
5. Jika dalam flow tersebut ada intervensi Tim internal lain (misalkan dalam case ini, Tim Finance), wawancara juga PIC di Tim Finance yang berinteraksi langsung dengan Tim X. Informasi yang diajukan juga seputar leadtime, misal berapa lama pengajuan PR sampai dananya ditransfer dsb.

Step 2 – Begin Analysis

1. Treat alur proses yang dibuat pada poin A Step 1 sebagai sebuah Project. Kenapa? Project punya milestones dan predecessor activity, demikian juga dengan flow proses tersebut. Tentukan milestones dan predecessor dari setiap proses yang dilakukan. Milestones adalah tahapan yang harus dicapai, contohnya setelah device rusak di cek oleh Tim X, maka Tim X akan putuskan device dapat diperbaiki internal atau external, keputusan itu adalah salah satu Milestones-nya. Predecessor adalah satu aktifitas yang hasilnya menentukan kegiatan selanjutnya. Contoh predecessor dalam case ini: aktifitas pengiriman device yang telah baik ke Vendor akan dilakukan BILA pembayaran telah lunas dilakukan—maka yang menjadi predecessor activity disini adalah Pembayaran Telah Lunas dilakukan agar aktifitas pengiriman device yang bagus bisa dijalankan. Buat alur-alur tersebut ke dalam Model Visio kemudian mulailah berpikir bagaimana proses ini dapat berlangsung cepat tanpa ada banyak predecessor/ dapat berjalan paralel. Maka jadilah flow current proses seperti dibawah

Lalu dari hasil analisa di Ms. Project untuk flow kerja yang digunakan saat ini, akan dibutuhkan waktu berkisar 33 hari mulai dari device dikirim ke Vendor Perbaikan sampai device diterima kembali oleh Tim X. Kerugian waktu yang sangat lama bila dikaitkan dengan potential income dari Tim Operation yang hilang karena hal ini. Berikut screenshot Ms. Project-nya

Sebelum memikirkan improvement apa yang bisa kita implementasikan untuk flow ini, hal yang saya pikirkan pertama kali adalah sbb :

1. Apakah ada kegiatan yang diluar kuasa? Misalnya dalam case ini, kita tidak dapat menentukan berapa lama device yang sudah dikirim tersebut akan berada di Vendor sampai bagus kembali. Dari hasil wawancara saya juga dapatkan bahwa Vendor tidak mau membuatkan RFP yang dibutuhkan Tim Purchasing untuk pencairan dana. Kita harus putar otak bagaimana dana perbaikan dapat cair, tanpa memberikan RFP dengan ketentuan TIDAK MELANGGAR KEBIJAKAN/ ATURAN PERUSAHAAN.
2. Apakah ada kebijakan terkait yang bisa dijadikan landasan dalam perubahan proses kerja? Kebijakan yang mesti di analisa tidak hanya kebijakan yang ada di Tim X, melainkan juga di Tim lainnya, semisal kebijakan di Accounting mengenai pencairan dana, dokumen pelengkap apa yang dibutuhkan dsb-nya. Dari hasil analisa ini saya temukan bahwa tim Accounting approve model pembayaran Advance bila ada dokumen Invoice dari Vendor, mungkin dengan begini kita tidak butuh RFP dari Vendor. Bisa saja kita mintakan invoice saja atas layanan perbaikan yang vendor berikan tapi dengan syarat, Layanan Perbaikan Telah Lunas dibayar ke Vendor.
3. Adakah proses kemungkinan proses seri diatas dilakukan secara parallel? (optional, disesuaikan dengan situasi dan kondisi problem)

Step 3 – Think

1. Pada step ini tidak ada teknik yang dapat saya jabarkan. Advice yang dapat saya berikan adalah, berikan solusi yang S.M.A.R.T
1. S – Specific : solusi yang diberikan harus spesifik, pada kasus ini solusi-nya pasti tidak jauh dari leadtime yang harus di-reduce
2. M – Measurable : solusi tersebut harus dapat diukur kriteria suksesnya. Misalkan kriteria suksesnya: bila current proses membutuhkan 33 hari, maka dengan improvement flow ini dapat device dapat yang rusak dapat kembali ke Tim X dalam 6-8 hari.
3. A – Achievable : solusi tersebut dapat dicapai dan realistis. Maksudnya solusi tersebut haruslah nyata bisa diimplementasikan. Contoh ekstrim untuk solusi yang tidak realistis misalnya, percepatan perbaikan device dapat dilakukan lebih cepat jika Tim X menyandera anak Direktur perusahaan Vendor Perbaikan.

Solusi yang akan saya jabarkan dibawah membutuhkan hitungan cost-benefit yang menjadi landasan dalam pengambilan Go or No Go –nya solusi ini. Hal-hal seperti potential loss, potential income yang dipengarahui oleh leadtime perbaikan device yang lama akan sangat berpengaruh disini. Untuk itu, dibutuhkan skill pengolahan data Excel diatas rata-rata untuk melakukannya, disamping kepahaman terhadap proses yang sedang berjalan dan yang akan diusulkan.

4. R – Relevant : solusi ini harus relevant dengan kondisi saat ini, misalnya dengan kebijakan-kebijakan yang berlaku dan berperan besar dalam improvement prosesnya.
5. T – Time-bound : buat batasan mengenai kapan solusi ini akan diimplementasikan.
4. Biasanya dalam penentuan solusi, selain olah-olah data yang ada, ajak juga rekan sejawat sebagai reviewer untuk mendapat pandangan luar terhadap solusi yang diajukan. Biasanya saya pribadi menganggap solusi yang saya usulkan adalah yang terbaik, namun setelah di review, ada saja beberapa bagian yang terlewat saya masukkan dalam faktor penentuan solusi. Oleh karena itu peer review sangat penting disini.

Step 4 – Present Solution

AKhirnya sampai pada tahap solusi yang diajukan untuk percepatan perbaikan device tersebut. Solusi yang diajukan sederhana, tidak melanggar kebijakan/ ketentuan yang ada. Apa solusi yang diberikan untuk case ini? Nantikan post saya selanjutnya…