COST ENGINEERING

SENI MENGENDALIKAN BIAYA TANPA MENGORBANKAN KUALITAS

Mengapa Perusahaan Tidak Cukup Hanya Meminta Setiap Departemen Mengurangi Pengeluaran?

Dalam dunia bisnis, ada satu instruksi yang sering diberikan manajemen ketika perusahaan menghadapi tekanan biaya: "Kita harus melakukan efisiensi!"

Departemen procurement diminta menegosiasikan harga bahan baku. Produksi diminta mengurangi pemakaian material. Warehouse diminta menekan biaya operasional. Bagian maintenance diminta menghemat suku cadang. Bahkan anggaran perjalanan dinas dan kebutuhan administrasi ikut dipangkas.

Namun, setelah semua penghematan dilakukan, muncul pertanyaan penting:

Apakah biaya perusahaan benar-benar menjadi lebih rendah, atau kita hanya memindahkan biaya dari satu departemen ke departemen lain?

Harga bahan baku mungkin turun, tetapi kualitasnya menurun sehingga produk cacat meningkat. Biaya maintenance berhasil ditekan, tetapi mesin lebih sering mengalami kerusakan. Jumlah tenaga kerja dikurangi, tetapi lembur meningkat. Biaya transportasi turun, tetapi pengiriman terlambat dan pelanggan kecewa.

Secara administratif, perusahaan terlihat melakukan efisiensi. Namun, secara keseluruhan, biaya bisnis justru bisa meningkat.

Di sinilah perusahaan membutuhkan pendekatan yang lebih sistematis, yaitu Cost Engineering.

Cost Engineering bukan sekadar aktivitas mencari pengeluaran yang bisa dipotong. Pendekatan ini menggunakan prinsip rekayasa, analisis ekonomi, estimasi, pengendalian biaya, dan evaluasi risiko untuk membantu perusahaan memperoleh hasil terbaik dari sumber daya yang digunakan.

AACE International, organisasi profesional di bidang Cost Engineering, menjelaskan bahwa disiplin ini mencakup estimasi, pengendalian biaya, perencanaan bisnis, analisis profitabilitas, manajemen proyek, serta perencanaan dan penjadwalan. Pendekatannya dapat diterapkan sepanjang siklus hidup produk, proyek, maupun fasilitas.

Pertanyaannya kemudian: bagaimana Cost Engineering diterapkan dalam operasional perusahaan?

1. Cost Engineering Bukan Sekadar Cost Cutting

Kita perlu membedakan tiga istilah yang sering dianggap sama: Cost Cutting, Cost Reduction, dan Cost Engineering.

Cost Cutting adalah tindakan mengurangi pengeluaran. Misalnya, perusahaan mengurangi perjalanan dinas, membatasi lembur, atau menunda pembelian peralatan.

Cost Reduction merupakan upaya menurunkan biaya secara lebih terencana, misalnya mengurangi material terbuang, memperbaiki produktivitas, atau menurunkan biaya transportasi per unit.

Sementara itu, Cost Engineering menggunakan pendekatan yang lebih luas untuk menganalisis struktur biaya, menentukan kebutuhan sumber daya, mengevaluasi alternatif teknis, dan mengendalikan biaya selama siklus hidup suatu produk atau proses.

Perbedaannya terletak pada pertanyaan yang diajukan.

Cost Cutting bertanya,

"Pengeluaran apa yang bisa kita kurangi?"

Cost Reduction bertanya,

"Bagaimana kita bisa melakukan pekerjaan yang sama dengan biaya lebih rendah?"

Cost Engineering bertanya,

"Bagaimana kita merancang dan menjalankan sistem agar fungsi, kualitas, kapasitas, risiko, dan biaya menghasilkan nilai terbaik bagi perusahaan?"

Perbedaan tersebut sangat penting.

Sebab tujuan perusahaan bukan sekadar mempunyai pengeluaran yang kecil, melainkan menghasilkan produk atau layanan yang kompetitif, berkualitas, dan menguntungkan.

2. Mengapa Cost Engineering Penting bagi Perusahaan Manufaktur?

Dalam industri manufaktur, biaya produk terbentuk dari banyak komponen.

Bukan hanya bahan baku.

Struktur biaya dapat mencakup:

Raw material dan sub-material.

Direct labor dan indirect labor.

Energi listrik, gas, dan bahan bakar.

Consumable serta spare part.

Biaya maintenance.

Biaya setup dan changeover.

Biaya scrap dan produk cacat.

Biaya packaging.

Biaya warehouse dan transportasi.

Depresiasi mesin dan peralatan.

Biaya overhead produksi.

Masing-masing komponen saling memengaruhi.

Sebagai contoh, perusahaan membeli mesin yang lebih murah untuk menghemat investasi awal. Namun, mesin tersebut memiliki kecepatan produksi lebih rendah, konsumsi listrik lebih tinggi, dan frekuensi kerusakan lebih sering.

Jika hanya melihat harga pembelian, keputusan tersebut terlihat ekonomis.

Namun, jika dihitung selama lima atau sepuluh tahun, total biaya kepemilikannya bisa jauh lebih tinggi.

Inilah cara berpikir Cost Engineering: jangan hanya melihat biaya pada saat transaksi, tetapi hitung konsekuensi ekonomi dari keputusan tersebut.

3. Memahami Cost Structure Sebelum Mencari Penghematan

Langkah pertama Cost Engineering adalah memahami struktur biaya secara menyeluruh.

Perusahaan harus mengetahui biaya apa saja yang muncul, bagaimana biaya tersebut terbentuk, serta faktor apa yang menyebabkan perubahannya.

Misalnya, sebuah pabrik memproduksi 15 ton produk plastik setiap bulan.

Untuk memahami biaya produksinya, perusahaan perlu mengidentifikasi:

Material Cost

Berapa kilogram bahan baku yang digunakan untuk menghasilkan satu kilogram produk jadi? Berapa besar scrap dan material yang hilang selama proses?

Labor Cost

Berapa jam kerja yang diperlukan untuk menghasilkan satu ton produk? Apakah jumlah tenaga kerja sesuai dengan kapasitas mesin dan pola produksi?

Energy Cost

Berapa konsumsi listrik per kilogram produk? Apakah konsumsi energi meningkat ketika mesin beroperasi di luar kondisi optimal?

Maintenance Cost

Berapa biaya spare part, preventive maintenance, corrective maintenance, dan kerugian akibat downtime?

Conversion Cost

Berapa biaya untuk mengubah bahan baku menjadi produk jadi, di luar biaya materialnya?

Dengan pemetaan ini, perusahaan dapat mengidentifikasi komponen biaya yang paling besar dan paling berpotensi diperbaiki.

Prinsipnya sederhana,

Kita tidak dapat mengendalikan biaya yang tidak kita pahami.

4. Gunakan Cost per Unit sebagai Dasar Analisis

Salah satu indikator penting dalam Cost Engineering adalah biaya per unit.

Good Output adalah jumlah produk yang memenuhi persyaratan kualitas, bukan sekadar jumlah produk yang keluar dari mesin.

Mengapa hal ini penting?

Bayangkan dua kondisi produksi berikut.

Indikator                 Kondisi A Kondisi B

Total biaya produksi Rp150 juta Rp150 juta

Output total          15.000 kg 15.000 kg

Produk cacat         5%         2%

Produk baik         14.250 kg 14.700 kg

Biaya per kg         Rp10.526 Rp10.204

Ilustrasi perhitungan dengan asumsi seluruh biaya produksi yang ditampilkan sama dan output dinyatakan dalam kilogram.

Walaupun total biaya dan output kotor sama, Kondisi B menghasilkan lebih banyak produk baik.

Akibatnya, biaya per kilogram produk baik menjadi lebih rendah.

Inilah alasan mengapa analisis biaya tidak boleh dipisahkan dari kualitas dan produktivitas.

Biaya yang relevan bukan hanya biaya untuk memproduksi barang, tetapi biaya untuk menghasilkan barang yang dapat dijual dan memenuhi spesifikasi.

5. Cost Engineering dan Material Loss

Dalam banyak industri manufaktur, material merupakan komponen biaya yang signifikan.

Karena itu, pengurangan material loss dapat memberikan dampak besar terhadap profitabilitas.

Misalnya, sebuah pabrik menggunakan 15.000 kg bahan baku per bulan dengan harga Rp20.000 per kg.

Jika tingkat kehilangan material sebesar 5%, maka material yang hilang setara dengan 750 kg.

Nilai material loss tersebut mencapai,

750 kg × Rp20.000 = Rp15 juta per bulan.

Jika perusahaan mampu menurunkan material loss dari 5% menjadi 3%, dengan asumsi penggunaan bahan baku tetap 15.000 kg, maka penghematan teoritisnya adalah,

300 kg × Rp20.000 = Rp6 juta per bulan.

Dalam setahun, potensi penghematan tersebut mencapai Rp72 juta.

Angka ini belum memperhitungkan kemungkinan pengurangan biaya penanganan scrap, pengolahan ulang, dan dampak lingkungan.

Namun, Cost Engineering tidak berhenti pada menghitung nilai kerugian.

Pertanyaan berikutnya adalah: mengapa material loss terjadi?

Apakah karena desain produk? Parameter mesin? Kualitas bahan baku? Metode kerja? Kesalahan operator? Atau proses startup dan changeover?

Di sinilah Cost Engineering terhubung dengan Continuous Improvement.

Pareto dapat membantu menentukan jenis kerugian terbesar. Fishbone Diagram dapat memetakan kemungkinan penyebab. Metode 5 Why dapat membantu menelusuri akar masalah. Setelah itu, perusahaan menentukan tindakan perbaikan berdasarkan dampak biaya dan kelayakan teknis.

Dengan demikian, penghematan tidak hanya terjadi sekali, tetapi dapat dipertahankan melalui standardisasi proses.

6. Hubungan Cost Engineering dengan Line Balancing

Salah satu kesalahan dalam mengelola biaya tenaga kerja adalah menganggap bahwa pengurangan jumlah pekerja selalu menjadi solusi terbaik.

Padahal, persoalannya mungkin bukan jumlah tenaga kerja, melainkan pembagian beban kerja yang tidak seimbang.

Bayangkan sebuah lini produksi memiliki empat stasiun kerja.

Stasiun Waktu proses

Stasiun 1         30 detik

Stasiun 2         55 detik

Stasiun 3         35 detik

Stasiun 4         40 detik

Stasiun 2 menjadi bottleneck karena membutuhkan waktu paling lama.

Meskipun stasiun lainnya mampu bekerja lebih cepat, keluaran lini tetap dibatasi oleh stasiun 2 jika proses berjalan berurutan tanpa buffer atau alternatif aliran.

Akibatnya, perusahaan mungkin mengalami waktu menunggu, utilisasi tenaga kerja yang tidak merata, dan kapasitas produksi yang tidak optimal.

Cost Engineering dapat digunakan untuk mengevaluasi alternatif seperti:

Membagi ulang elemen pekerjaan.

Memindahkan sebagian aktivitas ke stasiun lain.

Memperbaiki metode kerja.

Menggunakan alat bantu.

Mengubah layout.

Mengatur ulang jumlah operator berdasarkan kebutuhan aktual.

Tujuannya bukan sekadar mengurangi tenaga kerja, tetapi menurunkan biaya per unit melalui aliran produksi yang lebih seimbang.

Line Balancing membantu menata beban kerja, sedangkan Cost Engineering membantu menilai dampak ekonominya.

7. Jangan Mengabaikan Downtime dan Maintenance Cost

Mesin yang berhenti bukan hanya menimbulkan biaya perbaikan.

Downtime juga dapat menyebabkan kehilangan output, lembur, keterlambatan pengiriman, penggunaan energi yang tidak produktif, dan biaya tambahan untuk memenuhi pesanan.

Karena itu, perusahaan perlu membedakan biaya maintenance yang terlihat dengan kerugian operasional akibat kegagalan mesin.

Sebagai contoh, perusahaan mengeluarkan Rp10 juta untuk memperbaiki mesin.

Namun, selama mesin berhenti, perusahaan juga kehilangan kesempatan memproduksi barang senilai kontribusi margin Rp20 juta.

Dalam kasus ini, dampak ekonominya tidak cukup dinilai dari tagihan perbaikan sebesar Rp10 juta.

Kita perlu menghitung total dampak downtime dengan hati-hati, termasuk apakah kehilangan output benar-benar tidak dapat dipulihkan, apakah ada kapasitas cadangan, dan apakah pesanan akhirnya tetap dapat dipenuhi.

Pendekatan Cost Engineering dapat membantu perusahaan membandingkan beberapa alternatif:

Tetap menggunakan corrective maintenance.

Memperkuat preventive maintenance.

Menerapkan condition-based maintenance.

Mengganti komponen kritis.

Membeli mesin cadangan.

Mengubah desain atau metode operasi.

Keputusan terbaik tidak selalu berarti memilih biaya maintenance terendah.

Keputusan terbaik adalah memilih alternatif dengan total biaya yang paling masuk akal untuk tingkat keandalan dan kapasitas yang dibutuhkan.

8. Cost Engineering dalam Procurement dan Supply Chain

Procurement sering dinilai berdasarkan kemampuan mendapatkan harga beli terendah.

Namun, harga beli hanya satu bagian dari total biaya.

Bayangkan terdapat dua pemasok bahan baku.

Pemasok A menawarkan harga Rp19.000 per kg dengan tingkat cacat material 3%.

Pemasok B menawarkan harga Rp19.500 per kg dengan tingkat cacat 0,5%.

Jika hanya melihat harga, Pemasok A terlihat lebih murah.

Tetapi material cacat dapat menimbulkan biaya inspeksi, produksi ulang, scrap, keterlambatan, dan gangguan proses.

Karena itu, perusahaan perlu mengevaluasi Total Cost of Ownership (TCO) atau total biaya kepemilikan atau pengadaan yang relevan.

Dalam konteks procurement dan supply chain, TCO dapat mempertimbangkan,

Harga pembelian.

Biaya transportasi.

Bea dan biaya impor jika ada.

Biaya inspeksi dan penerimaan.

Biaya penyimpanan.

Biaya kualitas.

Risiko keterlambatan.

Biaya persediaan.

Biaya pengelolaan pemasok.

Biaya akibat gangguan pasokan.

TCO harus disesuaikan dengan karakter barang dan proses bisnis; tidak semua komponen biaya berlaku untuk setiap pembelian.

Dengan pendekatan ini, procurement tidak hanya mencari pemasok dengan harga termurah, tetapi pemasok yang memberikan nilai ekonomi terbaik.

Harga beli terendah belum tentu menghasilkan total biaya terendah.

9. Cost Engineering dan Life Cycle Cost

Sebuah keputusan bisnis sering terlihat murah pada awalnya, tetapi menjadi mahal ketika digunakan dalam jangka panjang.

Contohnya pembelian mesin, kendaraan operasional, sistem IT, peralatan warehouse, atau pembangunan fasilitas produksi.

Life Cycle Cost (LCC) membantu perusahaan menilai biaya selama masa penggunaan aset.

Dalam analisis yang lebih lengkap, perusahaan juga dapat memasukkan biaya penggantian, biaya penghentian operasi, dan nilai sisa aset. Untuk investasi jangka panjang, arus kas pada tahun yang berbeda idealnya dinilai dengan pendekatan nilai waktu uang.

Misalnya, mesin A mempunyai harga pembelian lebih rendah, tetapi membutuhkan energi lebih besar dan lebih sering mengalami kerusakan. Mesin B lebih mahal saat dibeli, tetapi lebih hemat energi dan mempunyai kebutuhan maintenance yang lebih rendah.

Jika perusahaan hanya membandingkan harga awal, mesin A mungkin terpilih.

Namun, ketika seluruh biaya selama masa pakai dihitung, mesin B bisa menjadi pilihan yang lebih ekonomis.

Pendekatan ini sejalan dengan prinsip Value Engineering: mencapai fungsi yang diperlukan dengan biaya siklus hidup yang optimal, tanpa mengorbankan kinerja, kualitas, keandalan, atau keselamatan. 

10. Bagaimana Memulai Cost Engineering?

Perusahaan tidak harus langsung membeli software mahal atau membentuk departemen baru.

Cost Engineering dapat dimulai dari proses analisis yang sederhana, tetapi disiplin.

Tahap 1 — Identifikasi biaya

Petakan biaya material, tenaga kerja, energi, maintenance, kualitas, logistik, dan overhead.

Tahap 2 — Tentukan cost driver

Identifikasi faktor yang paling memengaruhi biaya. Contohnya harga material, tingkat scrap, waktu siklus, konsumsi energi, downtime, atau utilisasi kapasitas.

Tahap 3 — Bangun baseline

Tentukan kondisi awal yang dapat diukur, seperti biaya per unit, material loss, biaya energi per kilogram, jam downtime, dan biaya lembur.

Tahap 4 — Analisis penyebab

Gunakan data aktual, observasi lapangan, process mapping, Pareto, Fishbone, dan 5 Why untuk menemukan peluang perbaikan.

Tahap 5 — Evaluasi alternatif

Bandingkan beberapa solusi berdasarkan penghematan, investasi yang diperlukan, risiko, dampak terhadap kualitas, dan waktu implementasi.

Tahap 6 — Hitung manfaat bersih

Jangan hanya menghitung penghematan kotor. Masukkan biaya implementasi, biaya tambahan operasional, serta dampak yang mungkin timbul pada proses lain.

Tahap 7 — Implementasi dan standardisasi

Uji solusi, ukur hasil aktual, perbarui SOP atau Work Instruction, dan pastikan penghematan dapat dipertahankan.

Tahap 8 — Monitor hasil

Gunakan dashboard untuk membandingkan biaya aktual dengan baseline, target, volume produksi, dan perubahan kondisi operasi.

Dengan tahapan ini, Cost Engineering menjadi bagian dari sistem pengambilan keputusan, bukan sekadar proyek penghematan sesaat.

11. KPI yang Perlu Dipantau

Cost Engineering membutuhkan indikator yang menghubungkan biaya dengan hasil operasional.

Beberapa KPI yang dapat digunakan antara lain:

KPI                 Fungsi

Cost per Unit         Mengukur biaya untuk menghasilkan satu unit produk baik

Material Loss Rate         Mengukur proporsi kehilangan material

Conversion Cost per Unit Mengukur biaya konversi per unit produk

Labor Cost per Unit Mengukur biaya tenaga kerja per unit

Energy Cost per Unit Mengukur biaya energi per unit

Maintenance Cost per Unit Mengukur biaya pemeliharaan relatif terhadap output

Cost of Poor Quality Mengukur biaya akibat cacat, rework, scrap, dan kegagalan kualitas

Budget Variance Membandingkan biaya aktual dengan anggaran

Savings Realization Mengukur penghematan bersih yang benar-benar terealisasi

Indikator tersebut tidak perlu digunakan seluruhnya sekaligus.

Pilih KPI yang relevan dengan masalah dan strategi perusahaan. Pastikan pula definisi, periode pengukuran, basis volume, serta metode alokasi biaya konsisten.

Sebab, biaya per unit dapat terlihat turun hanya karena volume produksi meningkat, sementara efisiensi proses sebenarnya tidak berubah.

Sebaliknya, biaya per unit dapat naik akibat volume rendah, meskipun proses produksi telah menjadi lebih efisien.

Angka biaya harus dibaca bersama konteks operasionalnya.

12. Cost Engineering Harus Menjadi Tanggung Jawab Lintas Departemen

Cost Engineering tidak seharusnya menjadi tanggung jawab Finance saja.

Finance memang berperan dalam pencatatan, analisis, penganggaran, dan validasi manfaat finansial.

Namun, penyebab biaya sering kali berada di bagian operasional.

Produksi memahami proses dan produktivitas.

Engineering memahami mesin dan desain proses.

Quality memahami cacat dan biaya kualitas.

Procurement memahami pemasok dan harga pembelian.

Warehouse memahami persediaan, ruang penyimpanan, dan material handling.

Maintenance memahami keandalan aset.

PPIC memahami perencanaan produksi, kapasitas, dan jadwal.

Karena itu, Cost Engineering membutuhkan kolaborasi lintas fungsi.

Finance membantu memastikan angka yang digunakan valid. Tim teknis menguji apakah solusi dapat dijalankan. Tim operasional memastikan hasilnya benar-benar terjadi di lapangan.

Tanpa kolaborasi tersebut, penghematan mudah berhenti sebagai angka di dalam laporan.

Capacity Planning

Memastikan Kapasitas Perusahaan Cukup untuk Memenuhi Permintaan

Bukan Sekadar Menghitung Berapa Banyak yang Bisa Diproduksi, Tetapi Menentukan Apakah Perusahaan Mampu Memenuhi Demand

Dalam dunia operasi, ada satu pertanyaan sederhana yang sebenarnya sangat fundamental:

"Apakah kapasitas kita cukup untuk memenuhi kebutuhan?"

Pertanyaan ini terdengar sederhana.

Tetapi jawabannya tidak sesederhana itu.

Karena kapasitas bukan hanya tentang berapa banyak mesin yang kita miliki.

Bukan hanya berapa jumlah operator.

Bukan hanya berapa jam kerja tersedia.

Dan bukan hanya berapa unit yang bisa diproduksi dalam satu hari.

Capacity Planning adalah proses untuk memastikan bahwa kapasitas sumber daya yang tersedia mampu memenuhi kebutuhan operasional pada waktu yang tepat, dengan biaya yang masuk akal, dan tanpa menciptakan bottleneck.

Inilah mengapa Capacity Planning menjadi salah satu elemen penting dalam Operations Management, Production Planning, PPIC, Supply Chain, Warehouse, dan bahkan Logistics.

Apa Itu Capacity Planning?

Secara sederhana:

Capacity Planning adalah proses menentukan kapasitas sumber daya yang dibutuhkan untuk memenuhi permintaan pada periode tertentu.

Sumber daya tersebut dapat berupa:

Machine

Manpower

Working hours

Warehouse space

Transportation

Equipment

Production line

Storage

Technology

Supplier capacity

Sedangkan kebutuhan dapat berasal dari:

Sales Order

Forecast

Production Plan

Customer Demand

Shipment Plan

Inventory Target

Jadi hubungan sederhananya:

Demand

↓

Capacity Requirement

↓

Available Capacity

↓

Capacity Gap

↓

Capacity Decision

Mengapa Capacity Planning Penting?

Bayangkan Sales mendapatkan order:

100.000 unit per bulan.

Sales tentu senang.

Tetapi Production bertanya:

"Apakah kita mampu memproduksi 100.000 unit?"

Ternyata:

Available capacity hanya:

80.000 unit.

Maka terdapat:

Capacity Gap = 20.000 unit.

Kalau gap ini tidak diketahui sejak awal, masalah baru akan terlihat ketika order sudah jatuh tempo.

Akhirnya:

overtime meningkat,

subcontracting dilakukan mendadak,

delivery terlambat,

inventory tidak sesuai,

operator kelelahan,

machine breakdown meningkat,

dan customer complaint muncul.

Padahal masalah tersebut sebenarnya bisa diprediksi.

Itulah fungsi Capacity Planning.

Capacity Planning Bukan Hanya untuk Production

Banyak orang menganggap Capacity Planning hanya milik Production atau PPIC.

Padahal tidak.

Capacity Planning dapat diterapkan pada:

Manufacturing

Berapa kapasitas mesin dan manpower yang dibutuhkan?

Warehouse

Apakah storage capacity cukup?

Logistics

Apakah jumlah kendaraan cukup?

Procurement

Apakah supplier mampu memenuhi kebutuhan?

Customer Service

Apakah jumlah agent cukup untuk menangani volume transaksi?

IT

Apakah server mampu menangani traffic?

Jadi konsepnya sangat luas:

Demand harus dibandingkan dengan Capacity.

Capacity Planning Dimulai dari Demand

Capacity Planning tidak dimulai dari:

"Kita punya berapa mesin?"

Tetapi:

"Kita membutuhkan kapasitas berapa?"

Misalnya forecast demand:

Bulan Demand

Januari 80.000

Februari 90.000

Maret 100.000

April 120.000

Mei 130.000

Kalau kapasitas produksi:

100.000 unit/bulan

Maka mulai April perusahaan menghadapi capacity gap.

Artinya, Capacity Planning sudah memberi warning sebelum masalah terjadi.

1. Available Capacity

Langkah pertama adalah menghitung:

Berapa kapasitas yang benar-benar tersedia?

Jangan menggunakan kapasitas teoritis.

Misalnya:

Mesin mampu bekerja:

24 jam × 30 hari = 720 jam/bulan.

Secara teori kapasitasnya:

720 jam.

Tetapi apakah perusahaan benar-benar dapat menggunakan 720 jam?

Tentu tidak.

Ada:

Maintenance

Break

Setup

Changeover

Meeting

Cleaning

Breakdown

Holiday

Waiting

Lack of material

Maka kita harus menghitung Available Capacity secara realistis.

2. Capacity Requirement

Setelah mengetahui available capacity, kita menghitung:

Berapa kapasitas yang dibutuhkan untuk memenuhi demand?

Misalnya:

Demand:

10.000 unit

Machine cycle time:

3 menit/unit

Maka kebutuhan waktu:

10.000 × 3 menit = 30.000 menit

atau:

500 jam.

Jadi:

Capacity Requirement = 500 jam

3. Capacity Gap

Sekarang kita bandingkan:

Available Capacity

vs

Capacity Requirement

Misalnya:

Available Capacity:

450 jam

Capacity Requirement:

500 jam

Maka:

Capacity Gap = 50 jam

Artinya perusahaan kekurangan kapasitas 50 jam.

Ini adalah informasi yang sangat penting untuk management.

Rumus Dasarnya

Interpretasinya:

Gap positif

→ Kapasitas berlebih.

Gap = 0

→ Kapasitas tepat.

Gap negatif

→ Kapasitas tidak mencukupi.

Capacity Utilization

Salah satu KPI yang sangat penting dalam Capacity Planning adalah:

Capacity Utilization.

Secara sederhana:

Contoh:

Available Capacity:

500 jam

Planned Hours:

400 jam

Maka:

Utilization = 80%

Artinya 80% kapasitas yang tersedia sudah direncanakan untuk digunakan.

Utilization 100% Apakah Bagus?

Belum tentu.

Ini adalah salah satu kesalahpahaman dalam Capacity Planning.

Banyak orang berpikir:

"Semakin tinggi utilization, semakin bagus."

Tidak selalu.

Kalau kapasitas selalu digunakan:

100%

maka sedikit gangguan saja bisa membuat seluruh schedule terganggu.

Misalnya:

breakdown,

urgent order,

quality problem,

material shortage,

absenteeism.

Tidak ada lagi capacity buffer.

Karena itu perusahaan sering membutuhkan capacity cushion.

Capacity Cushion

Capacity Cushion adalah kapasitas tambahan yang sengaja dipertahankan untuk menghadapi ketidakpastian.

Misalnya:

Available capacity:

100 jam

Planned requirement:

80 jam

Maka terdapat:

20 jam buffer.

Buffer ini bisa digunakan ketika:

demand meningkat,

terjadi breakdown,

ada urgent order,

proses lebih lambat dari standard,

terjadi rework.

Dengan kata lain:

Capacity Planning yang baik tidak selalu mengejar 100% utilization.

Kadang kapasitas yang "menganggur" justru merupakan insurance against uncertainty.

Capacity Planning dan Bottleneck

Ini bagian yang sangat penting.

Sebuah production line dapat memiliki banyak mesin.

Misalnya:

Process A → Process B → Process C → Process D

Kapasitas:

A = 1.000 unit/hari

B = 900 unit/hari

C = 600 unit/hari

D = 800 unit/hari

Walaupun Process A mampu menghasilkan:

1.000 unit

production line secara keseluruhan hanya mampu menghasilkan:

600 unit/hari.

Mengapa?

Karena Process C adalah bottleneck.

Inilah mengapa Capacity Planning tidak cukup hanya melihat total kapasitas.

Kita harus melihat:

Kapasitas setiap proses.

Bottleneck Menentukan Kapasitas Sistem

Secara sederhana:

Capacity of the system is constrained by its bottleneck.

Jadi:

Line Capacity ≠ Total Machine Capacity

Tetapi sangat dipengaruhi oleh:

Bottleneck Capacity.

Misalnya:

A = 100 pcs/hour

B = 120 pcs/hour

C = 80 pcs/hour

D = 110 pcs/hour

Maka kapasitas efektif line kira-kira:

80 pcs/hour.

Menambah kapasitas A tidak akan menyelesaikan masalah.

Menambah mesin D juga belum tentu menyelesaikan masalah.

Kita harus bertanya:

"Di mana bottleneck-nya?"

Capacity Planning Harus Melihat Variability

Masalah Capacity Planning adalah demand dan proses tidak selalu stabil.

Hari ini:

1.000 unit.

Besok:

1.500 unit.

Minggu depan:

800 unit.

Ditambah lagi:

machine breakdown,

absenteeism,

material shortage,

quality issue,

changeover,

urgent order.

Karena itu Capacity Planning harus mempertimbangkan variability.

Bukan hanya menggunakan angka rata-rata.

Capacity Planning dan Efficiency

Capacity berbeda dengan efficiency.

Misalnya:

Mesin memiliki available capacity:

500 jam.

Tetapi karena downtime dan speed loss, actual production hanya menggunakan equivalent:

400 jam produktif.

Maka kita harus membedakan:

Capacity

dengan:

Efficiency.

Capacity menjawab:

"Seberapa banyak kemampuan yang tersedia?"

Efficiency menjawab:

"Seberapa efektif kemampuan tersebut digunakan?"

Ini penting karena capacity gap tidak selalu berarti perusahaan harus membeli mesin baru.

Bisa jadi masalahnya adalah:

Efficiency rendah.

Capacity Planning dan Downtime

Misalnya:

Available Time:

500 jam

Downtime:

50 jam

Maka effective available time menjadi:

450 jam.

Kalau demand membutuhkan:

480 jam

maka perusahaan sebenarnya memiliki gap:

30 jam.

Tetapi jika downtime berhasil dikurangi dari:

50 jam → 20 jam

maka kapasitas efektif menjadi:

480 jam.

Gap hilang.

Artinya:

Capacity problem dapat diselesaikan melalui improvement, bukan selalu melalui investasi.

Capacity Planning dan OEE

Dalam manufacturing, Capacity Planning dapat dikaitkan dengan OEE — Overall Equipment Effectiveness.

OEE melihat:

Availability × Performance × Quality

Misalnya:

Availability = 90%

Performance = 85%

Quality = 98%

Maka OEE sekitar:

74,97%.

Artinya kapasitas teoritis mesin jauh lebih besar daripada kapasitas efektif yang benar-benar menghasilkan output berkualitas.

Karena itu capacity calculation yang hanya menggunakan machine rated capacity bisa menyesatkan.

Capacity Planning Harus Memperhatikan Product Mix

Ini juga sering dilupakan.

Tidak semua produk membutuhkan waktu produksi yang sama.

Misalnya:

Product A

Cycle time = 2 menit.

Product B

Cycle time = 5 menit.

Product C

Cycle time = 8 menit.

Jika demand:

A = 5.000 unit

B = 3.000 unit

C = 2.000 unit

Kita tidak bisa mengatakan:

"Total demand = 10.000 unit."

Karena yang lebih penting adalah:

Berapa jam kapasitas yang dibutuhkan?

Product mix menentukan total capacity requirement.

Capacity Planning dan Changeover

Semakin banyak product mix, semakin besar kemungkinan:

Changeover.

Misalnya:

Production:

A → B → C → D → A

Setiap pergantian membutuhkan:

30 menit.

Kalau ada 10 changeover:

10 × 30 menit = 300 menit

atau:

5 jam.

Lima jam tersebut adalah kapasitas yang hilang dari production.

Maka Capacity Planning harus memasukkan:

Setup Time + Changeover Time.

Capacity Planning dan Manpower

Kapasitas bukan hanya mesin.

Misalnya warehouse memiliki:

10 operator.

Setiap operator tersedia:

8 jam/hari.

Secara teori:

80 man-hours/day.

Tetapi setelah dikurangi:

break,

meeting,

training,

absenteeism,

waiting,

administrative work,

mungkin effective available capacity hanya:

65 man-hours/day.

Karena itu:

Manpower Capacity harus dihitung menggunakan productive available time, bukan sekadar jumlah orang × jam kerja.

Capacity Planning dan Overtime

Ketika capacity gap muncul, perusahaan biasanya mempunyai beberapa pilihan.

1. Overtime

Menambah jam kerja.

Cocok untuk:

temporary demand increase,

short-term capacity gap.

Tetapi tidak ideal jika dilakukan terus-menerus.

2. Additional Shift

Misalnya:

2 shift → 3 shift.

Ini meningkatkan available capacity tanpa membeli mesin baru.

3. Additional Manpower

Menambah tenaga kerja.

Cocok jika bottleneck berada pada manpower.

4. Improve Productivity

Meningkatkan output dengan resource yang sama.

Misalnya:

100 pcs/hour

menjadi:

120 pcs/hour.

5. Reduce Downtime

Jika capacity loss berasal dari downtime.

6. Reduce Changeover

Menggunakan:

SMED

atau metode improvement lainnya.

7. Subcontracting

Sebagian produksi dialihkan ke pihak ketiga.

8. Additional Equipment

Menambah mesin atau equipment.

Ini membutuhkan capital investment.

Capacity Planning Bukan Selalu "Tambah Kapasitas"

Ini mindset yang penting.

Ketika terjadi:

Capacity Gap

jangan langsung berpikir:

"Kita harus membeli mesin."

Tanyakan dulu:

Apakah utilization terlalu tinggi?

Apakah downtime terlalu tinggi?

Apakah cycle time bisa diperbaiki?

Apakah changeover terlalu lama?

Apakah manpower allocation optimal?

Apakah schedule sudah optimal?

Apakah product mix dapat diatur?

Apakah demand dapat diratakan?

Apakah bottleneck dapat dihilangkan?

Baru setelah semua dianalisis:

Apakah kita benar-benar membutuhkan additional capacity?

Capacity Planning dan Production Scheduling

Capacity Planning berbeda dengan Production Scheduling.

Capacity Planning menjawab:

"Apakah kita punya kapasitas yang cukup?"

Sedangkan:

Production Scheduling menjawab:

"Kapan dan urutan produksinya bagaimana?"

Contohnya:

Capacity Planning:

Mesin A membutuhkan 500 jam, tersedia 450 jam.

Berarti ada:

50 jam capacity gap.

Production Scheduling kemudian mengatur:

product apa,

kapan diproduksi,

mesin mana,

shift mana,

sequence bagaimana.

Jadi Capacity Planning menjadi salah satu input penting bagi Production Scheduling.

Capacity Planning dalam PPIC

Dalam lingkungan manufacturing, hubungan sederhananya dapat digambarkan:

Sales Order / Forecast

↓

Demand Planning

↓

Production Planning

↓

Material Planning

↓

Capacity Planning

↓

Production Scheduling

Tetapi dalam praktiknya, proses ini bersifat iteratif.

Kalau capacity tidak cukup:

Production Plan harus dikaji ulang.

Kalau material tidak cukup:

Production Plan juga harus dikaji ulang.

Kalau machine capacity berubah:

Schedule juga harus berubah.

Jadi PPIC bukan sekadar membuat jadwal.

PPIC adalah tentang:

menyeimbangkan Demand, Material, Capacity, dan Time.

Capacity Planning dan S&OP

Pada level management, Capacity Planning juga menjadi bagian dari Sales and Operations Planning (S&OP).

Sales mengatakan:

"Demand bulan depan naik 20%."

Operations menjawab:

"Capacity kita hanya naik 5%."

Finance bertanya:

"Berapa investasi untuk menambah kapasitas?"

Procurement bertanya:

"Apakah supplier mampu?"

HR bertanya:

"Berapa tambahan manpower?"

Di sinilah Capacity Planning menjadi alat pengambilan keputusan.

Bukan hanya alat perhitungan.

Capacity Planning Horizon

Capacity Planning biasanya dibagi berdasarkan horizon waktu.

Short-Term Capacity Planning

Biasanya untuk kebutuhan jangka pendek.

Contohnya:

overtime,

shift adjustment,

manpower allocation,

schedule adjustment.

Medium-Term Capacity Planning

Contohnya:

additional shift,

hiring,

subcontracting,

equipment adjustment.

Long-Term Capacity Planning

Contohnya:

new production line,

new warehouse,

new factory,

automation,

major capital investment.

Semakin panjang horizon, semakin strategis keputusan yang diambil.

Capacity Planning Harus Menghasilkan Keputusan

Output Capacity Planning bukan hanya:

Excel.

Bukan hanya:

grafik utilization.

Bukan hanya:

angka capacity gap.

Yang paling penting adalah:

Decision.

Misalnya:

Capacity surplus

→ manfaatkan kapasitas untuk additional order.

Capacity tight

→ monitor dan optimalkan.

Capacity gap kecil

→ overtime / shift adjustment.

Capacity gap besar

→ subcontracting / additional equipment.

Capacity gap permanen

→ capital investment.

Jadi:

Capacity Planning adalah decision-support system.

Contoh Sederhana Capacity Planning

Misalnya sebuah production line memiliki:

Available Hours = 500 jam

Production requirement:

450 jam

Maka:

Utilization = 90%

dan:

Capacity Gap = 50 jam surplus.

Tetapi bulan depan demand meningkat sehingga requirement menjadi:

550 jam.

Sekarang:

Available = 500 jam

Required = 550 jam

Gap:

-50 jam.

Management memiliki beberapa pilihan:

Option 1: Overtime 50 jam.

Option 2: Tambah shift.

Option 3: Improve productivity.

Option 4: Subcontract.

Option 5: Investasi mesin baru.

Pertanyaannya bukan:

"Mana yang paling mudah?"

Tetapi:

"Mana yang paling optimal secara operational dan financial?"

Capacity Planning Dashboard

Kalau diterapkan di perusahaan, Capacity Planning sebaiknya tidak berhenti pada spreadsheet.

Dashboard dapat menampilkan:

Parameter Value

Available Hours 500

Planned Hours 450

Utilization 90%

Required Capacity 480

Capacity Gap 20

Overtime 10

Downtime 25

Bottleneck Machine B

Manager kemudian dapat melihat:

Apakah kita aman?

Apakah capacity mulai kritis?

Di mana bottleneck?

Apakah perlu overtime?

Apakah perlu investasi?

Traffic Light Capacity

Dashboard juga bisa menggunakan pendekatan sederhana:

🟢 Green

Capacity masih aman.

🟡 Yellow

Capacity mulai tight.

Perlu monitoring dan improvement.

🔴 Red

Capacity gap.

Perlu tindakan segera.

Dengan demikian Capacity Planning berubah dari:

Data

menjadi:

Early Warning System.

Kesalahan Umum dalam Capacity Planning

1. Menggunakan kapasitas teoritis

Mesin 24 jam bukan berarti bisa berproduksi 24 jam penuh.

2. Tidak memperhitungkan downtime

Capacity yang hilang karena breakdown harus dihitung.

3. Mengabaikan changeover

Setup time mengonsumsi kapasitas.

4. Menggunakan demand rata-rata

Peak demand bisa menciptakan bottleneck.

5. Tidak melihat product mix

Produk berbeda membutuhkan waktu berbeda.

6. Hanya melihat total capacity

Harus melihat capacity setiap process.

7. Tidak mempertimbangkan efficiency

Rated capacity tidak sama dengan effective capacity.

8. Menganggap utilization tinggi selalu bagus

Utilization 100% bisa membuat sistem sangat rentan terhadap gangguan.

9. Langsung membeli mesin

Capacity gap belum tentu membutuhkan capital investment.

10. Capacity Planning tidak diperbarui

Capacity Planning harus mengikuti perubahan demand dan actual performance.

Capacity Planning dan Continuous Improvement

Di sinilah hubungan Capacity Planning dengan Continuous Improvement menjadi menarik.

Misalnya:

Awalnya:

Available Capacity = 500 jam

Required:

550 jam

Gap:

-50 jam.

Tim kemudian melakukan improvement:

Downtime reduction

50 jam → 25 jam.

Kemudian:

Changeover reduction

30 jam → 15 jam.

Kemudian:

Productivity improvement

100 unit/hour → 115 unit/hour.

Akhirnya capacity effective meningkat tanpa membeli mesin baru.

Ini adalah filosofi penting:

Before adding capacity, improve the capacity you already have.

Capacity Planning Bukan Hanya Tentang Kapasitas

Pada akhirnya, Capacity Planning sebenarnya adalah tentang keseimbangan.

Keseimbangan antara:

Demand

dan

Capacity.

Tetapi juga:

Capacity

dengan

Cost.

Capacity

dengan

Quality.

Capacity

dengan

Delivery.

Capacity

dengan

People.

Karena perusahaan bisa saja memiliki capacity besar, tetapi terlalu mahal.

Bisa juga capacity cukup, tetapi quality turun.

Bisa juga capacity tinggi, tetapi operator burnout.

Jadi Capacity Planning harus melihat business trade-off.

Kesimpulan

Capacity Planning pada dasarnya menjawab satu pertanyaan:

"Apakah kita memiliki kapasitas yang tepat untuk memenuhi kebutuhan pada waktu yang tepat?"

Tetapi untuk menjawabnya dengan benar, kita harus melihat:

Demand

Available Capacity

Required Capacity

Utilization

Capacity Gap

Efficiency

Downtime

Product Mix

Changeover

Manpower

Bottleneck

Capacity Cushion

dan Cost.

Karena capacity yang terlalu kecil menghasilkan:

Late Delivery.

Capacity yang terlalu besar menghasilkan:

Idle Capacity dan Cost.

Maka tujuan Capacity Planning bukan:

Maximum Capacity.

Bukan pula:

Maximum Utilization.

Tetapi:

Right Capacity at the Right Time.

Kapasitas yang tepat.

Pada waktu yang tepat.

Dengan biaya yang tepat.

Untuk memenuhi kebutuhan customer.

Dan ketika capacity gap muncul, jangan langsung bertanya:

"Berapa mesin yang harus kita beli?"

Pertanyaan yang lebih baik adalah:

"Mengapa kapasitas kita tidak cukup, dan bagaimana kita dapat meningkatkan kapasitas efektif yang sudah kita miliki?"

Karena mungkin masalahnya bukan kekurangan mesin.

Mungkin masalahnya adalah:

Downtime terlalu tinggi.

Changeover terlalu lama.

Productivity terlalu rendah.

Scheduling tidak optimal.

Manpower tidak tepat.

Bottleneck tidak dikelola.

Atau bahkan:

Demand dan capacity tidak pernah diselaraskan sejak awal.

Dan di situlah Capacity Planning berubah dari sekadar perhitungan kapasitas menjadi alat strategis untuk mengambil keputusan operasional.

Manajemen Operasi vs Produksi

Sama-sama Penting, Tetapi Bukan Hal yang Sama

Dalam dunia manufaktur, istilah Operation Management dan Production sering digunakan seolah-olah memiliki arti yang sama.

Padahal keduanya berbeda.

Produksi adalah bagian dari Manajemen Operasi.

Kalau produksi berfokus pada bagaimana bahan baku diubah menjadi produk jadi, maka Manajemen Operasi melihat sesuatu yang jauh lebih besar: bagaimana seluruh sistem bekerja dari permintaan customer sampai produk tersebut sampai kepada customer.

Dengan kata lain:

Produksi membuat produk. Manajemen Operasi memastikan sistem yang membuat dan mengirimkan produk tersebut berjalan dengan baik.

Produksi: Fokus pada Membuat Produk

Produksi merupakan aktivitas inti dalam proses manufaktur.

Di dalam produksi terdapat aktivitas seperti:

Material preparation

Machine setup

Processing

Molding

Extrusion

Spinning

Lamination

Cutting

Finishing

Assembly

Quality inspection

Misalnya pada manufaktur plastic fiber, proses produksinya dapat berupa:

Raw Material → Melting → Extrusion/Spinning → Cooling → Drawing → Heat Setting → Crimping → Cutting → Finishing → Finished Product

Fokus Production adalah memastikan proses tersebut menghasilkan produk sesuai:

Quantity + Quality + Cost + Time

Pertanyaan utama Production adalah:

"Bagaimana kita membuat produk dengan benar, sesuai target, menggunakan resource yang tersedia?"

Manajemen Operasi: Melihat Sistem Secara End-to-End

Manajemen Operasi mempunyai cakupan yang lebih luas.

Ia tidak hanya melihat bagaimana produk dibuat, tetapi juga bagaimana seluruh proses sebelum dan sesudah produksi saling terhubung.

Dalam manufaktur, flow-nya dapat digambarkan:

Sales Order

↓

Production Planning

↓

Material Planning

↓

Capacity Planning

↓

Production Schedule

↓

Production

↓

Quality

↓

Finished Goods

↓

Delivery

Di sinilah peran Manajemen Operasi.

Ia memastikan bahwa:

Demand → Material → Capacity → Production → Delivery

berjalan sebagai satu sistem.

Perbedaan Fundamental

Perbedaan keduanya dapat dilihat dari fokusnya.

Aspek Manajemen Operasi Produksi

Fokus Keseluruhan sistem operasi Proses pembuatan produk

Scope End-to-end Manufacturing process

Input Demand/customer requirement Raw material & production order

Aktivitas Planning, material, capacity, scheduling, production, inventory, delivery Processing, machine operation, assembly, finishing

Pertanyaan utama "Bagaimana seluruh sistem berjalan optimal?" "Bagaimana produk dibuat?"

Output Customer requirement terpenuhi Finished product

Jadi Production merupakan salah satu komponen utama dari Operation Management.

Lima Pilar Operation Planning

Jika kita mengambil perspektif Operation Management dalam manufaktur, setidaknya terdapat lima proses planning yang sangat fundamental:

1. Sales Order

Menjawab:

Apa yang diminta customer?

Informasinya antara lain:

Customer

Product

Quantity

Specification

Required date

Delivery requirement

Sales Order menjadi trigger bagi proses planning.

2. Production Planning

Menjawab:

Apa dan berapa yang harus diproduksi?

Production Planning menerjemahkan demand menjadi production requirement.

Contohnya:

Customer Order:

10.000 pcs

Production Planning menentukan:

Production Requirement = 10.000 pcs

dengan mempertimbangkan inventory, WIP, safety stock, yield, batch size, dan production lead time.

3. Material Planning

Menjawab:

Apakah material tersedia untuk memenuhi Production Plan?

Production Plan diterjemahkan melalui BOM menjadi kebutuhan material.

Contohnya:

10.000 pcs

membutuhkan:

Resin

Fiberglass

Additive

Pigment

Packaging

Kemudian dibandingkan dengan:

Stock + Open PO + Scheduled Receipt

sehingga diketahui apakah terdapat material shortage.

4. Capacity Planning

Menjawab:

Apakah kita mempunyai kapasitas yang cukup?

Capacity Planning membandingkan:

Required Capacity vs Available Capacity

Misalnya:

Required = 500 hours

Available = 450 hours

Maka:

Capacity Gap = -50 hours

Artinya perusahaan kekurangan kapasitas 50 jam.

Planner kemudian dapat mempertimbangkan:

Overtime

Additional shift

Additional machine

Subcontract

Productivity improvement

Rescheduling

5. Production Schedule

Menjawab:

Kapan dan dalam urutan apa produksi dilakukan?

Production Plan mungkin mengatakan:

Product A = 5.000 pcs

Production Schedule menerjemahkannya menjadi:

Monday → A → 1.000 pcs

Tuesday → A → 1.000 pcs

Wednesday → A → 1.000 pcs

dan seterusnya.

Jadi:

Production Planning menentukan WHAT & HOW MUCH.

Production Scheduling menentukan WHEN & SEQUENCE.

Production Adalah Execution dari Operation Planning

Di sinilah hubungan keduanya menjadi jelas.

Operation Planning menghasilkan:

Sales Order

↓

Production Plan

↓

Material Plan

↓

Capacity Plan

↓

Production Schedule

Kemudian Production menjalankan:

Production Schedule

↓

Material Preparation

↓

Machine Setup

↓

Processing

↓

Finishing

↓

Quality Check

↓

Finished Product

Jadi kita dapat mengatakan:

Operation Planning determines what should happen.

Production executes what has been planned.

Kenapa Perbedaan Ini Penting?

Kesalahan memahami perbedaan antara Operation dan Production dapat menyebabkan organisasi terlalu fokus pada output produksi.

Misalnya Production berhasil menghasilkan:

10.000 pcs

Secara sekilas terlihat berhasil.

Tetapi ternyata:

Material datang terlambat

Overtime terlalu tinggi

Capacity utilization terlalu tinggi

Production schedule sering berubah

WIP menumpuk

Finished Goods terlalu banyak

Delivery terlambat

Maka Production mungkin berhasil membuat produk, tetapi Operation secara keseluruhan belum tentu berhasil.

Inilah perbedaan pentingnya.

Production melihat output.

Operation Management melihat flow.

Operation Management Melihat Kinerja Secara Menyeluruh

Karena cakupannya lebih luas, KPI Operation juga tidak sama persis dengan KPI Production.

Untuk Operation Planning, misalnya, kita dapat menggunakan lima KPI utama:

Process KPI

Sales Order OTIF

Production Planning Plan Achievement

Material Planning Material Availability

Capacity Planning Capacity Utilization

Production Schedule Schedule Adherence

Sedangkan Production dapat memiliki KPI seperti:

Productivity

Efficiency

Machine Downtime

Yield

Scrap Rate

OEE

Output Achievement

Keduanya saling berhubungan.

Misalnya:

Machine Downtime ↑

↓

Production Capacity ↓

↓

Schedule Adherence ↓

↓

Production Plan Achievement ↓

↓

OTIF ↓

Satu masalah di Production dapat akhirnya menjadi masalah Operation.

Operation Management adalah "Orchestrator"

Saya melihat Manajemen Operasi seperti seorang orchestrator.

Ia tidak harus memainkan semua alat musik.

Tetapi ia harus memastikan seluruh alat musik dimainkan pada waktu yang tepat dan menghasilkan sebuah pertunjukan yang harmonis.

Dalam manufaktur:

Sales memberikan demand.

Planning menyusun rencana.

Material memastikan bahan tersedia.

Capacity memastikan kemampuan produksi tersedia.

Production membuat produk.

Quality memastikan produk sesuai standar.

Warehouse mengelola inventory.

Logistics mengirimkan produk.

Operation Management memastikan semuanya terhubung.

Dari Departmental Thinking menjadi End-to-End Thinking

Inilah perubahan cara berpikir yang penting.

Cara berpikir lama:

"Production sudah mencapai target."

Cara berpikir Operation:

"Apakah customer mendapatkan produk yang tepat, dalam jumlah yang tepat, dengan kualitas yang tepat, pada waktu yang tepat, dengan resource yang optimal?"

Karena pada akhirnya customer tidak membeli:

Production Output.

Customer membeli:

Value.

Dan tugas Manajemen Operasi adalah memastikan value tersebut mengalir dari customer demand sampai customer delivery.

Kesimpulan

Production dan Operation Management bukanlah dua hal yang saling menggantikan.

Production adalah bagian dari Operation Management.

Production berfokus pada:

Making the Product

Sedangkan Operation Management berfokus pada:

Managing the System that Delivers the Product

Dalam manufaktur, kita dapat menyederhanakannya menjadi:

Sales Order

→ Production Planning

→ Material Planning

→ Capacity Planning

→ Production Schedule

→ Production

→ Finished Goods

→ Customer

Maka:

Production membuat produk.

Operation Management memastikan seluruh sistem mampu membuat dan mengirimkan produk tersebut secara efektif, efisien, dan tepat waktu.

Dan ketika sebuah perusahaan mulai berpindah dari sekadar "mengejar output produksi" menuju "mengelola keseluruhan flow dari demand sampai delivery", di situlah fungsi Operation Management mulai memberikan nilai yang jauh lebih besar.

Fishbone 3 P

Mengapa Continuous Improvement Cukup Dimulai dari People, System, dan Culture?

Sederhanakan 6M, Tetapi Jangan Sederhanakan Cara Berpikir

Dalam Continuous Improvement, kita mengenal berbagai macam tools untuk mencari akar masalah.

Ada 5 Why.

Ada Pareto.

Ada Fishbone Diagram.

Ada PDCA.

Ada 5W1H.

Semua memiliki fungsi masing-masing.

Salah satu yang paling populer adalah Fishbone Diagram, atau Ishikawa Diagram.

Secara klasik, Fishbone sering dianalisis menggunakan pendekatan 6M:

Man – Method – Machine – Material – Measurement – Mother Nature/Environment.

Pendekatan ini sangat berguna, terutama dalam manufacturing dan operational problem solving.

Tetapi ketika kita membawa Continuous Improvement ke level yang lebih luas—warehouse, logistics, supply chain, service, bahkan organisasi—muncul sebuah pertanyaan:

Apakah kita benar-benar membutuhkan enam kategori untuk mulai memahami sebuah masalah?

Atau justru kita bisa menyederhanakannya menjadi tiga pertanyaan besar?

People.

System.

Culture.

Inilah yang bisa kita sebut sebagai:

Fishbone 3P

People – System – Culture

Sederhana.

Tetapi bukan berarti dangkal.

Justru tiga kategori ini dapat membantu manager melihat masalah dari tiga dimensi yang sangat fundamental.

Ketika Masalah Terjadi, Jangan Langsung Mencari Siapa yang Salah

Bayangkan sebuah warehouse mengalami inventory discrepancy.

Stock secara sistem: 10.000 pcs

Stock fisik: 9.750 pcs

Ada selisih: 250 pcs.

Apa yang biasanya terjadi?

Pertanyaan pertama:

"Siapa yang melakukan kesalahan?"

Kemudian mulai mencari operator.

Siapa yang melakukan receiving?

Siapa yang melakukan putaway?

Siapa yang melakukan picking?

Siapa yang melakukan adjustment?

Siapa yang terakhir memegang barang?

Akhirnya kita menemukan seseorang.

Lalu kita mengatakan:

"Human error."

Masalah selesai?

Belum tentu.

Karena kita baru menemukan siapa yang melakukan kesalahan, bukan mengapa sistem memungkinkan kesalahan tersebut terjadi.

Di sinilah Fishbone 3P menjadi menarik.

Fishbone 3P

Ketika sebuah masalah muncul, kita cukup mengajukan tiga pertanyaan besar:

1. PEOPLE

Apakah orangnya mampu?

2. SYSTEM

Apakah sistemnya memungkinkan?

3. CULTURE

Apakah budaya organisasinya mendukung?

Tiga pertanyaan ini dapat membuka perspektif yang jauh lebih luas.

1. PEOPLE — Apakah Orangnya Mampu?

People berkaitan dengan faktor manusia secara individual.

Pertanyaan utamanya:

"Apakah orang yang menjalankan proses memiliki kemampuan untuk melakukan pekerjaan dengan benar?"

Kita bisa melihat:

Knowledge

Skill

Competency

Experience

Training

Awareness

Communication

Workload

Fatigue

Leadership capability

Misalnya terjadi picking error.

Kita menemukan operator baru.

Ternyata operator belum memahami beberapa SKU.

Maka kemungkinan penyebabnya:

Training belum memadai.

Ini adalah People factor.

Solusinya mungkin:

Training

Coaching

Certification

Skill matrix

On-the-job training

Competency assessment

Tetapi jangan berhenti di sini.

Karena ada pertanyaan berikutnya.

2. SYSTEM — Apakah Sistemnya Memungkinkan?

Ini bagian yang sangat penting.

Kadang orang sebenarnya mampu, tetapi sistemnya membuat kesalahan mudah terjadi.

Misalnya operator sudah berpengalaman.

Sudah training.

Sudah bekerja lima tahun.

Tetapi tetap terjadi salah picking.

Mengapa?

Ternyata:

SKU memiliki packaging yang hampir sama,

lokasi penyimpanan berdekatan,

label sulit dibaca,

barcode tidak digunakan secara konsisten,

WMS masih memungkinkan manual input,

tidak ada validation,

dan tidak ada error-proofing.

Sekarang masalahnya bukan sekadar People.

System ikut berkontribusi.

System dalam Fishbone 3P dapat mencakup:

SOP

Work Instruction

Process

Workflow

WMS

ERP

Technology

Equipment

Layout

Material Flow

Information Flow

KPI

Measurement

Planning

Standard

Control Mechanism

Pertanyaan utamanya:

"Apakah sistem telah didesain untuk membuat pekerjaan yang benar menjadi mudah dan pekerjaan yang salah menjadi sulit?"

Ini adalah pertanyaan Continuous Improvement yang sangat penting.

Jangan Membuat Sistem yang Bergantung pada Kesempurnaan Manusia

Ini salah satu prinsip yang sering dilupakan.

Kalau sebuah proses hanya bisa berjalan dengan baik apabila:

"Operator harus sangat teliti."

maka sebenarnya kita mempunyai proses yang masih lemah.

Manusia bisa lelah.

Manusia bisa lupa.

Manusia bisa terdistraksi.

Manusia bisa salah.

Karena itu, Continuous Improvement berusaha membuat sistem yang mampu mencegah atau mendeteksi kesalahan manusia.

Misalnya:

Barcode scanning.

System validation.

Poka-yoke.

Visual control.

Interlock.

Automatic alert.

Standard work.

Semakin matang sistemnya, semakin kecil ketergantungannya pada "ingat-ingatan" manusia.

3. CULTURE — Apakah Budayanya Mendukung?

Ini dimensi yang sering tidak terlihat.

Sebuah perusahaan mungkin memiliki:

People yang kompeten.

System yang bagus.

Tetapi improvement tetap tidak bertahan.

Mengapa?

Karena Culture tidak mendukung.

Misalnya perusahaan sudah memiliki standar 5R.

Semua orang tahu caranya.

Tools tersedia.

Label tersedia.

Area sudah ditentukan.

Tetapi setelah beberapa minggu:

Warehouse kembali berantakan.

Kenapa?

Karena ada mindset:

"Yang penting pekerjaan selesai."

Atau:

"5R itu hanya untuk audit."

Atau:

"Kalau menemukan masalah, nanti malah disalahkan."

Atau:

"Itu bukan tanggung jawab saya."

Ini bukan lagi masalah skill.

Ini masalah Culture.

Culture Menjawab Pertanyaan: "Will They?"

Kalau People bertanya:

"Can they?"

Apakah mereka mampu?

System bertanya:

"Can the system?"

Apakah sistem memungkinkan?

Culture bertanya:

"Will they?"

Apakah mereka mau dan terbiasa melakukannya?

Karena orang yang mampu tetapi tidak mau tetap menghasilkan masalah.

Dan orang yang mau tetapi sistemnya tidak mendukung juga akan kesulitan menghasilkan performance.

People, System, Culture Harus Bekerja Bersama

Bayangkan sebuah perusahaan ingin meningkatkan Inventory Accuracy.

Target: 99,8%

Actual: 97,5%

Kita lakukan Fishbone 3P.

PEOPLE

Operator kurang memahami transaction process.

Training belum merata.

Skill antar shift berbeda.

Awareness terhadap inventory accuracy rendah.

SYSTEM

WMS masih memungkinkan manual adjustment.

Location control lemah.

SOP belum jelas.

Cycle count belum optimal.

Tidak ada barcode validation.

CULTURE

Stock discrepancy dianggap biasa.

Adjustment digunakan sebagai jalan keluar.

Tidak ada ownership terhadap inventory.

Fokus utama hanya shipment.

Root cause jarang dibahas.

Sekarang kita mempunyai gambaran yang lebih lengkap.

Masalah inventory bukan hanya:

"Operator salah."

Tetapi bisa merupakan kombinasi:

People + System + Culture.

3P Membantu Menghindari Blaming Culture

Ini mungkin salah satu manfaat terbesar Fishbone 3P.

Ketika terjadi masalah, kita tidak langsung mengatakan:

"People problem."

Kita memeriksa:

People?

↓

System?

↓

Culture?

Misalnya seorang operator salah melakukan transaksi.

Bisa jadi:

People: belum memahami proses.

Tetapi bisa juga:

System: interface terlalu rumit.

Atau:

Culture: transaksi sering ditunda karena organisasi lebih menghargai kecepatan daripada akurasi.

Ketiga masalah tersebut membutuhkan solusi yang berbeda.

Jangan Semua Masalah Diselesaikan dengan Training

Ini adalah salah satu penyakit organisasi.

Setiap kali terjadi masalah:

Training!

Picking error?

→ Training.

Quality defect?

→ Training.

Safety incident?

→ Training.

Inventory discrepancy?

→ Training.

Padahal training bukan obat untuk semua masalah.

Kalau masalahnya adalah:

System

training tidak menyelesaikan system.

Kalau masalahnya adalah:

Culture

training saja juga tidak cukup.

Bayangkan operator sudah dilatih lima kali.

Tetapi WMS tetap memungkinkan salah transaksi.

Apa yang terjadi?

Error akan tetap muncul.

Karena yang diperbaiki adalah People, sementara penyebabnya berada di System.

Begitu Juga Sebaliknya

Jangan semua masalah diselesaikan dengan membeli teknologi.

Misalnya:

"Picking error tinggi. Kita beli automation."

Padahal:

SOP belum jelas,

data master belum bersih,

slotting buruk,

operator belum memahami proses.

Teknologi yang mahal tidak otomatis membuat proses menjadi baik.

Kita bisa memiliki:

WMS terbaik.

Automation terbaik.

Scanner terbaik.

Tetapi jika Culture-nya:

"Yang penting target tercapai."

maka orang masih bisa mencari jalan pintas.

Culture Sering Menjadi Faktor yang Paling Sulit Dilihat

People bisa dilihat.

System bisa dipetakan.

Tetapi Culture sering tersembunyi.

Culture terlihat dari perilaku sehari-hari.

Misalnya:

Ketika ada masalah, apakah orang berkata:

"Mari kita cari penyebabnya."

atau:

"Siapa yang salah?"

Ketika ada ide improvement, apakah manager berkata:

"Coba kita uji."

atau:

"Dari dulu juga sudah seperti itu."

Ketika KPI turun, apakah organisasi berkata:

"Apa yang bisa kita perbaiki?"

atau:

"Siapa yang harus bertanggung jawab?"

Jawaban-jawaban tersebut menunjukkan culture.

Fishbone 3P dan Gemba

Fishbone 3P sebaiknya tidak dibuat hanya di ruang meeting.

Setelah menemukan problem, turunlah ke Gemba.

Lihat langsung.

Dengarkan operator.

Amati proses.

Periksa sistem.

Perhatikan perilaku.

Misalnya kita menemukan:

Loading Delay

Jangan hanya melihat dashboard.

Turun ke loading area.

Kemudian mungkin ditemukan:

People: manpower loading kurang.

System: staging process tidak terstandardisasi.

Culture: setiap departemen bekerja berdasarkan target masing-masing, bukan target end-to-end.

Sekarang kita memahami masalah dengan lebih baik.

Fishbone 3P Setelah Pareto

Dalam alur Continuous Improvement, Fishbone 3PSC sangat cocok ditempatkan setelah Pareto.

Contohnya:

Problem Identification

Kita menemukan:

Warehouse error meningkat.

↓

Data Collection

Kumpulkan data.

↓

Stratification

Kelompokkan berdasarkan jenis error.

↓

Pareto

Ternyata:

Wrong SKU = 42%

↓

Fishbone 3P

PEOPLE

Skill

Training

Awareness

SYSTEM

WMS

Label

Layout

SOP

Barcode

CULTURE

Discipline

Ownership

Improvement mindset

↓

5 Why

Pilih penyebab yang paling signifikan.

↓

Root Cause

↓

Improvement

↓

PDCA

↓

Standardization

Ini membuat Fishbone bukan sekadar gambar.

Tetapi menjadi bagian dari problem-solving journey.

3P Tidak Menggantikan 6M

Perlu digarisbawahi:

Fishbone 3P bukan berarti 6M salah.

6M tetap sangat berguna.

Terutama ketika kita membutuhkan analisis teknis yang lebih detail.

3P lebih tepat digunakan sebagai simplifikasi dan cara berpikir manajerial.

Kita bisa melakukan:

6M

untuk deep technical analysis.

Sedangkan:

3P

untuk high-level diagnosis.

Misalnya:

Machine

Material

Method

Measurement

Environment

dapat kita lihat lebih luas sebagai bagian dari:

SYSTEM

Sementara:

Man

menjadi:

PEOPLE

Dan faktor perilaku organisasi dapat kita eksplisitkan sebagai:

CULTURE

Mengapa 3P Menarik untuk Manager?

Karena seorang manager tidak selalu membutuhkan diagram yang sangat kompleks pada tahap awal.

Manager membutuhkan tiga pertanyaan sederhana:

PEOPLE

Apakah mereka mampu?

SYSTEM

Apakah sistemnya mendukung?

CULTURE

Apakah organisasi mendorong perilaku yang benar?

Dari tiga pertanyaan tersebut, kita bisa menentukan ke mana problem solving harus diarahkan.

Contoh: Overtime Warehouse Terlalu Tinggi

Misalnya overtime:

Target: 5%

Actual:

12%

Kita tidak langsung mengatakan:

"Kurang manpower."

Gunakan 3P.

PEOPLE

Skill tidak merata.

Banyak operator baru.

Produktivitas per orang rendah.

Fatigue.

SYSTEM

Wave planning tidak optimal.

Cut-off terlalu dekat.

Layout menyebabkan excessive motion.

WMS belum optimal.

Scheduling tidak sesuai demand pattern.

CULTURE

Overtime dianggap normal.

Orang terbiasa menyelesaikan masalah dengan lembur.

Tidak ada budaya mencari root cause.

Planning failure dianggap sebagai masalah operasional.

Sekarang terlihat bahwa:

Overtime bukan selalu masalah manpower.

Bisa jadi masalah:

People + System + Culture.

Dan Di Sinilah Continuous Improvement Menjadi Dewasa

Organisasi yang belum matang biasanya melihat:

Problem → Person

Organisasi yang mulai berkembang melihat:

Problem → Process

Organisasi yang lebih matang melihat:

Problem → People + System + Culture

Karena masalah operasional hampir selalu merupakan hasil interaksi ketiganya.

Formula Sederhana Fishbone 3P

Kalau ingin dibuat sangat sederhana, kita bisa menggunakan formula:

PROBLEM = PEOPLE × SYSTEM × CULTURE

Bukan rumus matematika literal, tetapi cara untuk mengingat bahwa ketiganya saling berinteraksi.

People menjalankan pekerjaan.

System mengarahkan pekerjaan.

Culture menentukan bagaimana orang menjalankan dan mempertahankan pekerjaan tersebut.

Kalau salah satunya lemah, performance bisa terganggu.

Tetapi Ada Satu Hal yang Harus Diingat

Tidak semua masalah membutuhkan ketiga faktor sekaligus.

Kadang root cause memang:

People.

Kadang:

System.

Kadang:

Culture.

Dan kadang merupakan kombinasi ketiganya.

Jangan memaksakan semua masalah masuk ke tiga kategori hanya agar diagram terlihat lengkap.

Tujuan Fishbone bukan membuat semua kotak terisi.

Tujuannya adalah:

menemukan penyebab yang benar.

Dari Fishbone Menuju Root Cause

Fishbone hanya menghasilkan:

Potential Causes.

Belum tentu:

Root Causes.

Karena itu setelah Fishbone, kita masih membutuhkan:

Data

Gemba

Observation

5 Why

Validation

Baru kemudian kita bisa mengatakan:

"Ini adalah root cause."

Dan setelah itu barulah:

Countermeasure.

Penutup

Fishbone Diagram mengajarkan kita untuk tidak terburu-buru menyimpulkan penyebab masalah.

Tetapi kita bisa menyederhanakan cara berpikir tersebut menjadi tiga pertanyaan besar:

PEOPLE — Apakah orangnya mampu?

SYSTEM — Apakah sistemnya mendukung?

CULTURE — Apakah budayanya mendorong?

Tiga hal ini sering kali menjadi akar dari berbagai masalah operasional.

Orang yang kompeten tidak akan banyak membantu jika sistemnya buruk.

Sistem yang bagus tidak akan optimal jika orang tidak memiliki kemampuan.

Dan People serta System yang bagus pun bisa gagal mempertahankan improvement jika Culture tidak mendukung.

Karena itu:

People membuat pekerjaan berjalan.

System membuat pekerjaan terstruktur.

Culture membuat perbaikan bertahan.

Dan mungkin inilah cara paling sederhana untuk melihat sebuah masalah:

Jangan langsung menyalahkan People.

Periksa System.

Kemudian lihat Culture.

Karena dalam Continuous Improvement, tujuan kita bukan menemukan siapa yang salah.

Tujuan kita adalah menemukan:

apa yang harus diperbaiki agar kesalahan yang sama tidak perlu terjadi lagi.

Dan ketika cara berpikir ini mulai menjadi kebiasaan, Fishbone bukan lagi sekadar sebuah diagram.

Ia menjadi cara organisasi melihat masalah.

Fishbone Diagram dalam Continuous Improvement

Jangan Terburu-buru Mencari Solusi Sebelum Memahami Penyebab Masalah

Dalam Continuous Improvement, ada satu kebiasaan yang sering dilakukan banyak perusahaan.

Ketika masalah muncul, kita langsung mencari solusi.

Picking error meningkat? Training operator.

Delivery terlambat? Tambah armada.

Produktivitas turun? Tambah manpower.

Mesin sering berhenti? Beli mesin baru.

Stock discrepancy? Perketat stock opname.

Semua terdengar masuk akal.

Tetapi ada satu pertanyaan yang sering terlupakan:

"Apakah kita sudah benar-benar memahami penyebab masalahnya?"

Karena masalah yang terlihat belum tentu merupakan akar masalah.

Dan di sinilah Fishbone Diagram menjadi salah satu tools penting dalam Continuous Improvement.

Apa Itu Fishbone Diagram?

Fishbone Diagram dikenal juga sebagai:

Ishikawa Diagram

Cause-and-Effect Diagram

Cause & Effect Analysis

Disebut Fishbone karena bentuk diagramnya menyerupai tulang ikan.

Di bagian kepala ikan terdapat masalah atau effect.

Kemudian dari garis utama muncul beberapa "tulang" yang mewakili berbagai kelompok kemungkinan penyebab.

Secara sederhana:

CAUSE → CAUSE → CAUSE → EFFECT

Tujuannya bukan langsung menemukan satu jawaban.

Tujuannya adalah:

Membantu tim melihat masalah dari berbagai sudut pandang dan mengidentifikasi kemungkinan penyebab secara sistematis.

Mengapa Tidak Langsung Menggunakan 5 Why?

Ini pertanyaan yang menarik.

Kalau kita sudah memiliki 5 Why, mengapa masih membutuhkan Fishbone?

Karena keduanya memiliki fungsi yang berbeda.

Fishbone digunakan untuk memetakan kemungkinan penyebab.

Sedangkan 5 Why digunakan untuk menggali lebih dalam salah satu penyebab tersebut.

Jadi keduanya bukan kompetitor.

Justru saling melengkapi.

Contohnya:

Problem: Picking Error

Fishbone membantu kita melihat:

Man

Method

Machine

Material

Measurement

Environment

Setelah itu kita menemukan bahwa Material: SKU memiliki kemasan yang sangat mirip merupakan salah satu penyebab potensial.

Kemudian kita lakukan 5 Why terhadap penyebab tersebut.

Fishbone Tidak Mencari Siapa yang Salah

Ini salah satu filosofi terpenting.

Ketika terjadi kesalahan, organisasi sering mencari:

"Siapa yang melakukan kesalahan?"

Continuous Improvement justru bertanya:

"Mengapa sistem memungkinkan kesalahan itu terjadi?"

Misalnya terjadi salah picking.

Cara berpikir tradisional:

Operator tidak teliti.

Selesai.

Tetapi Fishbone memaksa kita melihat lebih luas.

Mungkin:

Man

Operator belum cukup familiar dengan SKU.

Method

SOP picking tidak memberikan metode verifikasi yang memadai.

Machine

Scanner tidak selalu digunakan.

Material

Dua SKU memiliki kemasan yang hampir identik.

Measurement

Tidak ada monitoring picking error secara real-time.

Environment

Lokasi kedua SKU terlalu berdekatan.

Sekarang masalah terlihat jauh lebih kompleks.

Dan justru dari sinilah improvement yang sebenarnya bisa dimulai.

Menggunakan 6M

Salah satu pendekatan paling populer dalam Fishbone adalah 6M.

1. Man

Berkaitan dengan manusia.

Contohnya:

skill,

knowledge,

training,

experience,

fatigue,

workload,

manpower,

human error.

Tetapi hati-hati.

"Operator tidak teliti" bukan otomatis root cause.

Itu baru sebuah kemungkinan.

Kita tetap harus bertanya:

Mengapa operator bisa melakukan kesalahan tersebut?

2. Method

Berkaitan dengan cara kerja.

Misalnya:

SOP,

Work Instruction,

Standard Work,

workflow,

sequence,

approval,

inspection procedure.

Kadang masalah bukan karena orang tidak mengikuti SOP.

Masalahnya justru:

SOP-nya sendiri tidak efektif.

3. Machine

Berkaitan dengan mesin, equipment, dan teknologi.

Misalnya:

forklift,

conveyor,

barcode scanner,

weighing scale,

WMS,

printer,

automation,

sensor.

Contohnya:

Picking error terjadi karena barcode scanner sering gagal membaca barcode.

Jika kita hanya melakukan training operator, masalah tidak akan selesai.

4. Material

Berkaitan dengan material atau produk.

Misalnya:

ukuran,

bentuk,

packaging,

kualitas,

labeling,

SKU similarity,

material handling characteristics.

Dalam warehouse, kategori ini sangat penting.

Dua SKU yang memiliki bentuk dan kemasan hampir sama dapat meningkatkan risiko salah picking.

5. Measurement

Berkaitan dengan pengukuran dan data.

Misalnya:

KPI,

accuracy,

measurement method,

frequency,

calibration,

data accuracy,

reporting system.

Kadang perusahaan sebenarnya memiliki masalah, tetapi tidak menyadarinya karena cara mengukurnya salah.

6. Mother Nature / Environment

Berkaitan dengan lingkungan kerja.

Misalnya:

layout,

lighting,

temperature,

noise,

humidity,

space,

ergonomics,

congestion.

Dalam warehouse, layout bisa sangat menentukan.

Jarak yang terlalu jauh.

Aisle terlalu sempit.

SKU yang mirip diletakkan berdekatan.

Pencahayaan kurang.

Semua bisa menjadi penyebab.

Contoh Fishbone di Warehouse

Mari kita ambil sebuah kasus:

Picking Error meningkat.

Kemudian kita lakukan brainstorming menggunakan 6M.

MAN

Operator baru

Training belum cukup

Fatigue

Manpower kurang

Kurang familiar dengan SKU

METHOD

SOP tidak jelas

Tidak ada double check

Tidak ada standard scanning

Picking sequence tidak optimal

MACHINE

Scanner error

Printer label bermasalah

WMS lambat

Battery scanner habis

MATERIAL

SKU mirip

Packaging sama

Barcode sulit dibaca

Label mudah rusak

MEASUREMENT

KPI hanya melihat quantity

Error tidak dikategorikan

Tidak ada real-time monitoring

Data error tidak akurat

ENVIRONMENT

Lighting kurang

Lokasi SKU terlalu dekat

Layout tidak optimal

Area terlalu padat

Sekarang kita mempunyai peta kemungkinan penyebab.

Dan inilah kekuatan Fishbone.

Tetapi Fishbone Bukan Bukti

Ini bagian yang sangat penting.

Ketika tim membuat Fishbone, biasanya akan muncul banyak kemungkinan penyebab.

Tetapi:

Kemungkinan penyebab ≠ akar masalah.

Misalnya tim menulis:

Training operator kurang.

Apakah benar?

Belum tentu.

Harus dibuktikan dengan data.

Misalnya setelah dianalisis:

Operator yang sudah mengikuti training:

Error = 1,2%

Operator yang belum mengikuti training:

Error = 1,3%

Ternyata perbedaannya kecil.

Berarti training mungkin bukan faktor utama.

Sebaliknya:

SKU yang memiliki packaging mirip:

Error = 7,5%

SKU dengan packaging berbeda:

Error = 0,8%

Sekarang kita mempunyai indikasi yang lebih kuat.

Fishbone membantu kita membuat hipotesis.

Data membantu kita menguji hipotesis tersebut.

Di Sini Gemba Menjadi Penting

Fishbone sebaiknya tidak dibuat hanya di ruang meeting.

Jangan hanya:

Manager + Supervisor + PPT + Whiteboard.

Kemudian semua orang menebak-nebak penyebab.

Lebih baik:

Go to Gemba.

Pergi ke tempat masalah terjadi.

Lihat prosesnya.

Amati operator.

Lihat material.

Periksa sistem.

Tanyakan kepada orang yang melakukan pekerjaan.

Kadang operator justru mengetahui masalah yang tidak terlihat dalam laporan management.

Misalnya:

"Pak, sebenarnya scanner ini sering error. Tetapi kalau kami laporkan, biasanya dianggap masalah operator."

Kalimat seperti itu bisa membuka mata.

Karena itu:

Data tells you where to look. Gemba tells you what is actually happening.

Fishbone Harus Menghindari "Blaming"

Bayangkan sebuah perusahaan memiliki masalah:

Delivery terlambat.

Fishbone pertama:

Man → Driver tidak disiplin.

Selesai?

Belum.

Coba kita gali.

Man

→ Driver terlambat.

Method

→ Scheduling belum optimal.

Machine

→ Kendaraan sering breakdown.

Material

→ Loading preparation terlambat.

Measurement

→ KPI hanya mengukur delivery, bukan loading lead time.

Environment

→ Kemacetan di jalur tertentu.

Sekarang kita melihat bahwa masalah delivery bukan hanya masalah driver.

Bisa jadi driver hanya berada di ujung proses yang menghasilkan keterlambatan.

Fishbone Membantu Mengubah Cara Berpikir

Tanpa Fishbone:

Problem → Blame → Solution

Dengan Fishbone:

Problem → Possible Causes → Data → Root Cause → Countermeasure

Ini perubahan yang sangat besar.

Karena Continuous Improvement bukan bertujuan mencari orang yang salah.

Continuous Improvement bertujuan:

membuat proses menjadi lebih baik.

Fishbone dan Pareto

Fishbone akan semakin kuat ketika digunakan bersama Pareto.

Keduanya memiliki fungsi berbeda.

Pareto

Menjawab:

"Masalah mana yang paling dominan?"

Fishbone

Menjawab:

"Apa saja kemungkinan penyebab masalah tersebut?"

Contoh:

Data menunjukkan ada 1.000 warehouse errors.

Pareto menunjukkan:

Wrong SKU = 420

Maka kita fokus pada Wrong SKU.

Kemudian Fishbone digunakan:

Wrong SKU

→ Man

→ Method

→ Machine

→ Material

→ Measurement

→ Environment

Setelah itu kita validasi penyebab dengan data.

Jadi alurnya:

Data

↓

Pareto

↓

Fishbone

↓

Validation

↓

5 Why

↓

Root Cause

Ini jauh lebih kuat daripada sekadar membuat Fishbone tanpa data.

Fishbone dan 5 Why

Setelah Fishbone dibuat, kita dapat memilih penyebab yang paling signifikan untuk dianalisis lebih lanjut menggunakan 5 Why.

Misalnya:

Problem: Wrong SKU

Fishbone menunjukkan:

Material → SKU memiliki packaging yang mirip.

Kemudian 5 Why:

Why 1

Mengapa operator mengambil SKU yang salah?

→ Karena SKU A dan B memiliki packaging yang mirip.

Why 2

Mengapa SKU tersebut dapat tertukar?

→ Karena lokasinya berdekatan.

Why 3

Mengapa lokasinya berdekatan?

→ Karena slotting hanya berdasarkan movement.

Why 4

Mengapa slotting hanya berdasarkan movement?

→ Karena similarity SKU belum menjadi parameter slotting.

Why 5

Mengapa similarity SKU belum menjadi parameter?

→ Karena belum ada standard untuk mengidentifikasi dan mengendalikan similar SKU.

Sekarang kita mulai mendekati root cause.

Jangan Berhenti pada "Human Error"

Ini mungkin salah satu pelajaran terbesar dari Fishbone.

Human Error sering kali merupakan akibat, bukan akar masalah.

Jika seseorang salah memasukkan data, tanyakan:

Apakah sistem memberikan warning?

Apakah interface-nya membingungkan?

Apakah prosesnya terlalu manual?

Apakah SOP jelas?

Apakah workload terlalu tinggi?

Apakah data yang diberikan benar?

Apakah orang tersebut sudah dilatih?

Dengan demikian kita menggeser perspektif:

Human Error

menjadi:

Human + Process + System + Environment

Dan ini membuat improvement menjadi lebih sustainable.

Fishbone dalam Manufacturing

Fishbone sangat populer dalam manufacturing.

Misalnya:

Defect Rate meningkat.

Kemungkinan penyebab:

Man

Skill operator.

Machine

Machine setting.

Method

Work instruction.

Material

Raw material variation.

Measurement

Inspection method.

Environment

Temperature atau humidity.

Kemudian setiap kemungkinan penyebab diuji.

Bukan berdasarkan opini.

Tetapi berdasarkan:

data + observation + experiment.

Fishbone dalam Warehouse

Dalam warehouse, Fishbone bisa digunakan untuk menganalisis:

Picking Error

Putaway Error

Inventory Discrepancy

Damaged Goods

Late Shipment

Loading Delay

Receiving Delay

Productivity Drop

Excessive Overtime

Space Utilization

Stock Accuracy

Delivery Error

Jadi Fishbone bukan hanya tool manufacturing.

Ia sangat relevan untuk:

Warehouse

Logistics

Supply Chain

Procurement

Quality

Production

bahkan office process.

Kesalahan Umum dalam Membuat Fishbone

1. Terlalu cepat menyimpulkan

"Operator tidak teliti."

Padahal belum ada bukti.

2. Semua kemungkinan dianggap root cause

Fishbone hanya menghasilkan potential causes.

3. Tidak menggunakan data

Brainstorming saja tidak cukup.

4. Tidak melakukan Gemba

Masalah bisa berbeda antara laporan dan kondisi lapangan.

5. Terlalu banyak penyebab

Fishbone bukan tempat untuk memasukkan semua kemungkinan tanpa prioritas.

6. Berhenti setelah Fishbone

Setelah Fishbone harus ada validation dan root cause analysis.

Fishbone Bukan Sekadar Diagram

Kalau hanya menggambar tulang ikan di whiteboard, Fishbone tidak akan menghasilkan improvement.

Nilai sebenarnya ada pada proses berpikir di baliknya:

Observe

↓

Question

↓

Analyze

↓

Validate

↓

Improve

Fishbone membantu tim untuk tidak terjebak pada satu asumsi.

Dari "Siapa yang Salah?" Menjadi "Apa yang Salah dalam Sistem?"

Inilah perubahan mindset yang paling penting.

Organisasi yang masih menggunakan pendekatan lama bertanya:

"Siapa yang melakukan kesalahan?"

Organisasi yang mulai menerapkan Continuous Improvement bertanya:

"Proses apa yang memungkinkan kesalahan tersebut terjadi?"

Dan organisasi yang sudah matang bertanya lebih jauh:

"Bagaimana kita mendesain proses agar kesalahan tersebut sulit terjadi kembali?"

Inilah yang kemudian membawa kita menuju konsep:

Poka-Yoke.

Bukan hanya memperbaiki manusia.

Tetapi memperbaiki sistem agar manusia lebih sulit melakukan kesalahan.

Penutup

Fishbone Diagram pada dasarnya adalah sebuah alat sederhana.

Gambarnya hanya seperti tulang ikan.

Tetapi cara berpikir di baliknya sangat penting.

Karena ketika masalah terjadi, kita sering tergoda untuk mencari jawaban tercepat.

Operator salah.

Mesin rusak.

Supplier terlambat.

Sistem bermasalah.

Padahal jawaban pertama belum tentu jawaban yang benar.

Fishbone mengajarkan kita untuk berhenti sejenak dan berkata:

"Mari kita lihat masalah ini dari berbagai sisi."

Man.

Method.

Machine.

Material.

Measurement.

Environment.

Kemudian setiap kemungkinan penyebab diuji dengan data.

Karena dalam Continuous Improvement:

Kita tidak memperbaiki apa yang kita asumsikan sebagai masalah. Kita memperbaiki apa yang benar-benar terbukti menjadi penyebab masalah.

Dan pada akhirnya, tujuan Fishbone bukan menghasilkan diagram yang indah.

Tujuannya adalah menemukan root cause sehingga kita tidak hanya memadamkan api.

Tetapi menemukan mengapa api terus muncul.

Karena Continuous Improvement bukan tentang memperbaiki masalah yang sama berulang kali.

Continuous Improvement adalah membuat masalah yang sama tidak perlu terjadi lagi.