THEORY OF CONSTRAINTS

Jangan Perbaiki Semua Hal, Cari Satu Titik yang Menahan Sistem

Ada satu kesalahan yang cukup sering terjadi dalam Continuous Improvement. Ketika perusahaan menemukan banyak masalah, semuanya ingin diperbaiki sekaligus. Mesin A perlu diperbaiki. Warehouse perlu dirapikan. Produktivitas operator perlu ditingkatkan. Layout perlu diubah. Supplier perlu diperbaiki. Sistem informasi perlu diperbarui. Bahkan mungkin dilakukan pelatihan baru.

Semua terlihat sebagai masalah. Namun setelah berbulan-bulan melakukan improvement, mengapa output perusahaan tidak banyak berubah?

Bisa jadi masalahnya bukan karena perusahaan kurang melakukan improvement. Bisa jadi perusahaan memperbaiki terlalu banyak hal yang sebenarnya bukan penghambat utama sistem. Di sinilah Theory of Constraints (TOC) menjadi menarik.

TOC berangkat dari gagasan sederhana, dalam setiap sistem, selalu ada setidaknya satu constraint yang membatasi kemampuan sistem untuk mencapai tujuannya. Kalau constraint tersebut tidak diperbaiki, memperbaiki bagian lain yang bukan constraint mungkin hanya menghasilkan efisiensi lokal tanpa meningkatkan kinerja sistem secara keseluruhan.

Dengan kata lain, jangan bertanya, "Apa yang bisa kita perbaiki?"

Pertanyaan yang lebih penting adalah, "Apa yang sedang menahan seluruh sistem?"

1. Apa Itu Theory of Constraints? 

Theory of Constraints dikembangkan dan dipopulerkan oleh Eliyahu M. Goldratt, terutama melalui bukunya The Goal. TOC melihat perusahaan sebagai sebuah sistem yang terdiri dari berbagai bagian yang saling terhubung. Dalam manufaktur, misalnya, Supplier → Warehouse → Production → Quality → Packing → Warehouse Finished Goods → Customer

Masing-masing bagian mempunyai kapasitas yang berbeda. Masalah muncul ketika satu bagian memiliki kapasitas lebih rendah dibandingkan kebutuhan sistem. Bagian tersebut menjadi constraint atau kendala.

Secara sederhana, kapasitas sistem tidak bisa dipandang sebagai penjumlahan seluruh kapasitas tersebut. Inilah salah satu cara paling sederhana memahami TOC. Sistem tidak berjalan secepat bagian tercepatnya. Sistem dibatasi oleh constraint-nya.

2. Constraint Tidak Selalu Berupa Mesin

Ketika mendengar kata constraint, banyak orang langsung membayangkan mesin yang kapasitasnya kurang. Padahal constraint bisa sangat beragam.

Physical Constraint

Contohnya:

Kapasitas mesin.

Jumlah workstation.

Kapasitas warehouse.

Ketersediaan kendaraan.

Kapasitas tenaga kerja tertentu.

Ruang penyimpanan.

Policy Constraint

Ini sering kali lebih sulit terlihat.

Misalnya:

Kebijakan batch minimum terlalu besar.

Approval terlalu panjang.

Target departemen saling bertentangan.

Sistem insentif mendorong perilaku yang tidak optimal.

Aturan produksi menyebabkan perusahaan membuat barang yang belum dibutuhkan.

Market Constraint

Perusahaan mungkin memiliki kapasitas produksi besar, tetapi permintaan pasar tidak cukup.

Dalam kondisi tersebut, kapasitas produksi bukan lagi constraint utama.

Constraint bisa berada pada market atau demand.

Information Constraint

Informasi yang terlambat atau tidak akurat juga dapat menjadi constraint.

Misalnya:

Sales tidak memberikan forecast dengan baik.

PPIC menggunakan data yang terlambat.

Warehouse mempunyai stok aktual berbeda dengan sistem.

Production planning akhirnya membuat keputusan berdasarkan informasi yang tidak akurat.

Secara fisik mesin mungkin tidak bermasalah. Tetapi sistem tetap tidak mampu menghasilkan performa optimal.

3. Mengapa Perusahaan Sering Salah Menentukan Constraint?

Karena kita sering melihat gejala, bukan penyebab.

Contohnya:

Warehouse penuh.

Kesimpulan pertama, "Kita membutuhkan warehouse yang lebih besar."

Padahal mungkin penyebabnya adalah production menghasilkan barang lebih cepat daripada kemampuan sales menjualnya.

Atau, Mesin sering overtime.

Kesimpulan, "Kita perlu menambah mesin."

Padahal mungkin terdapat proses sebelumnya yang menghasilkan terlalu banyak WIP sehingga bottleneck bekerja dengan prioritas yang kacau.

Atau, Operator terlihat sangat sibuk.

Kesimpulan, "Berarti produktivitasnya tinggi."

Belum tentu. Kesibukan individu tidak sama dengan throughput sistem. Inilah jebakan yang sering terjadi dalam manajemen operasional. Kita mengoptimalkan utilisasi lokal, tetapi lupa melihat aliran sistem secara keseluruhan.

4. Lima Langkah Focusing TOC

TOC memiliki pendekatan yang sangat terkenal yang sering disebut Five Focusing Steps. Lima langkah ini menjadi kerangka untuk menemukan dan mengelola constraint.

Langkah 1 — Identify the Constraint

Temukan constraint.

Pertanyaan utamanya, Apa yang paling membatasi kemampuan sistem mencapai tujuannya saat ini?

Dalam manufaktur, kita dapat melihat:

Bottleneck.

Antrean WIP.

Mesin dengan beban tertinggi.

Proses dengan cycle time terpanjang.

Titik yang menyebabkan pekerjaan menunggu.

Keterbatasan material.

Keterbatasan tenaga kerja dengan skill tertentu.

Tetapi jangan langsung menganggap mesin dengan utilisasi tertinggi sebagai constraint. Data harus dianalisis berdasarkan hubungan proses secara keseluruhan. Constraint adalah titik yang benar-benar membatasi throughput sistem.

Langkah 2 — Exploit the Constraint

Setelah menemukan constraint, jangan langsung membeli mesin baru. Maksimalkan constraint yang sudah ada terlebih dahulu. Inilah konsep exploit. Misalnya sebuah mesin bottleneck mempunyai waktu tersedia 16 jam sehari.

Namun setelah dianalisis:

1 jam digunakan untuk menunggu material.

30 menit digunakan mencari tooling.

45 menit digunakan untuk setup yang sebenarnya dapat dikurangi.

30 menit hilang karena masalah minor.

Operator meninggalkan mesin saat proses berlangsung. Secara nominal mesin mempunyai kapasitas 16 jam. Namun kapasitas efektifnya jauh lebih rendah.

Sebelum membeli mesin baru, perusahaan dapat memperbaiki:

Material availability.

Setup.

Preventive maintenance.

Standard work.

Tool availability.

Changeover.

Scheduling.

Minor stoppage.

Dengan kata lain, Gunakan constraint seoptimal mungkin sebelum menambah investasi.

Langkah 3 — Subordinate Everything Else

Ini adalah bagian TOC yang sering bertentangan dengan cara berpikir tradisional. Jika sudah menemukan constraint, maka proses lain harus menyesuaikan diri dengan kebutuhan constraint. Bukan sebaliknya.

Misalnya bottleneck mampu menghasilkan 80 unit per jam.

Proses sebelumnya mampu menghasilkan 120 unit per jam.

Kalau proses sebelumnya terus dipaksa menghasilkan 120 unit per jam, maka apa yang terjadi?

WIP menumpuk.

Warehouse antara proses menjadi penuh.

Material handling meningkat.

Risiko kerusakan meningkat.

Lead time bertambah.

Operator sibuk.

Tetapi output akhir tetap sekitar kapasitas constraint. Maka produktivitas lokal terlihat tinggi, tetapi sistem tidak menjadi lebih produktif.

TOC mengatakan, Jangan memproduksi lebih cepat hanya karena mesin mampu. Produksi harus mengikuti kebutuhan sistem dan constraint. Ini adalah perubahan cara berpikir yang sangat penting.

Langkah 4 — Elevate the Constraint

Jika constraint sudah dieksploitasi dan proses lain sudah diselaraskan, tetapi constraint masih membatasi throughput, barulah kita mempertimbangkan elevate.

Artinya meningkatkan kapasitas constraint.

Contohnya:

Menambah shift.

Menambah operator.

Outsourcing sebagian proses.

Membeli mesin tambahan.

Meningkatkan kecepatan mesin jika aman.

Mengurangi waktu setup.

Mengubah layout.

Menambah tooling.

Menghilangkan aktivitas yang tidak bernilai tambah.

Menggunakan teknologi baru.

Pada tahap ini, investasi menjadi lebih masuk akal karena perusahaan sudah memahami di mana investasi benar-benar dibutuhkan.

Bukan, "Kita beli mesin karena mesin lama sudah tua."

Tetapi, "Kapasitas proses X merupakan constraint yang membatasi throughput. Setelah seluruh peluang peningkatan kapasitas internal dimanfaatkan, investasi tambahan diperkirakan memberikan peningkatan throughput yang signifikan."

Perbedaan cara berpikirnya sangat besar.

Langkah 5 — Repeat the Process

Ketika constraint berhasil diatasi, jangan berhenti. Karena constraint berikutnya mungkin berpindah.

Misalnya awalnya, Machine C → Constraint

Setelah diperbaiki, Machine C → bukan lagi constraint

Kemudian ternyata, Packing → Constraint

Setelah packing diperbaiki, Warehouse Finished Goods → Constraint

Kemudian, Delivery → Constraint

Artinya, improvement adalah proses yang berulang. Inilah mengapa TOC sangat cocok dengan Continuous Improvement. Ketika satu constraint hilang, cari constraint berikutnya.

5. Bottleneck dan Constraint: Apakah Sama?

Sering kali istilah bottleneck dan constraint digunakan seolah-olah sama.

Keduanya memang berkaitan, tetapi tidak selalu identik.

Bottleneck biasanya merujuk pada titik dalam aliran proses yang kapasitasnya paling rendah dibandingkan kebutuhan proses.

Sementara constraint memiliki makna lebih luas: segala sesuatu yang membatasi kemampuan sistem mencapai tujuannya.

Karena itu, bottleneck dapat menjadi constraint, tetapi constraint tidak harus berupa bottleneck fisik.

Misalnya:

Sebuah perusahaan memiliki kapasitas produksi yang cukup besar.

Namun perusahaan tidak dapat meningkatkan penjualan karena keterbatasan pasar.

Dalam situasi tersebut, constraint utamanya bukan mesin.

Market menjadi constraint.

6. TOC dalam Warehouse

Theory of Constraints sangat menarik jika diterapkan di warehouse.

Bayangkan sebuah warehouse mempunyai:

10 operator receiving.

20 operator picking.

10 operator packing.

5 operator shipping.

Namun proses shipping hanya mampu memproses 500 order per hari.

Receiving mampu menerima 800 order.

Picking mampu menyelesaikan 750 order.

Packing mampu menyelesaikan 700 order.

Jika semua bagian bekerja semaksimal mungkin, apa yang terjadi?

Order akan terus mengalir menuju shipping.

Akibatnya:

WIP/order backlog menumpuk di area sebelum shipping.

Manajemen kemudian mungkin mengatakan:

"Picking harus ditingkatkan lagi!"

Padahal picking sudah mampu menghasilkan lebih banyak daripada shipping.

Meningkatkan picking dari 750 menjadi 900 order per hari tidak menyelesaikan masalah.

Justru backlog semakin besar.

Pendekatan TOC akan bertanya:

Apa yang membatasi throughput warehouse?

Jika shipping adalah constraint, maka fokus improvement harus diarahkan ke shipping.

Misalnya:

Layout staging diperbaiki.

Sistem sorting diperbaiki.

Dokumen dipercepat.

Jadwal pickup diatur ulang.

Area loading diperbaiki.

Jumlah dock disesuaikan.

Proses scanning diperbaiki.

Bottleneck pada proses manifestasi dihilangkan.

Tujuannya bukan membuat setiap aktivitas bekerja 100%.

Tujuannya adalah meningkatkan throughput sistem.

7. TOC dalam Production Planning

TOC juga memiliki implikasi besar bagi PPIC. Kesalahan yang sering terjadi adalah membuat production schedule berdasarkan kapasitas masing-masing mesin tanpa memperhatikan constraint.

Misalnya:

Mesin A = 100 unit.

Mesin B = 80 unit.

Mesin C = 120 unit.

Mesin B menjadi constraint.

Jika production planning menjadwalkan A dan C secara maksimal, maka material akan terus masuk ke B.

Akibatnya WIP meningkat.

Warehouse semakin penuh.

Lead time meningkat.

Dan akhirnya perusahaan terlihat sangat sibuk. Namun output finished goods tidak meningkat secara proporsional. TOC mengajarkan bahwa jadwal produksi harus memperhatikan kapasitas constraint. Jangan membanjiri sistem dengan pekerjaan hanya agar setiap mesin terlihat sibuk.

8. TOC dan Konsep "Busy"

Ada satu fenomena menarik di dunia operasional. Orang sibuk belum tentu sistem produktif Mesin berjalan terus belum tentu perusahaan menghasilkan profit lebih besar. Warehouse penuh belum tentu inventory sehat. Truck terus keluar masuk belum tentu delivery efisien. Operator overtime belum tentu produktivitas meningkat.

Inilah perbedaan antara:

Activity

dan

Result.

TOC lebih menekankan hasil sistem. Jika sebuah aktivitas tidak meningkatkan throughput atau tidak membantu mengurangi constraint, kita perlu mempertanyakan apakah aktivitas tersebut benar-benar prioritas.

9. TOC dan Continuous Improvement

TOC bukan pengganti Lean atau Six Sigma. Justru ketiganya dapat saling melengkapi.

TOC bertanya, Di mana constraint-nya?

Lean bertanya, Di mana waste-nya?

Six Sigma bertanya, Di mana variasi dan akar penyebabnya?

Ketiganya dapat digunakan secara bersama. Misalnya ditemukan bottleneck pada mesin tertentu. TOC membantu menentukan bahwa mesin tersebut adalah constraint. Kemudian Lean digunakan untuk menghilangkan waste seperti waiting, motion, transportation, atau overprocessing. Six Sigma dapat digunakan jika masalah berkaitan dengan variasi proses dan kualitas. QCC kemudian dapat menjadi mekanisme keterlibatan tim dalam menyelesaikan masalah tersebut.

Jadi, pendekatannya bukan, TOC versus Lean versus Six Sigma.

Melainkan, TOC menentukan fokus, Lean menghilangkan waste, Six Sigma mengendalikan variasi, dan QCC melibatkan orang dalam pemecahan masalah.

10. Jangan Terjebak Mengejar Utilisasi 100%

Ini salah satu pelajaran penting dari TOC. Secara intuitif, perusahaan ingin setiap mesin bekerja sepanjang waktu. Utilisasi tinggi terlihat bagus. Tetapi utilisasi 100% pada proses yang bukan constraint bisa menghasilkan masalah.

Jika mesin tersebut menghasilkan lebih banyak daripada yang dapat diproses oleh constraint, output tambahannya hanya menjadi inventory atau WIP.

Misalnya, 

Proses A: 120 unit/jam

Constraint B: 80 unit/jam

Jika A dipaksa beroperasi 100%, maka A akan menghasilkan 40 unit/jam lebih banyak daripada kemampuan B. Dalam waktu tertentu, selisih tersebut menjadi WIP.

Maka pertanyaan yang lebih tepat bukan, "Apakah mesin kita sudah bekerja maksimal?"

Tetapi, "Apakah kapasitas mesin tersebut benar-benar dibutuhkan oleh sistem?"

Ini adalah perubahan paradigma yang sangat penting.

11. TOC dan Tiga Ukuran Utama

Dalam kerangka TOC, Goldratt banyak membahas tiga ukuran utama:

Throughput, Seberapa cepat sistem menghasilkan uang melalui penjualan.

Inventory, Uang yang diinvestasikan sistem dalam sesuatu yang dimaksudkan untuk dijual atau menghasilkan throughput.

Operating Expense, Uang yang dikeluarkan sistem untuk mengubah inventory menjadi throughput.

Ketiganya membantu mengubah perspektif dari sekadar efisiensi departemen menjadi ekonomi sistem.

Contohnya:

Production meningkatkan output, tetapi produk tidak terjual.

Inventory meningkat.

Throughput belum tentu meningkat.

Operating expense mungkin ikut meningkat.

Secara lokal production terlihat produktif.

Secara bisnis, hasilnya belum tentu lebih baik.

12. Contoh Sederhana: Mengapa Menambah Mesin Belum Tentu Solus

Bayangkan sebuah pabrik memiliki:

Production capacity: 10.000 unit/bulan

Packing capacity: 7.000 unit/bulan

Warehouse dispatch capacity: 6.000 unit/bulan

Jika permintaan pelanggan 8.000 unit/bulan, maka perusahaan memiliki beberapa titik yang perlu dianalisis. Menambah kapasitas produksi dari 10.000 menjadi 15.000 unit tidak menyelesaikan masalah jika dispatch hanya mampu menangani 6.000 unit. Bahkan perusahaan mungkin menghasilkan semakin banyak inventory.

Jika constraint berada di dispatch, maka investasi pertama seharusnya diarahkan pada dispatch. Setelah dispatch meningkat, mungkin packing kemudian menjadi constraint. Setelah packing ditingkatkan, constraint dapat berpindah lagi.

Inilah TOC. Bukan mencari satu solusi untuk selamanya. Melainkan terus menemukan titik yang paling membatasi sistem pada saat itu.

13. Pertanyaan TOC yang Harus Dimiliki Seorang Manager

Seorang Manager tidak harus menjadi ahli statistik atau engineer untuk mulai menggunakan TOC. Tetapi seorang Manager harus mampu mengajukan pertanyaan yang tepat.

Ketika output tidak mencapai target, "Apa yang sebenarnya membatasi output?"

Ketika warehouse penuh, "Di proses mana inventory mulai menumpuk?"

Ketika mesin banyak, "Mesin mana yang benar-benar membatasi throughput?"

Ketika tenaga kerja sibuk, "Kesibukan ini menghasilkan output atau hanya menghasilkan aktivitas?"

Ketika ada usulan investasi, "Apakah investasi ini menghilangkan constraint?"

Ketika improvement selesai, "Setelah constraint ini hilang, constraint berikutnya berada di mana?"

Pertanyaan-pertanyaan tersebut mengubah cara Manager melihat organisasi.

Dari melihat departemen menjadi melihat sistem.

Dari melihat aktivitas menjadi melihat aliran.

Dari melihat efisiensi lokal menjadi melihat hasil keseluruhan.