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.

Pareto dalam Continuous Improvement

Mengapa Kita Tidak Harus Memperbaiki Semuanya Sekaligus?

80% Masalah Sering Kali Berasal dari Sebagian Kecil Penyebab

Dalam dunia operasional, ada satu jebakan yang sering dialami manager. Ketika melihat banyak masalah, ia ingin memperbaiki semuanya.

Stock discrepancy.

Picking error.

Late delivery.

Barang rusak.

Overtime.

Rework.

Waiting time.

Komplain customer.

Semua dianggap penting. Akhirnya semua dibuatkan action plan. Semua diberi target. Semua dimonitor. Semua menjadi prioritas.

Masalahnya?

Kalau semuanya prioritas, sebenarnya tidak ada yang menjadi prioritas. Di sinilah konsep Pareto menjadi sangat penting dalam Continuous Improvement. Pareto mengajarkan sebuah prinsip sederhana:

Jangan mencoba menyelesaikan semua masalah. Cari beberapa penyebab yang memberikan dampak terbesar, lalu fokuskan energi di sana.

Apa Itu Pareto?

Konsep Pareto berasal dari nama ekonom Italia, Vilfredo Pareto, yang pada akhir abad ke-19 mengamati bahwa distribusi kekayaan tidak merata. Dari pengamatan tersebut berkembang gagasan yang kemudian dikenal luas sebagai:

Pareto Principle atau 80/20 Rule.

Secara sederhana: Sebagian besar hasil biasanya berasal dari sebagian kecil penyebab. Sering digambarkan sebagai: 

80% Effect ← 20% Causes

Tetapi angka 80 dan 20 jangan dianggap sebagai hukum matematika yang harus selalu tepat. Bisa saja: 70/30. 90/10. 95/5. Yang penting adalah konsepnya: Ada beberapa penyebab yang jauh lebih dominan dibandingkan penyebab lainnya. Dan tugas seorang Continuous Improvement practitioner adalah menemukan penyebab dominan tersebut.

Pareto Bukan Sekadar Grafik

Banyak orang mengenal Pareto hanya sebagai grafik dengan batang yang semakin mengecil dan garis kumulatif. Padahal kekuatan Pareto bukan pada grafiknya. Kekuatan Pareto ada pada cara berpikir. Ketika terdapat 100 masalah, pertanyaannya bukan:

"Bagaimana kita menyelesaikan 100 masalah?"

Tetapi: "Dari 100 masalah tersebut, mana 20% yang menghasilkan 80% dampaknya?"

Itulah perubahan cara berpikir. Contoh di Warehouse Bayangkan sebuah warehouse mengalami berbagai jenis error selama satu bulan. Data menunjukkan:

Jenis Error Jumlah

Salah SKU 420

Salah quantity 210

Salah lokasi 130

Damaged 80

Label salah 60

Dokumen 40

Lain-lain 60

Total: 1.000 error.

Sekilas semua masalah terlihat penting. Tetapi lihat datanya.

Salah SKU: 420 kasus

Salah quantity: 210 kasus

Salah lokasi: 130 kasus

Tiga kategori tersebut sudah menghasilkan: 760 kasus.

Artinya sekitar 76% dari seluruh error berasal dari hanya tiga kategori. Sekarang manager memiliki pilihan.

Pilihan A, Membuat tujuh program improvement sekaligus.

atau: Pilihan B, Memfokuskan energi terlebih dahulu pada tiga masalah terbesar.

Continuous Improvement akan lebih memilih: Pilihan B.

Mengapa Fokus Itu Penting?

Karena sumber daya perusahaan terbatas. Waktu terbatas. Orang terbatas. Budget terbatas. Energi manager terbatas. Kemampuan analisis juga terbatas. Jika semua masalah dikerjakan sekaligus, kemungkinan besar tidak ada satu pun yang diselesaikan secara mendalam. Sebaliknya, jika kita memilih masalah terbesar, sumber daya dapat dikonsentrasikan.

Misalnya: 

Masalah utama: Salah SKU

Kemudian dilakukan:

Gemba walk,

process mapping,

5 Why,

Fishbone Diagram,

observation,

data analysis,

dan trial improvement.

Dengan fokus seperti ini, kemungkinan mendapatkan improvement yang signifikan jauh lebih besar.

Pareto Membantu Menjawab "Mulai dari Mana?"

Ini sebenarnya fungsi Pareto yang paling penting.

Bukan: "Apa saja masalah kita?"

Tetapi: "Masalah mana yang harus kita selesaikan terlebih dahulu?"

Dalam Continuous Improvement, ini sangat penting. Karena proses improvement biasanya dimulai dari:

Problem Identification

↓

Prioritization

↓

Root Cause Analysis

↓

Countermeasure

↓

Implementation

↓

Control

Pareto membantu terutama pada tahap: Prioritization.

Jangan Salah Memahami 80/20

Ada satu kesalahan yang sering terjadi. Orang menganggap: "Kalau sudah menemukan 20%, berarti 80% masalah selesai."

Tidak selalu. Pareto bukan jaminan. Pareto adalah alat untuk memfokuskan perhatian. Misalnya 20% penyebab menghasilkan 70% masalah. Maka kita fokus pada 20% tersebut. Setelah diperbaiki, kita membuat Pareto baru. Dan mungkin masalah terbesar berikutnya muncul.

Kemudian kita perbaiki lagi. Lalu buat Pareto baru. Inilah yang membuat Pareto sangat cocok dengan Continuous Improvement.

Pareto Bukan Sekali Pakai

Bayangkan seperti ini.

Pareto #1 Masalah terbesar:

Picking Error

↓

Improvement

↓

Error turun 40%.

Kemudian kita membuat Pareto baru.

Pareto #2 Masalah terbesar: 

Replenishment Delay

↓

Improvement

↓

Performance meningkat.

Kemudian Pareto dibuat lagi.

Pareto #3 Masalah terbesar:

Putaway Delay

Begitu seterusnya. Artinya Pareto adalah living tool. Ia berubah mengikuti kondisi proses.

Dari Problem Pareto ke Cause Pareto

Ini bagian yang sangat penting. Pareto dapat digunakan bukan hanya untuk mengelompokkan jenis masalah, tetapi juga untuk mencari penyebab masalah.

Misalnya:

Problem: Picking Error

Kemudian kita pecah berdasarkan penyebab.

Penyebab Jumlah

Similar SKU 180

Human error 90

Wrong location 70

Label unclear 50

System issue 30

Other 20

Sekarang kita mengetahui sesuatu. Masalah terbesar bukan sekadar: "Operator tidak teliti."

Ternyata: Similar SKU adalah penyebab terbesar.

Maka solusi yang tepat mungkin bukan training operator. Tetapi:

memperbaiki slotting,

membuat visual differentiation,

menggunakan barcode,

memperjelas label,

atau menambahkan system validation.

Inilah contoh bagaimana Pareto membantu kita bergerak dari: Symptom

menuju: Cause.

Jangan Langsung Menyalahkan Operator

Ini adalah pelajaran penting dalam Continuous Improvement. Misalnya Pareto menunjukkan: Human Error = 40%.

Kesimpulannya jangan langsung: "Operator harus training."

Tanyakan: Mengapa human error terjadi?

Apakah:

SOP tidak jelas?

Instruksi terlalu rumit?

Label membingungkan?

Sistem memungkinkan input salah?

Layout tidak ergonomis?

Target terlalu tinggi?

Manpower kurang?

Fatigue?

Training tidak memadai?

Dengan kata lain: Human error bisa jadi symptom, bukan root cause.

Pareto membantu menemukan area yang perlu diteliti. Tetapi root cause tetap harus dicari melalui analisis lanjutan.

Pareto dan Lean Thinking

Pareto sangat dekat dengan filosofi Lean. Lean selalu berusaha menghilangkan: Waste.

Tetapi waste juga sangat banyak. Ada: 

Defect

Overproduction

Waiting

Non-utilized Talent

Transportation

Inventory

Motion

Extra Processing

Jika semua waste ingin diperbaiki sekaligus, tim akan kewalahan. Maka Pareto digunakan untuk menentukan: Waste mana yang paling besar dampaknya terhadap customer dan business performance?

Misalnya:

Waiting = 40%

Motion = 25%

Defect = 20%

Inventory = 10%

Transportation = 5%

Maka fokus awal bisa diarahkan pada: Waiting + Motion.

Pareto dalam Cost Improvement

Pareto juga sangat powerful dalam cost reduction. Misalnya perusahaan memiliki 500 supplier. Tidak semua supplier memberikan kontribusi biaya yang sama.

Bisa jadi: 20 supplier menyumbang 75% total purchasing value.

Maka manager Procurement tidak perlu memperlakukan 500 supplier dengan intensitas yang sama.

Fokuskan:

Vendor Management

Negotiation

Cost Reduction

Supplier Development

kepada supplier dengan kontribusi terbesar.

Hal yang sama dapat dilakukan terhadap:

SKU,

customer,

material,

spare part,

transport route,

overtime,

energy consumption.

Pareto dalam Inventory

Bayangkan warehouse memiliki: 10.000 SKU. Apakah semua SKU harus mendapatkan perlakuan yang sama? Tentu tidak. Biasanya terdapat sejumlah kecil SKU yang memiliki kontribusi besar terhadap:

demand,

revenue,

movement,

atau inventory value.

Di sinilah kita mengenal pendekatan ABC Analysis, yang secara filosofi memiliki hubungan erat dengan prinsip Pareto.

Misalnya:

A Items, 20% SKU → 80% value.

Maka item tersebut membutuhkan kontrol lebih ketat.

Lebih sering diperiksa.

Lebih diperhatikan availability-nya.

Lebih diperhatikan forecasting-nya.

Sedangkan item dengan kontribusi kecil dapat menggunakan kontrol yang lebih sederhana.

Ini adalah contoh bagaimana prinsip Pareto diterjemahkan menjadi sistem operasional.

Pareto dalam Customer Complaint

Bayangkan perusahaan menerima: 1.000 complaint.

Setelah dianalisis:

Delivery Delay → 400

Product Quality → 250

Wrong Item → 150

Packaging → 80

Documentation → 60

Other → 60

Sekarang kita tahu: Delivery Delay + Product Quality + Wrong Item, menghasilkan 80% complaint. Maka jangan membuat 20 proyek improvement. Fokuskan dulu pada tiga kategori tersebut. Jika ketiganya berhasil dikurangi secara signifikan, customer satisfaction kemungkinan ikut meningkat.

Pareto Membantu Manager Mengatakan "Tidak"

Ini mungkin fungsi Pareto yang paling underrated. Manager yang baik bukan hanya tahu apa yang harus dilakukan. Ia juga tahu: apa yang belum perlu dilakukan. Ketika ada 30 ide improvement, semuanya terlihat menarik. Tetapi tidak semuanya penting. Pareto membantu manager berkata: "Kita kerjakan tiga ini terlebih dahulu."

Bukan karena masalah lainnya tidak penting. Tetapi karena: impact-nya lebih kecil. Continuous Improvement bukan tentang melakukan sebanyak mungkin improvement. Continuous Improvement adalah tentang menghasilkan impact sebesar mungkin dengan sumber daya yang tersedia.

Pareto dan PDCA

Pareto juga dapat dimasukkan ke dalam siklus PDCA.

PLAN

Gunakan Pareto untuk menentukan masalah terbesar.

DO

Implementasikan countermeasure.

CHECK

Ukur hasilnya.

ACT

Standarisasi hasil dan cari masalah terbesar berikutnya.

Kemudian:

PDCA → Pareto → PDCA → Pareto → PDCA

Proses tersebut terus berulang.

Itulah Continuous Improvement.

Jangan Terjebak pada "80/20", Yang lebih penting daripada angka 80/20 adalah pertanyaan: "Di mana leverage terbesar kita?"

Bayangkan ada dua improvement. Improvement A Mengurangi masalah sebesar: 5%. Improvement B Mengurangi masalah sebesar: 40%. Jika sumber daya yang dibutuhkan hampir sama, tentu kita memilih B. Itulah cara berpikir Pareto. Cari high-impact improvement.

Pareto Bukan Alat untuk Mengabaikan Masalah Kecil

Ini juga penting. Masalah kecil bukan berarti boleh dibiarkan. Beberapa masalah yang jumlahnya kecil bisa memiliki dampak yang sangat besar.

Misalnya:

Safety incident. Jumlahnya hanya satu. Tetapi konsekuensinya bisa sangat besar. Maka jangan menggunakan Pareto secara buta. Dalam dunia Safety, Quality, dan Compliance, ada masalah yang harus ditangani meskipun frekuensinya rendah.

Karena yang penting bukan hanya:

Frequency

tetapi juga:

Severity

dan:

Risk.

Jadi Pareto harus dipadukan dengan risk assessment.

Pareto + Risk = Prioritas yang Lebih Cerdas

Seorang manager dapat menggabungkan: Frequency, Impact, Risk, Cost, Customer Impact, untuk menentukan prioritas.

Misalnya:

Problem A: Frekuensi tinggi, dampak rendah.

Problem B: Frekuensi rendah, dampak sangat tinggi.

Keduanya perlu perhatian. Namun pendekatan dan urgensinya berbeda. Karena itu, Continuous Improvement bukan sekadar: "Mana yang paling banyak?"

Tetapi: "Mana yang memberikan risiko dan dampak terbesar terhadap bisnis?"

Kesalahan Umum Menggunakan Pareto

Ada beberapa kesalahan yang sering terjadi.

1. Data terlalu sedikit

Kesimpulan dibuat dari data satu hari.

2. Kategori tidak jelas

Satu masalah bisa masuk ke beberapa kategori.

3. Menggunakan feeling

Pareto seharusnya berbasis data.

4. Berhenti setelah membuat grafik

Pareto bukan tujuan.

Ia adalah alat untuk menentukan tindakan.

5. Tidak melakukan Pareto ulang

Setelah improvement, data harus dianalisis kembali.

6. Menganggap 80/20 sebagai hukum pasti

Angka tersebut adalah prinsip, bukan aturan absolut.

Pareto Bukan Tentang 80 dan 20

Pada akhirnya, inilah inti dari Pareto. Bukan: 80%. Bukan: 20%. Tetapi: Fokus.

Di dalam perusahaan selalu ada terlalu banyak masalah. Dan tidak semua masalah memiliki bobot yang sama. Ada masalah yang menghabiskan energi tetapi memberikan dampak kecil. Ada masalah yang terlihat kecil tetapi sebenarnya merupakan sumber utama kerugian. Tugas Continuous Improvement adalah menemukan leverage point tersebut.

Penutup

Dalam dunia kerja, kita sering menganggap manager yang hebat adalah manager yang mampu menyelesaikan banyak masalah. Padahal belum tentu. Manager yang hebat justru tahu: masalah mana yang harus diselesaikan terlebih dahulu.

Karena waktu terbatas.

Orang terbatas.

Budget terbatas.

Energi terbatas.

Maka jangan bertanya: "Bagaimana kita memperbaiki semua masalah?"

Pertanyaan yang lebih baik adalah: "Masalah mana yang memberikan dampak terbesar, dan apa yang menjadi penyebab utamanya?"

Di situlah Pareto bekerja. Ia membantu kita melihat bahwa dari sekian banyak masalah, biasanya ada beberapa yang jauh lebih dominan. Temukan. Prioritaskan. Perbaiki. Ukur.

Kemudian buat Pareto berikutnya. Karena Continuous Improvement bukan tentang memperbaiki semuanya sekaligus. Continuous Improvement adalah tentang: memperbaiki hal yang paling penting, dengan cara yang paling efektif, kemudian bergerak ke masalah berikutnya. Dan mungkin inilah filosofi Pareto yang paling sederhana: Jangan sibuk memperbaiki 100 masalah kecil, ketika 3 masalah besar sedang menentukan kinerja perusahaan.

5R dalam Continuous Improvement

Mengapa Tempat Kerja yang Rapi Belum Tentu Produktif?

5R Bukan Sekadar Bersih-Bersih, Tetapi Cara Membangun Budaya Improvement

Ketika mendengar istilah 5R, sebagian orang langsung membayangkan aktivitas yang sederhana:

Menyapu lantai.

Merapikan meja.

Memberi label.

Membuang barang yang tidak diperlukan.

Kemudian mengambil foto sebelum dan sesudah.

Selesai.

Padahal, kalau 5R hanya dipahami sebagai kegiatan bersih-bersih, kita sedang kehilangan inti dari salah satu fondasi penting Continuous Improvement. 5R bukan tentang membuat tempat kerja terlihat bagus. 5R adalah tentang menciptakan tempat kerja yang lebih aman, lebih teratur, lebih mudah dikendalikan, dan lebih mudah untuk terus diperbaiki.

Karena dalam dunia operasional, kondisi tempat kerja sebenarnya adalah cermin dari kualitas sistem. Kalau sebuah warehouse berantakan, jangan hanya bertanya:

"Mengapa operator tidak mau merapikan?"

Tanyakan juga:

"Mengapa sistem kita memungkinkan kondisi berantakan ini terjadi berulang kali?"

Apa Itu 5R?

Di Indonesia, konsep 5R merupakan adaptasi dari prinsip Jepang yang dikenal sebagai 5S. Kelima prinsip tersebut adalah:

Ringkas

Rapi

Resik

Rawat

Rajin

Jika diterjemahkan ke dalam konsep Continuous Improvement, 5R dapat dipahami sebagai sebuah sistem untuk menciptakan tempat kerja yang:

memiliki barang yang benar,

berada di tempat yang benar,

dalam kondisi yang benar,

dengan standar yang benar,

dan dipertahankan secara konsisten.

Dengan demikian, 5R bukan sebuah proyek yang selesai dalam satu minggu. 5R adalah kebiasaan operasional.

R Pertama: Ringkas

"Apa yang benar-benar kita butuhkan?"

Ringkas berarti memisahkan antara barang yang diperlukan dan barang yang tidak diperlukan. Ini terdengar sederhana. Tetapi praktiknya sering sulit.

Lihat sebuah warehouse. Ada pallet rusak. Kardus bekas. Spare part lama. Dokumen yang sudah tidak berlaku. Peralatan rusak. Material obsolete. Barang retur. Peralatan yang "mungkin suatu hari diperlukan". Semuanya disimpan.

Alasannya hampir selalu sama: "Jangan dibuang dulu, siapa tahu nanti diperlukan."

Akhirnya warehouse berubah menjadi tempat penyimpanan barang yang tidak jelas statusnya. Inilah yang ingin dihilangkan oleh Ringkas.

Barang harus dikategorikan:

Diperlukan

Tidak diperlukan

Belum jelas statusnya

Untuk barang yang statusnya belum jelas, dapat digunakan konsep red tag.

Barang diberi tanda.

Kemudian diputuskan:

dipakai,

dipindahkan,

dikembalikan,

dijual,

didaur ulang,

atau dimusnahkan sesuai prosedur.

Ringkas bukan berarti membuang sebanyak-banyaknya.

Ringkas berarti: Hanya menyimpan sesuatu yang memang memiliki alasan untuk berada di tempat tersebut.

R Kedua: Rapi

Setelah barang yang tidak diperlukan disingkirkan, pertanyaannya berubah:

"Barang yang tersisa harus diletakkan di mana?"

Inilah fungsi Rapi. Rapi bukan berarti semua barang terlihat indah. Rapi berarti: A place for everything, and everything in its place. Setiap barang memiliki lokasi. Dan setiap lokasi memiliki identitas.

Misalnya:

lokasi pallet,

lokasi tools,

lokasi dokumen,

lokasi material,

lokasi barang retur,

lokasi barang reject,

lokasi fire extinguisher,

lokasi emergency equipment.

Kemudian gunakan:

Labeling

Color coding

Floor marking

Visual control

Location numbering

Tujuannya sederhana: Orang tidak perlu bertanya di mana barang berada. Sistem yang menjawabnya.

Rapi Harus Mengurangi Motion

Ini bagian yang sering dilupakan. Tujuan Rapi bukan sekadar estetika. Tujuan utamanya adalah mengurangi waste. Misalnya seorang picker membutuhkan scanner. Kalau scanner selalu berada di tempat yang sama, ia tahu ke mana harus mengambilnya.

Tetapi kalau scanner bisa berada di mana saja, operator harus mencari. Mencari adalah waste. Berjalan terlalu jauh adalah waste. Menunggu adalah waste. Memindahkan barang berkali-kali adalah waste. Karena itu, Rapi memiliki hubungan langsung dengan Lean Management.

Tempat kerja yang terorganisir akan mengurangi:

Motion

Transportation

Waiting

Searching

dan bahkan Error.

R Ketiga: Resik

Resik berarti membersihkan tempat kerja dan peralatan.

Tetapi sekali lagi: Resik bukan sekadar bersih. Dalam Continuous Improvement, kegiatan membersihkan seharusnya sekaligus menjadi kegiatan inspeksi.

Misalnya saat membersihkan mesin, operator menemukan:

kebocoran oli,

baut longgar,

kabel rusak,

suara abnormal,

debu berlebihan,

atau komponen mulai aus.

Artinya: Cleaning = Inspection.

Dengan demikian, aktivitas Resik bisa menjadi bagian dari autonomous maintenance. Operator bukan hanya membersihkan. Operator belajar mengenali kondisi abnormal.

Mengapa Resik Penting di Warehouse?

Bayangkan lantai warehouse dipenuhi debu dan serpihan material. Kemudian forklift melintas.

Ada kemungkinan:

roda menjadi bermasalah,

barang rusak,

operator terpeleset,

area kerja menjadi tidak aman.

Atau ada kebocoran oli dari forklift. Jika area tersebut dibersihkan setiap hari, kebocoran akan terlihat. Tetapi jika tidak pernah dibersihkan, masalah kecil bisa menjadi masalah besar.

Maka prinsipnya: Tempat kerja yang bersih membuat abnormality lebih mudah terlihat.

R Keempat: Rawat

Ini adalah tahap yang membedakan 5R sebagai program biasa dengan 5R sebagai sistem. Karena pertanyaannya sekarang: "Bagaimana memastikan Ringkas, Rapi, dan Resik tetap berjalan?"

Jawabannya adalah:

Standardisasi.

Buat standar.

Misalnya:

standar lokasi,

standar labeling,

standar kebersihan,

standar penyimpanan,

standar visual management,

standar inspeksi,

checklist,

jadwal cleaning,

audit 5R.

Tanpa standardisasi, hasil 5R biasanya hanya bertahan beberapa minggu. Hari Senin warehouse rapi. Hari Jumat mulai berantakan. Bulan depan kembali seperti semula.

Ini disebut: Improvement tanpa sustain. Rawat memastikan improvement menjadi bagian dari sistem kerja.

R Kelima: Rajin

Ini mungkin bagian yang paling sulit.

Karena Rajin bukan sekadar: "Rajin membersihkan."

Rajin berarti membangun disiplin untuk menjalankan standar secara konsisten. Hari ini dilakukan. Besok dilakukan. Minggu depan dilakukan. Bulan depan dilakukan. Bahkan ketika tidak ada audit. Inilah yang disebut discipline.

Dan pada tahap ini, 5R mulai berubah dari sekadar program menjadi budaya kerja.

5R dan Continuous Improvement

Sekarang kita bisa melihat hubungan antara 5R dan Continuous Improvement. 5R menciptakan kondisi dasar agar masalah lebih mudah terlihat.

Karena ketika tempat kerja:

Ringkas

↓

barang yang tidak perlu hilang

Rapi

↓

lokasi abnormal mudah terlihat

Resik

↓

kondisi abnormal mudah ditemukan

Rawat

↓

standar dibuat

Rajin

↓

standar dijalankan terus-menerus

Maka ketika terjadi penyimpangan, kita bisa segera mengetahuinya. Dan ketika abnormality lebih cepat ditemukan, problem solving menjadi lebih cepat dilakukan.

5R Bukan Tujuan Akhir

Ini poin yang sangat penting. Jangan menjadikan: "Warehouse harus bersih dan rapi." sebagai tujuan akhir. Itu baru kondisi dasar.

Tujuan akhirnya adalah:

Safety

↓

Quality

↓

Delivery

↓

Cost

↓

Productivity

↓

Customer Satisfaction

5R adalah fondasi untuk mencapai semuanya. Kalau warehouse rapi tetapi picking error tetap tinggi, berarti kita belum selesai. Kalau warehouse bersih tetapi produktivitas rendah, berarti kita belum selesai. Kalau tools tersusun rapi tetapi downtime tinggi, berarti kita belum selesai.

Karena Continuous Improvement selalu bertanya: "Apa dampak perbaikan ini terhadap performance?"

Jangan Jadikan 5R sebagai Lomba Kebersihan

Ini penyakit yang sering terjadi. Perusahaan membuat lomba: "Area Terbaik Bulan Ini." Semua orang sibuk mempercantik area. Lantai dicat. Label dibuat. Papan informasi dipasang. Foto before-after dibuat. Kemudian auditor datang. Semua terlihat sempurna. Tetapi seminggu kemudian kembali seperti semula.

Mengapa?

Karena yang diperbaiki adalah penampilan, bukan sistem. 5R bukan lomba dekorasi. 5R adalah sistem pengendalian kondisi tempat kerja.

Manager Harus Bertanya "Mengapa?"

Misalnya area warehouse selalu berantakan. Jangan hanya mengatakan: "Operator tidak disiplin."

Tanyakan: 

Mengapa barang diletakkan sembarangan?

Mungkin karena lokasi penyimpanan tidak cukup.

Mengapa lokasi tidak cukup?

Karena kapasitas warehouse tidak sesuai dengan volume aktual.

Mengapa kapasitas tidak sesuai?

Karena forecasting tidak akurat.

Mengapa forecasting tidak akurat?

Karena data demand tidak terintegrasi.

Sekarang kita melihat sesuatu yang lebih besar.

Masalah "5R" ternyata mungkin berhubungan dengan:

Planning

Inventory

Layout

Capacity

Information System

Inilah cara berpikir Continuous Improvement. Jangan berhenti pada gejala. Cari sistem yang menghasilkan gejala tersebut.

5R yang Baik Membuat Masalah Terlihat

Ada satu prinsip yang sangat menarik dalam Lean: "Make problems visible." Jangan menyembunyikan masalah. Justru buat masalah mudah terlihat.

Misalnya:

Rak kosong → langsung terlihat.

Pallet salah lokasi → langsung terlihat.

Tools hilang → langsung terlihat.

Material reject → memiliki area khusus.

Barang overdue → diberi visual indicator.

Area abnormal → memiliki tanda.

Dengan begitu, masalah tidak lagi tersembunyi. Dan ketika masalah terlihat, orang bisa mulai melakukan problem solving.

5R Bukan Pekerjaan Cleaning Service

Ini juga perlu diluruskan. Kalau hanya cleaning service yang bertanggung jawab terhadap 5R, maka perusahaan belum memahami konsepnya. Cleaning service bertanggung jawab terhadap kebersihan sesuai lingkup pekerjaannya. 

Tetapi 5R adalah tanggung jawab semua orang. 

Operator.

Supervisor.

Manager.

Warehouse.

Production.

Maintenance.

Engineering.

Office.

Bahkan management.

Karena orang yang menggunakan area tersebut adalah orang yang paling memahami kondisi normal dan abnormalnya.

Bagaimana Mengukur 5R?

5R sebaiknya tidak hanya dinilai berdasarkan: "Kelihatan bersih."

Gunakan indikator.

Misalnya:

Ringkas

jumlah barang obsolete,

jumlah barang tidak terpakai,

area yang berhasil dibebaskan.

Rapi

location accuracy,

waktu mencari tools,

waktu mencari material,

jumlah misplaced item.

Resik

jumlah abnormality yang ditemukan,

jumlah temuan kebocoran,

jumlah kondisi tidak aman.

Rawat

kepatuhan terhadap standard,

audit score,

jumlah penyimpangan.

Rajin

konsistensi audit,

penyelesaian action,

tingkat kepatuhan terhadap standar.

Dengan demikian, 5R menjadi measurable.

Dari 5R Menuju Budaya Improvement

Ketika 5R sudah berjalan dengan baik, organisasi akan mengalami perubahan yang lebih besar.

Orang mulai terbiasa bertanya: "Apakah ada cara yang lebih baik?"

Itulah awal Continuous Improvement.

Dari: 5R

menuju: Visual Management

menuju: Standard Work

menuju: Problem Solving

menuju: Kaizen

menuju: Operational Excellence.

Jadi 5R sebenarnya bukan akhir perjalanan. 5R adalah pintu masuk.

Penutup

Ada satu kalimat yang menurut saya sangat tepat untuk menggambarkan 5R:

"Kalau kita tidak mampu mengelola tempat kerja kita sendiri, bagaimana kita bisa berharap mampu mengelola proses yang jauh lebih kompleks?"

5R mengajarkan sesuatu yang sederhana. Buang yang tidak perlu. Letakkan sesuatu pada tempatnya. Jaga tempat kerja tetap bersih. Buat standar. Dan disiplin menjalankannya.

Tetapi di balik kesederhanaan tersebut ada filosofi Continuous Improvement yang sangat dalam. Karena tempat kerja yang baik bukan tempat kerja yang selalu terlihat sempurna. Tempat kerja yang baik adalah tempat di mana abnormality segera terlihat, masalah segera ditemukan, dan setiap orang memiliki kebiasaan untuk memperbaikinya.

Itulah mengapa 5R bukan sekadar:

Ringkas.

Rapi.

Resik.

Rawat.

Rajin.

Tetapi merupakan sebuah perjalanan menuju satu hal yang jauh lebih besar: Membangun budaya di mana setiap orang terbiasa melihat masalah, memperbaikinya, dan mencegahnya terjadi kembali. Dan ketika itu sudah menjadi kebiasaan, Continuous Improvement tidak lagi menjadi program perusahaan. Ia menjadi cara perusahaan bekerja.