Toyota Jidoka dan Continuous Integration


“Quality is never an accident, it is always the result of intelligent effort.” – John Rushkin

Sekarang ini gw sedang menjalani mata kuliah Operations Management. Salah satu hal yang paling menarik disini adalah rahasia di balik kesuksesan Toyota dalam hal produksinya. Toyota mempunyai apa yang disebut Toyota Production Systems. Ada dua hal yg penting dalam TPS, yaitu JIT (Just-In-Time) dan Jidoka. Just-in-time intinya adalah memproduksi barang berdasarkan apa yang diinginkan, pada saat yang diinginkan, dan dalam jumlah yang diinginkan juga (kata kuncinya adalah NEEDS). Sedangkan Jidoka adalah proses produksi barang yang diselaraskan dengan tingkat kualitas (kata kuncinya BUILT-IN-QUALITY). Jidoka memungkinkan keadaaan dimana setiap ada masalah (mesin rusak atau keterlambatan atau defect pada produk) dalam manufacturing, maka mesin akan berhenti dan memberikan alert kepada team leader atau supervisor. Berikut ilustrasinya,
jidoka

Jidoka ini didukung dengan sebuah alat untuk memvisualisasikan permasalahan yang ada pada pos2 tertentu dalam manufacturing yaitu Andon. Lihat gambar di bawah,

andon

Angka2 di atas menunjukkan pos2 dalam manufacturing, ada 3 warna dalam dalam angka2 tersebut. Merah menunjukkan bahwa ada masalah di pos tsb kemudian supervisor atau team lead akan mendatangi pos tersebut untuk membantu menyelesaikan permasalahannya.

Ternyata apa yang dipraktekan di Toyota tidak jauh berbeda dengan apa yang terjadi di dalam software development, terutama di project2 open source. Di dalam software development hal ini dikenal dengan nama Continuous Integration. Continuous integration adalah praktek dalam software development dimana team member diwajibkan untuk sesering mungkin mengintegrasikan kerjaannya dengan developer yang lain. Biasanya ritmenya per hari atau sering disebut daily build. Setiap proses integrasi tsb akan dilakukan pengujian secara otomatis untuk mendapatkan defect atau problem secepat mungkin dan selanjutnya diperbaiki. Bedanya dengan Jidoka yang menghentikan proses produksi untuk sementara, dalam continuous integration kita bisa lakukan paralel dengan kegiatan2 lainnya.

Berikut adalah ilustrasi mengenai Continuous Integration (diambil dari IBM.com).

  • Developer check-in/memasukkan codenya ke dalam Software Configuration Management (SCM) atau dikenal juga dengan nama Version Control
  • Integration Build Server akan memonitor perubahan2 pada SCM (setiap kali developer melakukan [1] )
  • Eksekusi build yang biasanya terdiri dari berbagai jenis testing, unit testing, coverage testing, dan integration testing
  • Kirimkan hasil build ke team member project
  • Deploy aplikasi yang sukses di build ke development application yang selanjutnya bisa digunakan untuk melakukan functional testing oleh tester.
Continuous IntegrationContinuous Integration 

Pentingnya hasil build membuat beberapa developer yang ekstrim mengintegrasikannya dengan orb, lavalamp, dan traffic lamp. Sama seperti Andon di Toyota yang mempunyai tiga warna, continious juga mempunyai tiga warna sebagai indikator hasil build. Berikut adalah hasil karya mereka,

  • Integrasi dengan Lavalamp
    lava-lamp
  • Integrasi dengan traffic lamp
    traffic-light

Sekarang pertanyaanya kenapa defect harus ditemukan secepatnya? apa bedanya kalau defect ditemukan pada saat internal testing atau user accepatance testing lalu kemudian diperbaiki? bukannya kalau benerin defect pada saat production malah membuat waktu production semakin lama? gimana korelasi antara ini cost dengan quality?

Alasan yang pertama adalah kesan dari user. Kesan dari user pasti berbeda jika mereka menemukan 1000 defect  daripada 100 defect. Itulah kenapa biasanya kita punya 2 fase testing, testing internal baru kemudian testing oleh user. Yang kedua adalah effort, defect yang ditemukan di akhir fase akan sangat lama untuk diselesaikan. Jika codebase dari aplikasi yang dibuat sudah besar, menemukan penyebab masalah sudah menjadi masalah tersendiri, belum lagi bagaimana solvenya, kalaupun sudah solve apakah sudah yakin tidak akan myebabkan defect di tempat lain?. Beda skenarionya jika defect ditemukan sedini mungkin, effort untuk menemukan penyebab permasalahan berkurang dan defect bisa langsung diperbaiki. Dan jika ternyata menimbulkan defect di tempat lain, developer akan dapat alertnya sedini mungkin dan langsung memperbaiknya.

Apakah meningkatkan kualitas berarti meningkatkan cost? Sepintas kita menjawab, YA. Tapi jika ditelusuri lebih mendalam, dengan kualitas yang tinggi maka akan mengurangi jumlah defect yang ada, dengan minimnya defect effort/cost untuk rework pun bisa diminimalisir. Sehingga dengan pendekatan spt itu Toyota bisa memproduksi mobil dengan kualitas tinggi dengan harga terjangkau, Itulah konsep yang diusung Toyota yaitu Better Car at Better Price for More People.

Demikian sekilas info kemiripan antara Jidoka Toyota dengan Continuous Integration.

Advertisements

About 327rudy

young, talented, dynamic, creative, fight like a tiger, win like a champion
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s