Magister Manajemen · FEB UNDIP

Manajemen Operasi dan Teknologi

Pertemuan 8 — Lean Operations dan Six Sigma

Setelah tujuh pertemuan membahas kapasitas, persediaan, kualitas, dan manajemen jasa secara terpisah, hari ini kita menyatukan semuanya lewat dua disiplin yang sama-sama mengejar keunggulan operasional: Lean menghilangkan pemborosan, Six Sigma mengendalikan variasi — dan Anda sebagai manajer harus tahu kapan memakai yang mana, dengan dasar angka, bukan slogan.

RPS minggu 9 · 2x50 menit

Selamat siang, Bapak/Ibu. Anda sudah mengenal konsep kualitas dan proses sejak S1 — TQM, Six Sigma sebagai istilah, mungkin juga pernah mendengar "budaya Toyota" — tapi hari ini kita tidak akan mengulang definisi dasar itu, kita masuk langsung ke level pengambilan keputusan: kapan sebuah lini produksi butuh Lean, kapan butuh Six Sigma, dan bagaimana Anda menghitung sendiri metrik yang jadi dasar keputusan itu, bukan sekadar mengutip dari textbook. Bayangkan Anda baru dipromosikan jadi Head of Operations di sebuah manufaktur komponen otomotif di Karawang, dan direksi meminta Anda memilih satu dari dua proposal: investasi pelatihan Lean Manufacturing atau sertifikasi Six Sigma Black Belt untuk tim — itulah kerangka keputusan yang akan kita bangun sepanjang dua jam ke depan. Siapkan kalkulator karena ada dua sesi hitung-hitungan yang harus Anda kerjakan bersama saya: takt time dan DPMO. Pertemuan ini juga menjadi jembatan menuju topik peramalan permintaan dan analitik operasi minggu depan, karena keduanya sama-sama bertumpu pada data proses yang akurat.

Bagian 1 dari 3

Filosofi Lean: Menghilangkan Pemborosan Nilai

Pertanyaan diskusi: Di unit kerja Anda, aktivitas apa yang paling banyak menyita waktu tapi TIDAK pernah ditanyakan atau dibayar oleh pelanggan?

Pertanyaan ini sengaja saya buka dulu sebelum masuk teori, karena jawabannya biasanya mengejutkan peserta sendiri — rapat koordinasi yang berlarut, dokumen yang bolak-balik minta tanda tangan, atau barang setengah jadi yang menumpuk menunggu proses berikutnya. Cobalah minta dua atau tiga Bapak/Ibu menyebutkan contoh nyata dari kantor atau pabrik masing-masing sebelum kita lanjut ke kerangka teori, supaya lean tidak terasa seperti jargon manufaktur semata. Di bagian pertama ini kita membahas akar filosofi Lean dari Toyota Production System, delapan jenis pemborosan yang harus Anda kenali sebagai manajer, dan alat pemetaan value stream untuk melihat proses secara utuh sebelum mengambil keputusan perbaikan. Ingat, Lean berlaku sama validnya di bank, rumah sakit, maupun lini perakitan — intinya selalu sama: hilangkan yang tidak menambah nilai bagi pelanggan.

Dari Toyota Production System ke Lean Enterprise

Akar Teori

Toyota Production System (Ohno, 1988) — respons terhadap keterbatasan modal pasca-perang: produksi harus efisien tanpa skala besar ala Ford.
Womack & Jones (1996), Lean Thinking — mengabstraksi TPS menjadi lima prinsip universal lintas industri.
Prinsip inti: nilai (value) didefinisikan HANYA oleh pelanggan, bukan oleh insinyur proses.

Lima Prinsip Lean Thinking

1. Definisikan nilai dari sudut pandang pelanggan akhir.
2. Petakan value stream — pisahkan aktivitas bernilai tambah dan pemborosan.
3. Ciptakan flow — hilangkan hambatan dan antrean antar-tahap.
4. Terapkan pull — produksi dipicu permintaan aktual (kanban), bukan jadwal dorong (push/forecast).
5. Kejar kesempurnaan (kaizen) — perbaikan berkelanjutan, bukan proyek sekali jadi.

Keputusan manajerial kunci: Lean bukan program pemangkasan biaya sesaat, melainkan sistem operasi jangka panjang — investasi awal (pelatihan, redesain layout) harus dievaluasi sebagai kapabilitas organisasi, bukan proyek satu tahun anggaran.

Anda mungkin sudah familier dengan istilah Toyota Production System, tapi yang perlu ditekankan di level manajer adalah bagaimana lima prinsip Lean Thinking ini diterjemahkan menjadi keputusan investasi dan alokasi sumber daya, bukan sekadar poster motivasi di dinding pabrik. Perhatikan prinsip pull versus push — ini sering jadi titik gagal implementasi Lean di perusahaan Indonesia karena sistem perencanaan produksi (MRP) yang sudah tertanam justru berbasis forecast dorong, sehingga migrasi ke kanban butuh perubahan sistem informasi sekaligus budaya kerja. Tanyakan ke kelas, adakah yang pernah bekerja di perusahaan yang mengklaim sudah "Lean" tapi ternyata hanya memangkas karyawan tanpa mengubah proses — itu kesalahan implementasi yang sangat umum dan layak didiskusikan. Ingatkan Anda semua bahwa evaluasi investasi Lean semestinya masuk dalam kerangka capital budgeting jangka panjang, bukan cost-cutting jangka pendek yang biasa disorot investor kuartalan.

Delapan Pemborosan (TIMWOODS) yang Wajib Anda Kenali

"Skills" adalah tambahan modern dari 7 waste asli Ohno (1988) — relevan untuk organisasi jasa/kantor di mana modal manusia adalah aset utama.

Delapan kategori ini bukan sekadar daftar hafalan — tugas Anda sebagai manajer adalah memetakan mana dari kedelapan pemborosan ini yang paling dominan di unit kerja Anda, karena strategi intervensinya berbeda-beda. Overproduction misalnya sering dianggap "aman" karena tidak terlihat sebagai kerugian langsung, padahal ia memicu inventory berlebih dan menyembunyikan masalah kualitas di baliknya — inilah yang oleh Ohno disebut induk dari segala pemborosan. Ajak kelas berpikir tentang kategori "skills" — ini relevan untuk perusahaan jasa seperti bank atau konsultan, di mana talenta analis junior sering hanya dipakai untuk pekerjaan administratif berulang padahal kapasitas analitisnya jauh lebih tinggi. Diskusikan sebentar, di industri Anda masing-masing (manufaktur, perbankan, ritel), pemborosan mana yang paling mahal secara finansial jika dibiarkan bertahun-tahun.

Mini-Kasus: Realokasi Shift di Pemasok Komponen Otomotif Karawang

Situasi (ilustrasi, berbasis pola umum industri komponen otomotif Jawa Barat): Sebuah pemasok komponen tingkat-2 untuk perakitan otomotif nasional (mirip pola kerja pemasok Astra Otoparts) memiliki lini stamping dengan tiga shift, tapi WIP (work-in-process) antar-stasiun terus menumpuk meski permintaan pelanggan stabil.

Gejala yang Terlihat Manajer

Lantai produksi penuh palet setengah jadi (inventory waste).
Operator shift malam sering menunggu komponen dari shift sebelumnya (waiting waste).
Biaya lembur naik 18% dalam dua kuartal tanpa kenaikan output signifikan.

Keputusan Manajerial yang Diambil

Beralih dari sistem produksi push (jadwal mingguan) ke pull kanban antar-stasiun.
Menyeimbangkan ulang beban kerja (line balancing) — bukan menambah shift baru.
Hasil ilustratif: WIP turun ~35%, lembur turun tanpa PHK, lead time internal memendek.

Poin pembelajaran: solusi intuitif manajer sering "tambah shift/orang" — padahal akar masalah adalah aliran (flow) yang tidak seimbang, bukan kapasitas kurang.

Kasus ini saya sengaja bingkai sebagai ilustrasi pola umum, bukan data resmi perusahaan tertentu, tapi polanya sangat khas ditemui di klaster industri komponen otomotif Karawang dan Cikarang. Perhatikan bagaimana gejala yang terlihat manajer — lembur naik, lantai penuh barang — justru sering direspons dengan solusi yang salah, yaitu menambah kapasitas, padahal Lean mengajarkan kita untuk mencari akar masalah di aliran proses lebih dulu. Tanyakan ke kelas, siapa yang pernah mengalami situasi serupa di tempat kerja masing-masing, di mana solusi "tambah orang" ternyata tidak menyelesaikan masalah nyata karena bottleneck sebenarnya ada di tempat lain. Kasus ini menjadi jembatan sempurna menuju Value Stream Mapping di slide berikutnya, karena VSM adalah alat yang tepat untuk membedakan gejala dari akar masalah sebelum Anda memutuskan investasi apa pun.

Value Stream Mapping: Kerangka Analisis Sebelum Bertindak

Langkah	Aktivitas Analisis	Output bagi Manajer
1. Pilih family produk/jasa	Fokus pada satu aliran nilai spesifik (bukan seluruh pabrik sekaligus)	Ruang lingkup proyek yang terkelola
2. Gambar current state map	Petakan aliran fisik + aliran informasi dari pemasok ke pelanggan	Baseline waktu proses & waktu tunggu aktual
3. Hitung lead time vs process time	Bandingkan total waktu tempuh pesanan dengan total waktu bernilai tambah	Rasio efisiensi aliran (biasanya jauh <10% di industri tradisional)
4. Identifikasi titik pemborosan	Tandai setiap antrean, rework, dan gerakan tak perlu pada peta	Daftar prioritas perbaikan berbasis dampak
5. Rancang future state map	Desain aliran ideal dengan pull system & flow berkelanjutan	Peta target dan rencana implementasi bertahap

Kesimpulan Manajerial VSM bukan alat teknis semata — ia adalah bahasa komunikasi lintas fungsi (produksi, procurement, finance) untuk menyepakati prioritas investasi perbaikan.

Perhatikan bahwa VSM bukan sekadar diagram alir biasa — kekuatannya ada pada langkah ketiga, membandingkan process time dengan lead time keseluruhan, karena di situlah Anda biasanya menemukan kejutan: proses yang benar-benar menambah nilai sering kurang dari sepuluh persen dari total waktu pesanan berjalan. Sebagai manajer, gunakan VSM sebagai alat diplomasi lintas departemen — begitu semua pihak melihat peta yang sama dengan data yang sama, perdebatan "siapa yang salah" berubah menjadi diskusi "di mana kita perbaiki dulu". Ajak kelas membayangkan mereka memimpin proyek VSM untuk proses pengajuan kredit di bank — current state map akan menunjukkan dokumen bolak-balik antar-departemen yang menyita hari, bukan menit. Tekankan bahwa future state map bukan target akhir permanen — begitu tercapai, siklus VSM diulang lagi sebagai bagian dari kaizen berkelanjutan.

Hitung dari Nol #1: Takt Time, Cycle Time, dan Jumlah Operator

Kasus: Lini jahit UMKM garmen ekspor di Jawa Tengah, satu shift 8 jam, target memenuhi pesanan retailer harian.

Langkah	Perhitungan	Nilai
1. Waktu tersedia kotor	8 jam x 60 menit	480 menit
2. Waktu tersedia bersih (setelah istirahat 30 menit)	480 - 30 menit = 450 menit, dikonversi 450 x 60 detik	27.000 detik
3. Permintaan harian retailer	Target pesanan per shift	500 unit
4. Takt time	27.000 detik / 500 unit	54 detik/unit
5. Total waktu proses 5 stasiun jahit	40 + 55 + 66 + 45 + 34 detik	240 detik/unit
6. Jumlah operator minimum	240 detik / 54 detik (dibulatkan ke atas)	5 operator

Peringatan Manajerial 66 > 54 Stasiun ke-3 (66 detik) melebihi takt time (54 detik) — line TIDAK bisa memenuhi target 500 unit/shift tanpa rebalancing beban kerja atau penambahan mesin bantu di stasiun tersebut.

Perhatikan baik-baik langkah keenam ini, karena di sinilah letak jebakan yang sering dilewatkan mahasiswa maupun praktisi baru — menghitung jumlah operator minimum saja tidak cukup, Anda wajib membandingkan stasiun paling lambat dengan takt time. Dalam kasus ini stasiun ketiga butuh 66 detik padahal takt time yang dituntut pelanggan hanya 54 detik, artinya secara matematis line ini akan selalu tertinggal dari target harian meski jumlah operatornya sudah dianggap cukup di atas kertas. Sebagai manajer operasi, keputusan Anda di titik ini bukan "tambah operator" secara sembarangan, melainkan pilih antara line balancing ulang, penambahan alat bantu di stasiun bottleneck, atau negosiasi ulang target dengan pelanggan retailer. Coba minta satu peserta menghitung ulang berapa detik yang perlu dipangkas dari stasiun ketiga agar line ini feasible — ini melatih Anda berpikir kuantitatif sebelum mengambil keputusan investasi mesin baru.

Coba Sendiri: Uji Keseimbangan Line Produksi Anda

Ubah waktu tersedia, target output, dan waktu proses tiap stasiun, lalu amati apakah stasiun mana pun melebihi takt time yang dituntut pelanggan.

Bagian 2 dari 3

Six Sigma: Mengendalikan Variasi Proses

Pertanyaan diskusi: Mana yang lebih berbahaya bagi reputasi perusahaan Anda — proses yang rata-rata bagus tapi variasinya liar, atau proses yang rata-ratanya sedang tapi sangat konsisten?

Pertanyaan ini penting untuk membalik intuisi peserta, karena kebanyakan manajer secara refleks mengejar rata-rata (mean) yang bagus, padahal pelanggan justru lebih sensitif terhadap variasi (variance) yang tidak terduga — bayangkan transfer bank yang kadang sedetik kadang sejam, itu jauh lebih merusak kepercayaan dibanding transfer yang konsisten lima menit meski "kurang cepat". Beri kesempatan dua atau tiga peserta berargumen dari sudut pandang industri masing-masing sebelum kita masuk ke kerangka teori Six Sigma. Di bagian kedua ini kita membahas DPMO, level sigma, biaya kualitas buruk (COPQ), dan siklus DMAIC sebagai metodologi pengambilan keputusan berbasis data untuk mengurangi variasi tersebut. Six Sigma awalnya lahir dari Motorola pada 1986 dan dipopulerkan General Electric era Jack Welch — tapi hari ini kita fokus pada bagaimana Anda menghitung dan menafsirkan metriknya sebagai manajer, bukan sejarahnya.

DNA Six Sigma: DPMO, Level Sigma, dan Biaya Kualitas Buruk

Metrik Inti

DPO (Defect per Opportunity) — proporsi cacat terhadap total peluang cacat.
DPMO (Defects per Million Opportunities) — DPO x 1.000.000, memungkinkan perbandingan lintas proses berbeda kompleksitas.
Level Sigma — konversi DPMO ke satuan standar deviasi dari batas spesifikasi (dengan asumsi pergeseran proses jangka panjang ~1,5σ).

Cost of Poor Quality (COPQ)

Biaya internal: rework, scrap, downtime akibat cacat sebelum sampai pelanggan.
Biaya eksternal: klaim garansi, retur, hilangnya kepercayaan pelanggan.
Rule of thumb industri: proses ~3-4 sigma dapat menyerap COPQ 15-25% dari revenue — inilah argumen finansial di balik investasi Six Sigma, bukan sekadar "kualitas untuk kualitas".

Sigma Level ≈ f(DPMO), dengan 6σ = 3,4 DPMO (praktis nyaris tanpa cacat) dan 3σ ≈ 66.807 DPMO

Poin yang sering hilang di diskusi Six Sigma adalah argumen finansial di balik COPQ — direksi tidak akan tertarik pada "6 sigma" sebagai angka abstrak, mereka tertarik pada berapa persen revenue yang bocor akibat rework dan klaim yang bisa dicegah. Jelaskan bahwa level sigma bukan skala linear — lompatan dari 3 sigma ke 4 sigma jauh lebih mudah dicapai dibanding dari 5 sigma ke 6 sigma, karena itulah kebanyakan perusahaan jasa di Indonesia realistis menargetkan 4 hingga 4,5 sigma, bukan 6 sigma penuh yang didominasi industri semikonduktor atau dirgantara. Tanyakan ke kelas, di industri perbankan atau telekomunikasi Indonesia, jenis "defect" apa yang paling relevan dihitung — kesalahan input data nasabah, gangguan jaringan, atau keterlambatan proses klaim asuransi. Slide berikutnya kita akan menghitung sendiri DPMO dan level sigma dari sebuah kasus verifikasi dokumen kredit, supaya konsep ini tidak berhenti sebagai rumus di atas kertas.

Hitung dari Nol #2: DPMO dan Level Sigma Proses Verifikasi Kredit

Kasus: Unit back-office bank menengah memverifikasi dokumen pengajuan kredit konsumer (ilustrasi, pola umum industri perbankan).

Langkah	Perhitungan	Nilai
1. Jumlah dokumen diperiksa/bulan	Data operasional bulan berjalan	10.000 dokumen
2. CTQ (peluang cacat) per dokumen	Nama, nominal, tanda tangan, tanggal, kelengkapan lampiran	5 karakteristik
3. Total peluang cacat	10.000 x 5	50.000 peluang
4. Jumlah cacat ditemukan audit	Hasil sampling kendali mutu	150 cacat
5. DPO	150 / 50.000	0,003
6. DPMO	0,003 x 1.000.000	3.000

Interpretasi Level Sigma ~4,25σ Interpolasi tabel konversi DPMO-sigma standar (asumsi shift 1,5σ) — di atas rata-rata industri jasa (~3-4σ), tapi masih jauh dari target 6σ (3,4 DPMO). Prioritas: turunkan cacat kelengkapan lampiran, sumber cacat terbesar biasanya.

Perhatikan urutan perhitungan ini dengan teliti — kesalahan paling umum mahasiswa adalah lupa mengalikan jumlah unit dengan jumlah peluang cacat per unit di langkah ketiga, sehingga DPMO yang dihasilkan keliru total. Setelah DPMO diperoleh sebesar 3.000, saya sengaja memberi nilai sigma dengan tanda hampir karena konversi DPMO ke level sigma memakai tabel standar dengan asumsi pergeseran proses 1,5 sigma, bukan rumus tertutup sederhana — jadi jangan hafalkan angka pastinya, pahami polanya. Ajak kelas berdiskusi, kalau bank ini ingin naik dari 4,25 sigma ke 5 sigma, opsi mana yang lebih realistis secara biaya — investasi sistem verifikasi otomatis (OCR/AI) atau menambah lapisan pemeriksaan manual, dan apa konsekuensi masing-masing terhadap kecepatan proses persetujuan kredit ke nasabah. Ingatkan bahwa metrik ini harus dipantau berkelanjutan, bukan dihitung sekali lalu dilupakan — inilah alasan Six Sigma selalu berpasangan dengan Statistical Process Control yang akan kita bahas beberapa slide lagi.

DMAIC sebagai Siklus Pengambilan Keputusan Manajerial

Fase	Pertanyaan Kunci Manajer	Output Keputusan
Define	Masalah apa, seberapa besar dampaknya ke pelanggan/biaya, siapa sponsor proyek?	Project charter dengan target terukur
Measure	Apakah sistem pengukuran kita sendiri sudah andal (measurement system analysis)?	Baseline DPMO/kapabilitas proses tervalidasi
Analyze	Akar penyebab mana yang secara statistik terbukti signifikan, bukan sekadar dugaan?	Root cause terverifikasi data (bukan opini rapat)
Improve	Solusi mana yang paling cost-effective dan bisa diuji coba (pilot) dulu?	Solusi teruji dengan bukti perbaikan terukur
Control	Bagaimana memastikan perbaikan tidak luntur dalam 6-12 bulan ke depan?	Peta kendali & standar kerja baru terkunci

Kesalahan paling sering: melompat dari Define langsung ke Improve tanpa Measure/Analyze yang solid — solusi jadi tebakan mahal, bukan keputusan berbasis bukti.

DMAIC sering disalahpahami sebagai daftar periksa administratif, padahal setiap fase punya pertanyaan keputusan yang berbeda bagi seorang manajer, dan melompati salah satu fase adalah kesalahan paling mahal yang bisa Anda buat sebagai project sponsor. Fase Measure sering diremehkan — banyak proyek gagal karena datanya sendiri tidak andal, misalnya dua orang mengukur "cacat" dengan definisi berbeda, sehingga sebelum bicara solusi Anda harus memastikan sistem pengukurannya sendiri konsisten. Tekankan ke kelas bahwa fase Analyze menuntut bukti statistik, bukan opini rapat direksi yang paling senior — inilah nilai tambah metodologi Six Sigma dibanding brainstorming biasa. Minta peserta membayangkan mereka memimpin proyek DMAIC untuk menurunkan keluhan pelanggan e-commerce terkait salah kirim barang — ajak mereka menyebutkan satu pertanyaan konkret untuk tiap fase sesuai konteks bisnis masing-masing.

Mini-Kasus: Proyek Six Sigma di Unit Kliring Bank Nasional

Situasi (ilustrasi, pola umum operasi perbankan nasional seperti BCA/Mandiri): Unit back-office kliring antar-bank mencatat keluhan nasabah korporat meningkat terkait keterlambatan dan kesalahan posting transaksi bulanan.

Define & Measure

Sponsor: Kepala Divisi Operasi; target: turunkan komplain 50% dalam 2 kuartal.
Baseline DPMO dihitung dari sampel 3 bulan transaksi — hasil awal ~4.500 (ilustrasi).

Analyze, Improve & Control

Root cause: input manual ganda antar-sistem legacy dan sistem baru (bukan human error acak).
Solusi: integrasi API antar-sistem + validasi otomatis, bukan pelatihan ulang staf semata.
Control: dashboard SPC real-time dipantau supervisor harian.

Pembelajaran manajerial: solusi "latih staf lebih teliti" terasa murah tapi tidak menyentuh akar masalah sistem — investasi integrasi sistem justru lebih cost-effective jangka panjang.

Kasus ini menggambarkan pola yang sangat umum di operasi perbankan nasional, di mana tekanan pertama dari manajemen biasanya "latih staf agar lebih teliti", padahal setelah fase Analyze dijalankan dengan benar, akar masalahnya ternyata sistemik — proses input ganda antar-sistem lama dan baru yang secara struktural rentan salah ketik dan salah baca. Ini mengajarkan Anda bahwa solusi termurah di permukaan (pelatihan) belum tentu solusi yang tepat, dan disiplin DMAIC memaksa Anda membuktikan akar masalah sebelum menghabiskan anggaran pelatihan yang sia-sia. Diskusikan dengan kelas, dalam pengalaman profesional masing-masing, berapa sering solusi "training ulang karyawan" diusulkan sebagai jawaban pertama padahal akar masalahnya ada di desain sistem atau proses. Tekankan juga pentingnya fase Control di sini — tanpa dashboard SPC harian, perbaikan yang sudah dicapai akan perlahan luntur begitu tekanan proyek mereda, sebuah pola yang sangat lazim terjadi enam bulan pasca-proyek Six Sigma selesai.

Statistical Process Control: Peta Kendali sebagai Radar Keputusan

Sinyal "Common Cause"

Titik acak di dalam batas kendali (UCL-LCL).
Variasi wajar sistem — perbaikan butuh redesain proses, bukan reaksi kasus per kasus.

Sinyal "Special Cause"

Titik keluar batas kendali atau pola tren (8 titik berturut naik/turun).
Butuh investigasi segera — ada sesuatu yang berubah di proses saat itu.

Peta kendali ini adalah alat radar bagi Anda sebagai manajer — bedanya dengan laporan bulanan biasa, SPC memberi sinyal secara real-time sebelum masalah membesar menjadi komplain pelanggan atau kerugian finansial. Perhatikan perbedaan penting antara variasi common cause dan special cause, karena kesalahan klasik manajer baru adalah bereaksi berlebihan terhadap setiap fluktuasi titik data padahal itu variasi wajar sistem — inilah yang disebut Deming sebagai "tampering", yang justru memperbesar variasi bukan menguranginya. Tanyakan ke kelas, dalam laporan operasional bulanan yang biasa mereka terima, apakah selama ini treatment terhadap satu titik anomali sudah tepat, atau justru bereaksi berlebihan padahal itu variasi biasa. Slide ini menutup pembahasan Six Sigma dengan pesan penting: DMAIC tanpa SPC di fase Control hanya akan menghasilkan perbaikan sesaat yang perlahan kembali ke kondisi lama.

Coba Sendiri: Bedakan Common Cause vs Special Cause

Masukkan atau ubah titik data proses, lalu amati kapan peta kendali menandai sinyal special cause yang butuh investigasi segera.

Bagian 3 dari 3

Integrasi Lean Six Sigma dan Peran Teknologi

Pertanyaan diskusi: Kalau organisasi Anda hanya boleh memilih SATU inisiatif tahun ini — Lean atau Six Sigma — bagaimana Anda meyakinkan direksi tentang pilihan Anda dengan data, bukan preferensi pribadi?

Pertanyaan ini memaksa Anda mempraktikkan langsung apa yang sudah kita pelajari — bukan memilih berdasarkan mana yang lebih populer atau lebih mudah dijelaskan ke direksi, tapi berdasarkan diagnosis data proses yang sesungguhnya. Beri waktu sejenak untuk peserta berpikir sebelum kita bahas kerangka pemilihannya secara eksplisit di slide berikutnya. Di bagian penutup ini kita akan membandingkan kapan Lean lebih tepat, kapan Six Sigma lebih tepat, bagaimana trade-off kecepatan versus presisi dikelola secara manajerial, dan bagaimana teknologi digital seperti IoT dan digital twin mengubah cara kedua metodologi ini dijalankan hari ini dibanding dua dekade lalu. Ingat, ini juga menjadi jembatan langsung ke topik peramalan permintaan dan analitik operasi minggu depan, karena keduanya sama-sama membutuhkan data proses yang bersih dan real-time.

Lean vs Six Sigma vs Lean Six Sigma: Memilih Senjata yang Tepat

Kriteria Diagnosis	Cenderung Lean	Cenderung Six Sigma
Gejala dominan	Lead time lama, WIP menumpuk, banyak langkah tak bernilai tambah	Output tidak konsisten, komplain kualitas, banyak rework
Sifat masalah	Terlihat kasat mata (visual, aliran fisik)	Butuh data statistik untuk terlihat (variasi tersembunyi)
Horizon perbaikan	Cepat (mingguan-bulanan, kaizen event)	Menengah-panjang (bulanan-tahunan, proyek DMAIC penuh)
Contoh keputusan	Redesain layout gudang, kanban antar-stasiun	Redesain sistem verifikasi dokumen, kalibrasi mesin

Lean Six Sigma (gabungan) dipakai saat organisasi punya kedua masalah sekaligus — pemborosan aliran DAN variasi kualitas — namun butuh kapabilitas tim yang lebih matang dan komitmen sumber daya lebih besar.

Tabel ini adalah alat diagnosis praktis yang bisa langsung Anda pakai minggu depan di kantor masing-masing — jangan mulai dari "kita mau Lean" atau "kita mau Six Sigma", mulai dari gejala nyata yang Anda amati di proses, baru tentukan metodologinya. Perhatikan baris horizon perbaikan — ini sering jadi pertimbangan politis penting, karena direksi yang butuh hasil cepat untuk laporan kuartalan cenderung tertarik pada kaizen event Lean, sementara proyek DMAIC penuh butuh kesabaran dan sponsor yang kuat. Ajak kelas mendiskusikan organisasi mereka masing-masing — apakah masalah utama yang mereka hadapi lebih mengarah ke gejala aliran (Lean) atau gejala variasi kualitas (Six Sigma), dan mengapa. Tekankan bahwa Lean Six Sigma gabungan bukan pilihan default yang otomatis lebih baik — ia menuntut kapabilitas tim dan komitmen anggaran yang jauh lebih besar, sehingga organisasi kecil atau menengah sering lebih realistis memulai dari salah satu dulu.

Trade-off Manajerial: Kecepatan (Lean) vs Presisi (Six Sigma)

Risiko Terlalu Lean Memangkas buffer/inventory tanpa mengendalikan variasi kualitas dulu

Line yang sudah "ramping" tapi masih bervariasi kualitasnya akan lebih rentan berhenti total saat ada cacat — buffer yang dipangkas justru menghilangkan bantalan pelindung dari variasi yang belum terkendali.

Risiko Terlalu Six Sigma Mengejar presisi ekstrem pada proses yang sebenarnya penuh pemborosan aliran

Menghabiskan sumber daya menyempurnakan variasi sebuah proses yang, secara keseluruhan, masih dipenuhi langkah tak bernilai tambah — presisi tinggi pada aktivitas yang seharusnya dihapus, bukan disempurnakan.

Sekuens yang disarankan riset operasi: stabilkan proses dulu (Six Sigma - kurangi variasi) SEBELUM memangkas buffer (Lean) — Lean pada proses yang belum stabil justru memperbesar risiko gangguan pasokan ke pelanggan.

Ini adalah salah satu keputusan manajerial paling halus dalam operasi, karena secara intuitif Lean dan Six Sigma terasa sejalan, padahal urutan penerapannya sangat menentukan hasil akhir. Kalau Anda memangkas persediaan penyangga sebelum variasi kualitas terkendali, Anda justru menghilangkan bantalan yang selama ini menyembunyikan masalah kualitas dari pelanggan — begitu buffer hilang, setiap cacat langsung terasa sebagai keterlambatan pengiriman ke pelanggan akhir. Sebaliknya, mengejar presisi Six Sigma ekstrem pada sebuah proses yang masih penuh langkah tak perlu adalah pemborosan sumber daya analitis pada aktivitas yang seharusnya justru dihapus. Tanyakan ke kelas, kalau mereka jadi konsultan operasi untuk pabrik tekstil yang ingin "Lean Six Sigma" sekaligus, urutan mana yang akan mereka rekomendasikan lebih dulu dan mengapa — ini melatih penalaran sekuensial, bukan sekadar hafalan konsep.

Teknologi Pendukung: Digital Twin, IoT, dan SPC Real-Time

Sensor IoT

Merekam data proses (suhu, getaran, dimensi) otomatis, menggantikan sampling manual periodik.
Mengurangi lag antara terjadinya cacat dan terdeteksinya cacat.

Digital Twin

Simulasi virtual lini produksi — uji skenario line balancing/rebalancing sebelum ubah fisik.
Menurunkan biaya dan risiko eksperimen Lean di lantai produksi nyata.

SPC Real-Time

Peta kendali otomatis-update, alert instan saat sinyal special cause muncul.
Mengubah Control dari laporan bulanan menjadi radar hidup harian.

Nama mata kuliah ini menegaskan poin utama: Lean dan Six Sigma yang dulu bertumpu pada observasi manual, kini bertumpu pada data proses yang mengalir otomatis — inilah jembatan menuju analitik operasi minggu depan.

Perhatikan bahwa teknologi di sini bukan menggantikan filosofi Lean atau Six Sigma, melainkan mempercepat siklus deteksi dan koreksinya — dulu peta kendali diisi manual oleh operator setiap jam, sekarang sensor IoT bisa mengalirkan data itu secara kontinu tanpa jeda manusia. Digital twin sangat relevan untuk kasus line balancing yang kita hitung tadi — daripada menghentikan lini produksi sungguhan untuk uji coba rebalancing, perusahaan bisa mensimulasikan dulu skenario penambahan mesin di stasiun bottleneck secara virtual. Ajak kelas berpikir tentang risiko sebaliknya juga — investasi IoT dan digital twin membutuhkan modal awal yang tidak kecil, sehingga keputusan adopsinya sendiri harus melalui analisis kelayakan finansial, bukan sekadar ikut tren Industri 4.0. Tekankan bahwa slide ini menjadi jembatan eksplisit ke pertemuan berikutnya tentang peramalan permintaan dan analitik operasi, karena data proses yang bersih dari sensor inilah yang kelak jadi input model analitik itu.

Tantangan Implementasi Lean Six Sigma di Organisasi Indonesia

Tantangan Budaya

Hierarki tinggi membuat operator lini segan melaporkan masalah ke atasan (menghambat deteksi dini akar masalah).
Insentif kinerja individu sering bertentangan dengan insentif aliran tim (kaizen butuh kolaborasi lintas stasiun).

Tantangan Struktural

Sertifikasi Belt (Yellow/Green/Black Belt) sering jadi status simbolik, bukan kapabilitas project delivery nyata.
Rotasi jabatan cepat di banyak korporasi Indonesia memutus kontinuitas champion proyek Lean Six Sigma.

Implikasi bagi Anda sebagai manajer: keberhasilan Lean Six Sigma lebih ditentukan oleh desain insentif dan kontinuitas kepemimpinan proyek, dibanding oleh canggihnya alat statistik yang dipakai.

Bagian ini penting justru karena banyak textbook Barat menganggap tantangan implementasi hanya soal teknis statistik, padahal di konteks organisasi Indonesia, hambatan budaya hierarki dan desain insentif jauh lebih menentukan keberhasilan proyek. Operator di lantai produksi yang segan melapor masalah ke atasan bukan karena tidak tahu masalahnya, tapi karena struktur relasi kekuasaan membuat pelaporan masalah terasa seperti mengaku gagal — ini yang harus diatasi lebih dulu sebelum alat statistik apa pun berguna. Diskusikan dengan kelas fenomena sertifikasi Belt yang jadi status simbolik — tanyakan siapa yang pernah melihat rekan kerja bergelar Green Belt atau Black Belt tapi tidak pernah benar-benar memimpin proyek DMAIC sampai tuntas. Tekankan bahwa sebagai calon pemimpin operasi, tugas Anda bukan hanya menguasai alat Lean Six Sigma, tapi merancang sistem insentif dan struktur kepemimpinan proyek yang membuat alat itu benar-benar dipakai dan bertahan.

Latihan Kelompok: Rancang Proyek Lean Six Sigma untuk Organisasi Anda

Instruksi (20 menit diskusi kelompok, 10 menit presentasi singkat)

1. Pilih satu proses nyata dari organisasi/pengalaman kerja Anda (produksi, layanan, back-office).
2. Diagnosis: apakah gejalanya lebih ke arah pemborosan aliran (Lean) atau variasi kualitas (Six Sigma)? Gunakan tabel diagnosis slide 15.
3. Kalau data tersedia, hitung minimal satu metrik (takt time ATAU DPMO) sesuai contoh perhitungan tadi.
4. Rancang satu fase DMAIC ATAU satu langkah VSM yang paling relevan sebagai langkah pertama proyek Anda.
5. Identifikasi tantangan budaya/struktural (slide 18) yang paling mungkin menghambat proyek Anda di organisasi nyata.

Tujuan latihan ini bukan mencari jawaban sempurna, melainkan melatih Anda mendiagnosis proses nyata dengan kerangka yang sudah dibangun sepanjang pertemuan ini — kemampuan yang langsung terpakai di pekerjaan Anda.

Latihan ini sengaja dirancang berbasis pengalaman kerja nyata Anda masing-masing, karena tujuan pembelajaran level magister bukan menghafal rumus, melainkan melatih penalaran diagnostik yang bisa langsung dipakai Senin depan di kantor. Dorong setiap kelompok memilih proses yang benar-benar mereka pahami detailnya — baik itu proses produksi pabrik, proses layanan cabang bank, atau proses back-office administrasi — supaya diskusi tidak terjebak asumsi abstrak. Selama kelompok berdiskusi, keliling dan tanyakan probing question: "Bagaimana Anda tahu ini masalah Lean, bukan masalah Six Sigma?" atau "Data apa yang sebenarnya Anda butuhkan tapi belum tersedia di organisasi Anda?" — pertanyaan ini memaksa mereka mengonfrontasi kesenjangan data riil yang sering jadi kendala nyata implementasi. Saat sesi presentasi singkat, minta tiap kelompok fokus pada satu tantangan budaya/struktural yang paling realistis mereka hadapi, karena itu sering menjadi diskusi paling berharga dibanding perhitungan angkanya sendiri.

Ringkasan dan Jembatan ke Pertemuan 9

Yang Sudah Kita Bangun Hari Ini

Lean menghilangkan pemborosan lewat VSM, pull system, dan line balancing (takt time vs cycle time).
Six Sigma mengendalikan variasi lewat DMAIC, DPMO/level sigma, dan SPC.
Keduanya butuh sekuens tepat: stabilkan kualitas dulu, baru pangkas buffer aliran.
Teknologi (IoT, digital twin, SPC real-time) mempercepat siklus deteksi-koreksi, bukan menggantikan filosofinya.

Menuju Pertemuan 9: Peramalan Permintaan & Analitik Operasi

Data proses bersih yang dihasilkan SPC/IoT hari ini menjadi input model peramalan permintaan.
Takt time yang stabil hanya berguna jika permintaan yang diperkirakan juga akurat — dua topik ini saling mengunci.
Siapkan pertanyaan: bagaimana kesalahan peramalan memengaruhi keputusan kapasitas yang sudah kita bahas di pertemuan-pertemuan awal?

Satu Kalimat Pegangan Lean tanpa kendali variasi rapuh; Six Sigma tanpa efisiensi aliran mahal — keputusan manajer yang baik adalah tahu urutan dan proporsi keduanya, bukan memilih satu secara dogmatis.

Sebelum kita tutup, saya ingin Anda membawa pulang satu kerangka berpikir, bukan sekadar daftar istilah — bahwa Lean dan Six Sigma adalah dua lensa berbeda untuk masalah yang berbeda pula, dan tugas Anda sebagai manajer adalah mendiagnosis dulu sebelum memilih lensa mana yang dipakai. Perhatikan bahwa dua sesi hitung-hitungan tadi, takt time dan DPMO, bukan latihan matematika semata — keduanya adalah bahasa yang akan Anda pakai untuk meyakinkan direksi bahwa keputusan investasi operasi Anda berbasis data, bukan intuisi. Pertemuan depan kita masuk ke peramalan permintaan dan analitik operasi, dan Anda akan melihat bahwa takt time yang sudah stabil hari ini hanya berguna kalau perkiraan permintaannya sendiri akurat — kedua topik ini saling mengunci, bukan berdiri sendiri-sendiri. Sebelum pulang, luangkan waktu menuliskan satu proses nyata di organisasi Anda yang menurut Anda paling butuh salah satu dari dua pendekatan hari ini, supaya minggu depan Anda sudah punya bahan konkret untuk didiskusikan lebih lanjut.