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 ☺

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…

Excel Pivot Table

Pivot Table/Chart merupakan fungsi dasar yang harus dimiliki oleh orang yang berkecimpung dalam analisa data. Fungsi ini dapat dengan mudah mengeluarkan ringkasan (summary) terhadap data yang sedang diolah.

Analogikan Anda mempunyai sekumpulan data mengenai hasil kerja engineer ATM. Data hasil kerja tersebut berisi setidaknya 8 Field dengan contoh field saya gambarkan sebagai berikut :

ATM_ID	Branch_Name	Location	Bank_Name	Hardware Condition	Software Status	Software Version	EngineerID
812818	Hypermart Cawang	Jakarta	BCA	Good	OK	v12.2	T1221
243636	Hypermart Cawang	Jakarta	Mandiri	Good	OK	v12.2	T1221
346363	Hypermart Cawang	Jakarta	BNI	Good	OK	v12.2	T1221
346363	Stasiun Cawang	Jakarta	BNI	Good	OK	v12.2	T1221
333633	RS. Bhakti Husada	Depok	BRI	Damage	Crash	v12.2	T1352
857945	Giant Cimanggis	Depok	BRI	Good	OK	v12.2	T1352
362315	Giant Cimanggis	Depok	Mandiri	Good	Crash	v12.2	T2982

Anda  ditugaskan membuat summary mengenai :

1. Jumlah ATM dengan kondisi hardware rusak
2. Jumlah ATM yang ditangani oleh masing-masing Engineer

Tanpa bantuan Pivot, mungkin anda akan melakukan rekap manual menggunakan fungsi Filter, membuat table baru untuk menyimpan masing-masing nilai, kemudian membuatkan diagram/chart-nya. Tentu hal diatas akan mengorbankan produktifitas. Oleh sebab itu, saya akan mengajarkan anda menggunakan fungsi Pivot Tablet agar pekerjan tersebut dapat lebih cepat dan lebih mudah.

1. Blok keseluruhan data

2. Klik Tab Insert, lalu Klik Tombol Pivot Table

3. Pada isian create Pivot Table, abaikan pilihan yang diberikan. Pivot table akan di generate pada Sheet baru. Jika anda ingin mengubah lokasi sheet pivot table yang akan dibuat, Pilih opsi Existing Worksheet kemudian pilih Locationnya dengan menempatkan cursor pada sheet yang diinginkan. Jika selesai, klik OK

4. Excel akan menampilkan Pivot Table Field yang merupakan relevansi data yang diblok di langkah sebelumnya (langkah 1). Pivot Table Field ini ada di bagian kanan Excel.

5. Sekarang kita kembali ke objective kita sebelumnya, yaitu :
1. Jumlah ATM dengan kondisi hardware rusak

Karena objektif disini adalah hardware yang rusak , maka Drag field Hardware_Condition ke Columns di Pivot Table Field. Lalu untuk menampilkan jumlah ATM-nya, drag field ATM_ID ke Report. *Jangan lupa set satuan pada Values menjadi Count, dengan mengeklik tanda panah kecil di Field ATM_ID, pilih Value Field Setting, kemudian pilih Count

Hasilnya adalah sebagai berikut:

Dari Summary tersebut dapat dilihat bahwa ada 1 ATM yang rusak. Anda dapat bereksperimen lebih jauh dengan data tersebut. Coba drag Field Bank_Name ke area ROWS di Pivot Table Field. Summary apa yang dapat anda temukan dari data yang ditampilkan? ☺

2. Jumlah ATM yang ditangani oleh masing-masing Engineer

Buatlah pivot table baru mengikuti langkah 1-5 diatas. Drag ATM_ID ke field Values, kemudian drag field Engineer ke field ROWS, maka summary ATM yang dihandle oleh masing-masing Engineer akan ditampilkan.

Selanjutnya, selamat bereksperimen dengan Excel :)